Claude Opus 4.5: cómo atribuir una mejora en tareas largas al modelo y no al arnés

La pregunta no es qué modelo gana, sino qué cambió

Claude Opus 4.5 puede aparecer como una mejora clara en un flujo de programación, investigación documental o resolución operativa de varios pasos. Sin embargo, el resultado final de un agente no pertenece exclusivamente al modelo. Depende de una configuración completa: la versión e identificador del modelo, el prompt de sistema, el contexto recuperado, las herramientas autorizadas, la política de planificación, el límite de acciones, los reintentos, el presupuesto de razonamiento, el criterio de parada y el verificador que acepta o rechaza la respuesta.

Por ello, sustituir un modelo en un producto y observar una tasa de éxito superior no basta para concluir que la diferencia sea causada por Claude Opus 4.5. Puede haber coincidido con un corpus de recuperación renovado, una herramienta más fiable, más turnos permitidos, una selección entre varias muestras o una modificación del evaluador. También puede haber cambiado el perfil de casos recibido por el sistema. La atribución exige convertir una impresión de mejora en una comparación controlada.

Esta pieza no pretende establecer un ganador general frente a otros modelos ni trasladar sin más resultados publicados a una aplicación propia. Su objetivo es más limitado y operativo: determinar qué evidencia permite afirmar que Claude Opus 4.5 aporta una mejora desplegable en una tarea concreta, bajo una configuración declarada y con riesgos aceptables.

La unidad real de evaluación es una configuración, no una etiqueta de modelo

Decir que una ejecución usa «Claude Opus 4.5» describe una parte insuficiente del experimento. La documentación de Anthropic identifica el modelo de su API directa con un identificador específico. La documentación de Amazon Bedrock muestra un identificador distinto para el mismo modelo ofrecido mediante ese canal, y la documentación de Google Cloud presenta otro formato de identificación. Estas diferencias no demuestran capacidades distintas por sí mismas, pero sí impiden tratar el nombre comercial como una especificación técnica completa.

Antes de comparar resultados, conviene construir un contrato de ejecución inmutable. Debe incluir proveedor y región cuando afecten al servicio, identificador exacto, fecha de prueba, interfaz utilizada, modalidades habilitadas, parámetros de generación, presupuesto de razonamiento si se usa, límite de salida y política de manejo de errores. Si el flujo es agentivo, el contrato debe añadir el prompt de sistema, las versiones de herramientas, sus descripciones, permisos, límites de pasos, estrategia de recuperación y criterio de finalización.

El propósito no es burocrático. Sin ese contrato, un resultado no es reproducible ni diagnosticable. Si una semana después cae el rendimiento, el equipo no podrá distinguir una variación de datos de una modificación del prompt, una cuota más restrictiva, una herramienta degradada o un cambio efectivo del modelo disponible en el canal elegido.

Las capas que suelen confundir la atribución

El primer factor de confusión habitual es el contexto. Un sistema de recuperación puede cambiar el número de documentos entregados, la calidad de los fragmentos, la consulta de búsqueda, el modelo de embeddings o el orden de las fuentes. Si Claude Opus 4.5 recibe una evidencia más completa que la línea base, la evaluación está midiendo una intervención combinada. En investigación documental, conviene conservar también el conjunto de documentos recuperados y no sólo la respuesta final.

El segundo es el arnés de herramientas. Un agente que puede consultar código, ejecutar pruebas, buscar incidencias o aplicar cambios reversibles no se comporta como un modelo en conversación aislada. Una nueva descripción de herramienta, una llamada adicional permitida o una política de reintento más tolerante puede tener un efecto mayor que la sustitución del modelo. La tasa de éxito debe desglosarse por acciones, errores de herramienta, reintentos y casos resueltos sin intervención.

El tercero es la selección. Elegir la mejor de varias respuestas, votar entre muestras o pedir a otro modelo que revise la salida puede aumentar la calidad agregada. Esas técnicas pueden ser apropiadas, pero deben figurar como parte de la solución evaluada. No deben presentarse como una capacidad pass@1 del modelo. La misma cautela aplica a un verificador que acepta respuestas parcialmente correctas o que comparte sesgos con el generador.

