Photon: Paieškos ir reitingavimo variklio kūrimas nuo nulio

Įvadas

"Perplexity" dirbtinio intelekto paieškos stekas surenka ir reitinguoja kandidatų puslapius, iškeldamas tinkamiausią turinį modeliui pagrįsti savo atsakymus. Iš pradžių šis etapas veikė atvirojo kodo variklyje, kurį pritaikėme savo sistemai. Tačiau augant mūsų indeksui ir darbo eigoms, pasiekėme griežtas sąnaudų, uodeginės delstos ir mazgo atsigavimo laiko ribas, kurių negalėjome išspręsti esamoje trečiosios šalies platformoje.

Norėdami įveikti šiuos iššūkius, sukūrėme "Photon" – naują nuosavą paieškos ir reitingavimo variklį. Tai tęsia mūsų požiūrį kurti dirbtinio intelekto paieškos infrastruktūrą nuo nulio, kaip padarėme su CobbleDB, mūsų paskirstyta rakto-reikšmės saugykla puslapių įrašams aptarnauti, ir mūsų Search API.

"Photon" naudoja glaudžius duomenų formatus, kad perskaitytų ir iškoduotų tik tai, ko reikia kiekvienai užklausai, su paketiniu podėliu ir asinchroniniu skaitymu, siekiant sumažinti kreipimąsi į diską ir persidengiančius laukimus. Indekso kūrimas vyksta atskirai nuo užklausų aptarnavimo, atnaujinant po vieną aptarnavimo grupę vienu metu ir sušildant jos podėlius prieš nukreipiant į ją tiesiogines užklausas.

"Photon" dabar palaiko mūsų paieškos konvejerį, taip pat yra naujo greitojo išankstinio nustatymo pagrindas mūsų paieškos API, o vienašalės paieškos delsta siekia 160 ms esant p50 ir 230 ms esant p95. Per šešis viešus etalonus greitasis nustatymas sumažino apskaičiuotą modelio ir paieškos kainą už užduotį 68 %, išlaikydamas bendrą užduočių kokybę, palyginamą su numatytuoju nustatymu. Šiandien jį išleidžiame, kad kūrėjai galėtų pasiekti šiuos patobulinimus.

Padidinti

Padidinti

Ko reikalauja paieškos ir reitingavimo variklis

Kiekvienai užklausai paieškos ir reitingavimo variklis ieško dideliame, paskirstytame indekse, kad pasirinktų ir išrikiuotų nedidelį rinkinį svarbių puslapių paieškos steko delstos biudžete. Sistema taip pat turi palaikyti indeksą atnaujintą atvykstant naujiems puslapiams ir keičiantis esamiems, neleisdama tam darbui sulėtinti tiesioginių užklausų.

Įvertinome kelis atvirojo kodo variantus ir pasirinkome subrendusį, bendros paskirties paieškos ir reitingavimo variklį, kuris atitiko mūsų pradinius poreikius. Tuomet pritaikėme jį prie mūsų architektūros ir darbo eigų, išlaikydami stabilią delstą ir pralaidumą gamybiniu mastu.

Kur mūsų ankstesnė sistema prastai pasirodė

Palaikėme savo pačių atšaką, kad pritaikytume variklį savo augančiam indeksui, tačiau pagrindinių apribojimų sprendimas vis labiau reikalavo pertvarkyti didelę platformos dalį. Keletas apribojimų pasirodė esą sunkiai išsprendžiami be esminių architektūrinių pokyčių:

1. Mastelio keitimo išlaidos. Tiek saugomų dokumentų skaičius, tiek duomenų kiekis vienam dokumentui, kurį turime gauti ir reitinguoti, bėgant laikui augo. Šis mastelio keitimas sukūrė spaudimą mūsų aparatūrai, ypač turimai RAM. Norėdami valdyti išlaidas, mums reikėjo kompaktiškesnių duomenų reprezentacijų ir smulkesnės kontrolės, kas lieka atmintyje, o kas skaitoma iš disko pagal poreikį.

