Para un millón de tickets etiquetados, Amazon pasó de pagar unos $22.200 con Claude Sonnet 4.6 a pagar cerca de $500 con un modelo de decisión propio, según relata el equipo de Strands Agents. El mismo trabajo, el mismo volumen de tickets, 44 veces menos costo y una latencia que bajó de más de 4 segundos a menos de 1. Dos ingenieros de Amazon, identificados como Carr y Mehul, hicieron ese cambio sobre el sistema interno de tickets de la compañía y lo documentaron con cifras exactas.

Este artículo explica qué hace distinto a un modelo de decisión frente a un LLM general como Sonnet, y en qué casos conviene reemplazar uno por el otro.

TL;DR

  • Un modelo de decisión conviene con catálogo fijo y volumen alto: cuesta hasta 44 veces menos que un LLM grande.- Amazon cambió Sonnet 4.6 por Strands Decider y bajó el costo por ticket de $0,0222 a cerca de $0,0005.- El tiempo promedio por llamada cayó de 4.215 ms con Sonnet a 897 ms con el modelo especializado: una caída del 78%.- Reemplazar un LLM grande solo conviene si el catálogo de opciones es cerrado y estable, no si cambia cada semana.- Enviar las claves JSON sin orden fijo mueve las probabilidades hasta 0,19 puntos entre corridas iguales.

¿Qué es un modelo de decisión?

Un modelo de decisión es un modelo de machine learning que, dado un estado y una pregunta con un conjunto cerrado de opciones, devuelve una probabilidad por cada opción más un puntaje de confianza. No genera texto libre: elige entre alternativas predefinidas, como un clasificador multiclase optimizado para velocidad y costo.

Un LLM general como Sonnet puede responder casi cualquier pregunta: explicar un concepto, escribir código, resumir un documento largo. Para lograrlo necesita generar texto token por token y razonar sobre un prompt extenso en cada llamada. Esa flexibilidad cuesta tiempo de cómputo y dinero en cada petición.

Un decision model renuncia a esa flexibilidad a cambio de velocidad. Amazon probó primero Strands Decider 2B y después pasó a una versión E4B basada en Gemma 4, que dio mejores resultados sobre su set de pruebas de tickets. Strands Decider no genera una respuesta en lenguaje natural, sino que puntúa cada opción del catálogo de 20 tipos de categoría que usa Amazon.
Strands Decider E4B corre sobre instancias ml.g5.xlarge, cada una con una GPU A10G de 24 GB.

Por qué importa

Muchas empresas usan un LLM grande para tareas que en el fondo son clasificación: etiquetar tickets, enrutar un mensaje de soporte, decidir si un comentario es spam. Es la opción más simple de implementar, porque el mismo modelo que ya usás para generar texto también puede devolver una etiqueta en formato JSON. El problema aparece cuando el volumen crece.

En el caso de Amazon, cada ticket con Sonnet 4.6 consumía 6.554 tokens de entrada y 170 de salida, un total de 6.724 tokens por ticket, según el reporte de Strands Agents. Con Strands Decider E4B esos números bajaron a 2.009 tokens de entrada y apenas 1 de salida, 2.010 en total, una reducción del 70% en tokens procesados por ticket.

Esa caída de tokens se traduce directo en costo. A precios públicos de Bedrock para Sonnet ($3,00 por millón de tokens de entrada y $15,00 por millón de salida) y de SageMaker para el endpoint de Strands Decider ($1,408 por hora de instancia ml.g5.xlarge), el costo por ticket pasó de $0,0222 a cerca de $0,0005. Multiplicado por un millón de tickets, eso es la diferencia entre $22.200 y cerca de $500, una reducción del 98%.

La latencia bajó en la misma proporción. El tiempo promedio por llamada pasó de 4.215 ms con Sonnet a 897 ms con el modelo especializado, un 78% menos. El día que Amazon apagó el tráfico de Sonnet, la duración promedio de su función Lambda cayó 74%.

