Photon: izgūšanas un ranžēšanas dzinēja būvēšana no nulles

Ievads

Perplexity AI-native meklēšanas staks izgūst un ranžē kandidātlapas, parādot atbilstošāko saturu, lai modelis pamatotu savas atbildes. Sākotnēji šis posms darbojās uz atvērtā koda dzinēja, ko mēs pielāgojām savai sistēmai. Tomēr, pieaugot mūsu indeksam un darba slodzēm, mēs saskārāmies ar stingriem ierobežojumiem attiecībā uz izmaksām, aizkaves pīķa vērtību un mezgla atgūšanas laiku, kurus mēs nevarējām atrisināt esošās trešās puses platformas ietvaros.

Lai pārvarētu šos izaicinājumus, mēs uzbūvējām Photon – jaunu iekšējo izgūšanas un ranžēšanas dzinēju. Tas turpina mūsu pieeju būvēt AI-first meklēšanas infrastruktūru no nulles, kā mēs to darījām ar CobbleDB – mūsu izkliedēto atslēgu-vērtību krātuvi lapu ierakstu apkalpošanai – un mūsu Search API.

Photon izmanto kompaktus datu formātus, lai nolasītu un atšifrētu tikai to, kas nepieciešams katram vaicājumam, izmantojot pakešdarbu apziņas kešatmiņu un asinhrono nolasīšanu, lai samazinātu diska piekļuvi un pārklātu gaidīšanas laiku. Indeksa veidošana norit atsevišķi no vaicājumu apkalpošanas, atjaunojot vienu apkalpošanas grupu vienlaikus un sasildot tās kešatmiņu pirms tiešsaistes vaicājumu maršrutēšanas uz to.

Photon tagad nodrošina mūsu meklēšanas konveijeru un ir arī pamats jaunam ātrajam iestatījumam mūsu Search API ar viena meklēšanas izsaukuma aizkavi 160 ms pie p50 un 230 ms pie p95. Sešos publiskajos etalonuzdevumos ātrais iestatījums samazināja aptuvenās modeļa un meklēšanas izmaksas uz vienu uzdevumu par 68%, vienlaikus saglabājot kopējo uzdevumu kvalitāti, kas ir salīdzināma ar noklusējuma iestatījumu. Mēs to izlaižam šodien, lai izstrādātāji varētu piekļūt šiem uzlabojumiem.

Izvērst

Izvērst

Kas nepieciešams izgūšanas un ranžēšanas dzinējam

Katram vaicājumam izgūšanas un ranžēšanas dzinējs meklē lielā, izkliedētā indeksā, lai atlasītu un sakārtotu nelielu atbilstošu lapu kopu meklēšanas staka aizkaves budžetā. Sistēmai ir arī jāuztur indekss aktuāls, kad ierodas jaunas lapas un mainās esošās, neļaujot šim darbam palēnināt tiešsaistes vaicājumus.

Mēs novērtējām vairākas atvērtā koda opcijas un izvēlējāmies nobriedušu, vispārējas nozīmes izgūšanas un ranžēšanas dzinēju, kas atbilda mūsu sākotnējām vajadzībām. Pēc tam mēs to pielāgojām mūsu arhitektūrai un darba slodzēm, saglabājot stabilu aizkavi un caurlaidi ražošanas mērogā.

Kur mūsu iepriekšējā sistēma kļuva par īsu

Mēs uzturējām savu zaru (fork), lai pielāgotu dzinēju mūsu augošajam indeksam, taču galveno ierobežojumu novēršana arvien vairāk prasīja lielu platformas daļu pārstrādi. Vairākus ierobežojumus izrādījās grūti atrisināt bez fundamentālām arhitektūras izmaiņām:

