Alle Ausgaben · AI Research Edition

Your Community, Your AI — CC BY 4.0

Was ist „Live in Production“ – Eine ungeschönte Bestandsaufnahme

Geltungsbereich

Dieser Artikel beschreibt das System, wie es im Juni 2026 in der Produktion vorliegt. Wenn eine Funktion geplant, aber noch nicht implementiert ist, weisen wir darauf hin. Wenn eine Funktion implementiert ist, aber bekannte Einschränkungen aufweist, beschreiben wir diese Einschränkungen. Ziel ist eine Bestandsaufnahme, anhand derer Forscher den Reifegrad des Systems sowie die an anderer Stelle in dieser Reihe aufgestellten Behauptungen bewerten können. (Serienspezifische Begriffe sind im Glossar definiert.)

Village AI ist seit 2025 im Produktivbetrieb – derzeit in der Startphase mit Gründungsauftrag. Es handelt sich um ein junges System, das in bescheidenem Umfang betrieben wird. Im Folgenden folgt eine technische Beschreibung der implementierten Architektur.

Modellarchitektur

Basismodell: ein auf die Qwen2-Familie abgestimmtes Feinabstimmungsmodell mit 14 Milliarden Parametern, villageai-14b-community-v1, das als Grundlage und Standardschicht für alle nicht spezialisierten Mandanten dient (festgelegt über OLLAMA_MODEL). Trainiert auf der Grundlage von plattformspezifischen Inhalten: Funktionsdokumentation, Navigationsmuster, Muster für Hilfeanfragen und Konventionen für die Interaktion in der Community. Es handelt sich um ein leistungsstarkes Generalistenmodell, nicht um ein abgespecktes Modell – es wird auch vom CPU-Fallback-Pfad genutzt (siehe unten).

Spezialisierte Schichten: Pro Produkttyp feinabgestimmte Modelle, die über eine Routing-Schicht (model-routing.js) bereitgestellt werden. Die Produktionsspezialisierungen gehören zur Familie villageai-14b-{community,whanau,episcopal,family,business}-v1, wobei jede auf die Inhalte ihres jeweiligen Produkttyps feinabgestimmt ist (die „Episcopal“-Spezialisierung, villageai-14b-episcopal-v1, auf anglikanisches Material zu Liturgie, Seelsorge und Kirchenleitung). Weitere Produkttypen (z. B. Denkmalschutz, Alumni, Diaspora) sind geplant, wurden jedoch noch nicht trainiert. Vision- und OCR-Aufgaben werden über denselben InferenceRouter an ein lokales qwen2.5vl:7b weitergeleitet.

Modell-Routing: getModelForTenant (in model-routing.js) wählt das Modell anhand des Produkttyps des Mandanten aus. Wenn für diesen Produkttyp eine Spezialisierung existiert, wird diese verwendet; andernfalls bedient das Basismodell die Anfrage. Ein Inferenz-Host mit einer einzigen GPU kann OLLAMA_FORCE_BASE_MODEL=true setzen, um alle Mandanten auf das 14B-Basismodell umzuleiten – dies verhindert, dass ein Ollama-System mit 24 GB, auf dem nur ein einziges Modell residiert, zwischen den produktbezogenen Feinabstimmungen hin- und herwechselt. Im Routing-Code existiert eine erweiterte Ebene (ENHANCED_MODELS), die derzeit jedoch eine leere Zuordnung darstellt: Sie ist für zukünftige Premium-Funktionen reserviert und greift standardmäßig auf die Standardebene zurück, sodass derzeit keinem Mandanten ein erweitertes Modell bereitgestellt wird. Beachten Sie, dass es keine Unterscheidung zwischen „schneller“ und „tiefer“ Schlussfolgerung gibt; die eigentliche Einstufung erfolgt anhand von Basis- und spezialisierten Gewichten, GPU/CPU-Failover und der Verifizierungsschicht.

