Por qué casi todo lo que te contaron sobre LLMs en producción está a medias
He visto equipos tirar seis meses de trabajo por dar por buenas dos ideas opuestas: que un LLM funcionaba como un endpoint REST y que bastaba con lanzarlo, o que era tan impredecible que no merecía la pena sacarlo del laboratorio. Ninguna de las dos resiste el contacto con tráfico real. Según la documentación oficial de los principales proveedores de modelos, la latencia, el coste y la calidad varían de forma no lineal con el contexto, la temperatura y la longitud de la respuesta, y eso rompe muchas de las promesas que circulan en charlas y posts.
Este artículo repasa los mitos que más daño hacen al llevar modelos de lenguaje a producción y los contrasta con lo que ocurre cuando el sistema atiende usuarios reales: reintentos, prompts mal formados, datos sensibles y picos de carga. No hay garantías de resultados: hay patrones que funcionan en ciertos contextos y otros que fallan estrepitosamente.
Mito 1: «El prompt perfecto elimina la necesidad de ingeniería»
El prompt importa, pero no sustituye a la arquitectura. Un equipo con el que colaboré construyó un asistente de soporte que respondía con precisión en pruebas manuales. En producción, el mismo prompt falló en cuanto los usuarios empezaron a escribir en mayúsculas, con faltas o pegando capturas de pantalla transcritas por un OCR defectuoso. La tasa de respuestas útiles cayó sin que el modelo hubiera cambiado.
Qué sí funciona
- Validación de entrada: normalizar texto, limitar longitud y detectar idioma antes de llamar al modelo.
- Contratos de salida: exigir JSON con un esquema y validarlo con una librería; si falla, reintentar con un prompt de corrección acotado.
- Fallback determinista: para consultas de alta frecuencia, una plantilla o reglas pueden responder mejor y más barato que el modelo.
La realidad es que el prompt es una pieza del sistema, no el sistema. Los equipos maduros versionan prompts como código, los evalúan con conjuntos de casos y miden regresiones antes de desplegar.
Mito 2: «Más contexto siempre mejora la respuesta»
La ventana de contexto amplia es útil, pero no gratuita. Según la documentación de los proveedores, el coste y la latencia crecen con los tokens de entrada, y en la práctica la calidad no mejora de forma monótona: meter diez documentos irrelevantes diluye la señal y aumenta la probabilidad de que el modelo cite información tangencial.
Ejemplo concreto de fallo
En un buscador interno sobre documentación técnica, pasar de 3 a 15 fragmentos recuperados mejoró la cobertura de respuestas correctas en preguntas amplias, pero empeoró las respuestas a preguntas de detalle porque el fragmento correcto quedaba enterrado entre otros parecidos. La solución no fue ampliar el contexto, sino mejorar el ranking de recuperación y limitar a los fragmentos con mayor puntuación, con un umbral de corte.
Limitaciones que conviene reconocer
No existe un número mágico de fragmentos. Depende del dominio, de la calidad del índice y del tipo de pregunta. Cualquiera que afirme «usa siempre top-k=5» está simplificando. Hay que medirlo con un conjunto de evaluación propio.
Mito 3: «El modelo es determinista si pongo temperatura 0»
Temperatura 0 reduce la variabilidad, pero no la elimina en todos los proveedores ni en todos los modelos. Además, el determinismo aparente oculta otra fuente de variación: cambios silenciosos en el modelo alojado. Un mismo identificador puede actualizarse y alterar respuestas, algo que la documentación de varios proveedores advierte de forma explícita.
Consecuencias prácticas
- Fijar versiones concretas cuando el proveedor lo permita.
- Mantener un conjunto de pruebas de regresión que se ejecute tras cada cambio de versión.
- Registrar la versión del modelo junto a cada respuesta para poder auditar.
Si tu producto depende de que la salida sea idéntica entre ejecuciones, un LLM no es la herramienta adecuada para esa parte. Ahí conviene lógica determinista.
Mito 4: «Cuesta poco porque el token es barato»
El coste por token parece bajo hasta que se multiplica por usuarios, reintentos y contexto. Un patrón que veo con frecuencia: un chatbot que incluye el historial completo de la conversación en cada llamada. Con conversaciones de veinte turnos, el coste crece de forma cuadrática respecto al número de turnos, no lineal.
Qué se puede hacer
- Resumir el historial antiguo y conservar solo los últimos turnos relevantes.
- Cachear respuestas para preguntas repetidas, si el dominio lo permite.
- Enrutar consultas simples a modelos pequeños y reservar los grandes para casos complejos.
- Poner límites de gasto por usuario o por sesión.
No hay una fórmula universal de ahorro. Cualquier cifra que se comparta sin contexto de tráfico y longitud de contexto es anecdótica. Lo que sí es consistente: sin observabilidad de tokens de entrada y salida, el coste se descontrola.
Mito 5: «Si funciona en la demo, está listo para producción»
La demo enseña el camino feliz. Producción es el camino infeliz: entradas vacías, intentos de inyección de prompts, usuarios que piden cosas fuera de alcance, caídas del proveedor y tiempos de espera. Según estudios del sector sobre fiabilidad de servicios, los fallos de dependencias externas son una causa habitual de incidentes, y un LLM es una dependencia externa más.
Checklist mínima antes de exponerlo a usuarios
- Timeouts y reintentos con backoff exponencial, con límite de intentos.
- Circuit breaker para no martillear al proveedor cuando falla.
- Mensajes de degradación claros cuando el modelo no está disponible.
- Filtros de entrada y salida para datos personales y contenido dañino.
- Registro de trazas con prompt, respuesta, latencia y coste, con retención definida.
Nada de esto es glamuroso, pero es lo que separa un prototipo de un servicio que aguanta un lunes por la mañana.
Mito 6: «La evaluación se resuelve con buenas métricas automáticas»
Las métricas automáticas como BLEU o ROUGE tienen correlación débil con la utilidad percibida en tareas abiertas. Para un sistema de extracción de datos con esquema fijo, una métrica de exactitud funciona. Para un asistente conversacional, no.
Lo que funciona en la práctica
- Un conjunto de evaluación pequeño pero representativo, revisado por personas del dominio.
- Evaluación por pares o rúbricas para tareas subjetivas.
- Muestreo periódico de respuestas reales para detectar deriva.
Reconozco una limitación: construir y mantener ese conjunto consume tiempo y no escala tan bien como un script automático. Pero sin él, cualquier afirmación sobre la calidad del sistema es una opinión.
Mito 7: «La privacidad se arregla con un aviso legal»
Enviar datos de usuarios a un proveedor externo tiene implicaciones que un aviso no resuelve. Hay que saber qué se envía, cuánto se retiene y en qué jurisdicción se procesa. Algunos equipos descubren tarde que estaban incluyendo correos y teléfonos en los prompts porque el formulario de origen los recogía sin filtrar.
Medidas concretas
- Seudonimizar identificadores antes de construir el prompt.
- Definir qué campos nunca salen del sistema.
- Revisar las condiciones de retención del proveedor y, si es necesario, usar despliegues que no almacenen datos.
Esto no es asesoramiento legal, y conviene consultar con quien corresponda. Pero técnicamente, filtrar antes de enviar es más barato que remediar después.
Mito 8: «Un LLM sustituye al equipo de soporte o al de contenido»
Puede reducir carga en tareas repetitivas, pero introduce un coste de supervisión. Un modelo que responde con seguridad sobre temas que no domina genera más trabajo del que ahorra. En proyectos de atención al cliente, la revisión humana de respuestas de baja confianza sigue siendo necesaria para evitar errores costosos.
La realidad es más aburrida: el LLM es una herramienta dentro de un flujo, con humanos en los puntos de riesgo. Los casos donde funciona sin supervisión son aquellos con esquema cerrado y consecuencias bajas de error, como clasificar tickets o resumir textos internos.
Lo que sí conviene asumir antes de empezar
- Vas a necesitar observabilidad desde el primer día, no después.
- El coste real se entiende cuando hay tráfico, no en el laboratorio.
- La calidad se mide con datos propios, no con benchmarks públicos.
- Habrá cambios en el proveedor que afecten a tu producto sin que tú toques nada.
- Algunas tareas no deberían resolverse con un LLM: cálculos exactos, cumplimiento normativo estricto o decisiones con consecuencias irreversibles.
Implementar LLMs en producción es menos magia y más disciplina de ingeniería: versionado, evaluación, límites y degradación controlada. Los mitos venden atajos; la realidad pide medir antes de prometer.
Perfiles verificables: Sitio web
Publicado el 25 de October de 2026. Última revisión: 25 de October de 2026.