LLM vs. Karar Modeli (Decision Model) & Shadow Mode Geçiş Rehberi
Esta guía arquitectónica interactiva se basa en el caso real de los ingenieros de AWS Carr Onstott y Mehul Jaiswal, quienes reemplazaron Claude Sonnet 4.6 por el modelo de decisión Strands Decider E4B (basado en Gemma 4) en uno de los sistemas internos de tickets más grandes del mundo, reduciendo el coste por millón de tickets de 22.200 $ a 500 $ (un 98% de ahorro, 44 veces más barato).
El error más caro de los equipos modernos es conectar un LLM generativo enorme a una tarea de clasificación o enrutamiento de catálogo cerrado y pagar para que genere cientos de tokens de JSON y razonamiento en cada llamada. Usa la lista de 4 etapas de abajo para auditar tus propios endpoints de IA y migrar de forma segura con un interruptor Shadow Mode de 3 posiciones.
- EsencialDomínalo bien antes de postularte
- RecomendableAparece mucho en ofertas de empleo y te da ventaja
- Más adelanteCuando ya estés trabajando y lo necesites
Haz clic en un tema para ver qué necesitas saber y dónde aprenderlo.
- 01
Etapa 1: Diagnóstico — ¿Por qué generamos 170 tokens de salida?
Identifica los cuellos de botella ocultos en tu sistema que requieren una distribución de probabilidad (Decision Model) en lugar de generación de texto.
- 02
Etapa 2: Compresión de prompt y la trampa del orden de claves JSON
Comprime las definiciones de categorías para caber en la ventana de 4.096 tokens y evita el fallo del orden de claves JSON que desvía las probabilidades hasta un 0,19.
- 03
Etapa 3: Interruptor Shadow Mode de 3 posiciones (BEDROCK -> DUAL -> DECIDER)
Nunca bajes el interruptor a ciegas: ejecuta ambos modelos en paralelo sobre tráfico real con garantía de rollback en 45 segundos.
- 04
Etapa 4: Infraestructura GPU aislada y verificación del 98% de ahorro
Ejecuta el modelo en una instancia GPU A10G aislada de red y verifica la caída de coste de 22.200 $ a 500 $.
Tema por tema
Todos los temas del mapa con su descripción, qué saber y recursos, en una sola lista.
01Etapa 1: Diagnóstico — ¿Por qué generamos 170 tokens de salida?
Auditoría de cargas de trabajo de catálogo cerrado· Esencial
En el sistema interno de tickets de Amazon, las escalaciones, solicitudes de capacidad, alarmas y hallazgos de seguridad se asignaban a 20 categorías fijas. Claude Sonnet 4.6 leía 6.554 tokens de entrada y generaba 170 tokens de salida en JSON y razonamiento.
Lo que deberías saber
- Audita tus llamadas al LLM: ¿el texto JSON generado se muestra realmente al usuario o tu código solo lee un campo 'category_id' o 'route' para un bloque if/switch?
- Si tu conjunto de opciones es fijo (p. ej., de 5 a 50 etiquetas + 1 opción 'none') y no necesitas texto explicativo, es un trabajo para un modelo de decisión, no para un LLM generativo.
- Los tokens de salida suelen ser 5 veces más caros que los de entrada (15 $/1M frente a 3 $/1M) y dominan la latencia. Bajar de 170 tokens de salida a 1 reduce la latencia un 78% al instante.
Recursos
02Etapa 2: Compresión de prompt y la trampa del orden de claves JSON
Reducción de tokens de entrada de 6.554 a 2.009· Esencial
Las descripciones de etiquetas de producción para Sonnet 4.6 superaban por sí solas la ventana de 4.096 tokens de Strands Decider. El equipo reescribió cada una de las 20 etiquetas en un criterio claro de 1 o 2 frases.
Lo que deberías saber
- Elige la versión E4B basada en Gemma 4 frente a la 2B; en las pruebas de Amazon, E4B superó tanto a la 2B como a Claude Sonnet 4.6 en producción.
- Reescribe cada opción como un criterio de 1-2 frases e incluye siempre una opción 'none' para no forzar al modelo a adivinar.
- En tickets o documentos largos, descarta primero los comentarios más antiguos para mantener el payload dentro de los 4.096 tokens.
Trampa crítica: el orden de claves JSON (desviación de probabilidad de 0,19)· Esencial
El hallazgo más sorprendente de los ingenieros de Amazon: ¡enviar exactamente el mismo contenido con las claves JSON en distinto orden movió las probabilidades de salida hasta en 0,19 (19%)!
Lo que deberías saber
- Antes de enviar un payload JSON a un modelo de decisión, serializa de forma determinista todos los objetos con claves ordenadas alfabéticamente (sort_keys=True).
- Ajusta un umbral de confianza estricto antes de aplicar una etiqueta; si la puntuación queda por debajo, abstente o redirige a un fallback.
03Etapa 3: Interruptor Shadow Mode de 3 posiciones (BEDROCK -> DUAL -> DECIDER)
Ejecución en 3 modos mediante Feature Flag / AppConfig· Esencial
Activada por SQS, la Lambda de etiquetado lee un ajuste de 3 posiciones en AWS AppConfig en cada mensaje: BEDROCK (solo Sonnet), DUAL (ambos en paralelo; se aplica Sonnet y se registran discrepancias) y DECIDER (solo Strands Decider).
Lo que deberías saber
- Paso 1 (BEDROCK / LLM actual): Tu ruta de producción base; aún no se llama al nuevo modelo de decisión.
- Paso 2 (DUAL / Shadow Mode): Se llama en paralelo a Sonnet 4.6 y a Strands Decider con tráfico real. Se aplica la etiqueta de Sonnet y se registra cada discrepancia para evaluarla.
- Paso 3 (DECIDER / Corte completo): Cuando el análisis de discrepancias demuestra que el modelo de decisión supera al LLM, se pasa a DECIDER. Revertir es un cambio de configuración de 45 segundos.
04Etapa 4: Infraestructura GPU aislada y verificación del 98% de ahorro
SageMaker ml.g5.xlarge (1x A10G 24GB) y aislamiento de red· Esencial
Strands Decider E4B consume unos 19 GiB de VRAM en una sola GPU NVIDIA A10G de 24 GB (ml.g5.xlarge a 1,408 $/h) y responde en 640 ms (897 ms de extremo a extremo).
Lo que deberías saber
- Copia los pesos del modelo desde S3 antes del arranque y aísla por completo la red del contenedor sin acceso saliente a internet.
- Una instancia ml.g5.xlarge procesa ~5.600 tickets/hora: 250 $ por millón de tickets a plena carga, o ~500 $ en la práctica con margen para picos (¡44 veces más barato que los 22.200 $ de Sonnet 4.6!).
- Beneficio extra: al caer la latencia de 4.215 ms a 897 ms, ¡la duración media de ejecución de AWS Lambda también baja un 74%!
Recursos