Die erste RAG-Demo funktioniert immer.
Du lädst das saubere PDF hoch. Du stellst die offensichtliche Frage. Das Modell findet den offensichtlichen Absatz und antwortet im Ton eines gut finanzierten Beraters.
Dann stellt ein Benutzer die Frage mit dem falschen Akronym, die Richtlinie wurde vor drei Wochen geändert, die Antwort lebt in zwei Dokumenten, und das System zitiert einen Absatz, der zwar verwandt klingt, die Behauptung aber nicht wirklich stützt.
Dann beginnt das Produkt.
Retrieval ist die erste Produktentscheidung
RAG-Qualität beginnt, bevor das Modell überhaupt etwas sieht.
Die Retrieval-Schicht entscheidet, was das Modell wissen darf. Wenn die falschen Chunks zurückkommen, ist die Antwort bereits kompromittiert. Ein besserer Prompt kann das Problem verbergen. Beheben wird er es nicht.
Ich evaluiere Retrieval mit langweiligen Fragen:
- Ist das richtige Dokument in den Top-Ergebnissen aufgetaucht?
- Ist der richtige Abschnitt aufgetaucht, nicht nur die richtige Datei?
- Hat neueres Material älteres Material überholt?
- Hat die Abfrage funktioniert, wenn sie so formuliert war, wie ein echter Benutzer sie formulieren würde?
- Hat das System nichts zurückgegeben, wenn nichts die ehrliche Antwort war?
Der letzte Punkt ist wichtig. Ein Suchsystem, das immer etwas zurückgibt, lehrt das Modell, immer etwas zu sagen.
Zitationstreue ist wichtiger als Antwortzuversicht
Die Antwort allein reicht nicht.
Für jedes Wissenssystem möchte ich wissen, ob die zitierte Quelle den behaupteten Satz tatsächlich stützt.
Das bedeutet, auf Behauptungsebene zu evaluieren, nicht nur auf Antwortebene. Wenn die Antwort vier Behauptungen enthält und nur zwei gestützt werden, ist die Antwort nicht "größtenteils richtig". Sie ist auf eine Weise gefährlich, die poliert aussieht.
Eine einfache Bewertungsmatrix funktioniert:
- Gestützt: die Zitation beweist die Behauptung direkt.
- Teilweise: die Zitation ist verwandt, beweist sie aber nicht vollständig.
- Nicht gestützt: die Zitation beweist die Behauptung nicht.
- Widersprochen: die Zitation sagt das Gegenteil.
Du brauchst keinen aufwändigen Benchmark, um zu beginnen. Du brauchst 30 echte Fragen und die Disziplin, die Fehler ehrlich zu markieren.
Verweigerung ist ein Feature
RAG-Systeme müssen wissen, wann sie nicht antworten sollen.
Das bedeutet, Fragen zu testen, bei denen das Korpus die Antwort nicht enthält. Es bedeutet auch, Fragen zu testen, bei denen die Antwort sensibel, veraltet oder von einem Kontext abhängig ist, den der Benutzer nicht geliefert hat.
Gutes Verweigerungsverhalten klingt so:
"Ich sehe das nicht in den verfügbaren Quellen. Das nächstgelegene verwandte Dokument ist X, aber es beantwortet die Frage nicht direkt."
Schlechtes Verweigerungsverhalten klingt so:
"Basierend auf den verfügbaren Informationen scheint es..."
Dieser Satz ist der Moment, in dem Halluzinationen einen Blazer anziehen.
Die nützliche Bewertungstafel
Für ein internes RAG-System würde ich lieber fünf fundierte Metriken verfolgen als einen beeindruckenden Benchmark-Score:
- Retrieval-Trefferquote: Ist die richtige Quelle erschienen?
- Zitationstreue: Hat die Quelle die Antwort gestützt?
- Verweigerungsgenauigkeit: Hat es nicht gestützte Fragen abgelehnt?
- Antwortnützlichkeit: Konnte der Benutzer den nächsten Schritt tun?
- Editierdistanz: Wie viel musste ein Mensch ändern?
Die letzte Metrik ist die ehrlichste. Wenn Benutzer die Antwort ständig umschreiben, spart das System ihnen keine Zeit. Es erstellt einen höflichen ersten Entwurf, den sie beaufsichtigen müssen.
Klein genug anfangen, um messen zu können
Das richtige erste RAG-System ist normalerweise nicht das "Unternehmensgehirn".
Es ist ein Korpus, ein Workflow, ein Benutzertyp und eine klare Aktion nach der Antwort. Support-Makros. Sales Enablement. Richtliniensuche. Interne Entwicklerdokumentation. Vertragsklauselsuche.
Ein enger Umfang macht Evaluierung möglich.
Evaluierung macht Vertrauen möglich.
Vertrauen macht Erweiterung möglich.
Diese Reihenfolge ist wichtig.
