Toutes les éditions · AI Research Edition

Your Community, Your AI — CC BY 4.0

Au-delà du modèle — Architecture de plateforme et intégration de la gouvernance

Le modèle n’est pas le système

Les articles précédents ont examiné le modèle de génération, le pipeline de vérification Guardian Agent et le problème du biais de distribution. Ce dernier article examine comment la gouvernance architecturale s’étend au-delà du modèle pour englober la plateforme, et évalue l’approche globale en fonction de ce qu’elle sacrifie et de ce qu’elle apporte. (La terminologie spécifique à cette série est définie dans le glossaire.)

L’argument central est que l’alignement de l’IA à l’échelle de la communauté ne peut être résolu par le modèle seul — ni par l’entraînement, ni par le réglage fin, ni par le RLHF, ni par la vérification au moment de l’inférence prise isolément. L’alignement au moment du déploiement nécessite des contraintes architecturales qui couvrent l’ensemble du système : isolation des données, architecture du consentement, cadrage du vocabulaire, intégration d’une supervision humaine et gouvernance fédérée. Le modèle n’est qu’un composant. C’est l’architecture qui constitue l’intervention.

L’isolation des données en tant que mécanisme d’alignement

L’isolation des données en environnement multi-locataires est généralement abordée sous l’angle de la sécurité. Dans l’architecture Village, elle fait également office de mécanisme d’alignement.

Chaque requête de base de données est filtrée par tenantId. Le magasin de vecteurs gère des collections limitées au locataire. Le modèle de génération ne reçoit de contexte que du corpus du locataire à l’origine de la requête. Il s’agit là de modèles standard de multi-locataires, mais ils ont une conséquence en matière d’alignement : le modèle ne peut pas s’appuyer sur les modèles de distribution issus des données d’autres locataires.

C’est important car l’alignement dans les contextes communautaires n’est pas universel. Ce qui constitue un langage approprié pour une paroisse épiscopale peut être inapproprié pour un groupe de défense de l’environnement, et vice versa. Un modèle ayant accès aux données de tous les locataires — même en lecture seule, même à des fins de récupération — développerait des a priori distributionnels qui se mélangeraient d’une communauté à l’autre. L’isolation des locataires empêche cette contamination croisée au niveau de la couche de données.

Le principe architectural est le suivant : la fenêtre de contexte du modèle ne doit contenir que du contenu provenant de la communauté qu’il dessert actuellement. Cette règle est appliquée de manière structurelle, et non par instruction. Il n’est pas nécessaire de demander au modèle de rester dans les limites du tenant ; il n’a accès à rien en dehors de celles-ci.

Architecture du consentement

Le système de consentement (modèle ConsentRecord, composant AIMemoryConsent) régit le contenu qui entre dans le pipeline d’IA. Trois finalités de consentement distinctes sont définies : ai_triage_memory, ai_ocr_memory et ai_summarisation_memory. Le contenu n’est pas indexé pour une utilisation par l’IA à moins que son créateur n’ait donné son consentement explicite pour la finalité concernée.

Il s’agit d’une contrainte d’alignement qui s’applique avant l’inférence. Le contenu pour lequel aucun consentement n’a été donné en vue d’une utilisation par l’IA n’apparaît pas dans le magasin de vecteurs, n’est pas récupéré lors du RAG et n’est pas disponible comme matériel de référence pour la vérification Guardian Agent. Le modèle ne peut pas produire d’hallucinations à partir d’un contenu qu’il n’a jamais vu.

L’architecture de consentement répond également à un problème plus subtil : les membres de la communauté qui ne sont pas à l’aise avec le traitement de leurs contributions par l’IA peuvent exclure leur contenu sans affecter la capacité du système à servir les autres membres. Il s’agit autant d’un mécanisme de gouvernance que d’un mécanisme de protection de la vie privée — il permet à la communauté de façonner la base de connaissances de l’IA par le biais de décisions individuelles en matière de consentement.

Limite : le consentement s’applique au niveau du contenu, et non au niveau de l’information. Si le membre A rédige un récit mentionnant le membre B, et que le membre A consent au traitement par l’IA, les informations concernant le membre B entrent dans le pipeline de l’IA indépendamment des préférences du membre B. Il s’agit là d’une limite inhérente au consentement au niveau du contenu que nous n’avons pas encore entièrement résolue.

