Docling PDF RAG : découper les tableaux sans perdre leur source

Commencez par la question à laquelle votre tableau PDF doit répondre

Pour une ingestion Docling PDF RAG inspectable, préservez le sens du tableau avec les références à la source. Commencez par inspecter la structure extraite, puis budgétez le texte d'embedding contextualisé, et conservez les références aux éléments du document avec chaque entrée de provenance disponible. Ces emplacements aident un relecteur à inspecter la source. Ils ne constituent pas une preuve automatique d'une citation exacte de cellule.

Une spécification fournisseur hypothétique, pas un cas client

Imaginez une spécification fournisseur avec des noms de composants, des limites de fonctionnement, des unités et des notes conditionnelles. La question de récupération paraît simple en surface : quelle limite de fonctionnement s'applique à ce composant dans les conditions indiquées ?

C'est un exemple hypothétique, pas un récit de client Optijara. Récupérer un nombre plausible ne suffit pas. Le passage récupéré doit contenir la bonne étiquette de ligne, l'en-tête de colonne, l'unité et la condition. Une exportation lisible est un point de départ utile, mais elle ne prouve pas que le fragment porte encore ces relations.

Le périmètre est volontairement étroit : concevoir un enregistrement de fragment de tableau inspectable qui relie le texte d'embedding aux éléments du document et aux emplacements source disponibles. Ce n'est pas un déploiement RAG complet, ni une promesse que les réponses seront correctes. Avant de changer le modèle, vérifiez si l'ingestion a préservé les preuves de tableau nécessaires pour répondre à la question.

Conservez le PDF original et son document structuré

Conservez la révision PDF autorisée à côté de son JSON structuré. DoclingDocument représente les tableaux, la hiérarchie du document, les informations de mise en page lorsqu'elles sont disponibles, et la provenance. Une exportation en texte brut ne remplace pas la conservation du document structuré et de ses références d'éléments.

La conversion de base est déjà couverte dans des ressources comme la note pratique de Simon Willison sur Docling. Ce guide se concentre sur ce qu'il faut préserver entre la conversion et l'indexation. Les procédures et exemples ci-dessous sont des modèles proposés, pas des résultats de tests rapportés.

Inspectez le tableau extrait avant de choisir sa sérialisation

Vérifiez les en-têtes, les cellules, les unités et l'ordre de lecture

Utilisez la spécification hypothétique tout au long de l'exemple : une ligne ordinaire, une ligne avec une longue cellule de conditions, et un tableau qui continue sur une autre page. Comparez le PDF avec l'extraction structurée avant de scinder quoi que ce soit.

Vérifiez si chaque valeur appartient encore à la ligne et à la colonne prévues. Inspectez les en-têtes fusionnés, les unités dans les légendes, les marqueurs de notes de bas de page et l'ordre de lecture. Si l'extraction place une condition sous le mauvais composant, scinder le texte obtenu en fragments plus petits ne corrige pas en soi cette association.

Le chemin de conversion produit un document qui peut être exporté en JSON structuré. Le schéma ci-dessous est du pseudocode, pas une recette d'installation vérifiée. Relevez les versions installées des paquets docling, docling-core et tokenizer avant d'adapter les exemples officiels. Une version affichée sur un site de documentation n'est pas votre version installée.

convertir le PDF autorisé avec DocumentConverter
conserver le DoclingDocument renvoyé
exporter le document structuré au format JSON
stocker le JSON à côté de la révision PDF exacte
inspecter les tableaux extraits par rapport aux pages originales

Choisissez une représentation pour la question de récupération

L'exemple de sérialisation avancée documente MarkdownTableSerializer comme alternative à la représentation de tableau par défaut. Comparez les deux en vous demandant si le composant, la limite et la condition restent compréhensibles. Un joli rendu est secondaire.

Pour le dernier cas, notre guide de récupération visuelle de documents explique le rôle distinct de la récupération fondée sur les pages.

L'exemple avancé traite aussi du parcours du texte OCR imbriqué sous des images. Cette option peut récupérer du contenu qui serait autrement omis, mais elle peut ajouter du bruit. Traitez-la comme un choix à tester, pas comme une règle par défaut pour chaque PDF.

Utilisez HybridChunker et inspectez le texte que vous allez réellement intégrer

Alignez le tokenizer avec la voie d'embedding

Le chemin de chunking natif de Docling opère directement sur DoclingDocument. Exporter d'abord en Markdown est facultatif. HybridChunker affine les fragments hiérarchiques avec un découpage tenant compte des tokens et une fusion des pairs compatibles.

L'exemple de chunking hybride distingue chunk.text de chunker.contextualize(chunk). Conservez les deux. Dans cette conception, la chaîne contextualisée est la charge utile d'embedding. La chaîne brute reste utile pour inspecter ce que contient le fragment avant l'ajout de contexte.

