Multimodális RAG ColPalival: oldalképek, többvektoros költségek és mikor nyernek

A multimodális RAG ColPalival a dokumentumok visszakeresésének első lépését változtatja meg ott, ahol a jelentés az elrendezésben van: szkennelt űrlapok, diák, táblázatok és ábrák. Oldalanként nem szöveget és darabokat állítunk elő, hanem az oldalt képként rendereljük, egy látás-nyelvi modellen futtatjuk, és képpatchenként egy beágyazó vektort tartunk meg. A lekérdezést ezekkel a patch-vektorokkal hasonlítjuk össze a MaxSim nevű késői interakciós pontszámmal. A pipeline elveszíti az OCR-t, az elrendezés-felismerést, a képleírást és a darabolást, cserébe jóval nagyobb indexet és nehezebb lekérdezési utat kap.

A csere mindkét irányban valós. A ViDoRe v1-en, az oldalszintű benchmarkon, amelyet a ColPali vezetett be, a modell 81,3 nDCG@5 pontot ér el, a papírban szereplő legjobb szövegfeldolgozó pipeline 67,0 pontjával szemben; a különbség ábráknál, infografikáknál és táblázatoknál a legnagyobb. Ugyanez a felépítés oldalanként nagyjából 260 KB float16 tárhelyet igényel, és lekérdezéskor brute-force pontozást kényszerít ki. Ez a cikk bemutatja a mechanizmust, a tárhelyszámításokat, a gyakorlativá tevő tömörítési lehetőségeket, a támogató vektoradatbázisokat, és azokat az eseteket, ahol a feldolgozott szöveg még mindig nyer. A számok 2026 októberére vonatkoznak, hacsak a forrás másként nem datálja őket.

Mit vált ki a ColPali alapú multimodális RAG?

A feldolgozási pipeline-t cseréli le vizuálisan gazdag oldalaknál. Egy hagyományos PDF-pipeline elrendezés-felismerést, OCR-t, képleírást és darabolást futtat, mielőtt bármely szövegmodell látná az oldalt; minden lépés késleltetést ad, hibát termel, és olyan hely, ahol egy táblázat elveszítheti az oszlopfejléceit. A ColPali-megközelítés ezt az egészet kihagyja. Az oldalkép egyenesen egy látás-nyelvi modellbe kerül, a kimenet pedig olyan vektorhalmaz, amely képrégiókhoz kötve marad.

A tanulmány indexelési számai mutatják a változás nagyságrendjét. Egy GCP g2-standard-8 gépen NVIDIA L4-gyel a feldolgozási út (elrendezés 0,81 s, OCR 2,67 s, képleírás 3,71 s, kódolás 0,03 s) oldalanként 7,22 s; a ColPali oldalanként 0,39 s, a SigLIP-alapvonal 0,12 s. A feldolgozás kihagyása a legnagyobb egyedi költségmegtakarítás, és egyben kiveszi azokat az OCR-hibákat, amelyek különben beépülnének az indexbe (ColPali-tanulmány).

A csere nem ingyenes. Ugyanaz az oldal most mintegy ezer vektort állít elő egy vagy néhány darab helyett, a lekérdezési oldalon pedig szintén kell egy látás-kódoló. A tanulmányban a lekérdezés kódolása 1-es kötegméretnél kb. 30 ms, szemben a BGE-M3 körülbelül 2 ms-ával, a késői interakciós pontozás pedig 1000 oldalonként nagyjából 1 ms-ot ad hozzá. Az indexelés olcsóbb lesz, a lekérdezés drágább, a tárhelyköltség a kettő között van.

Hogyan működik a MaxSim késői interakciós pontozás?

A MaxSim úgy pontozza a lekérdezést egy oldallal szemben, hogy minden lekérdezési token megkeresi a legjobb találatát az oldal vektorai között, majd ezeket a legjobb találatokat összegzi. Lekérdezési tokenenként vegyük az összes oldalvektorra vett skaláris szorzat maximumát, a maximumokat pedig adjuk össze. Az oldalakat egyszer, offline kódoljuk. Lekérdezéskor csak a kérdés kódolódik, az illesztés a tárolt patch-vektorok ellen történik. Ezért hívják késői interakciónak: a lekérdezés és az oldal csak a pontozáskor találkozik, nem a kódolón belül.

