Ce qui est en direct dans la production - Un inventaire sans fard

Series: Architectural AI Governance at Community Scale - A Technical Examination of Village AI (Article 4 of 5) Author: My Digital Sovereignty Ltd Date: Mars 2026 Licence: CC BY 4.0 International

Scope

Cet article décrit le système tel qu'il existe en production en mars 2026. Lorsqu'une capacité est prévue mais n'est pas encore déployée, nous le précisons. Lorsqu'une capacité est déployée mais présente des limites connues, nous décrivons ces limites. L'objectif est de dresser un inventaire qu'un chercheur pourrait utiliser pour évaluer la maturité du système et les affirmations faites ailleurs dans cette série.

Village AI est en production depuis octobre 2025. Il s'agit d'un jeune système fonctionnant à une échelle modeste. Voici une description technique de l'architecture déployée.

Modèle d'architecture

Modèle de base: villageai-8b-corrected-v4 - un modèle de paramètres 8B servant de couche de base pour tous les locataires. Formé au contenu opérationnel de la plateforme : documentation des fonctionnalités, modèles de navigation, modèles de requête d'aide et conventions d'interaction avec la communauté.

Couches spécialisées: Modèles affinés par type de produit déployés via une couche de routage (model-routing.js). La première spécialisation de production est villageai-8b-episcopal-v2, affinée sur le contenu liturgique, pastoral et de gouvernance épiscopalien/anglican. D'autres spécialisations (famille, conservation, communauté) sont prévues mais n'ont pas encore été formées.

**Un InferenceRouter sélectionne le modèle approprié en fonction du type de produit du locataire. Si une spécialisation existe pour le type de produit du locataire, elle est utilisée ; sinon, le modèle de base répond à la demande. Un niveau amélioré est défini dans l'architecture mais n'a pas encore été mis en place.

Matériel d'inférence: L'inférence primaire s'exécute sur un GPU AMD RX 7900 XTX, accessible via WireGuard VPN depuis le serveur d'application (OVH France). Une solution de repli du CPU est disponible en utilisant un modèle dégradé de paramètre 3B pour la disponibilité pendant les pannes du GPU. Le GPU n'est pas situé au même endroit que le serveur d'application - les demandes d'inférence traversent un tunnel VPN, ce qui ajoute une latence réseau au chemin d'inférence.

**L'inférence est gérée par Ollama, avec InferenceRouter qui s'occupe de la sélection des modèles et du routage des requêtes. Le système n'utilise pas d'API d'inférence tierce ; toute la génération a lieu sur une infrastructure contrôlée.

Génération assistée par récupération

