🎓 Academia Edition Article 3 de 7

Toutes les éditions · Academia Edition

A walking path curving into the distanceYour Community, Your AI — CC BY 4.0

IA de plateforme vs IA régie par la communauté — Une analyse structurelle

Le problème du corpus

Les propriétés de gouvernance d’un système d’IA sont largement déterminées par son corpus d’entraînement. Il ne s’agit pas d’une préoccupation secondaire, mais d’une propriété architecturale de premier ordre. (Les termes tels que corpus, réglage fin et agent sont définis dans le glossaire.)

Les grands modèles de langage (LLM) commerciaux proposés par les principaux fournisseurs de plateformes sont entraînés sur des corpus à l’échelle du Web : des milliards de documents extraits de l’Internet ouvert, complétés par des ensembles de données sous licence et des collections propriétaires. Les systèmes qui en résultent ont des capacités étendues et, par conséquent, des hypothèses de distribution tout aussi larges.

En tant que corpus d’entraînement, Internet surreprésente certains domaines et certaines perspectives :

En conséquence, il sous-représente :

Ce déséquilibre de répartition ne peut être corrigé par l’échelle. Un corpus web plus vaste ne fait qu’amplifier ces mêmes biais. Il s’agit d’une propriété structurelle de la source de données, et non d’une erreur d’échantillonnage.

L’IA spécifique à un domaine : l’alternative et ses limites

La plateforme Village adopte une approche architecturale différente : un modèle plus petit, entraîné sur un corpus en couches qui privilégie le contenu spécifique au domaine plutôt que l’étendue.

L’architecture d’entraînement comporte trois couches :

Couche « plateforme ». Connaissances opérationnelles communes partagées entre tous les déploiements — fonctionnement de la plateforme, fonctionnalités disponibles, aide à la navigation. Cette couche est analogue à une ontologie partagée entre les instances.

Couche « communauté ». Contenu spécifique à un déploiement particulier : les enregistrements, les communications et les documents produits par la communauté qui exploite l’instance. C’est cette couche qui différencie un déploiement d’un autre et ancre les résultats du modèle dans le contexte local.

Couche « consentement ». Une contrainte structurelle : aucun contenu n’entre dans le corpus d’entraînement sans le consentement explicite et vérifiable de son créateur. Cette règle est appliquée au niveau architectural, et non par le biais d’une politique.

Le système qui en résulte est plus restreint qu’un LLM commercial. Il ne peut aborder avec compétence des sujets hors de son domaine d’entraînement. Il ne produira pas d’écrits créatifs à usage général ni ne mènera de conversations sur des sujets variés. Ce qu’il offre en revanche, ce sont des résultats ancrés dans les archives d’une communauté spécifique, et vérifiables par rapport à ces archives.

Limites de cette approche

Il convient de reconnaître plusieurs limites :

Généralité réduite. Un modèle spécifique à un domaine ne peut pas aider à des tâches en dehors de son domaine d’entraînement. Les membres de la communauté qui ont besoin d’une assistance IA à usage général doivent utiliser un système distinct.

Contraintes liées à la taille du corpus. Les petites communautés produisent un contenu limité. Un modèle entraîné sur quelques centaines de documents dispose d’une base de connaissances proportionnellement restreinte. La qualité des résultats est directement limitée par le volume et la qualité du contenu de la communauté.

Délai de réentraînement. La couche communautaire nécessite un réentraînement périodique pour intégrer de nouveaux contenus. Entre deux cycles de réentraînement, les connaissances du modèle sont obsolètes. La cadence actuelle de réentraînement (hebdomadaire, selon un calendrier régulier) peut s’avérer insuffisante pour des contextes en évolution rapide.

Fragilité du réglage fin. Le réglage fin spécifique à un domaine superpose de nouveaux modèles à la distribution existante d’un modèle de base. Dans certaines conditions de requête — en particulier pour des questions nouvelles ou complexes —, les modèles du modèle de base peuvent réapparaître, un phénomène connu dans la littérature sous le nom d’« oubli catastrophique ». L’ampleur de l’impact de ce phénomène sur les résultats pertinents pour la gouvernance n’est pas encore bien caractérisée pour ce système.

Guardian Agents : architecture de vérification externe

La plateforme Village ne s’appuie pas uniquement sur l’entraînement pour garantir la qualité des résultats. Elle interpose une couche de vérification — appelée « Guardian Agents » — entre les résultats du modèle et l’utilisateur final.

L’architecture Guardian Agent comprend quatre mécanismes de vérification indépendants :

Vérification de l’ancrage sémantique. La sortie du modèle est comparée au corpus de documents de la communauté à l’aide de mesures de similarité basées sur l’encodage. Les sorties qui ne sont pas suffisamment ancrées dans des documents réels sont signalées ou supprimées.

Décomposition au niveau des affirmations. La sortie est décomposée en affirmations individuelles, chacune étant vérifiée indépendamment. Cela permet de remédier au problème courant où une réponse contient un mélange d’assertions étayées et non étayées.

Surveillance de la dérive comportementale. Une couche de surveillance longitudinale suit les tendances dans les résultats du modèle au fil du temps, détectant les changements systématiques de ton, de cadrage ou de précision qui pourraient indiquer une dérive ou une dégradation de la distribution.

Intégration adaptative des retours d’expérience. Les retours d’expérience des membres de la communauté (notations explicites et corrections des modérateurs) sont intégrés aux seuils de vérification. Cela crée une boucle de rétroaction dans laquelle le système de vérification s’adapte progressivement aux attentes de la communauté au fil du temps.

Contre-arguments et modes de défaillance

