Photon: Byggede en hentnings- og rangordningsmotor fra bunden

Introduktion

Perplexity’s AI-native søgestak henter og rangordner kandidatsider og overfladebehandler det mest relevante indhold, som modellen kan bruge til at fundere sine svar. Oprindeligt kørte dette stadie på en open source-motor, som vi tilpassede til vores system. Men efterhånden som vores indeks og arbejdsbelastninger voksede, stødte vi på hårde grænser for omkostninger, hal latens og nodegendannelsestid, som vi ikke kunne løse inden for den eksisterende tredjepartsplatform.

For at overvinde disse udfordringer byggede vi Photon, en ny internt udviklet hentnings- og rangordningsmotor. Dette fortsætter vores tilgang med at bygge AI-første søgeinfrastruktur fra bunden, som vi gjorde med CobbleDB, vores distribuerede nøgle-værdi-lager til betjening af sideposter, og vores Search API.

Photon bruger kompakte dataformater til kun at læse og afkode det, som hver forespørgsel har brug for, med batch-bevidst caching og asynkrone læsninger for at reducere diskadgang og overlappe ventetider. Indeksopbygning kører separat fra forespørgselsbetjening, hvor en betjeningsgruppe opdateres ad gangen, og dens cacher varmes op, inden liveforespørgsler dirigeres dertil.

Photon driver nu vores søgepipeline og er også fundamentet for en ny hurtig forudindstilling til vores Search API, med en enkelt søgeforpørgsels latens på 160 ms ved p50 og 230 ms ved p95. På tværs af seks offentlige benchmarks reducerede den hurtige forudindstilling de anslåede model-plus-søgning-omkostninger pr. opgave med 68%, samtidig med at den opretholdt en samlet opgavekvalitet, der kan sammenlignes med standardforudindstillingen. Vi frigiver den i dag, så udviklere kan få adgang til disse forbedringer.

Udvid

Udvid

Hvad hentnings- og rangordningsmotoren kræver

For hver forespørgsel søger hentnings- og rangordningsmotoren i et stort, distribueret indeks for at vælge og sortere et lille sæt relevante sider inden for søgestakkens latensbudget. Systemet skal også holde indekset opdateret, efterhånden som nye sider ankommer, og eksisterende sider ændrer sig, uden at det arbejde får lov til at sænke liveforespørgsler.

Vi evaluerede flere open source-muligheder og valgte en moden, generelt anvendelig hentnings- og rangordningsmotor, der opfyldte vores indledende behov. Vi tilpassede den derefter til vores arkitektur og arbejdsbelastninger, hvilket opretholdt stabil latens og gennemløb i produktionsskala.

Hvor vores forrige system kom til kort

Vi vedligeholdt vores egen fork for at tilpasse motoren til vores voksende indeks, men adressering af vigtige begrænsninger krævede i stigende grad omdesign af store dele af platformen. Flere begrænsninger viste sig svære at løse uden fundamentale arkitektoniske ændringer:

1. Skaleringsomkostninger. Både antallet af dokumenter, vi gemmer, og mængden af data pr. dokument, vi har brug for at hente og rangordne, er vokset over tid. Denne skalering lagde pres på vores hardware, især mængden af tilgængelig RAM. For at kontrollere omkostningerne havde vi brug for mere kompakte datarepræsentationer og finere kontrol over, hvad der forbliver i hukommelsen, og hvad der læses fra disk efter behov.

2. Dårlig hal latens. På produktionstrafik var det gamle systems p99-responstid omkring 800 ms. Datasættet oversteg tilgængelig RAM, så vi kunne ikke bruge mlock til at holde det fuldstændigt i hukommelsen. Adgang til ikke-resident data kunne udløse store sidefejl, hvilket standsede forespørgselsudførelsen, mens operativsystemet læste fra disk.

Motoren flettede også periodisk sit primære diskindeks med mindre indeks skyllet fra hukommelsen. Under denne diskindeksfusionsproces steg antallet af sidefejl endnu højere, idet p99-latensen nåede ca. 1,2 s i 10–15 minutter. Efterhånden som cacherne varmede op, faldt både hyppigheden af sidefejl og latensen, hvilket antydede, at kolde læsninger var en væsentlig bidragyder til spidsbelastningerne. Forhåndsindlæsning af data og opvarmning af indekset reducerede spidsbelastningerne, men adresserede ikke tilstrækkeligt høj hal latens.

