Pipeline RAG multimodal et framework d'évaluation en production

Mission de founding engineer dans une startup IA en pre-seed : un pipeline d'ingestion documentaire multimodal industrialisé sur Databricks, et le framework d'évaluation qui a arbitré chaque choix d'architecture, jusqu'à remplacer la solution commerciale par le pipeline interne.

  • RAG
  • Document Intelligence
  • OCR
  • LLM
  • Evaluation
  • Ragas
  • LangSmith
  • Databricks
  • AWS
  • Python

Par Marius Ayrault · 20/02/2026 · 4 min lire

Le contexte

Un assistant IA pour la maintenance et le diagnostic d’équipements industriels : les techniciens interrogent en langage naturel un corpus de manuels OEM et de documentations techniques, souvent scannés, denses en tableaux et en schémas. C’est le cas d’usage où le RAG naïf échoue, et celui où mon double parcours industrie et IA s’applique le plus directement. En tant que founding engineer, j’étais propriétaire de toute la chaîne : ingestion, retrieval et évaluation. Cette fiche décrit l’architecture et les résultats mesurés.

Le pipeline d’ingestion

Du PDF brut à l’index vectoriel, sur un cluster Databricks CPU adossé à un endpoint d’inférence GPU Hugging Face :

  • OCR par vision-language model servi sur un endpoint d’inférence Hugging Face dédié, avec autoscaling et scale-to-zero pour ne payer le GPU qu’à l’usage, warm-up de cold start, traitement par lots de pages et subdivision récursive en cas d’échec : un lot qui échoue est redécoupé et retenté, le succès partiel est accepté et les pages perdues sont tracées.
  • Annotation d’images en sortie structurée : chaque schéma ou photo est décrit par un modèle de vision avec ancrage contextuel (le prompt embarque le markdown environnant et la position exacte de l’image), raisonnement préalable obligatoire et score de confiance. Les images sont servies via un CDN et rendues directement dans la conversation avec leur explication : un technicien voit le schéma d’origine annoté, pas un paragraphe qui le paraphrase.
  • Déduplication perceptuelle avant l’inférence : le hash perceptuel élimine les images répétées, 52 % d’appels vision économisés sur un manuel réel (216 références, 103 uniques).
  • Chunking token-aware : découpage sémantique mesuré dans le tokenizer du modèle d’embedding lui-même (500 à 1 500 tokens), fusion puis re-découpage avec blocs d’image atomiques, fil d’Ariane de section préservé sur chaque fragment, tables sérialisées en JSON Lines plutôt qu’en markdown via un serializer custom, pour un retrieval vectorisé plus précis.
  • Réattribution des pages par fuzzy matching : l’OCR perd la provenance des pages, elle est reconstruite par une cascade exact, préfixe, fenêtre glissante RapidFuzz, pour que chaque réponse du chat soit sourcée comme une bibliographie : chapitre, paragraphe, page et annotation, en entonnoir jusqu’à la citation exacte.
  • Embeddings 3 072 dimensions et index Databricks Vector Search en upsert idempotent, avec métadonnées de filtrage par équipement, fabricant et catégorie de document.

Le retrieval

La maintenance interdit le retrieval purement sémantique : un code erreur ou une référence de pièce exacte ne se retrouve pas par similarité.

  • Recherche hybride : similarité vectorielle et recherche par mots-clés BM25, fusionnées par Reciprocal Rank Fusion, pour capter à la fois les questions en langage naturel et les identifiants exacts.
  • Reranking neuronal des passages récupérés, puis réordonnancement en U (Lost in the Middle) pour placer les passages décisifs là où le modèle les lit le mieux.
  • Des paliers de confiance qui décident de la suite : au-dessus du seuil, on répond ; en zone intermédiaire, la requête est réécrite et rejouée ; en dessous, bascule en recherche web pour élever le niveau de confiance, et à défaut une réponse qui explicite ses incertitudes plutôt que de les masquer.

L’industrialisation

  • Databricks Asset Bundles sur quatre cibles : des environnements par développeur, puis dev, test et prod, exécutés par un service principal avec ACLs déclarées dans le bundle.
  • La topologie d’environnements vit dans le code : une seule fonction dérive catalogue, host, CDN et bucket du workspace courant, zéro fichier de config par environnement.
  • Résilience à trois étages selon la classe d’erreur : backoff exponentiel pour le transitoire, subdivision progressive des lots pour les dépassements, recyclage périodique des clients HTTP pour les connexions dégradées.
  • Une gate de qualité plutôt qu’une dégradation silencieuse : au-delà de 10 % d’images non annotées, le document entier est rejeté au lieu d’indexer des chunks incomplets.
  • Le coût comme contrainte de conception : le GPU est isolé sur l’endpoint d’inférence à la demande pendant que le pipeline Databricks reste sur un cluster CPU single-node, les quotas de tokens et de payload sont calculés avant chaque appel, et les arbitrages DBU contre latence sont documentés dans l’historique git.

Le framework d’évaluation

La question à trancher : construire ou acheter. La réponse est venue d’un banc d’évaluation, pas d’une conviction.

  • Jusqu’à sept pipelines candidats comparés à la solution commerciale de référence et à la solution clé en main de la plateforme, derrière une interface unique où seul le retriever change.
  • Le générateur est fixé et la requête réécrite est rejouée pour tous les candidats : la seule variable libre entre deux systèmes est le retrieval. C’est ce qui distingue un benchmark d’une impression.
  • Corpus d’évaluation stratifié par pathologie documentaire : clustering KMeans seedé sur les caractéristiques structurelles de 183 PDF, puis groupes ciblés (denses en images, denses en tableaux, couche texte corrompue, changements de langue).
  • Jeux de test génératifs et contrôle multimodal : questions synthétiques Ragas sur graphe de connaissances, plus une slice multimodale écrite à la main pour tester ce que les benchmarks texte ne voient pas.
  • Six métriques balayées par profondeur de retrieval (k de 1 à 10) avec intervalles de confiance à 95 %, provenance des juges persistée par métrique, runs idempotents et reprenables.

Les résultats

  • Le pipeline interne dépasse la baseline commerciale en Precision@k 0,82 contre 0,68 et en Recall@k 0,70 contre 0,56.
  • Face à la solution clé en main de la plateforme : latence de retrieval réduite de 41 % (P95 à 1,4 s contre 2,3 s) et environ 40 % de tokens de contexte en moins par requête, à qualité de réponse comparable.
  • La slice multimodale inverse la conclusion du benchmark texte : +26 points de précision et +28 points de faithfulness sur les questions portant sur les schémas et tableaux, là où vit la valeur du produit.
  • La recommandation finale a été écrite avec ses contre-preuves : la solution clé en main gagne sur les requêtes purement textuelles, et le rapport le dit.

Ce que le projet démontre

L’évaluation comme instrument de décision plutôt que comme formalité : le premier benchmark, biaisé par le graphe complet dans la boucle, a été invalidé et jeté en 48 heures ; le dernier a arbitré un choix build-vs-buy avec ses chiffres, ses limites et ses contre-arguments. Entre les deux, un pipeline de production dont chaque étage, coût, qualité et provenance, est mesuré.