Este patrón no es exclusivo de Amazon. Cualquier equipo que corra una tarea de clasificación sobre millones de eventos (tickets, transacciones, mensajes) paga el mismo costo de usar un modelo generalista para una tarea que, en el fondo, tiene una respuesta de un puñado de opciones fijas. El LLM casi siempre puede resolverlo. Lo que hay que decidir es si vale la pena pagar el precio de un modelo generalista para una tarea que no necesita generar texto.

Cómo funciona un modelo de decisión

La arquitectura que montó Amazon es casi toda infraestructura estándar de AWS. Cada evento de ticket llega a una cola SQS, que dispara una función Lambda. La Lambda lee los datos del ticket y llama a un endpoint de Amazon SageMaker que corre Strands Decider. SageMaker copia los pesos del modelo desde S3 antes de levantar el contenedor, y la red del endpoint queda aislada, sin acceso de salida.
El endpoint usa cerca de 19 GiB de memoria y responde una peticion en unos 640 ms sobre una sola instancia.

flowchart TD A["Ticket nuevo"] --> B["Cola SQS"] B --> C["Funcion Lambda"] C --> D["Endpoint SageMaker: Strands Decider"] D --> E["Probabilidad por etiqueta"] E --> F["Etiqueta aplicada al ticket"] C --> G["AppConfig: BEDROCK / DUAL / DECIDER"] G --> C

Para no apostar todo a un cambio brusco, la Lambda lee en cada mensaje un valor de tres estados desde AWS AppConfig. En modo BEDROCK solo responde Sonnet. En modo DECIDER solo responde el modelo de clasificación. En modo DUAL, los dos modelos reciben el mismo ticket, Amazon aplica la etiqueta de Sonnet, y guarda la de Strands Decider para comparar después.

sequenceDiagram participant T as Ticket participant L as Lambda participant S as Sonnet en Bedrock participant D as Strands Decider T->>L: evento desde la cola SQS L->>S: pide etiqueta en modo DUAL L->>D: pide etiqueta en modo DUAL S-->>L: etiqueta aplicada mas tokens usados D-->>L: probabilidad por cada opcion Note over L: compara ambas respuestas antes de decidir el cambio

Correr ambos modelos en tráfico real, en paralelo, durante semanas, le dio a Amazon más información que cualquier evaluación offline. Y si algo salía mal, volver a BEDROCK era un cambio de configuración de 45 segundos, sin tocar código ni redeploy.

Para que el modelo clasificador funcione necesita un catálogo de opciones bien definido. La ventana de contexto de Strands Decider es de 4.096 tokens, y las descripciones de las 20 etiquetas que usaba Amazon en producción no entraban ahí. El equipo reescribió cada etiqueta como un criterio de una o dos oraciones, las mandó como las opciones de una sola pregunta de elección múltiple, y agregó una opción "ninguna" para los casos que no encajan.

Así se ve, en una versión simplificada en Python puro y sin ninguna librería de IA, el contrato de entrada y salida que sigue un modelo de decisión: un estado, un conjunto de opciones, y una probabilidad por cada una.

import math def decision_model(scores): exps = {label: math.exp(score) for label, score in scores.items()} total = sum(exps.values()) return {label: round(value / total, 3) for label, value in exps.items()} resultado = decision_model({ "facturacion": 2, "soporte_tecnico": 1, "ninguna": 0 }) print(resultado)

La salida literal de ese script es {'facturacion': 0.665, 'soporte_tecnico': 0.245, 'ninguna': 0.09}. Un modelo de decisión real reemplaza esos tres números fijos por una red entrenada que calcula el puntaje de cada opción a partir del ticket, pero el contrato de salida, una probabilidad por opción que suma 1, es el mismo.

⚠️ Ojo: en las pruebas de Amazon, enviar el mismo ticket con las claves del JSON en otro orden movió las probabilidades de salida hasta 0,19 puntos. Si servís un clasificador especializado detrás de una API, mandá siempre las claves en el mismo orden antes de comparar resultados entre corridas.

