Eine Antwort kann klar und höflich sein und dennoch genau an der entscheidenden Stelle falsch sein. Ein Kundendienstmitarbeiter könnte die richtige Produktbeschreibung zitieren und dann eine Lieferzusage hinzufügen, die in der Quelle gar nicht enthalten ist.
Ich betrachte die Generierung und die Validierung als getrennte Aufgabenbereiche. Das Modell schlägt eine Antwort vor. Die Anwendung entscheidet, ob diese Antwort den für die Bereitstellung erforderlichen Beleg- und Produktregeln entspricht.
Ermitteln Sie die Ansprüche, die ein Risiko darstellen
Nicht jeder Satz muss gleich behandelt werden. Eine Begrüßung enthält kaum sachliche Informationen. Ein Preis, eine Produktkennung, eine Garantiebedingung oder ein Link können die Entscheidung eines Kunden direkt beeinflussen.
Zunächst identifiziere ich diese konkreten Aussagen. Der Validator vergleicht sie anschließend mit den abgerufenen Quellen oder den maßgeblichen strukturierten Daten. Dabei sollten Beziehungen erhalten bleiben: Die Zahl 49 in einer Quelle zu finden, reicht nicht aus, um einen Preis von 49 € für das ausgewählte Produkt zu belegen.
Währung, Variante, Menge, Datum und Markt können die Bedeutung eines Wertes beeinflussen. Eine sinnvolle Überprüfung besteht darin, zu prüfen, ob die gesamte Aussage im jeweiligen Kontext fundiert ist.
Stellen Sie sicher, dass Links mit Datensätzen aus vertrauenswürdigen Quellen verknüpft sind
Ein Modell kann eine plausible URL erzeugen, die nicht existiert. Es kann aber auch eine echte URL erzeugen, die auf das falsche Produkt verweist. Ich bevorzuge Links, die aus verifizierten Quelldatensätzen ausgewählt wurden, gegenüber Pfaden, die aus generiertem Text zusammengesetzt wurden.
Für die Linkprüfung ist eine explizite Normalisierungsrichtlinie erforderlich. Würden nur Domains verglichen, würden viele falsche Ziele akzeptiert werden. Der Vergleich von Rohzeichenfolgen ohne Berücksichtigung legitimer Formatierungsunterschiede kann dazu führen, dass gültige Links abgelehnt werden.
Wenn die Anwendung eine generierte URL abruft, um diese zu validieren, entsteht durch diesen Abruf eine eigene Sicherheitsgrenze. In vielen Fällen ist der Abgleich mit einem kontrollierten Quellkatalog einfacher, als beliebige Netzwerkanfragen seitens des Validators zuzulassen.
Verwenden Sie deterministische Prüfungen, sofern es die Domäne zulässt
Identifikatoren für strukturierte Produkte und bekannte Preise eignen sich gut für eine deterministische Validierung. Offene Formulierungen in Versicherungsbedingungen sind schwieriger: Das Abgleichen von Schlüsselwörtern kann nicht nachweisen, dass ein Satz die ursprünglichen Bedingungen beibehält.
Ein modellbasierter Verifikator kann zwar bei der Überprüfung semantischer Aussagen helfen, führt jedoch eine weitere fehleranfällige Komponente ein. Ich würde ihn anhand von menschlich geprüften Beispielen kalibrieren und Regeln mit hoher Auswirkung explizit festhalten. Das gleiche Generierungsmodell zu fragen, ob es korrekt war, ist für sich genommen ein schwacher Beweis.
Eine mögliche Ergebnisstruktur ist:
{
"decision": "needs_revision",
"unsupported_claims": ["delivery_by_requested_date"],
"allowed_source_ids": ["shipping-policy-v3"],
"next_action": "ask_for_postcode"
}Dies ist ein Beispielvertrag. Wichtig ist, dass ein Fehlschlag einen verarbeitbaren Zustand erzeugt und nicht einen generischen booleschen Wert, den nachgelagerter Code ignorieren kann.
Plane, was passiert, wenn die Validierung fehlschlägt
Die Anwendung kann den Vorgang unter Zugrundelegung enger gefasster Anhaltspunkte einmalig wiederholen, eine unbegründete Behauptung entfernen, fehlende Informationen anfordern oder die Konversation an einen Menschen weiterleiten. Diese Entscheidung sollte vom Grund für den Fehlschlag abhängen.
Wiederholungsversuche müssen begrenzt werden. Das wiederholte Generieren von Anfragen, bis eine Antwort erfolgreich ist, kann die Kosten in die Höhe treiben und gleichzeitig Schwachstellen im Validator aufdecken. Jeder Versuch sollte innerhalb des Zeit- und Kostenrahmens der Anfrage bleiben.
Das Streaming wirkt sich auch auf das Design aus. Texte, die dem Kunden bereits angezeigt wurden, können nicht mehr ausgeblendet werden. Wenn das Produkt eine Überprüfung vor der Auslieferung verspricht, müssen aussagekräftige Angaben zwischengespeichert oder aus genehmigten strukturierten Feldern generiert werden, bevor sie veröffentlicht werden.
Die Validierung von Beweisen sollte vom Vertrauen in die Anweisungen getrennt bleiben
Ein abgerufenes Dokument kann sowohl nützliche Informationen als auch böswillige Anweisungen enthalten. Das Bestehen einer Plagiatsprüfung verleiht diesem Dokument nicht die Befugnis, die Berechtigungen von Tools oder das Systemverhalten zu ändern. Die OWASP-Leitlinien zur Prompt-Injection sind eine nützliche Referenz für diese separate Vertrauensgrenze.
Ich möchte, dass Validierungsfehler zu Auswertungsfällen werden. Jedes nicht unterstützte Versprechen oder jeder fehlerhafte Link beschreibt ein konkretes Verhalten, das das System beim nächsten Mal erkennen sollte, sowie eine Regressionsprüfung, die das Team durchführen kann, bevor es Änderungen an der Pipeline vornimmt.
Aktualisiert am 25. September 2026.