Señales de alerta en productos con LLM

Si ya estás construyendo un producto con LLM, seguro te pasó esto: el demo se ve increíble, pero cuando lo metes en manos reales empiezan los problemas. El modelo se inventa cosas, la latencia sube, el costo por usuario se dispara y tu equipo termina metiendo parches sobre parches. Ese momento suele sentirse como “algo está mal”, pero en realidad casi siempre hay señales bastante claras.

Este artículo resume esos patrones de mal diseño en productos con LLM. No es una lista teórica para hacer cosplay de arquitectura. Es una guía para founders y devs que ya chocaron con estos problemas y necesitan reconocerlos rápido, antes de que el producto se vuelva caro, frágil o imposible de mantener.

Cuando el LLM está en el centro de todo

Una de las primeras señales de alerta es simple: el producto depende del LLM para tareas que no deberían depender de un LLM. Si tu flujo completo se rompe porque el modelo no siguió una instrucción, probablemente estás usando IA como pegamento universal en lugar de usarla donde aporta valor real.

Esto se ve mucho en apps que intentan hacer demasiadas cosas con una sola caja de texto. El usuario escribe cualquier cosa, el modelo decide intención, extrae datos, ejecuta acciones, redacta respuestas y además “razona” sobre reglas de negocio. En papel suena elegante. En producción, cada paso agrega incertidumbre.

La documentación oficial de OpenAI insiste en separar tareas, evaluar salidas y diseñar con límites claros. Vale la pena leer la guía de prompt engineering y evaluación de la API de OpenAI: https://platform.openai.com/docs/guides/prompt-engineering y https://platform.openai.com/docs/guides/evals.

Señal 1: el modelo hace trabajo que sí podías programar

Si necesitas que el LLM ordene una lista, valide un formato, clasifique un valor cerrado o calcule algo determinista, probablemente estás pagando tokens para una tarea que un parser, una regex o una función normal resuelve mejor. Eso no solo sube el costo, también mete variabilidad donde no la necesitas.

Ejemplo realista: un flujo de soporte donde el modelo recibe un correo y devuelve prioridad, categoría y acción. Si prioridad solo puede ser baja, media o alta, no dejes que el modelo “redacte” una explicación antes de asignarla. Pídele un JSON estricto, valida el esquema y deja la lógica de negocio fuera del prompt.

Señal 2: todo depende de un prompt gigante

Otra alerta clásica es el prompt monstruo de 2.000 palabras con reglas, excepciones, ejemplos, tono, formato, política comercial y pasos de negocio. Al principio parece una solución rápida. Después nadie sabe qué parte del prompt arregla o rompe una salida.

Cuando el prompt se vuelve una especie de código oculto, tu equipo pierde capacidad de iterar. Cambiar una frase puede afectar 20 casos de uso. Y si el producto tiene varias rutas, el prompt termina intentando cubrir todo y no cubre nada bien.

Fricción entre UX y capacidad real

Muchos productos con LLM fallan porque prometen una experiencia más simple de la que el modelo realmente puede sostener. El problema no es solo técnico. También es de diseño de interacción. Si tu interfaz sugiere certeza donde solo hay probabilidad, el usuario va a desconfiar rápido.

La UX de un producto con LLM tiene que reflejar límites. Si el sistema puede fallar, debes mostrar qué hizo, qué no pudo hacer y cómo corregirlo. Si ocultas esa fricción, el usuario siente que el producto “piensa mal” cuando en realidad el producto está mal diseñado.

Aquí no sirve vender magia. Sirve diseñar expectativas. Y eso se nota mucho en productos para LatAm, donde los usuarios suelen ser más sensibles a errores que afectan tiempo, dinero o atención al cliente.

Señal 3: el usuario no sabe qué parte automatiza el sistema

Si no queda claro qué hace el LLM y qué hace el sistema alrededor, el usuario no entiende cómo usarlo ni cómo confiar en él. Por ejemplo, una herramienta que “redacta contratos” pero no explica qué cláusulas cambió, qué fuentes usó o qué campos dejó vacíos termina generando más revisión manual de la que ahorra.

