Photon: Að byggja heimtunar- og röðunarvél frá grunni

Inngangur

Gervigreindarmiðaður leitarstafla Perplexity sækir og raðar frambjóðendasíðum, og birtir viðeigandi efni fyrir líkanið til að byggja svör sín á. Upphaflega keyrði þessi áfangi á opnum grunni sem við löguðum að kerfi okkar.

Til að sigrast á þessum áskorunum byggðum við Photon, nýja innanhúss heimtunar- og röðunarvél. Þetta heldur áfram nálgun okkar við að byggja upp gervigreindarmiðaða leitarinnviði frá grunni, eins og við gerðum með CobbleDB, dreifða lykil-gildi geymslu okkar til að þjóna síðufærslum, og Leitar-API okkar.

Photon notar þétt gögn til að lesa og afkóða aðeins það sem hver fyrirspurn þarfnast, ásamt lotumiðaðri skyndiminni og ósamstilltum lestrum til að draga úr diskiaðgangi og yfirskrifi bíða. Vísitölugerð fer fram aðskilið frá afgreiðslu fyrirspurna, uppfærir einn afgreiðsluhóp í einu og hitar upp skyndiminni hans áður en lifandi fyrirspurnum er beint að honum.

Photon knýr nú leitarpípuna okkar og er einnig grunnurinn að nýrri hraðri stillingu fyrir leitar-API okkar, með eins leitarkalls leynd upp á 160 ms á p50 og 230 ms á p95. Yfir sex opinber viðmið dró hraða stillingin úr áætluðum kostnaði líkans og leitar á hvert verkefni um 68% á meðan heildargæði verkefna voru sambærileg við sjálfgefna stillinguna. Við gefum þetta út í dag svo verktakar geti nálgast þessar endurbætur.

Stækka

Stækka

Hvað heimtunar- og röðunarvélin krefst

Fyrir hverja fyrirspurn leitar heimtunar- og röðunarvélin í stórri, dreifðri vísitölu til að velja og raða litlu safni viðeigandi síðna innan leyndaráætlunar leitarstaflans. Kerfið verður einnig að halda vísitölunni uppfærðri þegar nýjar síður berast og fyrirliggjandi síður breytast, án þess að láta þá vinnu hægja á lifandi fyrirspurnum.

Við mátum nokkra opna valkosti og völdum þroskaða, almenna heimtunar- og röðunarvél sem uppfyllti upphaflegar þarfir okkar. Við löguðum hana síðan að arkitektúr okkar og vinnuálagi, og héldum stöðugri leynd og afköstum í framleiðslustærð.

Hvar fyrra kerfi okkar brást

Við héldum við okkar eigin kvísl til að laga vélina að vaxandi vísitölu okkar, en að takast á við lykilmörk krafðist í auknum mæli endurhönnunar á stórum hlutum pallsins. Nokkrar takmarkanir reyndust erfiðar í lausn án grundvallararkitektúrbreytinga:

Kvarðunarkostnaður. Bæði fjöldi skjala sem við geymum og magn gagna á hvert skjal sem við þurfum að sækja og raða hafa aukist með tímanum. Þessi kvarðun setti þrýsting á vélbúnað okkar, sérstaklega magn tiltæks vinnsluminnis.

2. Lélegur síðtöf. Við framleiðsluumferð var p99 svarsemi gömlu kerfisins um 800 ms. Gagnasafnið fór yfir tiltækt vinnsluminni, þannig að við gátum ekki notað mlock til að halda því öllu í minni. Að nálgast gögn utan minnis gæti komið af stað meiriháttar síðubilunum, sem stöðvaði fyrirspurnaframkvæmd á meðan stýrikerfið las af diski.

Vélin sameinaði einnig aðaldiskavísitölu sína með reglulegu millibili við minni vísitölur skolaðar úr minni. Meðan á þessu diskavísitölusamrunaferli stóð jókst fjöldi síðubilanna enn meira, með p99 leynd sem náði u.þ.b. 1,2 sekúndum í 10–15 mínútur.

3. Langvinn endurheimt og samstilling. Í fyrra kerfi gæti það tekið meira en viku að dreifa viðbótarþyrpingu og samstilla gögn hennar. Samstillingar var einnig krafist þegar bætt var við hópum hnúta til að geyma viðbótargagnaeintök eða endurheimta eftir hnútabilanir.

