Ihr Team verfügt über Prompts, die über die gesamte Codebasis verteilt sind. Einige befinden sich in Konfigurationsdateien. Einige sind fest codierte Zeichenfolgen. Einige kritische Punkte befinden sich in einem Google-Dokument, das von einer Person verwaltet wird. Niemand erinnert sich daran, warum die Systemaufforderung für die Zusammenfassungsfunktion lautet: „Reagieren Sie als hilfreicher britischer Bibliothekar“ – aber das Entfernen dieses Satzes verschlechtert die Ausgabe, also bleibt es dabei.
Auf diese Weise verwalten die meisten Teams Prompts, und es entspricht in etwa dem Schreiben von Code ohne Versionskontrolle im Jahr 2005. Es funktioniert so lange, bis es nicht mehr funktioniert, und wenn es nicht mehr funktioniert, haben Sie keine Ahnung, was sich geändert hat oder wie Sie es beheben können.
Schnelle technische Retrospektiven bringen die gleiche Disziplin in LLM-Interaktionen ein, die technische Retrospektiven in die Softwareentwicklung gebracht haben: systematische Überprüfung, gemeinsames Lernen und inkrementelle Verbesserung. Hier erfahren Sie, wie Sie es tatsächlich machen.
Das Problem mit Ad-hoc-Prompts
Die meisten Teams entwickeln Prompts in einem Zyklus, der wie folgt aussieht: Jemand schreibt eine Prompt, testet sie anhand einiger Beispiele, versendet sie und macht weiter. Wenn sich die Ausgabequalität verschlechtert oder ein neuer Fehlermodus auftritt, passt jemand die Prompt basierend auf dem spezifischen Fehlerfall an, unterbricht möglicherweise drei weitere Fälle im Prozess und der Zyklus wiederholt sich.
Die Probleme bei diesem Ansatz verschärfen sich:
Kein Verlauf. Wenn Sie eine Prompt ändern, ist die alte Version verloren. Wenn die neue Version schlechter ist, können Sie nicht einfach zurückkehren. Wenn jemand fragt: „Warum sagt die Prompt das?“, weiß niemand.
Kein gemeinsames Lernen. Die Person, die herausgefunden hat, dass das Hinzufügen von „Schritt für Schritt denken“ zur Argumentationsaufforderung die Genauigkeit spürbar verbessert, teilt diese Erkenntnis nicht. Die Person, die die nächste Aufforderung schreibt, lernt die gleiche Lektion von Grund auf.
Kein systematisches Testen. Prompts werden anhand aller Beispiele getestet, die Ihnen in den Sinn kommen, wobei es sich normalerweise um die einfachen Fälle handelt. Randfälle, gegnerische Eingaben und Verteilungsverschiebungen bleiben ungetestet, bis sie in der Produktion scheitern.
Keine Messung. „Die Ausgabe sieht besser aus“ ist die gebräuchlichste Bewertungsmethode. Besser wie? Im Vergleich zu was? Von wem gemessen? Ohne eine konsequente Bewertung lässt sich nicht erkennen, ob es sich bei Änderungen tatsächlich um Verbesserungen handelt.
Eine regelmäßige zeitnahe Retrospektive befasst sich mit allen vier dieser Probleme.
Was Sie in einer zeitnahen Retrospektive besprechen sollten
Sammeln Sie Ihre Beweise
Sammeln Sie vor der Retrospektive:
Produktionsfehler. Jeder Fall, bei dem eine LLM-basierte Funktion eine fehlerhafte Ausgabe erzeugte, die einem Benutzer auffiel. Erfassen Sie die Eingabe, die Prompt und die Ausgabe. Wenn Sie Benutzer-Feedback haben (Daumen nach unten, Beschwerden, Korrekturen), geben Sie dies an.
Prompt-Änderungen seit dem letzten Retro. Welche Prompts haben sich geändert, was war die Absicht hinter der Änderung und was geschah danach? Wenn Sie Ihre Prompts einer Versionskontrolle unterziehen (das sollten Sie tun), ist dies eine Diff-Überprüfung. Wenn nicht, ist dies der erste Aktionsgegenstand aus Ihrer Retro-Version.
Qualitätsmetriktrends. Wenn Sie automatisierte Auswertungen durchführen (mehr dazu weiter unten), bringen Sie die Trends mit. Verbessern sich die Dinge? Wird es schlimmer? Wohnung?
Kosten- und Latenzdaten. Prompts wirken sich direkt auf beide aus. Eine ausführliche Systemaufforderung, die die Qualität geringfügig verbessert, aber Ihre Token-Nutzung verdoppelt, ist ein Kompromiss, den es wert ist, explizit besprochen zu werden.
Das Gespräch
Eine gute zeitnahe Retrospektive deckt drei Fragen ab:
1. Wo versagen unsere Prompts und warum?
Klassifizieren Sie Ihre Fehler. Gemeinsame Kategorien:
- Anweisung folgt: Das Modell hat nicht getan, was in der Aufforderung verlangt wurde. Bedeutet normalerweise, dass die Anweisung mehrdeutig ist oder einem anderen Teil der Prompt widerspricht.
- Formatverstöße: Das Modell hat JSON zurückgegeben, wenn Sie einfachen Text wollten, oder umgekehrt. In der Regel mit klareren Formatspezifikationen und Beispielen behebbar.
- Halluzination: Das Modell generierte Informationen, die vom bereitgestellten Kontext nicht unterstützt werden. Hierbei kann es sich um ein sofortiges Problem (Anweisungen zur schwachen Erdung) oder um eine Modellbeschränkung handeln.
- Tone/Style Drift: Die Ausgabe klingt anders als beabsichtigt. Dies geschieht oft, wenn die Prompts lang sind und die Stilanweisungen untergehen.
- Randfallfehler: Die Prompt funktioniert bei typischen Eingaben, bricht jedoch bei ungewöhnlichen Eingaben ab. Hier schmerzt der Mangel an systematischen Tests am meisten.
Fragen Sie für jede Fehlerkategorie: Handelt es sich um ein Eingabeaufforderungsproblem, ein Modellproblem oder ein Eingabeproblem? Die Lösung ist bei jedem anders.
2. Was haben wir über die Anregung dieses Modells gelernt?
Jedes Modell hat Macken. GPT-4 reagiert auf dieselbe Prompt anders als Claude und beide ändern ihr Verhalten bei Aktualisierungen. Ihr Team sammelt durch die tägliche Arbeit Wissen über diese Besonderheiten – in der Retrospektive wird dieses Wissen geteilt und dokumentiert.
Nützliche Dinge zum Erfassen:
- Techniken, die die Leistung zuverlässig verbessern (und für welche Arten von Aufgaben)
- Ansätze, die scheinbar funktionieren sollten, aber nicht funktionierten
- Modellverhalten ändert sich nach Anbieteraktualisierungen
- Aufforderungsmuster, die für Ihre spezifischen Anwendungsfälle gut funktionieren
Dadurch entsteht eine Team-Wissensbasis, die verhindert, dass jeder die gleichen Lektionen wiederentdeckt.
3. Was sollten wir als nächstes ändern oder testen?
Identifizieren Sie anhand der Fehler und Erkenntnisse spezifische Experimente. Gute Experimente sind:
- Enger Umfang (jeweils eine Sache ändern)
- Messbar (definieren Sie vor dem Test, was „besser“ bedeutet)
- Zeitgesteuert (für einen bestimmten Zeitraum oder eine bestimmte Anzahl von Auswertungen ausgeführt)
Beispiel: „Wir testen, ob das Hinzufügen von zwei Beispielen des gewünschten Ausgabeformats zur Kundendienstaufforderung Formatverstöße von 12 % auf unter 5 % reduziert, gemessen über 200 Produktionsabfragen.“
Aufbau einer Prompt-Management-Praxis
Retrospektiven sind effektiver, wenn Sie über ein grundlegendes Prompt-Management verfügen. Für den Anfang benötigen Sie keine ausgefallenen Werkzeuge – nur ein paar Übungen.
Versionskontrolle Ihrer Prompts
Behandeln Sie Prompts wie Code. Speichern Sie sie in Ihrem Repository, überprüfen Sie Änderungen in PRs und Tag-Versionen. Dies bietet Ihnen Verlaufs-, Rollback- und Überprüfungsfunktionen. Wenn eine sofortige Änderung die Qualität beeinträchtigt, können Sie genau sehen, was sich geändert hat, und sie rückgängig machen.
Erwägen Sie für Teams mit vielen Prompts eine dedizierte Verzeichnisstruktur:
prompts/
summarization/
system.txt
few-shot-examples.json
customer-service/
system.txt
escalation-rules.txt
classification/
system.txt
label-definitions.json
Erstellen Sie ein Evaluierungsset
Pflegen Sie für jede größere Prompt eine Reihe von Testfällen: Eingabe-Ausgabe-Paare, bei denen Sie wissen, wie eine gute Ausgabe aussieht. Dies muss nicht riesig sein – 20–50 Fälle pro Prompt, die den typischen Einsatz, Randfälle und bekannte Fehlermodi abdecken.
Führen Sie Ihren Evaluierungssatz aus, wenn Sie eine Prompt ändern. Dadurch werden Regressionen aufgefangen, bevor sie in die Produktion gelangen. Der Aufbau erfordert zunächst Zeit, spart aber deutlich mehr Zeit als das Debuggen von Produktionsfehlern.
Dokumentieren Sie Ihre Entscheidungen
Wenn Sie eine sofortige Änderung vornehmen, schreiben Sie eine kurze Notiz: Was war das Problem, was haben Sie geändert und warum haben Sie erwartet, dass es hilft. Dies erscheint Ihnen wie ein Aufwand, bis Sie drei Monate später auf eine Prompt starren und sich fragen, warum diese eine scheinbar zufällige Anweisung enthält, die sich jedoch als kritisch herausstellt.
Schnelle retrospektive Formate, die funktionieren
Nicht jedes Retro muss gleich sein. Hier sind zwei Formate, die bei unterschiedlichen Kadenzen gut funktionieren:
Die Kurzübersicht (30 Minuten, zweiwöchentlich)
Für Teams, die schnell iterieren. Überprüfen Sie die Produktionsausfälle seit der letzten Sitzung, besprechen Sie alle vorgenommenen sofortigen Änderungen, teilen Sie jeweils eine wichtige Erkenntnis mit und wählen Sie das Experiment mit der höchsten Priorität für die nächsten zwei Wochen aus. Bleiben Sie straff und handlungsorientiert.
The Deep Dive (90 Minuten, monatlich)
Für den Fall, dass Sie einen Schritt zurücktreten und das Gesamtbild betrachten müssen. Überprüfen Sie Qualitätskennzahlen und Trends für alle Prompts. Wählen Sie die Prompt mit der schlechtesten Leistung aus und führen Sie eine gründliche Analyse durch: Gehen Sie Fehler durch, besprechen Sie die Grundursache, überlegen Sie sich Ansätze und entwerfen Sie ein geeignetes Experiment. Überprüfen Sie auch Ihre Eingabeaufforderungsbibliothek und Dokumentation auf Veraltung – sind Prompts veraltet oder unbenutzt?
Die Überprüfung des Vorfalls (ad-hoc)
Wenn ein sofortiger Fehler zu einem echten Vorfall für den Benutzer führt, führen Sie innerhalb weniger Tage eine gezielte Überprüfung durch. Was ist passiert, warum ist die Prompt fehlgeschlagen, warum haben unsere Tests sie nicht erkannt und was fügen wir unserem Bewertungssatz hinzu, um diese Art von Fehlern zu verhindern?
Häufige Fallstricke
Übertechnische Prompts. Längere Prompts sind nicht immer besser. Jede von Ihnen hinzugefügte Anweisung kann auf unvorhersehbare Weise mit jeder anderen Anweisung interagieren. Wenn Ihre Aufforderung mehr als 500 Wörter umfasst, überlegen Sie, ob Sie versuchen, zu viel in einer Aufforderung zu tun, und sie in eine Kette aufteilen sollten.
Optimierung für die falsche Metrik. Eine Prompt, die bei automatisierten Metriken gut abschneidet, aber Ausgaben erzeugt, die Benutzer als nicht hilfreich empfinden, ist keine gute Prompt. Beziehen Sie die menschliche Bewertung in Ihren Prozess ein, nicht nur die automatisierte Bewertung.
Kosten ignorieren. Sofortige Verbesserungen, die Ihren Token-Verbrauch verdoppeln, sind den Qualitätsgewinn möglicherweise nicht wert. Verfolgen Sie neben der Qualität auch die Kosten pro Anfrage und gehen Sie explizit Kompromisse ein.
Symptome statt Ursachen beheben. Wenn Sie immer wieder dieselbe Prompt für neue Fehlermodi patchen, muss die Prompt wahrscheinlich neu gestaltet werden und nicht erneut als Lösung. Ihre retrospektiven Daten zeigen dieses Muster – eine Prompt, die in Fehlerlisten mehrerer Retros erscheint, erfordert grundlegendere Aufmerksamkeit.
Keine Tests mit gegnerischen Eingaben. Ihre Benutzer werden Dinge tun, die Sie nicht erwarten. Ihre Retrospektive sollte in regelmäßigen Abständen einen Retrospektive darauf enthalten, was passiert, wenn die Prompt ungewöhnliche, feindselige oder außerhalb des Rahmens liegende Eingaben erhält. Warten Sie nicht auf einen Produktionsvorfall, um festzustellen, dass Ihre Prompt keine Leitplanken hat.
Erste Schritte
Sie müssen nicht alles geklärt haben, um zu beginnen. Hier ist ein minimaler erster Schritt:
- Wählen Sie Ihre wichtigste LLM-Funktion aus.
- Sammeln Sie 10 aktuelle Fehler (schlechte Ausgaben, Benutzerbeschwerden, alles, was nicht optimal ist).
- Verbringen Sie 30 Minuten mit Ihrem Team und klären Sie, warum die einzelnen Punkte gescheitert sind.
- Identifizieren Sie das häufigste Fehlermuster und entwerfen Sie ein Experiment, um dieses Problem zu beheben.
- Führen Sie das Experiment durch und überprüfen Sie die Ergebnisse in zwei Wochen.
Das ist Ihre erste prompte Retrospektive. Machen Sie es immer wieder und Sie werden die Muskeln aufbauen. Die Teams mit der besten KI-Ausgabequalität sind nicht diejenigen mit den intelligentesten Prompts – sie sind diejenigen, die systematisch aus ihren Fehlern lernen und nie denselben Fehler zweimal machen.
Probieren Sie NextRetro kostenlos aus – Klassifizieren Sie sofortige Fehler in Kategorien, stimmen Sie über Prioritäten ab und verfolgen Sie Verbesserungsexperimente über Sprints hinweg.
Letzte Aktualisierung: Februar 2026
Lesezeit: 7 Minuten