Una buena regla práctica: si la salida del modelo necesita revisión humana, la interfaz debe mostrar diferencias, fuentes o decisiones. Si no puedes enseñar eso, al menos deja un camino de edición claro y rápido.

Señal 4: la experiencia depende de pedirle al usuario que “prompte mejor”

Cuando un producto responde mal y la solución es decirle al usuario que escriba mejor, el diseño ya falló. Sí, hay casos donde una mejor instrucción ayuda. Pero si toda la UX depende de que la persona adivine cómo hablarle al sistema, estás externalizando el trabajo del producto.

Un producto serio reduce ambigüedad con botones, plantillas, campos guiados y ejemplos concretos. No obliga al usuario a convertirse en prompt engineer para completar una tarea simple.

Costos, latencia y escalabilidad: los tres golpes juntos

Hay una combinación que mata muchos productos con LLM: el costo por interacción sube, la latencia empeora y el margen desaparece. A veces el equipo mira solo el costo del modelo y se olvida de que el verdadero gasto está en repetir llamadas, reintentos y prompts largos.

Pongamos un caso sencillo. Si una interacción usa 3 llamadas al modelo, cada una con contexto largo, y además haces reintentos por errores de formato, tu costo real no es el de una sola respuesta. También pagas por el tiempo del usuario esperando y por la infraestructura que sostiene esa espera.

En productos con usuarios de LatAm, esto se siente más porque el contexto de conectividad y dispositivos es más variable. Una app lenta en escritorio ya molesta; una app lenta en móvil, con red inestable, directamente se abandona.

Señal 5: el producto no tiene presupuesto de tokens

Si nadie en el equipo puede responder cuánto cuesta una conversación típica, tienes un problema. No hace falta una precisión quirúrgica desde el día uno, pero sí necesitas una cifra aproximada por flujo. Sin eso, no sabes si tu producto escala o si solo funciona en demos.

Haz este ejercicio con datos reales de uso. Mide:

1. tokens de entrada por caso de uso
2. tokens de salida por caso de uso
3. número promedio de llamadas por tarea
4. porcentaje de reintentos
5. latencia p50 y p95

Si no tienes observabilidad para eso, estás volando a ciegas.

Señal 6: cada interacción necesita demasiados round trips

Cuando un producto hace una llamada al modelo para entender, otra para extraer, otra para validar y otra para responder, la experiencia se vuelve lenta y cara. A veces se puede resolver con una sola salida estructurada. Otras veces conviene mover validaciones fuera del LLM.

La pregunta útil es: ¿cuántas decisiones realmente necesitan lenguaje natural? El resto puede vivir en código, reglas o estados explícitos.

Datos, contexto y alucinaciones: el triángulo que rompe productos

Muchos equipos hablan de “alucinaciones” como si fueran un bug aislado. En realidad, casi siempre son el síntoma de un diseño pobre de contexto. Si el modelo no tiene acceso a la información correcta, o si le das demasiada información irrelevante, la probabilidad de respuestas malas sube.

El error típico es pensar que más contexto siempre ayuda. No. Más contexto sin curación puede empeorar la salida. El modelo se distrae, mezcla instrucciones y responde con seguridad sobre datos que no vio o entendió mal.

Para productos con datos propios, la pregunta no es solo “qué modelo usamos”. La pregunta es “cómo obtenemos, filtramos y presentamos el contexto correcto en cada paso”. Ahí es donde se juega la calidad real.

Señal 7: el RAG está puesto como parche universal

Si todo se resuelve agregando RAG, probablemente estás usando recuperación de información para tapar problemas de producto. RAG ayuda cuando el modelo necesita fuentes específicas. No reemplaza un buen modelo de datos, ni una taxonomía clara, ni una UX que guíe al usuario.

Además, RAG mal implementado introduce otro problema: recuperas documentos parecidos pero no relevantes. Entonces el modelo responde con algo que suena plausible y está respaldado por la fuente equivocada.

