Photon: Visszakeresési és rangsorolási motor építése a semmiből

Hogyan javítják a speciális adatábrázolások, a kötegelt olvasások és az indexépítés lekérdezés-kiszolgálástól való szétválasztása az MI-alapú keresést.

SzerzőkPerplexity Engineering

Bevezetés

A Perplexity MI-alapú keresési verme visszakeresi és rangsorolja a jelölt oldalakat, felszínre hozva a legrelevánsabb tartalmat ahhoz, hogy a modell megalapozza a válaszait. Eredetileg ez a szakasz egy nyílt forráskódú motoron futott, amelyet a rendszerünkhöz igazítottunk. Ahogy azonban az indexünk és a munkaterhelésünk nőtt, kemény korlátokba ütköztünk a költségek, a tail latency és a csomópont-helyreállítási idő terén, amelyeket nem tudtunk feloldani a meglévő külsős platformon belül.

Ezen kihívások leküzdése érdekében megépítettük a Photont, egy új, házon belül fejlesztett visszakeresési és rangsorolási motort. Ez folytatja azt a megközelítésünket, hogy a semmiből építünk MI-alapú keresési infrastruktúrát, amint azt a CobbleDB (a laprekordok kiszolgálására szolgáló elosztott kulcs-érték tárunk) és a Search API esetében is tettük.

A Photon kompakt adatformátumokat használ, hogy csak azt olvassa be és kódolja vissza, amire az egyes lekérdezéseknek szükségük van; kötegtudatos gyorsítótárazással és aszinkron olvasásokkal csökkenti a lemez-hozzáférést, valamint átfedésbe hozza a várakozásokat. Az indexépítés függetlenül fut a lekérdezések kiszolgálásától, egyszerre egy kiszolgálócsoportot frissítve, és felmelegítve annak gyorsítótárait, mielőtt az élő lekérdezéseket oda irányítaná.

A Photon mostantól a keresési folyamatunkat hajtja, és egyben a Search API új, gyors előbeállításának alapja is, 160 ms-os p50 és 230 ms-os p95 egykereséses hívási késleltetéssel. Hat nyilvános benchmark mentén a gyors előbeállítás 68%-kal csökkentette a feladatonkénti becsült modell-plusz-keresési költséget, miközben az alapértelmezett előbeállítással összehasonlítható, összesített feladatminőséget tartott fenn. Ma teszjük elérhetővé, hogy a fejlesztők is hozzáférhessenek ezekhez a fejlesztésekhez.

Saját jelentésű egykereséses hívási késleltetés. A PPLX Fast 160 ms-os p50 és 230 ms-os p95 késleltetést jelent. Az Exa Instant a magas tail értékéhez a p95 helyett a p90-et jelenti; a Parallel magas tail értékei nincsenek közzétéve. A jelentett percentilisek és mérési beállítások nem ellenőrzött, közvetlen összehasonlítást jelentenek.
Összesített feladatminőség a becsült teljes modell-plusz-keresési költséggel szemben ugyanezen 3554 kiválasztott feladat esetében. A pontszámok feladatszámmal vannak súlyozva, és a költségek a teljes feladatkészletet lefedik. A PPLX Fast 64,3%-ot ér el 59,73 dollárért, szemben az alapértelmezett PPLX előbeállítás 64,0%-ával 187,60 dollárért, ami körülbelül 68%-kal alacsonyabb becsült költséget jelent ugyanannyi feladat esetén.

Amit a visszakeresési és rangsorolási motor megkövetel

Minden egyes lekérdezéshez a visszakeresési és rangsorolási motor egy nagy, elosztott indexet kutat át, hogy kiválassza és sorrendbe állítsa a releváns oldalak egy kis halmazát a keresési verem késleltetési keretén belül. A rendszernek naprakészen kell tartania az indexet az új oldalak érkezésekor és a meglévő oldalak változásakor is anélkül, hogy ez a munka lelassítaná az élő lekérdezéseket.

Több nyílt forráskódú opciót is kiértékeltünk, és egy olyan érett, általános célú visszakeresési és rangsorolási motort választottunk, amely megfelelt a kezdeti igényeinknek. Ezután hozzáigazítottuk az architektúránkhoz és a munkaterheléseinkhez, fenntartva a stabil késleltetést és áteresztőképességet termelési skálán.

Ahol a korábbi rendszerünk csődöt mondott

