Toutes les éditions · AI Research Edition

Your Community, Your AI — CC BY 4.0

Qu'est-ce que « Live in Production » ? — Un état des lieux sans fard

Portée

Cet article décrit le système tel qu'il existe en production en juin 2026. Lorsqu'une fonctionnalité est prévue mais n'est pas encore déployée, nous le précisons. Lorsqu'une fonctionnalité est déployée mais présente des limites connues, nous décrivons ces limites. L’objectif est de fournir un état des lieux qu’un chercheur pourrait utiliser pour évaluer la maturité du système et les affirmations formulées ailleurs dans cette série. (La terminologie spécifique à la série est définie dans le glossaire.)

Village AI est en production depuis 2025 — il en est actuellement à la phase de lancement « founding-charge ». Il s’agit d’un système récent fonctionnant à une échelle modeste. Ce qui suit est une description technique de l’architecture déployée.

Architecture du modèle

Modèle de base : un modèle de la famille Qwen2 à 14 milliards de paramètres, « villageai-14b-community-v1 », servant de fondement et de couche par défaut pour tous les locataires non spécialisés (définis via OLLAMA_MODEL). Il a été entraîné sur le contenu opérationnel de la plateforme : documentation des fonctionnalités, schémas de navigation, schémas de requêtes d’aide et conventions d’interaction communautaire. Il s’agit d’un modèle généraliste performant, et non d’un modèle allégé — c’est également celui utilisé par la voie de secours CPU (voir ci-dessous).

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 en production appartiennent à la famille villageai-14b-{community,whanau,episcopal,family,business}-v1, chacune étant affinée sur le contenu propre à son type de produit (la spécialisation « Episcopal », villageai-14b-episcopal-v1, porte sur les documents liturgiques, pastoraux et de gouvernance de l’Église anglicane). D’autres types de produits (par exemple : conservation, anciens élèves, diaspora) sont prévus mais n’ont pas encore fait l’objet d’un entraînement. Les tâches de vision et d’OCR sont acheminées vers un qwen2.5vl:7b local via le même InferenceRouter.

Routage des modèles : getModelForTenant (dans model-routing.js) sélectionne le modèle en fonction du type de produit du locataire. Si une spécialisation existe pour ce type de produit, elle est utilisée ; sinon, c’est le modèle de base qui traite la requête. Un hôte d’inférence à GPU unique peut définir OLLAMA_FORCE_BASE_MODEL=true pour forcer tous les locataires à utiliser le modèle de base 14B — cela évite qu’un Ollama de 24 Go, hébergeant un seul modèle, ne bascule sans cesse entre les réglages fins spécifiques à chaque produit. Un niveau « enhanced » existe dans le code de routage (ENHANCED_MODELS), mais il s’agit actuellement d’une carte vide : il est réservé à de futures fonctionnalités premium et revient par défaut au niveau standard ; ainsi, aucun locataire ne bénéficie aujourd’hui d’un modèle « enhanced ». Notez qu’il n’y a pas de distinction entre « rapide » et « profond » ; la véritable hiérarchisation repose sur les poids de base par rapport aux poids spécialisés, le basculement GPU/CPU et la couche de vérification.

Matériel d’inférence : L’inférence principale s’exécute sur une carte AMD RX 7900 XTX (24 Go) installée à domicile, accessible via un tunnel WireGuard (OLLAMA_GPU_URL) depuis le serveur d’applications (OVH France) à un débit d’environ 150 jetons par seconde. Le GPU n’est pas colocalisé avec le serveur d’application — les requêtes transitent par le VPN, ce qui ajoute une latence réseau au chemin d’inférence. En cas de panne du GPU, l’inférence bascule vers le CPU de l’hôte OVH exécutant les mêmes poids villageai-14b-community-v1 (OLLAMA_CPU_MODEL) à un débit d’environ 7 jetons/seconde — il s’agit d’un débit réduit, et non d’un modèle plus petit. Par ailleurs, une carte NVIDIA A6000 (48 Go) sur Catalyst NZ sert de machine d’entraînement, mise en veille entre les sprints de réglage fin ; elle ne fait pas partie du chemin d’inférence.

