Photon: Izgradnja mehanizma za dohvat i rangiranje od nule

Kako specijalizirani formati podataka, serijska čitanja i odvajanje izgradnje indeksa od posluživanja upita poboljšavaju pretraživanje s izvornom umjetnom inteligencijom.

AutoriPerplexity Engineering

Uvod

Perplexityjev stog pretraživanja s izvornom umjetnom inteligencijom dohvaća i rangira stranice kandidate, izbacujući na površinu najrelevantniji sadržaj kako bi model utemeljio svoje odgovore. Izvorno se ova faza izvodila na mehanizmu otvorenog koda koji smo prilagodili našem sustavu. Međutim, kako su naš indeks i radna opterećenja rasli, naišli smo na stroga ograničenja troškova, krajnje latencije i vremena oporavka čvorova koja nismo mogli riješiti unutar postojeće platforme treće strane.

Kako bismo prevladali ove izazove, izgradili se Photon, novi vlastiti mehanizam za dohvat i rangiranje. Time se nastavlja naš pristup izgradnje infrastrukture za pretraživanje prve umjetne inteligencije od nule, kao što smo učinili s CobbleDB, našom distribuiranom pohranom ključ-vrijednost za posluživanje zapisa stranica, i našim Search API-jem.

Photon koristi kompaktne formate podataka za čitanje i dekodiranje samo onoga što je svakom upitu potrebno, uz predmemoriju svjesnu serija i asinkrono čitanje radi smanjenja pristupa disku i preklapanja čekanja. Izgradnja indeksa odvija se odvojeno od posluživanja upita, ažurirajući jednu poslužiteljsku grupu u isto vrijeme i zagrijavajući njezine predmemorije prije usmjeravanja aktivnih upita na nju.

Photon sada pokreće naš cjevovod pretraživanja i također je temelj nove brze predpostavke za naš Search API, s latencijom jednog poziva pretraživanja od 160 ms pri p50 i 230 ms pri p95. U šest javnih mjerila, brza predpostavka smanjila je procijenjeni trošak modela i pretraživanja po zadatku za 68% uz održavanje ukupne kvalitete zadatka usporedive sa zadanom predpostavkom. Danas je objavljujemo kako bi programeri mogli pristupiti ovim poboljšanjima.

Samoprijavljena latencija jednog poziva pretraživanja. PPLX Fast prijavljuje p50 latenciju od 160 ms i p95 latenciju od 230 ms. Exa Instant prijavljuje p90, a ne p95, za svoju vrijednost visokog repa; vrijednosti visokog repa za Parallel nisu objavljene. Prijavljeni percentili i postavke mjerenja nisu kontrolirana usporedba tipa "slično sa sličnim".
Ukupna kvaliteta zadatka naspram procijenjenog ukupnog troška modela i pretraživanja za istih 3.554 odabranih zadataka. Rezultati su ponderirani brojem zadataka, a troškovi pokrivaju cijeli skup zadataka. PPLX Fast ostvaruje 64,3% uz 59,73 USD, u usporedbi s 64,0% uz 187,60 USD za zadanu PPLX predpostavku, što je otprilike 68% niži procijenjeni trošak za isti broj zadataka.

Što mehanizam za dohvat i rangiranje zahtijeva

Za svaki upit, mehanizam za dohvat i rangiranje pretražuje veliki, distribuirani indeks kako bi odabrao i uredio mali skup relevantnih stranica unutar proračuna latencije stoga pretraživanja. Sustav također mora održavati indeks ažuriranim kako stižu nove stranice i postojeće se mijenjaju, bez dopuštanja da taj posao uspori aktivne upite.

Procijenili smo nekoliko opcija otvorenog koda i odabrali zreo, općeniti mehanizam za dohvat i rangiranje koji je zadovoljio naše početne potrebe. Zatim smo ga prilagodili našoj arhitekturi i radnim opterećenjima, održavajući stabilnu latenciju i propusnost u produkcijskom mjerilu.

