RegioWizard

Das AW-Wiki auf aw-wiki.de sammelt seit Jahren, was über den Kreis Ahrweiler bekannt ist: Vereine, Bauwerke, Weinlagen, Wanderwege, Gemeinderäte, Firmen, Ereignisse, Menschen. Rund 39.000 Artikel im Hauptnamensraum, geschrieben und gepflegt von Menschen aus der Region.

Wer dort etwas sucht, muss allerdings wissen, wonach er sucht. Ein Suchfeld beantwortet die Frage „Welche Vereine in Dernau waren von der Flut betroffen?“ nicht. Es findet Seiten, die das Wort Dernau enthalten. Den Rest muss der Mensch tun.

Genau dort liegt die Lücke: Der Bestand ist da, die Fragen sind da, dazwischen fehlt ein System, das beides verbindet, ohne dabei etwas zu erfinden. RegioWizard ist unsere Antwort darauf - ein lauffähiger Prototyp, kein Konzeptpapier.

Alles im Prototyp liest denselben lokalen Index. Es gibt keine zweite Datenquelle, die auseinanderlaufen könnte.

1. Fragen - belegte Antworten in ganzen Sätzen, mit Filtern und Suchprotokoll.
2. Atlas - jeder verortete Eintrag auf einer Karte, Flutebene zuschaltbar, Nachbarschaft im Umkreis von 3 km.
3. Auswertung - Struktur und Zeittiefe des Bestandes, dazu der Redaktionstisch.
4. Redaktion - der Abgleich von frischem Pressetext gegen das Wiki.
5. 14./15. Juli 2021 - die Dokumentation der Flutnacht, bewusst zurückhaltend gebaut.
6. Pipeline - der Zustand von Erfassung, Index und Modellen, offen einsehbar.
7. Artikelansicht - jeder Artikel als Lesefassung, mit Verweis auf das Original im Wiki.

Dazu eine Kommandopalette auf Strg + K, die alle 4.295 Titel im Griff hat: tippen, springen. Findet sie nichts, wird die Eingabe als Frage weitergereicht.

Das ist die Regel, an der alles andere hängt. Das Sprachmodell formuliert ausschliesslich aus den Textabschnitten, die die Suche vorher gefunden hat, und markiert jede Behauptung mit einer Fussnote. Die Fussnote ist anklickbar und öffnet den Abschnitt, aus dem sie stammt - Titel, Kapitel, Wortlaut.

Der wichtigere Teil ist der Fall ohne Modell. Ist keines konfiguriert, erfindet das System nichts und meldet auch keinen Fehler: Es zeigt die am besten passenden Sätze aus dem Wiki, wörtlich und mit Beleg, darunter die gefundenen Abschnitte im Volltext. Diese extraktive Betriebsart ist ein vollwertiger Weg, kein Ausfallzustand.

Das hat einen praktischen Grund. Eine Redaktion, die eine Angabe übernimmt, steht für sie gerade. Ein Werkzeug, das eine Quelle nur behauptet, statt sie zu zeigen, ist in dieser Lage wertlos.

„Wer aus der Region hat heute Geburtstag?“ klingt wie eine Frage an eine KI. Es ist aber eine Datenbankabfrage, und die Vektorsuche beantwortet sie zuverlässig schlecht: Sie findet Texte, die über Geburtstage sprechen, nicht Personen, deren Geburtstag heute ist.

Deshalb erkennt der Prototyp diese Fragen und leitet sie an feste Abfragen über die erschlossenen Felder weiter - Geburts- und Sterbedaten, Gründungsjahre, Koordinaten, Kategorien. So beantwortet werden: Jahrestage zu einem Datum, verzeichnete Sterbefälle eines Jahres, Gründungen, Umkreis und - der für Redaktionen interessanteste Fall - Themenlücken: Artikel, auf die oft verwiesen wird, die aber selbst dünn sind oder ganz fehlen.

Das Ergebnis ist eine Tabelle aus Name, Datum und Beleg. Kein Fliesstext, der Zahlen zusammenrät.

