Meilleures pratiques pour contrôler les hallucinations LLM au niveau de l'application

Les grands modèles de langage (LLM) offrent un potentiel de transformation pour la création d'applications, mais posent un défi majeur en matière d'hallucinations. Découvrez des stratégies pratiques, axées sur l'ingénierie, pour créer des fonctionnalités fiables intégrant les LLM.

Les grands modèles de langage (LLM) sont intégrés aux applications à un rythme effréné, promettant de révolutionner l'expérience utilisateur. Mais comme vous le dira toute équipe travaillant en première ligne, cela s'accompagne d'un défi majeur : les hallucinations.

La capacité d'un LLM à inventer, extrapoler et fabriquer des informations avec assurance n'est pas un défaut à corriger, mais une caractéristique fondamentale de sa créativité. Pour les développeurs, cela signifie que nous ne pouvons pas nous contenter d'espérer qu'un modèle ne s'égarera pas cette fois-ci et d'espérer le meilleur. Nous devons construire des systèmes qui anticipent ce comportement et le contrôlent au niveau de l'application.

Chez Parasoft, tandis que intégration des LLM Dans nos produits de tests logiciels, nous avons rencontré le défi de gérer les hallucinations. Lors d'un premier projet interne, nous avons fourni à un LLM des informations synthétisées à partir d'une définition de service OpenAPI et lui avons demandé de créer des scénarios à partir de données connexes. Apis. Comme l'a noté l'un de nos ingénieurs : « Il répondait parfois avec deux API réelles et une inventée. »

Sans aucune protection, les LLM sont imprévisibles, ce qui rend les applications qui en dépendent peu fiables.

Dans ce blog, je souhaite partager quelques stratégies pratiques, axées sur l'ingénierie, que nos équipes ont développées pour créer des fonctionnalités fiables basées sur le LLM.

1. Définissez des limites dans vos invites

La première ligne de défense contre les hallucinations est le déclencheur lui-même, et l’approche la plus efficace est souvent la plus directe.

Une technique très simple consiste à donner au LLM des règles fondamentales sur son comportement, par exemple en lui demandant de ne pas inventer d'informations. Par exemple, vous pouvez utiliser des invites telles que :

• « Veuillez répondre uniquement à partir des informations que j'ai fournies. »
• « S'il vous plaît, ne créez pas de nouveaux éléments qui n'étaient pas là. »

Cette approche agit comme un garde-fou principal. Elle empêche le modèle de s'en remettre à ses tendances créatives et ancre sa réponse dans le contexte spécifique que vous avez fourni.

Jusqu'à présent, nous avons trouvé que c'était une façon simple de commencer à gérer les hallucinations à la source. De plus, les LLM prennent en charge un paramètre appelé « température » qui contrôle la créativité du modèle. Lorsque la cohérence et la précision sont importantes, réglez la température du modèle sur une valeur basse (~0) et augmentez-la uniquement lorsque vous avez besoin d'une plus grande créativité du LLM. Soyez toutefois direct et indiquez-lui exactement ce que vous souhaitez.

2. Appliquer la structure de sortie avec des schémas

Des instructions claires constituent un bon début, mais pour une fiabilité optimale, il est essentiel de les appliquer. Il s'agit de passer de l'expression « dictée » au LLM à la « contrainte » programmatique à respecter un format de sortie spécifique à l'aide de sorties structurées.

La plupart des principaux fournisseurs de modèles vous permettent de définir un schéma JSON obligatoire dans votre appel d'API. Ce schéma indique au modèle le format spécifique des données à traiter, grâce à une fonctionnalité appelée « sorties structurées ». Cela contraint la réponse du modèle et garantit qu'elle respecte les champs, les types de données et la structure définis, afin que votre code puisse s'appuyer sur ce format spécifique.

Par exemple, lorsque nous demandons à un modèle de générer un tableau de données, nous utilisons un schéma comme celui-ci :

JSON

"data": {

  "type": "object",

  "description": "The generated data table based on user requirements.",

  "properties": {

    "columnNames": {

      "type": "array",

      "description": "Header row of the table containing the column names.",

      "items": { "type": "string" }

    },

    "generatedDataRows": {

      "type": "array",

      "items": {

        "type": "array",

        "description": "A row of data with the generated values for each column.",

        "items": { "type": "string" }

      }

    }

  }

}

Cela garantit que le modèle renvoie un objet JSON propre contenant un columnNames tableau et un generatedDataRows Tableau : il ne s'agit pas d'un paragraphe non structuré ni d'un JSON mal formé. L'utilisation de sorties structurées est devenue essentielle lorsque nous avons constaté que le LLM renvoyait une réponse qui ne contenait pas les données dans un format exploitable par programmation.

Pour gérer les modèles qui ne prennent pas en charge les sorties structurées, nous avons découvert que nous pouvons inclure le schéma JSON dans l'invite système elle-même, ce qui ne garantit pas la sortie attendue mais constitue une solution de secours étonnamment efficace.

3. Fonder les réponses sur des preuves externes (récupération-génération augmentée)

Bien que les instructions directes et les résultats structurés vous donnent le contrôle sur l'invite et le format de sortie, vous devez également contrôler les connaissances que le LLM utilise pour générer sa réponse.