Gdje je naš prethodni sustav zakazao

Zadržali smo vlastitu račvu kako bismo prilagodili mehanizam našem rastućem indeksu, ali rješavanje ključnih ograničenja sve je više zahtijevalo redizajniranje velikih dijelova platforme. Nekoliko se ograničenja pokazalo teškim za riješiti bez temeljnih arhitektonskih promjena:

1. Troškovi skaliranja. I broj dokumenata koje pohranjujemo i količina podataka po dokumentu koje trebamo dohvatiti i rangirati rasli su tijekom vremena. Ovo je skaliranje stavilo pritisak na naš hardver, posebno na količinu dostupnog RAM-a. Kako bismo kontrolirali troškove, bili su nam potrebni kompaktniji prikazi podataka i finija kontrola nad time što ostaje u memoriji, a što se čita s diska na zahtjev.

2. Loša krajnja latencija. Na produkcijskom prometu, vrijeme odziva p99 starog sustava iznosilo je oko 800 ms. Skup podataka premašio je dostupni RAM, tako da nismo mogli koristiti mlock kako bismo ga u potpunosti držali u memoriji. Pristup nerezidentnim podacima mogao je pokrenuti ozbiljne pogreške stranica, blokirajući izvršavanje upita dok je operativni sustav čitao s diska.

Mehanizam je također povremeno spajao svoj glavni indeks diska s manjim indeksima ispražnjenim iz memorije. Tijekom ovog procesa stapanja indeksa diska, broj pogrešaka stranica porastao je još više, pri čemu je latencija p99 dosegnula približno 1,2 s tijekom 10–15 minuta. Kako su se predmemorije zagrijavale, učestalost pogrešaka stranica i latencija su se smanjivale, što sugerira da su hladna čitanja bila glavni doprinositelj skokovima. Predučitavanje podataka i zagrijavanje indeksa smanjili su skokove, ali nisu adekvatno riješili visoku krajnju latenciju.

3. Dugotrajan oporavak i sinkronizacija. U prethodnom sustavu, primjena dodatnog klastera i sinkronizacija njegovih podataka mogla je potrajati više od tjedan dana. Sinkronizacija je također bila potrebna prilikom dodavanja grupa čvorova za držanje dodatnih kopija podataka ili oporavka od kvarova čvorova. Tijekom oporavka, veći udio odgovora na pretraživanje bio je djelomičan, što je smanjivalo rezultate kvalitete konačnog odgovora.

U konačnici, zaključili smo da bi bilo jednostavnije i jeftinije graditi od nule nego nastaviti prilagođavati i održavati našu račvu. Oslanjajući se na naše iskustvo u radu s prethodnim sustavom, mali inženjerski tim radio je zajedno s rojem trajnih kodirajućih agenata na izgradnji Photona.

Gdje se Photon uklapa u stog pretraživanja

Photon je dizajniran za dva primarna tijeka rada: posluživanje zahtjeva za pretraživanje i unos ažuriranja iz cjevovoda obrade.

Zahtjev iz usluge pretraživanja više razine stiže do Photon posrednika preko balansera opterećenja. Posrednik odabire grupu dijelova i prosljeđuje zahtjev svakom dijelu, prateći vremenska ograničenja i izdajući dodatne zahtjeve po potrebi.

Svaki dio obavlja dohvat, početno rangiranje i rangiranje druge faze, a zatim vraća svoje najbolje kandidate posredniku. Posrednik kombinira ove kandidate u jedan rangirani popis i dohvaća ključna polja dokumenata za odabrane stranice iz relevantnih dijelova. Zatim vraća ove rezultate usluzi pretraživanja više razine, koja prikuplja sadržaj stranice potreban agentu za generiranje utemeljenog odgovora.

