The prompting playbook

Hallo zusammen. Ähm, vielen Dank, dass Sie heute Nachmittag im Breakout-Raum dabei sind. Die letzte Sitzung heute von Code mit Claude. Ich hoffe, Sie hatten bisher alle einen fantastischen Tag. Mein Name ist Margot Vanlar. Ich bin angewandte KI-Ingenieurin bei Anthropic hier in London. Und heute Nachmittag werden wir über das Prompting-Playbook sprechen. Und Prompting ist wohl eine der ersten Fähigkeiten, wenn nicht sogar die erste Fähigkeit, die wir als Ingenieure lernen mussten, als wir anfingen, mit LLMs zu arbeiten. Und auch jetzt ist es immer noch eine der kritischsten Fähigkeiten, um effektive KI-Systeme aufzubauen.

Heute werden wir also einige Best Practices im Kontext von zwei praktischen Szenarien diskutieren, denen Sie wahrscheinlich bei der Arbeit begegnen werden. Das erste ist, wenn Sie einen bestehenden Prompt in der Produktion haben, den Sie seit einiger Zeit pflegen, und ihn möglicherweise auf ein neues Modell migrieren oder eine Änderung an der Architektur vornehmen und er aus irgendeinem Grund nicht mehr so gut funktioniert. Das zweite Szenario ist, wenn wir einen völlig neuen agentischen Anwendungsfall von Grund auf neu aufbauen und den Prompt von Null auf Eins aufbauen müssen.

Um diese Best Practices zu veranschaulichen, möchte ich Ihnen nicht nur eine Liste von Dos und Don'ts geben. Ich möchte ein praktisches Beispiel durchgehen, das von echten Prompts inspiriert wurde, die ich bei einigen unserer Kunden gesehen habe, die auf Claude aufbauen. Der Prompt, den wir uns heute ansehen werden, ist ein miniaturisiertes Beispiel. Die Prompts, mit denen Sie arbeiten, sind wahrscheinlich viel länger und komplexer als der, den wir heute sehen werden. Aber er ist repräsentativ für einige häufige Probleme, auf die Sie bei der Pflege eines Prompts stoßen könnten.

Stellen Sie sich also vor, wir haben einen Prompt, an dem mehrere Personen zusammengearbeitet haben. Es gibt keinen klaren Eigentümer. Er deckt viele verschiedene Bereiche ab, wie z. B. Richtlinien, Ton, Prozesse. Wir haben einige Patches für frühere Modelle, zu denen wir migriert sind, die alle vermischt sind. Er ist aufgebaut und komplex. Und wenn wir zu einem neuen Modell migrieren, stellen wir fest, dass plötzlich viele unserer Testfälle nicht mehr so gut funktionieren wie erwartet.

Was passiert hier also tatsächlich? Um diese Frage zu entschlüsseln, brauchen wir einen Ausgangspunkt. Und dieser Ausgangspunkt sind Auswertungen. Wir brauchen Auswertungen, um die nötige Strenge zu gewährleisten, um zu verstehen, ob eine Änderung unseres Prompts tatsächlich mit einer Verbesserung seiner Leistung korreliert. Und wir haben verschiedene Modelle, die unterschiedliche Fähigkeiten und Verhaltensweisen haben. Und wenn Sie zu einem anderen Modell migrieren, könnte es sein, dass Ihr System aus zwei Gründen nicht mehr so gut funktioniert. Erstens, wenn das neue Modell fähig ist, aber sich anders verhält, und wir daher unser Prompting anpassen können, um dieses Verhalten zu beheben. Der zweite Fall ist, dass das Modell, zu dem wir wechseln, nicht so fähig ist und kein Prompting dies beheben kann. Wir brauchen also eine Auswertungs-Suite, die als Test für diese Regression dient, damit wir unsere besten Prompting-Praktiken darauf anwenden können.

