Pipeline RAG pour PDF : révolution dans l'analyse documentaire

Pipeline RAG pour PDF : révolution dans l'analyse documentaire

Large Language Models

Un pipeline RAG de production pour les PDF : parsing relationnel, récupération de la table des matières (TOC), réponses typées.

Ce document fait partie de la série Enterprise Document Intelligence qui construit un système RAG d'entreprise à partir de quatre briques : document parsing, question parsing, retrieval, et generation.

C'est la première des deux parties sur le pipeline amélioré : cette partie améliore chaque brique, un contrat à la fois, sur le même document et la même question que l'Article 1 (RAG minimal). La deuxième partie, qui composera les quatre briques RAG en un seul pipeline, sera testée sur des documents réels.

Où se situe cet article dans la série

Cet article est l'Article 9 (le pipeline amélioré), ouvrant la Partie III.

Des carnets de notes exécutables sont disponibles sur GitHub : doc-intel/notebooks-vol1.

Un code compagnon public est également disponible à doc-intel/notebooks-vol1.

Fonctionnement du pipeline

Une centaine de lignes de Python relient quatre fonctions : parser le PDF, parser la question, récupérer quelques pages, interroger un modèle.

Ce pipeline renvoie la bonne réponse à une question claire sur un document avec une table des matières intégrée. Cependant, il échoue lors de la première saisie d'une question avec des fautes de frappe, comme "positonal encodig", ou lorsque le document est un contrat de 200 pages sans plan PDF. Quatre briques doivent être mises à niveau avant que le pipeline ne soit opérationnel.

• Document parsing : renvoie plus qu'une simple ligne plate ; un ensemble relationnel incluant une TOC, des métadonnées au niveau des pages, et un parsing_summary typé portant le type de document, la langue, et un résumé en un paragraphe.

• Question parsing : transforme l'entrée utilisateur bruyante en un bref structuré, avec des mots-clés corrigés selon le vocabulaire du corpus et une forme de réponse inférée (valeur unique, liste, tableau).

• Retrieval : lit la TOC comme un expert le ferait : remet la TOC complète à un petit LLM qui sélectionne les sections par pertinence sémantique, puis fusionne avec les pages clés.

• Generation : renvoie une réponse typée avec un extrait citant par élément, plus quatre indicateurs de qualité contextuelle que le pipeline lit pour décider d'envoyer la réponse ou de faire un autre passage.

Le document en cours est une soumission publique de 15 pages sur arXiv, Attention Is All You Need. La question "Quelles sont les options pour l'encodage positionnel ?" arrive avec deux fautes de frappe, ce qui donne du travail à la brique de question parsing. La sortie est ce dont un utilisateur d'entreprise a besoin : une réponse typée, avec des citations verbatim liées à des plages de lignes, et une traçabilité complète de la question à la citation.

1. Où le RAG de base échoue

Posez une question claire sur un PDF clair, faites-la passer par le pipeline RAG le plus simple : parser le PDF, extraire les mots-clés de la question, récupérer quelques pages, interroger un LLM. Sur le document Attention avec la question "Quelles sont les options pour l'encodage positionnel ?", ce pipeline renvoie "encodage positionnel sinusoidal et embeddings positionnels appris" avec une plage de pages continue citée. Cela a fonctionné, sur une question claire, sur un document clair.

Déposez le même pipeline dans un environnement d'entreprise et quatre points faibles apparaissent rapidement, un par brique :

• Document parsing : le document est aplati. L'Article 1 (RAG minimal) a analysé le PDF en une liste plate de lignes, suffisante pour compter les mots-clés mais rien de plus. Les pages, les sections, les tableaux, toute la structure qu'une brique en aval pourrait exploiter, est perdue dès la première étape.

• Question parsing : la question saisie par les utilisateurs est rarement claire. "Quelles sont les optoins pour posiitional encoding ?" contient deux fautes de frappe. L'extracteur de mots-clés de base n'a jamais vu le mot "positionnel", il a vu "posiitional", donc la récupération manque les pages où se trouve la réponse.

• Retrieval : la base ne regarde jamais la structure. Le document Attention a une TOC intégrée propre, avec des sections nommées et des numéros de page, trois niveaux de profondeur. Le signal de récupération le plus précis dans tout le document est ignoré.

• Generation : la réponse revient sous forme de chaîne brute. Une question de liste (options) demande un élément par option, chacun avec sa propre preuve. La prose libre oblige l'appelant à re-analyser la réponse pour trouver les éléments ; un schéma typé avec une plage de preuves par élément élimine cette étape.

Les quatre briques ci-dessous traitent ces quatre points faibles. Même document, même question, appels LLM réels. La sortie est une liste typée avec des citations verbatim, des plages de lignes, et la chaîne complète de décisions qui l'a produite.

2. Quatre briques, mises à niveau

