DGrid teste si les agents onchain peuvent améliorer la sélection de modèles d’IA

DGrid a transformé la sélection de modèles en compétition en conditions réelles, malgré un conflit non résolu : ses juges automatisés sont des modèles d’IA qui évaluent d’autres modèles d’IA. L’expérience a émergé dans une couverture de Google News liée à CertiK, plaçant le système d’agents onchain de DGrid sous un examen plus large. DGrid affirme que ces agents comparent des réponses anonymes, enregistrent des identités vérifiables sur BNB Chain et contribuent à améliorer ses décisions de routage.

L’approche répond à un véritable problème. Les développeurs choisissent désormais parmi des centaines de modèles aux forces, profils de latence, limites de contexte et coûts d’exploitation différents. Un routeur peut effectuer ce choix automatiquement, mais il a besoin d’éléments indiquant quel modèle obtient les meilleurs résultats pour chaque type de demande.

DGrid souhaite que son AI Arena fournisse ces éléments. Des participants humains et des agents configurés par les utilisateurs reçoivent deux réponses anonymes à la même requête, puis sélectionnent la meilleure. Ces préférences peuvent influencer le classement des modèles et, selon DGrid, orienter à terme les requêtes vers un modèle adapté.

La compétition centrale n’oppose pas DGrid à un seul rival. Elle oppose une évaluation automatisée et économiquement récompensée à des tests plus lents de préférence humaine. Les votes humains apportent du contexte et du jugement, mais leur collecte est coûteuse. Les votes d’agents arrivent à grande échelle, mais ils peuvent reproduire les mêmes biais qui affectent déjà les résultats des modèles.

Cette tension dépasse un seul projet Web3. OpenRouter propose déjà une sélection automatique de modèles, tandis que LMArena utilise des comparaisons humaines participatives pour classer les modèles. DGrid teste si l’identité onchain, les récompenses et les agents juges peuvent combiner les deux approches sans corrompre le signal de préférence.

Google News met l’expérience de routage de DGrid davantage en lumière

Le changement important n’est pas que DGrid ait enregistré des agents sur une blockchain. C’est que leurs jugements deviennent des données d’entrée pour la découverte et le routage des modèles.

DGrid a lancé Arena for Agent comme extension de sa plateforme existante de comparaison à l’aveugle. Un participant configure un agent avec un fournisseur d’API, une clé API et un modèle pris en charge. DGrid envoie ensuite à cet agent des tâches d’évaluation impliquant deux réponses anonymes de modèles.

L’agent renvoie une préférence au lieu de produire les réponses initiales. DGrid distribue la tâche, enregistre le résultat et met à jour le solde de récompenses de l’agent. Son système d’évaluation d’agents prend en charge des modèles accessibles via DGrid, OpenRouter, OpenAI, Google, Anthropic et d’autres fournisseurs listés.

DGrid décrit une boucle fermée. Un système d’IA génère une question, deux modèles y répondent, puis un autre modèle d’IA choisit la meilleure réponse. Le jugement qui en résulte alimente les données de performance de la plateforme.

C’est là que le cadrage de Google News mérite de la prudence. Google News est le canal de découverte de l’élément CertiK mentionné, et non le développeur, l’opérateur ou la norme technique derrière l’expérience. Les sujets sous-jacents sont Arena de DGrid, ses identités d’agents et ses ambitions de routage de modèles.

Chaque évaluateur configuré reçoit une identité enregistrée via ERC-8004 sur BNB Chain. ERC-8004 est une proposition de norme pour agents qui définit des registres d’identité, de réputation et de validation. L’enregistrement d’identité peut rendre un agent découvrable et le relier à des retours publics.

La norme ne rend pas un agent intelligent ou précis. Elle enregistre quel agent a agi et crée un emplacement pour les données de réputation. La spécification officielle ERC-8004 sépare identité, réputation et validation, car ces fonctions répondent à différents problèmes de confiance.

DGrid associe également des récompenses économiques aux évaluations terminées. Sa description publiée indique que la qualité des tâches affecte l’attribution de points et impose un plafond quotidien de gains à chaque agent. Cette organisation encourage les propriétaires à maintenir leurs agents disponibles et à soumettre des jugements de manière cohérente.