Framework : L’inférence est gérée via Ollama, l’InferenceRouter se chargeant de la sélection du modèle et du routage des requêtes. Le système n’utilise aucune API d’inférence tierce ; toute la génération s’effectue sur une infrastructure contrôlée.

Génération augmentée par la recherche

Stockage vectoriel : Qdrant, stockant des représentations vectorielles à 384 dimensions du contenu de la communauté (récits, annonces, documents, descriptions d’événements, comptes rendus de gouvernance). Le backend est sélectionné via VECTOR_STORE_BACKEND.

Pipeline d’embedding : L’EmbeddingService traite le contenu de la communauté pour le convertir en représentations vectorielles à l’aide d’un modèle local Xenova/all-MiniLM-L6-v2 (384 dimensions) — aucune API d’encodage tierce n’est utilisée. Le contenu est segmenté, encodé et indexé par locataire, ce qui garantit une isolation stricte des locataires au niveau du magasin de vecteurs.

Récupération au moment de l’inférence : Les requêtes des utilisateurs sont encodées et utilisées pour une recherche par similarité cosinus dans le corpus de documents du locataire. Les documents récupérés sont fournis comme contexte au modèle de génération, ancrant ainsi ses réponses dans le contenu réel de la communauté.

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

Pipeline Guardian Agent

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

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

Couche 2 : HallucinationDetector

• Décompose les réponses en affirmations individuelles
• Vérifie chaque affirmation indépendamment par rapport au corpus source
• Signale les affirmations individuelles qui manquent de fondement, même dans des réponses par ailleurs bien étayées
• Limite connue : la décomposition des affirmations repose elle-même sur l’inférence d’un modèle linguistique, ce qui introduit une dépendance vis-à-vis des capacités du modèle. Une décomposition mal effectuée peut entraîner des faux négatifs.

Couche 3 : AnomalyDetector + PressureMonitor

• Suit les propriétés de distribution des sorties du modèle au fil du temps
• Détecte les dérives de vocabulaire, les anomalies thématiques et les changements dans les caractéristiques des réponses
• PressureMonitor suit les conditions d’inférence : longueur du contexte, complexité de la requête, charge simultanée
• En cas de pression élevée, les seuils de vérification sont resserrés et les plafonds de confiance sont abaissés
• Limite connue : la détection des anomalies nécessite une période de référence. Pour les nouveaux locataires dont l’historique d’interactions est limité, la base de référence est clairsemée et la détection des anomalies est moins efficace.

Couche 4 : ResponseReviewer + RegressionMonitor + Adaptive Feedback

• Traite les retours des membres (signaux négatifs, corrections des modérateurs)
• RootCauseClassifier catégorise les modes de défaillance
• FeedbackInvestigator examine si les défaillances correspondent à des schémas systématiques
• RegressionMonitor vérifie si des modes de défaillance précédemment corrigés réapparaissent
• TrainingPairGenerator crée des données d’entraînement à partir des corrections confirmées pour de futurs cycles d’ajustement
• Limite connue : la boucle de rétroaction dépend de l’engagement des membres. Les communautés présentant un faible volume de retours ne produisent pas suffisamment de signaux pour permettre une détection significative de schémas.

Protection pré-inférence

Un PreInferenceProtector intervient avant la génération, filtrant les entrées à la recherche de schémas d’injection et acheminant certains types de requêtes directement vers un examen humain. Il s’agit d’un filtre prudent — qui privilégie le blocage — et distinct du pipeline Guardian post-génération.

Le trio de vérification du framework et les filtres Help-Stream

Deux autres voies de vérification fonctionnent parallèlement aux quatre couches Guardian, et il convient de les distinguer car elles sont souvent confondues :