Að lokum komumst við að þeirri niðurstöðu að það væri einfaldara og ódýrara að smíða frá grunni heldur en að halda áfram að laga og viðhalda kvíslinni okkar. Með hliðsjón af reynslu okkar af rekstri fyrri kerfisins vann lítið verkfræðiteymi með svarm af þrautseigum gervigreindarfulltrúum að því að smíða Photon.

Hvar Photon passar inn í leitarstaflann

Photon er hannað fyrir tvö aðalverkflæði: að þjóna leitarbeiðnum og taka við uppfærslum úr vinnslupípunni.

Beiðni frá leitarþjónustunni á hærra stigi nær til Photon miðlarans í gegnum áhlaðningadreifara. Miðlarinn velur skardhóp og sendir beiðnina áfram á hvert skard, fylgist með tímamörkum og gefur út viðbótarbeiðnir þegar þörf krefur.

Hvert skard framkvæmir heimt, upphaflega röðun og síðari stigs röðun, skilar síðan bestu frambjóðendum sínum til miðlarans. Miðlarinn sameinar þessa frambjóðendur í einn raðaðan lista og sækir lykilskjalareiti fyrir valdar síður úr viðeigandi skörðum.

Vísitöluuppfærslur fylgja aðskildri leið. Pillar, útgáfulag okkar, undirbýr gögnin og geymir þau í YTsaurus töflum. Vísitöluhöfundar breyta þessum töflum í vísitölusamsetningar sem skörð geta hlaðið fyrir leit. Stjórnandinn samræmir gagnaundirbúning, vísitölugerð og dreifingu nýrra vísitöluútgáfa til afgreiðsluhópa.

Stækka

Hönnun Photon fyrir verkflæði okkar

Þrjár hönnunarákvarðanir gera Photon vel til þess fallinn að passa við vinnuálag okkar: samsettar gagnasamsetningar, skyndiminni og ósamstilltir diskalestrar, og aðskilnaður vísitöluuppfærslna frá fyrirspurnarafgreiðslu.

Gagnframsetningar fyrir heimt og röðun

Heimt og röðun nálgast skjalagögn á mismunandi hátt. Leitarheimt byrjar á fyrirspurnarskilmálum og finnur skjöl sem innihalda þau. Röðun þarf síðan nákvæmar upplýsingar um hvert valið skjal, þar á meðal tíðni skilmála og staðsetningar.

Photon notar tvennar samstæðar framsetningar til að styðja þessi aðgangsmynstur. Umhverfisskráð vísitala geymir lista yfir samsvarandi skjöl fyrir hvern skilmála, kallaður skilaboðalisti, til að styðja við valbjóðenda.

Sérhæfðar gagnasamsetningar gera okkur kleift að geyma lykilgögn á skilvirkari hátt. Þéttari umhverfisskráð vísitala dregur úr magni gagna sem eru lesin eða flutt á hverja fyrirspurn, sem bætir leynd með því að útrýma óþarfa I/O aðgerðum. Þessi snið gera það einnig mögulegt að athuga hvort skjal birtist á lista án þess að afkóða það að fullu.

Umhverfisskráða vísitalan

Fyrir hvern skilmála geymir umhverfisskráða vísitalan skilaboðalista. Þessir listar geta verið frá handfylli af skjölum til milljóna, þannig að engin stök snið virka vel fyrir hvern lista.

Stuttir listar nota innbyggða framsetningu sem kemst fyrir á einni síðu og þarfnast enginnar blokkartöflu. Lengri listar sem komast ekki fyrir á innbyggða sniðinu eru skiptir niður í blokkir sem ná yfir fast bil skjalauðkenna. Framsetning hverrar blokkar fer eftir þéttleika hennar: strjál blokk geymir raðað fylki af skjalauðkennis-hliðrunum, á meðan þéttar blokkir nota bitamyndir.

Fyrirspurnartíðni skilmála ákvarðar hvar skilaboðalisti hans er staðsettur á diski. Oftar fyrirspurnum lista er geymt nálægt hver öðrum, sem þjappar heitum gögnum í minna geymslusvæði.

Stækka

Ganga í gegnum lista innan vinnufjárhagsáætlunar

Frambjóðendaval krefst þess að ganga í gegnum skilaboðalista til að finna mögulega viðeigandi skjöl. Það er dýrt að skanna hvern lista ítarlega, svo Photon notar WAND-líkt reiknirit sem gengur aðeins í gegnum sumt af listunum á meðan samt er gert ráð fyrir samsvörunum í hinum.

