Lokale Hybrid-Suche: Retrieval ohne RAG-Pipeline

Vor zwei Wochen habe ich darüber geschrieben, was sich ändert, wenn das Modell gleich bleibt und nur der Harness wechselt. Kurzfassung: der Wrapper macht mehr aus, als die meisten annehmen. Dieser Artikel geht eine Schicht tiefer, zu der Ebene, die niemand ins Architekturbild malt, bis sie kaputtgeht: Woher bekommt der Agent eigentlich sein Wissen?

Die Reflexantwort der letzten Jahre lautet RAG: chunken, embedden, in eine Vektordatenbank legen, eine Retrieval-Funktion schreiben und so lange tunen, bis sie nicht mehr peinlich ist. Eines unserer internen Experimente macht genau das, und ich komme kurz darauf zurück, weil es ein nützlicher Kontrast ist und nicht das Thema.

Das Thema ist die andere Antwort. Ein Kollege betreibt ein internes Content-Wiki: ein Git-Repository voll Markdown, geschichtet von unveränderlichen Rohquellen über gepflegte Wiki-Seiten bis zu Content-Drafts, gewartet überwiegend von Agenten. Seine Suchschicht ist keine Pipeline, die jemand geschrieben hat. Es ist qmd, eine lokale Suchmaschine für Markdown und Code.¹ BM25, Vektoren und ein LLM-Reranker, alles auf dem Gerät, ansprechbar als CLI und als MCP-Server. Eine SQLite-Datei, kein Service, kein API-Key.

Dieses Repository ist der Grund, warum in diesem Artikel Zahlen stehen. Es ist kein Produkt, es ist das Experiment eines Einzelnen an echtem Material, und genau das macht es lesenswert: eine Wissensschicht, die lange genug im täglichen Einsatz ist, um ein Betriebsmodell und eine Messung zu haben, statt einer Demo.

Warum das jetzt aufkommt

Im Juli 2026 sind zwei Dinge zusammengekommen.

Erstens sind die Modelle klein geworden, die man dafür braucht. Ein Embedding-Modell mit 300M Parametern und ein Reranker mit 600M passen bequem auf ein Notebook. Vektorsuche über einen Korpus in persönlicher oder Teamgröße braucht damit weder eine Embedding-API noch einen Datenbank-Service. Retrieval ist genau die Schicht, an der lokal aufhört, ein Kompromiss zu sein: die Modelle sind klein, und der Korpus gehört einem selbst.

Zweitens ist das Muster „gib deinem LLM ein Wiki" im Mainstream angekommen. Andrej Karpathys LLM-Wiki-Gist erschien im April und überschritt binnen Wochen 5.000 Stars und Forks, mit über zwanzig eigenständigen Implementierungen in den ersten fünf.² Sein Kernargument zielt direkt auf RAG: das Modell entdeckt Wissen bei jeder Frage neu, und nichts akkumuliert. Ein Wiki kompiliert Wissen einmal bei der Ingestion und hält es aktuell.

Dieses Muster hat ein Skalierungsproblem, und Karpathy benennt es selbst. Eine einfache Index-Datei trägt bei moderater Größe, etwa 100 Quellen. Jenseits einiger hundert Dokumente braucht man echte Suche. Im Juli-Update des Gists ist das Werkzeug, das er dafür nennt, qmd.

Deshalb lohnt der Blick auf das erwähnte Wiki-Repository als reale Instanz statt als Gedankenexperiment. Sein Aufbau, unveränderliche Rohquellen plus ein LLM-gepflegtes Wiki plus eine Schema-Datei mit den Konventionen, deckt sich nahe genug mit dem Muster, dass das Lesen des einen das andere erklärt. Und es liegt deutlich jenseits der Größe, bei der eine Index-Datei noch trüge.

Die Frage ist damit nicht akademisch. Wer 2026 eine Wissensschicht für Agenten baut, muss entscheiden, ob er Retrieval-Code schreibt oder Retrieval installiert.

Der Kontrast, kurz

