Jeder, der heute KI-Agenten in der Produktion einsetzt, stößt auf dieselbe technische Grenze. Das zugrundeliegende Large Language Model ist selten das eigentliche Limit, sondern die gesamte Infrastruktur vor dem eigentlichen Reasoning-Schritt. In diesem Beitrag erfahren Sie, warum Context Engineering entscheidend ist und wie eine Knowledge Engine diese kritische Lücke schließt.

Das eigentliche Problem: Context Engineering statt reines Retrieval

Jeder, der Agenten in Produktion baut, kennt das Problem: Das Modell selbst verfügt meist über ausreichende Reasoning-Fähigkeiten. Was den Prozess jedoch zum Erliegen bringt, ist alles, was vor dem eigentlichen Denkprozess passiert. Der Agent erhält eine Aufgabe, entscheidet sich für eine Informationssuche, holt Daten ab, bewertet Ergebnisse, sucht erneut und setzt ein fragmentarisches Bild zusammen. Bis das Modell schließlich eine Antwort generieren kann, ist der Großteil des Token- und Latenzbudgets bereits aufgebraucht.

Diese Diskrepanz definiert die aktuelle Agent-Infrastruktur. Die Disziplin, die sich hier herausgebildet hat, ist Context Engineering: Daten so zu formen, dass das Modell sie als nutzbares Wissen verarbeitet, anstatt den Agenten zu zwingen, Rohdaten zur Abfragezeit neu zusammenzusetzen.

Ein konkretes Beispiel: Der Marktanalyse-Agent

Stellen Sie sich einen Marktanalyse-Agenten bei einer Investmentfirma vor, der 10-K-Jahresberichte des S&P 500 durchsucht. Eine typische Anfrage könnte lauten: „Vergleichen Sie die Aktienrückkaufaktivitäten von NVIDIA, Microsoft und Walmart im Fiskaljahr 2022. Nennen Sie für jedes Unternehmen den Rückkaufbetrag, die ursprüngliche Programmgenehmigung und die verbleibende Authorization.“

Um diesen Agenten produktionsreif zu machen, muss die Context-Schicht vier strenge Anforderungen erfüllen:

• Genauigkeit: Richtige Antworten, die bei jedem Durchlauf reproduzierbar sind.
• Aufgaben-Latenz: Abfragebudgets in Sekunden, nicht in Minuten.
• Token-Kosten: Begrenzte Kosten pro Aufruf, die sich nicht im Workflow summieren.
• Governance: Feldbezogene Zugriffskontrollen und nachweisbare Quellenangaben.

Warum herkömmliche Ansätze scheitern

Teams versuchen oft, diese Anforderungen mit zwei gängigen Mustern zu lösen: Agentic RAG (Chunking, Embedding, hybrid Retrieval und Loops) oder einen Coding Agent in einer Sandbox mit Datei- und Suchtools. Beide Ansätze stoßen schnell an ihre Grenzen. Sie zwingen den Agenten, Wissen für jede Aufgabe zur Abfragezeit neu zu assemblieren. Die meiste Zeit und Rechenleistung wird für das Abrufen roher Daten aufgewendet, statt für das eigentliche Reasoning.

Die Knowledge Engine als neue Infrastrukturkategorie

Die Lösung ist altbekannt: Lassen Sie den Konsumenten keine Struktur pro Abfrage ableiten. Formen Sie die Daten stattdessen vorab in Artefakte, die die gewünschte Struktur bereits kodieren. Knowledge Graphs und semantische Schichten folgen genau diesem Prinzip. Context Engineering ist die moderne Ausprägung dieser Intuition, jetzt jedoch für Agenten anstelle von Dashboards.

Die Herausforderung der Domänen-Skalierung

Das Konzept ist einfach, die operative Umsetzung jedoch komplex. Eine gute Artefakt-Schicht für eine Domäne zu bauen, erfordert Monate der Iteration. Ein echtes Unternehmen hat jedoch Dutzende von Domänen (Vertrieb, Support, Recht, Finanzen, F&E), jede mit eigenen Datenstrukturen und Zugriffsmustern. Handgefertigte Pipelines skalieren nicht über die ersten ein oder zwei Domänen hinaus.

Dies erfordert eine neue Kategorie der Wissensinfrastruktur: eine Context-Schicht, die als Infrastruktur automatisch über Domänen hinweg arbeitet, anstatt manuell pro Use-Case neu gebaut zu werden. Wir haben genau dafür die Knowledge Engine entwickelt. Sie heißt Pinecone Nexus und fungiert als eigens dafür konstruierte Wissensmaschine für Agenten.

Aufbau einer Knowledge Engine

Eine Knowledge Engine basiert auf vier Grundbausteinen, die ineinandergreifen:

