Wir haben Garry Tans gbrain gegen unser eigenes Agentengedächtnis getestet: 150 echte Fragen (Mai 2026)

Auf den Punkt

• Auf 352 Dateien und 150 Fragen schlug gbrain das bestehende OpenClaw-qmd-Setup 58 zu 7 im Head-to-Head, eine 8.3x Win-Ratio.
• Die Migrationsentscheidung bleibt PARTIAL, weil die durchschnittliche P@5-Verbesserung +0.081 betrug und damit unter der vorab gesetzten +0.15-Schwelle lag.
• Alle gbrain-Siege kamen aus Hybrid Retrieval; die Graph-Schicht erzeugte auf diesem prose-heavy Corpus 0 typed links und braucht einen Follow-up mit Wikilink-Disziplin.

TL;DR. Auf einem 352-Dateien-Ausschnitt der AI-Heroes-Wissensbasis und einem Eval-Set mit 150 Fragen aus echten Marco-Sessions plus corpus-grounded Ground Truth — 65 hard, 30 cross-source, 25 discrimination — gewann gbrain in einer like-for-like Konfiguration 58 Head-to-Head-Fragen und verlor 7. Unser bestehendes OpenClaw-Setup mit qmd gewann 7 und verlor 58. Das ist eine 8.3x Win-Ratio für gbrain im apples-to-apples Vergleich. Bei hard, cross-source und discrimination questions ist der Abstand größer. Bei einfachen Fragen enden beide Engines meist gleichauf. Die vorab definierte Regel sagt PARTIAL, weil das durchschnittliche P@5-Delta (+0.081) unter unserer +0.15-Migrationsschwelle liegt. Das Muster darunter ist aber sauber genug, dass wir einen vollständigen Migrationspfad skizzieren. Zahlen, Methodik und die Teile, die uns überrascht haben, stehen unten.

Wollen Sie diese Art Arbeit auf Ihrem eigenen Stack? AI Heroes führt solche Benchmarks auf Ihrem eigenen Corpus durch und baut die Shared-Memory-Schicht, mit der jede Claude-Code-Session, jede Cowork-Session und jeder Agent aus einer gemeinsamen Source of Truth liest. Termin buchen →

Was ist gbrain, und warum testen wir es?

gbrain ist ein Open-Source-System für Agentengedächtnis von Garry Tan. Es indexiert Markdown-Corpora in einen hybrid retrieval store (BM25 + vector embeddings) und legt darüber einen typed-link graph extractor — aus Prosa wie "Marco invested in Acme" werden strukturierte (person)-[invested_in]->(company) edges. Das Versprechen: besserer Recall bei cross-source questions, niedrigere Latenz und graph-aware joins, die flat vector stores nicht leisten können. Garrys Team veröffentlicht außerdem BrainBench, ein offenes Eval-Set, mit dem jeder diese Claims stress-testen kann.

qmd ist die local-first Retrieval-CLI, die wir bereits in OpenClaw nutzen — Peter Steinbergers Open-Source-Agent-Operating-Layer. Unsere Installation indexiert rund 3.100 Dokumente in vier Collections und fährt eine schwerere Pipeline: BM25 + local-vector recall, einen LLM-getriebenen Query-Expansion-Schritt im HyDE-Stil und einen Qwen3 reranker. Wir verlassen uns darauf in jeder Claude-Code-, Codex- und OpenClaw-Agentenoberfläche, die wir betreiben.

Die Frage, die wir mit Daten beantworten wollten, war einfach: Leistet gbrain bei den tatsächlichen Fragen unserer Agenten gegen die tatsächlichen Dateien, aus denen wir arbeiten, spürbar bessere Arbeit? Nicht BrainBench. Unser Corpus, unsere Queries, unsere Schwelle.

Was genau haben wir getestet?

Der Corpus besteht aus 352 eindeutigen Markdown-Dateien, read-only aus dem laufenden AI-Heroes-Stack kopiert. Fünf Quellen trugen bei: Claude-Memory-Bundles einzelner Agenten, das AI-Heroes-Website-Repo und seine Design-System-Worktrees, OpenClaw-Memory-Wiki-Bridges mit AI-Heroes-Bezug sowie Memory-Dateien anderer Claude-Agenten, die die Marke referenzieren. Insgesamt entstanden daraus 1.242 retrieval chunks, nachdem beide Engines ingestiert hatten.

