Retrieval-Augmented Generation ist die häufigste KI- Architektur, die 2026 in Produktion geht, und die am häufigsten falsch implementierte. Ein Team wählt eine Vektordatenbank, eine Default-Chunk-Grösse und ein Default- Top-k, und dann beschuldigt es das Sprachmodell, wenn Antworten vage oder falsch zurückkommen. Nach unserer Erfahrung ist das Modell selten der Flaschenhals. Die Retrieval-Schicht ist es.

Retrieval ist der Flaschenhals.

Ein RAG-System ist eine zweistufige Pipeline. Stufe eins holt Dokumente. Stufe zwei generiert eine Antwort darüber. Liefert Stufe eins die falschen Dokumente, kann kein Modell das mehr retten. Das Modell kann nur über das halluzinieren, was es bekommen hat. Der Fehler ist still, weil die Antwort plausibel klingt. Die Heilung: Retrieval als eigenes System mit eigenem Design und eigener Eval behandeln.

Chunking, Form vor Grösse.

Der häufigste Fehler ist Chunking nach Zeichenanzahl. Ein langes Dokument wird alle 1000 Zeichen geschnitten, mit kleinem Überlapp. Das Embedding-Modell sieht ein halbes Paragraph, das mitten im Satz endet; der Retriever holt es, der Generator versucht, aus einem Fragment zu argumentieren. Bessere Praxis 2026: form-bewusstes Chunking.

  • Dokumentstruktur zuerst. Schnitt an Überschriften, Paragraphen, Listenelementen, Tabellenzeilen. Die Chunks decken sich mit den semantischen Einheiten des Dokuments.
  • Kontext-Präfixe. Seitentitel und Sektionspfad vor jeden Chunk setzen, bevor er embedded wird. Ein Chunk auf Seite 47 eines Vertrags «der Lieferant haftet» ist ohne «Abschnitt 12, Haftung» bedeutungslos.
  • Zweistufige Indexierung. Sowohl den Chunk selbst als auch eine Zusammenfassung embedden. Suchanfragen gegen Summaries für Breite, gegen Chunks für Präzision.

Retrieval, hybrid by default.

Vektorsuche ist gut in Bedeutung. Keywordsuche ist gut in Identifikatoren, Codes, seltenen Namen. Die Anfrage «Was sagt Artikel 7.3 zu Zahlungsverzug?» enthält eine semantische Absicht (Zahlungsverzug) und einen literalen Identifikator (Artikel 7.3). Reine Vektorsuche bringt Dokumente zu Zahlungsverzug allgemein hoch; reine Keywordsuche bringt Artikel 7.3 in beliebigem Kontext hoch.

Das Muster, das in Produktion gewinnt, ist Hybrid Retrieval: Vektor- und Keywordsuche (BM25 ist 2026 immer noch der Default-Keyword-Scorer) parallel laufen lassen, die Ergebnislisten mit Reciprocal Rank Fusion zusammenführen, und das gemerged Top-k an die nächste Stufe geben.

Reranking, der billige Accuracy-Lift.

Der Retriever liefert schnell die Top vierzig Kandidaten. Ein Reranker bewertet diese vierzig gegen die Anfrage auf tatsächliche Relevanz und gibt die Top acht zurück. Der Reranker ist ein kleines Cross-Encoder-Modell oder ein dünner LLM-Aufruf. Schnell, billig, deutlicher Genauigkeits-Lift. Die meisten RAG-Systeme, die wir auditieren, haben keinen Reranker, und die meisten sollten.

Retrieval evaluieren, nicht nur den Generator.

Fast kein Team in 2026 evaluiert die Retrieval-Schicht unabhängig. Die Rubrik bewertet die finale Antwort, das Modell bekommt Lob oder Tadel, die Retrieval-Schicht bleibt unsichtbar im Scoreboard. Die Korrektur: eine separate Retrieval-Eval mit eigenen Fixtures und Metriken:

  • Recall at k. Enthielt das Top-k den relevanten Chunk? Alles unter 100% bedeutet, dass der Generator manchmal ohne Quelle antworten musste.
  • Reranker-Präzision. Von den Top-3, die der Reranker ausgibt, wie viele sind tatsächlich relevant?
  • Chunk-Treue. Wenn der Generator den Chunk zitiert, stützt der Chunk die zitierte Aussage wirklich?

Häufige Fehlerformen.

  1. Top-k zu klein. k=5, weil das Tutorial das sagte. Der Workflow braucht k=20 mit Rerank auf k=5. Der Generator wird ausgehungert.
  2. Veralteter Index. Das Embedding-Modell wurde erneuert, der Index nicht neu gebaut. Alte und neue Vektoren leben in unterschiedlichen Räumen.
  3. Metadaten-Blindheit. Reine Ähnlichkeitssuche ignoriert Tenant, Sprache, Datum. Falsche Tenant-Dokumente lecken; falschsprachige Drafts tauchen auf.

Häufige Fragen.

Brauchen wir immer eine Vektordatenbank? Nein. Kleiner Korpus (unter wenigen Tausend Records) passt in den Speicher oder in Postgres mit pgvector. Vektordatenbank-Overhead rechtfertigt sich erst bei Skalierungs- oder Schreibgrenzen.

Long-Context-Modelle, können wir RAG überspringen? Manchmal. Wenn der Korpus in das Kontextfenster passt und die Kosten akzeptabel sind, paste alles rein. Für die meisten Produktionskorpora ist Retrieval billiger, schneller und besser auditierbar.

Vollständige englische Fassung: RAG in production · chunking, retrieval, reranking. Verwandte Glossareinträge auf Englisch: RAG, Vector Search, Embedding Model.

Diese deutschsprachige Fassung ist eine eigenständige Übersetzung der englischen Ausgabe. Read the English original ›