Pinecone Nexus und das Ende von Agentic RAG, wie wir es kennen

Pinecone Nexus und das Ende von Agentic RAG, wie wir es kennen

Ich habe mir am 5. Mai 2026 die Nexus-Ankündigung von Ich hatte bereits akzeptiert, dass Agentensysteme genau das im Jahr 2026 kosten. Wirf genügend Token in die Abrufschleife und schließlich findet der Agent den richtigen Absatz. Das ist der Deal.

Dann sagte Ash Ashutosh, CEO von Pinecone, bei der Ankündigung etwas, das den Deal in meinem Kopf zum Scheitern brachte.

Er bezeichnete RAG als „für menschliche Benutzer entwickelt“ und Nexus als „für Agentenbenutzer entwickelt“. Das klingt nach Marketing, bis man weiß, was es tatsächlich bedeutet. Das durch Abruf erweiterte Muster, das jeder in den letzten zwei Jahren in Agentenschleifen verpackt hat, wurde für den Fall „Human-in-the-Loop“ entwickelt: Eine Person gibt eine Frage ein, ein System ruft einige Passagen ab, ein Modell setzt diese Passagen wieder zu Prosa zusammen. Das Einschließen dieses Musters in eine Agentenschleife änderte nichts an dem Zweck des Musters. Dadurch wurde das Muster einfach öfter ausgeführt.

Und jeder zusätzliche Lauf kostet das Agenten-Argumentationsbudget, das ihm nicht zur Verfügung steht.

Das ist der Rahmen, an dem ich nicht rütteln kann. Agentic RAG war nie die Antwort auf den Abruf. Es war eine Lösung für die Tatsache, dass der Abruf immer der Engpass war, und wir hofften weiterhin, dass mehr Agentur dies ausgleichen würde. Pinecone Nexus ist das architektonische Eingeständnis, dass dies nicht der Fall ist. Sie können ein Abrufproblem nicht beheben, indem Sie den Abruf autonomer gestalten. Sie müssen vor dem Agenten Wissen zusammentragen, damit der Agent aufhört, bibliothekarische Arbeit zu leisten, und beginnt, die Arbeit zu erledigen, in der er eigentlich gut ist.

Ich werde durchgehen, was Nexus eigentlich ist, wie die Zahlen aussehen (mit allen Vorbehalten, die sie verdienen), wo dies neben Karpathys LLM-Wiki, Microsoft Fabric IQ und Google Knowledge Catalog passt und welche Frage jeder Entwickler im Jahr 2026 beantworten muss: Wann schlägt kompiliertes Wissen den Agenten RAG und wann ist die alte Schleife immer noch der richtige Anruf?

Manches davon wird wie eine Lobrede auf den Agenten RAG klingen. Das ist es nicht. Am Ende dieses Beitrags werden Sie sehen, warum die Zukunft hybrid ist – und warum Nexus die erste Infrastruktur ist, die den Hybrid ehrlich macht.

Was Agentic RAG Sie tatsächlich kostet

Lassen Sie mich dies in Zahlen begründen, bevor wir zur Architektur kommen, denn jedes Gespräch über die Rückholung ist ein Hin und Her, bis man die tatsächlichen Kosten auf den Tisch legt.

Durch das eigene Framing von Pinecone werden etwa 85 Prozent des Rechenzyklus eines Agenten in den Kontextabruf und nicht in die eigentliche Aufgabe verlagert. Das stimmt mit den Agentenspuren überein, die ich das ganze Jahr über beobachtet habe. Öffnen Sie einen beliebigen Agenten RAG, der mit aktivierter Debug-Anmeldung ausgeführt wird, und Sie werden das gleiche Muster sehen: Toolaufruf, abrufen, auswerten, erneut mit einer anderen Abfrage abrufen, erneut auswerten, manchmal einen Subagenten erzeugen, um zusammenzufassen, was zurückgekommen ist, und schließlich die Antwort generieren. Sechs bis zehn Werkzeugaufrufe sind normal. Zwölf sind keine Seltenheit. Ich habe gesehen, wie Läufe zwanzig erreichten, bevor sie zu etwas Brauchbarem führten.

Jeder dieser Aufrufe zieht den Kontext mit sich. Jeder verbraucht Token – nicht nur die abgerufenen Blöcke, sondern jeden Zwischenspeicher, den der Agent in sich selbst schreibt, um sich daran zu erinnern, was er versucht hat. Die Abrufschleife ist nicht nur langsam. Es ist in gewisser Weise teuer, denn je länger der Agent über verrauschte Abrufe nachdenkt, desto mehr Argumentationsspuren muss er im Kontext halten.

Branchenanalysen bestätigen dies. Agentic RAG kostet ungefähr das 3- bis 10-fache der Token-Kosten von Vanilla RAG. Die Kosten skalieren mit der Anzahl der Modellaufrufe. Der iterative Abruf skaliert die Kosten direkt mit der Anzahl der Schritte. Keine dieser Zahlen stammt von Pinecone – sie stammen aus unabhängigen Produktionsleitfäden, die Anfang 2026 veröffentlicht wurden, und sie beschreiben die Musterteams, die seit einem Jahr stillschweigend akzeptiert werden.

Dann gibt es noch das Determinismusproblem.

