InfoForge: Offline-Wikipedia als RAG-Quelle für meine lokalen KI-Agenten

Ich fragte ein lokales 8B-Modell, wer Kokoro geschrieben hat und wann es veröffentlicht wurde. Es antwortete: „Natsume Sōseki, 1914.“ Anschließend nannte es den Wikipedia-Artikel, aus dem es diese Information hatte. Das Modell wusste dieses Faktum eigentlich nicht – es hat es in einer 52,69 GB großen Kopie der Wikipedia nachgeschlagen, die auf einem Rechner bei mir zu Hause liegt; dabei spielte das Internet überhaupt keine Rolle.

Warum das nötig ist – obwohl das Modell ja „Dinge weiß“

Weil es das in Wirklichkeit nicht tut; der Fehlermodus ist dabei besonders problematisch. Ein kleines Modell liefert bei Fragen nach Daten, chemischen Eigenschaften oder Ortsnamen flüssige, zuversichtlich klingende Antworten – ohne irgendein Signal dafür, ob sie wahr sind. Es lügt nicht; es verfügt schlicht über keinen Mechanismus, um Erinnerung von generierten Antworten zu unterscheiden. Das ist für Texte in Ordnung – für Fakten jedoch katastrophal.

Eine Retrieval-Lösung behebt das Problem – doch die üblichen Ansätze setzen dabei eine Cloud-Such-API voraus: Die Frage gelangt zu einem Unternehmen, dieses protokolliert sie; die Nutzbarkeit des Assistenten hängt nun vom Betriebszustand und den Bedingungen jenes Unternehmens ab. In meinem Haushalt, wo meine Kinder Fragen an die KI stellen, gefällt mir keiner dieser Aspekte.

Wikipedia löst beide Probleme auf einen Schlag: Es ist das dichteste verfügbare Wissensspektrum; es kann vollständig legal und praktisch heruntergeladen werden; außerdem passt es auf eine Festplatte, die weniger kostet als ein Abendessen. Das Kiwix-Projekt übernimmt seit Jahren die komplexe Aufgabe, gesamte Wikis in das komprimierte, indexierte ZIM-Format zu verpacken – für den Offline-Gebrauch in Schulen, auf Schiffen und an Orten ohne Internetzugang. Ich lasse lediglich eine KI darauf zugreifen statt eines Browsers.

Was am Ende dabei herauskommt

Eine Frage kommt herein, eine Antwort geht hinaus – samt einem Quellenverzeichnis, das exakt angibt, welche Wikipedia-Artikel zur Antwort beigetragen haben. Etwa so:

$ infoforge "Who wrote Kokoro and when was it published?"

Kokoro was written by Natsume Sōseki and published in 1914.

Sources:
  - Kokoro

Auf den ersten Blick unspektakulär. Entscheidend ist jedoch, was nicht passiert: Keine Netzwerkabfrage verlässt das Haus; nichts wird bei irgendeinem Provider protokolliert; das Modell wird strukturell daran gehindert, aus dem Gedächtnis zu antworten. Hätte die Suche keine Treffer geliefert, hätte das Tool einen Fehlercode ausgegeben – statt eine leere Antwort zu generieren.

So funktioniert es

Fünf Phasen – keine davon besonders raffiniert; genau so soll es sein.

Schlüsselwort-Extraktion: Die Frage ist nicht die eigentliche Suche. „Who wrote Kokoro and when was it published?“ ist ein schlechter Suchbegriff; Kokoro hingegen ist gut. Ein paar Dutzend Zeilen Code reichen aus, um dies zu bewerkstelligen – ich habe sie bislang nicht ersetzt.

Suche: Kiwix’ Volltextsuche basiert auf einem echten Index, nicht auf einer simplen grep-Abfrage; das macht das Ganze überhaupt möglich. Bei 19,19 Millionen Einträgen liefert sie sortierte Titel in 3 bis 30 Millisekunden. In diesem System gibt es weder Embeddings noch einen Vektor-Datenbank oder ein Chunk-Repository – Wikipedia-Editoren haben die „Chunks“ bereits erstellt; sie nennen sie Artikel.

