Beseitigung von Halluzinationen in LLM-gesteuerten virtuellen Agenten

Erfahren Sie, wie Vonage AI Studio LLM-Halluzinationen mithilfe von strukturierten Argumentationsfeldern und Schemareihenfolgeverfeinerungen beseitigt.

Einführung

Vonage AI Studio ist eine Low-Code-Plattform für den Aufbau und die Verwaltung virtueller Agenten über Voice- und digitale Kanäle, wobei KI im Hintergrund arbeitet, um die Benutzer zu verstehen und intelligente Gespräche zu führen. Seit vielen Jahren hat diese Plattform ihre NLU-Enginevon schlagwortbasierten Ansätzen zu einbettungsbasierten Modellen und heute zu LLM-basiertem Verständnis, da im Laufe der Zeit neue Technologien eingeführt wurden.

Mit unserer Plattform für virtuelle Agenten können Unternehmen Konversationsagenten konfigurieren, die Absichten erkennen, Parameter extrahieren, Benutzereingaben validieren und Konversationen leiten. Der zugrundeliegende LLM empfängt den Gesprächskontext zusammen mit den konfigurierten Absichten, Parametern und Validierungsregeln und gibt eine strukturierte JSON-Ausgabe zurück, die den nächsten Gesprächsschritt bestimmt. Als das System wuchs, stießen wir immer wieder auf LLM-Halluzinationen, d. h. auf Ausgaben, die nicht auf der Konfiguration oder den Benutzereingaben beruhten, was zu Instabilität und unvorhersehbarem Verhalten führte.

In diesem Blogbeitrag werden die Verbesserungen erläutert, die eingeführt wurden, um die Ausgabegenauigkeit, Stabilität und Zuverlässigkeit des LLM zu verbessern. Er beschreibt die Herausforderungen, mit denen wir konfrontiert waren, die vorgenommenen Änderungen und wie diese Anpassungen die Gesamtqualität der Antworten des Systems verbessert haben.

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

Das Problem verstehen: Wie LLM-Halluzinationen virtuelle Agenten entgleisen lassen

LLMs können fließende Antworten erzeugen, die korrekt erscheinen, auch wenn sie nicht auf der Systemkonfiguration oder den Benutzereingaben beruhen. Dies führt häufig zu Halluzinationen, d. h. zu Situationen, in denen der Agent selbstbewusst ungültige Daten annimmt oder Fähigkeiten erfindet, die nicht existieren. Die folgenden Beispiele veranschaulichen dieses Problem.

Beispiel 1: Wenn der Agent ungültige Benutzereingaben annimmt

Problembeschreibung:

Die Buchungs-ID ist so definiert, dass er einem strengen Format folgt:

3 Großbuchstaben, gefolgt von 3 Ziffern.

In diesem Szenario setzt der Agent diese Regel nicht durch, während der Benutzer nur zwei statt drei Buchstaben der ID angibt

Gespräch:

Benutzer: Meine Reservierung stornieren

Agent: Um mit der Stornierung fortzufahren, benötige ich Ihre Buchungs-ID. Könnten Sie diese bitte angeben?

Benutzer: seine ab1234

Agent: Ich sehe, dass Ihre Buchungsnummer AB1234 lautet. Ist das korrekt?

In diesem Fall normalisiert der Agent fälschlicherweise einen ungültigen Wert und bestätigt ihn, anstatt die definierten Formatregeln einzuhalten.

Beispiel 2: Halluzinieren von Absichten und Parametern, die es nicht gibt

Problembeschreibung:

Das System enthält keine Funktion zum Abrufen von Bluttestergebnisseund es definiert auch keinen Parameter namens ID für einen solchen Fluss, aber der LLM halluziniert trotzdem, dass diese Funktionalität und dieser Parameter existieren.

Gespräch:

Benutzer: Ich möchte meine Bluttestergebnisse erhalten

