Das rag system wiki: Wissensquelle für Entwickler und Forscher

Autor: Provimedia GmbH

Veröffentlicht:

Aktualisiert:

Kategorie: KI-Tools & Workflows

Wiki-RAG als MediaWiki-Wissensquelle für Sprachmodelle

Wiki-RAG macht ein MediaWiki nicht nur lesbar, sondern als Wissensquelle für Sprachmodelle nutzbar. Das System greift Inhalte über die MediaWiki-API ab und bereitet sie für wissensgestützte Antworten auf. Für Entwickler und Forscher entsteht damit eine Verbindung zwischen redaktionell gepflegten Wiki-Seiten und einer KI-Anwendung, die Fragen in natürlicher Sprache verarbeitet.

Der entscheidende Vorteil liegt in der Herkunft des Wissens: Die Antworten können auf vorhandenen Seiten, Kategorien und Fachinhalten einer konkreten MediaWiki-Instanz aufbauen. Das ist besonders nützlich, wenn ein Modell nicht nur allgemeines Weltwissen verwenden soll, sondern Informationen aus einer bestimmten Dokumentationsumgebung benötigt. Dazu zählen etwa Lehrinhalte, technische Handbücher, Projektwissen oder interne Fachbegriffe.

Vom Wiki-Eintrag zur nutzbaren Wissensbasis

MediaWiki-Seiten enthalten oft mehr als reinen Fließtext. Überschriften, Links, Kategorien und Namensräume geben den Inhalten eine fachliche Ordnung. Beim Einlesen muss diese Struktur deshalb möglichst erhalten bleiben. Sie hilft später dabei, einen gefundenen Abschnitt richtig einzuordnen und verwandte Inhalte zu berücksichtigen.

Wiki-RAG übernimmt dabei im Kern vier Aufgaben:

Die Antwort entsteht somit nicht allein aus dem Modell. Sie basiert auf einer Kombination aus Nutzerfrage, abgerufenen Wiki-Inhalten und generativer Verarbeitung. Für Forschungsprojekte ist diese Trennung wertvoll: Die Wissensquelle bleibt sichtbar, während das Modell die sprachliche Darstellung übernimmt.

Warum MediaWiki für Entwickler interessant ist

MediaWiki eignet sich als Wissensquelle, weil Inhalte von mehreren Personen gepflegt, verlinkt und schrittweise erweitert werden können. Änderungen bleiben zudem in der Versionsgeschichte nachvollziehbar. Ein RAG-System kann diese redaktionelle Arbeit nutzen, ohne dass das Sprachmodell selbst neu trainiert werden muss.

Das schafft einen praktischen Entwicklungsweg: Ein Team pflegt Fachwissen im Wiki, während die KI-Anwendung dieses Wissen bei Anfragen abruft. Neue Seiten lassen sich so in den Wissensbestand aufnehmen, ohne das gesamte Modell anzupassen. Ganz reibungslos ist das nicht; der Index muss den aktuellen Stand der Quelle kennen. Trotzdem bleibt der Änderungsweg deutlich schlanker als ein erneutes Training.

OpenAI-kompatible Schnittstelle für Tests und Prototypen

Wiki-RAG stellt zusätzlich eine OpenAI-kompatible API bereit. Für Entwickler ist das hilfreich, weil bestehende Clients und Testskripte oft mit wenig Anpassung weiterverwendet werden können. Eine Anwendung kann dadurch Fragen an die Wiki-Wissensbasis senden, ohne eine komplett eigene Kommunikationsschicht zu bauen.

Für die Forschung eröffnet das mehrere Möglichkeiten:

Besonders aufschlussreich ist der Vergleich zwischen einer Antwort ohne Wiki-Kontext und einer Antwort mit abgerufenen Seiten. So wird sichtbar, ob das System tatsächlich fachlich passende Informationen findet oder nur sprachlich überzeugend wirkt.

Geeignet für Wissensräume mit klarer fachlicher Herkunft

Wiki-RAG spielt seine Stärke dort aus, wo die Wissensquelle feststeht und fachlich begrenzt ist. Ein Entwickler kann etwa ein MediaWiki mit API-Dokumentation, Kursmaterialien oder Forschungsnotizen anbinden. Die Nutzerfrage muss dann nicht exakt den Wortlaut einer Wiki-Seite wiederholen. Entscheidend ist, dass der gesuchte Inhalt in den verfügbaren Seiten enthalten und auffindbar ist.

Für Forscher ist außerdem die Abgrenzung der Quelle wichtig. Ein System mit einem klar definierten Wiki lässt sich leichter untersuchen als eine Anwendung, die beliebige Webinhalte vermischt. Dadurch können Versuchsaufbau, Datenbasis und Ergebnis besser dokumentiert werden. Das klingt trocken, ist aber für belastbare Experimente ziemlich entscheidend.

Als Ausgangspunkt dient das öffentliche Repository moodlehq/wiki-rag unter einer BSD-3-Clause-Lizenz. Die dort beschriebene Lösung ist als experimentelles Projekt einzuordnen. Für Entwickler bietet sie damit vor allem eine konkrete Grundlage, um die Verbindung von MediaWiki, Vektorsuche und Sprachmodellen praktisch zu untersuchen.

Abruf und Verarbeitung von Wiki-Inhalten über die MediaWiki-API

Die MediaWiki-API liefert Wiki-RAG einen kontrollierten Zugang zu Seiten, Revisionen und Metadaten. Für den Abruf wird meist der API-Endpunkt der jeweiligen Website verwendet. Die genaue Adresse hängt von der Installation ab, häufig endet sie auf api.php. Dadurch kann eine Anwendung Inhalte automatisiert laden, statt HTML-Seiten einzeln auszulesen.

