Couche par couche : conception d’un pipeline de récupération RAG réel pour les agents IA

Remplacer un agent de récupération de jouets par un véritable pipeline RAG est un bon moment pour ralentir et structurer le travail en étapes. Dans une plateforme d’entreprise multi-agents, le RetrievalAgent fonctionnait initialement avec une implémentation locale délibérément simple. Cela suffisait pour valider l’architecture, mais une utilisation en production exige des documents réels, des embeddings, un stockage vectoriel et une recherche sémantique. Le flux cible passe des documents par l’ingestion, le découpage et la génération d’embeddings vers ChromaDB, puis vers la récupération sémantique, le RetrievalAgent et l’ensemble de la plateforme.

Plutôt que de tout construire d’un coup, le plan prévoit d’ajouter une couche à la fois, avec des tests à chaque étape afin de maintenir le pipeline CI en bon état. Des améliorations progressives, un CI fiable et une architecture solide constituent les objectifs.

Les composants d’un pipeline RAG

Un pipeline complet regroupe plusieurs aspects techniques indépendants, que le diagramme ci-dessous présente à partir des documents sources.

Source Documents
       ↓
Document Ingestion
       ↓
    Chunking
       ↓
   Embeddings
       ↓
 Vector Storage
       ↓
Semantic Search
       ↓
Retrieved Context
       ↓
Retrieval Agent

Il est possible de développer chaque composant en même temps, mais cela rend difficile l’identification des pannes. Lorsque la qualité de la récupération est médiocre, où réside le problème ? Cela peut provenir du parsing des documents, de la segmentation en blocs, des embeddings, du stockage vectoriel, de la logique de requête, des métadonnées ou de l’intégration avec l’agent. En attribuant à chaque couche une responsabilité claire, un contrat et des limites de test, on peut répondre à ces questions. Le rythme de travail consiste à développer, tester, déployer, valider dans l’environnement CI, à maintenir tout en bon état, puis à continuer.

Commencer par le contrat de données

Au préalable à tout utilisation d’embeddings ou de ChromaDB, la première étape est l’établissement du contrat de données. Le pipeline doit distinguer deux concepts : SourceDocument et DocumentChunk.

Un SourceDocument désigne la source de connaissances originale avant qu’elle ne soit divisée. Il peut s’agir d’un fichier PDF, DOCX ou TXT, de documents internes, de rapports financiers, de politiques d’entreprise, de manuels techniques ou de contenus de base de connaissances. Sa structure conceptuelle est la suivante :

SourceDocument
 ├── document_id
 ├── content
 ├── source
 └── metadata

Chaque document original obtient ainsi une identité stable au sein de l’architecture de recherche.

Les documents d’entreprise volumineux ne devraient normalement pas être intégrés sous forme d’un seul gros bloc de texte. Ils doivent être divisés en unités plus petites et significatives, et c’est là la fonction de DocumentChunk:

DocumentChunk
 ├── chunk_id
 ├── document_id
 ├── content
 ├── source
 ├── chunk_index
 └── metadata

La relation entre les deux est un-à-plusieurs :

SourceDocument
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
       Chunk 0       Chunk 1      Chunk 2
          │            │            │
          └────────────┼────────────┘
                       ↓
                 Same document_id
                  + source metadata

Une seule source peut produire des dizaines, voire des centaines de fragments, mais chaque fragment conserve un lien vers son document_id d’origine et sa source. Ce lien devient essentiel dès que la récupération sémantique commence à restituer des fragments individuels de documents bien plus volumineux.

Pourquoi la traçabilité est intégrée dès le début

Imaginez un rapport financier de 50 pages. Le système peut le diviser en des dizaines de fragments, et une recherche sémantique n’en restitue que trois. Le système doit néanmoins être capable d’indiquer quel document original contient ces informations. Reconstituer cette relation après la récupération est fragile, il faut donc la préserver à chaque étape du processus.

Original Document
       ↓
SourceDocument
       ↓
DocumentChunk
       ↓
Embedding
       ↓
Vector Record
       ↓
Semantic Search
       ↓
RetrievedDocument
       ↓
Original Source

La traçabilité fait partie de l’architecture des données dès le début et n’est pas une idée ajoutée ultérieurement.

Vérification des contrats

Avec les modèles définis, des tests automatisés couvrent à la fois SourceDocument et DocumentChunk. Ils vérifient que les modèles sont construits correctement et que les champs clés se comportent comme prévu, y compris les IDs de document, les détails de la source, le contenu ainsi que les indices des fragments.

Cela peut sembler un jalon mineur, mais ces modèles seront au cœur de tout le processus de récupération :

Document Models
      ↓
   Chunking
      ↓
  Embeddings
      ↓
   ChromaDB
      ↓
  Retrieval
      ↓
    Agents