Da der Agent je nach dem, was er abgerufen hat, bei jedem Schritt unterschiedliche Entscheidungen trifft, kann dieselbe Abfrage bei verschiedenen Ausführungen unterschiedliche Pfade und unterschiedliche Ausgaben erzeugen. Ich habe zehn Mal hintereinander identische Fragen an meinen eigenen Vertragsmakler gestellt und dabei beobachtet, wie dieser drei verschiedene Klauseln zitierte – keine davon war genau falsch, aber keine davon gleich. Diese Art von Nichtdeterminismus ist beim Erkunden in Ordnung. Es ist inakzeptabel, wenn Sie etwas bauen, das überprüfbar sein muss.

Die Abschlussquoten für Aufgaben machen die andere Hälfte der Rechnung aus. Pinecone gibt den Bereich von 50–60 Prozent für den Agenten RAG in seinen eigenen Benchmarks an. Ich stehe jedem Anbieter-Benchmark skeptisch gegenüber, aber die Richtung ist fair: Selbst wenn der Agent RAG funktioniert, funktioniert er nicht konsistent genug, um in Compliance-sensible Workflows integriert zu werden, ohne dass ein Mensch jede Ausgabe überprüft. Das bedeutet, dass Sie Agentenpreise von RAG für ein System zahlen, das noch eine menschliche Validierung erfordert. Wählen Sie die Hälfte dieses Satzes aus, die Sie am meisten beleidigt.

Ich habe einen ähnlichen Aspekt angesprochen, als ich darüber geschrieben habe, warum MCP nach vierzig Werkzeugen zusammenbricht – derselbe Architekturfehler wiederholt sich. Das Protokoll geht davon aus, dass der Agent alle seine Optionen gleichzeitig im Kontext halten kann. Die Mathematik sagt, dass es nicht möglich ist. Schemainjektion, Abrufschleifen, Tool-Fanout – das sind alles Symptome eines tiefer liegenden Fehlers. Wir versuchen weiterhin, Agenten zur Laufzeit intelligenter zu machen, anstatt die Strukturierungsarbeit zur Build-Zeit zu erledigen.

Nexus ist die erste große Infrastruktur, die diesen Fehler beim Namen nennt.

Was Pinecone Nexus eigentlich ist

Entfernen Sie die Startsprache, und Nexus leistet eine wichtige Sache: Es verlagert den teuren Teil des Abrufs von der Abfragezeit auf die Aufnahmezeit.

Das ist der ganze Trick. Alles andere sind Implementierungsdetails.

Hier ist der Mechanismus. Anstatt Rohdokumente (oder Rohdokumentblöcke) zu speichern und bei Bedarf abzurufen, führt Nexus zum Zeitpunkt der Aufnahme einen Kontext-Compiler für das Quellmaterial aus. Der Compiler liest die Daten, versteht die Art der Aufgaben, die der Agent ausführen muss, und erstellt typisierte, aufgabenspezifische strukturierte Artefakte – vorgefertigte, voraggregierte, vorzitierte Antworten auf die Frageformen, die der Agent stellen wird.

Wenn zur Laufzeit eine Anfrage eingeht, führt der Agent keine Suche durch. Es deklariert seine Absicht in KnowQL, der neuen deklarativen Abfragesprache von Pinecone, und Nexus ruft das relevante kompilierte Artefakt in einem einzigen Roundtrip ab. Keine Abrufschleife. Kein erneuter Abruf. Keine iterative Verfeinerung. Die Arbeit ist bereits erledigt.

Es lohnt sich, bei KnowQL innezuhalten, denn es ist der Teil der Ankündigung, der signalisiert, wohin es architektonisch geht. Es verfügt über sechs Grundelemente: Absicht, Filter, Herkunft, Ausgabeform, Konfidenz und Budget. Das ist kein API. Das ist eine Sprache für Agenten. Die Absicht sagt aus, was der Agent zu tun versucht. Filter schränkt den Bereich ein. Die Provenienz erfordert Zitate. Die Ausgabeform gibt die Struktur an, die der Agent zurückerwartet. Vertrauen legt die Untergrenze für die Antwortqualität fest. Das Budget begrenzt die Token-Ausgaben.

Vergleichen Sie das mit den JSON-Tool-Aufrufen, die ich seit zwei Jahren schreibe, um den Abruf abzuschließen – maßgeschneiderte Schemata für jedes Abrufmuster, benutzerdefinierter Klebecode, keine Standardmethode zum Ausdruck „Ich brauche eine Antwort mit Zitaten und einem Konfidenzwert unter 200 ms.“ KnowQL ist der erste Versuch, den ich gesehen habe, Agenten ein Vokabular für den Wissenszugriff zu geben, das der Art und Weise entspricht, wie Agenten tatsächlich denken. Ob KnowQL konkret gewinnt, ist offen. Das Muster deklarativer agentennativer Abfragesprachen ist mit ziemlicher Sicherheit der Fall.

