Claude Sonnet 4.5 en ciencias de la vida: qué demuestran sus resultados y cómo revalidarlos

Qué significa superar una referencia humana en una prueba acotada

Una puntuación de benchmark responde a una pregunta delimitada: cómo rindió un modelo en un conjunto concreto, con una tarea, unas instrucciones y unas condiciones determinadas. No responde automáticamente a otra pregunta mucho más amplia: si el modelo puede leer correctamente los protocolos de un laboratorio, interpretar sus datos y apoyar conclusiones científicas con fiabilidad. Para decidir si Claude Sonnet 4.5 puede ayudar en un flujo de trabajo real, es necesario mantener separadas esas dos afirmaciones.

La tarjeta de sistema de Claude Sonnet 4.5 informa resultados de LAB-Bench para varias tareas, entre ellas Protocol QA, FigQA, SeqQA y Cloning, y presenta una referencia humana. En el gráfico señalado para Protocol QA, la puntuación de Sonnet 4.5 es 0,833 con k=10; la de Sonnet 4 es 0,741. Son cifras del resultado publicado por Anthropic, no una validación independiente del rendimiento en cualquier documentación o laboratorio.

Por tanto, que una puntuación supere una referencia humana en una evaluación concreta no significa que el modelo sea mejor que los investigadores en general, ni que acierte en cada pregunta, ni que sus respuestas sean seguras para convertirse en instrucciones experimentales. La interpretación depende de qué preguntas se hicieron, cómo se calificaron y quién integró el grupo de comparación humana. La información de las fuentes disponibles no basta para trasladar el resultado a otros documentos, equipos o decisiones.

Identificar con precisión el modelo evaluado

“Claude Sonnet 4.5” nombra una familia o versión comercial, pero una evaluación reproducible necesita registrar el identificador que recibió la solicitud. La documentación de Anthropic distingue entre identificadores fechados y alias, e identifica el snapshot de Sonnet 4.5 como claude-sonnet-4-5-20250929. Anotar ese identificador, junto con la fecha y la configuración de la prueba, reduce la ambigüedad al comparar resultados.

Esta precaución también afecta a la comparación con modelos posteriores. La fuente oficial aportada sobre Sonnet 5 anuncia ese modelo, pero no establece que haya sido evaluado en las mismas tareas de LAB-Bench o BixBench, bajo el mismo protocolo y con el mismo conjunto que Sonnet 4.5. La documentación suministrada tampoco permite afirmar que exista una comparación equivalente para Sonnet 4.6. La aparición de una versión posterior no constituye por sí sola evidencia de una mejora en estas tareas.

Una comparación útil debe fijar la tarea y las condiciones, no limitarse a enfrentar nombres de modelos. Si cambian el conjunto de preguntas, el número de ejemplos dados al modelo, las herramientas disponibles o el método de puntuación, las diferencias pueden deberse a esas variaciones, además de a la versión del modelo.

Tres benchmarks, tres tipos de evidencia

LAB-Bench es un conjunto de tareas para medir capacidades de modelos de lenguaje relacionadas con la investigación en biología. El artículo original describe preguntas de opción múltiple y una comparación con investigadores expertos. Su alcance es el de las tareas incluidas en el benchmark; no equivale a una observación directa del trabajo de laboratorio ni a una evaluación de todas las etapas de una investigación.

Protocol QA, dentro de LAB-Bench, se centra en responder preguntas sobre protocolos. El resultado publicado para Sonnet 4.5 aporta evidencia sobre su desempeño en esa tarea bajo las condiciones de la evaluación reportada. No demuestra que el modelo ejecute un protocolo, detecte todas sus ambigüedades o adapte correctamente una instrucción a reactivos, instrumentos y procedimientos locales. Comprender una pregunta documental y realizar una operación experimental son capacidades distintas.

LAB-Bench incluye también tareas asociadas a la lectura de figuras, secuencias y clonación. Que la tarjeta de sistema informe resultados en estas categorías amplía el mapa de evaluación, pero no hace intercambiables sus puntuaciones: cada tarea pone a prueba capacidades y formatos diferentes. Un buen resultado en preguntas sobre protocolos no permite inferir automáticamente un resultado equivalente al interpretar una figura.

BixBench aborda la biología computacional mediante preguntas abiertas que requieren trayectorias analíticas de varios pasos. El artículo original describe evaluaciones iniciales con GPT-4o y Claude 3.5 Sonnet, no con Claude Sonnet 4.5. En consecuencia, BixBench es útil para explicar una clase de evaluación de análisis computacional, pero sus resultados iniciales no son resultados de Sonnet 4.5 y no deben presentarse como tales.

