Aperta Scientia Crest
← Retour au Tech Radar
📡 Aperta Intelligence Lab
Docling, Granite & OpenShift AI : Ingestion Multimodale, Décodage Guidé et Extraction Structurée pour les Pipelines RAG

Docling, Granite & OpenShift AI : Ingestion Multimodale, Décodage Guidé et Extraction Structurée pour les Pipelines RAG

📅 13 octobre 2026
Tech Radar AI Infrastructure OpenShift AI

Sommaire de l'analyse

Dans la construction de pipelines RAG (Retrieval-Augmented Generation) et d’architectures d’IA d’entreprise, la qualité des représentations vectorielles dépend directement de la fidélité de l’ingestion documentaire. Les organisations disposent de volumes massifs de données stratégiques captives de formats bureautiques statiques (PDF, documents Word, feuilles de calcul). Or, le traitement naïf de ces flux se heurte à un écueil fondamental : la divergence radicale entre l’ordre d’impression (printing order) et l’ordre de lecture sémantique (reading order).

Dans un retour d’expérience technique publié sur le Red Hat Developer Blog, les équipes d’ingénierie détaillent l’architecture d’un moteur de matching sémantique combinant la bibliothèque multimodale open source Docling (portée par IBM Research et Red Hat), les modèles de langage ouverts IBM Granite et la plateforme Red Hat OpenShift AI (RHOAI). Cette architecture met en lumière les compromis d’ingénierie critiques entre le décodage guidé par grammaire et les guardrails défensifs lors de l’extraction de données structurées.

1. La rupture sémantique des documents : Ordre d’impression vs Ordre de lecture

Le format PDF standard n’a pas été conçu pour la structuration sémantique de données, mais pour la fidélité graphique lors de l’impression physique. Le flux de contenu d’un PDF brut est piloté par des opérateurs matriciels (tels que l’opérateur Tm qui positionne le curseur à des coordonnées cartésiennes précises X et Y).

En conséquence :

  • L’ordre des éléments dans le flux binaire reflète la séquence d’impression et non la hiérarchie logique du texte.
  • Un titre principal peut être encodé après un bloc de bas de page ou une colonne latérale.
  • La mise en page multi-colonnes, les en-têtes et les tableaux complexes sont désintégrés en fragments de texte déconnectés par les outils de parsing OCR ou textuels naïfs (pypdf, extracteurs regex).

Cette perte d’intégrité structurelle corrompt l’étape de découpage (chunking) dans les architectures RAG, produisant des fragments incohérents qui dégradent les scores de similarité cosinus et polluent le contexte injecté aux LLM.

2. L’approche hybride de Docling : Vision de layout et modèle intermédiaire

Pour surmonter cette barrière, Docling applique une approche hybride associant des parseurs de formats bureautiques (prenant en charge 35 formats différents via python-docx, openpyxl, BeautifulSoup) et des modèles d’IA de vision spécialisés dans l’analyse de mise en page (Document Layout Analysis).

Pour le traitement des PDF :

  1. Segmentation par modèle de vision : Docling utilise un réseau neuronal entraîné sur plus de 150 000 documents annotés (tel que docling-layout-heron) pour prédire les boîtes englobantes (bounding boxes) de chaque composant et lui assigner une étiquette sémantique ([section_header], [text], [table], [caption], [furniture]).
  2. Projection géométrique inverse : Les coordonnées vectorielles des opérateurs d’impression Tm du PDF sont projetées et réassociées à leurs boîtes englobantes parentes, restaurant fidèlement l’ordre de lecture original.
  3. Représentation intermédiaire DoclingDocument : La structure résultante est matérialisée dans un modèle objet Python/Pydantic hiérarchique. Ce modèle encapsule la liste ordonnée des éléments textuels (TextItem) et préserve l’arbre hiérarchique du document (corps, sections, sous-sections).

Cette représentation intermédiaire est ensuite exportée en Markdown propre et structuré, fournissant une matière première exploitable par les modèles de fondation sans bruit de mise en forme.

3. Extraction de données structurées : Décodage guidé vs Guardrails défensifs

Une fois le document converti en Markdown, l’étape suivante consiste à extraire un schéma JSON strictement typé via un LLM compact et performant, tel qu’IBM Granite 3.1 ou Granite 4:3B. Deux stratégies d’ingénierie s’affrontent pour garantir la conformité du schéma :

Approche A : Le décodage guidé (Guided Decoding) au runtime d’inférence

