Las búsquedas de Anthropic Simon se encuentran con smevals, una apuesta más pequeña por la evaluación de IA

Simon Willison lanzó smevals tras años de experimentos con evaluaciones, creando un nuevo contraste con las orientaciones más formales de Anthropic para probar agentes de IA. La conexión anthropic simon importa porque ambas partes ahora hacen hincapié en el mismo problema. La puntuación de un modelo dice poco si los equipos no prueban también los prompts, las herramientas, las instrucciones del sistema y el arnés que rodea a ese modelo.

Willison creó smevals con el laboratorio de investigación de IA aplicada Prime Radiant de Jesse Vincent. El proyecto ejecuta pequeños conjuntos de evaluaciones en múltiples configuraciones, califica sus resultados y genera informes para una inspección más detallada.

El lanzamiento cuestiona una suposición común sobre la evaluación de IA. Los equipos no siempre necesitan una gran plataforma de benchmarks antes de poder plantear una pregunta útil. Necesitan una tarea concreta, configuraciones reproducibles, comprobaciones explícitas y suficiente visibilidad para entender los fallos.

Esto convierte la principal competencia en algo más pequeño y práctico que Anthropic frente a otro proveedor de modelos. Se centra en la evaluación local y acotada frente a una infraestructura de evaluación generalizada y pesada. La primera favorece la velocidad y la capacidad de inspección, mientras que la segunda admite experimentos más amplios y entornos más complejos.

Lo que smevals cambió para las pequeñas evaluaciones de IA

smevals convierte una pregunta específica de producto en un directorio portátil de tareas, configuraciones y reglas de calificación.

Willison anunció smevals el 31 de julio de 2026. Su resumen de smevals lo describe como una herramienta para ejecutar pequeños conjuntos de evaluaciones en distintas configuraciones de modelos y calificar los resultados obtenidos.

El flujo de trabajo básico comienza con uvx smevals docs. Ese comando proporciona a un agente de programación la documentación del proyecto, lo que le permite estudiar el formato antes de crear un conjunto de evaluaciones.

Este enfoque trata la documentación como contexto operativo. En lugar de pedir a los usuarios que memoricen cada campo de configuración, el proyecto espera que un agente de programación lea las instrucciones y ayude a crear los archivos.

Una evaluación vive entonces dentro de un directorio que contiene archivos YAML. YAML es un formato de datos legible por humanos que suele utilizarse para la configuración. Esos archivos describen la pregunta, las tareas, las configuraciones de modelos y el comportamiento de calificación.

Un usuario puede ejecutar el mismo conjunto frente a varios modelos. El ejemplo de Willison compara configuraciones de GPT y Claude especificadas por nombre mediante argumentos -m repetidos.

Esa estructura de comandos es importante. Plantea la elección del modelo como una variable dentro de un experimento más amplio, en lugar de tratar el modelo como el producto completo.

smevals también separa la ejecución de la calificación. El comando run registra lo que ocurrió cuando una configuración intentó una tarea. El comando grade aplica posteriormente comprobaciones definidas a esos resultados registrados.

Esa separación crea un límite de auditoría útil. Los equipos pueden conservar el comportamiento sin procesar, revisar su lógica de calificación y examinar cómo una rúbrica diferente cambia la interpretación.

La herramienta ofrece dos vías de informes. El comando serve inicia una interfaz web local, mientras que build produce HTML estático que puede alojarse en otro lugar.

Willison demostró el flujo de trabajo con una evaluación de haikus. El informe verificaba si los modelos producían exactamente tres líneas no vacías y clasificaba las configuraciones mediante las calificaciones resultantes.

Un benchmark de haikus es deliberadamente modesto. Aun así, ilustra un principio serio de evaluación: los requisitos definidos de forma estrecha suelen revelar diferencias que las puntuaciones amplias de preferencia no pueden explicar.

El lanzamiento también introduce un vocabulario coherente. Una evaluación contiene tareas, mientras que una configuración define el modelo y otras variables bajo examen.

