Best Practices zur Kontrolle von LLM-Halluzinationen auf Anwendungsebene

Große Sprachmodelle (LLMs) bieten transformatives Potenzial für die Anwendungsentwicklung, stellen aber bei Halluzinationen eine große Herausforderung dar. Entdecken Sie praktische, ingenieursgestützte Strategien zur Entwicklung zuverlässiger LLM-basierter Funktionen.

Große Sprachmodelle (LLMs) werden in atemberaubendem Tempo in Anwendungen integriert und versprechen eine Revolution im Benutzererlebnis. Doch wie jedes Team, das an vorderster Front arbeitet, bestätigen wird, bringt dies eine entscheidende Herausforderung mit sich: Halluzinationen.

Die Fähigkeit eines LLM, Informationen zu erfinden, zu extrapolieren und sicher zu fabrizieren, ist kein Fehler, der behoben werden muss, sondern ein Kernmerkmal seiner kreativen Natur. Für Entwickler bedeutet dies, dass wir nicht einfach hoffen können, dass ein Modell diesmal keine Halluzinationen hat. Wir müssen Systeme entwickeln, die dieses Verhalten antizipieren und auf Anwendungsebene steuern.

Bei Parasoft, während Integration von LLMs In unsere Software-Testprodukte sind wir mit der Herausforderung konfrontiert, Halluzinationen zu bewältigen. In einem frühen internen Projekt gaben wir einem LLM zusammengefasste Informationen aus einer OpenAPI-Service-Definition und baten ihn, Szenarien aus verwandten APIsEiner unserer Ingenieure bemerkte: „Manchmal antwortete es mit zwei echten APIs und einer erfundenen.“

Ohne Leitplanken sind LLMs unvorhersehbar, was wiederum die von ihnen abhängigen Anwendungen unzuverlässig macht.

In diesem Blog möchte ich einige praktische, ingenieursgestützte Strategien vorstellen, die unsere Teams entwickelt haben, um vertrauenswürdige, LLM-basierte Funktionen zu erstellen.

1. Setzen Sie Grenzen in Ihren Eingabeaufforderungen

Die erste Verteidigungslinie gegen Halluzinationen ist der Hinweis selbst, und der wirksamste Ansatz ist oft der direkteste.

Eine sehr grundlegende Technik besteht darin, dem LLM grundlegende Regeln für sein Verhalten zu geben, z. B. die Anweisung, keine Informationen zu erfinden. Sie können beispielsweise Eingabeaufforderungen wie diese verwenden:

• „Bitte antworten Sie nur auf Grundlage der von mir bereitgestellten Informationen.“
• „Bitte erstellen Sie keine neuen Elemente, die nicht vorhanden waren.“

Dieser Ansatz fungiert als primäre Leitplanke. Er verhindert, dass das Modell seinen kreativen Tendenzen verfällt, und begründet seine Reaktion im spezifischen Kontext, den Sie bereitgestellt haben.

Bisher halten wir dies für eine einfache Möglichkeit, Halluzinationen an der Quelle zu bekämpfen. LLMs unterstützen zusätzlich einen Parameter namens „Temperatur“, der die Kreativität des Modells steuert. Wenn Konsistenz und Genauigkeit wichtig sind, stellen Sie die Temperatur des Modells niedrig (~0) ein und erhöhen Sie sie nur, wenn das LLM kreativer sein soll. Seien Sie jedoch direkt und sagen Sie ihm genau, was Sie wollen.

2. Erzwingen Sie die Ausgabestruktur mit Schemata

Klare Anweisungen sind ein guter Anfang, aber für echte Zuverlässigkeit ist Durchsetzung erforderlich. Hier wechseln Sie vom „Sagen“ des LLM, was Sie möchten, zum programmatischen „Zwingen“ des LLM, mithilfe strukturierter Ausgaben ein bestimmtes Ausgabeformat einzuhalten.

Die meisten großen Modellanbieter ermöglichen es Ihnen, in Ihrem API-Aufruf ein erforderliches JSON-Schema zu definieren, das dem Modell mithilfe einer Funktion namens „strukturierte Ausgaben“ das spezifische Format mitteilt, in dem Sie die Daten benötigen. Dadurch wird die Antwort des Modells eingeschränkt und sichergestellt, dass es Ihren definierten Feldern, Datentypen und der Struktur entspricht, sodass Ihr Code auf dieses spezifische Format angewiesen ist.

