A turbopuffer szerint száz milliszekundumokat farag le a natív embedding

A külső embedding lassította a keresést

A turbopuffer szeptember 29-i bejegyzése szerint a szolgáltatás korábban a BYOE, vagyis a „bring your own embeddings” megközelítést használta. Az ügyfelek maguk építették és működtették az embeddingfolyamatot, ami lehetőséget adott arra, hogy az egyes területekre, például pénzügyre, jogra vagy programozásra szabják azt.

A vállalat tapasztalata szerint sok ügyfél ezt már inkább teherként élte meg. Az embeddingfolyamat kezelése különböző programozási felületekkel, kötegeléssel, újrapróbálkozásokkal és időkorlátokkal járhatott.

A korábbi architektúrában az embedding egy másik számítógépen futott, ezért a turbopuffer lekérdezéstervezője nem látta ezt a lépést. A szolgáltató leírása szerint az embedding sorba rendeződött a lekérdezés végrehajtásával. A dokumentumvektorok pontozása csak a lekérdezési vektor elkészülte után kezdődhetett meg, miközben az ügyfél várakozott.

A lekérdezéstervező párhuzamosítja a munkát

A natív embeddinggel a vektorizálás bekerül a turbopuffer keresési folyamatába. Így a rendszer a kezdeti lekérdezés-végrehajtás egyes részeivel párhuzamosan indíthatja el az embeddinget, még azelőtt, hogy ténylegesen szükség lenne a vektorra.

A turbopuffer szerint az index névteréhez tartozó metaadatok beolvasása nem függ a lekérdezési vektortól, ezért ez a művelet a GPU embeddingfeladatának futása közben is elvégezhető. A klaszterek kiválasztásához és a dokumentumok pontozásához továbbra is szükség van a lekérdezési vektorra, így a keresés szkennelési szakasza megvárja az embedding befejezését.

A vállalat közlése szerint a rendszer jelenleg olvasási és írási műveleteknél is párhuzamosítja az embeddinget. A turbopuffer folyamatosan keresi annak lehetőségét, hogy a függőséget még későbbre tolja a folyamatban.

A Linear és a Readwise már tesztelte

A Linear és a Readwise a bétaidőszakban vezette be a natív embeddinget. A turbopuffer állítása szerint a Linear 150 milliszekundummal csökkentette az embeddingfolyamat késleltetését, a Readwise pedig a medián embeddingkésleltetést nyolcszorosára mérsékelte.

A szolgáltató szerint a natív embedding elsősorban azokhoz a munkafolyamatokhoz illeszkedik, amelyekben minden írási és olvasási művelethez új embedding készül. Ha egy lekérdezési embedding hosszabb ideig vagy több névtérben újra felhasználható, gazdaságosabb lehet elkerülni az újabb számítást.

Az ügyfelek ezért csak íráskor, csak lekérdezéskor, vagy egyáltalán nem is helyezik át az embeddinget a turbopufferbe. A későbbi verziók automatikusan gyorsítótárazhatják ugyanazon dokumentum ismételt embeddinghívásait, és a szolgáltató ezt a megtakarítást továbbadná az ügyfeleknek.

Újabb keresési alrendszerek költözhetnek a szolgáltatásba

A turbopuffer hosszabb távú célja, hogy a keresési rendszer nagyobb részét egyben optimalizálja. A vállalat szerint az egymástól elszigetelten fejlesztett alrendszerek helyi javulást hozhatnak, miközben a teljes folyamat kevésbé hatékony marad.

A cég adatbázis-fejlesztéseken dolgozik, amelyek lehetővé tennék egy teljes névtér háttérben, aszinkron módon végzett újra-embeddingelését. Ez a turbopuffer szerint a teljesítmény mellett a relevancia javítására is lehetőséget adhat, például új modellek értékelésével és a legjobban teljesítő modellre történő automatikus átállással.

A következőként említett fejlesztések között szerepel a natív újrarangsorolás, a jobb dokumentumértelmezés és darabolás, valamint a keresési ügynökök. A turbopuffer a szolgáltatásáról azt írja, hogy több mint 1 billió dokumentumot tárol, másodpercenként több mint 10 millió írást kezel, és másodpercenként több mint 25 ezer lekérdezést szolgál ki.