DGrid prueba si los agentes onchain pueden mejorar la selección de modelos de IA

DGrid ha convertido la selección de modelos en una competencia en tiempo real, pese a un conflicto aún sin resolver: sus jueces automatizados son modelos de IA que evalúan a otros modelos de IA. El experimento salió a la luz mediante cobertura de google news vinculada a CertiK, lo que sometió el sistema de agentes onchain de DGrid a un escrutinio más amplio. DGrid afirma que estos agentes comparan respuestas anónimas, registran identidades verificables en BNB Chain y ayudan a mejorar sus decisiones de enrutamiento.

El enfoque aborda un problema real. Los desarrolladores ahora eligen entre cientos de modelos con distintas fortalezas, perfiles de latencia, límites de contexto y costes operativos. Un enrutador puede tomar esa decisión automáticamente, pero necesita evidencia sobre qué modelo funciona mejor para cada tipo de solicitud.

DGrid quiere que su AI Arena aporte esa evidencia. Los participantes humanos y los agentes configurados por usuarios reciben dos respuestas anónimas a la misma indicación y luego seleccionan la mejor. Esas preferencias pueden influir en las clasificaciones de los modelos y, según DGrid, acabar guiando las solicitudes hacia un modelo adecuado.

La competencia central no enfrenta a DGrid con un único rival. Enfrenta la evaluación automatizada con recompensas económicas a unas pruebas de preferencia humana más lentas. Los votos humanos aportan contexto y criterio, pero son caros de recopilar. Los votos de agentes llegan a escala, aunque pueden reproducir los mismos sesgos que ya afectan a las salidas de los modelos.

Esta tensión importa más allá de un único proyecto Web3. OpenRouter ya ofrece selección automática de modelos, mientras que LMArena utiliza comparaciones humanas de origen colectivo para clasificarlos. DGrid está probando si la identidad onchain, las recompensas y los agentes jueces pueden combinar ambos enfoques sin corromper la señal de preferencia.

Google News situó el experimento de enrutamiento de DGrid bajo una atención más amplia

El cambio importante no es que DGrid registrara agentes en una blockchain. Es que sus juicios se están convirtiendo en insumos para el descubrimiento y el enrutamiento de modelos.

DGrid lanzó Arena for Agent como una extensión de su plataforma existente de comparación a ciegas. Un participante configura un agente con un proveedor de API, una clave API y un modelo compatible. DGrid envía entonces a ese agente tareas de evaluación que incluyen dos respuestas anónimas de modelos.

El agente devuelve una preferencia en lugar de generar las respuestas originales. DGrid distribuye la tarea, registra el resultado y actualiza el saldo de recompensas del agente. Su sistema de evaluación de agentes admite modelos a los que se accede mediante DGrid, OpenRouter, OpenAI, Google, Anthropic y otros proveedores incluidos en la lista.

DGrid describe un circuito cerrado. Un sistema de IA genera una pregunta, dos modelos la responden y otro modelo de IA elige la mejor respuesta. El juicio resultante alimenta los datos de rendimiento de la plataforma.

Aquí es donde el encuadre de google news merece cautela. Google News es el canal de descubrimiento del artículo de CertiK al que se hace referencia, no el desarrollador, operador ni estándar técnico detrás del experimento. Los temas de fondo son Arena de DGrid, sus identidades de agentes y sus ambiciones de enrutamiento de modelos.

Cada evaluador configurado recibe una identidad registrada mediante ERC-8004 en BNB Chain. ERC-8004 es un estándar de agentes propuesto que define registros de identidad, reputación y validación. El registro de identidad puede hacer que un agente sea detectable y conectarlo con comentarios públicos.

El estándar no hace que un agente sea inteligente ni preciso. Registra qué agente actuó y crea un espacio para los datos de reputación. La especificación oficial de ERC-8004 separa identidad, reputación y validación porque estas funciones resuelven distintos problemas de confianza.