2. Prasta uodeginė delsta. Esant gamybiniam srautui, senosios sistemų p99 atsako laikas buvo apie 800 ms. Duomenų rinkinys viršijo turimą RAM, todėl negalėjome naudoti mlock, kad palaikytume jį visiškai atmintyje. Prieiga prie ne reziduojančių duomenų galėjo sukelti didelių puslapių klaidų, stabdydama užklausos vykdymą, kol operacinė sistema skaitė iš disko.

Variklis taip pat periodiškai sujungdavo savo pagrindinį disko indeksą su mažesniais indeksais, nuplautais iš atminties. Šio disko indekso suliejimo proceso metu puslapių klaidų skaičius pakilo dar labiau, o p99 delsta pasiekė maždaug 1,2 s per 10–15 minučių. Podėliams sušilus, puslapių klaidų dažnis ir delsta sumenko, kas rodo, kad šalti skaitymai buvo pagrindinė smailių priežastis. Duomenų išankstinis įkėlimas ir indekso šildymas sumažino smailes, tačiau adekvačiai neišsprendė didelės uodeginės delstos.

3. Ilgas atsigavimas ir sinchronizavimas. Ankstesnėje sistemoje papildomo klasterio diegimas ir jo duomenų sinchronizavimas galėjo užtrukti ilgiau nei savaitę. Sinchronizavimo taip pat reikėjo pridedant mazgų grupes papildomoms duomenų kopijoms laikyti arba atsigaunant po mazgo gedimų. Atsigavimo metu didesnė dalis paieškos atsakų buvo daliniai, o tai sumažino galutinio atsakymo kokybės balus.

Galiausiai padarėme išvadą, kad būtų paprasčiau ir pigiau kurti nuo nulio, nei toliau pritaikinėti ir prižiūrėti savo atšaką. Remdamasi patirtimi, įgyta eksploatuojant ankstesnę sistemą, nedidelė inžinerinių komandų grupė dirbo kartu su nuolatinių kodavimo agentų spiečiumi, kad sukurtų "Photon".

Kur "Photon" dera paieškos steke

"Photon" suprojektuotas dviejoms pagrindinėms darbo eigoms: paieškos užklausų aptarnavimui ir atnaujinimų įsisavinimui iš apdorojimo konvejerio.

Aukštesnio lygio paieškos tarnybos užklausa pasiekia "Photon" brokerį per apkrovos balansavimo įrenginį. Brokeris pasirenka fragmento grupę ir persiunčia užklausą kiekvienam fragmentui, stebėdamas skirtuko laikus ir pateikdamas papildomas užklausas, kai reikia.

Kiekvienas fragmentas atlieka paiešką, pradinį reitingavimą ir antrojo etapo reitingavimą, tuomet grąžina geriausius kandidatus brokeriui. Brokeris sujungia šiuos kandidatus į vieną reitinguotą sąrašą ir parsiunčia pagrindinius dokumentų laukus pasirinktiems puslapiams iš atitinkamų fragmentų. Tuomet jis grąžina šiuos rezultatus aukštesnio lygio paieškos paslaugai, kuri surenka puslapio turinį, reikalingą agentui sugeneruoti pagrįstą atsakymą.

Indekso atnaujinimai vyksta atskiru keliu. "Pillar", mūsų publikavimo sluoksnis, paruošia duomenis ir saugo juos "YTsaurus" lentelėse. Indeksatoriai paverčia šias lenteles indekso struktūromis, kurias fragmentai gali įkelti paieškai. Valdiklis koordinuoja duomenų paruošimą, indekso kūrimą ir naujų indekso versijų diegimą aptarnavimo grupėms. Prieš aptarnaudamas tiesioginį srautą, kiekvienas fragmentas atkartoja tikras paieškos užklausas, kad sušildytų savo podėlius.

Padidinti

"Photon" projektavimas mūsų darbo eigoms

Trys dizaino pasirinkimai daro "Photon" gerai pritaikytu mūsų darbo eigai: kompaktiškos duomenų reprezentacijos, podėlis ir asinchroninis disko skaitymas bei indekso atnaujinimų atskyrimas nuo užklausų aptarnavimo.

Duomenų reprezentacijos paieškai ir reitingavimui

Paieška ir reitingavimas pasiekia dokumentų duomenis skirtingai. Leksikinė paieška prasideda nuo užklausos terminų ir randa juos turinčius dokumentus. Reitingavimui tuomet reikia išsamios informacijos apie kiekvieną pasirinktą dokumentą, įskaitant terminų dažnius ir pozicijas.

