Multimodales RAG mit ColPali: Seitenbilder, Multi-Vektor-Kosten und wann sie gewinnen

Multimodales RAG mit ColPali verändert die erste Retrieval-Stufe für Dokumente, deren Bedeutung im Layout steckt: gescannte Formulare, Folien, Tabellen und Diagramme. Statt jede Seite in Text und Chunks zu zerlegen, rendern Sie die Seite als Bild, lassen ein Vision-Language-Modell darüber laufen und behalten einen Embedding-Vektor pro Bild-Patch. Eine Anfrage wird mit einem Late-Interaction-Score namens MaxSim gegen diese Patch-Vektoren gematcht. Die Pipeline verliert OCR, Layouterkennung, Bildbeschreibung und Chunking und gewinnt dafür einen deutlich größeren Index und einen schwereren Anfragepfad.

Der Tausch wirkt in beide Richtungen. Auf ViDoRe v1, dem Seiten-Benchmark, den ColPali eingeführt hat, erreicht das Modell 81,3 nDCG@5, gegenüber 67,0 für die beste Parsing-Pipeline mit Text im Paper; der Abstand ist bei Abbildungen, Infografiken und Tabellen am größten. Dasselbe Design kostet rund 260 KB Float16-Speicher pro Seite und erzwingt beim Abfragen Brute-Force-Scoring. Dieser Artikel erklärt den Mechanismus, die Speicherrechnung, die Kompressionswege, die Vektordatenbanken mit Unterstützung und die Fälle, in denen geparster Text weiterhin gewinnt. Zahlen gelten Stand Oktober 2026, sofern eine Quelle nicht anders datiert ist.

Was ersetzt multimodales RAG mit ColPali?

Es ersetzt die Parsing-Pipeline für visuell reiche Seiten. Eine klassische PDF-Pipeline führt Layouterkennung, OCR, Bildbeschreibung und Chunking aus, bevor ein Textmodell etwas sieht; jeder Schritt kostet Latenz, erzeugt Fehler und ist eine Stelle, an der eine Tabelle ihre Spaltenköpfe verliert. Der ColPali-Ansatz überspringt all das. Das Seitenbild geht direkt in ein Vision-Language-Modell, und die Ausgabe ist eine Menge von Vektoren, die an Bildregionen gebunden bleiben.

Die Indexierungszahlen des Papers zeigen das Ausmaß. Auf einer GCP-g2-standard-8-Maschine mit NVIDIA L4 braucht der Parsing-Pfad (Layout 0,81 s, OCR 2,67 s, Bildbeschreibung 3,71 s, Encoding 0,03 s) 7,22 s pro Seite; ColPali braucht 0,39 s pro Seite, die SigLIP-Baseline 0,12 s. Das Überspringen des Parsings ist die größte einzelne Kostenersparnis, und es entfernt zugleich die OCR-Fehler, die sonst im Index landen würden (ColPali-Paper).

Der Tausch ist nicht kostenlos. Dieselbe Seite erzeugt jetzt etwa tausend Vektoren statt eines oder weniger Chunks, und auch die Anfrageseite braucht einen Vision-Encoder. Im Paper dauert die Anfrage-Kodierung bei Batchgröße eins etwa 30 ms, gegenüber rund 2 ms für BGE-M3, während das Late-Interaction-Scoring etwa 1 ms pro 1.000 Seiten hinzufügt. Die Indexierung wird billiger, die Abfrage teurer, und die Speicherkosten liegen dazwischen.

Wie funktioniert das Late-Interaction-Scoring mit MaxSim?

MaxSim bewertet eine Anfrage gegen eine Seite, indem jedes Anfrage-Token unter den Vektoren der Seite seinen besten Treffer sucht und diese besten Treffer dann summiert. Für jedes Anfrage-Token nehmen Sie das Maximum des Skalarprodukts über alle Seitenvektoren; die Maxima addieren Sie. Seiten werden einmal offline kodiert. Zur Abfragezeit wird nur die Anfrage kodiert, und das Matching läuft gegen die gespeicherten Patch-Vektoren. Deshalb heißt das Verfahren Late Interaction: Anfrage und Seite treffen sich erst beim Scoring, nicht innerhalb des Encoders.

