Capstone: der Prompt unter Betriebsdruck

Der Fall

Ein Assistent für den Zweitlevel-Support geht in vier Wochen in Produktion. Er beantwortet Fragen zu Verträgen und Richtlinien aus einem internen Dokumentenbestand, liest zusätzlich die eingegangene Kunden-E-Mail mit, schreibt seine Antwort als Kommentar in das Ticketsystem und setzt drei Metadatenfelder für die Weiterverarbeitung.

• Volumen — etwa 12.000 Vorgänge pro Monat, verteilt auf 40 Bearbeiter.
• Material — 2.400 interne Dokumente, gewachsen, teils in mehreren Fassungen, mit Ausstellungsdatum als Metadatum.
• Datenzugang — lesend auf die Kundendatenbank, damit der Vertragsstatus erwähnt werden kann.
• Ausgabe — ein Kommentar in Markdown plus drei Metadatenfelder, die ein Routing auslösen.
• Vorgeschichte — ein Prototyp mit gut gestellten Einzelfragen hat überzeugt; ein Eval-Set gibt es nicht.

Schritt 1: Aufgabe und Vertrag festlegen

Bevor eine Zeile Prompt entsteht, wird der Vertrag geschrieben. Der Fall hat zwei Konsumenten mit verschiedenen Bedürfnissen: einen Menschen, der den Kommentar liest, und ein Routing, das die Metadatenfelder auswertet. Beide brauchen eine eigene Zusicherung.

Die Reihenfolge ist nicht beliebig. Wer zuerst den Prompt schreibt und den Vertrag später dokumentiert, dokumentiert das, was entstanden ist — und verliert damit die Gelegenheit, die unbequemen Fragen früh zu stellen. Zwei davon entscheiden diesen Fall: Welche Zusicherung gibt der Kommentar, auf die ein Bearbeiter sich verlassen darf, wenn er auf ihrer Grundlage einem Kunden antwortet? Und was passiert mit einem Vorgang, für den der Assistent keine belegte Antwort hat? Beides sind Produktentscheidungen, nicht Formulierungsfragen.

Vertragsposition

Für diesen Fall

Vorbedingung

E-Mail nicht leer, Vorgang existiert, Dokumentenbestand erreichbar — geprüft im Code des Aufrufers.

Nachbedingung Kommentar

3 bis 6 Sätze, Fließtext, jede Tatsachenaussage mit auffindbarer Belegstelle.

Nachbedingung Metadaten

Drei benannte Felder mit festem Wertebereich, nicht belegte Felder null.

Nicht-Pflicht

Keine Zusicherung über Richtigkeit oder Aktualität der Dokumente selbst.

Schritt 2: Kontext budgetieren

Der naheliegende Aufbau — alle abgerufenen Abschnitte, die ganze E-Mail, der Vertragsstatus, der Ticketverlauf — ist zugleich der teuerste und der schlechteste. Bei 12.000 Vorgängen monatlich ist jedes feste Token ein Abonnement, und jeder irrelevante Abschnitt verdrängt die relevanten an schlechtere Positionen.

Eine Zahl lohnt sich vorab: 12.000 Vorgänge pro Monat mal 1.000 zusätzliche Eingabe-Tokens sind 12 Millionen Tokens monatlich für einen einzigen Block. Diese Rechnung ist in fünf Minuten gemacht und beendet die meisten Diskussionen darüber, ob ein Glossar oder ein Beispielblock im Prompt bleiben soll — sie verschiebt die Frage von Geschmack auf gemessenen Nutzen gegen bekannte Kosten.

Posten

Behandlung im Fall

Instruktion und Schema

Reserviert, stabil am Anfang für die Cache-Wiederverwendung.

Abgerufene Abschnitte

Obergrenze mit dokumentierter Priorität; die stärksten an die Ränder.

E-Mail-Text

Reserviert, abgegrenzt, nach hinten.

Vertragsstatus

Nur wenn er gebraucht wird — und siehe Schritt 7.

Reserve für die Ausgabe

Reserviert, sonst wird der Kommentar abgeschnitten.

Schritt 3: Ausgabe erzwingen — aber nur den richtigen Teil

Die Ausgabe hat zwei Teile mit gegensätzlichen Anforderungen. Die drei Metadatenfelder werden von einer Maschine gelesen und gehören unter Schema-Zwang. Der Kommentar wird von einem Menschen gelesen — und ein engmaschiges Format kostet dort messbar Urteilsqualität.

