Photon: Vytvorenie enginu vyhľadávania a hodnotenia od základu

Úvod

Vyhľadávací šták spoločnosti Perplexity orientovaný na AI vyhľadáva a hodnotí kandidátske stránky a vynáša na povrch najrelevantnejší obsah, aby ho model použil na uzmenenie svojich odpovedí. Pôvodne táto fáza bežala na open-source engine, ktorý sme prispôsobili nášmu systému. Keď však naše indexy a pracovné zaťaženia rástli, narazili sme na pevné limity nákladov, koncovej latencie a času obnovy uzlov, ktoré sme nedokázali vyriešiť v rámci existujúcej platformy tretej strany.

Na prekonanie týchto výziev sme vytvorili Photon, nový interný engine vyhľadávania a hodnotenia. To nadväzuje na náš prístup budovania infraštruktúry vyhľadávania zameranej na AI od základu, tak ako sme to urobili s CobbleDB, naším distribuovaným úložiskom kľúč-hodnota na obsluhu záznamov stránok, a naším Search API.

Photon používa kompaktné dátové formáty na čítanie a dekodovanie iba toho, čo každý dopyt potrebuje, s vyrovnávacou pamäťou citlivou na dávky a asynchrónnym čítaním na zníženie prístupu na disk a prekrytie čakaní. Vytváranie indexu prebieha oddelene od vybavovania dopytov, pričom aktualizuje jednu obslužnú skupinu naraz a zahrieva jej vyrovnávacie pamäte predtým, ako na ňu začne smerovať aktívne dopyty.

Photon teraz poháňa našu vyhľadávaciu pipeline a je tiež základom novej rýchlej predvoľby pre naše Search API, s latenciou jedného volania vyhľadávania 160 ms pri p50 a 230 ms pri p95. Naprieč šiestimi verejnými benchmarkmi znížila rýchla predvoľba odhadované náklady na model plus vyhľadávanie na úlohu o 68 % pri zachovaní súhrnnej kvality úloh porovnateľnej s predvolenou predvoľbou. Uvoľňujeme ho dnes, aby vývojári mohli získať prístup k týmto vylepšeniam.

Zväčšiť

Zväčšiť

Čo engine vyhľadávania a hodnotenia vyžaduje

Pre každý dopyt prehľadáva engine vyhľadávania a hodnotenia veľký, distribuovaný index s cieľom vybrať a usporiadať malú množinu relevantných stránok v rámci rozpočtu latencie vyhľadávacieho štáku. Systém musí tiež udržiavať index aktuálny s príchodom nových stránok a zmenami existujúcich stránok bez toho, aby táto práca spomalila živé dopyty.

Vyhodnotili sme niekoľko možností open-source a zvolili sme zrelý, všeobecne použiteľný engine vyhľadávania a hodnotenia, ktorý spĺňal naše počiatočné potreby. Potom sme ho prispôsobili našej architektúre a pracovným zaťaženiam pri zachovaní stabilnej latencie a priepustnosti v produkčnej mierke.

Kde náš predchádzajúci systém zlyhal

Udržiavali sme vlastný fork na prispôsobenie enginu nášmu rastúcemu indexu, ale riešenie kľúčových obmedzení si čoraz viac vyžadovalo prepracovanie veľkých častí platformy. Niekoľko obmedzení sa ukázalo ako ťažko riešiteľných bez zásadných architektonických zmien:

1. Náklady na škálovanie. Počet dokumentov, ktoré ukladáme, aj množstvo dát na dokument, ktoré potrebujeme vyhľadať a hodnotiť, časom rástli. Toto škálovanie vyvíjalo tlak na náš hardvér, najmä na množstvo dostupnej pamäte RAM. Na kontrolu nákladov sme potrebovali kompaktnejšie dátové reprezentácie a jemnejšiu kontrolu nad tým, čo zostáva v pamäti a čo sa číta z disku na požiadanie.

