RAG en production : guide pour les équipes techniques
Chunking sémantique, embeddings, bases vectorielles, retrieval hybride, reranking et évaluation RAGAS. Comment passer d'un RAG qui marche en démo à un système qui tient en production.
Le chunking : la décision la plus critique du RAG
La façon dont vous découpez vos documents détermine 40 à 60% de la qualité finale du RAG. C'est souvent la première cause d'un RAG qui échoue en production.
Chunking fixe
BasiqueDécoupage à intervalles réguliers (500 tokens). Simple à implémenter mais ignore la structure sémantique des documents.
Résultats corrects sur des textes uniformes, médiocres sur des docs structurés
Chunking par sections
RecommandéDécoupage aux titres H1/H2/H3. Préserve la cohérence thématique. Adapté aux docs techniques et wikis.
Bons résultats sur des docs bien structurés
Chunking sémantique
RecommandéUn LLM ou un modèle d'embedding identifie les frontières de sens naturelles. Le plus performant, le plus coûteux.
Meilleurs résultats, +30 à 50% de précision vs chunking fixe
Chunking avec overlap
RecommandéChevauchement entre les chunks (10-20% du chunk). Préserve le contexte aux frontières. Combine avec les autres stratégies.
Indispensable pour les documents narratifs longs
Choisir sa base vectorielle
Le meilleur choix dépend de votre stack existante, de votre volume et de votre capacité ops — pas des benchmarks abstraits.
pgvector
Extension PostgreSQLQuand l'utiliser : Déjà sur Postgres, volume < 1M vecteurs
Avantages
Zéro infra supplémentaire, SQL natif, ACID
Limites
Moins performant à très grande échelle
Pinecone
Managed cloudQuand l'utiliser : Besoin de scalabilité sans ops, budget disponible
Avantages
Entièrement managé, performances excellentes
Limites
Coût, lock-in vendor
Qdrant
Open source (Rust)Quand l'utiliser : Self-hosted, performances maximales
Avantages
Très rapide, filtrage avancé, open source
Limites
Infra à gérer
Weaviate
Open sourceQuand l'utiliser : Hybrid search natif important
Avantages
Hybrid search BM25 + vectoriel intégré
Limites
Infra à gérer, courbe d'apprentissage
Retrieval : au-delà de la recherche vectorielle simple
La recherche vectorielle seule n'est pas suffisante pour la production. Le hybrid search + reranking est la baseline minimale.
Recherche vectorielle (dense retrieval)
La requête est transformée en vecteur et comparée aux vecteurs de la base par similarité cosinus. Capture le sens sémantique mais peut rater des mots-clés exacts.
BM25 (sparse retrieval)
Algorithme de recherche par mots-clés. Excellent sur les termes précis (noms de produits, codes, acronymes) mais insensible à la sémantique.
Hybrid search
Combine dense + sparse avec une pondération configurable (RRF ou score fusion). C'est la baseline recommandée en production — systématiquement meilleure que l'un ou l'autre seul.
Reranking
Un modèle de reranking (Cohere Rerank, cross-encoder) reclasse les N candidats renvoyés par le retriever. Améliore la précision de 15 à 30% avec un surcoût minimal.
Évaluer son RAG avec RAGAS
Un RAG sans évaluation est un RAG qui se dégrade silencieusement. Ces 4 métriques couvrent l'essentiel.
Faithfulness
RAGAS
La réponse est-elle fidèle aux documents sources ? Mesure les hallucinations.
> 0.85
Answer Relevancy
RAGAS
La réponse répond-elle vraiment à la question posée ?
> 0.80
Context Recall
RAGAS / LangSmith
Le retriever retrouve-t-il les bons documents ?
> 0.75
Latence p95
Datadog / Langfuse
95% des requêtes répondent en moins de X secondes.
< 3s
Ne pas confondre évaluation automatique (RAGAS) et évaluation humaine. Les deux sont nécessaires — RAGAS détecte les dérives rapides, l'humain identifie les cas limites subtils.
Questions fréquentes
Quelle est la différence entre RAG et fine-tuning ?
Le RAG connecte le LLM à des données externes au moment de la requête — vos données sont toujours à jour. Le fine-tuning modifie les poids du modèle à l'entraînement — les données sont figées dans le modèle. Le RAG est préférable dans 90% des cas : plus rapide, moins cher, données toujours fraîches. Le fine-tuning sert à adapter le comportement du modèle (ton, format, style de raisonnement), pas pour injecter des connaissances.
Combien de temps prend le déploiement d'un RAG en production ?
Un RAG simple (une source, un cas d'usage) : 3 à 6 semaines de la conception au déploiement. Un RAG multi-sources avec évaluation, reranking et monitoring : 8 à 16 semaines. Les projets qui dérapent sous-estiment toujours la phase d'évaluation et les itérations sur le chunking.
Quelle base vectorielle choisir pour commencer ?
pgvector si vous êtes déjà sur PostgreSQL et que le volume prévisible est inférieur à 1 million de vecteurs. C'est la solution la plus simple : zéro infrastructure supplémentaire. Migrez vers Qdrant ou Pinecone si vous atteignez les limites de performance. Ne sur-ingéniérez pas dès le départ.
Comment évaluer la qualité d'un système RAG ?
Le framework RAGAS est le standard. Il mesure automatiquement la faithfulness (pas d'hallucination), l'answer relevancy (la réponse répond à la question) et le context recall (les bons documents sont retrouvés). Complétez avec du feedback humain sur un échantillon de requêtes réelles toutes les deux semaines.
Un RAG peut-il halluciner malgré tout ?
Oui, dans trois cas : (1) le retriever ne retrouve pas les bons documents (la réponse est hors sujet), (2) le LLM extrapole au-delà de ce que disent les documents, (3) les documents source contiennent des informations contradictoires. Les guardrails (citer les sources, refuser de répondre si le contexte est insuffisant) réduisent ces cas mais ne les éliminent pas à 100%.
Vous déployez un RAG en production ?
Fyher conçoit des systèmes RAG robustes avec chunking sémantique, hybrid search, reranking et évaluation RAGAS continue. Pour les scale-ups SaaS B2B qui veulent des résultats réels.
Discutons de votre projet RAGOu par email : contact@fyher.com