Une rupture de contrat au début de cette chaîne peut affecter tout ce qui suit, c’est pourquoi la base de données est protégée avant que d’autres infrastructures ne soient ajoutées par-dessus.

Un autre choix délibéré a été de maintenir cette étape dépourvue de dépendances externes. Aucune appel à OpenAI ni à ChromaDB n’a lieu ici, et les tests ne valident que les contrats de documents. La suite CI rapide reste donc déterministe.

Code Change
     ↓
Local Fast Tests
     ↓
Commit
     ↓
Push to GitHub
     ↓
GitHub Actions
     ↓
Clean CI Environment
     ↓
Fast Unit Tests
     ↓
CI PASSED ✅

La suite rapide continue de s’élargir tandis que les tests d’intégration externes restent dans un groupe distinct. La règle qui sous-tend cela est la suivante : chaque nouvelle couche intégrée à la plateforme bénéficie d’une protection automatisée.

Le plan complet

Le contrat pour les documents n’est que la première couche. Voici l’architecture cible dans son intégralité :

Enterprise Documents
        │
        ▼
     Ingestion
        │
        ▼
      Chunking
        │
        ▼
     Embeddings
        │
        ▼
     ChromaDB
   Vector Storage
        │
        ▼
 Semantic Retrieval
        │
        ▼
 Retrieved Context
        │
        ▼
  RetrievalAgent
        │
        ▼
Multi-Agent Platform

Chaque étape a une responsabilité spécifique et doit rester compréhensible et testable indépendamment.

Vient ensuite le chunking

Le composant suivant est le Chunking Service, qui transforme un SourceDocument en plusieurs objets DocumentChunk.

SourceDocument
      │
      ▼
ChunkingService
      │
      ├── DocumentChunk 0
      ├── DocumentChunk 1
      ├── DocumentChunk 2
      └── DocumentChunk N

Au fil du temps, le service doit gérer la taille des blocs et leur chevauchement, transmettre les métadonnées ainsi que les détails des sources, attribuer un index à chaque bloc et générer des identifiants stables. Une décision architecturale se distingue : le découpage en blocs reste hors de la responsabilité de l’Agent de récupération. Cet agent utilise uniquement les capacités de récupération et ne devrait pas également s’occuper de la préparation des documents.

Embeddings et stockage

Lorsque le découpage en blocs a été mis en œuvre et testé, la couche suivante génère des embeddings vectoriels.

DocumentChunk
      ↓
Embedding Service
      ↓
Embedding Model
      ↓
Vector Representation

Chaque morceau se transforme en un vecteur qui encode son sens. Par la suite, ces vecteurs sont comparés à une requête utilisateur intégrée afin de trouver du matériel pertinent.

DocumentChunk
      ↓
EmbeddingService
      ↓
Embedding Provider
      ↓
Vector

Changer le modèle d’incorporation ultérieurement ne devrait presque pas perturber le reste de la conception RAG.

Après les embeddings vient le stockage vectoriel persistant. Pour le développement local, le client persistant de ChromaDB peut conserver les connaissances indexées entre les redémarrages de l’application.

DocumentChunk
      +
Embedding
      +
Metadata
      ↓
   ChromaDB
      ↓
Persistent Vector Collection

Un enregistrement stocké a besoin de plus qu’un vecteur. Il contient également suffisamment d’informations pour préserver le contexte et assurer la traçabilité :

Vector Record
 ├── chunk_id
 ├── embedding
 ├── content
 ├── document_id
 ├── source
 ├── chunk_index
 └── metadata

Cela permet à la récupération de fournir un contexte de document significatif et non seulement des vecteurs similaires.

Recherche

Lorsque le stock est rempli, le système peut effectuer une recherche sémantique. Le chemin de la requête est :

User Query
    ↓
Query Embedding
    ↓
ChromaDB Similarity Search
    ↓
Top-K Relevant Chunks
    ↓
Scores + Metadata
    ↓
Retrieved Context

Au lieu de s’appuyer entièrement sur des correspondances exactes avec des mots-clés, la récupération sémantique identifie des segments conceptuellement liés à la demande de l’utilisateur. Les résultats sont ensuite convertis en le contrat de récupération standardisé déjà utilisé par la plateforme.

Reconnexion de l’agent

Seule lorsque l’infrastructure de récupération fonctionne, tout le processus est à nouveau connecté au RetrievalAgent. Du point de vue de l’agent, la situation reste simple :

AgentRequest
     ↓
RetrievalAgent
     ↓
RetrievalService
     ↓
Relevant Documents
     ↓
Structured RetrievalResult

Dans le cas de RetrievalService, l’implémentation devient bien plus sophistiquée :

RetrievalService
      ↓
Query Embedding
      ↓
ChromaDB
      ↓
Semantic Search
      ↓
Ranking
      ↓
Retrieved Context

La séparation est importante. L’agent de récupération doit considérer la récupération comme une capacité et n’a pas besoin de connaître les bases de données vectorielles, la génération d’embeddings, le stockage par blocs ou l’ingestion de documents.