3. Langvarig genoprettelse og synkronisering. I det forrige system kunne det tage mere end en uge at udrulle en yderligere klynge og synkronisere dens data. Synkronisering var også nødvendig, når der blev tilføjet grupper af noder til at rumme yderligere datakopier eller ved genoprettelse efter nodefejl. Under genoprettelse var en større del af søgeresultaterne delvise, hvilket sænkede kvalitetsscorene for det endelige svar.

I sidste ende konkluderede vi, at det ville være enklere og billigere at bygge fra bunden i stedet for at fortsætte med at tilpasse og vedligeholde vores fork. Med udgangspunkt i vores erfaring med driften af det forrige system arbejdede et lille engineering-team sammen med en sværm af vedholdende kodningsagenter på at bygge Photon.

Hvor Photon passer ind i søgestakken

Photon er designet til to primære arbejdsgange: betjening af søgeforespørgsler og indtagelse af opdateringer fra behandlingspipelinen.

En forespørgsel fra søgetjenesten på højere niveau når Photon-brokeren gennem en load balancer. Brokeren vælger en shard-gruppe og videresender forespørgslen til hver shard, overvåger timeouts og udsteder yderligere forespørgsler efter behov.

Hver shard udfører hentning, indledende rangordning og andengangs rangordning og returnerer derefter sine bedste kandidater til brokeren. Brokeren kombinerer disse kandidater til en enkelt rangordnet liste og henter nøgledokumentfelter for de valgte sider fra de relevante shards. Den returnerer derefter disse resultater til søgetjenesten på højere niveau, som indsamler det sideindhold, der er nødvendigt for, at agenten kan generere et funderet svar.

Indeksopdateringer følger en separat sti. Pillar, vores publiceringslag, forbereder dataene og gemmer dem i YTsaurus-tabeller. Indexere konverterer disse tabeller til indeksstrukturer, som shards kan indlæse til søgning. Controlleren koordinerer dataklargøring, indeksopbygning og distribution af nye indeksversioner til betjeningsgrupper. Før håndtering af livetrafik afspiller hver shard reelle søgeforespørgsler for at varme sine cacher op.

Udvid

Design af Photon til vores arbejdsgange

Tre designvalg gør Photon godt egnet til vores arbejdsbelastning: kompakte datarepræsentationer, caching og asynkrone disklæsninger samt adskillelse af indeksopdateringer fra forespørgselsbetjening.

Datarepræsentationer til hentning og rangordning

Hentning og rangordning tilgår dokumentdata forskelligt. Leksikalsk hentning starter med forespørgselsttermer og finder dokumenter, der indeholder dem. Rangordning har derefter brug for detaljerede oplysninger om hvert valgt dokument, herunder termfrekvenser og positioner.

Photon bruger to komplementære repræsentationer til at understøtte disse adgangsmønstre. Et inverteret indeks gemmer en liste over matchende dokumenter for hver term, kaldet en postliste, for at understøtte kandidatudvælgelse. Separate poster pr. dokument giver de data, der er nødvendige for rangordning. Vi optimerer også, hvordan postlister gemmes og gennemgås for at forbedre udvælgelsen inden for et fast arbejdsbudget.

Specialiserede datarepræsentationer gør det muligt for os at gemme nøgledata mere effektivt. Et mere kompakt inverteret indeks reducerer mængden af data, der læses eller flyttes pr. forespørgsel, hvilket forbedrer latensen ved at eliminere unødvendige I/O-operationer. Disse formater gør det også muligt at kontrollere, om et dokument vises på en liste uden fuldstændig afkodning af den, en egenskab som vores gennemgangslogik er afhængig af for at kontrollere, hvor meget arbejde en forespørgsel udfører under et fast budget. Optimering af poster pr. dokument giver os mulighed for at gemme mere data pr. dokument til rangordning, samtidig med at det reducerer skaleringsomkostningerne forbundet med vores forrige system.

