Photon: Bygge en hentings- og rangeringsmotor fra bunnen av

Innledning

Perplexitys AI-native søkestak henter og rangerer kandidatsider, og overflater det mest relevante innholdet for at modellen skal jorde svarene sine. Opprinnelig kjørte dette stadiet på en open source-motor som vi tilpasset til systemet vårt. Etter hvert som indeksen og arbeidsbelastningen vår vokste, nådde vi imidlertid harde grenser for kostnader, hale-latens og node-gjenopprettingstid som vi ikke kunne løse innenfor den eksisterende tredjepartsplattformen.

For å overvinne disse utfordringene bygde vi Photon, en ny egenutviklet hentings- og rangeringsmotor. Dette fortsetter vår tilnærming med å bygge AI-første søkeinfrastruktur fra bunnen av, slik vi gjorde med CobbleDB, vår distribuerte nøkkel-verdi-lagring for å betjene sideposter, og søke-API-et vårt.

Photon bruker kompakte dataformater til å lese og dekode bare det hver spørring trenger, med seriebevisst mellomlagring og asynkrone lesinger for å redusere disklesing og overlappe ventetider. Indeksbygging kjøres separat fra spørringstjenesten, der én tjenestegruppe oppdateres om gangen og mellomlagrene varmes opp før levende spørringer rutes dit.

Photon driver nå søkepipelinen vår og er også fundamentet for en ny hurtigforhåndsinnstilling for søke-API-et vårt, med en enkelt søkeforespørsel-latens på 160 ms ved p50 og 230 ms ved p95. På tvers av seks offentlige benchmarks reduserte hurtigforhåndsinnstillingen anslått modell-plus-søk-kostnad per oppgave med 68 %, samtidig som den opprettholdt en samlet oppgavekvalitet som kan sammenlignes med standardforhåndsinnstillingen. Vi lanserer den i dag slik at utviklere kan få tilgang til disse forbedringene.

Forstørr

Forstørr

Hva hentings- og rangeringsmotoren krever

For hver forespørsel søker hentings- og rangeringsmotoren i en stor, distribuert indeks for å velge ut og ordne et lite sett med relevante sider innenfor søkestakkens latensbudsjett. Systemet må også holde indeksen oppdatert etter hvert som nye sider ankommer og eksisterende sider endres, uten at dette arbeidet saktner ned levende spørringer.

Vi evaluerte flere open source-alternativer og valgte en moden, generell hentings- og rangeringsmotor som oppfylte våre innledende behov. Vi tilpasset den deretter til arkitekturen og arbeidsbelastningen vår, og opprettholdt stabil latens og gjennomstrømning i produksjonsskala.

Hvor det forrige systemet kom til kort

Vi vedlikeholdt vår egen fork for å tilpasse motoren til den voksende indeksen vår, men å løse viktige begrensninger krevde i økende grad redesign av store deler av plattformen. Flere begrensninger viste seg vanskelige å løse uten grunnleggende arkitekturendringer:

1. Skaleringskostnader. Både antall dokumenter vi lagrer, og mengden data per dokument vi trenger å hente og rangere, har vokst over tid. Denne skaleringen satte press på maskinvaren vår, spesielt mengden tilgjengelig RAM. For å kontrollere kostnader trengte vi mer kompakte datarepresentasjoner og finere kontroll over hva som forblir i minnet, og hva som leses fra disk ved behov.

2. Dårlig hale-latens. På produksjonstrafikk var det gamle systemets p99-responstid omtrent 800 ms. Datasettet oversteg tilgjengelig RAM, så vi kunne ikke bruke mlock til å holde det utelukkende i minnet. Tilgang til ikke-resident data kunne utløse store sidefeil, noe som stanset spørringsutførelsen mens operativsystemet leste fra disk.

Motoren samlet også periodisk hoveddiskindeksen sin med mindre indekser spylt fra minne. Under denne diskindeksfusjonsprosessen steg antall sidefeil enda mer, med p99-latens som nådde omtrent 1,2 s i 10–15 minutter. Ettersom mellomlagrene varmet seg opp, sank både frekvensen av sidefeil og latens, noe som tyder på at kalde leser var en vesentlig bidragsyter til toppene. Forhåndslasting av data og oppvarming av indeksen reduserte toppene, men løste ikke den høye hale-latensen tilstrekkelig.