Bei ColPali teilt PaliGemma-3B mit einem SigLIP-So400m-Vision-Encoder jede Seite in ein Raster von 32 × 32 = 1.024 Patches. Sechs Instruktions-Token werden angehängt, und jeder der 1.030 Vektoren wird auf 128 Dimensionen projiziert. Die Vespa-Beschreibung beschreibt denselben Aufbau. Der Kern des Scorings ist kurz:

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

Weil der Score eine Summe über die Maxima pro Anfrage-Token ist, lässt er sich auch nachvollziehen. Sie sehen, welcher Patch jedes Anfrage-Token gewonnen hat, und können eine Heatmap über die Seite legen. Das hilft beim Debugging des Retrievals und zeigt einem Leser, warum eine Seite zurückgegeben wurde, was wichtig ist, wenn die Antwort zitiert werden muss.

Warum wird der Multi-Vektor-Speicher so groß?

Ein Single-Vektor-Index speichert einen Vektor pro Dokument, seine Größe wächst also mit der Dokumentenzahl. Ein Multi-Vektor-Index speichert einen Vektor pro Token oder Patch, seine Größe wächst also mit Dokumenten mal Vektoren pro Dokument. Das ColPali-Paper nennt 257,5 KB pro Seite in Float16, gegenüber 8,60 KB für ein BGE-M3-Chunk-Embedding. Das ist etwa das Dreißigfache, und das Paper selbst verweist auf Pooling und Binarisierung als Abhilfe.

Auf eine Million Seiten hochgerechnet zeigt die Tabelle die Spanne. Die Werte stammen aus der Speicheranalyse des EVIE-Papers (arXiv 2610.11553), das aktuelle ColQwen-artige Checkpoints mit einer 2048-dimensionalen Single-Vektor-Baseline vergleicht.

Daraus folgen zwei Dinge. Erstens treibt die Zahl der Vektoren pro Seite die Kosten, nicht allein die Dimension: Ein Modell mit 2.304 Vektoren zu je 4.096 Dimensionen liegt in einer ganz anderen Speicherklasse als eines mit 768 Vektoren zu 320 Dimensionen. Zweitens kommen HNSW-Graphen mit MaxSim schlecht zurecht. Die Qdrant-Doku merkt an, dass HNSW für Multivektoren meist deaktiviert ist; die Abfragen bewerten die Kandidaten dann direkt, statt einen Graphen zu durchlaufen. Das ist für einige Hundert Kandidatenvektoren pro Anfrage vertretbar, bei einem vollen Scan eines großen Korpus aber teuer.

Wie wird Multi-Vektor-Retrieval bezahlbar?

Drei Hebel leisten den größten Teil der Arbeit: weniger Vektoren pro Seite, weniger Bits pro Vektor und eine günstige erste Stufe, die die Kandidatenmenge eingrenzt, bevor exaktes MaxSim läuft. In der Praxis kombinieren Teams sie.

• Token-Pooling. Das Mitteln benachbarter Patch-Vektoren verringert die Anzahl. ColPalis eigene Messung zeigt, dass Pool-Faktor 3 66,7 % der Vektoren entfernt und 97,8 % der Leistung behält. Sentence Transformers v6 bietet hierarchisches Token-Pooling als reguläre Option; im NQ-Beispiel mit 4.874 Passagen reduziert Faktor 3 608.414 Vektoren auf 204.407 (311,5 MB auf 104,7 MB, float32).
• Quantisierung. Qdrants Beispiel eines Index mit einer Million Dokumenten zu je 1.024 × 128 Vektoren braucht 512 GB in float32, dazu 16 GB bei 1 Bit, 21,3 GB bei 1,5 Bit und 32 GB bei 2 Bit, jeweils vor dem Rescoring. Der Datentyp turbo4 speichert Vektoren mit 4 Bit pro Dimension auf der Platte; auf fünf BEIR-Datensätzen mit ColBERT-Multivektoren behält er 99,6 % des float32-NDCG@20 über denselben MaxSim-Rescoring-Pfad. 1-Bit-Quantisierung obendrauf kostete mehr Qualität (Recall@20 minus 4,1 %) und 27,5 % Median-Latenz.
• Binär mit Hamming-Distanz. Vespa berichtet, dass binäre Vektoren mit Hamming-Distanz den 32-fachen Speicherplatz sparen und etwa 3,5-mal schneller laufen als Float-Skalarprodukte. Bei DocVQA nDCG@5 erreicht die Float-Baseline 52,4, rein binär 49,5 und binär mit Float-Rerank 51,6.
• PLAID. Die ColBERTv2-Engine PLAID reduziert den Platzbedarf der Late Interaction durch Residual-Kompression um das Sechs- bis Zehnfache (ColBERTv2, arXiv 2112.01488).
• MUVERA. Die NeurIPS-2024-Arbeit wandelt jede Multi-Vektor-Menge in eine Kodierung fester Dimension um, sodass ein Single-Vektor-MIPS-Index Kandidaten liefern kann, gefolgt von exaktem MaxSim-Rerank. Das Paper berichtet etwa 10 % mehr Recall und etwa 90 % weniger Latenz als PLAID.