1. Mērogošanas izmaksas. Gan dokumentu skaits, ko uzglabājam, gan katram dokumentam nepieciešamo datu apjoms, ko mums vajag izgūt un ranžēt, laika gaitā ir audzis. Šī mērogošana radīja spiedienu uz mūsu aparatūru, jo īpaši uz pieejamās RAM daudzumu. Lai kontrolētu izmaksas, mums bija nepieciešami kompaktāki datu attēlojumi un smalkāka kontrole pār to, kas paliek atmiņā un kas tiek nolasīts no diska pēc pieprasījuma.

2. Slikta aizkaves pīķa vērtība (tail latency). Ražošanas datplūsmā vecās sistēmas p99 atbildes laiks bija aptuveni 800 ms. Datu kopa pārsniedza pieejamo RAM, tāpēc mēs nevarējām izmantot mlock, lai to pilnībā saglabātu atmiņā. Piekļuve nerežidentiem datiem varēja izraisīt nopietnas lapas kļūdas (page faults), apturot vaicājuma izpildi, kamēr operētājsistēma lasīja no diska.

Dzinējs arī periodiski apvienoja savu galveno diska indeksu ar mazākiem indeksiem, kas izskaloti no atmiņas. Šī diska indeksa saplūšanas procesa laikā lapas kļūdu skaits pieauga vēl vairāk, p99 aizkavei sasniedzot aptuveni 1,2 s uz 10–15 minūtēm. Kešatmiņai iesilstot, lapas kļūdu biežums un aizkave samazinājās, liecinot, ka aukstā nolasīšana bija nozīmīgs pīķu cēlonis. Datu iepriekšēja ielāde un indeksa sasildīšana samazināja pīķus, bet adekvāti neatrisināja lielo aizkaves pīķa vērtību.

3. Ilgstoša atgūšana un sinhronizācija. Iepriekšējā sistēmā papildu klustera izvietošana un tā datu sinhronizācija varēja aizņemt vairāk nekā nedēļu. Sinhronizācija bija nepieciešama arī, pievienojot mezglu grupas papildu datu kopiju glabāšanai vai atgūstoties no mezgla kļūmēm. Atgūšanās laikā lielāka meklēšanas atbilžu daļa bija daļēja, kas pazemināja gala atbildes kvalitātes rādītājus.

Galu galā mēs secinājām, ka būtu vienkāršāk un lētāk būvēt no nulles, nevis turpināt pielāgot un uzturēt mūsu zaru (fork). Balstoties uz mūsu pieredzi, ekspluatējot iepriekšējo sistēmu, neliela inženieru komanda strādāja kopā ar pastāvīgu kodēšanas aģentu baru, lai izveidotu Photon.

Kur Photon iederas meklēšanas stakā

Photon ir izstrādāts divām galvenajām darbplūsmām: meklēšanas pieprasījumu apkalpošanai un atjauninājumu uzņemšanai no apstrādes konveijera.

Pieprasījums no augstāka līmeņa meklēšanas pakalpojuma sasniedz Photon brokeri caur slodzes balansētāju. Brokers izvēlas šardu grupu un pārsūta pieprasījumu uz katru šardu, uzraugot taimautus un izsniedzot papildu pieprasījumus, kad nepieciešams.

Katrs šards veic izgūšanu, sākotnējo ranžēšanu un otrā posma ranžēšanu, pēc tam atgriež savus labākos kandidātus brokerim. Brokers apvieno šos kandidātus vienā sakārtotā sarakstā un izvelk galvenos dokumenta laukus atlasītajām lapām no attiecīgajiem šardiem. Pēc tam tas atgriež šos rezultātus augstāka līmeņa meklēšanas pakalpojumam, kas savāc lapas saturu, kas nepieciešams aģentam, lai ģenerētu pamatotu atbildi.

Indeksa atjauninājumi seko atsevišķam ceļam. Pillar, mūsu publicēšanas slānis, sagatavo datus un glabā tos YTsaurus tabulās. Indekstētāji pārvērš šīs tabulas indeksa struktūrās, kuras šardi var ielādēt meklēšanai. Kontrolieris koordinē datu sagatavošanu, indeksa veidošanu un jaunu indekss versiju izvietošanu apkalpošanas grupās. Pirms tiešsaistes datplūsmas apstrādes katrs šards atkārto reālos meklēšanas vaicājumus, lai sasildītu savu kešatmiņu.

