Hay una costumbre nueva entre quienes usan inteligencia artificial todos los días: comparar modelos como antes se comparaban procesadores. GPT contra Claude. Claude contra Gemini. Una tabla de benchmarks, otra de precios, otra de contexto, y al final una conclusión que suena bastante razonable: este es más inteligente que aquel.
El problema es que cada vez usamos menos modelos desnudos. Usamos sistemas construidos alrededor de ellos.
El 21 de agosto Nvidia publicó un resultado que hace visible esa diferencia. Su arquitectura AVO completó los 183 niveles de los 25 entornos públicos de ARC-AGI-3 y obtuvo 100 puntos en la métrica RHAE usando Claude Opus 5 como modelo base. Un mes antes, ARC Prize había medido a Claude Opus 5 en 30,2% sobre el mismo benchmark público.
Treinta contra cien parece una de esas cifras diseñadas para convertirse en titular. Y, de hecho, hay que tener cuidado con ella: la propia Nvidia advierte que no se trata de una comparación controlada. Cambian el nivel de razonamiento, la representación de las observaciones y buena parte del sistema de evaluación. No podemos decir seriamente que “el harness añadió 70 puntos”.
Pero precisamente por eso el resultado es interesante. Lo que cambia no es solo una instrucción. Cambia todo lo que rodea al modelo.
Primero: qué demonios es un harness
La palabra no ayuda mucho. Harness se traduce como arnés, y en IA se usa para hablar de la capa de software que envuelve al modelo y decide cómo trabaja: qué contexto recibe, qué herramientas puede usar, qué recuerda, cómo se recupera después de un error, cuándo vuelve a intentarlo y quién —o qué— revisa si se está desviando.
Si el modelo fuera un analista muy capaz, el harness sería todo lo que hay alrededor de su escritorio. El acceso a los documentos correctos. El historial de lo que ya intentó. Excel. El navegador. Una terminal. Una libreta que sobrevive al cambio de turno. Un jefe que aparece cuando lleva dos horas insistiendo en una hipótesis que no funciona.
Quita todo eso y sigues teniendo al mismo analista. No necesariamente obtienes el mismo trabajo.
Dos aplicaciones pueden anunciar exactamente el mismo modelo y, aun así, estar vendiendo sistemas muy distintos.
Lo que Nvidia cambió alrededor de Claude
AVO —Agentic Variation Operators— no nació para resolver juegos. Nvidia lo había construido para tareas largas de ingeniería, en particular para optimizar kernels de GPU. Ahí un agente no puede limitarse a escribir una respuesta bonita. Tiene que inspeccionar código, proponer un cambio, ejecutarlo sobre hardware real, mirar qué ocurrió, conservar lo aprendido y decidir qué probar después.
En una de esas pruebas AVO trabajó durante siete días, exploró más de 500 direcciones de optimización y terminó dejando 40 versiones de kernels. Nvidia reportó mejoras de hasta 10,5% frente a FlashAttention-4 en las configuraciones evaluadas.
La cifra de rendimiento importa menos aquí que la duración. Siete días es una eternidad para un modelo que normalmente recibe una conversación, llena una ventana de contexto y se va. Mantener un proceso útil durante cientos de intentos exige resolver un problema diferente: qué recordar y qué olvidar.
AVO usa memoria persistente para arrastrar implementaciones anteriores, resultados de pruebas, salidas del compilador y del profiler. También tiene un supervisor que observa la trayectoria general y puede intervenir cuando el agente entra en ciclos poco productivos. El agente principal sigue tomando decisiones, pero no trabaja completamente solo.
Después Nvidia conectó esa misma arquitectura a ARC-AGI-3.
Un benchmark raro, y por eso útil para esta discusión
ARC-AGI-3 no presenta una pregunta y espera una respuesta. Mete al agente en pequeños entornos interactivos sin instrucciones, sin reglas explícitas y sin decirle cuál es el objetivo. Tiene que tocar cosas, mirar qué cambia, formular una hipótesis sobre el mundo y corregirla cuando se equivoca.
Es parecido a abrir un videojuego extraño sin tutorial. Pulsas una tecla. Algo se mueve. Pulsas otra. Descubres que aquello que parecía un obstáculo era una puerta. En el nivel siguiente las reglas se parecen, pero no son idénticas. Lo importante no es recordar una respuesta: es conservar una comprensión que se va construyendo.
Claude Opus 5 ya era muy bueno comparado con otros modelos cuando ARC Prize lo evaluó en julio. Su 30,2% era entonces el mejor resultado verificado de un modelo en ARC-AGI-3. Lo llamativo es que otras arquitecturas montadas sobre ese mismo Claude empezaron a comportarse de otra manera.
VISTA, un harness desarrollado por investigadores del MIT, también completó los 183 niveles públicos con Claude Opus 5 y obtuvo 100. Su estrategia era distinta: le entregaba al modelo imágenes PNG del entorno y conservaba una memoria visual sin pérdida. Prime Intellect, por su parte, publicó tres ejecuciones con Opus 5 usando Prime Agent: la ejecución mediana quedó en 95,24% RHAE y la mejor de las tres alcanzó 95,5%. Su enfoque también modifica elementos de su propia estructura de trabajo mientras avanza.
Cuando tres sistemas diferentes consiguen resultados muy distintos alrededor de un modelo que ya conocíamos, empieza a ser difícil seguir tratando el nombre del modelo como si describiera el producto completo.
Esto no significa que el modelo dejó de importar
Aquí conviene evitar el péndulo. Hace seis meses todo era “el modelo es lo único que importa”; ahora sería fácil pasar a “el modelo ya no importa”. Las dos frases son demasiado cómodas.
Un harness no fabrica capacidad de razonamiento de la nada. Si el modelo no puede interpretar una observación, utilizar una herramienta o mantener una hipótesis mínimamente coherente, añadirle memoria y un supervisor puede producir un sistema más organizado que sigue sin resolver el problema.
Y Nvidia es explícita sobre otra cosa: sus 100 puntos y los 30,2% de ARC Prize no son una ablación científica donde todo permanece idéntico excepto una variable. Su ejecución usa otra configuración de razonamiento y una interfaz textual de cuadrícula 64 x 64, mientras otros sistemas trabajan con imágenes. Además cambian memoria, administración de contexto y bucle de ejecución.
Pero ese caveat no destruye la tesis. La refuerza. Si tantas piezas cambian el resultado, entonces medir únicamente el modelo nos cuenta cada vez menos sobre el sistema que un usuario terminará usando.
La comparación que hacemos en la vida real ya está contaminada
Imaginemos que quieres decidir qué IA usar para revisar contratos. Pruebas dos productos. Ambos dicen utilizar Claude Opus 5.
En el primero subes veinte PDFs. El sistema extrae texto, crea un índice, recupera los fragmentos relevantes, conserva una memoria del expediente y obliga al modelo a citar la página de cada afirmación. Si encuentra una contradicción, ejecuta una segunda pasada antes de mostrar la respuesta.
En el segundo subes los mismos archivos, pero la aplicación mete tanto texto como puede en contexto, resume el resto y llama al mismo modelo una sola vez.
Los dos pueden poner “Powered by Claude Opus 5” en la página de precios. Compararlos diciendo “Claude contra Claude” no explica casi nada.
Algo parecido ya ocurre cuando usamos agentes para tareas de oficina. En el artículo anterior sobre IA y decisiones hablábamos de la deuda de supervisión: el tiempo que aparece después de automatizar, cuando tienes que revisar fuentes, corregir interpretaciones y averiguar por qué dos herramientas llegaron a conclusiones distintas. Parte de esa deuda puede venir del modelo. Otra parte viene de cómo fue construido el flujo alrededor de él.
Eso también explica una frustración común: cambiar a un modelo supuestamente mejor y notar que tu herramienta favorita no mejora en la misma proporción. El benchmark del modelo subió. Tu experiencia no necesariamente.
La nueva pregunta no es “qué modelo usa”, sino “qué hace con él”
Para una persona normal, “harness” puede seguir siendo una palabra innecesaria. Lo útil es convertirla en preguntas concretas.
- ¿La herramienta tiene memoria persistente o cada tarea empieza casi desde cero?
- ¿Puede buscar, ejecutar código, abrir archivos o consultar bases de datos?
- ¿Cómo decide qué información entra al contexto y cuál queda fuera?
- ¿Comprueba su propio trabajo antes de entregarlo?
- ¿Puede recuperarse cuando una estrategia falla o simplemente vuelve a intentar lo mismo con palabras distintas?
- ¿Qué parte del costo viene del modelo y qué parte de todas las llamadas adicionales que hace el sistema?
La última pregunta merece atención. Un buen harness puede mejorar resultados, pero también puede multiplicar llamadas, contexto y pasos. Prime Intellect muestra justamente curvas de costo y uso de tokens porque el problema ya no es solamente “qué tan inteligente es”, sino cuánto cuesta convertir esa inteligencia en una tarea terminada.
En otras palabras, puede existir un sistema más capaz que también sea más lento o más caro. La mejor arquitectura depende de la tarea, no del entusiasmo del benchmark.
También cambia la forma de pensar el lock-in
Hay una consecuencia empresarial menos vistosa. Hasta ahora muchas compañías han tratado el riesgo de dependencia como una pregunta de proveedor: “¿qué hacemos si mañana queremos salir de OpenAI, Anthropic o Google?”.
Pero si el rendimiento real depende cada vez más de memoria, herramientas, evaluadores, recuperación, permisos, formatos internos y lógica de supervisión, la parte difícil de mover quizá no sea el modelo. Puede ser todo lo construido alrededor.
Eso tiene dos caras. Una empresa que controla bien su propia arquitectura puede sustituir modelos con menos trauma. Otra que depende de un producto cerrado puede descubrir que “usa Claude” es apenas una fracción de lo que compró.
Curiosamente, esto puede reducir y aumentar el lock-in al mismo tiempo. Reduce la dependencia del modelo si el harness es tuyo. La aumenta si el harness pertenece al proveedor y es precisamente la razón por la que el producto funciona tan bien.
Tal vez necesitamos benchmarks de productos, no solo de modelos
Los rankings de modelos siguen siendo útiles. Nos dicen algo sobre capacidad base y permiten comparar bajo condiciones relativamente conocidas. El problema aparece cuando tomamos esa cifra y la trasladamos directamente a una aplicación real.
En una aplicación real hay búsqueda, memoria, permisos, archivos, herramientas, instrucciones del sistema, reintentos y límites de costo. A veces hay un segundo modelo revisando al primero. A veces hay código determinista haciendo la parte importante mientras el LLM solo decide cuándo ejecutarlo.
Por eso quizá la unidad que vamos a terminar comparando no sea “GPT vs. Claude vs. Gemini”, sino sistemas completos resolviendo tareas completas: cuánto tardaron, cuánto costaron, cuántas veces necesitaron intervención humana y qué hicieron cuando algo salió mal.
Eso sería bastante menos cómodo que una tabla con un número grande al lado de cada modelo. También se parecería mucho más a la forma en que realmente usamos la IA.
El modelo sigue siendo el motor. Pero ya estamos conduciendo el carro completo
El resultado de Nvidia no demuestra que Claude Opus 5 sea tres veces mejor cuando alguien le pone memoria. Tampoco demuestra que los benchmarks de modelos hayan dejado de servir.
Demuestra algo más incómodo: una parte creciente de la capacidad que atribuimos a “la IA” aparece en la interacción entre el modelo y el sistema que lo rodea.
Eso obliga a cambiar una costumbre. Cuando una nueva herramienta diga que utiliza el modelo más avanzado del mercado, la pregunta ya no debería terminar ahí.
¿Qué recuerda? ¿Qué puede hacer? ¿Cómo comprueba lo que hizo? ¿Qué ocurre cuando se equivoca? ¿Cuánto cuesta todo ese proceso? ¿Y cuánto del resultado desaparecería si mañana cambiaras el modelo y conservaras el resto?
Tal vez entonces descubramos que llevábamos meses discutiendo cuál motor era mejor sin mirar el vehículo en el que estaba montado.
Referencias
Nvidia describe la arquitectura AVO, su memoria persistente, el supervisor, los resultados en optimización de kernels y la evaluación de ARC-AGI-3. Ver el blog técnico de Nvidia.
ARC Prize publicó la evaluación verificada de Claude Opus 5 con 30,2% en ARC-AGI-3 y explica la metodología del benchmark. Ver resultados de ARC Prize.
El equipo de VISTA, del MIT, documenta cómo su harness visual con Claude Opus 5 completó los 183 niveles públicos de ARC-AGI-3. Ver VISTA.
Prime Intellect describe Prime Agent y publica tres ejecuciones con Claude Opus 5: 95,24% RHAE en la ejecución mediana y 95,5% en la mejor, además de datos de costo y uso de tokens. Ver Prime Agent.