Der tragfähige Zuschnitt ist deshalb geteilt: Freitext für den Kommentar, erzwungenes Schema für die Metadaten. Und für beide gilt die vollständige Prüfkette — syntaktisch, schematisch, semantisch. Die dritte Stufe ist hier keine Formalität: Eine erfundene, formal gültige Kategorie schickt den Vorgang in eine Warteschlange, in der ihn niemand erwartet.

Für die drei Metadatenfelder gilt zusätzlich, was ein abschließendes Schema braucht: benannte Pflichtfelder, verbotene Zusatzfelder und ein Enum, das den unbekannten Fall zulässt. Fehlt der Restwert, schickt eine neue Vorgangsart ihre Fälle in eine der bestehenden Kategorien — ohne Fehler, ohne Spur, und mit einer Zuordnungsquote von 100 %, die niemandem auffällt.

Schritt 4: Belegpflicht und Enthaltung

Der Bestand hat 2.400 gewachsene Dokumente — also gibt es Fragen, die er nicht abdeckt, und Fragen, zu denen er sich widerspricht. Beides braucht ein definiertes Verhalten, sonst entsteht die flüssige, plausible und falsche Antwort, die im Review nicht auffällt.

• Belegpflicht — je Tatsachenaussage eine wortwörtliche Stelle plus Dokument-ID, programmatisch gegen den Bestand geprüft.
• Enthaltung — ein eigenes Feld mit Grund, nicht ein Satz im Kommentar; die Quote wird erhoben.
• Teilabdeckung — belegte Teilfragen beantworten, unbelegte ausdrücklich kennzeichnen.
• Widerspruch — das Ausstellungsdatum liegt als Metadatum vor, also ist die Vorrangregel anwendbar und beide Fundstellen gehören belegt.

Zur Prüfung gehört die Grenze: Eine Textsuche belegt, dass die zitierte Stelle im Dokument existiert — nicht, dass die Aussage daraus folgt. Genau diese zweite Fehlerart bleibt und braucht eine Stichprobe durch Menschen. In einer Untersuchung generativer Suchsysteme waren nur rund die Hälfte der erzeugten Sätze vollständig durch ihre Zitate gestützt, bei durchweg flüssigen Antworten — Flüssigkeit ist also kein Hinweis auf Beleglage.

Schritt 5: Verweigerung und Eskalation

Support-Fragen berühren Themen, zu denen dieser Assistent nichts sagen darf — individuelle Rechtsauskünfte etwa. Das ist keine Enthaltung, sondern eine Verweigerung: Nicht die Grundlage fehlt, eine Regel untersagt es. Die Unterscheidung muss in der Ausgabe unterscheidbar sein, sonst ist keine der beiden Quoten deutbar.

Und die Eskalation braucht mehr als einen Satz. Bei 12.000 Vorgängen monatlich ist die erwartete Menge vorab zu schätzen und mit der zuständigen Stelle abzustimmen — sonst entsteht eine Warteschlange, von der niemand weiß, und Bearbeiter lernen, die Frage umzuformulieren, bis der Assistent doch antwortet.

Und die Gegenrichtung gehört gemessen. Nach jedem Vorfall wird jemand vorschlagen, die Verweigerungsregel zu verschärfen — das ist die organisatorisch risikolose Entscheidung, weil zu viel Verweigerung keinen Beschwerdeführer hat. Ohne eine Menge zulässiger, themennaher Fälle, die beantwortet werden müssen, läuft dieses Projekt in zwei Jahren als System, das kaum noch antwortet und für jede Regel eine Begründung hat.

Schritt 6: Das Regelwerk widerspruchsfrei halten

Nach dem ersten Betriebsmonat wird der System-Prompt Regeln angesammelt haben — nach jedem Vorfall eine. Der Fall enthält bereits einen absehbaren Konflikt: Die Nachbedingung verlangt höchstens 6 Sätze, und eine Pflichtangabe bei rechtlich berührten Themen wird länger sein.

Beide Regeln stehen auf derselben Ebene, also entscheidet keine Hierarchie. Es braucht eine deklarierte Präzedenz oder eine präzisierte Bedingung — und einen Testfall über die Überschneidung, sonst hebt die nächste Prompt-Änderung die Entscheidung unbemerkt auf.

Ein zweiter Konflikt ist in diesem Fall vorprogrammiert und weniger offensichtlich: Die Belegpflicht verlangt eine wortwörtliche Fundstelle je Aussage, und die Längenvorgabe begrenzt den Kommentar. Bei einer Frage mit drei belegten Teilaspekten konkurrieren beide direkt. Auch hier gilt: Präzedenz deklarieren oder die Bedingung präzisieren — und einen Testfall über die Überschneidung anlegen.

Schritt 7: Vertrauensgrenzen ziehen

