Ingérer, nettoyer et découper sa donnée pour construire un RAG

Un système RAG (Retrieval-Augmented Generation) ne fonctionne que sur la donnée qu’on lui fournit. Brute, non structurée, mal découpée, cette donnée produira des réponses hallucinées, hors sujet ou simplement inutilisables. Ingérer, nettoyer et découper ne sont pas des étapes accessoires : elles constituent le socle technique sans lequel aucun LLM, aussi performant soit-il, ne peut raisonner correctement sur un corpus. Ce texte détaille chaque phase de ce pipeline, des stratégies d’ingestion massives jusqu’aux métriques de validation, en passant par le parsing, le nettoyage et les différentes approches de chunking.

Pourquoi la donnée brute ne peut pas aller directement dans un RAG

La dégradation du raisonnement avec la longueur du contexte

On pourrait croire qu’envoyer un document entier (ou un corpus complet) au LLM résout le problème. C’est l’inverse. Les grands modèles de langage dégradent leur capacité de raisonnement à mesure que le contexte s’allonge. Les données publiées par Anthropic à l’occasion de leur annonce de contexte à 1 million de tokens montrent que trois fournisseurs majeurs de LLM perdent en précision de récupération à mesure que le volume de texte en entrée augmente ^[1]. Autrement dit, plus on donne de texte au modèle, moins il « lit » bien ce qu’on lui donne. Les chunks plus petits permettent au LLM de se concentrer sur l’information la plus pertinente sans être distrait par des détails inutiles ^[1].

La fenêtre de contexte limitée des modèles d’embedding

Le problème ne se situe pas uniquement côté génération. Les modèles d’embedding, utilisés pour convertir les fragments de texte en vecteurs stockés dans une base vectorielle, possèdent eux aussi une fenêtre de contexte bornée ^[1]. Si un chunk dépasse cette fenêtre, le modèle d’embedding tronque ou dégrade la représentation vectorielle, ce qui compromet directement la qualité de la recherche sémantique en aval. Le chunking est donc une nécessité technique imposée par l’architecture même des modèles d’embedding choisis.

Latence et coût : la réalité économique

Le Time To First Token (TTFT) explose avec des contextes volumineux. Les expériences de référence tournent sur 2× H100 en précision FP8, une configuration très haut de gamme ^[1]. Or AWS ne propose même pas d’instance dual-H100 standard, et à elle seule une instance mono-H100 (p5.4xlarge) coûte déjà environ 6,88 $/heure, soit 5 022 $/mois en on-demand ^[1] : un montage bi-H100 reviendrait donc encore plus cher. Réduire la longueur du contexte par le chunking diminue significativement la latence d’inférence et le coût opérationnel ^[1]. À l’échelle d’un déploiement production, ce n’est pas un luxe, c’est une contrainte budgétaire.

Le pipeline complet en un coup d’œil

Avant d’entrer dans le détail de chaque étape, voici la vue d’ensemble du pipeline :

Ingérer massivement : paralléliser pour ne pas rester bloqué des semaines

Le goulot d’étranglement du traitement séquentiel

Traiter des documents un par un fonctionne sur un corpus de quelques centaines de fichiers. Dès que l’on passe à l’échelle de millions de documents, le traitement séquentiel devient un goulot d’étranglement insurmontable. Le projet Caselaw Access Project de Harvard Law School, par exemple, porte sur près de 7 millions de documents juridiques ^[1]. Un pipeline non parallélisé sur un tel volume prendrait des semaines, rendant impossible le maintien de la fraîcheur des données ^[1].

Stratégies de parallélisation

La solution repose sur trois piliers : le traitement parallèle, le calcul distribué et l’orchestration robuste des pipelines ^[1].

Traitement parallèle. Au lieu de traiter les documents séquentiellement, le pipeline doit gérer les documents (ou les lots de documents) de manière concurrente sur plusieurs nœuds de calcul. Les bibliothèques de parallélisation comme Ray ou Dask permettent la génération distribuée d’embeddings, tandis que Spark excelle dans la préparation de données à grande échelle ^[1].

Calcul distribué. La génération d’embeddings à partir des chunks est particulièrement gourmande en calcul. Il faut exploiter simultanément plusieurs GPU, en utilisant des techniques de traitement par lots pour maximiser le débit du modèle d’embedding choisi ^[1]. L’extraction de texte, le chunking et l’extraction de métadonnées peuvent également être parallélisés ^[1].