Fenntartottuk a saját forkunkat, hogy a motort a növekvő indexünkhöz igazítsuk, de a kulcsfontosságú korlátok kezelése egyre inkább a platform nagy részeinek újratervezését igényelte. Számos megkötés bizonyult nehezen feloldhatónak alapvető építészeti változtatások nélkül:

1. Skálázási költségek. Idővel mind a tárolt dokumentumaink száma, mind a visszakeresendő és rangsorolandó dokumentumonkénti adatok mennyisége növekedett. Ez a skálázás nyomást helyezett a hardverünkre, különösen a rendelkezésre álló RAM mennyiségére. A költségek ellenőrzése érdekében kompaktabb adatábrázolásokra és finomabb szabályozásra volt szükségünk arra vonatkozóan, hogy mi maradjon a memóriában, és mi kerüljön beolvasásra a lemezről igény szerint.

2. Gyenge tail latency (felső határ szerinti késleltetés). Éles forgalomban a régi rendszer p99 válaszideje körülbelül 800 ms volt. Az adatkészlet meghaladta a rendelkezésre álló RAM-ot, így nem tudtuk az mlock segítségével teljes egészében a memóriában tartani. A nem rezidens adatok elérése súlyos laphibákat (page fault) okozhatott, ami megakasztotta a lekérdezések végrehajtását, amíg az operációs rendszer a lemezről olvasott.

A motor időszakosan egyesítette is a fő lemezes indexét a memóriából kiürített kisebb indexekkel. E lemezesindex-összevonási folyamat során a laphibák száma még magasabbra szökött, a p99 késleltetés pedig elérte a körülbelül 1,2 másodpercet 10–15 percre. Ahogy a gyorsítótárak felmelegedtek, a laphibák gyakorisága és a késleltetés is csökkent, ami arra utal, hogy a hideg olvasások jelentősen hozzájárultak a kiugrásokhoz. Az adatok előbetöltése és az index felmelegítése csökkentette a kiugrásokat, de nem kezelte megfelelően a magas tail latencyt.

3. Hosszadalmas helyreállítás és szinkronizálás. A korábbi rendszerben egy további fürt üzembe helyezése és az adatainak szinkronizálása akár egy hétig भी (vagy több mint egy hétig) tarthatott. Szinkronizálásra volt szükség akkor is, amikor további csomópontcsoportokat adtak hozzá a további másolatok tárolására, vagy a csomópontok hibáiból való felépülés során. A helyreállítás során a keresési válaszok nagyobb aránya volt részleges, ami rontotta a végső válasz minőségi pontszámait.

Végül arra a következtetésre jutottunk, hogy egyszerűbb és olcsóbb a semmiből felépíteni, mint tovább adaptálni és karbantartani a forkunkat. Az előző rendszer üzemeltetésével kapcsolatos tapasztalatainkra támaszkodva egy kis mérnöki csapat a perzisztens kódoló ügynökök (agentek) rajával együtt dolgozott a Photon megépítésén.

Hová illeszkedik a Photon a keresési veremben

A Photont elsődlegesen két munkafolyamathoz tervezték: a keresési kérések kiszolgálásához és a feldolgozási folyamatból származó frissítések betöltéséhez.

A magasabb szintű keresési szolgáltatás kérése terheléselosztón (load balancer) keresztül éri el a Photon brókert. A bróker kiválaszt egy shardcsoportot, és továbbítja a kérést az egyes shardoknak, figyelemmel kísérve az időtúllépéseket, és szükség esetén további kéréseket indítva.

Minden shard elvégzi a visszakeresést, a kezdeti rangsorolást és a második szakaszbeli rangsorolást, majd visszaküldi a legjobb jelöltjeit a brókernek. A bróker egyetlen rangsorolt listává egyesíti ezeket a jelölteket, és lekéri a kiválasztott oldalak kulcsfontosságú dokumentummezőit a releváns shardokból. Ezután visszaküldi ezeket az eredményeket a magasabb szintű keresési szolgáltatásnak, amely összegyűjti az ügynök számára a megalapozott válasz generálásához szükséges oldaltartalmat.

Az indexfrissítések külön útvonalat követnek. A Pillar, a közzétételi rétegünk, előkészíti az adatokat, és YTsaurus-táblákban tárolja azokat. Az indexelők ezeket a táblákat indexstruktúrákká alakítják, amelyeket a shardok betölthetnek a kereséshez. A vezérlő koordinálja az adatok előkészítését, az indexépítést és az új indexverziók üzembe helyezését a kiszolgálócsoportokon. Az éles forgalom kezelése előtt minden egyes shard valódi keresési lekérdezéseket játszik le a gyorsítótárai felmelegítése érdekében.