Für einen sauberen Import sind zunächst klare Abrufregeln nötig. Dazu gehören die erlaubten Websites, relevante Namensräume und der Umgang mit Weiterleitungen. Ein Wiki kann etwa neben Artikeln auch Vorlagen, Diskussionen oder Benutzerseiten enthalten. Werden diese Bereiche ungefiltert eingelesen, landen schnell Inhalte im Bestand, die für fachliche Antworten kaum Wert besitzen.

Die API arbeitet mit begrenzten Antwortmengen. Bei großen Wikis muss der Abruf deshalb seitenweise erfolgen. Dafür liefert MediaWiki Fortsetzungsmarken, mit denen der nächste Datenblock angefordert wird. Ein Importskript sollte diese Marken zuverlässig speichern und verarbeiten. Sonst fehlen am Ende still einige Seiten – ein kleiner technischer Fehler mit großer Wirkung.

Nach dem Abruf wird der API-Inhalt in eine verarbeitbare Textform überführt. Überschriften sollten als Abschnittsgrenzen erhalten bleiben. Tabellen, Listen und Vorlagen benötigen dagegen eine eigene Behandlung, weil ihr Rohformat für Sprachmodelle schwer lesbar sein kann. Auch Quelltextblöcke sollten nicht wie gewöhnliche Prosa behandelt werden. Bei technischer Dokumentation kann ihr Inhalt zwar zentral sein, doch seine Bedeutung hängt stark von der Darstellung ab.

Jeder importierte Abschnitt sollte außerdem mit Herkunftsdaten verbunden bleiben. Sinnvolle Felder sind der Seitentitel, die Webadresse, der Namensraum, die Revisionskennung und der Zeitpunkt des Abrufs. Diese Angaben helfen bei der Fehlersuche und machen spätere Antworten nachvollziehbarer. Für Forschungsversuche sind sie besonders nützlich, weil sich eine verwendete Wissensgrundlage exakt dokumentieren lässt.

Änderungen lassen sich über Revisionsinformationen erkennen. Statt jede Seite bei jedem Lauf vollständig neu zu übertragen, kann ein Importprozess bekannte Revisionen mit dem aktuellen Stand vergleichen. Geänderte Seiten werden erneut verarbeitet, unveränderte Inhalte bleiben bestehen. Gelöschte Seiten brauchen ebenfalls eine klare Behandlung: Sie dürfen nicht dauerhaft im Suchbestand bleiben, wenn sie in der Quelle nicht mehr vorhanden sind.

Die MediaWiki-API unterstützt verschiedene Abfragearten. Für einen gezielten Bestand sind etwa Titel- oder Kategorieabfragen sinnvoll. Für historische Untersuchungen können Revisionen und Zeitstempel entscheidend sein. Welche Methode passt, hängt vom Forschungsziel ab: Ein aktueller Frage-Antwort-Dienst braucht einen anderen Import als eine Studie zur Entwicklung eines Wikis.

Beim Betrieb sollte der Abruf die Quelle nicht unnötig belasten. Begrenzte Anfragegeschwindigkeit, Wiederholungsversuche bei Netzfehlern und Protokolle für fehlgeschlagene Seiten gehören daher in einen robusten Importprozess. Auch API-Änderungen oder ungewöhnliche Seitentypen sollten sichtbar gemeldet werden. Ein Import, der Fehler einfach verschluckt, wirkt zwar bequem, erzeugt aber einen trügerisch vollständigen Wissensbestand.

Die Verarbeitung endet erst, wenn der Inhalt fachlich brauchbar vorliegt. Wiki-RAG kann dann die ausgewählten Abschnitte für die spätere Suche bereitstellen. Die Qualität dieses Schritts hängt nicht nur vom Modell ab, sondern auch davon, ob Seitengrenzen, Revisionen und Quellenangaben korrekt erhalten wurden. Genau hier entscheidet sich, ob aus einem Wiki eine belastbare Wissensquelle oder nur ein großer Textstapel wird.

Vektorsuche und Kontextübergabe an das Sprachmodell

Die Vektorsuche bewertet, welche Wissensabschnitte am besten zu einer Anfrage passen. Dafür wird die Frage in eine numerische Darstellung überführt, die den semantischen Inhalt abbildet. Das System vergleicht diese Darstellung mit den gespeicherten Abschnittsvektoren. Hohe Ähnlichkeit bedeutet dabei nicht automatisch sachliche Richtigkeit, sondern zunächst nur eine gute inhaltliche Nähe.

Für Wiki-RAG ist diese Unterscheidung wichtig. Ein Abschnitt kann dieselben Begriffe wie die Frage enthalten und trotzdem am eigentlichen Informationsbedarf vorbeigehen. Umgekehrt kann ein fachlich passender Abschnitt andere Wörter verwenden. Die Suchqualität hängt daher von der Kombination aus Vektormodell, Abschnittsgröße und Suchstrategie ab.

In der Praxis werden zunächst mehr Treffer abgerufen, als später im Antwortkontext landen. Eine Suche nach beispielsweise 20 Kandidaten schafft Auswahl. Danach kann eine Rangfolge die besten Abschnitte bestimmen. Dieses Vorgehen wird oft als Reranking bezeichnet. Es berücksichtigt neben semantischer Nähe auch Faktoren wie Titel, Abschnittsposition oder exakte Schlüsselbegriffe.