Cependant, un enregistrement de transaction prouve seulement qu’un participant enregistré a soumis un résultat. Il ne prouve pas que la préférence était correcte, indépendante ou alignée sur les besoins d’un utilisateur humain. Cet écart pose la question centrale de l’expérience de DGrid.

La page publique d’Arena de DGrid affiche actuellement des chiffres de participation pour les votes, les juges, les modèles et les agents actifs. Ces chiffres sont des compteurs de première partie et n’ont pas été audités de manière indépendante. Ils indiquent l’ampleur revendiquée par DGrid, mais ne doivent pas être considérés comme une preuve vérifiée de la qualité du routage.

L’expérience modifie donc davantage le pipeline d’évaluation que les modèles sous-jacents. DGrid cherche à transformer des jugements continus par paires en un signal de routage réutilisable. La capacité de ce signal à améliorer la sélection de modèles dépend de la manière dont la plateforme filtre les biais, la collusion, la répétition et les participations de faible qualité.

L’évaluation automatisée met les tests de préférence humaine sous pression

Les agents de DGrid peuvent produire des préférences plus vite que les humains, mais cette rapidité ne compte que si les libellés obtenus représentent ce que les utilisateurs valorisent réellement.

La comparaison à l’aveugle est devenue une méthode influente pour évaluer les modèles conversationnels. Deux systèmes répondent à la même requête sans afficher leur identité. Un votant sélectionne la réponse préférée, ce qui réduit l’influence de la réputation de la marque.

LMArena a contribué à établir cette méthode avec des participants humains. Sa recherche sur l’arène a décrit plus de 240 000 votes dans le jeu de données initial de l’article. Les chercheurs ont indiqué que les préférences participatives présentaient un accord significatif avec les évaluateurs experts.

DGrid reprend la structure anonyme, par paires, mais modifie l’identité de ceux qui émettent une grande partie des votes. Un agent peut traiter des tâches en continu et appliquer de façon répétée la même consigne d’évaluation. Cette cohérence est attrayante lorsqu’une plateforme couvre de nombreux modèles et reçoit chaque jour de nouvelles sorties.

La réponse imposée aux plateformes d’évaluation menées par des humains n’est pas nécessairement de mettre chaque vote onchain. Elles doivent montrer pourquoi les jugements humains fournissent une information que les juges synthétiques ne peuvent pas reproduire. Elles peuvent aussi avoir besoin de systèmes hybrides plus rapides, réservant les humains aux cas ambigus ou à fort impact.

Les routeurs centralisés subissent une pression venant d’une autre direction. Des services comme OpenRouter analysent déjà les requêtes et sélectionnent dans un ensemble de modèles soigneusement choisi. Son routeur automatique tient compte de facteurs tels que le type de tâche, la complexité de la requête et les capacités des modèles.

La distinction proposée par DGrid réside dans la boucle de retour. Au lieu de s’appuyer uniquement sur des benchmarks internes ou sur une politique de routage gérée de manière centralisée, la plateforme veut recueillir les préférences d’un réseau de participants identifiables. Ces participants peuvent inclure des humains et des agents configurés indépendamment.

En théorie, cela élargit la couverture. Un juge spécialisé dans le code pourrait révéler quel candidat traite bien les questions sur les dépôts. Un autre agent pourrait se spécialiser dans la rédaction multilingue ou l’extraction structurée. Le routeur pourrait apprendre des préférences propres à chaque tâche au lieu de s’appuyer sur un classement global unique.

En pratique, la spécialisation doit être démontrée plutôt qu’inférée à partir de l’enregistrement d’un agent. DGrid a besoin d’un nombre suffisant d’évaluations répétées et contrôlées pour déterminer si un juge est fiable dans une catégorie donnée. Un modèle qui évalue bien de courtes réponses factuelles peut échouer face à l’analyse juridique, à l’humour ou à la synthèse longue.

La source des requêtes compte également. Un routeur entraîné principalement sur des questions simples peut sembler précis tout en échouant sur le travail que les développeurs lui soumettent réellement. DGrid affirme que son système utilise des agents de définition des questions, ce qui ajoute une autre couche automatisée au pipeline de données.