L’agent initial fonctionnait sur des données locales, et l’architecture ressemblait à peu près à ceci :

RetrievalAgent
      ↓
RetrievalService
      ↓
Local Documents

L’implémentation peut désormais évoluer vers quelque chose de plus riche :

RetrievalAgent
      ↓
RetrievalService
      ↓
Semantic Retrieval
      ↓
ChromaDB
      ↓
Embedded Enterprise Documents

Remarquez ce qui reste inchangé : le lien de RetrievalAgent vers RetrievalService. Seule l’infrastructure derrière ce contrat change, et c’est précisément pour cette raison que l’abstraction de récupération a été créée avant l’apparition des bases de données vectorielles. L’infrastructure doit pouvoir évoluer librement sans nécessiter une refonte de l’architecture de l’agent.

Intégration à la plateforme

Le pipeline RAG n’existe pas indépendamment. Son but est de fournir des connaissances d’entreprise concrètes au système multi-agents plus vaste.

User
                          │
                          ▼
                    Supervisor Agent
                          │
                          ▼
                     Planning Agent
                          │
                          ▼
                    Execution Plan
                          │
                          ▼
                     Agent Registry
                          │
             ┌────────────┼────────────┐
             ▼            ▼            ▼
       RetrievalAgent  ResearchAgent AnalysisAgent
             │
             ▼
      RetrievalService
             │
             ▼
         RAG Pipeline
             │
             ▼
      Relevant Context
             │
             ▼
       Downstream Agents

Dans cette image, l’agent de récupération met en relation la couche où plusieurs agents s’exécutent avec la couche qui contient les connaissances de l’entreprise.

Une leçon mérite d’être soulignée : RAG n’est pas simplement « ajouter une base de données vectorielle ». Une architecture de récupération solide implique de nombreuses décisions :

• Contrats de documents et ingestion
• Fragmentation et génération d’embeddings
• Stockage vectoriel et métadonnées
• Récupération sémantique et classement
• Traçabilité des sources
• Intégration des agents
• Tests et observabilité

La base de données vectorielle n’est qu’un composant parmi un système de récupération bien plus vaste.

Un schéma répétitif, intentionnellement

Le cycle d’ingénierie pour cet objectif est délibérément répétitif :

Build One Layer
      ↓
Add Unit Tests
      ↓
Run Fast Suite
      ↓
Push to GitHub
      ↓
CI Validates
      ↓
Keep Green
      ↓
Build Next Layer

Cela permet à la complexité d’augmenter tant que la confiance dans le système existant persiste. Au lieu d’ajouter cinq composants en même temps et de les déboguer ensemble, chaque fonctionnalité est validée avant l’arrivée de la suivante.

Le premier jalon du pipeline réel est atteint : le contrat SourceDocument, le contrat DocumentChunk, des tests pour les deux modèles ainsi qu’un exécution rapide de CI réussie. Voici le plan qui suit :

1. Document Contract             ✅ COMPLETE
          ↓
2. Chunking Service              ← NEXT
          ↓
3. Embedding Service
          ↓
4. ChromaDB Integration
          ↓
5. Semantic Retrieval
          ↓
6. RetrievalAgent Integration
          ↓
7. End-to-End RAG Pipeline

Chaque couche est mise en œuvre et testée de manière indépendante avant de passer à la suivante.

Pourquoi c’est important

Le premier agent de récupération a démontré que l’architecture d’agent fonctionnait. L’objectif maintenant est de remplacer sa récupération temporaire par une infrastructure réelle, en passant d’une récupération locale à un pipeline de documents, avec des segmentation en blocs, des embeddings, un stockage vectoriel, une recherche sémantique, et enfin un agent doté de RAG. Comme l’agent dépend d’une abstraction de service et non directement de ChromaDB, tout cela peut se faire sans avoir à redessiner la plateforme multi-agents.

Un principe plus général s’applique : il faut créer des contrats stables autour des composants susceptibles de changer. Les modèles évolueront, les bases de données vectorielles pourront être remplacées, les stratégies de segmentation se modifieront et les algorithmes de récupération s’amélioreront, mais la plateforme qui les entoure ne devrait pas avoir besoin d’être réécrite à chaque fois.

Ce qui est développé, c’est une capacité de récupération intégrée au sein d’une plateforme multi-agents d’entreprise, et non une démonstration ponctuelle de RAG. Là, le superviseur orchestre les opérations, le registre résout les capacités nécessaires, des agents spécialisés exécutent les tâches, RAG fournit des connaissances fiables, des tests protègent le comportement du système, CI surveille chaque modification et les outils d’observabilité évaluent le fonctionnement en production. La méthode reste toujours la même : créer une couche, la tester, la déployer, maintenir CI en état optimal, puis passer à la suivante.