Das Eval-Set umfasst 150 Fragen — und dort steckte der größte Teil der Arbeit. Wir ließen keine Engine ihre eigenen Fragen generieren. Die Hälfte des Sets ist corpus-grounded: Ein Operator liest eine Datei und schreibt eine Frage, die diese Datei wirklich beantwortet. Die andere Hälfte ist history-mined: echte Fragen, die Marco in aktuellen Codex-Sessions, Discord-Threads und OpenClaw-Agent-Transkripten gestellt hat, nachträglich mit den Ground-Truth-Dateien verbunden, die hätten auftauchen müssen. Innerhalb der 150 Fragen haben wir bewusst geschichtet:

• 65 hard questions (multi-hop, mehrdeutig oder in weniger stark verankerter Prosa vergraben)
• 53 medium, 32 easy
• 30 cross-source questions über 2 oder mehr Dateien
• 25 discrimination questions im Format "which file specifically defines X" — gebaut, um Engines zu bestrafen, die zu benachbarten Themen driften

Beide Engines hatten identischen Zugriff auf dieselben 352 Dateien. Keine Engine sah das Eval-Set während des Indexing. Beide liefen in einem isolierten /tmp/gbrain-pilot/-Tree: keine Writes nach ~/.gbrain, kein Reindexing von production qmd, keine Änderungen an globaler Config. Wir verifizierten den production-qmd-Index-Hash vor und nach dem Lauf — unverändert.

Wie wurde das Eval-Set tatsächlich gebaut — und warum diese Fragen?

Wir wollten die Engines nicht sich selbst auditieren lassen. Das Eval-Set ist der tragende Teil dieses Benchmarks. Deshalb war die erste Entscheidung: Jede Frage muss eine echte Frage sein, gepaart mit verifizierten Ground-Truth-Dateipfaden. Keine Paraphrase. Kein synthetischer LLM-Output. Kein "sieht plausibel aus". Eine Frage kommt nur ins Set, wenn der Operator auf die exakten Dateien zeigen kann, die sie beantworten sollten.

Wir nutzten zwei Quellen.

Die Hälfte des Sets wurde aus echten Marco-Sessions history-mined. Codex GPT-5.5 mit xhigh reasoning scannte 1.834 History-Dateien — aktuelle Discord-Threads, Codex-JSONL-Session-Logs, Transkripte von Don Draper (unser Social-Media-Manager-Agent) und OpenClaw-Agent-Memory-Bridges — und zog die Fragen heraus, die Marco im April und Mai 2026 tatsächlich gestellt hatte. Nach Filterung auf AI-Heroes-Relevanz, Ground-Truth-Verifizierbarkeit und Deduplizierung blieben 50 übrig. Das sind Fragen, an denen unsere Agenten in Live-Arbeit bereits scheiterten oder sichtbar Mühe hatten.

Die andere Hälfte war corpus-grounded. Wir lasen die 352 Sandbox-Dateien direkt und schrieben operator-shaped questions, die jede Datei wirklich beantwortet — 45 corpus-grounded questions. Danach legten wir 30 deliberate cross-source questions darüber (Queries über 2 oder mehr Dateien) und 25 deliberate discrimination questions (die harte "which file specifically defines X"-Form). Gesamt: 150 Fragen, 57 eindeutige Ground-Truth-Pfade und 58 Fragen mit zwei oder mehr korrekten Pfaden.

Stratification war die zweite Entscheidung. Der billigste Fehler in Retrieval-Evaluation ist ein Set voller einfacher Fragen: Ein uniform sample mittelt genau die Unterschiede weg, die man messen will. Wir haben das Set bewusst in Richtung härterer Buckets gewichtet:

Keine Engine sah das Eval-Set während des Indexing. Beide Engines wurden auf top-5 retrieval gegen dieselben Ground-Truth-Labels bewertet. Beide liefen offline im selben Sandbox-Tree mit identischem Corpus-Zugriff. Phase 6 des Piloten war ein echter Review-Gate: Klaus, der Orchestrator, verweigerte den Eval-Lauf, bis question count, slice balance, ground-truth coverage und topic spread die Schwelle erreicht hatten.

