Photon: hankimis- ja järjestusmootori ehitamine nullist

Sissejuhatus

Perplexity AI-põhine otsingupinu hangib ja järjestab kandidaatlehti, tuues esile asjakohasema sisu, millel mudel saab oma vastuseid maandada. Algselt töötas see etapp avatud lähtekoodiga mootoril, mida kohandasime oma süsteemi jaoks. Kuid meie indeksi ja töökoormuste kasvades jõudsime kulude, pika sabaga latentsuse ja sõlme taastamisaja rangete piirideni, mida me ei saanud olemasoleval kolmanda osapoole platvormil lahendada.

Nende väljakutsete ületamiseks ehitasime Photoni, uue sisemise hankimis- ja järjestusmootori. See jätkab meie lähenemist AI-esimese otsinguinfrastruktuuri ehitamisele nullist, nagu tegime CobbleDB-ga, mis on meie hajutatud võti-väärtus pood leheküljekirjete teenindamiseks, ja meie Search API-ga.

Photon kasutab kompaktseid andmevorminguid, et lugeda ja dekodeerida ainult seda, mida iga päring vajab, kasutades partiiteadlikku vahemällu salvestamist ja asünkroonseid lugemisi, et vähendada ketasjuurdepääsu ja kattuvusi ooteaegades. Indeksi koostamine toimub päringute teenindamisest eraldi, uuendades ühte teenindusrühma korraga ja soojendades selle vahemälusid enne reaalajas päringute suunamist.

Photon toidab nüüd meie otsingutoru ja on ka meie otsingu API uue kiire eelseadistuse aluseks, mille ühe otsingupäringu latentsus on 160 ms p50 juures ja 230 ms p95 juures. Kuue avaliku võrdlusaluse lõikes vähendas kiire eelseadistus hinnangulist mudeli ja otsingu kogukulu ülesande kohta 68%, säilitades samal ajal vaike-eelseadistusega võrreldava koondülesande kvaliteedi. Avaldame selle täna, et arendajad saaksid neile parandustele juurdepääsu.

Suurenda

Suurenda

Mida hankimis- ja järjestusmootor nõuab

Iga päringu jaoks otsib hankimis- ja järjestusmootor suurest hajutatud indeksist, et valida ja järjestada otsingupinu latentsuseelarve piires väike hulk asjakohaseid lehti. Süsteem peab hoidma ka indeksi ajakohasena uute lehtede saabumisel ja olemasolevate muutumisel, laskmata sellel tööl reaalajas päringuid aeglustada.

Hindasime mitut avatud lähtekoodiga valikut ja valisime küpse, üldotstarbelise hankimis- ja järjestusmootori, mis vastas meie esialgsetele vajadustele. Seejärel kohandasime selle oma arhitektuuri ja töökoormustega, säilitades tootmismastaabis stabiilse latentsuse ja läbilaskevõime.

Kus meie eelmine süsteem jäi lühikeseks

Hoidsime oma hargnemist, et kohandada mootorit kasvava indeksiga, kuid peamiste piirangute lahendamine nõudis üha enam platvormi suurte osade ümberkujundamist. Mitmed kitsaskohad osutusid raskesti lahendatavateks ilma fundamentaalsete arhitektuuriliste muudatusteta:

1. Skaleerimiskulud. Nii salvestatavate dokumentide arv kui ka hangitavate ja järjestatavate dokumendipõhiste andmete hulk on aja jooksul kasvanud. See skaleerimine avaldas survet meie riistvarale, eriti saadaoleva RAM-i mahule. Kulude kontrolli all hoidmiseks vajasime kompaktsemaid andmeesitusi ja täpsemat kontrolli selle üle, mis jääb mällu ja mida loetakse nõudmisel kettalt.

