Prompt engineering en producción: ¿cómo pruebo los cambios?
Traducción automática
Este artículo se tradujo automáticamente a partir de la versión original en inglés.
Define las salidas correctas, reúne casos representativos y compara un cambio del prompt con una referencia fija. Mejora la instrucción, los ejemplos o el contexto proporcionado según el fallo observado. Reserva un conjunto de pruebas para comprobar si el cambio funciona más allá de los ejemplos utilizados para diseñarlo.
Un prompt en producción debe gestionar entradas incompletas, ambiguas e inválidas, además de las solicitudes habituales.
Convierte los fallos en casos de prueba
Supongamos que un modelo extrae campos de facturas. Incluye facturas habituales, valores ausentes, diseños desconocidos, fechas contradictorias y documentos que no sean facturas. Define cómo debe gestionar el sistema cada caso antes de editar el prompt.
| Fallo | Cambio que comparar | Comprobación |
|---|---|---|
| Falta un campo obligatorio | Aclarar el campo y añadir un ejemplo pertinente | El campo está presente cuando hay información que lo respalda |
| Valor inventado | Especificar el comportamiento ante valores ausentes y aportar evidencia | El campo sin respaldo queda vacío |
| La respuesta no se puede analizar | Usar un esquema de salida compatible | El analizador acepta la respuesta completa |
| Valor correcto de una fuente equivocada | Conservar la identidad de la fuente en el contexto | El valor pertenece al documento solicitado |
Una salida restringida por un esquema puede resolver los fallos de sintaxis. La documentación de vLLM sobre structured outputs describe las restricciones de salida compatibles. Un objeto JSON válido puede contener una fecha incorrecta o una afirmación sin respaldo, así que valida los valores por separado.
Mantén una comparación interpretable
Mantén constantes la versión del modelo, los ajustes de decodificación, los datos de origen, las definiciones de las herramientas y los límites de salida al probar el cambio del prompt. Registra la calidad, las categorías de fallo, los tokens y la latencia. Repite los casos no deterministas lo suficiente para comprobar si la mejora se mantiene.
Los ejemplos few-shot deben cubrir la variación real, incluidas las entradas incompletas o ambiguas. Añádelos para resolver un problema medido, en lugar de asumir que más ejemplos siempre ayudan. La posición en el contexto también puede importar: Lost in the Middle encontró diferencias en el uso de la evidencia según su posición en los modelos y las tareas evaluados.
Usa etapas explícitas cuando faciliten aislar un fallo, pero incluye las llamadas e interfaces adicionales en la comparación. Aplica los permisos y otras reglas obligatorias de la aplicación en el código; un mensaje de sistema por sí solo no puede garantizarlos.
La sección sobre prompts en producción de la Guía de ingeniería de LLM explica las técnicas principales y sus limitaciones.