Die Auswahl muss auch zum verfügbaren Kontextfenster des Sprachmodells passen. Zu viele Treffer erhöhen zwar die Informationsmenge, können aber wichtige Aussagen verdecken. Außerdem steigen Verarbeitungszeit und Kosten. Ein kleiner, gut sortierter Kontext ist daher oft wirksamer als eine lange Sammlung nur halbpassender Textstücke.

Bei Wiki-Inhalten sollten zusammengehörige Abschnitte möglichst gemeinsam betrachtet werden. Eine Definition kann in einem Abschnitt stehen, während die Einschränkung erst im folgenden Absatz folgt. Ein Retrieval-System kann deshalb Nachbarabschnitte ergänzen oder den Treffer auf eine vollständige Wiki-Sektion erweitern. So bleibt der fachliche Zusammenhang erhalten, ohne gleich die gesamte Seite zu übertragen.

Vor der Übergabe wird der gefundene Inhalt meist in ein festes Nachrichtenformat eingebettet. Dazu gehören die Nutzerfrage, die Wissensabschnitte und klare Regeln für die Antwort. Das Sprachmodell sollte erkennen können, welcher Text als Quelle dient und welche Aufgabe es ausführen soll. Eine mögliche Anweisung lautet sinngemäß: Nutze nur den bereitgestellten Kontext und kennzeichne fehlende Informationen offen.

Die Quellenangaben können als Titel, Link oder Revisionskennung neben dem jeweiligen Abschnitt erscheinen. Dadurch erhält die Ausgabe eine prüfbare Spur. Für Entwickler ist das zudem praktisch, weil sich fehlerhafte Antworten auf zwei mögliche Ursachen zurückführen lassen: Der Suchschritt hat den falschen Inhalt geliefert oder das Modell hat den passenden Inhalt falsch interpretiert.

Ein belastbarer Test betrachtet diese beiden Ebenen getrennt. Beim Retrieval zählen etwa Trefferquote, Rangposition und Anteil relevanter Abschnitte. Bei der Antwort zählen sachliche Genauigkeit, Vollständigkeit und die korrekte Nutzung des Kontexts. Ein System kann bei der Suche gut abschneiden und dennoch schlechte Antworten erzeugen, wenn die Übergabe unklar formuliert ist.

Für Forschungsversuche lohnt sich ein fester Testsatz mit typischen, mehrdeutigen und bewusst schwierigen Fragen. Jede Frage sollte mit den erwarteten Wiki-Abschnitten verknüpft werden. So lässt sich prüfen, ob Änderungen an Suchparametern tatsächlich helfen oder nur zufällig bessere Einzelantworten erzeugen. Gerade diese nüchterne Messung trennt einen brauchbaren Prototyp von einer hübschen Demo.

LLM-Wiki und RAG im direkten Vergleich

Ein LLM-Wiki und RAG lösen dasselbe Grundproblem auf unterschiedliche Weise: Sie sollen einem Sprachmodell passendes Wissen zuführen. Der eigentliche Unterschied liegt im Auswahlprinzip. Beim LLM-Wiki bestimmt eine feste Inhaltslogik, welche Datei oder welcher Themenbereich geladen wird. RAG berechnet dagegen die Nähe zwischen Anfrage und Wissensabschnitten.

Für Entwickler ist deshalb nicht nur die Dokumentmenge entscheidend. Ebenso wichtig sind Fehlertoleranz, Nachvollziehbarkeit und die Art der Fragen. Eine klar formulierte Frage zu einem bekannten Thema kann mit einer Dateistruktur sehr zuverlässig bearbeitet werden. Eine mehrdeutige Anfrage aus einem breit gefächerten Bestand profitiert eher von einer Suchschicht, die Bedeutungen miteinander verknüpft.

Ein weiterer Unterschied zeigt sich bei der Kontextgestaltung. Das LLM-Wiki kann ein vollständiges Dokument laden. Dadurch bleiben Argumentationslinien, Definitionen und Ausnahmen zusammen. RAG übergibt meist kleinere Ausschnitte. Das spart Kontext, kann aber wichtige Bezüge zwischen entfernten Abschnitten trennen.

Die beiden Ansätze sind nicht zwingend Gegenspieler. Eine hybride Architektur nutzt das Wiki als Inhaltsverzeichnis und RAG innerhalb einzelner Themenbereiche. Ein Router wählt etwa zuerst den passenden Fachbereich aus. Danach sucht die semantische Komponente nur in diesem begrenzten Bestand. Das kann irrelevante Treffer reduzieren und zugleich flexible Fragen erlauben.

Für die Kostenbetrachtung zählt nicht nur der Preis der Datenbank. Ein LLM-Wiki verursacht Aufwand bei der Pflege von Dateinamen, Querverweisen und Ladeentscheidungen. RAG benötigt dagegen Prozesse für Embeddings, Indexaktualisierung, Suchparameter und Fehleranalyse. Bei wenigen, stabilen Dokumenten kann die einfache Lösung wirtschaftlicher sein. Bei häufigen Anfragen an einen wachsenden Bestand verschiebt sich der Vorteil oft zugunsten von RAG.

Eine belastbare Entscheidung gelingt mit einem kleinen Vergleichstest. Derselbe Fragenkatalog sollte beide Varianten prüfen. Sinnvoll sind direkte Faktenfragen, Fragen mit Synonymen, mehrteilige Aufgaben und Fälle, für die keine passende Information existiert. Bewertet werden nicht nur richtige Antworten, sondern auch unnötige Inhalte, erfundene Ergänzungen und die Zeit bis zur Ausgabe.