Izvērst

Photon izstrāde mūsu darbplūsmām

Trīs dizaina izvēles padara Photon labi piemērotu mūsu darba slodzei: kompakti datu attēlojumi, kešatmiņa un asinhronā diska nolasīšana, kā arī indeksa atjauninājumu nošķiršana no vaicājumu apkalpošanas.

Datu attēlojums izgūšanai un ranžēšanai

Izgūšana un ranžēšana piekļūst dokumentu datiem dažādi. Leksiskā izgūšana sākas ar vaicājuma terminiem un atrod dokumentus, kas tos satur. Pēc tam ranžēšanai ir nepieciešama detalizēta informācija par katru atlasīto dokumentu, ieskaitot terminu frekvences un pozīcijas.

Photon izmanto divus papildinošus attēlojumus, lai atbalstītu šos piekļuves modeļus. Inversais indekss katram termam saglabā atbilstošo dokumentu sarakstu, ko sauc par publicēšanas sarakstu, lai atbalstītu kandidātu atlasi. Atsevišķi ieraksti katram dokumentam nodrošina ranžēšanai nepieciešamos datus. Mēs arī optimizējam to, kā publicēšanas saraksti tiek glabāti un šķērsoti, lai uzlabotu atlasi fiksētā darba budžetā.

Specializēti datu attēlojumi ļauj efektīvāk uzglabāt galvenos datus. Kompaktāks inversais indekss samazina katrā vaicājumā nolasīto vai pārvietoto datu apjomu, uzlabojot aizkavi, novēršot nevajadzīgas I/O operācijas. Šie formāti arī ļauj pārbaudīt, vai dokuments parādās sarakstā, to pilnībā neatšifrējot – īpašība, uz paļaujas mūsu šķērsošanas loģika, lai kontrolētu darba apjomu, ko vaicājums veic noteiktā budžetā. Ierakstu optimizēšana katram dokumentam ļauj saglabāt vairāk datu vienam dokumentam ranžēšanai, vienlaikus samazinot mērogošanas izmaksas, kas saistītas ar mūsu iepriekšējo sistēmu.

Inversais indekss

Katram termam inversais indekss glabā publicēšanas sarakstu. Šie saraksti var svārstīties no nedaudziem dokumentiem līdz miljoniem, tāpēc neviens atsevišķs formāts neder katram sarakstam. Photon izvēlas formātu, pamatojoties uz to dokumentu skaitu, kuros ir šis terms.

Īsi saraksti izmanto iekļautu (inline) attēlojumu, kas ietilpst vienā lapā un neprasa bloku tabulu. Garāki saraksti, kas neietilpst iekļautajā formātā, tiek sadalīti blokos, kas aptver fiksētus dokumentu identifikatoru diapazonus. Katra bloka attēlojums ir atkarīgs no tā blīvuma: retie (sparse) bloki glabā sakārtotus dokumentu ID nobīžu masīvus, savukārt blīvie bloki izmanto bitu kartes (bitmaps). Retie bloki izmanto galopējošu meklēšanu (galloping search), kas virzās ar arvien lielākiem soļiem, lai izlaistu saraksta reģionus. Blīvie bloki ļauj veikt dalības pārbaudes, uzmeklējot bitu, kas atbilst dokumentam.

Terma vaicājuma frekvence nosaka, kur tā publicēšanas saraksts tiek izvietots uz diska. Bieži vaicātie saraksti tiek glabāti tuvu viens otram, koncentrējot karstos datus mazākā krātuves reģionā. Katrā sarakstā dokumenti tiek sakārtoti pēc atsevišķa lietderības signāla, lai daudzsološāki kandidāti tiktu sastapti agrāk.

Izvērst