• Le trio de vérification du cadre. Les réponses du chat sont annotées par chatAnnotator.js, qui exécute systématiquement trois contrôles structurellement indépendants du cadre : BoundaryEnforcer (application des règles de contenu/domaine), CrossReferenceValidator (vérification croisée RAG) et MetacognitiveVerifier (historique de vérification) — et, pour les projets pilotes whānau et maoris, s’approfondit par un passage via PluralisticDeliberationOrchestrator. Il s’agit des composants de gouvernance propres au cadre, distincts de la suite src/services/guardians/.
• Les portes 1/2/3 du flux Help. Le chemin WebSocket Help (HelpWebSocketService.js) applique un pipeline littéral à trois portes sur la réponse diffusée en continu (y compris la détection des répétitions en cours de flux et l’interruption à la porte 2). Il s’agit d’une protection concrète du flux, et non d’un simple changement de nom des quatre couches Guardian ou du trio de composants du framework mentionné ci-dessus.

Au-delà de ceux-ci, la suite Guardian au sens large comprend ResponseReviewer, HallucinationDetector, AccuracyVerifier, AnomalyDetector, PreInferenceProtector, un ModelRollbackService et la boucle d’apprentissage adaptatif. La raison pour laquelle nous les nommons séparément est que la « vérification », ici, ne correspond pas à une seule étape, mais à plusieurs mécanismes se chevauchant partiellement et reposant sur des bases épistémiques différentes (article 3).

Ce que le système est capable de faire aujourd’hui

Réponse aux questions ancrée dans la communauté. Face à une requête concernant le contenu de la communauté (« Quand aura lieu la prochaine réunion du conseil paroissial ? », « Qu’a dit le recteur au sujet du fonds de construction ? »), le système extrait les documents pertinents et génère une réponse fondée sur ce contenu. Si aucun document pertinent n’est trouvé, le système l’indique plutôt que de générer une réponse à partir des a priori du modèle de base.

Aide à la rédaction. Le système peut générer des brouillons de bulletins, d’annonces et de correspondance qui reflètent le ton et le vocabulaire de la communauté. Tous les brouillons sont relus par un modérateur avant leur publication.

Résumé de documents. Les documents longs (comptes rendus du conseil paroissial, documents de politique générale) peuvent être résumés en en extrayant les points clés.

Aide à la traduction. La plateforme prend en charge cinq langues : l’anglais, l’allemand, le français, le néerlandais et le te reo Māori. La traduction utilise DeepL (et non le modèle de génération) pour garantir la précision.

Triage des retours d’information — et interface opérationnelle du système. Les retours d’information des membres sont automatiquement classés, examinés dans la mesure du possible, puis acheminés vers le modérateur compétent. C’est également là que le système agit plutôt que de se contenter de répondre : le ResolutionExecutor vise un taux élevé de résolution automatique pour les cas courants et peu critiques — en recherchant la bonne réponse dans le corpus et en mettant à jour la base de connaissances de manière autonome — tandis qu’un schéma détecté d’échecs récurrents est transmis à un modérateur humain pour décision plutôt que d’être traité automatiquement. Il s’agit là d’une capacité d’action délibérément limitée : une action en plusieurs étapes confinée aux limites du tenant et à des opérations réversibles, une incarnation du principe de respect des limites (article 3) plutôt qu’une autonomie illimitée dans l’utilisation du navigateur ou de l’ordinateur. C’est ce qui se rapproche le plus, dans le système déployé, d’un « agent » au sens de 2025–2026, et ces contraintes sont justement l’essentiel.

OCR et traitement des documents. 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é. Cela s’opère à deux niveaux :

Niveau de l’interface : les libellés de l’interface utilisateur, les termes de navigation et les noms de fonctionnalités sont remplacés par un vocabulaire adapté au domaine. Une paroisse épiscopale voit apparaître les termes « paroissiens », « gestion du conseil paroissial » et « bulletins paroissiaux » plutôt que la terminologie générique de la plateforme.

