Table des Matières
1 Introduction : Le Chatbot d'Entreprise Nouvelle Génération
Les chatbots d'entreprise ont longtemps été synonymes de frustration : réponses génériques, incapacité à comprendre le contexte métier, et hallucinations fréquentes lorsqu'ils reposent uniquement sur des LLM (Large Language Models) pré-entraînés. En 2026, l'architecture RAG (Retrieval-Augmented Generation) combinée au framework LangChain transforme radicalement cette réalité en permettant de construire des assistants conversationnels qui s'appuient sur vos propres données d'entreprise.
Les limites des chatbots classiques
Les chatbots traditionnels souffrent de limitations structurelles qui les rendent inadaptés aux besoins complexes de l'entreprise :
- ▹Chatbots à règles (rule-based) — Limités à des scénarios prédéfinis, incapables de gérer les questions hors script. La maintenance devient exponentiellement coûteuse avec l'augmentation des cas d'usage.
- ▹LLM seuls (GPT, Claude) — Hallucinations sur les données internes, pas de connaissance des processus métier, données d'entraînement figées à une date de coupure. Un LLM ne connaît pas votre convention collective ni votre catalogue produit.
- ▹Fine-tuning complet — Coût prohibitif (dizaines de milliers d'euros), nécessité de re-entraîner à chaque mise à jour documentaire, risque de catastrophic forgetting. Inadapté pour des données qui évoluent quotidiennement.
La promesse du RAG
Le RAG (Retrieval-Augmented Generation) résout ces problèmes en séparant la connaissance du raisonnement. Au lieu de stocker toute l'information dans les poids du modèle, le RAG va chercher les informations pertinentes dans votre base documentaire au moment de la requête, puis les injecte comme contexte pour le LLM. C'est exactement ce que fait un expert humain : il consulte la documentation avant de répondre.
Cas d'usage concrets en entreprise :
- ▹Chatbot RH — Répond aux questions sur la convention collective, les congés, la mutuelle, les procédures internes. Source : documents RH, intranet, accords d'entreprise.
- ▹Assistant documentation technique — Interroge la base de connaissances technique, les manuels produit, les wikis Confluence. Idéal pour l'onboarding développeurs.
- ▹Support client niveau 1 — Exploite la FAQ, les tickets résolus, la documentation produit pour fournir des réponses précises et sourcées.
Dans ce guide, nous allons construire pas à pas un chatbot d'entreprise complet avec LangChain 0.3+, depuis l'ingestion de vos documents jusqu'au déploiement en production. Chaque étape sera accompagnée de code Python fonctionnel et de recommandations basées sur des retours d'expérience en production.
2 Architecture RAG pour Chatbot
L'architecture RAG pour un chatbot d'entreprise se décompose en deux pipelines fondamentaux : le pipeline d'ingestion (hors ligne) et le pipeline de requête (en temps réel). Comprendre cette séparation est essentiel pour concevoir un système performant et maintenable.
Pipeline d'ingestion (Indexing)
Le pipeline d'ingestion transforme vos documents bruts en représentations vectorielles interrogeables. Il s'exécute en amont, de manière asynchrone, et se compose des étapes suivantes :
- ▹Loading — Chargement des documents depuis leurs sources (PDF, DOCX, Confluence, Notion, bases de données, APIs).
- ▹Splitting (Chunking) — Découpage des documents en fragments de taille optimale, avec chevauchement (overlap) pour préserver le contexte.
- ▹Embedding — Transformation de chaque chunk en vecteur dense via un modèle d'embeddings (OpenAI, Cohere, BGE).
- ▹Storing — Stockage des vecteurs et métadonnées dans une base vectorielle (Milvus, ChromaDB, Qdrant, Weaviate).
Pipeline de requête (Retrieval + Generation)
Lorsqu'un utilisateur pose une question, le pipeline de requête s'active en temps réel :
- 1.Query Embedding — La question est transformée en vecteur avec le même modèle d'embeddings utilisé à l'ingestion.
- 2.Retrieval — Recherche par similarité vectorielle (cosine similarity, dot product) dans la base pour trouver les k chunks les plus pertinents.
- 3.Augmentation — Les chunks récupérés sont injectés dans le prompt comme contexte, avec la question de l'utilisateur.
- 4.Generation — Le LLM génère une réponse cohérente et sourcée en se basant uniquement sur le contexte fourni.
Architecture RAG complète : pipeline d'ingestion (offline) et pipeline de requête (realtime) avec mémoire conversationnelle
Point clé : Le même modèle d'embeddings doit être utilisé à l'ingestion et à la requête. Un décalage (mismatch) entre les modèles dégrade drastiquement la qualité du retrieval. Documentez toujours le modèle utilisé dans vos métadonnées de collection.
3 Ingestion et Préparation des Documents
La qualité de votre chatbot RAG dépend directement de la qualité de l'ingestion documentaire. Cette étape, souvent sous-estimée, représente 80% de l'effort de développement d'un chatbot d'entreprise robuste. LangChain 0.3+ fournit un écosystème complet de loaders et de text splitters pour couvrir la plupart des scénarios.
Document Loaders
LangChain propose plus de 160 loaders pour charger des documents depuis pratiquement n'importe quelle source. Voici les plus utilisés en contexte entreprise :
- ▹PyPDFLoader / PyMuPDFLoader — Chargement de fichiers PDF avec extraction de texte et métadonnées (numéro de page, auteur). PyMuPDF est plus rapide et gère mieux les tableaux.
- ▹Docx2txtLoader / UnstructuredWordDocumentLoader — Documents Word (.docx). Le loader Unstructured préserve mieux la structure (titres, listes).
- ▹ConfluenceLoader — Chargement direct depuis Atlassian Confluence via API. Supporte les espaces, les pages et les sous-pages.
- ▹NotionDBLoader — Intégration native avec Notion via l'API officielle. Idéal pour les bases de connaissances d'équipe.
- ▹CSVLoader / DataFrameLoader — Données structurées depuis CSV ou Pandas DataFrame avec mapping des colonnes en métadonnées.
Voici l'implémentation d'un pipeline d'ingestion multi-sources avec LangChain :
from langchain_community.document_loaders import (
PyMuPDFLoader,
Docx2txtLoader,
ConfluenceLoader,
NotionDBLoader,
DirectoryLoader
)
from langchain.schema import Document
from pathlib import Path
import logging
logger = logging.getLogger(__name__)
class EnterpriseDocumentLoader:
"""Pipeline d'ingestion multi-sources pour chatbot entreprise."""
def __init__(self, config: dict):
self.config = config
self.documents: list[Document] = []
def load_pdfs(self, directory: str) -> list[Document]:
"""Charge tous les PDF d'un répertoire."""
loader = DirectoryLoader(
directory,
glob="**/*.pdf",
loader_cls=PyMuPDFLoader,
show_progress=True,
use_multithreading=True
)
docs = loader.load()
logger.info(f"Chargé {len(docs)} pages PDF depuis {directory}")
return self._enrich_metadata(docs, source_type="pdf")
def load_confluence(self, space_key: str) -> list[Document]:
"""Charge les pages Confluence d'un espace."""
loader = ConfluenceLoader(
url=self.config["confluence_url"],
username=self.config["confluence_user"],
api_key=self.config["confluence_token"],
space_key=space_key,
include_attachments=True,
limit=100
)
docs = loader.load()
logger.info(f"Chargé {len(docs)} pages Confluence ({space_key})")
return self._enrich_metadata(docs, source_type="confluence")
def _enrich_metadata(self, docs, source_type: str):
"""Enrichit les métadonnées pour le filtrage et la traçabilité."""
for doc in docs:
doc.metadata["source_type"] = source_type
doc.metadata["ingested_at"] = datetime.now().isoformat()
doc.metadata["company"] = self.config.get("company_name", "default")
return docs
Stratégies de Chunking
Le chunking est l'art de découper vos documents en fragments optimaux pour le retrieval. Un chunk trop petit perd le contexte, un chunk trop grand noie l'information pertinente dans du bruit. LangChain propose plusieurs stratégies :
- ▹RecursiveCharacterTextSplitter — Le plus polyvalent. Découpe récursivement en utilisant une hiérarchie de séparateurs (\n\n, \n, espace, caractère). Recommandé comme point de départ.
- ▹SemanticChunker — Utilise les embeddings pour détecter les changements de sujet et découper aux frontières sémantiques naturelles. Plus coûteux mais plus précis.
- ▹MarkdownHeaderTextSplitter — Découpe selon la hiérarchie des titres Markdown. Parfait pour la documentation technique structurée.
- ▹HTMLHeaderTextSplitter — Similaire mais pour le HTML (pages web, exports Confluence). Préserve la structure des sections.
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai import OpenAIEmbeddings
# Stratégie 1 : RecursiveCharacter (recommandé pour commencer)
recursive_splitter = RecursiveCharacterTextSplitter(
chunk_size=1000, # Taille cible en caractères
chunk_overlap=200, # Chevauchement pour le contexte
length_function=len,
separators=["\n\n", "\n", ". ", " ", ""],
is_separator_regex=False
)
chunks = recursive_splitter.split_documents(documents)
# Stratégie 2 : SemanticChunker (pour du contenu varié)
semantic_splitter = SemanticChunker(
embeddings=OpenAIEmbeddings(model="text-embedding-3-small"),
breakpoint_threshold_type="percentile",
breakpoint_threshold_amount=95 # Seuil de similarité pour couper
)
semantic_chunks = semantic_splitter.split_documents(documents)
print(f"Recursive: {len(chunks)} chunks | Semantic: {len(semantic_chunks)} chunks")
Règle empirique pour le chunk_size : Commencez avec 1000 caractères et 200 d'overlap. Pour des documents très structurés (manuels techniques), montez à 1500. Pour du Q&A court (FAQ), descendez à 500. Toujours mesurer la qualité avec un jeu de test avant de changer.
4 Embeddings et Vector Stores
Les embeddings transforment le texte en vecteurs numériques denses dans un espace mathématique où la proximité reflète la similarité sémantique. Le choix du modèle d'embeddings et de la base vectorielle a un impact direct sur la pertinence des réponses de votre chatbot.
Modèles d'Embeddings
En 2026, plusieurs modèles d'embeddings se distinguent pour les applications d'entreprise :
- ▹OpenAI text-embedding-3-large — 3072 dimensions, excellent rapport qualité/prix. Supporte le dimension shortening pour réduire à 256 ou 1024 dimensions sans perte significative. ~$0.13/million de tokens.
- ▹Cohere embed-v3 — 1024 dimensions, spécialement optimisé pour le retrieval avec distinction query/document. Excellent pour le multilingue (100+ langues). ~$0.10/million de tokens.
- ▹BGE-M3 (BAAI) — Open source, 1024 dimensions, supporte dense + sparse + multi-vector. Idéal pour l'auto-hébergement et les contraintes de confidentialité.
- ▹Voyage AI voyage-large-2 — 1536 dimensions, performances état de l'art sur le MTEB benchmark. Excellent pour les domaines spécialisés (juridique, médical).
Bases Vectorielles
Le choix de la base vectorielle dépend de vos contraintes de volume, performance, et infrastructure :
- ▹ChromaDB — Léger, embarqué, parfait pour le prototypage et les petits volumes (<100K documents). Zéro configuration. S'intègre comme une bibliothèque Python.
- ▹Qdrant — Rust-based, très performant, supporte le filtrage avancé sur métadonnées. Excellent pour les déploiements production à moyenne échelle (1M-100M vecteurs).
- ▹Milvus / Zilliz — Conçu pour le passage à l'échelle massive (milliards de vecteurs). Architecture distribuée, multi-réplica, GPU-accelerated. Zilliz est la version managée cloud.
- ▹Weaviate — Supporte nativement les modules de vectorisation, le BM25 hybrid search, et le GraphQL. Bon choix si vous voulez tout-en-un.
Flow d'ingestion documentaire : des sources multiples vers le vector store avec preprocessing et enrichissement de métadonnées
Voici l'intégration complète embeddings + vector store avec LangChain :
from langchain_openai import OpenAIEmbeddings
from langchain_community.vectorstores import Chroma, Qdrant, Milvus
from langchain.schema import Document
# Initialisation du modèle d'embeddings
embeddings = OpenAIEmbeddings(
model="text-embedding-3-large",
dimensions=1024 # Dimension shortening pour économiser
)
# Option 1 : ChromaDB (développement / prototypage)
vectorstore = Chroma.from_documents(
documents=chunks,
embedding=embeddings,
persist_directory="./chroma_db",
collection_name="chatbot_rh"
)
# Option 2 : Qdrant (production)
from qdrant_client import QdrantClient
vectorstore = Qdrant.from_documents(
documents=chunks,
embedding=embeddings,
url="http://localhost:6333",
collection_name="chatbot_rh",
force_recreate=False
)
# Retriever avec paramètres optimisés
retriever = vectorstore.as_retriever(
search_type="similarity", # ou "mmr" pour diversifier
search_kwargs={
"k": 5, # Nombre de chunks à récupérer
"score_threshold": 0.7 # Seuil de pertinence minimum
}
)
5 Construction avec LangChain
LangChain 0.3+ introduit le LCEL (LangChain Expression Language) qui remplace l'ancienne API des Chains. Le LCEL offre une syntaxe déclarative avec le pipe operator (|) pour composer des pipelines RAG de manière élégante et maintenable.
Prompt Template RAG
Le prompt template est le coeur de votre chatbot RAG. Il doit instruire le LLM à répondre uniquement à partir du contexte fourni, en citant ses sources, et en avouant son ignorance quand l'information n'est pas disponible :
from langchain_core.prompts import ChatPromptTemplate, MessagesPlaceholder
RAG_PROMPT = ChatPromptTemplate.from_messages([
("system", """Tu es un assistant d'entreprise spécialisé et précis.
Tu réponds UNIQUEMENT à partir du contexte fourni ci-dessous.
Si l'information n'est pas dans le contexte, dis-le clairement.
Cite toujours la source de tes informations entre crochets [source].
Réponds en français de manière professionnelle et concise.
Contexte:
{context}
Règles:
- Ne fabrique JAMAIS d'information
- Si plusieurs sources se contredisent, mentionne-le
- Propose de contacter le service concerné si la question dépasse le contexte"""),
MessagesPlaceholder(variable_name="chat_history"),
("human", "{question}")
])
Chaîne RAG Complète avec LCEL
Voici l'implémentation complète d'un chatbot RAG conversationnel avec mémoire, utilisant le LCEL de LangChain 0.3+ :
from langchain_openai import ChatOpenAI
from langchain_core.runnables import RunnablePassthrough, RunnableParallel
from langchain_core.output_parsers import StrOutputParser
from langchain_community.chat_message_histories import ChatMessageHistory
from langchain_core.runnables.history import RunnableWithMessageHistory
# Initialisation du LLM
llm = ChatOpenAI(
model="gpt-4o",
temperature=0.1, # Bas pour des réponses factuelles
max_tokens=1500,
streaming=True # Pour la réponse en streaming
)
# Fonction de formatage du contexte
def format_docs(docs):
formatted = []
for i, doc in enumerate(docs, 1):
source = doc.metadata.get('source', 'Inconnu')
page = doc.metadata.get('page', '')
ref = f"{source}" + (f" p.{page}" if page else "")
formatted.append(f"[Source {i}: {ref}]\n{doc.page_content}")
return "\n\n---\n\n".join(formatted)
# Chaîne RAG avec LCEL
rag_chain = (
RunnableParallel(
context=retriever | format_docs,
question=RunnablePassthrough(),
chat_history=lambda x: x.get("chat_history", [])
)
| RAG_PROMPT
| llm
| StrOutputParser()
)
# Ajout de la mémoire conversationnelle
message_histories = {}
def get_session_history(session_id: str):
if session_id not in message_histories:
message_histories[session_id] = ChatMessageHistory()
return message_histories[session_id]
chatbot = RunnableWithMessageHistory(
rag_chain,
get_session_history,
input_messages_key="question",
history_messages_key="chat_history"
)
# Utilisation
response = chatbot.invoke(
{"question": "Combien de jours de congés ai-je droit ?"},
config={"configurable": {"session_id": "user_001"}}
)
print(response)
Gestion de la Mémoire Conversationnelle
La mémoire est essentielle pour un chatbot d'entreprise : elle permet les questions de suivi ("Et pour les RTT ?"), les clarifications, et maintient le contexte de la conversation. LangChain propose plusieurs stratégies :
- ▹ChatMessageHistory — Stocke l'intégralité des messages. Simple mais peut dépasser la fenêtre de contexte du LLM pour les longues conversations.
- ▹ConversationBufferWindowMemory — Conserve les k derniers échanges. Bon compromis pour la plupart des cas d'usage (k=5 à 10 recommandé).
- ▹ConversationSummaryMemory — Résume les échanges précédents via le LLM. Utile pour les conversations très longues (support technique multi-étapes).
- ▹ConversationTokenBufferMemory — Garde autant de messages que possible dans une limite de tokens. Le plus prévisible en termes de coûts.
Astuce production : Pour les chatbots à fort trafic, utilisez Redis comme backend de mémoire (RedisChatMessageHistory) au lieu du stockage en mémoire. Cela permet la persistance entre les redémarrages et le partage entre instances.
6 Optimisation et Qualité
Un chatbot RAG fonctionnel n'est que le début. Pour atteindre un niveau de qualité production, il faut optimiser le retrieval, implémenter le reranking, et mettre en place une évaluation continue. Cette section couvre les techniques avancées qui font la différence entre un prototype et un outil métier fiable.
Reranking : la clé de la pertinence
La recherche vectorielle initiale (bi-encoder) est rapide mais approximative. Le reranking utilise un cross-encoder plus puissant pour ré-ordonner les résultats et éliminer les faux positifs. C'est l'optimisation avec le meilleur retour sur investissement :
from langchain.retrievers import ContextualCompressionRetriever
from langchain_cohere import CohereRerank
from langchain.retrievers.document_compressors import CrossEncoderReranker
from langchain_community.cross_encoders import HuggingFaceCrossEncoder
# Option 1 : Cohere Rerank (cloud, très performant)
cohere_reranker = CohereRerank(
model="rerank-v3.5",
top_n=3 # Garder les 3 meilleurs après reranking
)
# Option 2 : Cross-encoder local (self-hosted, gratuit)
cross_encoder = HuggingFaceCrossEncoder(
model_name="cross-encoder/ms-marco-MiniLM-L-12-v2"
)
local_reranker = CrossEncoderReranker(
model=cross_encoder, top_n=3
)
# Retriever avec reranking intégré
compression_retriever = ContextualCompressionRetriever(
base_compressor=cohere_reranker,
base_retriever=vectorstore.as_retriever(search_kwargs={"k": 20})
# Récupère 20 docs, rerank garde les 3 meilleurs
)
Hybrid Search : le meilleur des deux mondes
La recherche hybride combine la recherche sémantique (dense vectors) avec la recherche lexicale (BM25/sparse). Cela couvre les cas où la recherche sémantique seule échoue, notamment pour les termes techniques spécifiques, les numéros de référence, ou les acronymes métier :
from langchain.retrievers import EnsembleRetriever
from langchain_community.retrievers import BM25Retriever
# Retriever dense (sémantique)
dense_retriever = vectorstore.as_retriever(search_kwargs={"k": 10})
# Retriever sparse (BM25 lexical)
bm25_retriever = BM25Retriever.from_documents(chunks)
bm25_retriever.k = 10
# Ensemble : fusion avec pondération
hybrid_retriever = EnsembleRetriever(
retrievers=[dense_retriever, bm25_retriever],
weights=[0.6, 0.4] # 60% sémantique, 40% lexical
)
Évaluation avec RAGAS
L'évaluation d'un chatbot RAG nécessite des métriques spécifiques. Le framework RAGAS (Retrieval Augmented Generation Assessment) est devenu le standard en 2026 pour mesurer la qualité d'un pipeline RAG :
- ▹Faithfulness — La réponse est-elle fidèle au contexte fourni ? Mesure les hallucinations. Score cible : >0.85.
- ▹Answer Relevancy — La réponse répond-elle bien à la question posée ? Détecte les réponses hors sujet. Score cible : >0.80.
- ▹Context Precision — Les chunks récupérés sont-ils pertinents pour la question ? Mesure la qualité du retrieval. Score cible : >0.75.
- ▹Context Recall — Le retrieval a-t-il trouvé tous les chunks nécessaires pour répondre ? Détecte les informations manquantes. Score cible : >0.70.
from ragas import evaluate
from ragas.metrics import (
faithfulness, answer_relevancy,
context_precision, context_recall
)
from datasets import Dataset
# Préparer le jeu de test
eval_data = {
"question": [
"Combien de jours de congés annuels ?",
"Quelle est la procédure de télétravail ?",
"Comment déclarer un accident de travail ?"
],
"answer": [resp1, resp2, resp3], # Réponses du chatbot
"contexts": [ctx1, ctx2, ctx3], # Chunks récupérés
"ground_truth": [gt1, gt2, gt3] # Réponses de référence
}
result = evaluate(
Dataset.from_dict(eval_data),
metrics=[faithfulness, answer_relevancy,
context_precision, context_recall]
)
print(result) # {'faithfulness': 0.92, 'answer_relevancy': 0.87, ...}
Recommandation : Constituez un jeu de test de 50-100 questions/réponses couvrant vos cas d'usage principaux. Faites-le valider par les experts métier. Exécutez l'évaluation RAGAS après chaque modification du pipeline (changement de chunk_size, nouveau modèle, ajout de documents).
7 Déploiement et Production
Le passage en production d'un chatbot RAG d'entreprise exige une attention particulière à la performance, la sécurité, le monitoring et la gestion des coûts. Voici un guide complet pour déployer et opérer votre chatbot de manière fiable et pérenne.
API avec FastAPI et LangServe
LangServe transforme votre chaîne LangChain en API REST production-ready avec documentation OpenAPI automatique, support du streaming, et playground intégré :
from fastapi import FastAPI, HTTPException
from fastapi.middleware.cors import CORSMiddleware
from langserve import add_routes
from pydantic import BaseModel
import uvicorn
app = FastAPI(
title="Chatbot RH - API RAG",
version="1.0.0",
description="API chatbot d'entreprise avec RAG et LangChain"
)
app.add_middleware(
CORSMiddleware,
allow_origins=["https://intranet.entreprise.fr"],
allow_methods=["POST"],
allow_headers=["*"],
)
# Expose la chaîne RAG via LangServe
add_routes(
app,
chatbot, # La chaîne RunnableWithMessageHistory
path="/chat",
enable_feedback_endpoint=True,
enable_public_trace_link_endpoint=False
)
# Endpoint de santé
@app.get("/health")
async def health_check():
return {"status": "healthy", "vector_count": vectorstore._collection.count()}
if __name__ == "__main__":
uvicorn.run(app, host="0.0.0.0", port=8000)
Monitoring et Observabilité
En production, vous devez surveiller chaque étape du pipeline RAG pour détecter les dégradations et optimiser en continu. Les outils de monitoring essentiels :
- ▹LangSmith — Plateforme officielle LangChain pour le tracing, l'évaluation et le monitoring. Visualise chaque étape de la chaîne avec latences et tokens consommés. Indispensable en production.
- ▹Prometheus + Grafana — Métriques techniques : latence P50/P95/P99, throughput, taux d'erreur, utilisation mémoire du vector store.
- ▹Métriques métier — Taux de satisfaction utilisateur (thumbs up/down), taux de fallback vers un humain, questions sans réponse, nombre de tours de conversation moyen.
Sécurité et Conformité
La sécurité d'un chatbot d'entreprise est primordiale, surtout lorsqu'il accède à des données sensibles (RH, juridique, financier). Mesures essentielles à implémenter :
- ▹Contrôle d'accès (RBAC) — Filtrez les documents accessibles selon le rôle de l'utilisateur. Utilisez les métadonnées du vector store pour le filtrage :
filter={"department": user.department}. - ▹Prompt injection protection — Validez et nettoyez les entrées utilisateur. Utilisez un LLM garde-fou (guardrails) pour détecter les tentatives de jailbreak et les requêtes malveillantes.
- ▹Audit trail — Loguez chaque interaction (question, contexte récupéré, réponse générée) pour la traçabilité RGPD et les audits de conformité.
- ▹Chiffrement — TLS en transit, chiffrement at-rest pour le vector store. Les embeddings peuvent être inversés partiellement : traitez-les comme des données sensibles.
Gestion des Coûts
Les coûts d'un chatbot RAG se répartissent entre embeddings, LLM, infrastructure et monitoring. Voici une estimation typique pour un chatbot RH servant 500 utilisateurs/jour :
- ▹Embeddings (ingestion) — ~$5/mois pour 10K documents (one-time + mises à jour). Coût marginal avec text-embedding-3-small.
- ▹LLM (génération) — ~$150-400/mois avec GPT-4o (500 requêtes/jour, ~1500 tokens/requête). Réduisible avec GPT-4o-mini ou Mistral pour les questions simples.
- ▹Vector Store — Qdrant Cloud ~$25/mois pour 1M vecteurs. Self-hosted : coût serveur uniquement (~$50/mois VM dédiée).
- ▹Reranking — Cohere Rerank ~$1/1000 requêtes. ~$15/mois pour 500 requêtes/jour.
Maintenance de la Base Documentaire
Un chatbot RAG n'est utile que si sa base documentaire est à jour. Mettez en place un pipeline de mise à jour continue :
- ▹Incremental indexing — Utilisez les métadonnées (hash du contenu, date de modification) pour ne réindexer que les documents modifiés. LangChain fournit le
RecordManagerpour gérer l'indexation incrémentale. - ▹Webhooks — Connectez Confluence/Notion/SharePoint via webhooks pour déclencher la réindexation automatiquement lors de la mise à jour d'un document.
- ▹Expiration et archivage — Définissez une politique d'expiration pour les documents obsolètes (TTL sur les métadonnées). Un document RH de 2019 ne doit pas polluer les réponses sur la politique actuelle.
- ▹Feedback loop — Analysez les questions sans réponse et les feedbacks négatifs pour identifier les lacunes documentaires. Intégrez ce retour dans votre processus de rédaction documentaire.
Checklist de déploiement production : Authentification SSO, rate limiting (10 req/min/user), circuit breaker sur l'API LLM, fallback gracieux ("Je ne peux pas répondre, contactez le service RH"), sauvegarde quotidienne du vector store, alertes sur latence P95 > 5s, revue mensuelle des métriques RAGAS, mise à jour documentaire hebdomadaire.