Por qué los servicios LLM ignoran tus instrucciones y cómo recuperar el control de verdad

El error principal al trabajar con LLM en producción es creer que un buen prompt equivale a un contrato fiable. En la práctica, el modelo no ejecuta instrucciones como un programa: cada vez compone de forma probabilística la siguiente respuesta a partir de todo el contexto a la vez. Por eso, incluso una petición perfectamente redactada de devolver JSON limpio puede acabar con una envoltura de markdown, explicaciones superfluas o una disculpa cortés en lugar del formato requerido. Cuanto más tiempo intenta un equipo arreglarlo con nuevas frases en el prompt, más crece la sensación de que el servicio vive su propia vida.

El artículo repasa un escenario que a muchos les resultará familiar: un desarrollador escribe un prompt detallado, añade ejemplos, prohíbe expresamente el formato y luego baja la temperatura a cero. El formato sí se vuelve más uniforme, pero las respuestas pierden contenido y variedad. El siguiente paso suele ser previsible: cambiar el modelo barato por uno más potente. A veces ayuda, pero el precio de la estabilidad se dispara y el problema de fondo no desaparece. El modelo sigue sin estar obligado a seguir una instrucción con la rigidez de un parser, un compilador o un esquema de API.

La causa está en cómo está construido un servicio LLM. Para el modelo, el prompt del sistema, la entrada del usuario, los ejemplos del historial y los mensajes de servicio ocultos son partes de un mismo contexto que compiten entre sí por influir en la respuesta final. Si la petición contiene un conflicto, el modelo no siempre elige la instrucción que el equipo de producto considera prioritaria.

De ahí los fallos típicos: se rompe el formato, se confunde la prioridad de las reglas y un texto inesperado del usuario empieza a cambiar el comportamiento del asistente. Por eso una sola frase corta como «ignora las instrucciones anteriores» puede destruir un escenario cuidadosamente montado si no hay capas adicionales de protección a su alrededor.

Otro problema es creer que la calidad se compra con solo cambiar de modelo. Los modelos más potentes sí mantienen mejor el formato, pierden el contexto con menos frecuencia y manejan con más cuidado las instrucciones complejas. Pero si la arquitectura del servicio se apoya en un único mensaje del sistema y en la esperanza de que el usuario se comporte correctamente, un modelo caro solo hace que el mismo esquema sea algo menos frágil.

En producción, eso no basta. Hacen falta modos de salida estructurada cuando sea posible, validación estricta de la respuesta tras la generación, reintentos que repitan la consulta solo para la parte problemática, aislamiento de la entrada del usuario respecto a las instrucciones críticas, límites en las herramientas y los permisos del modelo, y un tratamiento explícito de la inyección de prompts como una clase de ataques, no como una rareza ocasional del chat.

De aquí se desprende una conclusión de ingeniería importante: conviene ver al LLM no como un empleado listo que entendió la tarea a la primera, sino como un componente inestable en la cadena de procesamiento de datos. Necesita las mismas prácticas que cualquier dependencia externa: contrato de entrada y salida, monitorización de errores, conjuntos de pruebas, comparación de modelos con casos reales, medición del coste de cada punto porcentual de calidad y escenarios de respaldo seguros. De lo contrario, cada nuevo ajuste solo enmascarará el síntoma en lugar de eliminar el origen de la inestabilidad. Un buen prompt sigue siendo importante, pero debe ser solo una capa del sistema, no el sistema entero.

Ese es el sentido principal del artículo: el problema de las respuestas desobedientes no empieza por una mala redacción, sino por la falsa expectativa de que una instrucción de texto garantiza por sí sola el control. Un LLM puede ser útil, rápido y económicamente justificado, pero solo si a su alrededor se construyen restricciones, comprobaciones y protección frente a fallos. Cuanto antes deje un equipo de tapar agujeros de arquitectura con un párrafo más en el prompt y adopte un enfoque de ingeniería, antes empezará el servicio a comportarse de forma predecible.