Au niveau du modèle : le vocabulaire façonne le contexte fourni au modèle. Lorsque le système fait référence à des « paroissiens » plutôt qu’à des « utilisateurs » dans le contexte de la requête, la réponse du modèle reflète ce cadre. Il s’agit d’une intervention légère — elle opère au niveau de la requête, et non au niveau des 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, entreprise, anciens élèves, whanau et épiscopal. Chacun dispose d’une correspondance lexicale distincte.

Ce qui n’est pas encore prouvé

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

L’efficacité de Guardian Agent dans des conditions adverses. Le système n’a pas fait l’objet de tests systématiques de type « red team ». Les performances de Guardian Agent face à des invites adverses, à des tentatives délibérées de provoquer des hallucinations ou à des attaques par injection coordonnées sont inconnues.

Généralisation de la couche spécialisée. Des spécialisations existent désormais 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 des couches spécialisées se généralise efficacement — c’est-à-dire si elle réduit de manière mesurable la réversion distributionnelle silencieuse — à travers ces domaines, ainsi qu’à des domaines non encore entraînés (écologie de la conservation, contextes culturels du te reo Māori, généalogie familiale). Le déploiement ne constitue pas une preuve d’efficacité.

Calibrage des seuils de similarité cosinus. Les seuils de similarité utilisés par l’AccuracyVerifier ont été fixés sur la base de tests de développement et des premières expériences en production. Ils n’ont pas été optimisés par une évaluation systématique par rapport à un ensemble de données étiquetées comprenant des réponses étayées et non étayées.

Stabilité de la distribution à long terme. Le système est en production depuis environ huit mois. La question de savoir si les a priori du modèle de base réapparaissent au fil du temps — c’est-à-dire un lent retour vers la distribution d’entraînement malgré le réglage fin — n’a pas été observée sur un horizon temporel suffisant pour tirer des conclusions.

Vérification interlinguistique. Pour les communautés utilisant des langues autres que l’anglais, le pipeline Guardian Agent fonctionne sur les représentations du texte non anglophone. L’efficacité de la vérification par similarité cosinus n’a pas été évaluée de manière systématique dans toutes les langues.

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 des performances stables et améliorées ou s’il présente un comportement oscillatoire ou divergent sous certains schémas de rétroaction n’a pas fait l’objet d’une analyse formelle.

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

Infrastructure

• Serveur d’applications : OVH France (juridiction de l’UE en matière de données)
• Base de données : MongoDB avec isolation stricte des locataires (chaque requête filtrée par tenantId)
• Magasin de vecteurs : Qdrant (collections au niveau du locataire, 384 dimensions), backend via VECTOR_STORE_BACKEND
• Inférence GPU : carte AMD RX 7900 XTX (24 Go) à domicile via WireGuard (OLLAMA_GPU_URL), ~150 tok/s
• Solution de secours CPU : serveur OVH exécutant les mêmes poids villageai-14b-community-v1 (~7 tokens/s), et non un modèle plus petit
• Plateforme d’entraînement (hors ligne) : NVIDIA A6000 (48 Go) sur Catalyst NZ, mise de côté entre les sprints de réglage fin — hors du chemin d’inférence
• Authentification : cookies httpOnly, isolation du contexte du locataire, aucun accès public
• Déploiement : auto-hébergé, aucun service d’IA cloud tiers
• Médias : CDN Bunny pour la mise en cache en périphérie (serveur OVH)

Toutes les inférences s’effectuent au sein de l’infrastructure de l’opérateur. Aucune invite, réponse ou contenu communautaire n’est transmis à des fournisseurs d’IA tiers.

Architecture technique complète : Village AI sur la gouvernance agentique. Formations destinées aux professionnels sur l’exploitation de ces systèmes sous contrôle humain : Travailler avec Claude et Agents at Work.