Prompt Engineering en producto: diseño, pruebas, versiones y producción

Prompt Engineering nombra hoy cosas muy distintas. A veces se refiere a escribir una petición clara. Otras, a las instrucciones permanentes de un asistente. Y, en ocasiones, el término abarca todo el trabajo necesario para llevar ese asistente a producción. Al meter las tres cosas en el mismo saco, la palabra ingeniería pierde casi todo su significado.

Escribir bien importa. Explicar el objetivo, declarar límites, incluir ejemplos y pedir un formato concreto suele mejorar la respuesta. Pero una buena redacción no basta para controlar un comportamiento que se repetirá en producción.

Redactar un prompt es formular una instrucción. Hacer Prompt Engineering es diseñar, probar, versionar, desplegar, observar y mantener las instrucciones persistentes que condicionan el comportamiento de un sistema.

No hay una frontera aceptada por todo el mundo. La documentación de Google Cloud incluye la mejora iterativa y la evaluación de las respuestas. Anthropic utiliza una definición más estrecha y separa las instrucciones de la ingeniería de contexto. En este artículo hablo del ciclo de vida de las instrucciones que forman parte de un producto, no de toda la arquitectura que las rodea.

La diferencia aparece cuando el prompt deja de ser desechable. Si lo comparte un equipo, condiciona las respuestas de un producto o interviene en una decisión con consecuencias, «lo he probado y funciona bastante bien» deja de ser una garantía razonable.

Una respuesta buena no demuestra un comportamiento

Probar formulaciones, cambiar el orden o añadir un ejemplo ayuda a descubrir cómo interpreta el modelo una tarea. Es un trabajo útil. El resultado solo demuestra que una redacción produjo una respuesta satisfactoria en un caso.

Todavía falta saber si funcionará con entradas distintas, si mantendrá el comportamiento al cambiar de modelo o si resolver un fallo ha empeorado otra parte del producto.

Además, el rigor depende de la tarea. No es lo mismo resumir unas notas personales que clasificar incidencias que activan un proceso. Una respuesta mediocre en el primer caso puede corregirse en segundos. En el segundo, puede enviar el asunto al equipo equivocado o esconder una urgencia.

Hay ingeniería cuando se define un comportamiento que debe mantenerse, se comprueba y queda claro quién responde si deja de cumplirse.

Primero se define el resultado; después se escribe

Es habitual escribir la instrucción y decidir después si el resultado convence. En un producto conviene invertir el orden: primero se acuerda qué debe ocurrir y después se buscan las palabras.

Pensemos en un asistente que recibe consultas del alumnado y decide cuáles van a secretaría, cuáles corresponden al docente y cuáles puede responder sin intervención. «Clasifica esta consulta» no dice qué categorías existen, qué hacer con un mensaje que encaja en dos, cuándo debe abstenerse ni qué formato espera el sistema que viene después.

Las fronteras no son teóricas. «No puedo entrar en el curso» puede ser una incidencia técnica, una matrícula caducada o un curso todavía oculto. «No me aparece la nota» puede describir un fallo o una calificación que el docente aún no ha publicado. «Necesito una ampliación por enfermedad» no pide información: requiere la decisión de quien tenga autoridad para concederla.

La pregunta más delicada puede llegar acompañada de una fuente razonable. «¿Esto entra en el examen?» parece contestable desde la guía docente, pero esa guía puede describir el temario sin decidir qué se preguntará este año. Si no existe una fuente autorizada que lo aclare, el asistente debe abstenerse aunque pueda citar la guía. Esa decisión pertenece al producto, no a la improvisación del modelo ni a una instrucción genérica para que «sea prudente».

Una vez tomadas, el prompt las traduce a una instrucción que el modelo pueda interpretar. Según el caso, incluirá:

• el objetivo y el ámbito de la tarea;
• las definiciones que no deben quedar a criterio del modelo;
• la información que recibirá y la forma de distinguir datos de instrucciones;
• ejemplos y contraejemplos que aclaren fronteras reales;
• restricciones, exclusiones y condiciones de abstención;
• el formato de salida y los campos obligatorios;
• el tratamiento de entradas incompletas, ambiguas o contradictorias;
• los criterios que permiten considerar terminada la tarea.

No es una plantilla que haya que completar siempre. Una tarea sencilla puede necesitar solo dos puntos; una operación delicada quizá los necesite todos. Un prompt más largo también puede contradecirse, repetir reglas o esconder la decisión importante.

El prompt nunca se ejecuta solo

El asistente puede empezar a responder con más palabras y menos precisión aunque el prompt sea idéntico al de la semana anterior. Quizá cambió el modelo, su configuración, el esquema de salida, la descripción de una herramienta o la información añadida en cada petición. Si solo se guarda el texto de la instrucción, no se podrá saber qué ocurrió.

El contexto, la memoria y las herramientas tienen responsabilidades propias. El artículo sobre Context Engineering explica esa separación. Aun así, al comparar dos prompts hay que mantener esas condiciones iguales o registrarlas: versión de las instrucciones, modelo, configuración, datos de prueba, herramientas y esquema de salida. De otro modo, la comparación enfrentará resultados de sistemas distintos sin hacerlo visible.

Probar significa intentar que falle

Pedir cinco respuestas y escoger la preferida no es una evaluación. Solo se ha seleccionado el resultado favorable. Tampoco basta con el ejemplo que utilizó la persona que escribió el prompt: seguramente reflejará la interpretación que ya tenía en la cabeza.

Las pruebas deben salir de los usos reales y de los fallos que el producto no puede permitirse. Este clasificador debe incluir la consulta que encaja en dos categorías, la que llega sin decir de qué asignatura habla, la que mezcla un problema técnico con una petición académica, la que pide algo que el asistente no puede conceder y la que intenta que confirme una nota todavía oculta. También debe incluir la que llega cuando queda poco tiempo para cerrar una matrícula o unas actas.