Supporté nativement par les moteurs d’inférence modernes comme vLLM via les bibliothèques llguidance et xgrammar, le décodage guidé applique un masque de logits à chaque étape de génération de token. Les tokens qui violeraient la grammaire formelle du JSON Schema sont purement et simplement exclus de la distribution de probabilité.

  • Avantage : 100% de conformité syntaxique garantie en sortie de modèle sans post-traitement.
  • Écueil critique en production (L’hallucination forcée) : Si une propriété déclarée comme obligatoire dans le schéma (par exemple years_of_experience) est totalement absente du document source, le décodage guidé interdit syntaxiquement au modèle d’omettre la clé ou d’émettre une valeur hors-domaine. Le modèle est alors contraint par la grammaire d’inventer une valeur plausible pour respecter le contrat d’API, provoquant une hallucination silencieuse mais structurellement valide.

Approche B : Les guardrails défensifs et boucle de remédiation

L’approche retenue par les architectures résilientes (comme le projet PeopleMesh décrit par Red Hat) privilégie la souplesse de génération suivie de filtres de validation déterministes :

  • Nettoyage automatique des balises Markdown de code (```json).
  • Déduplication des listes de compétences et normalisation des chaînes (suppression des espaces superflus).
  • Clamping strict sur des vocabulaires contrôlés (mapping des niveaux de séniorité non reconnus vers des valeurs par défaut).
  • Validation sémantique par schéma Pydantic : si une information critique manque, l’absence est explicitée (valeur null ou tableau vide) plutôt qu’hallucinée. En cas d’erreur de structure, une boucle de relance ciblée (retry loop) renvoie l’erreur au LLM pour correction.

4. Vectorisation ciblée et évitement de la dilution d’embedding

Une erreur fréquente dans les pipelines RAG consiste à calculer un vecteur d’embedding global sur l’ensemble d’un profil ou d’un document complet. Cette pratique conduit au phénomène de dilution d’embedding (Embedding Dilution) : en moyennant mathématiquement des dizaines de compétences, d’intérêts et d’expériences hétérogènes dans un même vecteur dense (ex. 1536 dimensions), les signaux distinctifs s’annulent mutuellement dans l’espace latent. Le point résultant dérive vers une zone médiane peu différenciée.

Pour maximiser la précision des recherches sémantiques :

  • L’architecture segmente les entités en sous-facettes sémantiques cohérentes (rôle principal, compétences techniques, domaine d’activité).
  • Chaque facette génère un vecteur dédié ou s’appuie sur une recherche hybride (recherche vectorielle combinée à des filtres scalaires et de la recherche lexicale BM25) orchestrée sur PostgreSQL avec pgvector ou sur une base vectorielle distribuée comme Milvus.

5. Opérationnalisation sur Red Hat OpenShift AI (RHOAI)

L’industrialisation de cette chaîne sur Red Hat OpenShift mobilise plusieurs composants natifs de la plateforme :

  • NVIDIA GPU Operator & Accélération matérielle : Déploiement des conteneurs d’ingestion Docling avec accès direct aux GPU pour exécuter en parallèle les modèles de vision de layout à haut débit.
  • ServingRuntimes vLLM & KServe : Déploiement managé des modèles IBM Granite sous OpenShift AI avec support des backends d’inférence haute performance, allocation optimisée du KV-cache et configuration fine des endpoints d’inférence.
  • Orchestration de pipelines avec Data Science Pipelines (Kubeflow Pipelines v2) : Automatisation du flux continu d’ingestion documentaire, de validation des schémas et de mise à jour des index vectoriels.
  • Persistance souveraine sur OpenShift Data Foundation (ODF) : Stockage des documents sources sur NooBaa (Object Storage S3) et persistance des bases vectorielles sur volumes Ceph RBD chiffrés.

6. Compétences & Cursus Aperta Scientia

  • Cursus AS300 (AI Platform Engineer — 399h) : Ce cas d’usage illustre parfaitement l’ingénierie des pipelines de données pour l’IA — ingestion multimodale avec Docling, déploiement et configuration des ServingRuntimes vLLM avec IBM Granite sur Red Hat OpenShift AI (RHOAI), arbitrage opérationnel entre Guided Decoding (llguidance) et guardrails déterministes, conception d’architectures RAG évitant l’embedding dilution, et persistance vectorielle sur Milvus / ODF.
  • Cursus AS200 (DevOps Platform Engineer — 399h) : Industrialisation GitOps des manifestes de ServingRuntime via OpenShift GitOps (ArgoCD), gestion du cycle de vie du GPU Operator, isolation multi-tenant des workloads d’ingestion documentaire et sécurisation des flux d’API d’inférence.

7. Sources & Références Techniques

Appliquer ces technologies en production

Découvrez nos cursus intensifs de 3 mois AS200 (DevOps) et AS300 (AI Platform Engineer).

Découvrir les cursus →