Confluence ablösen: Ein KI-Firmenwiki, das sich selbst pflegt
Inhalt
Wir haben unsere Firmendokumentation aus Confluence herausgeholt: 310 Seiten und 720 Anhänge liegen jetzt in einem Git-Repository, und die mühsame Pflege übernimmt ein LLM-Agent. Er legt neue Informationen ab, aktualisiert verwandte Seiten, hält Links aktuell und weist darauf hin, wo sich unsere Dokumente widersprechen. Die Quellen wählen weiterhin Menschen aus, und jede Änderung prüft ein Mensch. Dieser Beitrag beschreibt den Aufbau des Repositorys, die Migration, den Pflegeprozess und die Grenzen, auf die wir gestoßen sind.
Der Grund: Firmenwikis gehen selten auf einen Schlag kaputt. Sie verfallen schleichend.
Ein Deployment-Ablauf ändert sich, aber drei verwandte Seiten beschreiben noch den alten. Ein Kundengespräch enthält eine wichtige Erkenntnis zum Produkt, die aber in den Besprechungsnotizen vergraben bleibt. Ein Dienst wird abgeschaltet und taucht trotzdem weiter in der Infrastruktur- und Sicherheitsdokumentation auf.
Niemand richtet dieses Chaos absichtlich an. Es entsteht, wenn Hunderte kleiner Pflegeaufgaben mit Kundenprojekten, Produktarbeit und dem gelegentlichen Wunsch, nach Hause zu gehen, konkurrieren.
Hätten wir unsere Confluence-Seiten einfach in ein anderes Dokumentationswerkzeug verschoben, wäre das Pflegeproblem dasselbe geblieben. Also haben wir geändert, wer die Pflege übernimmt.
Firmenwikis verfallen, weil sich der Pflegeaufwand aufschaukelt
Die erste Fassung eines Dokuments zu schreiben ist meist unkompliziert. Teuer wird es, sobald sich etwas ändert.
Angenommen, ein Entwickler zieht einen Dienst auf einen neuen Host um. Das Runbook für das Deployment muss angepasst werden, aber ebenso die Infrastrukturübersicht, die Notizen zur Notfallwiederherstellung, die Lieferantenliste, die Seite zur Kundenumgebung und vielleicht eine bereits getroffene technische Entscheidung. Fehlt eine dieser Änderungen, widerspricht sich das Wiki selbst.
Mit jeder neuen Seite wird das Problem größer. Jede Seite bringt nützliches Wissen, aber auch neue Zusammenhänge, an die jemand denken muss. Unser Ausweg war bisher: seltener aktualisieren, noch eine Übersichtsseite anlegen oder die Person fragen, die "einfach weiß, wie es funktioniert". Keine dieser Lösungen hat sich auf Dauer bewährt.
Außerdem war fehlende Dokumentation schwer zu erkennen. Eine leere Kontenübersicht kann wie eine fertige Seite aussehen, solange sie nicht ausdrücklich als offene Lücke markiert ist. Ein altes Runbook wirkt verbindlich, bis jemand den Befehl ausprobiert. Und eine Entscheidung ohne ihren ursprünglichen Kontext wird zum Hörensagen.
Am Speicherplatz lag es nicht. Die laufenden Kosten entstanden dadurch, Zusammenhänge und aktuelle Aussagen zu pflegen. Dieses Problem hat uns schließlich zum LLM-Wiki-Muster von Andrej Karpathy geführt.
Ein LLM-Wiki verknüpft belegtes Wissen über Themen hinweg
Die Grundidee eines LLM-Wikis ist einfach. Man bewahrt die Originalquellen auf und pflegt daneben eigene Seiten, die beschreiben, was das Unternehmen aktuell weiß.
Kommt eine neue Quelle hinzu, liest der Agent sie und sucht alle Seiten, die davon betroffen sein könnten. Er kann eine Themenseite überarbeiten, ein Runbook aktualisieren, einer Kundenseite eine Quelle hinzufügen, einen Widerspruch markieren und eine Entscheidung mit dem Experiment verknüpfen, aus dem sie hervorgegangen ist. Eine einzige Quelle kann Änderungen in zehn Dateien auslösen, ohne dass sich ein Mensch alle zehn merken muss.
Ein Kundengespräch ist ein gutes Beispiel. Das Transkript enthält vielleicht
eine Einschränkung für das Deployment, den Wunsch nach einer Produktfunktion,
eine Beschwerde über das Onboarding und einen Hinweis zur Preisgestaltung.
Legt man das Transkript unter meetings/ ab, ist es zwar dokumentiert, aber
keine dieser Informationen landet dort, wo später jemand danach suchen wird.
Unser Agent behandelt das Transkript als Rohmaterial. Er schlägt Änderungen an den Seiten zu Kunde, Produkt, Runbook und Experiment vor, die davon abhängen. Ein Mensch prüft ein einziges Change-Set, statt vier Bereiche des Wikis zu öffnen und sich zu überlegen, was wohin gehört.
Das ist der größte Vorteil des LLM: Es übernimmt bereitwillig die Buchhaltung. Die Quellen wählen weiterhin Menschen aus, sie korrigieren die Interpretation und geben das Ergebnis frei.
Die betroffenen Seiten findet der Agent mit agentischer Suche. Er sucht, prüft die Treffer, sucht erneut und schlägt dann ein Change-Set zur Prüfung durch einen Menschen vor. Bessere Indizes bedeuten weniger Suchaufwand, aber LLM-Agenten finden relevante Inhalte auch in sehr großen Wissensbeständen gut.
Quellen, aktuelles Wissen und Historie getrennt halten
Unser Wiki-Repository hat mehrere Ebenen, weil jede eine andere Frage beantwortet.
raw/ enthält das Ausgangsmaterial: Exporte aus Confluence,
Besprechungsprotokolle, Kundengespräche, Unterlagen von Lieferanten, Verträge,
Screenshots, Recherchen und Dateien aus Quellcode-Repositorys. Diese Dateien
werden nur ergänzt, nie verändert. Der Agent darf sie lesen und zitieren,
kann aber eine unbequeme Quelle nicht stillschweigend verbessern.
wiki/ enthält die gepflegten Seiten, die Menschen und Agenten tatsächlich
lesen. Die Ordner folgen den Themen des Unternehmens, etwa Kunden, Entwicklung,
Produkte, Sicherheit, Experimente und Entscheidungen. Wissen muss nicht mehr
dort liegen, wo ein Confluence-Bereich es zufällig abgelegt hat.
archive/ enthält abgelöste Abläufe, alte Produktarbeit und überholte Seiten.
Diese Historie wollen wir behalten, vor allem wenn sie erklärt, warum etwas
existiert. Wir wollen aber nicht, dass ein Agent eine Deployment-Anleitung für
ein eingestelltes Produkt als aktuellen Rat ausgibt.
index.md ist die Eingangstür. Die Datei listet die verfügbaren Seiten mit
ihrem Status und einer einzeiligen Beschreibung auf. log.md protokolliert
Aufnahmen neuer Quellen, Pflegevorgänge und Prüfungen in zeitlicher
Reihenfolge.
Schließlich sagen AGENTS.md und ein Skill für
das Firmenwiki dem Agenten, wie er arbeiten soll. Sie legen die
Verzeichnisstruktur, die Pflicht-Metadaten, die Regeln für Quellen und die
Schritte zum Aufnehmen oder Prüfen von Material fest. Die Speicherschicht
hängt nicht an einem bestimmten Modell. Wechseln wir das Modell, müssen wir
die Abläufe zum Aufnehmen, Bearbeiten und Prüfen trotzdem neu testen. Quellen,
Seiten, Historie und die Spielregeln der Pflege bleiben im Repository. Der
Skill ist damit das Betriebshandbuch der gesamten Wissensbasis.
Vieles davon stammt aus dem bewährten Ansatz Docs as Code. Mit reinem Text bekommen wir Git-Historie, Reviews über Pull Requests und automatische Prüfungen, ohne eine eigene Dokumentationsplattform zu brauchen.
Ebenen des LLM-Wikis: Indizes, kuratierte Seiten, Archiv und unveränderliche Rohquellen
Der Confluence-Export hat das Material gesichert, bevor wir es neu geordnet haben
Den Umzug aus Confluence haben wir als einmaligen, endgültigen Wechsel behandelt. (Wenn Sie Ihren Confluence-Inhalten nur Fragen stellen möchten, statt Confluence zu verlassen, ist eine RAG-Pipeline die einfachere Lösung. Eine solche zeigen wir in Chat with your Confluence, auf Englisch.)
Der Exporter nutzte die offizielle Content-API von Confluence Cloud und bewahrte jede Seite in drei Formen auf:
- als lesbares Markdown mit Metadaten zur Herkunft
- als XHTML im Speicherformat von Confluence für den Seiteninhalt
- mit allen Anhängen, abgelegt neben der jeweiligen Seite
Zu den Metadaten gehörten die ursprüngliche Seiten-ID und URL, die Seitenhierarchie, die Version, die Autoren sowie Erstellungs- und Änderungsdatum. Exportiert haben wir 310 Seiten und 720 Anhänge. Persönliche Bereiche haben wir ausgelassen, weil dieses Repository für Firmenwissen gedacht war, nicht für persönliche Notizen.
Weil der Rohexport zuerst gesichert war, konnten wir beim aktiven Wiki entschlossen vorgehen. Wir konnten fünf zusammengehörige Confluence-Seiten zu einer Infrastrukturübersicht zusammenführen, ohne die Originale zu verlieren. Wir konnten eine ausufernde Seite in ein Runbook und eine Referenzseite aufteilen. Und wir konnten Atlassian-Textbausteine aus der aktiven Ebene entfernen und sie im Schnappschuss trotzdem behalten.
Der erste Durchlauf ergab rund 160 aktive und 90 archivierte Seiten. Die übrigen Quellseiten gingen in anderen Themen auf oder blieben nur als Rohmaterial erhalten. Die Migration hat das Material nach Themen neu geordnet und Quellseiten bei Bedarf zusammengeführt oder aufgeteilt.
Der Agent hat außerdem nützliche Screenshots an genau den Stellen in die kuratierten Seiten übernommen, an denen sie gebraucht werden. Das klingt langweilig, bis jemand ein Runbook aus der Buchhaltung befolgen muss, dessen sechs Screenshots "erfolgreich migriert" in einem unbeschrifteten Asset-Ordner gelandet sind.
Manche Fragen ließen sich aus dem Export nicht beantworten. Lief ein Dienst noch? Wurde eine vorgeschlagene Browser-Erweiterung je gebaut? Welcher von zwei verschiedenen Hostnamen war aktuell? Solche Fragen hat der Agent für die Klärung durch Menschen gesammelt. Die Antworten haben wir als neue Quellen festgehalten, bevor wir das Wiki aktualisiert haben.
Unklarheiten gibt der Agent an Menschen weiter, weil er Fehler einbauen kann, wenn er sie ohne neue Belege selbst auflöst.
Confluence-Migration: unveränderlicher Schnappschuss, Synthese und Klärung durch den Agenten, kuratierte Seiten
Selbstpflege ist ein kontrollierter Git-Workflow
In unserem aktuellen Ablauf fügt ein Mensch eine Quelle hinzu und startet den Coding-Agenten. Der Agent überwacht nicht selbstständig jedes System im Unternehmen. Die Quelle kann ein Besprechungsprotokoll sein, ein Kundengespräch, ein Dokument eines Lieferanten oder eine Änderung in einem Anwendungs-Repository.
Der Agent liest die gesamte Quelle, erkennt, was sich geändert hat, und sucht im Wiki nach betroffenen Themen. Er prüft, ob die Quelle einer bestehenden Seite widerspricht. Dann schlägt er Änderungen, neue Querverweise, Archivierungen oder eine neue Seite vor, falls das Wissen noch keinen passenden Platz hat.
Jede aktive Seite hat Frontmatter, das Folgendes festhält:
- eine verantwortliche Person
- das Datum, an dem ein Mensch die Seite zuletzt geprüft hat
- ihre Quellen
- ihren Status
- frei wählbare Tags
Der Status beschreibt das Vertrauen in die Seite, nicht den Schreibfortschritt.
current heißt geprüft und in Gebrauch. stale heißt, die Seite stimmte
einmal, wurde aber nicht erneut geprüft. stub heißt, dass schon die
fehlende Information es wert ist, festgehalten zu werden. superseded
verweist auf die Seite, die sie ersetzt.
Getroffene Entscheidungen sind unveränderlich. Ändert das Unternehmen seine Meinung, legt der Agent eine neue Entscheidung an und verknüpft beide Einträge. Das folgt derselben Logik wie Architectural Decision Records: Kontext und Folgen bleiben erhalten, statt die Geschichte so lange umzuschreiben, bis die alte Entscheidung unvernünftig aussieht.
Bevor eine Änderung zur Prüfung bereit ist, laufen zwei Skripte darüber:
Das erste prüft Metadaten, Quellpfade, defekte Links, ob alle Seiten im Index stehen, verwaiste Seiten und pfadspezifische Regeln. Das zweite sucht nach konkreten Angaben wie Datumswerten, Hostnamen, Befehlen und Kennungen, die in den zitierten Quellen nicht vorkommen.
Die Belegprüfung meldet Verdachtsfälle und gibt nicht vor, die Wahrheit beweisen zu können. Eine Umschreibung kann legitim sein. Ein Befehl, der aus einem nicht zitierten Dokument kopiert wurde, ist es nicht. Das entscheidet ein Mensch im Review.
Nach der Freigabe aktualisiert der Agent den passenden Index und trägt den Vorgang ins Log ein. Damit schließt sich der Kreis: Die nächste Sitzung eines Agenten sieht sowohl das aktuelle Wissen als auch, wie es entstanden ist.
Aus einer neuen Quelle wird ein einziges, geprüftes Change-Set für das ganze Wiki
Hierarchische Indizes lassen einfachen Dateien Raum zum Wachsen
Der verdächtig primitive Teil unseres Wikis ist index.md. Eine einzelne
Markdown-Datei kann nicht der vollständige Katalog eines Firmenwikis mit
Tausenden Seiten bleiben. Ihre Aufgabe muss sich also ändern, wenn das Wiki
wächst.
Bei mittlerer Größe kann der Root-Index jede Seite auflisten. Wächst das Wiki, wird er zum Wegweiser, der auf kleinere Indizes für einzelne Fachbereiche verweist:
Der Root-Index beantwortet, in welchem Teil des Unternehmens die Antwort wahrscheinlich steckt. Ein Bereichsindex grenzt das auf wenige Seiten ein. Die Seite selbst enthält die Details, Quellen, den Status, die verantwortliche Person, Tags und Links.
Wir dehnen nicht einen Index immer weiter, bis er nutzlos wird. Stattdessen wiederholen wir dasselbe Muster auf der Ebene, auf der eine weitere Wegentscheidung hilft. Der Agent aktualisiert diese Indizes, wenn Seiten verschoben oder geändert werden, und der Linter findet Seiten, die aus der Navigation verschwinden.
Agenten brauchen keine perfekte erste Suche
Herkömmliche Suchoberflächen setzen viel auf eine einzige Anfrage. Ein Mensch gibt einen Begriff ein und erwartet die richtige Seite weit oben in einer sortierten Trefferliste.
Coding-Agenten können anders suchen. Sie können mehrere Suchen parallel starten, die Begriffe in den ersten Treffern auswerten, schwache Anfragen umformulieren, Links folgen, Kandidaten vergleichen und die Git-Historie prüfen. Die erste Suche muss nur einen brauchbaren Hinweis für die nächste liefern.
Ein Agent, der eine Deployment-Anleitung sucht, sucht vielleicht nach
deploy, release, docker stack, dem Namen des Dienstes, seinem Hostnamen
und einer Repository-Kennung. Exakte Zeichenketten schlagen hier oft clevere
Abstraktionen. Um einen Hostnamen in einer Markdown-Datei zu finden, braucht
es keine höhere Mathematik. grep erledigt das bestens.
Coding-Agenten bringen schnelle Dateisuche, paralleles Lesen, das Auslesen
von Frontmatter und Volltextsuche mit Werkzeugen wie
ripgrep bereits mit. Das Wiki
liefert diesen Werkzeugen sauberen Text, vorhersehbare Pfade und explizite
Links.
Primitive Suche ist dadurch nicht automatisch genauer. Die Zuverlässigkeit kommt aus dem Ablauf drumherum. Der Agent kann veraltete Treffer verwerfen, mehrere Seiten gegeneinander abgleichen, die zitierten Belege prüfen und weitersuchen, wenn die erste Antwort unvollständig ist.
Schwierige Suchen werden zu Pflegeaufgaben
Wenn ein Agent eine Seite im Wiki nur mühsam findet, sagt uns das etwas. Die Seite braucht vielleicht eine bessere Zusammenfassung, einen alternativen Namen, einen weiteren Querverweis, einen genaueren Dateinamen oder einen anderen Ort.
Nachdem der Agent die Frage beantwortet hat, kann er diese Verbesserung vorschlagen. Die nächste Suche beginnt dann in einem besseren Wiki.
Mit Tausenden aktiven Seiten haben wir dieses Design noch nicht erprobt. Unser geplanter Weg: generierte Kataloge, Übersichten nach Verantwortlichkeiten, Volltextindizes oder spezialisierte Retrieval-Dienste ergänzen, sobald Messungen zu Navigation und Latenz das rechtfertigen. Markdown bleibt darunter die dauerhafte Wissensschicht. So bauen wir Infrastruktur dort aus, wo wir an echte Grenzen stoßen, statt mit einem Suchprojekt zu beginnen, bevor es überhaupt ein Wiki gibt, in dem sich die Suche lohnt.
Wie einfache Suche mit agentischer Suche skaliert
Spezialisierte Wissensmanagement-Systeme können dieselben Kontrollen mit einer besseren Oberfläche bieten
Git funktioniert für uns, weil wir ein technisches Unternehmen sind. Branches, Diffs, Pull Requests und Coding-Agenten nutzen wir ohnehin jeden Tag. Jemanden zu bitten, eine Änderung an einer Markdown-Datei zu prüfen, ist für uns normal. In vielen Unternehmen würde sich das anfühlen, als müsste man die Buchhaltungsrichtlinie in einem Terminal prüfen.
Die Architektur hängt an den Kontrollen, nicht am Befehl git. Ein
spezialisiertes Wissensmanagement-System kann dasselbe Modell unterstützen,
wenn es Folgendes bietet:
- eine vollständige Versionshistorie
- prüfbare Änderungen statt stillschweigender Überschreibungen
- die Rückkehr zu einer früher freigegebenen Version
- einen Freigabeprozess mit namentlich benannten Prüfern
- Quellen und Herkunftsangaben direkt an der vorgeschlagenen Änderung
- Verantwortlichkeiten, Vertrauensstatus und ein Audit-Log
- Berechtigungen und eine API, die Agenten nutzen können, ohne die Prüfung durch Menschen zu umgehen
Eine eigens dafür gebaute Oberfläche könnte diesen Ablauf besser abbilden als unser jetziges Repository. Sie könnte den Vorschlag eines Agenten neben der freigegebenen Seite zeigen, erklären, welche Quelle welche Änderung stützt, und Prüfern erlauben, einzelne Teile anzunehmen oder abzulehnen. Änderungen könnten automatisch an die verantwortliche Person gehen. Widersprüche und veraltete Aussagen könnten in einer Prüfwarteschlange auftauchen statt in einem Terminal-Bericht.
Dasselbe gilt für die Navigation. Ein spezialisiertes System braucht keine
wörtliche index.md, aber einfache Eingangstüren, die Agenten auslesen
können. Das können Startseiten der Fachbereiche sein, Kataloge, gefilterte
Sammlungen oder generierte Ansichten, die Dokumente mit kurzen
Zusammenfassungen, Verantwortlichen, Vertrauensstatus und Links zu verwandten
Bereichen auflisten. Das Format ist weniger wichtig als ein günstiger Weg für
den Agenten, die Suche einzugrenzen, bevor er ganze Dokumente öffnet.
Auch die Suche sollte nützliche Grundfunktionen anbieten statt nur eines Antwortfelds. Ein Agent muss mehrere Anfragen stellen, Kandidaten prüfen, einen anderen Begriff ausprobieren, Beziehungen folgen, nach Metadaten filtern und Quellen vergleichen können. Ein Wissensmanagement-System, das für diesen Ablauf gebaut ist, würde diese Schritte über eine stabile API anbieten und dem prüfenden Menschen den entstandenen Suchpfad zeigen.
So könnte Wissensmanagement künftig besser funktionieren: eine zugängliche Navigation für Menschen, einfache maschinenlesbare Eingangstüren für Agenten und eine agentische Suche, die durch mehrere schnelle Versuche besser wird, statt alles auf einen Suchbegriff zu setzen.
Für Buchhaltung, Vertrieb, Betrieb und andere Teams, die kein Git-Vokabular lernen sollten, um Firmenwissen zu pflegen, wäre das deutlich einfacher. Ein solches System könnte auch feinere Zugriffsrechte bieten als ein Repository, bei dem Lesezugriff meist jede Datei offenlegt.
Jeder Ersatz muss die Kontrollen aber beibehalten. Ein angenehmer Editor, der die Herkunft versteckt oder einen Agenten freigegebene Inhalte überschreiben lässt, wäre ein Rückschritt. Der Agent soll einen Vorschlag einreichen, die verantwortliche Person soll ihn annehmen, und das System soll sowohl die vorherige Version als auch den Grund für die Änderung aufbewahren.
Unser Git-Repository ist deshalb eine brauchbare Umsetzung und ein Zwischenschritt. Breitet sich das Wiki über das Entwicklungsteam hinaus aus, ist ein spezialisiertes Wissenssystem vielleicht das bessere Ziel. Seine Aufgabe wäre, Prüfung, Navigation und Freigabe zugänglicher zu machen, ohne den Prüfpfad darunter zu schwächen.
Der praktische Gewinn: weniger Dokumentations-Buchhaltung
Der unmittelbare Nutzen des LLM-Wikis ist unspektakulär, und bei internen Werkzeugen ist das meist ein gutes Zeichen. Menschen liefern eine Quelle und prüfen den Vorschlag, wie sie eingearbeitet wird. Sie müssen sich nicht mehr jede Seite merken, die davon betroffen ist.
Runbooks sagen jetzt, ob sie aktuell, veraltet, unvollständig oder abgelöst sind. Ein alter Ablauf kann als historischer Kontext verfügbar bleiben, ohne neben der heutigen Anleitung als gleichwertige Option zu erscheinen.
Auch Wissenslücken sind sichtbar. Unklare Zuständigkeiten für Infrastruktur, unvollständige Kontenübersichten und ungeprüfte Abläufe werden zu benannten Lücken. Damit sind sie Aufgaben, die man jemandem zuweisen kann, statt Überraschungen, die auf das nächste Audit oder den nächsten Vorfall warten.
Besonders nützlich sind die Aktualisierungen über Abteilungsgrenzen hinweg. Ändert sich etwas bei einem Lieferanten, kann das die Infrastrukturdokumentation, die Nachweise zu Sicherheitsfreigaben und eine kundenspezifische Deployment-Seite betreffen. Eine einzige geprüfte Aufnahme kann alle drei aktualisieren.
Auch Experimente werden strenger behandelt. Ein laufendes Experiment muss seine Kennzahl festlegen, bevor es beginnt. Ein abgeschlossenes Experiment hält Ergebnisse und Ausgang fest, auch ein Scheitern. Die gescheiterte Arbeit bleibt im Wiki, damit die nächste Person sie nicht in sechs Monaten mit großer Überzeugung noch einmal entdeckt.
Eine Prozentzahl für den Produktivitätsgewinn nennen wir bewusst nicht, denn wir haben keine gemessen. Was wir beobachten können, ist der Mechanismus: Pflegeaufgaben, die früher vom Gedächtnis abhingen, werden jetzt gemeinsam vorgeschlagen, geprüft und als Change-Set freigegeben.
Nach einigen Jahren wird das Wiki zum Gedächtnis des Unternehmens
Mit der Zeit wird das Repository vermutlich Tausende Seiten enthalten, die mit Zehntausenden Quellen verknüpft sind. Es würde festhalten, wie das Unternehmen arbeitet, was es entschieden hat, was Kunden sich gewünscht haben, welche Experimente gescheitert sind und wie sich Produkte und Infrastruktur verändert haben.
Ein drei Jahre altes Kundengespräch ist nicht schon deshalb nützlich, weil das Transkript noch existiert. Nützlich wird es, wenn seine relevanten Details bereits auf den Kunden-, Produkt- und Entscheidungsseiten stehen, die heute jemand aufschlägt.
Das erinnert an Vannevar Bushs Beschreibung des Memex aus dem Jahr 1945 in "As We May Think": ein dauerhafter Bestand an Aufzeichnungen, verbunden durch assoziative Pfade. Bush überließ es dem Besitzer, diese Pfade anzulegen und zu pflegen. Wir setzen für diese Pflege einen LLM-Agenten ein.
Die Oberfläche wird sich weiterentwickeln. Wir rechnen mit mehr Bereichsindizes, Dashboards zu Verantwortlichkeiten, Prüfwarteschlangen und generierten Katalogen. Das Fundament darf langweilig bleiben: Quellen unten, gepflegtes Wissen darüber und die Git-Historie, die beides verbindet.
Das Firmenwiki als Langzeitgedächtnis, nach Themenbereichen geordnet
Die Prüfung durch Menschen bleibt nötig
Ein LLM-Agent kann nicht prüfen, ob ein alter Ablauf noch funktioniert, indem er den alten Ablauf liest. Er kann keine Systemänderung erkennen, die niemand festgehalten hat. Er kann nicht wissen, welche Seite eines echten Widerspruchs recht hat oder ob die Quelle selbst einen Fehler enthält.
Unsere Migration hat das schmerzhaft deutlich gemacht. An einer Stelle schloss das kompilierte Wiki, dass abgeschaltete Infrastruktur noch Geld kostet, weil keine Quelle ihre Stilllegung festhielt. Die Schlussfolgerung klang plausibel und war falsch. Ein Mensch hat die Frage beantwortet, und diese Antwort wurde zu einer neuen Quelle.
Deshalb hat jede Seite eine verantwortliche Person und ein Prüfdatum. Der Linter findet einen defekten Link. Die Belegprüfung findet einen Hostnamen, der in den zitierten Dokumenten fehlt. Keiner von beiden kann bestätigen, dass die Produktivumgebung noch zum Runbook passt.
Auch die Zugriffskontrolle ist eine Grenze. Ein Git-Repository bietet nicht dieselben Berechtigungen auf Seitenebene wie ein gehostetes Wiki. Wer das Repository klonen kann, kann meist auch die Rohanhänge lesen, einschließlich historischer Dateien. Die Aufteilung der Repositorys und die Zugriffsregeln müssen das berücksichtigen.
Auch der Modell-Endpunkt und die Agentenumgebung gehören zur Sicherheitsgrenze. Unsere Quellen können Verträge, Kundengespräche und Anhänge enthalten. Ein produktiver Aufbau braucht eine genehmigte Richtlinie zur Datenaufbewahrung, eine zur Quelle passende Berechtigung, eine Behandlung importierter Texte als nicht vertrauenswürdige Daten, eingeschränkte Berechtigungen für Tools und die Prüfung durch einen Menschen, bevor geschrieben wird. Eine in einem Quelldokument versteckte Prompt Injection darf nicht zur Anweisung an den Pflege-Agenten werden.
Das System geht davon aus, dass Agenten Grenzen und Kontrolle brauchen. Wer die mühsamen Teile automatisiert, nimmt den Menschen, die das Unternehmen kennen, die Verantwortung nicht ab.
Beginnen Sie mit einer Quelle und einem Pflegevertrag
Um dieses Muster zu testen, müssen Sie keine 310 Seiten migrieren.
Legen Sie ein Repository mit raw/, wiki/, index.md, log.md und einer
Datei AGENTS.md an. Legen Sie eine Quelle in raw/, sagen Sie dem Agenten,
dass Quellen unveränderlich sind, und bitten Sie ihn, eine belegte Seite mit
sichtbarem Link zur Quelle anzulegen.
Fügen Sie dann eine zweite Quelle hinzu, die etwas an der ersten ändert. Das ist der aussagekräftige Test. Achten Sie darauf, ob der Agent die bestehende Seite aktualisiert, den Widerspruch festhält und beide Quellen bewahrt. Ein System, das nur eine weitere Zusammenfassung erzeugt, hat das Ziel verfehlt.
Sobald sich der Ablauf richtig anfühlt, ergänzen Sie Prüfungen: ob die Quellen existieren, ob Links defekt sind, ob alle Seiten im Index stehen und ob die Pflicht-Metadaten vorhanden sind. Lassen Sie die Struktur mit den echten Dokumenten wachsen. Unser eigenes Schema wurde nach der Migration einfacher, weil eine frühe Einteilung in Seitentypen Arbeit gemacht, die Suche aber nicht verbessert hatte.
Karpathys ursprüngliche Ideendatei zum LLM-Wiki ist bewusst abstrakt gehalten. Geben Sie sie Ihrem Coding-Agenten, ergänzen Sie die Regeln, die Ihr Unternehmen braucht, und lernen Sie aus den ersten Aufnahmen, bevor Sie die große Wissensarchitektur entwerfen.
Wenn Sie dieses Muster auf Ihre eigene Dokumentation anwenden möchten, etwa beim Abschied von Confluence: Unser Team für KI-Beratung setzt Wissens- und Agentenprojekte wie dieses gemeinsam mit Unternehmen um.
FAQ zu Firmenwikis, die ein LLM pflegt
Was ist ein von einem LLM gepflegtes Wiki?
Eine dauerhafte Sammlung miteinander verlinkter Seiten, die ein LLM-Agent aktualisiert, sobald neue Quellen hinzukommen. Der Agent übernimmt Ablage, Zusammenführung, Querverweise und Routineprüfungen. Menschen liefern Quellen, klären Unklarheiten und prüfen Änderungen.
Wie verhindern Sie, dass das LLM Fakten über das Unternehmen erfindet?
Jede wesentliche Aussage muss auf eine Originalquelle verweisen. Seiten haben Verantwortliche, Prüfdaten und einen Vertrauensstatus. Automatische Prüfungen finden fehlende Quellen und verdächtige Angaben, und das Review in Git sorgt dafür, dass bei jeder Freigabe ein Mensch beteiligt ist. Diese Kontrollen verringern unbelegte Aussagen. Sie können nicht beweisen, dass jede Quelle und jede Interpretation stimmt.
Lässt sich ein Firmenwiki aus Markdown auf Tausende Seiten skalieren?
Getestet haben wir diese Struktur mit rund 160 aktiven Seiten, nicht mit Tausenden. Unser geplanter Weg: ein kleiner Root-Index, der auf Indizes für Bereiche und Unterbereiche verweist, und später generierte Kataloge oder eine Volltextsuche, wenn gemessene Daten zu Navigation und Latenz das rechtfertigen. Die Markdown-Dateien als maßgebliche Quelle müssen sich dafür nicht ändern, aber im größeren Maßstab muss sich das Design erst noch bewähren.
Sie möchten zuverlässige KI-Agenten-Systeme bauen?
Wir haben auf Basis aktueller Forschung einen ausführlichen Leitfaden (auf Englisch) erstellt, wie Sie robuste KI-Agenten-Systeme bauen, die auch im produktiven Betrieb funktionieren. Der Leitfaden behandelt:
- die 14 systematischen Fehlerquellen in Multi-Agenten-Systemen
- belegte Best Practices für das Design von Agenten
- strukturierte Kommunikationsprotokolle und Prüfmechanismen
Weiterlesen
- Zuverlässige KI-Agenten-Systeme bauen
- Building AI Agents from Scratch (auf Englisch)
- Advanced AI Agents (auf Englisch)
- Integrating enterprise knowledge with LLMs: fine-tuning, training or RAG (auf Englisch)
- SharePoint-Listen als Wissensquelle in Copilot Studio nutzen
- RAG mit Azure AI Search
Über den Autor
Andreas Nigg
Mitgründer, Pondhouse Data
Andreas entwickelt seit mehr als acht Jahren Datenanwendungen. Bei Pondhouse Data konzipiert und baut er KI-Systeme und integriert sie in komplexe, gewachsene Unternehmensumgebungen.