A ColPaliban a PaliGemma-3B egy SigLIP-So400m látás-kódolóval minden oldalt 32 × 32 = 1024 patch rácsra oszt. Hat utasítástokent fűzünk hozzá, és mind az 1030 vektort 128 dimenzióra vetítjük. A Vespa-leírás ugyanezt a felépítést írja le. A pontozás magja rövid:

import numpy as np

def maxsim(query_vecs, page_vecs):
    # query_vecs: (query_tokens, 128), page_vecs: (patches, 128)
    sims = query_vecs @ page_vecs.T      # (query_tokens, patches)
    return sims.max(axis=1).sum()        # best patch per query token, summed

Mivel a pontszám a lekérdezési tokenenkénti maximumok összege, az is visszakereshető. Látható, melyik patch nyert az egyes tokenekért, és hőtérképet rajzolhatunk az oldalra. Ez segít a visszakeresés hibakeresésében, és megmutatja az olvasónak, miért adtunk vissza egy oldalt, ami fontos, ha a választ idézni kell.

Miért lesz ilyen nagy a többvektoros tárolás?

Az egyvektoros index dokumentumonként egy vektort tárol, így mérete a dokumentumok számával nő. A többvektoros index tokenenként vagy patchenként egy vektort tárol, így mérete a dokumentumok száma szorozva dokumentumonkénti vektorszámmal nő. A ColPali-tanulmány oldalanként 257,5 KB-ot ad meg float16-ban, szemben a BGE-M3 darab-beágyazás 8,60 KB-jával. Ez nagyjából harmincszoros, a tanulmány maga pedig a poolingot és a binarizálást jelöli meg orvosságként.

Egymillió oldalra vetítve a táblázat mutatja a különbséget. Az adatok az EVIE-tanulmány tárolási elemzéséből származnak (arXiv 2610.11553), amely a jelenlegi ColQwen-jellegű ellenőrzőpontokat hasonlítja össze egy 2048 dimenziós egyvektoros alapvonallal.

Ebből két dolog következik. Először: a költséget az oldalankénti vektorszám hajtja, nem önmagában a dimenzió, így a 2304 vektort 4096 dimenzióval használó modell egészen más tárhelyosztályba esik, mint a 768 vektor 320 dimenzióval. Másodszor: a HNSW-gráfok rosszul kezelik a MaxSimet. A Qdrant dokumentációja megjegyzi, hogy többvektornál a HNSW általában ki van kapcsolva, így a lekérdezések a jelölteket közvetlenül pontozzák, nem gráfon járnak be. Ez néhány száz jelölt-vektoros lekérdezésnél elfogadható, nagy korpusz teljes átvizsgálásánál viszont drága.

Hogyan lesz a többvektoros visszakeresés megfizethető?

Három eszköz végzi a munka nagy részét: kevesebb vektor oldalanként, kevesebb bit vektoronként, és egy olcsó első szakasz, amely szűkíti a jelöltek körét, mielőtt a pontos MaxSim lefut. A gyakorlatban a csapatok ezeket kombinálják.

• Token-poolozás. A szomszédos patch-vektorok átlagolása csökkenti a számukat. A ColPali saját mérése szerint a 3-as poolfaktor a vektorok 66,7%-át eltávolítja, és a teljesítmény 97,8%-át megtartja. A Sentence Transformers v6 hierarchikus token-poolozást kínál alapfunkcióként; az 4874 szakaszos NQ-példában a 3-as faktor 608 414 vektort 204 407-re csökkent (311,5 MB-ról 104,7 MB-ra, float32-ben).
• Kvantálás. Qdrant példája egymillió dokumentumra, dokumentumonként 1024 × 128 vektorral, float32-ben 512 GB-ot igényel. 1 bitnél 16 GB, 1,5 bitnél 21,3 GB, 2 bitnél 32 GB, mindez az utólagos újrapontozás előtt. A turbo4 adattípus vektoronként 4 bitet tárol a lemezen; öt BEIR-adatkészleten, ColBERT-többvektorokkal a float32 NDCG@20 99,6%-át tartja meg ugyanazon a MaxSim-újrapontozási úton. Az 1 bites kvantálás turbo4 fölé kapcsolva több minőséget veszít (Recall@20 4,1%-kal csökken) és 27,5%-os mediánlatenciát ad hozzá.
• Bináris Hamming-távolsággal. A Vespa szerint a Hamming-távolságot használó bináris vektorok 32-szer kevesebb tárhelyet igényelnek, és mintegy 3,5-szer gyorsabbak a float skaláris szorzatnál. DocVQA nDCG@5 mutatón a float alapvonal 52,4, a tisztán bináris 49,5, a bináris float-újrapontozással 51,6.
• PLAID. A ColBERTv2 motorja, a PLAID maradékkompresszióval a késői interakció tárhelyigényét hatszorosára–tízszeresére csökkenti (ColBERTv2, arXiv 2112.01488).
• MUVERA. A NeurIPS 2024-es munka minden többvektoros halmazt rögzített dimenziós kódolássá alakít, így egy egyvektoros MIPS-index adhat jelölteket, majd pontos MaxSim-újrarangsorolás következik. A tanulmány a PLAID-hez képest körülbelül 10%-kal magasabb visszahívást és körülbelül 90%-kal kisebb késleltetést említ.

