Ein RAG-System nach Benchmark-Listen zu bauen, bedeutet für die Daten von jemand anderem zu optimieren.

Vor einiger Zeit sprach ich mit einem potenziellen Kunden. Ihm war ein multimodales RAG-System hingestellt worden — mit aktuellen Technologien, sauber aufgesetzt, alles state of the art. Das Problem: Es hat ihm einfach nicht die Informationen gegeben, die er brauchte.

Im Gespräch wurde klarer, was er eigentlich wollte: Fragen wie “Welche Analysen haben wir zu Thema X in Verbindung mit Thema Y gemacht?” — über Hunderte von PowerPoint-Dateien hinweg. Für solche Anfragen braucht man entweder eine relationale Datenbank, Graph-RAG oder Agentic RAG. Klassisches RAG ist die falsche Architektur.

Ich fragte mich: Wie kann so etwas passieren? Und die Antwort ist fast immer dieselbe: Es wurde nicht definiert, was das System können soll — und es wurde nicht gemessen, ob es das kann. Ein Eval Dataset mit repräsentativen Fragen hätte die falsche Architekturentscheidung aufgedeckt, bevor das System gebaut wurde.

Das eigentliche Fundament ist das Eval Dataset

Bevor man eine einzige Komponente eines RAG-Systems optimiert, braucht man ein Eval Dataset. Nicht als Formalität, sondern als Fundament. Denn jedes Experiment, jede Entscheidung, jede Aussage wie “Chunking-Strategie A ist besser als B” hängt vollständig davon ab.

Was ist ein Eval Dataset in diesem Kontext? Im Kern: eine Sammlung von Fragen, für die man weiß, welche Dokumente das System hätte finden sollen. Das erlaubt es, Retrieval-Qualität direkt und unabhängig vom LLM zu messen. Ein gutes Eval Dataset kann aber mehr: expected answers oder key facts, gegen die man die Generierung prüft — ohne sich vollständig auf einen LLM-Judge verlassen zu müssen.

In diesem Projekt (systematic-rag) enthält das Eval Dataset für ausgewählte Queries einen Referenzchunk und Keywords, die in der Antwort vorkommen sollen. Für die darüber hinausgehende Generation-Evaluation haben wir auf einen LLM-as-Judge gesetzt — was bei AWS-Zertifizierungsthemen funktioniert, weil das Modell das Thema kennt. Bei unternehmensinternen Daten, die kein LLM im Training gesehen hat, ist das eine schwächere Grundlage. Dort sind explizite Referenzantworten keine Kür, sondern Pflicht.

Das Dataset umfasst 53 Queries auf 180 AWS-Zertifizierungsdokumenten (PDF + HTML): 30 direkte Fragen, 23 beschreibende Statements, verteilt auf drei Schwierigkeitsgrade und vier Zertifizierungen. Dazu kommen drei bewusst falsche Fragen — zu Google-Diensten wie BigQuery und GKE — die das System zuverlässig ablehnen soll. Diese Negative Tests haben später die Entscheidung in Phase 6 maßgeblich beeinflusst.

53 Queries sind nicht viel. Ein größeres Dataset würde Varianz besser abbilden. Aber es reicht für konsistente, reproduzierbare Vergleiche — und es ist deutlich mehr als gar keins.

Das Methodikproblem: Kombinatorische Explosion

Nehmen wir an, man möchte folgende Komponenten vergleichen:

  • 5 Chunking-Konfigurationen
  • 3 Embedding-Modelle
  • 3 Vektordatenbanken
  • 5 Suchstrategien
  • 4 Reranker
  • 6 Synthesis-Modi
  • 7 LLMs

Vollständiger Grid Search: über 18.000 Kombinationen. Das ist nicht praktikabel.

Die Alternative, die die meisten wählen: einige vielversprechende Kandidaten zusammenstellen, ein bisschen ausprobieren, dann eine Konfiguration nehmen. Das Ergebnis hängt stark davon ab, was man zuerst ausprobiert — und ob man Glück hat.

Der Ansatz in diesem Repo ist ein anderer: Layered Baseline Optimization. Eine Variable zur Zeit, alle anderen eingefroren. Jede Phase optimiert exakt eine Schicht der Pipeline, friert das Ergebnis ein und bildet die Baseline für die nächste Phase.

Phase 1  Chunking-Strategie       → recursive_1024_100
Phase 2  Embedding-Modell         → e5-large-v2 (1024d)
Phase 3  Vektordatenbank          → Qdrant
Phase 4  Suchstrategie            → Dense
Phase 5  Reranking                → None
Phase 6  Antwortsynthese          → tree_summarize / Temp 0.0
Phase 7  LLM-Auswahl              → GPT-4o-mini (Prod) / Qwen3-8B (Qualität)
Phase 8  End-to-End-Evaluation    → Abschlussbericht

Das reduziert ~18.000 mögliche Kombinationen auf rund 40 gezielte Experimente.

Was dabei trotzdem schiefgehen kann

Ein zu striktes Layer-by-Layer-Vorgehen hat eine Schwachstelle: Wechselwirkungen zwischen Schichten. Phase 1 (Chunking) hatte in diesem Projekt kein eindeutiges Ergebnis — fixed_512_50 führte in den meisten Metriken, aber der Recall-Vorsprung fehlte. Erst mit einem stärkeren Embedding-Modell in Phase 2 zeigte sich, dass recursive_1024_100 das bessere Setup ist: Größere Chunks profitieren überproportional von höherdimensionalen Embeddings.

Das ist kein Fehler der Methodik — es ist ein Grund, bei nicht-eindeutigen Ergebnissen gezielt querzutesten, statt mechanisch weiterzugehen. Mehr dazu in Post 2 und 3.

Was diese Serie zeigt

Am Ende dieser 8 Phasen steht eine optimierte Pipeline vs. eine naive Baseline — gleicher Datensatz, gleiche Fragen, gleiches LLM:

  • MRR@5: +10.4%
  • Halluzinationsrate: −43%

Der größte Hebel war nicht das LLM. Es war Chunking + Embedding.

Aber das ist das Ergebnis für diese Daten, diesen Use Case, dieses Eval Dataset. Andere Daten können andere Antworten ergeben. Vertragstexte haben andere Eigenschaften als Zertifizierungsdokumente. Support-Tickets unterscheiden sich von technischen Handbüchern. Eine Konfiguration, die hier gewinnt, ist nicht universell optimal — sie ist optimal für diesen Kontext.

Das ist der eigentliche Grund, warum man systematisch vorgeht.

Code und Details: Eval Dataset, Experiment-Matrizen, Pipeline-Code und vollständige Phasenberichte — auf GitHub dokumentiert: → github.com/hanasobi/systematic-rag

Ich bin ML Engineer mit Fokus auf KI-Integration und RAG-Systeme im DACH-Raum. Offen für Austausch und spannende Projekte — schreib mir auf LinkedIn.