Dompter le Hasard : L’Approche Hybride pour Industrialiser les LLM grâce aux Mathématiques

Introduction

Les grands modèles de langage (LLM) ont révolutionné notre interaction avec l’information. De GPT-4 à Llama 3, leur capacité à comprendre, générer et raisonner sur du texte s’apparente souvent à de la magie. Mais pour une entreprise, la « magie » est un passif. En production, nous n’avons pas besoin de magie ; nous avons besoin de fiabilité, de cohérence et de contrôle des coûts.

Le problème fondamental est que les LLM sont, par nature, des « perroquets stochastiques ». Ils sont des moteurs probabilistes conçus pour prédire le mot suivant le plus plausible, et non le mot le plus vrai. Cette nature probabiliste est la source de leur créativité, mais aussi de leur plus grand défaut en entreprise : l’hallucination.

Face à ce défi, l’approche commune est souvent de surenchérir, en utilisant des modèles toujours plus grands (et plus chers), espérant que la taille corrigera les erreurs. Chez Full Remote Factory, nous préconisons une approche inverse, à la fois plus scientifique et plus robuste : au lieu d’utiliser un marteau-pilon pour écraser une noix, nous concevons un outil chirurgical.

Notre thèse est la suivante : la fiabilité en production ne vient pas de la taille du modèle, mais de sa spécialisation et de l’application de contraintes mathématiques et logicielles strictes. Il s’agit « d’alléger » le LLM pour mieux le « verrouiller » dans une chaîne de déterminisme.

Analysons cette approche à travers des cas d’usage concrets.

Le Mythe du « Plus C’est Gros, Mieux C’est »

Imaginons un premier cas d’usage : l’extraction structurée d’informations depuis des comptes-rendus d’assurance. L’objectif est de lire des milliers de rapports d’experts (PDF, emails) pour en extraire systématiquement : le nom du sinistré, le numéro de police, la date du sinistre et le montant estimé des réparations.

Utiliser un modèle généraliste de 175 milliards de paramètres (comme GPT-4) pour cette tâche est non seulement coûteux, mais contre-productif. Ce modèle a été entraîné à écrire de la poésie, à débattre de philosophie et à coder en Python. Cette vaste « surface créative » est précisément ce qui l’incitera, face à un document ambigu, à « inventer » une information plausible ou à formater sa réponse de manière créative (« Voici les informations que j’ai pu trouver pour vous… »).

Pour ce cas d’usage, 99% des capacités du modèle sont inutiles et constituent une source de risque. Notre première étape est donc une chirurgie de précision pour ne garder que le nécessaire.

1. La Chirurgie de Précision : Alléger le Modèle

Alléger un LLM n’est pas seulement une question de coût ou de latence ; c’est la première étape fondamentale pour réduire la surface d’hallucination.

A. Distillation Ciblée et Spécialisation (LoRA)

Nous n’avons pas besoin d’un « cerveau » omniscient.

• Distillation : Nous pouvons « distiller » les connaissances d’un grand modèle vers un modèle beaucoup plus petit (par exemple, un 7B ou 13B) en l’entraînant spécifiquement sur notre tâche : reconnaître des documents d’assurance. Le modèle devient « stupide » en poésie, mais « brillant » en analyse de sinistres.
• LoRA (Low-Rank Adaptation) : Plutôt que de modifier tout le modèle, nous gelons son « tronc commun » et ajoutons de petits « adaptateurs » (LoRA) spécialisés. Nous pouvons avoir un modèle de base de 7B, avec un adaptateur LoRA pour les sinistres « Auto » et un autre pour les sinistres « Habitation ». C’est sobre et hautement spécialisé.

B. Quantification : L’Art du « Suffisamment Précis »

La quantification est l’acte de réduire la précision mathématique des poids du modèle (passant, par exemple, de nombres à 32 bits à des entiers de 8 ou 4 bits).