"Photon" naudoja dvi papildomas reprezentacijas šiems prieigos modeliams palaikyti. Apverstas indeksas saugo atitinkančių dokumentų sąrašą kiekvienam terminui, vadinamą skelbimo sąrašu, kad palaikytų kandidatų atranką. Atskiri įrašai kiekvienam dokumentui suteikia duomenis, reikalingus reitingavimui. Mes taip pat optimizuojame, kaip skelbimo sąrašai saugomi ir pereinami, kad pagerintume atranką fiksuotame darbo biudžete.

Specializuotos duomenų reprezentacijos leidžia efektyviau saugoti pagrindinius duomenis. Labiau kompaktiškas apverstas indeksas sumažina duomenų, skaitomų ar perkeliamų per užklausą, kiekį, pagerindamas delstą pašalinant nereikalingas I/O operacijas. Šie formatai taip pat leidžia patikrinti, ar dokumentas yra sąraše jo visiškai neiškoduojant – tai savybė, kuria remiasi mūsų perėjimo logika, kad valdytų, kiek darbo atlieka užklausų fiksuotame biudžete. Įrašų optimizavimas vienam dokumentui leidžia saugoti daugiau duomenų vienam dokumentui reitingavimui, kartu sumažinant mastelio keitimo išlaidas, susijusias su ankstesne sistema.

Apverstas indeksas

Kiekvienam terminui apverstas indeksas saugo skelbimo sąrašą. Šie sąrašai gali svyruoti nuo kelių dokumentų iki milijonų, todėl joks vienas formatas netinka kiekvienam sąrašui. "Photon" pasirenka formatą pagal dokumentų, turinčių terminą, skaičių.

Trumpi sąrašai naudoja vidinę reprezentaciją, kuri telpa viename puslapyje ir nereikalauja bloko lentelės. Ilgesni sąrašai, kurie netelpa į vidinį formatą, yra padalijami į blokus, apimančius fiksuotus dokumentų identifikatorių diapazonus. Kiekvieno bloko reprezentacija priklauso nuo jo tankio: retuose blokuose saugomi rūšiuoti dokumentų ID poslinkių masyvai, o tankiuose blokuose naudojami bitų žemėlapiai. Reti blokai naudoja šuolinę paiešką, kuri juda vis didesniais žingsniais, kad praleistų sąrašo sritis. Tankūs blokai leidžia tikrinti narystę ieškant bitų, atitinkančių dokumentą.

Termino užklausos dažnis nulemia, kur jo skelbimo sąrašas patalpinamas diske. Dažnai užklausiami sąrašai saugomi arti vienas kito, sutelkiant karštus duomenis mažesnėje saugyklos srityje. Kiekviename sąraše dokumentai rikiuojami pagal atskirą naudingumo signalą, kad perspektyvesni kandidatai būtų sutinkami anksčiau.

Padidinti

Sąrašų perėjimas darbo biudžete

Kandidatų atranka reikalauja pereiti per skelbimo sąrašus, kad būtų rasti potencialiai svarbūs dokumentai. Išsamus kiekvieno sąrašo skanavimas yra brangus, todėl "Photon" naudoja "WAND" tipo algoritmą, kuris pereina tik per kelis sąrašus, vis tiek apskaitydamas atitikmenis kituose.

Algoritmas padalija sąrašus į dvi grupes. Vairavimo sąrašai stumia perėjimą ir siūlo kandidatų dokumentus. Zonduojamieji sąrašai prisideda prie šių kandidatų balų, tačiau patys negeneruoja kandidatų.

Kandidatų vertinimas derina svertinį užklausos terminų padengimą ir dažnio indėlį, su dokumento ilgio normalizavimu ir pelno apribojimu iš pakartotinių terminų. "Photon" pirmiausia patikrina terminų buvimą masyvuose ir bitų žemėlapiuose, kad apribotų kiekvieno kandidato maksimalų galimą balą. Jis nuskaito tikslius terminų dažnius tik tiems kandidatams, kurie vis dar gali atitikti atrankos slenkstį.

