Alle edities · AI Research Edition

Your Community, Your AI — CC BY 4.0

Wat is ‘Live in Production’ — Een onverbloemde inventarisatie

Reikwijdte

Dit artikel beschrijft het systeem zoals het in juni 2026 in productie is. Wanneer een functionaliteit gepland is maar nog niet is geïmplementeerd, vermelden we dat. Wanneer een functionaliteit wel is geïmplementeerd maar bekende beperkingen heeft, beschrijven we die beperkingen. Het doel is een overzicht dat een onderzoeker kan gebruiken om de volwassenheid van het systeem en de beweringen elders in deze reeks te beoordelen. (Reeks-specifieke terminologie wordt gedefinieerd in de woordenlijst.)

Village AI is sinds 2025 in productie — momenteel in de ‘founding-charge’-fase. Het is een jong systeem dat op bescheiden schaal opereert. Hieronder volgt een technische beschrijving van de geïmplementeerde architectuur.

Modelarchitectuur

Basismodel: een met 14 miljard parameters afgestemd model uit de Qwen2-familie, villageai-14b-community-v1, dat dient als basis en standaardlaag voor alle niet-gespecialiseerde tenants (ingesteld via OLLAMA_MODEL). Getraind op operationele inhoud van het platform: documentatie over functies, navigatiepatronen, patronen voor hulpvragen en conventies voor interactie binnen de community. Het is een sterk generalistisch model, geen uitgeklede versie — het is ook het model dat wordt gebruikt als CPU-fallback (zie hieronder).

Gespecialiseerde lagen: Per producttype afgestemde modellen die worden ingezet via een routeringslaag (model-routing.js). De productiespecialisaties vormen de villageai-14b-{community,whanau,episcopal,family,business}-v1-familie, elk afgestemd op de inhoud van het betreffende producttype (de ‘Episcopal’-specialisatie, villageai-14b-episcopal-v1, op anglicaans liturgisch, pastoraal en bestuurlijk materiaal). Verdere producttypes (bijv. natuurbehoud, alumni, diaspora) zijn gepland maar nog niet getraind. Vision- en OCR-taken worden via dezelfde InferenceRouter doorgestuurd naar een lokale qwen2.5vl:7b.

Modelroutering: getModelForTenant (in model-routing.js) selecteert het model op basis van het producttype van de tenant. Als er een specialisatie bestaat voor dat producttype, wordt deze gebruikt; anders verwerkt het basismodel het verzoek. Een inferentiehost met één GPU kan OLLAMA_FORCE_BASE_MODEL=true instellen om alle tenants naar het basismodel 14B te leiden — dit voorkomt dat een Ollama met 24 GB, waarop slechts één model is geïnstalleerd, heen en weer schakelt tussen productspecifieke afstemmingen. Er bestaat een ‘enhanced tier’ in de routeringscode (ENHANCED_MODELS), maar dit is momenteel een lege map: deze is gereserveerd voor toekomstige premiumfuncties en valt terug op de standaard, dus geen enkele tenant krijgt op dit moment een ‘enhanced model’ aangeboden. Let op: er is geen onderscheid tussen ‘snel’ en ‘diep’ redeneren; de daadwerkelijke gelaagdheid bestaat uit basis- versus gespecialiseerde gewichten, GPU/CPU-failover en de verificatielaag.

Inferentiehardware: De primaire inferentie draait op een AMD RX 7900 XTX (24 GB) thuis, bereikbaar via een WireGuard-tunnel (OLLAMA_GPU_URL) vanaf de applicatieserver (OVH Frankrijk) met een snelheid van ongeveer 150 tokens per seconde. De GPU bevindt zich niet op dezelfde locatie als de applicatieserver — verzoeken gaan via de VPN, wat netwerklatentie toevoegt aan het inferentiepad. Bij een GPU-storing wordt de inferentie overgeschakeld naar de CPU op de OVH-host waarop de zelfde villageai-14b-community-v1-gewichten (OLLAMA_CPU_MODEL) draaien, met een snelheid van ongeveer 7 tokens per seconde — dit is een verminderde doorvoer, geen kleiner model. Los daarvan is een NVIDIA A6000 (48 GB) op Catalyst NZ een trainingssysteem, dat tussen de fine-tuning-sprints door buiten gebruik is; het maakt geen deel uit van het inferentiepad.

Framework: De inferentie wordt beheerd via Ollama, waarbij de InferenceRouter de modelselectie en het routeren van verzoeken afhandelt. Het systeem maakt geen gebruik van een inferentie-API van derden; alle generatie vindt plaats op gecontroleerde infrastructuur.

Retrieval-Augmented Generation