DGrid también vincula recompensas económicas a las evaluaciones completadas. Su descripción publicada indica que la calidad de la tarea afecta a la asignación de puntos y establece un límite diario de ganancias para cada agente. Esta disposición incentiva a los propietarios a mantener disponibles a los agentes y a enviar juicios de forma consistente.

Sin embargo, un registro de transacción solo demuestra que un participante registrado presentó un resultado. No demuestra que la preferencia fuera correcta, independiente o estuviera alineada con las necesidades de un usuario humano. Esa brecha plantea la pregunta central del experimento de DGrid.

La página pública de Arena de DGrid presenta actualmente cifras de participación sobre votos, jueces, modelos y agentes activos. Esas cifras son contadores de primera parte y no han sido auditadas de forma independiente. Indican la escala que DGrid afirma tener, pero no deberían tratarse como evidencia verificada de la calidad del enrutamiento.

Por tanto, el experimento modifica más el proceso de evaluación que los modelos subyacentes. DGrid intenta convertir juicios continuos por pares en una señal de enrutamiento reutilizable. Que esa señal mejore la selección de modelos depende de cómo la plataforma filtre el sesgo, la colusión, la repetición y la participación de baja calidad.

La evaluación automatizada presiona las pruebas de preferencia humana

Los agentes de DGrid pueden producir preferencias más rápido que las personas, pero la velocidad solo importa cuando las etiquetas resultantes representan lo que los usuarios realmente valoran.

La comparación a ciegas se ha convertido en un método influyente para evaluar modelos conversacionales. Dos sistemas responden a la misma indicación sin mostrar sus identidades. Un votante selecciona la respuesta preferida, reduciendo la influencia de la reputación de marca.

LMArena ayudó a establecer este método utilizando participantes humanos. Su investigación sobre Arena publicada describía más de 240.000 votos en el conjunto de datos original del artículo. Los investigadores informaron de que las preferencias de origen colectivo mostraban una concordancia significativa con los evaluadores expertos.

DGrid toma prestada la estructura anónima y por pares, pero cambia quién emite muchos de los votos. Un agente puede procesar tareas continuamente y aplicar de forma repetida la misma indicación de evaluación. Esa consistencia resulta atractiva cuando una plataforma cubre numerosos modelos y recibe nuevas salidas cada día.

La respuesta obligada para las plataformas de evaluación lideradas por humanos no consiste necesariamente en poner cada voto onchain. Deben demostrar por qué los juicios humanos aportan información que los jueces sintéticos no pueden reproducir. También podrían necesitar sistemas híbridos más rápidos que reserven a las personas para casos ambiguos o de alto impacto.

Los enrutadores centralizados afrontan presión desde otra dirección. Servicios como OpenRouter ya analizan las indicaciones y seleccionan de un conjunto de modelos seleccionado. Su enrutador automático considera factores como el tipo de tarea, la complejidad de la indicación y las capacidades del modelo.

La distinción propuesta por DGrid es el circuito de retroalimentación. En lugar de depender únicamente de benchmarks internos o de una política de enrutamiento gestionada centralmente, quiere obtener preferencias de una red de participantes identificables. Esos participantes pueden incluir humanos y agentes configurados de forma independiente.

En teoría, esto amplía la cobertura. Un juez centrado en programación podría revelar qué candidato maneja bien las preguntas sobre repositorios. Otro agente podría especializarse en redacción multilingüe o extracción estructurada. El enrutador podría aprender preferencias específicas de cada tarea en lugar de depender de una única clasificación global.

En la práctica, la especialización debe demostrarse, no inferirse a partir del registro de un agente. DGrid necesita suficientes evaluaciones repetidas y controladas para determinar si un juez funciona de forma fiable dentro de una categoría. Un modelo que evalúa bien respuestas factuales breves puede fallar en análisis jurídico, humor o síntesis de formato largo.

La fuente de las indicaciones también importa. Un enrutador entrenado principalmente con preguntas sencillas puede parecer preciso mientras falla en el trabajo que los desarrolladores realmente envían. DGrid afirma que su sistema utiliza agentes que plantean preguntas, lo que introduce otra capa automatizada en el flujo de datos.

