Las Apps de LLM son Impredecibles por Diseño

A diferencia de una función normal, una llamada a un LLM es probabilística, lenta, costosa y puede ser dirigida por su entrada. Ponerla en producción significa añadir las capas que el software ordinario no necesita: evaluación, seguridad, caché y observabilidad. El prompt no es el producto; el sistema alrededor del prompt lo es.

Evals: Los Tests Unitarios de las Apps de LLM

No puedes lanzar lo que no puedes medir. Los evals son conjuntos de pruebas puntuados que bloquean cada cambio de prompt o modelo:

| Tipo de eval | Mide | |---|---|| | Conjunto dorado | Corrección en casos conocidos y curados | | LLM-as-judge | Puntuación de calidad en salidas abiertas | | Conjunto adversarial | Resistencia a jailbreaks e inyecciones | | Latencia/costo | Presupuesto operativo |

Cada edición de prompt es una candidata a liberación: ejecuta los evals, compara con el prompt anterior y bloquea en caso de regresión. Esta es la práctica con mayor impacto en la ingeniería de LLM.

Inyección de Prompts y Jailbreaks

La entrada a un LLM es código no confiable. Un usuario puede escribir “ignora todas las instrucciones anteriores y …” directamente en su mensaje. Defensas:

• Separar y etiquetar instrucciones de datos en el prompt.
• Guardrails que clasifiquen entradas y salidas por inyección o violaciones de política.
• Mínimo privilegio — no des al modelo acceso a herramientas que no necesita.
• No confiar en la salida del modelo con privilegios del sistema — valida y autoriza cualquier llamada a herramientas.

Asume que la inyección es posible y diseña de modo que una inyección exitosa no pueda escalar.

Capas de Guardrails

Los guardrails están antes y después del modelo, como componentes verificables:

1. Capa de entrada — detectar inyección, PII, temas bloqueados; aplicar límites de velocidad.
2. Capa del modelo — decodificación restringida, dominio permitido, grounding RAG.
3. Capa de salida — validar formato, redactar PII, marcar violaciones de política.

Los guardrails son clasificadores y reglas económicas, no más prompting — se ejecutan en cada solicitud y se prueban de forma independiente.

Caché y Control de Costos

Los tokens de un LLM cuestan dinero por solicitud. Las preguntas repetidas (FAQ, consultas comunes, resúmenes en caché) nunca deben llegar al modelo dos veces:

• Caché semántico — hash del embedding de la consulta; en una coincidencia cercana, devuelve la completación almacenada.
• Reutilización de KV-cache — prompts de sistema compartidos evitan re-procesar prefijos comunes.
• Agrupación y elección de proveedor — lotes más grandes y el modelo suficiente y más barato.

Establece presupuestos por funcionalidad y añade una verificación de presupuesto de latencia/costo a la suite de evals.

Observabilidad y Trazas

Los fallos de LLM no son excepciones: no hay excepciones. Necesitas trazas: el prompt enviado, el contexto recuperado, los tokens generados, la latencia, el coste y la salida final, por solicitud. La práctica estándar son trazas de OpenTelemetry con la carga útil del prompt/respuesta adjunta, más un ID de traza por sesión para poder reproducir exactamente una queja del usuario. Sin trazas, depurar una mala respuesta es arqueología.

Versionamiento de Prompts, Modelos y Datos

Los prompts, versiones de modelos y datos RAG cambian de forma independiente. Los sistemas de producción versionan las tres juntas por release, de modo que una funcionalidad desplegada es la tupla (prompt v7, modelo gpt-x-v2, índice 2026-03-01). El rollback restaura la tupla. Los prompts no versionados son software no desplegable.

Gobernanza y Cumplimiento

Las salidas del modelo pueden exponer datos privados, producir textos con derechos de autor, o tomar decisiones que requieren revisión humana. Postura práctica:

• Registra entradas/salidas con retención y controles de acceso.
• Enruta prompts con PII a proveedores/regiones aprobados.
• Añade revision humana para decisiones de alto impacto.
• Documenta el modelo, la procedencia de los datos de entrenamiento y los resultados de evaluación.

Trayectoria de Práctica

1. Escribe tres casos dorados para un chatbot de soporte y puntúalos.
2. Diseña un prompt resistente a inyección más una verificación de guardrails.
3. Dibuja un caché semántico y explica el umbral de coincidencia cercana.
4. Lista las trazas que una traza de producción debe capturar para replay.
5. Define la tupla de liberación que una funcionalidad de LLM de producción debe versionar.