2. Halb pika sabaga latentsus. Tootmisliikluses oli vana süsteemi p99 reageerimisaeg umbes 800 ms. Andmestik ületas saadaoleva RAM-i, seega ei saanud me mlock abil seda täielikult mälus hoida. Residendiks mittekasutuvatele andmetele juurdepääs võis esile kutsuda suuri leheküljetõrkeid, peatades päringu täitmise, samal ajal kui operatsioonisüsteem luges kettalt.

Mootor ühendas perioodiliselt ka oma peamise kettaindeksi mälust loputatud väiksemate indeksitega. Selle kettaindeksi liitmise protsessi käigus tõusis leheküljetõrgete arv veelgi, p99 latentsuse ulatudes 10–15 minuti jooksul ligikaudu 1,2 sekundini. Vahemälude soojenemisel leheküljetõrgete sagedus ja latentsus mõlemad vähenesid, viidates sellele, et külmad lugemised olid tippude peamiseks panustajaks. Andmete eellaadimine ja indeksi soojendamine vähendasid tippe, kuid ei lahendanud piisavalt suurt pika sabaga latentsust.

3. Pikk taastumine ja sünkroniseerimine. Eelmises süsteemis võis täiendava klastri juurutamine ja selle andmete sünkroniseerimine võtta rohkem kui nädala. Sünkroniseerimine oli vajalik ka sõlmerühmade lisamisel täiendavate andmekoopiate hoidmiseks või sõlme rikete taastamisel. Taastamise ajal oli suurem osa otsinguvastustest osalised, mis langetas lõpliku vastuse kvaliteediskoore.

Lõpuks jõudsime järeldusele, et lihtsam ja odavam on ehitada nullist, selle asemel et jätkata oma hargnemiise kohandamist ja hooldamist. Toetudes varasema süsteemi käitamise kogemusele, töötas väike insenerimeeskond koos püsivate kodeerimisagentide parvega Photoni ehitamise nimel.

Kus Photon otsingupinu struktuuris paikneb

Photon on loodud kahe esmase töövoo jaoks: otsingupäringute teenindamine ja värskenduste vastuvõtmine töötlemistorust.

Kõrgema taseme otsinguteenuse päring jõuab koormusjaoturi kaudu Photoni maaklerini. Maakler valib shardide rühma ja edastab päringu igale shardile, jälgides ajalõppe ja väljastades vajadusel täiendavaid päringuid.

Iga shard teostab hankimise, esialgse järjestamise ja teise etapi järjestamise ning tagastab seejärel oma parimad kandidaadid maaklerile. Maakler ühendab need kandidaadid üheks järjestatud loendiks ja hangib asjakohastelt shardidelt valitud lehtede jaoks olulised dokumendiväljad. Seejärel tagastab see need tulemused kõrgema taseme otsinguteenusele, mis kogub agendile maandatud vastuse genereerimiseks vajaliku lehesisu.

Indeksi värskendused järgivad eraldi teed. Meie avaldamiskiht Pillar valmistab andmed ette ja salvestab need YTsauruse tabelitesse. Indekseerijad teisendavad need tabelid indeksstruktuurideks, mida shardid saavad otsinguks laadida. Kontroller koordineerib andmete ettevalmistamist, indeksi ehitamist ja uute indeksiversioonide juurutamist teenindusrühmadesse. Enne reaalajas liikluse käsitlemist esitab iga shard oma vahemike soojendamiseks uuesti tegelikud otsingupäringud.

Suurenda

Photoni kujundamine meie töövoogude jaoks

Kolm disainivalikut teevad Photonist meie töövoole hästi sobiva: kompaktsed andmeesitused, vahemällu salvestamine ja asünkroonsed kettalugemised ning indeksi värskenduste eraldamine päringute teenindamisest.

Andmete esitused hankimiseks ja järjestamiseks

Hankimine ja järjestamine pääsevad dokumendiandmetele ligi erinevalt. Leksikaalne hankimine algab päringutermidest ja leiab neid sisaldavad dokumendid. Järjestamine vajab seejärel üksikasjalikku teavet iga valitud dokumendi kohta, sealhulgas termide sagedusi ja positsioone.