Les requêtes synthétiques peuvent étendre rapidement les tests, mais elles peuvent refléter les habitudes des modèles qui les génèrent. Des formulations similaires, des schémas de benchmark familiers ou une couverture thématique étroite peuvent donner l’impression que les modèles candidats sont plus capables qu’ils ne le sont en production.

Les requêtes humaines contiennent du contexte incomplet, des contraintes inhabituelles, des fautes de frappe, des intentions changeantes et des connaissances locales. Ces imperfections ne sont pas du bruit à éliminer. Elles font partie de l’environnement qu’un routeur utile doit pouvoir gérer.

La version la plus solide de l’approche de DGrid est donc hybride. Les agents apportent une couverture large et reproductible, tandis que les humains assurent l’étalonnage des cas subjectifs et difficiles. L’Arena de DGrid inclut ses deux modes de participation, ce qui lui offre une voie possible vers cet équilibre.

Pour les développeurs, le gain serait concret. Une application pourrait envoyer une demande de classification routinière vers un petit modèle, router une tâche de planification complexe ailleurs et conserver une solution de repli en cas de défaillance d’un fournisseur. Les équipes passeraient moins de temps à maintenir des règles propres à chaque modèle.

Toutefois, la sélection de modèles ne peut pas dépendre uniquement de la qualité des réponses. Les systèmes de production se préoccupent également de la latence, de la disponibilité, de la longueur de contexte, des politiques de données, de la prise en charge des outils et de la prévisibilité du comportement. Le signal de routage de DGrid doit relier les données de préférence à ces contraintes opérationnelles.

L’identité onchain ne peut pas vérifier le raisonnement d’un juge IA

DGrid peut rendre un évaluateur traçable sans rendre son jugement fiable, ce qui constitue le compromis déterminant de l’expérience.

ERC-8004 offre à DGrid une manière structurée d’identifier les agents. La norme utilise un registre d’identité et prend en charge des enregistrements de réputation ou de validation associés. Cela peut aider à distinguer les participants persistants des comptes anonymes jetables.

C’est utile pour la responsabilité. Si un agent est régulièrement en désaccord avec des jugements de référence fiables, le système peut réduire son influence. S’il obtient de bons résultats dans des tâches contrôlées, sa réputation peut gagner en valeur.

Pourtant, l’identité ne constitue que la première couche. Un propriétaire peut enregistrer un agent, puis modifier le modèle, la consigne, la configuration API ou la logique environnante. La propre description de DGrid autorise les utilisateurs à mettre à jour les paramètres API après la création, tandis que l’identité onchain reste en place.

Cela crée un problème de continuité. Un score de réputation peut décrire plusieurs configurations d’évaluateurs différentes opérant sous un même nom. À moins que chaque changement de configuration significatif soit enregistré et intégré à la notation, les utilisateurs ne peuvent pas savoir quelle version a acquis cette réputation.

Il existe également une frontière de vérification entre la chaîne et le fournisseur de modèles. La plupart des appels à des modèles commerciaux se font offchain via des API privées. Un enregistrement blockchain ne peut pas établir indépendamment quel modèle a traité une tâche, quelle consigne système il a reçue ou si le jugement renvoyé a été modifié avant sa soumission.

Des méthodes de validation peuvent réduire cet écart. Des environnements d’exécution fiables, des preuves cryptographiques, des reçus signés par les fournisseurs ou une inférence reproductible de modèles ouverts peuvent fournir des éléments plus solides. Chaque méthode ajoute des coûts, de la complexité ou des exigences matérielles.

Les documents techniques plus généraux de DGrid décrivent Proof of Quality, ou PoQ, comme un cadre d’évaluation des sorties d’inférence à travers l’alignement sur l’exactitude, la cohérence des réponses, la conformité au format et des signaux associés. Son litepaper du réseau décrit également le téléversement de journaux et de scores de qualité afin de constituer des enregistrements auditables.

Il s’agit d’affirmations de conception de DGrid, et non d’une confirmation indépendante que chaque jugement d’Arena bénéficie d’une vérification cryptographique complète. La documentation publique ne fournit pas encore assez de détails pour reproduire l’intégralité de la méthode de notation ni mesurer son taux d’erreur parmi les modèles juges.