Una ejecución registra una configuración intentando una tarea. Un calificador produce una nota al aplicar comprobaciones, incluidas comprobaciones deterministas o scripts de verificación personalizados.

Esas comprobaciones personalizadas pueden inspeccionar cadenas, validar formatos como XML o llamar a otro modelo para emitir un juicio. Esta variedad permite que un mismo conjunto combine restricciones objetivas con evaluaciones de calidad más subjetivas.

Nada en ese flujo de trabajo establece que smevals sea un producto de Anthropic. La asociación anthropic simon procede del interés coincidente en la evaluación de agentes y las configuraciones de Claude, no de la propiedad corporativa.

Por tanto, el cambio inmediato es la accesibilidad. Un desarrollador puede ahora empaquetar una pequeña pregunta de evaluación sin adoptar primero un servicio de evaluación extenso ni crear un panel personalizado.

Por qué el interés en Anthropic Simon se centra ahora en el arnés

El modelo ya no es la única unidad significativa de comparación porque el arnés de agente que lo rodea puede cambiar el resultado.

Anthropic define un arnés de agente como el sistema que procesa entradas, coordina llamadas a herramientas y devuelve resultados. Su guía de evaluación de agentes distingue esa capa del arnés de evaluación que ejecuta y califica experimentos.

Esta distinción ayuda a explicar por qué smevals admite configuraciones que van más allá de un nombre de modelo. Una configuración también puede incluir distintos prompts de sistema, parámetros de modelo o arneses de agentes.

Supongamos que dos productos de programación usan el mismo modelo subyacente. Uno proporciona al modelo mejor contexto del repositorio, mientras que el otro ofrece herramientas más potentes y comprobaciones de finalización más claras.

Un benchmark centrado solo en el modelo trataría esos sistemas como equivalentes. Una evaluación a nivel de configuración puede mostrar que su comportamiento real difiere.

La presión recae sobre los equipos de productos de IA que todavía seleccionan modelos basándose únicamente en rankings públicos. Esas clasificaciones pueden ayudar a acotar opciones, pero rara vez reproducen los prompts, herramientas, permisos y datos exactos de un producto.

El comportamiento de un agente también se desarrolla en múltiples pasos. Un sistema puede llamar a una herramienta, modificar el estado, interpretar el resultado y decidir si continúa.

Un error temprano puede afectar a cada acción posterior. Eso hace que evaluar un agente sea distinto de comprobar si un chatbot respondió correctamente a una sola pregunta.

La guía de Anthropic indica que los equipos evalúan conjuntamente el modelo y el arnés de agente cuando evalúan un agente. Esa visión coincide estrechamente con el modelo de configuración que utiliza smevals.

Este solapamiento es la verdadera historia de anthropic simon. Ambos enfoques desplazan la atención de la inteligencia aislada del modelo hacia el sistema completo que experimentan los usuarios.

El momento también refleja un problema operativo creciente. Los modelos, los prompts y los arneses cambian de forma independiente, pero los equipos de producto aún necesitan identificar qué causó una regresión.

Un nuevo modelo puede mejorar el razonamiento mientras cambia el estilo de salida. Un prompt de sistema revisado puede reducir la verbosidad, pero debilitar el seguimiento de instrucciones. Una actualización del arnés puede exponer mejores herramientas e introducir errores de estado.

Sin configuraciones controladas, esos cambios se entrelazan. Los equipos perciben que un producto se comporta de forma diferente, pero no pueden atribuir la diferencia con confianza.

Anthropic describe esta situación como operar sin suficiente visibilidad. Los equipos esperan las quejas de los usuarios, reproducen fallos manualmente, corrigen un problema y se arriesgan a crear otra regresión.

smevals ofrece una respuesta más pequeña al mismo problema. No pretende reproducir todas las condiciones de producción. Ofrece a los equipos una forma estructurada de aislar una pregunta antes de ampliar el experimento.