2. Slabá koncová latencia. Pri produkčnej premávke bol čas odozvy p99 starého systému približne 800 ms. Dátová množina presahovala dostupnú pamäť RAM, takže sme nemohli použiť mlock na jej úplné udržať v pamäti. Prístup k nerezidentným dátam mohol vyvolať závažné výpadky stránok, čo pozastavilo vykonávanie dopytu, zatiaľ čo operačný systém čítal z disku.

Engine tiež pravidelne zlučoval svoj hlavný diskový index s menšími indexmi vyprázdnenými z pamäte. Počas tohto procesu splývania diskového indexu počet výpadkov stránok rástol ešte viac, pričom latencia p99 dosahovala približne 1,2 s počas 10 až 15 minút. S otepľovaním vyrovnávacích pamätí frekvencia výpadkov stránok a latencia klesali, čo naznačuje, že studené čítania boli hlavným prispievateľom k špičkám. Predbežné načítanie dát a zahriatie indexu znížili špičky, ale adekvátne neriešili vysokú koncovú latenciu.

3. Dlhodobá obnova a synchronizácia. V predchádzajúcom systéme mohlo nasadenie dodatočného clustera a synchronizácia jeho dát trvať viac ako týždeň. Synchronizácia bola potrebná aj pri pridávaní skupín uzlov na uchovanie ďalších kópií dát alebo pri obnove po zlyhaniach uzlov. Počas obnovy bol väčší podiel odpovedí vyhľadávania čiastočný, čo znižovalo skóre kvality konečnej odpovede.

Nakoniec sme dospeli k záveru, že by bolo jednoduchšie a lacnejšie stavať od základu, než pokračovať v prispôsobovaní a údržbe nášho forku. Čerpajúc z našich skúseností s prevádzkou predchádzajúceho systému, malý inžiniersky tím pracoval po boku roja trvalých kódovacích Agentov na vytvorení Photonu.

Kam Photon zapadá v štáku vyhľadávania

Photon je navrhnutý pre dva primárne pracovné postupy: obsluhovanie požiadaviek na vyhľadávanie a prijímanie aktualizácií z potrubia spracovania.

Požiadavka zo služieb vyhľadávania vyššej úrovne dosahuje broker Photon cez balancer záťaže. Broker vyberie skupinu shardov a prepošle požiadavku každému shardovi, pričom sleduje časové limity a v prípade potreby vydáva ďalšie požiadavky.

Každý shard vykonáva vyhľadávanie, počiatočné hodnotenie a hodnotenie druhej fázy, potom vráti svojich najlepších kandidátov brokerovi. Broker kombinuje týchto kandidátov do jedného zoradeného zoznamu a načítava kľúčové polia dokumentov pre vybrané stránky z relevantných shardov. Potom tieto výsledky vracia službe vyhľadávania vyššej úrovne, ktorá zhromažďuje obsah stránky potrebný na to, aby Agent vygeneroval uzmenenú odpoveď.

Aktualizácie indexu nasledujú samostatnú cestu. Pillar, naša publikačná vrstva, pripravuje dáta a ukladá ich do tabuliek YTsaurus. Indexery konvertujú tieto tabuľky do štruktúr indexu, ktoré môžu shardy načítať pre vyhľadávanie. Kontrolér koordinuje prípravu dát, vytváranie indexu a nasadzovanie nových verzií indexu do obslužných skupín. Pred spracovaním aktívnej premávky každý shard prehráva skutočné vyhľadávacie dopyty na zahriatie svojich vyrovnávacích pamätí.

Zväčšiť

Navrhovanie Photonu pre naše pracovné postupy

Tri konštrukčné voľby robia Photon dobre prispôsobeným pre naše pracovné zaťaženie: kompaktné dátové reprezentácie, ukladanie do vyrovnávacej pamäte a asynchrónne čítania z disku a oddelenie aktualizácií indexu od obsluhy dopytov.

Dátové reprezentácie na vyhľadávanie a hodnotenie

Vyhľadávanie a hodnotenie pristupujú k dátam dokumentov odlišne. Lexikálne vyhľadávanie začína hľadanými výrazmi a nachádza dokumenty, ktoré ich obsahujú. Hodnotenie potom potrebuje podrobné informácie o každom vybranom dokumente vrátane frekvencií a pozícií termínov.

