
RAG, le premier véritable goulot d'étranglement: le parsing
Cet article explore pourquoi le parsing de documents est le premier véritable goulot d'étranglement dans la plupart des systèmes RAG. Il détaille comment un parsing défaillant corrompt l'ensemble du pipeline de retrieval, du chunking à l'embedding en passant par la génération, et compare trois approches principales : le parsing textuel, le parsing avec reconnaissance de mise en page et les Vision Language Models.
Publié le 22 mars 2026
Le pouvoir caché du parsing dans les systèmes RAG
Chez UBIK, nous construisons des systèmes d'IA depuis plusieurs années, et il y a quelque chose que la conversation autour du RAG continue de rater. Tout le monde est obsédé par les embeddings, les bases de données vectorielles et les derniers modèles, mais après avoir creusé dans les goulots d'étranglement du RAG, nous avons constaté que la plupart des gens passent à côté de quelque chose de plus fondamental. La plupart des implémentations RAG échouent avant même d'arriver à la phase de retrieval. Elles cassent au niveau du parsing, c'est-à-dire le processus d'extraction du sens structuré à partir des documents. Et parce que le RAG est un pipeline séquentiel, un parsing défaillant pénalise tout ce qui suit. Le problème ne se résume pas à extraire du texte depuis un fichier. Il s'agit de préserver la structure, le contexte et les relations qui donnent leur sens aux informations, autant pour la compréhension que pour la recherche. Un PDF complexe avec des tableaux, des mises en page multi-colonnes et des images intégrées ne peut pas simplement être exploité dans une base de données vectorielle. Pourtant, des entreprises passent des mois à affiner leurs embeddings et à optimiser leur recherche vectorielle, pour finalement découvrir que leur parsing était inefficace depuis le début : des tableaux réduits à des flux incohérents, des relations entre sections perdues, du contexte critique dispersé dans des chunks déconnectés. Les conséquences s'enchaînent vite. Le retrieval ne remonte pas les bonnes informations. Un contexte incomplet déclenche des hallucinations. Votre modèle de langage finit par expliquer avec assurance des choses qui ne sont pas vraies, non pas à cause du modèle, mais à cause d'une entrée dégradée qui ne ressemble plus au document original. Dans cet article, nous allons examiner pourquoi le parsing est devenu le principal goulot d'étranglement des systèmes RAG, et comment bien le gérer peut transformer une expérimentation frustrante en quelque chose qui fonctionne réellement à l'échelle.