Inferenz-Hardware: Die primäre Inferenz läuft auf einer AMD RX 7900 XTX (24 GB) zu Hause, die über einen WireGuard-Tunnel (OLLAMA_GPU_URL) vom Anwendungsserver (OVH Frankreich) aus mit etwa 150 Token/Sekunde erreicht wird. Die GPU befindet sich nicht am selben Standort wie der Anwendungsserver – Anfragen durchlaufen das VPN, was zu einer zusätzlichen Netzwerklatenz im Inferenzpfad führt. Bei einem GPU-Ausfall wird die Inferenz auf die CPU des OVH-Hosts umgeschaltet, auf der die gleichen villageai-14b-community-v1-Gewichte (OLLAMA_CPU_MODEL) mit einer Geschwindigkeit von etwa 7 Token/Sekunde laufen – es handelt sich um einen reduzierten Durchsatz, nicht um ein kleineres Modell. Unabhängig davon dient eine NVIDIA A6000 (48 GB) bei Catalyst NZ als Trainings-System, das zwischen den Feinabstimmungs-Sprints stillgelegt ist; es befindet sich nicht im Inferenzpfad.

Framework: Die Inferenz wird über Ollama verwaltet, wobei der InferenceRouter die Modellauswahl und das Routing der Anfragen übernimmt. Das System nutzt keine Inferenz-APIs von Drittanbietern; die gesamte Generierung erfolgt auf kontrollierter Infrastruktur.

Retrieval-Augmented Generation

Vektorspeicher: Qdrant, der 384-dimensionale Einbettungen von Community-Inhalten (Beiträge, Ankündigungen, Dokumente, Veranstaltungsbeschreibungen, Governance-Aufzeichnungen) speichert. Das Backend wird über VECTOR_STORE_BACKEND ausgewählt.

Einbettungspipeline: Der EmbeddingService verarbeitet Community-Inhalte mithilfe eines lokalen Xenova/all-MiniLM-L6-v2-Modells (384-dimensional) zu Vektordarstellungen – ohne Einbettungs-API von Drittanbietern. Die Inhalte werden pro Mandant in Blöcke unterteilt, eingebettet und indiziert, wodurch eine strikte Mandantenisolierung auf der Ebene des Vektorspeichers gewährleistet wird.

Abruf zur Inferenzzeit: Benutzerabfragen werden eingebettet und für die Kosinus-Ähnlichkeitssuche im Dokumentenkorpus des Mandanten verwendet. Die abgerufenen Dokumente dienen dem Generierungsmodell als Kontext, wodurch dessen Antworten auf den tatsächlichen Inhalten der Community basieren.

Inhaltsindizierung: Ein ContentIndexer-Dienst verarbeitet neue und aktualisierte Inhalte im Vektorspeicher. Die Indizierung berücksichtigt Einwilligungsgrenzen – Inhalte, die nicht ausdrücklich für die KI-Nutzung freigegeben wurden, werden nicht indiziert.

Guardian Agent-Pipeline

Jede KI-Antwort durchläuft vier Guardian Agent-Schichten, bevor sie den Nutzer erreicht. Die Pipeline ist in src/services/guardians/ implementiert und strukturell unabhängig vom Generierungsmodell.

Ebene 1: AccuracyVerifier

• Bettet die Antwort des Modells ein und berechnet die Kosinusähnlichkeit im Vergleich zu den für die Abfrage abgerufenen Quelldokumenten
• Markiert Antworten, die unter einem konfigurierbaren Ähnlichkeitsschwellenwert liegen
• Liefert einen Verankerungswert, der in den für den Nutzer sichtbaren Konfidenzindikator einfließt
• Bekannte Einschränkung: Die Kosinusähnlichkeit ist ein Maß für die semantische Nähe, kein Beweis für die sachliche Richtigkeit. Zwei Sätze können semantisch nahe beieinander liegen, sich jedoch in wesentlichen Details unterscheiden.

Ebene 2: HallucinationDetector

• Zerlegt die Antworten in einzelne Behauptungen
• Überprüft jede Behauptung unabhängig vom Quellkorpus
• Markiert einzelne Behauptungen, denen die Verankerung fehlt, selbst in ansonsten gut fundierten Antworten
• Bekannte Einschränkung: Die Aufschlüsselung der Aussagen selbst nutzt die Inferenz des Sprachmodells, wodurch eine Abhängigkeit von der Modellleistung entsteht. Eine fehlerhafte Aufschlüsselung der Aussagen kann zu falsch-negativen Ergebnissen führen.