El repositorio de BixBench describe un harness y una configuración para ejecutar evaluaciones que incluyen análisis de notebooks y código. Esa estructura permite plantear una reproducción controlada del benchmark, pero no elimina la necesidad de comprobar qué versión, herramientas y condiciones se aplicaron en cada experimento. Para LAB-Bench, el repositorio de los autores documenta formatos y scripts de evaluación, y advierte que el material público no contiene el conjunto completo. Esta limitación importa si se pretende reconstruir exactamente una cifra publicada.

Por qué las cifras de Protocol QA no deben combinarse sin verificar

La evidencia suministrada incluye un resultado de Protocol QA en la tarjeta de sistema de Sonnet 4.5: 0,833 para Sonnet 4.5 con k=10 y 0,741 para Sonnet 4. La propuesta editorial señala que algunas publicaciones de Anthropic muestran puntuaciones distintas para tareas denominadas Protocol QA. Sin embargo, las fuentes aportadas no documentan lo suficiente como para determinar si esas cifras proceden del mismo conjunto, de diferentes particiones, de prompts distintos o de otros cambios metodológicos.

La coincidencia en el nombre de la tarea no garantiza que dos mediciones sean equivalentes. Antes de presentarlas como una evolución o una discrepancia, habría que comprobar la versión exacta del modelo, el conjunto evaluado, el formato de las preguntas, los ejemplos incluidos en el prompt, la disponibilidad de herramientas, la regla de puntuación y el tratamiento de respuestas parciales. También habría que aclarar qué significa k=10 en el gráfico y cómo se agregaron las respuestas, si se quiere interpretar ese parámetro con precisión.

La comparación humana requiere una auditoría semejante. La tarjeta de sistema muestra una referencia humana, pero los materiales descritos aquí no proporcionan detalles suficientes para caracterizar con seguridad la población, el número de participantes, su experiencia o las instrucciones que recibieron. Sin esos datos no es riguroso presentar esa referencia como un estándar universal de desempeño experto.

La conclusión adecuada no es que los resultados sean incompatibles, ni que una cifra sea errónea: es que no se puede resolver la comparabilidad con la información disponible. Una redacción rigurosa informa cada cifra en su contexto y deja explícita la incertidumbre, en vez de calcular una tendencia o combinar puntuaciones.

Del benchmark al laboratorio: el salto que falta

Un benchmark puede evaluar si una respuesta se ajusta a una clave, pero un laboratorio necesita saber si esa respuesta es correcta para su documentación vigente y para el contexto de la pregunta. Puede haber protocolos con variantes locales, nombres internos, notas de revisión o condiciones relevantes que no aparezcan en el material de referencia de una prueba pública. La capacidad de responder preguntas generales no verifica que el modelo haya localizado y aplicado la versión pertinente.

Además, responder sobre un protocolo no equivale a llevarlo a cabo. La ejecución depende de personas, equipos, muestras, materiales y controles que no quedan demostrados por una puntuación de preguntas y respuestas. Del mismo modo, producir una interpretación plausible de una figura no prueba que la interpretación sea válida ni que la conclusión científica se sostenga frente a los datos completos.

El uso de herramientas añade otra dimensión. En una tarea de análisis computacional, la capacidad para producir o ejecutar código puede influir en el resultado; en una tarea documental, el modelo quizá responda solo a partir del prompt. Para atribuir la diferencia a una versión del modelo, la comparación debe mantener constantes las herramientas y dejar constancia de cuándo se usaron. Las fuentes disponibles describen elementos de evaluación de los benchmarks, pero no bastan para reconstruir todas las condiciones de cada cifra publicada.

Por estas razones, un resultado favorable sirve como motivo para evaluar un uso acotado —por ejemplo, localizar una respuesta candidata en documentación y preparar un borrador para revisión—, no como permiso para sustituir la comprobación de especialistas ni como demostración de validez científica.

Cómo diseñar una validación retrospectiva útil

Una prueba interna no necesita automatizar experimentos ni exponer información sensible para evaluar comprensión documental. Puede construirse con un corpus autorizado y congelado: documentos para los que el equipo tenga permiso de uso, una versión identificable de cada archivo y un registro de qué material estaba disponible al responder. Congelar el corpus evita que cambios posteriores en los documentos alteren la interpretación de los resultados.