Casos de uso reales

El patrón de Amazon se repite en cualquier sistema que reciba mucho volumen y tenga que elegir entre pocas categorías conocidas. Estos son los escenarios donde un modelo clasificador suele rendir mejor que un LLM general:

  • Enrutamiento de tickets de soporte: decidir a qué equipo va un caso (facturación, bugs, cuentas) antes de que lo vea una persona.- Moderación de contenido: marcar un comentario o una imagen como spam, apropiado o que necesita revisión humana, con un catálogo fijo de categorías.- Detección de fraude en transacciones: puntuar cada transacción contra un conjunto cerrado de patrones de riesgo conocidos.- Enrutamiento entre agentes en un sistema multiagente: elegir qué agente o herramienta especializada debe atender una consulta, en vez de que un LLM grande razone esa decisión cada vez.- Triage de alertas de monitoreo: clasificar una alerta como crítica, informativa o duplicada antes de despertar a un humano.

Todos estos casos comparten tres condiciones: un catálogo de opciones que no cambia todos los días, suficiente volumen para que el ahorro por ticket se multiplique, y una ventana de contexto donde el estado de cada caso entra completo, o casi, dentro del límite del modelo elegido.

Errores comunes y buenas prácticas

El error más común es asumir que un modelo de decisión puede reemplazar cualquier tarea de clasificación sin ajustes. Si las etiquetas necesitan una explicación larga para distinguirse entre sí, o el catálogo cambia cada semana, meter todo ese contexto en una ventana de unos pocos miles de tokens no funciona: hay que simplificar las etiquetas primero, como hizo Amazon.

Otro error es saltarse la fase de comparación en paralelo. Sin un modo como DUAL, no hay forma de saber si el modelo nuevo falla justo en los casos raros que más le importan al negocio. Correr los dos modelos sobre tráfico real, aunque sea por unas semanas, es la única evaluación que de verdad importa.

Ajustar el umbral de confianza también es parte del trabajo, no un detalle menor. Amazon tuvo que calibrar qué tan segura debía estar Strands Decider antes de aplicar una etiqueta sin revisión. Un umbral muy bajo aplica etiquetas equivocadas, y uno muy alto manda demasiados casos de vuelta a revisión humana o a Sonnet, si todavía corre en paralelo.

Tampoco conviene confundir un modelo de decisión con un motor de reglas tradicional. Un motor de reglas aplica condiciones exactas escritas a mano, mientras que un modelo de decisión aprende de ejemplos y da una probabilidad, lo que le permite manejar texto ambiguo que un if/else no puede interpretar.

Sobre si el modo DUAL de Amazon sigue activo en este momento: no hay forma directa de verificar esto desde afuera, porque el valor del flag vive en la cuenta privada de AWS de Amazon, dentro de su propio AppConfig. La verificación real la hace alguien del equipo de Carr y Mehul consultando ese flag desde dentro, no un tercero desde internet.

Comparativa con alternativas

Un modelo de clasificación no es la única forma de resolver un problema de clasificación. Esta tabla resume cuándo conviene cada enfoque:
OpciónCuándo usarlaVentajaLimitaciónLLM general (Sonnet)Catálogo abierto o inestable, pocas llamadas por díaFlexibilidad total, sin reentrenarCosto y latencia altos a gran volumenModelo de clasificación (Strands Decider)Catálogo cerrado, volumen alto, latencia críticaHasta 44 veces más barato y 78% más rápidoNecesita reescribir etiquetas largas como criterios cortosReglas if/else clásicasPocas condiciones, totalmente deterministasCero inferencia, costo casi nuloNo generaliza a texto libre ni a casos ambiguosClasificador clásico (regresión logística, SVM)Volumen alto, features bien definidas, sin GPU disponibleCorre en CPU, muy barato de entrenarRequiere ingeniería de features manual

Profundizando

