Claude Opus 5.5 frente a Sonnet 5.5 en el triaje: qué medir antes de elegir

La pregunta no es cuál modelo parece más capaz, sino cuál resuelve este flujo con menos riesgo

Comparar Claude Opus 5.5 y Claude Sonnet 5.5 para atención al cliente exige delimitar primero qué significa «hacer triaje». En esta evaluación, la tarea no sería responder al cliente, redactar una solución ni decidir por sí sola una compensación. Consistiría en convertir una consulta breve en datos estructurados que ayuden a una persona o a un sistema posterior a clasificarla y dirigirla al equipo adecuado.

Esa diferencia importa. Un modelo puede producir una respuesta fluida y, aun así, identificar mal el asunto, inventar un dato que el cliente no proporcionó o no detectar que falta información. Para operaciones, esos errores pueden ser más relevantes que el tono o la extensión de la respuesta. Por eso, la comparación debe medir campos concretos y decisiones de derivación, no impresiones generales sobre la calidad conversacional.

La evidencia verificada disponible no permite declarar un ganador en este flujo. No incluye una evaluación compartida de ambos modelos con consultas de soporte, una rúbrica común y resultados reproducibles de clasificación, extracción y escalada. La documentación localizada sobre Sonnet 5.5 sirve para consultar información del propio modelo, pero no establece su rendimiento frente a Opus 5.5 en esta tarea. Una comparación de configuraciones Medium identifica ambos modelos, pero el material verificado tampoco ofrece resultados de triaje.

Por tanto, esta guía no presenta puntuaciones ni simula una prueba ya ejecutada. Propone un protocolo que un equipo puede aplicar si confirma acceso a las variantes exactas y si puede documentar las condiciones de cada ejecución. Hasta entonces, cualquier recomendación sobre cuál elegir debe quedar condicionada. Para otras comparativas de modelos, puede consultarse el índice de comparaciones, pero tampoco sustituye una evaluación ajustada al flujo y a los datos propios.

Definir la tarea y el contrato de salida antes de ejecutar

El primer paso es redactar una especificación que no dependa de las respuestas de ninguno de los modelos. Para cada consulta, el sistema debe devolver únicamente los campos que el proceso realmente necesita. Un esquema ilustrativo podría incluir categoría principal, categorías secundarias si proceden, urgencia, producto o servicio mencionado, identificador explícito, datos ausentes, nivel de confianza y una decisión de continuar o escalar. El equipo debe decidir qué campos son obligatorios y qué valores están permitidos.

La categoría no debe confundirse con la derivación. «Problema de facturación» puede ser una clasificación válida, pero quizá no baste para dirigir el caso si la consulta también comunica una interrupción urgente del servicio. La rúbrica debe especificar cómo resolver varios asuntos en un mismo mensaje, si se permite más de una categoría y qué regla determina la prioridad. Sin esa definición, dos evaluadores pueden puntuar de manera distinta una misma salida.

También conviene separar la validez sintáctica de la corrección semántica. Una respuesta puede respetar perfectamente un formato estructurado y rellenar sus campos con valores equivocados. Y, a la inversa, puede comprender correctamente la consulta, pero incumplir el formato que necesita la integración. Esas dimensiones se deben puntuar por separado para no ocultar un problema operativo detrás de una puntuación agregada.

Antes de la ejecución se fijan las instrucciones, el esquema, las categorías, las reglas de escalada y el procedimiento de puntuación. Las modificaciones posteriores se documentan como una versión nueva de la prueba; no se cambian retroactivamente las reglas para favorecer el resultado de un modelo.

Construir un conjunto que represente consultas reales, no solo ejemplos cómodos

Una prueba útil debe incluir casos claros y casos difíciles. Los ejemplos claros permiten medir si el modelo reconoce la intención cuando está expresada directamente. Los incompletos comprueban si detecta información ausente. Los ambiguos muestran si pide revisión o elige una categoría sin fundamento. También hacen falta mensajes con varios asuntos, errores tipográficos, abreviaturas y referencias contextuales, siempre que esas características existan en el canal que se quiere evaluar.

El conjunto debe reflejar la distribución que el equipo espera procesar, pero también contener suficientes ejemplos de riesgos poco frecuentes para analizarlos aparte. Si una categoría urgente aparece muy pocas veces en el tráfico habitual, una muestra aleatoria pequeña podría no incluirla. El equipo puede añadir un bloque de casos de riesgo para evaluarlo de manera específica, sin ocultar que ese bloque no representa su frecuencia real.