Ažuriranja indeksa slijede zaseban put. Pillar, naš sloj za objavljivanje, priprema podatke i pohranjuje ih u YTsaurus tablice. Indeksiratelji pretvaraju ove tablice u strukture indeksa koje dijelovi mogu učitati za pretraživanje. Kontroler koordinira pripremu podataka, izgradnju indeksa i primjenu novih verzija indeksa na poslužiteljske grupe. Prije rukovanja aktivnim prometom, svaki dio ponovno reproducira stvarne upite pretraživanja kako bi zagrijao svoje predmemorije.

Upit se kreće od usluge pretraživanja više razine kroz balanser opterećenja i posrednika do odabrane grupe dijelova. Svaki dio dohvaća i rangira kandidate; posrednik spaja rezultate, dohvaća polja dokumenata za odabrane stranice i vraća ih usluzi pretraživanja više razine. Numerirani koraci prikazuju redoslijed. Pune strelice nose zahtjeve, a isprekidane strelice vraćaju rezultate nazad. Oznake faza s lijeve strane razlikuju odabir kandidata od čitanja sažetaka.

Dizajniranje Photona za naše tijekove rada

Tri dizajnerska izbora čine Photon prikladnim za naše radno opterećenje: kompaktni prikazi podataka, predmemoriranje i asinkrono čitanje s diska te odvajanje ažuriranja indeksa od posluživanja upita.

Prikazi podataka za dohvat i rangiranje

Dohvat i rangiranje pristupaju podacima dokumenata na različite načine. Leksički dohvat započinje s terminima upita i pronalazi dokumente koji ih sadrže. Rangiranje zatim treba detaljne informacije o svakom odabranom dokumentu, uključujući frekvencije termina i položaje.

Photon koristi dva komplementarna prikaza za podršku ovim uzorcima pristupa. Obrnuti indeks pohranjuje popis podudarnih dokumenata za svaki termin, koji se naziva popis objava, kako bi podržao odabir kandidata. Zasebni zapisi po dokumentu pružaju podatke potrebne za rangiranje. Također optimiziramo način na koji se popisi objava pohranjuju i kroz njih prolazi kako bismo poboljšali odabir unutar fiksnog proračuna rada.

Specijalizirani prikazi podataka omogućuju nam učinkovitiju pohranu ključnih podataka. Kompaktniji obrnuti indeks smanjuje količinu podataka pročitanih ili premještenih po upitu, poboljšavajući latenciju uklanjanjem nepotrebnih I/O operacija. Ovi formati također omogućuju provjeru pojavljuje li se dokument na popisu bez potpunog dekodiranja, svojstvo na koje se naša logika prolaza oslanja za kontrolu količine posla koju upit obavlja pod fiksnim proračunom. Optimiziranje zapisa po dokumentu omogućuje nam pohranu više podataka po dokumentu za rangiranje, uz istovremeno smanjenje troškova skaliranja povezanih s našim prethodnim sustavom.

Obrnuti indeks

Za svaki termin, obrnuti indeks pohranjuje popis objava. Ovi popisi mogu se kretati od nekoliko dokumenata do milijuna, tako da nijedan pojedinačni format ne radi dobro za svaki popis. Photon odabir formata vrši na temelju broja dokumenata koji sadrže termin.

Kratki popisi koriste unutrašnji prikaz koji stane unutar jedne stranice i ne zahtijeva tablicu blokova. Dulji popisi koji ne stane u unutarnji format podijeljeni su u blokove koji pokrivaju fiksne raspona identifikatora dokumenata. Prikaz svakog bloka ovisi o njegovoj gustoći: rijetki blokovi pohranjuju sortirana polja pomaka ID-a dokumenata, dok gusti blokovi koriste bitmape. Rijetki blokovi koriste galopirajuće pretraživanje koje napreduje u sve većim koracima kako bi preskočilo regije popisa. Gusti blokovi omogućuju provjere pripadnosti traženjem bita koji odgovara dokumentu.

