Woran man erkennt, ob RAG gut ist

Bisher haben wir immer nur bewertet, „ob die Suche das Richtige gefunden hat“. Der Nutzer sieht am Ende aber die Antwort. Selbst wenn die Suche alles richtig findet, kann die Antwort falsch sein: Das Modell kann etwas in den Unterlagen übersehen, zwei Abschnitte vermischen oder sich nicht verkneifen, eigenes „Wissen“ hinzuzufügen. Umgekehrt kann die Antwort richtig sein, obwohl die Suche den genauesten Chunk nicht gefunden hat.

Die Bewertung von RAG hat deshalb zwei Hälften: Suche und Antwort. Diese Lektion zeigt, wie man beide angeht, mit dem Schwerpunkt auf der Bewertung der Antworten und einer großen Falle dabei.

Beide Hälften getrennt bewerten

Getrennt zu bewerten hat den Vorteil, dass man bei Problemen weiß, wo man ansetzen muss:

Wer nur auf die Richtigkeit der Endantwort schaut, kann den zweiten nicht vom dritten Fall unterscheiden und doktert blind herum.

Die Bewertung der Suche haben wir schon: Trefferquote und MRR aus Lektion 3. Diese Lektion bewertet die Antworten.

Was man an einer Antwort bewertet

Bei RAG-Antworten schaut man am häufigsten auf zwei Dinge:

• Richtigkeit: Stimmt die Antwort? Dazu braucht man eine Musterantwort zum Vergleich.
• Treue: Lässt sich jede Aussage der Antwort in den gefundenen Unterlagen belegen? Ob die Antwort stimmt, ist dabei egal; es geht nur darum, ob sie „über die Unterlagen hinausgeht“.

Die Treue bewertet man gesondert, weil sie ein verstecktes Problem aufdeckt: Die Antwort ist zufällig richtig, stützt sich aber auf das Gedächtnis des Modells, nicht auf die Unterlagen. Diesmal stimmt es, beim nächsten Mal vielleicht nicht, und nachvollziehen lässt es sich auch nicht.

Musterantworten vorbereiten

Für jede der 20 Fragen aus Lektion 3 habe ich eine Musterantwort geschrieben, jeweils nach dem Originalabschnitt aus der Suchbewertung, zum Beispiel:

{"question": "怎么关闭 SSL 证书校验？", ..., "reference": "传 verify=False，比如 httpx.get(url, verify=False)；用 Client 时在创建客户端时传入。"}
{"question": "httpx 和 requests 在处理重定向上有什么不一样？", ..., "reference": "requests 默认跟随重定向，httpx 默认不跟随；httpx 要显式传 follow_redirects=True（单个请求或 Client 上都可以）。"}

Musterantworten müssen nicht lang sein; es genügt, die Punkte klar zu nennen, die enthalten sein müssen. Wie man gleich sehen wird, beeinflusst die Formulierung der Musterantwort aber direkt die Bewertung.

Ein Modell als Gutachter

20 Fragen mit je zwei Antworten (einmal ohne Unterlagen, einmal mit RAG) von Hand zu beurteilen, ist mühsam. Üblich ist, ein anderes Modell urteilen zu lassen, den Modell-Gutachter (LLM-as-a-judge). Als Gutachter dient das stärkere deepseek-v4-pro mit eingeschaltetem Denken:

def judge_correct(question, reference, answer):
    return judge(f"""判断"回答"是否正确地回答了"问题"。以"参考答案"为准：回答包含参考答案的要点、且没有和它矛盾的内容，就算正确。
回答比参考答案多说了一些内容没关系，只要多说的部分没有错误。
输出 json：{{"correct": true 或 false, "reason": "一句话理由"}}

问题：{question}
参考答案：{reference}
回答：{answer}""")


def judge_faithful(context, answer):
    return judge(f"""判断"回答"里的每一个事实性说法，是否都能在"资料"里找到依据。
回答说"资料里没有"之类的话不算事实性说法。只要有一处说法在资料里找不到依据，就判为不忠实。
输出 json：{{"faithful": true 或 false, "unsupported": "找不到依据的说法，没有就写空字符串"}}

资料：
{context}

回答：{answer}""")

Ein paar Designentscheidungen:

• Gutachter und begutachtetes Modell sind verschiedene Modelle. Bewertet sich ein Modell selbst, übersieht es leicht seine eigenen Fehler.
• Eine Begründung verlangen. Nicht nur true oder false, sondern auch ein Satz zum Warum. Wie du gleich siehst, ist die Begründung der einzige Hinweis, um Fehler des Gutachters zu entdecken.
• Kriterien klar aufschreiben. Der Satz „mehr zu sagen ist in Ordnung, solange das Zusätzliche nicht falsch ist“ verhindert, dass der Gutachter eine Antwort nur deshalb als falsch wertet, weil sie ausführlicher ist als die Musterantwort.

Die Funktion judge ruft den Gutachter im JSON-Modus aus Modul 02, Lektion 4 auf. Vollständiger Code in code/04-rag/rag_eval.py; ein Lauf sind etwa 80 Aufrufe und kostet etwa 0,1 Dollar.