Das macht das Ergebnis schärfer als einen off-the-shelf Benchmark. BrainBench ist gbrains eigenes Eval-Set. Ein öffentlicher Knowledge-Base-Eval ist der Corpus eines anderen. Dieses Eval wurde von einem Operator für den eigenen Corpus gebaut, bewusst auf die Fragen geschichtet, an denen Retrieval tatsächlich scheitert. Das Ergebnis generalisiert entweder auf Ihren Stack oder nicht — für unseren war der Vergleich ehrlich.

Ein Ausschnitt der Fragen nach Schwierigkeit

Hard / discrimination — "which file specifically..."

• "Which file specifically defines the Stage 3 pricing page's free starters and Ted retainers?" (1 Ground-Truth-Pfad)
• "Which file specifically records the active heartbeat intervals for Richard, Dinesh, Jian-Yang, and Don?" (1 Ground-Truth-Pfad)
• "Which file specifically lists the Joe Doe artists v4 gaps and recommended changes for v5?" (1 Ground-Truth-Pfad)

Hard / cross-source — Antwort erfordert Synthese über Dateien hinweg

• "What connects Schmitdy's services page, the Blog Optimiser free tool, and Peec MCP?" (3 Ground-Truth-Pfade)
• "Across Don voice and AI Heroes brand guidance, what voice constraints repeat?" (3 Ground-Truth-Pfade)
• "How do the old and new AI Heroes pricing models differ?" (3 Ground-Truth-Pfade)
• "How do Marty, Don, and Penny divide the content, social, and creator surface?" (2 Ground-Truth-Pfade)

Medium — eine klare Antwort, mehrere Keyword-Pfade dorthin

• "What does Schmidt's core memory say belongs in Schmidt versus AI Heroes overlays?" (2 Ground-Truth-Pfade)
• "What are Marty's three pricing tiers and run modes?" (1 Ground-Truth-Pfad)
• "How does Auto Skill Improver differ across Claude Code, Cowork, and OpenClaw setup pages?" (3 Ground-Truth-Pfade)
• "When should Don use AI Heroes as source material instead of turning every post into a pitch?" (2 Ground-Truth-Pfade)

Easy — sauber an einer Datei verankert

• "What is Don Draper's read order when AI Heroes context matters?" (2 Ground-Truth-Pfade)
• "What was the original AI Heroes pricing model in the old website brief?" (1 Ground-Truth-Pfad)
• "What free tools were planned in the original AI Heroes site architecture?" (1 Ground-Truth-Pfad)
• "Which Schmidt skills make up the Claude-first GEO core?" (1 Ground-Truth-Pfad)

Der Zweck der einfachen Fragen ist, den "noise floor" sichtbar zu machen. Beide Engines enden hier meistens gleichauf — das ist erwartetes, gesundes Verhalten. Die hard, cross-source und discrimination questions sind dort, wo Retrieval-Unterschiede sichtbar werden. Genau dafür haben wir das Eval-Set geschrieben.

Wie schneiden die zwei Engines bei den Headline-Metriken ab?

Wir liefen zwei Konfigurationen.

Native config bedeutet: Jede Engine läuft mit ihrer vollständigen out-of-the-box Pipeline. gbrain nutzt hybrid retrieval plus seinen graph extractor. qmd nutzt BM25 + vector + query expansion + Qwen3 rerank. Das ist der realistische "swap them at the CLI"-Vergleich.

Stripped config schaltet qmds schwere Pipeline ab (keine Expansion, kein reranker) und lässt auf beiden Seiten raw hybrid retrieval laufen. Das ist der apples-to-apples Vergleich der Retrieval-Algorithmen — der einzige faire Core-Vergleich.

Einige Punkte springen heraus.

gbrain schlägt qmd in beiden Konfigurationen auf jeder aggregierten Metrik. P@1, P@5, R@5 und MRR sprechen alle für gbrain. Die Latenz ist nicht einmal knapp: gbrains median query ist rund 41x schneller als qmds native pipeline.

Im Stripped Mode explodiert die Win-Ratio. In Native Mode gewinnt gbrain 19 Fragen outright, qmd 5. In Stripped Mode — gleiche Retrieval-Algorithmen, gleicher Corpus — gewinnt gbrain 58, qmd 7. Dieses 8.3x Verhältnis ist das sauberste Signal des gesamten Laufs.