Der andere Teil ist der Kontext-Compiler selbst, der Teil des Systems ist, der tatsächlich Artefakte aus Rohdaten erstellt. Pinecone beschreibt es als einen autonomen Codierungsagenten, der aus einer vorab überprüften Kompetenzbibliothek greift – Chunking-Strategien, Entitätsextraktion, Tabellenanalyse, Zusammenfassungsmuster – und aufgabenspezifische Artefakte synthetisiert, die anhand eines zurückgehaltenen Testsatzes evaluiert werden. Mit anderen Worten: Der Compiler ist selbst ein Agent, wird jedoch einmal, zur Erstellungszeit, anhand einer Spezifikation dessen ausgeführt, was das System antworten muss. Nicht bei jeder Anfrage.

Dies kommt der Funktionsweise einer Datenbank näher als der Funktionsweise von RAG. Sie definieren ein Schema, indizieren Ihre Daten anhand dieses Schemas und fragen den Index ab. Das Schema in Nexus ist der Bewertungssatz. Der Index sind die kompilierten Artefakte. Die Abfrage ist KnowQL. Jeder, der mit traditionellen Datenbanken gearbeitet hat, wird das Muster sofort spüren, denn es ist das Muster, das jedes funktionierende Datensystem antreibt, bevor wir mit der Vektorsuche den Überblick verloren.

Die Zahlen – und wo die Sternchen leben

Pinecone veröffentlichte parallel zum Nexus-Start einen Benchmark namens KRAFTBench (Knowledge Retrieval Assessment Framework for Text). Jede folgende Zahl ist der Anspruch von Pinecone. Bis zum Tag, an dem ich dies schreibe, wurde nichts davon unabhängig reproduziert, und ich möchte, dass Sie jede Abbildung unter Berücksichtigung dieser Einschränkung lesen.

Mit diesen Vorbehalten versehen:

– Die Token-Nutzung pro Abfrage sank von etwa 49.000 auf etwa 6.000 – etwa eine Reduzierung um 88 Prozent. – Die Aufgabenerledigung beim Finanzanalyse-Benchmark erreichte etwa 100 Prozent, im Vergleich zu 50–60 Prozent bei der Basislinie des Agenten RAG und etwa 62,7 Prozent bei der Basislinie des Codierungsagenten AI. – Tool-Aufrufe pro Abfrage sanken von sechs oder mehr auf einen – einen einzigen deklarativen Aufruf.

• Die Latenz wurde erheblich gesenkt (Pinecone behauptet eine bis zu 30-mal schnellere Zeit bis zur Fertigstellung). – Die AI-Coding-Agent-Basislinie, an der Nexus gemessen wurde, verbrannte etwa 528.000 Token pro Abfrage. Bei einer Finanzanalyseaufgabe behauptet Pinecone, dass eine Abfrage, die zuvor 2,8 Millionen Token verbrauchte, mit rund 4.000 abgeschlossen wurde – eine Reduzierung um 98 Prozent.

Diese Zahlen sind frappierend. Sie sind auch ein Anbieter-Benchmark für eine vom Anbieter ausgewählte Aufgabenkategorie. Die ehrliche Lesart lautet: Direktional ist dies das, was die Verlagerung der Arbeit von der Abfragezeit zur Kompilierzeit bewirken sollte. Die genauen Größenordnungen werden bei Ihrer Arbeitsbelastung anders aussehen, möglicherweise sogar schlimmer. Vermutlich immer noch eine erhebliche Verbesserung gegenüber wiederholbaren strukturierten Aufgaben. Möglicherweise schlechter als der Agent RAG bei explorativen Long-Tail-Fragen. Wir werden es erst wirklich wissen, wenn unabhängige Bewertungen vorliegen – und ich erwarte diese im Laufe des Sommers.

Was mir immer wieder in den Sinn kommt, ist die Form der Verbesserung, nicht die Größe. Der Wechsel von sechs Toolaufrufen zu einem ist kein Optimierungsgewinn. Es ist ein architektonischer Zusammenbruch. Sie können den Agenten RAG für immer weiter optimieren und nie zu einem „einen deklarativen Aufruf“ kommen, da die Schleife für den Ansatz strukturell ist. Kompilierte Artefakte gelangen dorthin, weil sie die Schleife vollständig entfernt haben.

Das ist meiner Meinung nach der Teil, bei dem die meisten Berichterstattungen unterboten sind.

Wie ein Nexus-Workflow tatsächlich durchgängig aussieht

Lassen Sie mich dies anhand des Beispielworkflows Pinecone konkretisieren, der während der Ankündigung gezeigt wurde, da die Abstraktion aufbricht, sobald Sie die Pipeline sehen.

Sie haben einen Ordner mit Verträgen in Box oder Google Drive. Ein paar hundert PDFs, jedes anders, größtenteils mit extrahierbarem Text, aber ein nicht trivialer Prozentsatz mit Tabellen, Signaturblöcken, Anlagen und eingebetteten Ergänzungen. Die Aufgabe, die Ihr Agent übernehmen soll: Beantwortung von Fragen zu Verlängerungsbedingungen für das gesamte Portfolio. Dinge wie „Welche Verträge verlängern sich automatisch innerhalb der nächsten 90 Tage“, „Wie lang ist die durchschnittliche Kündigungsfrist für die Verlängerung bei unseren Top-20-Anbietern“, „Welche Verträge haben Staffelungsklauseln, die an den CPI im Vergleich zu einem festen Prozentsatz gebunden sind.“

