Prompts sind Code, also haben wir aufgehört, sie wie Prosa zu bearbeiten
Unser wichtigster System-Prompt war auf neunhundert Wörter angewachsen, zusammengetragen von sechs Personen über vier Monate. Jede Zeile war aus einem Grund ergänzt worden, und kein Grund war aufgeschrieben.
Wie es dazu kam
Neunhundert Wörter, und jedes einzelne für sich vertretbar. Eine Zeile dazu, keine Auftragsnummern zu erfinden, ergänzt nach einem Vorfall. Ein Absatz zum Ton, ergänzt nach einer Beschwerde. Drei Sätze zu Datumsformaten, die sich überschneiden und einander leicht widersprechen, ergänzt von verschiedenen Personen in verschiedenen Wochen.
Das Symptom waren nicht schlechte Ausgaben. Es war Lähmung. Eine Änderungsanfrage kam, jemand sah in den Prompt, und das Gespräch endete damit, dass niemand etwas entfernen wollte — für den Fall, dass es tragend war.
Die Rahmung, die wir übernommen haben
Khattab und Kollegen haben vorgeschlagen, Sprachmodell-Pipelines als Programme zu behandeln, die kompiliert werden, statt als Prompts, die von Hand geschrieben werden — mit Formulierungen, die gegen eine Metrik erzeugt und verbessert werden, statt nach Gefühl bearbeitet.
Wir haben nicht das Framework übernommen, sondern die Prämisse, und die ist der übertragbare Teil: Wenn ein Prompt Verhalten bestimmt, ist er eine Komponente — und Komponenten werden versioniert, geprüft und getestet. Einen nach Gefühl zu bearbeiten heißt, Produktionsverhalten ohne Test zu ändern.
Was wir tatsächlich tun
Der Prompt wird aus benannten Fragmenten zusammengesetzt, jedes in einer eigenen Datei, jedes mit einem Kommentar, warum es existiert und aus welchem Vorfall oder welcher Anforderung es stammt. Ausgeliefert wird das Zusammengesetzte; bearbeitet werden die Fragmente.
Jedes Fragment, das ein Verhalten festlegt, hat mindestens einen Fall im Bewertungsset, der scheitert, wenn man das Fragment entfernt. Das ist die ganze Disziplin, und sie ist es, die Löschen erst möglich macht: Fragment raus, Set laufen lassen, sehen ob überhaupt etwas daran hing.
| Prompt als Prosa | Prompt als Komponente |
|---|---|
| Eine lange Datei, die alle bearbeiten | Benannte Fragmente mit Zuständigkeit |
| Warum eine Zeile existiert, ist Überlieferung | Steht neben der Zeile |
| Löschen ist ein Risiko | Löschen ist ein Testlauf |
| Änderungen werden gelesen | Änderungen werden per Diff und Ergebnis geprüft |
Was der erste Durchgang zutage brachte
Rund zweihundert Wörter fielen durch: Ihr Entfernen änderte nichts Messbares. Manche waren anders formulierte Dubletten. Manche wiesen Verhalten an, das das Modell ohnehin zeigte. Ein Absatz adressierte einen Fehlermodus, den eine Schemaänderung Monate zuvor beseitigt hatte.
Wir haben sie gelöscht. Die Ausgabequalität bewegte sich nicht, Latenz und Tokenkosten sanken leicht, und die verbliebenen siebenhundert Wörter wurden zu etwas, das eine neue Kollegin in einem Zug lesen kann.
Wo es uns etwas kostet
Die Disziplin ist nicht umsonst. Jedes verhaltensbestimmende Fragment braucht einen Fall, und einen Fall zu schreiben, der ohne das Fragment wirklich scheitert, dauert länger als das Fragment selbst. Bei kleinen Prompts lohnt der Aufwand nicht, und unterhalb von etwa hundert Wörtern wenden wir das nicht an.
Es gibt außerdem einen Fehlermodus, auf den wir achten: ein Fall, der aus dem falschen Grund besteht, sodass ein Fragment nötig aussieht, obwohl das Modell sich ohnehin richtig verhalten hätte. Einige davon fangen wir, indem wir zwei Fragmente gleichzeitig entfernen und prüfen, ob die Fehlerzahl dazu passt.
Was wir nicht behaupten
Wir behaupten nicht, automatische Prompt-Optimierung sei überflüssig. Für Pipelines mit klarer Metrik schlägt sie Handarbeit deutlich, und wir würden sie einsetzen, wo die Metrik belastbar ist. Bei uns ist sie es oft nicht — eine Aussage über unsere Bewertung, nicht über das Verfahren.
Wir behaupten auch nicht, ein getesteter Prompt sei ein richtiger. Die Tests halten die Fehler fest, die wir bereits kennen. Der Prompt bleibt eine Menge Anweisungen an ein System, das ihnen nicht folgen muss.