Evaluaciones de Claude Opus 4.5: qué comparan las pruebas y hasta dónde permiten concluir

Una puntuación solo tiene sentido junto a su protocolo

Las evaluaciones de modelos de lenguaje no miden una capacidad única. Una prueba puede examinar la resolución de tareas de programación con un agente y herramientas; otra, el rendimiento en una suite interna; una tercera, la respuesta a preguntas de conocimiento. Aunque todas publiquen una cifra o una posición, no se sigue que midan lo mismo ni que permitan ordenar los modelos de manera intercambiable. Para interpretar una puntuación hacen falta, como mínimo, la tarea, el conjunto evaluado, la métrica y las condiciones de ejecución.

En el caso de Claude Opus 4.5, las fuentes proporcionadas identifican varios tipos de material: una comunicación de Anthropic que menciona pruebas con Junie, la System Card del modelo, un trabajo independiente sobre modelos como agentes IDE y una ficha agregadora de benchmarks. También se propuso revisar un análisis de Artificial Analysis, pero entre las fuentes verificadas proporcionadas no hay una página de esa organización. Por tanto, no es posible documentar aquí el método ni la posición que se le atribuye en ese análisis.

La evidencia disponible permite describir el alcance general de algunos documentos y señalar qué información habría que comprobar en sus versiones completas. No basta, en cambio, para reconstruir protocolos completos, verificar cada resultado o establecer una clasificación global. Esta distinción no es un juicio sobre la calidad del modelo: es un límite de lo que se puede sostener con los materiales disponibles.

Qué aportan las fuentes localizadas

La página oficial de Anthropic sobre Claude Opus 4.5 es una fuente del proveedor. El fragmento disponible afirma que, según pruebas con Junie, su agente de programación, Opus 4.5 supera a Sonnet 4.5 en los benchmarks mencionados en esa comunicación y necesita menos pasos para resolver tareas. Sin embargo, el material proporcionado no enumera esos benchmarks ni detalla las tareas, el número de ejecuciones, las herramientas activas o el criterio exacto de «menos pasos». Por eso, la afirmación debe presentarse como una declaración de Anthropic, no como una comparación independiente con protocolo reconstruido.

La nota de verificación de esa misma página añade una referencia a GitHub Copilot, mientras que el fragmento citado menciona Junie. Los datos suministrados no permiten determinar si se trata de partes distintas de la página, de una descripción imprecisa o de una discrepancia en el registro. Conviene revisar la página íntegra antes de describir con precisión el entorno utilizado. No se debe resolver esa ambigüedad suponiendo que Junie y GitHub Copilot formaron parte del mismo ensayo.

La System Card de Anthropic es un documento institucional original. La información aportada indica que compara Opus 4.5 con otros modelos en una suite de tareas, pero no incluye los nombres de las pruebas, las métricas ni las condiciones concretas. La existencia de una comparación en el documento no basta para afirmar que todas las tareas representen programación o uso de agentes: esa caracterización requiere comprobar el contenido íntegro.

El trabajo localizado en arXiv trata la evaluación de modelos como agentes IDE en entornos reales y, según la nota disponible, menciona variabilidad en el caso de Opus 4.5. El resumen proporcionado no identifica las tareas concretas, el conjunto de modelos, el harness, el número de ejecuciones ni el cálculo de esa variabilidad. En particular, no permite verificar el valor de desviación estándar de 0,027 planteado en las preguntas de revisión, ni saber a qué métrica o conjunto de resultados se aplicaría.

Por último, BenchLM presenta una ficha agregada que atribuye a Opus 4.5 una posición y una puntuación global calculadas a partir de filas de resultados que la propia ficha muestra. Es una fuente secundaria de agregación, no una descripción primaria de los protocolos originales. Sin conocer cómo se seleccionan, normalizan y combinan las filas, esa puntuación no debe tratarse como una medida universal de capacidad.

Pruebas con Junie: una afirmación del proveedor, no un protocolo completo

El fragmento de Anthropic es útil para identificar una afirmación concreta: en pruebas realizadas con Junie, Opus 4.5 habría superado a Sonnet 4.5 en los benchmarks mencionados y habría necesitado menos pasos para resolver tareas. La formulación pertenece a Anthropic y debe atribuirse como tal. Con el material proporcionado no se pueden confirmar los conjuntos de evaluación, el tamaño de la muestra ni si cada modelo recibió idéntico contexto, herramientas y presupuesto.

