Ergebnis dieses Guides
Eine Antwort mit überprüfbaren Belegen und klaren Grenzen
Arbeitsumgebung
Eine serverseitige API-Anbindung mit getrennten Projektschlüsseln und festgelegtem Ausgabeformat
Wann ist diese Entscheidung wichtig?
Flüssige Sprache ist kein Beweis. Besonders Namen, Zahlen und Quellenangaben müssen gegen eine verlässliche Grundlage geprüft werden.
Halten Sie Zugangsschlüssel auf dem Server. Trennen Sie Anfrage, Antwortvalidierung und mögliche Seiteneffekte. Prüfen Sie die Fähigkeiten und Grenzen des konkret gewählten Modells anhand der aktuellen Dokumentation und Ihrer eigenen Fälle.
Halluzinationen: Schritt für Schritt.
- 01
Vorbereiten
Bestimmen Sie, welche Aussagen belegt werden müssen und welche Informationsquellen zulässig sind.
- 02
In OpenAI API umsetzen
Lassen Sie Belege mitliefern und prüfen Sie deren tatsächliche Aussage. Bei fehlenden Belegen muss das System Unsicherheit oder fehlendes Wissen mitteilen.
- 03
Im tatsächlichen Projekt prüfen
Erfassen Sie Modellkonfiguration, Fehlercodes, Verbrauch und Prüfergebnisse je Testlauf. Eine strukturiert aussehende Antwort muss fachlich und gegebenenfalls gegen ein Schema geprüft werden.
Beispiel zur Überprüfung
So lässt sich das Ergebnis prüfen.
Als Projektkontext dient einen Assistenten für wiederkehrende Kundenfragen. Der folgende Prüffall ist eine Vorlage für diese Aufgabe und kein Bericht über eine Kundenmessung.
- Eingabe / Auslöser
- Eine Frage zu einer belegten Information und eine bewusst unbeantwortbare Frage
- Erwartetes Ergebnis
- Die belegte Antwort verweist auf eine passende Quelle; die unbeantwortbare erzeugt keine erfundene Tatsache.
- Fehler- oder Grenzfall
- Eine Quellenadresse, die existiert, wird nicht automatisch als Beleg für eine beliebige Aussage akzeptiert.
Abnahme und typische Fehler.
- Das System fragt nach oder nennt fehlende Informationen.
- Eine Quellenadresse, die existiert, wird nicht automatisch als Beleg für eine beliebige Aussage akzeptiert.
- Modellausgaben sind Vorschläge; Berechtigungen und geschäftliche Entscheidungen bleiben bei der Anwendung.
Typischer Fehler
Selbstsicherer Ton ist kein Korrektheitsbeleg.
Quellen und Versionshinweis
Die Anleitung beschreibt das Vorgehen; konkrete APIs, Produktfunktionen und Laufzeitgrenzen müssen zur eingesetzten Version passen. Halten Sie Version, Konfiguration und Prüfergebnis im Projekt fest und vergleichen Sie die verlinkte Dokumentation bei Änderungen.
