Prompt Engineering im Produktivbetrieb: Wie teste ich Änderungen?
Automatische Übersetzung
Dieser Artikel wurde automatisch aus der englischen Originalversion übersetzt.
Definiere erfolgreiche Ausgaben, sammle repräsentative Fälle und vergleiche eine Prompt-Änderung mit einer festen Baseline. Verbessere die Anweisung, die Beispiele oder den bereitgestellten Kontext anhand des beobachteten Fehlers. Halte einen separaten Testsatz zurück, um zu prüfen, ob die Änderung auch außerhalb der Beispiele funktioniert, mit denen du sie entwickelt hast.
Ein Prompt im Produktivbetrieb muss fehlende, mehrdeutige und ungültige Eingaben ebenso verarbeiten wie gewöhnliche Anfragen.
Fehler in Testfälle umwandeln
Angenommen, ein Model extrahiert Rechnungsfelder. Nimm gewöhnliche Rechnungen, fehlende Werte, unbekannte Layouts, widersprüchliche Datumsangaben und Dokumente auf, die keine Rechnungen sind. Definiere vor der Änderung des Prompts, wie das System jeden Fall behandeln soll.
| Fehler | Änderung zum Vergleich | Prüfung |
|---|---|---|
| Pflichtfeld fehlt | Feld präzisieren und ein passendes Beispiel hinzufügen | Feld ist vorhanden, wenn die Quelle es belegt |
| Wert erfunden | Verhalten bei fehlenden Werten festlegen und Belege bereitstellen | Unbelegtes Feld bleibt leer |
| Antwort lässt sich nicht parsen | Ein unterstütztes Ausgabeschema verwenden | Parser akzeptiert die vollständige Antwort |
| Richtiger Wert aus der falschen Quelle | Identität der Quelle im Kontext erhalten | Wert gehört zum angefragten Dokument |
Eine durch ein Schema eingeschränkte Ausgabe kann Syntaxfehler beheben. Die Dokumentation zu Structured Outputs von vLLM beschreibt unterstützte Ausgabebeschränkungen. Ein gültiges JSON-Objekt kann trotzdem ein falsches Datum oder eine unbelegte Aussage enthalten. Prüfe daher die Werte separat.
Den Vergleich nachvollziehbar halten
Halte Model-Version, Decoding-Einstellungen, Quelldaten, Tool-Definitionen und Ausgabelimits beim Testen der Prompt-Änderung konstant. Erfasse Qualität, Fehlerkategorien, Tokens und Latency. Wiederhole nichtdeterministische Fälle oft genug, um zu sehen, ob die Verbesserung bestehen bleibt.
Few-Shot-Beispiele sollten die tatsächliche Vielfalt abdecken, einschließlich fehlender oder mehrdeutiger Eingaben. Füge sie für ein gemessenes Problem hinzu, statt anzunehmen, dass mehr Beispiele immer helfen. Auch die Position im Kontext kann eine Rolle spielen: Lost in the Middle stellte bei den getesteten Models und Aufgaben fest, dass die Nutzung von Belegen je nach Position unterschiedlich ausfiel.
Verwende explizite Schritte, wenn sie helfen, einen Fehler einzugrenzen. Beziehe aber die zusätzlichen Aufrufe und Schnittstellen in den Vergleich ein. Setze Berechtigungen und andere verbindliche Anwendungsregeln im Code durch; eine Systemnachricht allein kann sie nicht garantieren.
Der Abschnitt zu Prompts im Produktivbetrieb im LLM Engineering Guide erklärt die wichtigsten Techniken und ihre Grenzen.