«Menos pasos» tampoco equivale por sí solo a mejor rendimiento general. Para interpretar esa medida habría que saber qué cuenta como paso, si se penalizan los intentos fallidos o el uso de herramientas, si las tareas deben completarse correctamente y cómo se trata una solución parcial. Una menor cantidad de interacciones podría ser relevante en un entorno concreto, pero no informa automáticamente sobre coste, latencia, fiabilidad o calidad del código.

La página sobre Opus 4.5 también aparece asociada en las notas a GitHub Copilot. Como no se aporta el texto íntegro que explique esa referencia, no es posible determinar si describe otro contexto de evaluación, una integración o una tarea diferente. Una auditoría rigurosa mantendría separadas ambas menciones hasta revisar sus condiciones, en lugar de fundirlas en un único experimento.

System Card: un documento pertinente, con detalles aún no verificados

La System Card de Claude Opus 4.5 es una fuente primaria del proveedor y, por ello, es el lugar apropiado para comprobar qué evaluaciones decidió publicar Anthropic y cómo las presenta. La nota de verificación disponible solo confirma que el documento compara Opus 4.5 con otros modelos en una suite de tareas. No proporciona los nombres de las tareas ni permite reconstruir los resultados por categoría.

Para interpretar esa suite habría que revisar, prueba por prueba, qué capacidad intenta medir, qué modelos se comparan y qué métrica se usa. También habría que determinar si los modelos recibieron el mismo formato de instrucciones, herramientas y presupuesto. Si la System Card informa resultados en tareas distintas, no conviene resumirlos como si constituyeran una sola medida de «inteligencia» o de rendimiento en programación.

La documentación de la plataforma de Anthropic identifica una página de descripción de Opus 4.5 que puede servir para verificar información sobre identificadores y límites del modelo. Sin embargo, la nota suministrada no incluye el identificador exacto, los límites concretos ni una relación entre esa documentación y las ejecuciones de cada benchmark. En consecuencia, no cabe afirmar que los ensayos citados emplearan una configuración determinada hasta comprobar los documentos completos y la correspondencia entre versión y prueba.

Evaluación independiente de agentes IDE: qué falta para interpretar la variabilidad

El artículo localizado en arXiv aporta una perspectiva distinta de las comunicaciones del proveedor: estudia modelos como agentes IDE en entornos reales. La nota de verificación señala que aborda variabilidad en los resultados de Opus 4.5. Esa diferencia de procedencia es relevante, pero no basta para valorar la independencia metodológica ni para comparar sus cifras con las de Anthropic. Para ello hay que inspeccionar el método completo, los datos y el procedimiento de evaluación.

La variabilidad solo es interpretable si se conoce qué resultado se repite y bajo qué condiciones. Una desviación estándar puede describir diferencias entre ejecuciones, tareas, instancias o alguna otra unidad; cada elección cambia su significado. El material disponible no confirma qué representa el valor 0,027 mencionado en las preguntas de verificación, cuántas ejecuciones lo sustentan ni si se calcula sobre una métrica de éxito, una puntuación u otra variable. Por tanto, no se debe presentar ese valor como un resultado verificado.

También es necesario distinguir variación entre ejecuciones del modelo y variación entre tareas. Un agente puede obtener resultados similares en repeticiones de una tarea y, a la vez, rendir de forma muy desigual entre tareas distintas. Para separar ambos fenómenos hacen falta, al menos, el número de tareas y repeticiones, la unidad estadística, la definición de la métrica y el método para agregar resultados.

El rótulo «entornos reales» tampoco especifica por sí mismo qué condiciones se reprodujeron. Para saber qué cubre la prueba habría que verificar los repositorios o proyectos, las instrucciones, el acceso a terminal y herramientas, los límites de tiempo o de interacción, y cómo se juzga que un cambio resuelve el problema. Las notas aportadas no detallan esos elementos, así que la evaluación no puede usarse aquí para afirmar que representa el uso cotidiano de todos los equipos de desarrollo.

Artificial Analysis y agregadores: una posición no sustituye a la metodología

La propuesta editorial plantea verificar el Omniscience Index de Artificial Analysis y la posición atribuida a Opus 4.5. Sin embargo, la lista de fuentes verificadas no incluye una página de Artificial Analysis. Por ese motivo, no se puede afirmar qué mide ese índice, cuál es su método, qué resultado asigna al modelo ni bajo qué configuración se habría obtenido. La cuestión debe quedar abierta hasta disponer y revisar la fuente correspondiente.