L’architecture Guardian Agent est une contribution à la recherche, et non une solution définitive. Plusieurs contre-arguments et modes de défaillance méritent d’être examinés :

La similarité sémantique n’est pas la vérité. La vérification basée sur l’encodage mesure la proximité sémantique, et non l’exactitude factuelle. Une affirmation sémantiquement proche d’un document source peut tout de même être factuellement erronée — les paraphrases peuvent inverser le sens tout en préservant la similitude des représentations. La couche de décomposition au niveau des affirmations résout partiellement ce problème, mais des faux positifs et des faux négatifs subsistent.

La couverture de la vérification est incomplète. Les « gardiens » peuvent vérifier les affirmations par rapport aux archives existantes. Ils ne peuvent pas vérifier les affirmations portant sur des sujets non couverts par les archives de la communauté. Pour les questions inédites, le système est confronté à un choix entre refuser de répondre (approche prudente mais peu utile) et générer des résultats invérifiables (utile mais sans contrôle). La mise en œuvre actuelle signale les réponses à faible niveau de confiance plutôt que de les supprimer, ce qui transfère la charge de la vérification à l’utilisateur final.

Les boucles de rétroaction peuvent introduire des biais. Le mécanisme de rétroaction adaptative part du principe que les retours de la communauté constituent un signal fiable. Dans la pratique, ces retours peuvent être clairsemés, biaisés en faveur de certains groupes d’utilisateurs, ou refléter des préférences qui vont à l’encontre de la précision. Le système ne fait actuellement pas la distinction entre les retours qui corrigent des erreurs factuelles et ceux qui reflètent des préférences esthétiques ou idéologiques.

Surcoût de calcul. La vérification à quatre niveaux ajoute de la latence et un surcoût de calcul. Pour les requêtes urgentes, ce surcoût peut dégrader l’expérience utilisateur au point que le système ne soit plus utilisé — un échec de gouvernance dû à la non-adoption plutôt qu’à une erreur technique.

Délégation et centre de contrôle

L’analyse précédente concerne le corpus — dont le système reproduit les schémas. Le tournant agentique (article 1) introduit un deuxième axe orthogonal : le centre de contrôle dès lors que le système agit plutôt que de se contenter de conseiller. Déléguer une tâche à un agent commercial revient à transférer non seulement des données, mais aussi l’autorité opérationnelle — c’est-à-dire la capacité à mener des actions (transactions, communications, modifications d’enregistrements) sur une infrastructure que la partie déployante ne contrôle pas, les points d’intervention étant déterminés par le fournisseur. Des commentaires récents qualifient cela de problème de responsabilité et de confidentialité des données, sous le couvert d’une question de capacités de l’IA. L’alternative régie par la communauté n’élimine pas la délégation ; elle la limite. Les actions sont confinées aux limites de la communauté, restreintes à des opérations réversibles et contrôlées par le mécanisme d’application des limites (article 3), de sorte que les actions ayant des conséquences importantes ou irréversibles nécessitent une autorisation humaine. L’argument architectural n’est pas que l’agent soit plus performant, mais que le lieu du contrôle reste vérifiable et récupérable — une propriété orthogonale à la capacité brute et, dans cette analyse, prioritaire par rapport à celle-ci.

Le compromis : un cadre analytique

Le choix entre une IA commerciale et une IA régie par la communauté n’est pas un choix entre une bonne et une mauvaise option. Il s’agit d’un choix entre différents profils de compromis :

Dimension IA sur plateforme commerciale IA régie par la communauté
Étendue des capacités Élevée Faible (spécifique à un domaine)
Biais de distribution Reflète un corpus à l’échelle du Web Reflète un corpus communautaire
Vérifiabilité Faible (propriétaire, opaque) Plus élevée (open source, vérifiable)
Souveraineté des données Les données sont transmises au fournisseur Les données restent au sein de la communauté
Architecture de vérification Contrôlée par le fournisseur Inspectable par la communauté
Ressources informatiques Importantes (à l’échelle du cloud) Limitées (locales ou petit cloud)
Généralisation Élevée Faible (par conception)
Autorité d’action (agentique) Médiée par le fournisseur, peu de points d’intervention Limité à la communauté, contrôlée par des intervenants humains

Aucun des deux profils n’est catégoriquement supérieur. Le choix approprié dépend des priorités de gouvernance de la communauté qui déploie la plateforme — un point qui constitue en soi une décision de gouvernance.

Reproductibilité et généralisabilité

Une question qui intéresse particulièrement la communauté scientifique est de savoir si l’architecture Village est reproductible et généralisable au-delà de son contexte de déploiement actuel.

La plateforme est conçue pour un fonctionnement multi-locataires au sein de divers types de communautés (la mise en œuvre actuelle prend en charge neuf types de produits, allant des paroisses aux groupes de protection de la nature en passant par les associations d’anciens élèves). Le système de vocabulaire adapte la terminologie au contexte de la communauté, ce qui suggère un certain degré de généralisabilité au niveau de la couche de la plateforme.

Cependant, plusieurs facteurs limitent la possibilité d’affirmer avec certitude cette généralisabilité :

Il s’agit là de questions de recherche ouvertes, et non de choix de conception tranchés.


Pour l’architecture complète de Guardian Agents, voir Village AI sur la gouvernance agentique. Les questions de délégation et de lieu de contrôle soulevées ici sont abordées du point de vue du praticien dans le cours complémentaire Agents at Work ; Working with Claude traite de l’évaluation des résultats des modèles.

Cela vous a été utile ? Partagez cet article ou affichez un code QR à scanner.