Unter dem Agenten RAG ist dies jedes Mal ein Multi-Tool-Tanz. Der Agent ruft einige Kandidatenblöcke ab. Liest sie. Erkennt, dass es mehr Kontext braucht. Erneute Abfragen. Ruft zugehörige Verträge ab. Versucht zu aggregieren. Halluziniert einen Satz. Zur Überprüfung erneut abrufen. Eventually composes an answer. Vierzigtausend Token später erhalten Sie etwas Brauchbares. Vielleicht.

Unter Nexus sieht die Pipeline so aus:

1. Quelldaten – Die Verträge befinden sich in Box oder Drive. Daran ändert sich nichts. 2. Parsing – Pinecone lässt sich in den Unstructured-Dienst integrieren, der den eigentlichen Text sowie die Tabellen, Entitäten und Strukturelemente extrahiert. Das ist nur modernes Parsen – nichts Exotisches. 3. Kompilierung – Der Kontext-Compiler durchläuft die analysierte Ausgabe und bewertet sie anhand eines Testsatzes der Frageformen, die Sie interessieren. Es synthetisiert Artefakte. Ein Artefakt könnte eine strukturierte Tabelle sein, in der die Verlängerungsbedingungen aller Verträge im Portfolio zusammengefasst sind, mit Herkunftsverweisen zurück zu den Quelldokumenten. Eine andere könnte ein Beziehungsdiagramm sein, das übergeordnete Verträge mit Änderungen verknüpft. Der Compiler erstellt diese einmalig bei der Aufnahme. 4. Artefakt – Das kompilierte Artefakt ist das, was der Agent tatsächlich abfragt.

Für die „durchschnittliche Kündigungsfrist für Verlängerungen bei unseren Top-20-Anbietern“ aggregiert das Artefakt diese Daten bereits mit Zitaten auf Feldebene. Die Arbeit, herauszufinden, welche Verträge zu den „Top-20-Anbietern“ zählen und welche Klauseln als „Verlängerungsfrist“ gelten, wurde zum Zeitpunkt der Kompilierung durchgeführt. 5. Abfrage – Der Agent gibt einen einzelnen KnowQL-Aufruf mit Absicht, Filter, Herkunftsanforderungen und Ausgabeform aus. 6. Antwort – Präzise, ​​strukturiert, zitiert, keine Agentenschleife.

In diesem letzten Schritt findet der philosophische Wandel statt. Die Antwort ist präzise, da das Artefakt für diese Frageform erstellt wurde. Es ist strukturiert, weil KnowQL die Ausgabeform angegeben hat. Es wird zitiert, weil bei der Kompilierung die Herkunft bis zu den Quelldokumenten erhalten bleibt. Und es gibt keine Agentenschleife, da zum Zeitpunkt der Abfrage nichts mehr herauszufinden ist – die Berechnung ist bereits erfolgt.

Lesen Sie nun die gleichen sechs Schritte und stellen Sie sich die Frage, die ich gestellt habe, als ich das Diagramm zum ersten Mal sah: Was passiert, wenn jemand eine Frage stellt, mit der der Compiler nicht gerechnet hat?

Denn das ist der Haken. Und es ist ein echtes.

Wo zusammengestelltes Wissen bricht

Ich möchte ehrlich zu den Grenzwerten sein, denn jeder „Das ändert alles“-Beitrag, der die Grenzwerte nicht anspricht, verkauft etwas.

Nexus glänzt bei bekannten, wiederholbaren und genau spezifizierten Abfragen. Vertragsverlängerungsbedingungen. Fragen von Finanzanalysten zu einer bekannten Struktur der Gewinnablage. Kundensupportfragen anhand einer stabilen Wissensdatenbank. Compliance-Abfragen gegen eine feste Vorschrift. Hierbei handelt es sich um Arbeitslasten, bei denen die Fragenformen im Voraus bekannt sind, die Daten strukturiert genug sind, um sie zu kompilieren, und die Kosten für Fehler hoch genug sind, um die Kompilierungsarbeit im Vorfeld zu rechtfertigen.

Nexus wird mit explorativen, Long-Tail- oder neuartigen Fragen zu kämpfen haben – solchen, bei denen Sie nicht im Voraus wissen, was Sie brauchen werden. Wenn Sie einen Rechercheagenten aufbauen, der nach Ahnungen durch ein Dokumentenkorpus wandert, können kompilierte Artefakte nicht jede Ahnung vorhersehen. Der Compiler-Bewertungssatz ist endlich. Der Raum möglicher Fragen ist nicht vorhanden.

Ein paar konkrete Risiken möchte ich nennen:

Artefaktwartung. Pinecone sagt, dass Artefakte aktualisiert werden, wenn sich die zugrunde liegenden Daten ändern, aber die Kosten für die Neukompilierung sind wirklich ungewiss. Wenn sich Ihre Daten stündlich ändern und die Neukompilierung pro Artefakt Minuten dauert, wird die Mathematik schnell hässlich. Für statische oder sich langsam ändernde Daten – die meisten Unternehmensverträge, die meisten behördlichen Unterlagen, die stabilsten Wissensdatenbanken – ist dies kein Problem. Bei Hochgeschwindigkeitsdaten ist das eine echte Frage.