Orchestration. Un pipeline robuste s’apparente à une infrastructure de données critique, pas à un assemblage de scripts isolés ^[1]. Les services cloud proposent des solutions managées : sur Google Cloud Platform, par exemple, le mapping des services aux tâches de préparation des données pour les applications GenAI est le suivant ^[2] :

Tâche de préparation	Service(s) GCP principal(aux)	Cas d’usage pour les LLM/RAG
Ingestion	Cloud Storage, BigQuery, Pub/Sub, Dataflow	Stockage de fichiers bruts (GCS), formats ouverts (Iceberg, Hudi) via BigLake, chargement batch (BigQuery Load), flux temps réel (Pub/Sub + Dataflow/BigQuery)
Nettoyage et transformation	Dataflow, Dataproc, BigQuery SQL, Vertex AI Workbench	ETL batch/stream à grande échelle (Dataflow), traitement Spark (Dataproc), transformations SQL (BigQuery)
Structuration (pour RAG)	Dataflow, Dataproc, Vertex AI Workbench, Cloud Functions, BigQuery	Parsing de documents, logique de chunking, formatage (JSONL pour fine-tuning)
Feature engineering	BigQuery SQL, Vertex AI Workbench, Dataflow, Dataproc	Création de features pour modèles ML

L’approche dual-stream

Certains projets adoptent une ingestion à double flux pour distinguer données structurées et données sémantiques. Un premier flux extrait les champs objectifs (années d’expérience, attentes salariales, etc.) et les mappe directement vers des colonnes relationnelles. Un second flux identifie le texte descriptif et le marque pour vectorisation ultérieure ^[3]. Le flux structuré utilise par exemple une instruction SQL MERGE pour garantir l’idempotence, c’est-à-dire la possibilité de relancer le pipeline sans créer de doublons ^[3]. Cette architecture sépare clairement les responsabilités et facilite le debugging à grande échelle.

Parser les documents : sortir du texte exploitable

Le parsing, étape souvent sous-estimée

Les données textuelles destinées au RAG ne se présentent rarement sous forme de texte brut. Elles proviennent de PDF, de présentations PPTX, de documents Word (DOCX), de fichiers HTML ou de formats propriétaires divers ^[1]. La qualité du parsing conditionne tout ce qui suit : un texte mal extrait produit des chunks incohérents, des embeddings bruités et, in fine, des réponses incorrectes.

Les trois axes du preprocessing

Un pipeline de préparation robuste couvre trois axes ^[4] :

1. Préparation du texte : remplacer les abréviations, normaliser les encodages, nettoyer les artefacts de conversion (caractères spéciaux, numéros de page isolés, en-têtes répétitifs).
2. Collecte de métadonnées : stocker systématiquement les numéros de page, la source documentaire, l’auteur, la date de publication. Ces métadonnées ne servent pas au chunking lui-même mais conditionnent la qualité du retrieval et de l’attribution des sources.
3. Découpage : appliquer la stratégie de splitting choisie (cf. section suivante).

L’objectif final est de produire des chunks clairs et sans ambiguïté qui ne nécessitent pas le contexte environnant pour être compris ^[4].

Les formats et leurs spécificités

Chaque format pose ses propres défis. Les PDF peuvent contenir des tableaux multi-colonnes, des images intégrées, du texte en colonnes parallèles. Les PPTX mélangent texte libre, zones de texte et éléments graphiques. Les DOCX contiennent des styles hiérarchiques exploitables pour le chunking structurel. Sur GCP, le parsing est typiquement géré par Dataflow, Dataproc ou des Cloud Functions dédiées, qui implémentent la logique de chunking et produisent des fichiers formatés (comme du JSONL) prêts pour l’étape suivante ^[2].

Nettoyer et fiabiliser : se débarrasser du bruit et des documents périmés

Le piège de l’information obsolète

Le nettoyage des données est une étape critique souvent négligée dans les prototypes. En production, deux problèmes majeurs se présentent :

• Les doublons : un même document ingéré plusieurs fois (parfois sous des noms légèrement différents) fausse la recherche vectorielle en surreprésentant certaines informations.
• Les versions périmées : seul un expert du domaine peut déterminer si un document constitue véritablement la « source de vérité » ou s’il s’agit d’une version obsolète qui devrait être purgée, pour éviter que le RAG ne se base sur de l’information périmée ^[1].

Les tâches concrètes de nettoyage