Egy lekérdezés a magasabb szintű keresési szolgáltatástól a terheléselosztón és a brókeren keresztül jut el egy kiválasztott shardcsoportba. Minden shard lekéri és rangsorolja a jelölteket; a bróker egyesíti az eredményeket, lekéri a dokumentummezőket a kiválasztott oldalakhoz, és visszaküldi azokat a magasabb szintű keresési szolgáltatásnak. A sorszámozott lépések mutatják a sorrendet. A folytonos nyilak kéréseket, a szaggatott nyilak pedig az eredményeket szállítják vissza. A bal oldali fáziscímkék megkülönböztetik a jelöltválasztást az összefoglaló-olvasásoktól.

A Photon megtervezése a munkafolyamatainkhoz

Három tervezési döntés teszi a Photont alkalmassá a munkaterhelésünkre: a kompakt adatábrázolások, a gyorsítótárazás és az aszinkron lemezolvasások, valamint az indexfrissítések szétválasztása a lekérdezések kiszolgálásától.

Adatábrázolások a visszakereséshez és a rangsoroláshoz

A visszakeresés és a rangsorolás eltérően éri el a dokumentumadatokat. A lexikális visszakeresés a lekérdezési kifejezésekkel kezdődik, és megkeresi azokat a dokumentumokat, amelyek tartalmazzák azokat. A rangsoroláshoz ezután részletes információkra van szükség az egyes kiválasztott dokumentumokról, beleértve a kifejezések gyakoriságát és pozícióit is.

A Photon két kiegészítő ábrázolást használ ezen hozzáférési minták támogatására. Az invertált index az illeszkedő dokumentumok listáját tárolja minden egyes kifejezéshez (ezt hívják bejegyzéslistának vagy posting listnek), hogy támogassa a jelöltválasztást. Különálló dokumentumonkánti rekordok biztosítják a rangsoroláshoz szükséges adatokat. Optimalizáljuk továbbá a bejegyzéslisták tárolását és bejárását is, hogy javítsuk a kiválasztást egy rögzített munkakereten belül.

A speciális adatábrázolások révén hatékonyabban tudjuk tárolni a kulcsfontosságú adatokat. A kompaktabb invertált index csökkenti a lekérdezésenként beolvasott vagy mozgatott adatok mennyiségét, javítva a késleltetést a felesleges I/O műveletek kiküszöbölésével. Ezek a formátumok azt is lehetővé teszik, hogy ellenőrizzük, egy dokumentum szerepel-e egy listában anélkül, hogy teljesen dekódolnánk azt – ez a tulajdonság az alapja a bejárási logikánknak, amellyel fix kereten belül szabályozzuk a lekérdezések által végzett munka mennyiségét. A dokumentumonkanto rekordok optimalizálásával több adatot tudunk tárolni dokumentumonkánt a rangsoroláshoz, miközben csökkentjük a korábbi rendszerünkhöz kapcsolódó skálázási költségeket is.

Az invertált index

Az invertált index minden egyes kifejezéshez egy bejegyzéslistát tárol. Ezek a listák a dokumentumok maroknyi számától egészen a milliókig terjedhetnek, így nincs olyan egyetlen formátum, amely minden listához jól működne. A Photon a kifejezést tartalmazó dokumentumok száma alapján választja ki a formátumot.

A rövid listák inline ábrázolást használnak, amely egyetlen lapon elfér, és nem igényel blokktáblát. A hosszabb listák, amelyek nem férnek bele az inline formátumba, dokumentumazonosítók rögzített tartományait lefedő blokkokra oszlanak. Az egyes blokkok ábrázolása a sűrűségétől függ: a ritka blokkok a dokumentumazonosító-eltolások rendezett tömbjeit tárolják, míg a sűrű blokkok bittérképeket (bitmap) használnak. A ritka blokkok ugráló keresést (galloping search) használnak, amely egyre nagyobb lépésekben halad előre a lista tartományainak átugrásához. A sűrű blokkok lehetővé teszik a tagságellenőrzést a dokumentumnak megfelelő bit megkeresésével.