3. Langvarig gjenoppretting og synkronisering. I det forrige systemet kunne det ta mer enn en uke å distribuere en ekstra klynge og synkronisere dataene dens. Synkronisering var også nødvendig når man la til grupper av noder for å holde flere datakopier eller gjenopprette fra nodefeil. Under gjenoppretting var en større andel av søkeresponsene delvis, noe som senket kvalitetspoengsummene for endelige svar.

Til syvende og sist konkluderte vi med at det ville være enklere og billigere å bygge fra bunnen av i stedet for å fortsette å tilpasse og vedlikeholde forken vår. Med utgangspunkt i erfaringene våre med å drifte det forrige systemet, jobbet et lite ingeniørteam sammen med en sverm av vedvarende kodeagenter for å bygge Photon.

Hvor Photon passer inn i søkestakken

Photon er designet for to primære arbeidsflyter: å betjene søkeforespørsler og hente inn oppdateringer fra behandlingspipelinen.

En forespørsel fra søketjenesten på høyere nivå når Photon-megleren gjennom en lastebalanserer. Megleren velger en shard-gruppe og videresender forespørselen til hver shard, overvåker tidsavbrudd og utsteder ytterligere forespørsler ved behov.

Hver shard utfører henting, første trinns rangering og andre trinns rangering, og returnerer deretter de beste kandidatene til megleren. Megleren kombinerer disse kandidatene til en enkelt rangert liste og henter nøkkeldokumentfelter for de utvalgte sidene fra de relevante shardene. Den returnerer deretter disse resultatene til søketjenesten på høyere nivå, som samler innholdet på siden som agenten trenger for å generere et jordet svar.

Indeksoppdateringer følger en separat bane. Pillar, publiseringslaget vårt, klargjør dataene og lagrer dem i YTsaurus-tabeller. Indekserere konverterer disse tabellene til indeksstrukturer som sharder kan laste inn for søk. Kontrolleren koordinerer dataklargjøring, indeksbygging og distribusjon av nye indeksversjoner til tjenestegrupper. Før de håndterer live trafikk, spiller hver shard av reelle søkespørringer for å varme opp mellomlagrene sine.

Forstørr

Designe Photon for arbeidsflytene våre

Tre designvalg gjør at Photon passer godt til arbeidsbelastningen vår: kompakte datarepresentasjoner, mellomlagring og asynkrone disklesinger, og separering av indeksoppdateringer fra spørringstjenesten.

Datarepresentasjoner for henting og rangering

Henting og rangering får tilgang til dokumentdata på forskjellige måter. Leksikalsk henting starter med spørringstermer og finner dokumenter som inneholder dem. Rangering trenger deretter detaljert informasjon om hvert utvalgte dokument, inkludert termfrekvenser og posisjoner.

Photon bruker to utfyllende representasjoner for å støtte disse tilgangsmønstrene. En invertert indeks lagrer en liste over matchende dokumenter for hver term, kalt en postliste, for å støtte kandidatutvelgelse. Separate poster per dokument gir dataene som trengs for rangering. Vi optimerer også hvordan postlister lagres og traverseres for å forbedre utvelgelsen innenfor et fast arbeidsbudsjett.

Spesialisearte datarepresentasjoner gjør det mulig for oss å lagre nøkkeldata mer effektivt. En mer kompakt invertert indeks reduserer datamengden som leses eller flyttes per spørring, noe som forbedrer latensen ved å eliminere unødvendige I/O-operasjoner. Disse formatene gjør det også mulig å sjekke om et dokument vises i en liste uten å dekode det fullstendig, en egenskap traverseringslogikken vår er avhengig av for å kontrollere hvor mye arbeid en spørring utfører under et fast budsjett. Optimalisering av poster per dokument lar oss lagre mer data per dokument for rangering, samtidig som det reduserer skaleringskostnadene knyttet til det forrige systemet.

Den inverterte indeksen