Le nettoyage et la transformation des données englobent la gestion des erreurs, des valeurs manquantes et des incohérences, ainsi que la conversion des données dans un format exploitable pour les modèles ^[5]. Ce travail comprend :

• Suppression des doublons (exactes et proches) par hachage ou similarité textuelle.
• Filtrage temporel : conserver uniquement la version la plus récente d’un document lorsque plusieurs versions coexistent.
• Normalisation linguistique : uniformiser la casse, corriger les encodages, supprimer les caractères de contrôle.
• Validation par un expert métier : sur des corpus sensibles (juridique, médical, financier), aucune automatisation ne remplace l’œil humain pour trancher sur la validité d’un document ^[1][5].

L’avocate de la qualité des données auprès des équipes techniques est souvent le chef de produit, qui doit plaider pour des données de haute qualité et précises tout en comprenant l’impact de chaque erreur sur le système final ^[5]. Sur GCP, ces opérations de nettoyage s’appuient sur Dataflow pour le traitement batch/stream à grande échelle, Dataproc pour les workloads Spark, ou BigQuery SQL pour les transformations relationnelles ^[2].

Un pipeline continu, pas un one-shot

Le nettoyage n’est pas une passe unique. En production, les données évoluent, de nouveaux documents arrivent, des anciens deviennent obsolètes. Le pipeline de nettoyage doit être conçu comme un processus continu, orchestré et monitorable, à l’image de n’importe quelle infrastructure de données critique ^[1].

Choisir sa stratégie de chunking : du découpage fixe au découpage sémantique

Ce que le chunking cherche à résoudre

Le chunking découpe de longs documents en fragments plus petits. Chaque fragment est converti en vecteur d’embedding pour stockage dans une base vectorielle et pour une recherche sémantique rapide ^[4]. Le chunking fonctionne au mieux lorsque chaque fragment contient exactement une information et peut être compris de manière indépendante ^[4].

Les quatre stratégies principales