Agent: Ja, ich kann die Ergebnisse Ihrer letzten Blutuntersuchung finden. Bitte geben Sie Ihren Ausweis an, damit ich fortfahren kann.

Der Agent fälscht sowohl eine unterstützte Fähigkeit als auch einen erforderlichen Parameter, wodurch eine irreführende Interaktion entsteht, die das Vertrauen der Benutzer ernsthaft beeinträchtigen kann.

LLMs müssen häufig Antworten unter Verwendung von Informationen aus verschiedenen Teilen der Eingabeaufforderung generieren, wie Systemanweisungen, Benutzereingaben und aufgabenspezifische Regeln. Wenn dieser Kontext verstreut oder inkonsistent ist oder von dynamischen Benutzerdaten abhängt (z. B. wechselnde Parameterformate), ist die Wahrscheinlichkeit größer, dass das Modell Fehler macht.

Warum Halluzinationen auftreten: Die wichtigsten zugrunde liegenden Ursachen

Um besser zu verstehen, warum diese Fehler auftreten, können wir sie in mehrere Ursachen aufteilen, die bei unserer Analyse immer wieder auftauchten.

Ursache Nr. 1: Verwirrung aufgrund eines komplexen oder gemischten Kontextes

Bei LLMs kann es vorkommen, dass nicht alle erforderlichen Teile korrekt verbunden werden. Häufige Probleme sind:

• Auswahl der falschen Nutzungsabsicht.

• Falsche Anwendung der Validierung.

• Generierung von Ausgaben, die früheren Analysen widersprechen, oder Halluzinationen über fehlende Anweisungen oder Parameterformate.

Je komplexer und fragmentierter die Eingabeaufforderung ist, desto wahrscheinlicher werden diese Probleme.

Ursache Nr. 2: Unsichtbare Gründe führen zu versteckten Fehlern

LLMs erzeugen Text Schritt für Schritt, aber ihre Überlegungen bleiben intern. Wenn sie zu Beginn eine falsche Annahme treffen, wird die endgültige Ausgabe falsch sein, ohne dass es eine sichtbare Erklärung gibt. Promptes Tuning allein reicht nicht aus, um dies zu beheben. Solange das Modell nicht gezwungen wird, seine Überlegungen darzulegen, können Halluzinationen nicht nachvollzogen oder verhindert werden.

Ursache Nr. 3: Gleichgewicht zwischen Kontrolle und Modellierungsfähigkeit

Anwendungen in der realen Welt erfordern strukturierte, vorhersehbare Ausgaben, die geparst oder ausgeführt werden können. Gleichzeitig zeigt die Forschung, dass strenge Ausgabebeschränkungen, wie Erzwingen von Formatkonsistenzdie Argumentationsfähigkeit des Modells unterdrücken und die Genauigkeit der Aufgabe verringern können. Das Gleichgewicht zwischen Kontrolle und Flexibilität zu finden, ist entscheidend, aber immer noch eine offene Herausforderung. Dieser Kompromiss ist besonders in Unternehmensumgebungen wichtig, wo Zuverlässigkeit und sichere Ausführung ebenso wichtig sind wie die Kreativität des Modells.

Die Lösung: Strukturierung und Anordnung von LLM-Reasoning für verlässliche Ergebnisse

1. Leiten von LLMs mit Hilfsbegründungsfeldern

Um zu verhindern, dass die LLMs vom Weg abkommen, war mehr als nur eine schnelle Abstimmung erforderlich. Wir mussten ändern wie wie das Modell überhaupt eine Antwort erzeugt. Anstatt das LLM direkt zu einer Antwort springen zu lassen, leiten wir es nun an, das Problem Schritt für Schritt zu durchdenken, indem wir strukturierte Felder verwenden, bevor es eine Ausgabe erzeugt, die das System tatsächlich verbraucht.