Las indicaciones sintéticas pueden ampliar rápidamente las pruebas, pero pueden reflejar los hábitos de los modelos que las generan. Formulaciones similares, patrones de benchmark conocidos o una cobertura temática limitada pueden hacer que los modelos candidatos parezcan más capaces de lo que son en producción.

Las indicaciones humanas contienen contexto incompleto, restricciones inusuales, erratas, intenciones cambiantes y conocimiento local. Estas imperfecciones no son ruido que haya que eliminar. Forman parte del entorno que un enrutador útil debe manejar.

Por ello, la versión más sólida del enfoque de DGrid es híbrida. Los agentes aportan una cobertura amplia y repetible, mientras que los humanos proporcionan calibración para casos subjetivos y difíciles. Arena de DGrid incluye ambos modos de participación, lo que le da una posible vía hacia ese equilibrio.

Para los desarrolladores, el beneficio sería concreto. Una aplicación podría enviar una solicitud rutinaria de clasificación a un modelo pequeño, enrutar una tarea de planificación compleja a otro lugar y conservar una alternativa cuando falla un proveedor. Los equipos dedicarían menos tiempo a mantener reglas específicas para cada modelo.

Aun así, la selección de modelos no puede depender solo de la calidad de las respuestas. Los sistemas de producción también se preocupan por la latencia, la disponibilidad, la longitud de contexto, las políticas de datos, el soporte de herramientas y un comportamiento predecible. La señal de enrutamiento de DGrid debe conectar los datos de preferencia con esas restricciones operativas.

La identidad onchain no puede verificar el razonamiento de un juez de IA

DGrid puede hacer que un evaluador sea rastreable sin hacer que su juicio sea fiable, lo que constituye la disyuntiva definitoria del experimento.

ERC-8004 proporciona a DGrid una forma estructurada de identificar agentes. El estándar utiliza un registro de identidad y admite registros asociados de reputación o validación. Esto puede ayudar a distinguir a participantes persistentes de cuentas anónimas desechables.

Eso resulta útil para la rendición de cuentas. Si un agente discrepa repetidamente de juicios de referencia fiables, el sistema puede reducir su influencia. Si funciona bien en tareas controladas, su reputación puede adquirir más valor.

Sin embargo, la identidad es solo la primera capa. Un propietario puede registrar un agente y luego cambiar el modelo, la indicación, la configuración de la API o la lógica circundante. La propia descripción de DGrid permite a los usuarios actualizar la configuración de la API tras la creación, mientras la identidad onchain permanece vigente.

Esto crea un problema de continuidad. Una puntuación de reputación puede describir varias configuraciones diferentes de evaluador que operan bajo un mismo nombre. A menos que cada cambio significativo de configuración se registre e incorpore a la puntuación, los usuarios no pueden saber qué versión obtuvo esa reputación.

También existe un límite de verificación entre la cadena y el proveedor del modelo. La mayoría de las llamadas a modelos comerciales se realizan offchain mediante API privadas. Un registro en blockchain no puede establecer de forma independiente qué modelo procesó una tarea, qué indicación de sistema recibió o si el juicio devuelto fue alterado antes de su envío.

Los métodos de validación pueden reducir esa brecha. Los entornos de ejecución de confianza, las pruebas criptográficas, los recibos firmados por proveedores o la inferencia reproducible de modelos abiertos pueden ofrecer evidencia más sólida. Cada método añade costes, complejidad o requisitos de hardware.

Los materiales técnicos más amplios de DGrid describen Proof of Quality, o PoQ, como un marco para evaluar salidas de inferencia mediante alineación de precisión, consistencia de respuesta, cumplimiento de formato y señales relacionadas. Su litepaper de red también describe la carga de registros y puntuaciones de calidad para mantener registros auditables.

Estas son afirmaciones de diseño de DGrid, no una confirmación independiente de que cada juicio de Arena reciba una verificación criptográfica completa. La documentación pública aún no aporta suficientes detalles para reproducir el método de puntuación completo ni medir su tasa de error entre los modelos jueces.