Photon používa dve doplňujúce sa reprezentácie na podporu týchto vzorcov prístupu. Invertovaný index ukladá zoznam zhodných dokumentov pre každý termín, nazývaný zoznam príspevkov, na podporu výberu kandidátov. Samostatné záznamy pre jednotlivé dokumenty poskytujú dáta potrebné na hodnotenie. Optimalizujeme tiež spôsob ukladania a prechádzania zoznamov príspevkov na zlepšenie výberu v rámci pevného pracovného rozpočtu.

Špecializované dátové reprezentácie nám umožňujú efektívnejšie ukladat kľúčové dáta. Kompaktnejší invertovaný index znižuje množstvo prečítaných alebo presunutých dát na dopyt, čím zlepšuje latenciu elimináciou zbytočných I/O operácií. Tieto formáty tiež umožňujú skontrolovať, či sa dokument objavuje v zozname bez jeho úplného dekódovania, čo je vlastnosť, na ktorú sa spolieha naša logika prechádzania na kontrolu množstva práce, ktorú dopyt vykoná v rámci pevného rozpočtu. Optimalizácia záznamov pre jednotlivé dokumenty nám umožňuje ukladat viac dát na dokument pre hodnotenie a zároveň znižuje náklady na škálovanie spojené s naším predchádzajúcim systémom.

Invertovaný index

Pre každý termín invertovaný index ukladá zoznam príspevkov. Tieto zoznamy sa môžu pohybovať od niekoľkých dokumentov až po milióny, takže žiadny jednotlivý formát nefunguje dobre pre každý zoznam. Photon zvolí formát na základe počtu dokumentov obsahujúcich termín.

Krátke zoznamy používajú vloženú reprezentáciu, ktorá sa zmestí do jednej stránky a nevyžaduje žiadnu tabuľku blokov. Dlhšie zoznamy, ktoré sa nezmestia do vloženej formy, sú rozdelené do blokov pokrývajúcich pevné rozsahy identifikátorov dokumentov. Reprezentácia každého bloku závisí od jeho hustoty: riedke bloky ukladajú zoradené polia posunov ID dokumentov, zatiaľ čo husté bloky používajú bitové mapy. Riedke bloky používajú cvvalové vyhľadávanie, ktoré postupuje vo väčších krokoch, aby preskočilo oblasti zoznamu. Husté bloky umožňujú kontroly členstva vyhľadaním bitu zodpovedajúceho dokumentu.

Frekvencia dopytov termínu určuje, kde je jeho zoznam príspevkov umiestnený na disku. Často dopytované zoznamy sú uložené blízko seba, čím sa horúce dáta koncentrujú v menšej úložnej oblasti. V rámci každého zoznamu sú dokumenty usporiadané podľa samostatného signálu užitočnosti tak, aby sa sľubnejší kandidáti stretli skôr.

Zväčšiť

Prechádzanie zoznamov v rámci pracovného rozpočtu

Výber kandidátov vyžaduje prechádzanie zoznamov príspevkov na nájdenie potenciálne relevantných dokumentov. Vyčerpávajúce prehľadávanie každého zoznamu je drahé, takže Photon používa algoritmus podobný WAND, ktorý prechádza iba niektoré zoznamy a zároveň zohľadňuje zhody v ostatných.

Algoritmus delí zoznamy do dvoch skupín. Hnacie zoznamy posúvajú prechádzanie vpred a navrhujú kandidátske dokumenty. Sondačné zoznamy prispievajú k skóre týchto kandidátov, ale sami o sebe generujú kandidátov.

Bodovanie kandidátov kombinuje vážené pokrytie dopytovaných termínov a príspevok frekvencie s normalizáciou dĺžky dokumentu a hornou hranicou ziskov z opakovaných termínov. Photon najprv skontroluje prítomnosť termínov v poliach a bitových mapách, aby ohraničil maximálne možné skóre každého kandidáta. Presné frekvencie termínov číta iba pre kandidátov, ktorí by stále mohli splniť prah výberu.

