Prompt engineering

En el Radar compartido: Trial (valoración de la edición aportada).

Cómo funciona

Un prompt define objetivo, entradas, criterios y formato esperado. Separadores y ejemplos pueden aclarar el contrato; no sustituyen validación, recuperación de información o permisos.

Ejemplo de uso

Pedir: «Extrae proveedor, fecha y total; usa null si faltan; no inventes valores». Probar facturas incompletas y comparar el resultado contra etiquetas revisadas.

Estructura de un buen prompt

Componente	Contenido
Rol y contexto	Quién usa el resultado y para qué
Tarea	Qué hacer, en términos verificables
Entradas	Datos delimitados claramente (etiquetas XML, bloques)
Restricciones	Qué no hacer, cómo tratar casos ambiguos o faltantes
Formato de salida	Esquema, longitud, idioma
Ejemplos	Pocos, variados, incluyendo casos difíciles

Ejemplo de plantilla

Eres un analista de calidad de un equipo de cobranza. Tu resumen lo leerá un supervisor
que decide si la llamada requiere seguimiento.

<transcripcion>
{{transcripcion}}
</transcripcion>

Tarea: resume la llamada y clasifica el resultado.

Reglas:
- Usa solo información de la transcripción. Si algo no aparece, escribe "no mencionado".
- No incluyas números de documento ni de tarjeta.
- Si el cliente expresa intención de presentar una queja formal, marca "requiere_seguimiento": true.

Responde solo con JSON:
{"resumen": string (máx. 3 frases), "compromiso_pago": {"fecha": string|null, "monto": number|null},
 "requiere_seguimiento": boolean, "motivo": string}

Técnicas y cuándo usarlas

Técnica	Útil cuando
Few-shot (ejemplos)	El formato o el criterio son difíciles de describir
Delimitadores / XML	Hay varias entradas o contenido no confiable
Razonamiento paso a paso	Problemas de varios pasos; con modelos de razonamiento, basta pedir que piensen o activar el modo de razonamiento
Descomposición en cadena	Una tarea compleja se divide en varios prompts especializados
Salida estructurada	El resultado lo procesa código (structured output)
Autoverificación	Pedir que revise su respuesta contra los criterios antes de entregarla

Ciclo de mejora guiado por evaluación

1. Reunir 30–100 casos reales con resultado esperado, incluidos casos límite.
2. Medir la versión actual del prompt (exactitud, formato válido, abstenciones correctas).
3. Cambiar una cosa y volver a medir.
4. Versionar prompt + modelo + resultados juntos (Langfuse, LangSmith).

Sin un conjunto de evaluación, «mejorar el prompt» es cambiarlo según la última respuesta que se vio.

Errores frecuentes

• Instrucciones negativas vagas («no seas impreciso») en lugar de criterios concretos.
• Ejemplos todos iguales: el modelo copia su forma y no generaliza.
• Mezclar datos del usuario con instrucciones sin delimitarlos, lo que facilita la inyección de instrucciones.
• Ajustar el prompt a un modelo y migrar a otro sin reevaluar.

A medida que las tareas involucran herramientas y documentos, el problema pasa de redactar un prompt a decidir qué información recibe el modelo en cada paso: context engineering.

Criterios de implementación

Versionar plantilla y modelo. Con modelos de razonamiento, comenzar con instrucciones directas y añadir complejidad solo si mejora la evaluación; no asumir que más texto ayuda.