Wenn wir beispielsweise ein Modell auffordern, eine Datentabelle zu generieren, verwenden wir ein Schema wie das folgende:

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

      }

    }

  }

}

Dadurch wird sichergestellt, dass das Modell ein sauberes JSON-Objekt zurückgibt, das Folgendes enthält: columnNames Array und a generatedDataRows Array – kein unstrukturierter Absatz oder fehlerhaftes JSON. Die Verwendung strukturierter Ausgaben wurde unerlässlich, als wir sahen, dass das LLM eine Antwort zurückgab, die die Daten nicht in einem Format enthielt, das wir programmgesteuert verwenden konnten.

Um Modelle zu verarbeiten, die keine strukturierten Ausgaben unterstützen, haben wir festgestellt, dass wir das JSON-Schema in die Systemaufforderung selbst einbinden können, was zwar nicht die erwartete Ausgabe garantiert, aber ein überraschend effektiver Fallback ist.

3. Antworten mit externen Beweisen begründen (Retrieval-Augmented Generation)

Während Ihnen direkte Anweisungen und strukturierte Ausgaben die Kontrolle über die Eingabeaufforderung und das Ausgabeformat geben, müssen Sie auch das Wissen kontrollieren, das der LLM zur Generierung seiner Antwort verwendet.

Anstatt das Modell ausschließlich auf seine umfangreichen und manchmal veralteten internen Trainingsdaten zugreifen zu lassen, können Sie es mithilfe der Retrieval-Augmented-Generation (RAG)-Technik auf Domänenwissen stützen. Dies beinhaltet einen zusätzlichen Schritt zur Verbesserung der LLM-Ausgabe durch Hinzufügen von Informationen aus externen Wissensquellen vor der Generierung einer Antwort.

Durch die Bereitstellung zusätzlicher domänenspezifischer Informationen ändern Sie die Aufgabe von „Erinnern Sie sich an eine Antwort aus Ihrem allgemeinen Gedächtnis“ zu „Erhalten Sie eine Antwort aus diesen spezifischen Fakten“. Dadurch werden Halluzinationen drastisch reduziert.

Anstatt das Modell beispielsweise aufzufordern, verwandte APIs aus dem Speicher zu benennen (wo es möglicherweise eine erfindet), würde eine RAG-Technik zuerst die tatsächlichen Definitionen gültiger APIs abrufen und dann das LLM bitten, sie zusammenzufassen.

Dadurch wird das Modell in einen relevanten Kontext eingebettet und die Informationen bleiben aktuell.

4. Komplexe Logik in separate Agenten aufteilen

Ein häufiger Fehler bei der Arbeit mit LLMs besteht darin, komplexe Eingabeaufforderungen mit bedingter Logik zu erstellen und so zu versuchen, das LLM so zu „programmieren“, dass es sich je nach Bedingung unterschiedlich verhält. Diese Art der Übererklärung verwirrt LLMs oft, sodass sie sich auf die falschen Informationen konzentrieren und unerwartete Ergebnisse liefern. Und selbst wenn die komplexe Eingabeaufforderung für ein Modell funktioniert, funktioniert sie möglicherweise nicht für andere Modelle.

Wir haben erkannt, dass die Aufteilung des Workflows in separate, kleinere Agenten, die jeweils eine bestimmte Aufgabe ausführen, eine bessere Strategie darstellt. Im weiteren Verlauf des Workflows wird die Steuerung basierend auf den Benutzereingaben und dem nächsten Schritt im Workflow zwischen den Agenten übertragen. Anstatt zu versuchen, das Verhalten des Modells mit einer einzigen Eingabeaufforderung zu steuern, wird das Verhalten auf die verschiedenen Agenten aufgeteilt. Dadurch kann sich das LLM in jedem Schritt auf die jeweilige Aufgabe konzentrieren.

5. Automatisierte Verifizierung

Selbst mit einfachen direkten Eingabeaufforderungen und RAG kann ein LLM Quellmaterial falsch interpretieren oder die Wahrheit übertreiben. Die nächste Verteidigungsebene ist ein „Vertrauen, aber überprüfen“-Schritt, der die Ausgabe des Modells prüft, bevor der Workflow fortgesetzt wird.