Ebene 3: AnomalyDetector + PressureMonitor

• Verfolgt die Verteilungseigenschaften der Modellausgaben im Zeitverlauf
• Erkennt Vokabularverschiebungen, thematische Anomalien und Veränderungen der Antwortmerkmale
• Der PressureMonitor verfolgt die Inferenzbedingungen: Kontextlänge, Komplexität der Abfrage, gleichzeitige Auslastung
• Bei erhöhtem Druck werden die Verifizierungsschwellen verschärft und die Konfidenzobergrenzen gesenkt
• Bekannte Einschränkung: Die Anomalieerkennung erfordert einen Basiszeitraum. Bei neuen Mandanten mit begrenzter Interaktionshistorie ist die Basisperiode spärlich, wodurch die Anomalieerkennung weniger effektiv ist.

Ebene 4: ResponseReviewer + RegressionMonitor + Adaptives Feedback

• Verarbeitet Feedback von Mitgliedern (Daumen-runter-Signale, Korrekturen durch Moderatoren)
• Der RootCauseClassifier kategorisiert Fehlermodi
• Der „FeedbackInvestigator“ untersucht, ob Fehler systematische Muster darstellen
• Der „RegressionMonitor“ verfolgt, ob zuvor korrigierte Fehlermodi erneut auftreten
• Der „TrainingPairGenerator“ erstellt aus bestätigten Korrekturen Trainingsdaten für zukünftige Feinabstimmungszyklen
• Bekannte Einschränkung: Die Rückkopplungsschleife hängt vom Engagement der Mitglieder ab. Communities mit geringem Feedback-Aufkommen liefern keine ausreichenden Signale für eine aussagekräftige Mustererkennung.

Schutz vor der Inferenz

Ein „PreInferenceProtector“ greift vor der Generierung ein, überprüft Eingaben auf Injektionsmuster und leitet bestimmte Abfragetypen direkt zur Überprüfung durch Menschen weiter. Dabei handelt es sich um einen konservativen Filter – er neigt eher dazu, zu blockieren – und ist von der „Guardian“-Pipeline nach der Generierung getrennt.

Das Verifizierungstrio des Frameworks und die Help-Stream-Gates

Neben den vier Guardian-Ebenen laufen zwei weitere Verifizierungspfade, die es wert sind, gesondert betrachtet zu werden, da sie häufig miteinander verwechselt werden:

• Das Framework-Trio. Chat-Antworten werden von chatAnnotator.js annotiert, das stets drei strukturell unabhängige Framework-Prüfungen durchführt – BoundaryEnforcer (Durchsetzung von Inhalts-/Domänen-Gates), CrossReferenceValidator (RAG-Gegenprüfung) und MetacognitiveVerifier (Verifizierungshistorie) – und wird bei den Whānau- und Māori-Pilotprojekten durch einen PluralisticDeliberationOrchestrator-Durchlauf vertieft. Dies sind die framework-eigenen Governance-Komponenten, die sich von der Suite src/services/guardians/ unterscheiden.
• Das Help-Stream-Gate 1/2/3. Der Help-WebSocket-Pfad (HelpWebSocketService.js) erzwingt eine buchstäbliche Drei-Gate-Pipeline über die gestreamte Antwort (einschließlich Erkennung von Wiederholungen während des Streams und Abbruch an Gate 2). Dies ist eine konkrete Streaming-Sicherheitsmaßnahme und keine Umbenennung der vier Guardian-Schichten oder des oben genannten Framework-Trios.

Darüber hinaus umfasst die umfassendere Guardian-Suite den ResponseReviewer, den HallucinationDetector, den AccuracyVerifier, den AnomalyDetector, den PreInferenceProtector, einen ModelRollbackService sowie die adaptive Lernschleife. Der Grund für die separate Benennung liegt darin, dass „Verifizierung“ hier nicht aus einem einzigen Gate besteht, sondern aus mehreren sich teilweise überschneidenden Mechanismen auf unterschiedlichen epistemischen Grundlagen (Artikel 3).

Was das System heute leisten kann