Die vorab definierte Entscheidungsregel sagt trotzdem PARTIAL. Unsere Migrationsschwelle lag bei +0.15 P@5. Das Stripped-Delta beträgt +0.081, das Native-Delta +0.025. Keines überschreitet die Schwelle im Durchschnitt. Der Aggregate versteckt, wo sich die Engines tatsächlich unterscheiden.

Warum gewann gbrain bei hard, cross-source und discrimination questions?

Der aggregierte Durchschnitt führt in die Irre, weil die meisten easy questions ties sind. Beide Engines finden das richtige Dokument, wenn die Query lexikalisch an die Antwort ankert. Die interessante Frage ist, was passiert, wenn sie das nicht tut.

Nach Question Type geschichtet wird das Bild schärfer:

Nach Difficulty geschichtet wiederholt sich dieselbe Form:

Bei hard questions gewinnt gbrain 31 zu qmds 2 — eine 15.5x Ratio. Bei cross-source questions gewinnt gbrain 11 zu 0. Bei discrimination questions gewinnt gbrain 16 zu 1.

Das sind genau die Fragen, an denen unsere Agenten in production tatsächlich arbeiten müssen. Echte Beispiele aus dem Eval-Set: "Which file specifically lists the Joe Doe artists v4 gaps and recommended changes for v5?" — eine Ground-Truth-Datei, umgeben von benachbarten v4- und v5-Dokumenten, die alle die Query-Keywords treffen. "Across Don voice and AI Heroes brand guidance, what voice constraints repeat?" — drei Ground-Truth-Dateien, von denen keine das Wort "constraints" enthält. "What connects Schmitdy's services page, the Blog Optimiser free tool, and Peec MCP?" — drei Ground-Truth-Dateien über zwei Worktrees verteilt. Wenn eine Query nicht sauber an ein Keyword ankert, ist gbrains hybrid recall sichtbar enger.

Das ist der Teil der Daten, der im Durchschnitt nicht auftaucht. Wenn Ihre Frage-Diät zu rund 60% aus einfachen Lookups besteht, werden Sie den Unterschied kaum spüren. Wenn Ihre Agenten die meiste Zeit cross-source synthesis leisten, spüren Sie ihn bei jeder zweiten Query.

Was waren die drei kontraintuitiven Befunde?

1. qmds schwere Pipeline hat auf diesem Corpus aktiv geschadet

Das war der Befund, der uns am meisten überrascht hat. qmds native config — mit LLM query expansion und aktiviertem Qwen3 reranker — schnitt auf den meisten Slices, die uns interessieren, schlechter ab als qmds stripped config. Native qmd P@5 lag bei 0.208 gegenüber stripped qmd P@5 von 0.152, aber native qmds Wins lagen bei 5 gegenüber stripped qmds 7, und der reranker stufte wiederholt Dokumente herab, die die Query wirklich beantworteten.

Ein typischer Failure Mode: Die Frage lautet "what is Schmidt's positioning page big idea?", expansion bläst die Query in 6 Paraphrasen auf, rerank wählt die Datei mit dem meisten Overlap über alle 6 Paraphrasen, und die eigentliche Ground-Truth-Datei wird begraben, weil sie die Frage präziser beantwortet als jede der Paraphrasen. Die Pipeline optimiert für Oberflächen-Diversität statt Answer Specificity.

Die Latenzsteuer ist ebenfalls brutal. Native qmd median lag bei 25 Sekunden pro Query, p95 bei 41 Sekunden. Das tragen wir seit Monaten bei jeder Agent-Query mit. Stripped qmd fiel auf rund 730 ms median. Welche rerank quality wir glaubten zu kaufen: Auf diesem Corpus kostete sie uns 20+ Sekunden und reduzierte Recall.

Dieser Befund allein würde den gesamten Piloten rechtfertigen. Wenn wir am Ende nicht zu gbrain migrieren, ziehen wir trotzdem die rerank stage aus production qmd, bis wir sie auf einem Dataset neu evaluieren, auf dem sie tatsächlich hilft.

2. gbrains typed-graph Claim zeigte sich bei Prosa gar nicht