For hver term lagrer den inverterte indeksen en postliste. Disse listene kan variere fra en håndfull dokumenter til millioner, så ingen enkelt format fungerer bra for hver liste. Photon velger formatet basert på antall dokumenter som inneholder termen.

Korte lister bruker en innebygd representasjon som får plass på én enkelt side og ikke krever noen blokktabell. Lengre lister som ikke får plass i det innebygde formatet, deles inn i blokker som dekker faste områder med dokumentidentifikatorer. Hver blokks representasjon avhenger av tettheten: sparsomme blokker lagrer sorterte matriser med dokument-ID-forskyvninger, mens tette blokker bruker bitkart. Sparsomme blokker bruker galopperende søk, som beveger seg frem i stadig større trinn for å hoppe over områder i listen. Tette blokker tillater medlemssjekker ved å slå opp bitten som tilsvarer et dokument.

En terms spørringsfrekvens avgjør hvor postlisten dens plasseres på disk. Ofte forespurte lister lagres nær hverandre, slik at varme data konsentreres i et mindre lagringsområde. Innenfor hver liste er dokumenter ordnet etter et separat nyttighetssignal slik at mer lovende kandidater møtes tidligere.

Forstørr

Traversering av lister innenfor et arbeidsbudsjett

Kandidatutvelgelse krever traversering av postlister for å finne potensielt relevante dokumenter. Å skanne hver eneste liste uttømmende er dyrt, så Photon bruker en WAND-lignende algorisme som bare traverserer noen lister samtidig som den tar hensyn til treff i de andre.

Algoritmen deler lister inn i to grupper. Kjørelister fremmer traverseringen og foreslår kandidatdokumenter. Probelister bidrar til poengsummene til disse kandidatene, men genererer ikke kandidater selv.

Kandidatpoengsum kombinerer vektet spørringstermdekning og et frekvensbidrag, med dokumentlengdenormalisering og et tak på gevinster fra gjentatte termer. Photon sjekker først termforekomst i matrisene og bitkartene for å begrense hver kandidats maksimale mulige poengsum. Den leser nøyaktige termfrekvenser bare for kandidater som fremdeles kan oppfylle valgterskelen.

Valget foregår deretter i tre trinn:

• Traversering: Start med et strengt krav til spørringsdekning. Hvis for få kandidater blir funnet, gjenta med et avslappet krav.
• Oppbevaring: Kandidater holdes i et begrenset sett ved hjelp av en poengsum som kombinerer dekning og frekvens. Etter hvert som de samlede toppkandidatene blir bedre, stiger opptaksterskelen.
• Endelig valg: Endelig resultat for passet velges fra det beholdte settet basert på frekvenspoengsummene. Hvert felt kjører sitt eget pass, og resultatene slås sammen ved hjelp av feltvekter.

Algoritmen produserer et kandidatsett med relevante dokumenter som skal brukes i videre rangering.

Forstørr

Docblob

Etter at kandidatsider er valgt ut, trenger rangeringsfasen termfrekvenser, feltdekning og plasseringer og nærhet til forekomster. Å skaffe disse dataene gjennom den inverterte indeksen ville kreve spredt tilgang på tvers av mange term-dokument-par. I Photon lagrer vi en kompakt post per dokument som kalles docblob, og som inneholder termfrekvenser, hvilke felter en term dukket opp i, og hvor i dokumentet den forekom. Som et resultat krever rangering av en kandidat bare ett oppslag per dokument.

Formatet er bygget for å unngå å dekode mer enn nødvendig. Inne i en docblob er felter gruppert etter tekstanalysator. Hver gruppe lagrer en sortert termliste kodet med Elias-Fano, slik at en spørringsterm kan slås opp direkte uten å utvide hele listen først. En feltmaske markerer hvor en term forekom, en frekvenseller sporer hvor ofte, og faktiske posisjoner ligger i separate blokker per term-felt-par kodet som posisjonsforskjeller. Bare blokkene for termer som faktisk matchet, blir dekodede, mens alt annet i posten forblir i det komprimerte formatet.