Sarakstu šķērsošana darba budžeta ietvaros

Kandidātu atlase prasa publicēšanas sarakstu šķērsošanu, lai atrastu potenciāli atbilstošus dokumentus. Katra saraksta izsmeļoša skenēšana ir dārga, tāpēc Photon izmanto WAND-līdzīgu algoritmu, kas šķērso tikai dažus sarakstus, vienlaikus ņemot vērā sakritības pārējos.

Algoritms sadala sarakstus divās grupās. Virzošie saraksti virza šķērsošanu un iesaka kandidātdokumentus. Zondes saraksti dod ieguldījumu šo kandidātu vērtībās, bet paši ģenerē kandidātus.

Kandidātu vērtēšana apvieno svērtu vaicājuma terminu pārklājumu un frekvences ieguldījumu, ar dokumenta garuma normalizāciju un ierobežojumu ieguvumiem no atkārtotiem terminiem. Photon vispirms pārbauda terminu klātbūtni masīvos un bitu kartēs, lai ierobežotu katra kandidāta maksimālo iespējamo vērtību. Tas nolasa precīzas terminu frekvences tikai tiem kandidātiem, kuri joprojām var sasniegt atlases slieksni.

Pēc tam atlase norit trīs soļos:

• Šķērsošana: Sāciet ar stingru vaicājuma pārklājuma prasību. Ja tiek atrasts pārāk maz kandidātu, atkārtojiet ar atvieglotu prasību.
• Saglabāšana: Kandidāti tiek turēti ierobežotā kopā, izmantojot punktu skaitu, kas apvieno pārklājumu un frekvenci. Uzlabojoties savāktajiem top kandidātiem, uzņemšanas slieksnis paaugstinās.
• Galīgā atlase: Cikla gala rezultāti tiek izvēlēti no saglabātās kopas, pamatojoties uz frekvences punktiem. Katrs lauks veic savu ciklu, un rezultāti tiek apvienoti, izmantojot lauku svarus.

Algoritms ģenerē atbilstošu dokumentu kandidātu kopu, ko izmantot tālākā ranžēšanā.

Izvērst

Docblob

Pēc kandidātlapu atlases ranžēšanas fāzei ir nepieciešamas termu frekvences, lauku pārklājums, kā arī parādīšanās vietas un tuvums. Šo datu iegūšana, izmantojot inverso indeksu, prasītu izkliedētas piekļuves daudzos termu un dokumentu pāros. Photon mēs glabājam kompaktu ierakstu katram dokumentam, ko sauc par docblob un kas satur termu frekvences, laukus, kuros termiņš parādījās, un dokumenta vietu, kur tas notika. Tā rezultātā kandidāta ranžēšanai nepieciešama tikai viena uzmeklēšana katram dokumentam.

Formāts ir veidots tā, lai izvairītos no liekas atšifrēšanas. Docblob ietvaros lauki ir sagrupēti pēc teksta analizatora. Katra grupa glabā sakārtotu terminu sarakstu, kas kodēts ar Elias-Fano, tāpēc vaicājuma terminu var tieši uzmeklēt, vispirms nepaplašinot visu sarakstu. Lauka maska atzīmē vietu, kur terms parādījās, frekvences skaitītājs seko līdzi tam, cik bieži, un faktiskās pozīcijas atrodas atsevišķos blokos katram termu un lauku pārim, kas kodēti kā pozīciju starpības. Tiek atšifrēti tikai tie bloki, kuru termi faktiski sakrita, savukārt viss pārējais ierakstā paliek saspiestajā formātā.

Šī izgūstamā atlase ļauj docblob atbalstīt lielāka datu apjoma uzglabāšanu katram dokumentam bez proporcionāla izmaksu pieauguma. Ieraksta palielināšana neuzspiež lielāku darbu uz vienu uzmeklēšanu, jo ranžēšana vienmēr skar tikai tās daļas, kas attiecas uz atbilstošajiem terminiem, nevis visu ierakstu.