Det inverterede indeks

For hver term gemmer det inverterede indeks en postliste. Disse lister kan spænde fra en håndfuld dokumenter til millioner, så intet enkelt format fungerer godt til hver liste. Photon vælger formatet baseret på antallet af dokumenter, der indeholder termen.

Korte lister bruger en inline-repræsentation, der passer inden for en enkelt side og ikke kræver en bloktabel. Længere lister, der ikke passer til inline-formatet, opdeles i blokke, der dækker faste intervaller af dokumentidentifikatorer. Hver bloks repræsentation afhenger af dens tæthed: sparse blokke gemmer sorterede arrays af dokument-ID-forskydninger, mens dense blokke bruger bitmønstre. Sparse blokke bruger galloperende søgning, som bevæger sig frem i stadigt større trin for at springe områder af listen over. Dense blokke tillader medlemskabskontroller ved at slå den bit op, der svarer til et dokument.

En terms forespørgselsfrekvens bestemmer, hvor dens postliste placeres på disken. Hyppigt forespurgte lister gemmes tæt på hinanden, hvilket koncentrerer varme data i et mindre lagringsområde. Inden for hver liste ordnes dokumenter efter et separat nytteværdisignal, så mere lovende kandidater stødes på tidligere.

Udvid

Gennemgang af lister inden for et arbejdsbudget

Kandidatudvælgelse kræver gennemgang af postlister for at finde potentielt relevante dokumenter. Udtømmende scanning af hver liste er dyr, så Photon bruger en WAND-lignende algoritme, der kun gennemgår nogle lister, mens den stadig tager højde for matches i de andre.

Algoritmen opdeler lister i to grupper. Drivlister fremmer gennemgangen og foreslår kandidatdokumenter. Probelister bidrager til scorene for disse kandidater, men genererer ikke selv kandidater.

Kandidatscoring kombinerer vægtet forespørgselstermdækning og et frekvensbidrag med dokumentlængdenormalisering og et loft over gevinster fra gentagne termer. Photon kontrollerer først termens tilstedeværelse i de arrays og bitmønstre for at afgrænse hver kandidats maksimale mulige score. Den læser nøjagtige termfrekvenser kun for kandidater, der stadig kan opfylde udvælgelsestærsklen.

Udvælgelsen fortsætter derefter i tre trin:

• Gennemgang: Start med et strengt forespørgselsdækningskrav. Hvis der findes for få kandidater, gentages med et afslappet krav.
• Fastholdelse: Kandidater holdes i et afgrænset sæt ved hjælp af en score, der kombinerer dækning og frekvens. Efterhånden som de indsamlede top-kandidater forbedres, stiger adgangstærsklen.
• Endelig udvælgelse: Endelige resultater for gennemgangen vælges fra det fastholdte sæt baseret på frekvensscorene. Hvert felt kører sin egen gennemgang, og resultaterne flettes ved hjælp af feltvægte.

Algoritmen producerer et kandidatsæt af relevante dokumenter, der skal bruges i yderligere rangordning.

Udvid

Docblob

Når kandidatsider er valgt, har rangordningsfasen brug for termfrekvenser, feltdækning samt forekomsternes placering og nærhed. At opnå disse data gennem det inverterede indeks ville kræve spredte adgange på tværs af mange term-dokument-par. I Photon gemmer vi en kompakt post pr. dokument kaldet docblob, som indeholder termfrekvenser, hvilke felter en term optrådte i, og hvor i dokumentet den forekom. Som et resultat kræver rangordning af en kandidat kun ét opslag pr. dokument.

Formatet er bygget til at undgå at afkode mere end nødvendigt. Inden for en docblob grupperes felter efter tekstanalyse. Hver gruppe gemmer en sorteret termliste kodet med Elias-Fano, så der kan slås op direkte på en forespørgselsterm uden først at udvide hele listen. En feltmaske markerer, hvor en term forekom, en frekvensoptælling sporer hvor ofte, og faktiske positioner ligger i separate blokke pr. term-felt-par kodet som positionsforskelle. Kun blokkene for termer, der faktisk matchede, bliver afkodet, mens alt andet i posten forbliver i det komprimerede format.

