3) Stratégies RAG qui comptent lors d'un Entretien ou d'un Audit
Leviers prioritaires à explorer en entretien/audit de kick-off : hybride lexical+vectoriel, reranking, context builder, query rewriting, routing, structured RAG, freshness, évaluation continue.
Hybrid Search Rerank Context Builder Query Rewrite Routing Structured RAG Freshness Éval continue
Hybride lexical + vectoriel (BM25 + ANN)
🎯 Pourquoi c’est clé en entretien
- Les mots rares/codes (réfs produit, IDs) sont mieux captés par BM25.
- Les paraphrases & synonymes → mieux via vecteur (ANN).
- L’hybride réduit les trous : robustesse ↑, surprises ↓.
Punchline : « On fusionne sémantique et exact-match pour ne rater ni le sens, ni les codes. »
🗺️ Script d’audit (questions à poser)
- Vos données contiennent-elles des références ou numéros critiques ?
- Exemples où la recherche actuelle rate des acronymes ?
- Souhaitez-vous filtrer par langue, produit, version ?
- Quelle latence cible p95 côté recherche ?
Heuristique de départ
{"hybrid":{"alpha":0.7,"k_vec":50,"k_bm25":50,"k_out":20},
"filters":["lang","product","version"]}✅ Signaux verts | ⛔ Rouges
- Jeux tests avec codes/acronymes.
- Normalisation scores (z-score/min-max) par requête.
- Filtres méta appliqués des deux côtés.
- Index vecteur seul pour docs très techniques.
- Aucun test sur mots rares.
- Fusion naïve sans calibration.
📏 KPI & plan 7 jours
- Hit@20 & nDCG@20 ↑ vs vecteur-seul (+10–20% typique).
- A/B 100 requêtes réelles (RH/IT/Produit).
- Review des 20 pires cas → ajuster α et filtres.
Re-ranking (cross-encoder) — bond de qualité
🧠 Idée simple à expliquer
On fait relire au modèle question×passage pour re-noter la pertinence. On ne garde que les 3–6 meilleurs → contexte plus propre, citations exactes.
Config de départ
{"rerank":{"model":"cross-encoder-base","k_in":20,"k_out":5,"timeout_ms":600,"batch":16}}🧪 Questions d’audit
- Latency p95 cible ? ≤ 600 ms rerank recommandé.
- Besoin de citations très précises ?
- Volume req/jour → budget coût rerank acceptable ?
✅ Quick wins
- Batch 8–32 + parallélisme.
- Failover : si timeout → garder top-k brut.
- Limiter passage_len (512–1024 tok).
📏 Évaluer vite
- nDCG@k ↑, “exact citation” ↑.
- Analyse avant/après sur 50 questions.
- Surcoût mesuré (€/1000 req) & trade-off validé.
Anti-patterns : reranker sans limiter k_in; absence de timeout; passer des passages duplicés.
Context Builder — faire mieux avec moins de tokens
🧱 Règles pratiques
- Dedup strict (même phrase/source).
- Merge par section (H2/H3) pour cohérence.
- Ordre logique : Intro → Étapes → Exceptions → Liens.
- 3–6 passages max, budget 700–1000 tokens.
Pseudo
ctx = compress(merge_by_section(dedup(passages)), max_tokens=900)🗺️ Entretien — à vérifier
- Faut-il toujours afficher les citations cliquables ? (oui)
- Faut-il résumer les morceaux avant assemblage ?
- Gérer multilingue : filtrer vs traduire ?
📦 Format sortie
{"context":[{"title":"SSO/Prerequis","url":"...#p3","text":"..."}],
"must_cite": true, "language":"fr","style":"concise"}✅ Signaux verts | ⛔ Rouges
- Citations exactes et cliquables.
- Compression mesurée (ROUGE/semantic).
- Pas de doublons.
- Envoyer 10–20 passages bruts au LLM.
- Ordre aléatoire des extraits.
- Pas de limite de tokens.
Punchline : « On nourrit le LLM avec un plateau trié, pas un buffet en vrac. »
Query rewriting & décomposition multi-hop
✍️ Rewrite — règles
- Expansion d’acronymes (AD → Active Directory).
- Injecter filtres implicites (langue, produit, version).
- Supprimer le bruit (“urgent”, “stp”…).
Politique (JSON)
{"rewrite":{"normalize_lang":true,
"expand_acronyms":true,
"inject_filters":["product","lang","version"]}}🔪 Décomposition multi-hop
- Découper en 2–3 sous-questions séquentielles.
- Chaînage (retrieve → réponse partielle → retrieve).
- Composer la réponse finale + sources fusionnées.
# exemple
subs = decompose("Activer SSO Azure AD sur WebApp 4.2")
# → ["Prerequis SSO WebApp 4.2", "Configurer SSO Azure AD", "Tester SSO"]🧪 Entretien — check
- Cas d’usage nécessitant multi-hop ? (procédures longues)
- Latence tolérée si décomposition ?
- Suivi des sous-requêtes (trace_id parent) ?
Anti-patterns : rewrite agressif qui change l’intention; décomposition sans limites de temps.
Routing — choisir la bonne collection
🎛️ Options
- Classifieur ML (RH / Produit / IT / Juridique).
- Règles par métadonnées (lang, conf, org, pays).
- Fallback multi-route (fusion top-k).
Contrat
{"routing":{"collections":["kb_product","kb_rh","kb_it"],
"policy":"ml+rules","fallback":"merge_topk"}}🧪 Questions d’audit
- Combien de collections actives et leurs périmètres ?
- Quelle confidentialité par collection ?
- Erreurs de routage actuelles ? (exemples concrets)
✅ / ⛔
- Logs de routage + confusion matrix.
- Fallback contrôlé.
- Tests multi-domaines.
- Routage “magique” sans explicabilité.
- Collections qui se recouvrent fortement.
- Pas de gouvernance.
Structured RAG — extraire d’abord les “facts”
🧱 Principe & bénéfices
- Extraire des tables/JSON → champs clés normalisés.
- Réponse LLM = rédaction à partir de facts vérifiables.
- Meilleure factualité & calculs reproductibles.
Schéma d’extraction
{"extract":{"schema":{"incident":{"id":"str","sev":"int","date":"date","owner":"str"}}}}🧪 Entretien — check
- Quels artefacts structurables ? (tableaux, KPIs, SLA)
- Besoin de calculs (moyennes, deltas) ?
- Qui valide le schéma (SME) ?
✅ / ⛔
- Schéma versionné + tests.
- Contrôles de type & ranges.
- Traçabilité des champs (provenance).
- Extraction “free-form” sans contraintes.
- Pas d’alignement SME.
- Pas d’export machine-readable.
Punchline : « On sépare l’extraction des facts de leur rédaction. »
Freshness — garder l’index à jour
🕒 Stratégie
- Méta
last_updatedau niveau doc & chunk. - Filtres par date (ex. from_date=J-90).
- Re-index incrémental (watcher/stream).
- Version d’index → invalidation de cache.
Exemple de requête
{"filters":{"lang":"fr","product":"WebApp","from_date":"2025-01-01"},"k":16}🧪 Entretien — check
- Sources avec fréquence de mise à jour élevée ?
- SLAs de fraicheur (ex. < 24h) ?
- Fenêtres de ré-indexation & budget compute ?
✅ / ⛔
- Horodatage, checksum, auteur.
- Règles d’expiration TTL par collection.
- Alerting si backlog ingestion.
- Index “figé”.
- Pas de filtre temporel.
- Cache réponse non versionné.
Punchline : « Un RAG périme comme un site web : on monitore la fraîcheur. »
Évaluation continue — mesures & boucles d’amélioration
📏 Jeux & métriques
- Golden set (question → doc(s) cibles).
- Métriques : Hit@k, nDCG@k, Faithfulness, Context Precision, Answer Relevancy, Citation rate.
- Feedback humain (👍/👎 + commentaire).
Spec d’un job d’éval
{"eval":{"schedule":"daily","dataset":"golden_v3.jsonl",
"metrics":["hit@10","ndcg@10","faithfulness","citation_rate"],
"alerting":{"slack":"#rag-alerts",
"thresholds":{"hit@10":0.8,"lat_p95_ms":3500}}}}🛠️ Audit — questions clés
- Qui maintient le golden set ? (propriétaire, fréquence)
- Où sont stockés les résultats (séries temporelles) ?
- Quelles actions automatiques si régression ?
Anti-patterns : évaluation ad hoc manuelle; zéro traçabilité; seuils non définis.
🔁 Boucles d’amélioration
- Tuning : α hybride, k, rerank, chunking, prompts.
- Ajout de sources manquantes (lacunes détectées).
- Retrain reranker si dérive des domaines.
Plan 30-60-90 : 30j stabiliser KPIs; 60j enrichir sources et guardrails; 90j automatiser éval & alerting.
Punchline : « Pas de prod sans métriques automatiques et boucle d’amélioration. »
