Photon: Izgradnja motora za preuzimanje i rangiranje od nule

Uvod

Perplexity-jev AI-native stek pretrage preuzima i rangira stranice kandidate, izbacujući na površinu najrelevantniji sadržaj da model utemelji svoje odgovore. Prvobitno se ova faza odvijala na open-source motoru koji smo prilagodili našem sistemu. Međutim, kako su naš indeks i radna opterećenja rasli, naišli smo na stroga ograničenja u pogledu troškova, krajnje latencije i vremena oporavka čvorova koja nismo mogli da rešimo unutar postojeće platforme treće strane.

Da bismo prevazišli ove izazove, izgradili smo Photon, novi sopstveni motor za preuzimanje i rangiranje. Ovo nastavlja naš pristup izgradnji AI-first infrastrukture pretrage od nule, kao što smo uradili sa CobbleDB, našim distributivnim skladištem ključ-vrednost za opsluživanje zapisa stranica, i našim Search API.

Photon koristi kompaktne formate podataka za čitanje i dekodiranje samo onoga što je svakom upitu potrebno, uz keširanje svesno paketa i asinhrona čitanja kako bi se smanjio pristup disku i preklopila čekanja. Izgradnja indeksa se odvija odvojeno od opsluživanja upita, ažurirajući jednu grupu za opsluživanje u isto vreme i zagrevajući njene keševe pre usmeravanja živih upita ka njoj.

Photon sada pokreće naš cevovod pretrage, a takođe je i osnova novog brzog predseta za naš Search API, sa latencijom jednog poziva pretrage od 160 ms na p50 i 230 ms na p95. Preko šest javnih repernih testova, brzi predset je smanjio procenjeni trošak modela i pretrage po zadatku za 68% uz održavanje ukupnog kvaliteta zadatka uporedivog sa podrazumevanim predsetom. Objavljujemo ga danas kako bi programeri mogli da pristupe ovim poboljšanjima.

Uvećaj

Uvećaj

Šta motor za preuzimanje i rangiranje zahteva

Za svaki upit, motor za preuzimanje i rangiranje pretražuje veliki, distribuirani indeks kako bi izabrao i uredio mali skup relevantnih stranica unutar budžeta latencije steka pretrage. Sistem takođe mora održavati indeks ažuriranim kako stižu nove stranice i menjaju se postojeće, bez dozvoljavanja da taj posao uspori žive upite.

Procenili smo nekoliko open-source opcija i izabrali zreo, opštenamenski motor za preuzimanje 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 protok na produkcionoj skali.

Gde je naš prethodni sistem zakazao

Održavali smo naš sopstveni fork da bismo prilagodili motor našem rastućem indeksu, ali je rešavanje ključnih ograničenja sve više zahtevalo redizajniranje velikih delova platforme. Nekoliko ograničenja se pokazalo teškim za rešavanje bez suštinskih arhitektonskih promene:

1. Troškovi skaliranja. I broj dokumenata koje skladištimo i količina podataka po dokumentu koje treba da preuzmemo i rangiramo rasli su tokom vremena. Ovo skaliranje je izvršilo pritisak na naš hardver, posebno na količinu dostupnog RAM-a. Da bismo kontrolisali troškove, bili su nam potrebni kompaktniji prikazi podataka i finija kontrola nad tim šta ostaje u memoriji, a šta se čita sa diska po zahtevu.

2. Loša krajnja latencija. Na produkcionom saobraćaju, vreme odziva p99 starog sistema bilo je oko 800 ms. Skup podataka je premašivao dostupni RAM, tako da nismo mogli da koristimo mlock da bismo ga u potpunosti držali u memoriji. Pristup nerezidentnim podacima mogao je da pokrene veće greške stranice, zaustavljajući izvršavanje upita dok operativni sistem čita sa diska.

Motor je takođe periodično spajao svoj glavni indeks diska sa manjim indeksima isprženi iz memorije. Tokom ovog procesa fuzije indeksa diska, broj grešaka stranice je rastao još više, pri čemu je p99 latencija dostizala približno 1,2 s tokom 10–15 minuta. Kako su se keševi zagrevali, učestalost grešaka stranice i latencija su opadali, što sugeriše da su hladna čitanja bila glavni doprinosilac skokovima. Unapred učitavanje podataka i zagrevanje indeksa smanjili su skokove, ali nisu adekvatno rešili visoku krajnju latenciju.