Pasirinkimas tuomet vyksta trimis žingsniais:

• Perėjimas: Pradėkite nuo griežto užklausos padengimo reikalavimo. Jei randama per mažai kandidatų, pakartokite su laisvesniu reikalavimu.
• Išlaikymas: Kandidatai laikomi ribotame rinkinyje, naudojant balą, kuris sujungia padengimą ir dažnį. Geresniems viršutiniams kandidatams kylant, priėmimo slenkstis kyla.
• Galutinis pasirinkimas: Galutiniai etapo rezultatai atrenkami iš išlaikyto rinkinio, remiantis dažnio balais. Kiekvienas laukas vykdo savo etapą, o rezultatai sujungiami naudojant lauko svorius.

Algoritmas sukuria kandidatų rinkinį iš susijusių dokumentų, kurie bus naudojami tolimesniam reitingavimui.

Padidinti

Docblob

Pasirinkus kandidatų puslapius, reitingavimo fazei reikalingi terminų dažniai, laukų padengimas bei pasirodymų vietos ir artumas. Šių duomenų gavimas per apverstą indeksą reikalautų išvaikytos prieigos per daugelį terminų ir dokumentų porų. "Photon" saugome kompaktišką įrašą kiekvienam dokumentui, vadinamą "docblob", kuriame yra terminų dažniai, laukai, kuriuose pasirodė terminas, ir kur dokumente tai įvyko. Dėl to kandidato reitingavimui reikia tik vienos paieškos dokumentui.

Formatas sukurtas siekiant išvengti didesnio nei būtina iškodavimo. "Docblob" laukai sugrupuoti pagal teksto analizatorių. Kiekvienoje grupėje saugomas rūšiuotas terminų sąrašas, užkoduotas naudojant "Elias-Fano", todėl užklausos terminą galima tiesiogiai rasti neišskleidžiant viso sąrašo iš karto. Lauko kaukė žymi, kur įvyko terminas, dažnio skaitiklis seka, kaip dažnai, o faktinės pozicijos gyvena atskiruose blokuose kiekvienai termino ir lauko porai, užkoduotose kaip pozicijų skirtumai. Iškoduojami tik tie blokai, kurių terminai iš tikrųjų sutapo, o visa kita įraše lieka suglaudintu formatu.

Šis selektyvus iškodavimas leidžia "docblob" palaikyti daugiau duomenų saugojimą vienam dokumentui be proporcingo sąnaudų augimo. Įrašo didinimas neskatina papildomo darbo paieškai, nes reitingavimas visada liečia tik tas dalis, kurios susijusios su sutampančiais terminais, o ne visą įrašą.

Padidinti

Paketiniai skaitymai ir darbas su atmintimi

Net ir su efektyvesnėmis duomenų reprezentacijomis, RAM vis tiek išsenka anksčiau nei kiti ištekliai, todėl dažnai turime pasiekti diske saugomus duomenis. "Photon" naudoja asinchroninį disko skaitymą ir paketiniams skaitymams optimizuotą podėlį, kad pagreitintų šiuos pasiekimus, sutrumpindamas laukimo laiką užklausai. Tai prisideda prie reikšmingo uodeginės delstos pagerėjimo, palyginti su ankstesne sistema.

Padidinti

Persidengiantys disko laukimai

Reitingavimui reikia gauti šimto dokumentų, esančių skirtingose failo dalyse, požymius. Mūsų ankstesnė sistema naudojo mmap, kad suplanuotų failą į virtualią adresų erdvę, kad jį būtų galima perskaityti per atminties rodykles. Tačiau prieiga prie puslapio, kurio nebuvo atmintyje, vis tiek reikalavo disko skaitymo. Gija turėjo laukti duomenų prieš tęsiant skaičiavimą, o šis laukimo laikas kaupėsi, kai procesui reikėjo nuosekliai skaityti šaltus įrašus.

"Photon" pasinaudoja tuo, kad įrašų poslinkiai yra žinomi iš anksto, todėl galime pateikti kelis skaitymus vienu metu. Tai valdo reaktorius: specialios darbinės gijos pateikia paketus per io_uring ir perduoda perskaitytus duomenis kviečiančiajam kodui. Kiekviena gija palaiko savo io_uring; paketai siunčiami mažiausiai apkrautam reaktoriui. Iš anksto užregistruoti failų deskriptoriai ir buferių telkiniai sumažina pakartotinių skaitymų sąnaudas. Šis asynerginis vykdymas leidžia kelių operacijų laukimams persidengti, o tai sumažina uodeginę delstą.