Vectoropslag: Qdrant, waarin 384-dimensionale embeddings van community-content (verhalen, aankondigingen, documenten, evenementbeschrijvingen, bestuursverslagen) worden opgeslagen. De backend wordt geselecteerd via VECTOR_STORE_BACKEND.

Embedding-pijplijn: De EmbeddingService verwerkt community-content tot vectorrepresentaties met behulp van een lokaal Xenova/all-MiniLM-L6-v2-model (384-dim) — er wordt geen gebruikgemaakt van een embedding-API van derden. Content wordt per tenant in stukken verdeeld, ingebed en geïndexeerd, waarbij strikte tenant-isolatie op het niveau van de vectoropslag wordt gehandhaafd.

Opvragen tijdens inferentie: Zoekopdrachten van gebruikers worden ingebed en gebruikt voor het zoeken op cosinus-similariteit in het documentcorpus van de tenant. De opgehaalde documenten worden als context aan het generatiemodel aangeboden, waardoor de antwoorden van het model worden gebaseerd op de daadwerkelijke content van de community.

Indexering van inhoud: Een ContentIndexer-service verwerkt nieuwe en bijgewerkte inhoud in de vectoropslag. Bij de indexering worden toestemmingsgrenzen gerespecteerd — inhoud die niet expliciet is gedeeld voor AI-gebruik, wordt niet geïndexeerd.

Guardian Agent-pijplijn

Elk AI-antwoord doorloopt vier Guardian Agent-lagen voordat het de gebruiker bereikt. De pijplijn is geïmplementeerd in src/services/guardians/ en is structureel onafhankelijk van het generatiemodel.

Laag 1: AccuracyVerifier

• Verwerkt het antwoord van het model en berekent de cosinusgelijkenis ten opzichte van de brondocumenten die voor de zoekopdracht zijn opgehaald
• Markeert antwoorden die onder een configureerbare gelijkenisdrempel liggen
• Levert een onderbouwingsscore die wordt gebruikt voor de vertrouwensindicator die de gebruiker te zien krijgt
• Bekende beperking: Cosinusgelijkenis is een maatstaf voor semantische nabijheid, geen bewijs van feitelijke nauwkeurigheid. Twee zinnen kunnen semantisch dicht bij elkaar liggen, terwijl ze op belangrijke details van elkaar verschillen.

Laag 2: HallucinationDetector

• Splits antwoorden op in afzonderlijke beweringen
• Controleert elke bewering afzonderlijk aan de hand van het broncorpus
• Markeert afzonderlijke beweringen die onvoldoende onderbouwd zijn, zelfs in antwoorden die verder wel goed onderbouwd zijn
• Bekende beperking: De ontleding van beweringen maakt zelf gebruik van inferentie op basis van het taalmodel, waardoor er een afhankelijkheid ontstaat van de capaciteit van het model. Een onjuist uitgevoerde ontleding van beweringen kan tot valse negatieven leiden.

Laag 3: AnomalyDetector + PressureMonitor

• Houdt de distributie-eigenschappen van modeloutputs in de loop van de tijd bij
• Detecteert verschuivingen in woordgebruik, afwijkingen in onderwerpen en veranderingen in de kenmerken van antwoorden
• PressureMonitor houdt inferentieomstandigheden bij: contextlengte, complexiteit van de zoekopdracht, gelijktijdige belasting
• Bij verhoogde druk worden de verificatiedrempels aangescherpt en worden de betrouwbaarheidsdrempels verlaagd
• Bekende beperking: Anomaliedetectie vereist een basisperiode. Voor nieuwe gebruikers met een beperkte interactiegeschiedenis is de basisperiode schaars en is anomaliedetectie minder effectief.

Laag 4: ResponseReviewer + RegressionMonitor + Adaptive Feedback

• Verwerkt feedback van leden (duim-omlaag-signalen, correcties door moderators)
• RootCauseClassifier categoriseert foutmodi
• FeedbackInvestigator onderzoekt of fouten systematische patronen vertonen
• RegressionMonitor houdt bij of eerder gecorrigeerde foutmodi terugkeren
• TrainingPairGenerator genereert trainingsgegevens op basis van bevestigde correcties voor toekomstige verfijningscycli
• Bekende beperking: De feedbacklus is afhankelijk van de betrokkenheid van leden. Gemeenschappen met een laag feedbackvolume produceren onvoldoende signalen voor zinvolle patroonherkenning.

Bescherming vóór inferentie

Een PreInferenceProtector treedt in werking vóór de generatie, screent invoer op injectiepatronen en stuurt bepaalde soorten query’s direct door naar menselijke beoordeling. Dit is een conservatief filter — het neigt naar het blokkeren — en staat los van de Guardian-pijplijn na de generatie.

