AWS et Artificial Genius ont démontré comment réduire les hallucinations des LLM en finance et médecine

AWS, en partenariat avec Artificial Genius, a démontré comment adapter les grands modèles de langage pour des tâches où l'erreur est inacceptable. L'approche repose sur Amazon Nova et SageMaker, mais l'idée clé n'est pas un nouveau tapage de modèle, mais plutôt d'utiliser sa compréhension du langage sans génération libre de réponses.

Pourquoi C'est un Problème

Pour les services financiers, la médecine, l'assurance et les processus juridiques, les LLM ordinaires semblent toujours risqués. Ils écrivent, résument et expliquent bien, mais restent par nature des systèmes probabilistes: le modèle prédit le prochain token plutôt que d'extraire un fait garantissement correct. Cela conduit à des hallucinations—des réponses qui semblent convaincantes mais ne sont pas soutenues par les données sources. Dans un environnement où l'audit, la reproductibilité et la responsabilité sont importants, ce mode de fonctionnement est incompatible avec la production.

Les auteurs de l'article suggèrent de considérer l'évolution de l'IA en trois étapes. La première vague reposait sur la logique symbolique et les règles rigides: ces systèmes étaient déterministes mais trop inflexibles. La deuxième vague, qui inclut les transformateurs modernes, a fourni un énorme bond en fluidité et compréhension du langage, mais a apporté l'imprévisibilité. Artificial Genius appelle son approche la troisième génération: le modèle comprend toujours le langage naturel comme un LLM moderne, mais la réponse finale passe par une logique déterministe et ne doit pas dépasser ce qui existe réellement dans le contexte d'entrée.

Comment Fonctionne le Schéma

La thèse principale d'AWS et Artificial Genius est la suivante: un modèle génératif peut être utilisé de manière strictement non-générative. C'est-à-dire qu'il ne "devine" pas la réponse en fonction de la probabilité du prochain token, mais vérifie si elle peut être extraite du document, et si ce n'est pas le cas—il refuse de répondre. Un tel mode est particulièrement utile pour les questions comme les dates, les montants, les noms, les extraits de rapports ou la confirmation d'un fait spécifique.

Dans l'article, ceci est formulé très directement:

"Si la question ne peut pas être répondue à partir du document, le

modèle doit répondre: 'Unknown'."

• comme modèle de base, ils ont choisi Amazon Nova Lite, car il convient mieux aux réponses courtes et claires sans verbosité inutile;
• le fine-tuning est effectué dans SageMaker via supervised fine-tuning, afin que le modèle suive une règle système—ne rien inventer;
• pour l'entraînement, ils utilisent un ensemble synthétique de questions et réponses, avec des requêtes répondables et intentionnellement non-répondables;
• au lieu du RAG classique, qui reste génératif de toute façon, l'accent est mis sur une connexion plus étroite entre le texte du document et une question spécifique;
• par-dessus, ceci est emballé dans une plateforme d'agents, où une requête libre peut être traduite en une spécification plus stricte, et la seule vérification manuelle reste au stade de cette traduction.

Un détail important: les auteurs contrastent séparément leur méthode avec le conseil familier "mettez la température à zéro." Selon eux, cela ne résout pas le problème fondamental car le modèle continue à générer de toute façon. Dans leur version, ce qui change n'est pas seulement le degré d'aléa, mais la logique même d'utilisation du modèle: la compréhension probabiliste est préservée à l'entrée, tandis qu'à la sortie le système aspire à un mode binaire—répondre seulement avec ce qui est confirmé par le texte, ou honnêtement dire qu'il n'y a pas de réponse.

Ce Que les Tests Ont Montré

Techniquement, le schéma semble plutôt pragmatique et donc intéressant. Les données d'entraînement sont stockées dans Amazon S3, le fine-tuning du modèle Nova de base est effectué dans SageMaker Training Jobs, puis la version personnalisée est importée dans Amazon Bedrock et livrée à l'application via un pipeline d'inférence standard. Pour les équipes d'entreprise, ceci est important non seulement pour la commodité, mais aussi pour la transparence de la lignée des données: il est plus facile de comprendre sur quelles données le modèle a été entraîné, où il a été modifié et comment il a été déployé en production.

L'équipe a également révélé plusieurs conclusions d'ingénierie. Pour le fine-tuning, ils ont utilisé LoRA pour ne pas casser la compréhension du langage de base du modèle. Lors d'expériences précédentes sur un autre modèle, ils ont même dû supprimer de force chain-of-thought via un token de service `</think>`, car le raisonnement détaillé gênait les réponses déterministes concises. Pour la version Nova Lite, les auteurs ont combiné LoRA dropout à un niveau de 50%, early stopping manuel et expansion de l'ensemble de données synthétique à 30 mille exemples. Selon leurs données, cela a réduit la fréquence des hallucinations de fractions de pourcentage dans les configurations initiales à 0,03% dans la meilleure variante.

Ce Que Cela Signifie

L'histoire n'importe pas seulement aux utilisateurs d'AWS. Elle montre un changement plus large: le marché commence à chercher non pas seulement les LLM "les plus intelligents", mais les modèles avec des limites de comportement définies par l'ingénierie. Pour les banques, les assureurs, les cliniques et la legal-tech, c'est un signal que la mise en œuvre de l'IA sera de plus en plus construite autour de la vérifiabilité, du refus de réponse et des flux de travail contrôlés, plutôt qu'autour de la belle génération à tout prix.