A kétszakaszos visszakeresés az a forma, amely működik. A Qdrant 2024-es kísérlete 20 000 oldalon oldalanként az 1030 vektort 38-ra vonta össze, a legjobb 200-at visszakérte, és azokat teljes felbontású MaxSimmel újrapontozta. A bejegyzés 13-szoros visszakeresési gyorsulást közöl. Ez egy szállító 2024-es benchmarkja, nem általános állandó; a lényeg a szerkezet: az olcsó szakasz dönt a visszahívásról, a pontos szakasz a sorrendről.

Mivel szolgálhatók ki ezek a modellek 2026-ban?

A tanulmány szerzőinek könyvtára, a colpali-engine elavult; új projektekhez a Sentence Transformers v6 az ajánlott. Ennek MultiVectorEncoder osztálya betölti a ColPali, ColQwen2, PyLate és ColBERTv2 ellenőrzőpontokat, és a maxsim vagy a meanmaxsim függvénnyel számolja a MaxSimet. A Sentence Transformers v6.0.0 transformers v5-öt és legalább 2.2-es torch-ot követel meg. Nagyobb léptékű kiszolgáláshoz a vLLM-ben van ColQwen3 implementáció token_embed poolinggal és MaxSim-pontozással, így a kódoló ugyanazon az inferenciaveremen futhat, mint a RAG-rendszer többi része. Szállítás előtt ellenőrizze a licenceket: a ColPali a Gemma feltételei alatt áll, a ColQwen2 és ColQwen2.5 ellenőrzőpontok és a colSmol Apache-2.0 licencűek, a TomoroAI colqwen3 modellek szintén Apache-2.0-sak.

Mikor nyernek az oldalképek a feldolgozott szöveggel szemben?

Az oldalképek akkor nyernek, ha a válasz az elrendezéstől vagy nem szöveges tartalomtól függ: egy ábra, egy diagram jelmagyarázata, összevont fejlécű táblázat, egy szkennelt űrlap. A ViDoRe v1 tanulmányában 79,1 szemben 35,7 az ArxivQA-n, 81,8 szemben 71,9 az InfoVQA-n és 83,9 szemben 69,1 a TabFQuAD-on (nDCG@5). A benchmark kifejezetten ábrákat és táblázatokat vizsgál, így a különbségek azt tükrözik, amit mér.

A benchmarkok tovább léptek. A ViDoRe v1 közel telített, a vezető modellek 90 nDCG@5 fölött vannak. A ViDoRe v2 vakon kontextuális kérdéseket, hosszú és dokumentumokon átívelő kérdéseket, valamint négy többnyelvű adatkészletet ad hozzá. A ViDoRe v3 (ACL 2026) lényegesen nehezebb: tíz adatkészlet, körülbelül 26 000 oldal, 3099 emberi ellenőrzésű kérdés hat nyelven. A vizuális visszakeresők felülmúlják a szövegalapúakat, és a késői interakció javítja a rangsorolást, de a jelenlegi modellek még elbuknak a nem szöveges elemeken és a finom vizuális hivatkozáson. A legjobb közölt eredmény körülbelül 66,75 nDCG@10 (EVIE-8B), szemben a tomoro-colqwen3-embed-8b 61,60 pontjával. Ezek tanulmányi számok; mielőtt rangsort idéz, ellenőrizze a modellkártyákat és a benchmark oldalait, mert az élő nézetek változnak.