Denne selektive afkodning gør det muligt for docblob at understøtte lagring af mere data pr. dokument uden en proportional omkostningsstigning. Vækst i posten tvinger ikke mere arbejde pr. opslag frem, fordi rangordning kun berører de dele, der er relevante for de matchede termer, i stedet for hele posten.

Udvid

Batch-behandlede læsninger og arbejde med hukommelse

Selv med de mere eficiente datarepræsentationer løber RAM tør før andre ressourcer, så vi har jævnligt brug for at tilgå data gemt på disk. Photon bruger asynkrone disklæsninger og en cache optimeret til batch-læsninger for at fremskynde disse adgange, hvilket skærer ventetiden pr. anmodning ned. Dette bidrager til en markant forbedring i hal latens sammenlignet med det forrige system.

Udvid

Overlappende diskventetider

Rangordning kræver indhentning af funktionerne for et hundrede dokumenter placeret forskellige steder i en fil. Vores forrige system brugte mmap til at tilknytte filen til virtuel adresseplads, så den kunne læses gennem hukommelsespointere. Men adgang til en side, der manglede fra hukommelsen, krævede stadig en disklæsning. Tråden var nødt til at vente på dataene, før beregningen kunne fortsætte, og denne ventetid hobede sig op, når processen havde brug for at læse kolde poster sekventielt.

Photon udnytter det faktum, at postforskydninger kendes på forhånd, så vi kan indsende flere læsninger på én gang. Dette styres af reaktoren: dedikerede arbejdetråde indsender batches via io_uring og sender de læste data videre til den kaldende kode. Hver tråd opretholder sin egen io_uring; batches sendes til den mindst belastede reaktor. Forregistrerede filbeskrivelser og bufferpools reducerer overhead ved gentagne læsninger. Denne asynkrone udførelse gør det muligt for ventetiderne for flere operationer at overlappe hinanden, hvilket reducerer hal latens.

Reduktion af antallet af drevadgange

Før indsendelse af læsninger kontrollerer Photon hele batchen i hukommelsescachen. Kun anmodninger om manglende poster går til disk; de læste data udfylder derefter cachen.

Cachen er designet til batch-behandlede læsninger. Specifikt:

• Der er ingen separat tildeling ved et hit. I stedet kopieres data til en buffer, der er forberedt på forhånd af den kaldende kode.
• Der er ingen låseophvervelse af læseren. I stedet tjekker den dataversionen og prøver igen, hvis den er i konflikt med en skrivning.
• Den bruger CLOCK-rydning i stedet for at kræve opdateringer til en delt LRU-liste ved hver læsning.
• Den bruger CPU-cacheprefetching, hvor metadata og data for kommende poster anmodes om på forhånd.

Disse optimeringer reducerer latensen uden at skade ydeevnen på de arbejdsbelastninger, vi bekymrer os om.

Opbygning og opdatering af indekset adskilt fra betjening

I Photon kører indeksopbygning og forespørgselsbetjening på forskellige noder. Indexere transformerer data til klargjorte lagringsstrukturer, mens betjeningsnoder læser dem og udfører hentning og rangordning. Som et resultat konkurrerer indeksopbygning ikke med søgeforespørgsler om CPU, og ressourcer til disse opgaver kan skaleres uafhængigt.

Denne adskillelse adresserer de genoprettelses- og synkroniseringsflaskehalse, der var til stede i den forrige implementering. Da indeksopbygning kørte inde i den samme klynge, der betjente forespørgsler, kunne genetablering af en mislykket node eller tilføjelse af en ny kopi af dataene betyde genindeksering af dokumenter på stedet, en proces der tog dage og øgede delvise svar under genoprettelse. Photon fjerner denne kobling; indexere kører som distribuerede job, der producerer versionerede, klar-til-at-betjene indeksstrukturer uafhængigt af betjeningsnoderne, så opbygning af den næste version af indekset ikke længere konkurrerer med live trafik.

Udvid

Forberedelse og distribueret opbygning