3. Dugotrajan oporavak i sinhronizacija. U prethodnom sistemu, primena dodatnog klastera i sinhronizacija njegovih podataka mogla je da potraje duže od nedelju dana. Sinhronizacija je takođe bila potrebna pri dodavanju grupa čvorova za držanje dodatnih kopija podataka ili pri oporavku od otkazivanja čvorova. Tokom oporavka, veći udeo odgovora na pretragu bio je delimičan, što je smanjivalo ocene kvaliteta konačnog odgovora.

Na kraju smo zaključili da bi bilo jednostavnije i jeftinije graditi od nule nego nastaviti sa prilagođavanjem i održavanjem našeg forka. Oslanjajući se na naše iskustvo u upravljanju prethodnim sistemom, mali inženjerski tim radio je rame uz rame sa rojem perzistentnih kodnih agenata na izgradnji Photona.

Gde se Photon uklapa u pretraživački stek

Photon je dizajniran za dva primarna radna toka: opsluživanje zahteva pretrage i preuzimanje ažuriranja iz cevovoda obrade.

Zahtev iz pretraživačkog servisa višem nivoa stiže do Photon brokera preko balansera opterećenja. Broker bira grupu šardova i prosleđuje zahtev svakom šardu, prateći vremenska ograničenja i izdajući dodatne zahteve kada je to potrebno.

Svaki šard obavlja preuzimanje, početno rangiranje i rangiranje druge faze, a zatim vraća najbolje kandidate brokeru. Broker kombinuje ove kandidate u jednu rangiranu listu i dobavlja ključna polja dokumenata za izabrane stranice sa relevantnih šardova. On zatim vraća ove rezultate pretraživačkom servisu višeg nivoa, koji prikuplja sadržaj stranice potreban da agent generiše utemeljeni odgovor.

Ažuriranja indeksa prate poseban put. Pillar, naš sloj za objavljivanje, priprema podatke i skladišti ih u YTsaurus tabele. Indeksatori konvertuju ove tabele u strukture indeksa koje šardovi mogu učitati radi pretrage. Kontroler koordiniše pripremu podataka, izgradnju indeksa i primenu novih verzija indeksa na grupe za opsluživanje. Pre rukovanja živim saobraćajem, svaki šard ponovo reprodukuje prave upite pretrage kako bi zagrejao svoje keševe.

Uvećaj

Dizajniranje Photona za naše radne tokove

Tri dizajnerska izbora čine Photon pogodnim za naše radno opterećenje: kompaktni prikazi podataka, keširanje i asinhrona čitanja diska, i odvajanje ažuriranja indeksa od opsluživanja upita.

Prikazi podataka za preuzimanje i rangiranje

Preuzimanje i rangiranje pristupaju podacima dokumenata na različite načine. Leksičko preuzimanje počinje sa terminima upita i pronalazi dokumente koji ih sadrže. Rangiranju su potom potrebne detaljne informacije o svakom izabranom dokumentu, uključujući frekvencije termina i pozicije.

Photon koristi dva komplementarna prikaza za podršku ovim obrascima pristupa. Invertovani indeks skladišti listu podudarnih dokumenata za svaki termin, koja se zove lista postova, radi podrške izboru kandidata. Zasebni zapisi po dokumentu obezbeđuju podatke potrebne za rangiranje. Takođe optimizujemo način na koji se liste postova skladište i prolaze kako bismo poboljšali izbor pod fiksnim budžetom rada.

Specijalizovani prikazi podataka omogućavaju nam da efikasnije skladištimo ključne podatke. Kompaktniji invertovani indeks smanjuje količinu podataka pročitanih ili pomerenih po upitu, poboljšavajući latenciju eliminisanjem nepotrebnih I/O operacija. Ovi formati takođe omogućavaju proveru da li se dokument pojavljuje na listi bez potpunog dekodiranja, što je svojstvo na koje se naša logika prolaza oslanja radi kontrolisanja količine posla koju upit obavlja pod fiksnim budžetom. Optimizovanje zapisa po dokumentu omogućava nam da skladištimo više podataka po dokumentu za rangiranje, istovremeno smanjujući troškove skaliranja povezane sa našim prethodnim sistemom.