Abruf und Kürzung: Die Top-Ergebnisse werden als vollständige Artikel in jeweils etwa 0,5 Millisekunden geliefert. Das Kürzen ist der einzige Teil, bei dem Urteilsvermögen erforderlich ist: Die Einleitungen enthalten meist die relevanten Fakten; daher wird das Token-Limit von oben nach unten ausgeschöpft – genug pro Artikel, damit er für sich steht, aber nicht so viel, dass die folgende Anweisung untergeht.

Der fundierte Prompt: Die Artikel werden in den Prompt eingefügt; dabei wird das Modell angewiesen, ausschließlich aus diesen Quellen zu antworten und die Titel zu zitieren. Das ist der Kern des Verfahrens – es handelt sich dabei jedoch nur um einen Prompt, keine Garantie; daher folgt nun der nächste Abschnitt.

Das Modell: Ein lokales Reasoning-Modell (DeepSeek-R1 8B auf meinem GPU-Server) generiert die Antwort. Im „warmen“ Zustand dauert der gesamte Prozess etwa 8 Sekunden – wobei davon rund 7,9 Sekunden das Modell für seine Überlegungen benötigt. Die Retrieval-Komponente ist kostenlos; Denken hingegen nicht.

Fundierung als Ablehnungsvertrag

Dies ist die Entscheidung, die ich am nachdrücklichsten verteidigen würde – und sie ist keineswegs technischer Natur.

Ein Prompt wie „Verwenden Sie ausschließlich diese Quellen“ ist lediglich eine Bitte. Meist befolgen Modelle sie; manchmal ignorieren sie sie jedoch stillschweigend – insbesondere wenn die Quellen dünn sind und das Modell zufällig ein passendes Gedächtnis hat. Ist das einzige Verteidigungsmittel des Systems jener Satz, dann ist „fundiert“ lediglich ein Gefühl.

Daher wird die Fundierung außerhalb des Modells erzwungen: Wenn die Suche keine brauchbaren Ergebnisse liefert, übergibt das Tool dem LLM nicht einfach die unveränderte Frage als Ausweichlösung – es scheitert stattdessen und gibt dabei einen Fehlercode zurück. Dieser Code ist das einzige Signal, das alle aufrufenden Programme ohnehin erkennen können. Die KI-Agenten, die es nutzen, sind zudem angewiesen, einen fehlgeschlagenen Abruf zu melden statt eine aus dem Gedächtnis erratene Antwort zu generieren. Eine Ablehnung bleibt erhalten; sie wird nicht durch höhere Ebenen abgemildert.

Das Ergebnis ist ein Assistent, der offen zugibt, dass er etwas nicht finden konnte. Auf einer Feature-Liste wirkt das wie eine Schwäche – in Wahrheit ist es das Gegenteil. Ein Modell, das sagt: „Ich habe es nicht gefunden“, ist wertvoller als ein größeres Modell, das etwas erfindet, denn Ersteres kann man weiterverwenden; bei Letzterem muss man jede Antwort erst noch auf ihre Richtigkeit prüfen – und wenn man das bei jeder Antwort tun muss, hat man sich überhaupt keinen Aufwand erspart.

Datenschutz ist Architektur, keine Politik

Jeder große Assistent verfügt über eine Datenschutzerklärung. Dieser hier besitzt stattdessen eine Topologie: Die Frage wandert vom Terminal zum Suchindex im selben LAN zum Modell im selben LAN und zurück. Es gibt keinen Provider, der sie protokollieren könnte; keinen Schlüssel, der mich identifiziert; keine Nutzungsbedingungen, die sich im nächsten Quartal ändern könnten. Mein Kind kann ihm etwas Peinliches fragen – und der Vorgang bleibt so privat, als würde man in einem Buch nachschlagen, denn genau das geschieht funktional gesehen.