Egy kifejezés lekérdezési gyakorisága határozza meg, hogy a bejegyzéslistája hová kerül a lemezen. A gyakran lekérdezett listák egymás közelében tárolódnak, így a forró adatokat egy kisebb tárolási régióba koncentrálják. Az egyes listákon belül a dokumentumokat egy külön hasznossági jel rendezi sorba, így a kedvezőbb jelöltekkel korábban találkozhatunk.

A Photon hossz és blokksűrűség alapján választja ki a bejegyzéslista-ábrázolást. A rövid listák inline módon elférnek egy lapon. A hosszabb listák rögzített dokumentumazonosító-tartományokra oszlanak, a ritka blokkokhoz rendezett eltolástömbökkel, a sűrű blokkokhoz pedig bittérképekkel.

Listák bejárása munkakereten belül

A jelöltválasztás a bejegyzéslisták bejárását igényli a potenciálisan releváns dokumentumok megtalálásához. Minden egyes lista kimerítő átvizsgálása költséges, ezért a Photon egy WAND-szerű algoritmust használ, amely csak néhány listát jár be, miközben továbbra is számol a többi egyezésével.

Az algoritmus két csoportra osztja a listákat. A meghajtó listák előreviszik a bejárást, és jelölt dokumentumokat javasolnak. A próbalisták hozzájárulnak ezen jelöltek pontszámaihoz, de maguk nem generálnak jelölteket.

A jelöltek pontozása egyesíti a súlyozott lekérdezésikifejezés-lefedettséget és a gyakorisági hozzájárulást, dokumentumhossz-normalizálással és az ismétlődő kifejezésekből származó nyereség korlátozásával. A Photon először ellenőrzi a kifejezések jelenlétét a tömbökben és bittérképekben, hogy korlátozza az egyes jelöltek lehetséges maximális pontszámát. A pontos kifejezés-gyakoriságokat csak azoknál a jelölteknél olvassa be, amelyek még elérhetik a kiválasztási küszöböt.

A kiválasztás ezután három lépésben történik:

  • Bejárás (Traversal): Szigorú lekérdezés-lefedettségi követelménnyel kezdődik. Ha túl kevés jelölt található, ismételje meg enyhébb követelménnyel.
  • Megtartás (Retention): A jelöltek egy korlátos halmazban maradnak egy olyan pontszám alapján, amely egyesíti a lefedettséget és a gyakoriságot. Ahogy az összegyűjtött top jelöltek javulnak, az elfogadási küszöb emelkedik.
  • Végső kiválasztás: A menet végső eredményei a megtartott halmazból kerülnek kiválasztásra a gyakorisági pontszámok alapján. Minden mező a saját menetét futtatja, és az eredmények a mezősúlyok felhasználásával összevonásra kerülnek.

Az algoritmus előállítja a releváns dokumentumok egy jelölthalmazát, amelyet a további rangsorolás során kell felhasználni.

Szemléltető korlátos jelöltbejárás. A meghajtó listák dokumentumokat javasolnak, míg a felső korlátok lehetővé teszik az aktuális elfogadási küszöb alatti jelöltek kiszűrését anélkül, hogy lekért listákat vagy pontos frekvenciákat kellene olvasni. A küszöb emelkedik, ahogy a megtartott halmaz javul. A pontszámok illusztrációként lettek kitalálva, és a megőrzött jelöltek nem garantáltan pontos top-k eredmények.

Docblob

A jelölt oldalak kiválasztása után a rangsorolási fázisnak szüksége van a kifejezések gyakoriságára, a mezőlefedettségre, valamint az előfordulások helyére és közelségére. Ennek az adatnak az invertált indexen keresztül történő megszerzése szétszórt hozzáféréseket igényelne számos kifejezés-dokumentum páron keresztül. A Photonban egy kompakt, dokumentumonkánti rekordot, úgynevezett docblobot tárolunk, amely tartalmazza a kifejezések gyakoriságát, azt, hogy a kifejezés mely mezőkben jelent meg, és hogy hol fordult elő a dokumentumban. Ennek eredményeként egy jelölt rangsorolásához dokumentumonkánt mindössze egy keresésre van szükség.

A formátumot úgy alakították ki, hogy elkerülje a szükségesnél nagyobb mértékű dekódolást. Egy docblobon belül a mezők szövegelemzők szerint vannak csoportosítva. Minden csoport Elias-Fano kódolással kódolt, rendezett kifejezéslistát tárol, így egy lekérdezési kifejezés közvetlenül, a teljes lista előzetes kibontása nélkül is kereshető. Egy mezőmaszk jelöli meg, hogy hol fordult elő egy kifejezés, egy gyakoriságszámláló nyomon követi, hogy milyen gyakran, és a tényleges pozíciók kifejezés-mező páronkénti különálló blokkokban élnek, pozíciókülönbségekként kódolva. Csak a ténylegesen illeszkedő kifejezések blokkjai dekódolódnak, míg a rekord minden más része tömörített formátumban marad.