Výber potom prebieha v troch krokoch:

• Prechádzanie: Začnite s prísnou požiadavkou na pokrytie dopytu. Ak sa nájde primálo kandidátov, zopakujte to s uvoľnenou požiadavkou.
• Uchovanie: Kandidáti sú udržiavaní v ohraničenej množine pomocou skóre, ktoré kombinuje pokrytie a frekvenciu. Slepovaním najlepších zhromaždených kandidátov sa prah prijatia zvyšuje.
• Konečný výber: Konečné výsledky pre prechod sú vybrané zo zachovanej množiny na základe frekvenčných skóre. Každé pole spúšťa vlastný prechod a výsledky sa zlučujú pomocou váh polí.

Algoritmus vytvára kandidátsku množinu relevantných dokumentov, ktoré sa použijú pri ďalšom hodnotení.

Zväčšiť

Docblob

Po výbere kandidátskych stránok fáza hodnotenia vyžaduje frekvencie termínov, pokrytie polí a umiestnenia a blízkosť výskytov. Získanie týchto dát prostredníctvom invertovaného indexu by si vyžadovalo roztrieštené prístupy naprieč mnohými pármi termín-dokument. V Photone ukladáme kompaktný záznam pre každý dokument nazývaný docblob, ktorý obsahuje frekvencie termínov, polia, v ktorých sa termín objavil, a miesto v dokumente, kde sa vyskytol. V dôsledku toho hodnotenie kandidáta vyžaduje iba jedno vyhľadávanie na dokument.

Formát je vytvorený tak, aby sa zabránilo dekódovaniu viac, než je nutné. V rámci docblobu sú polia zoskupené podľa textového analyzátora. Každá skupina ukladá zoradený zoznam termínov kódovaný pomocou Elias-Fano, takže vyhľadávací výraz možno vyhľadať priamo bez predchádzajúceho rozbalenia celého zoznamu. Maska poľa označuje, kde sa výraz vyskytol, počítadlo frekvencií sleduje, ako často, a skutočné pozície sú v samostatných blokoch pre každý pár termín-pole kódovaných ako rozdiely pozícií. Dekódujú sa iba bloky pre termíny, ktoré sa skutočne zhodovali, zatiaľ čo všetko ostatné v zázname zostáva v komprimovanom formáte.

Toto selektívne dekódovanie umožňuje docblob podporovať ukladanie viacerých dát na dokument bez úmerného zvýšenia nákladov. Rast záznamu nevynucuje viac práce na jedno vyhľadávanie, pretože hodnotenie sa vždy dotýka iba častí relevantných pre zhodujúce sa termíny namiesto celého záznamu.

Zväčšiť

Dávkové čítanie a práca s pamäťou

Dokonca aj s efektívnejšími dátovými reprezentáciami sa pamäť RAM stále minie skôr než ostatné prostriedky, takže často potrebujeme pristupovať k dátam uloženým na disku. Photon používa asynchrónne čítania z disku a vyrovnávaciu pamäť optimalizovanú pre dávkové čítanie na urýchlenie týchto prístupov, čím skracuje čas čakania na požiadavku. To prispieva k významnému zlepšeniu koncovej latencie v porovnaní s predchádzajúcim systémom.

Zväčšiť

Prekrývajúce sa čakania disku

Hodnotenie si vyžaduje získanie rysov stovky dokumentov umiestnených v rôznych častiach súboru. Náš predchádzajúci systém používal mmap na namapovanie súboru do virtuálneho adresného priestoru, aby sa dal čítať cez pamäťové ukazovatele. Avšak prístup k stránke, ktorá chýbala v pamäti, stále vyžadoval čítanie z disku. Vlákno muselo čakať na dáta pred pokračovaním výpočtu a tento čas čakania sa sčítaval, keď proces potreboval čítať studené záznamy sekvenčne.