Zur Kalibrierung die Form des selbstgebauten Wegs. Unser anderes Experiment ist ein Chatbot über gescrapten Website-Content in ChromaDB, sein Ingest- und Retrieval-Pfad liegt bei ein paar tausend Zeilen Python.³ So weit zu kommen ist der leichte Teil. Danach beginnt die wiederkehrende Arbeit, und die sieht in den meisten selbstgebauten Pipelines gleich aus: Synonyme und Domänenvokabular liegen in handgepflegten Tabellen, womit die Retrieval-Schicht bearbeitet werden muss, sobald der Content darunter umbenannt wird; Relevanz wird eine gewichtete Summe, deren Gewichte ein Mensch gewählt hat, meist ohne Reranker in der Kette; und das Chunking ist ein festes Zeichenfenster mit Overlap, das quer durch Abschnitte schneidet und den Index zum Ausgleich wachsen lässt.

Das ist die normale Form von Retrieval, das man selbst baut, und kein Fehler in einer bestimmten Codebasis. Unsere beantwortet heute Fragen, und sie enthält Guardrails und Sprachfilterung, für die qmd keine Entsprechung hat. Mitzunehmen ist nur, dass jedes Teil davon Plumbing ist, das jemand besitzt. Jetzt der andere Weg.

Was qmd anders macht

qmd ist bewusst klein. Es indiziert Dateien, gibt Dokumente zurück und hört da auf. Keine Generierung, keine Antwortsynthese, keine Meinung zu deinem Prompt.

Drei Modi: search ist reines BM25, vsearch reine Vektorsuche, query der hybride Pfad mit Query-Expansion und Reranking. Drei Modelle laufen lokal über node-llama-cpp: EmbeddingGemma-300M für Vektoren, Qwen3-Reranker-0.6B für Relevanz und ein 1,7B-Modell für die Query-Expansion. Der Index ist eine einzelne SQLite-Datei unter ~/.cache/qmd/index.sqlite, mit FTS5 für Volltext und sqlite-vec für Vektoren. MIT-lizenziert.