Izvērst

Pakešveida nolasīšana un darbs ar atmiņu

Pat ar efektīvākiem datu attēlojumiem RAM joprojām beidzas pirms citiem resursiem, tāpēc mums bieži ir nepieciešams piekļūt datiem, kas glabājas uz diska. Photon izmanto asinhrono diska nolasīšanu un kešatmiņu, kas optimizēta pakešveida nolasīšanai, lai paātrinātu šīs piekļuves, samazinot gaidīšanas laiku vienā pieprasījumā. Tas veicina ievērojamu aizkaves pīķa vērtības uzlabojumu salīdzinājumā ar iepriekšējo sistēmu.

Izvērst

Pārklājošās diska gaidīšanas

Ranžēšana prasa iegūt simts dokumentu pazīmes, kas atrodas dažādās faila daļās. Mūsu iepriekšējā sistēma izmantoja mmap, lai kartētu failu virtuālās adreses telpā, lai to varētu nolasīt caur atmiņas rādītājiem. Tomēr piekļuve lapai, kas nebija atmiņā, joprojām prasīja diska nolasīšanu. Pavedienam bija jāgaida dati pirms skaitļošanas turpināšanas, un šis gaidīšanas laiks summējās, kad procesam vajadzēja secīgi nolasīt aukstos ierakstus.

Photon izmanto to, ka ierakstu nobīdes ir zināmas jau iepriekš, tāpēc mēs varam vienlaikus iesniegt vairākas nolasīšanas darbības. To pārvalda reaktors: īpaši darba pavedieni iesniedz pakešdarbus, izmantojot io_uring, un nodod nolasītos datus izsaucošajam kodam. Katrs pavediens uztur savu io_uring; paketes tiek nosūtītas reaktoram ar mazāko noslodzi. Iepriekš reģistrēti failu deskriptori un buferu kopas samazina atkārtotu nolasīšanu pieskaitāmās izmaksas. Šī asinhronā izpilde ļauj vairāku operāciju gaidīšanai pārklāties, samazinot aizkaves pīķa vērtības (tail latency).

Diska piekļuves reižu skaita samazināšana

Pirms nolasīšanas iesniegšanas Photon pārbauda visu paketi operatīvās atmiņas kešatmiņā. Uz disku dodas tikai pieprasījumi pēc trūkstošajiem ierakstiem; nolasītie dati pēc tam aizpilda kešatmiņu.

Kešatmiņa ir izstrādāta pakešveida nolasīšanai. Konkrēti:

• Trāpījuma gadījumā nav atsevišķas piešķires. Tā vietā dati tiek kopēti buferī, ko iepriekš sagatavojis izsaucošais kods.
• Lasītājs neveic slēdzenes iegūšanu. Tā vietā tas pārbauda datu versiju un mēģina vēlreiz, ja tā konfliktē ar rakstīšanu.
• Tas izmanto CLOCK evakuāciju (eviction), nevis pieprasa atjauninājumus koplietotam LRU sarakstam katrā nolasīšanā.
• Tas izmanto procesora (CPU) kešatmiņas iepriekšējo ielādi (prefetching), kurā metadati un dati gaidāmajiem ierakstiem tiek pieprasīti iepriekš.

Šie optimizācijas pasākumi samazina aizkavi, nekaitējot veiktspējai darba slodzēs, kas mums rūp.

Indeksa būvēšana un atjaunināšana atsevišķi no apkalpošanas

Photon indeksu veidošana un vaicājumu apkalpošana darbojas uz dažādiem mezgliem. Indekstētāji pārveido datus lietošanai gatavās krātuves struktūrās, savukārt apkalpošanas mezgli tos nolasa un veic izgūšanu un ranžēšanu. Tā rezultātā indeksa būvēšana nekonkurē ar meklēšanas vaicājumiem par CPU resursiem, un šo uzdevumu resursus var mērogot neatkarīgi.

