Le RAG (Retrieval-Augmented Generation) est devenu le standard pour connecter vos données métier à un LLM. Voici un guide concret pour mettre en place une architecture RAG fiable en production, avec LangChain et pgvector.
Pourquoi RAG plutôt que fine-tuning ?
Le fine-tuning d'un LLM sur vos données coûte cher, prend du temps, et devient obsolète dès que vos données évoluent. Le RAG, à l'inverse, est dynamique : votre base de connaissances est mise à jour en continu, et le modèle interroge systématiquement les données les plus récentes à chaque requête.
C'est pourquoi pour 90% des cas d'usage entreprise, documentation interne, support client, analyse de contrats, le RAG est la bonne réponse.
Architecture cible
Notre stack de référence pour un RAG production-ready :
Ingestion & chunking
Chargement des documents (PDF, Word, web, APIs), découpage en chunks cohérents avec chevauchement, nettoyage et normalisation du texte.
Embedding & stockage vectoriel
Vectorisation avec text-embedding-3-large (OpenAI) ou un modèle local. Stockage dans Postgres avec l'extension pgvector pour des requêtes vectorielles natives.
Retrieval hybride
Combinaison de la recherche sémantique (cosine similarity) et de la recherche BM25 (full-text) pour maximiser la précision du contexte récupéré.
Génération et évaluation
Construction du prompt avec le contexte récupéré, appel au LLM, et évaluation automatique des réponses avec RAGAS ou LangSmith.
Le code qui compte
Voici le cœur de notre implémentation. On commence par la configuration de la connexion pgvector :
from langchain_postgres import PGVector
from langchain_openai import OpenAIEmbeddings
embeddings = OpenAIEmbeddings(model="text-embedding-3-large")
vectorstore = PGVector(
embeddings=embeddings,
collection_name="knowledge_base",
connection="postgresql+psycopg://user:pass@localhost/ragdb",
use_jsonb=True,
)
Ensuite, la chaîne RAG avec retrieval hybride :
from langchain.chains import create_retrieval_chain
from langchain.chains.combine_documents import create_stuff_documents_chain
from langchain_core.prompts import ChatPromptTemplate
retriever = vectorstore.as_retriever(
search_type="mmr", # Maximal Marginal Relevance
search_kwargs={"k": 6, "fetch_k": 20}
)
prompt = ChatPromptTemplate.from_template("""
Réponds à la question en te basant uniquement sur le contexte fourni.
Si tu ne trouves pas la réponse, dis-le clairement.
Contexte: {context}
Question: {input}
""")
chain = create_retrieval_chain(
retriever,
create_stuff_documents_chain(llm, prompt)
)
Les erreurs classiques à éviter
Des chunks trop grands ou trop petits
Un chunk de 2000 tokens noie l'information pertinente dans du bruit. Un chunk de 50 tokens perd le contexte nécessaire à la compréhension. Notre sweet spot : 400-600 tokens avec un chevauchement de 80 tokens.
Ignorer la phase d'évaluation
Un pipeline RAG sans métriques d'évaluation, c'est voler à l'aveugle. Nous utilisons systématiquement RAGAS pour mesurer la fidélité des réponses, la pertinence du retrieval et l'absence d'hallucinations.
Pro tip : Activez le logging de chaque retrieval dès le début. C'est votre meilleur outil de debugging, vous verrez immédiatement si le problème vient du retrieval ou de la génération.
Mise en production : checklist
Avant de passer en prod, vérifiez ces points : indexation incrémentale (pas de ré-indexation complète à chaque mise à jour), gestion des embeddings en batch pour réduire les coûts API, cache des embeddings fréquents, monitoring de la latence P95, et tests de régression automatisés sur un golden dataset.
Avec toute mon attention,
Article très complet et ancré dans la réalité du terrain. On retrouve exactement les mêmes patterns chez nos clients. La partie sur les coûts d'inférence est particulièrement précieuse, c'est un sujet que peu d'articles abordent franchement.
Merci Thomas ! Effectivement, l'optimisation des coûts est souvent négligée en phase de prototypage mais devient critique en production. N'hésitez pas à nous contacter si vous voulez approfondir ce point.
Je partage cet article à toute mon équipe. La distinction entre « démo impressionnante » et « production robuste » est exactement le débat qu'on a en ce moment en interne. Le conseil sur les human checkpoints est actionnable immédiatement.
Très bon article. Je nuancerais sur le délai de 18 jours pour déployer un premier agent, dans mon expérience c'est plus proche de 4 à 6 semaines quand on intègre vraiment les contraintes de sécurité et de RGPD.
Remarque tout à fait juste Marc. Les 18 jours correspondent à un premier agent en environnement de test ou pour un cas d'usage bien délimité. En production avec toutes les contraintes enterprise, votre estimation est réaliste.