Alignez le tokenizer avec le modèle d'embedding prévu, puis inspectez la charge utile sérialisée exacte. Compter uniquement le texte brut ignore le contexte ajouté ensuite. Tenez aussi compte des préfixes ou enveloppes introduits par votre intégration d'embeddings.

Conservez les en-têtes de tableau sans supposer que chaque ligne tient

La documentation de chunking étudiée indique repeat_table_header=True et omit_header_on_overflow=False comme valeurs par défaut. Ce sont des paramètres documentés, pas des valeurs par défaut vérifiées ici sur un paquet installé. Vérifiez l'API de votre version avant de les configurer.

Les en-têtes répétés aident un tableau scindé à conserver son contexte, mais les en-têtes consomment aussi de l'espace. Dans la spécification hypothétique, une longue cellule de conditions peut rendre une ligne difficile à faire tenir sans perte de sens. Inspectez la sortie contextualisée de cette ligne au lieu de supposer que le budget configuré garantit son acceptation par votre point de terminaison d'embedding.

L'exemple avancé officiel affiche des sorties contextualisées au-dessus du réglage de tokens qu'il montre. C'est une raison d'inspecter votre propre charge utile. Ce n'est pas la preuve d'un bug diagnostiqué de la bibliothèque ni d'un comportement de débordement universel.

Ne tronquez pas silencieusement une condition pour faire tenir la requête. Signalez-la pour une autre représentation ou pour une revue explicite. Séparez aussi deux problèmes qui sont souvent mélangés : scinder un tableau déjà détecté et joindre des fragments de pages séparés. La répétition des en-têtes ne prouve pas la continuité.

Construisez un enregistrement de fragment qui porte ses références de source

Gardez l'identité du document à côté des deux représentations textuelles

Utilisez un enregistrement détenu par l'application pour relier la charge utile d'embedding à sa source. Les noms de champs ci-dessous sont une conception proposée, pas un schéma intégré de Docling.

document_id identifie la source dans votre application. source_version identifie la révision conservée. chunk_id distingue la sortie d'ingestion particulière. Stockez chunk_text et embedding_text séparément, ainsi que serialization_settings et tokenizer_revision.

Ne réutilisez pas une ancienne identité de fragment après un changement de sérialiseur ou de révision source. Relevez aussi les paramètres de chunking et la révision du modèle d'embedding dans votre manifeste d'ingestion. Sinon, un opérateur ultérieur ne pourra pas savoir si un comportement de récupération différent vient d'un changement de document ou d'un changement de représentation.

Ce JSON illustratif décrit le contrat d'enregistrement visé. Les valeurs null sont des espaces réservés, pas des valeurs source observées ni un enregistrement prêt pour l'indexation.

{
  "document_id": null,
  "source_version": null,
  "chunk_id": null,
  "chunk_text": null,
  "embedding_text": null,
  "doc_item_refs": [],
  "item_provenance": [],
  "serialization_settings": {},
  "tokenizer_revision": null,
  "review_status": "not_checked"
}

Conservez chaque entrée de provenance d'élément disponible

L'exemple avancé expose les éléments contributeurs via chunk.meta.doc_items. La référence du document décrit les références d'éléments et les champs de provenance, notamment page_no, bbox et charspan. Préservez l'association entre chaque référence d'élément et ses entrées de provenance.

Une procédure proposée de construction d'enregistrement est :

pour chaque chunk renvoyé par le chunker natif configuré:
    conserver chunk.text comme chunk_text
    conserver chunker.contextualize(chunk) comme embedding_text
    pour chaque item dans chunk.meta.doc_items:
        conserver le self_ref de l'item
        conserver chaque entrée disponible dans la liste prov de l'item
        associer chaque entrée à ce self_ref
        marquer explicitement la provenance manquante
    joindre l'identité du document, la révision et les paramètres d'ingestion
    valider les références par rapport au document structuré conservé

Évitez de sélectionner seulement prov[0]. Conservez tous les emplacements disponibles pour chaque élément pertinent. Une liste de provenance vide doit rester une condition explicite d'emplacement manquant, pas devenir une référence de page fabriquée.

Résolvez chaque self_ref par rapport au document structuré exact conservé, pas par rapport à la dernière conversion d'un fichier au nom similaire. Préservez les conventions de coordonnées des boîtes englobantes lorsque vous transmettez les emplacements à un visualiseur.

Il existe une limite de précision. Un élément de tableau référencé peut couvrir plus de contenu que le fragment scindé actuel. Son emplacement n'isole pas automatiquement la cellule qui étaye une réponse. Préserver la provenance rend l'inspection possible ; cela n'établit pas que la récupération a sélectionné la bonne condition ni que la génération l'a utilisée correctement.

Traitez explicitement les continuations de page et les citations ambiguës

Un tableau continué exige plus qu'un en-tête répété

Revenez à la page de continuation de la spécification hypothétique. Comparez les en-têtes, les unités, l'identité du composant et les notes de bas de page. Vérifiez si la première ligne visible est nouvelle ou si elle continue une cellule de conditions de la page précédente.