Šī nošķiršana atrisina atgūšanas un sinhronizācijas vājās vietas, kas pastāvēja iepriekšējā implementācijā. Tā kā indeksa veidošana noritēja tajā pašā klusterī, kas apkalpoja vaicājumus, kļūmīgi nostrādājuša mezgla atgūšana vai jaunas datu kopijas pievienošana varēja nozīmēt dokumentu atkārtotu indeksēšanu uz vietas – process, kas aizņēma dienas un palielināja daļējo atbilžu skaitu atgūšanas laikā. Photon noņem šo sasaisti; indeksētāji darbojas kā izkliedēti darbi, kas rada versijās sadalītas, lietošanai gatavas indeksa struktūras neatkarīgi no apkalpošanas mezgliem, tāpēc nākamās indeksa versijas būvēšana vairs nekonkurē ar tiešsaistes datplūsmu.

Izvērst

Sagatavošana un izkliedētā būvēšana

Būvniecība sākas, atlasot dokumentus aktīvajam indeksam un sagatavojot avota eksportu. Kontrolieris reģistrē avota versiju, ievades tabulas un paredzēto šardu skaitu. MapReduce darbi YTsaurus sagatavo tekstu, metadatus, fragmentus, pazīmes un iepriekš aprēķinātos iegultos datus (embeddings) versijās sadalītās tabulās, kas sadalītas pa šardiem. Katrs indeksētājs straumē sagatavoto tabulu, izveido struktūras savam šardam un apvieno teksta segmentus. Gatavais indekss kopā ar tā komponentu aprakstu tiek augšupielādēts objektu krātuvē.

Šardu skaits un vienlaikus darbojošos indeksētāju skaits tiek konfigurēts neatkarīgi, tāpēc būvniecība var notikt vairākos viļņos vai var tikt piešķirts vairāk mašīnu darbam paralēli. Izkliedētā sagatavošana un paraleliezētie indeksētāji ļauj izveidot visu tīmekļa indeksu dažu stundu laikā (single-digit number of hours), kas ir ievērojams uzlabojums salīdzinājumā ar iepriekšējo sistēmu.

Jaunas versijas izvietošana

Pirms izvietošanas kontrolieris pārbauda, vai jaunais indekss ir gatavs. Ja dati nav pilnīgi, izvietošana tiek automātiski bloķēta.

Ja ir vairākas apkalpošanas grupas, kontrolieris tās atjaunina pa vienai. Tas vispirms noņem grupu no brokeru maršrutēšanas un sāk to jaunajā indeksa versijā. Pirms pieprasījumu apkalpošanas šardi iziet cauri atsevišķam iesildīšanās posmam, pamatojoties uz meklēšanas žurnāliem, kas iepriekš aizpilda sākotnējo stāvokli un padara pāreju uz reālu datplūsmu vienmērīgāku. Pēc iesildīšanās kontrolieris pārbauda indeksa stāvokli un gatavību, pēc tam atgriež grupu maršrutēšanā. Citas grupas šajā laikā turpina apkalpot pieprasījumus. Tā kā darbības stāvoklis tiek saglabāts, restartēšana neuzspiež būvniecības sākšanu no jauna; kontrolieris var atkārtoti pievienoties jau notiekošai sagatavošanai, atkārtoti izmantot gatavu rezultātu vai turpināt pārtrauktu rotāciju no saglabātā soļa.

Datu atjaunināšanas laiki atšķiras dažādās meklēšanas vertikālēs. Vertikālēm ar augstām svaiguma prasībām dokumentu piegāde aizņem dažas minūtes (single-digit number of minutes). Papildu datu kopiju var izvietot aptuveni pusstundas laikā; gatavie indeksi tiek ielādēti un piesaistīti šardiem, atkārtoti neindeksējot avota dokumentus.

Izvērst

Migrācija un validācija mūsu meklēšanas stakā