Niemand muss mir dabei vertrauen; das ist das Gute daran. Man kann es überprüfen, indem man das Internet abzieht – und siehe da: Es arbeitet weiter.

Die unspektakulären 90 %

Die eigentliche Pipeline zu entwickeln war ein angenehmes Wochenendprojekt. Der wahre Aufwand lag in drei Container-Parametern.

Der Wikipedia-Server läuft als rootloser Container auf einem immutablen Linux-Desktop mit aktiviertem SELinux – und jedes dieser Attribute bereitete mir Abende voller Arbeit:

• Rootlose Benutzermapping: Der Container muss innerhalb seines eigenen Namensraums als Root laufen; dieser wird nach außen auf meinen unprivilegierten Benutzer abgebildet. Macht man das falsch, startet der Server, meldet sich als gesund – liefert aber nichts, weil er schlicht nicht in der Lage ist, die angegebene Datei zu lesen.
• SELinux-Neuetikettierung: Ein Volume, das in einen Container eingebunden wird, benötigt bei einem SELinux-System eine spezielle Mount-Option, um die Neuetikettierung durchzuführen; andernfalls verweigert das Kernel-Policy den Zugriff – der Fehler zeigt sich als „Datei fehlt“, wodurch man am falschen Ort sucht.
• Explizite Dateipfade: Die automatische Erkennung des ZIM-Verzeichnisses funktionierte innerhalb der Container-Ansicht nicht so, wie die Dokumentation es vorgab. Nachdem ich aufgehört hatte, an ein anderes Problem zu denken, dauerte es nur noch 30 Sekunden, bis ich die Datei explizit benannt hatte.

Drei Parameter – sie beanspruchten rund 90 % der gesamten Entwicklungszeit. So sieht die Realität bei der meisten Selbst-Hosting-Arbeit aus; genau dieser Teil wird in Tutorials aber ausgelassen – weshalb viele Leute glauben, sie seien dafür ungeeignet, obwohl sie es lediglich zum ersten Mal allein mit denselben drei Parametern versuchen.

Dann starb es – und niemand bemerkte es

Es funktionierte. Es war schnell. Ich testete es, notierte die Ergebnisse und machte weiter.

Eine Woche später wollte ich es erneut nutzen – doch es war verschwunden. Irgendwann hatte sich der Rechner neu gestartet; der Container war nicht mehr da. Mir wurde nichts mitgeteilt – schließlich gab es weder eine Service-Einheit, noch Überwachung oder Gesundheitschecks. Schlimmer noch: Die „Skill-Datei“, die meinen KI-Agenten mitteilen sollte, dass dieses Tool existiert, war lediglich als Entwurf vorhanden und nie installiert worden. Somit antworteten alle Agenten in dieser Woche aus dem Gedächtnis – obwohl sie eigentlich nachschlagen hätten können – und wussten nicht einmal, dass ihnen eine Option fehlte.

Die Lektion ist kurz genug, um sich zu merken:

Eine Funktion, die weder automatisch startet noch von irgendjemandem bekannt ist, unterscheidet sich in nichts von einer Funktion, die man nie erstellt hat.

Die Lösung bestand aus einer 12 Zeilen langen Service-Einheit sowie einer Markdown-Datei. Die Service-Einheit sorgt dafür, dass der Server nach einem Neustart weiterläuft. Die Markdown-Datei fungiert als „Shared Skill“ im Agenten-Stack – sie teilt den Agenten mit, dass das Tool existiert, wie man es aufruft (per Shell-Befehl oder per HTTP) sowie dass Antworten stets mit Zitaten versehen werden müssen.

Der gesamte Aufbau umfasste 700 Zeilen Code – doch erst diese dreizehn Zeilen machten alles möglich. Ich lerne das immer wieder aufs Neue.