• Analogie : C’est comme décider que pour notre tâche, une règle graduée en millimètres est suffisante, et qu’une précision au micromètre (plus « lourde » à manipuler) est inutile.
• Application : Pour notre cas d’usage « Assurance », une quantification agressive (int4 via GGUF ou AWQ) est excellente pour le texte (nom, date).
• Vigilance (Point Scientifique) : Attention aux champs numériques ! Pour le « montant des réparations », une quantification trop forte peut altérer la précision. Nous utiliserons donc une Quantification Aware Training (QAT) ou des tables de calibration spécifiques sur ce champ pour garantir que 10,000.50 € ne devienne pas 10,000.49 € ou 10,001.00 €.

C. Le Verrouillage de la Génération (Constrained Decoding)

C’est ici que les mathématiques reprennent le dessus sur les probabilités.

1. Le Décodage « Sobre » :

Nous supprimons toute « créativité » en paramétrant le décodage :

• temperature = 0 : Le modèle choisira toujours le mot (token) le plus probable, et non un mot « un peu moins probable pour être créatif ».
• top_p ≈ 0.1 : On ne considère qu’une toute petite fenêtre des mots possibles.

2. Le Schéma de Sortie (Constrained JSON) :

C’est le levier le plus puissant. Nous ne demandons pas au LLM de nous donner les informations ; nous le forçons à remplir un moule mathématiquement défini.

Pour notre cas d’usage, nous imposons au LLM de générer une sortie qui valide strictement un JSON Schema (ou une grammaire EBNF) :

JSON

{

  « nom_sinistre »: « string »,

  « numero_police »: « string (format: ‘XX-000000’) »,

  « date_sinistre »: « string (format: ‘YYYY-MM-DD’) »,

  « montant_estime »: « number »

}

Si le LLM tente de générer « Le montant est probablement… », le conteneur de génération l’arrête net. La sortie doit être un JSON valide. L’hallucination de format est ainsi réduite à zéro.

2. La Cage de Confiance : Bâtir un Écosystème Déterministe

Le modèle est allégé et contraint. Maintenant, nous construisons un écosystème déterministe autour de lui.

A. Le RAG Discipliné (Retrieval-Augmented Generation)

Le RAG consiste à donner au LLM le « contexte » (le rapport d’expertise) et à lui demander de répondre uniquement sur cette base. Mais un RAG « naïf » n’est pas fiable.

• Notre approche : Nous ajoutons des règles strictes :
  • Citations Obligatoires : Le modèle doit citer la phrase exacte d’où il tire l’information.
  • Seuil de Refus : Si la recherche (vectorielle ou mot-clé) ne trouve pas de passage pertinent dans le document (seuil de similarité trop bas), le LLM a pour instruction de ne pas répondre et de renvoyer NULL. Il est préférable d’avoir un « vide » qu’une « invention ».

B. L’Orchestration Hybride : Du Vérifieur à l’Agent Raisonneur

Nous appliquons le principe « laissez le LLM faire le flou, laissez le code faire le dur ». Mais nous pouvons l’étendre : « Utilisez le bon outil pour la bonne tâche, et validez-le toujours. »

• Cas 1 (Simple) : Le Vérifieur Arithmétique (Ex: Comptabilité)
  • Analyser une facture pour extraire HT et TVA.
  • Approche FRF :
    1. Le LLM (léger et contraint) est chargé de l’extraction sémantique : trouver Montant HT (« 100.00 € ») et Taux de TVA (« 20% »).
    2. Un vérifieur (Python déterministe) calcule le TTC (100.00 * 1.20 = 120.00 €).
    3. Cette fonction compare son résultat avec le TTC extrait. Si écart, l’humain vérifie.
• Cas 2 (Complexe) : L’Agent Raisonneur (Ex: Banque ou Santé)
  • Imaginez une tâche plus complexe : « Ce dossier de prêt est-il à risque ? » (Banque) ou « Ce patient présente-t-il des contre-indications majeures ? » (Santé).
  • Approche naïve : Demander à un GPT-4 géant de lire 50 documents et de donner un « oui » ou « non ». C’est une boîte noire, incontrôlable et non auditable.
  • Approche Hybride (Notre thèse) : Nous construisons un agent orchestrateur qui décompose le problème :