Le vocabulaire comme gouvernance du cadrage

L’article 4 décrivait l’interface du système de vocabulaire et ses effets au niveau du modèle. Nous l’examinons ici en tant que mécanisme de gouvernance.

Le système de vocabulaire met en œuvre ce que l’on pourrait appeler une « gouvernance du cadrage » : il restreint le cadre conceptuel dans lequel le modèle opère. Lorsque le système remplace « utilisateurs » par « paroissiens » et « paramètres d’administration » par « gouvernance du conseil paroissial » dans l’ensemble du contexte de la consigne, il fait évoluer la distribution conditionnelle du modèle, l’éloignant des schémas propres aux plateformes technologiques pour l’orienter vers des schémas de gouvernance communautaire.

Il s’agit d’une intervention moins forte que le réglage fin — elle opère au niveau de la prompt, et non au niveau des poids — mais elle présente deux avantages :

1. Elle est transparente et vérifiable. Les correspondances de vocabulaire sont définies dans un seul fichier de configuration (product-vocabularies.js). Un chercheur peut vérifier exactement quels termes sont remplacés et prédire leur effet sur le comportement du modèle.

2. Elle est configurable par la communauté. Différents types de produits ont des mappages de vocabulaire différents, et ceux-ci peuvent être étendus sans réentraîner le modèle. Cela est pertinent pour les communautés dont la terminologie ne correspond à aucun type de produit existant.

L’interaction entre le cadrage lexical et le réglage fin de la couche spécialisée mérite d’être soulignée. Le système lexical modifie le contexte de la prompt ; le réglage fin modifie les a priori distributionnels du modèle. Lorsque les deux fonctionnent conjointement — la prompt utilise le vocabulaire épiscopal et le modèle bénéficie d’un réglage fin épiscopal —, l’effet combiné est plus fort que celui de chacune des interventions prises isolément. Lorsqu’un seul de ces éléments est actif (un type de communauté sans modèle spécialisé, utilisant uniquement le cadrage lexical), l’effet est plus faible mais reste mesurable en termes de qualité de sortie.

Intégration d’une supervision humaine

Le « boundary enforcer » (décrit à l’article 3 de la série « parish » comme un composant de gouvernance) achemine les questions portant sur les valeurs, l’éthique ou le contexte culturel vers un examen humain. Ce processus est mis en œuvre via le PreInferenceProtector et grâce à un routage basé sur le niveau de confiance : lorsque la vérification Guardian Agent produit un niveau de confiance inférieur à un seuil configurable, la réponse est signalée pour examen par un modérateur plutôt que d’être délivrée directement.

Cela crée une architecture « human-in-the-loop » dans laquelle l’IA traite de manière autonome les requêtes hautement fiables et bien fondées, et transmet les requêtes incertaines ou sensibles à la supervision humaine. Le seuil est configurable par locataire, ce qui permet aux communautés de définir leur propre tolérance au risque.

Limite : La qualité de la supervision humaine dépend de la qualité des modérateurs. Le système peut acheminer les requêtes incertaines vers un modérateur, mais il ne peut garantir que ce dernier dispose de l’expertise nécessaire pour les évaluer efficacement. Il s’agit d’une contrainte organisationnelle, et non technique, mais elle limite l’efficacité de l’architecture globale.

Le parcours d’accréditation des modérateurs — une formation structurée destinée aux membres de la communauté assumant le rôle de modérateur — est conçu pour pallier cette limitation, mais son déploiement se fait progressivement.

Fédération et gouvernance intercommunautaire

L’architecture fédérée permet à des instances distinctes de Village d’établir des connexions bilatérales — partageant des contenus sélectionnés au-delà des frontières communautaires tout en préservant la souveraineté des données. Les deux communautés doivent consentir à la connexion, et chacune peut s’en retirer à tout moment.

Du point de vue de l’alignement, la fédération introduit un canal contrôlé par lequel les modèles de distribution d’une communauté peuvent influencer une autre. Un échange de contenu fédéré entre une paroisse épiscopale et un groupe de défense de l’environnement pourrait, en principe, modifier le comportement de l’IA de la communauté réceptrice en introduisant du contenu hors domaine dans le magasin de vecteurs.

