- Die Diskussion verlagert sich von „Prompt Engineering“ hin zu „Context Engineering“ als nächstem Entwicklungsschritt
- Kontext bedeutet nicht nur einen einfachen Prompt-Satz, sondern alle Informationen, die ein LLM vor der Generierung einer Antwort sehen kann (Anweisungen, Gesprächsverlauf, Langzeitspeicher, externe Informationen, verfügbare Tools usw.)
- Erfolg oder Misserfolg von Agenten hängt inzwischen mehr von der Qualität des Kontexts als von der Modellleistung ab
- Fortgeschrittene Agenten integrieren verschiedene Zusammenhänge wie den Kalender des Nutzers, frühere E-Mails und Kontakte, um Antworten zu erzeugen, die echter Problemlösung deutlich näherkommen
- Context Engineering ist der Entwurf situationsangepasster, dynamischer Systeme und der Prozess, dem LLM die richtigen Informationen und Tools zum genau richtigen Zeitpunkt bereitzustellen
Was ist Context Engineering?
- In der KI-Branche verbreitet sich der Begriff „Context Engineering“ derzeit sehr schnell
- Während sich klassisches „Prompt Engineering“ auf das Design einer einzelnen Frage oder Anweisung konzentrierte, ist Context Engineering ein wesentlich breiterer und leistungsfähigerer Ansatz
- Tobi Lutke definiert es als „die Kunst, allen Kontext bereitzustellen, damit ein LLM eine Aufgabe zuverlässig lösen kann“
Die wichtigsten Elemente des Kontexts
- Ob ein Agentensystem erfolgreich funktioniert, hängt stark davon ab, welche Informationen im Arbeitsgedächtnis (working memory) enthalten sind
- Die meisten Fehlschläge von Agenten liegen nicht am Modell, sondern an fehlendem geeignetem Kontext
Bestandteile des Kontexts
- System-Prompt/Anweisungen: Grundlegende Vorgaben, Beispiele und Regeln, die das Verhalten des Modells definieren
- User-Prompt: Die unmittelbare Anfrage oder Frage des Nutzers
- Status/Gesprächshistorie: Der bisherige Gesprächsverlauf und Kontextinformationen
- Langzeitgedächtnis: Frühere mehrstufige Gespräche, Nutzerpräferenzen, Zusammenfassungen vergangener Projekte und Informationen, die das Modell langfristig behalten soll
- RAG (Retrieval-Augmented Generation): Aktuelle und hochrelevante Informationen aus externen Dokumenten, Datenbanken, APIs usw.
- Verfügbare Tools: Definitionen von Funktionen oder eingebauten Tools, die das Modell aufrufen kann (z. B.
check_inventory, send_email)
- Strukturierte Ausgabe: Definition des Antwortformats, dem das Modell folgen soll (z. B. JSON)
Warum Kontext wichtig ist
- Der eigentliche entscheidende Faktor beim Bau effektiver KI-Agenten ist weder komplexer Code noch die Modellqualität, sondern wie passend der bereitgestellte Kontext ist
- Ein einfacher Agent für „Demo-Zwecke“ nimmt nur die Anfrage des Nutzers entgegen und liefert eine Basisantwort, während ein „magischer“ Agent reichhaltigen Kontext berücksichtigt und dadurch wesentlich nützlichere und menschlichere Antworten erzeugt
- Vergleich
- Agent mit geringer Qualität (Demo): Betrachtet nur die einfache Anfrage und erzeugt lediglich schematische Antworten. Beispiel: Auf die Mail „Haben Sie morgen Zeit?“ kommt die mechanische Antwort „Morgen passt es. Welche Uhrzeit wäre gut?“
- Hochwertiger („magischer“) Agent: Kann den eigenen Kalender, frühere E-Mail-Historien, Informationen zur Identität des Gegenübers und Optionen zum Aufruf benötigter Tools nutzen, um natürliche und situationsangepasste Antworten zu erzeugen. Beispiel: „Morgen ist mein Kalender voll, aber Donnerstagvormittag ist frei, daher habe ich Ihnen eine Termineinladung geschickt. Geben Sie mir gern Bescheid, ob das passt.“
- Entscheidend sind also nicht Algorithmen oder das Modell selbst, sondern die Bereitstellung des richtigen Kontexts für die jeweilige Aufgabe
- Die meisten Fehlschläge von KI-Agenten sind nicht auf das Modell, sondern auf Fehler im Kontextdesign zurückzuführen
Die Evolution von Prompt Engineering zu Context Engineering
- Während sich Prompt Engineering auf die Optimierung einzeiliger Textanweisungen konzentriert, umfasst Context Engineering einen viel breiteren Bereich an Informationen, Tools und strukturellem Design
- Context Engineering ist „die fachliche Kompetenz, Systeme so zu entwerfen und aufzubauen, dass die benötigten Informationen und Tools in der richtigen Form und zum richtigen Zeitpunkt bereitgestellt werden, damit ein LLM eine Aufgabe erfüllen kann“
Merkmale von Context Engineering
- Ganzheitliches Systemdesign: Kontext ist nicht bloß ein einfaches Prompt-Template, sondern das Ergebnis des gesamten Systems, das vor dem LLM-Aufruf arbeitet
- Dynamische Generierung: Informationen wie Kalender, E-Mails oder Websuche werden je nach Aufgabe in Echtzeit ausgewählt und aufbereitet
- Informationen und Tools zur richtigen Zeit am richtigen Ort: Das Prinzip „Garbage In, Garbage Out“ gilt auch hier; wichtig ist, dem Modell weder unnötige noch fehlende Informationen zu geben
- Klarheit des Formats ist wichtig: Informationen sollten nicht unübersichtlich aufgelistet, sondern zusammengefasst und strukturiert werden; auch die Nutzung von Tools muss klar vermittelt werden
Fazit
- Das Wesen der Entwicklung leistungsfähiger und verlässlicher KI-Agenten liegt nicht in einem „magischen Prompt“ oder dem neuesten Modell, sondern im Context Engineering (dem Entwurf und der Bereitstellung von Kontext)
- Das geht über ein rein technisches Problem hinaus und erfordert umfassende Fähigkeiten im Systemdesign, darunter die Definition von Informationen, Tools und strukturierten Ausgaben passend zu Geschäftsanforderungen und Zielen
- Entscheidend ist, zur richtigen Zeit die passenden Informationen im richtigen Format bereitzustellen, damit ein LLM die Aufgabe erfüllen kann
Referenzen
2 Kommentare
Es fühlt sich stark so an, als würde nur der Name geändert.
Hacker-News-Kommentare
Ich habe vor Kurzem selbst über dieses Thema gebloggt, siehe mein Beitrag - Context Engineering
Ich finde, dass Drew Breunigs Texte dieses Thema wirklich hervorragend behandeln
Das Timing fiel zwar zufällig in eine Phase, in der das Meme „context engineering“ kursierte, aber die Arbeit selbst hatte damit eigentlich nichts zu tun
Der Beitrag How Long Contexts Fail - Warum lange Kontexte scheitern erklärt auf verschiedene Weise, wie lange Kontexte Probleme verursachen und wie die sogenannte „context rot“ entsteht
Der Beitrag How to Fix Your Context - Wie man seinen Kontext repariert versieht verschiedene Techniken wie Tool Loadout, Context Quarantine, Context Pruning, Context Summarization und Context Offloading mit Namen und zeigt Wege zur Lösung des Problems auf
Ich denke, Drew Breunigs Posts sind unbedingt lesenswert
Das ist nicht nur wichtig, wenn man eigene Agenten baut, sondern auch jetzt schon beim Einsatz von Agent Coding
Diese Einschränkungen und Verhaltensmuster werden uns wohl noch eine Weile begleiten
Ich bin gespannt, wer als Erster einen Logic Core entwickelt, der Context Engineers automatisiert
Ich halte auch das für einen „Ein-Monats-Skill“
Am Ende wird es wie so viele andere Trends bald wieder verschwinden
Diese Themen gelten in der LLM-Forschung als Produkt der aktuellen LLMs
Es wird bereits daran geforscht, wie man Millionen von Tools gleichzeitig nutzt und stabile Long-Context-Systeme einsetzt
Künftig dürfte in den meisten Fällen ein einzelner Agent ausreichen, außer in Spezialfällen, in denen Verbindungen zu anderen Anbietern nötig sind
Wer zukünftige Agentensysteme auf Basis heutiger LLMs entwirft, könnte so enden wie LangChain
So wie LangChain für GPT-3 gebaut wurde und mit GPT-3.5 praktisch sofort veraltet war
Für jemanden, der LLMs benutzt hat oder weiß, wie sie funktionieren, ist das ziemlich offensichtlich
Dass Prompt Engineering als „Skill“ kein dauerhafter Kernbereich sein würde, war ebenfalls absehbar
Im Grunde gibt man dem LLM Eingaben (Kontext) und Handlungen (Output), und dafür ist viel Pipeline-Arbeit nötig
Ich stimme der Schlussfolgerung zu, dass sich der Bau „leistungsfähiger und zuverlässiger AI-Agenten von der Suche nach magischen Prompts oder Modell-Updates entfernt“
Es stimmt, dass man sich stärker auf „Context Engineering konzentrieren sollte, also darauf, die richtigen Informationen und Werkzeuge im passenden Format zum passenden Zeitpunkt bereitzustellen“
Aber wenn dieses „passende Format“ und der „passende Zeitpunkt“ im Kern nicht definiert sind, jagt man dann nicht immer noch einer „magischen Lösung“ hinterher?
Wenn „die richtigen Informationen“ einfach „die Informationen sind, die das LLM zu einer ausreichend genauen Antwort bringen“, dann unterscheidet sich das im Kern nicht von Prompt Engineering
Bei solchen nichtdeterministischen Maschinen sehe ich letztlich kaum verlässliche Heuristiken außer „Prompt ausprobieren und Ergebnis ansehen“
Am Ende bleibt es endloses magisches Denken
Selbst wenn man es jetzt von „Prompt Engineering“ in „Context Engineering“ umbenennt, bleibt es doch nur Herumprobieren, um in einem unsicheren Raum etwas zu finden, das wirkt
Im Kern ist es Overfitting
Genau das ist Prompt Engineering letztlich
Das Problem ist, dass „passendes Format, passender Zeitpunkt“ nicht grundlegend definiert sind
Die meisten Ratschläge dazu, „wie man AI gut nutzt“, gehen letztlich von genau diesem Problem aus
Am Ende fühlt es sich an, als würde man auf Trommeln schlagen und ein schamanisches Ritual aufführen
In neueren theoretischen Frameworks wird dieser Prozess in zwei Phasen unterteilt: Exploratory und Discovery
Die Exploratory-Phase kann man sich als eine Art Vorrichtung zum Versprühen luftgetragener Partikel vorstellen
Dabei werden leicht identifizierbare Markerstoffe schnell eingebracht, meist mit einer Metapher aus dem Fäkalbereich
Die Discovery-Phase wird dann als Analyse des Ausbreitungsmusters konzeptualisiert
Zusammengefasst lassen sich diese beiden Phasen als „einfach mal probieren“ und danach „das Ergebnis prüfen“ beschreiben
Es fühlt sich so an, als würden in der AI-Branche die Torpfosten ständig verschoben, seit allen klar geworden ist, dass „Prompt Engineering“ kein großartiger Skill ist
Der neue Skill ist am Ende einfach „Programmieren“
Also derselbe Skill wie früher
Um so etwas zu verstehen, sollte man Programme selbst schreiben
Schreib Programme, die LLMs trainieren, Inferenz ausführen und ihr Verhalten analysieren, und du wirst immer mehr verstehen
Ich hatte anfangs Theorien und Erwartungen an die Ergebnisse, aber nachdem ich LLMs tatsächlich auf verschiedene Arten trainiert hatte, kam ich zu völlig anderen Resultaten und Überzeugungen
Der eigentliche Unterschied entsteht dadurch, dass man die Werkzeuge selbst implementiert
Ich selbst habe auch nur Erfahrung mit maschinellem Lernen auf mittlerem Niveau, aber ich denke, dass es entscheidend für gute Ergebnisse in komplexen Systemen ist, selbst schon einmal einen Compiler mittlerer Komplexität gebaut zu haben
Wie, glaubst du, hat Karpathy all das gelernt?
Die Antwort steht in Karpathys Blog
Das ist wie der Rat, man solle einen Compiler selbst schreiben, um Compiler zu verstehen
Technisch stimmt das, aber die meisten wollen gar nicht so tief einsteigen
Ich habe das Gefühl, dass diese Diskussion immer mehr wie Foren zu Spielen wie WoW wird, in denen Gamer Strategien austesten und in einer seltsamen Gruppensprache miteinander streiten
Sogenannte Strategien werden fast nur durch Versuch und Irrtum gefunden, und darüber spricht man in einer Sprache, die nur innerhalb der jeweiligen Gruppe funktioniert
Auch das Programmieren passt sich immer stärker an ein Zeitalter der Gamification an
Power-User verkaufen Pseudo-Strategien an Anfänger oder an Manager mit übertrieben starkem Gamer-Mindset
Eigentlich hat sich Ähnliches schon bei früheren Enterprise-Software-Hypes wiederholt
Diesmal ist es nur so, dass dieser „Power-User-getriebene Hype“ tief in den Einfluss-, Kontroll- und Workflow-Bereich der Entwickler, also der Builder, eingedrungen ist
Was Entwickler heute fühlen, dürfte sich nicht groß von dem unterscheiden, was früher Leute in QA, SRE oder CS erlebt haben, wenn ihnen mit „Das ist jetzt der Trend!“ Tooling oder Praktiken aufgezwungen wurden
Fazit:
„Beim Bau leistungsfähiger und zuverlässiger AI-Agenten geht es nicht um magische Prompts oder Modell-Updates, sondern darum, mit Context Engineering die richtigen Informationen und Tools im richtigen Format zum richtigen Zeitpunkt für den Geschäftszweck bereitzustellen“
Das ist im Grunde ein Prinzip, das genauso auch für Menschen gilt
Wenn man Menschen zur richtigen Zeit die richtigen Informationen gibt, lösen auch sie Probleme besser
Ich mag diesen Trend zu oberflächlichen Vergleichen zwischen maschinellem Lernen und Menschen nicht
Er ist wenig aufschlussreich und meistens nicht einmal besonders zutreffend
Letztlich geht es darum, in einer Umgebung effektiv den Zielknopf zu finden und zu drücken
Das unterscheidet sich gar nicht so sehr von klassischem Software Engineering
Nur dass das Ergebnis etwas nichtdeterministischer ist
Ich frage UX- und Produktleute ständig nach Mockups, Anforderungen, Akzeptanzkriterien, Beispiel-Inputs und -Outputs und danach, warum diese Funktion wichtig ist
Solange wir nicht das Gehirn scannen und daraus extrahieren können, was jemand will, muss man realistisch gesehen präzise erklären, was man möchte
Das ist nichts, was man einfach dem „Gefühl“ überlassen sollte
Nicht mehr Kontext ist entscheidend, sondern besserer Kontext
(ein klassisches Beispiel: das X-Y problem)
Selbst wenn man modernen LLMs einen wirklich hervorragenden Kontext gibt, scheitern sie immer noch
Unser Unternehmen untersucht diesen Punkt inzwischen seit mehr als zwei Jahren intensiv
Es ist erstaunlich, wie stark der Glaube daran ist, dass „Kontext die Antwort“ sei
Ab einem gewissen Punkt denke ich, dass es schneller ist, die Arbeit einfach direkt ohne AI zu erledigen
Dann nimmt man wenigstens noch eine nützliche Lektion mit, statt Stunden in die Erstellung von LLM-Kontexten zu stecken
Mich würden Beispiele interessieren, in denen ein LLM trotz ausreichendem Kontext gescheitert ist
Es wäre gut, wenn du konkrete Fälle teilen könntest
Die Suche nach dem magischen Prompt war nie wirklich das, was „Prompt Engineering“ ausgemacht hat
Im Kern war es schon immer „Context Engineering“
Viele selbsternannte AI-Experten haben das als Prompt Engineering verkauft, obwohl sie das eigentliche Wesen der Sache gar nicht verstanden haben
RAG (Retrieval-Augmented Generation) ist kein Konzept, das erst dieses Jahr plötzlich entstanden ist
Tools, die komplexes Know-how rund um Embeddings, Vektor-DBs, Graph-DBs und Ähnliches kapseln, werden ebenfalls immer verbreiteter
Auch große Plattformen verbessern ihre entsprechenden Werkzeuge und stellen immer umfangreichere Ökosysteme bereit
Es fühlt sich an, als würde man aus denselben Problemen ständig neue Konzepte machen und ihnen nur neue Namen geben
Am Ende ist es immer wieder dasselbe schamanische Ritual: vor dem Lagerfeuer trommeln und Beschwörungen murmeln
Es fühlte sich an, als würde ich einen Dämon beschwören, in der Hoffnung, mit den richtigen Worten den richtigen Zauber zu sprechen, damit er meinen Befehlen folgt
In mir ringt der Ingenieur, der Zuverlässigkeit, Reproduzierbarkeit und starke Testabdeckung will, mit der heutigen unkontrollierbaren Komplexität
Ich habe großen Respekt vor Leuten, die mit solchen Systemen Demos in großem Maßstab machen
Das erinnert mich an frühere Demos aus der Forschung zu Sicherheitslücken
Egal wie gut man vorbereitet war, das Ergebnis konnte vor Ort jederzeit kippen, und ich erinnere mich noch daran, wie ich bei Vorträgen ins Schwitzen kam
Das deckt sich sehr mit meiner eigenen Erfahrung
Wenn ich Kontext in ein LLM einspeise, frage ich mich oft: „Könnte ein Mensch das allein mit diesen Informationen lösen?“
Als ich früher ein text2SQL-Produkt gebaut habe, kam es bei Modellfehlern oft vor, dass auch echte Datenanalysten sagten: „Ah, diese Tabelle ist veraltet. Heute verwendet man diese hier.“
Letztlich macht das deutlich, dass LLMs Fehler machen, wenn ihnen der Kontext fehlt, den auch ein „menschlicher Analyst“ bräuchte
Was in dieser Diskussion fehlt, sind „Evaluations“
Ich bin immer noch erstaunt, wie viele AI-Projekte ohne Evaluations auskommen oder sie nur schlampig behandeln
Evaluations sind noch wichtiger als Tests im traditionellen Engineering
Das Eval-Set muss nicht riesig sein; wenn es den Problembereich gut abdeckt, reicht das
Ohne das ist alles nur „Raten“
Und ich frage mich selbst oft: „Kann ein Mensch das allein mit diesen Informationen lösen?“
Ich habe selbst schon erwartet, dass ein LLM Probleme löst, die ein Mensch gar nicht lösen könnte
Ein klassisches Gesetz des Computerprogrammierens
„Wenn man versucht, Programmierer in Englisch coden zu lassen, merkt man in Wirklichkeit, dass Programmierer nicht einmal in Englisch ordentlich schreiben können“
Das ist halb scherzhaft gemeint, aber da steckt Wahrheit drin
Die meisten natürlichen Sprachen sind nicht besonders präzise
Wenn du auf Englisch wirklich sehr exakt ausdrücken könntest, was du willst, hättest du es auch gleich in einer Sprache schreiben können, die eine Maschine interpretiert
Wenn man Ja/Nein-Fragen stellt, bekommt man mit 50% Wahrscheinlichkeit eine falsche Antwort
So ist diese Eigenschaft nun einmal
Ich lasse das Modell oft zuerst solche Fragen stellen, bevor es tatsächlich mit der Arbeit beginnt
Wenn es zum Beispiel Unsicherheiten gibt, weise ich es an, Rückfragen zu stellen und nach Beispielen für bestehende Code-Patterns zu fragen
Ich versuche es dahin zu lenken, bereits verwendete Templates als Vorlagen zu nehmen
Leute, die nur so tun, als wären sie Data Scientists, wollen keine Evaluations
Deshalb gibt es außerhalb tatsächlich monetarisierter Produkte fast keine
Denn mit „Der Kaiser ist nackt“ verdient man kein Geld
Wenn es für echte praktische Arbeit gebraucht wird, gehören Evaluations zwingend dazu