Invertovani indeks

Za svaki termin, invertovani indeks skladišti listu postova. Ove liste mogu varirati od nekoliko dokumenata do miliona, tako da nijedan pojedinačni format ne radi dobro za svaku listu. Photon bira format na osnovu broja dokumenata koji sadrže termin.

Kratke liste koriste ugrađeni prikaz koji stane unutar jedne stranice i ne zahteva tabelu blokova. Duže liste koje ne staju u ugrađeni format dele se na blokove koji pokrivaju fiksne opsege identifikatora dokumenata. Prikaz svakog bloka zavisi od njegove gustine: retki blokovi skladište sortirana polja pomaka ID-a dokumenata, dok gusti blokovi koriste bitmape. Retki blokovi koriste galopirajuću pretragu, koja napreduje u sve većim koracima kako bi preskočila regione liste. Gusti blokovi omogućavaju provere pripadnosti traženjem bita koji odgovara dokumentu.

Učestalost upita nekog termina određuje gde se njegova lista postova smešta na disk. Liste koje se često pretražuju skladište se blizu jedna druge, koncentrišući vruće podatke u manjem regionu skladištenja. Unutar svake liste, dokumenti su poređani po zasebnom signalu korisnosti tako da se na obećavajuće kandidate naiđe ranije.

Uvećaj

Prolazak kroz liste unutar budžeta rada

Izbor kandidata zahteva prolazak kroz liste postova kako bi se pronašli potencijalno relevantni dokumenti. Iscrpno skeniranje svake liste je skupo, pa Photon koristi WAND-sličan algoritam koji prolazi samo kroz neke liste dok i dalje uzima u obzir podudaranja u ostalima.

Algoritam deli liste u dve grupe. Vodeće liste unapređuju prolaz i predlažu kandidate dokumente. Probne liste doprinose skorovima tih kandidata, ali same ne generišu kandidate.

Bodovanje kandidata kombinuje ponderisanu pokrivenost termina upita i doprinos frekvencije, uz normalizaciju dužine dokumenta i ograničenje dobitaka od ponovljenih termina. Photon prvo proverava prisustvo termina u nizovima i bitmapama kako bi ograničio maksimalni mogući skor svakog kandidata. On čita tačne frekvencije termina samo za kandidate koji još uvek mogu da ispune prag selekcije.

Selekcija se zatim odvija u tri koraka:

• Prolaz: Počnite sa strogim zahtevom za pokrivenost upitom. Ako se pronađe premalo kandidata, ponovite sa opuštenijim zahtevom.
• Zadržavanje: Kandidati se drže u ograničenom skupu koristeći skor koji kombinuje pokrivenost i frekvenciju. Kako prikupljeni top kandidati postaju bolji, prag prijema raste.
• Konačna selekcija: Konačni rezultati za prolaz se biraju iz zadržanog skupa na osnovu skorova frekvencije. Svako polje pokreće sopstveni prolaz, a rezultati se spajaju korišćenjem težina polja.

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

Uvećaj

Docblob

Nakon što su kandidat-stranice izabrane, fazi rangiranja su potrebne frekvencije termina, pokrivenost polja, kao i lokacije i blizina pojavljivanja. Dobijanje ovih podataka preko invertovanog indeksa zahtevalo bi rasute pristupe kroz mnoge parove termin-dokument. U Photon-u skladištimo kompaktan zapis po dokumentu koji se zove docblob i koji sadrži frekvencije termina, u kojim poljima se termin pojavio i gde se u dokumentu dogodio. Kao rezultat toga, rangiranje kandidata zahteva samo jednu pretragu po dokumentu.

Format je napravljen tako da izbegava dekodiranje više nego što je neophodno. Unutar docblob-a, polja su grupisana po analizatoru teksta. Svaka grupa skladišti sortiranu listu termina kodiranu sa Elias-Fano, tako da se termin upita može direktno potražiti bez prvobitnog širenja cele liste. Maska polja označava gde se termin pojavio, brojač frekvencije prati koliko često, a stvarne pozicije se nalaze u zasebnim blokovima po paru termin-polje kodiranim kao razlike pozicija. Dekodiraju se samo blokovi za termine koji su se zaista podudarali, dok sve ostalo u zapisu ostaje u kompresovanom formatu.