Community-basierte Beantwortung von Fragen. Bei einer Anfrage zu Inhalten der Gemeinde („Wann findet die nächste Kirchenvorstandssitzung statt?“, „Was hat der Pfarrer zum Baufonds gesagt?“) ruft das System relevante Dokumente ab und generiert eine Antwort, die auf diesen Inhalten basiert. Werden keine relevanten Dokumente gefunden, weist das System darauf hin, anstatt eine Antwort auf der Grundlage der A-priori-Wahrscheinlichkeiten des Basismodells zu generieren.

Unterstützung beim Verfassen von Texten. Das System kann Entwürfe für Gemeindebriefe, Ankündigungen und Korrespondenz erstellen, die den Ton und den Wortschatz der Gemeinde widerspiegeln. Alle Entwürfe werden vor der Veröffentlichung von einem Moderator geprüft.

Zusammenfassung von Dokumenten. Lange Dokumente (Kirchenvorstandsprotokolle, Richtlinien) können zusammengefasst und die wichtigsten Punkte extrahiert werden.

Übersetzungsunterstützung. Die Plattform unterstützt fünf Sprachen: Englisch, Deutsch, Französisch, Niederländisch und Te Reo Māori. Für die Übersetzung wird DeepL (nicht das Generierungsmodell) verwendet, um die Genauigkeit zu gewährleisten.

Feedback-Triage – und die einsetzbare agierende Oberfläche des Systems. Das Feedback der Mitglieder wird automatisch klassifiziert, soweit möglich untersucht und an den zuständigen Moderator weitergeleitet. Hier handelt das System auch, anstatt nur zu antworten: Der „ResolutionExecutor“ strebt eine hohe Rate an automatischer Lösung für routinemäßige Fälle mit geringem Risiko an – indem er die richtige Antwort anhand des Korpus überprüft und die Wissensdatenbank autonom aktualisiert –, während ein erkanntes Muster verwandter Fehler zur menschlichen Beurteilung eskaliert wird, anstatt darauf zu reagieren. Dies ist bewusst begrenzte Handlungsfähigkeit: mehrstufige Aktionen, die auf die Mandantengrenze und auf reversible Vorgänge beschränkt sind – eine Konkretisierung des Prinzips der Grenzdurchsetzung (Artikel 3) anstelle einer uneingeschränkten Autonomie bei der Browser- bzw. Computernutzung. Dies kommt dem eingesetzten System am nächsten, was einen „Agenten“ im Sinne der Jahre 2025–2026 betrifft, und genau diese Einschränkungen sind der springende Punkt.

OCR und Dokumentenverarbeitung. Der DocumentExtractor-Dienst verarbeitet gescannte Dokumente, macht deren Inhalt durchsuchbar und für den RAG-Abruf verfügbar.

Vokabularsystem

Das Vokabularsystem (product-vocabularies.js, vocabulary.js) passt die Terminologie der Plattform an den Community-Typ an. Dies geschieht auf zwei Ebenen:

Schnittstellenebene: UI-Bezeichnungen, Navigationsbegriffe und Funktionsnamen werden durch domänenangemessenes Vokabular ersetzt. Eine episkopale Gemeinde sieht „Gemeindemitglieder“, „Kirchenvorstand“ und „Gemeindebriefe“ anstelle der generischen Plattformterminologie.

Modellebene: Das Vokabular prägt den Kontext, der dem Modell bereitgestellt wird. Wenn das System im Prompt-Kontext von „Gemeindemitgliedern“ statt von „Nutzern“ spricht, spiegelt die Ausgabe des Modells diesen Rahmen wider. Dies ist ein minimaler Eingriff – er findet auf der Prompt-Ebene statt, nicht auf der Gewichtungsebene –, reduziert jedoch die Reibung zwischen den Verteilungs-Prioren des Modells und der Terminologie der Community.

Es sind neun Produkttypen definiert: Gemeinschaft, Familie, Naturschutz, Diaspora, Vereine, Wirtschaft, Alumni, Whanau und bischöflich. Jeder verfügt über eine eigene Vokabularzuordnung.

Was noch nicht bewiesen ist

Wir listen spezifische Behauptungen auf, die noch nicht validiert wurden:

Die Wirksamkeit von Guardian Agent unter adversarialen Bedingungen. Das System wurde noch keinem systematischen Red-Teaming unterzogen. Die Leistung von Guardian Agent bei adversarialen Eingaben, gezielten Versuchen, Halluzinationen hervorzurufen, oder koordinierten Injektionsangriffen ist unbekannt.