Frekvencija upita termina određuje gdje se njegov popis objava nalazi na disku. Često traženi popisi pohranjeni su blizu jedni drugima, koncentrirajući vruće podatke u manjoj regiji pohrane. Unutar svakog popisa, dokumenti su poredani prema zasebnom signalu korisnosti tako da se na obećavajuće kandidate nailazi ranije.

Photon odabire prikaz popisa objava prema duljini i gustoći bloka. Kratki popisi stanu unutar stranice. Dulji popisi podijeljeni su u fiksne raspona ID-a dokumenata, s sortiranim poljima pomaka za rijetke blokove i bitmapama za guste blokove.

Prolazak kroz popise unutar proračuna rada

Odabir kandidata zahtijeva prolazak kroz popise objava kako bi se pronašli potencijalno relevantni dokumenti. Iscrpno skeniranje svakog popisa je skupo, stoga Photon koristi algoritam nalik WAND-u koji prolazi samo kroz neke popise dok istovremeno uzima u obzir podudaranja u ostalima.

Algoritam dijeli popise u dvije grupe. Vodeći popisi unapređuju prolaz i predlažu dokumente kandidate. Popisi provjere doprinose rezultatima tih kandidata, ali sami po sebi ne generiraju kandidate.

Bodovanje kandidata kombinira ponderiranu pokrivenost termina upita i doprinos frekvencije, s normalizacijom duljine dokumenta i gornjom granicom dobitaka od ponovljenih termina. Photon prvo provjerava prisutnost termina u poljima i bitmapama kako bi ograničio maksimalno mogući rezultat svakog kandidata. Čita točne frekvencije termina samo za kandidate koji još uvijek mogu zadovoljiti prag odabira.

Odabir se zatim odvija u tri koraka:

  • Prolaz: Započnite sa strogim zahtjevom za pokrivenost upita. Ako je pronađeno premalo kandidata, ponovite s ublaženim zahtjevom.
  • Zadržavanje: Kandidati se drže u ograničenom skupu pomoću rezultata koji kombinira pokrivenost i frekvenciju. Kako se prikupljeni najbolji kandidati poboljšavaju, prag prijema raste.
  • Konačni odabir: Konačni rezultati za prolaz odabiru se iz zadržanog skupa na temelju rezultata frekvencije. Svako polje pokreće vlastiti prolaz, a rezultati se spajaju pomoću težina polja.

Algoritam proizvodi skup kandidata relevantnih dokumenata koji će se koristiti u daljnjem rangiranju.

Ilustrativan prolaz kroz ograničene kandidate. Vodeći popisi predlažu dokumente, dok gornje granice omogućuju obrezivanje kandidata ispod trenutnog praga prijema bez čitanja popisa provjere ili točnih frekvencija. Prag raste kako se zadržani skup poboljšava. Rezultati su izmišljeni radi ilustracije, a zadržani kandidati nisu zajamčeni točni top-k.

Docblob

Nakon što su odabrane stranice kandidata, faza rangiranja treba frekvencije termina, pokrivenost polja te lokacije i blizinu pojavljivanja. Dobivanje tih podataka kroz obrnuti indeks zahtijevalo bi raspršene pristupe u mnogim parovima termin-dokument. U Photonu pohranjujemo kompaktan zapis po dokumentu nazvan docblob koji sadrži frekvencije termina, polja u kojima se termin pojavio i gdje se u dokumentu pojavio. Kao rezultat toga, rangiranje kandidata zahtijeva samo jedno pretraživanje po dokumentu.

Format je izgrađen kako bi se izbjeglo dekodiranje više nego što je potrebno. Unutar docbloba, polja su grupirana prema analizatoru teksta. Svaka grupa pohranjuje sortirani popis termina kodiran s Elias-Fano, tako da se termin upita može izravno potražiti bez prvotnog proširivanja cijelog popisa. Maska polja označava gdje se termin pojavio, brojač frekvencije prati koliko često, a stvarni položaji nalaze se u odvojenim blokovima po paru termin-polje kodiranim kao razlike položaja. Samo se blokovi za termine koji su se stvarno podudarali dekodiraju, dok sve ostalo u zapisu ostaje u komprimiranom formatu.