Esto importa para el trabajo intensivo en conocimiento. Un equipo de ingeniería podría probar si un asistente encuentra la especificación interna correcta antes de generar código.

La prueba podría comparar dos prompts de recuperación, dos versiones de modelo o dos políticas de herramientas. Los equipos que mantienen una base de conocimiento consultable afrontan preguntas similares cada vez que cambia el acceso a documentos.

La comparación resultante es más útil que preguntar qué modelo es el mejor. Pregunta qué configuración completa realiza una tarea definida bajo condiciones establecidas.

El mecanismo es la separación, no una puntuación más inteligente

smevals gana claridad al mantener las tareas, la ejecución, la calificación y los informes lo bastante separados como para inspeccionarlos de forma independiente.

Muchos productos de evaluación prometen una única puntuación que facilita la comparación. Esa conveniencia puede ocultar las decisiones que produjeron la puntuación.

smevals adopta una vía más descompuesta. La evaluación plantea la pregunta más amplia y cada tarea presenta un desafío específico.

Las configuraciones describen entonces los sistemas que intentan esas tareas. Una ejecución captura el intento, mientras que un calificador evalúa el resultado guardado mediante una o más comprobaciones.

Esta arquitectura suena a pruebas convencionales porque gran parte de ella sigue la lógica de las pruebas convencionales. Las entradas, las condiciones, las salidas, las aserciones y los informes siguen siendo conceptos reconocibles.

El comportamiento de los modelos de lenguaje complica cada componente. El mismo prompt puede producir respuestas diferentes, mientras que varias respuestas distintas pueden satisfacer al usuario.

Por tanto, una comprobación útil debe ajustarse al requisito. La coincidencia exacta de cadenas sirve para un token fijo, pero funciona mal cuando varias formulaciones son válidas.

Las comprobaciones estructurales ofrecen otra opción. Un equipo puede validar JSON, XML, recuentos de líneas, secciones obligatorias o archivos creados dentro de un entorno de agente.

Los calificadores basados en modelos manejan cualidades menos deterministas. Otro modelo puede evaluar si una respuesta sigue una rúbrica, incluye el razonamiento necesario o cumple un requisito de estilo.

Sin embargo, un juez de IA no convierte una cuestión subjetiva en una verdad objetiva. Introduce otro modelo, prompt y conjunto de supuestos en la evaluación.

Separar la calificación de la ejecución facilita investigar esa limitación. Un equipo puede conservar las mismas ejecuciones y comparar varios métodos de calificación sin pagar por cada tarea de nuevo.

También puede inspeccionar discrepancias. Si un comprobador de formato aprueba mientras un juez de IA suspende, el informe revela dos dimensiones distintas en lugar de promediarlas de inmediato.

La capa de informes importa por la misma razón. Las puntuaciones agregadas ayudan a los lectores a revisar los resultados, pero las ejecuciones individuales revelan por qué una configuración tuvo éxito o falló.

El ejemplo de haikus de Willison ilustra este equilibrio. Una clasificación ofrece el resumen, mientras que las ejecuciones recientes, los detalles de las tareas, las etiquetas y la información del calificador exponen la evidencia subyacente.

El HTML estático añade otra ventaja práctica. Un equipo puede publicar un resultado sin mantener un servicio de evaluación activo.

El punto de entrada uvx también reduce la fricción de configuración. Según la guía oficial de herramientas de uv, uvx ejecuta una herramienta empaquetada dentro de un entorno temporal aislado.

Ese diseño es adecuado para investigaciones breves. Un desarrollador puede probar el comando sin que una instalación global persistente sea el primer requisito.

El flujo de trabajo con agentes de programación reduce otro coste de configuración. El agente puede leer la documentación del proyecto, proponer archivos YAML y ayudar a perfeccionar la prueba.

La revisión humana sigue siendo necesaria. Un conjunto generado por un agente puede codificar expectativas vagas, omitir casos difíciles o crear comprobaciones que simplemente recompensen sus propios supuestos.