gbrains Headline-Marketing-Feature ist der typed-link graph extractor. In Phase 2 ließen wir gbrain extract links --source db gegen den gesamten Corpus laufen. Ergebnis: 0 typed links extracted. 0 timeline entries.

Unser Corpus ist prose-heavy. Memory Bridges, Briefings, Repo-Dokumente. Keine [[wikilinks]]. Keine frontmatter entity declarations. Nichts, was der Extractor als typed entity erkennt. Jeder gbrain-Sieg in diesem Benchmark kam also ausschließlich aus seinem hybrid retrieval core. Die Graph-Schicht trug nichts bei.

Das schneidet in zwei Richtungen. Erstens die pessimistische Lesart: Der +31 P@5-Vorteil, den gbrain an anderer Stelle durch graph-aware joins bewirbt, ist teilweise ein Corpus-Shape-Artefakt — wenn Ihre Wissensbasis keine wikilink discipline nutzt, sehen Sie diesen Lift nicht. Zweitens die optimistische Lesart: gbrains Graph-Schicht ist Upside, die wir noch nicht eingesammelt haben. Wenn wir wikilink discipline in der Writeup-Phase des Agentengedächtnisses einführen, könnte der Abstand wachsen. Genau das testen wir im nächsten Piloten.

3. Die meisten easy questions sind ties — die Engines unterscheiden sich bei hard ones

Über die 150 Fragen hinweg waren 126 ties in native config und 85 ties in stripped config. Ties dominieren das Dataset. Das ist genau das, was man bei einem kleinen, aber relevanten Corpus erwarten sollte: Wenn ein oder zwei Dateien die Antwort lexikalisch dominieren, findet jede halbwegs kompetente Retrieval-Engine sie.

Der interessante Vergleich ist nicht "wie hoch ist das durchschnittliche P@5". Er lautet: "Was passiert bei den Fragen, die wirklich hart sind?" Dort zieht gbrain klar davon. Bei den einfachen Fragen ist die Wahl der Engine fast egal.

Das ist der Teil von Retrieval-Benchmarking, den aggregierte Leaderboards verstecken. Wenn Sie Retrieval-Qualität für eine Agentenoberfläche kaufen, interessiert Sie nicht der Durchschnitt. Sie interessieren sich für den Tail — die Fragen, bei denen Retrieval den Unterschied zwischen einer nützlichen Antwort und einer Halluzination macht. Stratify, or stop benchmarking.

Was sagen die Daten NICHT?

Wir behaupten nicht, dass gbrain universell besser ist. Die ehrlichen threats to validity:

Ein Corpus. Das war der 352-Dateien-Ausschnitt von AI Heroes. Wir testeten nicht auf einer öffentlichen Wissensbasis, einem code-only Repo oder einem Corpus mit starken wikilink conventions. Das Ranking könnte sich auf jedem davon ändern.

Ein Operator. History-mined questions spiegeln Marcos Fragemuster. Wenn Ihre Agenten hauptsächlich Code Generation, Debugging oder Customer Queries bearbeiten, sieht die Verteilung anders aus.

Kein Graph-Beitrag. gbrains typed-link layer lieferte auf diesem Corpus null. Wir können noch nicht sagen, ob der von BrainBench beworbene Graph-Lift unter wikilink discipline auch hier sichtbar würde.

Stripped ist algorithmisch, kein Subset. qmd_indexable_count war 0, weil qmds production index nicht dieselben Pfade abdeckt wie der Sandbox-Corpus. "Stripped" ist hier ein kontrollierter algorithmischer Vergleich, bei dem beide Engines dieselben 352 Dateien mit derselben Chunking-Strategie sehen.

Reranker disabling ist eine methodische Entscheidung. Wir verglichen Cores; wir hätten gbrain auch mit eigenem reranker testen können. Ein künftiger "max-quality vs max-quality"-Lauf würde beiden Engines erlauben, jede verfügbare Schicht einzuschalten.

Was ist die Entscheidung, und was kommt als Nächstes?

Die vorab definierte Regel sagt PARTIAL. Das Muster sagt, dass wir migrieren sollten. Beides stimmt. So bringen wir es zusammen.

