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

Série: Gouvernance architecturale de l'IA à l'échelle de la communauté - Un examen technique de la gouvernance architecturale de l'IA à l'échelle de la communauté Village AI (Article 4 de 5) Author: My Digital Sovereignty Ltd Date: Juin 2026 Licence: CC BY 4.0 International

Scope

Cet article décrit le système tel qu'il existe en production en juin 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: un modèle de 14B paramètres Qwen2 fine-tune servant de couche de base pour tous les locataires. Formation sur le 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). Les spécialisations de production sont la famille villageai-14b-{community,whanau,episcopal,family,business}-v1, chacune affinée sur le contenu de son type de produit (la spécialisation épiscopale, villageai-14b-episcopal-v1, sur le matériel liturgique, pastoral et de gouvernance anglican). D'autres types de produits (par exemple, conservation, anciens élèves, diaspora) sont prévus mais n'ont pas encore été formés. Les tâches de vision (classification des photos, OCR) sont dirigées vers qwen2.5vl:7b.

Model routing: 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). Le 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 un temps de latence au chemin d'inférence.

Cadre de travail: L'inférence est gérée par Ollama, InferenceRouter se chargeant 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, qui stocke les enchâssements du contenu de la communauté (histoires, annonces, documents, descriptions d'événements, dossiers 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 : AccuracyVerifier

• 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 : HallucinationDetector

• Décomposition des 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 revendications 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 la dérive du vocabulaire, les anomalies des sujets et les changements des caractéristiques de 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 d'anomalies est moins efficace.

Couche 4 : ResponseReviewer + RegressionMonitor + retour d'information adaptatif

• 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
• FeedbackInvestigator examine si les défaillances représentent des modèles systématiques
• RegressionMonitor vérifie si les modes d'échec 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 site PreInferenceProtector fonctionne 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 distinct 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é. C'est également à ce stade que le système agit plutôt que de se contenter de répondre : le site ResolutionExecutor poursuit un taux élevé de résolution automatique pour les cas courants et à faible enjeu - en recherchant la bonne réponse dans le corpus et en mettant à jour la base de connaissances de manière autonome - tandis qu'un modèle détecté d'échecs connexes est transmis à un juge humain plutôt que d'être traité. Il s'agit d'une action délibérément limitée : une action en plusieurs étapes limitée aux limites du locataire et à des opérations réversibles, une instanciation du principe d'application des limites (article 3) plutôt qu'une autonomie illimitée du navigateur/de l'utilisation de l'ordinateur. C'est le système déployé qui se rapproche le plus d'un "agent" au sens de 2025-2026, et ce sont les contraintes qui comptent.

**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.

Généralisation de la couche spécialisée Il existe maintenant des spécialisations pour plusieurs types de produits (villageai-14b-{community,whanau,episcopal,family,business}-v1). Il n'a pas été démontré empiriquement si la stratégie de la couche spécialisée se généralise efficacement - c'est-à-dire qu'elle réduit de manière mesurable la réversion distributionnelle silencieuse - dans ces domaines et dans d'autres qui n'ont pas encore été formés (écologie de la conservation, contextes culturels maoris te reo, généalogie des familles). Le déploiement n'est pas une preuve d'efficacité.

**Les seuils de similarité utilisés par le site 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 huit 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)
• Magasin vectoriel: Qdrant (collections adaptées au locataire)
• GPU inference: 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édia: CDN Bunny pour la mise en cache en périphérie (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 sur la gouvernance agentique] (https://agenticgovernance.digital/village-ai.html).

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