LLM-Halluzinationen im Unternehmen: falsche KI-Antworten reduzieren
Um LLM-Halluzinationen zu begrenzen, legen Sie fest, woher der Assistent seine Fakten bezieht, wie er mit fehlenden Informationen umgeht und welche Antworten vor der Verwendung geprüft werden müssen. RAG, also die Suche nach Material vor dem Formulieren einer Antwort, kann dabei helfen. Das ersetzt jedoch weder die Quellenprüfung noch einen Test des gesamten Kundenservice-Prozesses.
Von einer Halluzination spricht man, wenn ein Sprachmodell falsche oder durch das bereitgestellte Material nicht belegte Informationen als Tatsache darstellt. Ein sicherer Ton und korrekte Sprache bestätigen deren Wahrheitsgehalt nicht. NIST beschreibt dieses Problem auch bei erfundenen Quellenangaben und Begründungen. Für ein Unternehmen ist entscheidend, ob jemand die Antwort bei der Arbeit verwendet oder an Kunden weitergibt.
Legen Sie fest, was der Assistent sagen und tun darf
Eine geprüfte Nachricht umzuformulieren erfordert eine andere Kontrolle als eine Auskunft über Produktverfügbarkeit, Liefertermine oder die Bedingungen einer bestimmten Bestellung. Benennen Sie für solche Auskünfte die Quelle, aus der sich die jeweilige Tatsache ergibt. Das allgemeine Wissen des Modells über übliche Verkaufsabläufe reicht dafür nicht aus.
Trennen Sie das Formulieren einer Nachricht von einer Aktion im System. Dass ein Assistent eine Antwort zu einer Rückerstattung verfassen kann, bedeutet nicht, dass er die Rückzahlung selbst freigeben sollte. Legen Sie im Projektumfang den Datenzugriff, die Berechtigung zum Nachrichtenversand und die Berechtigung zur Änderung von Bestellungen getrennt fest. Bestimmen Sie außerdem, wer Entscheidungen übernimmt, die der Assistent nicht treffen darf.
Kann eine Antwort eine Zusage gegenüber dem Kunden enthalten, regeln Sie deren Freigabe. Die prüfende Person sollte auf die zugrunde liegenden Informationen zugreifen können und wissen, was genau zu beurteilen ist. Eine Schaltfläche „Freigeben“ allein ersetzt diese Prüfung nicht.
RAG hilft bei der Suche, bestätigt aber nicht die Richtigkeit
Bei einer RAG-Lösung sucht das System zunächst passende Dokumentabschnitte und übergibt sie anschließend dem Modell zum Formulieren der Antwort. Die Microsoft-Dokumentation erläutert die Bedeutung passender Suchergebnisse und des Zugriffs auf die richtigen Inhalte. Allein die Anbindung einer firmeneigenen Wissensbasis garantiert nicht, dass das richtige Dokument beim Modell ankommt.
Benennen Sie eine verantwortliche Person für die Aktualität der Inhalte. Enthält die Wissensbasis zwei widersprüchliche Fassungen der Bedingungen, muss klar sein, welche gilt und wie das System mit der Abweichung umgehen soll. Dasselbe gilt bei Angebotsänderungen: Neuer Text auf der Website bedeutet nicht automatisch, dass die vom Assistenten genutzte Kopie bereits aktualisiert wurde.
Daten einer bestimmten Bestellung sollten möglichst aus dem System stammen, das sie verwaltet, und nur im Rahmen der Zugriffsrechte des Nutzers abgerufen werden. Eine Beschreibung des Lieferverfahrens bestätigt nicht das Versanddatum eines einzelnen Pakets. Prüfen Sie auch das Verhalten bei einem Verbindungsfehler: Fehlende Informationen dürfen nicht durch überzeugend formulierte Vermutungen ersetzt werden.
Regeln Sie den Umgang mit fehlenden Informationen
Die Anweisung an das Modell sollte ausdrücklich zulassen, dass es auf fehlende Informationen im Material hinweist. Diesen Ansatz enthalten auch die Empfehlungen von Anthropic zur Verringerung von Halluzinationen bei Claude. Prüfen Sie die Anweisung mit Ihren eigenen Fragen, auch wenn ein Kunde auf einer eindeutigen Antwort besteht.
Legen Sie den nächsten Schritt fest: fehlende Angaben erfragen, den Fall an einen Mitarbeiter weitergeben oder nur den belegten Teil beantworten. Kündigt der Assistent Kontakt mit einem Mitarbeiter an, muss der Prozess den Fall tatsächlich zur Bearbeitung weiterleiten, etwa indem ein Ticket erstellt und zur Bearbeitung zugewiesen wird. Eine solche Zusage sollte nicht nur dazu dienen, das Gespräch höflich abzuschließen.
Eine beispielhafte Anweisung könnte lauten: „Nenne einen Liefertermin nur, wenn er in den Daten dieser Bestellung bestätigt ist. Fehlt er, weise auf die fehlende Information hin und folge dem vereinbarten Bearbeitungsweg.“ Prüfen Sie diese Anweisung zusammen mit dem Datenabruf und der Weiterleitung von Fällen.
Beispiel: Ein Kunde fragt nach dem Liefertermin
Nehmen wir hypothetisch an, ein Kunde fragt nach dem Tag der Zustellung. Das Bestellsystem liefert den Status „in Vorbereitung“, enthält aber keinen bestätigten Liefertermin. Der Assistent hat damit eine Grundlage, den Status mitzuteilen. Daraus lässt sich kein Datum auf Basis der üblichen Lieferdauer ableiten.
Die Antwort kann daher lauten, dass die Bestellung vorbereitet wird und noch kein Zustelltermin bestätigt ist. Der nächste Schritt richtet sich nach dem tatsächlichen Verfahren des Unternehmens. Soll ein Mitarbeiter den Termin klären, prüfen Sie, ob er einen Vorgang mit den dafür erforderlichen Angaben erhält. Das ist ein Beispiel für die Gestaltung des Serviceablaufs, kein Bericht über ein Projekt bei einem Kunden oder dessen Ergebnis.
Verändern Sie die Testbedingungen: Geben Sie einen bestätigten Termin vor, entfernen Sie ihn, liefern Sie widersprüchliche Angaben und simulieren Sie ein nicht verfügbares System. Eine gute Antwort in einem dieser Fälle zeigt noch nicht, wie sich der Assistent in den übrigen verhält.
Prüfen Sie den Inhalt, nicht nur das Format
JSON ist ein Format für strukturierte Daten. Eine korrekte Syntax bestätigt nicht, dass ein eingetragenes Datum oder ein Preis stimmt. Auch ein Dokumentlink allein reicht nicht: Prüfen Sie, ob das Dokument die jeweilige Aussage tatsächlich belegt. Die Kontrolle sollte sowohl die Existenz der Quelle als auch ihren Zusammenhang mit der Antwort umfassen.
Ein zweites Modell kann helfen, Widersprüche zu erkennen. Seine Zustimmung bestätigt jedoch keine Tatsache. Die abschließende Prüfung eines Termins oder Betrags sollte sich auf den richtigen Systemeintrag oder das maßgebliche Dokument beziehen. Vergleichen Sie vor dem Einsatz eines zusätzlichen Modells, welche Fehler es tatsächlich erkennt, welche es übersieht und was seine Nutzung sowie die Bearbeitung von Korrekturen kosten.
Nehmen Sie die Lösung anhand von Fragen aus dem Arbeitsalltag ab
Stellen Sie typische und schwierige Fragen zusammen und legen Sie fest, wie sie behandelt werden sollen. Berücksichtigen Sie Fälle ohne Antwort in den Quellen, veraltete Unterlagen und mehrdeutige Fragen. Auch die Anthropic-Empfehlungen zur Bewertung von LLM-Anwendungen beziehen Kriterien auf die Aufgabe und berücksichtigen fehlende Daten. Einen für jedes Unternehmen passenden Qualitätsgrenzwert gibt es nicht.
Bewerten Sie falsche Tatsachenangaben, berechtigte Hinweise auf fehlende Informationen und unnötige Antwortverweigerungen getrennt. Ein Assistent, der jede Antwort verweigert, liefert möglicherweise selten falsche Informationen, hilft dem Team aber trotzdem nicht. Prüfen Sie außerdem, wie viel Zeit Mitarbeiter zum Korrigieren einer Antwort benötigen und ob die Weitergabe eines Falls an einen Menschen funktioniert.
Behalten Sie nach der Einführung eine Möglichkeit zur Fehlermeldung bei und bestimmen Sie, wer solche Meldungen untersucht. Verwendete Quellen, die Versionen von Modell und Anweisung sowie der Antworttext helfen, einen Fehler nachzustellen. Was gespeichert wird und wer darauf zugreifen darf, sollte den Datenregeln des Unternehmens entsprechen. Nehmen Sie erkannte Fälle in die Tests für spätere Änderungen auf. So beruht die Entscheidung über den weiteren Einsatz auf dem tatsächlichen Verhalten des Assistenten und nicht auf der Aussage, man nutze RAG oder „bessere Anweisungen“.