• Artefakt: Ein typisiertes, governed Informationsstück, das für eine spezifische Aufgabe konstruiert wurde.
• Context: Eine kuratierte Sammlung von Artefakten für eine bestimmte Rolle oder einen Workflow.
• Knowledge: Der gesamte Wissenspool aller Contexte im Unternehmen.
• Knowledge Engine: Das System, das all dies baut und bereitstellt. Im Kern steht der Context Compiler.

Der Context Compiler im Detail

Der Context Compiler ist ein autonomer Coding-Agent im Herzen der Wissensmaschine. Er nutzt ein agentic Harness-Muster, um task-optimierte Contexte zu konstruieren. Dabei kombiniert er einen Coding-Agenten mit drei Elementen:

1. Einer domänenspezifischen Eval-Sammlung (repräsentative Aufgaben mit bekannten Lösungen).
2. Einer Bibliothek vorab geprüfter Skills (z. B. Dokumentenverarbeitung, Entity-Extraktion).
3. Einem Feedback-Loop, der jede Iteration gegen das Eval-Signal bewertet.

Der Agent modifiziert kontinuierlich die Funktionen zur Artefakt-Konstruktion und zum Wissenabruf, bis die Tests bestehen. Das Ergebnis ist ein optimierter Context für die jeweilige Domäne, der in Tagen statt in Monaten bereitsteht.

KnowQL: Die deklarative Abfragesprache

Um sicherzustellen, dass der Agent das kompilierte Wissen effektiv nutzt, wurde KnowQL (Knowledge Query Language) entwickelt. Anstatt natürliche Sprache zu parsen, deklariert der Agent in KnowQL, was er benötigt, und erhält eine präzise, typisierte Antwort zurück. Eine Abfrage besteht aus vier Kategorien:

• Intent: Die Frage, das Antwortformat und die relevanten Contexte.
• Filter: Deterministische Prädikate und Zugriffskontrollen.
• Provenance: Feldbezogene Zitate, die direkt aus der Quelle stammen.
• Control: Ein Budget-Rahmen für Tiefe und Latenz.

Messung des Impakts: KRAFTBench

Um den Wert dieser Infrastruktur zu quantifizieren, wurde KRAFTBench erstellt. Dieses Framework misst Genauigkeit, Latenz und Token-Kosten über verschiedene Retrieval-Mechanismen hinweg, während das Composer-Modell konstant bleibt. Getestet wurden 150 komplexe Fragen zu 10-K-Berichten des S&P 500.

Die Ergebnisse im Vergleich

Die drei getesteten Ansätze zeigten deutliche Unterschiede. Der Coding Agent war der langsamste und unzuverlässigste. Agentic RAG erreichte zwar eine hohe Vollständigkeitsrate, litt jedoch unter niedrigerer Genauigkeit und höherer Latenz. Die Knowledge Engine lieferte die höchste Genauigkeit und Vollständigkeit bei der niedrigsten Latenz und deutlich geringeren Token-Kosten (ca. 7x günstiger als RAG, 80x günstiger als der Coding Agent).

Der Grund liegt in der Fehleranalyse: Während RAG und Coding Agents versuchen, Informationen durch semantische Suche oder Grep neu zusammenzusetzen und dabei oft in Partial-Matches oder Kontext-Overflows stecken bleiben, nutzt die Engine vorbereitete „Fact Sheet“-Artefakte. Die Antwort wird in einem einzigen Durchlauf komponiert.

Von der Quelle zum Wissen: Integration mit Box und Unstructured

Für den Einsatz mit echten Unternehmensdaten arbeitet die Engine nahtlos mit Ökosystem-Partnern zusammen. Ein typischer Workflow für einen Legal-Review-Agenten sieht wie folgt aus:

• Box (Quelle): Verwahrt die Verträge und deren Zugriffsberechtigungen.
• Unstructured (Parsing): Normalisiert PDFs und Word-Dokumente, extrahiert Tabellen und Entitäten sowie Metadaten.
• Pinecone Nexus (Knowledge Engine): Der Context Compiler verarbeitet die extrahierten Daten zu Artefakten. Bei der Abfrage werden die Berechtigungs-Metadaten als Filter angewendet, sodass nur autorisierte Verträge angezeigt werden.

Fazit: Eine neue Infrastruktur für die Agenten-Ära

Die Lücke zwischen fähigen Modellen und der sie stützenden Infrastruktur bestimmt, ob Agenten im großen Maßstab erfolgreich sind. Herkömmliche Pipelines stoßen hier an ihre Grenzen. Die Zukunft gehört der Knowledge Engine: einer Infrastruktur, die selbst agentic arbeitet, um den Context für jede Domäne im Unternehmen automatisch zu kompilieren. Damit wird die Vision konkret, dass jeder Agent in jedem Team auf optimiertes, kompiliertes Wissen zugreifen kann.

Quelle: https://www.pinecone.io/blog/introducing-nexus-knowledge-engine/