Por tanto, la herramienta no elimina el diseño de evaluaciones. Acorta la distancia entre una pregunta y la primera versión ejecutable de esa pregunta.

Esa diferencia importa. Los equipos suelen posponer la evaluación porque su primer paso imaginado incluye bases de datos, paneles, sistemas de trazabilidad y un gran conjunto de datos de referencia.

smevals propone un primer paso más acotado: codificar una incertidumbre real y ejecutarla en unas pocas configuraciones controladas.

Los pequeños conjuntos de evaluaciones desafían a los frameworks pesados

El principal argumento a favor de smevals no es la amplitud de funciones, sino la capacidad de empezar con una pregunta delimitada y conservar la evidencia.

El mercado de evaluación ya incluye marcos abiertos más amplios. La plataforma Inspect del Instituto de Seguridad de IA del Reino Unido admite conjuntos de datos, solucionadores, evaluadores, agentes, entornos aislados, proveedores de modelos y transcripciones detalladas.

Su documentación de Inspect presenta una tarea como la combinación de un conjunto de datos, un solucionador y un evaluador. El solucionador puede realizar una llamada a un modelo u operar un agente de varios turnos con herramientas.

Inspect también admite evaluaciones de seguridad complejas y entornos de ejecución aislados. Estas capacidades encajan con organizaciones que ejecutan benchmarks formales o prueban agentes que modifican estados externos.

Promptfoo aborda el problema desde las pruebas de prompts y aplicaciones. Su formato de configuración abarca proveedores, prompts, casos de prueba, aserciones y variables.

El espacio de trabajo oficial de evaluación muestra cómo YAML puede definir proveedores, prompts y comportamientos esperados. Esto convierte a Promptfoo en una comparación relevante para equipos que ya tratan los prompts como código verificable.

smevals entra en este ámbito con un alcance declarado más reducido. Su ventaja depende de que ese alcance limitado siga siendo coherente a medida que los usuarios soliciten más funciones.

Una suite enfocada puede ser más fácil de revisar. Cada tarea puede relacionarse directamente con una decisión de producto, y cada configuración puede representar un cambio que un equipo realmente podría lanzar.

Ese enfoque también mejora el análisis de fallos. Una prueba nombrada en torno a una necesidad concreta del usuario informa más a los desarrolladores que una categoría abstracta de capacidad.

Pensemos en un asistente que prepara actualizaciones semanales de producto. Una suite pequeña podría comprobar si cita las notas de reunión correctas, distingue las decisiones de las propuestas y evita afirmaciones sin respaldo.

Las configuraciones podrían variar el prompt de recuperación, el modelo y la herramienta de selección de documentos. Los evaluadores podrían comprobar la presencia de citas, la identidad de las fuentes y la coherencia factual.

Un benchmark público no respondería a esa pregunta de producto. Carece de los documentos del equipo, el flujo de trabajo esperado y la definición de una actualización útil.

Los marcos más complejos siguen siendo valiosos cuando el propio entorno requiere simulación. Los agentes de navegador, de programación y los sistemas de atención al cliente a menudo necesitan tareas con estado y bases de datos o entornos aislados reproducibles.

Las suites YAML pequeñas no recrean automáticamente esas condiciones. Necesitan ejecutores compatibles, scripts, fixtures u otros componentes de infraestructura de pruebas.

Por eso, el principal competidor es un enfoque, no una empresa concreta. La elección está entre empezar localmente con una pregunta acotada o comenzar con infraestructura de evaluación generalizada.

Ningún enfoque gana en todos los casos. El enfoque más pequeño gana cuando el coste de configuración impide a los equipos probar cualquier cosa.

El enfoque más amplio gana cuando la prueba debe controlar un estado complejo, capturar trayectorias completas, imponer aislamiento u operar de forma continua dentro de pipelines de despliegue.

La progresión más útil puede conectar ambos. Un equipo puede descubrir casos valiosos mediante smevals y después migrar las pruebas maduras a un sistema de regresión más amplio.