Photon kasutab nende juurdepääsumustrite toetamiseks kahte täiendavat esitust. Pööratud indeks salvestab kandidaatide valiku toetamiseks iga termi jaoks sobivate dokumentide loendi, mida nimetatakse postitamisloendiks. Eraldi dokumendipõhised kirjed pakuvad järjestamiseks vajalikke andmeid. Optimeerime ka postitamisloendite salvestamist ja läbimist, et parandada valikut fikseeritud tööeelarve piires.

Spetsiaalsed andmete esitused võimaldavad meil võtmeandmeid tõhusamalt salvestada. Kompaktsem pööratud indeks vähendab päringu kohta loetud või liigutatud andmete hulka, parandades latentsust tarbetute I/O toimingute kõrvaldamise kaudu. Need vormingud võimaldavad ka kontrollida, kas dokument ilmub loendis ilma seda täielikult dekodeerimata – omadus, millele meie läbikäigu loogika tugineb, et juhtida päringu tehtava töö mahtu fikseeritud eelarve piires. Dokumendipõhiste kirjete optimeerimine võimaldab meil salvestada rohkem andmeid dokumendi kohta järjestamiseks, vähendades samal ajal meie eelmise süsteemiga seotud skaleerimiskulusid.

Pööratud indeks

Iga termi jaoks salvestab pööratud indeks postitamisloendi. Need loendid võivad ulatuda käputäiest dokumentidest miljoniteni, nii et ükski vorming ei toimi iga loendi puhul hästi. Photon valib vormingu dokumenti sisaldavate dokumentide arvu põhjal.

Lühikesed loendid kasutavad sisemist esitust, mis mahub ühele lehele ega vaja plokitabelit. Pikemad loendid, mis sisemisse vormingusse ei mahu, jagatakse plokkideks, mis hõlmavad dokumentide identifikaatorite fikseeritud vahemikke. Iga ploki esitus sõltub selle tihedusest: hõredad plokid salvestavad dokumentide ID nihete sorteeritud massiivid, tihedad plokid aga bitikaarte. Hõredad plokid kasutavad galoppivat otsingut, mis liigub üha suuremate sammudega, et loendi piirkondi vahele jätta. Tihedad plokid võimaldavad liikmesuse kontrolli dokumendile vastava biti otsimise teel.

Termi päringusagedus määrab, kuhu selle postitamisloend kettal paigutatakse. Sageli päritud loendid salvestatakse üksteise lähedale, koondades kuumad andmed väiksemasse salvestuspiirkonda. Igas loendis on dokumendid järjestatud eraldi kasulikkuse signaali alusel, nii et lootustandvamad kandidaadid leitakse varem.

Suurenda

Loendite läbimine tööeelarve piires

Kandidaatide valik nõuab postitamisloendite läbimist, et leida potentsiaalselt asjakohaseid dokumente. Iga loendi ammendav skannimine on kallis, seega kasutab Photon WAND-i sarnast algoritm, mis läbib ainult mõnda loendit, võttes samal ajal arvesse vasteid teistes.

Algoritm jagab loendid kahte rühma. Juhtivad loendid viivad läbikäiku edasi ja pakuvad kandidaatdokumente. Sondiloendid aitavad kaasa nende kandidaatide skooridele, kuid ei genereeri kandidaate ise.

Kandidaatide hindamine kombineerib kaalutud päringutermi katvuse ja sageduse panuse koos dokumendi pikkuse normaliseerimise ja korduvatest termidest saadava kasu ülempiiriga. Photon kontrollib esmalt termide olemasolu massiivides ja bitikaartides, et piirata iga kandidaadi maksimaalset võimalikku skoori. See loeb täpsed termide sagedused ainult nende kandidaatide jaoks, kes võivad endiselt täita valikuläve.

Valik jätkub seejärel kolmes etapis:

• Läbikäik: Alustage range päringu katvuse nõudega. Kui leitakse liiga vähe kandidaate, korrake leebema nõudega.
• Säilitamine: Kandidaate hoitakse piiratud hulgas skoori abil, mis kombineerib katvuse ja sageduse. Kogutud parimate kandidaatide paranedes vastuvõtulävi tõuseb.
• Lõplik valik: Vooru lõplikud tulemused valitakse säilitatud hulgast sagedusskooride põhjal. Iga väli käivitab oma vooru ja tulemused ühendatakse väljade kaalude abil.

Algoritm genereerib täiendavaks järjestamiseks kasutatava asjakohaste dokumentide kandidaatide hulga.

Suurenda

Docblob

Pärast kandidaatlehtede valimist vajab järjestamisfaas termide sagedusi, väljade katvust ning esinemiste asukohti ja lähedust. Selle andme saamine pööratud indeksi kaudu nõuaks hajutatud juurdepääsu paljudele termi-dokumendi paaridele. Photonil salvestame kompaktse dokumendipõhise kirje nimega docblob, mis sisaldab termide sagedusi, väljasid, kus term ilmus, ja seda, kus dokumendis see esines. Selle tulemusena nõuab kandidaadi järjestamine ainult ühte otsingut dokumendi kohta.

Vorming on ehitatud nii, et vältida tarbetut dekodeerimist. Docblobi sees on väljad rühmitatud tekstianalüsaatori järgi. Iga rühm salvestab Elias-Fanoga kodeeritud sorteeritud termide loendi, nii et päringutermi saab otse otsida ilma kogu loendit esmalt laiendamata. Väljamask märgib, kus term esines, sagedusloend jälgib kui tihti ja tegelikud positsioonid asuvad eraldi plokkides termi-välja paari kohta, mis on kodeeritud positsiooni erinevustena. Dekodeeritakse ainult nende termide plokid, mis tegelikult vastendasid, samas kui kõik muu kirjes püsib tihendatud vormingus.

See valikuline dekodeerimine võimaldab docblobil toetada suurema andmemahu salvestamist dokumendi kohta ilma proportsionaalse kulude kasvuta. Kirje suurendamine ei sunni tegema rohkem tööd otsingu kohta, sest järjestamine puudutab alati ainult vastendatud termidega seotud osi, mitte tervet kirjet.

Suurenda

Partiidena lugemine ja mäluga töötamine

Isegi tõhusamate andmeesituste korral saab RAM enne muid ressursse otsa, seega peame sageli juurde pääsema kettale salvestatud andmetele. Photon kasutab nende juurdepääsude kiirendamiseks asünkroonseid kettalugemisi ja partiidena lugemiseks optimeeritud vahemälu, vähendades päringupõhist ooteaega. See aitab kaasa pika sabaga latentsuse märkimisväärsele paranemisele võrreldes eelmise süsteemiga.

Suurenda

Kattuvad ketta ooteajad

Järjestamine nõuab faili erinevates osades asuvate saja dokumendi funktsioonide hankimist. Meie eelmine süsteem kasutas mmap-i faili vastendamiseks virtuaalsesse aadressiruumi, et seda saaks lugeda mälupunktide kaudu. Siiski nõudis mälust puuduva lehe poole pöördumine ikkagi kettalt lugemist. Lõim pidi enne arvutuse jätkamist andmeid ootama ja see ooteaeg kuhjus, kui protsess pidi külmi kirjeid järjestikku lugema.

Photon kasutab ära asjaolu, et kirje nihked on eelnevalt teada, mistõttu saame esitada mitu lugemistaotlust korraga. Seda haldab reaktor: spetsiaalsed töölõimed esitavad partiisid io_uring kaudu ja edastavad loetud andmed kutsuvale koodile. Iga lõim haldab oma io_uring instantsi; partiid saadetakse kõige vähem koormatud reaktorile. Eelregistreeritud failideskirjeldid ja puhvrikogumid vähendavad korduvate lugemiste lisakoormust. See asünkroonne täitmine võimaldab mitme operatsiooni ooteaegadel kattuda, vähendades pika sabaga latentsust.

