Gesprächsdesign vs. Prompt Engineering
Gesprächsdesign legt fest, was der Agent tun soll; Prompt Engineering bringt ein Modell dazu, es zu tun. Wer die Reihenfolge vertauscht, optimiert das falsche Verhalten.
Gesprächsdesign (Conversation Design) heißt festzulegen, was ein KI-Agent tun und sagen soll: die Abläufe, die Beispiel-Turns, die Abzweigungen, in denen etwas schiefgeht, und die Regeln für die Übergabe an einen Menschen, vereinbart mit den Stakeholdern, noch bevor irgendetwas gebaut wird. Prompt Engineering heißt, ein Modell dazu zu bringen, es tatsächlich zu tun: die Anweisungen, Beispiele und Vorgaben zu schreiben und zu verfeinern, die ein bestimmtes Modell in dieses Verhalten lenken. Das eine ist eine Geschäftsentscheidung. Das andere ist eine Umsetzungstechnik. Die meisten Teams brauchen beides, und die Reihenfolge ist wichtiger, als viele erwarten.
Die beiden werden vermischt, weil beide Texte darüber hervorbringen, wie sich ein Agent verhalten soll, und weil in kleinen Projekten oft dieselbe Person beides am selben Nachmittag erledigt. Bei jedem Agenten, der mit Kundschaft spricht, eine Marke trägt oder mehr als einen Stakeholder hat, sind es verschiedene Aufgaben mit verschiedenen Verantwortlichen und verschiedenen Fehlerbildern. Wer beides verwechselt, landet bei einem hervorragend justierten Agenten, der das Falsche tut.
Was ist Gesprächsdesign?
Gesprächsdesign ist die Arbeit, das Verhalten eines Agenten Turn für Turn zu spezifizieren, und zwar in einer Form, die Menschen, die nie einen Code-Editor öffnen, lesen und abnehmen können. Es umfasst die Abläufe, Beispiel-Turns für jede Situation, die Daten, die der Agent in jedem Schritt abruft, die Abzweigungen für Timeouts, Absagen und verärgerte Kundschaft und die genauen Bedingungen, unter denen der Agent aufhört und das Gespräch an einen Menschen übergibt.
Kennzeichnend ist, mit wem es entsteht. Ein Gesprächsdesign wird mit Stakeholdern ausgehandelt: mit der Product Ownership, die das Projekt trägt, mit der juristischen Prüfung, die sich um die Versprechen des Agenten sorgt, mit den Markenverantwortlichen, denen wichtig ist, wie er klingt, und mit dem Kundenunternehmen, das dafür bezahlt. Das Ergebnis ist ein Designdokument, und seine Aufgabe ist es, gelesen zu werden, auf Widerspruch zu stoßen, überarbeitet und schließlich abgenommen zu werden. Wir erklären es ausführlicher in unserem Beitrag dazu, was Gesprächsdesign für KI-Agenten ist.
Was ist Prompt Engineering?
Prompt Engineering ist das Handwerk, den Text zu schreiben und Schritt für Schritt zu verbessern, der ein Modell steuert: Systemprompts, Aufgabenanweisungen, ausgearbeitete Beispiele, Vorgaben zum Ausgabeformat, Tool-Definitionen und die Leitplanken-Klauseln, die das Modell in seiner Spur halten. Es wird an einem bestimmten Modell gemacht, denn nur dort geht es überhaupt. Derselbe Prompt verhält sich auf verschiedenen Modellen unterschiedlich und auf der nächsten Version desselben Modells wieder anders.
Gute Fachleute für Prompt Engineering pflegen Eval-Sets, führen vor jedem Modell-Upgrade Regressionsläufe durch, kennen den Unterschied zwischen einer Anweisung, die ein Modell zuverlässig befolgt, und einer, die es nur an guten Tagen befolgt, und können Latenz und Kosten aus einer Pipeline herausholen, ohne Genauigkeit zu verlieren. Nichts davon ist trivial, und nichts davon verschwindet, wenn die Modelle besser werden; das Ziel bewegt sich weiter. Der Fehler, den man benennen sollte, ist enger gefasst: Prompt Engineering ist das falsche Instrument, um überhaupt zu entscheiden, was der Agent tun soll, denn die Menschen, denen diese Entscheidung gehört, können keinen Prompt prüfen.
Was unterscheidet Gesprächsdesign und Prompt Engineering tatsächlich?
Die beiden unterscheiden sich darin, wer die Arbeit verantwortet, was sie hervorbringt, wer sie prüft und wie sie scheitert.
| Gesprächsdesign | Prompt Engineering | |
|---|---|---|
| Verantwortung | Eine Fachperson aus Design, Analyse oder Product Ownership, die mit Stakeholdern arbeitet | Eine Fachperson aus Entwicklung oder Prompt-Erstellung, die an einem Modell arbeitet |
| Ergebnis | Ein lesbares Design: Turns, Abzweigungen, Tool-Schnittstellen, Eskalationsregeln | Ein Systemprompt, Beispiele und ein Eval-Set, die zusammen mit dem Code gepflegt werden |
| Geprüft von | Fachbereich, Recht, Marke, Kundenseite: Menschen, die es von Anfang bis Ende lesen | Entwicklung, über Evals, Regressionsläufe und die Durchsicht von Transkripten |
| Anlass für Änderungen | Das Unternehmen ändert seine Meinung: Richtlinie, Umfang, Tonfall, ein neues Szenario | Das Modell ändert sich: ein Versions-Upgrade, eine Regression, eine neue Fähigkeit |
| So scheitert es | Der Agent tut selbstsicher etwas, dem niemand zugestimmt hat | Der Agent kennt das Ziel und verfehlt es: ignorierte Anweisungen, Abdriften, falsches Format |
Die letzte Zeile ist die wichtigste. Ein Designfehler zeigt sich in einem Meeting: Jemand aus der Führungsebene liest ein Transkript und fragt: „Seit wann bieten wir das an?“ Ein Prompting-Fehler zeigt sich in einem Eval: Dem Agenten wurde das Ziel genannt, und er hat es verfehlt. Der erste ist teuer, weil er spät entdeckt und quer durch die Abteilungen ausgefochten wird. Der zweite ist billig zu finden, wenn Sie Evals haben, und bis zum Produktivbetrieb unsichtbar, wenn nicht.
Warum kommt es auf die Reihenfolge an?
Prompt Engineering ist Optimierung, und Optimierung braucht ein Ziel. Jede Stunde, die in die Justierung eines Prompts fließt, macht den Agenten besser in dem Verhalten, das die Person, die den Prompt schreibt, gerade für gewünscht hält. Wurde diese Überzeugung nie aufgeschrieben und vereinbart, funktioniert die Justierung trotzdem; sie steuert nur auf eine private Vermutung zu.
Angenommen, eine Fachperson für Prompt Engineering bekommt den Auftrag „Bauen Sie einen Erstattungsagenten, machen Sie ihn hilfreich.“ Sie leistet hervorragende Arbeit: Der Agent zeigt Einfühlungsvermögen, löst Anliegen schnell und bewilligt grenzwertige Erstattungen, weil Hilfsbereitschaft der Auftrag war und Großzügigkeit in Evals gut abschneidet. Wochen später liest die Finanzabteilung die Transkripte und entdeckt eine Erstattungsrichtlinie, die niemand genehmigt hat, erfunden Anweisung für Anweisung. Die Fachperson hat ihre Arbeit richtig gemacht. Das Ziel war falsch, und kein Prompting-Geschick hätte das auffangen können, denn dafür hätten die Verantwortlichen für die Erstattungsrichtlinie das beabsichtigte Verhalten lesen müssen, bevor es umgesetzt wurde.
Hinzu kommt ein schlichtes Kostengefälle. Eine Zeile in einem Design zu ändern kostet Minuten und einen Kommentar-Thread. Ein falsches Ziel nach der Justierung zu entdecken kostet die Justierung, die erneute Justierung und den Streit darüber, wer schuld war. Zuerst zu entscheiden ist auch dann günstiger, wenn die Entscheidung schwerfällt, und meist ist es gerade deshalb günstiger, weil sie schwerfällt: Die Auseinandersetzungen finden an einem Dokument statt und nicht an einem laufenden Agenten.
Wann zählt Gesprächsdesign am meisten, und wann Prompt Engineering?
Gesprächsdesign zahlt sich vor der Umsetzung aus und an jeder Stelle, an der eine Einigung nötig ist. Am wichtigsten ist es, wenn der Agent in einem regulierten Bereich mit Kundschaft spricht, wenn ein Kundenunternehmen zahlt und irgendwann sagen wird: „So haben wir das nicht vereinbart“, wenn Recht oder Compliance Formulierungen abnehmen müssen und wenn das interessante Verhalten in den Abzweigungen für den Fehlerfall liegt statt im Regelfall. Zu diesem letzten Punkt: Die Abzweigungen sind meist das ganze Spiel; dieses Argument haben wir in Der Regelfall ist kein Design ausgeführt.
Prompt Engineering zahlt sich aus, sobald das Ziel feststeht. Am wichtigsten ist es, wenn Zuverlässigkeit der Engpass ist: Werkzeugaufrufe jedes Mal korrekt zu formatieren, das Verhalten bei böswilligen Eingaben stabil zu halten, Antworten im vereinbarten Umfang zu belassen und den Agenten ohne Regressionen durch eine Modellmigration zu bringen. Es zählt auch immer dann, wenn das Design etwas verlangt, das dem aktuellen Modell schwerfällt, und genau diese Information muss die Designseite hören.
Wie läuft die Übergabe zwischen Gesprächsdesign und Prompt Engineering?
Das Design ist zugleich das Anforderungsdokument und die Eval-Quelle für das Prompt Engineering. Jede Abzweigung im Design ist ein Testfall: Die Abzweigung für das Timeout, die für die Absage und die für verärgerte Kundschaft beschreiben jeweils eine Eingabe und die vereinbarte Antwort. Der Abschnitt zur Stimme liefert ausgearbeitete Beispiele für passende und unpassende Antworten, also Few-Shot-Material. Die Tool-Schnittstellen legen fest, was jeder Aufruf braucht und was passiert, wenn er scheitert. Die Eskalationsregeln werden zu den harten Klauseln im Systemprompt. Wer ein echtes Design in der Hand hat, beginnt im Prompt Engineering mit Ziel, Vorgaben und Testsatz, die schon geschrieben sind.
Die Übergabe läuft auch in die andere Richtung, und genau diesen Teil überspringen Teams. Stellt sich bei der Justierung heraus, dass das Modell nicht zuverlässig leisten kann, was ein Turn verlangt, ist das eine Design-Tatsache, und sie gehört zurück ins Design, wo Stakeholder sie sehen und den Rückfallplan vereinbaren können. Sie stillschweigend im Prompt zu flicken, öffnet die ursprüngliche Lücke wieder: Das vereinbarte Dokument und das tatsächliche Verhalten laufen auseinander, und das nächste „Seit wann tut er das?“ ist schon vorprogrammiert. Der Kreislauf schließt sich erst, wenn das Design die Referenz bleibt, die beide Seiten pflegen. Diese Referenz macht auch die Abnahme überhaupt erst möglich, was gerade Beratende auf die harte Tour lernen; siehe den Beitrag zur Abnahme eines Agent-Designs durch das Kundenunternehmen.
In Klate werden die Turns, Abzweigungen und Tool-Schnittstellen als ein Dokument geschrieben, geprüft und abgenommen, bevor jemand einen Playground öffnet. Wenn Ihr nächster Agent Stakeholder hat, liegt der günstigste Moment, um herauszufinden, was sie tatsächlich wollen, vor dem ersten geschriebenen Prompt.