En opbygning starter med at vælge dokumenter til det aktive indeks og producere kildeeksporten. Controlleren registrerer kildeversionen, inputtabeller og det forventede antal shards. MapReduce-job i YTsaurus forbereder tekst, metadata, fragmenter, funktioner og præ-beregnede indlejringer til versionerede tabeller opdelt efter shard. Hver indexer streamer den forberedte tabel, opbygger strukturerne for sin shard og fletter tekstsegmenter. Det klargjorte indeks uploades sammen med en beskrivelse af dets komponenter til objektlagring.

Shard-antal og antallet af samtidigt kørende indexere konfigureres uafhængigt, så en opbygning kan køre i flere bølger, eller flere maskiner kan tildeles til at arbejde parallelt. Distribueret forberedelse og parallelle indexere gør det muligt at opbygge hele webindekset på et enkeltcifret antal timer, en markant forbedring i forhold til det forrige system.

Udrulning af en ny version

Før udrulning kontrollerer controlleren, at det nye indeks er parat. Hvis dataene er ufuldstændige, blokeres udrulningen automatisk.

Når der er flere betjeningsgrupper, opdaterer controlleren dem én ad gangen. Den fjerner først en gruppe fra broker-routing og starter den på den nye indeksversion. Før betjening af forespørgsler gennemgår shards et separat opvarmningsstadie baseret på søgelogs, som præ-populerer den oprindelige tilstand og gør overgangen til reel trafik glattere. Efter opvarmning kontrollerer controlleren indekstilstanden og paratheden, og returnerer derefter gruppen til routing. De andre grupper fortsætter med at betjene forespørgsler i denne tid. Da driftstilstanden gemmes, tvinger en genstart ikke en opbygning til at starte forfra; controlleren kan gen-tilknytte til klargøring, der allerede er i gang, genbruge et parat resultat eller fortsætte en afbrudt rotation fra det gemte trin.

Dataopdateringstider varierer på tværs af søgevertikaler. For vertikaler med høje friskhedskrav tager dokumentlevering et enkeltcifret antal minutter. En yderligere kopi af dataene kan udrulles på omkring en halv time; klargjorte indeks indlæses og tilknyttes shards uden genindeksering af kildedokumenterne.

Udvid

Migration og validering i vores søgestak

Vores første mål var at erstatte det gamle system med en motor, der bevarede funktionalitet og søgekvalitet, samtidig med at responstiderne blev reduceret. Vi validerede Photon i etaper, startende med reproducerbare belastningstests og offline-kvalitetsevalueringer, før vi gik over til live trafik. Photon driver nu hentning og rangordning i vores produktionssøgestak med væsentligt lavere responstider end det gamle system.

Belastningstest og evalueringer

Til ydeevnetest opbyggede vi et belastningstestværktøj, der afspiller forespørgsler fra vores søgelogs ved konfigurerbare ankomstrater. Det sammenligner resultater på tværs af kørsler og anvender statistiske tests for at vurdere, om observerede ydeevneforskelle er konsistente. Separat evaluerede vi Photon og det gamle system på de samme datasæt i vores interne offline-evalueringssystemer for at tjekke for kvalitetsregressioner.

Efter disse kontroller sendte vi liveforespørgsler til begge motorer samtidigt ved hjælp af skyggetrafik. Dette gjorde det muligt for os at sammenligne deres ydeevne og resultater på produktionsarbejdsprocesser, før vi ændrede, hvilken motor der betjente brugere. Vi aktiverede derefter Photon for små undergrupper af brugere og udvidede gradvist udrulningen, mens vi overvågede kvalitet og ydeevne undervejs. Den første version bestod accepttest uden kvalitetsregressioner, og vi fortsatte udrulningen, indtil Photon betjente al produktionstrafik.

Målte forbedringer i produktion

I vores produktionsarbejdsproces faldt p99-responstiden fra ca. 800 ms i det gamle system til ca. 65 ms i Photon. Denne måling dækker alle stadier inde i Photon, men udelukker efterfølgende stadier i søgestakken på højere niveau. Vi observerer heller ikke længere de latensspidsbelastninger, der tidligere var forbundet med skift af indeksversioner.