La forme qui survit à la mise à niveau est la même que les quatre briques introduites dans l'Article 1 (RAG minimal). Ce qui change, c'est le contrat par brique : ce que chacune consomme, ce qu'elle produit, et comment la suivante l'exploite. Le diagramme ci-dessous présente le contrat complet : chaque brique, les sorties qu'elle produit, et quelle brique en aval consomme chacune (y compris le canal latéral parsing_summary dans les question parsing et generation). Les sous-sections par brique zooment ensuite sur chaque boîte.

Chaque brique des quatre est mise à niveau dans ses propres articles, à lire pour le contrat complet :

• Document parsing : Article 5A (ce qu'il faut lire dans un PDF) et Article 5B (le modèle de données relationnelles).

• Question parsing : Article 6A (la thèse), Article 6B (extraction), et Article 6C (dispatch).

• Retrieval : Article 7A (récupération comme filtrage), Article 7B (détection d'ancrage), et Article 7C (l'arbitre LLM).

• Generation : le contrat de réponse, assemblage de prompt, et validation (Articles 8A à 8C, liens à venir).

2.1 Document parsing : un petit ensemble relationnel

Le parsing s'exécute une fois et transforme le PDF en un petit ensemble de tables que chaque brique ultérieure réutilise.

• Entrée : pdf_path, le PDF sur le disque.
• Sortie : line_df, page_df, toc_df, parsing_summary.

Le document parsing : parse_pdf lit le PDF une fois et renvoie le petit ensemble relationnel que chaque brique en aval réutilise.

Ce qui sort, une ligne par unité :

• line_df : une ligne par ligne visible (page_num, line_num, texte, boîte englobante). L'unité de citation.

• page_df : une ligne par page (page_num, texte). La surface de scan grossière.

• toc_df : une ligne par section (titre, niveau, start_page). La carte propre du document.

• parsing_summary : métadonnées au niveau du document (type de doc, langue, nombre de pages, mise en page). Le canal latéral vers les briques LLM.

L'Article 1 (RAG minimal) a analysé le PDF en un DataFrame appelé line_df, une ligne par ligne de texte visible. Suffisant pour la récupération de mots-clés, mais pas pour autre chose. L'Article 5 (document parsing) reformule le parsing comme la construction d'un petit ensemble relationnel : line_df reste, page_df agrège les lignes par pages avec leur texte, et toc_df porte la table des matières native du document.

Le morceau de démarrage en haut de l'article a déjà produit les trois DataFrames sur le document Attention. Un aperçu de chacun :

• Une ligne par ligne visible, avec page_num et line_num pour les citations.

• Les mêmes lignes, redessinées sur la page : chaque boîte bleue est une ligne_df, le numéro de la gouttière est son line_num.

• L'agrégation des lignes page par page donne page_df, l'unité de page naturelle qui porte le texte de la page entière et le contexte au niveau de la page.

• toc_df porte le plan natif ; sur le document Attention, il a trois niveaux et vingt-deux entrées, une ligne par section avec son titre, son niveau, et sa page de départ.

Trois tables, même contrat de forme, mêmes clés primaires numériques. Les briques en aval lisent ce dont elles ont besoin sans re-analyser le PDF ; Retrieval (Section 2.3) scanne les frappes de mots-clés et lit toc_df pour s'ancrer sur la bonne section, puis dimensionne le contexte autour (toute la section, ou une fenêtre de ligne) à la granularité que la question implique. page_df est l'unité de scan au niveau de la page, toc_df la carte, line_df les lignes atomiques dont l'ancre et la fenêtre sont découpées. parse_pdf renvoie en réalité plus dans le même dictionnaire (régions d'image, références internes, objets nommés) plus un parsing_summary portant des métadonnées au niveau du document (type de doc, langue, nombre de pages, mise en page, champs typiques, un court résumé) ; cette section se concentre sur les trois tables que retrieval lit, et parsing_summary sera renvoyé dans la deuxième partie comme le canal latéral qui voyage vers les briques LLM.

2.2 Question parsing : du bruit au bref

Le question parsing transforme la chaîne brute de l'utilisateur en un bref typé sur lequel les deux briques suivantes peuvent agir.

• Entrée : la question brute, le concept_keywords_df de l'expert, et parsing_summary pour le contexte du document.
• Sortie : un ParsedQuestion portant l'intention, les mots-clés, un bref RetrievalQuery, et un GenerationBrief.

Le question parsing : un appel LLM corrige les fautes de frappe et extrait les mots-clés, puis concept_keywords_df les développe.

• mots-clés : fautes corrigées et termes de contenu extraits en un appel LLM, puis élargis avec le vocabulaire de l'expert.

• intention : la forme de réponse que la question implique (factuelle, liste, comparaison).

• RetrievalQuery : le bref que la récupération consomme (main_query, réécritures, anchor_keywords, section_hint, layout_hint).

• GenerationBrief : uniquement les champs sur lesquels la génération peut agir (la question, la forme de réponse, désambiguïsation).

L'Article 1 (RAG minimal) a appelé get_keywords_from_question sur la question claire et a obtenu une corrected_question plus une courte liste de mots-clés en un seul appel LLM. Cet appel unique effectue deux tâches à la fois : il corrige les fautes et extrait les mots-clés.