Het verificatietrio van het framework en de Help-Stream-poorten

Naast de vier Guardian-lagen lopen nog twee verdere verificatietrajecten, die het waard zijn apart te behandelen omdat ze vaak door elkaar worden gehaald:

• Het framework-trio. Chatreacties worden geannoteerd door chatAnnotator.js, dat altijd drie structureel onafhankelijke frameworkcontroles uitvoert — BoundaryEnforcer (handhaving van inhouds-/domeinbeperkingen), CrossReferenceValidator (RAG-kruiscontrole) en MetacognitiveVerifier (verificatiegeschiedenis) — en wordt voor whānau- en Māori-pilootprojecten uitgebreid met een PluralisticDeliberationOrchestrator-controle. Dit zijn de eigen governance-componenten van het framework, losstaand van de src/services/guardians/-suite.
• De Help-stream Gate 1/2/3. Het Help WebSocket-pad (HelpWebSocketService.js) dwingt een letterlijke pijplijn met drie poorten af op het gestreamde antwoord (inclusief detectie van herhalingen halverwege de stream en afbreking bij Gate 2). Dit is een concrete beveiligingsmaatregel voor streaming, geen herbenoeming van de vier Guardian-lagen of het hierboven genoemde framework-trio.

Daarnaast omvat de bredere Guardian-suite ResponseReviewer, HallucinationDetector, AccuracyVerifier, AnomalyDetector, PreInferenceProtector, een ModelRollbackService en de adaptieve leercyclus. De reden om ze afzonderlijk te benoemen is dat „verificatie“ hier niet één poort is, maar meerdere, deels overlappende mechanismen op verschillende epistemische grondslagen (Artikel 3).

Wat het systeem vandaag de dag kan

Vraagbeantwoording op basis van de gemeenschap. Bij een vraag over gemeenschapsinhoud („Wanneer is de volgende kerkbestuursvergadering?”, „Wat zei de rector over het bouwfonds?”) haalt het systeem relevante documenten op en genereert het een antwoord dat is gebaseerd op die inhoud. Als er geen relevante documenten worden gevonden, geeft het systeem dit aan in plaats van een antwoord te genereren op basis van de aannames van het basismodel.

Hulp bij het opstellen van teksten. Het systeem kan conceptversies van mededelingen, aankondigingen en correspondentie genereren die de toon en woordkeuze van de gemeenschap weerspiegelen. Alle concepten worden vóór publicatie door een moderator gecontroleerd.

Samenvatting van documenten. Lange documenten (notulen van de kerkraad, beleidsdocumenten) kunnen worden samengevat, waarbij de belangrijkste punten worden geëxtraheerd.

Ondersteuning bij vertalingen. Het platform ondersteunt vijf talen: Engels, Duits, Frans, Nederlands en te reo Māori. Voor vertalingen wordt DeepL gebruikt (niet het generatiemodel) om de nauwkeurigheid te waarborgen.

Feedbacktriage — en het ingezette agentische oppervlak van het systeem. Feedback van leden wordt automatisch geclassificeerd, waar mogelijk onderzocht en doorgestuurd naar de juiste moderator. Dit is ook waar het systeem handelt in plaats van louter te antwoorden: de ResolutionExecutor streeft naar een hoog percentage automatische oplossing voor routinematige, minder belangrijke gevallen — waarbij het juiste antwoord wordt getoetst aan het corpus en de kennisbank autonoom wordt bijgewerkt — terwijl een gedetecteerd patroon van gerelateerde fouten wordt geëscaleerd voor menselijke beoordeling in plaats van dat er direct op wordt ingegrepen. Dit is opzettelijk beperkte handelingsbevoegdheid: meerstapsacties die beperkt blijven tot de grenzen van de tenant en tot omkeerbare bewerkingen, een concretisering van het principe van grenshandhaving (artikel 3) in plaats van onbeperkte autonomie bij het gebruik van de browser of computer. Het is het dichtst dat het geïmplementeerde systeem in de buurt komt van een „agent“ in de zin van 2025–2026, en de beperkingen zijn juist het punt.

OCR en documentverwerking. De DocumentExtractor-service verwerkt gescande documenten, waardoor de inhoud ervan doorzoekbaar wordt en beschikbaar is voor RAG-opvraging.

Woordenschatsysteem

Het woordenschatsysteem (product-vocabularies.js, vocabulary.js) past de terminologie van het platform aan het type gemeenschap aan. Dit werkt op twee niveaus:

Interfaceniveau: UI-labels, navigatietermen en functienamen worden vervangen door domeinspecifieke terminologie. Een episcopale parochie ziet „parochianen“, „bestuur door de kerkraad“ en „parochiebulletins“ in plaats van algemene platformterminologie.