Für ein MediaWiki-Projekt bietet sich meist folgende Regel an: Bleibt der Bestand überschaubar und sind seine Themen sauber trennbar, liefert ein LLM-Wiki die bessere Steuerbarkeit. Verteilen sich Antworten über viele Seiten und formulieren Nutzer ihre Fragen sehr unterschiedlich, bietet RAG mehr Suchspielraum. Eine Mischform ist dann interessant, wenn Ordnung und semantische Suche gemeinsam gebraucht werden.

Geeignete Wissensbestände für ein LLM-Wiki

Ein LLM-Wiki eignet sich besonders für Wissensbestände, deren Inhalte bewusst ausgewählt, klar abgegrenzt und direkt lesbar sind. Der Wert liegt dann nicht in möglichst vielen Seiten, sondern in einer verlässlichen Auswahl. Wenige, gut geschriebene Dokumente schlagen oft ein unübersichtliches Archiv.

Besonders passend sind Inhalte mit stabiler fachlicher Bedeutung. Dazu gehören etwa Begriffsdefinitionen, verbindliche Arbeitsabläufe, technische Regeln und kurze Entscheidungshilfen. Solche Texte lassen sich als einzelne Wissenseinheiten anlegen. Jede Einheit beantwortet idealerweise eine erkennbare Frage und besitzt einen klaren Geltungsbereich.

Ein guter Bestand enthält außerdem möglichst wenig widersprüchliche Aussagen. Wenn zwei Dokumente dieselbe Regel unterschiedlich beschreiben, muss der Leser erst den Konflikt lösen. Für ein Sprachmodell wird die Lage noch heikler: Es kann beide Aussagen verbinden und daraus eine dritte, falsche Regel bilden. Eindeutige Formulierungen und ein sichtbares Gültigkeitsdatum schaffen hier Ordnung.

Hilfreich ist eine feste Dokumentstruktur. Ein Eintrag kann zum Beispiel mit Zweck, Anwendungsbereich, Voraussetzungen, Ablauf und Ausnahmen beginnen. Diese Reihenfolge macht Inhalte für Menschen schnell erfassbar und unterstützt zugleich eine gezielte Auswahl durch die Anwendung.

Auch tabellarisches Wissen kann in einem LLM-Wiki funktionieren, wenn die Tabelle klein bleibt und jede Spalte verständlich benannt ist. Preisstufen, Rollen oder Kompatibilitäten lassen sich so kompakt darstellen. Sehr breite Tabellen mit vielen Sonderfällen sind dagegen schwer zu verarbeiten. Sie sollten in mehrere thematische Einträge aufgeteilt werden.

Ein weiterer geeigneter Bestand sind kuratierte Forschungsnotizen. Dazu gehören Hypothesen, Versuchsparameter, Beobachtungen und Schlussfolgerungen. Wichtig ist die Trennung zwischen belegtem Ergebnis und vorläufiger Annahme. Wörter wie Entwurf, unbestätigt oder veraltet liefern dem Modell wichtige Signale.

Weniger geeignet sind lose Protokollsammlungen, ungefilterte Chatverläufe und Dokumente ohne erkennbare Zuständigkeit. Auch stark zeitabhängige Daten brauchen besondere Kennzeichnungen. Ein LLM-Wiki kann solche Inhalte aufnehmen, doch der redaktionelle Aufwand steigt schnell. Dann verliert die einfache Struktur ihren größten Vorteil.

Als praktische Faustregel gilt: Ein Eintrag sollte eine klar umrissene Wissenseinheit darstellen, eine verantwortliche Quelle besitzen und ohne lange Erklärung verständlich sein. Wenn Leser den Text nicht sinnvoll benennen oder einem Thema zuordnen können, ist er für ein LLM-Wiki wahrscheinlich noch nicht reif.

Geeignete Einsatzfälle für RAG mit großen Dokumentmengen

RAG ist besonders hilfreich, wenn Wissen über viele Dateien, Abteilungen oder Formate verteilt liegt. Dazu gehören etwa technische Handbücher, Forschungsberichte, Sitzungsprotokolle, Supportfälle und Lehrmaterialien. Der entscheidende Punkt ist nicht allein die Menge. Auch wechselnde Begriffe, uneinheitliche Schreibweisen und verteilte Bezüge sprechen für einen solchen Ansatz.

In der Softwareentwicklung kann ein RAG-System Fragen zu mehreren Versionen einer Programmbibliothek beantworten. Dafür müssen Dokumente ihren Versionsstand und möglichst auch ihre Zielgruppe tragen. Eine Anfrage zu einer älteren Schnittstelle darf nicht versehentlich mit einer aktuellen Beschreibung beantwortet werden. Metadaten wie Version, Sprache, Produktbereich und Veröffentlichungsdatum werden dadurch zu einem fachlichen Filter.

In der Forschung eignen sich große Sammlungen aus Preprints, Laborprotokollen, Datensatzbeschreibungen und Methodenpapieren. Ein System kann verstreute Aussagen auffinden, etwa wenn eine Messmethode in einer Veröffentlichung erklärt und in einer späteren Notiz verändert wird. Für die wissenschaftliche Arbeit ist dabei die Unterscheidung zwischen Originalbefund, Zusammenfassung und Interpretation zentral.

Auch Hochschulen und Bildungseinrichtungen profitieren von RAG, wenn Lernmaterialien in vielen Kursen liegen. Studierende fragen oft nicht nach dem Titel eines Dokuments, sondern nach einem Problem: Warum gilt eine bestimmte Formel nur unter einer Bedingung? Ein gut aufgebauter Bestand kann passende Erklärungen aus Skripten, Übungen und Glossaren zusammenführen.