Vector store: Qdrant, stockant les embeddings du contenu de la communauté (histoires, annonces, documents, descriptions d'événements, enregistrements de gouvernance).

Pipeline d'intégration: Le service d'intégration traite le contenu de la communauté en représentations vectorielles. Le contenu est découpé en morceaux, intégré et indexé par locataire, en maintenant une stricte isolation du locataire au niveau du magasin de vecteurs.

Récupération au moment de l'inférence: Les requêtes de l'utilisateur sont intégrées et utilisées pour la recherche de similarité de cosinus par rapport au corpus de documents du locataire. Les documents récupérés sont fournis en tant que contexte au modèle de génération, ancrant ses réponses dans le contenu réel de la communauté.

Indexation du contenu: Un service ContentIndexer traite le contenu nouveau et mis à jour dans le magasin de vecteurs. L'indexation respecte les limites du consentement - le contenu qui n'est pas explicitement partagé pour l'utilisation de l'IA n'est pas indexé.

Guardian Agent Pipeline

Chaque réponse de l'IA passe par quatre couches Guardian Agent avant d'atteindre l'utilisateur. Le pipeline est implémenté dans src/services/guardians/ et est structurellement indépendant du modèle de génération.

Couche 1 : Vérificateur de précision

• Embarque la réponse du modèle et calcule la similarité en cosinus par rapport aux documents sources récupérés pour la requête
• Signale les réponses inférieures à un seuil de similarité configurable
• Fournit un score de base qui alimente l'indicateur de confiance destiné à l'utilisateur
• Limitation connue: La similarité cosinus est une mesure de proximité sémantique, et non une garantie d'exactitude factuelle. Deux phrases peuvent être sémantiquement proches tout en différant sur des détails clés.

Couche 2 : Détecteur d'hallucinations

• Décompose les réponses en affirmations individuelles
• Vérifie chaque affirmation de manière indépendante par rapport au corpus source
• Signale les affirmations individuelles qui manquent de fondement, même dans des réponses par ailleurs bien fondées
• Limitation connue: La décomposition des affirmations elle-même utilise l'inférence de modèles de langage, ce qui introduit une dépendance à l'égard de la capacité du modèle. Une décomposition malformée peut produire des faux négatifs.

Couche 3 : AnomalyDetector + PressureMonitor

• Suivi des propriétés de distribution des résultats du modèle au fil du temps
• Détecte les dérives du vocabulaire, les anomalies des sujets et les changements des caractéristiques de la réponse
• PressureMonitor suit les conditions d'inférence : longueur du contexte, complexité de la requête, charge concurrente
• En cas de pression élevée, les seuils de vérification sont resserrés et les plafonds de confiance sont abaissés
• Limitation connue: La détection des anomalies nécessite une période de référence. Pour les nouveaux locataires dont l'historique d'interaction est limité, la base de référence est peu abondante et la détection des anomalies est moins efficace.

Couche 4 : ResponseReviewer + RegressionMonitor + Adaptive Feedback

• Traite le retour d'information des membres (signaux du pouce vers le bas, corrections du modérateur)
• RootCauseClassifier catégorise les modes de défaillance
• Le FeedbackInvestigator examine si les défaillances représentent des schémas systématiques
• RegressionMonitor vérifie si les modes de défaillance précédemment corrigés se reproduisent
• TrainingPairGenerator crée des données d'entraînement à partir des corrections confirmées pour les futurs cycles de réglage fin
• Limitation connue: La boucle de rétroaction dépend de l'engagement des membres. Les communautés ayant un faible volume de retour d'information produisent un signal insuffisant pour une détection significative des schémas.

Protection contre les préjugés

Un PreInferenceProtector intervient avant la génération, en filtrant les entrées à la recherche de modèles d'injection et en acheminant certains types de requêtes directement vers un examen humain. Il s'agit d'un filtre conservateur - il penche du côté du blocage - et il est séparé du pipeline Guardian post-génération.

Ce que le système peut faire aujourd'hui

**Le système récupère les documents pertinents et génère une réponse basée sur le contenu de la communauté ("Quand a lieu la prochaine réunion du conseil paroissial ?", "Qu'a dit le recteur à propos du fonds de construction ?"). Si aucun document pertinent n'est trouvé, le système l'indique au lieu de générer une réponse à partir des antécédents du modèle de base.

**Le système peut générer des projets de bulletins, d'annonces et de correspondance qui reflètent le ton et le vocabulaire de la communauté. Tous les projets sont revus par un modérateur avant d'être publiés.

Résumés de documents. Les documents longs (procès-verbaux, documents de politique générale) peuvent être résumés et les points clés extraits.

**La plateforme prend en charge cinq langues : Anglais, allemand, français, néerlandais et te reo Maori. La traduction utilise DeepL (et non le modèle de génération) pour la précision.

**Les commentaires des membres sont automatiquement classés, examinés dans la mesure du possible et acheminés vers le modérateur approprié. Le HelpFeedbackSweepService et le GeneralFeedbackProcessor se chargent de l'investigation et de la résolution automatisées.

**Le service DocumentExtractor traite les documents numérisés, rendant leur contenu consultable et disponible pour la recherche RAG.

Système de vocabulaire

Le système de vocabulaire (product-vocabularies.js, vocabulary.js) adapte la terminologie de la plateforme au type de communauté. Il fonctionne à deux niveaux :

**Au niveau de l'interface : les étiquettes de l'interface utilisateur, les termes de navigation et les noms des fonctionnalités sont remplacés par un vocabulaire approprié au domaine. Une paroisse épiscopale voit "paroissiens", "gouvernance de la sacristie" et "bulletins paroissiaux" plutôt que la terminologie générique de la plateforme.

Niveau du modèle: Le vocabulaire façonne le contexte fourni au modèle. Lorsque le système fait référence aux "paroissiens" plutôt qu'aux "utilisateurs" dans le contexte de l'invite, les résultats du modèle reflètent ce cadrage. Il s'agit d'une intervention légère - elle opère au niveau de l'invite, et non au niveau du poids - mais elle réduit la friction entre les a priori distributionnels du modèle et la terminologie de la communauté.

Neuf types de produits sont définis : communauté, famille, conservation, diaspora, clubs, entreprises, anciens élèves, whanau et épiscopat. Chacun d'entre eux possède une cartographie de vocabulaire distincte.

Ce qui n'est pas encore prouvé

Nous énumérons les affirmations spécifiques qui n'ont pas été validées :

Guardian Agent efficacité dans des conditions adverses. Le système n'a pas été soumis à un red-teaming systématique. Guardian Agent performance dans des conditions adverses d'incitation, de tentatives délibérées de provoquer des hallucinations, ou d'attaques coordonnées par injection est inconnue.

**La spécialisation Episcopal (villageai-8b-episcopal-v2) a été déployée pour un type de produit. Il n'a pas été démontré empiriquement si la stratégie de la couche spécialisée se généralise efficacement à d'autres domaines (écologie de la conservation, contextes culturels maoris te reo, généalogie familiale).

**Les seuils de similarité utilisés par l'AccuracyVerifier ont été fixés sur la base de tests de développement et d'une expérience de production précoce. Ils n'ont pas été optimisés par une évaluation systématique par rapport à un ensemble de données étiquetées de réponses fondées et non fondées.

**Le système est en production depuis environ cinq mois. Il n'a pas été possible d'observer sur une période suffisamment longue pour tirer des conclusions si les antécédents du modèle de base se réaffirment au fil du temps - une lente dérive vers la distribution d'entraînement malgré un réglage fin.

**Pour les communautés travaillant dans des langues autres que l'anglais, le pipeline Guardian Agent fonctionne sur la base de l'intégration du texte non anglais. La question de savoir si la vérification par similitude de cosinus est aussi efficace d'une langue à l'autre n'a pas fait l'objet d'une évaluation systématique.

Convergence de la boucle de rétroaction Le mécanisme de rétroaction adaptative (couche 4) est conçu pour améliorer le comportement du système au fil du temps. La question de savoir s'il converge vers une performance stable et améliorée ou s'il présente un comportement oscillatoire ou divergent sous certains modèles de rétroaction n'a pas fait l'objet d'une analyse formelle.

Nous ne les présentons pas comme des reports, mais comme des questions ouvertes. Le système est opérationnel, mais ces questions restent sans réponse.

Infrastructure

• Serveur d'application: OVH France (juridiction de données de l'UE)
• Base de données: MongoDB avec isolation stricte des locataires (chaque requête est filtrée par l'identifiant du locataire)
• Stockage vectoriel: Qdrant (collections adaptées au locataire)
• Inférence GPU: AMD RX 7900 XTX via WireGuard VPN
• Refus de CPU: modèle dégradé 3B pour la disponibilité
• Authentification: cookies httpOnly, isolation du contexte du locataire, pas d'accès public
• Déploiement: Auto-hébergé, pas de services tiers d'IA dans le nuage
• Médias: CDN de Bunny pour la mise en cache (serveur OVH)

Toute l'inférence se fait au sein de l'infrastructure de l'opérateur. Aucune invite, réponse ou contenu communautaire n'est transmis à des fournisseurs d'IA tiers.

Ceci est l'article 4 sur 5 de la série "Gouvernance architecturale de l'IA à l'échelle de la communauté". Pour l'architecture technique complète, visitez Village AI on Agentic Governance.

Précédent : Pourquoi la gouvernance en temps de formation échoue - Les contraintes architecturales comme alternative Suivant : Au-delà du modèle - Architecture de la plate-forme et intégration de la gouvernance