Photon využíva skutočnosť, že pozície záznamov sú známe vopred, takže môžeme odoslať niekoľko čítaní naraz. To riadi reaktor: vyhradené pracovné vlákna odosielajú dávky prostredníctvom io_uring a odovzdávajú prečítané dáta volajúcemu kódu. Každé vlákno udržiava vlastné io_uring; dávky sa posielajú do najmenej zaťaženého reaktora. Vopred zaregistrované deskriptory súborov a bazény vyrovnávacích pamätí znižujú réžiu opakovaného čitania. Toto asynchrónne vykonávanie umožňuje prekrývanie čakaní na viaceré operácie, čím sa znižuje koncová latencia.

Zníženie počtu prístupov k jednotke

Pred odoslaním čítaní Photon skontroluje celú dávku vo vyrovnávacej pamäti v pamäti. Na disk idú iba požiadavky na chýbajúce záznamy; prečítané dáta potom naplnia vyrovnávaciu pamäť.

Vyrovnávacia pamäť je navrhnutá pre dávkové čítanie. Konkrétne:

• Pri zásahu nedochádza k žiadnej samostatnej alokácii. Dáta sa namiesto toho skopírujú do vyrovnávacej pamäte pripravenej vopred volajúcim kódom.
• Čitateľ nezískava žiadny zámok. Namiesto toho skontroluje verziu dát a ak je v konflikte so zápisom, operáciu zopakuje.
• Využíva vypratanie CLOCK namiesto vyžadovania aktualizácií zdieľaného zoznamu LRU pri každom čítaní.
• Využíva predbežné načítanie do vyrovnávacej pamäte procesora, kde sa metadáta a dáta pre nadchádzajúce záznamy vyžadujú vopred.

Tieto optimalizácie znižujú latenciu bez toho, aby poškodili výkon pri pracovných zaťaženiach, na ktorých nám záleží.

Vytváranie a aktualizácia indexu oddelene od obsluhy

V Photone beží budovanie indexu a obsluhovanie dopytov na rôznych uzloch. Indexery transformujú dáta do štruktúr pripravených na úložisko, zatiaľ čo obslužné uzly ich čítajú a vykonávajú vyhľadávanie a hodnotenie. V dôsledku toho budovanie indexu nekonkuruje vyhľadávacím dopytom o CPU a prostriedky pre tieto úlohy možno škálovať nezávisle.

Toto oddelenie rieši úzke miesta obnovy a synchronizácie prítomné v predchádzajúcej implementácii. Keďže vytváranie indexu prebiehalo vnútri rovnakého clustera, ktorý obsluhoval dopyty, obnova zlyhaného uzla alebo pridanie novej kópie dát mohlo znamenať reindexáciu dokumentov na mieste, čo je proces, ktorý trval dni a zvyšoval čiastočné odpovede počas obnovy. Photon odstraňuje toto prepojenie; indexery fungujú ako distribuované úlohy, ktoré produkujú verzované štruktúry indexov pripravené na obsluhu nezávisle od obslužných uzlov, takže budovanie ďalšej verzie indexu už nekonkuruje aktívnej premávke.

Zväčšiť

Príprava a distribuované budovanie

Zostavenie začína výberom dokumentov pre aktívny index a vytvorením zdrojového exportu. Kontrolér zaznamenáva zdrojovú verziu, vstupné tabuľky a očakávaný počet shardov. Úlohy MapReduce v YTsaurus pripravujú text, metadáta, fragmenty, rysy a predvypočítané vnorenia do verzovaných tabuliek rozdelených podľa shardov. Každý indexer streamuje pripravenú tabuľku, vytvorí štruktúry pre svoj shard a zlúči textové segmenty. Pripravený index spolu s popisom jeho komponentov sa nahrajú do objektového úložiska.

Počet shardov a počet súbežne bežiacich indexerov sú konfigurované nezávisle, takže zostavenie môže prebiehať v niekoľkých vlnách alebo je možné priradiť viac strojov na paralelnú prácu. Distribuovaná príprava a paralelné indexery umožňujú vytvoriť celý webový index za jednociferný počet hodín, čo je výrazné zlepšenie oproti predchádzajúcemu systému.

Nasadzovanie novej verzie