L’architecture de fédération résout ce problème grâce à un partage sélectif — seul le contenu explicitement marqué pour la fédération est partagé — et à une vérification au niveau du tenant. La vérification Guardian Agent s’applique au corpus de la communauté réceptrice, qui n’intègre le contenu fédéré qu’après son acceptation et son indexation. Les modérateurs de la communauté réceptrice contrôlent le contenu fédéré qui entre dans leur pipeline d’IA.

Il s’agit d’un mécanisme de gouvernance qui n’a pas d’équivalent dans la littérature sur l’alignement, car celle-ci ne considère généralement pas le déploiement multi-communautaire comme une préoccupation majeure. Nous le signalons comme un domaine dans lequel les systèmes d’IA communautaires déployés sont confrontés à des défis d’alignement que les environnements de laboratoire ne permettent pas de saisir.

Ce que cette approche sacrifie

Nous énumérons clairement les coûts de cette approche :

Capacité brute. Un modèle à 14 milliards de paramètres ne peut rivaliser avec les systèmes de pointe sur des tâches générales. Les utilisateurs ayant besoin d’écriture créative, de raisonnements complexes dans des domaines inconnus ou d’une assistance intellectuelle à large spectre trouveront ce système insuffisant.

Latence. Le pipeline Guardian Agent ajoute une surcharge de vérification à chaque réponse. Ce pipeline à quatre couches, comprenant le calcul des représentations, la recherche par similarité cosinus, la décomposition des affirmations et la détection des anomalies, introduit une latence mesurable. Pour les communautés qui privilégient la rapidité de réponse au détriment de la rigueur de vérification, cela constitue un inconvénient.

Couverture. La fidélité du système au domaine dépend de la qualité et de la couverture des données de fin-ajustement ainsi que du corpus de contenu de la communauté. Une communauté nouvellement créée disposant d’un contenu minimal fournit un corpus de référence clairsemé, ce qui rend la vérification de Guardian Agent moins efficace et le comportement du modèle moins ancré dans la réalité.

Évolutivité. L’architecture est conçue pour un déploiement à l’échelle d’une communauté (de quelques dizaines à quelques centaines d’utilisateurs simultanés par locataire). Elle n’a pas été testée à l’échelle d’Internet, et le pipeline de vérification par réponse nécessiterait probablement des modifications architecturales substantielles pour fonctionner à haut débit.

Généralisabilité. La stratégie de la « couche spécialisée » a été déployée pour plusieurs types de produits (communauté, whanau, épiscopal, famille, entreprise) mais n’a été validée pour aucun d’entre eux — le déploiement ne constitue pas une preuve d’efficacité. Il n’est pas prouvé qu’elle soit généralisable à l’ensemble des neuf types de produits définis, ni que les seuils Guardian Agent nécessitent un calibrage par domaine.

Les avantages de cette approche

Vérifiabilité. Chaque réponse générée par l’IA peut être rattachée à des documents sources spécifiques. Les scores de similarité cosinus, les résultats de vérification au niveau des affirmations et les indicateurs de confiance sont disponibles pour inspection. Il s’agit d’une propriété que les systèmes de pointe fonctionnant sur des corpus d’entraînement illimités ne peuvent offrir.

Agence limitée. Comme c’est la plateforme — et non le Web ouvert — qui constitue la surface d’action, la capacité d’action du système est limitée par sa conception même : il n’agit que sur des données isolées par locataire, effectue des opérations réversibles, et ses actions ayant des conséquences sont soumises à l’autorisation humaine. Le tournant agentique observé dans l’ensemble du domaine (article 1) rend cette propriété plus saillante, et non l’inverse : là où les agents à usage général étendent l’espace d’action à Internet, la conception limitée à la plateforme le restreint à une surface inspectable et récupérable. Il s’agit là d’un avantage en matière de gouvernance qui n’est perceptible qu’au niveau de la plateforme, et non au niveau du modèle — ce qui constitue le propos général de cet article.