Cada error encontrado en producción debe incorporarse a ese conjunto antes de preparar la siguiente versión. Es la forma de comprobar que la corrección de un caso no reintroduce el fallo de otro.

En un campus no basta con informar de una tasa de acierto. Una variación pequeña puede desviar muchas consultas cuando se concentra la matrícula o el cierre de actas. La evaluación debe traducir cada porcentaje al volumen esperado, al número de casos que llegarían a la bandeja equivocada y a la capacidad real del equipo para corregirlos. No hace falta inventar una cifra: hace falta medirla con la carga del servicio.

Cada caso necesita un criterio de éxito. Un programa puede comprobar que exista un campo o que la categoría pertenezca a una lista. La utilidad de una explicación o el tono ante una situación delicada necesitarán una guía de evaluación y, a menudo, revisión humana. Un modelo puede ayudar a aplicar esa guía, pero antes habrá que contrastar sus juicios con ejemplos revisados por personas.

La guía de Anthropic sobre evaluaciones distingue los casos, las ejecuciones y los evaluadores. La separación importa: una salida variable puede exigir varios intentos, y una media alta puede ocultar que la nueva versión falla justo en los casos más delicados.

La pregunta no es si el nuevo prompt parece mejor. Es en qué casos mejora,

cuánto mejora y qué comportamiento empeora a cambio.

Versionar para poder explicar y volver atrás

Guardar archivos llamados final, final-2 y final-bueno no permite reconstruir nada. Una versión útil conserva el texto, las variables, el motivo del cambio y las pruebas con las que se autorizó.

El historial debe permitir reconstruir qué versión estaba activa cuando apareció el error, qué diferencia introdujo la candidata, qué problema pretendía resolver, con qué casos y modelo se evaluó, quién revisó la evidencia y qué versión puede recuperarse si el resultado empeora.

Si cambian a la vez el prompt, el modelo y las fuentes, se podrá comprobar el conjunto nuevo, pero no quedará claro qué causó la diferencia. La guía de modelos de OpenAI recomienda trabajar con evaluaciones representativas y aislar los cambios cuando se quiere atribuir el resultado.

No importa tanto dónde viva ese historial como que permita revisar diferencias, identificar al responsable y recuperar la versión anterior.

Publicar un prompt es cambiar el producto

Cuando una aplicación recupera instrucciones persistentes durante la ejecución, cambiar esas instrucciones modifica el producto aunque no se despliegue código. El efecto puede ser pequeño o afectar a todas las respuestas posteriores. Por eso la publicación necesita una decisión explícita.

Una versión candidata debería superar primero sus pruebas fuera de producción. Si el riesgo lo justifica, se puede probar después con un grupo limitado o en un entorno donde no produzca efectos irreversibles. Además de la calidad, habrá que observar coste, tiempo de respuesta, errores y casos enviados a revisión humana.

Cada ejecución relevante debe poder relacionarse con la versión que la produjo. Eso no autoriza a guardar conversaciones completas de forma indefinida. A veces bastan unos identificadores y las señales necesarias para investigar un fallo.

Las quejas, las correcciones humanas y los errores repetidos revelan casos que las pruebas no contemplaban. Hay que incorporarlos antes de preparar otra versión.

El Prompt Engineering no termina al publicar una instrucción: los fallos observados en producción se incorporan al conjunto de evaluación antes de preparar la siguiente versión.

Ver a tamaño originalCerrar

Volver a una versión anterior puede detener un fallo causado por esa versión, pero no deshace un correo enviado, una compra o un borrado. Si el prompt puede desencadenar acciones, el producto también necesita límites y un procedimiento para reparar sus efectos.

Alguien tiene que responder por el comportamiento

Que esté escrito en lenguaje natural no convierte el prompt en un texto sin propietario. Alguien debe definir el comportamiento, reunir los casos reales, autorizar los cambios y poder detener una versión defectuosa. Seguridad y privacidad intervienen cuando hay datos, herramientas o efectos sensibles.

En un equipo pequeño, una persona puede asumir varias funciones. Lo importante es que no queden implícitas.

Y quien redactó el prompt no debería ser la única persona que lo aprueba. Puede haber expresado perfectamente una idea equivocada. Separar la autoría de la decisión ayuda a descubrir ese tipo de error.

El rigor depende de las consecuencias

No toda conversación necesita este proceso. Aplicar una revisión formal y un despliegue gradual a una petición de un solo uso sería burocracia.

La permanencia y el impacto ayudan a graduar el proceso:

La frecuencia tampoco es el único criterio. Una instrucción de un solo uso puede necesitar controles fuertes si desencadena una acción irreversible. Importan el alcance, la facilidad para detectar el fallo y la posibilidad de repararlo.

Entonces, ¿qué es realmente Prompt Engineering?

Las técnicas de redacción siguen siendo importantes. Un ejemplo o una restricción pueden resolver un problema real. La diferencia es que, en un producto, se tratan como cambios que deben demostrar su utilidad.

El Prompt Engineering tampoco absorbe toda la ingeniería de una aplicación de IA. El contexto, la memoria, la recuperación, los permisos, los bucles y la observación plantean problemas propios. La superficie de software alrededor de los agentes es mucho mayor que cualquier instrucción.

Un prompt que vive en un producto no se da por bueno porque una respuesta

convenza. Se publica cuando la nueva versión supera los casos conocidos y puede retirarse sin perder la trazabilidad.

Ahí está la diferencia. Redactar persigue una buena instrucción. La ingeniería permite cambiarla sin perder el control del producto.