Supongamos que un equipo de atención al cliente tiene que organizar cada día una gran cantidad de comentarios: clasificar los problemas en categorías como inicio de sesión, pagos y sugerencias sobre funciones, y luego generar resúmenes para quienes se encargan de gestionarlos. Es un trabajo repetitivo, pero no se puede hacer a la ligera: pasar por alto una frase como «ya se me ha cobrado dos veces» podría cambiar la forma de gestionar el caso.
El 7 de octubre, Anthropic presentó Claude Haiku 5.5 y lo posicionó para tareas de alta frecuencia y sensibles al coste, como resumir, clasificar, comprimir contexto y consultar bases de datos; también puede ayudar a programar. Cabe preguntarse: tras la bajada de precios, ¿qué pasos se le pueden delegar y qué decisiones siguen requiriendo un modelo más potente o la intervención de una persona?
El análisis siguiente se basa en la descripción oficial y en la tabla de precios; no se realizaron pruebas independientes y los flujos de trabajo son hipotéticos.
【Primero hay que acotar la tarea para poder evaluar si se hace bien】
Tomemos como ejemplo la clasificación de comentarios anterior. Un diseño verificable consiste en fijar las categorías, definirlas y especificar el formato de salida; luego se pide al modelo que devuelva una clasificación y cite el texto original que la respalda. Si no puede clasificar un contenido, se le permite marcarlo como «pendiente de revisión».
Así, los criterios de aceptación quedan concretos: si se eligió la categoría correcta, si el texto original respalda la conclusión y si se confundieron dos cuestiones distintas.
También hay que definir claramente el objetivo de un resumen. «Que sea conciso» no basta como criterio. Si el resumen sirve para que otro agente de atención al cliente se haga cargo del caso, el estado de la cuenta, cuándo ocurrió, el mensaje de error y las acciones que ya se intentaron pueden ser más importantes que la fluidez del texto. El modelo podría omitir una condición clave y producir un resumen que, aunque se lea muy bien, no permita dar el siguiente paso.
Esto explica por qué vale la pena asignar por separado a un modelo más pequeño las tareas frecuentes y acotadas: la entrada, la salida y los criterios de evaluación pueden mantenerse relativamente fijos, y los errores son más fáciles de localizar. Pero que una tarea sea acotada no significa que sea sencilla. Si un comentario incluye tanto un pago fallido como una solicitud de reembolso, el sistema tendrá que admitir varias etiquetas o derivarlo a una persona para que lo gestione.
Que pueda hacerse cargo del trabajo depende, ante todo, de que el diseño de la tarea contemple una vía para identificar las excepciones.
【Para ayudar a un modelo potente, lo esencial es conservar la información necesaria para juzgar】
En tareas de programación también se puede plantear una división del trabajo como esta: primero, un modelo más pequeño organiza los registros de errores, resume los archivos pertinentes y condensa la conversación previa; después, entrega ese material a un modelo más potente para que lo analice.
Esto coincide con el papel de apoyo que Anthropic atribuye a Haiku 5.5. La empresa también recomienda considerar Sonnet 5.5 u Opus 5.5 para tareas complejas de programación con agentes. Estas recomendaciones de uso siguen siendo valoraciones del proveedor; no permiten concluir qué modelo debería elegirse para un proyecto concreto.
La posible ventaja de esta división es reducir el tiempo que el modelo más potente dedica a volver a leer y organizar materiales; el riesgo está en el traspaso de información. Si al resumir se elimina la condición previa a la aparición del error, el modelo que recibe el material no contará con un dato clave.
Por eso, los resúmenes deben poder rastrearse hasta el texto original. En lo relativo a versiones, ubicaciones de archivos y condiciones excepcionales, hay que conservar suficientes detalles para que los pasos posteriores puedan verificarlos.
Los límites de las consultas a bases de datos son más evidentes. Que el modelo genere una consulta no significa que entienda cómo se definen los datos. Supongamos que el usuario pregunta «cuántas personas pagaron este mes»: primero hay que aclarar si se cuentan los pagos realizados con éxito, las suscripciones vigentes o las cuentas únicas. La consulta puede ejecutarse sin problemas y, aun así, responder a otra pregunta. Un flujo de trabajo adecuado debe verificar tanto la consulta como los criterios de cómputo, y restringir los permisos de ejecución.
【¿Cómo se calcula el costo de 0,003 dólares por tarea?】
Según la tabla de precios oficial, Haiku 5.5 tiene dos tarifas según la longitud de la entrada de cada solicitud; no se puede aplicar una sola reducción de precio de manera general.
El precio por millón de tokens es el siguiente: para entradas de hasta 100k, 0,10 dólares por la entrada y 0,50 dólares por la salida; para entradas de más de 100k, 0,50 dólares por la entrada y 2,50 dólares por la salida.
Las tarifas por lectura desde la caché en ambos tramos son 0,01 y 0,05 dólares, respectivamente; las de escritura en la caché son 0,125 y 0,625 dólares, respectivamente.
Aquí, un token es una unidad con la que se mide el texto procesado por el modelo; no equivale al número de caracteres chinos. 100k significa cien mil tokens de entrada y determina el tramo de precios aplicable.
Veamos un cálculo hipotético concreto: una tarea con 20.000 tokens de entrada y 2.000 de salida, sin usar la caché y dentro del tramo de hasta 100k.
Costo de entrada: 20.000 ÷ 1.000.000 × 0,10 = 0,002 dólares.
Costo de salida: 2.000 ÷ 1.000.000 × 0,50 = 0,001 dólares.
Total: 0,003 dólares.
Si se toma como referencia el precio de Haiku 4.5, de 1 dólar por millón de tokens de entrada y 5 dólares por millón de tokens de salida, la misma cantidad de tokens costaría 0,03 dólares. En este ejemplo, el costo baja un 90%, siempre que se mantenga la misma cantidad de tokens, se aplique el mismo tramo y no haya reintentos ni costos de herramientas.
La cantidad de tokens de un mismo texto puede variar según el modelo. El uso de la caché también debe calcularse por separado: la escritura inicial y las lecturas posteriores tienen precios distintos. El ahorro depende de que el contenido se pueda reutilizar y de que la solicitud encuentre una entrada en la caché; no se puede calcular todo el texto de entrada con la tarifa de lectura.
【Lo que realmente importa es cuánto cuesta cada resultado que cumple los requisitos】
Supongamos que el sistema procesa mil comentarios. La primera llamada es barata, pero se producen con frecuencia errores de clasificación u omisiones de condiciones, así que el equipo tiene que reintentar o revisar los resultados manualmente. Que baje la factura no significa necesariamente que también baje el costo total de completar el mismo trabajo.
Una comparación más útil consiste en fijar la tarea y los criterios de aceptación y registrar cuatro datos: la tasa de resultados correctos en el primer intento, el número de reintentos, la proporción de casos derivados a un modelo más potente y el tiempo de revisión manual. Si se utilizan bases de datos u otras herramientas, también hay que incluir los costos de esas llamadas.
En tareas de clasificación se pueden medir los errores y las omisiones de categorías; en los resúmenes, comprobar si se conservaron las condiciones clave; y en la asistencia para programación, verificar si el material condensado basta para respaldar el análisis posterior. Estos indicadores reflejan mejor la utilidad del producto que el «costo medio por llamada».
El bajo precio de Haiku 5.5 crea nuevas condiciones de costo para separar y delegar tareas repetitivas de organización. Cuánto trabajo podrá asumir en última instancia debe comprobarse en tareas concretas: que resuelva de forma fiable los casos habituales, identifique las excepciones y no pierda pruebas clave al transferir el trabajo. Solo si se cumplen estas condiciones, las llamadas baratas se traducirán en una carga de trabajo gestionada de forma fiable.
Solo con fines de investigación y aprendizaje; no constituye asesoramiento de inversión.