Integrar LLMs en producción no es instalar ChatGPT en tu empresa

La brecha entre la demo y la producción

Las demos de IA son engañosamente buenas. Alguien abre ChatGPT en una reunión de dirección, pega un documento, formula una pregunta compleja, y el resultado parece magia. El CTO sale convencido de que en tres meses tendrá IA integrada en el producto, y la organización ajusta su roadmap en consecuencia. Seis meses después, el equipo sigue luchando con los mismos problemas de siempre, más una factura de OpenAI que nadie entiende del todo, un prototipo que funciona el 70% de las veces y un director de operaciones que ya no cree en la IA.

Hemos construido sistemas de IA en producción para entornos tan exigentes como hospitales y plataformas farmacéuticas. La distancia entre una demo que impresiona y un sistema que funciona de forma fiable es enorme, y la mayoría de los problemas que encontramos no los anticipamos leyendo papers ni siguiendo tutoriales. Aparecieron en producción, con usuarios reales, en contextos donde el error tiene consecuencias.

La razón por la que las demos funcionan tan bien es precisamente la que las hace engañosas. Una demo es un caso cuidadosamente seleccionado con un prompt ajustado, datos limpios, sin carga concurrente, sin requisitos de latencia, sin trazabilidad, sin preocupación por coste. La producción es lo contrario: peticiones no controladas, datos sucios, picos de concurrencia, clientes que esperan respuestas en menos de un segundo, auditorías trimestrales, y facturas mensuales que hay que justificar.

Latencia: tolerable en un chat, catastrófica en un triaje

El primer problema que nadie menciona en las demos es la latencia. Un modelo de lenguaje grande puede tardar entre 3 y 15 segundos en generar una respuesta completa, dependiendo de la longitud del output, el modelo elegido y la carga del proveedor. En una interfaz conversacional tipo chat es tolerable: el usuario espera, ve el cursor parpadear, y el streaming de tokens da sensación de progreso. En un flujo de trabajo clínico o transaccional, donde el LLM es un paso intermedio en una cadena de procesamiento, esa latencia puede ser inaceptable.

La solución no es esperar a que los modelos sean más rápidos —aunque lo serán—. La arquitectura tiene que diseñarse pensando en latencia desde el principio. Eso significa streaming de respuestas para que el usuario vea el texto generarse en tiempo real, procesamiento asíncrono para tareas que no requieren respuesta inmediata, caché agresiva para queries repetidas, y en muchos casos una jerarquía de modelos: un modelo pequeño y rápido para clasificación y enrutado, y un modelo grande solo para las tareas que realmente lo justifican.

En Aedevita, nuestra plataforma de triaje dermatológico por WhatsApp, el usuario envía una foto de una lesión cutánea y espera una respuesta. La latencia percibida no podía ser de 10 segundos: diseñamos el flujo para procesar la imagen en paralelo mientras el paciente responde preguntas de contexto, de modo que cuando llega la última pregunta el análisis visual ya está listo y el LLM solo tiene que sintetizar resultados. El usuario ve una respuesta en menos de tres segundos porque el trabajo pesado ocurrió durante los veinte segundos anteriores, invisibles para él.

La latencia de un LLM se gestiona con arquitectura, no con promesas del proveedor de modelo.

Coste: cómo una integración ingenua cuesta 50.000 euros al mes

Los modelos de lenguaje se pagan por token. Un token es aproximadamente cuatro caracteres en inglés, algo menos en español. Si tu prompt de sistema tiene 2.000 tokens, lo envías con cada petición, y tienes 10.000 peticiones al día, estás mandando 20 millones de tokens diarios solo en contexto base. A precios actuales de los modelos frontier, eso puede suponer entre 3.000 y 8.000 euros mensuales en contexto que no varía entre peticiones.

Multiplica eso por una aplicación con 100.000 peticiones diarias, un prompt de sistema de 5.000 tokens y un RAG que inyecta otros 4.000 tokens de contexto por query, y la factura mensual se va a cinco cifras sin que el producto haya encontrado aún su encaje en el mercado. Hemos visto startups consumir su ronda seed en facturas de API porque nadie modeló el coste antes de integrar.

Hay soluciones técnicas: prompt caching en APIs que lo soportan (Anthropic, Google, OpenAI con ciertos modelos), compresión de contexto, separación estricta entre instrucciones del sistema —que se cachean— y contexto de usuario —que varía—, batching de peticiones no urgentes, y modelos más pequeños para los pasos donde el gigante es overkill. Pero la mejor optimización empieza antes de escribir el primer prompt: calcular el coste por transacción objetivo, dividir por el margen aceptable, y diseñar la arquitectura para caber en ese número.

La regla que aplicamos en todos nuestros proyectos es simple: antes de construir, un modelo de costes con tres escenarios —bajo volumen, caso esperado, pico—, calculado con el proveedor de modelo más probable y con una versión conservadora de los prompts. Si esos números no cierran, no es un proyecto de IA: es un experimento con un final predecible.

Alucinaciones: distintas mitigaciones para distintos dominios

Las alucinaciones —respuestas incorrectas pero convincentes— no se eliminan con mejores prompts. Se gestionan con arquitectura. Y la arquitectura correcta depende del dominio.

Un asistente conversacional que alucina una receta de cocina es un inconveniente gracioso. Un asistente clínico que alucina una dosis farmacológica es un peligro sanitario. La tolerancia al error no es una sola variable: es específica al impacto de cada tipo de error en cada dominio.

