Élimination des hallucinations dans les agents virtuels pilotés par LLM

Découvrez comment AI Studio de Vonage élimine les hallucinations LLM à l'aide de champs de raisonnement structurés et de raffinements de l'ordre des schémas.

Introduction

Vonage AI Studio est une plateforme low-code permettant de créer et de gérer des agents virtuels sur les canaux vocaux et numériques, l'IA opérant en coulisses pour comprendre les utilisateurs et piloter des conversations intelligentes. Depuis de nombreuses années, cette plateforme n'a cessé de faire évoluer son moteur NLUpassant d'approches basées sur des mots clés à des modèles basés sur des embeddings, et aujourd'hui à une compréhension alimentée par LLM, au fur et à mesure de l'adoption de nouvelles technologies.

Notre plateforme d'agents virtuels permet aux organisations de configurer des agents conversationnels qui détectent les intentions, extraient les paramètres, valident les entrées de l'utilisateur et guident les conversations. Le LLM sous-jacent reçoit le contexte de la conversation ainsi que les intentions configurées, les paramètres et les règles de validation, et renvoie une sortie JSON structurée qui détermine la prochaine étape de la conversation. Au fur et à mesure que le système se développait, nous avons rencontré à plusieurs reprises des hallucinations LLM, des sorties qui n'étaient pas fondées sur la configuration ou l'entrée de l'utilisateur, ce qui a provoqué une instabilité et un comportement imprévisible.

Ce billet de blog explique les améliorations introduites pour renforcer la précision, la stabilité et la fiabilité des résultats du LLM. Il décrit les défis rencontrés, les changements appliqués et la manière dont ces ajustements ont amélioré la qualité globale des réponses du système.

Error rate comparison before and after introducing structured reasoning: 23.7% of responses were incorrect before changes, dropping to just 1.0% after.

Comprendre le problème : comment les hallucinations du LLM font dérailler les agents virtuels

Les LLM peuvent générer des réponses fluides qui semblent correctes, même si elles ne sont pas fondées sur la configuration du système ou sur les données fournies par l'utilisateur. Cela conduit souvent à des hallucinations, des situations dans lesquelles l'agent accepte avec confiance des données non valides ou invente des capacités qui n'existent pas. Les exemples suivants illustrent ce problème.

Exemple 1 : Lorsque l'agent accepte une saisie invalide de la part de l'utilisateur

Description du problème :

Les ID de réservation est défini de manière à respecter un format strict :

3 lettres majuscules suivies de 3 chiffres.

Dans ce scénario, l'agent n'applique pas cette règle, alors que l'utilisateur ne fournit que deux lettres de l'identifiant au lieu de trois

Conversation :

Utilisateur : Annuler ma réservation

Agent : Pour procéder à l'annulation, j'ai besoin de votre numéro de réservation. Pouvez-vous me le fournir ?

Utilisateur : son ab1234

Agent : Je vois que votre numéro de réservation est AB1234. Est-ce exact ?

Dans ce cas, l'agent normalise et confirme de manière incorrecte une valeur non valide au lieu d'appliquer les règles de format définies.

Exemple 2 : Halluciner des intentions et des paramètres qui n'existent pas

Description du problème :

Le système ne comprend pas d'intention de d'extraire résultats d'analyses de sangIl ne définit pas non plus de paramètre appelé ID pour un tel flux, mais le LLM a toujours l'impression que cette fonctionnalité et ce paramètre existent.

Conversation :

Utilisateur : J'aimerais obtenir les résultats de mes analyses de sang

Agent : Oui, je peux localiser les résultats de votre récent test sanguin. Veuillez me fournir votre pièce d'identité pour que je puisse continuer.

L'agent fabrique à la fois une capacité prise en charge et un paramètre requis, créant ainsi une interaction trompeuse qui peut sérieusement affecter la confiance de l'utilisateur.

Les LLM doivent souvent générer des réponses en utilisant des informations provenant de différentes parties de l'invite, telles que les instructions du système, les entrées de l'utilisateur et les règles spécifiques à la tâche. Lorsque ce contexte est dispersé, incohérent ou dépend de données utilisateur dynamiques (comme des formats de paramètres changeants), le modèle est plus susceptible de commettre des erreurs.

Pourquoi les hallucinations surviennent-elles ? Principales causes sous-jacentes

Pour mieux comprendre les raisons de ces défaillances, nous pouvons les décomposer en plusieurs causes sous-jacentes qui sont apparues à plusieurs reprises au cours de notre analyse.

Cause n° 1 : Confusion due à un contexte complexe ou mixte

