RT-Vector: Chatten mit eigenen Dokumenten – gemessen statt geraten.

Ausgangslage & Frage

Große Sprachmodelle formulieren flüssig, aber ihr Wissen endet mit dem Training. Interne Handbücher, Verträge oder Fachartikel kennen sie nicht, und wenn ihnen Wissen fehlt, erfinden sie im Zweifel plausibel klingende Details. Retrieval-Augmented Generation (RAG) entkoppelt deshalb Wissen und Sprachmodell: Das System sucht zuerst die passenden Stellen in den eigenen Dokumenten und gibt sie dem Modell als Grundlage mit.

RAG hat sich schnell weiterentwickelt: vom einfachen „Suchen und Antworten“ (Naive RAG) über optimierte Vor- und Nachverarbeitung (Advanced RAG) bis zu flexibel kombinierbaren Bausteinen (Modular RAG) und autonom planenden Agenten (Agentic RAG). Ich wollte selbst ein System bauen, das diese Ideen umsetzt, und dabei eine Frage beantworten:

Architektur

RT-Vector besteht aus drei Schichten, die per Docker Compose gemeinsam starten. Das Frontend in Next.js bietet Chat mit Streaming, Upload und Einstellungen. Das Backend in FastAPI übernimmt Ingestion, also das Einlesen und Aufbereiten der Dokumente, und die RAG-Pipeline. PostgreSQL speichert alles an einem Ort: Dokumente, Chunks (Textabschnitte), Embeddings (Zahlenvektoren, die die Bedeutung eines Abschnitts abbilden) und Gesprächsverläufe.

Eine bewusste Entscheidung war, keine separate Vektordatenbank einzusetzen. Mit der Erweiterung pgvector und einem HNSW-Index (Hierarchical Navigable Small World, ein Suchverzeichnis für schnelle Ähnlichkeitssuche) sucht PostgreSQL nach Bedeutung. Parallel dazu liefert ein tsvector-Feld mit GIN-Index (Generalized Inverted Index, ein Stichwortverzeichnis wie das Register eines Buchs) eine klassische Stichwort-Volltextsuche. Sie gewichtet Treffer danach, wie oft die Suchbegriffe in einem Abschnitt vorkommen. Ein Verfahren wie BM25, das zusätzlich seltene Begriffe höher bewertet, ist das nicht. Beides liegt in derselben Datenbank, in denselben Transaktionen, neben den Metadaten, sodass kein zweites System betrieben werden muss.

Das Sprachmodell ist austauschbar: Antworten kommen wahlweise von OpenAI, Anthropic Claude, Google Gemini, Azure OpenAI oder lokal über Ollama.

Ingestion & Chunking

Bevor eine einzige Frage beantwortet werden kann, muss jedes Dokument aufbereitet werden. Von diesem Schritt hängt ab, ob die Suche später die richtigen Stellen findet.

Parsing mit Docling

Docling liest Dokumente mit Machine Learning. Neben dem Text erkennt es das Layout: Überschriften, Absätze, Listen und Tabellen. Mit dieser Struktur kann das Chunking Sinnzusammenhänge erhalten.

Neun Chunking-Methoden und eine Vorschau

In der App stehen neun Verfahren zur Wahl, vom einfachen festen Fenster bis zum strukturbewussten Hybrid-Chunking von Docling (NLTK steht für Natural Language Toolkit, eine Python-Bibliothek zur Sprachverarbeitung):

• Hybrid (Docling)
• Fixed
• Sentence
• Paragraph
• Sliding Window
• Recursive
• Token
• Markdown Header
• NLTK Sentence

Welche Methode zu einem Dokument passt, zeigt die Chunk-Vorschau: Sie markiert vor dem Upload für jede Methode farbig, wo im Originaltext die Abschnittsgrenzen liegen. Daran erkennst Du, ob Tabellen zerschnitten werden oder Absätze zusammenbleiben.

Contextual Embedding

Ein einzelner Chunk verliert schnell seinen Zusammenhang. Deshalb reichere ich jeden Abschnitt vor dem Embedding mit je 150 Zeichen Kontext aus dem vorherigen und dem nächsten Chunk an. Gespeichert und an das Sprachmodell übergeben wird nur der Originalabschnitt. Das Embedding-Modell multilingual-e5-large erzeugt daraus einen Vektor mit 1024 Dimensionen, mit getrennten Präfixen für Passagen und Suchanfragen.

Suche & Modular RAG

