- Ein von Anthropic bereitgestelltes Prompt-Engineering-Tutorial, das interaktiv und Schritt für Schritt zeigt, wie man für Claude optimierte Prompts schreibt
- Nutzer können die Struktur guter Prompts, Fehlerschläge sowie effiziente Verbesserungstechniken direkt üben und verinnerlichen
- Jedes Kapitel enthält Praxisbeispiele und Erklärungen und bietet damit eine Erfahrung nah an realen Einsätzen
- Es besteht aus 9 Kapiteln von Einsteiger- bis Fortgeschrittenenniveau plus Anhang und hilft dabei, eigene Prompting- und Problemlösungsfähigkeiten aufzubauen
- Das Tutorial ist auch in einer Google-Sheets-Version verfügbar und erhöht so Zugänglichkeit und Nutzbarkeit
Anthropics interaktives Tutorial für Prompt Engineering
- Open-Source-Lernmaterial, das Wissen zum Prompt-Design vermittelt, optimiert für das KI-Modell Claude
- Ähnlich zu Lernabläufen für OpenAI-basierte Chatbots, bietet aber durch den Fokus auf die besonderen Stärken und Grenzen des Claude-Modells sowie auf praxisnahe Übungen eine besonders hohe Anwendbarkeit und Praxistauglichkeit im Arbeitsalltag
- Besonders vorteilhaft für Einsteiger:innen, da man das Schreiben von Prompts und das Testen der Ergebnisse direkt parallel durchführen kann
Kursvorstellung und Ziele
- Dieses Tutorial führt Schritt für Schritt durch die Gestaltung und Nutzung optimaler Prompts innerhalb von Claude
- Nach Abschluss des Kurses können Nutzer Folgendes beherrschen
- Verständnis für effektive Prompt-Strukturen
- Erkennen typischer Fehlermuster und priorisierte Verbesserungsmethoden (80/20-Regel)
- Verständnis der Stärken und Schwächen des Claude-Modells
- Fähigkeit zum Aufbau von Prompts für viele allgemeine Arbeitsaufgaben
Kursstruktur und Inhalte
- Besteht aus 9 Kapiteln (Einsteiger bis Fortgeschrittene) sowie einem vertiefenden Anhang
- Jedes Kapitel bietet sowohl theoretische Erklärungen als auch praktische Übungen
- Am Ende jedes Abschnitts gibt es im "Example Playground" einen Bereich, in dem man Prompts direkt eingeben und Veränderungen in den Antworten testen kann
- Für alle Beispiele ist ein Lösungsschlüssel mit Erklärungen enthalten
- Das Standardmodell des Tutorials ist Claude 3 Haiku, das leichteste, schnellste und günstigste Modell. Bei Bedarf werden auch die intelligenteren Modelle Sonnet und Opus erwähnt
- Es kann auch als erweiterte Google-Sheets-Version genutzt werden, was die Zugänglichkeit beim Lernen erhöht
Curriculum
- Einsteiger
- Kapitel 1: Grundlegende Prompt-Struktur
- Kapitel 2: Klare und direkte Anweisungen formulieren
- Kapitel 3: Rollen vergeben
- Mittelstufe
- Kapitel 4: Daten und Anweisungen trennen
- Kapitel 5: Ausgabeformat festlegen und Claude dialogorientiert einsetzen
- Kapitel 6: Vorabdenken (schrittweises Herleiten von Gedanken)
- Kapitel 7: Beispiele effektiv nutzen
- Fortgeschrittene
- Kapitel 8: Halluzinationen vermeiden
- Kapitel 9: Komplexe Prompts erstellen (branchenbezogene Beispiele)
- Beispiele: Chatbots, Rechtsdienstleistungen, Finanzdienstleistungen, Coding und weitere praxisnahe Aufgaben aus unterschiedlichen Arbeitsbereichen
- Anhang
- Methoden jenseits von Standard-Prompts
- Vertiefende Techniken wie Prompt Chaining, Tool-Nutzung sowie Suche/Integration von Suchergebnissen
Hinweise zur Nutzung
- Es wird empfohlen, das Tutorial Kapitel für Kapitel in der vorgesehenen Reihenfolge durchzuarbeiten
- Durch praxisorientierte Übungen und schrittweise Erklärungen können auch Einsteiger:innen ganz natürlich Fähigkeiten im Prompt-Design erwerben, die sich direkt in der Praxis einsetzen lassen
- Alle Produkt- und Modellnamen bleiben im Original erhalten und sind dadurch auch in englischsprachigen Arbeitsumgebungen sofort nutzbar
Zusätzliche Merkmale und Open-Source-Informationen
- Auf GitHub verzeichnet es derzeit mehr als 19.400 Stars und 1.900 Forks
- Die hauptsächliche Entwicklungssprache ist Jupyter Notebook, außerdem ist teilweise Python-Code enthalten
- Es gibt kein separates Distributionspaket; alle Materialien sind als Open Source frei einsehbar
1 Kommentare
Hacker-News-Kommentare
Dass das Wort „engineering“ in so einem Kontext verwendet wird, stört mich sehr; ich finde nicht, dass man das wirklich als Engineering bezeichnen kann. Engineering bedeutet, auf Basis von über viele Jahre angesammeltem Wissen, physikalischen Gesetzen und Regeln vorhersehbar zu entwerfen und zu bauen. Das hier ist im Grunde nur planloses Herumprobieren, bis ein Ergebnis herauskommt.
Ich denke, jedes Wort hat mehrere Bedeutungen. Das „engineering“ in „prompt engineering“ hat eine ähnliche, aber andere Nuance wie in „social engineering“. Zum Beispiel ist die zweite Definition von Googles Engineering-Definition „das Erreichen eines Ziels durch geschicktes Vorgehen“. Auch in der dritten Definition bei Merriam-Webster sowie im Collins Dictionary und bei YourDictionary gibt es eindeutig nichttechnische Bedeutungen wie „geschickte Manipulation“ oder „Planung“. Das ist eine etablierte Nebenbedeutung des Wortes.
Ich esse Müsli und prüfe dabei die Spezifikationen auf der Müslischachtel. Das mache ich jeden Morgen, und ich setze auch meine Engineering-Skills fürs Busfahren ein, denn ich verdiene meinen Lebensunterhalt mit Prompt Engineering. Es ist immerhin beruhigend zu wissen, dass nicht nur ich genervt davon bin, dass heutzutage so viele Wörter ihre ursprüngliche Bedeutung verlieren.
Ich bevorzuge weiterhin den kanadischen Ansatz, nach dem man den Titel „Ingenieur“ nur verwenden darf, wenn man von der Ingenieursaufsicht der jeweiligen Provinz lizenziert ist. In den USA geht es meiner Meinung nach zu weit, wenn man alle Softwareentwickler, Mechaniker, HVAC-Installateure und sogar Klempner als Engineers bezeichnet.
Ich denke, dieselbe Kontroverse ließe sich eigentlich genauso auf die Arbeit vieler „engineering teams“ anwenden. Dahinter steckt implizit die Annahme, dass etwas automatisch Engineering ist, wenn Engineers es tun, und darüber hinaus auch eine tiefere Annahme darüber, ob Software selbst überhaupt den Wert hat, als Software Engineering bezeichnet zu werden.
Ich denke, das Wort „Engineering“ ist ein rhetorisches Mittel, um Leuten den Eindruck zu vermitteln, dass es nicht bloß ums Schreiben von Sätzen geht. Ehrlich gesagt könnte „prompt writing“ leicht als etwas Nebensächliches abgetan werden, und für Leute, die den Begriff „soft skill“ ohnehin nicht mögen, wirkt das wohl noch unangenehmer.
Fühlt sich an wie die heutige Folge von „Alchemie für Anfänger“. Das erinnert mich an den Fall, in dem ein Algorithmus auf einem Benchmark-Set 30 % schneller wurde, wenn man als Random Seed die 7 setzte. Nicht 8 und nicht 6, sondern 7.
Beim Lesen dieses Artikels war für mich die wichtige Erkenntnis, über die Reihenfolge der Ausgabe nachzudenken. Zum Beispiel kann man verlangen, dass zuerst Belege oder Indikatoren extrahiert werden, bevor geantwortet wird. Mir war klar, dass LLMs probabilistische Autovervollständiger sind, aber ich hatte Priming auf diese Weise noch nicht bedacht.
Das gilt möglicherweise nicht für Reasoning-Modelle. Reasoning-Modelle durchlaufen vor der Antwort ohnehin einen Denkprozess in der gewünschten Form, daher hat die Ausgabereihenfolge weniger Einfluss auf die Genauigkeit. Vielleicht ist das einer der Gründe, warum OpenAI Reasoning erzwingen will.
Ich bitte normalerweise zuerst um kurze Zitate aus online gefundenen Quellen, sofern sie relevant sind. Das hilft dabei, die Zuverlässigkeit der Informationen etwas abzusichern. In letzter Zeit war das beim Aufbau von Cloudflare Zero Trust in unserer Organisation sehr notwendig.
Wenn man umgekehrt zuerst eine Antwort verlangt und dann nach Belegen fragt, schaltet das Modell in einen „Unsinnsmodus“, in dem es irgendeine Antwort ausgibt und sie anschließend plausibel rationalisiert. Wenn man es stattdessen erst objektiv Vor- und Nachteile auflisten lässt und danach zu einem Schluss kommen lässt, antwortet es viel vorsichtiger.
Meiner Meinung nach sollte „(2024)“ in den Titel dieses Beitrags aufgenommen werden.
Für schwierige Probleme ist mein bester Prompt-Engineering-Tipp das Prinzip „öffnen und verengen“. Konkret heißt das: Zuerst stellt man Problem und Kontext klar dar und lässt die AI alle möglichen Optionen und Herangehensweisen analysieren und sammeln, um den Informationsraum maximal zu öffnen. Danach lässt man die Vor- und Nachteile jeder Methode auflisten und die geeignetste Lösung auswählen. Bei einfachen Problemen kann man das alles weglassen und direkt fragen, aber wenn man bei schwierigen Problemen sofort nach einer Antwort fragt, erfindet das Modell einfach etwas Plausibles. Deshalb muss man immer mit realistischen Grundlagen beginnen. Man braucht also den Ablauf konkreter Kontext – Optionsanalyse – Pros & Cons – endgültige Auswahl.
Der Titel sollte um 2024 ergänzt werden.
Ich habe das Gefühl, wir lernen gerade, AI etwas beizubringen, was wir bisher selbst gemacht haben, und dann wiederum zu lernen, wie man der AI effektiv sagt, dass sie diese Arbeit tun soll. Falls diese Technologie nicht von der gesamten US-Wirtschaft getragen wird, könnte sie wie ein Heißluftballon erst aufsteigen und dann plötzlich wieder absacken.
Ähnlich wie andere Kommentare finde ich, dass sich das nicht wie klassisches Engineering anfühlt. Ich finde aber, dass Anthropic im Bereich Model Interpretability ziemlich spannende Forschung gemacht hat. Wenn dieses Tool als public API verfügbar würde, könnte man möglicherweise eine Feedback-Schleife schaffen, in der man Unterschiede in den internen Zuständen des Modells je nach Prompt vergleicht und systematischeres Tuning betreibt.
Dieses Tutorial wurde für drei Modelle geschrieben (Sonnet, Haiku, Opus 3). Einige Lehren daraus gelten auch heute noch, aber manches ist für intelligentere RL-Modelle (wie Sonnet 4.5) nicht mehr besonders relevant. Zur Einordnung: Claude 3 Haiku ist das kleinste, schnellste und günstigste Modell, Sonnet und Opus sind intelligenter, und Opus ist das beste.