Im Kundendienst liegt ein weiterer Einsatzfall. Produktanleitungen, Fehlercodes, Garantiebedingungen und interne Lösungsnotizen bilden häufig ein großes Geflecht. RAG kann eine Anfrage anhand technischer Symptome einordnen, selbst wenn der Nutzer den offiziellen Fehlercode nicht kennt. Für belastbare Antworten müssen jedoch Produktmodell, Region und Gültigkeitszeitraum berücksichtigt werden.

Besonders nützlich ist RAG bei Fragen, die mehrere Quellen verbinden. Eine Antwort kann dann zum Beispiel eine technische Änderung, eine betroffene Arbeitsanweisung und eine zugehörige Testbeschreibung zusammenführen. Dafür müssen die Dokumente jedoch sauber verschlagwortet und zeitlich eingeordnet sein. Sonst entsteht zwar eine umfangreiche, aber sachlich schiefe Zusammenfassung.

Ein weiterer Vorteil zeigt sich bei mehrsprachigen Beständen. Nutzer können eine Frage auf Deutsch stellen, während die wichtigste Quelle auf Englisch vorliegt. Mehrsprachige Einbettungen erleichtern diesen Abruf. Die Antwortsprache bleibt davon getrennt und lässt sich unabhängig festlegen. Fachbegriffe sollten trotzdem in ihrer Originalform erhalten bleiben, wenn Übersetzungen zu Missverständnissen führen könnten.

Für große Archive ist außerdem die Zugriffskontrolle entscheidend. Nicht jeder Nutzer darf jeden Abschnitt sehen. Berechtigungen müssen bereits bei der Suche berücksichtigt werden, nicht erst nach der Antworterzeugung. Ein Treffer aus einem geschützten Dokument darf niemals in den Kontext gelangen, nur weil er semantisch besonders gut passt.

RAG passt damit vor allem zu Wissensräumen, in denen Umfang, Vielfalt und Querverbindungen den Zugriff erschweren. Gute Ergebnisse entstehen jedoch nicht automatisch durch mehr Dokumente. Erst die Kombination aus passenden Metadaten, klaren Zugriffsregeln und einer fachlich passenden Suchlogik macht ein großes Archiv für Entwickler und Forscher wirklich nutzbar.

Repository, Lizenz und experimenteller Projektstatus

Das öffentliche Repository moodlehq/wiki-rag bündelt Quellcode, Vorlagen und technische Hinweise für das Wiki-RAG-Projekt. Es gehört zur Organisation Moodle Research und steht unter der BSD-3-Clause-Lizenz. Diese Lizenz erlaubt die Nutzung, Änderung und Weitergabe des Codes, sofern die Lizenz- und Urheberrechtshinweise erhalten bleiben. Auch bei einer Weiterverwendung in eigenen Forschungs- oder Entwicklungsprojekten sollten die konkreten Lizenzbedingungen geprüft werden.

Das Repository dient nicht nur als Download-Ort. Seine Versionsgeschichte zeigt, wie sich Architektur, Konfiguration und Schnittstellen entwickeln. Für Entwickler sind Commits, Issues und Projektdateien daher wichtige Arbeitsmaterialien. Sie helfen dabei, Änderungen einzuordnen, offene Fragen zu erkennen und die eigene Umgebung an den dokumentierten Entwicklungsstand anzupassen.

Die Bezeichnung experimentell ist für die Bewertung des Projekts zentral. Sie bedeutet, dass Wiki-RAG vor allem als Forschungs- und Entwicklungsgrundlage gedacht ist. Eine experimentelle Codebasis kann wertvolle Konzepte zeigen, muss aber nicht dieselben Zusagen erfüllen wie ein langfristig gepflegtes Produkt. Schnittstellen können sich ändern, Dokumentation kann Lücken haben und einzelne Funktionen können noch nicht ausreichend erprobt sein.

Für Forscher eröffnet dieser Status einen Vorteil: Das Projekt lässt sich als veränderbare Versuchsbasis nutzen. Retrieval-Verfahren, Datenquellen und Bewertungsmethoden können angepasst werden, ohne an eine vollständig abgeschlossene Produktarchitektur gebunden zu sein. Ergebnisse sollten dabei immer mit dem verwendeten Commit oder Release verknüpft werden. Sonst ist später kaum feststellbar, unter welchen Bedingungen ein Experiment entstanden ist.

Vor einer eigenen Nutzung lohnt sich ein Blick auf die Aktivität des Repositorys. Relevant sind nicht nur Sterne oder Forks, sondern vor allem die Aktualität der Commits, die Reaktion auf Issues und die Verständlichkeit der Installationshinweise. Auch die Zahl der veröffentlichten Änderungen sagt allein wenig über Reife aus. Ein Projekt kann viele Commits besitzen und trotzdem zentrale Funktionen nur als Prototyp anbieten.

Für eine faire technische Einschätzung sollten Entwickler mindestens diese Punkte dokumentieren:

So bleibt klar, ob ein Ergebnis aus dem unveränderten Repository stammt oder durch eigene Anpassungen beeinflusst wurde. Genau diese Trennlinie ist für wissenschaftliche Reproduzierbarkeit und für spätere Wartung wichtig. Wiki-RAG bietet damit weniger eine fertige Komplettlösung als einen nachvollziehbaren Ausgangspunkt für eigene Untersuchungen.

Technische Voraussetzungen mit Python, Docker und Milvus

Für Wiki-RAG ist eine klar abgegrenzte Laufzeitumgebung nötig. Unterstützt wird Python 3.12 oder neuer. Zusätzlich gehören Git und pip zur Grundausstattung. Git verwaltet den Quellstand, während pip die Python-Abhängigkeiten installiert. Eine isolierte virtuelle Umgebung verhindert, dass Bibliotheken anderer Projekte die Installation beeinflussen.