Denne selektive dekodingen gjør at docblob støtter lagring av mer data per dokument uten proporsjonal kostnadsøkning. Å øke posten tvinger ikke frem mer arbeid per oppslag, fordi rangering bare berører delene som er relevante for de matchede termene i stedet for hele posten.

Forstørr

Satsvise lesinger og arbeid med minne

Selv med de mer effisiente datarepresentasjonene går RAM tom før andre ressurser, slik at vi ofte trenger tilgang til data lagret på disk. Photon bruker asynkrone disklesinger og et mellomlager optimert for satsvise lesinger for å få fart på disse tilgangene, og kutter ventetiden per forespørsel. Dette bidrar til en betydelig forbedring i hale-latens sammenlignet med det forrige systemet.

Forstørr

Overlappende diskventetider

Rangering krever innhenting av funksjonene til hundre dokumenter som befinner seg i forskjellige deler av en fil. Det forrige systemet vårt brukte mmap til å tilordne filen til virtuell adresseplass slik at den kunne leses gjennom minnepekere. Å få tilgang til en side som ikke fantes i minnet, krevde imidlertid fremdeles en disklesing. Tråden måtte vente på dataene før den fortsatte beregningen, og denne ventetiden hopet seg opp når prosessen trengte å lese kalde poster sekvensielt.

Photon utnytter det faktum at postforskyvninger er kjent på forhånd, slik at vi kan sende inn flere lesinger samtidig. Dette styres av reaktoren: dedikerte arbeidstråder sender inn serier gjennom io_uring og sender dataene de leser videre til koden som kaller den. Hver tråd vedlikeholder sin egen io_uring; serier sendes til reaktoren med minst belastning. Forhåndsregistrerte fildekontekster og bufferpooler reduserer overheaden ved gjentatte lesinger. Denne asynkrone utførelsen gjør at ventetider for flere operasjoner overlapper, noe som reduserer hale-latens.

Redusere antall stasjonstilganger

Før innsending av lesinger sjekker Photon hele batchen i minnemellomlageret. Bare forespørsler etter manglende poster går til disk; dataene som leses fyller deretter opp mellomlageret.

Mellomlageret er designet for satsvise lesinger. Nærmere bestemt:

• Det er ingen egen tildeling ved et treff. I stedet kopieres data til en buffer som koden som kaller den, har klargjort på forhånd.
• Det er ingen låsinnhenting av leseren. I stedet sjekker den dataversjonen og prøver på nytt hvis den er i konflikt med en skriving.
• Den bruker CLOCK-fjernelse i stedet for å kreve oppdateringer til en delt LRU-liste ved hver lesing.
• Den bruker hurtigminne-pre-fetching, der metadata og data for kommende poster forespørres på forhånd.

Disse optimaliseringene reduserer latensen uten å skade ytelsen på arbeidsbelastningene vi bryr oss om.

Bygge og oppdatere indeksen separat fra betjening

I Photon kjører indeksbygging og spørringstjeneste på forskjellige noder. Indekserere transformerer data til klargjorte lagringsstrukturer, mens tjenestenoder leser dem og utfører henting og rangering. Som et resultat konkurrerer ikke indeksbygging med søkespørringer om CPU, og ressurser for disse oppgavene kan skaleres uavhengig.

Denne separasjonen adresserer flaskehalsene for gjenoppretting og synkronisering som var tilstede i den forrige implementeringen. Fordi indeksbygging kjørte inne i den samme klyngen som betjente spørringer, kunne gjenoppretting av en feilet node eller tillegg av en ny kopi av dataene bety reindeksering av dokumenter på stedet, en prosess som tok dager og økte delvis respons under gjenoppretting. Photon fjerner denne koblingen; indekserere kjører som distribuerte jobber som produserer versjonerte, klargjorte indeksstrukturer uavhengig av tjenestenodene, slik at bygging av den neste versjonen av indeksen ikke lenger konkurrerer med live trafikk.

Forstørr

Klargjøring og distribuert bygging

En bygging starter med å velge dokumenter for den aktive indeksen og produsere kildeeksporten. Kontrolleren registrerer kildeversjonen, inngangstabellene og forventet antall sharder. MapReduce-jobber i YTsaurus klargjør tekst, metadata, fragmenter, funksjoner og prekomputerte innbygginger i versjonerte tabeller partisjonert etter shard. Hver indekserer strømmer den klargjorte tabellen, bygger strukturene for sharden sin og slår sammen tekstdeler. Den klare indeksen, sammen med en beskrivelse av komponentene, lastes opp til objektlagring.