Zusammensetzen von Fehlern zur Kompilierungszeit. Der Compiler ist ein LLM-Agent, der strukturierte Artefakte erzeugt. LLMs halluzinieren. Wenn der Compiler zur Erstellungszeit eine falsche Aggregation halluziniert, wird jede Abfrage dieses Artefakts mit voller Sicherheit und einem falschen Zitat die falsche Antwort zurückgeben. Pinecone mildert dies mit dem Evaluierungssatz – der Compiler optimiert anhand zurückgehaltener Testdaten –, aber kein Evaluierungssatz deckt alles ab. Die Abweichung von der Quelle zum Artefakt ist eine Fehlerkategorie, die es in Vanilla RAG nicht gab, wo die Quelle und der abgerufene Text identisch waren.

Fallback-Verhalten ist unklar. Was passiert, wenn der Agent eine KnowQL-Abfrage ausgibt, die mit keinem kompilierten Artefakt übereinstimmt? Wird auf das traditionelle Abrufen zurückgegriffen? Kommt es leer zurück? Löst es eine Neukompilierung aus? In den Einführungsmaterialien herrscht diesbezüglich Stillschweigen, und die Antwort ist für den Produktionseinsatz von enormer Bedeutung.

Die Kosten für die Erstellungszeit betragen nicht Null. Die Abfragezeit ist günstig, da die Kompilierung bereits stattgefunden hat. Bei der Kompilierung handelt es sich jedoch um einen autonomen Codierungsagenten, der für Ihr gesamtes Korpus ausgeführt wird. Das ist echte Berechnung, echte Modellinferenz, echtes Geld. Bei kleinen Datensätzen ist dies vernachlässigbar. Bei Korpora im Unternehmensmaßstab ist die Bauzeitrechnung eine Budgetkategorie, die bisher niemand vorhersehen musste.

Die klare Art, darüber nachzudenken: Nexus verschiebt den Kompromiss von „teuer jede Abfrage“ zu „teuer jede Neukompilierung, billig jede Abfrage“. Für Workloads mit hohem Abfragevolumen für stabile Daten ist diese Berechnung großartig. Bei Workloads mit geringem Abfragevolumen für flüchtige Daten ist die Rechnung schlechter. Sie müssen Ihre Arbeitslast kennen, bevor Sie wissen, ob die Architektur passt.

Die Vergleichskarte: Nexus, LLM-Wiki, Wissenskatalog, Fabric IQ

Nexus entsteht nicht im luftleeren Raum. Das Muster des gesammelten Wissens konvergiert aus mindestens vier Richtungen, und es lohnt sich, sie auf derselben Karte zu sehen, da sie eine gemeinsame Diagnose haben, aber nach unterschiedlichen Lösungen streben.

Karpathys LLM-Wiki, das ich ausführlich behandelt habe, als ich eine Markdown-First-Wissensdatenbank in Obsidian erstellt habe, ist die Infrastruktur-Light-Version derselben Idee. Legen Sie Rohstoffe in einem Ordner ab. Führen Sie einen LLM-Kompilierungsdurchlauf aus, der strukturierte Markdown-Wiki-Seiten, Indizes und Querlinks erstellt. Fragen Sie das Wiki ab, indem Sie den Index lesen. Keine Vektordatenbank. Keine Einbettungen. Kein KnowQL. Nur Markdown und ein LLM, das die Struktur versteht, die es aufgebaut hat.

Das LLM-Wiki und Nexus sind sich in der Kernthese einig: Bauen Sie die Struktur zum Zeitpunkt der Aufnahme auf, nicht zum Zeitpunkt der Abfrage. Über die Infrastruktur sind sie sich nicht einig – die Version von Karpathy läuft auf Obsidian, Claude Code und Ihrem Dateisystem. Nexus läuft auf der gehosteten Datenbank KnowQL von Pinecone und dem Kontext-Compiler. Das Wiki eignet sich für persönliche Wissensdatenbanken mit weniger als 400.000 Wörtern. Nexus eignet sich für unternehmensweite Daten mit aufgabenspezifischen Kompilierungsanforderungen, die keine Markdown-Struktur ausdrücken kann.

Beides ist richtig. Sie nehmen unterschiedliche Maßstäbe ein.

Der Cloud Knowledge Catalog von Google (ehemals Dataplex Universal Catalog, umbenannt im April 2026) geht einen dritten Weg. Es baut eine kontinuierliche semantische Schicht auf strukturierten Daten auf und stellt diese über Model Context Protocol-Endpunkte den Agenten zur Verfügung. Die semantische Ebene ist dynamisch – sie synthetisiert Kontext aus Schemata, Abfrageprotokollen und Looker-Modellen – und die Bindung an die Geschäftsbedeutung erfolgt weitgehend manuell. Während Nexus einen autonomen Compiler verwendet, um Artefakte aus Rohdaten zu erstellen, nutzt Knowledge Catalog eine vom Menschen definierte Ontologie, um Agenten in der organisatorischen Wahrheit zu verankern. Beide reduzieren Halluzinationen. Sie tun dies über entgegengesetzte Enden des Strukturierungsspektrums.