Im Beispiel, das wir uns heute ansehen werden, wird es, wie gesagt, ein miniaturisiertes Beispiel sein. Wir werden fünf Testfälle in unserer Auswertung haben. In Wirklichkeit werden Sie viel mehr Testfälle in Ihrer Auswertungs-Suite haben, aber das Wichtigste hier ist, dass es repräsentativ für drei Schlüsselbereiche ist, die wir abdecken müssen. Diese drei Schlüsselbereiche umfassen einen Kontrollfall, der ein Fall ist, der immer bestehen sollte. Es ist etwas, das das Modell gut beherrscht. Es ist unzweideutig. Der zweite sind Grenzfälle. Und das sind Fälle, in denen das Modell zuvor versagt hat. Und indem wir Anweisungen in den Prompt aufnehmen, stellen wir sicher, dass dasselbe Verhalten in Zukunft nicht wieder durchrutscht. Und schließlich, und das ist entscheidend, müssen wir sicherstellen, dass das Modell ein gutes Verständnis für den Umfang seiner Fähigkeiten hat, wo es an einen Menschen übergeben sollte oder wo es eine Anfrage kategorisch ablehnen sollte.

Im Beispiel, das wir uns heute ansehen werden, werden wir einen Prompt für einen Kundensupport-Bot für ein Telekommunikationsunternehmen namens Meridian Mobile verwenden. Und dies sind die fünf Testfälle, die wir uns heute ansehen werden. Wir haben einen einfachen Kontrollfall, der sich mit der Frage beschäftigt, wie hoch das Datenlimit im Basistarif ist. Wir betrachten auch Grenzfälle wie die Fähigkeit, Berechnungen durchzuführen, wie z. B. die Berechnung von anteiligen Rechnungen. Wenn ich meinen Tarif mitten im Monat wechsle, wie sieht dann meine Rechnung aus? Wir wollen prüfen, ob er wichtige Fragen, die von unserer Richtlinie abgedeckt sind, korrekt beantwortet. Wir müssen sicherstellen, dass er an einen Menschen eskaliert, wenn es einen Abrechnungsfehler gibt. Und schließlich wollen wir sicherstellen, dass unser Modell keine Informationen zurückhält, auf die es Zugriff hat und die es dem Kunden übergeben sollte.

Was wir in diesem Prozess tun werden, ist, dass wir unseren Prompt nehmen und ihn auf unserer v0-Version der Auswertung ausführen und sehen, welche Fehlerarten wir haben und diese Fehlerarten systematisch einzeln angehen, um zu sehen, ob wir diese Fehlerarten durch Prompting beheben können, und dabei werden wir ein wenig mehr über die Anti-Muster und Fallen lernen, die es zu vermeiden gilt, und dies ist repräsentativ dafür, wie wir diese besten Prompting-Techniken in der Praxis anwenden würden. Wir schreiben selten einen Prompt von Grund auf neu. Wir debuggen oft einen bestehenden Prompt. Und Best Practice, bevor wir beginnen, diese Fehlerarten gezielt anzugehen, ist, unsere allgemeinen Prompting-101-Best Practices anzuwenden, allgemeine Hygiene anzuwenden, um aufzuräumen, bevor wir den Auswertungslauf durchführen.

Schauen wir uns also das Beispiel an, das wir verwenden werden. Was wir hier zuerst sehen, bevor wir uns den Prompt ansehen, ist nur diese Vibe-codierte Web-App, die ich für die heutige Präsentation erstellt habe, damit wir sehen können, wie wir den Prompt gemeinsam iterieren. Auf dieser Seite hier kann ich meine Auswertungen für alle fünf Testfälle einfach ausführen und die Ergebnisse detaillierter untersuchen. Bevor wir uns den Prompt ansehen, führe ich die Auswertungen im Hintergrund aus. Dies ist ein ziemlich guter erster Entwurf eines Prompts. Wenn wir uns das ansehen, haben wir die Rolle des Bots oben definiert. Wenn wir nach unten scrollen, haben wir ihm einige Daten gegeben. Wir haben ihm Informationen gegeben, wie er die Antworten, die er dem Kunden geben sollte, verarbeiten soll. Er gibt einige kritische Anweisungen bezüglich des Tons, den er verwenden sollte, wie er Berechnungen durchführen soll usw. Und dann übergeben wir schließlich unseren Kundenkontokontext und unsere Benutzernachricht.

