La parte más subestimada de construir un producto con LLMs no es el modelo, ni el RAG, ni el fine-tuning. Es la disciplina de iterar prompts hasta que producen lo que necesitas, una y otra vez, sin sorpresas. No voy a publicar los prompts específicos de ReclamaAI — esos son trabajo de muchas iteraciones y son una parte real del producto. Pero los principios se pueden compartir, y son los que más me hubieran ahorrado tiempo si alguien me los hubiera dicho al empezar.
Los modelos aprenden por imitación, no por instrucción
La diferencia entre escribir "redacta de forma profesional, conciso, en español formal" y mostrar dos o tres ejemplos completos de lo que quieres es enorme. Las instrucciones son ambiguas: "profesional" significa cosas distintas para humanos distintos y para el modelo es ruido. Los ejemplos son inequívocos.
Si te encuentras escribiendo tres párrafos de instrucciones sobre tono, formato o estilo, probablemente lo que necesitas en su lugar es uno o dos ejemplos bien elegidos. Eso solo cambia cuánto y qué tan consistente produce el modelo.
Separa el "quién eres" del "qué hago"
El system prompt define la personalidad — el "tú": tono, audiencia, qué evitar, qué priorizar. El user prompt define la tarea concreta — el "esto": los datos del caso, la entrada del usuario, lo que hay que producir.
Cuando mezclas las dos cosas en un solo bloque, el modelo pierde el rastro de a quién está siendo cuando el contexto se llena. Mantenerlas separadas no solo es más limpio organizacionalmente; es más confiable en producción.
Los anti-ejemplos importan tanto como los ejemplos
Mostrar lo que NO hacer es a veces más útil que mostrar lo que sí. Un anti-ejemplo bien elegido elimina un patrón de error que diez líneas de instrucciones no logran erradicar. Funciona especialmente bien para errores de protocolo, de tono, o de convención específica de un dominio: cosas donde "sabes que está mal cuando lo ves" pero te cuesta articular la regla.
La evaluación importa más que el prompt en sí
La pregunta no es "¿este prompt es bueno?". La pregunta es "¿cómo sé que este prompt es mejor que el anterior?". Sin evaluación sistemática, estás iterando en la oscuridad.
No necesitas evaluación elegante para empezar. Lo que sí necesitas es un set de casos representativos que cubran la variedad real de tu producto, y un proceso de revisión consistente. Si cada cambio de prompt no pasa por ese filtro, eventualmente vas a romper algo en producción que era invisible en local.
Trata los prompts como código
Versionados en git. Con historial. Con un proceso de cambio. Si "actualizar el prompt" en tu proceso significa "abrir un archivo y editarlo en producción", vas a vivir noches incómodas.
La regla mental simple que aplico: si rompes un prompt, deberías poder revertir en menos de 30 segundos. Si rompes un prompt y necesitas una hora para recordar qué cambiaste, tu sistema de versionado falló.
Lo que no funciona (y la gente sigue intentando)
Algunas cosas que probé y no resolvieron lo que prometen:
- Pedirle al modelo que "piense paso a paso" cuando ya no aplica. Chain-of-thought ayuda en razonamiento explícito, no en tareas creativas o de redacción donde el output esperado ya tiene su propia estructura.
- Hacer prompts ultra largos "por si acaso". Más instrucciones no es más calidad. Cada instrucción adicional dispersa la atención del modelo y aumenta el costo. Los prompts largos rara vez ganan contra prompts cortos con buenos ejemplos.
- Usar otro LLM como verificador del primero. Suena seguro, no lo es. El modelo que se equivocó tiene altas probabilidades de "validar" su propio error. La verificación confiable viene de reglas explícitas o de humanos, no de otra capa de modelo.
Lo que sigue siendo difícil
El primero es cómo medir "calidad subjetiva" de forma reproducible. En dominios donde una respuesta puede ser correcta de muchas formas distintas, tu evaluación termina siendo opinión disfrazada de métrica. He probado rúbricas, escalas Likert, comparaciones pareadas, y todas tienen el mismo problema: el resultado depende más del evaluador que del modelo.
El segundo es cómo evolucionar un sistema de prompts cuando el modelo cambia. Cada versión nueva del proveedor puede romper sutilezas en las que invertiste semanas: tonos que ya no salen igual, formatos que el modelo nuevo prefiere ignorar, instrucciones que antes funcionaban y ahora no. No hay una solución limpia — solo hay disciplina de tener un eval estable que detecte la regresión rápido.
Lo que sí cambió mi forma de pensar el problema: dejé de buscar trucos sueltos y empecé a pensar en el sistema completo de cómo escribo, evalúo, versiono y revierto prompts. Eso es la diferencia entre tener un pipeline que mejora mes a mes y uno que se rompe la semana que el proveedor lanza una versión nueva.