BrandenburgPilot

Bevor eine einzige Frage beantwortet werden kann, muss das System wissen was es weiß. KiStack bezieht sein Wissen aus zwei offiziellen Quellen der Stadt Brandenburg an der Havel: dem Stadtportal stadt-brandenburg.de (Verwaltung, Ämter, Dienstleistungen) und dem Tourismusportal erlebnis-brandenburg.de (Events, Unterkünfte, Sehenswürdigkeiten). Jede Nacht um 04:20 Uhr werden diese Quellen automatisch aktualisiert. Dienstags und freitags durchsucht ein automatischer Crawler (ein Programm, das Webseiten selbstständig ausliest) zusätzlich alle Unterseiten und PDF-Dokumente. Das gesamte Wissen — über 36.000 Textabschnitte — ist auf dem eigenen Server gespeichert, nicht in einer Cloud.

Parent-Child Chunking (Phase 1a, seit 2026-03-16): Lange Texte werden zunächst in Parent-Chunks (~1.000 Zeichen) aufgeteilt, die den vollständigen Kontext bewahren. Jeder Parent wird anschließend in kleinere Child-Chunks (~300 Zeichen) zerlegt. Nur die Children bekommen einen Embedding-Vektor vom Modell bge-m3 (VM301) und werden per Similarity Search retrieved. Die Parents erhalten Zero-Vektoren und dienen als Kontext-Lieferant: Findet das System einen relevanten Child-Chunk, holt es automatisch den zugehörigen Parent — so bekommt das LLM immer den vollständigen Zusammenhang statt eines Textfragments.

Alle Vektorisierungen — sowohl beim täglichen Daten-Ingest als auch bei jeder Bürgeranfrage in Echtzeit — werden auf einem dedizierten Server (VM301, 192.168.1.8) berechnet. Das Embedding-Modell bge-m3 erzeugt 1024-dimensionale Vektoren. Durch die Auslagerung bleibt die NVIDIA A10 auf dem Hauptserver (VM300) vollständig für die LLM-Textgenerierung reserviert. Die Kommunikation erfolgt über eine FastAPI-Schnittstelle (Port 8532).

Optional: Nach dem Chunking kann jeder Textabschnitt durch das Sprachmodell mit Alltagsbegriffen und einer Kurzbeschreibung angereichert werden. Damit schließt das System die semantische Lücke zwischen Verwaltungssprache und Bürgersprache bereits im Ingest-Schritt — noch bevor eine Bürgerfrage gestellt wird. Aktiviert via INGEST_ENRICH=1.

Jeder Textabschnitt wird auf Adressen und Ortsnamen untersucht. Gefundene Adressen werden über den OpenStreetMap-Dienst Nominatim in Koordinaten (geo_lat/geo_lon) umgewandelt und im Qdrant-Payload gespeichert. Damit können Bürger standortbezogene Fragen stellen wie „Was ist in meiner Nähe?". Ein lokaler Cache beschleunigt wiederholte Abfragen.

Points of Interest werden wöchentlich aus OpenStreetMap synchronisiert. Die Overpass-API liefert Restaurants, Hotels, Museen, Parks, Kirchen, Supermärkte und weitere Orte im Stadtgebiet — als Node, Way und Relation mit Centroid-Koordinaten. 463 kuratierte POIs bilden die Collection city_pois mit 100% Geo-Abdeckung.

Personen der Stadtverwaltung werden aus dem Personalverzeichnis (PDF/HTML) extrahiert und als city_people Collection in Qdrant gespeichert. Manuelle Korrekturen über die Admin-Oberfläche (manual_overrides) überleben jeden Re-Ingest. Aktuell ~173 Personen mit Funktion, Abteilung, Kontaktdaten und Sprechzeiten.

Veraltete Datenpunkte, die in der Quell-XML nicht mehr vorhanden sind, werden nach 45 Tagen automatisch aus Qdrant und Meilisearch entfernt. Verhindert, dass das System Antworten auf Basis gelöschter oder veralteter Webseiten gibt. Protokollierung in den Ingest-Logs.

Nach jedem Qdrant-Ingest werden alle Dokumente automatisch in Meilisearch gespiegelt — die Stichwort-Suchmaschine (BM25). Titel, Textinhalt, Alltagsbegriffe, Tags und Geo-Koordinaten werden synchronisiert. 237 Synonym-Gruppen und Stoppwörter werden dabei angewendet, damit z.B. „Kita" auch „Kindertagesstätte" findet. Ohne diesen Schritt würde die Hybrid-Suche (Phase 2) nur Vektoren nutzen und keine Stichwort-Treffer liefern.