Cada caso debe tener una etiqueta de referencia y una explicación breve de la decisión esperada. En los casos discutibles, es preferible que dos personas revisen el criterio y acuerden la referencia antes de comparar los modelos. Si ni siquiera los evaluadores pueden resolver un ejemplo con la política disponible, ese caso debe marcarse como dudoso, excluirse de la puntuación principal o analizarse por separado.

Para evitar que el conjunto se convierta en una prueba memorizable, conviene reservar casos que no se usen para ajustar las instrucciones. Las consultas deben anonimizarse y reducirse a los datos necesarios. No se deben copiar conversaciones identificables en una herramienta hasta haber confirmado que el canal y las condiciones de tratamiento autorizan ese uso.

Verificar que la comparación sea realmente equivalente

El nombre mostrado en una interfaz no basta para identificar qué se está probando. Antes de ejecutar, hay que registrar el identificador exacto del modelo que devuelve cada canal, la fecha, la interfaz o API utilizada y los parámetros configurables. Si uno de los accesos apunta a una variante distinta, usa herramientas adicionales o aplica una configuración que el otro no ofrece, ya no se trata de una comparación estrictamente equivalente.

La documentación disponible para Sonnet 5.5 describe cambios, compatibilidad y otros datos de ese modelo, pero no cubre Opus 5.5 ni resuelve por sí sola cómo igualar los dos accesos. La página de comparación de Artificial Analysis aportada identifica configuraciones Medium de ambos modelos; eso delimita una pareja que podría investigarse, pero no demuestra que el canal operativo elegido por el equipo exponga los mismos parámetros ni que haya medido el flujo de soporte.

Si los controles no son iguales, no hay que forzar una equivalencia ficticia. Se pueden realizar dos análisis: uno de capacidad bajo la configuración común que sea posible y otro de rendimiento operativo en los canales reales que se usarían. En el segundo deben quedar explícitas las diferencias. También se registran límites de salida, herramientas disponibles, reintentos automáticos y cualquier transformación que aplique la plataforma.

Las instrucciones deben mantenerse idénticas cuando el propósito sea aislar el efecto del modelo. Si se ajusta un prompt distinto para cada uno, se está comparando el conjunto modelo-configuración, no solo los modelos. Ese experimento puede ser útil para seleccionar una solución de producción, pero debe nombrarse correctamente y documentarse como tal.

Medir calidad por dimensión y analizar los errores que cambian una decisión

La puntuación principal debe desglosarse. Para clasificación se mide la proporción de etiquetas correctas y se muestra el detalle por categoría: una media global puede esconder que el sistema falla justo en el tipo de consulta más sensible. Para extracción se comprueba cada campo por separado, contando tanto omisiones como datos añadidos sin respaldo. Cuando el proceso permita varios valores, la rúbrica debe indicar cómo puntuarlos.

La detección de información ausente requiere una referencia explícita: qué dato falta, si realmente es necesario y si la respuesta correcta es preguntar, dejar el campo vacío o escalar. No basta con premiar que el modelo diga «no sé» con frecuencia. Una abstención innecesaria puede ralentizar el soporte; una falta de abstención ante una incertidumbre relevante puede mandar un caso a la cola equivocada.

La escalada se debe medir con errores de ambos tipos. Una escalada que la política no exige consume capacidad humana, mientras que no escalar un caso incierto puede convertir una conjetura en una decisión operativa. El equipo debe ponderar esos costes según sus consecuencias. Si el error de no escalar es mucho más grave, puede definirse un umbral conservador y publicar qué sucede con la carga adicional de revisión.

Los errores de formato se contabilizan aparte de la calidad del contenido. Se puede informar de la proporción de salidas que cumplen el esquema y, dentro de las válidas, de la proporción que además supera los criterios de contenido. También se revisan manualmente los errores con impacto alto: urgencia mal asignada, invención de datos personales, derivación incorrecta y ausencia de escalada.

Las diferencias entre modelos no deben considerarse concluyentes sin incertidumbre estadística y revisión de casos. Si el conjunto es pequeño, una variación de unos pocos ejemplos puede cambiar mucho el porcentaje. Publicar el numerador, el denominador y los errores observados ayuda a interpretar el resultado mejor que presentar solo una nota.

Calcular latencia y coste por caso aceptado, no por impresión