Reikniritið skiptir listum í tvo hópa. Driflistar færa gönguna á fram og leggja til frambjóðendaskjöl. Prófunarlistar leggja til stig þessara frambjóðenda en búa ekki til frambjóðendur sjálfir.

Stigagjöf frambjóðenda sameinar vegið yfirspurnar-skilmálaþekju og tíðniframlag, með skjalalengdarnormun og þaki á ávinningi frá endurteknum skilmálum. Photon athugar fyrst tilvist skilmála í fylkjum og bitamyndum til að binda hámarks möguleg stig hvers frambjóðanda. Það les nákvæma skilmálatíðni aðeins fyrir frambjóðendur sem gætu enn uppfyllt valröskuldinn.

Val heldur síðan áfram í þremur skrefum:

• Ganga: Byrjaðu með stranga fyrirspurnar-þekjukröfu. Ef of fáir frambjóðendur finnast, endurtaktu með rýmkaðri kröfu.
• Varðveisla: Frambjóðendur eru geymdir í bundnu safni með því að nota stig sem sameinar þekju og tíðni. Eftir þessu sem söfnuðu efstu frambjóðendurnir batna hækkar aðgöngumörkin.
• Lokaútval: Lokaniðurstöður fyrir umferðina eru valdar úr varðveitta safninu byggt á tíðnistigum. Hver reitur keyrir sína eigin umferð og niðurstöðunum er blandað saman með reiturvigtum.

Reikniritið skilar frambjóðendasafni viðeigandi skjala sem á að nota í frekari röðun.

Stækka

Docblob

Eftir að frambjóðendasíður hafa verið valdar þarf röðunaráfanginn skilmálatíðni, reitaþekju og staðsetningar og nálægð tilviks. Til að fá þessi gögn í gegnum umhverfisskráðu vísitöluna þyrfti dreifðan aðgang yfir margar skilmála-skjalapör. Í Photon geymum við þétta færslu á hvert skjal sem kallaist docblob.

Sniðið er smíðað til að forðast afkóðun umfram það sem nauðsynlegt er. Innan docblob eru reitir flokkaðir eftir textagreiningartæki. Hver hópur geymir raðað skilmálalista afkóðaðan með Elias-Fano, þannig að hægt er að fletta upp fyrirspurnarskilmála beint án þess að stækka allan listann fyrst.

Sú valkvæða afkóðun gerir docblob kleift að styðja við geymslu á meiri gögnum á hvert skjal án hlutfallsleikerfi kostnaðaraukningar. Að stækka færsluna þvingar ekki fram meiri vinnu á hvert flett, vegna þess að röðunin snertir einnig aðeins þá hluta sem tengjast samsvörunarskilmálunum frekar en alla færsluna.

Stækka

Lotulestrar og vinna með minni

Jafnvel með skilvirkari gagnasamsetningum klárast vinnsluminnið enn áður en önnur úrræði gera það, þannig að við þurfum oft að nálgast gögn sem geymd eru á diski. Photon notar ósamstillta diskalestra og skyndiminni fínstillt fyrir lotulestra til að flýta fyrir þessum aðgangi, sem skerðir biðtíma á hverja beiðni.

Stækka

Skörun diskabíða

Röðun krefst þess að fá einkenni hundrað skjala sem staðsett eru á mismunandi stöðum í skrá. Fyrra kerfi okkar notaði mmap til að varpa skránni í sýndarvinnusvæði svo hægt væri að lesa hana í gegnum minnisbendingar.

Photon nýtir sér þann eiginleiki að færsluhliðranir eru þekktar fyrir fram, þannig að við getum sent margar lesbeiðnir í einu. Þetta er stýrt af hvarfaranum: sérstakir vinnuþræðir senda lotur í gegnum io_uring og senda gögnin sem þeir lesa áfram til kalliðnaðarkóðans. Hver þráður heldur sínu eigin io_uring; lotur eru sendar á þann hvarfara sem er minnst hlaðinn. Forskráð skrárskilgreining og biðminnissafn draga úr yfirbyggingu endurtekinna lestra. Þessi ósamstillta framkvæmd gerir það að verkum að biðtími eftir nokkrum aðgerðum getur skarast, sem dregur úr síðtöf.

Að draga úr fjölda drifaðganga