Disko kreipimų skaičiaus mažinimas

Prieš pateikdamas skaitymus, "Photon" patikrina visą paketą atmintyje esančiame podėlyje. Į diską keliauja tik trūkstamų įrašų užklausos; nuskaityti duomenys tuomet užpildo podėlį.

Podėlis suprojektuotas paketiniams skaitymams. Konkrečiai:

• Pataikymo atveju nėra atskiro paskirstymo. Vietoj to duomenys nukopijuojami į buferį, kurį iš anksto paruošė kviečiantysis kodas.
• Skaitytojas neįgyja užrakto. Vietoj to jis patikrina duomenų versiją ir bando iš naujo, jei ji susikirta su rašymu.
• Jis naudoja "CLOCK" pašalinimą, o ne reikalauja atnaujinimų bendrame LRU sąraše kiekvieno skaitymo metu.
• Jis naudoja CPU podėlio išankstinį nuskaitymą, kai būsimų įrašų metaduomenys ir duomenys užklausiami iš anksto.

Šie optimizavimai sumažina delstą nepakenkdami našumui mums svarbiose darbo eigose.

Indekso kūrimas ir atnaujinimas atskirai nuo aptarnavimo

"Photon" indekso kūrimas ir užklausų aptarnavimas veikia skirtinguose mazguose. Indeksatoriai paverčia duomenis paruoštomis saugojimo struktūromis, o aptarnavimo mazgai juos skaito ir atlieka paiešką bei reitingavimą. Dėl to indekso kūrimas nekonkuruoja su paieškos užklausomis dėl CPU, o šių užduočių ištekliai gali būti keičiami nepriklausomai.

Šis atskyrimas sprendžia atsigavimo ir sinchronizavimo kliūtis, esančias ankstesnėje implementacijoje. Kadangi indekso kūrimas vyko tame pačiame klasteryje, kuris aptarnavo užklausas, atsigaunantis sugedęs mazgas arba naujos duomenų kopijos pridėjimas galėjo reikšti dokumentų perindeksavimą vietoje – procesą, kuris užtruko dienas ir padidino dalinius atsako rodiklius atsigavimo metu. "Photon" pašalina šį ryšį; indeksatoriai veikia kaip paskirstytos užduotys, kurios gamina versijuotas, paruoštas naudoti indekso struktūras nepriklausomai nuo aptarnavimo mazgų, todėl kitos indekso versijos kūrimas nebekonkuruoja su tiesioginiu srautu.

Padidinti

Paruošimas ir paskirstytas kūrimas

Kūrimas prasideda nuo dokumentų pasirinkimo aktyviam indeksui ir šaltinio eksporto generavimo. Valdiklis įrašo šaltinio versiją, įvesties lenteles ir numatomą fragmentų skaičių. "MapReduce" užduotys "YTsaurus" paruošia tekstą, metaduomenis, fragmentus, požymius ir iš anksto apskaičiuotas įdėtis į versijuotas lenteles, padalintas pagal fragmentą. Kiekvienas indeksatorius srautu siunčia paruoštą lentelę, kuria struktūras savo fragmentui ir sujungia teksto segmentus. Paruoštas indeksas kartu su jo komponentų aprašymu įkeliamas į objektų saugyklą.

Fragmentų skaičius ir vienu metu veikiančių indeksatorių skaičius konfigūruojami nepriklausomai, todėl kūrimas gali vykti keliomis bangomis arba daugiau mašinų gali būti priskirta dirbti lygiagrečiai. Paskirstytas paruošimas ir lygiagretūs indeksatoriai leidžia sukurti visą žiniatinklio indeksą per vienaženklį valandų skaičių – tai didelis patobulinimas lyginant su ankstesne sistema.

Naujos versijos diegimas

Prieš diegimą valdiklis patikrina, ar naujas indeksas paruoštas. Jei duomenys neužbaigti, diegimas automatiškai užblokuojamas.