Draivile juurdepääsude arvu vähendamine

Enne lugemiste esitamist kontrollib Photon kogu partiid mälus olevas vahemälus. Kettale lähevad ainult puuduvate kirjete taotlused; loetud andmed täidavad seejärel vahemälu.

Vahemälu on loodud partiidena lugemiseks. Täpsemalt:

• Tabamuse korral eraldi eraldamist ei toimu. Selle asemel kopeeritakse andmed kutsuva koodi poolt eelnevalt ettevalmistatud puhvrisse.
• Lugeja ei vii läbi lukkude omandamist. Selle asemel kontrollib see andmete versiooni ja proovib uuesti, kui see on kirjutamisega vastuolus.
• See kasutab CLOCK väljatõrjumist, selle asemel et nõuda värskendusi jagatud LRU loendile igal lugemisel.
• See kasutab CPU vahemälu eellaadimist, kus tulevaste kirjete metaandmed ja andmed nõutakse ette.

Need optimeerimised vähendavad latentsust ilma meie jaoks oluliste töökoormuste jõudlust kahjustamata.

Indeksi ehitamine ja värskendamine teenindamisest eraldi

Photonis toimuvad indeksi ehitamine ja päringute teenindamine erinevatel sõlmedel. Indekseerijad muudavad andmed valmis salvestusstruktuurideks, samal ajal kui teenindavad sõlmed loevad neid ning teostavad hankimise ja järjestamise. Selle tulemusena ei konkureeri indeksi ehitamine otsingupäringutega CPU pärast ja nende ülesannete ressursse saab skaleerida sõltumatult.

See eraldamine lahendab eelmises juurutuses esinenud taastamis- ja sünkroniseerimise pudelikaelad. Kuna indeksi ehitamine toimus päringuid teenindavas klastris endas, võis ebaõnnestunud sõlme taastamine või andmete uue koopia lisamine tähendada dokumentide kohapeal ümberindekseerimist – protsess, mis võttis päevi ja suurendas taastamise ajal osalisi vastuseid. Photon eemaldab selle seose; indekseerijad töötavad hajutatud töödena, mis toodavad versiooniga teenindusvalmis indeksstruktuure teenindavatest sõlmedest sõltumatult, nii et indeksi järgmise versiooni ehitamine ei konkureeri enam reaalajas liiklusega.

Suurenda

Ettevalmistus ja hajutatud ehitamine

Ehitis algab aktiivse indeksi jaoks dokumentide valimise ja lähteekspordi tootmisega. Kontroller salvestab lähteversiooni, sisendtabelid ja eeldatava shardide arvu. YTsauruse MapReduce tööd valmistavad teksti, metaandmed, fragmendid, tunnused ja eelarvutatud manustused shardide kaupa jaotatud versiooniga tabeliteks. Iga indkeerija voogedastab ettevalmistatud tabelit, ehitab oma shardi struktuurid ja ühendab tekstisegmendid. Valmis indeks koos komponentide kirjeldusega laaditakse üles objektisalvestusse.

Shardide arv ja samaaegselt töötavate indekseerijate arv konfigureeritakse sõltumatult, nii et ehitis saab töötada mitmes laines või paralleelselt töötamiseks saab eraldada rohkem masinaid. Hajutatud ettevalmistus ja paralleelsed indekseerijad võimaldavad kogu veebiindeksi ehitada ühekohalise tunniga, mis on märkimisväärne paranemine võrreldes eelmise süsteemiga.

Uue versiooni juurutamine

Enne juurutamist kontrollib kontroller, kas uus indeks on valmis. Kui andmed on puudulikud, blokeeritakse juurutamine automaatselt.

