Warum RAG

In der letzten Lektion hat RepoBot v1 die Frage „Folgt httpx standardmäßig Weiterleitungen?“ falsch beantwortet und eine Versionsgeschichte erfunden, um die Antwort zu stützen. Prompt-Änderungen oder Denken können solche Fehler nur verringern, nicht beseitigen, denn das Modell kann nur aus dem Gedächtnis antworten, und in seinem Gedächtnis sind httpx und requests vermischt.

Was tut ein Mensch bei so einer Frage? Er schlägt in der Dokumentation nach. In dieser Lektion lassen wir das Modell ebenfalls „nachschlagen“.

Experiment: ihm einen Abschnitt der Dokumentation geben

In der httpx-Dokumentation gibt es eine Seite compatibility.md, die eigens die Unterschiede zu requests beschreibt, und darin einen Abschnitt „Redirects“. Ich finde diesen Abschnitt zuerst mit der Zerlegungsfunktion aus Lektion 2 und stelle dann dieselbe Frage zweimal: einmal ohne Unterlagen, einmal mit diesem Abschnitt im Prompt.

section = next(c for c in split_by_heading(load_docs()["compatibility.md"]) if c.startswith("## Redirects"))

answer, tokens = ask([{"role": "user", "content": QUESTION + "用两三句话回答。"}])

prompt = f"""根据下面的 httpx 文档片段回答问题。文档里没有提到的，就说文档里没有。

<doc>
{section}
</doc>

问题：{QUESTION}用两三句话回答。"""
answer, tokens = ask([{"role": "user", "content": prompt}])

Der gefundene Abschnitt:

## Redirects

Unlike `requests`, HTTPX does **not follow redirects by default**.

