RAG in der Praxis: Warum die Suche wichtiger ist als das Modell

Ein Assistent, der auf die eigene Dokumentation antwortet, besteht aus zwei Teilen: einer Suche, die Passagen findet, und einem Modell, das daraus eine Antwort formuliert. Wenn die Antwort schlecht ist, liegt es in den meisten Fällen am ersten Teil.

Erst die Suche messen, dann das Modell tauschen

Die entscheidende Frage lautet: Steht die richtige Antwort überhaupt unter den zurückgegebenen Passagen? Diese Kennzahl lässt sich ohne Modell prüfen. Liegt sie bei 60 %, kann kein Sprachmodell der Welt daraus zuverlässige Antworten machen.

1def hit_rate(cases, retrieve, k: int = 5) -> float:
2    """Anteil der Anfragen, bei denen die richtige Passage unter den Top-k liegt."""
3    hits = 0
4    for case in cases:
5        passages = retrieve(case.query, k=k)
6        if any(p.id == case.expected_id for p in passages):
7            hits += 1
8    return hits / len(cases)
9
10
11# Zielwerte aus der Praxis
12#   > 90 %   solide Basis
13#   70–90 %  Chunking und Metadaten prüfen
14#   < 70 %   Indexaufbau überarbeiten

[Bild: Vier verbundene Kästen: Anfrage, Suche, Reranking, Antwort — Die vier Stationen einer Anfrage. Die meisten Qualitätsprobleme entstehen zwischen Schritt zwei und drei.]

Die häufigsten Ursachen

• Zu große Chunks: Ein 4.000-Zeichen-Block verwässert den Vektor bis zur Unbrauchbarkeit.
• Fehlende Metadaten: Ohne Produkt, Version und Datum trifft die Suche veraltete Stände.
• Rein semantische Suche: Bei Fehlercodes und Artikelnummern schlägt klassisches Keyword-Matching die Vektorsuche deutlich.
• Kein Reranking: Die ersten zwanzig Kandidaten sortiert ein Cross-Encoder deutlich besser als die reine Ähnlichkeit.

Erst wenn die Trefferquote stimmt, lohnt die Arbeit am Antwortteil: Zitate erzwingen, Unsicherheit zulassen, und dem Modell erlauben zu sagen, dass die Information nicht vorliegt.