Auditabilité. Les données de réglage fin, les correspondances de vocabulaire, les seuils Guardian Agent et les corrections apportées par la boucle de rétroaction sont tous inspectables. Un chercheur ou un auditeur peut examiner l’ensemble de la chaîne, de l’entrée à la sortie, et comprendre pourquoi le système a produit une réponse spécifique. Le cadre Tractatus est publié en open source ; l’architecture de gouvernance est ouverte à un examen externe.

Souveraineté de la communauté. La communauté contrôle les données, l’infrastructure d’inférence, le cadrage du vocabulaire, les limites du consentement et la politique de modération. Aucun fournisseur tiers ne peut modifier le comportement du système sans le consentement de la communauté. Il s’agit d’une propriété de gouvernance, et non d’une propriété technique, mais elle est garantie au niveau de l’architecture.

Séparation épistémique. Le système de vérification fonctionne selon des principes différents de ceux du système de génération. Cela ne prouve pas l’exactitude, mais fournit un mécanisme de détection pour le mode de défaillance spécifique — la réversion distributionnelle silencieuse — qui a motivé la conception de l’architecture. L’incident 27027 serait détecté par le pipeline Guardian Agent, car la similarité cosinus entre le langage du deuil thérapeutique et le corpus théologique de la communauté serait inférieure au seuil de vérification.

Falsifiabilité. Le système émet des affirmations spécifiques et vérifiables : que la vérification Guardian Agent réduit les réponses non fondées, que la spécialisation par domaine améliore la fidélité au registre, que le cadrage lexical modifie de manière mesurable le comportement du modèle. Ces affirmations sont, en principe, vérifiables de manière indépendante. Nous n’avons pas encore organisé de tests indépendants, mais l’architecture ne s’y oppose pas.

Questions ouvertes pour la communauté scientifique

Nous concluons par des questions auxquelles nous ne pouvons pas répondre nous-mêmes et sur lesquelles nous serions ravis d’échanger :

1. La séparation épistémique est-elle suffisante pour l’alignement, ou simplement nécessaire ? L’architecture Guardian Agent permet de détecter la réversion distributionnelle. La détection n’est pas la prévention. Existe-t-il une base théorique permettant d’affirmer que la détection et la correction convergent vers l’alignement, ou cela se limite-t-il simplement à restreindre la fréquence des échecs ?

2. Comment les seuils de similarité cosinus devraient-ils être calibrés ? Les seuils actuels sont ajustés de manière empirique. Existe-t-il une méthode fondée sur des principes pour définir des seuils de vérification qui équilibrent le taux de faux positifs (signaler des réponses fondées comme non fondées) et le taux de faux négatifs (laisser passer des réponses non fondées) ?

3. Existe-t-il des mesures d’atténuation pratiques pour la vulnérabilité liée à l’embedding corrélé ? Le modèle d’embedding partagé, utilisé à la fois pour la recherche et la vérification, crée un point de défaillance unique. Quelles architectures pourraient permettre une vérification véritablement indépendante tout en restant gérables sur le plan computationnel ?

4. La stratégie de la « couche spécialisée » peut-elle être formalisée ? L’intuition selon laquelle un réglage fin spécifique au domaine sur un modèle plus petit offre une meilleure fidélité au domaine que l’utilisation d’un modèle plus grand est empiriquement corroborée dans notre déploiement, mais n’a pas fait l’objet d’une comparaison rigoureuse. Dans quelles conditions cela se vérifie-t-il, et quand cela ne fonctionne-t-il plus ?

5. Quels cadres d’évaluation s’appliquent à l’alignement à l’échelle d’une communauté ? Les benchmarks d’alignement standard évaluent des propriétés de sécurité à usage général. Quels benchmarks seraient appropriés pour évaluer l’alignement spécifique à un domaine — la fidélité aux normes, au vocabulaire et aux valeurs d’une communauté donnée ?

Ces questions dépassent le champ d’action d’une seule équipe de déploiement. Nous les soulevons car le problème de l’alignement à l’échelle communautaire — prosaïque, lourd de conséquences opérationnelles et largement ignoré par la communauté scientifique — mérite davantage d’attention qu’il n’en reçoit actuellement.

Programme de la plateforme et de la communauté fondatrice : My Digital Sovereignty. Architecture IA complète : Village AI on Agentic Governance. Formations destinées aux professionnels sur l’exploitation de ces systèmes sous contrôle humain : Travailler avec Claude et Agents at Work.