Zentrale Datenbankverbindung über einen Thread-sicheren Connection Pool (psycopg2, min=2, max=10 Verbindungen). PostgreSQL 16.13 ersetzt SQLite als primäre Datenbank für alle strukturierten Daten: Benchmark-Ergebnisse, Traces, Sessions, Judge-Scores, FAQ und den SQL-RAG-Layer (Einrichtungen, Personen, POIs). Extensions pg_trgm (Trigramm-Suche) und unaccent (Umlaut-tolerant) ermöglichen Fuzzy-Suche direkt in der Datenbank.

Jede eingehende Anfrage wird zunächst auf Häufigkeit geprüft. Mehr als 30 Anfragen pro Minute von einer IP-Adresse werden mit HTTP 429 gedrosselt — Antwort als JSON (nicht HTML). Verhindert missbräuchliche Nutzung und schützt Server-Ressourcen.

Die Eingabe wird auf persönliche Daten (IBAN, Kreditkarte, Telefon, E-Mail, Ausweis, SV-Nummer) und auf Manipulationsversuche geprüft. Erkannte PII-Muster werden durch [Typ entfernt] maskiert, Injection-Versuche (6 Pattern-Gruppen: Rollenanweisungen, Jailbreak, DAN, Code-Injection, Datenexfiltration …) mit HTTP 400 abgewiesen. Output-Bereinigung entfernt IBAN und Kreditkartennummern aus LLM-Antworten.

Jede Browser-Sitzung erhält eine Session-ID (sessionStorage, Tab-basiert, kein Cookie). Die letzten 3 Fragen und Antworten werden als [Bisheriger Gesprächsverlauf]-Block dem Prompt vorangestellt. Bürger können Folgefragen stellen ohne die vorherige Frage zu wiederholen. TTL: 2 Stunden, Antworten auf 300 Zeichen gekürzt (Token-Effizienz).

Die Eingabe des Bürgers wird technisch vorbereitet: Groß- und Kleinschreibung wird vereinheitlicht, Satzzeichen werden entfernt, Umlaute in beide Schreibweisen umgewandelt — ä wird zu ae, aber auch ae wird zu ä. Dadurch findet das System „Straße" auch wenn „Strasse" eingegeben wurde, und umgekehrt.

Das System analysiert die Struktur der Frage und erkennt die Absicht des Bürgers. Fragt er nach einer Person (WHO), einem Ort (WHERE), einem Termin (WHEN), einer Aufzählung (LIST) oder einem Vorgang (HOW)? Diese Erkennung entscheidet welche Datenquellen bevorzugt werden und welche Antwortstruktur das Sprachmodell am Ende verwendet. Es gibt insgesamt 9 Absichtstypen.

Manchmal kennt das System die Antwort bereits — ohne die volle KI-Verarbeitung. Wenn eine Frage sehr genau mit einem gespeicherten FAQ-Eintrag übereinstimmt (Score ≥ 0.90), wird die Antwort direkt geliefert und alle nachfolgenden Schritte werden übersprungen. Bei einem Score ≥ 0.45 wird der FAQ-Treffer nur als Hinweis dem Kontext hinzugefügt, die volle Pipeline läuft weiterhin durch.

Noch bevor die aufwendige Vektorsuche startet, prüft das System ob die Frage eine strukturierte Antwort aus der PostgreSQL-Datenbank liefern kann. Anhand des erkannten Intents und extrahierter Entitäten (z.B. "Standesamt", "Touristinfo") werden drei Tabellen per Fuzzy-Suche (pg_trgm, Schwelle > 0.25) durchsucht: 803 Einrichtungen, 173 Personen, 463 POIs. Bei einem Treffer wird der strukturierte Datensatz (Name, Adresse, Telefon, Öffnungszeiten) als Prioritäts-Kontext vor die Vektor-Ergebnisse gestellt. Durchschnittliche Latenz: ~12 ms — über 1.000× schneller als die Vektorsuche.