To selektivno dekodiranje omogućava docblob-u da podrži skladištenje više podataka po dokumentu bez proporcionalnog povećanja troškova. Rast zapisa ne primorava na više posla po pretrazi, jer rangiranje uvek dotiče samo delove relevantne za podudarne termine umesto celog zapisa.

Uvećaj

Grupna čitanja i rad sa memorijom

Čak i sa efikasnijim prikazima podataka, RAM se i dalje troši pre drugih resursa, tako da često moramo da pristupamo podacima uskladištenim na disku. Photon koristi asinhrona čitanja diska i keš optimizovan za grupna čitanja kako bi ubrzao ove pristupe, skraćujući vreme čekanja po zahtevu. Ovo doprinosi značajnom poboljšanju krajnje latencije u poređenju sa prethodnim sistemom.

Uvećaj

Preklapanje čekanja diska

Rangiranje zahteva dobijanje karakteristika stotina dokumenata koji se nalaze u različitim delovima datoteke. Naš prethodni sistem koristio je mmap da mapira datoteku u virtuelni adresni Prostor kako bi se mogla čitati preko memorijskih pokazivača. Međutim, pristup stranici koja je odsustvovala iz memorije i dalje je zahtevao čitanje sa diska. Nit je morala da sačeka podatke pre nastavka izračunavanja, a ovo vreme čekanja se nagomilavalo kada je proces morao sekvencijalno da čita hladne zapise.

Photon koristi činjenicu da su pozicije zapisa poznate unapred, tako da možemo da podnesemo nekoliko čitanja odjednom. Time upravlja reaktor: namenske radne niti podnose pakete preko io_uring-a i prosleđuju pročitane podatke pozivajućem kodu. Svaka nit održava sopstveni io_uring; paketi se šalju reaktoru sa najmanjim opterećenjem. Unapred registrovani opisivači datoteka i bazeni bafera smanjuju opterećenje ponovljenih čitanja. Ovo asinhrono izvršavanje omogućava da se čekanja na nekoliko operacija preklapaju, čime se smanjuje krajnja latencija.

Smanjenje broja pristupa drajvu

Pre podnošenja čitanja, Photon proverava ceo paket u in-memory kešu. Samo zahtevi za nedostajuće zapise idu na disk; pročitani podaci zatim popunjavaju keš.

Keš je dizajniran za grupna čitanja. Preciznije:

• Nema zasebne alokacije pri pogotku. Umesto toga, podaci se kopiraju u bafer koji je unapred pripremio pozivajući kod.
• Nema pribavljanja zaključavanja od strane čitaoca. Umesto toga, on proverava verziju podataka i ponavlja pokušaj ako je u konfliktu sa upisom.
• On koristi CLOCK izbacivanje, umesto da zahteva ažuriranja deljene LRU liste pri svakom čitanju.
• On koristi keš prefetčing za CPU, gde se metapodaci i podaci za predstojeće zapise traže unapred.

Ove optimizacije smanjuju latenciju bez ugrožavanja performansi na radnim opterećenjima do kojih nam je stalo.

Izgradnja i ažuriranje indeksa odvojeno od opsluživanja

U Photon-u, izgradnja indeksa i opsluživanje upita rade na različitim čvorovima. Indeksatori transformišu podatke u strukture spremne za skladištenje, dok čvorovi za opsluživanje čitaju te strukture i obavljaju preuzimanje i rangiranje. Kao rezultat toga, izgradnja indeksa ne konkuriše upitima pretrage za CPU, a resursi za ove zadatke mogu se skalirati nezavisno.

Ovo odvajanje rešava uska grla oporavka i sinhronizacije prisutna u prethodnoj implementaciji. Pošto se izgradnja indeksa odvijala unutar istog klastera koji je opsluživao upite, oporavak otkazanog čvora ili dodavanje nove kopije podataka moglo je da znači ponovno indeksiranje dokumenata u mestu, proces koji je trajao danima i povećavao delimične odgovore tokom oporavka. Photon uklanja tu spregu; indeksatori rade kao distribuirani poslovi koji proizvode verzionisane strukture indeksa spremne za opsluživanje nezavisno od čvorova za opsluživanje, tako da izgradnja sledeće verzije indeksa više ne konkuriše živom saobraćaju.