Schauen wir uns an, wie unser erster Auswertungslauf abgeschnitten hat. Wir sehen, wie erwartet, dass unser Kontrollfall, alle unsere Testfälle bestanden wurden. Das ist, was wir für diesen unzweideutigen Testfall erwarten. Aber in diesen anderen Bereichen schneidet er ziemlich schlecht ab. Bevor wir uns diese spezifischen Fehlerarten hier genauer ansehen, nehmen wir eine allgemeine Bereinigung unseres Prompts vor. Wie erwähnt, gibt es hier schon ein paar Merkwürdigkeiten. Zum Beispiel sagen wir dem Bot, dass er ein Mensch ist, was einfach nicht stimmt, oder? Wir sehen, wenn wir nach unten scrollen, dass hier eindeutig Informationen stehen, die direkt von einer Website kopiert wurden. Der entscheidende Hinweis hier ist der Verweis auf ein Heldenbild. Am Ende gibt es sogar Verweise auf Cookies. Wir müssen also etwas redundante Informationen entfernen. Wenn wir uns die Anweisungen hier ansehen, sind sie alle in einem großen Absatz zusammengefasst. Wir haben hier einige Begründungen. Wir haben Anweisungen zur Rolle, kritische Anweisungen, ohne dass wir wirklich Richtlinien von Leitlinien, von Ton usw. trennen können.

Ich habe einige Änderungen, die wir an diesem Prompt vornehmen wollen, vorweggenommen, und dies ist nur eine Diff-Ansicht einiger dieser Änderungen. Wir haben also zuerst eine Struktur hinzugefügt. Sie sehen, dass wir XML-Tags hinzugefügt haben, um die Rolle zu definieren, allgemeine Leitlinien zu trennen, Richtlinien zu trennen, den Tonfall usw. zu trennen. Wenn wir also die Auswertung für diesen neuen aktualisierten Prompt ausführen, sollten wir hoffentlich eine Verbesserung der Ausgabe sehen. Wir sehen, dass wir durch die Bereinigung des Prompts die Leistung des Modells in diesem Prepaid-Szenario bereits verbessert haben. Es gibt eine interessante Regression in diesem fünften Hotspot-Fall, und ich möchte mich jetzt nicht zu sehr darum kümmern. Es wird ein natürliches Maß an Varianz bei den verschiedenen Auswertungsdurchläufen geben, und wir werden auf diesen Fall speziell zurückkommen, um zu sehen, ob wir den Prompt in diesem Bereich konsistent verbessern können.

Was haben wir also daraus gelernt? Allein die Bereinigung des Prompts mit einer besseren Struktur und einer besseren Rollenbeschreibung hat die Leistung verbessert. Und dies ist eine Best Practice, zu der Sie in jeder Phase des Schreibens und Pflegens Ihres Prompts zurückkehren können, insbesondere wenn Ihre Prompts detaillierter und komplexer werden. Eine allgemeine Faustregel, der ich gerne folge, ist: Wenn Sie einen Prompt lesen und Richtlinien von Richtlinien, von Daten nicht unterscheiden können, kann das Modell es höchstwahrscheinlich auch nicht.

Bevor wir uns einige dieser Fälle genauer ansehen, können wir noch ein wenig allgemeine Bereinigung vornehmen. Insbesondere hier geht es um die Erstellung eines Ausgabevertrags. Dies ist eine wichtige Best Practice, wenn Sie mit der Konsistenz Ihres Ausgabeformats zu kämpfen haben. In diesem Fall haben wir einen Kundensupport-Bot. Wir möchten, dass er in einem gesprächigen Ton antwortet. Es ist also unwahrscheinlich, dass dies in diesem Fall ein großes Problem darstellt, aber es ist etwas, das Sie beachten sollten, wenn Sie mit komplexeren Ausgabeformaten wie verschachtelten JSONs zu tun haben.