Naive RAG führt für jede Frage genau eine Suche aus und antwortet mit dem, was dabei herauskommt. RT-Vector passt den Ablauf dagegen an die Frage an. Genau das meint Modular RAG: Einzelne Bausteine werden je nach Bedarf kombiniert.

Die Stufen gleichen gegenseitig ihre Schwächen aus. Die Vektorsuche versteht Bedeutung, übersieht aber exakte Begriffe wie Produktnummern, die Volltextsuche ist genau dort stark. HyDE hilft, wenn die Frage ganz anders formuliert ist als die Antwort im Dokument. Der Cross-Encoder ist langsamer, aber deutlich genauer als der reine Vektorvergleich, deshalb sortiert er nur die vorgefilterten Kandidaten.

Evaluierung

Ob ein RAG-System gut ist, lässt sich nicht durch ein paar Testfragen im Chat beurteilen. Deshalb habe ich eine eigene Evaluierungs-Pipeline aufgebaut und drei Chunking-Strategien unter identischen Bedingungen verglichen:

• Docling Hybrid: strukturbewusst, baut auf Hierarchical auf und passt die Abschnitte zusätzlich an die Token-Grenze des Embedding-Modells an
• Docling Hierarchical: strukturbewusst, ein Abschnitt je erkanntem Dokumentelement (Absatz, Tabelle, Liste)
• LangChain Recursive: naiver, rein textbasierter Splitter als Vergleich

Die Testdaten stammen aus dem öffentlichen Benchmark Open RAGBench, genauer aus dessen Split text_tables. Verwendet habe ich eine Teilmenge mit 90 wissenschaftlichen Papern (Fließtext und Tabellen) und 200 Fragen samt Referenzantworten. Die Noten vergab die Python-Bibliothek Ragas, wobei gpt-4o-mini als Gutachter-Modell diente („LLM-as-a-Judge“). Gemessen wurde mit vier Kennzahlen:

Bei Context Precision, Context Recall und Faithfulness hat Docling Hybrid die höchsten Werte, bei der Answer Correctness dagegen Docling Hierarchical. LangChain Recursive landet in drei der vier Kennzahlen auf dem letzten Platz und hat mit 0,5879 die niedrigste Answer Correctness, relativ rund 8 % weniger als Docling Hierarchical. Meine Vermutung, ohne Beleg aus dieser Auswertung: Ein Splitter, der nur Zeichen zählt, setzt Schnitte auch mitten in Tabellen, und gerade dort stehen in wissenschaftlichen Papern viele der gesuchten Antworten. Bei 200 Fragen sind außerdem kleine Abstände, etwa 0,9339 zu 0,9276, keine gesicherte Rangfolge.

Erkenntnisse

Mein wichtigstes Learning betrifft das Messen: Im Chat wirken viele Varianten „gut genug“. Erst ein Benchmark mit festen Fragen und Metriken zeigt, wo die Unterschiede wirklich liegen.

Was das für Unternehmen bedeutet

Wenn Du einen Dokumenten-Chat oder einen KI-Assistenten auf Basis Deiner eigenen Daten planst, lassen sich aus RT-Vector einige Empfehlungen ableiten:

1. In die Datenaufbereitung investieren. Saubere Extraktion und strukturbewusstes Chunking verbessern die Antworten, noch bevor ein Modell ausgewählt ist, besonders bei Tabellen.
2. Bestehende Infrastruktur nutzen. Läuft bei Dir schon PostgreSQL, kann pgvector Vektor- und Volltextsuche liefern, ohne ein weiteres System zu betreiben.
3. Mit eigenen Fragen messen. Eine Sammlung typischer Fragen aus Deinem Alltag plus Metriken wie in Ragas macht Verbesserungen sichtbar und vergleichbar.
4. Quellen und Schutz einbauen. Mit Quellenangaben lässt sich jede Antwort nachprüfen, und klar abgegrenzter Kontext erschwert Prompt Injection.
5. Modell und Betriebsort bewusst wählen. Cloud-Modell oder lokal über Ollama: Das hängt von Datenschutz, Kosten und Qualität ab und lässt sich austauschbar halten.

Du willst wissen, ob ein RAG-System für Deine Dokumente sinnvoll ist? Hier findest Du meine KI-Lösungen. Die Grundlagen zum Thema habe ich außerdem im Artikel Warum Chunking über die Qualität Deines RAG-Systems entscheidet zusammengefasst.

Tech-Stack