Zweistufiges Retrieval ist die Form, die funktioniert. Das Qdrant-Experiment von 2024 mit 20.000 Seiten fasste die 1.030 Vektoren pro Seite auf 38 zusammen, holte die besten 200 und bewertete diese mit vollauflösendem MaxSim neu. Der Beitrag nennt ein 13-faches Tempo beim Retrieval. Das ist der Benchmark eines Anbieters von 2024 und keine allgemeine Konstante; wichtig ist die Struktur: Die günstige Stufe bestimmt den Recall, die exakte die Reihenfolge.

Welche Werkzeuge bedienen diese Modelle 2026?

Die Bibliothek der Paper-Autoren, colpali-engine, ist veraltet; neue Projekte verweist man auf Sentence Transformers v6. Dessen MultiVectorEncoder lädt ColPali-, ColQwen2-, PyLate- und ColBERTv2-Checkpoints und berechnet MaxSim mit maxsim oder meanmaxsim. Sentence Transformers v6.0.0 setzt transformers v5 und torch ab 2.2 voraus. Für den Betrieb in größerem Maßstab hat vLLM eine ColQwen3-Implementierung mit token_embed-Pooling und MaxSim-Scoring, sodass der Encoder hinter demselben Inferenz-Stack laufen kann wie der Rest des RAG-Systems. Prüfen Sie vor dem Ausliefern die Lizenzen: ColPali steht unter den Gemma-Bedingungen, die ColQwen2- und ColQwen2.5-Checkpoints sowie colSmol sind Apache-2.0, und die colqwen3-Modelle von TomoroAI sind ebenfalls Apache-2.0.

Wann schlagen Seitenbilder geparsten Text, und wann nicht?

Seitenbilder gewinnen, wenn die Antwort vom Layout oder von Nicht-Text-Inhalten abhängt: eine Abbildung, eine Diagrammlegende, eine Tabelle mit verbundenen Kopfzeilen, ein gescanntes Formular. Im ViDoRe-v1-Paper stehen 79,1 gegen 35,7 bei ArxivQA, 81,8 gegen 71,9 bei InfoVQA und 83,9 gegen 69,1 bei TabFQuAD (nDCG@5). Der Benchmark prüft gezielt Abbildungen und Tabellen, die Abstände spiegeln also wider, was er misst.

Die Benchmarks sind weitergezogen. ViDoRe v1 ist nahezu gesättigt, mit Spitzenmodellen über 90 nDCG@5. ViDoRe v2 ergänzt blinde kontextuelle Anfragen, lange und dokumentübergreifende Anfragen sowie vier mehrsprachige Datensätze. ViDoRe v3 (ACL 2026) ist deutlich schwerer: zehn Datensätze, rund 26.000 Seiten, 3.099 von Menschen geprüfte Anfragen in sechs Sprachen. Visuelle Retriever schlagen textbasierte, und Late Interaction verbessert das Ranking, doch aktuelle Modelle scheitern noch an Nicht-Text-Elementen und feiner visueller Verankerung. Der beste berichtete Wert liegt bei etwa 66,75 nDCG@10 (EVIE-8B), gegenüber 61,60 für tomoro-colqwen3-embed-8b. Das sind Paper-Zahlen; prüfen Sie Model-Cards und Benchmark-Seiten, bevor Sie eine Rangliste zitieren, denn Live-Ansichten ändern sich.