Ez a szelektív dekódolás lehetővé teszi, hogy a docblob több adat tárolását támogassa dokumentumunkként anélkül, hogy a költségek arányosan növekednének. A rekord növelése nem kényszeríti ki több munka elvégzését keresésenként, mivel a rangsorolás mindig csak az egyező kifejezésekhez kapcsolódó részeket érinti, a teljes rekord helyett.

Egy docblob kompakt dokumentumonkánti rekordba csoportosítja a rangsorolási adatokat. A lekérdezési kifejezések egy Elias–Fano kódolású kifejezéslistában kereshetők ki; a mezőmaszkok, a gyakoriságok és a pozícióblokkok biztosítják az illeszkedő kifejezésekhez szükséges adatokat, miközben a nem kapcsolódó kifejezések tömörítve maradnak. A kifejezésazonosítók és -pozíciók illusztrációs jellegűek.

Kötegelt olvasások és a memóriával való munka

Még a hatékonyabb adatábrázolások mellett is a RAM hamarabb kimerül, mint a többi erőforrás, így gyakran kell hozzáférnünk a lemezen tárolt adatokhoz. A Photon aszinkron lemezolvasásokat és a kötegelt olvasásokra optimalizált gyorsítótárat használ ezen hozzáférések felgyorsítására, csökkentve a kérésenkénti várakozási időt. Ez hozzájárul a tail latency jelentős javulásához a korábbi rendszerhez képest.

A Photon a lemezolvasások indítása előtt ellenőrzi az ismert rekordeltolások egy kötegét a gyorsítótárában. A gyorsítótár-találatok egy előkészített pufferbe másolódnak; a tévesztések az io_uring-on keresztül kerülnek beküldésre, így a lemezvárakozások átfedhetők, a visszaadott adatok pedig feltöltik a gyorsítótárat. A rekordok és az idővonalak schematikusak, nem mért késleltetések.

Átfedő lemezvárakozások

A rangsoroláshoz egy fájl különböző részein található száz dokumentum jellemzőinek megszerzése szükséges. A korábbi rendszerünk mmap segítségével képezte le a fájlt a virtuális címtérbe (address space), hogy memóriapmutatókon keresztül lehessen olvasni. A memóriából hiányzó oldal elérése azonban továbbra is lemezolvasást igényelt. A szálnak meg kellett várnia az adatokat a számítás folytatása előtt, és ez a várakozási idő összeadódott, amikor a folyamatnak hideg rekordokat kellett egymás után olvasnia.

A Photon kihasználja azt a tényt, hogy a rekordok eltolásai előre ismertek, így egyszerre több olvasási műveletet is elküldhetünk. Ezt a reaktor kezeli: a dedikált munkaszálak a io_uring-on keresztül küldenek kötegeket, és a beolvasott adatokat továbbítják a hívó kódnak. Minden szál fenntartja a saját io_uring példányát; a kötegek a legkevésbé terhelt reaktornak kerülnek elküldésre. Az előre regisztrált fájlleírók és pufferkészletek csökkentik az ismétlődő olvasások többletterhelését. Ez az aszinkron végrehajtás lehetővé teszi, hogy több művelet várakozása átfedésbe kerüljön, csökkentve a késleltetés felső határát (tail latency).

A meghajtó-hozzáférések számának csökkentése

Az olvasások beküldése előtt a Photon ellenőrzi a teljes köteget a memórián belüli gyorsítótárban. Csak a hiányzó rekordokra vonatkozó kérések mennek a lemezre; az ezután beolvasott adatok pedig feltöltik a gyorsítótárat.

A gyorsítótárat kötegelt olvasásokra tervezték. Konkrétan:

  • Találat esetén nincs külön memóriafoglalás. Ehelyett az adatok a hívó kód által előre előkészített pufferbe másolódnak.
  • Az olvasó nem végez zárolás-elsajátítást (lock acquisition). Ehelyett ellenőrzi az adatverziót, és újra próbálkozik, ha az ütközik egy írással.
  • CLOCK kiszorítást (eviction) használ ahelyett, hogy minden olvasáskor megkövetelné a megosztott LRU-lista frissítését.
  • CPU-gyorsítótár előzetes lehívását (prefetching) használja, amellyel a közelgő rekordok metaadatait és adatait előre lekéri.

