L’architecture RAG utile : préciser l’équation avant d’empiler les briques
Un RAG met un moteur de recherche sémantique devant un modèle génératif pour ancrer les réponses sur des sources factuelles. En production, l’équation ne change jamais : plus vous augmentez le rappel (retrieval large, variantes de requêtes), plus vous risquez la latence et la facture ; plus vous serrez le précision‑rappel (reranking agressif), plus vous payez de calcul — avant même la génération. D’où un pipeline pensé comme une chaîne de décisions mesurables : comment on découpe, ce qu’on retient, ce qu’on rejette, quand on ré‑ordonne, quand on appelle le LLM, et quand… on n’appelle rien du tout (cache).
Côté indexation, un chunking context‑aware (sémantique/récursif) autour de 400–600 tokens évite des blocs denses qui diluent l’information et améliore le rappel contextualisé. Sur les embeddings, les familles BGE et E5 (versions 1.5 et multi‑langues, 768–1024 dimensions) offrent un excellent compromis performance/coût, avec la possibilité d’ajouter un reranker cross‑encoder (Cohere Rerank, BGE‑reranker) pour reclasser un sous‑ensemble court et stabiliser la pertinence. L’essentiel se gagne aussi dans les métadonnées (source, date, version, ACL) : elles autorisent un filtrage par fraîcheur et par droits avant la moindre similarité.
huggingface.co +2 • arXiv +2
Sur le stockage vectoriel, le débat n’est pas « le meilleur produit » mais vos contraintes d’exploitation : besoins d’hybride lexical+vectoriel (BM25 + dense), de latence managée, d’édition en ligne, de budget. Weaviate pousse le hybrid search (BM25+vector), Pinecone est apprécié pour l’offre managée et la latence, et des benchmarks indépendants comparent ces approches aux solutions pgvector/Zilliz selon l’échelle et le coût. Le choix doit s’adosser à des tests maison, pas à une fiche marketing.
docs.weaviate.io +2 • GitHub +2
Un pipeline de référence (et pourquoi il tient)
Dans la requête, on normalise (casse, espaces, chiffres) et on ré‑écrit quand nécessaire. La technique HyDE — générer un document hypothétique à partir de la question, l’encoder puis chercher avec cet embedding — fait des merveilles quand la requête est pauvre ou ambiguë, en « projetant » la question vers l’espace sémantique du corpus. On exécute ensuite une première passe large (k = 20–50) pour garantir le rappel, puis on ré‑ordonne les meilleurs candidats via un cross‑encoder. En fin de chaîne, on fusionne éventuellement plusieurs listes (dense, lexical, hybride) avec un Reciprocal Rank Fusion (RRF), rustique mais très robuste pour combiner des signaux hétérogènes.
research.google +3 • Haystack +3 • docs.opensearch.org +3
À chaque étape, la latence compte : embedding batché, reranking sur un sous‑ensemble (pas plus de 50 passages), streaming côté LLM pour afficher la réponse sans attendre la fin, et co‑localisation des composants (retrieval et génération dans la même région/zone) pour éviter des allers‑retours réseau. Dans les architectures distribuées, la distance régionale pèse lourd : quelques dizaines de millisecondes par saut finissent en secondes bout‑en‑bout quand on empile reranking, policy et appels d’outils.
Net Solutions
Évaluer sans complaisance : goldens et garde‑fous
Le mythe du score absolu n’aide personne. Ce qui fonctionne, ce sont des golden sets par domaine (100–300 questions bien posées, avec contexte attendu) et des métriques standardisées qui isolent les effets : faithfulness, answer relevancy, context precision/recall. La librairie RAGAS a popularisé ce cadrage et propose une implémentation reproductible — utile pour comparer avant/après : nouveau chunking, nouveau reranker, nouvelle politique de filtrage. En pré‑prod, on fait du gating : pas de mise en ligne si la factualité descend sous un seuil, si la latence p95 explose, ou si le coût par requête franchit la ligne rouge. En prod, on itère par A/B : on mesure, on garde ce qui gagne, on jette le reste.
arXiv +1
Maîtriser coûts et latence : l’optimisation qui compte
- Ne pas appeler le LLM quand on n’en a pas besoin. Un cache sémantique (embeddings + réponses et récupération par similarité) évite de régénérer des réponses à des questions proches. Bien réglé, ce mécanisme baisse fortement les appels au LLM et améliore la latence perçue, avec des hit rates significatifs sur les cas répétitifs.Microsoft Learn +1
- Réduire ce qu’on envoie au modèle. Le coût suit les tokens : un chunking pertinent, des prompts compacts et des schémas de sortie stricts (JSON Schema / function calling) élaguent la conversation. Quand la confiance retrieval est haute, on réduit le contexte ; quand elle est basse, on paie le reranking plutôt qu’un long contexte verbeux.
- Servir plus intelligemment. Côté LLM, le continuous batching (par exemple via vLLM) multiplie le débit tout en réduisant la p50, en gardant les GPU pleins. En clair : plus de requêtes traitées par carte et par heure, moins de trous d’air, un coût amorti.docs.vllm.ai +1
- Placer les briques là où la physique le permet. Co‑localiser retrieval, reranking et génération dans la même région/zone évite des centaines de millisecondes et des frais d’egress sous‑estimés. À l’échelle, ce « détail » devient une ligne de budget.Net Solutions
Patterns qui font la différence (quand les métriques le disent)
HyDE, le coup de pouce aux requêtes pauvres
Sur des questions courtes, bruitées ou sous‑spécifiées, HyDE rapproche la requête du langage des documents ; sur corpus techniques, les gains de rappel sont nets. À activer sélectivement.
Haystack
Reranking cross‑encoder, le scalpel
Les embeddings ramènent des candidats ; un cross‑encoder (Cohere Rerank ou BGE‑reranker) re‑note finement les meilleurs. À employer sur un k serré pour contenir la latence, souvent conditionné par un score de confiance retrieval.
docs.cohere.com
RRF, la méthode qui gagne souvent « à la moyenne »
Fusionner dense, lexical et hybride par RRF améliore régulièrement le top‑n sans réglages sophistiqués. Idéal quand les corpus sont hétérogènes ou quand les signaux sont complémentaires.
cormack.uwaterloo.ca
Observabilité : ce qu’on trace existe
Un RAG de production trace chaque requête comme un parcours. Dans vos traces OpenTelemetry : un trace_id, des spans par étape (ré‑écriture, retrieval, reranking, génération), et des attributs qui rendent l’analyse actionnable : embedding_model, k_initial, k_rerank, reranker_name, tokens_prompt, tokens_completion, latence par étape, coût estimé, source_ids retenues, score de confiance. Côté logs, on veut la rejouabilité (prompts et contextes exacts), et côté métriques, un quatuor simple : factualité moyenne, p95 latence, pourcentage de cache hits, coût moyen par requête.
Anti‑patterns fréquents (et comment les éviter)
- Tout mettre dans le contexte. Un long contexte n’est pas un gage de qualité ; c’est souvent un gage de coût et de contre‑sens. Préférer peu de bons passages bien classés et audités, ou… ne pas générer si le retrieval est faible.
- Changer la base vectorielle au lieu de changer la question. Avant de migrer un cluster, tester HyDE, la reformulation, l’hybride lexical+vectoriel et RRF : meilleurs leviers effort/gain.
- Ré‑entraîner partout. Fine‑tuner embeddings et reranker n’a d’intérêt qu’après avoir épuisé les réglages (chunking, filtrage, fusion, reformulation).
Feuille de route réaliste (90 jours)
- Semaine 1–3. Fixer les golden sets métier, brancher RAGAS, instrumenter le tracing (attributs coûts/tokens/latences), poser les SLO : factuel ≥ X, p95 ≤ Y ms, coût ≤ Z € par requête.arXiv
- Semaine 4–6. Déployer HyDE sur les requêtes pauvres, tester hybride et RRF, introduire un reranker sur top‑50, activer le cache sémantique.Microsoft Learn +3 • Haystack +3 • docs.weaviate.io +3
- Semaine 7–12. Optimiser latence/coût : batch embeddings, streaming, continuous batching (vLLM), co‑localisation des composants, A/B permanent.docs.vllm.ai
Conclusion
- Retrouver bien : requête soignée, hybride quand il faut, reranking parcimonieux.
- Répondre vite : embeddings batchés, vLLM pour saturer les GPU, composants co‑localisés.
- Coûter juste : cache sémantique, contexte court, mesure en continu.
Le reste — choix d’un vecteur DB ou d’un embedding « à la mode » — suit si vous mesurez ce qui compte et si vous refusez de mettre en production ce qui n’atteint pas vos seuils. C’est ce professionnalisme‑là, bien plus que n’importe quel modèle, qui transforme un POC séduisant en capacité d’entreprise.
Références clés
HyDE (génération de document hypothétique) ; RAGAS (faithfulness, answer relevancy, context precision/recall) ; familles BGE/E5 pour les embeddings et Cohere Rerank / BGE‑reranker côté cross‑encoder ; hybrid search (BM25+vector) et RRF ; continuous batching (vLLM) et semantic cache ; vigilance sur egress et co‑localisation des composants.