Uvećaj

Priprema i distribuirana izgradnja

Izgradnja počinje izborom dokumenata za aktivni indeks i generisanjem izvoza izvora. Kontroler beleži verziju izvora, ulazne tabele i očekivani broj šardova. MapReduce poslovi u YTsaurus-u pripremaju tekst, metapodatke, fragmente, karakteristike i unapred izračunata ugnježđenja u verzionisane tabele podeljene po šardovima. Svaki indeksator strimuje pripremljenu tabelu, gradi strukture za svoj šard i spaja segmente teksta. Spremni indeks, zajedno sa opisom njegovih komponenti, otprema se u objektno skladište.

Broj šardova i broj istovremeno pokrenutih indeksatora se konfigurišu nezavisno, tako da se izgradnja može odvijati u nekoliko talasa, ili se više mašina može dodeliti za rad u paralelnom režimu. Distribuirana priprema i paralelni indeksatori omogućavaju da se kompletni veb indeks izgradi za jednocifren broj sati, što predstavlja značajno poboljšanje u odnosu na prethodni sistem.

Primena nove verzije

Pre primene, kontroler proverava da li je novi indeks spreman. Ako su podaci nepotpuni, primena se automatski blokira.

Kada postoji više grupa za opsluživanje, kontroler ih ažurira jednu po jednu. On prvo uklanja grupu iz usmeravanja brokera i pokreće je na novoj verziji indeksa. Pre opsluživanja zahteva, šardovi prolaze kroz zasebnu fazu zagrevanja zasnovanu na dnevnicima pretrage, što unapred popunjava početno stanje i čini prelaz na stvarni saobraćaj glatkijim. Nakon zagrevanja, kontroler proverava stanje indeksa i spremnost, a zatim vraća grupu u usmeravanje. Ostale grupe nastavljaju da opslužuju zahteve tokom ovog vremena. Pošto je stanje rada perzistirano, ponovno pokretanje ne primorava izgradnju da počne iznova; kontroler može ponovo da se zakači na pripremu koja je već u toku, ponovo iskoristi spreman rezultat ili nastavi prekinutu rotaciju od sačuvanog koraka.

Vremena ažuriranja podataka se razlikuju među vertikalama pretrage. Za vertikale sa visokim zahtevima za svežinom, isporuka dokumenata traje jednocifren broj minuta. Dodatna kopija podataka može se primeniti za oko pola sata; spremni indeksi se učitavaju i prilažu šardovima bez ponovnog indeksiranja izvornih dokumenata.

Uvećaj

Migracija i validacija unutar našeg steka pretrage

Naš prvi cilj bio je da zamenimo stari sistem motorom koji je očuvao funkcionalnost i kvalitet pretrage uz smanjenje vremena odziva. Validiorali smo Photon u fazama, počevši od reproduktivnih testova opterećenja i vanmrežnih procena kvaliteta pre prelaska na živi saobraćaj. Photon sada pokreće preuzimanje i rangiranje u našem produkcionom steku pretrage, uz znatno niža vremena odziva u odnosu na stari sistem.

Testiranje opterećenja i procene

Za testiranje performansi napravili smo alat za testiranje opterećenja koji ponovo reprodukuje upite iz naših dnevnika pretrage pri podesivim stopama dolaska. On upoređuje rezultate kroz pokretanja i primenjuje statističke testove kako bi procenio da li su uočene razlike u performansama dosledne. Zasebno smo procenili Photon i stari sistem na istim skupovima podataka u našim internim sistemima vanmrežne procene kako bismo proverili da li postoje regresije kvaliteta.

Nakon ovih provera, poslali smo žive upite na oba motora istovremeno koristeći senu saobraćaja. To nam je omogućilo da uporedimo njihove performanse i rezultate na produkcionim radnim opterećenjima pre promene koji motor opslužuje korisnike. Zatim smo omogućili Photon za male podskupove korisnika i postepeno proširivali uvođenje, prateći kvalitet i performanse sve vreme. Prva verzija je prošla testiranje prihvatanja bez regresija kvaliteta, i nastavili smo uvođenje sve dok Photon nije opsluživao sav produkcioni saobraćaj.

Izmerena poboljšanja u produkciji