Photon bruger ca. 20% færre tilsvarende betjeningsmaskiner end det gamle systems indholdsnoter, mens den gemmer ca. 2,5 gange så meget data pr. dokument. Efter migrationen brugte vi disse ekstra data til at forbedre rangordningskvaliteten ud over det gamle systems.

Photon reducerer også mængden af data, der skal forblive i hukommelsen. Pinning af det samme Photon-datasæt i RAM med mlock ville kræve anslået 4,6 gange så meget resident hukommelse, som Photon i øjeblikket bruger.

Evaluering af den hurtige Search API-forudindstilling

Vi brugte også Photon som grundlag for en ny hurtig forudindstilling til vores Search API, designet til latenssensitive arbejdsgange. Ifølge vores målinger er enkelt søgeforespørgsels latens for den hurtige forudindstilling 160 ms ved p50 og 230 ms ved p95, lavere end eller sammenlignelig med andre Search API-udbyderes selvrapporterede tal, selvom de rapporterede halpercentiler adskiller sig.

Vi evaluerede den hurtige forudindstilling på seks agentbaserede benchmarks: WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0 og SEAL-Hard. På tværs af disse evalueringer havde den de laveste anslåede samlede model-plus-søgning-omkostninger og den højeste samlede opgavescore blandt de testede konfigurationer.

Den hurtige forudindstilling parrer Photon med rangordning optimeret til agentbaserede arbejdsgange, hvilket leverer sammenlignelig ydeevne med standardforudindstillingen til væsentligt lavere omkostninger. Den kommer dog med et kompromis i bredere søgekvalitet. Den hurtige forudindstilling bruger mindre beregning til rangordning end standardforudindstillingen. På interne benchmarks, der dækker langhalede forespørgsler, bred dækning og resultatdiversitet, scorer den 0,24 point lavere på relevans og ca. 3 procentpoint lavere på svarets tilgængelighed. Vi mener, at dette er et fornuftigt kompromis for agentbaserede arbejdsgange, da modellens egen ræsonnering og viden kan hjælpe med at kompensere for forskellen.

Udvid

Vi anbefaler den hurtige forudindstilling til daglige agentbaserede opgaver. For mere udfordrende eller tvetydige spørgsmål, der er mindre tidssensitive, tilbyder standardforudindstillingen mere robust kvalitet, hvilket retfærdiggør dens højere latens og omkostninger.

Konklusion

Vi flytter støt vores søgestak over på Rust-baseret, internt udviklet infrastruktur. Udskiftning af open source-motoren med Photon, vores tilpassede hentnings- og rangordningsmotor, er det seneste skridt. Photon giver os fuld kontrol over datarepræsentationer, hvordan læsninger organiseres, og hvordan nye indeks udrulles, hvilket gør det muligt for os at optimere hvert lag til vores arbejdsbelastninger.

Photon har muliggjort hurtigere søgning på tværs af Perplexity’s produkter og giver fundamentet for vores nye hurtige forudindstilling i Search API. Efter migrationen faldt p99-hentning-og-rangordningslatensen fra ca. 800 ms til 65 ms. Vores kompakte dataformater giver os også mulighed for at gemme 2,5 gange så meget data pr. dokument, hvilket giver hentning og rangordning adgang til rigere dokumentoplysninger.

Den hurtige forudindstilling leverer en enkelt søgeforpørgsels latens på 160 ms ved p50 og 230 ms ved p95. På tværs af de seks evaluerede agentbaserede benchmarks reducerede den de estimerede model-plus-søgning-omkostninger pr. opgave med 68% i forhold til standardforudindstillingen, samtidig med at den opretholdt en sammenlignelig samlet opgavekvalitet. Disse resultater viser de praktiske fordele ved infrastruktur designet omkring vores søgearbejdsprocesser, både for Perplexity’s produkter og for udviklere, der bygger med vores API.

Vi fortsætter med at forbedre Photons ydeevne og lagringseffektivitet. Vores mål er at understøtte et større indeks og rigere dokumentdata på den samme hardware, samtidig med at vi holder søgningen hurtig, efterhånden som vores arbejdsbelastninger vokser.

Citat

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