Architecture RAG moderne : au-delà de la simple boucle retrieve-and-generate
Un pipeline RAG naïf (embedder, chercher, injecter dans le prompt) suffit pour une démo. Le RAG de production a besoin d'une stratégie de chunking, de recherche hybride, de transformation de requête, de re-ranking et d'une boucle d'évaluation. Voici l'architecture complète.
Un pipeline RAG naïf (embedder des chunks de documents, faire une recherche par similarité, injecter les meilleurs résultats dans un prompt) suffit à construire une démo convaincante. Ça ne suffit pas à tenir en production, où le bruit de récupération, un mauvais chunking et l'absence de boucle de feedback dégradent silencieusement la qualité des réponses. Voici l'architecture qui tient, composant par composant.
Le pipeline dans son ensemble
Chaque étape alimente la suivante, et la boucle d'évaluation les alimente toutes. Une étape faible plafonne la qualité de tout ce qui suit, ce qui explique pourquoi les corrections de récupération battent généralement les ajustements de prompt.
documents
|
[ chunking ] --- fixe / sémantique / hiérarchique
|
[ embed + index ] --- vecteurs denses + sparse (BM25)
|
question --> [ transform. requête ] --- réécriture / HyDE / multi-query
|
[ recherche hybride ] --- dense + sparse, fusionnés (RRF)
|
[ re-ranking ] --- cross-encoder sur le top 20-50
|
[ génération ] --- prompt ancré, cite les sources
|
réponse ---> [ évaluation ] ---> retour vers chaque étapeIndexation : le chunking est une décision d'architecture
La stratégie de chunking détermine tout ce qui suit. Le chunking à taille fixe est le défaut courant, mais il coupe des phrases et des idées en deux. Le chunking sémantique découpe sur les frontières de sens ; le chunking hiérarchique garde des petits chunks pour une récupération précise, liés à un chunk parent plus large pour le contexte. Les deux surpassent le découpage à taille fixe sur des documents réels.
| Stratégie | Précision de récupération | Contexte conservé | Coût de mise en place |
|---|---|---|---|
| Taille fixe | Moyenne, coupe les idées | Faible | Faible |
| Sémantique | Élevée | Bon | Moyen |
| Hiérarchique (parent-enfant) | Élevée | Élevé, le parent donne le contexte | Moyen à élevé |
Transformation de requête : corrigez la question avant de chercher
La question de l'utilisateur n'est souvent pas la meilleure requête de recherche. Réécrivez-la sous une forme autonome quand elle dépend de l'historique de conversation. Utilisez HyDE (générer une réponse hypothétique et embedder celle-ci à la place) quand questions et documents utilisent un vocabulaire différent. Éclatez une question complexe en plusieurs sous-requêtes et récupérez pour chacune. Ce sont des appels LLM peu coûteux qui améliorent la récupération plus qu'un plus gros modèle d'embedding.
Recherche hybride : la recherche vectorielle seule ne suffit pas
La similarité vectorielle pure excelle sur les correspondances conceptuelles et faiblit sur les correspondances exactes : codes produit, codes d'erreur, noms propres. Combinez la recherche vectorielle dense avec une recherche par mots-clés sparse (BM25) et fusionnez les deux ensembles de résultats avec du reciprocal rank fusion.
def hybrid_search(query: str, k: int = 10):
dense_results = vector_store.similarity_search(query, k=20)
sparse_results = bm25_index.search(query, k=20)
return reciprocal_rank_fusion([dense_results, sparse_results], k=k)
def reciprocal_rank_fusion(result_lists, k, rrf_k=60):
scores = {}
for results in result_lists:
for rank, doc in enumerate(results):
scores[doc.id] = scores.get(doc.id, 0) + 1 / (rrf_k + rank + 1)
return sorted(scores.items(), key=lambda x: x[1], reverse=True)[:k]Re-ranking : une seconde passe, plus coûteuse
Récupérez largement et à moindre coût d'abord (20 à 50 candidats), puis re-rankez avec un cross-encoder qui score la requête et chaque document ensemble. Les cross-encoders sont bien plus précis que la similarité d'embeddings mais trop lents pour tourner sur tout le corpus, ils ont donc leur place à l'étape de re-ranking, pas à la récupération initiale.
RAG agentique : la récupération comme outil, pas comme étape fixe
Plutôt que de toujours récupérer une fois avant de générer, laissez le modèle décider si la récupération est même nécessaire, et autorisez une récupération en plusieurs étapes pour les questions complexes : chercher, évaluer les résultats, chercher à nouveau avec une requête affinée si la première passe n'était pas satisfaisante. Ça coûte plus de tokens et de latence, réservez-le aux questions qui en ont vraiment besoin.
Génération : ancrée, et elle cite ses sources
Le prompt demande au modèle de répondre uniquement à partir du contexte récupéré, de dire qu'il ne sait pas sinon, et d'attacher la source de chaque affirmation. Renvoyer les chunks sources avec la réponse est ce qui rend un système RAG auditable, et c'est la différence entre une réponse plausible et une réponse vérifiable.
Évaluation et observabilité : la partie que tout le monde saute
- ✓Mesurez la qualité de la récupération séparément de la qualité de génération : recall@k et précision, pas seulement si la réponse sonnait juste.
- ✓Loggez les chunks récupérés à côté de chaque réponse générée ; impossible de déboguer une mauvaise réponse sans voir ce que le modèle a vraiment vu.
- ✓Utilisez un jeu d'évaluation labellisé ou un LLM-as-judge pour attraper les régressions avant qu'elles n'atteignent la production.
- ✓Surveillez les échecs silencieux de récupération : ensembles de résultats vides, chunks non pertinents scorés comme pertinents, index obsolètes.
| Composant | Version naïve | Version moderne |
|---|---|---|
| Chunking | Taille fixe | Sémantique ou hiérarchique |
| Requête | Utilisée telle quelle | Réécrite, HyDE, multi-query |
| Récupération | Top-k dense | Dense plus sparse, fusionnés en RRF |
| Classement | Score d'embedding | Re-rank par cross-encoder |
| Flux de contrôle | Toujours récupérer une fois | Agentique, récupère quand nécessaire |
| Qualité | Évaluée à l'oeil | Récupération et génération notées séparément |
La plupart des problèmes de qualité RAG vivent dans la récupération, pas dans la génération. Avant de fine-tuner un modèle ou de changer de fournisseur, auditez ce que votre retriever retourne réellement pour vos requêtes les plus difficiles ; c'est généralement là qu'est la correction.
FAQ
- Qu'est-ce que la recherche hybride en RAG ?
- Lancer une recherche vectorielle dense et une recherche par mots-clés sparse (BM25) en parallèle, puis fusionner les deux listes de résultats, généralement avec du reciprocal rank fusion. La recherche vectorielle gère les correspondances conceptuelles, la recherche par mots-clés gère les termes exacts comme les codes et les noms, et ensemble elles battent chacune prise seule.
- À quoi sert le re-ranking ?
- Il lance une seconde passe de scoring plus précise sur les 20 à 50 meilleurs candidats récupérés, avec un cross-encoder qui lit la requête et chaque document ensemble. Trop lent pour tout le corpus mais peu coûteux sur une liste courte, il améliore nettement quels chunks arrivent dans le prompt.
- Qu'est-ce que le RAG agentique ?
- Un design RAG où la récupération est un outil que le modèle peut choisir d'appeler, plutôt qu'une étape fixe. Le modèle décide s'il a besoin de chercher, peut chercher plusieurs fois avec des requêtes affinées, et peut évaluer ses propres résultats. Il convient aux questions complexes et coûte plus cher par réponse.
- Comment choisir sa stratégie de chunking ?
- Commencez par le chunking sémantique pour que les chunks cassent sur les frontières de sens. Ajoutez une couche parent-enfant (hiérarchique) si les réponses ont besoin d'un contexte environnant qu'un petit chunk perd. Puis ajustez les tailles avec votre jeu d'évaluation plutôt que de deviner.
- Comment mesurer la qualité d'un système RAG ?
- Notez récupération et génération séparément. Pour la récupération, utilisez recall@k et précision face à un jeu labellisé : le bon chunk est-il dans le top-k. Pour la génération, vérifiez la fidélité au contexte et la pertinence de la réponse, avec un jeu labellisé ou un LLM-as-judge, et rejouez à chaque changement du pipeline.
Une architecture RAG de production est un pipeline avec des boucles de feedback, pas une simple fonction embed-search-generate. Traitez la qualité de la récupération comme une métrique de premier ordre, mesurée, et le reste du système devient bien plus facile à raisonner et à améliorer.
Besoin d'aide sur ce sujet ? Intégration IA & RAG
Découvrir ce service →