Wenn wir also noch einmal zum Prompt zurückkehren und sehen, welche Korrekturen wir hier anwenden können. Zuerst haben wir am Ende einen Abschnitt hinzugefügt, in dem wir ein Ausgabeformat für das Modell definiert haben, das ihm sagt, dass es XML-Tags verwenden soll, um die Antwort auszugeben. Aber der Prompt ist nicht immer der effektivste Weg, um Probleme zu lösen. Wir können auch Dinge in der Harness ändern, um die Konsistenz in höherem Maße zu gewährleisten. Was wir hier dem API-Aufruf hinzugefügt haben, ist eine Stoppsequenz, die das schließende XML-Tag erkennt und dem Modell sagt, dass es die Generierung einer Antwort an diesem Punkt stoppen soll. Wenn ich die Auswertung hier ausführe, erwarte ich nicht unbedingt eine klare Leistungsverbesserung, aber es ist eine allgemeine Best Practice, die wir befolgen sollten, und wie gesagt, etwas, das wir uns besonders merken sollten, wenn wir komplexere Ausgabeschemata haben. Eine Sache, die hier auch zu erwähnen ist, wenn Sie ein komplexeres Ausgabeschema haben, können strukturierte Ausgaben unglaublich hilfreich sein, um diese Konsistenz auf programmatischere Weise zu gewährleisten.

Okay. Nach der Bereinigung sehen wir also, dass wir jetzt zwei Testfälle haben, die konsistent bestanden werden, aber wir haben drei Hauptfehlerarten: die Ratenberechnung, den Abrechnungsfehler und den Hotspot. Lassen Sie uns diese einzeln isolieren, um den Prompt zu iterieren und die Auswirkungen davon zu sehen. Zuerst die Hotspot-Frage. Die Frage ist, wie viel Hotspot-Daten mein unbegrenzter Tarif enthält. Wir erwarten, dass das Modell direkt die Menge der Hotspot-Daten angibt, die der Kunde hat. Und der Grund, warum dies ein etwas komplexer Fall ist, ist, dass der Kundentestfall, mit dem wir es zu tun haben, sich auf einen Legacy-Tarif bezieht. Die aktuelle Richtlinie gilt also tatsächlich nicht für ihn.

Wenn wir uns also ansehen, was im eigentlichen Testfall passiert, enthält die Kundendaten, die wir dem Prompt zuführen, die Menge der Hotspot-Daten, die der Kunde hat. Er hat 5 Gigabyte, richtig? Aber er hat auch einen "grandfathered plan". Was wir also sehen, ist, dass das Modell dem Kunden tatsächlich sagt, dass der allgemeine unbegrenzte Tarif 4 GB enthält, aber da Sie einen Legacy-Tarif haben, sollten Sie sich selbst darum kümmern.

Schauen wir uns also den Prompt an, um zu sehen, warum das Modell diese Frage an die URL des Kundenkontos ablenkt, anstatt die Informationen selbst zu geben. Wenn wir diesen Prompt lesen, heißt es ursprünglich: "Wir haben unsere Tarife kürzlich geändert und das Richtliniendokument zeigt die Daten des aktuellen Tarifs und Kunden mit grandfathered plans haben unterschiedliche Tarife. Geben Sie einem Kunden niemals falsche Tarifdetails. Verweisen Sie ihn stattdessen auf die URL." Es ist also klar, dass diese Anweisung, die letztere: "Geben Sie einem Kunden niemals falsche Informationen", die Anweisung ist, für die der Bot optimiert hat. Und Sie erkennen vielleicht, dass dies einem Patch sehr ähnlich ist, den Sie möglicherweise für ein früheres Modell eingeführt haben, um zu vermeiden, dass das Modell dem Kunden falsche Informationen über diesen Tarif gibt.

Da sich unsere Modelle weiterentwickelt haben, sind sie viel besser im Befolgen von Anweisungen geworden. Es ist also wahrscheinlich, dass Anweisungen wie diese jetzt überflüssig geworden sind und tatsächlich überangepasst werden. Was wir dem Modell stattdessen sagen werden, ist, diese ausgewogene Ansicht zu geben, in der es heißt: Kunden mit grandfathered plans haben unterschiedliche Freibeträge, aber es ist in den Kundeninformationen erfasst, die gegeben werden, und das ist die genaue Quelle der Wahrheit.