Traversiert den Neo4j Knowledge Graph (3.050 Knoten, 1.555 Kanten, 85 Themen) um semantische Lücken zu schließen die weder SQL-RAG noch Vektorsuche lösen können. Beispiel: "Brandschutzbeauftragter" → Thema(Brandschutz) → Amt(Feuerwehr) → Person(Kalka). Score-Schwelle: 0.5. Unterstützt WHO, WHERE, WHAT, LIST Intents. Bei LIST mit historischen Keywords: Chronologische Auflistung (z.B. alle OBMs). Graph-Kontext wird als Priorität vorangestellt (vor Vektor-Chunks).

Das System erkennt besondere Anforderungen in der Frage: „Nenne mir 3 Restaurants" → es werden genau 3 Ergebnisse gesucht (COUNT). „Restaurants in der Nähe" → Ergebnisse werden nach Entfernung zum erkannten Standort sortiert (NEARBY). „Liste alle Hotels" → die Antwort wird als Aufzählung formatiert (LIST). Diese Constraints steuern sowohl Suche als auch Antwortstruktur des Sprachmodells.

Aus der vorbereiteten Frage werden inhaltlich tragende Wörter herausgelöst — die eigentlichen Fachbegriffe der Anfrage. Füllwörter wie „ist", „gibt", „kann", „sich" werden ignoriert (das System kennt 306 solcher Stoppwörter). Was übrig bleibt sind die Begriffe die die Suche steuern: z.B. „Touristinformation", „Öffnungszeiten", „Ordnungsamt". Je präziser diese Begriffe, desto besser das Suchergebnis.

Das System prüft ob die Frage einen geografischen Bezug enthält: Stadtteile (Neustadt, Altstadt, Görden …), Postleitzahlen (14770–14776) oder bekannte Orte (Bahnhof, Rathaus, Dom). Wird ein Ort erkannt, werden Suchergebnisse nach ihrer Entfernung zu diesem Punkt sortiert und die Antwort enthält Angaben wie „ca. 300 m entfernt".

Bevor die eigentliche Suche startet, reichert das System die Anfrage durch zwei parallele LLM-Aufrufe an — beide Schritte schließen die semantische Lücke zwischen Bürgersprache und Verwaltungsdokumenten. HyDE (Hypothetical Document Embeddings) lässt das Modell eine fiktive Verwaltungsantwort formulieren und embeddet diese statt der Originalfrage — der Vektor liegt viel näher an echten Dokumenten als der der Bürgerfrage. Query-Rewriting erzeugt 2–3 Umformulierungen für breiteren BM25-Abdeckung in Meilisearch.

Die ursprüngliche Frage wird mit den extrahierten Schlüsselbegriffen angereichert bevor sie in die Suche geht. Ein Duplikat-Schutz verhindert dass Begriffe doppelt erscheinen. Zusätzlich werden Umlaut-Varianten erzeugt (ä/ae, ö/oe, ü/ue), damit die Suche sowohl „Öffnungszeiten" als auch „Oeffnungszeiten" findet. Das Ergebnis ist eine optimierte Suchanfrage die mehr relevante Dokumente findet als die Originalfrage allein.

KiStack hat 7 Datenquellen (Collections): Stadtverwaltung, Unterseiten, Dokumente, Tourismus/Erlebnis, Personen, Einrichtungen und POIs. Ein speziell trainiertes neuronales Netz (gbert-base, 110 Mio. Parameter, §226) analysiert den Fragetext und berechnet für jede Datenquelle eine Wahrscheinlichkeit — bei „Welche Schiffsrundfahrten gibt es?" erhält Tourismus 97%, bei „Wer leitet das Ordnungsamt?" die Personendaten 49%. Das Modell wurde auf 1.367 Beispielen trainiert und erreicht 95,8% Genauigkeit. Falls der Classifier deaktiviert ist, greift ein statistisches Fallback (CollectionRouter) oder die statische Intent-basierte Gewichtung.

Drei Suchpfade laufen gleichzeitig: (1) Dense-Suche mit dem HyDE-Vektor aus Phase 1b — findet semantisch ähnliche Dokumente im Bedeutungsraum der Verwaltungsdokumente. (2) Dense-Suche mit dem Embedding der erweiterten Originalfrage (Qdrant / bge-m3). (3) BM25-Stichwortsuche für jede Query-Rewriting-Variante in Meilisearch — mit Synonymen und Stoppwörtern. Alle drei Ergebnislisten werden per RRF-Fusion zu einem gemeinsamen Ranking vereint.