Die Fälle, in denen Text reicht, sind real. Digital erzeugte PDFs mit sauberer Textebene brauchen selten ein Vision-Modell, um den richtigen Absatz zu finden, und exakte Filter auf Feldebene sind über Text leichter nachvollziehbar. Geparste Chunks liefern außerdem einen Textabschnitt zum Zitieren. Ein paar Tausend Seiten auf einer reinen CPU-Maschine passen schlecht zu einem Multi-Vektor-Index. Schriften, die OCR stark fordern, sind ein Testfall, kein belegter Vorteil: Kein ViDoRe-Split ist ein CJK-Korpus, testen Sie solche Schriften also an Ihren eigenen Seiten.

Welche Vektordatenbanken unterstützen Multi-Vektoren?

Die Unterstützung ist uneinheitlich. Qdrant hat seit v1.10.0 ein natives Multivektor-Feld mit dem Komparator max_sim und erzwingt eine Grenze, bei der Subvektoren mal Dimensionen unter 1.048.576 bleiben; eine ColPali-Seite mit 128 Dimensionen erfüllt das problemlos. Vespa drückt MaxSim als Tensor-Ranking-Ausdruck aus und unterstützt binäre Vektoren mit Hamming-Distanz. In Postgres hat pgvector keinen nativen Multivektor-Typ; das Feature-Request-Issue 970 dokumentiert die Umgehungen mit einer Zeile pro Token und MaxSim in der Anwendung. VectorChord liefert den produktiven Weg mit Vektor-Arrays, dem Operator @# für MaxSim und einem vchordrq-Index (VectorChord-Doku).

Die Tabelle gibt nur wieder, was die verlinkten Quellen belegen. Prüfen Sie die aktuelle Version jedes Produkts, bevor Sie sich auf ein Feature festlegen.

Wie entscheiden Sie, und was testen Sie zuerst?

Beginnen Sie mit Ihren eigenen Seiten, nicht mit einer Rangliste. Bauen Sie einen kleinen Evaluationssatz aus 100 bis 300 echten Fragen mit Seiten-Labels, führen Sie geparsten Text und Seitenbilder durch dasselbe Retrieval-Harness und vergleichen Sie den Recall an der Schwelle, die Ihr Generator tatsächlich nutzt. Prüfen Sie danach:

1. Korpusgröße und Wachstum: Multiplizieren Sie Seiten mit Vektoren pro Seite und Bytes pro Vektor, bevor Sie eine Datenbank wählen.
2. Seitenmix: Wie viele Seiten hängen an Tabellen, Abbildungen oder Scans, und wie viele sind sauberer digitaler Text?
3. GPU-Budget: Im Setup des Papers kostet die Anfrage-Kodierung etwa das Fünfzehnfache des Textpfads; planen Sie das im Anfragepfad ein, nicht nur bei der Indexierung.
4. Reranking: Entscheiden Sie, ob eine Kandidatenstufe mit gepoolten oder binären Vektoren einen exakten MaxSim-Rerank speist.
5. Lizenzen: Prüfen Sie, ob die Lizenz des Checkpoints Ihren Einsatz erlaubt.
6. Zitate: Stellen Sie sicher, dass die Antwort auf eine Seitenregion verweisen kann, und liefern Sie das Seitenbild mit der Antwort aus.

Wenn ich eine Demo davon baute, begänne ich mit einer Suchbox über gerenderte Seiten auf meiner eigenen Nuxt-Seite, auf der ich bereits LLM-Funktionen betreibe. Das ist ein Plan, kein laufendes System. Für die Text-Basislinie lesen Sie PDF-Parsing für RAG und Embedding-Quantisierung mit Binär- und Matryoshka-Verfahren. Für die Store-Seite beschreibt Qdrant die Single-Vektor-Einrichtung, die weiterhin der Standard ist. Meine Arbeit als KI-Ingenieur fasst die Seite KI-Engineering zusammen.

Quellen

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