Préparer ses documents pour un pipeline RAG : Markdown et JSON propres

Un pipeline RAG (retrieval-augmented generation) ne vaut que ce que valent ses documents d'entrée. Si vous ingérez des fichiers bruts, hétérogènes et pleins de bruit de mise en page, vous récupérez des chunks incohérents et des réponses approximatives. Préparer ses documents pour un pipeline RAG commence donc par une étape simple mais décisive : normaliser n'importe quel format en Markdown et JSON propres, avant même de parler de chunking ou d'embeddings.

Pourquoi un document brut casse un pipeline RAG

Un PDF, un Word et une page web ne se ressemblent pas sous le capot. L'un porte une mise en page en colonnes, l'autre un balisage XML, le troisième des balises HTML et des scripts. Quand vous les découpez en chunks sans les avoir nettoyés, plusieurs problèmes apparaissent :

• Des chunks coupés au mauvais endroit, parce que la structure du fichier ne correspond pas à la structure du contenu.
• Du bruit embarqué dans les embeddings : en-têtes, pieds de page, artefacts, qui diluent le signal.
• Des formats traités différemment, donc des résultats de recherche non comparables d'un document à l'autre.

Le modèle final n'y peut rien : il travaille sur ce qu'on lui donne. La qualité se joue en amont, à l'entrée du pipeline.

Normaliser n'importe quel format en une seule sortie

L'idée centrale est la normalisation : quelle que soit la source, on vise une sortie unique, propre et stable. C'est ce que fait un convertisseur comme Sygal, qui transforme 29 types de fichiers en Markdown lisible et en JSON structuré, en s'appuyant sur MarkItDown pour la conversion locale.

L'intérêt n'est pas d'économiser des tokens partout, ce serait faux pour un Word déjà structuré. L'intérêt est d'obtenir le même format de sortie pour tout votre corpus : un PDF, une note Word et un export de tableur ressortent dans la même forme, prête à découper et à indexer. Vous écrivez votre logique de chunking une fois, pas une par format.

Markdown ou JSON : lequel pour votre pipeline ?

Les deux sorties répondent à des besoins différents, et beaucoup de pipelines utilisent les deux.

Le Markdown conserve la structure de lecture : titres, listes, tableaux, hiérarchie. C'est idéal pour un découpage sémantique en chunks, parce que les titres marquent des frontières naturelles, et pour donner au modèle un contexte lisible.

Le JSON structuré expose des champs exploitables par du code : blocs identifiés, tableaux transformés en données, métadonnées. C'est ce qu'il vous faut quand votre pipeline a besoin de champs stables à parser plutôt que de texte libre, par exemple pour rattacher chaque chunk à sa source ou pour traiter des tableaux comme des données.

Une règle simple : le Markdown pour le contenu à découper et à embedder, le JSON pour la structure et les métadonnées que votre code doit lire.

Un exemple concret : un tableau de prix dans un PDF. En Markdown, il ressort sous forme de tableau lisible, parfait pour donner du contexte à un modèle. En JSON, les mêmes lignes deviennent des données, où chaque colonne est un champ que votre code peut lire et comparer. Le même contenu, deux usages : l'un pour la génération, l'autre pour le traitement.

Garder une sortie cohérente sur un corpus hétérogène

Un vrai corpus mélange les formats et les sources. La cohérence de sortie est ce qui rend le pipeline maintenable. Concrètement, cela veut dire :

• Une conversion par lot qui traite un dossier entier et produit du .md et du .json pour chaque fichier.
• Un même schéma de sortie, quel que soit le format d'entrée.
• Des reprises simples quand un fichier échoue, sans casser tout le lot.

En ligne de commande, cette étape s'automatise dans un script ou un orchestrateur d'agents. Sygal CLI expose le même moteur de conversion que l'application, avec une sortie JSON stricte et des codes d'erreur stables, pensés pour être branchés dans un pipeline sans surprise.

Découper proprement : quelques repères sur le chunking

Une fois vos documents normalisés en Markdown, le découpage en chunks devient beaucoup plus simple, parce que la structure est explicite. Quelques repères qui évitent les erreurs les plus courantes :

• Découpez sur les titres. Les H2 et H3 du Markdown marquent des frontières sémantiques naturelles. Un chunk qui commence et finit sur une section reste cohérent, contrairement à un découpage à l'aveugle tous les N caractères, qui coupe souvent une phrase ou une idée en plein milieu.
• Gardez les tableaux entiers. Un tableau coupé en deux perd son sens. Le JSON structuré aide ici : il isole le tableau comme un bloc que vous pouvez traiter à part, sans le laisser se faire découper au hasard.
• Rattachez chaque chunk à sa source. Le nom du fichier, la page, la section : ces métadonnées, portées par le JSON, permettent de citer la source dans la réponse et de remonter au document d'origine quand un utilisateur le demande.
• Restez cohérent sur tout le corpus. La même stratégie de découpage doit s'appliquer partout. C'est justement ce que permet une sortie normalisée : vous réglez le chunking une fois, pas un traitement par format.

Aucune de ces règles n'est propre à un outil. Elles deviennent simplement applicables dès que l'entrée est propre et uniforme, ce qui ramène toujours au même point : la qualité d'un pipeline RAG se joue à la conversion, avant l'indexation.

Faut-il tout traiter dans le cloud ?

Non, et c'est souvent un point bloquant pour les données d'entreprise. La conversion des documents texte se fait entièrement en local : vos fichiers ne sont pas téléversés. Seuls deux gestes touchent le réseau, et seulement si vous les déclenchez : l'OCR d'une image, envoyée au fournisseur que vous choisissez avec votre clé, et l'import d'une URL. Pour un corpus de documents sensibles, cette frontière change tout, un sujet que nous détaillons dans le guide sur la conversion sans cloud.

En résumé

Un pipeline RAG solide commence par des entrées propres. Normalisez d'abord, indexez ensuite : convertissez chaque source en Markdown et JSON cohérents, gardez la même sortie pour tout le corpus, et laissez le réseau en dehors de l'équation autant que possible. Vous pouvez tester la conversion sur vos propres documents avec l'essai gratuit, ou l'intégrer directement à vos scripts via le CLI.