Kui teenindusrühmi on mitu, värskendab kontroller neid ükshaaval. Esmalt eemaldab see rühma maakleri suunamisest ja käivitab selle uuel indeksiversioonil. Enne päringute teenindamist läbivad shardid otsingulogidel põhineva eraldi soojendusetapi, mis eeltäidab algoleku ja teeb ülemineku reaalajas liiklusele sujuvamaks. Pärast soojendamist kontrollib kontroller indeksi olekut ja valmisolekut ning tagastab rühma suunamisele. Teised rühmad jätkavad selle aja jooksul päringute teenindamist. Kuna operatsiooni olek säilitatakse, ei sunni taaskäivitamine ehitist nullist alustama; kontroller saab uuesti ühenduda juba toimuva ettevalmistusega, taaskasutada valmis tulemust või jätkata katkestatud pööramist salvestatud sammust.

Andmete värskendamise ajad on otsinguvertikaalide lõikes erinevad. Suure värskenõudlusega vertikaalide puhul võtab dokumentide edastamine ühekohalise minuti. Andmete täiendava koopia saab juurutada umbes poole tunniga; valmis indeksid laaditakse ja kinnitatakse shardide külge ilma lähtedokumente ümber indekseerimata.

Suurenda

Migratsioon ja valideerimine meie otsingupinus

Meie esimene eesmärk oli asendada vana süsteem mootoriga, mis säilitas funktsionaalsuse ja otsingukvaliteedi, vähendades samal ajal reageerimisaegu. Valideerisime Photoni etappides, alustades reprodutseeritavatest koormustestidest ja võrguühenduseta kvaliteedihinnangutest enne reaalajas liiklusele üleminekut. Photon toidab nüüd hankimist ja järjestamist meie tootmisotsingupinus, märgatavalt madalamate reageerimisaegadega kui vanal süsteemil.

Koormustestid ja hindamised

Jõudluse testimiseks ehitasime koormustestimise tööriista, mis esitab uuesti päringuid meie otsingulogidest konfigureeritavatel saabumissagedustel. See võrdleb tulemusi jooksude vahel ja rakendab statistilisi teste, et hinnata, kas täheldatud jõudluse erinevused on järjepidevad. Eraldi hindasime Photonit ja vana süsteemi samadel andmestikel oma sisemistes võrguühenduseta hindamissüsteemides, et kontrollida kvaliteedi halvenemist.

Pärast neid kontrollimisi saatsime variliikluse abil reaalajas päringud mõlemale mootorile samaaegselt. See võimaldas meil võrrelda nende jõudlust ja tulemusi tootmistöökoormustel enne mootori vahetamist, mis kasutajaid teenindab. Seejärel lubasime Photoni väikeste kasutajaallhulkade jaoks ja laiendasime järk-järgult juurutamist, jälgides kogu protsessi vältel kvaliteeti ja jõudlust. Esimene versioon läbis vastuvõtetestid ilma kvaliteedi halvenemiseta ja jätkasime juurutamist, kuni Photon teenindas kogu tootmisliiklust.

Mõõdetud parandused tootmises

Meie tootmistöövoos langes p99 reageerimisaeg vana süsteemi umbes 800 ms-lt Photonis umbes 65 ms-le. See mõõtmine katab kõik Photoni sisemised etapid, kuid välistab järgnevad etapid kõrgema taseme otsingupinus. Me ei tähelda enam ka varasemate indeksiversioonide vahetamisega seotud latentsuspiike.

Photon kasutab ligikaudu 20% vähem ekvivalente teenindusmasinaid kui vana süsteemi sisusõlmed, salvestades samal ajal ligikaudu 2,5 korda rohkem andmeid dokumendi kohta. Pärast migratsiooni kasutasime neid täiendavaid andmeid järjestamiskvaliteedi parandamiseks üle vana süsteemi taseme.

Photon vähendab ka mällu jääma peavate andmete mahtu. Sama Photon andmestiku kinnitamine RAM-is mlock abil nõuaks hinnanguliselt 4,6 korda rohkem residentmälu, kui Photon praegu kasutab.