Ursprünglich enthielt das LLM-Antwortschema nur operative Felder, die entweder vom System nachbearbeitet oder direkt an den Benutzer zurückgegeben wurden. Um die Argumentation des Modells zu stärken und seine Aufmerksamkeit auf die wichtigsten Anweisungen in der Systemaufforderung zu lenken, haben wir das Schema um explizite, strukturierte Argumentationsfelder erweitert, die zuerst generiert werden müssen.

Diese Argumentationsfelder sind intern in der Agenten-Engine enthalten und werden den Endbenutzern nicht angezeigt. Sie werden nicht direkt vom System konsumiert. Indem wir jedoch ihr Vorhandensein vorschreiben, ermutigen wir das Modell, zunächst den Kontext zu analysieren, wichtige Einschränkungen zu identifizieren und relevante Signale zu extrahieren, bevor es die endgültige, umsetzbare Ausgabe produziert. In der Praxis werden dadurch zuvor verborgene Überlegungen in strukturierte, überprüfbare Daten umgewandelt und die Zuverlässigkeit der Ergebnisse erheblich verbessert.

Im Folgenden zeigen wir anhand von Vorher-Nachher-Beispielen, wie sich diese Änderung auswirkt.

2. Schema-Bestellung: Kleine Änderung, große Auswirkung auf das LLM-Verhalten

Auf den ersten Blick erscheint die Neuordnung von JSON-Feldern unbedeutend, da JSON keine semantische Vorstellung von Ordnung hat. Aber LLMs interpretieren JSON nicht strukturell. Sie erzeugen es als reinen Text, ein Token nach dem anderen, basierend auf allem, was vorher kam.

Aus diesem Grund ist die Reihenfolge der Felder wichtig. Die ersten Felder prägen den internen Kontext und den Argumentationspfad des Modells, während die später erzeugten Felder anfälliger für Abweichungen oder Inkonsistenzen sind. Indem wir die schlussfolgernden Felder ganz am Anfang des Schemas platzieren und die gesamte Feldreihenfolge sorgfältig kontrollieren, leiten wir das Modell dazu an, "zu denken, bevor es etwas tut".

Diese kleine strukturelle Änderung hat eine erstaunlich große Wirkung. Das Modell wird dazu angehalten, zuerst die Eingaben und Einschränkungen zu analysieren und erst dann die operativen Felder zu erzeugen, auf die sich das System verlässt. Durch die Neuordnung des Schemas und die Einführung expliziter Argumentationsfelder wird der Generierungsprozess des Modells mit den tatsächlichen Erwartungen des Systems in Einklang gebracht, was zu konsistenteren und vorhersehbareren Ergebnissen führt.

Verbessertes Beispiel 1: Effektive Durchsetzung von Parameterformaten

Gespräch:

Benutzer: Meine Reservierung stornieren

Agent: Um mit der Stornierung fortzufahren, benötige ich Ihre Buchungs-ID. Könnten Sie diese bitte angeben?

Benutzer: seine ab1234

Agent: Die Buchungs-ID sollte 3 Buchstaben gefolgt von 3 Numbers enthalten. Bitte geben Sie eine gültige Buchungs-ID an.

Was sich geändert hat:

• Der Agent normalisiert oder bestätigt keine ungültigen Daten mehr

• Die Formatregeln werden strikt durchgesetzt

• Der Benutzer wird angeleitet, die Eingabe zu korrigieren, bevor der Fluss fortgesetzt wird.

Verbessertes Beispiel 2: Blockieren halluzinierter Absichten und Parameter

Gespräch:

Benutzer: Ich möchte meine Bluttestergebnisse erhalten

Agent: Es tut mir leid, ich kann für diese Aktion keine medizinischen Testergebnisse abrufen oder einen Ausweis anfordern. Ich kann Ihnen bei der Verwaltung Ihrer Termine behilflich sein und Sie bei allen anderen Anfragen direkt an die Klinik weiterleiten.

Was sich geändert hat:

• Der Agent erfindet keine nicht unterstützten Fähigkeiten mehr