Ezek az optimalizálások anélkül csökkentik a késleltetést, hogy csorbítanák a számunkra fontos munkaterhelések teljesítményét.

Az index építése és frissítése a kiszolgálástól függetlenül

A Photonban az indexépítés és a lekérdezések kiszolgálása különböző csomópontokon fut. Az indexelők adatokból kiszolgálási struktúrákat alakítanak ki, míg a kiszolgáló csomópontok beolvassák ezeket, és elvégzik a visszakeresést és a rangsorolást. Ennek eredményeként az indexépítés nem verseng a keresési lekérdezésekkel a CPU-ért, és ezen feladatok erőforrásai egymástól függetlenül skálázhatók.

Ez a szétválasztás orvosolja a korábbi megvalósításban jelen lévő helyreállítási és szinkronizálási szűk keresztmetszeteket. Mivel az indexépítés a lekérdezéseket kiszolgáló fürtön belül futott, a meghibásodott csomópont helyreállítása vagy az adatok új másolatának hozzáadása a dokumentumok helyben történő újraindexelését jelenthette – ez a folyamat napokig tartott, és növelte a részleges válaszok arányát a helyreállítás során. A Photon eltávolítja ezt a csatolást; az indexelők elosztott feladatokként futnak, amelyek a kiszolgáló csomópontoktól függetlenül állítanak elő verziózott, kiszolgálásra kész indexstruktúrákat, így az index következő verziójának felépítése már nem verseng az éles forgalommal.

Az indexépítés függetlenül fut az élő lekérdezések kiszolgálásától. A Pillar exportálja a forrásadatokat, a YTsaurus shardonként készíti elő a verziózott táblákat, a párhuzamos indexelők pedig kiszolgálásra kész indexstruktúrákat írnak az objektumtárolóba. A kiszolgáló csomópontok betöltik ezeket a struktúrákat a visszakereséshez és a rangsoroláshoz; az indexelői párhuzamosság és a shardok száma egymástól függetlenül van konfigurálva.

Előkészítés és elosztott építés

Az építés az aktív index dokumentumainak kiválasztásával és a forrásexport elkészítésével kezdődik. A vezérlő rögzíti a forrásverziót, a bemeneti táblákat és a shardok várt számát. A YTsaurusban futó MapReduce feladatok előkészítik a szöveget, a metaadatokat, a töredékeket, a jellemzőket és az előre kiszámított beágyazásokat shardonként particionált verziózott táblákba. Minden indexelő streameli az előkészített táblát, felépíti a shard struktúráit, és egyesíti a szövegszegmenseket. A kész index a összetevőinek leírásával együtt felkerül az objektumtárolóba.

A shardok száma és a párhuzamosan futó indexelők száma egymástól függetlenül van konfigurálva, így az építés futhat több hullámban, vagy több gép rendelhető a párhuzamos munkavégzéshez. Az elosztott előkészítés és a párhuzamos indexelők lehetővé teszik a teljes weblapindex felépítését egyszámjegyű óra alatt, ami jelentős javulás a korábbi rendszerhez képest.

Új verzió üzembe helyezése

Az üzembe helyezés előtt a vezérlő ellenőrzi, hogy az új index készen áll-e. Ha az adatok hiányosak, az üzembe helyezés automatikusan blokkolva van.

Több kiszolgálócsoport esetén a vezérlő egyszerre egyet frissít közülük. Először eltávolítja a csoportot a bróker útvonalválasztásából, és elindítja az új indexverzión. A kérések kiszolgálása előtt a shardok egy külön melegítési (warmup) szakaszon mennek keresztül a keresési naplók alapján, amely előre feltölti a kezdeti állapotot, és zökkenőmentesebbé teszi a valódi forgalomra való áttérést. A melegítés után a vezérlő ellenőrzi az index állapotát és olvasottságát, majd visszaküldi a csoportot az útvonalválasztásba. A többi csoport ezalatt továbbra is kiszolgálja a kéréseket. Mivel a műveleti állapot perzisztálva van, az újraindítás nem kényszeríti ki az építés újrakezdését; a vezérlő újra csatlakozhat a már folyamatban lévő előkészítéshez, újrahasznosíthat egy kész eredményt, vagy folytathatja a megszakított rotációt a mentett lépéstől.

