Prompt Engineer

Empiezo escribiendo la especificación de la tarea antes de escribir una sola línea de prompt: el formato de entrada exacto, el esquema de salida exacto, y tres o cuatro ejemplos trabajados de cómo es una respuesta correcta, incluyendo al menos un caso límite. Redacto la primera versión como una instrucción directa con un rol claro y restricciones, y la pruebo contra un conjunto de prueba construido a mano de unos veinte casos que cubran el rango de entradas reales, no solo las fáciles. A partir de ahí itero con un ciclo ajustado: cambio una sola variable cada vez, ya sea la redacción de la instrucción, la selección de ejemplos o el formato de salida, y compruebo contra el conjunto de prueba antes de pasar al siguiente cambio, porque apilar varias ediciones a la vez hace imposible saber qué ayudó realmente. Una vez que el prompt es estable en el conjunto construido a mano, amplío el conjunto de prueba con datos parecidos a producción y lo paso por un framework de evaluación como promptfoo o Braintrust para detectar regresiones automáticamente. Solo después añado restricciones de salida estructurada y gestión de respuestas mal formadas. Guardo cada versión en control de versiones junto con los resultados de evaluación, para que un cambio de prompt se pueda revisar igual que un cambio de código.

Un cambio de prompt solo es real si mueve una métrica que definí antes de hacer el cambio, así que el primer paso siempre es tener un conjunto de evaluación fijo y un método de puntuación establecido. Para tareas con una respuesta correcta clara, como extracción o clasificación, puntúo por coincidencia exacta o comparación estructurada. Para generación abierta, uso un montaje de LLM-as-judge con una rúbrica detallada, contrastado con una muestra etiquetada por humanos de al menos treinta casos para confirmar que el modelo juez coincide con el juicio humano lo suficiente como para confiar en él. Siempre ejecuto el prompt nuevo y el antiguo contra el mismo conjunto de evaluación en la misma sesión, no de forma secuencial días después, porque el comportamiento del modelo se desvía incluso con un prompt fijo cuando los proveedores actualizan sus modelos en silencio detrás de una API. Miro la distribución completa de las puntuaciones, no solo la media, porque un cambio que ayuda al caso mediano pero rompe una categoría concreta de casos límite no es una mejora neta aunque la media suba. Solo despliego el cambio una vez que el conjunto de evaluación muestra una ganancia clara y reproducible, y mantengo etiquetada la versión anterior del prompt para poder revertir rápido si las señales de producción contradicen la evaluación offline.

La elección del modelo depende de la complejidad de la tarea, el presupuesto de latencia y el coste por solicitud, aproximadamente en ese orden. Para tareas simples de clasificación o extracción uso por defecto un modelo más pequeño y rápido, porque un modelo de razonamiento de gama alta suele ser gasto desperdiciado en una tarea que no necesita razonamiento en varios pasos. Para tareas que requieren razonamiento genuino, uso de herramientas o síntesis sobre contexto largo, recurro a un modelo frontier y acepto el compromiso de latencia y coste, porque equivocarse cuesta más que los tokens de más. Comparo dos o tres modelos candidatos contra mi conjunto de evaluación antes de decidir, en lugar de elegir por reputación general, porque el modelo que mejor rinde en benchmarks públicos no siempre es el que mejor rinde en mi tarea y mis datos concretos. Cuando un proveedor lanza una nueva versión de modelo, nunca dejo que se actualice automáticamente en producción sin pasar antes la suite de evaluación completa, porque incluso un cambio de versión menor puede alterar el comportamiento lo suficiente como para romper un prompt que dependía de las particularidades del modelo anterior. Fijo las versiones de modelo explícitamente en la configuración y trato una actualización como un release deliberado y probado, igual que trataría una subida de versión de una dependencia en el código de la aplicación.

