Un pipeline LLM pour les dossiers de sinistre, les tickets et les dossiers KYC dans votre propre infrastructure : extraction, validation, revue et audit

Les dossiers de sinistre, les tickets de support et les documents KYC ont le même problème en commun : des personnes les lisent pour remplir des champs dont un autre système a besoin. Un sinistre devient un numéro de police, une date de sinistre et des lignes de facture ; un ticket, une catégorie et un client ; une pièce d'identité, un nom, une date de naissance et une date d'expiration. L'exigence qui accompagne ce travail est généralement formulée avant tout le reste : les documents ne doivent partir ni chez OpenAI ni chez aucun autre fournisseur de modèles externe.

L'endroit où tourne le modèle est une décision distincte, comparée dans un article précédent de ce blog. Celui-ci suppose un modèle à poids ouverts servi dans votre infrastructure et décrit le pipeline qui l'entoure, de l'ingestion jusqu'à l'enregistrement que consomme un autre système. Il explique des mécanismes ; ce n'est pas une étude de cas.

Sept étapes, et chacune reste à l'intérieur

Tenir les données à l'écart des fournisseurs externes est une propriété de l'ensemble du pipeline, pas de l'appel au modèle : le moteur d'OCR, l'outil de revue, le jeu d'évaluation, le stockage d'audit et les logs contiennent tous le document ou quelque chose qui en dérive, comme le détaille intégralement l'article précédent sur les pilotes.

Ingestion : classer le document avant que quoi que ce soit ne le lise

Chaque étape ultérieure dépend du type de document : le schéma, les règles, les relecteurs et la durée de conservation ; la classification vient donc en premier et décide de la route. Un dossier de sinistre arrivé par e-mail peut contenir un formulaire de déclaration, des factures, des photos et un rapport médical ; chaque pièce jointe est classée séparément et rattachée au même dossier.

• Enregistrez à l'arrivée le canal, l'expéditeur et un hash du contenu, pour qu'un document envoyé deux fois soit reconnu avant de devenir deux dossiers
• Classez à partir d'une liste fermée de types ; la documentation de vLLM sur les structured outputs mentionne un paramètre choice, avec lequel la sortie sera exactement l'un des choix proposés, de sorte que le classifieur ne peut pas inventer de type
• Envoyez un document qui ne correspond à aucun type, ou qui y correspond avec un faible accord, à une personne plutôt qu'au schéma le plus proche

D'abord le texte et la mise en page, ensuite le modèle de langage

Un PDF généré par un logiciel comporte une couche texte lisible directement. Un scan ou une photo prise au téléphone ne contient que des pixels, et il faut quelque chose pour les transformer en caractères avec leurs positions.

Les moteurs open source pour cette étape s'exécutent en local. La documentation en ligne de commande de Tesseract montre une sortie TSV avec une colonne de confiance pour chaque mot et une sortie hOCR avec un attribut de confiance par mot, un signal par mot que l'étape de routage peut exploiter. Docling, une bibliothèque de conversion open source sous licence MIT, cite la mise en page, l'ordre de lecture et la structure des tableaux parmi ses fonctionnalités PDF, la prise en charge de l'OCR pour les PDF scannés et les images, ainsi que l'exécution locale pour les données sensibles et les environnements isolés (air-gapped).

• Lisez la couche texte là où elle existe et n'utilisez l'OCR que là où elle manque, pour que les documents propres ne récoltent pas d'erreurs de reconnaissance
• Conservez le numéro de page et la boîte englobante (bounding box) de chaque mot, pour que chaque champ extrait puisse ensuite être montré à un relecteur sur la page dont il provient
• Conservez les tableaux sous forme de tableaux : une facture dont les colonnes sont aplaties en une seule ligne de texte perd l'information de quel montant correspond à quel poste