• Es werden keine undefinierten Parameter (wie "ID") angefordert.

• Die Antwort ist auf die tatsächlichen Systemfähigkeiten abgestimmt

Und falls Sie sich fragen, wie das hinter den Kulissen aussieht:

Seite an Seite: Halluzinationen im Vergleich zum vernunftbegabten Schema

Vor dem JSON-Antwortschema (Halluzinationen-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."
    
  }
}

Nach JSON-Antwortschema (mit zusätzlichen Begründungsfeldern)

{
  "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."
  }
}

Durch Hinzufügen der neuen Argumentationsfelder: evidence_from_prompt,intents_i_am_familiar_with, out_of_scope_requestist der LLM verpflichtet, die Benutzereingabe und die Konfiguration zu analysieren bevor bevor es die endgültige Antwort erzeugt. Dies zwingt das Modell dazu, die Einschränkungen zu durchdenken, die Grenzen des Szenarios zu verstehen und seine Antwort auf explizite Beweise zu stützen, was zu klareren, genaueren und kontrollierteren Antworten führt.

Parameter-Validierung: Schemaverfeinerung für exakte Benutzereingaben

Vor dem JSON-Antwortschema (Antwort zuerst, Analyse danach)

{
  "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",
      
    }
    ]
}

Nach (Bestellung ändern und Begründungsfelder hinzufügen)

{
  "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",
    
  }
}

Zusammen erfordern diese Felder, dass das Modell den extrahierten Parameter validiert, ihn mit dem erwarteten Format vergleicht und ausdrücklich angibt, ob der Wert akzeptabel ist, bevor es die endgültige Antwort gibt. Dies stellt sicher, dass die Antwort vollständig auf den Argumentationsschritten des Modells basiert und verhindert Fälle, in denen das LLM zuversichtlich einen ungültigen Parameter bestätigt oder das Gespräch auf der Grundlage falscher Annahmen weiterführt.

Wir waren mit den Ergebnissen dieser Maßnahmen zufrieden, aber wir waren weiterhin besorgt über mögliche Abweichungen bei der Validierung von Parameterformaten. Deshalb haben wir eine messbare Validierungsschicht eingeführt, die die Extraktionsraten überwacht und Fälle auffängt, in denen der LLM immer noch Regeln für natürlichsprachliche Formate falsch interpretiert.

Erzwingen präziser Parameterformate mit Regex-Validierung

Die Hinzufügung zusätzlicher Argumentationsparameter und die Neuordnung des Schemas brachten bedeutende Verbesserungen. Dennoch verfolgten wir zwei weitere Ziele:

1. eine nahezu 100-prozentige Präzision bei der Durchsetzung des Parameterformats zu erreichen und

2. eine strenge Überwachung der Produktion, um festzustellen, wann eine weitere Optimierung erforderlich ist.

Um diese Ziele zu erreichen, haben wir eine mehrstufige Validierungspipeline eingesetzt.

Schritt 1: LLM generiert eine Regex aus der Beschreibung

Wie im vorangegangenen Abschnitt erläutert, muss ein Teil der zusätzlichen Argumentationsfelder vom LLM erstellt werden:

• parameter_value_format: Eine menschenlesbare Beschreibung

• parameter_value_format_regex: Ein aus der Freitextbeschreibung generiertes Regex-Muster

• simulate_regex_execution: Die Bewertung des LLM, ob der extrahierte Wert das Regex-Muster erfüllt.

Dies zwingt den LLM dazu, natürliche Sprache in ein maschinenlesbares Format zu übersetzen.

Schritt 2: LLM prüft seine eigene Regex (Simulation)

Als Teil seiner Argumentation antwortet das Modell "simulate_regex_execution": true | falseund gibt an, ob es glaubt die Regex funktioniert. Dies hat die Genauigkeit bereits deutlich erhöht.

Schritt 3: Abschließende systemseitige Regex-Prüfung stellt die Genauigkeit sicher