Trato la reducción de alucinaciones como un problema por capas en lugar de algo que arregla un solo ajuste de prompt. A nivel de prompt, instruyo explícitamente al modelo para que diga cuándo no sabe algo en lugar de adivinar, y le doy permiso para responder 'información insuficiente' como salida válida, porque los modelos alucinan a menudo porque el prompt exige implícitamente una respuesta. Para cualquier cosa factual, ancoro la respuesta en material fuente recuperado en lugar de confiar en el conocimiento paramétrico del modelo, y le pido que cite el pasaje concreto que usó, lo que mejora la precisión y me da una forma de verificar la respuesta automáticamente. Uso formatos de salida estructurados siempre que puedo, porque forzar al modelo a un esquema reduce el margen para una fabricación que suene convincente. Para salidas de alto riesgo añado un paso de autoverificación, una segunda llamada que comprueba la primera respuesta contra el material fuente y marca las afirmaciones no respaldadas. Ninguna de estas técnicas es perfecta por sí sola, pero combinadas capturan la mayoría de lo que un solo prompt bien escrito deja pasar, y sigo la tasa de alucinación residual mediante mi conjunto de evaluación para saber si el enfoque por capas realmente funciona o solo añade latencia.

Había construido un prompt que clasificaba los tickets de soporte entrantes en una de doce categorías, con una precisión superior al 95% sobre mi conjunto de prueba de doscientos ejemplos etiquetados. En producción, la precisión cayó a alrededor del 78% en la primera semana. Al investigar los fallos, el patrón era claro: mi conjunto de prueba se había construido a partir de tickets históricos todos en inglés, pero aproximadamente una cuarta parte del tráfico real llegaba en francés y español, y el modelo caía por defecto en una categoría genérica 'otros' cada vez que cambiaba el idioma de entrada, algo que el prompt original nunca abordaba porque no se me había ocurrido comprobar la distribución de idiomas del tráfico real frente a mi conjunto de prueba. Reconstruí el conjunto de evaluación para reflejar la mezcla real de idiomas, añadí ejemplos multilingües explícitos al prompt, y añadí un paso de detección de idioma antes para que el prompt de clasificación recibiera una pista de idioma en lugar de adivinar. La precisión se recuperó al 93% en los tres idiomas en pocos días. La lección: un conjunto de prueba construido a partir de una muestra conveniente, en lugar de una que refleje realmente la distribución de producción, siempre sobreestimará lo bueno que es un prompt.

Un product manager quería que el asistente de soporte diera respuestas definitivas sobre si una acción concreta afectaría a la garantía de un cliente, redactadas con plena confianza en lugar de con matices, porque las pruebas de usuario mostraban que las respuestas matizadas frustraban a la gente. El problema era que las condiciones de garantía variaban según la línea de producto y la fecha de compra, y nuestro sistema de recuperación no siempre tenía cobertura completa de las políticas de casos límite, así que una respuesta segura pero incorrecta suponía un riesgo financiero y de confianza real. Preparé un breve análisis mostrando las categorías de preguntas de garantía donde nuestra confianza de recuperación era realmente alta frente a aquellas donde era escasa, y propuse un camino intermedio: respuestas directas y seguras para las categorías de alta confianza, y una derivación explícita de 'te pongo en contacto con un especialista' para las categorías de cobertura escasa, en lugar de una política uniforme de respuestas seguras en todos los casos. Respaldé esto con las puntuaciones reales de confianza de recuperación de una muestra de dos semanas en lugar de un argumento de riesgo abstracto, lo que hizo el compromiso concreto para el product manager en vez de teórico. El equipo de producto aceptó el enfoque escalonado, y se lanzó sin una sola queja relacionada con garantías en el trimestre siguiente.

Heredé un prompt para generar resúmenes de reuniones que los usuarios puntuaban de media un 2,9 sobre 5, y la queja más común era que los resúmenes se perdían acciones enterradas en conversación informal en lugar de enunciadas formalmente. Cogí cincuenta de las transcripciones peor puntuadas y las leí manualmente en lugar de adivinar la solución, y descubrí que el prompt original pedía al modelo extraer 'acciones' sin definir qué contaba como tal, así que se perdía sistemáticamente cualquier cosa formulada como sugerencia o pregunta en lugar de instrucción directa. Reescribí el prompt con una definición explícita de qué es una acción, incluyendo ejemplos de las formulaciones indirectas que debía captar, y dividí la tarea en dos pasadas: primero extraer cada compromiso o afirmación candidata tipo tarea, luego una segunda pasada para filtrar y formatear las acciones confirmadas. Validé la solución contra las cincuenta transcripciones, después contra el conjunto de evaluación completo, antes de desplegarla en producción tras un feature flag durante una semana. La puntuación de usuarios subió a 4,3 sobre 5, y la queja concreta sobre acciones perdidas cayó a casi cero en el feedback del mes siguiente.