Das Urteil des Gutachters

不查资料：答对 15/20
RAG：    答对 19/20，忠实于资料 19/20

[不查资料答错] 响应是 404 或 500 时，怎么让它直接抛异常？
    评委：回答中“3xx不会抛”与参考答案“状态码不是2xx时会抛出”矛盾
[不查资料答错] httpx 和 requests 在处理重定向上有什么不一样？
    评委：回答错误地声称httpx默认跟随重定向，与参考答案中“httpx默认不跟随”相矛盾。
[不查资料答错] 怎么限制连接池里最多同时有多少个连接？
    评委：回答遗漏了参考答案中默认 max_connections=100 这一要点，未完整包含参考答案的默认值信息。
[不查资料答错] 怎么显示下载进度？
    评委：回答未使用参考答案中的 response.num_bytes_downloaded 属性，而是手动累计长度
[不查资料答错] 网页返回的中文是乱码，怎么指定解码用的字符集？
    评委：回答未提及参考答案中的 default_encoding 参数指定字符集的方法
[RAG 答错] httpx 和 requests 在处理重定向上有什么不一样？
    评委：回答中关于 requests 暴露的属性 response.next 的描述有误，requests 并没有该属性。
[RAG 不忠实] 怎么显示下载进度？
    找不到依据：显示下载进度需要用流式响应（streaming），并检查 `response.num_bytes_downloaded` 属性

Das Ergebnis wirkt klar: RAG steigert die Richtigkeit von 15/20 auf 19/20. Aber nicht vorschnell urteilen. Jedes „falsch“ habe ich mir in der Originalantwort angesehen und mit Dokumentation und Quellcode von httpx abgeglichen.

Den Gutachter Urteil für Urteil prüfen

„3xx wirft nicht“: Der Gutachter hatte recht. Die Antwort ohne Unterlagen sagte, raise_for_status() werfe bei 3xx keine Ausnahme. Im httpx-Quellcode _models.py steht bei raise_for_status: Alles, was nicht 2xx ist (is_success falsch), wirft HTTPStatusError, und bei 3xx heißt der Fehlertyp „Redirect response“. Die Antwort war also tatsächlich falsch.

Weiterleitungen: Die Antwort ohne Unterlagen war falsch, der Gutachter hatte recht. Wieder behauptete sie, httpx folge standardmäßig Weiterleitungen, sogar „ab 0.20+ standardmäßig“, genau derselbe Fehler wie bei RepoBot v1.

Verbindungspool: Der Gutachter war zu streng. Die Antwort ohne Unterlagen nannte korrekt httpx.Limits(max_connections=..., max_keepalive_connections=...), erwähnte nur nicht den Standardwert 100. Gefragt war „wie begrenzt man“, nicht nach dem Standardwert. Das Problem lag an meiner Musterantwort, in die ich nebenbei „standardmäßig höchstens 100 Verbindungen“ geschrieben hatte; der Gutachter hielt das für einen Pflichtpunkt.

Download-Fortschritt: Das Urteil des Gutachters war berechtigt. Die Antwort ohne Unterlagen summierte die heruntergeladenen Bytes von Hand mit len(chunk). Die httpx-Dokumentation sagt eigens, dass bei aktivierter Kompression die entpackte Länge nicht zu den tatsächlich heruntergeladenen Bytes passt und man daher response.num_bytes_downloaded nutzen soll. Der Ansatz der Antwort funktioniert ohne Kompression, ist aber nicht der richtige.

Kodierung: Der Gutachter lag falsch. Die Antwort ohne Unterlagen sagte: vor dem Zugriff auf response.text response.encoding = "gbk" setzen. Ich habe im httpx-Quellcode nachgesehen: Response.encoding hat einen Setter, der das Setzen der Kodierung vor dem Lesen von text erlaubt (danach wirft er ValueError). Das ist ein völlig korrekter anderer Weg. Der Gutachter wertete ihn als falsch, weil „default_encoding aus der Musterantwort nicht erwähnt“ wurde; er hielt die Musterantwort für die einzige richtige.

Die RAG-Antwort zu Weiterleitungen: Der Gutachter lag falsch. Er schrieb, „requests hat kein Attribut response.next“. Aber in Zeile 50 von compatibility.md der httpx-Dokumentation steht wörtlich: „The requests library exposes an attribute response.next, which can be used to obtain the next redirect request.“ Die RAG-Antwort folgte der Dokumentation und war richtig. Der Gutachter hat die Unterlagen nicht angesehen, aus dem eigenen Gedächtnis geurteilt und sich dabei selbst geirrt.

RAG zum Download-Fortschritt: „nicht treu“ war falsch. Ich habe die Suche für diese Frage wiederholt; die ersten beiden Chunks stammen aus advanced/clients.md und enthalten beide num_bytes_downloaded, und im Text steht ausdrücklich, eine gestreamte Antwort zu nutzen und dieses Attribut zu prüfen. Die Antwort war den Unterlagen völlig treu; der Gutachter hat nicht genau hingesehen.