Shard-antall og antall samtidig kjørende indekserere konfigureres uavhengig, slik at en bygging kan kjøre i flere bølger, eller flere maskiner kan tildeles til å arbeide parallelt. Distribuert klargjøring og parallelle indekserere gjør at hele webindeksen kan bygges på et ensifret antall timer, en betydelig forbedring i forhold til det forrige systemet.

Distribuere en ny versjon

Før distribusjon sjekker kontrolleren at den nye indeksen er klar. Hvis dataene er ufullstendige, blokkeres distribusjonen automatisk.

Når det er flere tjenestegrupper, oppdaterer kontrolleren dem én om gangen. Den fjerner først en gruppe fra meglerroutingen og starter den på den nye indeksversjonen. Før de betjener forespørsler, går shardene gjennom et separat oppvarmingsstadium basert på søkelogger, som forhåndsutfyller den opprinnelige tilstanden og gjør overgangen til ekte trafikk jevnere. Etter oppvarming sjekker kontrolleren indekstilstanden og klarheten, og returnerer deretter gruppen til routing. De andre gruppene fortsetter å betjene forespørsler i løpet av denne tiden. Fordi driftstilstanden er vedvarende, tvinger ikke en omstart en bygging til å starte på nytt; kontrolleren kan koble til klargjøring som allerede pågår, gjenbruke et klart resultat eller fortsette en avbrutt rotasjon fra det lagrede trinnet.

Dataoppdateringstider varierer på tvers av søkevertikaler. For vertikaler med høye ferskningskrav tar dokumentlevering et ensifret antall minutter. En ekstra kopi av dataene kan distribueres på omtrent en halvtime; klare indekser lastes inn og kobles til sharder uten å indekse kildedokumentene på nytt.

Forstørr

Migrering og validering i søkestakken vår

Vårt første mål var å erstatte det gamle systemet med en motor som bevarte funksjonalitet og søkekvalitet samtidig som responstidene ble redusert. Vi validerte Photon i trinn, med start i reproduserbare lastetester og offline-kvalitetsevalueringer før vi gikk over til live trafikk. Photon driver nå henting og rangering i produksjonssøkestakken vår, med vesentlig lavere responstider enn det gamle systemet.

Lastetesting og evalueringer

For ytelsestesting bygget vi et lastetestverktøy som spiller av forespørsler fra søkeloggene våre med konfigurerbare ankomstrater. Det sammenligner resultater på tvers av kjøringer og bruker statistiske tester for å vurdere om observerte ytelsesforskjeller er konsistente. Separat evaluerte vi Photon og det gamle systemet på de samme datasettene i våre interne offline-evalueringssystemer for å sjekke for kvalitetsregresjoner.

Etter disse sjekkene sendte vi levende spørringer til begge motorene samtidig ved hjelp av skyggetrafikk. Dette gjorde det mulig for oss å sammenligne ytelsen og resultatene deres på produksjonsarbeidsbelastninger før vi endret hvilken motor som betjente brukere. Vi aktiverte deretter Photon for små undergrupper av brukere og utvidet utrullingen gradvis, mens vi overvåket kvalitet og ytelse underveis. Den første versjonen bestod godkjenningstesting uten kvalitetsregresjoner, og vi fortsatte utrullingen til Photon betjente all produksjonstrafikk.

Målte forbedringer i produksjon

I produksjonsarbeidsflyten vår falt p99-responstiden fra omtrent 800 ms i det gamle systemet til omtrent 65 ms i Photon. Denne målingen dekker alle stadier inne i Photon, men utelukker etterfølgende stadier i søkestakken på høyere nivå. Vi observerer heller ikke lenger lattoppene som tidligere var knyttet til bytte av indeksversjoner.

