Prompt engineering para desarrolladores: técnicas avanzadas

El prompt engineering no es magia, es ingeniería. En la Lección 2 aprendiste cómo llamar a la API; ahora toca aprender a escribir prompts que sean eficientes, reproducibles y orientados a producción. El examen Developer espera que entiendas no solo qué preguntar a Claude, sino cómo estructurar esas preguntas para obtener resultados fiables, económicos y rápidos. Esta lección te prepara para escenarios reales donde la calidad del prompt determina el éxito de tu aplicación.

1. Prompt caching: optimiza costo y latencia

¿Qué es? El prompt caching permite reutilizar bloques grandes de tokens sin volver a procesarlos. Si tu aplicación envía el mismo contexto (documentación, sistema de instrucciones, o historial) en múltiples solicitudes, solo pagas por esos tokens una sola vez, y el caché acelera las respuestas posteriores.

¿Cuándo usarlo? Cuando tengas:

Documentación o contexto extenso que reutilizas (p. ej., manual de producto, políticas de empresa)
Análisis repetitivo de archivos grandes
Chatbots con historial largo que no cambia

Cómo implementarlo:

En la solicitud a la API, marca los bloques reutilizables con cache_control de tipo ephemeral:

{
  "model": "claude-3-5-sonnet-20241022",
  "system": [
    {
      "type": "text",
      "text": "Eres un asistente de soporte técnico experto en productos de IA."
    },
    {
      "type": "text",
      "text": "[DOCUMENTACIÓN EXTENSA DEL PRODUCTO: 50KB]",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [
    {
      "role": "user",
      "content": "¿Cómo configuro el streaming?"
    }
  ],
  "max_tokens": 1024
}

Claude procesa la documentación en la primera llamada (y paga por esos tokens), pero en llamadas posteriores, mientras el caché esté vigente (duración: mínimo 5 minutos), los tokens en caché se cobran a una fracción del precio.

En el examen: Espera preguntas sobre cuándo usar caché, qué tokens se reutilizan, y el impacto en costos y latencia.

2. Salidas estructuradas: JSON schema y fiabilidad

¿Qué es? Las salidas estructuradas garantizan que Claude devuelve respuestas en un formato JSON específico que defines. No es solo "pídele JSON amablemente": es una restricción válida que Claude respeta.

¿Por qué es crítico? En producción, si esperas parsear JSON y Claude decide devolver texto libre, tu aplicación falla. Las salidas estructuradas eliminan esa ambigüedad.

Cómo usar JSON schema:

import json
import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-3-5-sonnet-20241022",
    max_tokens=1024,
    messages=[
        {
            "role": "user",
            "content": "Extrae el nombre, email y rol del siguiente texto: Juan García, juan@empresa.com, ingeniero de software."
        }
    ],
    tools=[
        {
            "name": "extract_user",
            "description": "Extrae información de usuario",
            "input_schema": {
                "type": "object",
                "properties": {
                    "nombre": {"type": "string"},
                    "email": {"type": "string", "format": "email"},
                    "rol": {"type": "string"}
                },
                "required": ["nombre", "email", "rol"]
            }
        }
    ]
)

# Claude devolverá un bloque tool_use que garantiza estructura

Alternativa con response_format (algunos modelos):

{
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "name": "user_extraction",
      "schema": {
        "type": "object",
        "properties": {
          "nombre": {"type": "string"},
          "email": {"type": "string"}
        }
      }
    }
  }
}

En el examen: Puedes encontrar preguntas sobre cómo validar esquemas, manejar errores si Claude no cumple, y cuándo usar tool_use vs response_format.

3. Few-shot learning: enseña por ejemplo

¿Qué es? En lugar de explicar una tarea con palabras, le muestras a Claude ejemplos de entrada-salida esperada. Así aprende patrones específicos del dominio.

¿Cuándo es imprescindible? Cuando:

Necesitas un estilo o formato muy específico
La tarea es ambigua en palabras
Trabajas con dominios especializados (p. ej., jurídico, médico)

Ejemplo: clasificar sentimiento de reseñas de clientes:

{
  "model": "claude-3-5-sonnet-20241022",
  "messages": [
    {
      "role": "user",
      "content": "Clasifica el sentimiento en: positivo, neutro, negativo.\n\nEjemplos:\n\nReseña: 'Excelente producto, llegó rápido y es exacto lo que esperaba.'\nClasificación: positivo\n\nReseña: 'El producto funciona, pero tardó 3 semanas.'\nClasificación: neutro\n\nReseña: 'No funciona, es una estafa.'\nClasificación: negativo\n\nAhora clasifica esta reseña:\nReseña: 'Buena calidad, pero el precio es muy alto comparado con competidores.'\nClasificación:"
    }
  ],
  "max_tokens": 100
}

Claude verá los patrones y probablemente responda "neutro" o "negativo leve", mucho más coherente que si solo dijeras "clasifica sentimientos".

Tip: 2-5 ejemplos suelen ser suficientes. Más ejemplos aumentan tokens y costo sin mejorar mucho la calidad (y ocupan espacio que podrías dedicar a prompt caching).

4. Prefills: guía el inicio de la respuesta

¿Qué es? Un prefill es el inicio de la respuesta que tú proporcionas. Claude continúa desde ahí. Es útil para:

Forzar un formato específico al inicio
"Recordar" a Claude un rol o tono
Garantizar que respete un estilo

Ejemplo: genera JSON con prefill:

{
  "model": "claude-3-5-sonnet-20241022",
  "messages": [
    {
      "role": "user",
      "content": "Dame 3 ideas de productos para una tienda de tecnología."
    },
    {
      "role": "assistant",
      "content": "{\n  \"ideas\": [\n"
    }
  ],
  "max_tokens": 500
}

Claude completará el JSON a partir del prefill garantizado. Sin prefill, podría responder en prosa.

Advertencia: Los prefills cuentan como tokens de salida. Úsalos estratégicamente, no como alternativa a un prompt claro.

5. Etiquetas XML: estructura sin reglas formales

¿Por qué XML? Claude está entrenado para entender etiquetas XML como marcadores lógicos. Aunque el modelo no requiere XML, es una convención poderosa para:

Separar secciones del prompt
Marcar datos especiales o sensibles
Hacer el prompt legible y mantenible

Ejemplo estructurado:

<sistema>
Eres un analista de datos de producto.
</sistema>

<contexto>
<datos>
Nombre: Claude
Tipo: Modelo de IA
Casos de uso: Redacción, análisis, codificación
</datos>
</contexto>

<tarea>
Basándote en los datos anteriores, escribe una descripción ejecutiva de 2 párrafos.
</tarea>

<restricciones>
- Evita jerga innecesaria
- Usa ejemplos concretos
- Máximo 300 palabras
</restricciones>

Esta estructura es legible, escalable y Claude la entiende perfectamente. Además, facilita el debugging de prompts.

6. Evaluación de prompts: mide lo que importa

¿Cómo saber si tu prompt funciona? No es suficiente con "probar una vez". En producción necesitas métricas:

Exactitud: ¿La respuesta es correcta? (usa un dataset de test con respuestas esperadas)
Consistencia: ¿Claude da la misma respuesta con la misma entrada? (corre 3-5 veces)
Latencia: ¿Es aceptable para tu caso de uso?
Costo: ¿El volumen de tokens es proporcional al valor entregado?

Flujo típico:

1. Escribe un prompt (versión v1)
2. Prueba con 10-20 ejemplos reales
3. Calcula % de aciertos
4. Si < 85%, itera (añade few-shot, refina instrucciones, etc.)
5. Repite hasta confianza > 90%
6. Despliega con logging para monitorear en producción

Herramientas útiles:

Pruebas manuales: corre el prompt en Anthropic Console
Pruebas automatizadas: escribe scripts que comparen salidas contra "ground truth"
Monitoring en producción: rastrea % de errores, latencia, tokens por solicitud

En el examen: Espera preguntas sobre cómo validar que un prompt es "listo para producción" y qué métricas monitores.

Para el examen

El examen valida que domines estas técnicas de forma integrada. Aquí están los tópicos clave:

Prompt caching: Cuándo usar, qué tipos de contenido se cachean, impacto en latencia y costo.
Salidas estructuradas: JSON schema, tool_use, validación, manejo de errores si la salida no es válida.
Few-shot learning: Número óptimo de ejemplos, cómo elegir ejemplos representativos.
Prefills: Caso de uso, impacto en tokens de salida.
XML: Práctica común para estructurar prompts complejos.
Evaluación: Métricas (exactitud, consistencia, latencia), flujo de iteración.

Preguntas tipo test

Pregunta 1: Estás construyendo un chatbot que analiza documentos de 100KB sobre políticas de empresa. El mismo documento se usa en 50 preguntas al día. ¿Qué técnica deberías usar primero?

A) Reducir la documentación a resumen
B) Prompt caching
C) Few-shot learning
D) Prefills

Respuesta correcta: B. El prompt caching es la herramienta diseñada para reutilizar contexto extenso y reducir costos repetidamente. Las otras técnicas resuelven otros problemas.

Pregunta 2: Necesitas que Claude extraiga campos específicos (nombre, email, teléfono) de formularios. ¿Cuál es la mejor forma de garantizar que devuelve siempre un JSON válido?

A) Pedir amablemente en el prompt
B) Usar few-shot con ejemplos
C) Usar JSON schema o tool_use
D) Añadir un prefill

Respuesta correcta: C. Las salidas estructuradas (JSON schema o tool_use) son la forma garantizada de obtener JSON válido. Few-shot y prefills ayudan pero no garantizan.

Pregunta 3: Has creado un prompt que resuelve el 70% de tus casos de test. ¿Cuál es el siguiente paso recomendado?

A) Desplegar a producción con monitoreo
B) Aumentar max_tokens
C) Iterar: añadir few-shot, refinar instrucciones, validar con más ejemplos
D) Cambiar de modelo

Respuesta correcta: C. El 70% indica problemas en la lógica del prompt. Iterar mejora la calidad antes de desplegar. Desplegar con métricas tan bajas sería arriesgado.

Pregunta 4: ¿Cuántos ejemplos de few-shot son "óptimos" para la mayoría de tareas?

A) 1 ejemplo
B) 2-5 ejemplos
C) 10-20 ejemplos
D) Cuantos más, mejor

Respuesta correcta: B. 2-5 ejemplos bien elegidos generalmente capturan el patrón sin bloat innecesario de tokens. Más ejemplos raramente mejora mucho y aumenta costo.

Pregunta 5: Tu prompt funciona bien en tests, pero en producción tiene latencia alta. ¿Qué verificarías primero?

A) Si el prompt caching está activo y reutilizándose
B) Si el modelo es lo suficientemente rápido
C) Si la salida es muy larga
D) Si hay un problema de red

Respuesta correcta: A. Si no usas caché y reutilizas contexto extenso, el modelo procesa todo cada vez. Verificar que el caché funciona es el primer paso.

Pregunta 6: Estás escribiendo un prompt complejo con múltiples secciones (contexto, instrucciones, restricciones, ejemplos). ¿Cuál es una buena práctica de estructura?

A) Todo en un bloque de texto legible
B) Usar etiquetas XML para separar secciones
C) Separar en múltiples system messages
D) Usar prefills para cada sección

Respuesta correcta: B. Las etiquetas XML hacen el prompt legible, escalable y fácil de debuggear. Los system messages están para instrucciones globales, no para estructura. Los prefills son para la salida.

Para recordar

Prompt caching reutiliza tokens costosos en múltiples llamadas; usa cache_control: ephemeral en bloques de contexto que no cambien.
Salidas estructuradas (JSON schema o tool_use) garantizan formato válido en producción; nunca confíes solo en "pídelo amablemente".
Few-shot learning con 2-5 ejemplos bien elegidos supera la mayoría de instrucciones genéricas; es tu herramienta de precisión.
Evaluación sistemática (test set, % aciertos, consistencia, latencia) es la diferencia entre un prompt que funciona y uno en producción; itera hasta > 90% de exactitud.

Próxima lección: Tool use / function calling — Aprende cómo darle a Claude acceso a herramientas externas, integra APIs reales, y construye agentes que actúan en el mundo.