Modelniveau: De woordenschat bepaalt de context die aan het model wordt aangeboden. Wanneer het systeem in de promptcontext verwijst naar „parochianen“ in plaats van „gebruikers“, weerspiegelt de output van het model die framing. Dit is een lichte ingreep — het werkt op promptniveau, niet op gewichtsniveau — maar het vermindert de wrijving tussen de distributiepriors van het model en de terminologie van de gemeenschap.

Er zijn negen producttypes gedefinieerd: gemeenschap, familie, natuurbehoud, diaspora, verenigingen, bedrijfsleven, alumni, whanau en bisdom. Elk type heeft een eigen woordenschattoewijzing.

Wat nog niet is bewezen

We sommen specifieke beweringen op die nog niet zijn gevalideerd:

De doeltreffendheid van Guardian Agent onder vijandige omstandigheden. Het systeem is nog niet onderworpen aan systematische red-teaming. De prestaties van Guardian Agent bij vijandige prompts, opzettelijke pogingen om hallucinaties uit te lokken of gecoördineerde injectieaanvallen zijn onbekend.

Generalisatie van de gespecialiseerde laag. Er bestaan nu specialisaties voor verschillende producttypes (villageai-14b-{community,whanau,episcopal,family,business}-v1). Of de strategie van de gespecialiseerde lagen effectief generaliseert — d.w.z. de stille distributieve terugkeer meetbaar vermindert — binnen deze domeinen en naar nog niet getrainde domeinen (natuurbehoudsecologie, culturele contexten van te reo Māori, familiegenealogie), is nog niet empirisch aangetoond. Implementatie is geen bewijs van doeltreffendheid.

Kalibratie van de cosinus-gelijkenisdrempel. De gelijkenisdrempels die door de AccuracyVerifier worden gebruikt, zijn vastgesteld op basis van ontwikkelingstests en vroege productie-ervaringen. Ze zijn niet geoptimaliseerd door middel van systematische evaluatie aan de hand van een gelabelde dataset met onderbouwde en niet-onderbouwde antwoorden.

Distributiestabiliteit op lange termijn. Het systeem is nu ongeveer acht maanden in productie. Of de priors van het basismodel zich in de loop van de tijd opnieuw doen gelden — een langzame terugkeer naar de trainingsdistributie ondanks fine-tuning — is nog niet gedurende een voldoende lange tijdsperiode waargenomen om conclusies te kunnen trekken.

Taaloverschrijdende verificatie. Voor gemeenschappen die in andere talen dan het Engels werken, verwerkt de Guardian Agent-pijplijn inbeddingen van de niet-Engelse tekst. Of verificatie op basis van cosinusgelijkenis in alle talen even effectief is, is nog niet systematisch geëvalueerd.

Convergentie van de feedbacklus. Het adaptieve feedbackmechanisme (Laag 4) is ontworpen om het gedrag van het systeem in de loop van de tijd te verbeteren. Of het convergeert naar stabiele, verbeterde prestaties of onder bepaalde feedbackpatronen oscillerend of divergerend gedrag vertoont, is niet formeel geanalyseerd.

We presenteren deze niet als uitstel, maar als open vragen. Het systeem is operationeel; deze vragen zijn onbeantwoord.

Infrastructuur

• Applicatieserver: OVH Frankrijk (EU-gegevensjurisdictie)
• Database: MongoDB met strikte tenant-isolatie (elke query gefilterd op tenantId)
• Vectoropslag: Qdrant (collecties op tenantniveau, 384-dim), backend via VECTOR_STORE_BACKEND
• GPU-inferentie: AMD RX 7900 XTX (24 GB) thuis via WireGuard (OLLAMA_GPU_URL), ~150 tok/s
• CPU-fallback: OVH-host waarop de zelfde villageai-14b-community-v1-gewichten draaien (~7 tok/s), geen kleiner model
• Trainingsopstelling (offline): NVIDIA A6000 (48 GB) op Catalyst NZ, buiten gebruik tussen de fine-tuning-sprints — maakt geen deel uit van het inferentiepad
• Authenticatie: httpOnly-cookies, isolatie van tenantcontext, geen openbare toegang
• Implementatie: Zelf gehost, geen AI-clouddiensten van derden
• Media: Bunny CDN voor edge-caching (OVH-server)

Alle inferentie vindt plaats binnen de infrastructuur van de operator. Er worden geen prompts, reacties of community-inhoud doorgegeven aan externe AI-aanbieders.

Volledige technische architectuur: Village AI over Agentic Governance. Cursussen voor praktijkbeoefenaars over het bedienen van deze systemen onder menselijke controle: Werken met Claude en Agents at Work.