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