La discussion 704 documente des praticiens aux prises avec des tableaux qui s'étendent sur plusieurs pages et des lignes continuées. C'est la preuve d'un problème pratique, pas une preuve faisant autorité qu'une version actuelle manque toujours de prise en charge multipage.

Si vous ajoutez une jonction propre à l'application, conservez les fragments originaux et leurs références à côté du tableau dérivé. Relevez la règle de jonction et laissez visible la continuité non résolue. La simple correspondance des noms de colonnes ne doit pas autoriser une fusion silencieuse.

Une valeur correspondante n'est pas une citation exacte

Supposons que la même valeur courte apparaisse dans plusieurs cellules. Une correspondance de chaîne n'identifie pas le composant et la condition qui étayent la réponse. Avant de surligner une cellule, exigez un alignement vérifié entre la réponse, la ligne et la colonne pertinentes, et l'emplacement source.

La discussion 4321 soulève ce problème de granularité. Ses interfaces cite_sources et confidence_scores sont des propositions, pas des API livrées et vérifiées à copier dans une implémentation.

Lorsque seules des preuves au niveau de l'élément sont disponibles, qualifiez honnêtement la référence de référence de tableau ou de page. Gardez l'ambiguïté visible, ou orientez la question vers une revue, au lieu de présenter un surlignage d'apparence précise sans appui.

Erreurs courantes et limites opérationnelles

Ne confondez pas les notes de confiance avec des cellules de tableau correctes

Les erreurs courantes ont des corrections concrètes :

• Créer des embeddings de lignes isolées : inspectez les étiquettes, les en-têtes, les unités et les conditions dans la charge utile finale.
• Compter seulement chunk.text : tokenisez le texte contextualisé réellement soumis.
• Écarter les références ou ne conserver que la première entrée de provenance : préservez les associations d'éléments et chaque emplacement disponible.
• Joindre silencieusement les continuations : conservez les fragments et documentez la décision de continuité.
• Prendre une boîte source pour une preuve : séparez l'exactitude de l'emplacement de la justesse de la réponse.

La documentation de confiance étudiée recommande mean_grade et low_grade plutôt que les scores numériques internes, et marque table_score comme non implémenté. N'inventez pas de seuil de confiance de tableau et ne traitez pas une note de document comme la certification d'une cellule particulière.

Le traitement local exige tout de même une planification de la confidentialité et des ressources

Les options avancées de Docling documentent le mode TableFormer et les contrôles de correspondance de cellules. Examinez-les lorsque l'extraction est mauvaise, mais ne supposez pas que le réglage garantit une réparation. Les tentatives de conversion supplémentaires et l'inspection manuelle ont des coûts d'implémentation et de ressources.

Le traitement local, les téléchargements initiaux de modèles et les services distants explicitement activés sont des sujets distincts. Préchargez les modèles requis et vérifiez la configuration avant d'attendre un fonctionnement hors ligne. Les embeddings, le stockage et les journaux nécessitent leur propre revue de traitement des données. Un convertisseur local ne rend pas toute l'application locale uniquement.

Appliquez les permissions de source aux PDF conservés, au texte extrait et aux enregistrements de fragments. Vérifiez les contrôles d'accès avant d'indexer des conditions ou des notes sensibles. Fixez des limites de ressources par document, relevez les révisions des paquets et des modèles, et décidez comment les versions source remplacées seront retirées sans rendre les citations existantes insolubles.

Avant l'indexation : une liste de vérification pratique

Comparez les représentations sur le même PDF autorisé

Ce qui suit est une procédure proposée, non exécutée. Comparez la sérialisation de tableau par défaut et Markdown sur le même PDF autorisé et la même question de récupération. Incluez des lignes ordinaires, des lignes surdimensionnées et des continuations de page. Relevez les observations au lieu de supposer un gagnant.

Gardez fixes la révision du document, les questions et les règles de revue pendant cette comparaison. Notre guide de documentation des protocoles d'évaluation explique pourquoi les résultats ont besoin de leurs conditions de test, pas seulement d'un score.

Décidez ce qui est prêt et ce qui nécessite encore une revue

Si l'extraction est mauvaise, revenez à la conversion. Si le contexte manque, revenez à la sérialisation ou au chunking. Si les preuves sont ambiguës, préservez cette incertitude au lieu d'émettre une citation plus précise.

Un enregistrement valide n'est pas nécessairement un résultat de récupération pertinent. Notre guide du rappel, de la pertinence et de la justesse des réponses explique pourquoi ces résultats doivent être évalués séparément.

Avant l'indexation, vous devriez pouvoir ouvrir la révision conservée, résoudre les références d'éléments du fragment et inspecter le texte d'embedding exact. Cela donne à l'étape suivante quelque chose de concret à évaluer, y compris un compte rendu clair de ce que les emplacements source ne prouvent pas.