Empiezo definiendo los modos de fallo que realmente importan para esa funcionalidad concreta, no una puntuación de calidad genérica, porque 'bueno' significa algo distinto para una funcionalidad de resumen que para una de extracción de datos. Construyo el conjunto de prueba a partir de tres fuentes: casos escritos a mano que cubren casos límite conocidos, una muestra de entradas reales o parecidas a producción, y casos adversariales diseñados para romper el prompt, incluyendo intentos de inyección de prompt si la funcionalidad toma texto del usuario como entrada. Defino la puntuación por modo de fallo en lugar de un número agregado único: precisión factual puntuada contra el material fuente, cumplimiento de formato comprobado programáticamente ya que eso no necesita un modelo juez, tono y utilidad puntuados con LLM-as-judge según una rúbrica, y seguridad comprobada contra un conjunto fijo de entradas problemáticas conocidas. Calibro las puntuaciones de LLM-as-judge frente a una muestra etiquetada por humanos antes de confiar en ellas en el pipeline, típicamente treinta a cincuenta casos puntuados por ambos, y no avanzo hasta que el acuerdo sea suficientemente alto como para confiar en la puntuación automatizada como proxy. Conecto todo esto a la CI para que cada cambio de prompt ejecute la evaluación completa automáticamente, y pongo una barrera estricta: ningún cambio de prompt se despliega si hace regresar cualquier modo de fallo individual, aunque la puntuación agregada mejore.

Trato los prompts como artefactos versionados con la misma disciplina que el código de la aplicación, guardados en control de versiones en lugar de en un campo de base de datos que se edita in situ, para que cada cambio tenga un diff, un autor y un resultado de evaluación vinculado. En producción mantengo los prompts detrás de una capa de configuración que puede referenciar una versión concreta por ID, lo que me permite hacer un despliegue parcial o una prueba A/B entre dos versiones de prompt sin un despliegue de código. Cada versión de prompt está etiquetada con los resultados de evaluación que superó y la versión de modelo contra la que se validó, así que si un proveedor lanza una actualización, sé de inmediato qué versiones de prompt necesitan revalidación en lugar de descubrirlo por un pico de reportes de error. Para el rollback, mantengo la versión estable anterior activa y accesible a través de la misma capa de configuración, así que revertir es un cambio de configuración en lugar de un despliegue, lo que saca un mal prompt de producción en minutos en vez de esperar a un ciclo de release. También registro el ID de versión del prompt junto a cada solicitud en producción, así que cuando un usuario reporta una mala respuesta, puedo reproducirla contra la versión exacta del prompt y del modelo que la generó, en lugar de la versión actual, que podría ya ser distinta.

Empiezo definiendo los esquemas de herramientas con la misma precisión que un contrato de API, con tipos de parámetros estrictos y descripciones claras, porque las descripciones de herramientas vagas son la causa número uno de que un agente llame a la herramienta equivocada o pase argumentos mal formados. Mantengo el prompt de sistema centrado en la política de decisión del agente: cuándo llamar a una herramienta frente a responder directamente, cuándo pedir aclaración al usuario frente a avanzar sobre un supuesto, y qué hacer cuando falla una llamada a herramienta, en lugar de intentar enumerar todos los escenarios posibles. Incorporo condiciones de parada explícitas y un número máximo de pasos, porque un agente poco especificado repetirá con gusto llamadas a herramientas improductivas si nada le dice que se detenga y reevalúe. Para tareas de varios pasos prefiero un patrón explícito de planificar y luego ejecutar frente a la llamada a herramientas puramente reactiva, donde el modelo primero enuncia su secuencia de pasos prevista antes de ejecutarlos, porque esto hace que el razonamiento sea inspeccionable y permite detectar planes claramente erróneos antes de que se ejecute ninguna herramienta. Registro la traza completa de llamadas a herramientas de cada ejecución del agente, no solo la respuesta final, porque cuando un agente falla, la señal útil de depuración casi siempre está en la secuencia de decisiones intermedias, no solo en la salida final. Evalúo las ejecuciones del agente por tasa de finalización de tarea y por el número de llamadas a herramientas innecesarias, porque un agente que triunfa a base de forzar diez llamadas redundantes no está realmente listo para producción.