Cette distinction est importante, car un juge IA peut soumettre une erreur parfaitement traçable. Il peut favoriser une réponse plus longue, reproduire les préférences stylistiques d’un fournisseur, manquer une erreur factuelle subtile ou sélectionner une réponse dangereuse qui paraît assurée.

Les incitations économiques peuvent aggraver le problème si la plateforme récompense trop directement l’accord. Le propriétaire d’un agent peut optimiser la réponse consensuelle plutôt que la meilleure réponse. Une fois que les participants ont appris quels styles remportent généralement les suffrages, ils peuvent produire des votes prévisibles sans effectuer une évaluation rigoureuse.

Cela rappelle le problème auquel sont confrontés les systèmes de réputation en ligne. Les registres publics découragent certains abus, mais les participants peuvent encore se coordonner, imiter les comportements efficaces ou créer plusieurs identités lorsque les récompenses attendues dépassent les coûts d’inscription.

La conception onchain de DGrid peut aider les enquêteurs à repérer des schémas qu’une base de données privée pourrait masquer. Les analystes pourraient examiner des relations de vote répétées, la concentration des récompenses ou des groupes suspects. La transparence facilite l’audit, mais elle ne réalise pas l’audit automatiquement.

La confidentialité soulève une autre préoccupation. Les requêtes adressées aux modèles contiennent souvent du code propriétaire, des données personnelles, des documents commerciaux ou des instructions internes. Enregistrer l’intégralité des prompts et des sorties sur une chaîne publique ne conviendrait pas à de nombreux usages en entreprise.

Un système pratique devrait enregistrer des engagements, des hachages, des preuves de paiement ou des métadonnées limitées, tout en conservant les contenus sensibles offchain. Il doit également prévoir des politiques de conservation claires pour les données d’évaluation offchain. La permanence onchain ne supprime pas les obligations conventionnelles de sécurité.

Pour les acheteurs, la question n’est pas de savoir si la blockchain apparaît dans l’architecture. Elle est de savoir si le système peut démontrer une chaîne fiable, depuis la classification de la tâche jusqu’au résultat observé en production, en passant par la sélection des candidats, l’évaluation et la décision de routage.

Ces preuves doivent rester compréhensibles pour les opérateurs. Une équipe qui enquête sur une mauvaise réponse doit savoir pourquoi le routeur a sélectionné un modèle. Un identifiant d’agent immuable est peu utile si la politique de décision reste opaque.

Le véritable risque est que les juges IA renforcent les biais de l’IA

L’expérience échoue si les votes des agents deviennent un signal autoréférentiel qui récompense les comportements familiers des modèles plutôt que les résultats pour les utilisateurs.

L’évaluation par LLM en tant que juge est utile, car des modèles compétents peuvent comparer des réponses avec bien moins d’efforts que des examinateurs experts. Les chercheurs savent également que ces juges présentent des préférences systématiques.

Un problème documenté est le biais de position. Un juge peut favoriser la réponse affichée en premier ou en second, même lorsque le contenu demeure inchangé. Des chercheurs ayant étudié 12 modèles juges dans plus de 100 000 instances d’évaluation ont constaté que les effets de position variaient selon la tâche et le juge.

La même étude a révélé que l’écart de qualité entre les réponses influençait l’ampleur de l’effet. Les divergences évidentes sont plus faciles à juger. Les confrontations serrées laissent davantage de place à des caractéristiques de présentation non pertinentes pour influencer le résultat.

Un autre problème est le biais de style. Un juge peut récompenser un langage assuré, une mise en forme rigide, la longueur ou le niveau de détail des explications, même lorsque ces traits n’améliorent pas l’exactitude factuelle. Les modèles candidats peuvent alors optimiser leurs réponses en fonction des préférences visibles des évaluateurs.

La préférence pour soi présente un risque particulièrement pertinent pour DGrid. Un agent alimenté par une famille de modèles peut favoriser des réponses qui ressemblent au style ou au schéma de raisonnement de cette famille. Si de nombreux participants configurent le même juge populaire, les classements obtenus peuvent hériter d’une perspective concentrée.

DGrid peut réduire ces effets en randomisant l’ordre des réponses et en évaluant des paires inversées. Il peut utiliser plusieurs familles de juges, mesurer les désaccords entre évaluateurs, insérer des tâches de contrôle vérifiées et séparer les catégories objectives des catégories subjectives.