A szövegnél maradás esetei valósak. A digitálisan készült PDF-ek tiszta szövegrétegekkel ritkán igényelnek látásmodellt a megfelelő bekezdés megtalálásához, a pontos egyezésen vagy mezőszintű szűrőn pedig szöveges alapon könnyebb gondolkodni. A feldolgozott darabok emellett idézhető szakaszt adnak. Néhány ezer oldal CPU-s gépen rossz illeszkedés egy többvektoros indexhez. Az OCR-t megterhelő írásrendszerek tesztelendő kérdés, nem bizonyított előny: egyetlen ViDoRe-felosztás sem CJK-korpusz, ezért ezeket a saját oldalain teszteljék.

Mely vektoradatbázisok támogatják a többvektorokat?

A támogatás egyenetlen. A Qdrant a v1.10.0 óta natív többvektoros mezőt kínál max_sim összehasonlítóval, és kikényszeríti azt a korlátot, hogy az alvektorok száma szorozva a dimenzióval 1 048 576 alatt maradjon; egy 128 dimenziós ColPali-oldal ezt könnyedén teljesíti. A Vespa MaxSimet tenzoros rangsorolási kifejezésként írja le, és támogatja a Hamming-távolságú bináris vektorokat. Postgresben a pgvectornak nincs natív többvektoros típusa; a 970-es funkciókérés dokumentálja a megkerülő megoldásokat: tokenenként egy sor, alkalmazásoldali MaxSim. A VectorChord adja a termelési útvonalat: vektortömbök, a MaxSimhez való @# operátor és vchordrq index (VectorChord-dokumentáció).

A táblázat csak azt tükrözi, amit a hivatkozott források igazolnak. Mielőtt egy funkcióra építene, ellenőrizze az egyes termékek aktuális verzióját.

Hogyan döntsön, és mit teszteljen először?

Kezdje a saját oldalaival, ne egy ranglistával. Építsen egy kis kiértékelő halmazt 100–300 valódi kérdéssel oldalszintű címkékkel, futtassa a feldolgozott szöveget és az oldalképeket ugyanazzal a visszakeresési keretrendszerrel, és hasonlítsa össze a visszahívást azon a küszöbön, amelyet a generátora ténylegesen használ. Ezután ellenőrizze:

1. Korpuszméret és növekedés: oldalak × vektorok oldalanként × bájt vektoronként, mielőtt adatbázist választ.
2. Oldalösszetétel: hány oldal függ táblázatoktól, ábráktól vagy szkenektől, és hány tiszta, digitális szöveg?
3. GPU-keret: a tanulmány felállásában a lekérdezés kódolása a szöveges út körülbelül tizenötszöröse; ezt a lekérdezési úton tervezze be, ne csak az indexelésnél.
4. Újrarangsorolás: döntse el, hogy a poolozott vagy bináris vektorokkal dolgozó jelöltszakasz táplál-e pontos MaxSim-újrarangsorolást.
5. Licencek: ellenőrizze, hogy az ellenőrzőpont licence engedi-e a felhasználását.
6. Hivatkozások: győződjön meg róla, hogy a válasz oldalrégióra tud mutatni, és a válasszal együtt az oldalképet is visszaadja.

Ha ebből demót építenék, a saját Nuxt-oldalamon lévő, renderelt oldalakra mutató keresőmezővel kezdeném, ahol már futtatok LLM-funkciókat. Ez terv, nem működő rendszer. A szöveges kiindulóponthoz olvassa a PDF-feldolgozás RAG-hoz és a beágyazás-kvantálás bináris és Matryoshka módszerrel cikket; a tárolóoldalhoz a Qdrant cikk az egyvektoros beállítást írja le, amely továbbra is az alapértelmezés. A MI-mérnöki munkámat a MI-mérnök oldal foglalja össze.

Források

1. ColPali: Efficient Document Retrieval with Vision Language Models (arXiv:2407.01449)
2. ViDoRe V2 benchmark (arXiv:2505.17166)
3. ViDoRe V3 benchmark (arXiv:2601.08620)
4. EVIE: storage and benchmark analysis for ColQwen-family models (arXiv:2610.11553)
5. Vespa: scaling ColPali to billions
6. Qdrant documentation: vectors, multivectors and the max_sim comparator
7. Qdrant: ColPali optimization with pooling and two-stage retrieval (2024)
8. Qdrant: turbo4 multivector search tutorial
9. Sentence Transformers v6.0.0 release notes
10. illuin-tech/colpali repository and model table
11. MUVERA: multi-vector retrieval via fixed dimensional encodings (NeurIPS 2024)
12. VectorChord documentation: indexing with MaxSim operators