Esa progresión solo funciona si los artefactos siguen siendo legibles. Las tareas, configuraciones, resultados y reglas de evaluación deben ser lo suficientemente claros para que otro ingeniero pueda reproducirlos.

smevals parece diseñado en torno a esa portabilidad, pero la adopción determinará si la convención se mantiene. Las herramientas se vuelven más difíciles de sustituir una vez que se acumulan evaluadores y ejecutores personalizados.

Por tanto, el pequeño tamaño del proyecto es tanto su argumento de venta como su prueba. Debe añadir suficiente capacidad para agentes reales sin recrear cada plataforma de evaluación compleja.

Lo que las puntuaciones aún no pueden resolver

Una suite repetible puede revelar comportamientos, pero no puede garantizar que sus tareas, evaluadores y muestras representen la realidad de producción.

La primera incertidumbre se refiere a la cobertura. Una suite compacta puede responder bien a una pregunta acotada mientras pasa por alto fallos poco frecuentes que importan más que su puntuación media.

Los equipos también pueden redactar tareas en torno a casos de éxito ya conocidos. Los agentes de programación a los que se pide generar evaluaciones pueden producir variaciones plausibles sin descubrir los casos límite sorprendentes que encuentran los usuarios reales.

Por ello, los incidentes de producción deberían retroalimentar la suite. Las quejas, trazas fallidas, tickets de soporte y revisiones manuales pueden revelar escenarios que la generación sintética de tareas pasó por alto.

La segunda incertidumbre es la falta de determinismo. Los modelos pueden producir resultados diferentes en intentos repetidos, incluso cuando la configuración parece no haber cambiado.

Una única ejecución por tarea no puede distinguir una configuración fiable de otra que simplemente tuvo éxito por casualidad. Las pruebas repetidas se vuelven esenciales cuando la variación de salida afecta a la decisión.

La guía de evaluación de Anthropic recomienda examinar las tasas de éxito en múltiples pruebas. También advierte que un modelo puede encontrar una solución válida que el evaluador no anticipó.

Eso crea un modo de fallo difícil. Un evaluador rígido puede penalizar un resultado creativo incluso cuando este sirve mejor al usuario.

El problema opuesto se produce con los evaluadores basados en modelos. Un juez de IA permisivo puede aceptar una salida fluida que incumple un requisito oculto importante.

La calibración humana ayuda a identificar estos errores. Los revisores deberían inspeccionar aprobaciones y fallos, comparar las decisiones de los evaluadores y revisar las rúbricas cuando el juez recompensa el comportamiento equivocado.

La tercera incertidumbre se refiere a la contaminación entre el sistema y el evaluador. Cuando los agentes de programación ayudan a redactar tareas, prompts y comprobaciones, sus preferencias pueden moldear el benchmark.

Usar un modelo relacionado como evaluador puede profundizar ese efecto. La prueba podría favorecer formulaciones o patrones de razonamiento familiares sin medir la utilidad real.

Esto no invalida la evaluación basada en modelos. Significa que la calificación debe seguir siendo trazable a una rúbrica, una configuración del juez y un proceso de revisión.

La cuarta cuestión es la confianza estadística. Una suite de tres tareas puede identificar una regresión evidente de formato, pero no puede respaldar afirmaciones amplias sobre la calidad de un modelo.

smevals se define como una suite de evaluación pequeña, y los lectores deberían respetar ese límite. Sus informes comparan las tareas que se ejecutaron, no todas las capacidades de los modelos implicados.

Los equipos deberían evitar convertir un resultado local en una clasificación universal. «La configuración A superó ocho casos de producto» es defendible. «El modelo A es mejor» normalmente no lo es.

Los costes y la latencia requieren una cautela similar. Una configuración con mejor puntuación puede usar prompts más largos, más llamadas a herramientas o un modo de razonamiento más lento.

Si esos factores importan para el producto, la suite debe registrarlos y compararlos. Las puntuaciones de calidad por sí solas no pueden determinar la mejor opción para lanzar.