Wenn wir die Auswertung hier ausführen, sollten wir hoffentlich alle Testfälle für den Hotspot-Fall behandeln. Ich führe dies jetzt live aus, daher kann es zu einigen Schwankungen kommen, aber wir sehen hier, dass jetzt eindeutig alle unsere Testfälle bestanden werden. Was haben wir also daraus gelernt? Nun, wir machen uns viele Sorgen über Halluzinationen oder die Erfindung von Fakten und Zahlen, aber tatsächlich kann auch das Gegenteil passieren. Das Modell kann Informationen zurückhalten, auf die es tatsächlich Zugriff hat. Wir haben hier gesehen, dass dies wahrscheinlich das Ergebnis eines Patches ist, den wir für ein früheres Modell eingeführt haben. Und eine Best Practice, die wir hier befolgen könnten, ist die Verwendung von Versionskontrolle, wo immer wir defensive Änderungen im Prompt vornehmen, wir den Grund für die Einführung dieser Änderungen verfolgen. Manchmal sind sie notwendig, aber in Zukunft können solche Änderungen unerwünschte Auswirkungen haben, so dass wir sie rückgängig machen können.

Der nächste fehlschlagende Testfall ist also diese Ratenberechnung, bei der ein Kunde fragt: "Was passiert, wenn ich auf den 30-Gigabyte-Tarif umsteige? Wie hoch wird meine nächste Rechnung sein?" Und was wir wollen, ist, dass das Modell eine Berechnung durchführt und genau angibt, wie hoch seine nächste Rechnung sein wird, anstatt eine vage Antwort zu geben, was wir sehen, dass es gerade tut. Wenn wir uns ansehen, was das Modell zurückgibt, verarbeitet es es eindeutig. Es macht ein bisschen Kopfrechnen hier und da, aber es gibt dem Kunden keine konkrete Antwort. Und ich würde mich nicht darauf verlassen, dass es dem Kunden eine genaue Antwort geben kann.

Wenn wir uns also den Prompt ansehen, um zu sehen, wie wir das beheben können, können wir im ursprünglichen Prompt sehen, dass alle Anweisungen, die ihm gegeben wurden, lauten: "Geben Sie einem Kunden niemals eine vage Antwort. Berechnen Sie immer alle anteiligen Beträge korrekt." Dem Modell zu sagen, dass es gute Arbeit leisten soll, ist nicht besonders hilfreich, wenn wir dem Modell nicht die Fähigkeit geben, gute Arbeit zu leisten. Wir wollen vermeiden, dass das Modell Kopfrechnen betreibt.

Was wir also einführen werden, ist, dem Modell ein Werkzeug zu geben. Wir sagen also im Prompt: Wenn Sie Berechnungen durchführen, verwenden Sie bitte das Werkzeug zur Berechnung von Raten, um dies zu tun. Um dieses Werkzeug einzuführen, müssen wir es in die API einführen, um dem Modell zu sagen, dass es Zugriff auf dieses Werkzeug hat. Wir müssen das Werkzeugschema definieren, das dem Modell sagt, was dieses Werkzeug tut und wann es verwendet werden soll. Und schließlich müssen wir das Werkzeug tatsächlich implementieren, das ist die Mathematik dahinter, wie es diese Berechnung durchführen soll.

Wenn wir diese Auswertung also für einen weiteren Durchlauf ausführen, können wir sehen, dass alle Testfälle jetzt bestanden werden. Es hat eindeutig die Mathematik im Hintergrund mit dem Werkzeug durchgeführt und die richtige Antwort zurückgegeben. Die wichtigste Lektion, die wir hier mitnehmen können, ist: Anweisungen fügen keine Fähigkeiten hinzu. Dem Modell zu sagen, dass es entscheidend ist, eine Berechnung richtig durchzuführen, macht es nicht besser im Kopfrechnen. Der richtige Ansatz war also, ihm ein Werkzeug zu geben. Insgesamt ihm die Fähigkeit zu geben, komplexere Probleme zu lösen, und Werkzeuge zu verwenden, um sie zuverlässig auszuführen.

