What Is Live in Production - Eine ungeschminkte Bestandsaufnahme

Serie: Architektonische KI-Governance auf Gemeinschaftsebene - Eine technische Untersuchung von Village AI (Artikel 4 von 5) Autor: My Digital Sovereignty Ltd Datum: März 2026 Lizenz: CC BY 4.0 International

Geltungsbereich

Dieser Artikel beschreibt das System, wie es im März 2026 in Produktion ist. Wo eine Fähigkeit geplant ist, aber noch nicht eingesetzt wird, wird dies erwähnt. Wo eine Fähigkeit bereits eingesetzt wird, aber bekannte Einschränkungen aufweist, werden diese beschrieben. Ziel ist eine Bestandsaufnahme, anhand derer ein Forscher den Reifegrad des Systems und die an anderer Stelle in dieser Reihe gemachten Aussagen beurteilen kann.

Village AI ist seit Oktober 2025 in Betrieb. Es handelt sich um ein junges System, das in bescheidenem Umfang betrieben wird. Im Folgenden finden Sie eine technische Beschreibung der eingesetzten Architektur.

Modellarchitektur

Basismodell: villageai-8b-corrected-v4 - ein 8B-Parametermodell, das als Basisschicht für alle Mieter dient. Geschult an den operativen Inhalten der Plattform: Funktionsdokumentation, Navigationsmuster, Muster für Hilfeabfragen und Konventionen für die Interaktion mit der Gemeinschaft.

Spezialisierte Schichten: Pro Produkttyp feinabgestimmte Modelle, die über eine Routing-Schicht (model-routing.js) bereitgestellt werden. Die erste Produktionsspezialisierung ist villageai-8b-episcopal-v2, fein abgestimmt auf bischöfliche/anglikanische liturgische, pastorale und Governance-Inhalte. Weitere Spezialisierungen (Familie, Naturschutz, Gemeinschaft) sind geplant, aber noch nicht ausgebildet.

Modell-Routing: Ein InferenceRouter wählt das geeignete Modell auf der Grundlage des Produkttyps des Mandanten aus. Wenn für die Produktart des Mandanten eine Spezialisierung existiert, wird diese verwendet; andernfalls wird das Basismodell für die Anfrage verwendet. Eine erweiterte Ebene ist in der Architektur definiert, aber noch nicht bestückt.

Inferenz-Hardware: Die primäre Inferenz läuft auf einer AMD RX 7900 XTX GPU, auf die über WireGuard VPN vom Anwendungsserver (OVH Frankreich) zugegriffen wird. CPU-Fallback ist unter Verwendung eines 3B-Parameter-degradierten Modells für die Verfügbarkeit bei GPU-Ausfällen verfügbar. Der Grafikprozessor befindet sich nicht am gleichen Standort wie der Anwendungsserver - die Inferenzanfragen durchqueren einen VPN-Tunnel, wodurch sich die Netzwerklatenz auf dem Inferenzpfad erhöht.

Framework: Die Inferenz wird über Ollama verwaltet, wobei der InferenceRouter die Modellauswahl und die Weiterleitung von Anfragen übernimmt. Das System verwendet keine Inferenz-API von Drittanbietern; die gesamte Generierung erfolgt auf einer kontrollierten Infrastruktur.

Abruf-erweiterte Generierung

Vektorspeicher: Qdrant, der Einbettungen von Community-Inhalten speichert (Beiträge, Ankündigungen, Dokumente, Ereignisbeschreibungen, Governance-Datensätze).

Einbettungspipeline: Der EmbeddingService verarbeitet Community-Inhalte in Vektordarstellungen. Die Inhalte werden pro Tenant gechunked, eingebettet und indiziert, wobei eine strikte Tenant-Isolierung auf der Ebene des Vektorspeichers beibehalten wird.

Retrieval zur Inferenzzeit: Benutzeranfragen werden eingebettet und für die Cosinus-Ähnlichkeitssuche gegen den Dokumentenkorpus des Mandanten verwendet. Die abgerufenen Dokumente werden dem Generierungsmodell als Kontext zur Verfügung gestellt, so dass die Antworten auf den tatsächlichen Inhalt der Community basieren.

Inhaltsindizierung: Ein ContentIndexer-Dienst verarbeitet neue und aktualisierte Inhalte im Vektorspeicher. Bei der Indizierung werden die Grenzen der Zustimmung beachtet - Inhalte, die nicht ausdrücklich für die KI-Nutzung freigegeben sind, werden nicht indiziert.

Guardian Agent Pipeline

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

Schicht 1: AccuracyVerifier