Kai yra kelios aptarnavimo grupės, valdiklis atnaujina jas po vieną. Jis pirmiausia pašalina grupę iš brokerio maršruto ir paleidžia nauja indekso versija. Prieš aptarnaudami užklausas, fragmentai pereina per atskirą šildymo etapą, pagrįstą paieškos žurnalais, kuris iš anksto užpildo pradinę būseną ir padeda sklandžiau pereiti prie tikro srauto. Po šildymo valdiklis patikrina indekso būseną ir pasirengimą, tuomet grąžina grupę į maršrutą. Kitos grupės tuo metu toliau aptarnauja užklausas. Kadangi operacijos būsena išsaugoma, paleidimas iš naujo nepriverčia kurti iš naujo; valdiklis gali iš naujo prijungti prie jau vykstančio paruošimo, pakartotinai naudoti paruoštą rezultatą arba tęsti nutrauktą pasukimą nuo išsaugoto žingsnio.

Duomenų atnaujinimo laikas skiriasi skirtinguose paieškos vertikaliuose. Vertikaliems su dideliais šviežumo reikalavimais dokumentų pristatymas užtrunka vienaženklį minučių skaičių. Papildoma duomenų kopija gali būti įdiegta per maždaug pusvalandį; paruošti indeksai įkeliami ir prijungiami prie fragmentų iš naujo neindeksuojant šaltinio dokumentų.

Padidinti

Migracija ir patvirtinimas mūsų paieškos steke

Mūsų pirmasis tikslas buvo pakeisti senąją sistemą varikliu, kuris išlaikytų funkcionalumą ir paieškos kokybę, kartu sumažindamas atsako laiką. Patvirtinome "Photon" etapais, pradedant nuo atkuriamų apkrovos testų ir neprisijungusio kokybės vertinimo prieš pereinant prie tiesioginio srauto. "Photon" dabar palaiko paiešką ir reitingavimą mūsų gamybiniame paieškos steke, su žemesniu atsako laiku nei senoji sistema.

Apkrovos testavimas ir vertinimai

Našumo testavimui sukūrėme apkrovos testavimo įrankį, kuris atkuria užklausas iš mūsų paieškos žurnalų konfigūruojamais atvykimo dažniais. Jis lygina rezultatus tarp paleidimų ir taiko statistinius testus, kad įvertintų, ar stebimi našumo skirtumai yra nuoseklūs. Atskirai įvertinome "Photon" ir senąją sistemą tuose pačiuose duomenų rinkiniuose mūsų vidinėse neprisijungusio vertinimo sistemose, kad patikrintume kokybės regresijas.

Po šių patikrų išsiuntėme tiesiogines užklausas abu varikliams vienu metu, naudodami šešėlinį srautą. Tai leido palyginti jų našumą ir rezultatus gamybinėse darbo eigose prieš pakeičiant vartotojus aptarnaujantį variklį. Tuomet įjungėme "Photon" mažoms vartotojų pogrupiams ir palaipsniui plėtėme diegimą, stebėdami kokybę ir našumą. Pirmoji versija praėjo priėmimo testavimą be kokybės regresijų, ir tęsėme diegimą, kol "Photon" aptarnavo visą gamybinį srautą.

Išmatuoti patobulinimai gamyboje

Mūsų gamybinėje darbo eigoje p99 atsako laikas nukrito nuo maždaug 800 ms senojoje sistemoje iki maždaug 65 ms "Photon". Šis matavimas apima visus etapus "Photon" viduje, tačiau neapima vėlesnių etapų aukštesnio lygio paieškos steke. Taip pat nepastebime delstos smailių, anksčiau susijusių su indekso versijų keitimu.

"Photon" naudoja maždaug 20% mažiau lygiaverčių aptarnavimo mašinų nei senosios sistemos turinio mazgai, o saugo maždaug 2,5 karto daugiau duomenų vienam dokumentui. Po migracijos panaudojome šiuos papildomus duomenis reitingavimo kokybei pagerinti virš senosios sistemos lygio.

"Photon" taip pat sumažina duomenų kiekį, kuris turi likti atmintyje. To paties "Photon" rinkinio pririšimas RAM atmintyje naudojant mlock reikautų maždaug 4,6 karto daugiau reziduojančios atminties nei "Photon" naudoja dabar.

