RaBitQ-val gyorsítja és tömöríti a vektoros keresést a LanceDB

A bináris tárolás csökkenti a vektorok méretét

A legtöbb beágyazási modell 32 bites lebegőpontos, vagyis float32 vektorokat állít elő. Ezek pontosak, viszont jelentős tárhelyet igényelnek, és a lekérdezések feldolgozása is hosszabb lehet. A LanceDB szerint egy 1024 dimenziós float32 vektor 4 KB méretű, RaBitQ-val és a korrekciós tényezőkkel együtt viszont körülbelül 136 bájtra csökkenthető.

A LanceDB eddig alapértelmezett tömörítési és keresési módszerként az IVF_PQ-t, vagyis az invertált fájlos, termékkvantálást használta. Ez sok feladathoz megfelelő, de kódolókönyv, úgynevezett codebook betanítását igényli. Az adat eloszlásának változásakor újratanításra lehet szükség, a távolságok becslése pedig lassabb lehet.

A RaBitQ minden normalizált vektor bináris előjelmintáját tárolja. A módszer a vektort egy véletlenszerűen elforgatott hiperkocka legközelebbi csúcsához rendeli az egységgömbön, így minden dimenzióhoz egy bit tartozik. A LanceDB szerint a kvantálási hiba a dimenziószám növekedésével csökken, ezért a megoldás különösen a 512, 768 és 1024 dimenziós beágyazásoknál lehet hatékony.

Gyorsabb indexelés, kevesebb újratanítás

Az index létrehozásakor a LanceDB a vektorokat egy centroid köré rendezi és normalizálja, majd a bináris reprezentációt két korrekciós értékkel együtt tárolja. Az egyik a vektor és a centroid távolsága, a másik a kvantált és a normalizált vektor skaláris szorzata. A lekérdezés során a rendszer ugyanilyen módon dolgozza fel a bemenetet, legyen szó szövegről, képről, hangról vagy videóról.

Az összehasonlítás ezután gyors bináris skaláris szorzásokkal történik, a korrekciós értékek pedig javítják a távolságbecslés pontosságát. Az IVF_PQ-val szemben a RaBitQ nem igényel kódolókönyv-betanítást és a vektorok részvektorokra bontását. Ez a LanceDB szerint gyorsabb indexelést, egyszerűbb karbantartást és stabilabb eredményeket jelenthet adatfrissítések után.

Mindkét módszer jelölteket választ ki, majd teljes pontosságú vektorokkal újrarangsorolja őket. A LanceDB külön kiemeli, hogy ezt a lépést RaBitQ használatakor is el kell végezni, mivel a jelöltgenerálás közelítő számításokra épül.

A teszteken a RaBitQ gyorsabbnak bizonyult

A LanceDB két nyilvános adathalmazon hasonlította össze a módszereket, egy OpenAI beágyazásokat használó DBpedia 1M és egy sűrű, 960 dimenziós vektorokat tartalmazó GIST1M adathalmazon. A méréseket Intel 12400F processzorral, 1 TB-os SSD-vel és grafikus processzor nélkül végezték.

A DBpedia 1M esetében az IVF_PQ körülbelül 92 százalékos recall@10 értéket, 350 QPS áteresztőképességet és nagyjából 85 másodperces indexépítési időt ért el. A RaBitQ eredménye 96 százalék feletti recall@10, 495 QPS és körülbelül 75 másodperces indexépítés volt.

A GIST1M adathalmazon az IVF_PQ körülbelül 90 százalékos recall@10 értéket, 420 QPS áteresztőképességet és hozzávetőleg 130 másodperces indexépítési időt produkált. A RaBitQ 94 százalékos recall@10 értéket, 540 és 765 QPS közötti áteresztőképességet, valamint körülbelül 21 másodperces indexépítési időt ért el.

A LanceDB szerint a RaBitQ a tesztelt processzoron már most felülmúlta az IVF_PQ-t. A vállalat úgy látja, grafikus processzorokon tovább nőhet a különbség, mivel a RaBitQ műveletei könnyebben párhuzamosíthatók.

Az IVF_PQ továbbra is az alapértelmezett

A LanceDB nem váltja le az IVF_PQ-t: ez marad az alapértelmezett kvantálási módszer az általános feladatokhoz. A RaBitQ különösen nagy adathalmazoknál, 512 dimenzió feletti beágyazásoknál és multimodális gyűjteményeknél lehet hasznos, ahol egyszerre fontos a tárhely csökkentése, a gyors lekérdezés és a magas visszakeresési pontosság.

A vállalat szerint a megoldás RAG-rendszerekben, multimodális keresésben és elemzési feladatokban is lehetővé teszi több beágyazás online tárolását. Az extended-RaBitQ kutatási változata dimenziónként 2, 3 vagy 4 bitet is használhat, ez azonban a LanceDB-ben még nem érhető el. A RaBitQ most az IVF_PQ mellett választható lehetőségként jelent meg.