Embedding-kvantálás: bináris, int8 és Matryoshka vektorok a visszakeresés minőségének elvesztése nélkül

A vektorindexek gyorsabban drágulnak, mint gondolnánk. Tízmillió chunk 1024 dimenziós float32 embeddingekkel nagyjából 41 GB nyers vektor, még bármilyen indexterhelés előtt, a HNSW-indexek pedig a memóriában szeretnek lenni. Jóval azelőtt, hogy az embedding-modell vagy az adatbázis gondot okozna, a RAM lesz a szűk keresztmetszet. A kvantálás 2–32-szeresére zsugorítja ezeket a vektorokat, és egy plusz lépéssel meglepően kevés visszakeresési minőségbe kerül.

A cikk összeveti a félpontosságot, az int8-at, a bináris kvantálást és a Matryoshka-vágást a mért megtartási számokkal, bemutatja a megvalósítást pgvectorban, és egy saját korpuszra szabott teszttervvel zárul. Magát a tárolóválasztást a pgvector vagy vektoradatbázis cikk tárgyalja.

Mit csinál valójában az embedding-kvantálás?

Ez a vektorokon végzett utófeldolgozás, nem a modellen. Ahogy a Hugging Face írása fogalmaz, a bináris kvantálás minden float32 értéket nullánál húzott küszöbbel egy bitté alakít, ami 32-szeres memória- és tárhelycsökkenést jelent; a skaláris int8 kvantálás minden értéket 256 tartomány egyikére képez le, ez 4-szeres csökkenés. A bináris vektorokat Hamming-távolsággal hasonlítjuk össze, amely nagyon olcsón számolható.

A számok nyers vektorméretek; az indexek ezen felül nagyjából arányos többletet adnak. A lényeg a nagyságrend: a bináris egy külön szervert igénylő problémát olyanná tesz, ami elfér az alkalmazás mellett.

Mennyi visszakeresési minőséget veszítesz?

A Hugging Face ezt az mxbai-embed-large-v1 modellel mérte MTEB visszakeresésen. A bináris embeddingek önmagukban a float32 teljesítmény nagyjából 92,5%-át tartották meg. Egy rescoring lépés – a jelöltek bináris lekérdezéssel való lekérése, majd float32 lekérdezés-embeddinggel való pontozása – ezt kb. 96%-ra emelte, miközben az index 32-szeres memóriamegtakarítása megmaradt. Az int8 a kettő között van, és biztonságosabb választás, ha nem fér bele egy rescoring kör.

Mit adnak hozzá a Matryoshka-embeddingek?

A kvantálás a dimenziónkénti bitek számát csökkenti. A Matryoshka Representation Learning a dimenziók számát: a modelleket úgy tanítják, hogy az első dimenziók hordozzák a legtöbb információt, és a vektor egy előtagja önmagában is használható embedding. Az eredeti tanulmány ImageNet-osztályozáson azonos pontosság mellett akár 14-szer kisebb embeddingekről számol be. Szövegre a Hugging Face írása szerint az OpenAI text-embedding-3-large 12-szeres tömörítésnél a teljesítmény 93,1%-át, a nomic-embed-text-v1.5 3-szorosnál 95,8%-ot, 6-szorosnál 90%-ot tart meg.

A vágás csak az így tanított modelleknél működik. Egy közönséges modell dimenzióinak levágása jelentősen rontja a minőséget, a klasszikus dimenziócsökkentés, például a PCA pedig embeddingeken általában gyengén teljesít, ahogy ugyanez az írás megjegyzi. Vágás előtt nézd meg a modellkártyát.

Hogyan csináld ezt pgvectorban?

A pgvector README felsorolja a HNSW-indexek korlátait: vector 2000, halfvec 4000, bit 64 000 dimenzióig. A bináris kvantálás a binary_quantize(embedding) kifejezésre épített indexszel és Hamming-távolsággal működik, ugyanaz a lekérdezés pedig az eredeti vektorokkal újrarangsorolhatja a jelölteket. A subvektor-kifejezésindexek második oszlop nélkül adják a Matryoshka-vágást.

-- Binary index for candidate search, full vectors for rescoring
CREATE INDEX chunks_bq ON chunks
  USING hnsw ((binary_quantize(embedding)::bit(1024)) bit_hamming_ops);

SELECT id, text FROM (
  SELECT id, text, embedding FROM chunks
  ORDER BY binary_quantize(embedding)::bit(1024) <~> binary_quantize($1::vector)
  LIMIT 200                                   -- 4–10x the final k
) candidates
ORDER BY embedding <=> $1::vector             -- rescore with the float query
LIMIT 20;

-- Matryoshka: index only the first 512 dimensions of a model trained for it
CREATE INDEX chunks_mrl ON chunks
  USING hnsw ((subvector(embedding, 1, 512)::vector(512)) vector_cosine_ops);

-- Half precision: half the memory, nearly no loss
CREATE INDEX chunks_half ON chunks
  USING hnsw ((embedding::halfvec(1024)) halfvec_cosine_ops);

A lekérdezésnek ugyanazt a kifejezést kell használnia, mint az indexnek, különben a Postgres szekvenciális olvasásra vált. Lekérdezésformánként egyszer ellenőrizd EXPLAIN-nel. A dedikált vektoradatbázisok, például a Qdrant, a skaláris és bináris kvantálást gyűjteménybeállításként, beépített rescoringgal kínálják; a kompromisszumok ugyanazok.

Melyik technikát válaszd?

Hogyan teszteld a kvantálást a saját adataidon?

1. Vedd a visszakeresési értékelőkészletedet, ismert releváns chunkokkal rendelkező kérdéseket, ahogy a RAG értékelése cikkben leírtam.
2. Mérd a recall@10 és recall@50 értéket float32 alapvonallal.
3. Ismételd meg halfvec, int8, rescoring nélküli bináris és a végső k 4- és 10-szeresével végzett rescoringos bináris változatra.
4. Egy táblázatba írd fel az indexméretet, a p95 lekérdezési késleltetést és a felidézést, és válaszd a felidézési kereteden belüli legolcsóbb lehetőséget.

Utána futtasd le a teljes pipeline-t, a hibrid kereséssel és a rerankerrel együtt az Éles RAG-pipeline cikkből. A reranker gyakran elfedi az első lépcső kis felidézési veszteségeit, ez is oka annak, hogy a kvantált első lépcsős visszakeresés a gyakorlatban jól működik.

Források

1. Hugging Face: Binary and Scalar Embedding Quantization for Significantly Faster and Cheaper Retrieval (Mar 2024)
2. Kusupati et al.: Matryoshka Representation Learning (2022)
3. pgvector README: halfvec, bit, binary quantization and subvector indexing