Unter jeder Antwort steht, wie sie zustande kam: wie viele Kandidaten die Stichwortsuche geliefert hat, wie viele die Vektorsuche, wie viele nach der Zusammenführung übrig blieben, wie viele tatsächlich in die Antwort eingingen und wie lange das gedauert hat. Im abgebildeten Lauf: 72 lexikalisch, 72 fusioniert, 12 verwendet, 120 Millisekunden.

Die Suche selbst ist deutschsprachig gebaut. Umlaute werden gefaltet, Wortstämme gebildet, Komposita zerlegt - Weinbau findet auch Weinbaubetrieb. Jeder Textabschnitt trägt eine feste Kopfzeile aus Titel, Abschnitt, Typ, Ort und Kategorien, damit er auch dann verständlich bleibt, wenn er aus seinem Artikel herausgelöst wurde.

Wir zeigen das nicht aus Technikfreude. Wer eine Angabe weiterverwendet, soll sehen können, wie dünn oder wie breit die Grundlage war.

Ein Regionalwiki veraltet genau dort, wo die Gegenwart passiert - im Lokalteil, im Wochenblatt, in der Pressemitteilung des Vereins. Die Redaktion sieht diese Meldungen ohnehin jeden Tag. Sie zusätzlich ins Wiki zu übertragen, kostet Zeit, die niemand hat.

Der Redaktionstisch nimmt einen Text und vergleicht ihn mit dem Bestand. Erkannt werden Personen, Vereine, Firmen und Orte; jeder Fund wird gegen die vorhandenen Artikel geprüft und bekommt einen von drei Zuständen: bereits erfasst, Artikel vorhanden, Aussage fehlt, kein Artikel. Im gezeigten Beispiel: 8 Entitäten, 5 ohne Artikel, 3 mit möglicher Ergänzung.

Zu jedem Vorschlag gehört ein Entwurf im Wiki-Format zum Kopieren. Entscheidend ist, was das System nicht tut: Es schreibt nichts ins Wiki. Die Auswahl bleibt in der Redaktion - keine technische Einschränkung, sondern die Aufgabenteilung, die wir für richtig halten.

Der Bestand enthält zahlreiche Artikel mit Bezug zur Flut vom 14./15. Juli 2021. Eine eigene Seite dafür war unvermeidlich - die Frage war, wie sie aussehen darf.

Wir haben sie unter feste Auflagen gestellt, und diese Auflagen sind Teil des Produkts, keine Stilfrage: ein Hinweis vor dem Inhalt, keine Namen von Opfern, keine Bilder, keine Animationen, keine hochzählenden Zahlen, keine Interaktionsanreize, eine gedämpfte Farbgebung, die sich vom Rest der Anwendung unterscheidet.

Angaben auf dieser Seite stehen mit ihrer Quelle. Wo Quellen sich unterscheiden, wird der Unterschied benannt statt geglättet.

Ehrlich zum Stand: Erfasst sind 4.295 der rund 39.000 Artikel, ausgewählt nach Relevanz für die typischen Fragen. Daraus entstehen 20.543 Textabschnitte, 68.992 Indexbegriffe und 1.040 verortete Einträge. Die Erfassung respektiert die Ratenbegrenzung des Wikis; für den Vollbestand wäre ein Datenbankexport der richtige Weg, nicht 39.000 Einzelabrufe.

Die Anwendung läuft vollständig lokal: Korpus, Index und Vektoren liegen als Dateien im Projektordner. Keine Datenbank, kein externer Dienst, kein Tracking, keine Cookies - die einzige Fremdanfrage im Browser sind die Kartenkacheln.

Alle Illustrationen im Prototyp sind Zeichnungen, mit einem Bildmodell erzeugt und als solche beschriftet. Keine davon zeigt einen realen Ort, ein reales Bauwerk oder eine reale Person. Das ist Absicht: Eine Anwendung, deren ganzer Anspruch die Belegbarkeit ist, darf kein Bild ausliefern, das man für eine Aufnahme halten könnte.

Die Bilder unterhalb dieses Abschnitts stammen aus der ersten Fassung von 2025 - dem ursprünglichen Chatbot-Entwurf, mit dem die Idee begann. Sie bleiben stehen, weil sie zeigen, woher das Projekt kommt.