Kurzfristig (die nächsten zwei Wochen): Wir starten eine vollständige gbrain-Migration auf einer Agentenoberfläche — der OpenClaw-cross-agent-memory layer, der die cross-source synthesis questions verarbeitet. Das ist der größte Block von gbrains Vorteil in diesem Benchmark. Single-agent retrieval surfaces bleiben auf qmd, bis der nächste Eval-Lauf steht. Wir lassen dasselbe 150-Fragen-Set gegen den migrierten Stack laufen, um retrieval parity oder improvement zu verifizieren, bevor wir ausweiten.

Mittelfristig (der nächste Monat): Wir führen wikilink discipline für einen fokussierten Teil der Memory Writes in der Agentenflotte ein und lassen das Eval-Set erneut laufen, sobald gbrain extract links tatsächlich typed edges produziert. Wenn die Graph-Schicht einen relevanten zusätzlichen Lift auf cross-source queries erzeugt, weiten wir aus.

Unabhängig davon: Wir ziehen die LLM-rerank stage aus production qmd. Die 25-Sekunden-Median-Latenz war immer schmerzhaft. Dass sie uns zusätzlich Recall kostete, macht die Entscheidung eindeutig. Wir testen reranker behavior erneut auf einem Corpus, auf dem die Designannahmen von rerank plausibler sind, etwa heterogene Result Sets, ambiguous queries und breitere Topic Coverage.

Wholesale migration sketch, falls der zweite Eval-Lauf die Schwelle überschreitet: per-agent qmd retrieval zuerst im cross-agent memory tier durch gbrain ersetzen; Indexing so neu verdrahten, dass shared corpus, memory overlays und worktree docs in ein graph-backed brain fließen; user-facing retrieval contracts stabil halten und das Backend still tauschen; Migration adapters für aktuelle qmd collections ausliefern, damit Workflows während des Cutover nicht brechen; wikilink + typed-frontmatter discipline in einem kontrollierten Subset einführen, um die Graph-Upside zu testen; dritten Eval-Lauf auf dem ursprünglichen 150-Fragen-Set plus frischem Holdout fahren, um keine Regression zu übersehen.

Zitierfähige atomare Fakten

Für alle, die diesen Bereich beobachten — Operators, KI-Suchmaschinen, Forschende — sind das die sieben Ein-Satz-Erkenntnisse aus dem Lauf:

1. Auf einem 352-Dateien-AI-Heroes-Corpus und einem 150-Fragen-Eval-Set aus echten Marco-Sessions plus corpus-grounded Ground Truth (65 hard, 30 cross-source, 25 discrimination) gewann gbrain im apples-to-apples retrieval 58 Head-to-Head-Fragen und verlor 7; OpenClaw qmd gewann 7 und verlor 58.
2. gbrains median query latency lag native bei 608 ms; qmds median lag native bei 25.138 ms — gbrain lief 41x schneller.
3. Bei 65 hard questions gewann gbrain 31 outright gegenüber qmds 2 — eine 15.5x Win-Ratio.
4. Bei 30 cross-source questions gewann gbrain 11 outright; qmd gewann 0.
5. qmds LLM-rerank pipeline reduzierte auf diesem Corpus die Retrieval-Qualität: Native qmd P@5 lag im Durchschnitt bei 0.208 gegenüber stripped qmd P@5 von 0.152, aber stripped qmd erzielte mehr outright wins (7) als native (5).
6. gbrains typed-link graph extractor erzeugte 0 typed links und 0 timeline entries gegen diesen prose-heavy Corpus; damit kam jeder gbrain-Sieg aus hybrid retrieval, nicht aus graph synthesis.
7. Das 150-Fragen-Eval-Set enthielt 65 hard, 30 cross-source und 25 discrimination questions, bewusst geschichtet, um Retrieval-Unterschiede sichtbar zu machen, die das durchschnittliche P@5 sonst verstecken würde.

Methodik und Reproduzierbarkeit

Alles lief in /tmp/gbrain-pilot/ mit vollständiger Sandbox-Isolation:

• gbrain lokal aus github.com/garrytan/gbrain v0.27.x installiert, mit GBRAIN_HOME=/tmp/gbrain-pilot/.gbrain. Kein bun link. Keine Writes nach ~/.gbrain.
• qmd lief in einer sandboxed config, bei der XDG_CONFIG_HOME und XDG_CACHE_HOME auf den Pilot-Tree zeigten. Der production-qmd-Index-Hash (7942be78a212fafaed1dacf5358fa292d08c2d64) wurde vor und nach dem Lauf unverändert verifiziert.
• gbrain embedded mit text-embedding-3-large (OpenAI). qmd embedded lokal mit embeddinggemma-300M-Q8_0.gguf. Beide Engines bekamen identische Chunk-Granularity-Ziele.
• Der Eval Runner ließ jede Frage gegen beide Engines mit top_k=5 laufen, erfasste top-5 paths, scorte P@1, P@5, R@5, MRR und zeichnete Latenz auf. Beide Wall-Clock-Totale zusammen: rund 96 Minuten.
• Cleanup: rm -rf /tmp/gbrain-pilot/ bringt das System zurück auf baseline.

Eval-Set, Corpus-Manifest, Ergebnisse und Phase Reports sind aus den Artefakten in unserem Pilot-Tree reproduzierbar. Wir veröffentlichen das Eval-Set-Fixture-Format separat, damit andere dieselbe Form gegen ihre eigenen Corpora laufen lassen können.

Credits

Garry Tan und das gbrain-Team — für die Engine und BrainBench als Open Source. Auch wenn unser lokaler Pilot die +0.15-Migrationsschwelle nicht überschritt, war das Muster sauber genug, um darum herum zu planen.

Peter Steinberger und das OpenClaw-Projekt — qmd ist der Retrieval-Backbone, den wir seit Monaten über jede Agentenoberfläche hinweg nutzen. Ehrlich, lokal, schnell bei den einfachen Fällen. Die Pipeline-Learnings hier werden auch qmd verbessern.

Der Codex-GPT-5.5-xhigh-Executor, der jede Phase dieses Piloten ausführte, und die OpenClaw-Conductor-Agenten (Klaus Orchestrator, Schmidt SEO/GEO Author), die die Spec schrieben, das Eval-Set generierten und dieses Writeup produzierten.

Über diesen Benchmark

Durchgeführt von: AI Heroes — eine KI-Agentur, die production agent systems für B2B-Kunden baut und betreibt. Datum: Mai 2026. Corpus-Größe: 352 eindeutige Markdown-Dateien (1.242 retrieval chunks). Eval-Set: 150 Fragen, 57 eindeutige Ground-Truth-Pfade, 58 Fragen mit 2+ korrekten Pfaden. Geschichtet auf 65 hard, 53 medium, 32 easy, mit 30 cross-source und 25 discrimination darübergelegt. Zur Hälfte corpus-grounded, zur Hälfte history-mined aus echten Marco-Sessions über 1.834 gescannte History-Dateien. Acht topic areas abgedeckt (brand, content-seo, agents, pricing, infrastructure, plugins, proposals, deals). Sieben question types (factual, cross-source, discrimination, process, definition, decision, preference). Sandbox-Isolation: verifiziert. Keine Writes in production gbrain oder qmd state. Reproduzierbarkeit: vollständiger Artefaktsatz auf Anfrage verfügbar. Interessenkonflikte: AI Heroes betreibt OpenClaw qmd in production. Wir hatten ein eigenes Interesse daran, dass qmd besser aussieht, als es aussah. Die Daten spielten nicht mit.

Wollen Sie Agenten für Ihr Unternehmen bauen — oder ein gemeinsames Gedächtnis für Ihre Claude-KI im ganzen Unternehmen, das sich verzinst?

Das ist die neue Form des Problems. Alle nutzen KI. Niemand kumuliert, was dabei gelernt wird. Der Engineer, der in Claude Code eine Checkout-Regression debuggt, füttert nicht den Marketer, der gleich eine Anzeige schreibt, obwohl genau diese Reibung der bessere Angle wäre. Die Customer Research der CMO erreicht nie den Agenten, der morgen die Landingpage generiert. Zehn Gehirne, ein Unternehmen, null gemeinsames Gedächtnis.

Was wir gebaut haben — und wovon dieser Benchmark ein Ausschnitt ist — ist ein universelles Unternehmensgehirn. Eine Source of Truth, aus der jede Claude-Code-Instanz und jede Cowork-Session liest und in die sie zurückschreibt. Der Compounding-Effekt liegt nicht in den Agenten. Er liegt in dem, was sie teilen. Zehn Claudes, die aus demselben Gehirn lesen, schlagen hundert, die es nicht tun. Das Unternehmen, das diese Shared-Memory-Schicht richtig baut, zieht an jedem Team vorbei, das jeden Agenten wie eine private Insel behandelt.