Por último, el coste computacional forma parte de la explicación. Una mejora obtenida con más pasos, más tokens de razonamiento, más llamadas a herramientas o más candidatos no equivale necesariamente a una mejora eficiente. Puede ser una decisión válida si reduce de forma material la revisión humana o el riesgo operacional, pero requiere medir el coste por caso correctamente resuelto, no sólo el coste medio por solicitud.

Qué pueden indicar las evaluaciones oficiales y qué no prueban

El anuncio de Anthropic sobre Claude Opus 4.5 declara detalles metodológicos para las evaluaciones que comunica, incluidos presupuestos de pensamiento, contexto, niveles de esfuerzo, parámetros de muestreo, repeticiones independientes y excepciones según la prueba. Esa información es relevante porque permite interpretar un resultado publicado como el producto de un protocolo, no como una propiedad descontextualizada del modelo.

La tarjeta de sistema del proveedor aporta información adicional sobre evaluaciones de capacidad y seguridad, así como sobre el enfoque de despliegue. Estas fuentes son útiles para conocer el alcance declarado por quien desarrolla el modelo y para formular hipótesis de prueba. No sustituyen una validación en el repositorio, corpus, herramientas y criterios de riesgo de cada organización.

Al leer cualquier benchmark, el equipo debería preguntar si se midió una respuesta única o una selección entre varias, si hubo herramientas, qué contexto se proporcionó, cómo se puntúa una abstención y si el presupuesto de ejecución fue comparable. Una puntuación puede ser informativa sin ser transferible. En particular, una tarea cerrada con un verificador automático puede no representar una operación abierta donde importan la trazabilidad de la evidencia, los permisos y la reversibilidad de las acciones.

Protocolo de atribución para flujos largos

El protocolo comienza definiendo la decisión que se quiere tomar. Por ejemplo: permitir que el agente proponga correcciones de código para revisión humana, dejar que clasifique expedientes con abstención obligatoria o ampliar el número de casos que puede investigar sin escalado. La métrica principal debe corresponder a esa decisión y no a una medida fácil pero desconectada, como la longitud de la respuesta.

Después se construye una línea base reproducible. Puede ser el modelo actualmente desplegado o una configuración previa de Claude Opus 4.5, pero debe ejecutarse con el mismo conjunto de casos congelado. Cuando existen entradas que cambian con el tiempo, como búsquedas web, estados de un repositorio o herramientas transaccionales, deben usarse instantáneas, simuladores o registros reproducibles. De otro modo, el entorno introduce ruido no atribuible.

La intervención inicial ha de cambiar una sola variable: el identificador del modelo. El resto del contrato se conserva. Si el nuevo modelo requiere un formato de llamada distinto, esa adaptación debe ser mínima, revisada y documentada como una desviación. Tras medir ese cambio aislado, el equipo puede evaluar configuraciones completas más realistas, como un prompt optimizado o un presupuesto mayor, pero debe etiquetarlas como combinaciones y no como efecto puro del modelo.

Las repeticiones son necesarias porque las salidas y las rutas de herramientas pueden variar. El número de ejecuciones y la agregación elegida deben declararse antes de inspeccionar los resultados. Además de los promedios, conviene guardar distribuciones, fallos materiales y diferencias por estrato de dificultad. Una mejora agregada que desaparece en casos ambiguos puede ser insuficiente para un flujo de alto riesgo.

Métricas que no conviene condensar en una sola puntuación

La métrica central suele ser el éxito completo del caso: la respuesta o acción satisface todos los criterios aplicables y no introduce un error material. Debe distinguirse de la corrección parcial. En un diagnóstico técnico, identificar una causa plausible no equivale a proponer una corrección que pase pruebas y respete las restricciones del repositorio. En una investigación, resumir documentos no equivale a sostener la conclusión con evidencia pertinente y correctamente atribuida dentro del sistema.

