ai_parse_document() : transformez un PDF en table gouvernée avec une seule instruction SQL

Extraire des données de documents a toujours été l'une des parties les plus ingrates de l'ingénierie des données. Des factures en PDF, des contrats en DOCX, des rapports avec des tables dans des tables, des images scannées. Le chemin traditionnel assemble un service d'OCR, une bibliothèque de mise en page en Python, une étape séparée pour reconstruire les tables et une bonne dose de code de colle pour tout relier. Chaque pièce est un point de défaillance, et le moindre changement de format de document fait tomber le pipeline.

ai_parse_document() de Databricks propose une autre approche : réunir tout ce flux en une seule instruction SQL déclarative, avec le résultat qui atterrit directement dans une table gouvernée d'Unity Catalog.

Ce que fait la fonction

ai_parse_document() reçoit le contenu binaire d'un document et renvoie sa structure dans un format semi-structuré (VARIANT). Elle lit PDF, JPG, PNG, DOCX et PPTX et livre :

• Le texte avec l'ordre de lecture préservé ;
• Les tables exactement comme elles apparaissent, y compris les cellules fusionnées et les structures imbriquées ;
• Les figures et diagrammes décrits automatiquement avec des légendes générées par IA ;
• Les métadonnées spatiales et bounding boxes, utiles pour la citation, l'audit et la validation humaine.

Tout cela sans provisionner un seul serveur d'OCR ni écrire le moindre parser.

Le pas à pas

1. Lisez les fichiers du Volume

Placez les documents dans un Volume d'Unity Catalog et lisez-les en binaire avec READ_FILES :

SELECT path,
       ai_parse_document(content) AS doc
FROM READ_FILES(
  '/Volumes/main/raw/docs',
  format => 'binaryFile'
);

En un seul appel, chaque document devient une ligne avec la colonne doc contenant la structure complète.

2. Matérialisez le résultat

Écrivez la sortie dans une table Delta pour interroger et retraiter sans répéter le parsing :

CREATE TABLE main.silver.docs_parsed AS
SELECT path,
       ai_parse_document(content) AS doc
FROM READ_FILES('/Volumes/main/raw/docs',
                 format => 'binaryFile');

3. Naviguez dans la structure

Comme doc est un VARIANT, vous accédez aux champs avec la notation de chemin et n'extrayez que ce dont vous avez besoin — par exemple, le texte de chaque page ou les tables détectées :

SELECT path,
       doc:document:pages AS pages,
       doc:document:elements AS elements
FROM main.silver.docs_parsed;

À partir de là, c'est du SQL classique : explode des pages, filtres par type d'élément, jointures avec vos dimensions. Le contenu extrait alimente directement le RAG, Agent Bricks et l'AI/BI, parce qu'il est déjà dans le lakehouse.

Pourquoi c'est important pour l'ingénierie des données

Moins de pièces mobiles. Un SELECT remplace un pipeline de parsing dédié. Moins de code, moins de dépendances, moins d'astreinte.

Incrémental par défaut. Intégré aux Spark Declarative Pipelines, le traitement est incrémental : les nouveaux documents qui arrivent dans le Volume entrent tout seuls, sans retraiter l'historique.

Une vraie gouvernance. Le résultat est une table Unity Catalog comme une autre — avec permissions, lignage de bout en bout et audit au même endroit que le reste de vos données. Pas de données sensibles qui fuient vers un service externe sans trace.

Coût compétitif. Databricks positionne le système avec une qualité comparable aux meilleures offres du marché pour un coût 3 à 5 fois moindre — pertinent quand le volume de documents grimpe.

Quand (et quand ne pas) l'utiliser

C'est un choix naturel quand les documents vivent déjà, ou peuvent vivre, dans un Volume d'Unity Catalog et que la destination est le lakehouse lui-même : extraction de factures, contrats, rapports réglementaires et bases pour des chatbots d'entreprise.

Attention aux limites actuelles : 500 pages maximum et 100 Mo par document — au-delà, la fonction renvoie une erreur. Pour les documents très volumineux, découpez-les avant de traiter. Et, comme pour toute extraction assistée par IA, gardez une étape de validation pour les cas les plus à risque : les bounding boxes existent précisément pour ça.

Conclusion

ai_parse_document() fait passer l'extraction de documents de « projet d'intégration » à « une ligne de SQL de plus ». Pour les équipes data, cela signifie livrer des données de documents avec la même gouvernance, le même lignage et la même simplicité que n'importe quelle table du lakehouse — et libérer du temps qui partait auparavant dans la maintenance de pipelines de parsing fragiles.

Si vous travaillez avec Databricks, un test rapide avec un Volume d'exemple vaut le coup dès cette semaine.