Il se peut que les LLM ne parviennent pas à connecter correctement toutes les pièces requises. Les problèmes les plus courants sont les suivants :

• Sélection de la mauvaise intention de l'utilisateur.

• Application incorrecte de la validation.

• Générer des résultats qui contredisent l'analyse précédente, ou halluciner des instructions ou des formats de paramètres manquants.

Plus le message est complexe et fragmenté, plus ces problèmes sont susceptibles de se poser.

Cause n°2 : un raisonnement invisible conduit à des défaillances cachées

Les LLM génèrent du texte étape par étape, mais leur raisonnement reste interne. S'ils font une mauvaise hypothèse au début, le résultat final sera erroné, sans explication visible. Un réglage rapide ne suffit pas à résoudre ce problème. À moins que le modèle ne soit forcé de montrer son raisonnement, les hallucinations ne peuvent pas être tracées ou évitées

Cause n° 3 : Équilibrer le contrôle et la capacité de raisonnement du modèle

Les applications du monde réel exigent des résultats structurés et prévisibles qui peuvent être analysés ou exécutés. En même temps, la recherche montre que contraintes de sortie strictescomme l'application de la cohérence du formatpeuvent supprimer la capacité de raisonnement du modèle et réduire la précision de la tâche. Trouver l'équilibre entre le contrôle et la flexibilité est essentiel, mais reste un défi ouvert. Ce compromis est particulièrement pertinent dans les environnements d'entreprise, où la fiabilité et la sécurité d'exécution sont aussi importantes que la créativité du modèle.

La solution : Structurer et ordonner le raisonnement LLM pour des résultats fiables

1. Guidage des LLM avec des champs de raisonnement auxiliaires

Empêcher les LLM de déraper ne se résume pas à une simple mise au point. Nous avons dû modifier comment Nous avons dû changer la façon dont le modèle aborde la génération d'une réponse en premier lieu. Au lieu de laisser le LLM passer directement à une réponse, nous le guidons maintenant pour qu'il raisonne à travers le problème étape par étape, en utilisant des champs structurés, avant qu'il ne produise un résultat que le système consomme réellement.

A l'origine, le schéma de réponse LLM ne comprenait que des champs opérationnels, qui étaient soit post-traités par le système, soit renvoyés directement à l'utilisateur. Pour renforcer le raisonnement du modèle et concentrer son attention sur les instructions les plus critiques de l'invite du système, nous avons élargi le schéma pour inclure des champs de raisonnement explicites et structurés qui doivent être générés en premier.

Ces champs de raisonnement sont internes au moteur de l'agent et ne sont jamais exposés aux utilisateurs finaux. Ils ne sont pas consommés directement par le système. Cependant, en exigeant leur présence, nous encourageons le modèle à analyser d'abord le contexte, à identifier les contraintes clés et à extraire les signaux pertinents avant de produire un résultat final exploitable. Dans la pratique, cela permet de transformer un raisonnement précédemment caché en données structurées et inspectables, et d'améliorer considérablement la fiabilité des résultats.

Ci-dessous, nous présentons des exemples avant et après qui démontrent l'impact de ce changement.

2. Ordonnancement des schémas : Petit changement, grand impact sur le comportement du LLM

À première vue, la réorganisation des champs JSON semble insignifiante, puisque JSON n'a pas de notion sémantique d'ordre. Mais les LLM n'interprètent pas JSON de manière structurelle. Ils le génèrent comme du texte brut, un jeton à la fois, en se basant sur tout ce qui précède.

C'est pourquoi l'ordre des champs est important. Les premiers champs façonnent le contexte interne du modèle et le cheminement du raisonnement, tandis que les champs générés ultérieurement sont plus susceptibles de dériver ou d'être incohérents. En plaçant les champs de raisonnement au tout début du schéma et en contrôlant soigneusement l'ordre général des champs, nous guidons le modèle pour qu'il "réfléchisse avant d'agir".

Ce petit changement structurel a un effet étonnamment important. Le modèle est encouragé à analyser d'abord les données d'entrée et les contraintes, puis à produire les champs opérationnels sur lesquels le système s'appuie. La réorganisation du schéma et l'introduction de champs de raisonnement explicites permettent d'aligner le processus de génération du modèle sur les attentes réelles du système, ce qui se traduit par des résultats plus cohérents et plus prévisibles.

Exemple 1 amélioré : application efficace des formats de paramètres

Conversation :

Utilisateur : Annuler ma réservation

Agent : Pour procéder à l'annulation, j'ai besoin de votre numéro de réservation. Pouvez-vous me le fournir ?

Utilisateur : son ab1234

Agent : L'identifiant de réservation doit contenir 3 lettres suivies de 3 chiffres. Veuillez fournir un numéro de réservation valide.