Áður en lesbeiðnir eru sendar athugar Photon alla lotuna í vinnsluminni skyndiminni. Aðeins beiðnir um vantar færslur fara á disk; gögnin sem lesin eru fylla síðan skyndiminnið.

Skyndiminnið er hannað fyrir lotulestra. Nánar tiltekið:

• Það er engin aðskilin úthlutun við högg. Í staðinn er gögnum afritað í biðminni sem hringikóðinn hefur undirbúið fyrir fram.
• Það er engin læsingaröflun af hálfu lesandans. Í staðinn athugar hann gagnavtgáfuna og reyndir aftur ef hún stangast á við skrif.
• Það notar CLOCK brottrekstur, í stað þess að krefjast uppfærslu á sameiginlegum LRU lista við hvern lestur.
• Það notar skyndiminni örgjörva (CPU cache prefetching), þar sem óskað er eftir lýsigögnum og gögnum fyrir yfirvofandi færslur fyrir fram.

Þessar fínstillingar draga úr leynd án þess að skaða afköst á því vinnuálagi sem okkur stendur á sama um.

Smíði og uppfærsla vísitölunnar aðskilið frá afgreiðslu

Í Photon keyra vísitölugerð og fyrirspurnarafgreiðsla á mismunandi hnútum. Vísitöluhöfundar breyta gögnum í tilbúnar geymslusamsetningar, á meðan afgreiðsluhnútar lesa þær og framkvæma heimt og röðun.

Þessi aðskilnaður tekur á endurheimtar- og samstillingarflöskuhálsum sem voru til staðar í fyrri útfærslu. Vegna þess að vísitölugerð keyrði innan sömu þyrpingar og þjónaði fyrirspurnum, gæti það þýtt að endurvísitöluleggja skjöl á staðnum að endurheimta bilaðan hnút eða bæta við nýju eintaki af gögnunum.

Stækka

Undirbúningur og dreifð smíði

Smíði hefst á því að velja skjöl fyrir virku vísitöluna og framleiða upprunaútflutninginn. Stjórnandinn skráir upprunaútgáfu, inntatstöflur og áætlaðan fjölda skarda. MapReduce verk í YTsaurus undirbúa texta, lýsigögn, brot, einkenni og fyrirreiknaðar innfellingar í útgáfuskiptar töflur skiptar eftir skörðum.

Skardfjöldi og fjöldi samtímis keyrandi vísitöluhöfunda eru stilltir óháð hvort öðru, þannig að smíði getur keyrt í nokkrum bylgjum, eða hægt er að úthluta fleiri tækjum til að vinna samhliða. Dreifður undirbúningur og samhliða vísitöluhöfundar leyfa að öll vefvísitalan sé smíðuð á einni tölustaf klukkustunda, veruleg framför frá fyrra kerfi.

Að dreifa nýrri útgáfu

Fyrir dreifingu athugar stjórnandinn hvort nýja vísitalan sé tilbúin. Ef gögnin eru ófullkomin er dreifingu sjálfkrafa lokað fyrir.

Þegar margir afgreiðsluhópar eru til staðar uppfærir stjórnandinn þá einn í einu. Hann fjarlægir fyrst hóp úr beinabeiðnum og byrjar hann á nýju vísitöluútgáfunni. Áður en beðið er um beiðnir fara skörðin í gegnum aðskilið upphitunarstig byggt á leitargagnaskrám.

Tími gagnauppfærslu er breytilegur milli leitarsviða. Fyrir svið með miklar kröfur um ferskleika tekur afhending skjala einn tölustaf mínútna. Hægt er að dreifa viðbótareintaki af gögnunum á um hálftíma; tilbúnum vísitölum er hlaðið og þær tengdar við skörð án þess að endurvísitöluleggja upprunaskjölin.

Stækka

Flutningur og staðfesting innan leitarstaflans okkar

Fyrsta markmið okkar var að skipta út gömlu kerfinu fyrir vél sem varðveitti virkni og leitargæði á meðan svatími minnkaði. Við staðfestum Photon í áföngum, byrjuðum á endurteknum álagprófunum og ótengdu gæðamati áður en skipt var yfir í lifandi umferð.

Álagprófanir og mat

Til að prófa afköst smíðuðum við álagstestunartól sem endurtekur fyrirspurnir úr leitarskránum okkar á stillanlegum komutíðnum. Það bera saman niðurstöður milli keyrslna og beitir tölfræðiprófum til að meta hvort greinilegur munur á afköstum sé samrægur. Að auki bárum við saman Photon og eldra kerfið á sömu gagnasöfnum í innri matskerfum okkar án nettengingar til að athuga hvort gæðabreytingar hefðu átt sér stað.

