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: Juni 2026 Lizenz: CC BY 4.0 International

Geltungsbereich

Dieser Artikel beschreibt das System, wie es im Juni 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. Es folgt eine technische Beschreibung der eingesetzten Architektur.

Modellarchitektur

Basismodell: eine Feinabstimmung mit 14B-Parametern Qwen2, die 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 Community.

Spezialisierte Schichten: Pro Produkttyp feinabgestimmte Modelle, die über eine Routing-Schicht (model-routing.js) bereitgestellt werden. Bei den Produktionsspezialisierungen handelt es sich um die villageai-14b-{community,whanau,episcopal,family,business}-v1-Familie, die jeweils auf den Inhalt ihres Produkttyps abgestimmt sind (die Episcopal-Spezialisierung, villageai-14b-episcopal-v1, auf anglikanisches Material zu Liturgie, Pastoral und Verwaltung). Weitere Produkttypen (z.B. Konservierung, Alumni, Diaspora) sind geplant, aber noch nicht trainiert. Bildverarbeitungsaufgaben (Fotoklassifizierung, OCR) gehen an qwen2.5vl:7b.

Modell-Routing: Ein InferenceRouter wählt das passende Modell auf der Grundlage des Produkttyps des Tenants aus. Wenn eine Spezialisierung für den Produkttyp des Mandanten 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 durchlaufen einen VPN-Tunnel, wodurch sich die Netzwerklatenz auf dem Inferenzpfad erhöht.

Framework: Die Inferenz wird über Ollama verwaltet, wobei die 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 (Geschichten, Ankündigungen, Dokumente, Ereignisbeschreibungen, Governance-Aufzeichnungen) speichert.

Einbettungspipeline: Der EmbeddingService verarbeitet Gemeinschaftsinhalte in Vektordarstellungen. Die Inhalte werden pro Mandant in Stücke geschnitten, eingebettet und indiziert, wobei die strikte Isolierung der Mandanten 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
• Kennzeichnet Antworten unterhalb eines konfigurierbaren Ähnlichkeitsschwellenwertes
• Liefert einen Grounding Score, der 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: HallucinationDetector

• Zerlegung der Antworten in einzelne Aussagen
• Ü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 des Sprachmodells, 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 im Laufe der 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 Verifizierungsschwellen 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 Rückmeldung

• Verarbeitet das Feedback der Mitglieder (Daumen-nach-unten-Signale, Moderationskorrekturen)
• RootCauseClassifier kategorisiert Fehlerarten
• FeedbackInvestigator untersucht, ob Ausfälle 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 Feedbackschleife 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

PreInferenceProtector arbeitet vor der Generierung, indem es die 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 leisten 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 - und die vom System eingesetzte agenturische Oberfläche. Das Feedback der Mitglieder wird automatisch klassifiziert, wenn möglich untersucht und an den entsprechenden Moderator weitergeleitet. Dies ist auch der Punkt, an dem das System handelt und nicht nur antwortet: ResolutionExecutor verfolgt eine hohe Rate an automatischen Lösungen für Routinefälle mit geringem Risiko, indem es die korrekte Antwort mit dem Korpus vergleicht und die Wissensdatenbank selbstständig aktualisiert, während ein erkanntes Muster verwandter Fehler zur menschlichen Entscheidung eskaliert wird, anstatt darauf zu reagieren. Dies ist eine absichtlich eingeschränkte Handlungsfähigkeit: mehrstufige Aktionen, die auf die Grenzen des Mieters und auf umkehrbare Vorgänge beschränkt sind, eine Umsetzung des Grundsatzes der Durchsetzung von Grenzen (Artikel 3) anstelle einer unbegrenzten Browser-/Computernutzungsautonomie. Damit kommt das eingesetzte System einem "Agenten" im Sinne von 2025-2026 am nächsten, und die Beschränkungen sind der springende Punkt.

**Der DocumentExtractor-Dienst verarbeitet gescannte Dokumente und macht ihren 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.

Verallgemeinerung der spezialisierten Schicht. Es gibt jetzt Spezialisierungen für mehrere Produkttypen (villageai-14b-{Gemeinde,Whanau,Episkopal,Familie,Unternehmen}-v1`). Ob die Specialised-Layer-Strategie wirksam generalisiert - d.h. die stille Verteilungsumkehr messbar reduziert - in diesen Bereichen und in noch nicht trainierten Bereichen (Naturschutzökologie, te reo Maori-Kulturkontext, Familiengenealogie), wurde nicht empirisch nachgewiesen. Der Einsatz ist kein Beweis für die Wirksamkeit.

**Die von AccuracyVerifier verwendeten Ähnlichkeitsschwellenwerte wurden auf der Grundlage von Entwicklungstests und ersten Produktionserfahrungen festgelegt. Sie wurden nicht durch eine systematische Evaluierung anhand eines markierten Datensatzes von geerdeten und nicht geerdeten Antworten optimiert.

Langfristige Verteilungsstabilität. Das System ist seit etwa acht 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 gefiltert nach TenantId)
• 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
• Entwicklung: 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 zu Agentic Governance.

Zurück: Warum Governance zur Einarbeitungszeit scheitert - Architektonische Beschränkungen als Alternative Nächste: Jenseits des Modells - Plattformarchitektur und Governance-Integration