Mūsu pirmais mērķis bija aizstāt veco sistēmu ar dzinēju, kas saglabā funkcionalitāti un meklēšanas kvalitāti, vienlaikus samazinot atbildes laikus. Mēs validējām Photon pa posmiem, sākot ar reproducējamiem slodzes testiem un bezsaistes kvalitātes novērtējumiem pirms pārejas uz tiešsaistes datplūsmu. Photon tagad nodrošina izgūšanu un ranžēšanu mūsu ražošanas meklēšanas stakā, ar ievērojami zemākiem atbildes laikiem nekā vecajai sistēmai.

Slodzes testēšana un novērtējumi

Veiktspējas testēšanai mēs izveidojām slodzes testēšanas rīku, kas atkārto vaicājumus no mūsu meklēšanas žurnāliem ar konfigurējamiem ienākšanas ātrumiem. Tas salīdzina rezultātus dažādos ciklos un piemēro statistiskos testus, lai novērtētu, vai novērotās veiktspējas atšķirības ir konsekventas. Atsevišķi mēs novērtējām Photon un veco sistēmu tajās pašās datu kopās mūsu iekšējās bezsaistes novērtēšanas sistēmās, lai pārbaudītu kvalitātes regresijas.

Pēc šīm pārbaudēm mēs nosūtījām tiešsaistes vaicājumus uz abiem dzinējiem vienlaikus, izmantojot ēnu datplūsmu (shadow traffic). Tas ļāva mums salīdzināt to veiktspēju un rezultātus ražošanas darba slodzēs pirms maiņas, kurš dzinējs apkalpo lietotājus. Pēc tam mēs iespējojām Photon nelielām lietotāju apakškopām un pakāpeniski paplašinājām ieviešanu, visu laiku uzraugot kvalitāti un veiktspēju. Pirmā versija izturēja pieņemšanas testēšanu bez kvalitātes regresijām, un mēs turpinājām ieviešanu, līdz Photon apkalpoja visu ražošanas datplūsmu.

Izmērītie uzlabojumi ražošanā

Mūsu ražošanas darbplūsmā p99 atbildes laiks kritās no aptuveni 800 ms vecajā sistēmā līdz aptuveni 65 ms Photon. Šis mērījums sedz visus posmus Photon iekšienē, bet izslēdz turpmākos posmus augstāka līmeņa meklēšanas stakā. Mēs vairs nenovērojam arī aizkaves pīķus, kas iepriekš bija saistīti ar indekss versiju maiņu.

Photon izmanto aptuveni par 20% mazāk ekvivalentu apkalpošanas mašīnu nekā vecās sistēmas satura mezgli, vienlaikus uzglabājot aptuveni 2,5 reizes vairāk datu katram dokumentam. Pēc migrācijas mēs izmantojām šos papildu datus, lai uzlabotu ranžēšanas kvalitāti, pārsniedzot vecās sistēmas kvalitāti.

Photon arī samazina datu apjomu, kam jāpaliek atmiņā (RAM). Tāda paša Photon datu kopas piespraušana operatīvajā atmiņā ar mlock prasītu aptuveni 4,6 reizes vairāk rezidentās atmiņas, nekā Photon pašlaik izmanto.

Ātrā Search API iestatījuma novērtējums

Mēs arī izmantojām Photon par pamatu jaunam ātrajam iestatījumam mūsu Search API, kas izstrādāts darba slodzēm, kuras ir jutīgas pret aizkavi. Saskaņā ar mūsu mērījumiem, viena meklēšanas izsaukuma aizkave ātrajam iestatījumam ir 160 ms pie p50 un 230 ms pie p95, kas ir zemāka par vai salīdzināma ar citiem Search API nodrošinātāju pašu ziņotajiem skaitļiem, lai gan uzrādītās pīķa procentiles atšķiras.

Mēs novērtējām ātro iestatījumu sešos aģentu etalonuzdevumos: WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0 un SEAL-Hard. Šajos novērtējumos tam bija zemākās aptuvenās kopējās modeļa un meklēšanas izmaksas un augstākais kopējais uzdevumu rezultāts starp testētajām konfigurācijām.