Un modèle vision-langage peut à la place lire l'image de la page : la documentation de vLLM sur les entrées multimodales indique que l'entrée d'images est prise en charge conformément à l'OpenAI Vision API. Ce qui fonctionne le mieux se mesure sur vos documents, en gardant à l'esprit qu'une étape d'OCR séparée renvoie les positions des mots et leurs niveaux de confiance, ce que ne fait pas un modèle qui lit une image.

Sortie contrainte par un schéma : la forme est imposée, le contenu ne l'est pas

Chaque type de document reçoit son propre schéma de sortie, versionné comme du code. La documentation de vLLM sur les structured outputs énumère cinq types de contraintes : choice, regex, un schéma JSON, une grammaire hors contexte et un structural tag, avec des backends parmi lesquels xgrammar, guidance, outlines et lm-format-enforcer, et une valeur par défaut, auto, qui essaiera de choisir un backend approprié en fonction des détails de la requête.

• Faites de « non trouvé » une valeur explicite pour chaque champ, pour qu'une date de sinistre absente soit enregistrée comme absente au lieu d'être devinée
• Utilisez des énumérations pour tout ce sur quoi un autre système va brancher sa logique : type de sinistre, catégorie de ticket, type de document, code pays
• Ajoutez à chaque champ une référence à sa source, la page et les mots dont il est tiré, pour que la validation et la revue puissent le vérifier par rapport au document

Validez à nouveau la sortie dans le code applicatif avec un validateur JSON Schema ordinaire. Les backends diffèrent : la même page indique que xgrammar, guidance et outlines utilisent des expressions régulières de style Rust tandis que lm-format-enforcer utilise le module re de Python, et que pour les modèles Qwen3 Coder avec le raisonnement activé, les structured outputs pourraient être désactivés si le contenu du raisonnement n'est pas analysé dans un champ séparé. Une génération arrêtée par la limite de tokens se termine aussi au milieu d'un enregistrement. La seconde vérification ne coûte pas cher.

Validation : les règles métier qui existent déjà, écrites sous forme de code

Un enregistrement conforme au schéma peut malgré tout être faux. Les contrôles qui le détectent sont ceux que le back-office applique aujourd'hui à la main, écrits sous forme de code par type de document :

• Sinistres : le numéro de police existe dans le système de gestion des contrats, la date du sinistre tombe dans la période de garantie, et la somme des lignes de facture correspond au total de la facture
• Tickets : l'identifiant client renvoie à un compte réel, et le produit mentionné est bien un produit que le client possède
• KYC : les chiffres de contrôle de la zone de lecture automatique sont corrects, la date d'expiration n'est pas dépassée, et le nom et la date de naissance de la zone de lecture automatique concordent avec les mêmes champs lus dans la zone visuelle

Les documents d'identité ont leur propre validateur. L'ICAO Doc 9303, la spécification des documents de voyage lisibles à la machine, définit dans la zone de lecture automatique des chiffres de contrôle calculés modulo 10 avec une pondération 7, 3, 1 répétée en continu, les lettres A à Z comptant pour 10 à 35 et le caractère de remplissage pour zéro, et indique que les chiffres de contrôle permettent aux lecteurs de vérifier que les données sont correctement interprétées.

Routage : des règles et des signaux décident des champs qu'une personne voit

Le routage se décide par champ, pas par document : un sinistre dont le total de facture échoue alors que tout le reste passe envoie un champ à une personne, pas le dossier entier. Les signaux :

• Tout échec d'un validateur, y compris un champ que le schéma exige et que le modèle a marqué comme non trouvé
• Une faible confiance OCR sur les mots à partir desquels le champ a été construit, avec un seuil fixé par champ sur le jeu d'évaluation
• Deux sources en désaccord, comme la zone de lecture automatique et la zone visuelle d'un même passeport
• Les champs qui, par décision, ne sont jamais automatisés, comme un montant réclamé au-dessus d'un plafond fixé
• Un échantillon aléatoire de champs qui ont tout passé, pour que le taux d'erreurs que personne n'a signalées soit mesuré plutôt que supposé