To selektivno dekodiranje omogućuje docblobu podržavanje pohrane više podataka po dokumentu bez proporcionalnog povećanja troškova. Rastući zapis ne prisiljava više posla po pretraživanju, jer rangiranje uvijek dodiruje samo dijelove relevantne za podudarne termine, umjesto cijelog zapisa.

Docblob grupira podatke rangiranja u kompaktan zapis po dokumentu. Termini upita traže se na popisu termina kodiranom pomoću Elias-Fano; maske polja, frekvencije i blokovi položaja pružaju podatke potrebne za podudarne termine dok nesrodni termini ostaju komprimirani. ID-ovi termina i položaji su ilustrativni.

Serijska čitanja i rad s memorijom

Čak i s učinkovitijim prikazima podataka, RAM se i dalje potroši prije ostalih resursa, stoga često moramo pristupati podacima pohranjenim na disku. Photon koristi asinkrono čitanje s diska i predmemoriju optimiziranu za serijska čitanja kako bi ubrzao ove pristupe, smanjujući vrijeme čekanja po zahtjevu. To doprinosi značajnom poboljšanju krajnje latencije u usporedbi s prethodnim sustavom.

Photon provjerava seriju poznatih pomaka zapisa u svojoj predmemoriji prije izdavanja čitanja s diska. Pogodci predmemorije kopiraju se u pripremljeni međuspremnik; promašaji se šalju putem io_uring kako bi se čekanja na disk mogla preklopiti, a vraćeni podaci popunjavaju predmemoriju. Zapisi i vremenske crte su shematski, a ne izmjerene latencije.

Preklapanje čekanja diska

Rangiranje zahtijeva dobivanje značajki stotina dokumenata smještenih u različitim dijelovima datoteke. Naš prethodni sustav koristio je mmap za mapiranje datoteke u virtualni adresni Prostor kako bi se mogla čitati putem pokazivača memorije. Međutim, pristup stranici koja je nedostajala u memoriji i dalje je zahtijevao čitanje s diska. Nit je morala čekati podatke prije nastavka računanja, a to se vrijeme čekanja zbrajalo kada je proces trebao sekvencijalno čitati hladne zapise.

Photon koristi činjenicu da su pomaci zapisa poznati unaprijed, tako da možemo poslati nekoliko čitanja odjednom. Time upravlja reaktor: namjenske radne niti šalju serije putem io_uring i prosljeđuju pročitane podatke kodu koji poziva. Svaka nit održava vlastiti io_uring; serije se šalju reaktoru s najmanjim opterećenjem. Unaprijed registrirani opisnici datoteka i skupovi međuspremnika smanjuju opterećenje ponovljenih čitanja. Ovo asinkrono izvršavanje omogućuje preklapanje čekanja za nekoliko operacija, čime se smanjuje krajnja latencija.

Smanjenje broja pristupa pogonu

Prije slanja čitanja, Photon provjerava cijelu seriju u predmemoriji u memoriji. Samo zahtjevi za nedostajuće zapise odlaze na disk; pročitani podaci zatim popunjavaju predmemoriju.

Predmemorija je dizajnirana za serijska čitanja. Točnije:

  • Nema zasebne alokacije pri pogotku. Umjesto toga, podaci se kopiraju u međuspremnik koji je unaprijed pripremio kod koji poziva.
  • Nema stjecanja zaključavanja od strane čitača. Umjesto toga, provjerava verziju podataka i ponavlja pokušaj ako je u sukobu s upisom.
  • Koristi izbacivanje CLOCK, umjesto zahtijevanja ažuriranja zajedničkog LRU popisa pri svakom čitanju.
  • Koristi preddohvat predmemorije CPU-a, gdje se metapodaci i podaci za nadolazeće zapise traže unaprijed.