La latencia debe medirse con un método constante: desde el envío de la consulta hasta que la salida está disponible y validada. Conviene informar de la mediana y de una medida de cola, como el percentil 95, además del número de ejecuciones. Las mediciones deben cubrir las condiciones que el equipo espera en producción; una ejecución aislada no representa necesariamente la variabilidad del servicio.

El coste exige documentar canal, fecha, unidades facturadas y tarifas vigentes para esa configuración. Los materiales verificados aquí no bastan para confirmar una comparación completa de precios aplicable a los dos modelos en los canales que usaría un equipo. No se debe trasladar un precio de una página secundaria, una variante o una fecha distinta como si fuera el coste real de la integración evaluada.

Una métrica más útil que el coste nominal por llamada es el coste por caso aceptado. Para calcularlo, se suman los costes observados de las ejecuciones y las revisiones necesarias, y se dividen por los casos que superan la rúbrica. Si una salida inválida provoca reintentos o intervención humana, ese trabajo también puede formar parte del coste operativo, siempre que el método se defina y se aplique igual a ambas alternativas.

El cálculo debe evitar mezclar costes que no se hayan medido. Si se excluye la infraestructura, el tiempo de revisión o los reintentos, se indica. El resultado sirve para la configuración y el volumen considerados, no como propiedad universal del modelo.

Tratar privacidad y gobernanza como propiedades del canal

La privacidad no se deduce del nombre del modelo ni de su capacidad para clasificar. Depende de las condiciones del servicio concreto: qué datos se envían, cuánto tiempo se conservan, quién puede acceder, si se usan para otros fines y qué controles ofrece el canal elegido. Estas condiciones pueden cambiar entre una interfaz de consumo, un servicio empresarial y una API, por lo que no se deben presentar como una propiedad genérica de Opus 5.5 o Sonnet 5.5.

Antes de probar con consultas reales, el responsable debe identificar el canal, revisar sus condiciones aplicables y obtener la aprobación interna correspondiente. Si esa verificación no está disponible, se usan datos sintéticos o adecuadamente anonimizados, teniendo en cuenta que la anonimización no elimina automáticamente todos los riesgos. También deben excluirse secretos, credenciales y datos personales que no sean imprescindibles para evaluar la tarea.

Incluso con condiciones de tratamiento aceptables, la salida debe considerarse una sugerencia hasta que la evaluación y el diseño de controles justifiquen otra cosa. Una clasificación equivocada puede afectar los tiempos de respuesta o la atención recibida. Para decisiones de prioridad, acceso, compensación o cierre, la política debe definir qué revisión humana hace falta y cómo se corrigen los errores.

Cómo publicar una conclusión sin exagerar su alcance

Un informe útil presentaría resultados totales y por tipo de consulta, junto con el protocolo, el número de casos, las etiquetas de referencia, las instrucciones y las configuraciones verificadas. También explicaría las exclusiones, los casos dudosos, los fallos de mayor impacto y las condiciones de acceso que no pudieron igualarse. Cuando las condiciones de publicación lo permitan, se compartirían los materiales necesarios para repetir la prueba, retirando cualquier dato que pueda identificar a clientes.

La conclusión se limitaría a la población, el canal y la configuración evaluados. Si Sonnet 5.5 obtuviera menor coste por caso aceptado en un conjunto de consultas habituales, eso no probaría que sea mejor para todos los tipos de soporte. Si Opus 5.5 detectara más casos ambiguos en una muestra concreta, tampoco probaría una ventaja universal. El resultado podría justificar una prueba en sombra o un piloto con revisión humana, no una automatización inmediata.

Las condiciones para una prueba en producción deben definirse por anticipado: porcentaje máximo de errores críticos, proporción de salidas válidas, política de escalada, controles de privacidad y mecanismo de reversión. Si no se alcanzan, la opción prudente es mantener la revisión humana o no desplegar. Si ambos modelos fallan de manera similar en una categoría, quizá el problema sea el esquema, la política o la calidad de los datos, no una diferencia que la elección entre modelos pueda resolver.

Con la evidencia actualmente verificada, no se puede recomendar uno de los dos modelos como ganador del triaje. Sí se puede establecer qué falta para decidir: confirmar los identificadores y los canales, fijar una rúbrica, ejecutar la misma colección de casos bajo condiciones documentadas y medir los errores que afectan a la operación. Hasta contar con esos datos, cualquier elección es una hipótesis que debe probarse, no una conclusión sustentada.

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.