Ātrā iepriekšējā iestatīšana savieno Photon ar reitingu, kas optimizēts aģentu darbplūsmām, nodrošinot salīdzināmu veiktniarbu ar noklusējuma iepriekšējo iestatīšanu par ievērojami zemākām izmaksām. Tomēr tai ir kompromiss plašākā meklēšanas kvalitātē. Ātrā iepriekšējā iestatīšana izmanto mazāk skaitļošanas resursu reitingam nekā noklusējuma iestatīšana. Iekšējos etalonos, kas aptver garās astes vaicājumus, plašu pārklājumu un rezultātu dažādību, tā iegūst par 0,24 punktiem zemāku atbilstību un aptuveni par 3 procentu punktiem zemāku atbilžu pieejamību. Mēs uzskatām, ka tas ir saprātīgs kompromiss aģentu darbplūsmām, jo modeļa pašas Spriestspēja un zināšanas var palīdzēt kompensēt šo atšķirību.

Izvērst

Mēs iesakām ātro iestatījumu ikdienas aģentu uzdevumiem. Sarežģītākiem vai neskaidrākiem jautājumiem, kas ir mazāk jutīgi pret laiku, noklusējuma iestatījums piedāvā stabilāku kvalitāti, pamatojot to ar augstāku aizkavi un izmaksām.

Secinājums

Mēs stabili virzām savu meklēšanas staku uz Rust-bāzētu, iekšējo infrastruktūru. Atvērtā koda dzinēja aizstāšana ar Photon, mūsu pielāgoto izgūšanas un ranžēšanas dzinēju, ir jaunākais solis. Photon sniedz mums pilnīgu kontroli pār datu attēlojumiem, to, kā nolasīšanas tiek organizētas un kā tiek izvietoti jauni indeksi, ļaujot mums optimizēt katru slāni mūsu darba slodzēm.

Photon ir iespējojis ātrāku meklēšanu Perplexity produktos un nodrošina pamatu mūsu jaunajam ātrajam iestatījumam Search API. Pēc migrācijas p99 izgūšanas un ranžēšanas aizkave samazinājās no aptuveni 800 ms līdz 65 ms. Mūsu kompaktie datu formāti arī ļauj uzglabāt 2,5 reizes vairāk datu vienam dokumentam, sniedzot izgūšanai un ranžēšanai piekļuvi bagātākai dokumenta informācijai.

Ātrais iestatījums nodrošina viena meklēšanas izsaukuma aizkavi 160 ms pie p50 un 230 ms pie p95. Sešos novērtētajos aģentu etalonuzdevumos (benchmarks) tas samazināja aptuvenās modeļa un meklēšanas izmaksas uz vienu uzdevumu par 68%, salīdzinot ar noklusējuma iestatījumu, vienlaikus saglabājot salīdzināmu kopējo uzdevumu kvalitāti. Šie rezultāti parāda infrastruktūras, kas izstrādāta ap mūsu meklēšanas darba slodzēm, praktiskās priekšrocības gan Perplexity produktiem, gan izstrādātājiem, kuri veido risinājumus, izmantojot mūsu API.

Mēs turpinām uzlabot Photon veiktspēju un krātuves efektivitāti. Mūsu mērķis ir atbalstīt lielāku indeksu un bagātākus dokumentu datus uz tās pašas aparatūras, saglabājot meklēšanu ātru, augot mūsu darba slodzēm.

Citāts

@online{perplexity2026Photon,
  author = {{Perplexity} and Maksim Morozov and Bogdan Savko and Ruslan Kovalev and Aleksei Bykov and Artur Zayats and Denis Bykov and Nikita Kireev and Jarrod Bryan and Claire Beamer and Jeremy Yang},
  title = {{Photon: Building a retrieval and ranking engine from scratch}},
  date = {2026-09-24},
  url = {https://www.perplexity.ai/hub/blog/photon}
}