Ce qui a changé :

• L'agent ne normalise ni ne confirme plus les données non valides

• Les règles de format sont strictement appliquées

• L'utilisateur est guidé pour corriger l'entrée avant que le flux ne continue.

Exemple 2 amélioré : blocage des intentions et des paramètres hallucinés

Conversation :

Utilisateur : J'aimerais obtenir les résultats de mes analyses de sang

Agent : Désolé, je ne suis pas en mesure de récupérer les résultats des tests médicaux ou de demander une pièce d'identité pour cette action. Je peux vous aider à gérer vos rendez-vous, et pour toute autre demande, je peux vous diriger directement vers la clinique.

Ce qui a changé :

• L'agent n'invente plus de capacités non prises en charge

• Aucun paramètre indéfini (tel que "ID") n'est demandé.

• La réponse est alignée sur les capacités réelles du système

Et si vous vous demandez à quoi cela ressemble dans les coulisses :

Côte à côte : schéma halluciné ou raisonné

Avant le schéma de réponse JSON (Hallucination-Prone)

{
  "detected_intent": {
    "id": null,
    "name": null
    
  },
  "generated_answer": 
  {
    "answer": "Yes, I can locate your recent blood test results. Please provide your ID so I can proceed."
    
  }
}

Après le schéma de réponse JSON (avec les champs de raisonnement auxiliaires)

{
  "detected_intent": {
    "id": null,
    "name": null
    
  },
  "generated_answer": {
    "evidence_from_prompt": "Supported intents: Book Appointment Reschedule Appointment, Cancel Appointment, Manage Appointments."
    "intents_i_am_familiar_with": [
      "Book Appointment",
      "Reschedule Appointment",
      "Cancel Appointment",
      "Manage Appointments"
    ],
    "out_of_scope_request": true,
    "answer": "Sorry, I’m not able to retrieve medical test results or request identification for this action. I can help you manage your appointments, and for any other requests, I can route you directly to the clinic."
  }
}

En ajoutant les nouveaux champs de raisonnement : evidence_from_prompt,intents_i_am_familiar_with, out_of_scope_requestle LLM est tenu d'analyser les données de l'utilisateur et la configuration avant de avant de produire la réponse finale. Cela oblige le modèle à réfléchir aux contraintes, à comprendre les limites du scénario et à fonder sa réponse sur des preuves explicites, ce qui permet d'obtenir des réponses plus claires, plus précises et plus contrôlées.

Validation des paramètres : Raffinement du schéma pour une saisie précise par l'utilisateur

