Die meisten Unternehmens-Wissensdatenbanken brauchen kein RAG

Mein internes Unternehmens-Wiki läuft auf fünf Shell-Befehlen und einer manuell gepflegten Indexdatei. Keine Embeddings, keine Vektordatenbank, kein Re-Indexing-Job. Für eine Wissensdatenbank mit rund 200 Dokumenten ist dieser Aufbau schneller umgesetzt, günstiger im Betrieb und genauer als eine typische RAG-Pipeline. Der Trade-off lohnt sich erst jenseits von tausend Dokumenten.

Karpathy und Obsidian: zwei Impulse

Zwei Dinge haben diesen Ansatz nahegelegt. Erstens Andrej Karpathys beharrliches Argument, dass KI-Agenten Werkzeuge erhalten sollten, anstatt abgerufene Textfragmente eingespeist zu bekommen. Sein Projekt AutoResearch, veröffentlicht im März 2026, macht das buchstäblich deutlich: Der Agent führt Code aus statt Embeddings abzufragen, und Fortschritt entsteht durch Ausführung. In einem früheren Artikel wurde AutoResearch ausführlich behandelt.

Zweitens Obsidian. Ein Obsidian-Vault ist schlicht ein Ordner mit einfachen Markdown-Dateien. Keine proprietäre Datenbank, kein Schema zum Migrieren, kein SDK zum Erlernen. In Kombination mit Obsidians lokalem REST-API-Plugin liegt die gesamte Wissensdatenbank hinter einem normalen HTTP-Endpunkt, den jeder Prozess lesen oder beschreiben kann. Diese Kombination macht das Prinzip "dem Agenten Werkzeuge geben" trivial umsetzbar: Eine Handvoll Shell-Befehle genügt, und Sie haben ein LLM, das eine strukturierte Wissensdatenbank direkt lesen, schreiben und durchsuchen kann.

Der konkrete Aufbau

Das interne Wiki umfasst heute 22 Seiten strukturierten Wissens: Entitäten (Personen, Unternehmen, Projekte), Konzepte (Frameworks und Prinzipien), Quellen (rohe Recherche-Notizen) und Syntheseseiten, die alles verknüpfen. Jede Seite verweist über Obsidian-Wikilinks auf andere Seiten, und eine manuell gepflegte `index.md` im Stammverzeichnis listet alles nach Kategorie mit einzeiligen Beschreibungen auf.

Der Agent durchsucht den Vault nicht mit Embeddings. Er führt fünf Befehle aus:

• `wiki read <path>`. Eine einzelne Markdown-Seite abrufen.
• `wiki write <path> -`. Eine Seite aus stdin erstellen oder überschreiben.
• `wiki append <path> <text>`. Eine Zeile an eine Seite anhängen (verwendet für das laufende Aktivitätsprotokoll).
• `wiki search <query>`. Die eingebaute Volltext-Suche von Obsidian aufrufen.
• `wiki list <dir>`. Dateien in einem Verzeichnis auflisten.

Die gesamte Implementierung umfasst etwa 80 Zeilen Bash und curl. Keine Vektordatenbank, kein Embedding-Modell, keine Chunking-Strategie, kein Reranker, kein nächtlicher Index-Job. Eine neue Notiz hinzuzufügen bedeutet, die Datei zu schreiben. Der Agent übernimmt sie bei der nächsten Abfrage, ohne einen zwischengeschalteten Pipeline-Schritt.

Die Indexdatei ist das Retrievalsystem

Der entscheidende Punkt: Der Agent beginnt mit `wiki/index.md`. Dieses kuratierte Inhaltsverzeichnis listet jede Seite mit einer Ein-Satz-Beschreibung, gruppiert nach Kategorie. Aus diesem einzelnen Lesevorgang von etwa 400 Tokens weiß der Agent bereits, welche ein oder zwei Seiten relevant sind.

Danach folgen ein oder zwei gezielte Lesevorgänge, um die relevanten Seiten vollständig zu laden. Jede Seite umfasst zwischen 200 und 800 Tokens. Die meisten Abfragen enden mit zwei oder drei Lesevorgängen und rund tausend Tokens Vault-Inhalt im Kontextfenster. Das ist weniger als eine Standard-RAG-Konfiguration einbringt, und der Inhalt ist kohärent (ganze Seiten) statt fragmentiert (aus ihrem Kontext herausgerissene Chunks).

Ein gepflegter Index leistet dasselbe wie eine Vektordatenbank in einer RAG-Pipeline: Er ordnet einer Abfrage die richtigen Dokumente zu. Der Unterschied besteht darin, dass ein Mensch diese Zuordnung einmal kuratiert hat, anstatt dass ein Embedding-Modell sie bei jeder Abfrage annähert.

Token- und Kostenvergleich

Für eine kleine Unternehmens-Wissensdatenbank mit rund 200 Dokumenten zeigt sich, was ein Standard-RAG-Aufbau im Vergleich zum indexbasierten Dateizugriff kostet. Die Token-Zahlen sind Richtwerte auf Basis typischer Abrufmuster. Die Infrastrukturzahlen stammen aus den öffentlichen Preislisten der gängigsten verwalteten Dienste.

