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.

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.