KI-Kontext-Engineering besteht darin, sämtliche Informationen, Grenzen und Anweisungen rund um einen Agenten so zu gestalten, dass er weiß, was er sehen kann, was er tun soll und wie er sich verhält, wenn er auf einen neuen Fall oder unvollständige Daten trifft. Laut der Erklärung von Doug Whitley, dem Engineering Director bei Stack Overflow, und Ash Zade, dem Product Director, geht es nicht darum, den Agenten mit allen verfügbaren Daten zu überfluten, sondern ihm den spezifischen Kontext bereitzustellen, den er benötigt, um eine Aufgabe mit vorhersehbarem Ergebnis zu erledigen.
Dies wurde in einem von Stack Overflow Blog im Rahmen der Reihe „No Dumb Questions“ veröffentlichten Gespräch erläutert. Dabei wurden die Unterschiede zwischen Kontext-Engineering, Kontextinfrastruktur und Kontext-Engineering sowie die Beziehung dieser Konzepte zu den Technologien RAG und MCP und die Gründe dafür erörtert, warum Unternehmen fertige Lösungen kaufen, statt alles intern zu entwickeln.
Von der Infrastruktur zum Engineering
Whitley unterscheidet zwischen Kontextinfrastruktur, bei der es um die Speicherung, Darstellung und Bereitstellung des Kontexts für den Agenten geht, und Kontext-Engineering, das sich auf die Gestaltung des Systems und die Gründe konzentriert, aus denen seine Komponenten auf eine bestimmte Weise organisiert werden. Kontext-Engineering im praktischen Sinn betrifft dagegen den tatsächlichen Aufbau des Systems, etwa die Auswahl der verwendeten Algorithmen, Programmiersprachen und Werkzeuge.
RAG ordnet er einem Bereich zu, der alle drei Ebenen miteinander verbindet. Indizes, Kontexts Speicher und Suchmethoden stellen den infrastrukturellen Aspekt dar, während der Aufbau des Systems in einer Sprache wie .NET, Python oder Rust den Engineering-Aspekt repräsentiert. Die Architektur wiederum bestimmt die allgemeine Form des Systems und die Regeln, die seine Funktionsweise steuern. MCP betrachtet Whitley als Protokoll mit bestimmten Anforderungen; die Entscheidung, es in das System zu integrieren, die verwendeten Sprachen und die unterstützten Funktionen sind jedoch Designentscheidungen.
Den Entscheidungsraum des Agenten verkleinern
Zade erklärt das Konzept anhand des Beispiels einer Suche nach Autoreifen. Wird ein Agent in eine Bibliothek geschickt, um nach „Reifen“ zu suchen, kann er Informationen über Flugzeuge, Fahrräder und Schubkarren finden, da sie alle dem gesuchten Begriff entsprechen. Ein gut konzipiertes System legt jedoch von Anfang an fest, dass es um Autoreifen oder speziell um Reifen für Sportwagen geht, und beschränkt die verfügbaren Informationen auf diesen Bereich.
Zade ist der Ansicht, dass es nicht ausreicht, diese Anweisungen allein in einer Textaufforderung zu hinterlegen, um die Einhaltung durch den Agenten zu gewährleisten. Daher erfordert Kontext-Engineering die Kontrolle über die Daten, auf die der Agent zugreifen kann, sowie die Festlegung dessen, was er tun soll, wenn er auf unvollständige oder falsche Informationen stößt. Auf diese Weise werden einige Variablen aus den Entscheidungen des Agenten entfernt, statt ihn selbst entscheiden zu lassen, ob eine Information zuverlässig ist oder ob der Suchbereich erweitert werden sollte.
Zum System gehört auch der Speicher des Agenten, damit dieser festhält, was er erledigt, gelernt, besprochen und bisher aufgebaut hat. Dieser Speicher gewinnt an Bedeutung, wenn mehrere Agenten arbeiten oder wenn eine Aufgabe unterbrochen und später fortgesetzt wird.
Vertrauen, Berechtigungen und menschliches Eingreifen
Stack Internal stellt den Gesprächspartnern zufolge ein Beispiel für die Verknüpfung von Kontext mit einem Vertrauenssystem und einem Prüfablauf durch Fachleute dar. Wissen wird mit einem hohen, mittleren oder niedrigen Grad eingestuft. Bei einem mittleren oder niedrigen Grad kann der Nutzer an einen Fachexperten verwiesen werden, der die Information überprüft oder fehlende Angaben ergänzt, statt dass der Agent eine Entscheidung auf Grundlage unsicheren Wissens trifft.
Der Datenschutz geht über die Frage hinaus, ob der Agent eine bestimmte Information sehen kann. Eine Information kann für den Nutzer zugänglich, aber für die vom Agenten ausgeführte Aufgabe ungeeignet sein. Deshalb beschreiben die beiden Gesprächspartner zwei Ebenen der Kontrolle:
- Quellberechtigungen: Der Agent übernimmt die Berechtigungen des Nutzers in den Systemen, in denen er sucht, etwa Slack, MS Teams, Google Drive oder SharePoint.
- Bereiche: Der Nutzer kann den Umfang der für den Agenten verfügbaren Daten einschränken, selbst wenn er selbst auf einen größeren Datenbestand zugreifen darf.
- Neue Daten: Es kann eingeschränkt werden, was der Agent erstellt oder an das System zurückgibt, sodass er es zunächst an den Nutzer sendet und nicht automatisch zur allgemeinen Wissensdatenbank hinzufügt oder mit dem Team teilt.
Diese Unterscheidung zeigt, dass Kontextverwaltung nicht nur den Abruf betrifft, sondern auch die Kontrolle über den Speicher und das vom Agenten erzeugte Wissen umfasst.
Warum könnte ein Unternehmen die Lösung kaufen, statt sie selbst zu entwickeln?
Whitley zufolge ist der Aufbau von Kontext-Engineering möglich, aber die Herausforderung beschränkt sich nicht auf das Schreiben von Code. Wenn ein Unternehmen Daten aus Slack, MS Teams, Google Drive, SharePoint, Confluence, GitHub und Jira zusammenführt, muss es festlegen, wie diese indiziert, gefiltert und neu geordnet werden und wie mit widersprüchlichen, fehlenden oder falschen Informationen umzugehen ist.
Zade ist der Ansicht, dass ein großer Teil der Arbeit darin besteht, Vertrauen selbst zu definieren. Ein erfahrener Nutzer kann den Ausgaben der künstlichen Intelligenz vertrauen, wenn sie mit seinen Erwartungen und bisherigen Erfahrungen übereinstimmen. Dieser Ansatz steht jedoch Personen, denen die Erfahrung in dem Bereich fehlt, in dem sie die künstliche Intelligenz einsetzen möchten, nicht in gleichem Maß zur Verfügung. Daher erfordert das System Diskussionen darüber, was eine Information vertrauenswürdig macht, und nicht nur technische Lösungen zu ihrer Sammlung.
Whitley fügt hinzu, dass der Kauf einer fertigen Lösung einem Unternehmen die über Jahre gesammelte Erfahrung aus Problemen bieten kann, mit denen andere Kunden konfrontiert waren, einschließlich Sonderfällen und alltäglicher Probleme, die sein Team nach eigener Aussage in ungefähr 20 Kategorien einteilt. Dennoch schließen die beiden Gesprächspartner eine interne Entwicklung nicht aus; sie kann geeignet sein, wenn der Anwendungsfall neu ist oder das Unternehmen eigene spezifische Designentscheidungen benötigt.
Für Whitley und Zade wird die Qualität des Kontext-Engineerings an der Flexibilität des Systems und seiner Fähigkeit gemessen, konsistente und vorhersehbare Ausgaben zu liefern, nicht allein daran, dass sein Anwendungsbereich auf eine einzige Aufgabe beschränkt ist. Außerdem kann eine frühzeitige Filterung der Informationen die Zahl der Tokens verringern, die der Agent verarbeitet: Die Suche in Autobüchern ist kostengünstiger als die Suche in einer vollständigen Bibliothek, und die Suche in Reifenseiten ist günstiger, als alle Bücher zu prüfen. Das endgültige Ziel bleibt, den Agenten in die Lage zu versetzen, die erwartete Aufgabe auszuführen und anzuhalten oder menschliche Hilfe anzufordern, wenn er Grenzen erreicht, die er nicht überschreiten sollte.