La seguridad también cambia el diseño de la evaluación. Un agente con acceso al shell, al navegador o a una base de datos necesita entornos aislados y comprobaciones sobre el estado final.

Una transcripción puede mostrar que un agente afirmó haber tenido éxito. El resultado real depende de si creó el archivo correcto, modificó el registro previsto o evitó acciones prohibidas.

Estas limitaciones no son un argumento contra las evaluaciones pequeñas. Definen dónde una suite pequeña sigue siendo fiable.

La convergencia de anthropic simon resulta útil precisamente porque ninguno de los dos enfoques trata un número agregado como la meta final. Las ejecuciones, trazas, resultados y comportamiento de los evaluadores merecen inspección.

Tres señales mostrarán si la coincidencia entre Anthropic y Simon perdura

smevals importará más allá de su lanzamiento si los equipos lo utilizan para comparar decisiones reales de infraestructura, calibrar evaluadores y preservar evidencia repetible.

La primera señal es la variedad de suites de evaluación publicadas. El formato de Haiku demuestra el flujo de trabajo, pero los desarrolladores de agentes necesitan ejemplos que impliquen herramientas, estado y finalización en varios pasos.

Las suites que comparan solo prompts mantendrían a smevals cerca de las herramientas establecidas de pruebas de prompts. Las suites que comparan infraestructuras de programación o investigación respaldarían su posicionamiento más amplio.

La valoración se fortalece si los usuarios publican casos reproducibles de agentes con ejecuciones y comprobaciones visibles. Se debilita si los ejemplos siguen limitados a tareas breves de formato de texto.

La segunda señal es la calibración de los evaluadores. El proyecto admite comprobaciones deterministas y scripts de verificación más complejos, incluida la evaluación basada en modelos.

Ahora los usuarios necesitan métodos para comparar esas calificaciones con el juicio humano. Los informes útiles deberían mostrar los desacuerdos en lugar de ocultarlos dentro de una única puntuación.

El argumento a favor de smevals se fortalece si los equipos pueden volver a ejecutar la evaluación, inspeccionar las rúbricas y documentar por qué cambiaron los evaluadores. Se debilita si las clasificaciones se desvinculan de la evidencia subyacente.

La tercera señal es la integración con el desarrollo cotidiano. Un experimento local genera conocimiento una vez, mientras que una suite de regresión protege los cambios futuros.

Observe si los equipos ejecutan smevals tras actualizaciones de modelos, ediciones de prompts, cambios de herramientas y lanzamientos de infraestructura. Un uso repetido demostraría que las suites pequeñas pueden convertirse en activos de ingeniería duraderos.

La integración no exige que todos los equipos construyan una plataforma elaborada. Un repositorio compartido, YAML revisado, ejecuciones guardadas y una comprobación de lanzamiento coherente pueden ser suficientes.

La señal se debilita si las suites quedan obsoletas tras la comparación inicial. Un benchmark desactualizado puede generar confianza sin reflejar el producto actual.

Para desarrolladores y compradores empresariales, la acción práctica es sencilla. Identifique una decisión que actualmente se toma mediante intuición y defina la prueba más pequeña que podría cuestionarla.

Esa decisión podría implicar Claude frente a GPT, pero también podría implicar dos prompts de sistema o dos estrategias de recuperación. La configuración debería reflejar lo que realmente experimentan los usuarios.

Trate el primer resultado como evidencia, no como veredicto. Inspeccione los fallos, cuestione al evaluador, añada casos del trabajo real y repita las pruebas donde el comportamiento varíe.

La lección duradera de anthropic simon no es que una herramienta pequeña resuelva la evaluación de IA. Es que la elección de modelo, el diseño de prompts y el comportamiento de la infraestructura deben probarse conjuntamente.

¿Qué decisión de producto sigue tomando su equipo a partir de demostraciones, clasificaciones o intuición? Convierta esa incertidumbre en una suite enfocada, conserve las ejecuciones y compruebe si la evidencia cambia la respuesta.