La plateforme doit également expliquer comment elle résout les conflits. Un vote majoritaire est facile à comprendre, mais une majorité de juges corrélés ne constitue pas une preuve équivalente à des éléments indépendants. Dix agents utilisant le même modèle sous-jacent peuvent apporter moins d’informations que trois évaluateurs réellement différents.

La conception des récompenses exige un examen tout aussi attentif. DGrid affirme que des points liés à la qualité encouragent un meilleur jugement, mais la qualité nécessite une référence externe. Si la plateforme définit principalement la qualité comme l’accord avec les pairs, des agents coordonnés ou homogènes peuvent dominer le signal.

L’étalonnage humain peut fournir cette référence. Des experts peuvent examiner un échantillon de comparaisons contestées, tandis que des utilisateurs ordinaires peuvent exprimer leurs préférences quant à l’utilité conversationnelle. Ces étiquettes peuvent révéler les cas où le consensus automatisé s’écarte des attentes humaines.

Cependant, les votes humains comportent eux aussi des biais et des normes incohérentes. Un système d’évaluation utile ne devrait idéaliser aucun des deux camps. Il devrait mesurer le désaccord et adapter la population de juges à l’application.

Un routeur de résumés médicaux, par exemple, nécessite une évaluation factuelle et de sécurité par des examinateurs qualifiés. Un routeur d’écriture créative a besoin des préférences du public plutôt que d’une réponse prétendument correcte. Un routeur de code nécessite des tests exécutables en complément d’une évaluation stylistique.

C’est pourquoi un classement global unique des modèles ne peut pas résoudre la sélection automatique. Le routage exige des preuves conditionnelles : quel modèle fonctionne pour cette tâche, sous ces contraintes, pour cette population d’utilisateurs ? L’Arena de DGrid peut apporter des données, mais seulement si elle préserve ces distinctions.

L’interface publique de la plateforme met l’accent sur les votes et les classements agrégés. L’activité agrégée peut attirer la participation, mais elle révèle peu de choses sur les intervalles de confiance, la couverture des catégories, la diversité des juges ou la résistance à la manipulation.

Les développeurs qui évaluent ce service devraient demander ces précisions avant de s’appuyer sur le routage automatique. Ils devraient également conserver des listes blanches de modèles, des contrôles de dépenses, des journaux et des solutions de repli déterministes. Un routeur doit rester un composant de politique, et non une autorité sans contrôle.

Les équipes qui collectent leurs propres évaluations ont besoin d’une rigueur comparable. Une base de connaissances IA consultable peut aider à préserver les prompts, les décisions et les notes des évaluateurs, mais les critères d’évaluation exigent toujours une conception délibérée.

Le résultat le plus précieux de DGrid ne sera peut-être pas un classement universel. Il pourrait s’agir d’un ensemble de données transparent montrant quand les agents sont en désaccord, quels juges restent fiables et comment les préférences évoluent selon les tâches.

Ce résultat rendrait le système plus utile même si une notation entièrement autonome se révélait irréaliste. Le désaccord est une information. Le masquer derrière un unique score de routage gaspillerait la contribution potentiellement la plus forte de l’expérience.

Trois signaux montreront si DGrid améliore la sélection des modèles

DGrid a désormais besoin de preuves reproductibles, d’usages réels diversifiés et de gains de routage mesurables, plutôt que de compteurs de participation plus élevés.

Le premier signal est une méthodologie d’évaluation publique suffisamment détaillée pour permettre des tests indépendants. DGrid devrait définir l’échantillonnage des prompts, la randomisation des réponses, la pondération des juges, les tâches de contrôle, la gestion des désaccords et la résistance aux agents dupliqués.

Un benchmark reproductible renforcerait l’affirmation centrale. Des chercheurs indépendants pourraient comparer les classements dérivés des agents de DGrid avec des étiquettes d’experts et des votes humains de l’Arena. Une forte concordance dans plusieurs catégories de tâches soutiendrait l’approche automatisée.

Un désaccord important ne la discréditerait pas automatiquement. La question essentielle serait de savoir si DGrid identifie cette incertitude et empêche les signaux faibles de contrôler le routage en production. Une abstention tenant compte de la confiance peut être plus utile qu’une réponse forcée.

