Analysez le dossier, pas seulement les PDF : les tables relationnelles dont le RAG a besoin sur un dossier

Contexte

Dans l'ingénierie de la documentation d'entreprise, le RAG est souvent réduit à un pipeline unique : découper les PDF en fragments, exécuter une recherche vectorielle, puis confier ces morceaux à un grand modèle de langage. Ce traitement convient aux articles de blog, aux manuels techniques et aux wikis internes, mais il échoue dès que les documents s'organisent autour de dossiers discrets. Les dossiers juridiques, les demandes d'assurance et les demandes de prêt partagent une structure que le découpage ne peut capturer.

Une analyse récente publiée sur Towards Data Science dénonce directement cette défaillance. Sa thèse affirme que l'unité à analyser n'est pas le PDF, mais le dossier tout entier, et que les deux requêtes les plus précises à construire ne sont pas des questions de récupération. Ce sont des problèmes de tables relationnelles. Cette distinction révèle un biais à l'origine même de l'architecture de la plupart des systèmes d'entreprise.

La valeur d'un dossier réside non dans la sémantique d'une page isolée, mais dans le réseau de relations traversant plusieurs documents, pages et lignes de temps. Une demande de prêt tire son sens de la capacité d'un certificat de revenus, de relevés bancaires, d'un rapport de crédit et du formulaire à être appariés, réconciliés et tracés les uns par rapport aux autres. Le montant inscrit sur un certificat est secondaire face à ces liens transdocuments. Tout empiler dans une base vectorielle, c'est comprimer un réseau relationnel en sable dispersé.

Analyse approfondie

La recherche vectorielle répond aux questions de similarité sémantique. Elle identifie quel fragment de texte est le plus proche d'une requête, mais elle ne peut dire si le montant du document A correspond à celui du document B, si les signataires d'un contrat couvrent toutes les clauses requises, ou à quel stade d'un processus d'approbation tombe une horodate. Ces questions n'admettent aucun score de similarité. Elles produisent vrai ou faux, oui ou non, apparié ou non. Ces réponses appartiennent au domaine des bases relationnelles, régies par les clés étrangères, les contraintes, l'agrégation et les jointures, non par la distance cosinus dans un espace d'embedding. La distinction est structurelle, pas une simple question de réglage de recherche. La proposition centrale de l'auteur est qu'avant l'ouverture de tout dossier, le système d'indexation devrait déjà connaître son type d'affaire et pré-lister le contenu exigé. Cela exige une connaissance du domaine : quels documents un divorce exige, quelles qualifications un appel d'offres nécessite, quels reçus une réclamation exige. L'extraction structurée pilotée par le type d'affaire s'oppose frontalement au découpage texte suivi d'une recherche passive. Le premier encode les règles métier en schéma avant extraction ; le second aplatit tout et laisse le modèle assembler le sens au fur et à mesure.

Cette seconde approche est particulièrement dangereuse dans le domaine juridique. Une fois une relation critique tranchée lors du découpage, le modèle n'infère plus que depuis des fragments sémantiques brisés, et les erreurs surgissent avec une grande confiance. Sur le plan commercial, les enjeux tombent dans l'exactitude et la responsabilité. Le droit, la finance et le médical tolèrent presque aucune erreur de traitement ; un seul champ mal placé peut rejeter un prêt, juger fausse une réclamation ou omettre une clause contractuelle. Quand l'erreur naît de la dérive sémantique de la recherche vectorielle, la responsabilité est diffuse et intracable. Quand elle naît d'un schéma relationnel manquant, elle est claire et corrigeable par l'architecture.

Impact sur l'industrie

Cette distinction redessine le flux des ressources. Les entreprises de pointe déplacent leur investissement des meilleures stratégies de découpage vers un schéma d'affaire plus rigoureux. Le paysage concurrentiel se scinde en conséquence. Un groupe de fournisseurs continue de concurer sur les modèles d'embedding et le classement. Un autre commence à bâtir des moteurs d'extraction structurée pensés pour les types d'affaire verticaux, qui portent souvent des barrières plus fortes dans les contextes spécialisés.

Pour les acheteurs, cela modifie les questions à poser. Sélectionner une solution de documentation d'entreprise n'est plus une affaire de savoir quelle est l'exactitude de la récupération. La question la plus tranchante est de savoir si le système peut énoncer, avant de lire un seul fichier, quels matériaux, quels champs et quelles relations un dossier donné exige.

Perspectives

Trois signaux méritent l'attention. Premièrement, les schémas pilotés par le type d'affaire peuvent-ils être générés automatiquement, laissant les systèmes inférer d'après les dossiers historiques la structure de table commune d'un type d'affaire, plutôt que de définir manuellement à chaque fois. Deuxièmement, comment les structures relationnelles et la recherche vectorielle peuvent coopérer au sein d'un seul système, de sorte que les requêtes structurées localisent les documents clés pendant que la récupération sémantique comble les détails, se complétant plutôt que se remplaçant. Troisièmement, ces tables peuvent-elles être standardisées en un modèle de données d'affaire universel traversant les institutions, permettant une véritable interopérabilité entre différents cabinets d'avocats, assureurs et banques.

Si ces directions avancent, la documentation d'entreprise dépassera la simple lecture des PDF pour réellement mener à bien les affaires. Cette transition sera sans doute l'eau séparant les démonstrations industrielles des systèmes de production.