Au lieu de laisser le modèle s'appuyer uniquement sur ses vastes données d'entraînement internes, parfois obsolètes, vous pouvez l'appuyer sur des connaissances du domaine grâce à la technique de génération augmentée par récupération (RAG). Cette technique intègre une étape supplémentaire pour améliorer les résultats du LLM en ajoutant des informations provenant de sources de connaissances externes avant de générer une réponse.

En fournissant des informations supplémentaires spécifiques au domaine, vous modifiez la tâche : « Récupérer une réponse de votre mémoire générale » en « Obtenir une réponse à partir de ces faits spécifiques ». Cela réduit considérablement les hallucinations.

Par exemple, au lieu de demander au modèle de nommer les API associées à partir de la mémoire (où il pourrait en inventer une), une technique RAG récupérerait d'abord les définitions réelles des API valides, puis demanderait au LLM de les résumer.

Cela ancre le modèle dans un contexte pertinent et maintient les informations à jour.

4. Diviser la logique complexe en agents distincts

Une erreur fréquente lors du travail avec les LLM est de créer des invites complexes, remplies de logique conditionnelle, en essayant de « scripter » le LLM pour qu'il se comporte différemment selon les conditions. Ce type d'explications excessives perturbe souvent les LLM, les amenant à se concentrer sur des informations erronées et à produire des résultats inattendus. Et même si une invite complexe fonctionne pour un modèle, elle peut ne pas fonctionner pour d'autres.

Nous avons constaté qu'une meilleure stratégie consiste à scinder le workflow en agents plus petits, chacun sachant comment effectuer une tâche spécifique. À mesure que le workflow progresse, le contrôle est transféré entre les agents en fonction des données saisies par l'utilisateur et de l'étape suivante. Au lieu de tenter de contrôler le comportement du modèle avec une seule invite, vous répartissez le comportement entre les différents agents. Cela permet au LLM de se concentrer sur la tâche spécifique à accomplir à chaque étape.

5. Vérification automatisée

Même avec des invites directes simples et un RAG, un LLM peut mal interpréter le matériel source ou déformer la vérité. La couche de défense suivante est une étape de « confiance, mais vérification » qui vérifie les résultats du modèle avant de poursuivre le flux de travail.

Les LLM « juges » légers peuvent comparer les résultats du LLM aux informations récupérées utilisées dans RAG afin d'attribuer un score de confiance. Les résultats inférieurs à un seuil spécifique sont présentés au LLM de manière différente, voire automatiquement rejetés, ce qui permet de poursuivre le processus avec le contenu déjà validé.

Une autre technique consiste à utiliser des filtres de post-traitement basés sur des règles qui valident le résultat du LLM par rapport aux attentes connues. Il est important de préciser que ces vérifications ne jugent pas la qualité sémantique du La réponse de l'IA, par exemple, en demandant : « Est-ce une bonne idée ? » Au lieu de cela, ils valident son intégrité structurelle ou le contenu de son résultat.

Comme l'a expliqué l'un de nos ingénieurs, il est essentiel de « vérifier la réponse par le code ». Cela garantit que le résultat est conforme aux règles métier connues avant d'être utilisé par l'application.

6. Vérifiez avec un humain dans la boucle

Les techniques que nous avons mentionnées peuvent vous aider à réduire les hallucinations, mais en fin de compte, vous devez souvent intégrer une surveillance humaine dans le flux de travail pris en charge par le produit, afin que l'utilisateur ait la décision finale sur ce qui est produit.

La nécessité de cette mesure dépend de la gravité des conséquences d'informations erronées. Dans certains cas, une intervention humaine peut être requise sous certaines conditions, sur la base d'une validation automatisée des résultats du LLM, comme mentionné précédemment.

Pour solliciter les retours humains, nous mettons en œuvre un processus agentique en plusieurs étapes qui sollicite l'intervention humaine à différents moments du processus. Notre agent de création de scénarios de test en est un excellent exemple :

1. Triage. La demande d'un utilisateur (« créer un nouveau scénario de test ») est acheminée vers l'agent de création de test spécialisé.
2. Clarification. L'agent interagit avec l'utilisateur pour collecter les entrées nécessaires, comme une URL de définition de service.
3. Proposition. L'agent propose un plan des tests qu'il va créer et demande l'approbation de l'utilisateur.
4. Exécution. Ce n'est qu'après que l'utilisateur a cliqué sur « Approuver » que le scénario de test est généré et enregistré.

Ce modèle de proposition puis d’exécution donne à l’utilisateur le contrôle final, créant un point de contrôle crucial qui empêche le système d’agir sur une hallucination plausible qui est incorrecte.

Construire pour la réalité ajoute de la fiabilité et réduit le stress

Contrôler les hallucinations ne consiste pas à trouver une seule formule magique. Il s'agit de construire un système de défense multicouche au sein de votre application, basé sur des techniques telles que celles que nous avons mentionnées.

Les LLM étant susceptibles de présenter des hallucinations, il est nécessaire de mettre en place une série de défenses pour garantir des résultats fiables. En combinant des instructions résilientes, des schémas imposés et un processus de vérification robuste, vous pouvez passer de l'espoir qu'un LLM se comporte correctement à la conception d'un système capable de compenser d'éventuels dysfonctionnements et de produire des résultats fiables.

À mesure que la technologie évolue, ces garde-fous au niveau des applications pourraient changer. En attendant, gardez-les à l'esprit pour optimiser la fiabilité des LLM lors de leur intégration à vos applications.