Az adatok frissítési ideje eltér a keresési vertikumok (search verticals) között. A magas frissességi követelményeket támasztó vertikumok esetében a dokumentumok kézbesítése egyszámjegyű percet vesz igénybe. Az adatok egy további másolata fél óra alatt üzembe helyezhető; a kész indexek betöltődnek és csatolódnak a shardokhoz a forrásdokumentumok újraindexelése nélkül.

A vezérlő ellenőrzi, hogy egy új index elkészült-e, majd egyszerre egy kiszolgálócsoportot rotál. Egy csoport kilép a bróker útvonalválasztásából, betölti az új verziót, felmelegíti a gyorsítótárait a keresési naplók lekérdezéseivel, és teljesíti az olvasottsági ellenőrzéseket, mielőtt visszatérne a forgalomba. A többi csoport tovább szolgál ki, a perzisztált vezérlőállapot pedig lehetővé teszi a megszakított rotáció folytatását.

Migráció és validálás a keresési vermünkön belül

Első célunk az volt, hogy a régi rendszert olyan motorra cseréljük, amely megőrzi a funkcionalitást és a keresési minőséget, miközben csökkenti a válaszidőket. A Photont szakaszosan validáltuk, a reprodukálható terheléses tesztekkel és offline minőségértékelésekkel kezdve, mielőtt az éles forgalomra áttértünk volna. A Photon mostantól a visszakeresést és a rangsorolást hajtja végre a termelési keresési vermünkben, lényegesen alacsonyabb válaszidőkkel, mint a régi rendszer.

Terheléses tesztelés és kiértékelések

A teljesítményteszteléshez építettünk egy terheléses tesztelő eszközt, amely a keresési naplóinkból származó lekérdezéseket játsza újra konfigurálható érkezési arányokkal. Összehasonlítja az eredményeket a futtatások között, és statisztikai teszteket alkalmaz annak felmérésére, hogy a megfigyelt teljesítménykülönbségek konzisztensek-e. Ezzel párhuzamosan a Photont és a régi rendszert is kiértékeltük ugyanazon adatkészleteken a belső offline kiértékelő rendszereinkben, hogy ellenőrizzük a minőségi regressziókat.

Ezek az ellenőrzések után az árnyékforgalom (shadow traffic) használatával egyidejűleg küldtünk élő lekérdezéseket mindkét motorra. Ez lehetővé tette számunkra, hogy összehasonlítsuk a teljesítményüket és az eredményeiket a termelési munkaterheléseken, mielőtt megváltoztattuk volna, hogy melyik motor szolgálja ki a felhasználókat. Ezután engedélyeztük a Photont a felhasználók kis részhalmazai számára, és fokozatosan kiterjesztettük a bevezetést, végig figyelemmel kísérve a minőséget és a teljesítményt. Az első verzió minőségi regressziók nélkül ment át az elfogadási tesztelésen, és a bevezetést addig folytattuk, amíg a Photon nem szolgálta ki az összes éles forgalmat.

Mért fejlesztések a termelésben

A gyártási munkafolyamatunkban a p99 válaszidő a régi rendszerben nagyjából 800 ms-ról a Photonban nagyjából 65 ms-ra csökkent. Ez a mérés a Photonon belüli összes szakaszt lefedi, de kizárja a magasabb szintű keresési verem későbbi szakaszait. Továbbá már nem észlelünk olyan késleltetési csúcsokat, amelyek korábban az indexverziók váltásához kapcsolódtak.

A Photon körülbelül 20%-kal kevesebb egyenértékű kiszolgálógépet használ, mint a régi rendszer tartalomcsomópontjai, miközben megközelítőleg 2,5-ször annyi adatot tárol dokumentumonkánt. A migráció után ezt a többletadatot arra használtuk fel, hogy a rangsorolási minőséget a régi rendszeré felettire javítsuk.

A Photon emellett csökkenti a memóriában tartandó adatok mennyiségét is. Ugyanezen Photon-adatkészlet RAM-ban való rögzítése (pinning) az mlock használatával becslések szerint 4,6-szor annyi rezidens memóriát igényelne, mint amennyit a Photon jelenleg használ.

A gyors Search API előbeállítás kiértékelése

