In einem vorherigen Artikel haben wir uns mit den theoretischen Grundlagen von Retrieval-Augmented Generation beschäftigt. Wir haben uns angesehen, wie Dokumente aufbereitet, in Chunks zerlegt, über Embeddings durchsuchbar gemacht und relevante Inhalte einem Sprachmodell als Kontext zur Verfügung gestellt werden.
Doch wie gut funktioniert ein multimodales RAG-System in der Praxis?
In diesem Artikel beschreibe ich, wie ich mithilfe KI-gestützter Entwicklungswerkzeuge ein solches System entwickelt habe. Ein zentraler Punkt war dabei die Multimodalität: Das RAG sollte nicht nur Text verarbeiten. Auch Tabellen, Bilder, Diagramme und eingebettete Audiodateien sollten durchsuchbar sein und später als Quellen für eine Antwort zur Verfügung stehen.
Eine weitere Vorgabe war die Hardware. Die gesamte Anwendung sollte auf einem kleinen Rechner mit einer NVIDIA-Grafikkarte und lediglich 8 GB VRAM laufen.
RAG ist nicht gleich RAG
Mittlerweile gibt es zahlreiche unterschiedliche RAG-Architekturen. Neben klassischen Vector-RAG-Systemen existieren beispielsweise hybride Ansätze, hierarchisches RAG, agentische Systeme und spezialisierte Verfahren wie Graph RAG, bei denen Informationen und ihre Beziehungen in einer Graphstruktur abgebildet werden.
Welche Architektur sinnvoll ist, hängt stark von der jeweiligen Aufgabe und den vorhandenen Daten ab.
Für dieses Projekt habe ich mich für ein modernes multimodales Hybrid-RAG entschieden. Es kombiniert klassische Volltextsuche mit semantischer Vektorsuche und einem nachgeschalteten Reranker. Gleichzeitig können neben Text auch Tabellen, Bilder, Diagramme und Audioinformationen berücksichtigt werden.
Das Ziel war dabei nicht, eine neue RAG-Architektur zu erfinden, sondern bewährte moderne Verfahren so miteinander zu kombinieren, dass sie auch auf kleiner Hardware praktisch eingesetzt und miteinander verglichen werden können.
Die verwendeten Modelle
Für die verschiedenen Aufgaben kommen mehrere spezialisierte Modelle zum Einsatz. Da die Anwendung auch auf kleiner Hardware mit lediglich 8 GB VRAM funktionieren sollte, haben wir dafür eine entsprechende Standardkonfiguration gewählt:
- Qwen3-Embedding-0.6B für die Embeddings
- Qwen3-Reranker-0.6B für das Reranking
- Qwen2.5-VL-3B-Instruct für Bildverständnis und Antwortgenerierung
- Whisper large-v3-turbo für die Audiotranskription
Diese Modelle sind jedoch nicht fest in der Anwendung vorgegeben. Die Modell-IDs können direkt über die grafische Oberfläche geändert werden. Dadurch lassen sich beispielsweise andere Embedder und Reranker oder ein leistungsfähigeres VLM ausprobieren, sofern das jeweilige Modell mit der vorgesehenen Aufgabe kompatibel ist und die vorhandene Hardware dafür ausreicht.
Die genannten Modelle bilden somit in erster Linie unsere 8-GB-Standardkonfiguration.
Ein zusätzlicher Modellserver wie Ollama ist dafür nicht notwendig.
Die Anwendung lädt die ausgewählten Modelle direkt aus Python über Hugging Face. Ist ein angegebenes Modell noch nicht vorhanden, wird es automatisch heruntergeladen und anschließend im lokalen Hugging-Face-Cache gespeichert. Bei späteren Starts können die bereits vorhandenen Modelldateien wiederverwendet werden.
Im Sourcecode genügt dafür beispielsweise die Modell-ID:
"Qwen/Qwen3-Embedding-0.6B"Der Download erfolgt über den Hugging Face Hub:
def download_model(model_id: str) -> str:
from huggingface_hub import snapshot_download
repo = hub_id(model_id)
try:
return snapshot_download(repo)
except Exception as exc:
if "401" not in str(exc):
raise
return snapshot_download(repo, token=False)Damit müssen die Modelle nicht über einen separaten Modellserver installiert und verwaltet werden.
Die Modellwahl selbst wird gleichzeitig zu einem Teil der Evaluation. So lässt sich beispielsweise untersuchen, ob ein größerer Embedder oder Reranker die Qualität tatsächlich verbessert und welchen zusätzlichen Ressourcenbedarf wir dafür in Kauf nehmen müssen.
Da 8 GB VRAM nicht ausreichen, um alle Modelle gleichzeitig auf der GPU zu halten, werden sie bei Bedarf geladen und anschließend wieder freigegeben. Das VLM wird in unserer 8-GB-Konfiguration zusätzlich in einer speichersparenden 4-Bit-Variante betrieben.
Vom Dokument zum durchsuchbaren Inhalt
Die Dokumentenaufbereitung übernimmt hauptsächlich Docling. Dabei soll nicht nur der reine Text erhalten bleiben, sondern möglichst auch die Struktur des Dokuments.
Das ist insbesondere bei Dokumenthierarchien und Tabellen wichtig. Eine Tabelle darf beispielsweise nicht einfach in beliebige Textstücke zerlegt werden. Andernfalls können die Beziehungen zwischen Überschrift, Zeilen und Spalten verloren gehen.
In unserer Anwendung bleibt deshalb jede Tabelle als eigener Chunk erhalten. Zusätzlich speichern wir unter anderem die zugehörige Folie, die Überschrift und die Tabelle selbst in Markdown-Darstellung.
Auch beim Chunking wollten wir uns nicht auf eine einzige Einstellung festlegen. Die Konfiguration sieht beispielsweise so aus:
@dataclass
class ChunkingSettings:
chunker: str = "docling_hybrid"
max_tokens: int = 512
merge_peers: bool = True
contextualize: bool = True
parent_retrieval: bool = TrueChunking-Verfahren und Chunk-Größe können über die Oberfläche verändert werden. Dadurch lässt sich später untersuchen, welchen Einfluss diese Einstellungen auf die Retrieval-Qualität haben.
Bilder und Diagramme im RAG
Auch für die Einbindung visueller Inhalte existieren unterschiedliche Verfahren.
Ein bekannter Ansatz ist CLIP. Dabei werden Bilder und Texte in einen gemeinsamen Embedding-Raum überführt. Dadurch kann eine Textanfrage direkt mit den Embeddings vorhandener Bilder verglichen werden.
Modelle aus der BLIP-Familie verbinden Bild- und Sprachinformationen stärker über multimodale Transformer-Mechanismen.
Moderne generative Vision-Language-Modelle (VLMs) gehen noch einen Schritt weiter und können visuelle Informationen gemeinsam mit einer sprachlichen Anfrage verarbeiten und daraus Antworten oder Beschreibungen erzeugen.
Für unsere Anwendung haben wir einen pragmatischen zweistufigen Ansatz gewählt.
Beim Einlesen eines Dokuments analysiert Qwen-VL die Bilder und Diagramme und erzeugt daraus zunächst eine textuelle Beschreibung. Diese Beschreibung wird anschließend wie ein normaler Text-Chunk indexiert.
Dadurch bleibt die spätere Suche effizient. Das VLM muss nicht bei jeder Anfrage sämtliche Bilder erneut analysieren. Die bereits erzeugten Beschreibungen können über dieselbe Hybrid-Retrieval-Pipeline wie der übrige Dokumentinhalt durchsucht werden.
Wird über die Bildbeschreibung eine relevante visuelle Quelle gefunden, lädt die Anwendung zusätzlich das zugehörige Originalbild.
Dieses wird gemeinsam mit der konkreten Nutzerfrage und dem übrigen Kontext an Qwen-VL übergeben.
Vereinfacht:
Bild / Diagramm
↓
VLM
↓
Bildbeschreibung
↓
BM25 + Embedding
↓
Retrieval
↓
relevantes Bild gefunden
↓
Originalbild + Frage + Kontext
↓
VLM
↓
AntwortDamit verbinden wir zwei Vorteile.
Für das Retrieval genügt zunächst die bereits erzeugte textuelle Repräsentation des Bildes. Die Suche muss deshalb nicht jedes Originalbild erneut durch ein Vision-Modell schicken.
Für die eigentliche Antwort ist das System dagegen nicht auf diese Beschreibung beschränkt. Das VLM sieht wieder das Originalbild und kann es gezielt im Hinblick auf die aktuelle Frage analysieren.
Die Bildbeschreibung dient damit vor allem dazu, die relevante visuelle Quelle schnell zu finden. Die eigentliche visuelle Interpretation erfolgt anschließend anhand des Originals.
Auch Audio wird Teil des RAG
Eine zusätzliche Herausforderung waren eingebettete Audioaufnahmen.
PowerPoint-Präsentationen können beispielsweise Audiodateien enthalten, die zusätzliche Informationen zu einzelnen Folien liefern. Diese Dateien müssen zunächst aus dem Dokument extrahiert werden.
Bei PowerPoint erfolgt das über die internen Beziehungen des Dokuments. Bei PDFs berücksichtigen wir unter anderem Anhänge, Sound-Anmerkungen und lokale Dateiverweise.
Die gefundenen Audiodateien werden anschließend mit Whisper transkribiert.
Whisper-Segmente werden dabei nur innerhalb derselben Audiodatei zusammengeführt. Dadurch bleibt jede Aufnahme eine eigenständige Quelle und kann bei einer passenden Frage separat als Beleg angezeigt und abgespielt werden.
Damit behandelt das RAG Audio ähnlich wie Bilder: Für das Retrieval steht zunächst eine textuelle Repräsentation zur Verfügung, während die Verbindung zur ursprünglichen Quelle erhalten bleibt.
Hybrid Retrieval statt reiner Vektorsuche
Für die eigentliche Suche verwenden wir zwei unterschiedliche Verfahren.
BM25 eignet sich besonders gut für exakte Begriffe, Produktnummern und andere konkrete Bezeichnungen.
Parallel dazu erzeugt Qwen3-Embedding-0.6B semantische Embeddings. Diese werden mit FAISS und einem HNSW-Index durchsucht.
Der HNSW-Index wird im Sourcecode direkt über FAISS erzeugt:
index = faiss.IndexHNSWFlat(
matrix.shape[1],
int(m),
faiss.METRIC_INNER_PRODUCT
)
index.hnsw.efConstruction = int(ef_construction)
index.add(np.ascontiguousarray(matrix))Die Ergebnisse von BM25 und Vektorsuche werden anschließend über Reciprocal Rank Fusion (RRF) zusammengeführt.
Ein wesentlicher Vorteil besteht darin, dass die unterschiedlichen Scores von BM25 und Vektorsuche nicht zunächst auf eine gemeinsame Skala normalisiert werden müssen. RRF verwendet stattdessen die Rangpositionen der Treffer.
Danach bewertet Qwen3-Reranker-0.6B die gefundenen Chunk-Kandidaten noch einmal anhand der konkreten Nutzerfrage.
Vereinfacht ergibt sich folgende Pipeline:
Dokumente
↓
Docling / VLM / Whisper
↓
Chunks
↓
┌─────────────┬─────────────┐
│ BM25 │ Embeddings │
│ │ FAISS/HNSW │
└──────┬──────┴──────┬──────┘
└──────┬──────┘
↓
RRF
↓
Reranker
↓
Parent Context
↓
Text + Originalbilder
↓
Qwen-VL
↓
AntwortWenn das Sprachmodell besser nicht selbst rechnet
LLMs und insbesondere kleine Sprachmodelle sind keine Taschenrechner. Auch bei vergleichsweise einfachen Berechnungen können Fehler auftreten.
Statt deshalb ein größeres Modell einzusetzen – bei dem korrekte Berechnungen ebenfalls nicht garantiert sind –, haben wir der Anwendung einen Calculator als Tool hinzugefügt.
Das Tool wird dem Modell explizit beschrieben:
CALCULATOR_TOOL = {
"name": "calculator",
"description": "Evaluate one arithmetic expression. Use this for every sum, difference, product, or quotient.",
"parameters": {
"type": "object",
"properties": {
"expression": {
"type": "string",
"description": "Arithmetic expression using the evidence numbers, for example 130 - 110.",
}
},
"required": ["expression"],
},
}Erkennt das Modell, dass für eine Antwort eine Berechnung notwendig ist, erzeugt es einen Tool-Call mit dem mathematischen Ausdruck. Die Anwendung berechnet das Ergebnis deterministisch und gibt es anschließend an das Modell zurück.
Eine praktische Herausforderung sind dabei unterschiedliche Zahlenschreibweisen. So muss beispielsweise berücksichtigt werden, ob ein Punkt als Dezimal- oder als Tausendertrennzeichen verwendet wird.
Damit übernimmt jede Komponente die Aufgabe, für die sie besser geeignet ist:
Das RAG findet die Zahlen, das Sprachmodell versteht die Frage und der Calculator führt die eigentliche Berechnung aus.
Wie gut ist die Antwort durch die Quellen gestützt?
Neben der eigentlichen Antwort wollten wir auch sichtbar machen, wie gut diese durch die gefundenen Informationen gestützt wird.
Die Anwendung führt deshalb zusätzlich einen Grounding- und Confidence-Check durch.
Dabei werden die erzeugte Antwort und die tatsächlich gefundenen Evidenzen miteinander abgeglichen. Neben der Abdeckung der Antwort durch die Quellen werden dabei unter anderem auch enthaltene Zahlen berücksichtigt.
Aus diesen Informationen erzeugt die Anwendung einen Confidence-Score und eine entsprechende Einstufung, die direkt in der Oberfläche angezeigt wird.
Der Nutzer erhält damit nicht nur eine Antwort und die zugehörigen Quellen. Er bekommt zusätzlich einen Hinweis darauf, wie stark die generierte Antwort durch die gefundenen Dokumentinhalte gestützt wird.
Gerade bei einem RAG-System ist das wichtig: Nicht nur die Antwort selbst sollte sichtbar sein, sondern auch, auf welcher Evidenz sie basiert.
29 von 30 Fragen richtig
Zum Testen der Anwendung haben wir einen Katalog mit 30 Fragen verwendet.
29 davon wurden korrekt beantwortet. Das entspricht rund 96,7 Prozent.
Interessant war vor allem die einzige falsche Antwort.
Bei einer Frage zum verfügbaren Bestand des Artikels EF-440 wurde die richtige Tabelle gefunden und dem Modell zur Verfügung gestellt. Das kleine VLM interpretierte jedoch die falsche Tabellenspalte und verwendete den Wert aus „Reserviert“.
Der Fehler lag damit nicht beim Retrieval, sondern bei der Interpretation der korrekt gefundenen Evidenz.
Hier zeigt sich die bewusste Abwägung unseres Projekts: Wir verwenden ein sehr kompaktes Modell, damit das gesamte System auf kleiner Hardware betrieben werden kann. Größere Modelle können bei komplexeren Interpretationsaufgaben robuster arbeiten, benötigen dafür jedoch entsprechend mehr Ressourcen.
Das RAG als Playground
Die Anwendung ist nicht nur als Dokumenten-RAG gedacht. Sie dient gleichzeitig als Playground zur Evaluation unterschiedlicher RAG-Konfigurationen.
Über die grafische Oberfläche lassen sich sowohl die verwendeten Modelle als auch die wesentlichen Parameter der Pipeline verändern.
Dazu gehören unter anderem die Modell-IDs für Embedder, Reranker und Generator, das Chunking-Verfahren und die Chunk-Größe sowie verschiedene Parameter für BM25, HNSW, RRF, Reranking und die anschließende Kontextauswahl.
Damit können unterschiedliche Konfigurationen getestet werden, ohne dafür den Sourcecode verändern zu müssen.
Das ist ein wesentlicher Zweck der Anwendung.
Denn es gibt nicht die eine optimale RAG-Konfiguration für alle Dokumente.
Ein technisches Handbuch mit vielen Produktnummern kann von anderen Einstellungen profitieren als ein Geschäftsbericht mit langen Textabschnitten, Tabellen und Diagrammen.
Mit dem Playground lässt sich deshalb untersuchen, welche Kombination aus Modellen und Parametern für einen konkreten Dokumentensatz die besten Ergebnisse liefert.
Die Anwendung zeigt außerdem die einzelnen Stufen des Retrievals. Dadurch lässt sich nachvollziehen, welche Chunks BM25 und Vektorsuche gefunden haben, wie RRF diese Ergebnisse zusammengeführt hat und wie sich ihre Reihenfolge durch den Reranker verändert.
Damit lässt sich nicht nur feststellen, dass eine Antwort falsch war, sondern wesentlich genauer untersuchen, an welcher Stelle der Pipeline die Ursache liegt.
Fazit
Unser Praxistest zeigt, dass ein modernes multimodales RAG-System keineswegs zwingend große Server oder sehr große Sprachmodelle voraussetzt.
Mit Docling für die Dokumentenstruktur, BM25 und semantischen Embeddings für das Retrieval, FAISS/HNSW für die Vektorsuche, RRF für die Zusammenführung, einem spezialisierten Reranker sowie Qwen-VL und Whisper für visuelle und auditive Inhalte lässt sich eine leistungsfähige Pipeline auch auf vergleichsweise kleiner Hardware aufbauen.
Bilder und Diagramme werden dabei nicht lediglich in Text umgewandelt. Ihre Beschreibung ermöglicht zunächst ein effizientes Retrieval, während das Originalbild anschließend wieder multimodal an das VLM übergeben werden kann. Audioaufnahmen werden transkribiert, bleiben aber ebenfalls als eigenständige Quellen erhalten.
Deterministische Aufgaben wie Berechnungen können über Tools ausgelagert werden, während ein zusätzlicher Grounding- und Confidence-Check sichtbar macht, wie gut eine Antwort durch die gefundenen Informationen gestützt wird.
Gleichzeitig ist die Architektur nicht an die von uns verwendeten Modelle und Parameter gebunden. Über die grafische Oberfläche lassen sich Modelle und wesentliche Einstellungen austauschen und anschließend miteinander vergleichen. Die Anwendung dient damit nicht nur als RAG, sondern gleichzeitig als Experimentier- und Evaluationsumgebung.
Mit 29 korrekt beantworteten Fragen bei 30 Testfragen erreichte die Anwendung in unserem Test rund 96,7 Prozent – und das mit einem bewusst kleinen generativen Modell auf einer Grafikkarte mit lediglich 8 GB VRAM.
Damit zeigt das Projekt vor allem eines:
Mit überschaubarem Aufwand und vergleichsweise kleiner Hardware lässt sich heute ein funktionierendes, modernes und multimodales RAG-System entwickeln.
Entscheidend ist dabei weniger die Größe eines einzelnen Modells als das sinnvolle Zusammenspiel der spezialisierten Komponenten – von der Dokumentenaufbereitung über Retrieval und Reranking bis zur multimodalen Verarbeitung, dem Einsatz von Tools und der nachvollziehbaren Bewertung der erzeugten Antworten.