Die Token-Einsparungen hängen von der Korpusstruktur und den Abfragemustern ab. Der wichtigere Punkt ist alles, was in der zweiten Spalte wegfällt: kein Vektordatenbank-Posten auf der Monatsrechnung, kein Embedding-Modell zum Warten und keine Debugging-Session für die Chunking-Strategie, wenn Antworten plötzlich schwanken. Für eine Wissensdatenbank, die problemlos in einem einzelnen Kopf Platz findet, ist jedes dieser beweglichen Teile Overhead ohne entsprechenden Nutzen.

Was nicht mehr durchdacht werden muss

Am klarsten lässt sich dieses Muster durch die Entscheidungen begründen, die schlicht entfallen:

• Chunking-Strategie. Keine Debatte über "nach Absatz, nach Satz oder nach Token-Anzahl?". Die Seite ist die Einheit.
• Auswahl des Embedding-Modells. Kein Rechercheprojekt zum Vergleich von text-embedding-3-small mit feinabgestimmten Alternativen.
• Vektordatenbank-Betrieb. Kein verwalteter Dienst zum Überwachen, Aktualisieren oder Budgetieren.
• Re-Indexing-Pipelines. Kein nächtlicher Batch-Job, keine "Der Index ist veraltet"-Nachrichten.
• Retrieval-Evaluierungs-Harness. Keine Precision-und-Recall-Testsuite, die parallel zur Wissensdatenbank läuft.
• Hybrid-Search-Tuning. Keine BM25-plus-Vektor-plus-Rerank-Pipeline, die im Gleichgewicht gehalten werden muss.

Das ist in etwa das gesamte RAG-Betriebshandbuch, entfernt. Was es ersetzt, ist ein Shell-Skript und die Disziplin, eine Indexdatei aktuell zu halten. Die Disziplin ist real, aber es ist dieselbe Disziplin, die ein Wiki für Menschen überhaupt wertvoll macht.

Wann RAG die richtige Wahl bleibt

Dieses Muster hat klare Grenzen. Ein gepflegter Index stößt bei etwa tausend Dokumenten an seine Grenzen: Ab diesem Punkt kann kein Mensch die Struktur mehr vollständig im Kopf behalten, und die Indexdatei wird zu lang, um sie bei jeder Abfrage effizient zu scannen. Jenseits dieser Schwelle verdienen Embeddings und eine echte Retrieval-Schicht ihren Platz.

Weitere Fälle, in denen RAG das richtige Werkzeug bleibt:

• Multimodale Korpora. PDFs mit Tabellen, gescannte Dokumente, Audio-Transkripte, bildlastige Berichte. Ein Markdown-Vault setzt voraus, dass sich alles auf Text reduzieren lässt.
• Hochfrequente Aktualisierungen im großen Maßstab. Wenn Tausende öffentlicher Dokumente indexiert werden, die sich jede Minute ändern und sofort abfragbar sein müssen.
• Strenge Metadaten-Filterung zur Abrufzeit. Wenn Abfragen strukturierte Filter (Datumsbereiche, Autor, Dokumenttyp) direkt im Retrieval-Schritt erfordern, ist eine Vektordatenbank mit Metadaten die sauberere Lösung.
• Nicht vertrauenswürdige oder adversarielle Inhalte. Wenn der Korpus von vielen Autoren mit widersprüchlichen Absichten stammt und kein einzelner Mensch damit betraut werden kann, einen kuratierten Index zu pflegen.

Für die meisten internen Unternehmens-Wissensdatenbanken (Firmen-Wikis, Produktdokumentation, Sales-Playbooks, Onboarding-Leitfäden, interne Standardprozesse) trifft keine dieser Bedingungen zu. Der Korpus ist klein, die Autoren sind wenige, die Struktur ist stabil, und die Personen, die die Dokumentation pflegen, sind dieselben, denen ihre Richtigkeit am wichtigsten ist. RAG ist für die Anwendungsfälle, die ich sehe, oft der falsche Standard.

Passend für die meisten Unternehmen

Für kleine und mittelgroße Unternehmen, die ihre bestehende Dokumentation betrachten und sich fragen, wie sie KI-abfragbar gemacht werden kann, lautet die ehrliche Antwort meistens: Sie brauchen keine Vektordatenbank. Sie brauchen eine Indexdatei, ein kurzes Skript, das Ihre Dokumente liest und schreibt, sowie ein LLM mit Werkzeugzugang. Die Komponenten sind alle sofort verfügbar. Die Arbeit liegt darin, den Index korrekt zu halten.

RAG-as-a-Service-Anbieter liegen mit der Technologie nicht falsch; die Meinungsverschiedenheit betrifft den Zeitpunkt, an dem sie zur Standardarchitektur werden sollte. RAG ist das richtige Werkzeug für Probleme in einem Maßstab, den die meisten Unternehmen nicht haben, bei Inhaltstypen, die die meisten Unternehmen nicht speichern. Wer zuerst zu RAG greift, riskiert lange Roadmaps und laufende Infrastrukturkosten, bevor der eigentliche Anwendungsfall erfüllt wird.

webvise baut interne KI-Werkzeuge auf genau diesem pragmatischen Fundament: strukturiertes Wissen, einfache Tools, Agenten, die direkt lesen und schreiben. Wer ein RAG-Projekt für die Team-Dokumentation erwägt und eine zweite Meinung dazu möchte, ob die Komplexität gerechtfertigt ist, kann Kontakt aufnehmen, um den tatsächlichen Korpus zu besprechen, bevor die Infrastruktur-Entscheidung getroffen wird.