• • 1. Étape 1 (Extraction – LLM Léger) : L’orchestrateur utilise d’abord nos LLM 7B spécialisés et contraints (Section 1) pour extraire les faits bruts de tous les documents (ex: dette_totale, revenu_annuel, antécédents_de_paiement pour la banque ; allergies_connues, médicaments_actuels, résultats_biologiques pour la santé). Cette sortie est structurée et fiable.
    2. Étape 2 (Raisonnement – LLM Optimal) : L’orchestrateur transmet ces faits structurés (et non les 50 PDF bruts) à un modèle à capacité optimale (ex: un Llama 70B, un GPT-4) avec un prompt spécifique : « Évalue le risque de crédit sur la base de ces faits. » C’est une tâche de synthèse et de jugement, où un modèle plus grand est nécessaire.
    3. Étape 3 (Audit – Chain of Thought Forcée) : Nous ne nous contentons pas de sa réponse. Nous forçons ce grand modèle à produire une Chaîne de Pensée (Chain of Thought – CoT) auditable : « Le risque est élevé parce que le ratio dette/revenu (calculé à 45%) dépasse le seuil de 40% et que l’antécédent ‘Défaut de paiement’ a été trouvé. »
    4. Étape 4 (Vérification – Code Déterministe) : L’orchestrateur valide cette chaîne de pensée. Il vérifie lui-même le calcul (dette/revenu) et confirme la présence du fait (‘Défaut de paiement’) dans les données extraites à l’étape 1.

• • Dans ce scénario, le grand modèle n’est pas une « boîte noire magique ». Il est réduit au rôle d’un « moteur de synthèse » puissant, mais isolé, contrôlé et dont chaque affirmation est vérifiée par des composants déterministes. Nous utilisons sa capacité de raisonnement sans subir son caractère stochastique.

C. La Validation Formelle : Les « Garde-fous » Logiques et Mathématiques

Pour des cas d’usage critiques (banque, santé, aérospatial), la vérification ne peut pas être optionnelle. Le LLM propose, mais le code déterministe et les mathématiques disposent.

Nous implémentons des « garde-fous logiques » (Logical Guardrails) qui agissent comme un filet de sécurité impénétrable. Ce sont des règles métier, traduites en code ou en formalismes logiques (ex: automates, règles Prolog, ou simples if/then en Python) qui s’exécutent après le LLM.

• Exemple (Santé) : Un LLM (même un grand) pourrait suggérer un plan de traitement.
  • Garde-fou Logique (Code) : IF (patient.allergies CONTAINS ‘pénicilline’) AND (traitement_proposé.classe == ‘pénicilline’) THEN REJECT_PROPOSAL_AND_FLAG_ERROR.
  • Cette règle déterministe empêchera toujours une erreur critique, quelle que soit l' »hallucination » potentielle du modèle.
• Exemple (Banque – Risque) : Le LLM (étape 2.B) a évalué un risque comme « Faible ».
  • Garde-fou Mathématique (Code) : IF (LTV_ratio > 0.9) OR (credit_score < 600) THEN risk_status = MAX(risk_status, ‘Élevé’).
  • Le système corrige ou outrepasse le jugement du LLM si des seuils mathématiques stricts, définis par le métier, sont violés.

Cette approche mathématique et formelle déplace la responsabilité de la « vérité » du modèle probabiliste (le LLM) vers le système déterministe (le code) qui l’encapsule. C’est la clé de la fiabilité en production.

3. La Reproductibilité : Pierre Angulaire de l’Audit

Pour un cas d’usage audité (finance, médical, assurance), un processus doit être reproductible. La même entrée doit toujours produire la même sortie. Les LLM ne le sont pas par défaut, même avec temperature=0, à cause de l’implémentation des kernels GPU (cuDNN).