Stratégie	Principe	Forces	Faiblesses	Cas d’usage idéal
Fixed-size	Découpage à taille prédéfinie (caractères, mots ou tokens)	Simple, rapide, aucun appel d’embedding pendant le splitting [6]	Coupe au milieu des phrases, ignore la structure sémantique	Prototype rapide, baseline fiable [6]
Recursive	Hiérarchie de délimiteurs (paragraphes → phrases → sous-phrases)	Préserve la cohérence sémantique en respectant la structure humaine du texte [4]	Nécessite un réglage de la taille et des séparateurs	Documents avec structure en paragraphes, RAG généraliste [4]
Document-structure	Utilise la structure explicite du document (titres Markdown ##, ###…)	Préserve l’organisation logique du contenu [1]	Dépend de la qualité du balisage source	Documents Markdown, fichiers structurés [1]
Semantic	Segmentation basée sur la similarité sémantique, clustering de phrases par sujet	Chaque chunk couvre un sujet naturellement borné [6]	Plus coûteux (appels d’embedding pendant le découpage)	Corpus thématiques, documents multi-sujets [6]

Le chunking récursif en détail

L’approche récursive utilise une hiérarchie de délimiteurs pour fractionner progressivement le texte en unités plus petites : paragraphes d’abord, puis phrases, puis sous-phrases ^[1]. L’implémentation de référence est le RecursiveCharacterTextSplitter de LangChain ^[1]. Lorsqu’un chunk atteint sa taille limite, le splitter utilise le séparateur de plus haute priorité disponible ^[4].

Cette approche fonctionne parce qu’elle respecte la façon dont les humains structurent le texte, qu’elle garde les phrases liées dans le même chunk et qu’elle réduit les coupures en milieu de phrase qui détériorent le sens ^[4]. C’est le choix par défaut recommandé lorsque le format du document est inconnu ^[4].

Le chunking sémantique : la frontière

Le chunking sémantique va plus loin en segmentant le texte sur la base de la similarité sémantique, par exemple en regroupant les phrases par sujet ^[1]. Contrairement au découpage fixe, les frontières des chunks s’alignent sur les changements de thème plutôt que sur un nombre arbitraire de tokens ^[6].

La comparaison visuelle entre les deux approches est éclairante : avec un découpage fixe, les lignes de coupe tombent en plein milieu de régions thématiques ; avec un découpage sémantique, chaque chunk est d’une seule couleur, couvrant un sujet unique ^[6].

La proposition chunking : l’extrême granularité

À l’autre bout du spectre, la proposition chunking décompose chaque chunk en propositions individuelles : des énoncés atomiques et autonomes qui expriment chacun exactement un fait ^[6]. Une proposition a cinq propriétés : elle exprime un fait unique, elle est compréhensible sans contexte environnant, elle utilise des noms complets au lieu de pronoms, elle inclut les dates et qualificatifs pertinents, et elle contient un seul sujet ^[6].

L’analogie parlante : un paragraphe de manuel scolaire versus une pile de fiches flash créées à partir de ce paragraphe. Le paragraphe tisse les idées ensemble. Les fiches isolent chaque fait. Quand on cherche dans les fiches, on trouve exactement le fait recherché ^[6]. Cette approche maximise la précision du retrieval mais augmente significativement le nombre de chunks et donc le coût d’embedding et de stockage.

Préserver le contexte : overlap, métadonnées et structure hiérarchique

L’overlap, amortisseur entre les chunks

Un chunk isolé perd souvent le fil de ce qui le précède et le suit. L’overlap (chevauchement) entre chunks consécutifs permet de mitiger cet effet de bord ^[6]. Dans le chunking fixe, par exemple, une zone de chevauchement adoucit les effets de bord des frontières ^[6]. L’idée est simple : les dernières phrases d’un chunk sont répétées au début du suivant, créant une continuité informationnelle.

Le réglage de l’overlap est un arbitrage : trop faible, et les chunks deviennent des îlots déconnectés ; trop élevé, et l’on gonfle inutilement le volume de données à indexer. Un chevauchement modéré (quelques phrases ou un pourcentage raisonnable de la taille du chunk) constitue un bon point de départ, à affiner selon la nature du corpus.

Les métadonnées : le ciment du retrieval

L’étape de collecte des métadonnées stocke les numéros de page, la source et l’auteur de chaque chunk ^[4]. Ces métadonnées ne participent pas directement au chunking mais conditionnent la qualité du retrieval :

• Numéro de page : permet de reconstituer le contexte documentaire d’origine et de fournir des citations précises à l’utilisateur.
• Source : identifie le document d’origine, essentiel pour l’attribution et la vérification.
• Niveaux hiérarchiques (titres, sections) : dans le chunking structurel, conserver les métadonnées de hiérarchie (niveau 1, niveau 2, etc.) permet au système de retrieval de comprendre la position d’un chunk dans l’architecture globale du document.

Un chunk enrichi de métadonnées se transforme d’un simple fragment de texte en une unité informationnelle contextualisée, beaucoup plus exploitable lors de la recherche sémantique.

La structure documentaire comme guide

Le chunking structurel exploite la hiérarchie des documents pour produire des fragments cohérents. Un document Markdown peut être segmenté hiérarchiquement sur la base des niveaux de titres (par exemple, # → ## → ###), préservant ainsi l’organisation logique du contenu ^[1]. Cette approche est particulièrement efficace lorsque les documents sources sont bien structurés (documentation technique, contrats, rapports réglementaires). Elle échoue en revanche face à des documents plats ou mal formatés, où le fallback vers le chunking récursif reste la meilleure option.

Le stockage vectoriel comme aboutissement

Une fois les chunks découpés, enrichis de métadonnées et encodés en vecteurs d’embedding, ils sont stockés dans une base vectorielle (Milvus, QDrant, Weaviate, Pinecone, ou la fonctionnalité vectorielle d’une base existante comme Snowflake ou MongoDB) ^[1]. La recherche sémantique utilise la similarité cosinus entre le vecteur de la requête utilisateur et les vecteurs stockés pour récupérer les fragments les plus pertinents ^[7][8]. La similarité cosinus calcule un produit scalaire normalisé entre deux vecteurs, retournant une valeur entre -1 et 1, où 1 indique une correspondance parfaite de direction ^[8].

Valider la qualité du pipeline avant de vectoriser

Context precision et context recall

La validation ne peut pas se limiter à un « ça a l’air de marcher » visuel. Deux métriques spécifiques au RAG permettent de mesurer rigoureusement la qualité du système de retrieval ^[8] :

• Context precision : elle évalue le ratio signal/bruit des informations récupérées depuis la base vectorielle. Un score élevé signifie que les chunks renvoyés sont pertinents et que peu de bruit parasite les résultats.
• Context recall : elle mesure si toutes les informations nécessaires pour répondre à la requête utilisateur ont été récupérées. Un score élevé garantit qu’aucun fait crucial n’a été omis.

Ces deux métriques sont complémentaires : un système peut avoir une excellente précision (les chunks renvoyés sont tous pertinents) mais un rappel médiocre (il manque des informations importantes), et inversement ^[8].

Le jeu de vérité terrain

Pour calculer ces métriques, il faut un jeu de données de référence (« Ground Truth ») contenant des paires requête/réponse attendue ^[3]. Ce jeu permet de tester le pipeline end-to-end : on soumet les requêtes au système réel, on récupère les chunks depuis la base vectorielle, puis on compare les résultats aux réponses attendues. L’écosystème RAG adaptatif, par exemple, inclut un composant dédié aux requêtes de retrieval sur le dataset de vérité terrain ^[3].

L’audit par l’expert métier

Les métriques quantitatives ne couvrent pas tout. Sur des corpus spécialisés (juridique, médical, financier), seul un expert du domaine peut juger si un chunk est véritablement informatif, s’il contient une information périmée, ou s’il manque un élément contextuel crucial ^[1]. Cette validation humaine ne remplace pas les métriques automatiques, elle les complète.

Le reranking comme filet de sécurité

Même après un chunking et un nettoyage soigneux, la recherche vectorielle pure peut renvoyer des résultats sous-optimaux. Les modèles d’embedding représentent chaque texte indépendamment, et leur similarité est mesurée a posteriori par des opérations vectorielles ^[1]. Les reranker transformer-based, eux, évaluent la requête et le chunk candidat de manière jointe, permettant l’attention croisée de mieux capturer les relations nuancées, l’alignement contextuel et la pertinence sémantique entre les deux textes ^[1]. Le reranking intervient après la retrieval initiale pour réordonner les résultats selon un score de pertinence plus fin.

Mettre bout à bout : de la donnée brute aux chunks validés

L’ensemble de ces étapes constitue un pipeline cohérent et séquentiel :

Fichiers bruts (PDF, DOCX, PPTX…)
 │
 ▼
┌─────────────────────┐
│ PARSING │ Extraction de texte, nettoyage des artefacts,
│ │ collecte de métadonnées (page, source, auteur)
└─────────┬───────────┘
 ▼
┌─────────────────────┐
│ NETTOYAGE │ Suppression doublons, filtrage versions périmées,
│ │ normalisation, validation expert métier
└─────────┬───────────┘
 ▼
┌─────────────────────┐
│ CHUNKING │ Choix de la stratégie (fixe, récursif, structurel,
│ │ sémantique), réglage overlap, enrichissement metadata
└─────────┬───────────┘
 ▼
┌─────────────────────┐
│ VALIDATION │ Tests sur Ground Truth, métriques context precision
│ │ et recall, audit expert, reranking si nécessaire
└─────────┬───────────┘
 ▼
 Embedding & Indexation
 (base vectorielle)

Chaque étape alimente la suivante. Un parsing médiocre produit des chunks incohérents. Un nettoyage insuffisant injecte du bruit. Un mauvais choix de chunking fragmente ou dilue l’information. Une validation absente laisse passer des erreurs qui ne seront découvertes qu’en production, quand l’utilisateur final recevra des réponses incorrectes.

La clé est de traiter ce pipeline comme une infrastructure de données critique, orchestrée, monitorable et reproductible ^[1], et non comme un script de préparation jetable. C’est ce travail, souvent invisible, qui distingue un prototype fonctionnel d’un système RAG fiable en production.

Besoin d’accompagnement pour construire ou fiabiliser votre pipeline RAG ? Demandez un devis personnalisé.

Sources

• [1] Hands-On RAG for Production · Ofer Mendelevitch and Forrest Sheng Bao
• [2] GenAI on Google Cloud Enterprise Generative AI Systems and Agents
• [3] RAG-Driven Generative AI Build MAS-RAG with DualRAG, GraphRAG, multimodal video pipelines, and Oracle Database 23ai
• [4] RAG with Python Cookbook Practical Recipes from Data Preprocessing to LLM Agents
• [5] The AI Product Playbook Strategies, Skills, and Frameworks for the AI-Driven Product Manager
• [6] RAG Made Simple: The Complete Visual Guide to Retrieval-Augmented Generation · Nir Diamant
• [7] Data Engineering with Generative and Agentic AI on AWS
• [8] Building Generative AI Services with FastAPI A Practical Approach to Developing Context-Rich Generative AI Applications