Pred nasadením kontrolér overí, či je nový index pripravený. Ak sú dáta neúplné, nasadenie sa automaticky zablokuje.

Ak existuje viacero obslužných skupín, kontrolér ich aktualizuje po jednej. Najprv odstráni skupinu zo smerovania brokera a spustí ju na novej verzii indexu. Pred obsluhou požiadaviek prechádzajú shardy samostatnou fázou zahrievania založenou na záznamoch vyhľadávania, čím sa predbežne naplní počiatočný stav a prechod na skutočnú premávku je plynulejší. Po zahriatí kontrolér skontroluje stav indexu a pripravenosť a potom vráti skupinu do smerovania. Ostatné skupiny počas tejto doby pokračujú v obsluhovaní požiadaviek. Pretože je prevádzkový stav zachovaný, reštart nevynucuje opätovné spustenie zostavenia; kontrolér sa môže znova pripojiť k prebiehajúcej príprave, opätovne použiť pripravený výsledok alebo pokračovať v prerušenej rotácii od uloženého kroku.

Časy aktualizácie dát sa líšia naprieč vertikálami vyhľadávania. Pre vertikály s vysokými požiadavkami na čerstvosť trvá doručenie dokumentu jednociferný počet minút. Ďalšiu kópiu dát je možné nasadiť za približne pol hodinu; pripravené indexy sa načítajú a pripoja k shardom bez reindexácie zdrojových dokumentov.

Zväčšiť

Migrácia a overenie v rámci nášho vyhľadávacieho štáku

Naším prvým cieľom bolo nahradiť starý systém enginom, ktorý zachoval funkčnosť a kvalitu vyhľadávania a zároveň skrátil časy odozvy. Overili sme Photon v etapách, počnúc reprodukovateľnými záťažovými testami a offline vyhodnoteniami kvality pred prechodom na živú premávku. Photon teraz poháňa vyhľadávanie a hodnotenie v našom produkčnom vyhľadávacom štáku s podstatne nižšími časmi odozvy než starý systém.

Záťažové testovanie a vyhodnotenia

Na testovanie výkonu sme vytvorili nástroj na záťažové testovanie, ktorý prehráva dopyty z našich záznamov vyhľadávania pri konfigurovateľných frekvenciách príchodu. Porovnáva výsledky naprieč behmi a aplikuje štatistické testy na posúdenie, či sú pozorované rozdiely vo výkone konzistentné. Okrem toho sme vyhodnotili Photon a starý systém na rovnakých dátových sadách v našich interných offline systémoch vyhodnocovania, aby sme skontrolovali regresie kvality.

Po týchto kontrolách sme odoslali živé dopyty do oboch enginov súčasne pomocou tieňovej premávky. To nám umožnilo porovnať ich výkon a výsledky pri produkčnom zaťažení pred zmenou enginu, ktorý obsluhuje používateľov. Potom sme povolili Photon pre malé podskupiny používateľov a postupne rozšírili zavádzanie, pričom sme neustále sledovali kvalitu a výkon. Prvá verzia prešla akceptačným testovaním bez regresií kvality a v zavádzaní sme pokračovali, kým Photon neobsluhoval všetku produkčnú premávku.

Namerané vylepšenia v produkte

V našom produkčnom pracovnom postupe klesol čas odozvy p99 z približne 800 ms v starom systéme na približne 65 ms v Photone. Toto meranie pokrýva všetky fázy vnútri Photonu, ale nezahŕňa následné fázy vo vyhľadávacom štáku vyššej úrovne. Už tiež nepozorujeme špičky latencie predtým spojené so zmenou verzií indexu.

Photon využíva približne o 20 % menej ekvivalentných obslužných strojov než obsahové uzly starého systému, pričom ukladá približne 2,5-krát viac dát na dokument. Po migrácii sme použili tieto dodatočné dáta na zlepšenie kvality hodnotenia nad rámec starého systému.

Photon tiež znižuje množstvo dát, ktoré musia zotrvať v pamäti RAM. Pripnutie rovnakej databázy Photon v pamäti RAM pomocou príkazu mlock by vyžadovalo odhadom 4,6-krát viac rezidentnej pamäte, než Photon aktuálne využíva.

