RAG pour agents : ancrer les réponses sans noyer le contexte
La génération augmentée par récupération est souvent présentée comme un pipeline : vectoriser la question, ramener les meilleurs fragments, coller, générer. Cela marche pour une boîte de questions. Dans un agent, c'est la mauvaise forme, car l'agent ignore ce dont il a besoin tant qu'il n'a pas fait un pas.
La version qui marche traite la recherche comme un outil que l'agent appelle quand il décide qu'il lui faut des preuves — parfois deux fois avec des requêtes différentes, parfois jamais. Ce seul changement supprime beaucoup de contexte inutile et rend l'exécution moins chère et plus nette.
La recherche comme outil, pas comme préambule#
Exposez la recherche comme un outil ordinaire avec un argument de requête et un retour petit et structuré : quelques passages, chacun avec identifiant et source. L'agent décide quand appeler, affine après avoir vu ce qui revient et peut appeler un autre outil si la réponse est structurée. La version pipeline ne peut rien de tout cela et paie la recherche à chaque requête.
Journalisez les requêtes écrites par l'agent. C'est la description la plus honnête que vous aurez de ce que vos utilisateurs demandent vraiment.
Le découpage compte plus que le modèle d'embeddings#
- Découpez par structure — titres, sections, éléments de liste — pas par nombre fixe de caractères.
- Gardez chaque fragment autonome : un fragment qui commence par `Cela exige aussi` est inutile hors contexte.
- Attachez le titre du document et l'intitulé de section à chaque fragment.
- Stockez un identifiant et une URL avec chaque fragment pour pouvoir citer.
- Préférez peu de fragments grands et significatifs ; le chevauchement est un pansement.
L'hybride bat le vectoriel pur sur de vrais corpus#
| Type de requête | Recherche vectorielle | Mots-clés | Le mieux |
|---|---|---|---|
| Question conceptuelle | Forte | Faible | Vectorielle |
| Code produit ou message d'erreur exact | Faible | Forte | Mots-clés |
| Nom propre rare | Mitigée | Forte | Mots-clés |
| Question de politique reformulée | Forte | Faible | Vectorielle |
| Trafic réel dans l'ensemble | Mitigée | Mitigée | Les deux, fusionnés et reclassés |
Faites citer, et permettez l'échec#
Deux exigences font l'essentiel de la fiabilité. D'abord, chaque affirmation issue de la recherche porte l'identifiant de son passage et votre interface en fait un lien : le non étayé devient visible plutôt que plausible. Ensuite, la recherche doit pouvoir ne rien renvoyer, et l'agent doit avoir appris que `je ne trouve pas cela dans notre documentation` est un bon résultat. Un agent qui ne peut pas échouer en recherche inventera.
Garder l'index honnête#
La qualité de recherche se dégrade en silence. Les documents changent, des sections disparaissent, et l'index continue de servir ce qu'il a vu en dernier. Réindexez régulièrement, supprimez les fragments dont la source n'existe plus et gardez un petit jeu de requêtes à passages corrects connus pour mesurer après chaque changement. Sans cela, on aboutit à un agent citant avec assurance une politique retirée en mars.
Questions fréquentes
L'agent doit-il toujours chercher avant de répondre ?
Non. Chercher à chaque requête gaspille de la latence et remplit le contexte pour des questions sans besoin de preuve. Laissez l'agent décider et mesurez à quelle fréquence il aurait dû chercher.
Combien de passages renvoyer ?
Trois à six bien choisis valent mieux que vingt. Plus de texte dilue l'attention, augmente le coût et le risque de s'appuyer sur un passage seulement en apparence pertinent.
Et si la recherche ne renvoie rien d'utile ?
Ce doit être une issue prise en charge. Renvoyez un vide explicite et demandez à l'agent de dire qu'il n'a pas trouvé et de proposer l'étape suivante.
rag pour agentsgénération augmentée par récupérationrecherche hybridestratégie de découpageréponses ancrées
