Pourquoi ce sujet est important
Quand un RAG simple atteint ses limites, ajouter plus de chunks ou un modèle plus grand ne règle pas toujours le problème. Il faut identifier l’étape défaillante : formulation de la requête, récupération des candidats, classement ou génération.
Établir la baseline
Mesurez retrieval et réponse séparément. Créez des requêtes avec documents attendus, puis calculez recall@k, MRR ou nDCG. Ajoutez citations et qualité finale. Sans baseline, plusieurs techniques ajoutées ensemble rendent les gains impossibles à attribuer.
Réécrire ou étendre la requête
La query expansion génère synonymes, sous-questions ou variantes. Elle aide les requêtes courtes et multi-hop, mais peut dériver. Limitez le nombre, conservez la requête originale et fusionnez les résultats. Pour les identifiants exacts, privilégiez lexical et filtres.
Combiner les recherches
La recherche hybride associe BM25 et embeddings. Utilisez une fusion de rangs ou scores calibrés. Ajoutez filtres de langue, date, produit et droits. Comparez dense, lexical et hybride par type de requête.
Reranker les candidats
Un reranker évalue plus finement la paire requête-document sur un petit ensemble. Il peut améliorer les premiers résultats au prix de latence et coût. Ajustez le nombre de candidats et mesurez le gain sur la réponse, pas seulement le classement.
Router selon la demande
Un routeur choisit collection, stratégie ou absence de retrieval. Utilisez règles pour catégories évidentes et un classifieur évalué pour les autres. Prévoyez une route de secours. Le routage ne doit pas contourner les droits.
Décomposer les questions
Pour une question multi-hop, générez des sous-questions, récupérez les preuves et synthétisez avec provenance. Borner les étapes évite explosion du coût. Vérifiez chaque sous-réponse avant de la réutiliser.
Optimiser coût et latence
Cachez embeddings et résultats appropriés, parallélisez les recherches indépendantes et n’appliquez le reranker qu’aux cas utiles. Suivez tokens, appels, p95 et coût par réponse acceptée.
Exemple concret
Un support produit route les requêtes avec code d’erreur vers hybride lexical-vectoriel et les comparaisons vers une décomposition en sous-questions. Un reranker reclasse vingt candidats. Les questions conversationnelles simples évitent le retrieval, réduisant le coût.
Les erreurs fréquentes
- ajouter toutes les techniques simultanément
- réécrire une requête contenant un identifiant exact
- reranker des centaines de documents
- router sans route de secours
- évaluer uniquement la génération
- oublier filtres d’autorisation
Checklist
- [ ] Baseline retrieval et génération
- [ ] Types de requêtes identifiés
- [ ] Expansion bornée
- [ ] Hybride comparé
- [ ] Reranker justifié par métriques
- [ ] Routing évalué
- [ ] Coût et p95 surveillés
FAQ
Quand ajouter un reranker ?
Lorsque les bons documents sont récupérés mais mal classés dans les premières positions.
La query expansion augmente-t-elle toujours le rappel ?
Non. Elle peut dériver ; conservez l’original et mesurez.
Faut-il router avec un LLM ?
Pas forcément. Des règles ou un petit classifieur sont souvent plus stables.
Comment choisir le nombre de candidats ?
Par courbe rappel-latence-coût sur votre jeu d’évaluation.
Pipeline explicite avec seuils
~~~python def answer(question, identity): route = classify_route(question) queries = expand_query(question, max_variants=3) candidates = deduplicate([ doc for query in queries for doc in retrieve(query, tenant_id=identity.tenant_id, k=20) ]) ranked = reranker.rank(question, candidates)[:6] if not ranked or ranked[0].score < 0.55: return {"answer": None, "reason": "sources_insuffisantes"} return generate(question, ranked) ~~~
Bornez le nombre de variantes et de candidats : sinon la query expansion augmente rapidement coût et latence. Le routeur doit disposer d’une voie de repli. Appliquez les filtres d’accès avant le reranking et tracez route, requêtes dérivées, documents retenus et scores. Évaluez chaque étape séparément pour savoir si le gain vient du retrieval ou du générateur.