A Photont a Search API új, gyors előbeállításának alapjaként is felhasználtuk, amelyet késleltetés-érzékeny munkaterhelésekhez terveztünk. Méréseink szerint a gyors előbeállítás egykereséses hívási késleltetése 160 ms p50-nél és 230 ms p95-nél, ami alacsonyabb vagy összehasonlítható más Search API-szolgáltatók saját maguk által jelentett számaival, bár a jelentett tail percentilisek eltérőek.

A gyors előbeállítást hat ügynöki benchmarkon értékeltük: WideSearch, BrowseComp, DSQA, FRAMES, SEAL-0 és SEAL-Hard. Ezen kiértékelések során a tesztelt konfigurációk közül ennek volt a legalacsonyabb becsült teljes modell-plusz-keresési költsége és a legmagasabb összesített feladatpontszáma.

A gyors előbeállítás a Photont az ügynöki munkafolyamatokhoz optimalizált rangsorolással párosítja, amellyel az alapértelmezett előbeállításéval összehasonlítható teljesítményt nyújt lényegesen alacsonyabb költséggel. Ez azonban kompromisszummal jár a szélesebb körű keresési minőség terén. A gyors előbeállítás kevesebb számítási kapacitást használ a rangsoroláshoz, mint az alapértelmezett előbeállítás. A hosszúfarkú (long-tail) lekérdezéseket, a széles lefedettséget és az eredménydiverzitást lefedő belső benchmarkokon 0,24 ponttal alacsonyabb relevanciát és megközelítőleg 3 százalékponttal alacsonyabb válaszelérhetőséget ér el. Úgy véljük, ez ésszerű kompromisszum az ügynöki munkafolyamatok esetében, mivel maga a modell következtetése (reasoning) és tudása segíthet ellensúlyozni a különbséget.

Belső visszakeresési minőség összehasonlítása az alapértelmezett PPLX előbeállítás és a PPLX Fast között. A relevancia (DCG) 2,45-ről 2,21-re csökken (0,24 pontos csökkenés); a válaszelérhetőség 0,596-ról 0,567-re csökken (2,9 százalékpontos csökkenés). A két panel eltérő, nem nulla tengelyalapvonalakat használ, így az oszlopmagasságok az arányos különbségek helyett a hézagokat hangsúlyozzák.

A mindennapos ügynöki feladatokhoz a gyors előbeállítást ajánljuk. Az időkritikusnak kevésbé számító, nagyobb kihívást jelentő vagy kétértelmű kérdések esetében az alapértelmezett előbeállítás robusztusabb minőséget kínál, igazolva a magasabb késleltetést és költséget.

Következtetés

Fokozatosan helyezzük át a keresési vermünket Rust-alapú, saját fejlesztésű infrastruktúrára. A nyílt forráskódú motor lecserélése a Photonra, a egyedi visszakeresési és rangsorolási motorunkra, a legújabb lépés. A Photon teljes ellenőrzést biztosít számunkra az adatábrázolások, az olvasások szervezése és az új indexek üzembe helyezése felett, lehetővé téve számunkra, hogy minden réteget a munkaterheléseinkhez optimalizáljunk.

A Photon gyorsabb keresést tett lehetővé a Perplexity termékeiben, és biztosítja az alapját az új, gyors előbeállításunknak a Search API-ban. A migrációt követően a p99 visszakeresési és rangsorolási késleltetés a korábbi mintegy 800 ms-ról 65 ms-ra csökkent. Kompakt adatformátumaink emellett lehetővé teszik, hogy 2,5-ször annyi adatot tároljunk dokumentumonkánt, így a visszakeresés és a rangsorolás gazdagabb dokumentuminformációkhoz férhet hozzá.

A gyors előbeállítás (fast preset) 160 ms-os p50 és 230 ms-os p95 egykereséses hívási késleltetést biztosít. A kiértékelt hat ügynöki benchmark mentén felére-harmadára, 68%-kal csökkentette a feladatonkénti becsült modell-plusz-keresési költséget az alapértelmezett előbeállításhoz képest, miközben fenntartotta a hasonló összesített feladatminőséget. Ezek az eredmények bemutatják a keresési munkaterheink köré tervezett infrastruktúra gyakorlati előnyeit, mind a Perplexity termékei, mind az API-unkat használó fejlesztők számára.

Folyamatosan javítjuk a Photon teljesítményét és tárolási hatékonyságát. Célunk, hogy nagyobb indexet és gazdagabb dokumentumadatokat támogassunk ugyanazon a hardveren, miközben a keresés gyors marad a munkaterheléseink növekedésével.

Idézet

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