Photon bruker omtrent 20 % færre ekvivalente tjenestemaskiner enn det gamle systemets innholdsnoder, samtidig som den lagrer omtrent 2,5 ganger så mye data per dokument. Etter migreringen brukte vi disse ekstra dataene til å forbedre rangeringskvaliteten utover det gamle systemets.

Photon reduserer også mengden data som må ligge i minnet. Å feste det samme Photon-datasettet i RAM med mlock ville krevd anslagsvis 4,6 ganger så mye resident minne som Photon bruker for øyeblikket.

Evaluering av den raske søke-API-forhåndsinnstillingen

Vi brukte også Photon som grunnlag for en ny hurtigforhåndsinnstilling for søke-API-et vårt, designet for latenssensitiv arbeidsbelastning. Ifølge målingene våre er enkelt søkeforespørsel-latens for hurtigforhåndsinnstillingen 160 ms ved p50 og 230 ms ved p95, lavere enn eller sammenlignbar med andre søke-API-leverandørers selvrapporterte tall, selv om de rapporterte hale-persentilene avviker.

Vi evaluerte hurtigforhåndsinnstillingen på seks agentbaserte benchmarks: WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0 og SEAL-Hard. På tvers av disse evalueringene hadde den den laveste anslåtte totale modell-plus-søk-kostnaden og den høyeste samlede oppgavepoengsummen blant de testede konfigurasjonene.

Hurtigforhåndsinnstillingen parer Photon med rangering optimert for agentbaserte arbeidsflyter, og leverer sammenlignbar ytelse til standardforhåndsinnstillingen til betydelig lavere kostnad. Den kommer imidlertid med et kompromiss i bredere søkekvalitet. Hurtigforhåndsinnstillingen bruker mindre beregning til rangering enn standardforhåndsinnstillingen. På interne benchmarks som dekker langhaleforespørsler, bred dekning og resultatmangfold, scorer den 0,24 poeng lavere på relevans og omtrent 3 prosentpoeng lavere på svarets tilgjengelighet. Vi mener dette er et fornuftig kompromiss for agentbaserte arbeidsflyter, da modellens egen resonnering og kunnskap kan bidra til å kompensere for forskjellen.

Forstørr

Vi anbefaler hurtigforhåndsinnstillingen for daglige agentbaserte oppgaver. For mer krevende eller tvetydige spørsmål som er mindre tidssensitive, tilbyr standardforhåndsinnstillingen mer robust kvalitet, noe som rettferdiggjør den høyere latensen og kostnaden.

Konklusjon

Vi flytter jevn og trutt søkestakken vår over på Rust-basert, egenutviklet infrastruktur. Å erstatte open source-motoren med Photon, vår tilpassede hentings- og rangeringsmotor, er det siste steget. Photon gir oss full kontroll over datarepresentasjoner, hvordan leser organiseres, og hvordan nye indekser distribueres, slik at vi kan optimalisere hvert lag for arbeidsbelastningene våre.

Photon har muliggjort raskere søk på tvers av Perplexitys produkter og gir fundamentet for vår nye hurtigforhåndsinnstilling i søke-API-et. Etter migreringen falt p99-hentings- og rangeringslatensen fra ca. 800 ms til 65 ms. De kompakte dataformatene våre lar oss også lagre 2,5 ganger så mye data per dokument, noe som gir henting og rangering tilgang til rikere dokumentinformasjon.

Hurtigforhåndsinnstillingen gir en enkelt søkeforespørsel-latens på 160 ms ved p50 og 230 ms ved p95. På de seks evaluerte agentbaserte ytelsestestene reduserte den anslått modell-plus-søk-kostnad per oppgave med 68 % sammenlignet med standardforhåndsinnstillingen, samtidig som den opprettholdt sammenlignbar samlet oppgvekvalitet. Disse resultatene demonstrerer de praktiske fordelene med infrastruktur designet rundt søkearbeidsbelastningene våre, både for Perplexitys produkter og for utviklere som bygger med API-et vårt.

Vi fortsetter å forbedre Photons ytelse og lagringseffektivitet. Målet vårt er å støtte en større indeks og rikere dokumentdata på den samme maskinvaren, samtidig som søket holdes raskt etter hvert som arbeidsbelastningen vår vokser.

Sitat

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