• Bettet die Antwort des Modells ein und berechnet die Kosinusähnlichkeit mit den für die Anfrage abgerufenen Quelldokumenten
• Markiert Antworten unterhalb eines konfigurierbaren Ähnlichkeitsschwellenwertes
• Liefert eine Basisbewertung, die in den benutzerseitigen Vertrauensindikator einfließt
• Bekannte Einschränkung: Die Cosinus-Ähnlichkeit ist ein Maß für die semantische Nähe und keine Garantie für die sachliche Richtigkeit. Zwei Sätze können semantisch nahe beieinander liegen, sich aber in wichtigen Details unterscheiden.

Schicht 2: HalluzinationDetector

• Zerlegt die Antworten in einzelne Behauptungen
• Überprüft jede Behauptung unabhängig mit dem Quellkorpus
• Markiert einzelne Behauptungen, die nicht fundiert sind, selbst in ansonsten gut begründeten Antworten
• Bekannte Einschränkung: Die Anspruchszerlegung selbst nutzt die Inferenz von Sprachmodellen, wodurch eine Abhängigkeit von der Modellfähigkeit entsteht. Eine fehlerhafte Dekomposition von Behauptungen kann zu falsch negativen Ergebnissen führen.

Schicht 3: AnomalyDetector + PressureMonitor

• Verfolgt die Verteilungseigenschaften der Modellausgaben über die Zeit
• Erkennt Vokabeldrift, thematische Anomalien und Änderungen der Antwortmerkmale
• PressureMonitor verfolgt die Inferenzbedingungen: Kontextlänge, Abfragekomplexität, gleichzeitige Last
• Bei erhöhtem Druck werden die Verifikationsschwellen verschärft und die Konfidenzgrenzen gesenkt
• Bekannte Einschränkung: Die Erkennung von Anomalien erfordert einen Basiszeitraum. Bei neuen Mietern mit begrenzter Interaktionshistorie ist die Basislinie spärlich und die Anomalieerkennung ist weniger effektiv.

Schicht 4: ResponseReviewer + RegressionMonitor + Adaptive Feedback

• Verarbeitet Mitglieder-Feedback (Daumen-nach-unten-Signale, Moderationskorrekturen)
• RootCauseClassifier kategorisiert Fehlerarten
• FeedbackInvestigator prüft, ob Fehler systematische Muster darstellen
• RegressionMonitor verfolgt, ob zuvor korrigierte Fehlermodi wiederkehren
• TrainingPairGenerator erzeugt Trainingsdaten aus bestätigten Korrekturen für zukünftige Feinabstimmungszyklen
• Bekannte Einschränkung: Die Feedback-Schleife hängt vom Engagement der Mitglieder ab. Gemeinschaften mit geringem Feedback-Volumen liefern kein ausreichendes Signal für eine aussagekräftige Mustererkennung.

Schutz vor Präferenzen

Ein PreInferenceProtector arbeitet vor der Generierung, indem er Eingaben auf Injektionsmuster überprüft und bestimmte Abfragetypen direkt zur menschlichen Überprüfung weiterleitet. Dabei handelt es sich um einen konservativen Filter, der eher blockiert, und der von der Guardian-Pipeline nach der Generierung getrennt ist.

Was das System heute kann

Gemeindebezogene Fragebeantwortung Bei einer Abfrage zu Gemeindeinhalten ("Wann ist die nächste Gemeindeversammlung?", "Was hat der Rektor über den Baufonds gesagt?") ruft das System relevante Dokumente ab und erzeugt eine Antwort, die auf diesen Inhalten basiert. Wenn keine relevanten Dokumente gefunden werden, zeigt das System dies an, anstatt eine Antwort auf der Grundlage der Priors des Basismodells zu generieren.

**Das System kann Entwürfe für Bulletins, Ankündigungen und Korrespondenz erstellen, die den Ton und das Vokabular der Gemeinschaft widerspiegeln. Alle Entwürfe werden vor der Veröffentlichung von einem Moderator geprüft.

Dokumentenzusammenfassung. Lange Dokumente (Gemeindeprotokolle, Grundsatzdokumente) 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 Maori. Die Übersetzung verwendet DeepL (nicht das Generierungsmodell), um die Genauigkeit zu gewährleisten.

Feedback Triage. Die Rückmeldungen der Mitglieder werden automatisch klassifiziert, wenn möglich untersucht und an den zuständigen Moderator weitergeleitet. Der HelpFeedbackSweepService und der GeneralFeedbackProcessor übernehmen die automatische Untersuchung und Lösung.

OCR und Dokumentenverarbeitung. Der DocumentExtractor-Dienst verarbeitet gescannte Dokumente und macht deren Inhalt durchsuchbar und für den Abruf durch die RAG 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:

Oberflächenebene: Benutzeroberflächenbezeichnungen, Navigationsbegriffe und Funktionsnamen werden durch bereichsgerechtes Vokabular ersetzt. Eine episkopale Kirchengemeinde sieht "Gemeindemitglieder", "Kirchenvorstand" und "Gemeindebriefe" statt allgemeiner Plattformterminologie.