Señal 8: no puedes rastrear de dónde salió una respuesta

Si el usuario pregunta “¿por qué me dijiste esto?” y tu producto no puede mostrar trazabilidad, estás construyendo sobre arena. En sectores como legal, salud, finanzas o ecommerce, esa trazabilidad no es un lujo. Es parte del producto.

Un buen diseño guarda el prompt, la versión del modelo, los documentos recuperados, el resultado intermedio y la respuesta final. No para obsesionarse con logs, sino para poder depurar y explicar errores.

Señales de que tu equipo está sobreajustando el producto al modelo

Otra alerta menos obvia es cuando el roadmap empieza a girar alrededor de las limitaciones del modelo en vez de alrededor del problema del usuario. El equipo deja de preguntar “qué necesita la persona” y empieza a preguntar “cómo hacemos para que el LLM no se equivoque tanto”.

Ese cambio de foco suele terminar en producto inflado. Agregas confirmaciones, retries, filtros, clasificaciones auxiliares y capas de validación hasta que el sistema parece más un laboratorio que una herramienta útil.

No se trata de evitar controles. Se trata de no construir una arquitectura entera para compensar una propuesta de valor débil. Si el producto solo funciona cuando el modelo acierta demasiado seguido, quizá el problema está en la propuesta, no en el prompt.

Señal 9: el roadmap está lleno de parches defensivos

Cuando ves tareas como “agregar otro validator”, “meter una segunda llamada para revisar la primera”, “crear un prompt más estricto” o “poner otro filtro para casos raros”, vale la pena frenar y revisar el diseño base.

Una lista de parches no es una estrategia. Es una señal de que el sistema ya está luchando contra su propia complejidad.

Señal 10: el equipo no define qué es éxito ni qué es error

Si no hay métricas claras, todo se vuelve subjetivo. “Se siente mejor”, “parece que responde más natural”, “el cliente dijo que le gustó” no alcanzan para operar un producto con LLM.

Necesitas métricas por tarea. Por ejemplo:

• exactitud de extracción de campos
• tasa de respuesta aceptable por revisión humana
• tiempo hasta primera respuesta útil
• porcentaje de conversaciones que terminan sin intervención
• costo promedio por tarea completada

Sin eso, no sabes si una nueva versión mejoró el producto o solo cambió el estilo de las respuestas.

Qué hacer cuando ya detectaste el olor

Si ya reconociste varias de estas señales, no hace falta tirar todo y empezar de cero. Pero sí necesitas ordenar el sistema. La salida casi nunca es “usar un modelo más grande”. La salida suele ser reducir ambigüedad, cortar pasos y separar responsabilidades.

Empieza por mapear cada flujo y marcar qué parte requiere lenguaje natural y qué parte no. Después define dónde entra el contexto, dónde se valida, dónde se registra y dónde se muestra al usuario. Eso te va a enseñar rápido si el LLM está en el lugar correcto.

Una secuencia útil para equipos que ya están en producción es esta:

1. medir costo, latencia y tasa de error por flujo
2. eliminar tareas deterministas del LLM
3. reducir prompts largos a instrucciones y ejemplos mínimos
4. exigir salidas estructuradas cuando sea posible
5. agregar trazabilidad para depurar respuestas
6. diseñar fallback humano o manual para casos críticos

Si quieres una referencia técnica de salidas estructuradas, la documentación oficial de OpenAI sobre structured outputs y function calling es un buen punto de partida: https://platform.openai.com/docs/guides/structured-outputs y https://platform.openai.com/docs/guides/function-calling.

También conviene revisar la documentación de Anthropic sobre prompt engineering y tool use si trabajas con Claude: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview y https://docs.anthropic.com/en/docs/build-with-claude/tool-use.

Tabla resumen

Si tu producto con LLM ya está creciendo, estas señales te ahorran semanas de iteración inútil. No porque el modelo sea malo, sino porque el diseño alrededor del modelo suele estar mal resuelto. Cuando detectas el olor temprano, puedes corregir arquitectura, UX y métricas antes de que el problema se vuelva estructural.