Décoder le parsing : la base des systèmes RAG
Que signifie concrètement le parsing ? Le parsing de documents est le processus de conversion de documents complexes et non structurés en représentations propres et structurées qui préservent non seulement le contenu, mais aussi le contexte et les relations. Quand vous lisez un article de recherche, vous comprenez instinctivement qu'un titre diffère d'un résumé, qu'une note de bas de page est liée à un contenu spécifique au-dessus, et qu'un tableau est un tableau. Le parsing doit recréer cette compréhension structurelle pour les machines. La plupart des systèmes n'y parviennent pas. Au lieu de préserver la structure, ils la détruisent. Prenez un manuel technique avec des procédures structurées, des sections croisées et des tableaux formatés. Un parser naïf le transforme en fragments de texte déconnectés : un tableau de sécurité critique devient quelque chose comme "Avertissement 150 Température Maximum Celsius Arrêt Critique", les références croisées disparaissent, et les annotations de diagrammes se retrouvent dispersées aléatoirement. Le sens du document est perdu avant même que l'IA ne le voie. Les PDFs rendent cela particulièrement complexes. Ils sont fondamentalement hostiles aux systèmes RAG ; leur structure interne correspond rarement à l'ordre de lecture logique. Ce qui rend un mauvais parsing si dommageable, c'est la profondeur à laquelle il atteint le pipeline. Le chunking dépend de la capacité du parser à distinguer les titres du corps du texte ; si vous ratez ça, vos chunks sont des morceaux sans signification. La génération d'embeddings nécessite un texte cohérent et contextuellement riche, fournissez-lui une sortie incohérente, et vos vecteurs encodent du bruit. Le retrieval dépend du regroupement de contenus sémantiquement liés, mais si le parsing les a dispersés dans des chunks aléatoires, la recherche par similarité risque de ne pas bien fonctionner.
Explorer les méthodes de parsing
Quelles sont les options ? Les approches de parsing varient considérablement dans leur façon de gérer la complexité des documents, et le choix a un impact direct sur tout ce qui suit.
Parsing textuel
Le parsing textuel est le point de départ le plus courant. Plutôt que d'utiliser l'OCR, il travaille directement à partir des octets bruts du document, extrayant le texte encodé dans le fichier lui-même. C'est rapide et peu coûteux, et sur des documents propres et bien structurés, ça fonctionne bien. Le problème, c'est que la plupart des documents réels ne sont pas propres. Les informations de mise en page vivent en dehors du texte encodé en octets, tableaux, colonnes, ordre de lecture, relations spatiales, et les parsers textuels les ignorent tous. Vous obtenez du contenu, mais sans la structure qui lui donne son sens.
Parsing avec reconnaissance de mise en page
Le parsing avec reconnaissance de mise en page adopte une approche plus sophistiquée, combinant l'OCR avec des modèles de vision dans un pipeline multi-étapes. La première étape utilise des modèles de vision pour détecter et classifier les régions du document, distinguer les titres du corps du texte, identifier les limites des tableaux, localiser les figures. L'OCR extrait ensuite le texte dans chaque région détectée, et une étape finale réassemble tout en une représentation structurée qui préserve les relations spatiales. C'est significativement plus coûteux et plus lent, mais pour les documents complexes, manuels techniques, rapports financiers, tout ce qui contient des tableaux ou des mises en page multi-colonnes, la différence de qualité de sortie est dramatique. Cette méthode produit également des bounding boxes précises par région de contenu, ce qui permet une représentation plus riche du document et rend possible la traçabilité de l'information jusqu'à son emplacement exact dans la source.
Modèles de langage visuels (VLM)
Les modèles de langage visuels représentent un paradigme entièrement différent. Au lieu d'un pipeline qui extrait et reconstruit, les VLMs traitent le document comme un objet visuel, comme un humain le ferait, en gérant texte, mise en page et graphiques en une seule passe unifiée. Ils peuvent interpréter des légendes de graphiques, des diagrammes annotés et du contenu dépendant de la mise en page qui mettrait en échec toute approche basée sur l'extraction. La contrepartie est le coût, la latence et la précision : les VLM sont coûteux en calcul, et à grande échelle, ça s'accumule vite, ils sont également assujettis aux hallucinations et aux sorties imprécises en raison de la diversité de ce qu'ils peuvent prédire par rapport aux modèles OCR.
Parsers spécialisés
Il convient également de noter que tout le contenu n'est pas un PDF ou un document Word. Les fichiers de code, l'audio (MP3) et la vidéo (MP4) nécessitent chacun leur propre couche de parsing spécialisée, des parsers AST pour le code afin de préserver la structure et la syntaxe, des pipelines de transcription audio pour l'audio, et une extraction de frames combinée à la transcription pour la vidéo. Ces types de fichiers ne s'inscrivent pas dans le spectre des pipelines de parsing du texte. En pratique, le choix n'est pas toujours l'un ou l'autre. De nombreuses équipes convergent vers des stratégies hybrides, des mises en page ou des VLM pour les documents complexes et à forte valeur où la précision est critique, et des approches plus légères pour le contenu simple où la vitesse et le coût comptent davantage.
Choisir la bonne stratégie
Catégorisez vos documents avant de choisir une approche de parsing. La répartition est approximativement la suivante : les documents simples à forte densité de texte se prêtent au parsing traditionnel ou spécialisé, les documents complexes dépendant de la mise en page ont besoin d'une approche avec reconnaissance de mise en page ou VLM, et la plupart des collections de documents réels sont suffisamment mixtes pour justifier une stratégie hybride.
À petite échelle, vous pouvez vous permettre d'être généreux avec les méthodes coûteuses. Avec des centaines de milliers de documents, vous avez besoin d'un routage plus intelligent. Ne construisez pas votre preuve de concept autour des VLMs pour tout et supposez que le coût sera gérable en production, ce n'est généralement pas le cas.
Connaissez vos modes d'échec. Le parsing traditionnel échoue de manière prévisible sur les éléments visuels et les mises en page complexes. Les VLMs échouent différemment, avec plus de risques d'hallucination mais une meilleure compréhension contextuelle. Aucun mode d'échec n'est acceptable si vous n'en tenez pas compte.
Et intégrez de la flexibilité dès le départ. La bonne stratégie de parsing aujourd'hui ne sera pas la bonne quand votre volume de documents doublera ou que vos cas d'usage s'élargiront. Traitez-la comme une décision continue, pas une configuration ponctuelle.
C'est exactement le problème qu'UBIK cherche à résoudre. Plutôt que de forcer les équipes à devenir des experts en parsing ou à maintenir plusieurs pipelines spécialisés, la plateforme gère le routage des documents automatiquement, classifiant chaque document à l'ingestion et l'envoyant dans le pipeline approprié. Les documents textuels simples passent par un parsing rapide et léger. Les mises en page complexes avec tableaux et visuels intégrés reçoivent le traitement avec reconnaissance de mise en page. Les documents très visuels ou imprévisibles sont routés vers les VLM. Et la plateforme supporte même l'hébergement autonome de votre parser, selon les exigences de confidentialité. Vous pouvez explorer comment UBIK gère tout cela de bout en bout dans notre documentation.