Microsofts Fabric IQ Ontology (derzeit in der Vorschau) kommt dem Google-Ansatz näher als der Pinecone-Ansatz. Fabric IQ erstellt eine Graphontologie – Entitätstypen, Beziehungen, Eigenschaften, Bedingungs-Aktionsregeln – die Agenten über MCP-Endpunkte abfragen. Die Grafik ist explizit. Das Schema ist explizit. Die semantische Bindung erfolgt manuell. Routing ist deterministisch, weil die Struktur deterministisch ist. Fabric IQ ist die Antwort für Organisationen, die möchten, dass ihre AI-Agenten auf einem von Menschen kuratierten Unternehmensvokabular mit strenger Governance basieren.

Diese gegeneinander abbilden:

• Pinecone Nexus – autonome Kompilierung, aufgabenoptimierte Artefakte, deklarative agentennative Abfragesprache (KnowQL). Hohe Automatisierung, schnelle Iteration, herstellerdefinierte Abfragesemantik.
• Karpathy's LLM Wiki – manuelle oder halbautomatische Kompilierung in Markdown, Navigation durch Indizes. Leichte Infrastruktur, niedrige Zeremonie, skalierbar auf vielleicht 400.000 Wörter.
• Google Knowledge Catalog – kontinuierliche semantische Ebene mit manueller Ontologiebindung, MCP-exponiert. Stark in der Governance, abhängig von einer von Menschen kuratierten Ontologie.
• Microsoft Fabric IQ – kompiliertes Ontologiediagramm, explizite Beziehungen, MCP-exponiert, deterministisches Routing. Stärkste Governance, am langsamsten einzurichten.

Das Muster in allen vier Fällen: Erledigen Sie die Strukturierungsarbeit vor dem Agenten, nicht bei jeder Abfrage. Die Unterschiede bestehen darin, wo die Strukturierung stattfindet, wer sie durchführt und wie der Agent mit dem Ergebnis umgeht.

Diese Konvergenz ist das Signal. Vier sehr unterschiedliche Unternehmen, vier sehr unterschiedliche Stacks, die alle auf die gleiche architektonische Schlussfolgerung zielen. Wenn das passiert, ist die Schlussfolgerung normalerweise richtig.

Was das jetzt für jeden bedeutet, der Makler baut

Wenn ich von der Ankündigung zurückdenke, ist hier der konkrete Rat, den ich mir selbst vor einem Jahr geben würde.

Hören Sie auf, Ihrer Abrufschleife mehr Agentur hinzuzufügen. Wenn Ihr Agent ausfällt, weil der Abruf verrauscht ist, können weitere Iterationen das Problem nicht beheben. Weitere Tools werden das Problem nicht beheben. Ein größeres Modell wird das Problem nicht beheben. Der Abruf ist falsch und die Argumentation kann das Upstream-Rauschen nicht kompensieren. Der nächste Schritt besteht darin, die Daten in einer Form zu kompilieren, die den Fragen entspricht, und nicht darin, den Abruf in einen anderen Agenten einzubinden.

Fangen Sie frühzeitig an, die Frage zum Bewertungssatz zu stellen. Was Nexus kann, was Vanilla RAG nicht kann, ist die Optimierung der Kompilierung anhand eines bekannten Satzes von Frageformen. Das setzt voraus, dass Sie wissen, wozu Ihr Agent dient. Wenn Sie die 20 häufigsten Frageformen, mit denen Ihr Agent konfrontiert wird, nicht formulieren können, sind Sie noch nicht bereit, Wissen zusammenzustellen – Sie befinden sich noch in der Erkundungsphase, und der Agent RAG ist immer noch das richtige Werkzeug. Die Reifekurve lautet: explorativer Agent → stabiler Anwendungsfall → kompilierte Wissensschicht. Durch das Überspringen des mittleren Schritts wird der Bewertungssatz übersprungen, was bedeutet, dass die gesamte Kompilierungsvoraussetzung übersprungen wird.

Behandeln Sie kompiliertes Wissen als Bereitstellungsmeilenstein. Wenn eine Arbeitslast von „Wir finden heraus, was wir fragen sollen“ zu „Wir stellen immer wieder dieselben Formen von Fragen“ wechselt, ist dies der Moment, von der Agentenebene zu einer kompilierten Ebene zu wechseln. Nexus, LLM Wiki, Fabric IQ – wählen Sie diejenige aus, die Ihrer Skala entspricht. Der Auslöser ist derselbe.

Hybrid ist die Antwort, kein Kompromiss. Agentic RAG bleibt das richtige Werkzeug für wirklich explorative Arbeit. Ein Rechercheagent, der auf der Suche nach neuartigen Fragen durch ein Korpus wandert, wird das zusammengestellte Wissen zu diesen neuartigen Fragen übertreffen, da der Compiler diese nicht vorhersehen kann. Die Architektur, die ich in den Jahren 2026 und 2027 voraussichtlich gewinnen werde, ist hybrid – zusammengestelltes Wissen für die hochwertigen, wiederholbaren, Governance-kritischen Workloads und agentisches RAG für die Erkundung. Die beiden sind Ergänzungen, keine Substitute.