Kiire Search API eelseadistuse hindamine

Kasutasime Photoni ka meie uue otsingu API kiire eelseadistuse alusena, mis on loodud latentsustundlike töövoogude jaoks. Meie mõõtmiste kohaselt on kiire eelseadistuse ühe otsingupäringu latentsus 160 ms p50 juures ja 230 ms p95 juures, mis on madalam või võrreldav teiste otsingu API pakkujate iseteatatud numbritega, kuigi teatatud saba protsentiilid erinevad.

Hindasime kiiret eelseadistust kuuel agendipõhisel võrdlusalusel: WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0 ja SEAL-Hard. Nende hinnangute lõikes oli sellel testitud konfiguratsioonidest madalaim hinnanguline mudeli ja otsingu kogukulu ning kõrgeim koondülesande skoor.

Kiire eelseadistus ühendab Photoni agentpõhiste töövoogude jaoks optimeeritud järjestusega, pakkudes võrreldavat jõudlust vaike-eelseadistusega oluliselt madalama hinnaga. Kuid sellega kaasneb kompromiss laiemas otsingukvaliteedis. Kiire eelseadistus kasutab järjestamiseks vähem arvutusressursse kui vaike-eelseadistus. Pika sabaga päringuid, laia katvust ja tulemuste mitmekesisust hõlmavates sisemistes võrdlusuuringutes kogub see asjakohasuse osas 0.24 punkti vähem ja vastuste kättesaadavuse osas umbes 3 protsendipunkti vähem. Usume, et see on agentpõhiste töövoogude jaoks mõistlik kompromiss, kuna mudeli enda arutlus ja teadmised aitavad erinevust kompenseerida.

Suurenda

Soovitame kiiret eelseadistust igapäevasteks agendipõhisteks ülesanneteks. Keerulisemate või ebamlasemate küsimuste jaoks, mis on vähem ajakriitilised, pakub vaike-eelseadistus tugevamat kvaliteeti, õigustades oma suuremat latentsust ja kulusid.

Kokkuvõte

Liigutame oma otsingupinu püsivalt Rust-põhisele sisemisele infrastruktuurile. Avatud lähtekoodiga mootori asendamine Photoniga, meie kohandatud hankimis- ja järjestusmootoriga, on viimane samm. Photon annab meile täieliku kontrolli andmeesituste, lugemiste korraldamise ja uute indeksite juurutamise üle, võimaldades meil optimeerida iga kihti oma töövoogude jaoks.

Photon on võimaldanud kiiremat otsingut Perplexity toodetes ja pakub alust meie uuele kiirele eelseadistusele Search API-s. Pärast migratsiooni langes p99 hankimis- ja järjestuslatentsus ligikaudu 800 ms-lt 65 ms-le. Meie kompaktsed andmevormingud võimaldavad meil salvestada ka 2,5 korda rohkem andmeid dokumendi kohta, andes hankimisele ja järjestamisele juurdepääsu rikkalikumale dokumenditeabele.

Kiire eelseadistus tagab ühe otsingupäringu latentsuseks 160 ms p50 juures ja 230 ms p95 juures. Hinnatud kuue agendipõhise võrdlusaluse lõikes vähendas see hinnangulist mudeli ja otsingu kogukulu ülesande kohta 68% võrreldes vaike-eelseadistusega, säilitades samal ajal võrreldava koondülesande kvaliteedi. Need tulemused demonstreerivad meie otsingutöökoormuste jaoks loodud infrastruktuuri praktilisi eeliseid nii Perplexity toodete kui ka meie API-ga ehitavate arendajate jaoks.

Jätkame Photoni jõudluse ja salvestustõhususe parandamist. Meie eesmärk on toetada samal riistvaral suuremat indeksit ja rikkalikumaid dokumendiandmeid, hoides samal ajal otsingu kiirena meie töökoormuste kasvades.

Tsitaat

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