Vor dem Start sollte geprüft werden, ob der Rechner die geforderte Python-Version verwendet. Gerade bei mehreren Python-Installationen zeigt python nicht immer auf dieselbe Version wie python3. Eine kurze Versionsprüfung spart später Fehlersuche. Für reproduzierbare Versuche empfiehlt sich außerdem eine festgehaltene Paketumgebung, damit spätere Installationen nicht unbemerkt andere Bibliotheksstände verwenden.

Die Vektorsuche benötigt Milvus 2.6.14 oder neuer. Wiki-RAG unterstützt dafür Standalone- und Distributed-Bereitstellungen. Milvus Lite wird nicht unterstützt. Diese Unterscheidung ist wichtig, weil eine lokale Lite-Installation zwar bequem wirken kann, aber nicht der vorgesehenen Betriebsart entspricht.

Für Entwicklung und Tests ist Docker Compose der passende Weg. Die Container kapseln Datenbankdienste und erleichtern einen einheitlichen Start über verschiedene Rechner hinweg. Benötigt werden daher eine funktionierende Docker-Installation, das Compose-Werkzeug und ausreichend Speicher für Container, Indizes und temporäre Importdaten.

Milvus besteht nicht nur aus einem einzelnen Prozess. Je nach Bereitstellung kommen weitere Dienste für Metadaten, Speicherung und Koordination hinzu. Deshalb sollte die Konfiguration des Containers genügend Ressourcen erhalten. Bei knappen Limits äußern sich Probleme oft nicht sofort als klarer Fehler, sondern durch langsame Importe, abgebrochene Suchläufe oder instabile Neustarts.

Für einen ersten Labortest reicht eine Standalone-Umgebung. Eine Distributed-Installation richtet sich eher an Szenarien mit höherem Datenvolumen oder mehreren Verarbeitungsknoten. Sie bringt jedoch zusätzliche Betriebsarbeit mit. Die Wahl sollte deshalb vom Versuchsziel abhängen und nicht allein vom Wunsch nach möglichst großer Infrastruktur.

Vor dem eigentlichen Import empfiehlt sich ein kurzer Funktionstest: Starten die Dienste, lässt sich die Vektordatenbank erreichen und können Schreib- sowie Lesezugriffe ausgeführt werden? Erst danach sollte ein größerer Bestand verarbeitet werden. Dieser kleine Check wirkt unspektakulär, verhindert aber, dass ein langer Import an einer falsch gesetzten Verbindung scheitert.

Die technischen Voraussetzungen bilden damit eine zusammenhängende Kette: Python führt die Anwendung aus, Docker stellt die Dienste bereit und Milvus speichert die Suchdaten. Fehlt ein Glied oder liegt eine inkompatible Version vor, kann das gesamte System trotz korrekter Quelltexte nicht zuverlässig starten.

Konfiguration mit `config.yml` und `.env`

Die Konfiguration trennt öffentliche Systemeinstellungen von geheimen Zugangsdaten. In config.yml stehen Werte, die für den Betrieb sichtbar und versionierbar sein können. Dazu zählen die anzubindenden MediaWiki-Websites, erlaubte Namensräume, Modellangaben, Suchparameter und weitere Laufzeitoptionen.

Die Datei sollte aus der bereitgestellten Vorlage erzeugt und anschließend an die eigene Umgebung angepasst werden. Wichtig ist eine gültige YAML-Struktur: Einrückungen müssen konsistent sein, Schlüssel dürfen nicht doppelt vorkommen und Zeichenketten mit Sonderzeichen sollten eindeutig als Werte erkennbar bleiben. Ein kleiner Formatfehler kann sonst dazu führen, dass die Anwendung beim Start die gesamte Konfiguration ablehnt.

Die Datei .env ist für vertrauliche Werte vorgesehen. Dazu gehören etwa API-Schlüssel, Zugriffstoken oder Kennwörter für angebundene Dienste. Solche Angaben gehören nicht in config.yml und sollten auch nicht in Quelltexten, Screenshots oder öffentlichen Fehlermeldungen auftauchen.

Für lokale Tests werden die Vorlagen mit diesen Befehlen kopiert:

cp config.yml.template config.yml
cp dotenv.template .env

Anschließend müssen die Platzhalter ersetzt werden. Bei URLs empfiehlt sich eine vollständige Schreibweise mit Protokoll. Modellnamen sollten exakt der jeweils eingerichteten Umgebung entsprechen. Auch Suchwerte wie die Anzahl der Treffer oder ein Ähnlichkeitsschwellenwert verdienen Aufmerksamkeit: Zu strenge Werte liefern möglicherweise keine Ergebnisse, zu großzügige Werte füllen den Kontext mit schwachen Treffern.

Die Trennung der Dateien erleichtert mehrere Betriebsprofile. Für eine lokale Untersuchung kann eine Testquelle eingetragen werden, während eine andere Umgebung eigene Modellzugänge und Suchgrenzen erhält. Die Anwendung bleibt dabei unverändert. Nur die Konfigurationsdateien wechseln.

Geheime Dateien sollten vom Versionskontrollsystem ausgeschlossen werden. Ein Eintrag in .gitignore verhindert, dass die lokale .env versehentlich veröffentlicht wird. Bereits übertragene Zugangsdaten gelten als kompromittiert und müssen ersetzt werden. Das gilt auch dann, wenn der betreffende Commit später aus dem sichtbaren Verlauf entfernt wird.

