Préparer des PDF pour les LLM et les pipelines de recherche

Pourquoi ne pas se contenter d'extraire le texte brut

Toute bibliothèque PDF vous donnera le texte d'un document en deux lignes de code, et pour une note de service à une colonne cela suffit vraiment. Pour tout le reste, non, pour trois raisons qui coûtent toutes de la qualité de recherche.

Premièrement, l'ordre de lecture. L'extraction brute renvoie le texte dans l'ordre où les glyphes ont été tracés, ce qui entrelace les colonnes sur une page à deux colonnes. La moitié de vos chunks deviennent des fragments de phrases alternant entre des paragraphes sans rapport, et ils s'incorporent à un point de l'espace vectoriel qui ne correspond à rien.

Deuxièmement, les limites. Sans titres, il n'y a rien sur quoi découper sinon le nombre de caractères ; les chunks se coupent donc en plein milieu d'une phrase et d'un tableau, et un chunk qui commence au milieu d'une explication ne se comprend pas isolément — ce qui est précisément ce qu'un chunk retrouvé doit faire.

Troisièmement, les tableaux. Extrait en texte brut, un tableau devient un flot de nombres sans aucune indication de la colonne d'origine. Un modèle qui lit cela répondra quand même à votre question. La réponse sera simplement fausse.

Ce que Markdown apporte au pipeline

Markdown est ici un bon format intermédiaire pour des raisons qui n'ont rien à voir avec son élégance.

• Les titres donnent des limites de chunk sémantiques : un chunk est une section plutôt qu'une fenêtre de mille caractères.
• Le chemin de titres donne son contexte à chaque chunk — vous pouvez préfixer « Chapitre 3 › Limites de débit › Comportement en rafale » avant l'incorporation, ce qui améliore mesurablement la recherche sur les documents où le même mot n'a pas le même sens selon la section.
• Les tableaux GFM gardent les lignes et les colonnes associées, si bien qu'un modèle lisant un tableau retrouvé sait quel chiffre appartient à quel intitulé.
• C'est compact. Markdown porte la structure au prix de quelques caractères par élément, là où HTML ou les formats JSON de mise en page dépensent des tokens en balisage qui n'apprend rien au modèle.
• C'est un format dont tous les modèles actuels ont vu des quantités énormes à l'entraînement : il n'a donc besoin d'aucune explication dans le prompt.

Le découpage, concrètement

L'approche qui marche sur des documents convertis est de découper d'abord sur les titres et de ne recourir aux limites de taille qu'à l'intérieur d'une section trop grande.

Des paramètres approximatifs qui tiennent sur la plupart des types de documents :

Ne coupez jamais un tableau

C'est la règle que la plupart des pipelines enfreignent, parce qu'un découpeur naïf n'a aucune idée qu'il se trouve à l'intérieur d'un tableau.

Un tableau GFM coupé en son milieu produit deux chunks dont aucun n'est un tableau valide : le premier a un en-tête et quelques rangées, le second a des rangées sans aucun en-tête. Le second est pire qu'inutile, car ses nombres ne portent pas d'étiquette et un modèle leur en attribuera une en devinant.

Détectez les blocs de tableau avant le découpage et gardez chacun intact, même si cela donne un chunk au-dessus de la taille visée. Si un tableau est vraiment trop grand pour un chunk, répétez la rangée d'en-tête dans chaque morceau.

Où se placent les documents numérisés

Une numérisation n'a pas de texte : il n'y a donc rien à découper. La reconnaissance de texte doit intervenir d'abord — et sa sortie a des propriétés dont un pipeline doit tenir compte, parce que la reconnaissance est une estimation plutôt qu'une transcription.

Deux en particulier. La confiance varie selon la page : un document peut être quasi parfait sur quarante pages et douteux sur trois ; si votre étape de reconnaissance rapporte une confiance par page, reportez-la dans les métadonnées du chunk pour pouvoir signaler une réponse peu fiable. Et les mots illisibles sont abandonnés plutôt que marqués, ce qui veut dire que le texte paraît fluide et complet tout en omettant exactement les éléments qui ont le plus résisté au moteur — souvent des noms, des références et des chiffres.

Pour tout ce dont une erreur a des conséquences, un texte reconnu doit être traité comme une piste à vérifier contre l'original, pas comme une source de référence.

Que vérifier avant d'indexer un corpus

L'indexation est l'étape coûteuse, lente et difficile à défaire : il vaut donc la peine de passer vingt minutes sur un échantillon d'abord. Convertissez cinq documents choisis pour être différents les uns des autres, et lisez le Markdown.

• Les titres forment-ils une échelle sensée ? S'ils sont plats, votre découpeur n'a rien sur quoi couper et vous retomberez sur des fenêtres de taille fixe pour tout le corpus.
• Les tableaux ont-ils survécu ? Comptez les colonnes par rapport à l'original sur deux ou trois d'entre eux.
• L'ordre de lecture est-il correct sur les pages à plusieurs colonnes ? Des colonnes entrelacées sautent aux yeux quand on regarde et deviennent invisibles une fois indexées.
• Y a-t-il des conversions vides ou presque ? Ce sont des numérisations, et elles demandent un autre chemin.
• Le même texte type se répète-t-il dans tous les documents ? Les en-têtes et pieds répétés deviennent des chunks quasi identiques qui évincent le vrai contenu des résultats.

La dimension confidentialité, qui n'est pas accessoire

Les corpus RAG sont bâtis précisément sur les documents que les organisations sont le moins disposées à confier à un tiers : contrats, rapports internes, dossiers clients, recherches non encore publiées.

Il vaut la peine d'être délibéré sur les étapes de votre pipeline qui envoient ces documents quelque part. La conversion n'a pas à en faire partie : un convertisseur qui tourne dans le navigateur traite le fichier sur la machine où il se trouve déjà, si bien que l'étape de conversion n'ajoute aucune partie à la chaîne. Que les étapes suivantes le fassent est une décision distincte — mais c'est une décision que vous pouvez prendre séparément.