Pour garantir un déterminisme total, nous mettons en place un protocole d’ingénierie strict :

• Seeds Fixes : random_seed est fixé partout (numpy, torch, etc.).
• Décodage Déterministe : temperature=0, top_k et top_p fixes.
• Conteneurisation (Docker) : L’entièreté de l’environnement (drivers, librairies, dépendances) est gelée dans une image immuable.
• Versions Pinnées : Nous fixons les versions exactes (requirements.lock) du modèle, de l’moteur d’inférence (ex: vLLM==0.4.0), et des poids du modèle (hash).
• Configuration Matérielle : Nous documentons le GPU, le driver et forçons les kernels (cuDNN) en mode déterministe, quitte à sacrifier un peu de performance.
• Traçabilité Totale : Chaque appel est logué avec le hash des poids, les hyperparamètres, et l’entrée/sortie.

Le résultat : un système qui, bien que basé sur un LLM, se comporte comme un logiciel déterministe traditionnel.

4. La Preuve par la Mesure : L’Évaluation Scientifique

Comment prouver que notre approche (léger + contraint) est meilleure qu’un modèle géant ? Par un plan d’évaluation rigoureux.

1. Le « Golden Set » :

Nous constituons un jeu de données « d’or » (vérité terrain) de 200 à 500 documents (ex: factures) étiquetés à la main par des experts métier.

2. Les KPIs (Indicateurs Clés) :

L' »accuracy » globale est un mauvais indicateur. Nous mesurons :

2. • Pour l’extraction : Le F1-score par champ. Il est possible d’avoir un F1 de 0.99 sur le nom_sinistre mais de 0.85 sur le montant_estime. C’est ce détail qui compte.
   • Conformité : % de sorties conformes au schéma JSON (doit être de 100% avec le constrained decoding).
   • Robustesse : Variance inter-runs (doit être de 0 avec le déterminisme).
   • Coût & Latence : p50/p95 et coût par 1000 requêtes.
3. L’Étude d’Ablation (La Méthode Scientifique) :

Nous ne gardons que ce qui est nécessaire. Nous testons des « ablations » (retraits de fonctionnalités) pour trouver la configuration la plus simple qui atteint l’objectif métier (ex: F1 ≥ 0.97).

Conclusion de l’étude : La configuration 4 (Modèle 7B + RAG + temp=0 + Schéma JSON) est la grande gagnante. Elle surpasse le modèle 70B en précision (sur cette tâche spécifique) tout en étant 5 fois plus rapide et bien moins chère. L’ajout du « Vérifieur » (Config 5) n’augmente pas le F1-score, mais il ajoute une couche de sécurité essentielle pour le métier.

Conclusion : L’Art de l’Ingénieur Hybride

L’approche que nous préconisons chez Full Remote Factory est un retour à l’ingénierie fondamentale. Elle consiste à cesser de traiter les LLM comme des boîtes noires magiques et à les considérer pour ce qu’ils sont : des moteurs sémantiques probabilistes extrêmement puissants.

Notre rôle n’est pas de les laisser « libres », mais de les contraindre.

En combinant deux stratégies :

1. Des modèles allégés et spécialisés (LoRA, quantification) pour l’extraction fiable et rapide.
2. Des modèles à haute capacité (raisonnement), utilisés chirurgicalement et isolés au sein d’un agent orchestrateur.

…le tout encapsulé dans un écosystème rigide de vérificateurs, de schémas de sortie (JSON), de garde-fous logiques et d’ingénierie déterministe (Docker, seeds), nous créons un système hybride qui tire le meilleur des deux mondes : la flexibilité sémantique du LLM et la rigueur mathématique du code déterministe.

C’est ainsi que nous transformons une technologie de « Proof of Concept » en un outil de production fiable, auditable et performant, capable de gérer aussi bien l’extraction de masse que le raisonnement critique pour la finance et la santé.