Ova optimizacija smanjuje latenciju bez narušavanja performansi na radnim opterećenjima do kojih nam je stalo.

Izgradnja i ažuriranje indeksa odvojeno od posluživanja

U Photonu se izgradnja indeksa i posluživanje upita odvijaju na različitim čvorovima. Indeksiratelji transformiraju podatke u spremne strukture pohrane, dok ih čvorovi za posluživanje čitaju i obavljaju dohvat i rangiranje. Kao rezultat toga, izgradnja indeksa ne konkurira upitima pretraživanja za CPU, a resursi za te zadatke mogu se skalirati neovisno.

Ovo odvajanje rješava usko grlo oporavka i sinkronizacije prisutno u prethodnoj implementaciji. Budući da se izgradnja indeksa odvijala unutar istog klastera koji je posluživao upite, oporavak neuspjelog čvora ili dodavanje nove kopije podataka moglo je značiti ponovno indeksiranje dokumenata na licu mjesta, proces koji je trajao danima i povećavao djelomične odgovore tijekom oporavka. Photon uklanja tu povezanost; indeksiratelji rade kao distribuirani poslovi koji proizvode verzirane strukture indeksa spremne za posluživanje neovisno o čvorovima za posluživanje, tako da izgradnja sljedeće verzije indeksa više ne konkurira aktivnom prometu.

Izgradnja indeksa odvija se odvojeno od posluživanja aktivnih upita. Pillar izvozi izvorne podatke, YTsaurus priprema verzirane tablice po dijelovima, a paralelni indeksiratelji zapisuju strukture indeksa spremne za posluživanje u objektno spremište. Čvorovi za posluživanje učitavaju te strukture za dohvat i rangiranje; suprotnost indeksiratelja i broj dijelova konfigurirani su neovisno.

Priprema i distribuirana izgradnja

Izgradnja započinje odabirom dokumenata za aktivni indeks i izradom izvornog izvoza. Kontroler bilježi izvornu verziju, ulazne tablice i očekivani broj dijelova. MapReduce poslovi u YTsaurusu pripremaju tekst, metapodatke, fragmente, značajke i unaprijed izračunate ugrađene slojeve u verzirane tablice particionirane po dijelovima. Svaki indeksiratelj struji pripremljenu tablicu, gradi strukture za svoj dio i spaja tekstualne segmente. Spremni indeks, zajedno s opisom njegovih komponenti, učitava se u objektno spremište.

Broj dijelova i broj istovremeno pokrenutih indeksiratelja konfigurirani su neovisno, tako da se izgradnja može izvoditi u nekoliko valova, ili se više strojeva može dodijeliti za rad u paralelnom načinu rada. Distribuirana priprema i paralelni indeksiratelji omogućuju izgradnju cijelog web indeksa u dvoznamenkastom broju sati, što je značajno poboljšanje u odnosu na prethodni sustav.

Primjena nove verzije

Prije primjene, kontroler provjerava je li novi indeks spreman. Ako su podaci nepotpuni, primjena se automatski blokira.

Kada postoji više poslužiteljskih grupa, kontroler ih ažurira jednu po jednu. Prvo uklanja grupu iz usmjeravanja posrednika i pokreće je na novoj verziji indeksa. Prije posluživanja zahtjeva, dijelovi prolaze kroz zasebnu fazu zagrijavanja temeljenu na dnevnicima pretraživanja, što unaprijed popunjava početno stanje i čini prijelaz na stvarni promet glađim. Nakon zagrijavanja, kontroler provjerava stanje indeksa i spremnost, a zatim vraća grupu u usmjeravanje. Ostale grupe nastavljaju posluživati zahtjeve tijekom tog vremena. Budući da je radno stanje sačuvano, ponovno pokretanje ne prisiljava izgradnju da započne iznova; kontroler se može ponovno priključiti na pripremu koja je već u tijeku, ponovno koristiti spreman rezultat ili nastaviti prekinutu rotaciju od spremljenog koraka.

