Sechsteiliger Engineering-Leitfaden: von einzelnen Prompts zu spezifikationsgetriebener, probabilistischer Software.
Prompt Engineering wird zur Programmierung lesen →Ausführung: Lebenszyklus, Transaktionen und Evaluierung (Evals)
Ein deklarierter Lifecycle für das Modell, Transaktionssemantik für Agent-Aktionen, eval-getriebene Entwicklung und natürliche Sprache als Quellcode.
Das Modell arbeitet in einem deklarierten Lifecycle
Das Modell darf Entscheidungen innerhalb eines Zustands treffen. Normaler Code steuert, welche Zustandsübergänge zulässig sind.
Ein deklarierter Lifecycle gibt jedem Lauf einen bekannten Zustand, eine Menge zulässiger Übergänge und ein Ende. Ohne ihn können Sie die beiden Fragen nicht beantworten, die in jedem Vorfall aufkommen: Wo steht dieser Prozess gerade, und was kostet es, wenn er weiterläuft. Explizite Zustände machen den Fortschritt außerdem in Geschäftsbegriffen berichtbar statt in Log-Zeilen, und geben dem Betrieb einen belastbaren Punkt zum Eingreifen.
Agent-Aktionen wie Transaktionen behandeln
Manche Aktionen lassen sich nicht vollständig rückgängig machen: eine E-Mail versenden, eine Zahlung belasten, sensible Daten veröffentlichen, bestimmte Domains registrieren, externe Ressourcen ohne Backup löschen. Diese erfordern eine Freigabe vor der Ausführung.
Agent-Aktionen berühren echte Systeme, also brauchen sie die Disziplin, die Sie bei Datenbankarbeit bereits anwenden: planen, Vorschau, anwenden, verifizieren, committen, mit einem definierten Rollback. Fehlt diese Abfolge, hinterlässt ein Fehler auf halbem Weg die Umgebung in einem inkonsistenten Zustand, und die Bereinigung ist manuell, langsam und wird meist von Ihren erfahrensten Leuten erledigt. Umkehrbarkeit ist außerdem das, was es sicher macht, mit der Zeit mehr Autonomie zu gewähren, weil Fehler aufhören, dauerhaft zu sein.
Test-driven Development für probabilistische Software
Weil Ausgaben variieren, beweist ein einzelner Durchlauf nichts. Führen Sie mehrere Durchläufe aus, vergleichen Sie die Verteilung der Scores gegen eine Baseline und deployen Sie nur, wenn es besser ist.
Prompt oder Workflow anpassen →
Mehrere Durchläufe ausführen → Ergebnisse vergleichen →
Nur deployen, wenn es besser ist
Wesentliche Regel: verifizieren Sie den finalen Zustand der Umgebung, nicht bloß die schriftliche Behauptung des Modells, dass die Aufgabe erledigt ist.
Ein Eval-Set ist die Regressions-Suite für probabilistische Software. Es ist das, womit Sie sagen können, ob ein neues Modell, ein neues Prompt oder eine Kontextänderung tatsächlich etwas verbessert hat, statt aus Anekdoten und den letzten drei Beispielen zu argumentieren, die jemand zufällig ausprobiert hat. Teams, die hier investieren, können ein neues Modell binnen Tagen einführen und die Entscheidung mit Zahlen belegen; Teams, die das nicht tun, sind strukturell nicht in der Lage, sicher zu upgraden, und ihre Qualitätsdiskussionen kommen nie zu einem Ergebnis.
Natürliche Sprache als Quellcode
natürlicher Sprache
Repräsentation
Spezifikation
Richtung
plan
Code-Änderungen
Artefakt
Eine Anfrage als Quellcode zu behandeln, der Stages durchläuft, vom geparsten Intent über Spezifikation, Plan und Ausführung bis zur Verifizierung, hat einen sehr praktischen Vorteil: Wenn die Ausgabe falsch ist, können Sie sagen, welche Stage falsch war. Systeme, die als ein einziger undurchsichtiger Aufruf gebaut sind, lassen sich im Nachhinein nicht diagnostizieren, sodass jeder Vorfall wieder mit Raten beginnt und jeder Fix spekulativ ist. Die Zwischenartefakte aufzubewahren ist günstig; sie nicht zu haben, ist das, was Post-mortems ergebnislos macht.
Weitere Artikel
Zuverlässige UX für vernetzte Geräte über Hardware, Apps, BLE, Wi-Fi, Cloud, Onboarding und Fehlerfälle hinweg gestalten.
UX für vernetzte Geräte: Erlebnisse über Hardware, Apps, Konnektivität und Cloud gestalten lesen →Companion Apps für Hardware: schwierige Teile, Partner-Fähigkeiten und Fragen, die Spezialisten von Agenturen trennen.
So wählen Sie den richtigen Companion-App-Partner für Ihr Hardware-Produkt lesen →