Especialistas que conozcan los documentos deberían redactar y revisar preguntas representativas, junto con respuestas de referencia verificadas contra la fuente. Conviene incluir preguntas que tengan respuesta explícita, preguntas cuya respuesta exija combinar partes del documento y preguntas que no puedan resolverse con el material disponible. Esta última categoría permite comprobar si el sistema reconoce los límites de la evidencia en vez de completar huecos con una respuesta plausible.

Cada respuesta debe evaluarse contra una rúbrica antes de comparar modelos. Una rúbrica puede separar exactitud del contenido, respaldo en la fuente, identificación de la versión pertinente, omisiones importantes y afirmaciones no respaldadas. Las respuestas deberían ser revisadas por personas que no dependan de la marca o la versión del modelo para juzgar el resultado, y las discrepancias entre revisores deberían quedar registradas y resolverse con criterios previamente acordados.

Para comparar Sonnet 4.5 con versiones posteriores, se deben usar las mismas preguntas, documentos, instrucciones, herramientas y reglas de puntuación. Hay que registrar el identificador exacto de cada modelo. Si una plataforma no permite fijar una versión o un parámetro, esa limitación forma parte del resultado y no debe ocultarse. Las repeticiones también ayudan a identificar si el sistema responde de manera estable; el número de repeticiones se decide según el coste y el riesgo de la aplicación, no se deduce de las fuentes públicas.

La prueba debe ser retrospectiva y limitada a comprensión de documentación revisable. No se necesita pedir al modelo que diseñe, modifique o ejecute experimentos para saber si encuentra información, interpreta el texto o reconoce que una pregunta no está contestada. Si se evalúan figuras o resultados analíticos, el equipo debe disponer de referencias verificadas y separar ese resultado de las puntuaciones de preguntas sobre protocolos.

Clasificar los errores que importan

Una sola tasa global de aciertos puede ocultar fallos de distinta gravedad. En lectura de protocolos, una omisión puede dejar fuera una condición importante; una inversión de pasos puede alterar el significado de una instrucción; una confusión de unidades puede hacer que una respuesta parezca precisa sin serlo. El equipo debería registrar esos casos por separado, sin suponer que todas las respuestas incorrectas implican el mismo riesgo.

En preguntas sobre figuras, conviene distinguir entre describir un elemento visible, atribuir una relación que no se muestra y proponer una explicación causal. En tareas computacionales, se debe diferenciar un análisis reproducible de una conclusión que no se deriva de los datos. También hay que marcar las referencias que no respaldan la respuesta, las citas a secciones equivocadas y la confianza injustificada ante información ausente.

La evaluación de seguridad editorial debe mantenerse en el terreno documental: comprobar si el modelo representa fielmente el contenido autorizado y si señala la incertidumbre. No es necesario incluir instrucciones experimentales sensibles ni pedir acciones que no formen parte de la tarea de lectura. El objetivo es saber si el sistema sirve como apoyo revisable, no convertir el benchmark interno en una validación de procedimientos.

Uso acotado y conclusión

Si una evaluación interna favorable confirma que Sonnet 4.5 encuentra información y la representa con respaldo verificable, el equipo podría probarlo como asistente de lectura o como generador de borradores sometidos a revisión. La respuesta final seguiría dependiendo del proceso de comprobación acordado por el laboratorio. La puntuación pública, por sí sola, no justifica que una salida se utilice como instrucción experimental ni que determine una interpretación científica.

La comparación con sucesores debe plantearse como una nueva prueba controlada. La documentación aportada permite identificar Sonnet 4.5 y señala un anuncio oficial de Sonnet 5, pero no ofrece resultados equivalentes de este último en Protocol QA, LAB-Bench o BixBench. Tampoco permite establecer una comparación controlada con Sonnet 4.6. Por ello, no cabe inferir de estas fuentes qué modelo posterior rinde mejor en las mismas tareas.

La conclusión verificable es más limitada, pero útil: Anthropic publica resultados favorables de Sonnet 4.5 en tareas concretas de LAB-Bench, incluido Protocol QA, mientras que BixBench evalúa otra clase de trabajo y sus resultados iniciales citados no corresponden a Sonnet 4.5. Esos datos justifican formular una hipótesis de utilidad para lectura y análisis, no afirmar fiabilidad en un laboratorio real. La evidencia que falta debe obtenerse con documentos autorizados, preguntas revisadas por especialistas, referencias trazables y comparaciones bajo condiciones equivalentes.

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.