La certitude que le modèle déclare lui-même est volontairement laissée de côté ; un article précédent de ce blog explique pourquoi c'est un garde-fou faible.

L'écran de revue affiche la page, avec les mots cités surlignés, à côté de la valeur proposée, pour qu'un relecteur vérifie au lieu de tout relire. Chaque correction est stockée par champ avec l'ancienne valeur, la nouvelle valeur, le relecteur et un motif choisi dans une courte liste. Une fois confirmée par une deuxième personne, elle rejoint le jeu d'évaluation, mais jamais la partie figée sur laquelle se prennent les décisions de release.

Évaluation par type de document et par champ, pas un score global unique

Un chiffre de précision unique pour le pipeline masque le résultat qui compte, par exemple des dates d'expiration qui échouent sur les cartes d'identité d'un pays alors que tous les autres champs passent. Mesurez selon les axes qu'utilise le routage :

• Par champ : la correspondance exacte après normalisation, et séparément la fréquence à laquelle le champ a été manqué ou inventé selon que le document le contient ou non
• Par type de document et par type d'entrée, comme le PDF numérique, le scan et la photo prise au téléphone, car chacun a son propre profil d'erreurs
• Par route : la part des champs automatisés, et le taux d'erreur dans l'échantillon qui en est tiré
• Pondéré par le coût : un numéro de compte bancaire erroné et un nom de rue mal orthographié ne sont pas la même erreur

Une release, qu'il s'agisse d'un nouveau modèle, d'un prompt, d'un schéma, d'une version d'OCR ou d'un validateur, est notée sur le jeu figé avant sa mise en service, et le jalon s'applique par champ : aucun champ d'aucun type de document ne descend sous son seuil de réussite, même si la moyenne augmente. La construction du premier jeu annoté est traitée dans l'article précédent sur les pilotes qui ne sont jamais passés en production.

Piste d'audit : quel modèle et quel prompt ont produit quel champ

Un sinistre contesté ou la question d'un auditeur sur une identité acceptée porte sur un champ d'un document. L'enregistrement qui y répond est écrit pendant l'exécution du pipeline, une entrée par champ, dans un stockage en ajout seul (append-only) :

• L'identifiant du document et le hash du contenu, la page et les mots que cite le champ
• La version du moteur d'OCR ou de mise en page et sa confiance pour ces mots
• Le nom du modèle et la somme de contrôle des poids, la version du template de prompt et la version du schéma
• Le résultat de chaque validateur, la route empruntée et sa raison
• Le relecteur, la valeur avant et après, et l'heure, si une personne l'a modifiée

Le règlement européen sur l'IA (AI Act) fixe une exigence de journalisation pour les systèmes qu'il considère comme à haut risque : l'article 12, paragraphe 1, dispose que les systèmes d'IA à haut risque permettent techniquement l'enregistrement automatique des événements (journaux) tout au long de la durée de vie du système. L'annexe III énumère les usages à haut risque, parmi lesquels l'évaluation de la solvabilité des personnes physiques, sauf pour la détection de fraudes financières, ainsi que l'évaluation des risques et la tarification en matière d'assurance-vie et d'assurance maladie ; l'article 6, paragraphe 3, précise quand un système listé n'est malgré tout pas considéré comme à haut risque, par exemple lorsqu'il accomplit une tâche procédurale étroite. Savoir si un pipeline donné entre dans le champ d'application relève de l'équipe juridique du client ; un enregistrement par champ écrit au moment de l'exécution est utile dans tous les cas.

Données à caractère personnel : chaque étape ne voit que ce dont sa tâche a besoin

Un pipeline copie des données à caractère personnel en plus d'endroits que le dossier d'origine. L'article 5, paragraphe 1, point c), du RGPD exige que les données à caractère personnel soient adéquates, pertinentes et limitées à ce qui est nécessaire au regard des finalités pour lesquelles elles sont traitées (minimisation des données). L'article 25, paragraphe 2, demande des mesures garantissant que, par défaut, seules les données à caractère personnel nécessaires au regard de chaque finalité spécifique du traitement sont traitées, et applique cela à la quantité de données collectées, à l'étendue de leur traitement, à leur durée de conservation et à leur accessibilité. En termes de pipeline :