Vor dem Start lohnt sich eine Prüfung der tatsächlich geladenen Werte. Dabei sollten Geheimnisse maskiert erscheinen, etwa nur mit den letzten vier Zeichen eines Tokens. So lassen sich Tippfehler und fehlende Variablen erkennen, ohne vertrauliche Inhalte in Protokollen zu hinterlassen.

Bei mehreren Umgebungen sollte jede Konfiguration eindeutig benannt und dokumentiert werden. Eine knappe Notiz zu Quelle, Modellprofil und Suchverhalten genügt oft. Dadurch bleibt später nachvollziehbar, warum zwei Tests trotz gleicher Anfrage unterschiedliche Ergebnisse liefern.

Beispiel: Eine MediaWiki-Wissensbasis für Entwickler aufbauen

Eine MediaWiki-Wissensbasis für Entwickler sollte nicht als ungebremster Sammelort starten. Besser ist ein kleiner, fachlich klarer Bereich mit Seiten, die konkrete Entwicklungsfragen beantworten. Ein sinnvoller Pilot kann etwa die Architektur eines Projekts, die lokale Einrichtung, zentrale Schnittstellen und typische Fehlermeldungen abdecken.

Als Beispiel dient ein internes Entwickler-Wiki für eine Webanwendung. Die Seiten erhalten feste Namenskonventionen und ein einheitliches Inhaltsmuster. Dadurch erkennt das System leichter, welche Angaben zusammengehören.

Jede Seite sollte mit einem kurzen Zweck beginnen. Danach folgen Voraussetzungen, konkrete Schritte, Beispiele und bekannte Grenzen. Ein Eintrag zur API kann etwa die unterstützte Version, Pflichtfelder, Fehlercodes und ein minimales Beispiel enthalten. Unklare Aussagen wie „normalerweise“ oder „bei Bedarf“ sollten nur erscheinen, wenn der Text den jeweiligen Fall genauer beschreibt.

Für die spätere Suche helfen aussagekräftige Seitentitel. „Authentifizierung: Token-Erneuerung“ ist präziser als „Login-Themen“. Auch Synonyme dürfen im Text vorkommen: Token-Erneuerung, Refresh-Token und Sitzungserneuerung können dieselbe Funktion bezeichnen. So steigt die Chance, dass unterschiedliche Entwicklerfragen auf derselben Seite landen.

Ein typischer Arbeitsablauf sieht so aus:

  1. Die wichtigsten Entwicklerfragen sammeln.
  2. Jede Frage einer eigenen Wiki-Seite oder einem klaren Abschnitt zuordnen.
  3. Beispiele mit realistischen Eingaben und Ausgaben ergänzen.
  4. Version, Zuständigkeit und Gültigkeitsbereich sichtbar machen.
  5. Den Bestand mit echten Testfragen aus dem Entwickleralltag prüfen.

Besonders wertvoll sind Seiten, die Zusammenhänge erklären. Ein API-Eintrag sollte nicht nur den Endpunkt nennen, sondern auch zeigen, welche Anwendung ihn aufruft und was bei einem Fehler geschieht. Dadurch kann das Sprachmodell eine technische Frage besser einordnen. Der Unterschied ist spürbar: Eine reine Parameterliste beantwortet „Welche Felder gibt es?“, aber kaum „Warum schlägt mein Aufruf fehl?“

Für Codebeispiele empfiehlt sich eine klare Trennung zwischen Erklärung und Quelltext. Veraltete Beispiele sollten deutlich markiert oder entfernt werden. Ein falscher Codeblock ist gefährlicher als eine fehlende Erläuterung, weil er sehr überzeugend aussehen kann.

Die Wissensbasis sollte außerdem verschiedene Fragetypen abdecken. Entwickler fragen nach Definitionen, Ursachen, Abläufen und Entscheidungen. Ein guter Testkatalog enthält daher nicht nur „Was ist …?“, sondern auch:

Nach dem ersten Lauf werden schwache Seiten gezielt verbessert. Fehlen wichtige Begriffe, werden sie ergänzt. Werden zwei Themen regelmäßig verwechselt, erhalten sie deutlichere Titel oder Querverweise. So wächst die Wissensbasis nicht bloß an Umfang, sondern an praktischer Treffgenauigkeit.

Prüfkriterien für Genauigkeit, Sicherheit und Skalierbarkeit

Die Prüfung eines Wiki-RAG-Systems sollte drei Ebenen getrennt betrachten: Findet die Suche den richtigen Inhalt, verarbeitet das Modell ihn korrekt und bleibt der Dienst unter Last zuverlässig? Eine einzelne gute Antwort reicht dafür nicht. Nötig ist ein fester Testkatalog mit erwarteten Quellen, zulässigen Aussagen und klaren Fehlerszenarien.

Für die Genauigkeit zählt zunächst die Trefferqualität. Markiere pro Testfrage, ob der passende Abschnitt an erster Stelle, unter den ersten fünf Treffern oder gar nicht erscheint. Ergänzend zeigt die Antworttreue, ob das Sprachmodell nur belegte Aussagen verwendet. Besonders wertvoll sind Fragen mit ähnlichen Begriffen, widersprüchlichen Seiten, fehlenden Informationen und mehreren nötigen Quellen.

Ein guter Testdatensatz enthält neben normalen Fachfragen auch absichtlich schwierige Fälle. Dazu gehören Tippfehler, Synonyme, veraltete Begriffe und Fragen mit falschen Voraussetzungen. Für jede Anfrage sollte ein Fachkundiger festlegen, was als korrekt gilt. Automatische Bewertungsmodelle können unterstützen, ersetzen aber keine stichprobenartige Prüfung durch Menschen.

