1. Pourquoi RAG et pas un simple chatbot

Un chatbot classique (LLM seul, sans retrieval) a deux défauts rédhibitoires pour le support client :

  • Il hallucine : il peut inventer des politiques de retour, des prix ou des délais de livraison qui n'existent pas.
  • Sa connaissance est figée : il ne connaît pas vos nouveaux produits, vos offres actuelles ni vos procédures internes.

Un agent RAG (Retrieval-Augmented Generation) résout ces deux problèmes. Avant de générer une réponse, il récupère les passages pertinents de votre base de connaissances. La réponse est ancrée dans vos documents réels, pas dans les paramètres du modèle.

Gain mesuré Avec une base de connaissances bien construite et un bon pipeline RAG, un agent peut répondre correctement à 65-85 % des questions de niveau 1 sans halluciner. Le 15-35 % restant est escaladé vers un humain.

2. Construire la base de connaissances

La qualité de la base de connaissances est le facteur n°1 de la performance de l'agent. Un bon modèle avec une mauvaise base donnera de mauvais résultats.

Contenu à inclure :

  • FAQ validée (questions fréquentes avec réponses officielles)
  • Documentation produit et guides d'utilisation
  • Politique de retour, remboursement et garantie
  • Conditions générales de vente
  • Procédures internes de traitement (ce que peut promettre le support)
  • Historique des tickets résolus (avec les solutions)

Contenu à exclure :

  • Documents non validés ou en cours de mise à jour
  • Données personnelles de clients (RGPD)
  • Procédures confidentielles qui ne doivent pas être communiquées
  • Documents contradictoires (si deux docs disent des choses différentes, résolvez le conflit avant d'indexer)
Erreur fréquente Indexer "tout ce qu'on a" sans curation. Un agent qui trouve des informations contradictoires dans sa base va soit choisir la mauvaise, soit générer une réponse confuse. La curation est un travail continu, pas un projet ponctuel.

3. Stratégies de chunking

Les documents ne peuvent pas être indexés en entier — ils doivent être découpés en chunks (morceaux) qui seront indexés séparément. La stratégie de découpage a un impact direct sur la qualité du retrieval.

Chunking par taille fixe

Découper tous les 500 tokens avec un overlap de 50 tokens. Simple, mais peut couper une idée en deux et créer des chunks sans contexte.

Chunking par structure sémantique

Découper aux délimitations naturelles : paragraphes, sections, questions de FAQ. Préserve mieux la cohérence sémantique. Recommandé pour les FAQs et la documentation structurée.

Chunking hiérarchique (recommandé)

Deux niveaux d'indexation : des chunks parents (section entière) et des chunks enfants (paragraphe). Le retrieval s'effectue sur les enfants, mais la réponse est générée à partir du parent complet. Meilleur contexte, meilleure cohérence.

Recommandations pratiques

  • Taille de chunk : 200-500 tokens selon le contenu
  • Overlap : 10-15 % de la taille du chunk
  • Inclure les métadonnées dans chaque chunk : source, date, section, produit concerné
  • Tester avec 20 questions représentatives et mesurer le recall

4. Embeddings et moteur vectoriel

Chaque chunk est transformé en un vecteur numérique (embedding) qui représente sa signification sémantique. Des chunks similaires en sens auront des vecteurs proches. La requête du client est également transformée en vecteur, et le moteur vectoriel récupère les chunks les plus proches.

Modèles d'embedding recommandés :

  • text-embedding-3-large (OpenAI) — haute performance, API cloud
  • multilingual-e5-large — multilingue, fonctionne bien pour le français
  • nomic-embed-text — open source, auto-hébergeable

Moteurs vectoriels :

  • Chroma — open source, simple, idéal pour démarrer
  • Qdrant — open source, performant, auto-hébergeable
  • Pinecone — cloud managé, scalable, plus simple à opérer
  • pgvector — extension PostgreSQL, si vous avez déjà une base PG

5. Pipeline de retrieval et génération

Le pipeline complet d'un agent RAG pour le support :

  1. Réception de la question : le client pose sa question via le chat, l'email ou le formulaire.
  2. Reformulation optionnelle : un premier appel LLM peut reformuler la question pour améliorer le retrieval ("Qu'est-ce que vous entendez par 'ça ne marche pas' ? Le produit ne se connecte pas ou ne s'allume pas ?").
  3. Vectorisation de la requête : la question est transformée en vecteur avec le même modèle d'embedding que la base.
  4. Retrieval : le moteur vectoriel retourne les N chunks les plus similaires (typiquement 3-5).
  5. Reranking optionnel : un modèle de reranking (Cohere Rerank, BGE Reranker) réordonne les chunks par pertinence réelle. Améliore significativement la qualité.
  6. Génération : le LLM génère une réponse en utilisant uniquement les chunks récupérés. Le prompt système l'instruit de ne pas inventer d'informations absentes des sources.
  7. Vérification de source : la réponse cite les documents sources. Le client peut vérifier l'information.

6. Score de confiance et escalade

Un bon agent sait quand il ne sait pas. Implémenter un mécanisme de score de confiance est essentiel pour éviter que l'agent réponde avec assurance sur des sujets hors de sa base de connaissances.

Signaux d'un faible niveau de confiance :

  • Score de similarité des chunks récupérés en dessous d'un seuil (ex. : < 0.75)
  • Chunks récupérés issus de catégories différentes de la question
  • Question contenant des termes non présents dans la base
  • Le LLM lui-même déclare ne pas trouver l'information (si le prompt le lui permet)

Réponse à un faible score :

  • L'agent répond "Je n'ai pas d'information précise sur ce sujet" plutôt qu'une réponse inventée
  • L'agent propose de transférer vers un humain
  • L'agent propose 2-3 questions de clarification pour affiner la recherche

7. Ce que l'agent ne doit pas faire seul

Même un excellent agent RAG doit avoir des limites claires sur les actions qu'il peut prendre sans validation humaine :

✗Promettre un remboursement ou un geste commercial
✗Modifier une commande ou un abonnement
✗Répondre à une plainte juridique ou réglementaire
✗Demander des données bancaires ou des pièces d'identité
✗Communiquer sur des incidents de sécurité
✗Prendre des engagements de délai non validés
Règle d'or L'agent parfait n'est pas celui qui répond toujours. C'est celui qui sait quand s'arrêter, prépare un résumé clair de la conversation, et transfère à un humain avec le contexte complet.

8. Monitoring et amélioration continue

Un agent RAG n'est pas un projet "lancer et oublier". Il nécessite un suivi régulier pour maintenir sa qualité :

  • Métriques clés : taux de résolution autonome, taux d'escalade, satisfaction client (CSAT), taux de réponse hors base (hallucination).
  • Revue hebdomadaire : examiner les 10-20 conversations avec le plus faible CSAT ou les escalades les plus fréquentes.
  • Enrichissement de la base : chaque question fréquente sans bonne réponse dans la base est une opportunité d'enrichissement.
  • Test de régression : après chaque mise à jour de la base, retester les 50 questions de référence pour s'assurer que la qualité ne régresse pas.

Le meilleur cycle d'amélioration : déployer → mesurer → identifier les gaps → enrichir la base → re-tester → déployer. Six semaines suffisent généralement pour atteindre un niveau de qualité stable.