U našem produkcionom radnom toku, vreme odziva p99 palo je sa otprilike 800 ms u starom sistemu na otprilike 65 ms u Photon-u. Ovo merenje pokriva sve faze unutar Photona, ali isključuje naknadne faze u pretraživačkom steku višeg nivoa. Takođe više ne primećujemo skokove latencije koji su prethodno bili povezani sa promenom verzija indeksa.

Photon koristi približno 20% manje ekvivalentnih mašina za opsluživanje od čvorova sadržaja starog sistema, dok skladišti približno 2,5 puta više podataka po dokumentu. Nakon migracije, iskoristili smo ove dodatne podatke da poboljšamo kvalitet rangiranja iznad onog u starom sistemu.

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

Procena brzog Search API predseta

Takođe smo koristili Photon kao osnovu za novi brzi predset za naš Search API, dizajniran za radna opterećenja osetljiva na latenciju. Prema našim merenjima, latencija jednog poziva pretrage za brzi predset iznosi 160 ms na p50 i 230 ms na p95, što je niže od ili uporedivo sa brojevima koje su sami prijavili drugi provajderi Search API-ja, mada se prijavljeni krajnji percentili razlikuju.

Procenili smo brzi predset na šest agentskih repernih testova: WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0 i SEAL-Hard. Kroz ove procene, imao je najniži procenjeni ukupni trošak modela i pretrage i najviši ukupni skor zadatka među testiranim konfiguracijama.

Brzi predset uparuje Photon sa rangiranjem optimizovanim za agentske radne tokove, isporučujući uporedive performanse sa podrazumevanim predsetom uz znatno nižu cenu. Međutim, on dolazi sa kompromisom u širem kvalitetu pretrage. Brzi predset koristi manje računanja za rangiranje nego podrazumevani predset. Na internim repernim testovima koji pokrivaju upite dugog repa, široku pokrivenost i diverzitet rezultata, ima skor 0,24 poena niži na relevantnosti i približno 3 procentna poena niži na dostupnosti odgovora. Verujemo da je ovo razuman kompromis za agentske radne tokove, pošto sopstveno rezonovanje i znanje modela mogu pomoći da se nadoknadi razlika.

Uvećaj

Preporučujemo brzi predset za svakodnevne agentske zadatke. Za izazovnija ili dvosmislenija pitanja koja su manje vremenski osetljiva, podrazumevani predset nudi robustniji kvalitet, opravdavajući svoju veću latenciju i cenu.

Zaključak

Ujednačeno pomeramo naš stek pretrage na Rust-baziranu, sopstvenu infrastrukturu. Zamena open-source motora sa Photon-om, našim prilagođenim motorom za preuzimanje i rangiranje, predstavlja najnoviji korak. Photon nam daje potpunu kontrolu nad prikazima podataka, načinom na koji su čitanja organizovana i načinom na koji se novi indeksi primenjuju, omogućavajući nam da optimizujemo svaki sloj za naša radna opterećenja.

Photon je omogućio bržu pretragu širom Perplexity-jevih proizvoda i pruža osnovu za naš novi brzi predset u Search API-ju. Nakon migracije, latencija p99 preuzimanja i rangiranja pala je sa otprilike 800 ms na 65 ms. Naši kompaktni formati podataka takođe nam omogućavaju da skladištimo 2,5 puta više podataka po dokumentu, dajući preuzimanju i rangiranju pristup bogatijim informacijama o dokumentima.

Brzi predset obezbeđuje latenciju jednog poziva pretrage od 160 ms na p50 i 230 ms na p95. U šest procenjenih agentskih repernih testova, smanjio je procenjeni trošak modela i pretrage po zadatku za 68% u odnosu na podrazumevani predset, uz održavanje uporedive ukupne kvaliteta zadataka. Ovi rezultati demonstriraju praktične prednosti infrastrukture dizajnirane oko naših radnih opterećenja pretrage, kako za Perplexity-jeve proizvode, tako i za programere koji grade sa našim API-jem.

Nastavljamo da poboljšavamo performanse i efikasnost skladištenja Photona. Naš cilj je da podržimo veći indeks i bogatije podatke dokumenata na istom hardveru uz održavanje brze pretrage kako naša radna opterećenja rastu.

Citiranje

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