Leichtgewichtige „Judge“-LLMs können die LLM-Ausgabe mit den abgerufenen Informationen vergleichen, die in RAG verwendet werden, um einen Vertrauenswert zuzuweisen. Ausgaben, die unter einen bestimmten Schwellenwert fallen, werden dem LLM erneut auf andere Weise präsentiert oder sogar automatisch abgelehnt, sodass der Workflow mit bereits geprüften Inhalten fortgesetzt werden kann.

Eine weitere Technik besteht in der Verwendung regelbasierter Nachbearbeitungsfilter, die die LLM-Ausgabe anhand bekannter Erwartungen validieren. Es ist wichtig klarzustellen, dass diese Prüfungen nicht die semantische Qualität der Die Antwort der KI, indem sie beispielsweise fragen: „Ist das eine gute Idee?“ Stattdessen validieren sie die strukturelle Integrität oder den Inhalt der Ausgabe.

Einer unserer Ingenieure drückte es so aus: „Sie müssen die Antwort tatsächlich durch Code überprüfen lassen.“ Dadurch wird sichergestellt, dass die Ausgabe den bekannten Geschäftsregeln entspricht, bevor sie von der Anwendung verwendet wird.

6. Verifizierung mit einem Menschen im Kreislauf

Die genannten Techniken können Ihnen dabei helfen, Halluzinationen zu reduzieren, aber letztendlich müssen Sie oft eine menschliche Überwachung in den vom Produkt unterstützten Arbeitsablauf integrieren, damit der Benutzer die endgültige Entscheidung darüber hat, was produziert wird.

Ob dies erforderlich ist, hängt davon ab, wie schwerwiegend die Folgen falscher Informationen wären. In einigen Fällen ist möglicherweise ein menschliches Eingreifen erforderlich, basierend auf der automatischen Validierung der LLM-Ausgabe, wie bereits erwähnt.

Um menschliches Feedback einzuholen, implementieren wir einen mehrstufigen Agentenfluss, der an verschiedenen Stellen im Prozess menschliche Eingaben einfordert. Ein gutes Beispiel ist unser Agent zur Erstellung von Testszenarien:

1. Triage. Die Anfrage eines Benutzers („Erstellen eines neuen Testszenarios“) wird an den spezialisierten Agenten zur Testerstellung weitergeleitet.
2. Klärung. Der Agent interagiert mit dem Benutzer, um notwendige Eingaben zu sammeln, beispielsweise eine Servicedefinitions-URL.
3. Vorschlag. Der Agent schlägt einen Plan der Tests vor, die er erstellen wird, und bittet den Benutzer um Genehmigung.
4. Ausführung. Erst wenn der Benutzer auf „Genehmigen“ klickt, wird das Testszenario generiert und gespeichert.

Dieses Muster „Vorschlagen, dann ausführen“ überlässt dem Benutzer die endgültige Kontrolle und schafft einen entscheidenden Kontrollpunkt, der verhindert, dass das System auf der Grundlage einer plausibel klingenden Halluzination handelt, die jedoch falsch ist.

Realistisches Bauen erhöht die Zuverlässigkeit und reduziert Stress

Bei der Kontrolle von Halluzinationen geht es nicht darum, einen einzigen magischen Trick zu finden. Es geht darum, in Ihrer Anwendung ein mehrschichtiges Abwehrsystem aufzubauen, das auf Techniken wie den oben genannten basiert.

Da LLMs halluzinieren, müssen Sie eine Reihe von Abwehrmechanismen aufbauen, um zuverlässige Ergebnisse zu gewährleisten. Durch die Kombination belastbarer Anweisungen, erzwungener Schemata und eines robusten Verifizierungsprozesses können Sie von der Hoffnung auf ein gutes Verhalten eines LLMs zur Entwicklung eines Systems übergehen, das mögliches Fehlverhalten kompensiert und zuverlässige Ergebnisse liefert.

Mit der Weiterentwicklung der Technologie werden sich diese Leitlinien auf Anwendungsebene möglicherweise ändern. Behalten Sie sie in der Zwischenzeit im Hinterkopf, um die Zuverlässigkeit von LLMs bei der Integration in Ihre Anwendungen zu erhöhen.