Vremena ažuriranja podataka razlikuju se među vertikalama pretraživanja. Za vertikale s visokim zahtjevima za svježinom, dostava dokumenata traje dvoznamenkasti broj minuta. Dodatna kopija podataka može se primijeniti za oko pola sata; spremni se indeksi učitavaju i pričvršćuju na dijelove bez ponovnog indeksiranja izvornih dokumenata.

Kontroler provjerava je li novi indeks dovršen, a zatim rotira jednu po jednu poslužiteljsku grupu. Grupa napušta usmjeravanje posrednika, učitava novu verziju, zagrijava svoje predmemorije upitima iz dnevnika pretraživanja i prolazi provjere spremnosti prije povratka na promet. Druge grupe nastavljaju s posluživanjem, a spremljeno stanje kontrolera omogućuje nastavak prekinute rotacije.

Migracija i provjera unutar našeg stoga pretraživanja

Naš prvi cilj bio je zamijeniti stari sustav mehanizmom koji je očuvao funkcionalnost i kvalitetu pretraživanja uz smanjenje vremena odziva. Validaciju Photona proveli smo u fazama, počevši s ponovljivim testovima opterećenja i izvanmrežnim procjenama kvalitete prije prelaska na aktivni promet. Photon sada pokreće dohvat i rangiranje u našem produkcijskom stogu pretraživanja, uz znatno niže vrijeme odziva nego stari sustav.

Testiranje opterećenja i procjene

Za testiranje performansi izgradili smo alat za testiranje opterećenja koji ponovno reproducira upite iz naših dnevnika pretraživanja pri podesivim stopama dolaska. Uspoređuje rezultate kroz izvođenja i primjenjuje statističke testove kako bi procijenio jesu li uočene razlike u performansama dosljedne. Zasebno smo procijenili Photon i stari sustav na istim skupovima podataka u našim internim sustavima izvanmrežne procjene kako bismo provjerili postoje li regresije kvalitete.

Nakon ovih provjera, poslali smo aktivne upite na oba stroja istovremeno koristeći sjene prometa. To nam je omogućilo usporedbu njihovih performansi i rezultata na produkcijskim radnim opterećenjima prije promjene poslužiteljskog stroja. Zatim smo omogućili Photon za male podskupove korisnika i postupno širili uvođenje, prateći kvalitetu i performanse cijelo vrijeme. Prva verzija prošla je testiranje prihvatljivosti bez regresije kvalitete, a uvođenje smo nastavili sve dok Photon nije posluživao sav produkcijski promet.

Izmjerena poboljšanja u produkciji

U našem produkcijskom tijeku rada, vrijeme odziva p99 palo je s otprilike 800 ms u starom sustavu na otprilike 65 ms u Photonu. Ovo mjerenje pokriva sve faze unutar Photona, ali isključuje naknadne faze u stogu pretraživanja više razine. Također više ne primjećujemo skokove latencije koji su prethodno bili povezani s prebacivanjem verzija indeksa.

Photon koristi otprilike 20% manje ekvivalentnih poslužiteljskih strojeva nego sadržajni čvorovi starog sustava uz pohranu otprilike 2,5 puta više podataka po dokumentu. Nakon migracije, iskoristili smo ove dodatne podatke za poboljšanje kvalitete rangiranja iznad one u starom sustavu.

Photon također smanjuje količinu podataka koja mora ostati u memoriji. Fiksiranje istog skupa podataka Photona u RAM-u s mlock zahtijevalo bi procijenjenih 4,6 puta više rezidentne memorije nego što Photon trenutno koristi.

Procjena brze predpostavke Search API-ja