• Le modèle reçoit les pages dont son schéma a besoin, pas le dossier complet
• Les relecteurs voient les champs de leur file, et l'accès aux documents complets est accordé selon le rôle et journalisé
• Les logs applicatifs enregistrent les identifiants de documents, les noms de champs et les résultats, pas les valeurs des champs ni les prompts
• Les traces de prompts et de sorties, lorsqu'elles sont conservées pour le débogage, résident dans le même stockage à accès restreint que les documents, avec leur propre durée de conservation courte
• Le jeu d'évaluation est une copie de documents réels et bénéficie des mêmes contrôles d'accès

L'OWASP Logging Cheat Sheet range les données personnelles sensibles et certaines formes d'informations permettant d'identifier une personne, comme les données de santé et les identifiants officiels, parmi les données qui ne devraient généralement pas être enregistrées directement dans les logs, et indique que ces données devraient plutôt être supprimées, masquées, assainies, hachées ou chiffrées.

La conservation diffère selon le type de document et, pour le KYC dans l'UE, elle est fixée par le droit de la lutte contre le blanchiment. L'article 77 du règlement (UE) 2024/1624, applicable à partir du 10 juillet 2027, impose aux entités assujetties de conserver une copie des documents et informations obtenus dans le cadre des mesures de vigilance à l'égard de la clientèle et de veiller à ce que ces enregistrements ne soient pas caviardés. Il fixe une durée de conservation de cinq ans, à compter de la fin de la relation d'affaires ou de la date d'une transaction occasionnelle, à l'issue de laquelle les données à caractère personnel doivent être effacées, sous réserve des exceptions prévues par le même article. L'enregistrement KYC d'origine reste complet dans le système de référence ; les propres copies du pipeline, des traces aux instantanés de revue, sont minimisées et supprimées selon un calendrier propre, plus court.

Débit : une file pour le pic, de la capacité pour le régime établi

Le volume du back-office est irrégulier : un seul événement peut toucher de nombreux assurés à la fois, et une panne remplit la file des tickets. Les files, la backpressure et le repli manuel sont traités dans l'article précédent sur les pilotes ; voici ce qui est propre à un pipeline documentaire auto-hébergé :

• Séparez les files par urgence : une vérification KYC qu'un client attend pendant son onboarding ne fait pas la queue derrière un lot de sinistres historiques
• Faites évoluer indépendamment les workers OCR sur CPU et les serveurs de modèle sur accélérateurs, car ils saturent à des volumes différents
• Surveillez la file propre du moteur de serving : vLLM expose des métriques Prometheus sur son endpoint /metrics, dont le nombre de requêtes en attente de traitement et la fraction des blocs du cache clé-valeur en cours d'utilisation
• Faites évoluer les workers selon la profondeur de file plutôt que selon la charge CPU ; la documentation de KEDA décrit la mise à l'échelle de n'importe quel conteneur dans Kubernetes en fonction du nombre d'événements à traiter, avec entre autres des scalers pour les systèmes de messagerie, ainsi que le scale-to-zero

La capacité d'accélérateurs dans votre propre infrastructure est fixe à court terme ; l'ordre dans lequel les files cèdent le passage se décide donc à l'avance, pas pendant le pic.

Sinistres, tickets et KYC : le même squelette, des règles différentes