La abstención correcta merece una medida independiente. Un agente que rechaza un caso fuera de alcance o con evidencia insuficiente puede ser más seguro que otro que produce una respuesta convincente pero infundada. También debe medirse la tasa de acciones correctas, incluyendo llamadas autorizadas, parámetros válidos y efectos esperados. Esta separación impide que una alta tasa de finalización o de uso de herramientas oculte acciones improcedentes.

Para la viabilidad económica y operativa, registre coste por caso correctamente resuelto, distribución de latencia —incluida la cola alta—, número de pasos, tokens, llamadas a herramientas y minutos de revisión humana. La revisión evitada sólo debe contabilizarse cuando el resultado pasa un criterio independiente y cuando el proceso realmente permite omitir o reducir esa revisión. Es una inferencia de negocio, no una propiedad que entregue el modelo por sí mismo.

Tres pruebas representativas para un equipo instrumentado

La primera prueba puede cubrir análisis documental multifuente. El conjunto debe contener expedientes con evidencia concordante, conflictiva e insuficiente. La evaluación no debería limitarse a si la conclusión coincide con una etiqueta: debe comprobar si el sistema utiliza el material recuperado pertinente, declara incertidumbre cuando corresponde y evita afirmar hechos ausentes del expediente. Los casos sin respuesta concluyente son especialmente útiles para medir abstención.

La segunda prueba puede ser un diagnóstico técnico multietapa en un repositorio congelado. Cada caso debe definir el síntoma, las restricciones y las pruebas disponibles. El agente puede inspeccionar archivos y ejecutar herramientas en un entorno aislado, pero las versiones del repositorio, los comandos permitidos y el límite de iteraciones han de ser idénticos. La evaluación debería separar localización del problema, corrección propuesta, resultado de pruebas y cambios no deseados.

La tercera prueba puede simular una acción con herramienta reversible, como crear un borrador, preparar un cambio pendiente de aprobación o actualizar un estado de prueba. Estos casos revelan si el modelo aprovecha correctamente la interfaz, pide aclaraciones cuando faltan datos y respeta permisos. No conviene extrapolar un buen comportamiento en simulación a autonomía irreversible sin una validación específica de controles, autorización y recuperación ante fallos.

Cómo interpretar resultados mixtos y decidir un despliegue

Los resultados mixtos no son un fracaso de la evaluación; a menudo son la conclusión más útil. Claude Opus 4.5 puede mejorar la calidad de análisis en casos complejos y, al mismo tiempo, no compensar su coste o latencia en solicitudes rutinarias. Puede reducir errores de diagnóstico, pero realizar más acciones innecesarias. Puede requerir un prompt o una herramienta distinta para alcanzar su mejor resultado. En cada supuesto, la decisión correcta es segmentar el uso, no convertir una media en una política universal.

Un despliegue gradual debería limitar primero el alcance, los permisos y la población de casos. Un canary permite comparar resultados en condiciones reales mientras se conserva una ruta de reversión. Defina por adelantado qué métricas obligan a pausar: aumento de acciones no autorizadas, caída de evidencia válida, deterioro de la abstención, latencia incompatible con el servicio, sobrecoste por caso resuelto o incremento de revisión humana. Los umbrales concretos dependen del dominio y deben ser aprobados por quienes asumen el riesgo.

Conserve evidencia suficiente para auditar la decisión: versión del contrato, conjunto de evaluación, trazas con datos sensibles protegidos, resultados por caso, reglas del verificador, criterios de exclusión y justificación de los cambios. Esta evidencia es más valiosa que una afirmación genérica de mejora, porque permite reproducir la decisión, detectar regresiones y revisar si el rendimiento se mantiene cuando cambian datos, herramientas o restricciones de operación.

La incertidumbre principal es inevitable: ningún conjunto finito de pruebas cubre todos los casos futuros. Además, las condiciones documentadas por proveedores y canales pueden evolucionar. La respuesta razonable no es asumir estabilidad ni descartar toda adopción, sino versionar la configuración, repetir evaluaciones ante cambios relevantes y conservar supervisión proporcional a la reversibilidad y al impacto de las acciones.

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.