Ergebnis nach der Prüfung

Die Richtung des Ergebnisses bleibt: RAG ist deutlich besser als ohne Unterlagen, und die Antworten ohne Unterlagen hatten bei zwei Fragen echte Fehler. Aber die konkreten Zahlen haben sich geändert, und der Gutachter lag bei 60 Urteilen dreimal falsch und war einmal zu streng.

Die vier Probleme lassen sich in zwei Arten einteilen:

• Der Gutachter nutzt nicht das ihm gegebene Material, sondern eigenes Wissen. Das response.next-Urteil ist so ein Fall. Auch der Gutachter ist ein Sprachmodell und erinnert sich falsch.
• Er hält die Musterantwort für die einzige Antwort. Die Urteile zu Kodierung und Verbindungspool sind so. Gibt es mehrere richtige Wege und nennt die Musterantwort nur einen, wertet der Gutachter die anderen richtigen Wege als falsch.

Wie man den Gutachter verlässlicher macht

• Immer Stichproben machen. Die Urteile des Gutachters nie direkt als Ergebnis nehmen. Mindestens alle „falsch“ von Hand prüfen und zufällig einige „richtig“ ansehen.
• Vom Gutachter Begründungen verlangen. Die Probleme diesmal wurden nur dank der Begründungen gefunden. „requests hat dieses Attribut nicht“ wirkt auf den ersten Blick verdächtig, und ein Nachschlagen zeigt, dass der Gutachter irrte.
• Musterantworten als Punkte formulieren und andere richtige Wege zulassen. Im Prompt erklären, dass „andere richtige Wege außer der Musterantwort auch richtig sind“. In die Musterantwort nur das schreiben, was die Frage wirklich fragt.
• Der Treue-Gutachter muss die Unterlagen ansehen. Im Prompt betonen: „Nur anhand der Unterlagen urteilen, nicht mit eigenem Wissen.“
• Den Gutachter mit menschlichen Markierungen kalibrieren. Einige Dutzend von Hand markieren, sehen, wie oft Gutachter und Mensch übereinstimmen, und bei zu geringer Übereinstimmung den Prompt des Gutachters ändern. Modul 06, Lektion 2 behandelt das systematisch.

Das Fazit dieser Lektion

• Die Bewertung von RAG teilt man in Suche und Antwort; nur getrennt sieht man, wo das Problem liegt.
• Bei Antworten schaut man am häufigsten auf Richtigkeit und Treue.
• Ein Modell-Gutachter spart viel menschliche Arbeit, irrt sich aber, und zwar selbstsicher. Die Ausgabe des Gutachters sind Daten, die geprüft werden müssen, kein endgültiges Ergebnis.

Übungen

1. Entferne in eval_qa.jsonl bei den Musterantworten zu Verbindungspool und Kodierung, wonach nicht gefragt wurde, füg dem Prompt des Gutachters „andere richtige Wege außer der Musterantwort sind auch richtig“ hinzu und lass rag_eval.py erneut laufen. Haben sich die Urteile geändert?
2. Füg dem Prompt des Treue-Gutachters „nur anhand der Unterlagen urteilen, kein eigenes Wissen verwenden“ hinzu, lass es erneut laufen und schau, ob sich das Urteil zum Download-Fortschritt ändert.
3. Wähle 5 Fragen und sei selbst Gutachter: Ist die Antwort ohne Unterlagen richtig? Bei wie vielen Fragen urteilst du anders als der Modell-Gutachter?

Selbsttest

1. Warum trennt man bei der Bewertung von RAG Suche und Antwort?

Schaut man nur auf die Endantwort, kann man nicht unterscheiden, in welchem Schritt der Fehler lag: ob die richtigen Unterlagen nicht gefunden wurden oder richtig übergeben, aber vom Modell schlecht genutzt. Getrennt bewertet, weiß man, ob man an der Suche (Zerlegung, Umformulierung, Suchmethode) oder an der Erzeugung (Prompt, Modell) ansetzen muss.

2. Eine RAG-Antwort ist richtig, die Treue-Bewertung sagt aber „nicht treu“. Was bedeutet das?

Ein Teil der Antwort ist in den gefundenen Unterlagen nicht belegt und stammt wahrscheinlich aus dem Gedächtnis des Modells. Diesmal war es zufällig richtig, bei einer anderen Frage kann es falsch sein, und die Herkunft ist nicht nachvollziehbar. Natürlich kann sich auch der Gutachter geirrt haben; das muss ein Mensch prüfen.

3. Der Modell-Gutachter wertet eine Antwort als „falsch“, weil sie „eine Methode aus der Musterantwort nicht erwähnt“. Was tust du?

Zuerst prüfen, ob die in der Antwort verwendete Methode ebenfalls richtig ist. Musterantworten nennen oft nur einen Weg, und der Gutachter wertet dann andere richtige Wege als falsch. Stellt sich die Antwort als richtig heraus, ändert man den Prompt des Gutachters (andere richtige Wege zulassen) oder die Musterantwort.