La cuenta de por qué Strands Decider sale tan barato no es complicada: una instancia ml.g5.xlarge cuesta $1,408 la hora y, a unos 640 ms por petición, atiende cerca de 5.600 tickets en esa hora. Dividiendo, sale a unos $0,0002514 por ticket a utilización completa, unos $250 por millón de tickets. Amazon reporta cerca de $500 por millón en producción real, el doble, porque deja margen de capacidad para picos de tráfico en vez de saturar cada instancia al 100%.

Ese margen es una decisión de diseño, no un desperdicio: una instancia siempre al límite no tiene cómo absorber un pico sin acumular cola. El endpoint de SageMaker autoescala según el tráfico, así que ese margen extra compra tiempo para que entren instancias nuevas antes de que la latencia se dispare.

La otra pieza avanzada es por qué el salto de Strands Decider 2B a la versión E4B, basada en Gemma 4, mejoró los resultados. Más parámetros en el modelo clasificador le dan más capacidad para separar etiquetas parecidas entre sí, al costo de más memoria (el endpoint usa cerca de 19 GiB) y algo más de latencia por petición. Amazon midió ambas versiones contra el mismo set de tickets de prueba antes de decidir cuál pasaba a producción, el mismo principio del modo DUAL aplicado a elegir entre dos versiones del propio decision model.

💭 Clave: el ahorro real no viene solo del modelo más chico: viene también del prompt mucho más corto. Las descripciones de las 20 etiquetas de producción ya superaban por sí solas la ventana de 4.096 tokens de Strands Decider, así que simplificarlas fue tan importante como cambiar de modelo.

📖 Resumen en Telegram: Ver resumen

Tu próximo paso: tomá 20 tickets reales de tu soporte, armá un catálogo cerrado de 10 etiquetas con una oración cada una, y medí con una regresión logística simple cuántos resuelve bien antes de pensar en reemplazar un LLM grande.

Preguntas frecuentes

¿Un modelo de decisión reemplaza siempre a un LLM como Sonnet?

No. Solo conviene cuando la tarea es elegir entre un catálogo cerrado y conocido de opciones, con volumen alto y latencia importante. Si las etiquetas necesitan explicación larga, cambian seguido, o la tarea requiere generar texto libre, un LLM general sigue siendo la mejor opción.

¿Qué pasa si el catálogo de opciones de un clasificador especializado cambia seguido?

Cada cambio de catálogo obliga a reescribir las descripciones de las etiquetas y, en muchos casos, a recalibrar el umbral de confianza. Si eso pasa cada semana, el costo de mantenimiento puede superar el ahorro en tokens, y conviene quedarse con un LLM general más flexible.

¿Cómo se despliega en producción un modelo como Strands Decider?

En el caso de Amazon, corre como un endpoint de Amazon SageMaker sobre instancias ml.g5.xlarge, con una cola SQS y una función Lambda al frente, y AWS AppConfig controlando el interruptor entre Sonnet y el modelo nuevo.

¿Un modelo de clasificación necesita reentrenarse con cada ticket nuevo?

No en el flujo normal de inferencia. El modelo se entrena, o se ajusta, una vez por versión, y después solo clasifica tickets nuevos. Solo se reentrena cuando el catálogo de etiquetas cambia de forma significativa o cuando una evaluación periódica muestra que su precisión bajó.

¿Qué pasa con la latencia de un decision model si el tráfico aumenta de golpe?

Depende del autoescalado del servicio que lo hospede. En el caso de Amazon, el endpoint de SageMaker agrega instancias nuevas a medida que sube la demanda, pero ese proceso toma tiempo, por eso el equipo deja margen de capacidad en vez de operar al límite.

¿Un LLM como Sonnet sigue siendo necesario en el mismo sistema?

Sí, para los casos que el modelo de decisión no puede resolver: tickets que no encajan en ninguna etiqueta del catálogo, o que necesitan una respuesta en texto. Muchos equipos, incluido el de Amazon, mantienen el LLM general como respaldo para esos casos.

Referencias

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.