Die Sicherheit beginnt bei der Rechteprüfung vor der Antworterzeugung. Zugriffsregeln müssen verhindern, dass geschützte Wiki-Inhalte überhaupt in den Suchkontext gelangen. Protokolle sollten keine geheimen Texte oder vollständigen Zugangsdaten speichern. Außerdem sind Anweisungen innerhalb importierter Seiten als Daten zu behandeln, nicht als Befehle an das System. Das reduziert das Risiko von Prompt-Injection über manipulierte Wiki-Inhalte.

Für personenbezogene oder vertrauliche Daten gelten zusätzliche Anforderungen. Der EU AI Act sieht je nach Einsatzgebiet unterschiedliche Pflichten vor; seit dem 2. August 2026 gelten zahlreiche Regelungen für Anbieter und Betreiber. Eine RAG-Anwendung sollte deshalb früh klären, welchem Zweck sie dient, welche Nutzer betroffen sind und welche Protokollierungs- oder Informationspflichten entstehen. Datenschutzrechtliche Fragen, insbesondere nach der DSGVO, bleiben davon getrennt bestehen.

Zur Sicherheitsprüfung gehören auch technische Angriffe: ungewöhnlich lange Anfragen, massenhafte API-Aufrufe, manipulierte Dokumente und der Versuch, Systemanweisungen offenzulegen. Begrenzte Anfragegrößen, Authentifizierung, Rollenrechte und eine kontrollierte Fehlermeldung bilden dabei die erste Schutzschicht. Ein Dienst sollte nie mehr interne Details ausgeben, als der jeweilige Nutzer benötigt.

Skalierbarkeit zeigt sich nicht nur an der Zahl gespeicherter Vektoren. Miss auch Importdauer, Suchlatenz, Antwortzeit, Speicherverbrauch und Fehlerrate. Führe Lasttests mit steigender Zahl paralleler Anfragen durch. Ein sinnvolles Ziel ist nicht bloß ein niedriger Durchschnittswert: Auch das 95. und 99. Perzentil der Antwortzeit müssen innerhalb der geplanten Nutzung bleiben.

Die Ergebnisse gehören in ein Prüfprotokoll. Notiere Testdatum, Softwarestand, Modell, Datenbestand, Suchparameter und Messwerte. So lässt sich erkennen, ob eine Verbesserung wirklich aus einer technischen Änderung stammt oder nur durch einen anderen Testbestand entstand. Eine kompakte Auswertung mit Grenzwerten macht aus Einzelbeobachtungen eine belastbare Entscheidung.

Fazit: Wiki-RAG testen, bewerten und gezielt einsetzen

Wiki-RAG ist vor allem dann sinnvoll, wenn eine konkrete MediaWiki-Quelle mit Sprachmodellen nutzbar gemacht werden soll und der technische Aufbau selbst Teil der Untersuchung ist. Als experimentelles Projekt eignet es sich für Prototypen, Lehrveranstaltungen und Forschungsreihen, weniger als fertige Lösung ohne eigene Betriebsplanung.

Für eine faire Entscheidung sollte ein Test nicht bei einer einzelnen Demo enden. Definiere vorher ein Ziel, etwa bessere Antworten zu einem abgegrenzten Fachgebiet, und lege passende Messgrößen fest. Danach kannst du Wiki-RAG gegen eine einfache Suche, ein LLM-Wiki oder eine andere RAG-Architektur vergleichen. Entscheidend ist nicht, welches System am eindrucksvollsten klingt, sondern welches die konkreten Fragen zuverlässig löst.

Forscher sollten zusätzlich zwischen Systemleistung und Wissensqualität unterscheiden. Ein niedriger Suchfehler beweist noch nicht, dass das Wiki vollständig oder fachlich aktuell ist. Umgekehrt kann eine gute Quelle schlecht wirken, wenn Fragen unklar formuliert sind oder wichtige Begriffe im Test fehlen. Diese Trennung verhindert voreilige Schlussfolgerungen.

Entwickler profitieren von einem stufenweisen Übergang. Nach dem Labortest folgt ein begrenzter Pilot mit wenigen Nutzern und einem klaren Anwendungsfall. Erst wenn Betrieb, Kosten und Antwortverhalten nachvollziehbar sind, lohnt sich eine größere Anbindung. Ein solcher Weg ist weniger spektakulär, aber er spart später viel Rückbauarbeit.

Die passende Architektur darf sich außerdem verändern. Beginnt ein Projekt mit einem strukturierten LLM-Wiki, kann später eine semantische Suche hinzukommen. Umgekehrt kann ein umfangreicher RAG-Bestand für häufige Kernfragen durch feste, kuratierte Einträge ergänzt werden. Wissensbasen sind keine einmalige Weichenstellung, sondern entwickeln sich mit Daten, Fragen und Anforderungen.

Als Ergebnis sollte ein kurzer Entscheidungsbericht entstehen. Er beantwortet, welche Fragen gut gelöst wurden, wo die Grenzen liegen, welche Ressourcen benötigt werden und unter welchen Bedingungen ein weiterer Betrieb vertretbar ist. So wird aus einem technischen Versuch eine belastbare Grundlage für Forschung oder Produktplanung.

Fazit: Wiki-RAG bietet eine konkrete Brücke zwischen MediaWiki und generativer KI. Sein größter Wert liegt in der untersuchbaren Architektur und der anpassbaren Ausgangsbasis. Wer mit klaren Testzielen startet, Ergebnisse sauber dokumentiert und den Einsatzbereich begrenzt, kann den Ansatz sinnvoll bewerten und gezielt weiterentwickeln.