La ficha de BenchLM sí está entre los materiales localizados. Su nota informa de una posición, una puntuación global y un conjunto de filas que la página presenta como resultados de benchmarks. Esos datos describen lo que publica el agregador, no validan por sí solos la selección de pruebas ni la operación de combinar resultados diferentes. Para interpretar una posición se necesitarían las reglas de normalización, ponderación, inclusión de fuentes y actualización de cada fila.

Una clasificación agregada puede ser útil para explorar resultados o localizar pruebas, pero no debe presentarse como una medida neutral de capacidad general sin justificar cómo se construye. Si una puntuación reúne tareas heterogéneas, un cambio de selección o de peso puede cambiar la posición. Además, sin trazabilidad hasta las publicaciones originales no se puede comprobar si las condiciones de todas las filas son comparables o si se refieren a la misma versión del modelo.

Comparabilidad, contaminación y reproducibilidad

Dos resultados pueden compararse directamente solo si sus condiciones son suficientemente equivalentes para la pregunta que se quiere responder. En evaluaciones de agentes IDE eso implica revisar, entre otros aspectos, el modelo exacto y su versión, el nivel de razonamiento, las instrucciones, las herramientas disponibles, el harness que conecta el modelo con el entorno y los límites de ejecución. Las fuentes resumidas no aportan estos datos para todas las pruebas citadas, por lo que no es posible establecer equivalencia entre ellas.

La contaminación de conjuntos de evaluación requiere una revisión específica. Para estimar ese riesgo habría que saber cómo se construyeron las tareas, cuándo se incorporaron, si sus soluciones o enunciados pudieron aparecer en datos de entrenamiento y qué controles aplicaron los autores. Las notas de las fuentes proporcionadas no describen controles o análisis de contaminación para la System Card, las pruebas con Junie, el estudio de agentes IDE ni la agregación de BenchLM. Esto significa que el riesgo no queda evaluado aquí; no significa que se haya demostrado contaminación.

La reproducibilidad también depende de más que publicar una puntuación. Resultan útiles los prompts, los datos de evaluación, el código del harness, la configuración del modelo, los criterios de puntuación y los registros de ejecución. Si alguno de esos elementos no se publica, debe explicarse qué parte del resultado no puede repetirse o inspeccionarse de forma independiente. Con los resúmenes disponibles no se puede confirmar qué materiales acompañan a cada documento ni si bastan para reproducirlo.

Estas carencias deben tratarse como cuestiones pendientes de verificación, no como defectos probados de las evaluaciones. Una revisión posterior de los documentos completos podría aportar los detalles que no aparecen en las notas. Hasta entonces, la opción rigurosa es mantener separados los resultados, atribuir cada afirmación a su fuente y evitar inferencias sobre una posición general.

Conclusiones acotadas

Con las fuentes y notas verificadas se puede afirmar que Anthropic comunica resultados favorables de Opus 4.5 frente a Sonnet 4.5 en pruebas asociadas a Junie; que la System Card compara Opus 4.5 con otros modelos en una suite de tareas; que existe un estudio independiente sobre modelos como agentes IDE que menciona variabilidad para Opus 4.5; y que BenchLM publica una puntuación y una posición agregadas. Cada afirmación corresponde a una fuente y a un tipo de evidencia diferente.

No se pueden reconstruir con este material los protocolos completos ni determinar si las pruebas utilizan el mismo identificador de modelo, herramientas, presupuesto, harness o métrica. Tampoco se pueden verificar el valor y la interpretación de la desviación estándar planteada, los controles de contaminación, la disponibilidad de materiales reproducibles ni la metodología de Artificial Analysis. En consecuencia, las puntuaciones no forman una clasificación común y no justifican una conclusión global sobre qué modelo es mejor.

Para un equipo que evalúa Opus 4.5 en programación o agentes IDE, la decisión práctica es pedir o consultar la documentación de la prueba que se parezca a su propio flujo de trabajo. Hay que comparar tareas equivalentes, medir calidad y tasa de finalización, contabilizar coste y latencia, y observar variación entre repeticiones. Si la metodología no está publicada, esa limitación debe figurar junto al resultado y la decisión no debería descansar en una posición agregada aislada.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.