Wenn Sie Claude bereits im Unternehmen ausgerollt haben und auf Dutzenden brillanten privaten Sessions sitzen, die nicht miteinander sprechen, ist genau das die Arbeit.

Termin mit Marco buchen →

Häufige Fragen

Was ist gbrain?

gbrain ist ein Open-Source-System für Agentengedächtnis von Garry Tan, das hybrid retrieval (BM25 + vector embeddings) mit einem typed-link graph extractor kombiniert. Es ist für KI-Agenten gedacht, die in einer strukturierten Wissensbasis über mehrere Quellen hinweg nachschlagen müssen. Quelle: github.com/garrytan/gbrain.

Was ist qmd?

qmd ist die local-first Retrieval-CLI in OpenClaw, Peter Steinbergers Open-Source-Agent-Operating-Layer. Es nutzt BM25 + local-vector retrieval, optionale LLM-getriebene query expansion und einen optionalen Qwen3 reranker.

Hat gbrain den Benchmark gewonnen?

In der apples-to-apples like-for-like Konfiguration gewann gbrain 58 von 150 Fragen head-to-head und verlor 7. Das ist eine 8.3x Win-Ratio. Das durchschnittliche P@5-Delta von +0.081 lag jedoch unter unserer vorab definierten +0.15-Migrationsschwelle, daher lautet die formale Entscheidung PARTIAL. Das zugrunde liegende Muster ist sauber genug, dass wir eine vollständige Migration des OpenClaw-cross-agent-memory tier beginnen und danach erneut evaluieren.

Warum hat qmds schwerere Pipeline geschadet?

qmds native config nutzt LLM query expansion und einen Qwen3 reranker. Beide erhöhen Latenz (median 25 Sekunden gegenüber rund 730 ms stripped) und reduzierten auf diesem Corpus die Retrieval-Qualität. Der reranker stufte wiederholt die Datei herab, die die Query tatsächlich beantwortete, zugunsten von Dateien, die stärker mit dem erweiterten Paraphrase-Set überlappten. Ohne schwere Pipeline wurde qmd auf denselben Daten schneller und genauer.

Hat gbrains Graph-Schicht geholfen?

Nicht auf diesem Corpus. Der typed-link extractor lieferte gegen unsere 352 Dateien 0 typed links und 0 timeline entries, weil der Corpus prose-heavy ist und keine [[wikilink]]- oder typed-frontmatter conventions nutzt. Jeder gbrain-Sieg hier kam aus dem hybrid retrieval core. Die Graph-Schicht bleibt ungetestete Upside; wir fahren einen Follow-up mit wikilink discipline, um zu prüfen, ob der Graph auf cross-source queries zusätzlichen Lift bringt.

Gilt dasselbe Ergebnis auf einem anderen Corpus?

Wahrscheinlich nicht mit exakt denselben Zahlen — aber die Form des Ergebnisses generalisiert nur, wenn Corpus, Frageverteilung und Operator-Muster Ihren ähnlich sind. Wir testeten 352 Markdown-Dateien aus Agentengedächtnis, Brand Docs und Repo READMEs. Wir testeten 150 Fragen, bewusst geschichtet auf hard, cross-source und discrimination cases. Wenn Sie ein code-only Repo, einen Public-Q&A-Corpus oder eine stark wikilinked Wissensbasis betreiben, kann der Vergleich in beide Richtungen kippen. Der richtige Schritt ist, dieselbe Eval-Form auf Ihren eigenen Daten laufen zu lassen.

Wie lasse ich das auf meiner eigenen Wissensbasis laufen?

Clonen Sie gbrain von github.com/garrytan/gbrain, installieren Sie OpenClaw qmd von github.com/openclaw/openclaw, kopieren Sie 200-500 Markdown-Dateien in einen Sandbox-Tree und schreiben Sie 100-150 geschichtete Eval-Fragen mit Ground-Truth-Dateipfaden. Wir teilen das genaue Eval-Set-Fixture-Format und die Runner-Form gern — buchen Sie den Termin, und wir geben beides weiter.