RAG en entreprise : transformer des documents métier en connaissance exploitable

Dans beaucoup de contextes métier les documents non structurés s’accumulent, cela peut prendre la forme de notes, de comptes rendus, de documents administratifs, etc. Une recherche classique ne se base que sur des mots-clés exacts (éventuellement cela peut-être améliorée avec l’utilisation de dictionnaire de synonymes). Si la question n’emploie pas le même vocabulaire que le document : celui-ci ne ressortira pas.

Le RAG (pour Retrieval Augmented Generation) combine deux choses : pouvoir retrouver des passages pertinents dans une base documentaire dans un premier temps, puis demander à un modèle de langage de rédiger une réponse à partir de ces extraits dans un second temps. Le modèle s’appuie ainsi sur des sources identifiables.

Recherche sémantique

La recherche vectorielle convertit chaque texte en une liste de nombres (= un embedding) qui capture son sens. Ainsi deux textes au sens proches ont aussi des vecteurs proches, même s’ils ne partagent aucun mot directement. Cette approche permet donc de retrouver des passages dont le sens correspond à la requête formulée.

Pour fonctionner un RAG repose donc sur une chaîne de traitement de données en amont de toute génération de réponse.

Ingestion des documents

L’ingestion part des documents bruts. On en nettoie le contenu, on le découpe en passages, on ajoute des métadonnées (type, date, domaine).

flowchart TB
  A[Fichiers bruts] --> B[Extraction du texte]
  B --> C[Découpage en passages]
  C --> D[Génération des embeddings]
  D --> E[Stockage vectoriel]
  C --> F[Métadonnées]
  F --> E

Le découpage doit préserver le sens car des segments trop courts perdent le contexte et de trop longs diluent la pertinence. Les métadonnées servent ensuite de filtres.

Architecture

La plateforme doit à-minima comprendre les composants suivants :

• une interface d’import et de consultation des documents
• un service d’orchestration des traitements
• une base de données (par exemple PostgreSQL) et la représentation vectorielle des données (via par exemple le plugin pgvector)
• un moteur de recherche vectorielle pour retrouver les passages les plus proches de la question

Lorsqu’une réponse rédigée par IA est nécessaire, le modèle reçoit les extraits sélectionnés comme contexte.

flowchart TB
  A[Question posée en langage naturel]
  B[Recherche dans la base de connaissance]
  C[Sélection des passages pertinents]
  D[Réponse appuyée sur des sources]
  A --> B --> C --> D

Chaque composant a un rôle précis. Cette séparation permet d’itérer.

Au-delà de la recherche textuelle

Un RAG classique récupère des passages textuels et laisse le modèle générer une réponse. Certaines questions nécessitent d’interroger des bases de données structurées, d’effectuer des calculs ou des analyses statistiques.

La plateforme peut orchestrer d’autres outils :

• traduction d’une question en requête SQL pour interroger une base de gestion
• délégation de calculs
• appel à un module d’analyse statistique (par exemple en R) pour produire une tendance

La recherche sémantique reste le point d’entrée, mais le système peut enchaîner plusieurs actions pour produire une réponse.

Limites et points d’attention

Un RAG ne vaut que si les sources sont fiables et les droits d’accès respectés. La qualité des réponses dépend directement de la qualité de l’ingestion et des métadonnées associées. Il faut prévoir :

• la traçabilité des sources
• la gestion des droits d’accès aux documents
• le cycle de vie des contenus (obsolescence, archivage)
• la conformité réglementaire

Conclusion

Le RAG sert entre autre à retrouver une information dans des documents non structurés et à produire une réponse sourcée. Sa mise en œuvre demande une phase d’ingestion soignée et une recherche vectorielle efficace. L’architecture modulaire rend la solution résiliente et permet d’étendre le système au-delà de la simple recherche documentaire et de s’adapter aux différentes évolutions.