Die Ergebnisse beider Suchverfahren werden zusammengeführt und nach einem kombinierten Wert neu sortiert. Das Verfahren heißt RRF (Reciprocal Rank Fusion — gegenseitige Rangverstärkung): Ein Dokument das in beiden Suchlisten weit oben steht, erhält einen besonders hohen Gesamtwert. Zusätzlich misst ein Coverage-Score wie viele der Suchbegriffe tatsächlich im Dokument vorkommen. So profitiert jedes Ergebnis von beiden Suchverfahren gleichzeitig.

Nach dem RRF-Ranking werden die Top-20 Treffer durch das Modell BAAI/bge-reranker-v2-m3 (~1.1 GB, gecacht) neu bewertet. Es vergleicht Frage und Dokumentinhalt als Paar — präziser als reines Vektor-Ähnlichkeitsmaß. Smoke-Test bestanden: Score 0.9826 für relevanten Treffer.

Bei WHO-Anfragen (z.B. „Wer leitet das Amt im März 2026?") wird das Datum aus der Frage extrahiert — auch deutsche Monatsnamen. Personen-Treffer werden gegen ihre Amtszeiten geprüft: nur wer zum angefragten Zeitpunkt aktiv war, bleibt im Ergebnis. Bei NEARBY-Anfragen werden vergangene Veranstaltungen und abgelaufene Events herausgefiltert. Unterstützt DD.MM.YYYY, YYYY-MM-DD und „im April 2026"-Formate.

Nicht alle gefundenen Textabschnitte sind gleich gut. Das System prüft jeden Treffer nach mehreren Kriterien: Relevanz-Score (≥ 0.18 Minimum), Newsletter-Abwertung, Coverage-Score (wie viele Suchbegriffe im Dokument vorkommen), Freshness-Penalty (ältere Dokumente werden leicht abgewertet), Past-Event-Filter (vergangene Veranstaltungen werden entfernt), und bei NEARBY-Anfragen: rank_by_distance (Sortierung nach Geo-Distanz) plus Temporal-Filter (nur aktuelle Events und Seiten). Wenn zu wenige gute Quellen übrig bleiben, antwortet das System ehrlich: „Dazu habe ich leider keine Information."

Die Top-5 Dokumente werden als Textausschnitte zusammengestellt. Bei Standort-Fragen enthält jeder Ausschnitt die berechnete Entfernung zum gesuchten Ort. Dieses Kontext-Paket ist das einzige was das Sprachmodell zu sehen bekommt — es darf keine eigenen Kenntnisse oder Informationen aus dem Internet verwenden, sondern ausschließlich diese bereitgestellten, geprüften Quellen.

Ein separates Modell (qwen3.5:9b auf VM301) prüft die generierte Antwort auf Halluzinationen und Widersprüche zum Kontext. Bei SQL-RAG-Treffer mit Score ≥ 0.9 wird nur der SQL-RAG-Kontext an die Critique übergeben (Vermeidung widersprüchlicher Chunks). Die Critique kann die Antwort korrigieren oder unverändert durchlassen. Läuft nur wenn SELF_CRITIQUE_ENABLED=1.

Critique-Score → bei niedrigem Score: Deep Search → erneute Critique → Retry. Wurde in Iter 4 deaktiviert (§276): Wandelte Teilantworten in harte Ablehner um (12 neue Ablehner, OK-Rate 98.3% → 96.6%). SELF_RAG_LOOP_ENABLED=0. Kann nach Code-Verbesserung reaktiviert werden.

Wird nur aktiviert wenn Retry + Self-Critique keinen Treffer liefern (Ablehner nach Stufe 1). Generiert 5-8 alternative Suchbegriffe via LLM, durchsucht alle Collections einzeln, sammelt bis zu 136 Chunks und versucht eine Teilantwort. Letzte Rettung vor "Dazu liegen keine Informationen vor". Nur bei DEEP_SEARCH_ENABLED=1.

Die rohe Antwort des Sprachmodells wird für die Anzeige aufbereitet: Formatierungszeichen wie ** oder ## die das Modell manchmal einfügt werden entfernt. Jede Quellenangabe wird als klickbarer Link zur Originalseite auf stadt-brandenburg.de oder erlebnis-brandenburg.de aufgebaut. Bei Spracheingabe wird die Antwort zusätzlich an den Vorlesedienst (Piper TTS — ein Sprachsyntheser, der lokal auf dem Server läuft) übergeben. Erst dann wird die fertige Antwort Wort für Wort (Streaming) an den Browser des Bürgers übertragen. Stand 10.04.2026: Im Stream-Pfad /ask_stream läuft aktuell nur _validate_answer() (rag_chat.py:302). Der erweiterte _cleanup_response() mit Hedging- und Meta-Leak-Regex (rag_chat.py:391) wirkt nur im Non-Streaming-Pfad /ask via _call_ollama Z.519. Siehe docs/Systemanalyse20260410.md Finding #1.

Vor der LLM-Generierung wird eine detaillierte Antwort-Instruktion erstellt: Formale Anrede („Sie"), Quellenpflicht, Länge (max. 4 Sätze), intent-spezifische Regeln (WHO → Name+Funktion+Kontakt, WHERE → Adresse+Öffnungszeiten, WHEN → Datum+Uhrzeit). Bei zu wenig Kontext (Score < 0.18) greift die Fallback-Logik: Das System antwortet ehrlich „Dazu habe ich leider keine verlässliche Information" statt zu halluzinieren.

Zeigt ein farbiges Balkendiagramm der gemessenen Laufzeiten aller Verarbeitungsschritte. Typisch: Sprachverarbeitung (NLP) ~15 ms, KI-Bedeutungssuche (Qdrant) ~150 ms, Stichwortsuche (Meilisearch) ~70 ms, Zusammenführung (RRF) ~10 ms, Sprachmodell (LLM) 3–8 Sekunden. Der mit Abstand größte Zeitblock ist immer die KI-Generierung der Antwort.

Dieser letzte Schritt ist kein technischer Verarbeitungsschritt, sondern ein bewusstes Bekenntnis: Die gesamte Verarbeitung — von der Frage des Bürgers bis zur fertigen Antwort — findet ausschließlich auf dem eigenen Server der STG Brandenburg an der Havel statt. Kein einziges Wort der Bürgerfrage verlässt den städtischen Server. Es wird kein Cloud-Dienst genutzt, keine externe KI-API aufgerufen (OpenAI, Google, Microsoft etc.), keine Nutzerdaten weitergegeben. Das Sprachmodell qwen3:14b, die Vektordatenbank Qdrant, die Suchmaschine Meilisearch und der Vorlesedienst Piper — alle laufen vollständig lokal auf der eigenen Hardware.

qwen3:14b wird ein zweites Mal aufgerufen — diesmal nicht als Chatbot, sondern als Judge. Er bewertet jede Antwort auf zwei Metriken: Faithfulness (Ist die Antwort durch die gefundenen Quellen belegt, oder halluziniert der LLM?) und Context Precision (Sind die retrieved Chunks überhaupt relevant für die Frage?). So lässt sich gezielt erkennen, ob ein Problem im Retrieval oder in der Generierung liegt.

… Testfragen werden regelmäßig automatisch gegen die Pipeline getestet. Jede Antwort wird als OK oder Ablehner klassifiziert (ok_count Tracking). Ergebnisse fließen in die Lückenanalyse: Ablehner-Muster werden erkannt, fehlende Synonyme automatisch generiert und das System kontinuierlich verbessert.

Jeder Verarbeitungsschritt wird als Span mit Zeitstempel in PostgreSQL gespeichert. 7 Spans: nlp_phase → sql_rag → embed → qdrant_search → meilisearch_search → rerank_merge → llm_generate. Bei Produktionsfehlern ist sofort sichtbar: In welchem Schritt ist die Pipeline abgewichen? Dashboard unter /admin/traces mit Span-Statistiken und Timeline-Visualisierung.

Jede Chat-Antwort wird in der Ergebnis-Datenbank gespeichert. Negative Bewertungen (👎) und Antworten mit niedrigem Score fließen automatisch als neue Testfälle in den Benchmark-Katalog. So wächst die Testabdeckung organisch mit der realen Nutzung. Positive Antworten können als FAQ-Einträge übernommen werden. Der Kreislauf schließt sich: Chat → Feedback → Benchmark → Verbesserung → bessere Antworten.

Integrierte CI/CD-Pipeline unter /admin/cicd: Quality Gate prüft Regressions-Risiko vor Deployment (Stichprobe N=20), Deploy-Button mit automatischem Service-Restart, Regression-Check vergleicht aktuelle Antworten mit letztem Benchmark. Benchmark-Durchläufe als eigenständiger systemd-Worker-Service (kistack-benchmark.service), unabhängig von UI und API.