Daraus folgen vier Dinge, und das größte ist die Wartung. Die handgepflegte Vokabular-Tabelle aus dem vorigen Abschnitt hat hier kein Gegenstück, weil Query-Expansion die Aufgabe des dritten Modells ist: niemand muss dem Index beibringen, dass ein Produkt umbenannt wurde. Das Chunking ist das zweite. qmd bewertet natürliche Markdown-Bruchstellen, damit Abschnitte, Absätze und Code-Blöcke intakt bleiben, statt bei einer festen Zeichenzahl zu schneiden und darauf zu hoffen, dass der Overlap das Zerschnittene auffängt. Collections nutzen standardmäßig einen **/*.md-Glob, aber die Maske ist konfigurierbar, und Quelldateien in TypeScript, JavaScript, Python, Go und Rust bekommen AST-bewusstes Chunking, wenn man die automatische Strategie aktiviert.

Das dritte ist betrieblich und schlägt im Budget auf: es gibt nichts zu betreiben. Kein Chroma, kein Embedding-API-Key, kein Netzwerk-Egress, was für eine Wissensbasis voller interner Notizen, Kundenkontext und halbfertiger Strategie weniger Komfort als Voraussetzung ist. Das vierte ist, dass es von Haus aus agentenfähig kommt. Der MCP-Server stellt query, get, multi_get und status über stdio oder HTTP bereit, und das ist die ganze Integration: man schreibt kein Retrieval-Tool für seinen Agenten, man zeigt ihm einen Server, der schon eines ist.

Ein Haken für die Lokal-Inferenz-Fraktion: qmd fährt GGUF-Modelle über node-llama-cpp, nicht MLX. Auf Apple Silicon bleibt damit Leistung liegen. Wer Query-Latenz statt Ergebnisqualität optimiert, schaut also zuerst dort hin.

Als Wissensschicht betreiben

Eine Feature-Liste ist kein Betriebsmodell. Drei Gewohnheiten machen aus qmd erst eine Wissensschicht statt eines Suchbefehls, und keine davon ist ein qmd-Feature.

Die Hybrid-Suche gehört neben die anderen Zugänge, nicht an ihre Stelle. Für unscharfes Erinnern ist Hybrid da, also für den Fall, dass man weiß, was etwas tut, aber nicht, wie es heißt. Existenz-Checks mit bereits bekanntem Begriff sind bei Grep oder einem deterministischen Index besser aufgehoben, weil das schneller und exakt ist. Fragen danach, wie Dinge zusammenhängen, gehören in eine Graph-Ansicht, weil kein Suchmodus „was verweist auf X" beantwortet. Und wenn Hybrid schwach zurückkommt, läuft die Query einmal als reines BM25 mit exakten Keywords, bevor man schließt, der Korpus habe zum Thema nichts. Vier Wege, pro Weg eine Regel, aufgeschrieben. Diese Arbeitsteilung ist der Teil, den man überspringt, und sie ist der Grund, warum das Werkzeug nicht in allem gut sein muss.

Reindizieren gehört in einen Task, nicht in eine Gewohnheit. qmd update und qmd embed arbeiten inkrementell über Content-Hashes, unveränderte Dateien kosten also nichts. Damit ist es billig, sie an das zu hängen, was nach Content-Änderungen ohnehin läuft, zusammen mit allem anderen, was vom Index abgeleitet ist. Retrieval-Qualität, die davon abhängt, dass jemand ans Reindizieren denkt, verfällt still.

Den Index als Substrat behandeln, nicht als Blackbox. Das ist das Argument für SQLite, das ich unterschätzt hatte. Weil die Vektoren in einer gewöhnlichen Datei liegen, können andere Werkzeuge sie lesen, ohne API und ohne Export-Schritt. In dem Setup, das ich gesehen habe, liest ein kleines Skript die Embeddings direkt aus qmds Datenbank und projiziert sie in eine zweidimensionale Karte des Korpus, ein zweiter Konsument desselben Index. Bei einer gehosteten Vektordatenbank wird daraus ein Projekt.

Woher diese Zahlen kommen

Diese Messung habe ich nicht selbst gefahren. Sie existierte schon in jenem Wiki-Repository, datiert auf Anfang Juli 2026, qmd 2.5.3.⁴ Sie zu zitieren bringt mehr, als eine schwächere Variante auf einem kleineren Korpus nachzustellen.

Zitierwürdig macht sie der Aufbau des Golden-Sets. Die 17 Queries stammen wörtlich aus echten Session-Prompts aus Juni und Juli, sie wurden nicht für den Benchmark geschrieben. Sie sind in zwei Klassen geteilt, für die unterschiedliche Gewinner erwartet werden:

• coverage: „haben wir X schon?" Der exakte Begriff ist bekannt. Grep sollte gewinnen.
• episodic: „da war doch mal was mit …" Der Begriff ist unbekannt oder umschrieben. Hybrid sollte gewinnen.

Metrik ist hit@5. Ergebnisse:

Hybrid gewinnt insgesamt und ist der einzige Modus, der zwei der Queries überhaupt findet. Das ist die Schlagzeile. Die drei Einschränkungen darunter sind nützlicher als die Schlagzeile.

Die grep-Spalte ist nicht, was man denkt. Sie misst eine naive Wortzähl-Baseline über die rohe Query, Füllwörter inklusive. Sie misst nicht agentisches Grep. Ein Mensch oder ein LLM, das aus „haben wir opentelemetry schon als entity" den Begriff opentelemetry zieht, trifft coverage mühelos 5 von 5. Die coverage-Zeile ist also kein Argument gegen Grep. Sie zeigt, dass naive Automatik dort versagt, was eine andere Aussage ist.

BM25 allein ist auf Natursprache das falsche Werkzeug. Vier von siebzehn. Als der weiter oben beschriebene Gegencheck mit exakten Keywords verdient es seinen Platz, als Primär-Modus nicht.

Reranker können exakte Treffer begraben. Zwei der vier Hybrid-Misses wurden von Grep beziehungsweise BM25 gefunden und dann beim Reranking aus den Top-5 gedrängt. Mit diesem Fehlermodus rechnet niemand, wenn er einen Reranker dazunimmt, und genau deshalb existiert der BM25-Fallback als Absicht statt als Überrest.

Wenn man eine Sache aus dieser Tabelle mitnimmt, dann diese: Hybrid ist der beste Default für unscharfes Erinnern, und es ersetzt keine deterministische Suche, wenn man den Begriff schon kennt. Behalte beides.

Was das für Agenten bedeutet

Ab hier geht es nicht mehr um Suchqualität, sondern um eine Architekturfrage.

Wer RAG für einen Agenten baut, baut ein Werkzeug, das der Agent aufruft. Man besitzt dann das Chunking, das Scoring, das Tuning, das Eval-Harness, das man vermutlich nie geschrieben hat, und eine Deploy-Pipeline für ein Synonym-Wörterbuch. Das ist alles undifferenzierte Arbeit. Nichts davon ist das eigene Produkt.

Wer stattdessen eine lokale Suchmaschine mit MCP-Server installiert, macht Retrieval zu Infrastruktur. Der Agent bekommt ein Wissenswerkzeug zum Preis eines Config-Eintrags, und die interessante Ingenieursarbeit wandert eine Ebene höher: was in die Wissensbasis kommt, wie sie aktuell bleibt, und was der Agent aus einem Treffer schließen darf.

Der letzte Punkt verdient Betonung, weil sich Teams genau dort die Finger verbrennen. Die Regel, die man übernehmen sollte: Retrieval-Output wird nie als Fakt weitergegeben, ohne die Quelle gelesen zu haben. qmd liefert Dokumente mit Scores, es liefert keine Wahrheit. Ein Agent, der Such-Snippets zu einer kundenseitigen Antwort zusammenfasst, ist ein Halluzinationsgenerator mit Zwischenschritten, egal wie gut der Reranker ist.

Das zweite Übernahmewürdige ist das Eval-Harness, und es ist billig. Siebzehn Queries in einer YAML-Datei, gezogen aus Fragen, die real gestellt wurden, mit dem erwarteten Dokumentpfad pro Query. Das ist ein Nachmittag Arbeit, der jede künftige Retrieval-Änderung von einem Gefühl in eine Messung verwandelt.

Was mir beim Lesen des Wiki-Repositorys von außen aufgefallen ist: das Golden-Set trägt dasselbe Datum wie die Suchschicht selbst. Die Messung wurde nicht nach dem ersten enttäuschenden Ergebnis nachgerüstet, sie kam mit dem Walking Skeleton. Das ist die Disziplin, die ich stehlen würde, noch vor der Werkzeugwahl: eines unserer zwei Systeme hat ein Golden-Set und das andere nicht, und der Unterschied darin, wie zuversichtlich man beide ändern kann, geht vollständig darauf zurück.

Wo das passt und wo nicht

Keine Tabelle, weil die Entscheidung nicht mehrdimensional ist. Es kommt darauf an, was man tatsächlich baut.

Nimm qmd, wenn dein Korpus Text auf der Platte ist und der Konsument du selbst oder ein Agent in deinem Auftrag. Persönliche Notizen, Engineering-Docs, Meeting-Transkripte, ein internes Wiki, eine ADR-Sammlung, ein Source-Tree. Markdown ist der Default und der am besten unterstützte Fall, aber die Glob-Maske ist konfigurierbar, und verbreitete Quellsprachen bekommen AST-bewusstes Chunking. Wer gerade eine Chunking-Funktion für ein Verzeichnis voll Dokumente schreiben will, sollte anhalten und stattdessen das hier installieren. Das Setup ist ein npm install plus ein Index-Lauf.

Behalte deine RAG-Pipeline, wenn du Anforderungen hast, die qmd nicht adressiert und auch nicht zu adressieren behauptet. Mandantenfähigkeit und Zugriffskontrolle pro Nutzer. Guardrails und Content-Filterung für alles, was nach außen zeigt. Quellen, die keine Dateien auf der Platte sind: PDFs, HTML-Scrapes, Datenbankzeilen, Ticketsysteme. Horizontale Skalierung über eine Maschine hinaus. Alles, wo Retrieval Teil eines Produkts mit SLA ist statt Teil eines Arbeitsablaufs. Unser Chatbot-Experiment sitzt in dieser Spalte, und der nützlichste nächste Schritt dafür ist nicht qmd, sondern ein Golden-Set.

Für DevOps- und Platform-Teams speziell lautet der praktische Schritt: Retrieval nicht länger als Bauaufgabe behandeln. Zwei Rollen, zwei Antworten. Bedient deine Plattform Kunden, betreibst du einen Retrieval-Service und solltest ihn ordentlich besitzen, mit Evals und Observability. Bedient deine Plattform die eigenen Engineers und ihre Agenten, konsumierst du eine Commodity, und den Retrieval-Code 2026 selbst zu schreiben ist eine Entscheidung, die man besser vor der Arbeit in einem Design-Review begründet als danach.

Die unbequeme Zusammenfassung ist, dass das interessante Problem nie das Retrieval war. Es ist die Wissensbasis selbst: was erfasst wird, wer sie pflegt, und was sie am Verfallen hindert. RAG-Code war immer ein Umweg auf dem Weg zu dieser Frage. Lokale Hybrid-Suche ist nur das erste Werkzeug, das den Umweg optional macht.