Um die Genauigkeit zu gewährleisten, wurde nach Erhalt der LLM-Antwort eine weitere Überprüfungsebene hinzugefügt: Das System führt die generierte Regex aus dem Feld parameter_value_format_regex (mit Leitplanken zur Vermeidung unsicherer Muster) selbständig erneut aus. Stimmt die Regex nicht überein, auch wenn sie laut LLM übereinstimmen sollte, weist der Agent den Wert zurück und leitet den Benutzer an, ihn zu korrigieren.

Dieser hybride Ansatz, der LLM-Schlussfolgerungen mit programmatischer Validierung kombiniert, führte zu einer nahezu perfekten Präzision bei der Durchsetzung des Parameterformats und löste die letzten von uns beobachteten Unstimmigkeiten.

Durch diese Validierung erhalten wir eine messbare Kennzahl, mit der wir die Leistung des LLM im Laufe der Zeit verfolgen können. Wann immer der LLM vorhersagt, dass der Regex übereinstimmen sollte (simulate_regex_execution = true), die systemseitige Regex-Ausführung aber fehlschlägt, erkennen wir die Diskrepanz sofort. Wir gehen davon aus, dass diese Fälle extrem selten sind, und wenn ein Aufwärtstrend auftritt, dient dies als frühzeitiger Indikator für eine Abweichung oder Verschlechterung im Verhalten des LLM.

Bewertung: Wie sehr haben die Änderungen geholfen?

Um die Wirkung des neuen Argumentationsschemas zu bewerten, haben wir einen virtuellen Agenten für eine medizinische Klinik erstellt und 97 Sätze, die absichtlich außerhalb des Geltungsbereichs lagen. Für alle von ihnen war das richtige Verhalten:

• intent = null, und

• Die generierte Antwort sollte die Anfrage höflich zurückweisen

• Minimierung der Fälle, in denen simulate_regex_execution = true ist, aber die systemseitige Regex-Ausführung fehlschlägt.

Wir haben einen Vergleich durchgeführt, um die Auswirkungen der Einführung von Argumentationsfeldern zu bewerten:

Kein Schaden für echte Positivisten

Wir haben auch Fälle validiert, in denen der virtuelle Agent sollte eine Absicht erkennen sollte. Die Erkennung von True Positive (TP) blieb unverändert: kein Abfall, keine Verschlechterung. Die neue Argumentationsschicht reduziert Halluzinationen ohne ohne die korrekte Absichtserkennung zu schwächen.

Vorher vs. Nachher

Es gab keine Fälle, in denen der LLM voraussagte simulate_regex_execution = true vorausgesagt hat, während die systemseitige Regex-Ausführung fehlschlug. Mit anderen Worten: Alle Verbesserungen wurden durch den LLM selbst erzielt.

Ähnliche Muster wurden bei anderen Aufgaben beobachtet, die das LLM generieren muss.

Ergebnisse: Was wir gelernt haben und was sich geändert hat

Die Einführung expliziter Argumentationsfelder, die Umstrukturierung des Antwortschemas und die Hinzufügung einer systemseitigen Regex-Ausführung hatten eine signifikant positive Auswirkung auf das Gesamtverhalten des LLM. Diese Änderungen reduzierten Halluzinationen und Antworten, die außerhalb des Geltungsbereichs lagen, während die Fähigkeit des Modells, gültige Eingaben korrekt zu identifizieren, erhalten blieb. Infolgedessen wurden die Ausgaben des LLM konsistenter, vorhersehbarer und besser auf die beabsichtigte Konfiguration und Logik abgestimmt.

Während sich diese Arbeit weiterentwickelt, untersuchen wir weiterhin Möglichkeiten, die Argumentation und die Entscheidungen unseres Systems besser zu erklären, um sowohl reale Anwendungsfälle zu unterstützen als auch eine starke KI-Governance aufrechtzuerhalten.

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