Avant le schéma de réponse JSON (réponse d'abord, analyse ensuite)

{
  "generated_answer": {
    "answer": "I see that your booking ID is AB1234. Is that correct?",
    "answer_refer_to_parameter_id": "Booking_id",
    
  },
  "message_content": "its ab1234",
  "parameters": [
    {
      "parameter_id": "Booking_id",
      "parameter_value": "AB1234",
      
    }
    ]
}

Après (Champs de l'ordre de modification et de l'ajout de motifs)

{
  "user_messages_analysis": {
    "message_content": "its ab1234",
    "current_intent": "Cancel_Reservation",
    "parameters": [
      {
        "parameter_id": "Booking_id",
        "parameter_value_format": "3 letters followed by 3 numbers (e.g., ABC123)",
        "parameter_value_format_regex": "^[A-Z]{3}[0-9]{3}$",
        "parameter_extracted_part": "ab1234",
        “simulate_regex_execution”:false
        
      }
      ]
    
  },
  "generated_answer": {
    "evidence_from_prompt": "Booking_id format: 3 letters followed by 3 numbers (e.g., ABC123).",
    "answer": "The booking ID should contain 3 letters followed by 3 numbers. Please provide a valid booking ID.",
    "answer_refer_to_parameter_id": "Booking_id",
    
  }
}

Ensemble, ces champs exigent que le modèle valide le paramètre extrait, le vérifie par rapport au format attendu et indique explicitement si la valeur est acceptable avant de produire la réponse finale. Cela garantit que la réponse est entièrement fondée sur les étapes de raisonnement du modèle et évite les cas où le MLD confirme en toute confiance un paramètre non valide ou fait avancer la conversation sur la base d'hypothèses incorrectes.

Nous avons été satisfaits des résultats de ces actions, mais nous sommes restés préoccupés par les dérives potentielles dans la validation du format des paramètres. Pour y remédier, nous avons introduit une couche de validation mesurable qui surveille les taux d'extraction et détecte les cas où le LLM interprète encore mal les règles de format en langage naturel.

Renforcer la précision des formats de paramètres avec la validation Regex

L'ajout de paramètres de raisonnement auxiliaires et la réorganisation du schéma ont apporté des améliorations significatives. Néanmoins, nous visions deux objectifs supplémentaires :

1. une précision proche de 100 % dans l'application du format des paramètres, et

2. en bénéficiant d'un suivi rigoureux de la production afin de détecter si des ajustements supplémentaires sont nécessaires.

Pour atteindre ces objectifs, nous avons utilisé un processus de validation en plusieurs étapes.

Étape 1 : LLM génère une expression rationnelle à partir d'une description

Comme expliqué dans la section précédente, une partie des champs de raisonnement auxiliaires doit être produite par le LLM :

• parameter_value_format: Une description lisible par l'homme

• parameter_value_format_regex: Un motif regex généré à partir de la description en texte libre

• simulate_regex_execution: L'évaluation par le LLM de la conformité de la valeur extraite avec le motif de la regex.

Cela oblige le LLM à traduire le langage naturel dans un format vérifiable par une machine.

Étape 2 : LLM valide sa propre expression rationnelle (simulation)

Dans le cadre de son raisonnement, le modèle répond "simulate_regex_execution": true | falseen indiquant si s'il pense que que la regex fonctionne. Cela a déjà permis d'augmenter la précision de manière significative.

Étape 3 : Vérification finale des expressions rationnelles côté système pour garantir l'exactitude des données

Pour garantir la précision, une autre couche de vérification a été ajoutée après la réception de la réponse du LLM : le système réexécute indépendamment la regex générée à partir du champ parameter_value_format_regex (avec des garde-fous pour éviter les modèles non sûrs). Si la regex ne correspond pas, même si le LLM indique qu'elle devrait correspondre, l'agent rejette la valeur et guide l'utilisateur pour qu'il la corrige.

Cette approche hybride, qui combine le raisonnement LLM et la validation programmatique, a permis d'obtenir une précision quasi parfaite dans l'application du format des paramètres et de résoudre les dernières incohérences que nous avons observées.

Cette validation nous fournit une métrique mesurable pour suivre la performance du LLM dans le temps. Chaque fois que le LLM prédit que la regex devrait correspondre (simulate_regex_execution = true) mais que l'exécution de la regex côté système échoue, nous détectons immédiatement l'écart. Nous nous attendons à ce que ces cas restent extrêmement rares, et si une tendance à la hausse apparaît, elle sert d'indicateur précoce d'une dérive ou d'une dégradation du comportement du LLM.

Évaluation : Dans quelle mesure les changements ont-ils été utiles ?

Pour évaluer l'effet du nouveau schéma de raisonnement, nous avons créé un agent virtuel pour une clinique médicale et généré 97 phrases intentionnellement hors du champ d'application. Pour chacune d'entre elles, le comportement correct était :

• intention = null, et

• La réponse générée doit rejeter poliment la demande

• Minimiser les cas où simuler_exécution_regex = true mais que l'exécution de la regex côté système échoue.

Nous avons effectué une comparaison pour évaluer l'impact de l'introduction des champs de raisonnement :

Ne pas nuire aux vrais positifs

Nous avons également validé les cas où l'agent virtuel devrait détecter une intention. La détection des vrais positifs (TP) est restée inchangéepas de baisse, pas de dégradation. La nouvelle couche de raisonnement réduit les hallucinations sans sans affaiblir la détection des intentions correctes.

Avant et après

Il n'y a eu aucun cas où le LLM a prédit simuler_exécution_regex = vrai alors que l'exécution de la regex côté système a échoué. En d'autres termes, toutes les améliorations ont été réalisées par le LLM lui-même.

Des schémas similaires ont été observés pour d'autres tâches que le LLM doit générer.

Résultats : Ce que nous avons appris et ce qui a changé

L'introduction de champs de raisonnement explicites, la restructuration du schéma de réponse et l'ajout d'une exécution regex côté système ont eu un effet positif significatif sur le comportement global du LLM. Ces changements ont considérablement réduit les hallucinations et les réponses hors de portée, tout en préservant la capacité du modèle à identifier correctement les entrées valides. En conséquence, les résultats du LLM sont devenus plus cohérents, prévisibles et mieux alignés sur la configuration et la logique prévues.

Au fur et à mesure que ce travail évolue, nous continuons à chercher des moyens de rendre le raisonnement et les décisions de notre système plus explicables, à la fois pour soutenir les cas d'utilisation dans le monde réel et pour soutenir une gouvernance forte de l'IA.

A high-level overview of the reasoning structure and validation pipeline added to improve LLM response reliability and reduce hallucinations.