Modellebene: Das Vokabular bestimmt den Kontext, der dem Modell zur Verfügung gestellt wird. Wenn sich das System im Kontext der Eingabeaufforderung auf "Gemeindemitglieder" und nicht auf "Benutzer" bezieht, spiegelt die Ausgabe des Modells diesen Rahmen wider. Dies ist ein leichter Eingriff - er wirkt auf der Ebene der Eingabeaufforderung, nicht auf der Ebene der Gewichtung - aber er verringert die Reibung zwischen den Verteilungsprioritäten des Modells und der Terminologie der Gemeinde.

Es werden neun Produkttypen definiert: Gemeinde, Familie, Naturschutz, Diaspora, Vereine, Unternehmen, Ehemalige, Whanau und Episkopal. Jeder dieser Typen hat eine eigene Vokabularzuordnung.

Was noch nicht bewiesen ist

Wir zählen bestimmte Aussagen auf, die noch nicht validiert wurden:

**Guardian Agent Wirksamkeit unter gegnerischen Bedingungen. ** Das System wurde keinem systematischen Red-Teaming unterzogen. Guardian Agent Die Leistung bei gegnerischen Aufforderungen, absichtlichen Versuchen, Halluzinationen hervorzurufen, oder koordinierten Injektionsangriffen ist unbekannt.

**Die Spezialisierung Episcopal (villageai-8b-episcopal-v2) wurde für einen Produkttyp eingesetzt. Ob sich die Strategie der spezialisierten Ebene wirksam auf andere Bereiche (Naturschutzökologie, kulturelle Kontexte der Maori, Familienforschung) übertragen lässt, wurde nicht empirisch nachgewiesen.

**Die vom AccuracyVerifier verwendeten Ähnlichkeitsschwellenwerte wurden auf der Grundlage von Entwicklungstests und ersten Produktionserfahrungen festgelegt. Sie wurden nicht durch systematische Evaluierung anhand eines gelabelten Datensatzes mit fundierten und nicht fundierten Antworten optimiert.

Langfristige Verteilungsstabilität. Das System ist seit etwa fünf Monaten in Produktion. Ob sich die Prioritäten des Basismodells im Laufe der Zeit wieder durchsetzen - ein langsames Abdriften zurück zur Trainingsverteilung trotz Feinabstimmung - wurde nicht über einen ausreichenden Zeithorizont beobachtet, um Schlussfolgerungen zu ziehen.

Sprachübergreifende Verifikation. Für Communities, die in anderen Sprachen als Englisch arbeiten, arbeitet die Guardian Agent Pipeline mit Einbettungen des nicht-englischen Textes. Ob die Kosinus-Ähnlichkeitsprüfung in allen Sprachen gleich effektiv ist, wurde nicht systematisch untersucht.

Konvergenz der Rückkopplungsschleife Der adaptive Rückkopplungsmechanismus (Schicht 4) ist so konzipiert, dass er das Systemverhalten im Laufe der Zeit verbessert. Ob er zu einer stabilen, verbesserten Leistung konvergiert oder unter bestimmten Feedback-Mustern ein oszillierendes oder divergierendes Verhalten zeigt, wurde nicht formal analysiert.

Wir stellen diese Fragen nicht als Aufschub, sondern als offene Fragen dar. Das System ist in Betrieb; diese Fragen sind unbeantwortet.

Infrastruktur

• Anwendungsserver: OVH Frankreich (EU-Datenhoheit)
• Datenbank: MongoDB mit strikter Tenant-Isolierung (jede Abfrage wird nach TenantId gefiltert)
• Vektorspeicher: Qdrant (mandantenübergreifende Sammlungen)
• GPU-Inferenz: AMD RX 7900 XTX über WireGuard VPN
• CPU-Fallback: 3B degraded model für Verfügbarkeit
• Authentifizierung: httpOnly-Cookies, Tenant-Kontext-Isolierung, kein öffentlicher Zugriff
• Bereitstellung: Selbst gehostet, keine Cloud-KI-Dienste von Dritten
• Medien: Bunny CDN für Edge-Caching (OVH-Server)

Alle Schlussfolgerungen erfolgen innerhalb der Infrastruktur des Betreibers. Es werden keine Prompts, Antworten oder Community-Inhalte an Drittanbieter von KI übertragen.

Dies ist Artikel 4 von 5 in der Reihe "Architektonische KI-Governance im Gemeinschaftsmaßstab". Die vollständige technische Architektur finden Sie unter Village AI on Agentic Governance.

Vorherige Seite: Warum Governance zur Einarbeitungszeit scheitert - Architektonische Einschränkungen als Alternative Nächste: Jenseits des Modells - Plattformarchitektur und Governance-Integration