Eftir þessar athuganir sendum við lifandi fyrirspurnir á bæði kerfin samtímis með skuggaumferð. Þetta gerði okkur kleift að bera saman afköst þeirra og niðurstöður á framleiðsluálagi áður en skipt var um kerfi sem þjónaði notendum. Við virkuðum síðan Photon fyrir litla undirhópa notenda og stækkuðum úrúllan skref fyrir skref, fylgdumst með gæðum og afköstum í gegn. Fyrsta útgáfan stóðst samþykktarpróf án gæðaskerðingar, og við héldum áfram útbreiðslunni þar til Photon þjónaði allri framleiðsluumferð.

Mældar endurbætur í framleiðslu

Í framleiðsluverkflæði okkar féll p99 svatími úr u.þ.b. 800 ms í gömlu kerfinu niður í u.þ.b. 65 ms í Photon. Þessi mæling nær yfir öll stig innan Photon, en útilokar síðari stig í leitarstaflanum á hærra stigi.

Photon notar u.þ.b. 20% færri jafngilda afgreiðsluvélar en efnisnútar gömlu kerfisins á meðan það geymir u.þ.b. 2,5 sinnum meira af gögnum á hvert skjal.

Photon dregur einnig úr magni gagna sem verða að vera í minni. Að festa sama Photon gagnasafn í vinnsluminni með mlock myndi krefjast áætlaðra 4,6 sinnum meira fasta minni en Photon notar eins og er.

Mat á hröðu leitar-API stillingunni

Við notuðum einnig Photon sem grundvöll fyrir nýja hraða stillingu fyrir leitar-API okkar, hannaða fyrir leyndarnæmt vinnuálag. Samkvæmt mælingum okkar er leittími eins leitarkalls fyrir hraðu stillinguna 160 ms á p50 og 230 ms á p95.

Við mátum hraða stillinguna á sex gervigreindarviðmiðum: WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0 og SEAL-Hard. Yfir þetta mat hafði hún lægsta áætlaða heildarkostnað líkans og leitar og hæsta heildarverkefnisstig meðal prófaðra stillinga.

Hraða stillingin para Photon við röðun fínstillta fyrir gervigreindarverkflæði, skilar sambærilegum afköstum og sjálfgefin stilling á verulega lægri kostnaði. Hins vegar fylgir henni málamiðlun í víðtækari leitargæðum.

Stækka

Við mælum með hröðu stillingunni fyrir dagleg gervigreindarverkefni. Fyrir erfiðari eða tvíræðari spurningar sem eru minnst tímanæmar býður sjálfgefin stilling upp á sterkari gæði, sem réttlætir hærri leynd og kostnað.

Niðurstaða

Við erum stöðugt að færa leitarstaflann okkar yfir á Rust-undirstaða, innanhúss innviði. Að skipta út opnu vélinni fyrir Photon, sérsniðnu heimtunar- og röðunarvélina okkar, er nýasta skrefið.

Photon hefur gert hraðari leit kleift í vörum Perplexity og veitir grunninn að nýju hröðu stillingunni í leitar-API. Eftir flutninginn féll p99 heimtunar- og röðunarleynd úr um það bil 800 ms niður í 65 ms. Þétt gagnasnið okkar leyfa okkur einnig að geyma 2,5 sinnum meira af gögnum á hvert skjal.

Hraða stillingin skilar leittími eins leitarkalls upp á 160 ms við p50 og 230 ms við p95. Yfir sex metna gervigreindarhópmiðaða viðmiðunarpunkta dró hún úr áætluðum kostnaði líkans og leitar á hvert verkefni um 68% miðað við sjálfgefna stillinguna á meðan sambærileg heildargæði verkefna voru viðhaldið. Þessar niðurstöður sýna fram á hagnýtan ávinning innviða sem hannaðir eru í kringum leitaraðgerðir okkar, bæði fyrir vörur Perplexity og fyrir verktaka sem smíða með API okkar.

Við höldum áfram að bæta afköst og geymsluskilvirkni Photon. Markmið okkar er að styðja stærri vísitölu og ríkari skjalagögn á sama vélbúnaði á meðan leit er haldið hröðum eftir því sem vinnuálag okkar stækkar.

Tilvitnun

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