Generalisierung der spezialisierten Schichten. Derzeit existieren Spezialisierungen für mehrere Produkttypen (villageai-14b-{community,whanau,episcopal,family,business}-v1). Ob sich die Strategie der spezialisierten Schichten über diese Domänen hinweg sowie auf bislang noch nicht trainierte Bereiche (Naturschutzökologie, kulturelle Kontexte des Te Reo Māori, Familiengenealogie) effektiv verallgemeinern lässt – d. h. ob sie die stille Verteilungsumkehr messbar reduziert –, wurde empirisch noch nicht nachgewiesen. Der Einsatz ist kein Beweis für die Wirksamkeit.

Kalibrierung der Kosinus-Ähnlichkeitsschwellenwerte. Die vom AccuracyVerifier verwendeten Ähnlichkeitsschwellenwerte wurden auf der Grundlage von Entwicklungstests und ersten Erfahrungen im Produktivbetrieb festgelegt. Sie wurden nicht durch eine systematische Bewertung anhand eines beschrifteten Datensatzes mit fundierten und unbegründeten Antworten optimiert.

Langfristige Verteilungsstabilität. Das System ist seit etwa acht Monaten im Einsatz. Ob sich die Prioren des Basismodells im Laufe der Zeit wieder durchsetzen – eine langsame Drift zurück zur Trainingsverteilung trotz Feinabstimmung –, wurde über einen Zeitrahmen, der für Schlussfolgerungen ausreicht, noch nicht beobachtet.

Sprachübergreifende Verifizierung. Für Communities, die in anderen Sprachen als Englisch arbeiten, verarbeitet die Guardian Agent-Pipeline Einbettungen des nicht-englischen Textes. Ob die Überprüfung anhand der Kosinusähnlichkeit sprachübergreifend gleichermaßen effektiv ist, wurde noch nicht systematisch evaluiert.

Konvergenz der Rückkopplungsschleife. Der adaptive Rückkopplungsmechanismus (Schicht 4) ist darauf ausgelegt, das Systemverhalten im Laufe der Zeit zu verbessern. Ob er unter bestimmten Rückkopplungsmustern zu einer stabilen, verbesserten Leistung konvergiert oder oszillierendes bzw. divergierendes Verhalten zeigt, wurde noch nicht formal analysiert.

Wir stellen diese Punkte nicht als Aufschübe, sondern als offene Fragen dar. Das System ist betriebsbereit; diese Fragen sind noch unbeantwortet.

Infrastruktur

• Anwendungsserver: OVH Frankreich (EU-Datenschutzgebiet)
• Datenbank: MongoDB mit strikter Mandantenisolierung (jede Abfrage wird nach tenantId gefiltert)
• Vektorspeicher: Qdrant (mandantenbezogene Sammlungen, 384-dimensional), Backend über VECTOR_STORE_BACKEND
• GPU-Inferenz: AMD RX 7900 XTX (24 GB) zu Hause über WireGuard (OLLAMA_GPU_URL), ~150 Token/s
• CPU-Fallback: OVH-Host, auf dem die gleichen villageai-14b-community-v1-Gewichte laufen (~7 Token/s), kein kleineres Modell
• Trainingssystem (offline): NVIDIA A6000 (48 GB) auf Catalyst NZ, zwischen den Feinabstimmungs-Sprints außer Betrieb – nicht im Inferenzpfad
• Authentifizierung: httpOnly-Cookies, Isolierung des Mandantenkontexts, kein öffentlicher Zugriff
• Bereitstellung: Selbst gehostet, keine Cloud-KI-Dienste von Drittanbietern
• Medien: Bunny CDN für Edge-Caching (OVH-Server)

Die gesamte Inferenz findet innerhalb der Infrastruktur des Betreibers statt. Es werden keine Eingabeaufforderungen, Antworten oder Community-Inhalte an externe KI-Anbieter übertragen.

Vollständige technische Architektur: Village AI zu Agentic Governance. Praxiskurse zum Betrieb dieser Systeme unter menschlicher Kontrolle: Arbeiten mit Claude und Agents at Work.