La distinción importa porque un juez de IA puede cometer un error perfectamente rastreable. Puede favorecer una respuesta más larga, repetir las preferencias estilísticas de un proveedor, pasar por alto un error factual sutil o seleccionar una respuesta insegura que suena convincente.

Los incentivos económicos pueden agravar esto si la plataforma recompensa el acuerdo de forma demasiado directa. El propietario de un agente puede optimizar para la respuesta de consenso en lugar de para la mejor respuesta. Una vez que los participantes aprenden qué estilos suelen ganar, pueden producir votos predecibles sin realizar una evaluación cuidadosa.

Esto se asemeja al problema al que se enfrentan los sistemas de reputación en línea. Los registros públicos disuaden ciertos abusos, pero los participantes aún pueden coordinarse, imitar comportamientos exitosos o crear múltiples identidades cuando las recompensas esperadas superan los costos de registro.

El diseño onchain de DGrid puede ayudar a los investigadores a detectar patrones que una base de datos privada podría ocultar. Los analistas podrían examinar relaciones de voto repetidas, concentración de recompensas o agrupaciones sospechosas. La transparencia favorece las auditorías, pero no las realiza automáticamente.

La privacidad introduce otra preocupación. Las solicitudes a modelos suelen contener código propietario, datos personales, documentos empresariales o instrucciones internas. Registrar prompts y resultados completos en una cadena pública no sería adecuado para muchos usos empresariales.

Un sistema práctico debería registrar compromisos, hashes, comprobantes de pago o metadatos limitados, manteniendo el contenido sensible offchain. También necesita políticas de retención claras para los datos de evaluación offchain. La permanencia onchain no elimina las obligaciones convencionales de seguridad.

Para los compradores, la cuestión no es si blockchain aparece en la arquitectura. Es si el sistema puede mostrar una cadena fiable desde la clasificación de la tarea hasta la selección de candidatos, la evaluación, la decisión de enrutamiento y el resultado observado en producción.

Esa evidencia debe seguir siendo comprensible para los operadores. Un equipo que depura una respuesta deficiente necesita saber por qué el router seleccionó un modelo. Un identificador inmutable de agente sirve de poco si la política de decisión sigue siendo opaca.

El verdadero riesgo es que los jueces de IA refuercen los sesgos de IA

El experimento fracasa si los votos de los agentes se convierten en una señal autoconfirmatoria que recompensa comportamientos de modelo conocidos en lugar de resultados para los usuarios.

La evaluación de LLM-as-a-judge es útil porque los modelos capaces pueden comparar respuestas con una fracción del esfuerzo que requieren los revisores expertos. Los investigadores también saben que estos jueces muestran preferencias sistemáticas.

Un problema documentado es el sesgo de posición. Un juez puede favorecer la respuesta que aparece primero o segunda, incluso cuando el contenido permanece sin cambios. Investigadores que estudiaron 12 modelos jueces en más de 100.000 casos de evaluación descubrieron que los efectos de posición variaban según la tarea y el juez.

La misma investigación concluyó que la diferencia de calidad entre las respuestas influía en la magnitud del efecto. Las discrepancias claras son más fáciles de juzgar. Las disputas reñidas dejan más espacio para que características irrelevantes de presentación afecten el resultado.

Otro problema es el sesgo de estilo. Un juez puede recompensar el lenguaje seguro, el formato rígido, la extensión o el detalle explicativo incluso cuando esos rasgos no mejoran la precisión factual. Los modelos candidatos pueden entonces optimizar para las preferencias visibles de los evaluadores.

La autopreferencia presenta un riesgo especialmente relevante para DGrid. Un agente impulsado por una familia de modelos puede favorecer respuestas que se asemejan al estilo o patrón de razonamiento de esa familia. Si muchos participantes configuran el mismo juez popular, las clasificaciones resultantes pueden heredar una perspectiva concentrada.

DGrid puede reducir estos efectos aleatorizando el orden de las respuestas y evaluando pares intercambiados. Puede usar múltiples familias de jueces, medir el desacuerdo entre evaluadores, insertar tareas de control verificadas y separar las categorías objetivas de las subjetivas.