Beobachten Sie die Bewertungsdisziplin, die mit dieser Änderung einhergeht. Die Kompilierung anhand eines Bewertungssatzes ist eine Disziplinänderung. Es zwingt Sie, die Ausgabeformen, die Konfidenzuntergrenzen, die Latenzbudgets und die Zitieranforderungen im Voraus anzugeben. Diese Besonderheit ist gut für die Agentenqualität, unabhängig davon, ob Sie Nexus jemals einsetzen. Selbst wenn Sie auf dem Agenten RAG bleiben, werden beim Schreiben Ihres Evaluierungssatzes so, wie Nexus ihn schreiben möchte, Fehlermodi auftauchen, die Sie ignoriert haben.

Ich habe Agenten in meiner eigenen Arbeit durch diesen Übergang gedrängt. Der Vertragsagent, den ich oben in diesem Beitrag erwähnt habe, ist der erste Workload, den ich vom Agenten RAG auf ein Muster mit kompilierten Artefakten umstelle – teilweise unter Verwendung von Nexus, wo es sich in der frühen Zugriffsphase befindet, teilweise beim Erstellen meines eigenen Kontext-Compilers anhand eines kleineren Auswertungssatzes für die Teile, bei denen ich volle Kontrolle haben möchte. Das erste Signal ist das, was die Benchmarks von Pinecone nahelegen: Wenn Sie kompilieren, hört der Agent auf, ein Bibliothekar zu sein, und beginnt, ein Denker zu sein. Die Token-Kosten brechen ein. Der Nichtdeterminismus verschwindet größtenteils. Auditing wird möglich, weil jede Antwort ihre zusammengestellte Herkunft trägt.

Der letzte Punkt – die Überprüfbarkeit – ist meiner Meinung nach derjenige, der in regulierten Branchen letztendlich am wichtigsten sein wird. Wenn ein Agent eine Frage beantwortet, indem er ein zusammengestelltes Artefakt mit Zitaten auf Feldebene abruft, können Sie nachweisen, was er wusste und woher er es wusste. Agentic RAG hat dir das nie gegeben. Der Abrufpfad war jedes Mal anders. Der Prüfpfad war eine Fiktion. Zusammengetragenes Wissen ist die erste Architektur, in der die Antworten von Agenten in einer Compliance-Überprüfung verteidigt werden können, ohne mit der Hand zu winken.

Ich habe einen Teil dieser Disziplin bereits abgedeckt, als ich darüber geschrieben habe, warum Kontext-Engineering besser ist als Konfiguration – das gleiche Prinzip lässt sich erweitern. Weniger konfigurieren. Gestalten Sie die Struktur dessen, was der Agent liest. Verschieben Sie die Arbeit flussaufwärts.

Die ehrliche Wette darauf, was gewinnt

Hier ist die Vorhersage, die ich zu Protokoll geben möchte.

In 18 Monaten wird die Standardarchitektur für hochwertige Unternehmensagenten aus Wissensschichten zusammengestellt – unter dem Namen des jeweiligen Anbieters. Pinecone Nexus heute, aber das Muster ist größer als das Produkt. Die Unternehmen, die darauf wetten – Pinecone, Microsoft, Google und wer auch immer die nächste Welle auslöst – haben mit ihrer Richtung Recht. Ob sich ihre konkreten Umsetzungen durchsetzen, ist offen. Der Strukturwandel ist es nicht.

Agentic RAG wird nicht verschwinden. Es wird sich auf die Arbeitslasten zurückziehen, in die es tatsächlich passt – explorative Forschungsagenten, Ad-hoc-Analysen, Situationen, in denen die Form der Frage wirklich unbekannt ist. Das ist eine kleinere Fläche als in den Überlegungen für 2024–2025 angenommen, aber sie ist nicht Null. Die ehrliche Begründung ist, dass wir den Agenten RAG überbeansprucht haben, weil es das einzige Tool war, das wir hatten. Jetzt haben wir zwei Werkzeuge. Wir werden gleich erfahren, welche Workloads zu welchen gehören.

Die Bauherren, die im Jahr 2026 den größten Einfluss haben, werden diejenigen sein, die diesen Übergang früh richtig erkannt haben. Das bedeutet, dass Sie jetzt mit der Formulierung des Evaluierungssatzes für Ihre hochwertigen Workloads beginnen, auch wenn Sie noch nicht zum Kompilieren bereit sind. Es bedeutet, die unabhängigen Benchmarks von Nexus und seinen Konkurrenten im Laufe des Sommers zu beobachten. Es bedeutet, mit KnowQL – oder dessen Äquivalenten – zu experimentieren, damit Sie in deklarativen, agentennativen Abfragesprachen denken können, bevor diese obligatorisch werden. Und es bedeutet, dem Instinkt zu widerstehen, Ihrer vorhandenen Agenten-RAG-Pipeline eine weitere Iterationsschleife hinzuzufügen, wenn der richtige Schritt darin besteht, die Schleife vollständig zu entfernen.

Ich möchte dies mit der Metapher verbinden, die mir die Architektur schließlich schmackhaft gemacht hat.

Agentic RAG war der Agent, der jeden Morgen eine Bibliothek betrat, den Bibliothekar um ein Buch bat, es las, um ein weiteres Buch bat, es las, Notizen machte, um ein drittes Buch bat und schließlich mit einer Antwort wieder hinausging. Jeden Morgen. Für jede Frage. Sogar die gleichen Fragen.