Jetzt haben wir noch einen letzten fehlschlagenden Testfall, den wir angehen müssen, und das ist dieser Abrechnungsfehler. In diesem Szenario gibt es einen Abrechnungskonflikt, und was wir wirklich wollen, ist, dass der Agent dies an einen Menschen eskaliert. Und was wir stattdessen sehen, ist, dass er versucht, dem Kunden zu erklären, was der Grund dafür sein könnte, und er versucht, das Problem selbst zu diagnostizieren.

Um dieses Verhalten zu beheben, schauen wir uns noch einmal an, was ihm im Prompt gesagt wurde. Wir sehen in den anfänglichen Anweisungen, dass es heißt: "Vermeiden Sie die Eskalation oder Überweisung an einen Kundendienstmitarbeiter, es sei denn, dies ist absolut notwendig, da dies etwa 8 US-Dollar kostet und gegen den schnellen Lösungsvertrag unseres Teams zählt." Dies gibt nur eine Seite der Geschichte wieder, oder? Wir sagen ihm, was die Kosten für die Eskalation sind, aber nicht den Nutzen, was bedeutet, dass er wieder überangepasst wird, um dieses Szenario nicht zu eskalieren. Und zweitens haben wir diesen klaren Konflikt zwischen dem, was wir in der Auswertung definiert haben, in Bezug auf das, was wir wollen, dass das Modell diese Eskalation durchführt, und dem, was wir ihm tatsächlich sagen, zu tun.

Und die relevante Korrektur hier ist, ihm beide Seiten der Geschichte zu geben, indem wir sagen, dass es 8 US-Dollar kostet, einen Fall zu eskalieren, aber tatsächlich, wenn Sie das falsch machen, wird es Sie eine Rückerstattung sowie das Vertrauen der Kunden kosten. Auch hier haben wir beobachtet, wie das Modell für ein Ziel optimiert. Und diese Art von Anweisung ist eine übliche Anweisung. Sie ähnelt der, die wir zuvor gesehen haben, bei der wir nicht wollten, dass sie sich auf eine bestimmte Verhaltensweise überangepasst. Aber es ist die Art von Anweisung, die von verschiedenen Modellgenerationen recht unterschiedlich befolgt werden kann. Und insbesondere, da Modelle intelligenter werden, müssen wir uns daran erinnern, beide Seiten der Kompromisse anzugeben, da unsere Modelle selbst besser darin werden, diese Kompromisse zu treffen.

Wenn wir also noch einmal zu unserer Auswertung zurückkehren und unseren letzten Testfall ausführen, sollten wir sehen, dass alle unsere Auswertungen jetzt korrekt bestanden werden.

Insgesamt haben wir uns die Anwendung allgemeiner Hygieneprinzipien angesehen, wie diese die Leistung sofort verbessern können, wenn wir einen Satz von Auswertungen durchführen, und dass wir diese Auswertungen benötigen, um die Auswirkungen von Änderungen an unserem Prompt auf die Ausgabe rigoros sehen zu können. Dann sahen wir diesen Prozess des gezielten Ansprechens von Fehlerarten einzeln, das Hinzufügen von Struktur, das Vermeiden langer Listen usw. waren alles Dinge, die dazu beitrugen, unser Modell zum richtigen Verhalten zu bewegen. Und schließlich sahen wir bei unserem neuen agentischen Bot, den wir bauten, die Auswirkungen der Aufteilung in drei separate Prompt-Systeme. Anstatt einen Prompt zu verwenden, um alles zu behandeln, isolieren wir tatsächlich verschiedene Aufgaben, bei denen es einfach und wiederholbar ist, die Schritte zu trennen, die er jedes Mal ausführen muss.

Vielen Dank, dass Sie heute Nachmittag dabei waren. Ich hoffe, Sie haben einen fantastischen Rest des Tages.