L’expérience perdrait en crédibilité si la méthodologie restait opaque tandis que les compteurs d’activité propriétaires continuaient d’augmenter. Davantage de votes ne résolvent pas les biais corrélés. Ils peuvent les amplifier.

Le deuxième signal est la composition de la participation à l’Arena. DGrid devrait divulguer la répartition des modèles juges, des fournisseurs, des catégories de tâches, des régions et des participants récurrents, sans exposer d’informations privées.

Un groupe de juges diversifié renforcerait l’idée que les agents onchain apportent des perspectives indépendantes. Une concentration autour d’un fournisseur ou d’une stratégie de récompense affaiblirait cette idée. Il en va de même pour des prompts générés par une famille restreinte de modèles qui conçoivent les questions.

La participation humaine reste pertinente ici. L’AI Arena publique de DGrid permet aux personnes de comparer des réponses anonymes aux côtés d’évaluateurs agents. La relation entre ces deux flux de votes importe davantage que leur total combiné.

La plateforme devrait indiquer où les humains et les agents sont d’accord, où ils divergent et quel camp prédit la satisfaction ultérieure des utilisateurs. Cela transformerait sa conception hybride en avantage empirique.

Le troisième signal est la performance du routage en production. DGrid doit montrer que les données de préférence améliorent les requêtes réelles par rapport à des références plus simples. Ces références devraient inclure la sélection manuelle des modèles, des règles statiques, un choix aléatoire parmi les modèles qualifiés et un routeur automatique centralisé.

Les mesures utiles comprennent la réussite des tâches, le taux de correction, la latence, la fréquence des solutions de repli et les remplacements par les utilisateurs. Le coût peut faire partie de la comparaison sans réduire la qualité à la réponse disponible la moins chère.

Un essai contrôlé pourrait acheminer des requêtes similaires via différentes politiques, puis évaluer les résultats à l’aide de tests objectifs et d’examinateurs en aveugle. Le résultat devrait identifier les charges de travail qui en bénéficient, plutôt que de présenter un unique chiffre d’amélioration universel.

C’est à ce stade que la passerelle et l’Arena de DGrid se connectent ou restent des produits séparés. La passerelle annonce l’accès à plus de 200 modèles et un routage intelligent. L’Arena affirme que les votes entraînent des décisions de routage plus intelligentes.

DGrid n’a pas encore publié suffisamment de preuves indépendantes pour établir dans quelle mesure ces votes améliorent la sélection en direct. Le maillon manquant est une comparaison mesurée avant-après utilisant des charges de travail divulguées.

La visibilité de CertiK peut ajouter un niveau de contrôle, mais ne doit pas être confondue avec un audit de la méthode d’évaluation. Le profil DGrid de CertiK a répertorié des informations de sécurité et de maturité, tout en indiquant qu’un audit de code CertiK n’était pas disponible sur le profil indexé. La surveillance de sécurité et la validation de la qualité des modèles sont des évaluations distinctes.

Le marché plus large fournira également un test. Les services de routage centralisés peuvent se mettre à jour rapidement, utiliser des données de production privées et éviter les surcoûts de la blockchain. DGrid doit démontrer que la participation ouverte et une identité traçable créent des informations que ces systèmes ne peuvent pas recueillir aussi efficacement.

Si DGrid publie des gains reproductibles, démontre la diversité des juges et relie les préférences de l’Arena à de meilleurs résultats en production, son expérience soutiendra un nouveau modèle de routage. Les agents onchain serviraient alors de contributeurs responsables plutôt que d’identités blockchain décoratives.

Si ces signaux n’apparaissent pas, le projet pourra toujours exploiter une plateforme de récompenses active. Il n’aura pas établi que les votes des agents sélectionnent de meilleurs modèles.

Les lecteurs arrivant via google news devraient surveiller la chaîne de preuves, et non le titre sur la participation. DGrid peut-il montrer qui a jugé, comment les biais ont été contrôlés et si les applications ont obtenu de meilleures réponses ? Ces trois questions détermineront si cela devient une infrastructure IA utile ou une nouvelle boucle d’évaluation autoréférentielle.