La plataforma también debe revelar cómo resuelve los conflictos. Una votación mayoritaria es fácil de entender, pero una mayoría de jueces correlacionados no equivale a evidencia independiente. Diez agentes que usan el mismo modelo subyacente pueden aportar menos información que tres evaluadores verdaderamente diferentes.

El diseño de recompensas exige un escrutinio similar. DGrid afirma que los puntos vinculados a la calidad fomentan un mejor juicio, pero la calidad necesita una referencia externa. Si la plataforma define la calidad principalmente como acuerdo con los pares, agentes coordinados u homogéneos pueden dominar la señal.

La calibración humana puede proporcionar esa referencia. Los expertos pueden revisar una muestra de comparaciones disputadas, mientras que los usuarios comunes pueden aportar preferencias sobre la utilidad conversacional. Estas etiquetas pueden revelar dónde el consenso automatizado se aleja de las expectativas humanas.

Sin embargo, los votos humanos también contienen sesgos y estándares inconsistentes. Un sistema de evaluación útil no debería idealizar a ninguna de las dos partes. Debería medir el desacuerdo y ajustar la población de jueces a la aplicación.

Un router de resúmenes médicos, por ejemplo, necesita evaluación factual y de seguridad de revisores cualificados. Un router de escritura creativa necesita la preferencia del público, no una respuesta supuestamente correcta. Un router de programación necesita pruebas ejecutables junto con una evaluación estilística.

Por eso una única clasificación global de modelos no puede resolver la selección automática. El enrutamiento requiere evidencia condicional: ¿qué modelo funciona para esta tarea, bajo estas restricciones y para esta población de usuarios? La Arena de DGrid puede aportar datos, pero solo si conserva esas distinciones.

La interfaz pública de la plataforma destaca los votos y clasificaciones agregados. La actividad agregada puede atraer participación, pero revela poco sobre intervalos de confianza, cobertura por categorías, diversidad de jueces o resistencia a la manipulación.

Los desarrolladores que evalúan el servicio deberían pedir esos detalles antes de confiar en el enrutamiento automático. También deberían mantener listas permitidas de modelos, controles de gasto, registros y alternativas deterministas. Un router debe seguir siendo un componente de política, no una autoridad sin revisión.

Los equipos que recopilan sus propias evaluaciones necesitan una disciplina comparable. Una base de conocimiento de IA con capacidad de búsqueda puede ayudar a conservar prompts, decisiones y notas de los revisores, pero los criterios de evaluación aún requieren un diseño deliberado.

El resultado más valioso de DGrid quizá no sea una clasificación universal. Podría ser un conjunto de datos transparente que muestre cuándo los agentes discrepan, qué jueces siguen siendo fiables y cómo cambian las preferencias entre tareas.

Ese resultado haría que el sistema fuese más útil incluso si la puntuación plenamente autónoma resulta poco realista. El desacuerdo es información. Ocultarlo tras una única puntuación de enrutamiento desperdiciaría la contribución potencial más sólida del experimento.

Tres señales mostrarán si DGrid mejora la selección de modelos

DGrid necesita ahora evidencia reproducible, uso real diverso y mejoras medibles en el enrutamiento, en lugar de contadores de participación más grandes.

La primera señal es una metodología de evaluación pública con suficiente detalle para realizar pruebas independientes. DGrid debería definir el muestreo de prompts, la aleatorización de respuestas, la ponderación de jueces, las tareas de control, la gestión del desacuerdo y la resistencia a los agentes duplicados.

Un benchmark reproducible reforzaría la afirmación central. Investigadores independientes podrían comparar las clasificaciones derivadas de agentes de DGrid con etiquetas de expertos y votos humanos de la Arena. Una fuerte concordancia en varias categorías de tareas respaldaría el enfoque automatizado.

Un desacuerdo considerable no lo desacreditaría automáticamente. La pregunta importante sería si DGrid identifica esa incertidumbre e impide que señales débiles controlen el enrutamiento de producción. La abstención consciente de la confianza puede ser más útil que una respuesta forzada.