We differ in behaviour here [because auto-redirects can easily mask unnecessary network
calls being made](https://github.com/encode/httpx/discussions/1785).

You can still enable behaviour to automatically follow redirects, but you need to
do so explicitly...

```python
response = client.get(url, follow_redirects=True)
```

Or else instantiate a client, with redirect following enabled by default...

```python
client = httpx.Client(follow_redirects=True)
```

Die zwei Antworten (vollständiger Code in code/04-rag/why_rag.py; deine Formulierung wird anders sein):

== 不给资料（输入 19 词元）：
会，httpx 默认会自动跟随重定向（最多 20 次）。可以在请求中用 `follow_redirects=False` 关闭，或用 `max_redirects` 调整次数。

== 给了文档片段（输入 169 词元）：
不会。文档明确说明 httpx 与 `requests` 不同，**默认不跟随重定向**。如果想自动跟随，必须显式设置，例如在请求中用 `follow_redirects=True`，或在创建客户端时用 `httpx.Client(follow_redirects=True)`。

Ohne Unterlagen falsch, derselbe Fehler wie bei RepoBot v1. Mit 150 Tokens Dokumentation sofort richtig, samt Begründung und Anleitung zum Einschalten. Die zusätzlichen Kosten sind 150 Eingabe-Tokens, zu den Preisen aus Modul 01, Lektion 4 etwa 0,00005 Dollar.

Das ist die ganze Idee von RAG: erst die passenden Unterlagen finden, dann das Modell danach antworten lassen.

Was RAG ist

RAG steht für Retrieval-Augmented Generation, auf Deutsch etwa abrufgestützte Generierung. Der Name ist lang, zerfällt aber in drei Schritte: Retrieval (Abruf), Augmented (angereichert, das Gefundene in den Prompt einfügen) und Generation (Erzeugung).

Im Experiment oben habe ich „den Redirects-Abschnitt finden“ von Hand erledigt; ich wusste vorher, wo die Antwort steht. Ein echtes RAG-System muss diesen Schritt automatisch erledigen: Zu jeder Frage des Nutzers findet das Programm in einem großen Dokumentenbestand die paar relevantesten Abschnitte. Der vollständige Ablauf hat zwei Teile:

提前准备（只做一次，文档更新时再做）：

  文档 ──▶ 切成小块 ──▶ 为每块建立索引（向量、关键词）──▶ 存起来
          （第 2 课）     （第 3、4 课）

每次提问时：

  用户问题 ──▶ 检索：找出最相关的几块 ──▶ 把这几块和问题一起放进提示词 ──▶ 模型回答
                （第 3、4 课）              （第 5 课：要求它注明引用）

Die folgenden Lektionen dieses Moduls bauen jeden Kasten dieses Bildes: Lektion 2 das Zerlegen, Lektion 3 die Vektorsuche, Lektion 4 Stichwortsuche und die Fusion beider, Lektion 5 das Antworten mit Quellenangaben, Lektion 6 die Bewertung des ganzen Systems, Lektion 7 den Einbau in RepoBot.

Was RAG löst

Was das Modell nicht weiß. Interne Dokumente deiner Firma, der Code deines Projekts, die Versionshinweise der letzte Woche erschienenen Version: Das Modell hat sie im Training nie gesehen. RAG gibt sie ihm im Moment der Frage.

Was das Modell falsch erinnert. Das httpx-Weiterleitungsbeispiel ist so ein Fall. Das Modell „kennt“ httpx, bringt aber etwas durcheinander. Mit dem Originaltext muss es sich nicht aufs Gedächtnis verlassen.

Nachvollziehbarkeit. Das Programm weiß, auf welche Abschnitte sich eine Antwort stützt, und kann sie dem Nutzer zeigen. Der Nutzer kann im Original nachprüfen, und bei Fehlern lässt sich feststellen, ob die Suche oder das Verständnis des Modells versagt hat.

Billige Aktualisierung. Ändert sich die Dokumentation, verarbeitet man nur die geänderten Seiten neu. Neues Wissen per Training in ein Modell zu „bringen“, kostet dagegen viel mehr und wirkt unzuverlässig (Modul 10, Lektion 1 erklärt, warum Finetuning sich nicht für Wissen eignet).

Warum nicht einfach alle Dokumente hineinpacken

Modul 01, Lektion 4 hat das ausprobiert: Die gesamte httpx-Dokumentation hat etwa 29.000 Tokens, und ganz hineingepackt antwortet das Modell auch richtig. Wozu dann der Aufwand mit der Suche?

Weil jedes Mal 29.000 Tokens einzufügen Dutzende Male teurer und viel langsamer ist als die paar hundert relevanten, und der Nutzer jeweils nur einen winzigen Teil braucht. Die httpx-Dokumentation ist noch klein; die Wissensbasis deiner Firma hat vielleicht Dutzende Millionen Tokens und passt gar nicht in den Kontext. Außerdem gilt: Je mehr Irrelevantes drinsteht, desto eher lässt sich das Modell ablenken und sucht an der falschen Stelle.

Beide Wege haben also ihren Bereich:

Prüf zuerst, ob alles hineinpasst. Wenn ja, mach das zuerst und greif nicht vorschnell zu RAG.

Wofür RAG sich nicht eignet

• Die Frage braucht die gesamten Unterlagen. „Fass dieses Dokument zusammen“ oder „wie viele Parameter nennt das Dokument insgesamt“ verlangen den ganzen Text; ein paar gefundene Abschnitte reichen nicht.
• Die Unterlagen selbst sind schlecht. Veraltete, widersprüchliche oder unklare Dokumente führen bei RAG nur dazu, dass das Modell nach falschen Unterlagen antwortet, und weil es eine „Quelle“ gibt, wirkt es noch glaubwürdiger.
• Die Antwort steht in keinem Dokument. Etwa ein Verhalten von httpx, das nur im Quellcode steckt und nicht dokumentiert ist. Dann muss das Modell den Quellcode lesen; das tut der Agent in Modul 05.
• Es braucht Schlussfolgern statt Nachschlagen. Bei „warum wirft mein Code diesen Fehler“ reicht Dokumentation nicht, man muss den Code des Nutzers verstehen. RAG kann passende Dokumentation beisteuern, aber hauptsächlich kommt es auf die Fähigkeit des Modells an.

Übungen

1. Führ code/04-rag/why_rag.py aus und schau, wie deine beiden Antworten aussehen.
2. Nimm eine andere Frage, etwa „Hat die Response von httpx ein Attribut ok?“, such in compatibility.md von Hand den passenden Abschnitt (Tipp: nach „Checking for success“ suchen) und ändere why_rag.py, um denselben Vergleich zu machen.
3. Ersetz die Dokumentation im Prompt von why_rag.py durch irrelevanten Inhalt (etwa einen Abschnitt aus timeouts.md) und stell die Weiterleitungsfrage erneut. Wie antwortet das Modell? Sagt es „davon steht nichts in der Dokumentation“?

Selbsttest

1. Wofür stehen die drei Buchstaben von RAG, und was tut jeder der drei Schritte?

Retrieval (Abruf): anhand der Frage die relevantesten Unterlagen finden; Augmented (angereichert): die gefundenen Unterlagen in den Prompt einfügen; Generation (Erzeugung): das Modell erzeugt anhand der Unterlagen die Antwort.

2. Die Unterlagen umfassen nur 20.000 Tokens und werden täglich einige Dutzend Male abgefragt. Würdest du RAG nutzen?

In der Regel nicht. Sind die Unterlagen klein und die Aufrufe selten, ist es einfacher und zuverlässiger, alles in den Prompt zu packen; feste Unterlagen am Anfang treffen zudem den Cache, und die Kosten bleiben gering. RAG passt, wenn die Unterlagen zu groß für den Kontext sind oder die Aufrufe so häufig, dass alles hineinzupacken zu teuer wird.

3. Warum kann RAG die Lage verschlimmern, wenn die Unterlagen schlecht sind?

Das Modell antwortet nach den gefundenen Unterlagen. Sind sie falsch, ist die Antwort falsch, und weil eine „Quelle“ dabeisteht, glauben Nutzer ihr eher. Die Wirkung von RAG ist durch die Qualität der Unterlagen begrenzt.