Zusammengetragenes Wissen bedeutet, dass der Bibliothekar über Nacht eine individuelle Enzyklopädie für den Agenten schreibt, die genau die Fragen enthält, die der Agent stellen wird, wobei alle Fakten zitiert und alle Beziehungen vorab nachgezeichnet werden. Der Agent betritt die Bibliothek, schlägt die rechte Seite der Enzyklopädie auf, liest einen Eintrag und geht hinaus. Gleiche Antwort. Ein Prozent der Arbeit.

Wir zahlen seit zwei Jahren Agentenpreise, weil niemand die Enzyklopädie geschrieben hat. Pinecone Nexus ist die Wette, dass die Enzyklopädie im Jahr 2026 geschrieben wird. Ob Sie Nexus speziell übernehmen, ist eine geringere Frage als die Frage, ob Sie das Muster übernehmen.

Wenn Ihr Agent immer noch jeden Morgen die Bibliothek betritt, kommt für diesen Arbeitsablauf die Enzyklopädie. Die Frage ist nur, ob Sie es nach Ihren eigenen Vorstellungen schreiben – oder Ihren Konkurrenten dabei zusehen, wie sie ihre eigenen Vorstellungen zusammenstellen.

Häufig gestellte Fragen

Was ist Pinecone Nexus und wie unterscheidet es sich vom regulären RAG?

Pinecone Nexus ist eine Wissens-Engine für AI-Agenten, die die Arbeit des Abrufs von der Abfragezeit auf die Kompilierungszeit verlagert. Anstatt bei jeder Abfrage Rohblöcke abzurufen, kompiliert Nexus aufgabenspezifische strukturierte Artefakte bei der Aufnahme mit einem Kontext-Compiler vor und Agenten fragen diese Artefakte über KnowQL – die deklarative Abfragesprache von Pinecone – in einem einzigen Tool-Aufruf ab. Regulärer RAG ruft bei Bedarf ab. Nexus erledigt die Abrufarbeit im Voraus. Die vollständige Aufschlüsselung der Architektur finden Sie oben in der exemplarischen Vorgehensweise zum Workflow.

Was ist KnowQL und warum ist es für AI-Agenten wichtig?

KnowQL ist die deklarative Abfragesprache von Pinecone für Agenten mit sechs Grundelementen: Absicht, Filter, Herkunft, Ausgabeform, Konfidenz und Budget. Dies ist wichtig, weil es Agenten ein Vokabular für den Wissenszugriff bietet, das der Argumentation der Agenten entspricht – indem es benutzerdefinierte Tooldefinitionen und maßgeschneiderten Retrieval-Glue-Code durch einen einzigen deklarativen Aufruf ersetzt. KnowQL ist für Agenten das, was SQL für Datenbanken war.

Wird Pinecone Nexus den Agenten RAG vollständig ersetzen?

Nein. Kompilierte Wissensebenen wie Nexus glänzen durch wiederholbare, genau spezifizierte Abfragen anhand stabiler Daten. Agentic RAG bleibt das richtige Werkzeug für explorative Arbeiten und Long-Tail-Fragen, bei denen die Frageform im Voraus unbekannt ist. Die Architektur, die im Jahr 2026 gewinnt, ist hybrid: zusammengestelltes Wissen für hochwertige, Governance-kritische Workloads, Agent RAG für die Erkundung.

Wie vergleichen sich Pinecone Nexus, Karpathy's LLM Wiki und Microsoft Fabric IQ?

Alle drei bewegen die Strukturierungsarbeit vor dem Agenten, jedoch auf unterschiedlichen Ebenen. Das LLM-Wiki von Karpathy basiert auf Markdown-First und Infrastruktur-Light, ideal für persönliche Wissensdatenbanken mit weniger als 400.000 Wörtern. Fabric IQ Ontology erstellt einen expliziten, von Menschen kuratierten Graphen für die Unternehmensführung. Pinecone Nexus verwendet einen autonomen Kontext-Compiler, der für Evaluierungssätze optimiert ist und zwischen dem manuellen Ansatz von Fabric IQ und dem einfachen Ansatz von LLM Wiki angesiedelt ist.

Welche Risiken birgt der Wechsel von der Agentenschicht RAG zu einer kompilierten Wissensschicht?

Vier Hauptrisiken: Kosten für die Neukompilierung von Artefakten bei flüchtigen Daten, zur Kompilierungszeit eingeführte LLM-Halluzinationen, die sich auf jede nachgelagerte Abfrage ausbreiten, unklares Fallback-Verhalten für Abfragen, die der Compiler nicht vorhergesehen hat, und erhebliche Rechenkosten zur Erstellungszeit, die in Vanilla RAG nicht vorhanden waren. Zusammengetragenes Wissen gewinnt durch stabile Daten mit wiederholbaren Abfragen. Es hat Probleme mit Hochgeschwindigkeitsdaten und explorativen Arbeitslasten.

Lasst uns zusammenarbeiten

Möchten Sie AI-Systeme aufbauen, Arbeitsabläufe automatisieren oder Ihre technische Infrastruktur skalieren? Ich würde gerne helfen.

• Fiverr (benutzerdefinierte Builds und Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Unternehmenslösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienste): xcybersecurity.io