Vyhodnotenie rýchlej predvoľby Search API

Photon sme použili aj ako základ pre novú rýchlu predvoľbu pre naše Search API, navrhnutú pre pracovné postupy citlivé na latenciu. Podľa našich meraní je latencia jedného volania vyhľadávania pre rýchlu predvoľbu 160 ms pri p50 a 230 ms pri p95, čo je nižšie alebo porovnateľné so samohlasenými číslami iných poskytovateľov Search API, hoci hlásené koncové percentily sa líšia.

Vyhodnotili sme rýchlu predvoľbu na šiestich agentických benchmarkoch: WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0 a SEAL-Hard. Naprieč týmito vyhodnoteniami mala najnižšie odhadované celkové náklady na model plus vyhľadávanie a najvyššie súhrnné skóre úloh medzi testovanými konfiguráciami.

Rýchla predvoľba spája Photon s hodnotením optimalizovaným pre agentické pracovné postupy, čo prináša porovnateľný výkon s predvolenou predvoľbou za podstatne nižšie náklady. Prináša však kompromis v širšej kvalite vyhľadávania. Rýchla predvoľba využíva menej výpočtového výkonu na hodnotenie než predvolená predvoľba. Na interných benchmarkoch pokrývajúcich dopyty s dlhým chvostom, široké pokrytie a rôznorodosť výsledkov dosahuje o 0,24 bodu nižšie skóre v relevancii a približne o 3 percentuálne body nižšiu dostupnosť odpovedí. Veríme, že ide o rozumný kompromis pre agentické pracovné postupy, pretože vlastné uvažovanie a znalosti modelu môžu pomôcť kompenzovať tento rozdiel.

Zväčšiť

Odporúčame rýchlu predvoľbu pre každodenné agentické úlohy. Pre náročnejšie alebo nejednoznačné otázky, ktoré sú menej časovo citlivé, ponúka predvolená predvoľba robustnejšiu kvalitu, čo odôvodňuje jej vyššiu latenciu a náklady.

Záver

Priebežne presúvame náš vyhľadávací šták na internú infraštruktúru založenú na jazyku Rust. Nahradenie open-source enginu Photonom, naším vlastným enginom vyhľadávania a hodnotenia, je najnovším krokom. Photon nám poskytuje plnú kontrolu nad dátovými reprezentáciami, organizáciou čítaní a nasadzovaním nových indexov, čo nám umožňuje optimalizovať každú vrstvu pre naše pracovné zaťaženia.

Photon umožnil rýchlejšie vyhľadávanie naprieč produktmi Perplexity a poskytuje základ pre našu novú rýchlu predvoľbu v Search API. Po migrácii klesla latencia vyhľadávania a hodnotenia p99 z približne 800 ms na 65 ms. Naše kompaktné dátové formáty nám tiež umožňujú ukladat 2,5-krát viac dát na dokument, čo poskytuje vyhľadávaniu a hodnoteniu prístup k bohatším informáciám o dokumentoch.

Rýchla predvoľba poskytuje latenciu jedného volania vyhľadávania 160 ms pri p50 a 230 ms pri p95. Naprieč šiestimi vyhodnocovanými agentickými benchmarkmi znížila odhadované náklady na model plus vyhľadávanie na úlohu o 68 % v porovnaní s predvolenou predvoľbou pri zachovaní porovnateľnej súhrnnej kvality úloh. Tieto výsledky demonštrujú praktické výhody infraštruktúry navrhnutej okolo našich vyhľadávacích pracovných zaťažení, a to tak pre produkty spoločnosti Perplexity, tak pre vývojárov budujúcich s naším API.

Neustále zlepšujeme výkon a úložnú efektivitu Photonu. Našim cieľom je podporovať väčší index a bohatšie dáta dokumentov na rovnakom hardvéri a zároveň udržiavať rýchle vyhľadávanie s rastom našich pracovných zaťažení.

Citácia

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