Pourquoi le RAG

À la leçon précédente, RepoBot v1 s'est trompé sur « httpx suit-il les redirections par défaut ? », et a même inventé un historique de versions pour se justifier. Retoucher le prompt ou activer la réflexion ne fait que réduire ce genre d'erreur sans l'éliminer, car le modèle ne peut répondre que de mémoire, et dans sa mémoire, httpx et requests se mélangent.

Que fait un humain face à ce problème ? Il consulte la documentation. Dans cette leçon, nous faisons « consulter la documentation » au modèle aussi.

Expérience : lui donner un passage de documentation

La documentation de httpx contient un fichier compatibility.md consacré aux différences avec requests, dont une section s'intitule justement « Redirects ». Je retrouve d'abord cette section avec la fonction de découpage présentée à la leçon 2, puis je pose deux fois la même question : une fois sans aucun document, une fois avec cette section dans le 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}])

Le passage trouvé est le suivant :

## 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)
```

Les deux réponses (code complet dans code/04-rag/why_rag.py ; votre formulation sera différente) :

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

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

Sans documents, il se trompe, exactement comme RepoBot v1. Avec un passage de 150 tokens, il répond juste immédiatement, en expliquant pourquoi et comment activer le suivi. Le surcoût : 150 tokens d'entrée, soit environ 0,00005 dollar aux prix de la leçon 4 du module 01.

Voilà toute l'idée du RAG : trouver d'abord les documents pertinents, puis faire répondre le modèle d'après eux.

Qu'est-ce que le RAG

RAG est l'abréviation de Retrieval-Augmented Generation, en français génération augmentée par la recherche. Le nom est long, mais il se décompose en trois étapes : la recherche (retrieval), l'augmentation (augmented, ajouter les documents trouvés au prompt), la génération (generation).

Dans l'expérience ci-dessus, c'est moi qui ai « trouvé la section Redirects », à la main, parce que je savais d'avance où était la réponse. Un vrai système RAG doit faire cette étape automatiquement : pour n'importe quelle question de l'utilisateur, le programme doit trouver les quelques passages les plus pertinents dans une masse de documents. Le déroulé complet se divise en deux parties :

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

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

每次提问时：

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

Les leçons suivantes de ce module construisent chaque case de ce schéma : leçon 2 le découpage, leçon 3 la recherche vectorielle, leçon 4 la recherche par mots-clés et la fusion des deux, leçon 5 les réponses avec citations, leçon 6 l'évaluation de tout le système, leçon 7 l'intégration dans RepoBot.

Ce que résout le RAG

Ce que le modèle ne sait pas. Les documents internes de votre entreprise, le code de votre projet, les notes de version publiées la semaine dernière : le modèle ne les a jamais vus à l'entraînement. Le RAG les lui fournit sur le moment.

Ce dont le modèle se souvient mal. C'est le cas des redirections de httpx. Le modèle « connaît » httpx, mais confond. Avec le texte d'origine, il n'a plus besoin de sa mémoire.

La traçabilité. Le programme sait de quels passages provient la réponse et peut les montrer à l'utilisateur. L'utilisateur peut ouvrir le texte d'origine pour vérifier, et en cas d'erreur, on sait si c'est la recherche ou la compréhension du modèle qui a failli.

Des mises à jour bon marché. Quand la documentation change, il suffit de retraiter les pages modifiées. Par comparaison, vouloir « apprendre » de nouvelles connaissances au modèle par l'entraînement coûte beaucoup plus cher, pour un résultat peu fiable (la leçon 1 du module 10 explique pourquoi le fine-tuning ne convient pas pour injecter des connaissances).

Pourquoi ne pas tout mettre dans la requête

La leçon 4 du module 01 a fait l'expérience : toute la documentation de httpx fait environ 29 000 tokens, et avec tout dedans, le modèle répond juste aussi. Alors pourquoi se donner la peine de chercher ?

Parce que mettre 29 000 tokens à chaque fois coûte des dizaines de fois plus cher et est bien plus lent que ne mettre que quelques centaines de tokens pertinents, alors que l'utilisateur n'a besoin que d'une toute petite partie. La documentation de httpx est encore petite ; la base de connaissances de votre entreprise peut compter des dizaines de millions de tokens, impossibles à mettre dans le contexte. Et plus il y a de contenu non pertinent, plus le modèle risque d'être distrait et de chercher au mauvais endroit.

Les deux méthodes ont donc chacune leur domaine :

Demandez-vous d'abord si tout peut tenir dans la requête. Si oui, commencez ainsi, sans vous précipiter sur le RAG.

Quand le RAG ne convient pas

• La question demande de synthétiser l'ensemble des documents. « Résume ce document », « combien de paramètres le document mentionne-t-il en tout ? » : ces questions exigent le texte complet, quelques passages trouvés ne suffisent pas.
• Les documents sont de mauvaise qualité. Documentation obsolète, contradictoire ou floue : le RAG fera simplement répondre le modèle d'après de mauvais documents, et, « source » à l'appui, la réponse paraîtra plus crédible.
• La réponse n'est dans aucun document. Par exemple, un comportement de httpx qui n'apparaît que dans le code source, pas dans la documentation. Il faut alors faire lire le code source au modèle ; c'est le travail des agents du module 05.
• Il faut raisonner plutôt que chercher. « Pourquoi mon code plante-t-il ? » : trouver de la documentation ne suffit pas, il faut comprendre le code de l'utilisateur. Le RAG peut fournir de la documentation pertinente en appui, mais c'est surtout la capacité du modèle lui-même qui compte.

Exercices

1. Lancez code/04-rag/why_rag.py et voyez à quoi ressemblent vos deux réponses.
2. Changez de question, par exemple « la Response de httpx a-t-elle un attribut ok ? », trouvez à la main la section correspondante dans compatibility.md (indice : cherchez « Checking for success »), et modifiez why_rag.py pour faire la même comparaison.
3. Remplacez le passage mis dans le prompt de why_rag.py par un contenu sans rapport (par exemple une section de timeouts.md), et reposez la question sur les redirections. Comment le modèle répond-il ? Dit-il que « la documentation n'en parle pas » ?

Auto-test

1. Que représentent les trois lettres de RAG, et que fait chacune de ces étapes ?

Retrieval (recherche) : trouver les documents les plus pertinents pour la question ; Augmented (augmentation) : ajouter les documents trouvés au prompt ; Generation (génération) : le modèle génère la réponse d'après ces documents.

2. Vos documents ne font que vingt mille tokens, et on vous pose quelques dizaines de questions par jour. Utiliseriez-vous le RAG ?

En général non. Quand les documents sont petits et les appels peu fréquents, mettre tout le document dans le prompt est plus simple et plus fiable ; les documents fixes placés en tête touchent le cache, et le coût reste faible. Le RAG convient quand les documents sont trop grands pour le contexte, ou quand les appels sont si fréquents que tout mettre coûterait trop cher.

3. Pourquoi le RAG peut-il aggraver les choses quand les documents sont de mauvaise qualité ?

Le modèle répond d'après les documents trouvés. Si les documents sont faux, la réponse l'est aussi, et comme elle est accompagnée d'une « source », l'utilisateur la croira plus facilement. L'efficacité du RAG est limitée par la qualité des documents eux-mêmes.