In den Agenten-Stack integriert

Ich betreibe eine kleine Flotte lokaler KI-Agenten für Haushalts- und Geschäftsaufgaben. InfoForge ist nun eine „geteilte Fähigkeit“ – kein bloßes Skript, das ich mir merken muss. Ein Agent, der Informationen benötigt, führt den entsprechenden Befehl aus oder ruft den Endpunkt auf; er erhält eine Antwort samt Zitaten, die er weiterleitet. Diese Zitate sind wichtiger, als es scheint: Wenn ein Agent mir etwas mitteilt und dabei den Artikel nennt, kann ich diesen per Klick überprüfen – und genau das macht aus einem „plausiblen“ Assistenten einen tatsächlich nutzbaren.

InfoForge arbeitet zudem mit allen anderen Systemen im Haus zusammen. Derselbe GPU-Server beantwortet InfoForge-Anfragen, entwirft E-Mails und führt Chats durch; die Wissensschicht ist somit ein weiteres Element, das keinerlei Registrierung erfordert.

Stolpersteine

• Genügend Festplattenspeicher vor dem Download: Ca. 53 GB für die „no-images“-Version – bei Bildern etwa doppelt so viel. Prüfen Sie den freien Speicherplatz zuvor; ein halbfertiger ZIM-Download ist eine langsame Art, das herauszufinden.
• Das Datenpaket hat ein Datum: Mein Paket stammt vom Juni 2026. Wikipedia hört nicht auf, neue Inhalte hinzuzufügen – doch für dieses System existieren alle Informationen, die jünger als das Datum des Pakets sind, nicht. Das ist in Ordnung, wenn man es weiß – ansonsten eine Falle.
• Die Suchqualität hängt von der Schlüsselwort-Extraktion ab: Fast jede schlechte Antwort resultiert aus einer schlechten Abfrage – nicht aus einem schlechten Modell. Verbessern Sie die Extraktion, bevor Sie ein größeres Modell einsetzen.
• Die Kontextlänge ist eine bewusste Entscheidung: Zu wenig Kontext führt zu unvollständigen Antworten; zu viel führt dazu, dass das Modell von den Anweisungen abweicht. Passen Sie die Einstellung an reale Fragen an – nicht an synthetische.
• Testen Sie auch den Fehlerfall: Stellen Sie eine Frage, zu der Wikipedia keinen Artikel hat; vergewissern Sie sich, dass Sie eine Ablehnung sowie einen nicht-nullen Exit-Code erhalten – kein flüssiger Text. Testen Sie nur funktionierende Fragen, und Sie haben lediglich die „leichte“ Hälfte getestet.
• Erstellen Sie die Service-Einheit bereits am ersten Tag: Siehe oben. Fragen Sie mich, woher ich das weiß.

Wo stehe ich jetzt?

Mein Haus verfügt nun über eine offline verfügbare Enzyklopädie samt Suchindex – sowie eine KI, die ausschließlich aus diesen Daten antworten darf. Der Aufwand bestand lediglich aus einem Download und einem Wochenende Arbeit. Das System ist schneller als das Internet, funktioniert auch bei Ausfällen, kann nicht „abgeschaltet“ werden – und verlangt kein Geschäftsmodell von mir.

Als Nächstes kommen weitere ZIM-Pakete ins Spiel: medizinische und technische Sammlungen aus den Kiwix-Paketen sowie ein oder zwei eigene Wikis. Die Abrufschicht kümmert sich schließlich nicht darum, um welche Inhalte es sich handelt. Und natürlich brauche ich noch einen Gesundheitscheck – denn diese Lektion habe ich mittlerweile auf die harte Tour gelernt.

Downloads

• Download InfoForge project source (zip) 80 KB

Kostenlos für die private Nutzung. Wenn es dir einen Nachmittag erspart, ist der Kaffee-Button gleich in der Nähe.