5 Dinge, die in deinem Retrieval kaputtgehen (und wie du sie fixst)

Retrieval-Augmented Generation (RAG) ist, in jeder Demo, die du siehst, ein paar Zeilen Code: embedde deine Dokumente, embedde die Frage, such die Top-5 der nächstgelegenen Chunks, kleb sie in den Prompt. Das klappt für die Demo. Und dann gehst du live, bekommst echte Fragen, und es fällt auseinander.

Nachfolgend fünf Kategorien von Problemen, auf die wir in 12 Monaten Produktion gestoßen sind, plus wie wir sie gelöst haben. Keines davon ist Raketenwissenschaft; alle erfordern, dass du über die Defaults hinausgehst.

1. Chunking, der Fehler beginnt hier

Der Default in jedem RAG-Tutorial ist Recursive Character Splitting bei 1.000 Token mit 200 Overlap. Klappt für Essays. Scheitert bei technischer Dokumentation, FAQs und juristischen Texten.

Beispiel: eine FAQ-Seite mit 30 Fragen. Bei 1.000-Token-Splitting bekommst du pro Chunk ~3-5 zusammengefügte Fragen. Die Antwort auf Frage 12 sitzt dann in Chunk 4, zusammen mit Frage 11 und 13, die womöglich ganz andere Themen behandeln. Das Embedding dieses Chunks ist ein Durchschnitt aus drei semantisch verschiedenen Dingen, und das Ranking leidet darunter.

Unser Ansatz

• Strukturbewusstes Chunking. Für Markdown splitten wir bei H2, für HTML bei semantischen Blöcken, für FAQ-Seiten pro Frage-Antwort-Paar.
• Mindest-Chunk-Größe. Jeder Chunk mindestens 300 Token, sonst ist das Embedding zu brüchig und du verlierst Kontext.
• Kein Overlap, wo es geht. Overlap ist ein Proxy für 'ich weiß nicht, wo die logische Grenze liegt'. Wenn du sie kennst (Header, Absatzumbruch), ist Overlap überflüssig.

2. Recency, der Kanal, den niemand fixt

Reine Cosine-Similarity hat keine Ahnung, dass eines von zwei identischen Dokumenten von gestern ist und das andere von 2019. Für den Kundensupport ist das ein großes Problem: Alte, intern archivierte Dokumentation, die aber noch im Index steht, gewinnt gegen den frischen FAQ-Artikel, wenn sie zufällig besser zur Frage passt.

Unser Ansatz

Ein Recency-Boost als Post-Processing-Schritt. Konkret: Nach der initialen Vektorsuche multiplizieren wir den Similarity-Score mit einer Decay-Funktion auf Basis des last_modified-Timestamps. Dokumente, die älter als 18 Monate sind, bekommen 0,7x, älter als 3 Jahre 0,5x. Kein harter Cutoff, manchmal ist ein altes Dokument relevant, aber genug, um bei gleichem Score frischen Inhalt den Ausschlag geben zu lassen.

3. Authority / Source-Boosting

Nicht alle Quellen sind gleich. Eine offizielle Rückgabebedingungen-Seite sollte immer gegen einen Blog-Post über Rücksendungen gewinnen. Ein Runbook sollte gegen einen Slack-Thread gewinnen. Reine Similarity weiß das nicht.

Unser Ansatz

Pro Wissensquelle ein Authority-Weight (0,5 bis 2,0). Offizielle Policy-Seiten: 2,0. Help-Center-Artikel: 1,5. Blog: 1,0. Slack-Archiv: 0,7. Externe Seiten: 0,5. Dieses Weight wird nach der Vektorsuche mit dem Similarity-Score multipliziert.

Wichtig: Diese Weights werden vom Merchant selbst konfiguriert, nicht von uns. Wir wissen nicht, welche Quelle in seinem Unternehmen maßgeblich ist. Wir geben Defaults und sie tweaken.

4. Deduplizierung, das versteckte Problem

Viele Inhalte landen in mehreren Formen in deinem Index: ein Artikel + eine Newsletter-Version + eine Slack-Weiterleitung. Vektor-Similarity rankt alle drei hoch, und deine Top-5-Retrievals sind dann eigentlich Top-2 oder Top-3 einzigartige Dokumente mit Varianten.

Effekt: Das LLM bekommt dieselbe Info 5-mal und 'denkt', sie sei wichtig, während du gerade diese Vielfalt brauchst, um eine gute Antwort zu formulieren.

Unser Ansatz

1. Bei der Indexierung: Erkenne Near-Duplicates via MinHash / SimHash. Behalte eine Canonical Version pro Cluster.
2. Beim Retrieval: nach der initialen Top-K-Vektorsuche einen Diversity-Pass ausführen. Bekannt als MMR (Maximal Marginal Relevance). Ergebnis: 5 Retrievals, die jeweils einen anderen Aspekt abdecken, statt 5 Varianten desselben Texts.

5. Query-Rewriting, wo du am meisten rausholst

Die Frage des Nutzers ist selten die optimale Suchanfrage. 'Mein Paket ist weg' ist eine schlechte Vektorsuche-Query. 'Verfahren bei verlorener Sendung, Erstattung, Kontakt mit Versanddienstleister' ist besser.

Unser Ansatz

Ein kleiner LLM-Call vor der Vektorsuche, der die User-Query in 1-3 Suchbegriffe umformuliert. Wir nutzen Claude Haiku, kostet ~0,005 Cent pro Call, Latenz 100-200ms, und der Gewinn an Retrieval-Qualität ist erheblich.

const expanded = await haiku.complete({
  prompt: `Rewrite this user message as 1-3 retrieval queries.
User: ${userMessage}
Context: ${conversationHistory}
Queries (one per line):`,
});
const queries = expanded.split("\n").filter(Boolean);
const results = await Promise.all(queries.map(embedAndSearch));
// merge + dedupe + rank → return top 5

Bonus: Du bekommst jetzt mehrere Kandidaten-Queries, die du für Hybrid Search (Vektor + Keyword/BM25) nutzen kannst, was in der Praxis oft noch einen spürbaren Relevanzgewinn bringt.

Was das ALLES nicht ersetzt

Gutes Wissensmanagement. Wenn deine Dokumentation veraltet, widersprüchlich oder unvollständig ist, rettet dich keine RAG-Technik. Die Techniken oben machen eine gute Wissensdatenbank 30-50% wirksamer. Aus einer schlechten Wissensdatenbank sorgfältiger abzurufen, bleibt das Abrufen schlechter Inhalte.