Wenn ein Betrieb sein Firmenwissen für KI nutzbar machen will, liegt nach zwei Gesprächen meist ein Angebot auf dem Tisch: Dokumente aufbereiten, Vektordatenbank, Suchpipeline, Chatbot. Fünfstellig, ein paar Monate Laufzeit. Technisch ist daran nichts falsch.
Nur fehlt davor eine Frage, die kaum jemand stellt: Habt ihr euer Wissen überhaupt schon einmal aufgeschrieben? In den meisten Fällen lautet die Antwort nein. Und dann baut man eine Suchmaschine über einen Haufen, den vorher noch niemand sortiert hat.
Die Alternative heißt in Entwicklerkreisen inzwischen LLM-Wiki: ein überschaubarer Satz gepflegter Textdateien, den das Sprachmodell direkt liest, ohne Datenbank und ohne Suchtechnik dazwischen. Dieser Beitrag klärt, wann das reicht, wann es nicht mehr reicht und woran du den Übergang erkennst.
Was ein LLM-Wiki ist
Ein LLM-Wiki ist kein Produkt, das du kaufst. Es ist ein Ordner. Darin liegen Textdateien, meist im Format Markdown, und zwar nach vier Regeln:
- Ein Thema pro Datei. Nicht „Vertrieb.md" mit 60 Seiten, sondern „angebot-erstellen.md", „rabattstaffel.md", „reklamation-annehmen.md".
- Sprechende Dateinamen. Sie sind die halbe Suche. Ein Modell, das den Ordner sieht, weiß schon am Namen, wo es nachschauen muss.
- Ein Kopf in jeder Datei. Worum es geht, für wen es gilt, Stand vom, verantwortlich ist. Vier Zeilen.
- Eine Übersichtsdatei. Eine Seite, die auflistet, was es gibt und wofür es zuständig ist. Das ist die Landkarte, an der sich Mensch und Modell orientieren.
Genutzt wird das Ganze auf zwei Wegen. Entweder du legst die Dateien in ein Projekt in ChatGPT oder Claude, dann hat das Modell sie bei jeder Frage vorliegen. Oder ein Agent greift auf den Ordner zu und liest gezielt die eine Datei, die zur Frage passt. Das ist der interessantere Weg, weil er nicht alles auf einmal in den Kopf des Modells schiebt.
Wer schon einmal einen brauchbaren SOP geschrieben hat, hat die Hauptarbeit für sein LLM-Wiki bereits gemacht. Es ist derselbe Text, nur ohne Formatierungsgeklingel.
Warum das heute trägt und vor zwei Jahren nicht
RAG, also das gezielte Nachschlagen passender Wissensausschnitte, wurde aus einem Mangel geboren: Die Modelle konnten nur wenige Seiten Text auf einmal lesen, also musste man ihnen vorsortieren, welche Stellen sie überhaupt zu sehen bekommen. Wie das im Detail funktioniert, habe ich in RAG einfach erklärt beschrieben.
Zwei Dinge haben sich seitdem verschoben.
Erstens die Menge. Aktuelle Modelle lesen bis zu eine Million Tokens auf einmal, das sind grob 650.000 bis 700.000 Wörter deutscher Fachprosa. Ein komplettes Qualitätshandbuch samt Arbeitsanweisungen bleibt darunter, oft deutlich.
Zweitens der Preis. Wiederholt mitgeschickter Text wird zwischengespeichert, und dieses Zwischenspeichern ist deutlich billiger geworden. Bei Claude Fable 5.1 kostet das Lesen aus dem Cache 0,25 US-Dollar je Million Tokens, 75 Prozent weniger als vorher, während frisch verarbeiteter Text mit 10 US-Dollar je Million zu Buche schlägt.
Rechne es an einem realistischen Fall durch. 30 Dokumente à vier Seiten sind rund 70.000 Tokens. Frisch verarbeitet kostet jede Frage darauf etwa 0,70 US-Dollar. Aus dem Cache gelesen sind es knapp zwei Cent. Bei 50 Fragen am Tag ist das der Unterschied zwischen 35 Dollar und einem Dollar.
Ein Sternchen gehört dazu: Der erste Aufruf schreibt den Cache und kostet mehr als der reine Lesepreis, und der Cache lebt je nach Einstellung nur Minuten bis eine Stunde. Wer zweimal am Tag eine Frage stellt, zahlt jedes Mal den vollen Preis. Welche Hebel bei der Rechnung wirklich ziehen, steht im Beitrag zu den Token-Kosten.
Wo das Wiki an die Wand fährt
Damit das nicht als Werbung für den einfachen Weg gelesen wird: Ein LLM-Wiki hat eine klare Obergrenze, und die ist niedriger, als die Million Tokens vermuten lässt.
Ein volles Kontextfenster macht das Modell unzuverlässiger. Das ist gemessen, nicht vermutet: Bei rund 256.000 Tokens findet ein Modell 93 Prozent der abgefragten Informationen wieder, bei einer Million nur noch 76 Prozent. Jede vierte Information geht also verloren, wenn du das Fenster randvoll machst. Mehr dazu im Beitrag über Context Engineering. Dazu kommt der gut belegte Effekt, dass Modelle Inhalte am Anfang und Ende langer Texte besser nutzen als in der Mitte.
Alle sehen alles. Ein Ordner kennt keine Rollen. Wenn Gehaltsbänder, Einkaufskonditionen und Personalakten im selben Wiki liegen wie die Arbeitsanweisungen, kann dir niemand versprechen, dass die Antwort für den Azubi nichts davon enthält. Rollen- und versionsgenaue Antworten sind genau das, was ein RAG-System über Metadaten-Filter leistet. Welche Architekturentscheidungen dabei datenschutzrechtlich anstehen, steht in DSGVO-konforme Wissensdatenbank.
Keine Quellenangabe von selbst. Wenn 40 Dateien im Kontext liegen, kannst du das Modell bitten, seine Fundstelle zu nennen, aber prüfen musst du es selbst. Ein Abrufsystem liefert den Beleg als Teil der Antwort. Für alles, was revisionssicher sein muss, ist das kein Komfort, sondern Pflicht.
Es wächst mit dem Betrieb. 30 Dateien pflegt eine Person nebenbei. 300 Dateien pflegt niemand mehr nebenbei, und veraltete Dateien sind schlimmer als fehlende, weil das Modell ihnen genauso glaubt.
Wo RAG an die Wand fährt
Die Gegenrichtung ist genauso wichtig, weil sie in Angeboten selten vorkommt.
Das Zerschneiden zerstört Zusammenhänge. Wer Dokumente in Stücke zerlegt, trennt die Regel von ihrer Ausnahme, die Tabellenüberschrift von den Zahlen darunter, den Prüfschritt von seiner Toleranz. Das Modell bekommt Bruchstücke und reimt sich den Rest zusammen.
Bedeutungssuche trifft keine Artikelnummern. Eine Vektorsuche findet, was gemeint ist, nicht was exakt dasteht. Fehlercodes, Normbezeichnungen und Eigennamen fallen durch, solange keine klassische Stichwortsuche daneben läuft. Deshalb braucht ein ernstzunehmendes System Hybrid Search und Reranking.
Es wird nie hundertprozentig. Selbst in der besten von Anthropic gemessenen Konfiguration verfehlt der Abruf in rund zwei Prozent der Fälle die richtige Quelle. Das ist gut, aber es ist nicht null, und du brauchst einen Prüfkatalog, um zu wissen, wo du stehst.
Und der eigentliche Punkt: RAG über unsortierte Dokumente macht Unordnung nur schneller auffindbar. Warum ein Stapel PDFs noch kein Wissen ist, habe ich in diesem Beitrag auseinandergenommen. Die Aufräumarbeit fällt in beiden Fällen an. Im Wiki machst du sie zuerst, bei RAG holt sie dich in Monat drei ein.
Die Entscheidung in vier Fragen
Das sind Erfahrungswerte aus Projekten, keine Studienergebnisse. Sie taugen als Ausgangspunkt, nicht als Beweis.
- Wie viel Wissen ist wirklich im Spiel? Nicht wie viele Dateien auf dem Laufwerk liegen, sondern wie viele davon Fragen beantworten, die im Alltag vorkommen. Unter etwa 50 Dokumenten reicht ein Wiki fast immer. Ab einigen Hundert wird Abrufen zur Pflicht.
- Müssen verschiedene Leute Verschiedenes sehen? Sobald die Antwort von der Rolle abhängt oder Vertrauliches im selben Bestand liegt, brauchst du Filter, und damit Metadaten und ein Abrufsystem.
- Muss die Antwort belegt sein? Wenn eine falsche Auskunft ein Audit, eine Reklamation oder eine Haftungsfrage auslöst, gehört die Quelle in die Antwort und nicht in eine Rückfrage.
- Wie oft ändert sich der Inhalt? Täglich wechselnde Preise und Bestände gehören ohnehin nicht in Textdateien, sondern kommen aus dem System, das sie führt. Das ist dann keine Wissensfrage mehr, sondern eine Anbindung.
Viermal nein heißt: Fang mit dem Wiki an. Ein klares Ja bei Rollen oder Belegpflicht heißt: Plan von Anfang an ein Abrufsystem ein. Die Zwischenstufe, die in der Praxis am häufigsten passt, ist ein Wiki in Themenordnern, auf das ein Agent gezielt zugreift, statt alles gleichzeitig zu lesen. Wann welcher Aufbau in einen Wissens-Chatbot mündet, steht in Wissens-Chatbot und Onboarding-Agent.
Wie du in zwei Wochen ein LLM-Wiki hinstellst
Kein Projekt, kein Budget, kein Werkzeugkauf. Der Reihe nach:
- Fragen sammeln, nicht Dokumente. Eine Woche lang notiert jeder im Team jede Frage, die er einem Kollegen gestellt hat oder gestellt bekommen hat. Am Ende hast du 30 bis 60 Fragen, und die dreißig häufigsten sind dein Bauplan.
- Je Frage eine Datei. Titel ist die Frage, Inhalt ist die Antwort, so wie du sie einem neuen Kollegen gibst. Fließtext und Listen, keine Screenshots, keine Tabellenfriedhöfe.
- Kopfzeilen setzen. Gilt für wen, Stand vom, verantwortlich ist wer. Ohne diese drei Angaben veraltet das Wiki unbemerkt.
- Übersichtsdatei schreiben. Eine Seite mit allen Dateien und einem Halbsatz dazu, wofür jede zuständig ist.
- Gegen echte Fragen testen. Nimm zehn Fragen aus Schritt eins, stell sie dem Modell mit dem Wiki im Zugriff und prüf die Antworten mit der Fachabteilung. Jede falsche Antwort ist keine Modellschwäche, sondern eine Lücke im Text.
- Pflege festlegen. Eine Person je Datei, ein fester Termin im Monat, Stand-Datum aktualisieren. Das ist der Schritt, an dem es scheitert, nicht die Technik.
Nach zwei Wochen weißt du mehr über eure Wissenslage als aus jedem Beratungsgespräch. Und du weißt, ob die Menge für ein Wiki reicht, weil du sie jetzt siehst.
Das Wiki ist kein Wegwerfprodukt
Der wichtigste Punkt zum Schluss: Diese Entscheidung ist keine Gabelung, bei der ein Weg verloren geht. Ein gepflegtes Wiki ist genau das Material, aus dem später ein gutes RAG-System entsteht. Sauber getrennte Themen, klare Überschriften, Stand-Datum und Verantwortlicher an jeder Datei: Das sind bereits die Chunks und die Metadaten, für die in einem Projekt sonst die Hälfte des Budgets draufgeht. Wie sich Aufwand und Preis dort zusammensetzen, steht in Was kostet ein KI-Projekt.
Umgekehrt gilt das nicht. Eine Vektordatenbank über ungeordnete Dokumente wird nie zu einem geordneten Wissensbestand. Sie bleibt eine Suche über Unordnung.
Deshalb lautet meine Empfehlung fast immer: erst das Wiki, dann messen, dann entscheiden. Nicht weil die Technik schlecht wäre, sondern weil die Vorarbeit in beiden Fällen dieselbe ist und im Wiki sofort etwas abwirft.
Häufige Fragen
Reichen unser SharePoint oder unser Notion nicht als LLM-Wiki?
Als Ablage ja, als Kontext für ein Modell nur, wenn der Inhalt den vier Regeln von oben folgt. Das Problem an gewachsenen Ablagen ist selten das Werkzeug, sondern dass dieselbe Information in vier Fassungen an drei Orten liegt und keine davon ein Stand-Datum hat. Räum inhaltlich auf, dann ist das Werkzeug zweitrangig.
Muss ich dafür Markdown lernen?
Nein. Markdown sind Überschriften mit Rautezeichen und Listen mit Strichen, das ist in zehn Minuten erklärt. Wichtiger als das Format ist, dass es reiner Text ist: durchsuchbar, versionierbar und ohne Layout, das das Modell erst wegräumen muss.
Wie halte ich Vertrauliches aus dem Wiki heraus?
Mit einem zweiten Ordner, auf den das Modell keinen Zugriff hat. Solange die Trennung an der Ordnergrenze läuft, ist sie überprüfbar. Sobald du innerhalb eines Bestandes nach Rollen unterscheiden willst, brauchst du ein Abrufsystem mit Filtern.
Und wenn ich schon ein RAG-Angebot auf dem Tisch habe?
Dann frag nach zwei Dingen: Woran wird gemessen, ob die Antworten stimmen, und wer bereitet die Dokumente auf. Wenn der Aufbereitungsteil im Angebot fehlt oder pauschal mitläuft, fehlt der Teil, der über das Ergebnis entscheidet.
Fazit
RAG ist kein Fortschritt gegenüber einem Wiki, und ein Wiki ist keine Notlösung vor RAG. Es sind zwei Antworten auf unterschiedlich große Probleme. Bis etwa 50 gepflegte Dokumente, ohne Rollentrennung und ohne Belegpflicht, gewinnt der Ordner: sofort verfügbar, für Cent-Beträge im Betrieb, von jedem lesbar. Darüber, oder sobald verschiedene Leute Verschiedenes sehen dürfen, gewinnt das Abrufsystem.
Was in beiden Fällen gleich bleibt, ist die Arbeit, die niemand abnimmt: aufschreiben, was bisher nur in Köpfen steht, und dafür sorgen, dass es aktuell bleibt. Das ist der Teil, der den Unterschied macht, und er hat mit KI überhaupt nichts zu tun.
Wenn du wissen willst, welche der beiden Wege in deinem Betrieb trägt, schau dir mit dem KI-Potenzial-Check an, wo bei euch die Fragen entstehen, oder wir gehen das in einer KI-Beratung gemeinsam an deinen Unterlagen durch. Was dabei am Ende herauskommt, beschreibt die Seite zur Wissens-KI.