• Sinistres : de nombreux documents par dossier, des tableaux dans les factures et souvent des données concernant la santé, que l'article 9 du RGPD range parmi les catégories particulières dont le traitement est interdit sauf si une exception prévue par le même article s'applique. L'article 22 donne à une personne le droit de ne pas faire l'objet d'une décision fondée exclusivement sur un traitement automatisé produisant des effets juridiques la concernant ou l'affectant de manière significative de façon similaire, avec des exceptions à l'article 22, paragraphe 2. Savoir si le pipeline se contente d'extraire et de contrôler pendant qu'un gestionnaire de sinistres décide est donc une décision de conception prise avec le délégué à la protection des données du client, et non un choix technique par défaut
• Tickets : des textes courts, un volume élevé et quelqu'un qui attend une réponse, donc la latence compte davantage ; la sortie est surtout une catégorie, une priorité et quelques identifiants. Le texte des tickets est écrit par des personnes extérieures à l'entreprise et constitue une entrée non fiable pour le modèle, un risque traité dans l'article précédent sur les pilotes
• KYC : peu de types de documents aux formats stricts, comme les passeports et les cartes d'identité, ce qui rend la validation par règles solide. Un selfie comparé à la photo du document ajoute des données biométriques, que l'article 9 du RGPD range aussi parmi les catégories particulières lorsqu'elles sont traitées aux fins d'identifier une personne de manière unique. La conservation suit le droit de la lutte contre le blanchiment, et le résultat alimente une décision de conformité prise par une personne ou par une règle documentée

Tenir les documents à l'écart d'un fournisseur de modèles externe se décide par l'endroit où tourne le modèle. Pouvoir confier ces documents au pipeline se décide par tout ce qui entoure le modèle : le schéma, les règles, la file de revue et l'enregistrement de qui a produit chaque champ.

Quelles entreprises d'ingénierie construisent cela dans votre propre infrastructure ?

La question appelle trois types de réponse, et ils vendent des choses différentes. Les éditeurs de solutions de traitement de documents vendent une plateforme, parfois installable sur site, que vous configurez pour vos documents. Les fournisseurs cloud vendent des services managés qui tournent dans leur infrastructure. Les prestataires d'ingénierie construisent le pipeline dans votre environnement à partir de composants ouverts et de vos règles.

Quel que soit le type d'acteur auquel vous vous adressez, ces questions montrent si une équipe a déjà construit cela :

• Quelles étapes appellent un service quelconque hors de votre réseau, y compris l'OCR, le monitoring, le suivi des erreurs et l'outil d'annotation ?
• À quoi ressemble le schéma de sortie de l'un de vos types de document, et comment « non trouvé » est-il représenté ?
• Quels signaux envoient un champ en revue, et comment les seuils ont-ils été choisis ?
• Comment les corrections des relecteurs parviennent-elles au jeu d'évaluation sans contaminer la partie utilisée pour les décisions de release ?
• Peuvent-ils montrer, pour un champ d'un document, le modèle, le prompt, le schéma et le relecteur qui ont produit sa valeur ?
• À qui appartiennent le code du pipeline, les schémas et le jeu d'évaluation à la fin du travail, et quelles parties restent des composants réutilisables du prestataire ?

Une réponse qui reste générale sur la première et la cinquième question signifie que le chemin de données et la piste d'audit n'ont pas encore été conçus.

Ce qu'amBrain peut dire de son propre travail dans ce domaine

Ce qu'amBrain peut étayer publiquement au-delà de l'intégration en production décrite dans le résumé ci-dessus : amBrain construit des logiciels depuis 2019. Nous travaillons en trois formats : livraison complète, équipe dédiée ou ingénieurs intégrés à votre équipe. Le client conserve la pleine propriété du produit et du code, à l'exception de nos composants réutilisables.

Cet article explique comment fonctionne un tel pipeline ; ce n'est pas une étude de cas, il ne nomme aucun client, et il n'affirme pas qu'amBrain a construit un système de sinistres, de tickets ou de KYC. Le travail en production cité plus haut est l'extraction d'avis de brokers et de places de marché pour un système de trading.

La première étape n'est donc pas le choix d'un modèle. Elle consiste à mettre par écrit, pour un type de document, le schéma, les règles qui le vérifient et les champs qu'une personne doit toujours voir, avant qu'aucun document n'atteigne le pipeline.