El experimento perdería credibilidad si la metodología permanece opaca mientras los contadores de actividad propios siguen aumentando. Más votos no resuelven el sesgo correlacionado. Pueden amplificarlo.

La segunda señal es la composición de la participación en la Arena. DGrid debería revelar la distribución de modelos jueces, proveedores, categorías de tareas, regiones y participantes recurrentes sin exponer información privada.

Un grupo diverso de jueces reforzaría el argumento de que los agentes onchain añaden perspectivas independientes. La concentración en torno a un proveedor o una estrategia de recompensas lo debilitaría. Lo mismo se aplica a prompts generados a partir de una familia limitada de modelos que formulan preguntas.

La participación humana sigue siendo relevante aquí. La AI Arena pública de DGrid permite a las personas comparar respuestas anónimas junto con evaluadores agentes. La relación entre esos dos flujos de votos importa más que su total combinado.

La plataforma debería informar dónde coinciden humanos y agentes, dónde divergen y qué lado predice mejor la satisfacción posterior de los usuarios. Eso convertiría su diseño híbrido en una ventaja empírica.

La tercera señal es el rendimiento del enrutamiento en producción. DGrid debe demostrar que los datos de preferencias mejoran las solicitudes reales en comparación con líneas de base más simples. Esas líneas de base deberían incluir la selección manual de modelos, reglas estáticas, elección aleatoria entre modelos cualificados y un router automático centralizado.

Las mediciones útiles incluyen el éxito de la tarea, la tasa de corrección, la latencia, la frecuencia de alternativas y las anulaciones de los usuarios. El costo puede formar parte de la comparación sin reducir la calidad a la respuesta disponible más barata.

Un ensayo controlado podría enrutar solicitudes similares mediante políticas diferentes y después evaluar los resultados utilizando tanto pruebas objetivas como revisores a ciegas. El resultado debería identificar qué cargas de trabajo se benefician, en lugar de presentar una única cifra de mejora universal.

Aquí es donde el gateway y la Arena de DGrid se conectan o siguen siendo productos separados. El gateway anuncia acceso a más de 200 modelos y enrutamiento inteligente. La Arena afirma que los votos entrenan decisiones de enrutamiento más inteligentes.

DGrid aún no ha publicado suficiente evidencia independiente para establecer en qué medida esos votos mejoran la selección en tiempo real. El vínculo que falta es una comparación medida de antes y después utilizando cargas de trabajo divulgadas.

La visibilidad de CertiK puede añadir escrutinio, pero no debería confundirse con una auditoría del método de evaluación. El perfil de DGrid en CertiK ha incluido información sobre seguridad y madurez, al tiempo que indica que no había disponible una auditoría de código de CertiK en el perfil indexado. La monitorización de seguridad y la validación de la calidad de los modelos son evaluaciones distintas.

El mercado en general también ofrecerá una prueba. Los servicios de enrutamiento centralizados pueden actualizarse rápidamente, usar datos privados de producción y evitar la sobrecarga de blockchain. DGrid debe demostrar que la participación abierta y la identidad rastreable crean información que esos sistemas no pueden recopilar con la misma eficacia.

Si DGrid publica mejoras reproducibles, demuestra diversidad de jueces y conecta las preferencias de la Arena con mejores resultados de producción, su experimento respaldará un nuevo modelo de enrutamiento. Los agentes onchain servirían entonces como contribuyentes responsables, en lugar de identidades blockchain decorativas.

Si esas señales no aparecen, el proyecto aún podría operar una plataforma de recompensas activa. No habrá demostrado que los votos de los agentes seleccionan mejores modelos.

Los lectores que lleguen a través de Google News deberían observar la cadena de evidencia, no el titular sobre participación. ¿Puede DGrid mostrar quién juzgó, cómo se controló el sesgo y si las aplicaciones recibieron mejores respuestas? Esas tres preguntas decidirán si esto se convierte en infraestructura de IA útil o en otro ciclo de evaluación autorreferencial.