Harness ist bereits sehr präzise, warum wird dann noch eine Agent Native Database benötigt?
RAG steht an einem Scheideweg
Retrieval Augmented Generation (RAG) ist in den letzten zwei Jahren fast zum „Standard“ für die Implementierung von großen Sprachmodellen in unternehmensweiten Wissensszenarien geworden. Durch die Kombination der Abfrage externer Wissensdatenbanken mit generativen Modellen verbessert es die Aktualität und Genauigkeit der generierten Inhalte erheblich und senkt die Halluzinationsrate drastisch. Diese Logik klingt unangreifbar: Was das Modell nicht weiß, wird sofort nachgeschlagen, und erst nach dem Finden der Informationen wird die Antwort erstellt.
Aber die Realität ist weitaus komplexer als die Logik.
Wenn eine große Anzahl von Unternehmen RAG tatsächlich in die Produktivumgebung übernimmt, bildet sich eine frustrierende gemeinsame Erkenntnis heraus: RAG ist gut, aber bei weitem nicht gut genug. Das einfache RAG – die Standardpipeline, die Dokumente in Stücke zerlegt, vektorisiert und dann die Ähnlichkeit berechnet – scheitert in praktischen Szenarien immer wieder. Wie legt man die Strategie für die Stückenaufteilung fest? Welches Embedding-Modell verwendet man? Welchen Schwellenwert für die Ähnlichkeit setzt man? Jeder Schritt erfordert eine umfangreiche Parameterabstimmung, und selbst nach der Abstimmung kann die Qualität der Abfrage nicht garantiert werden. Die abgerufenen Textabschnitte stehen in keinem Zusammenhang mit der Antwort, und wenn Störfaktoren in den Kontext gelangen, stören sie den Schlussfolgerungsprozess des LLM stattdessen.
Daraus entstand das erweiterte RAG, zum Beispiel die DeepDoc-Parsing-Funktion von RAGFlow für PDF, verschiedene erweiterte Chunker, Hybrid Search, die Wissensgraph-Erweiterung von GraphRAG, der rekursive Zusammenfassungsbaum von RAPTOR, die kontextbewusste Stückenaufteilung von Contextual Retrieval … Der Technologie-Stack wird immer komplexer, die Architekturdiagramme werden immer ansprechender, aber die Verbesserung der Effekte entspricht nicht der Zunahme der Komplexität. Komplexität führt nicht zu besseren Ergebnissen.
Im Jahr 2026 haben zwei Schlüsselereignisse diese Diskussion auf ein neues Niveau gehoben.
Das erste Ereignis: Andrej Karpathy hat das Konzept des „LLM Wiki“ vorgeschlagen. Er plädiert dafür, ursprüngliche Notizen als Ausgangsmaterial zu betrachten und sie mithilfe von LLM in ein ständig aktualisiertes Wiki mit klaren Zitaten und wörtlich lesbaren Inhalten zu kompilieren – nicht bei jeder Frage vorübergehend einige ähnliche Abschnitte zusammenzufügen, sondern „Wissen einmal zu kompilieren und dann auf dem neuesten Stand zu halten, anstatt bei jeder Abfrage neu abzuleiten“. Diese Idee ist schnell aus dem Bereich des persönlichen Wissensmanagements in den Bereich des unternehmensweiten RAG übergegangen und hat eine weitverbreitete Infragestellung des traditionellen RAG-Paradigmas ausgelöst.
Das zweite Ereignis: Der Forschungsbericht von PwC US stellt eine Frage mit einem provokanten Titel – „Is Grep All You Need?“. Die Forscher haben dem Agenten sowohl die Vektorsuche als auch Grep zur Verfügung gestellt und festgestellt, dass Grep (genaue Zeichenfolgenübereinstimmung) oft eine höhere Genauigkeit liefert als die semantische Suche. Weitere vergleichende Experimente zeigen, dass die Qualität des Agentic RAG, das nur durch Zeichenfolgenübereinstimmung realisiert wird, bereits sehr nah an der des LLM-Compiled Wiki liegt.
Diese beiden Ereignisse führen gemeinsam zu einem Schluss: Das Paradigma des traditionellen RAG „Abfrage → Übereinstimmung → Sortierung“ wird umgestoßen. Der Kern der Abfrage verschiebt sich von „die Entwicklung eines stärkeren Rückrufalgorithmus“ hin zu „die Gestaltung eines Entscheidungsrahmens, der dynamisch zwischen mehreren Tools orchestriert werden kann“. Die Suche ist nicht mehr eine Engine, sondern ein Harness (Steuerungsrahmen).
Aber obwohl Harness + Grep einen äußerst starken Ausgangswert (Baseline) darstellen, ist es nicht das Ende. Wenn der Datenumfang zunimmt, führt die vollständige Abhängigkeit von der iterativen Erkundung des Harness und der genauen Übereinstimmung von Grep dazu, dass der Agent wiederholt suchen muss, um den Antwortbereich zu finden – hoher Token-Verbrauch, langsame Antwortgeschwindigkeit, und jedes neue Kontextfenster muss den Erkundungsprozess erneut durchlaufen.
Genau hier setzt das Wissenskompilieren ein. Die Kernaussage dieses Artikels lautet: Der Search Harness ist die Engine des Agentic Search; das Wissenskompilieren ist seine Kontextversorgungsebene. Das Wissenskompilieren soll Search/Grep nicht ersetzen, sondern dem Harness reichere, stärker komprimierte und nachvollziehbare Wissensartefakte liefern, sodass der Agent die Antwort mit weniger Iterationen und geringerem Token-Verbrauch präzise lokalisieren kann.
Vierfaches Dilemma von RAG
Um den Wert des Wissenskompilierens zu verstehen, muss man zuerst das tatsächliche Dilemma erkennen, mit dem RAG heute konfrontiert ist. Diese Dilemmata sind keine Mängel eines einzelnen Produkts, sondern strukturelle Probleme auf der Ebene des gesamten Paradigmas.
Dilemma 1: Einfaches RAG – „ungenaue Suche“ ist sein Schicksal
Das Wesen des einfachen RAG ist der einzelne Pfad „Abfrage → Einbettung → Ähnlichkeitssortierung“. Bei ursprünglichen Dokumenten ist die Ähnlichkeit fast der einzige Zugangspunkt. Aber das Problem lautet: Ähnlich bedeutet nicht relevant, und relevant bedeutet nicht korrekt.
Bei einer genauen Datumsabfrage (z. B. „Wie hoch war der Umsatz im dritten Quartal 2025?“) führt die Vektorsuche nur zu einer großen Menge an semantisch ähnlichem, aber völlig irrelevantem Rauschen. Bei einer unscharfen konzeptuellen Frage (z. B. „Was ist der Kerngedanke des Microservice-Architektur?“) findet Grep überhaupt keine relevanten Abschnitte – denn niemand schreibt in Dokumenten genau den Satz, der mit Ihrer Abfrage identisch ist. Manchmal befindet sich die Antwort nicht in einem einzelnen Dokumentenstück, sondern man muss zuerst eine Gruppe von Kandidatendokumenten lokalisieren und dann jedes einzelne gründlich durchlesen.
Ein einzelner Pfad kann verschiedene Arten von Abfragen nicht abdecken. Dies ist ein struktureller Mangel des einfachen RAG, der nicht durch Parameterabstimmung behoben werden kann.
Dilemma 2: Erweitertes RAG – „Komplexität führt nicht zu besseren Ergebnissen“
Das erweiterte RAG versucht, die oben genannten Probleme durch die Einführung komplexerer Architekturen zu lösen. GraphRAG nutzt Wissensgraphen zur Erweiterung der Abfrage, RAPTOR organisiert Dokumente mit rekursiven Zusammenfassungsbäumen, Contextual Retrieval verwendet eine kontextbewusste Strategie für die Stückenaufteilung … Jede Lösung hat ihre eigenen Papers, ihre eigenen Benchmarks und ihre eigenen Anhänger.
Aber das Problem liegt darin: Die Bereitstellungs- und Wartungskosten dieser Lösungen steigen sprunghaft an, während die Effektverbesserung bei weitem nicht die Erwartungen erfüllt. GraphRAG verwendet fragmentierte graphenartige Strukturen als Hauptquelle für die Abfrage, und nach dem Verbrauch einer großen Menge an Token gibt es keine grundlegende Verbesserung der Abfrageergebnisse – es gibt nur Verbesserungen in einigen Szenarien mit mehrstufigen Fragen und Antworten. Noch schlimmer: Diese komplexen Lösungen machen das System oft schwer erklärbar, schwer zu debuggen und schwer zu warten.
Ein RAG-System, das nur von Experten optimiert werden kann, ist in der realen unternehmensweiten Produktivumgebung nicht haltbar.
Dilemma 3: Herausforderungen von Agent Harness + Grep
Die Forschung von PwC hat ergeben, dass wenn der Agent sowohl mit Vektorsuche als auch mit Grep ausgestattet ist, Grep oft eine höhere Genauigkeit liefert als die semantische Suche. Diese Erkenntnis wurde in der Branche schnell zu einem provokanten Schluss vereinfacht: „Grep ersetzt RAG“.
Aber vergleichende Experimente mit Vector RAG zeigen, dass die alleinige Abhängigkeit von Grep nicht in allen Szenarien besser als RAG ist. Der genauere Schluss sollte lauten: Ein gut gestalteter Agent Harness kann selbst mit einfachen Tools wie Grep in vielen Szenarien Ergebnisse erzielen, die nahe an denen des komplexen RAG liegen oder diese sogar übertreffen. Dies stellt eine grundlegende Herausforderung für die Annahme dar, dass „RAG auf komplexe Abfragearchitekturen angewiesen sein muss“.
Aber obwohl Harness + Grep einen äußerst starken Ausgangswert darstellen, ist es nicht das Ende. Wenn der Datenumfang zunimmt, führt die vollständige Abhängigkeit von der iterativen Erkundung des Harness und der genauen Übereinstimmung von Grep dazu, dass der Agent wiederholt suchen muss, um den Antwortbereich zu finden – die Anzahl der Iterationen steigt linear an, und der Token-Verbrauch steigt exponentiell an. Genau hier muss das Wissenskompilieren einspringen.
Dilemma 4: Das „Kaltstart“-Problem von RAG – das tiefste Problem
Dies ist das tiefste Problem und auch der Pain Point, den Karpathys Konzept des „LLM Wiki“ genau trifft.
Die Arbeitsweise des traditionellen RAG ist, bei jeder Abfrage von Grund auf neu zu beginnen. Der Benutzer stellt eine Frage, das System vektorisiert die Frage, ruft ähnliche Dokumentenstücke in der Vektordatenbank ab, fügt die Abfrageergebnisse in das Prompt ein, und das LLM generiert die Antwort – dann wird alles zurückgesetzt. Bei der nächsten Abfrage wird der gleiche Ablauf wiederholt. Keine Akkumulation, kein Zustand, kein kognitives Fundament, das sich kontinuierlich weiterentwickeln kann.
Jede Abfrage ist ein „Kaltstart“. Jedes Mal muss das System erneut „verstehen“, was sich in der Wissensdatenbank befindet, welche Beziehungen zwischen den Dokumenten bestehen und welche Quellen autoritativ sind. Wenn dieselbe Aufgabe zweimal mit denselben Daten ausgeführt wird, kann der Agent unterschiedliche Antworten zurückgeben, und es gibt keine Aufzeichnung, woher die Unterschiede zwischen den beiden Ergebnissen stammen.
Die Schätzung von Pinecone zeigt, dass 85 % der Rechenleistung des Agenten im Zyklus des „Wiederentdeckens“ verbraucht werden, statt die eigentliche Aufgabe zu erledigen. Dies ist kein Bug von RAG, sondern ein Paradigmenfehler von RAG. Das Wissenskompilieren ist genau die systematische Antwort auf diesen Mangel: Es verlagert einen Teil der „Verstehens“-Arbeit von der Abfragezeit auf die Indexzeit, sodass der Search Harness nicht jedes Mal von Grund auf neu beginnen muss.
Der Aufstieg von Grep und die Grenzen des Harness
In Kapitel 2 haben wir das vierfache Dilemma von RAG gesehen, von dem das dritte besonders nachdenkenswert ist: Ein einfaches Grep-Tool kann unter der Orchestrierung des Agenten Ergebnisse erzielen, die nahe an denen des komplexen RAG liegen oder diese sogar übertreffen. Diese Erkenntnis stürzt die traditionelle Vorstellung der Branche, dass „Abfrage auf semantisches Verständnis angewiesen sein muss“, um, wirft aber auch neue Fragen auf – wo liegen die Grenzen von Harness + Grep? In diesem Kapitel werden wir eingehend analysieren, warum Grep wirksam ist, welche Rolle das Harness spielt und wie die Einschränkungen dieser Kombination uns zum Wissenskompilieren führen.
3.1 Warum kann Grep RAG besiegen?
Die Antwort auf die Frage „Is Grep All You Need?“ ist weitaus komplexer, als es auf den ersten Blick scheint.
Die Forscher von PwC haben dem Agenten sowohl die Vektorsuche als auch Grep zur Verfügung gestellt und festgestellt, dass Grep oft eine höhere Genauigkeit liefert als die semantische Suche. Diese Erkenntnis lässt sich leicht zu „genaue Übereinstimmung reicht aus“ vereinfachen – aber die wahre Einsicht liegt in der Schlussfolgerung am Ende des Papers: Bei der Abfrage geht es nicht einfach darum, Wissen an den Agenten zurückzugeben. Wichtig ist der Rahmen – er bestimmt, was in den Kontext eingefüllt werden kann und welche Aktionen der Agent ausführen muss, bevor er den Kontext nutzt.
Mit anderen Worten: Was Grep stark macht, ist nicht das Tool selbst, sondern wie der Agent es orchestriert.
Das zwingt uns, zwei grundverschiedene Arten von Problemen zu unterscheiden:
• Semantisches Entdeckungsproblem: Die Antwort ist auf konzeptueller Ebene verborgen und erfordert semantisches Verständnis, um gefunden zu werden
• Beweislokalisierungsproblem: Die Antwort liegt in wörtlichen Beweisen – Namen, Daten, Dateipfade, Funktionsnamen, Fehlerzeichenfolgen
Für einen Coding-Agenten gehört ein großer Teil der Arbeit genau zur Beweislokalisierung: Suchen von Symbolen, Verfolgen von Aufrufkettengliedern, Prüfen von Abweichungen, Lesen fehlgeschlagener Testfälle, Lokalisieren genauer Codezeilen. In diesem Fall ist ein Tool zur genauen Zeichenfolgenübereinstimmung weitaus direkter und wirksamer als die semantische Suche.
Es ist bemerkenswert, dass die Art und Weise, wie der Agent Grep verwendet, völlig anders ist als die von Menschen. Die Analyse des Suchverhaltens von OpenAI für GPT-5 auf dem BrowseComp-Plus-Datensatz zeigt: 98 % der Sitzungen verwenden die Anführungszeichen-Suche (weit höher als bei menschlichen Benutzern), und der Median der Abfragelänge überschreitet das 99. Perzentil der menschlichen Benutzer. KI ist bei der Verwendung genauer Übereinstimmungen „präziser“ und „strukturierter“ als Menschen – sie kann auf einmal komplexe Abfragen mit mehreren Einschränkungen erstellen, die Menschen kaum eingeben würden. Grep selbst hat sich nicht geändert, aber sein Benutzer hat sich von Menschen zu Agenten gewandelt, und die Verwendungsweise hat sich qualitativ verändert.
3.2 Einschränkungen von Harness + Grep: Erkundungskosten und Token-Kosten
Aber obwohl Harness + Grep einen äußerst starken Ausgangswert darstellen, ist es nicht das Ende. Der Grund liegt darin:
Wenn der Datenumfang zunimmt, führt die vollständige Abhängigkeit von der iterativen Erkundung des Harness und der genauen Übereinstimmung von Grep dazu, dass die Kosten für wiederholte iterative Erkundungen des Harness stark steigen. Der Agent muss wiederholt Grep ausführen, um den Antwortbereich zu finden, was zu zwei schwerwiegenden Folgen führt:
1. Langsam: Jeder Grep-Vorgang ist eine E/A-Operation, und die lineare Zunahme der Anzahl von Iterationen führt zu einem starken Anstieg der Antwortzeit
2. Hoher Token-Verbrauch: Bei jeder Iteration werden die Suchergebnisse in den Kontext geladen, und die akkumulierte Token-Menge bei mehreren Iterationen ist enorm
Bei jedem neuen Kontextfenster verschwendet das Harness-zentrierte Agentic Retrieval Aufrufe, um immer wieder neu zu lernen, welche Suchstrategien wirksam sind. Das ist sowohl teuer als auch langsam.
Daher ergibt sich eine natürliche Frage: Wie kann man die Erkundungspfade des Harness verkürzen und gleichzeitig seine Orchestrierungsfähigkeit behalten?