Greitojo paieškos API nustatymo vertinimas

Taip pat naudojome "Photon" kaip pagrindą naujam greitajam nustatymui mūsų paieškos API, suprojektuotam laiku jautrioms darbo eigoms. Remiantis mūsų matavimais, vienašalės paieškos delsta greitajam nustatymui yra 160 ms esant p50 ir 230 ms esant p95, mažesnė arba palyginama su kitų paieškos API teikėjų savarankiškai praneštais skaičiais, nors pranešti uodeginiai procentiliai skiriasi.

Įvertinome greitąjį nustatymą šešiuose agentų etalonuose: "WideSearch", "BrowseComp", "DSQA", "FRAMES", "SEAL-0" ir "SEAL-Hard". Šių vertinimų metu jis turėjo mažiausias apskaičiuotas bendras modelio ir paieškos sąnaudas bei didžiausią bendrą užduoties balą iš testuotų konfigūracijų.

Greitasis išankstinis nustatymas suporuoja "Photon" su reitingavimu, optimizuotu agentų darbo eigoms, ir užtikrina palyginamą našumą su numatytuoju nustatymu už žymiai mažesnę kainą. Tačiau tai susiję su kompromisu platesnėje paieškos kokybėje. Greitasis nustatymas naudoja mažiau skaičiavimo resursų reitingavimui nei numatytasis. Vidinėse metrikose, apimančiose ilgos uodegos užklausas, plataus masto aprėptį ir rezultatų įvairovę, jis surinkia 0,24 punkto mažiau svarbos ir maždaug 3 procentiniais punktais mažiau atsakymų prieinamumo. Manome, kad tai protingas kompromisas agentų darbo eigoms, nes paties modelio mąstymas ir žinios gali padėti kompensuoti skirtumą.

Padidinti

Kasdienėms agentų užduotims rekomenduojame greitąjį išankstinį nustatymą. Sudėtingesniems ar dviprasmiškiems klausimams, kurie yra mažiau jautrūs laikui, numatytasis išankstinis nustatymas siūlo tvirtesnę kokybę, pateisinančią didesnį delstą ir kainą.

Išvada

Nuolat perkeliame paieškos steką į "Rust" pagrindu sukurtą nuosavą infrastruktūrą. Atvirojo kodo variklio pakeitimas "Photon", mūsų pasirinktiniu paieškos ir reitingavimo varikliu, yra naujausias žingsnis. "Photon" suteikia mums pilną duomenų reprezentacijų, skaitymų organizavimo ir naujų indeksų diegimo kontrolę, leidžiančią optimizuoti kiekvieną sluoksnį mūsų darbo eigoms.

"Photon" įgalino greitesnę paiešką visuose "Perplexity" produktuose ir suteikia pagrindą mūsų naujam greitajam nustatymui paieškos API. Po migracijos p99 paieškos ir reitingavimo delsta nukrito nuo maždaug 800 ms iki 65 ms. Mūsų kompaktiški duomenų formatai taip pat leidžia saugoti 2,5 karto daugiau duomenų vienam dokumentui, suteikiant paieškai ir reitingavimui prieigą prie turimesnės dokumento informacijos.

Greitasis išankstinis nustatymas užtikrina 160 ms vienašalės paieškos delstą esant p50 ir 230 ms esant p95. Vertinant pagal šešis agentų etalonus, jis sumažino apskaičiuotą modelio ir paieškos kainą už užduotį 68 %, palyginti su numatytuoju išankstiniu nustatymu, išlaikydamas panašią bendrą užduočių kokybę. Šie rezultatai demonstruoja praktinę infrastruktūros, suprojektuotos atsižvelgiant į mūsų paieškos darbo eigas, naudą tiek "Perplexity" produktams, tiek kūrėjams, kurtiems su mūsų API.

Tęsiame "Photon" našumo ir saugojimo efektyvumo gerinimą. Mūsų tikslas – palaikyti didesnį indeksą ir turimesnius dokumentų duomenis toje pačioje aparatūroje, išlaikant greitą paiešką augant mūsų darbo eigoms.

Citata

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