El patrón más efectivo para dominios de precisión es Retrieval-Augmented Generation (RAG): en lugar de pedirle al modelo que genere respuestas desde su conocimiento parametrizado, le proporcionamos documentos relevantes como contexto y le pedimos que responda basándose exclusivamente en ellos. El modelo pasa de generar conocimiento a sintetizar y citar información que nosotros controlamos. Combinado con outputs estructurados —JSON schemas en lugar de texto libre— que separan la clasificación de la explicación, y con umbrales de confianza que derivan los casos ambiguos a revisión humana, el patrón se vuelve viable para producción.

Para Aedevita esto era no negociable. La arquitectura combina RAG sobre guías dermatológicas validadas, outputs estructurados que separan la clasificación de riesgo de la recomendación narrativa, y un flujo de validación humana cuando la confianza del modelo está por debajo de un umbral. El dermatólogo siempre tiene la última palabra, y el sistema está diseñado para facilitársela, no para reemplazarla.

RAG en profundidad: lo que los tutoriales explican mal

RAG suena sencillo en un diagrama: partes el corpus en chunks, calculas embeddings, los guardas en una vector DB, y en runtime recuperas los k más cercanos a la query. Todos los tutoriales acaban ahí. La producción empieza justo después.

La primera decisión no trivial es la estrategia de chunking. Partir un documento en fragmentos de 500 tokens con overlap fijo funciona en la demo y falla en producción. Un chunk que corta una frase por la mitad no se recupera bien. Un chunk que mezcla dos temas distintos contamina las respuestas. En los proyectos serios que hemos hecho, el chunking es una fase de ingeniería en sí misma: chunking por estructura del documento —secciones, apartados, tablas tratadas como unidad—, metadatos que acompañan cada chunk —fuente, fecha, versión, sección padre— y reglas específicas del dominio.

La segunda es la elección del modelo de embeddings. Los modelos multilingües generalistas funcionan aceptablemente para texto general en español, pero degradan con vocabulario técnico. En proyectos clínicos hemos tenido que evaluar varios modelos contra un benchmark propio de queries reales, y la diferencia entre el modelo mejor y el peor para el dominio específico era de 15 puntos de recall.

La tercera es el scoring y re-ranking. La similitud coseno no es la última palabra: en producción hay que re-rankear los resultados con un modelo dedicado, filtrar por metadatos, y muchas veces combinar búsqueda semántica con búsqueda léxica (BM25 o equivalente). Los sistemas RAG que funcionan bien en producción son casi siempre híbridos.

Un RAG en producción no es una vector DB con un LLM encima: es chunking, embeddings, re-ranking y evaluación continua.

Evaluación: cómo saber si tu IA es realmente buena

Este es el problema que más equipos subestiman. Con software tradicional tienes tests: input, output esperado, pasa o falla. Con LLMs el output es estocástico, semánticamente válido en muchas formas distintas, y difícil de validar automáticamente.

La respuesta práctica es construir una evaluación sólida desde el principio. Un dataset de casos reales del dominio, clasificados por expertos, con anotación de qué respuesta se considera correcta y por qué. Métricas específicas: precisión en clasificaciones, tasa de respuestas fuera de dominio, fidelidad al contexto recuperado (en RAG), longitud media y estilo. Para partes subjetivas —la calidad de una explicación—, un LLM evaluador con rúbrica bien definida funciona razonablemente como proxy, siempre que se calibre contra evaluación humana periódicamente.

Para cada release del sistema, el pipeline ejecuta el benchmark automáticamente y compara con la baseline anterior. Si alguna métrica cae, el release no sale. Este proceso no es perfecto —hay dimensiones que no cubre—, pero sin él no sabes si un cambio en el prompt mejoró o empeoró el comportamiento del sistema, y acabas volando a ciegas.

En producción, el monitoreo continúa: log de todas las interacciones, muestreo aleatorio para revisión humana semanal, alertas cuando la distribución de outputs se desplaza respecto a la baseline. Los LLMs en producción se comportan distinto a los LLMs en pruebas, porque los usuarios reales hacen preguntas que nadie anticipó.

El reto organizativo: esto no lo hace un backend dev

Una confusión que vemos repetidamente: las organizaciones intentan tratar la IA como una extensión del backend. Asignan a un ingeniero de backend senior, le piden que "integre GPT-4", y esperan que en seis semanas salga algo en producción.

Los sistemas de IA en producción requieren un perfil distinto. Ingenieros de ML que sepan construir pipelines de evaluación, diseñar experimentos comparativos entre modelos, y gestionar el ciclo completo de iteración de prompts, embeddings y datasets. MLOps que sepan desplegar modelos con rollback, monitorizar drift y gestionar versionado de datasets. Product managers que entiendan que el roadmap de una feature de IA no es un diagrama de Gantt: es una serie de experimentos con resultados inciertos.

Integrar LLMs en producción es ingeniería de sistemas, no prompt engineering. Los equipos que lo hacen bien son los que tratan la IA como cualquier otro componente crítico: con arquitectura deliberada, evaluación continua, observabilidad profunda y respeto por sus limitaciones. Los que no lo hacen bien son los que confundieron una demo con una arquitectura, y la factura del mes siguiente se lo recuerda.