Photon smo također koristili kao osnovu za novu brzu predpostavku za naš Search API, dizajniranu za radna opterećenja osjetljiva na latenciju. Prema našim mjerenjima, latencija jednog poziva pretraživanja za brzu predpostavku iznosi 160 ms pri p50 i 230 ms pri p95, što je niže ili usporedivo sa samoprijavljenim brojevima drugih pružatelja Search API-ja, iako se prijavljeni krajnji percentili razlikuju.

Procijenili smo brzu predpostavku na šest agencijskih mjerila: WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0 i SEAL-Hard. U ovim procjenama imala je najniži procijenjeni ukupni trošak modela i pretraživanja i najviši ukupni rezultat zadatka među testiranim konfiguracijama.

Brza predpostavka uparuje Photon s rangiranjem optimiziranim za agencijske tijekove rada, isporučujući usporedive performanse sa zadanom predpostavkom uz znatno nižu cijenu. Međutim, ona dolazi s kompromisom u široj kvaliteti pretraživanja. Brza predpostavka koristi manje računalnih resursa za rangiranje nego zadata predpostavka. Na internim mjerilima koja pokrivaju dugotrajne upite, široku pokrivenost i raznolikost rezultata, ostvaruje 0,24 boda niže rezultate u relevantnosti i približno 3 postotna boda niže u dostupnosti odgovora. Vjerujemo da je ovo razuman kompromis za agencijske tijekove rada, budući da vlastito rasuđivanje i znanje modela mogu pomoći nadoknaditi razliku.

Unutarnja usporedba kvalitete dohvata između zadane PPLX predpostavke i PPLX Fast. Relevantnost (DCG) pada s 2,45 na 2,21, što je smanjenje od 0,24 boda; dostupnost odgovora pada s 0,596 na 0,567, što je smanjenje od 2,9 postotnih bodova. Dvije ploče koriste različite, ne-nulte osnovne linije osi, tako da visine stupaca naglašavaju praznine, a ne proporcionalne razlike.

Preporučujemo brzu predpostavku za svakodnevne agencijske zadatke. Za izazovnija ili dvosmislena pitanja koja su manje vremenski osjetljiva, zadata predpostavka nudi robusniju kvalitetu, opravdavajući svoju veću latenciju i trošak.

Zaključak

Stalno premještamo naš stog pretraživanja na vlastitu infrastrukturu temeljenu na Rustu. Zamjena mehanizma otvorenog koda Photonom, našim prilagođenim mehanizmom za dohvat i rangiranje, najnoviji je korak. Photon nam daje potpunu kontrolu nad prikazima podataka, načinom organiziranja čitanja i načinom primjene novih indeksa, omogućujući nam optimizaciju svakog sloja za naše radno opterećenje.

Photon je omogućio brže pretraživanje diljem Perplexityjevih proizvoda i pruža temelj za našu novu brzu predpostavku u Search API-ju. Nakon migracije, latencija dohvata i rangiranja p99 pala je s otprilike 800 ms na 65 ms. Naši kompaktni formati podataka također nam omogućuju pohranu 2,5 puta više podataka po dokumentu, dajući dohvatu i rangiranju pristup bogatijim informacijama o dokumentima.

Brza predpostavka isporučuje latenciju jednog poziva pretraživanja od 160 ms pri p50 i 230 ms pri p95. U šest procijenjenih agencijskih mjerila, smanjila je procijenjeni trošak modela i pretraživanja po zadatku za 68% u odnosu na zadanu predpostavku uz održavanje usporedive ukupne kvalitete zadatka. Ovi rezultati pokazuju praktične prednosti infrastrukture dizajnirane oko naših radnih opterećenja pretraživanja, kako za Perplexityjeve proizvode tako i za programere koji grade s našim API-jem.

Nastavljamo poboljšavati Photonove performanse i učinkovitost pohrane. Naš je cilj podržati veći indeks i bogatije podatke dokumenata na istom hardveru uz održavanje brzog pretraživanja kako naša radna opterećenja rastu.

Citiranje

BibTeX
@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}
}