Hier liegt das schärfste Risiko des Falls, und es entsteht aus einer Kombination, die im Entwurf harmlos aussieht: Der Assistent liest fremden Text (die Kunden-E-Mail und die Dokumente), hat Zugang zu privaten Daten (Kundendatenbank, interne Vorgangsnotizen) und schreibt in ein Feld, das als Markdown gerendert wird — ein Weg nach außen.

Schritt 8: Mehrturn-Zustand

Der Prototyp funktionierte mit gut gestellten Einzelfragen. In Produktion werden Bearbeiter nachfragen, präzisieren und korrigieren — der Fall, für den ein Einbruch von durchschnittlich 39 % gemessen wurde, mit dem Hauptanteil in der Zuverlässigkeit und nicht in der Fähigkeit.

Die Konsequenzen für den Entwurf sind zwei. Erstens gehört alles, was der Vorgang ist — die erkannte Frageart, die bereits belegten Teilfragen, ob eskaliert wurde — in den Anwendungszustand und wird als Feld mitgegeben, nicht aus dem Verlauf erschlossen. Zweitens braucht ein verfahrenes Gespräch einen konsolidierten Neustart, den die Anwendung aus diesem Zustand aufbaut, ohne dass der Bearbeiter etwas wiederholt.

Praktisch heißt das für diesen Fall: Die erkannte Frageart, die belegten Teilfragen, der Eskalationsstatus und die bereits genannten Dokument-IDs gehören in Felder, die die Anwendung führt. Der Verlauf trägt dann nur noch, was gesagt wurde — und kann verdichtet oder verworfen werden, ohne dass der Vorgang Schaden nimmt.

Schritt 9: Eval-Set und Gate

Der Fall hat kein Eval-Set — das ist der eigentliche Befund der Vorgeschichte. Ohne Fallmenge ist keine der bisherigen Entscheidungen überprüfbar, kein Modellwechsel machbar und kein Vorfall gegen Rückfall gesichert.

Fallsorte

Warum sie im Set sein muss

Echte Fehler aus dem Pilotbetrieb

Relevant und mit bekanntem Sollwert.

Grundlast je Metadatenkategorie

Zeigt, dass die Basis hält.

Fälle mit Abwesenheit als Sollwert

Prüft, dass null und Enthaltung korrekt gewählt werden.

Gegenfälle zu jeder Verweigerungsregel

Verhindert, dass Verschärfungen in die Übervorsicht laufen.

Konflikt-Testfälle

Hält jede deklarierte Präzedenz gegen künftige Änderungen.

Injection-Fälle

Prüft, dass Fremdtext keine Handlung auslöst.

Mehrturn-Verläufe, mehrfach ausgeführt

Zeigt Drift und Streuung, die Einzelanfragen verbergen.

Der Pilotbetrieb ist dabei die wertvollste Quelle, und er ist nur einmal verfügbar. Jede Fehlantwort aus diesen Wochen ist ein Fall mit bekanntem Sollwert, kostenlos entstanden und garantiert relevant — wer sie nicht einsammelt, muss sie später erfinden. Deshalb gehört das Einsammeln in den Pilotplan und nicht in die Zeit danach.

Dein Entscheidungsprotokoll

Für die folgenden Aufgaben lohnt sich eine Haltung, die im Berufsalltag denselben Dienst tut: Notiere je Entscheidung, was du festlegst, warum, und was es kostet. Der dritte Teil ist der, der in Entwurfsdokumenten fehlt — und der, an dem sich sechs Monate später entscheidet, ob eine Maßnahme verteidigt oder stillschweigend zurückgebaut wird.

Die Kostenangabe ist auch der Prüfstein für die eigene Argumentation. Eine Maßnahme, für die dir kein Preis einfällt, hast du wahrscheinlich noch nicht verstanden — in diesem Fall etwa: Der Ausgangskanal wird geschlossen und nimmt 40 Bearbeitern eine legitime Funktion; die Belegpflicht macht Antworten kürzer und vorsichtiger; der Eskalationspfad verlagert Arbeit auf Menschen; und das Eval-Set kostet Wochen, bevor es zum ersten Mal etwas verhindert.

Was der Capstone prüft — gleich im Check

Die folgenden Aufgaben führen durch denselben Fall: Spezifikation und Vertrag, Kontextbudget, erzwungene Ausgabe am richtigen Teil, Belegpflicht und Enthaltung, Vertrauensgrenzen, Regelkonflikt, Eval und Gate — und am Ende ein Vorfall, in dem mehrere Achsen zusammenkommen. Jede Aufgabe nennt dazu den Preis der richtigen Wahl, denn genau der entscheidet in vier Wochen, ob die Maßnahme den ersten Widerspruch übersteht.