Le besoin

Vos équipes passent du temps à chercher : dans Confluence, dans des PDF, dans des e-mails, dans la tête d'un collègue. Un assistant RAG (Retrieval-Augmented Generation) répond à leurs questions en s'appuyant sur vos documents, et cite ses sources pour que chacun puisse vérifier.

C'est le cas d'usage GenAI le plus demandé en entreprise. C'est aussi celui où l'écart entre la démo et la production est le plus grand : une démo RAG se monte en deux jours, un RAG fiable en production demande une vraie architecture.

L'architecture

Le système se découpe en deux chaînes distinctes, qui vivent à des rythmes différents.

La chaîne d'ingestion transforme vos documents en base interrogeable :

  • Extraction : chaque format (PDF, Word, pages Confluence, tickets) a son parseur. C'est moins glamour que le LLM, et c'est là que la moitié des problèmes de qualité naissent.
  • Découpage (chunking) : les documents sont découpés en passages qui respectent leur structure : sections, tableaux, listes. Un découpage aveugle au milieu d'un tableau produit des réponses fausses en aval.
  • Indexation hybride : chaque passage est indexé deux fois, en vecteurs (pour le sens) et en mots-clés (pour les références exactes : noms de produits, codes, sigles). L'un sans l'autre rate des questions.

La chaîne de réponse traite chaque question :

  • Récupération : les deux index sont interrogés, leurs résultats fusionnés, puis reclassés par un modèle de reranking qui garde les passages réellement pertinents.
  • Génération : le LLM répond uniquement à partir des passages fournis, avec une consigne stricte : citer chaque source, et dire « je ne sais pas » quand les documents ne répondent pas.
  • Citations : chaque affirmation renvoie au document d'origine. C'est ce qui transforme un gadget en outil de travail : l'utilisateur peut vérifier.

Les pièges que nous connaissons

  • Le corpus pourri. Un RAG répond à partir de ce qu'on lui donne. Si trois versions contradictoires d'une procédure coexistent, il citera l'une des trois au hasard. Le tri du corpus fait partie du projet, pas de l'après-projet.
  • Le « ça a l'air bon ». Dix questions testées à la main ne disent rien. Il faut un jeu d'évaluation : des vraies questions de vos équipes, avec les bonnes réponses attendues, rejoué à chaque modification.
  • Les droits d'accès. Si un document est confidentiel, l'assistant ne doit ni le citer ni s'en inspirer selon qui demande. Le filtrage par permissions se conçoit dès le départ, pas après le premier incident.
  • La dérive silencieuse. Les documents changent, l'index vieillit, la qualité baisse sans bruit. Sans réindexation planifiée et sans suivi de la qualité dans le temps, le système se dégrade en quelques mois.

Comment on mesure que ça marche

Trois familles de métriques, suivies en continu :

  • Qualité de récupération : pour chaque question du jeu de test, les bons passages sont-ils remontés ? (rappel, précision du reranking)
  • Qualité de réponse : la réponse est-elle exacte, sourcée, et refuse-t-elle de répondre quand il le faut ? (évaluée automatiquement, vérifiée par échantillon humain)
  • Coût et latence : coût par question, temps de réponse de bout en bout, suivis par requête dans un outil d'observabilité.

Ce que vous gardez à la fin

Le code dans votre dépôt, l'index sur votre infrastructure, le jeu d'évaluation branché à votre CI, et une équipe formée pour faire vivre le corpus. Le système continue de tourner sans nous.