Lección 8: Producción — costes, límites y evaluación

Producción: costes, límites y evaluación

Has construido un agente, integrado herramientas y optimizado tus prompts. Ahora llega la parte que muchos subestiman: llevar Claude a producción sin sorpresas de costes, sin alcanzar límites de tasa inesperados, y con la confianza de que funciona como debe. Este tema no es teoría: es lo que define si tu aplicación sobrevive el primer mes en producción.

El examen Developer valida que entiendas cómo tomar decisiones operativas reales: elegir modelo según coste y latencia, predecir gastos, manejar rate limits, evaluar calidad en el mundo real, y cumplir con gobernanza de datos. Sin estos conocimientos, acabarás con una factura inesperada o un sistema que falla silenciosamente.

Modelos, precios y selección de modelo

Anthropicofrecealgunmodosdeacceso a Claude:

API de Claude (pay-as-you-go): pagas por entrada y salida, medidas en tokens. Es el modelo estándar para desarrollo y producción pequeña.
Dedicated cloud: infraestructura dedicada con throughput garantizado, para volúmenes altos y requisitos de latencia consistente.
On-premise: despliegue privado en tu infraestructura, para máxima conformidad y control de datos.

Cada modelo disponible (Claude 3.5 Sonnet, Claude 3 Opus, etc.) tiene un coste de entrada y salida diferente. La regla es simple:

Entrada más barata = menos capacidad. Salida más cara = penaliza generar mucho contenido.

Para elegir modelo en producción:

Define la tarea: ¿análisis de documentos simples? ¿razonamiento complejo? ¿generación de código?
Mide coste por usuario/solicitud: tokens esperados × precio por token.
Calcula volumen mensual: solicitudes × coste unitario.
Valida latencia: ¿qué modelo cumple SLA?
Elige el modelo más barato que cumpla los requisitos.

No uses el modelo más potente por defecto. En producción, la eficiencia importa tanto como la calidad.

Límites de tasa y request throttling

Los límites de tasa (rate limits) son restricciones que Anthropic impone para proteger su infraestructura y la tuya:

Límites por minuto: número máximo de solicitudes en 60 segundos.
Límites por día: techo total de tokens procesados en 24 horas.
Límites por organización: compartidos entre todos los proyectos.

Cuando alcanzas el límite, la API devuelve un error 429 (Too Many Requests). Si no estás preparado:

Los usuarios ven errores.
Pierdes datos (solicitudes no reenviadas).
Tu SLA se rompe.

Estrategias de mitigación:

Exponential backoff con jitter: cuando recibes 429, espera de forma aleatoria antes de reintentar.
Rate limiting en cliente: implementa un queue (cola) de solicitudes; limita lo que envías antes de que la API lo rechace.
Dedicated cloud: acceso garantizado sin competencia con otros usuarios.
Batch processing: agrupa solicitudes no urgentes en lotes, reduce picos.

import anthropic
import random
import time

def call_claude_with_backoff(prompt: str, max_retries: int = 3):
    client = anthropic.Anthropic()
    for attempt in range(max_retries):
        try:
            response = client.messages.create(
                model="claude-3-5-sonnet-20241022",
                max_tokens=1000,
                messages=[{"role": "user", "content": prompt}]
            )
            return response
        except anthropic.RateLimitError:
            wait_time = (2 ** attempt) + random.uniform(0, 1)  # exponential backoff + jitter
            print(f"Rate limited. Retrying in {wait_time:.2f}s...")
            time.sleep(wait_time)
    raise Exception("Max retries exceeded")

Monitorea tu uso en el dashboard de Anthropic. Si ves que te aproximas al límite, actúa antes de estar bloqueado.

Batch processing y optimización de costes

Si tienes cientos de solicitudes que no necesitan respuesta inmediata, batching reduce costes drásticamente:

Batch API: envía un lote de solicitudes en un archivo JSON, Anthropic las procesa fuera de horas pico, devuelve resultados más tarde.
Ventaja de coste: descuento de hasta 50% frente a API normal (consulta los precios actuales).
Ventaja de rate limit: no cuenta contra tus límites por minuto, solo por día.

Cuándo usar Batch API:

Análisis masivo de documentos históricos.
Procesamiento de backlog acumulado.
Cualquier tarea donde puedas esperar horas o días.

Cuándo NO usar:

Aplicaciones interactivas (chatbots, asistentes en tiempo real).
Flujos de usuario que esperan respuesta inmediata.

Ejemplo simplificado de estructura de batch:

{
  "requests": [
    {
      "custom_id": "doc-001",
      "params": {
        "model": "claude-3-5-sonnet-20241022",
        "max_tokens": 1000,
        "messages": [{"role": "user", "content": "Analiza este documento..."}]
      }
    },
    {
      "custom_id": "doc-002",
      "params": {
        "model": "claude-3-5-sonnet-20241022",
        "max_tokens": 1000,
        "messages": [{"role": "user", "content": "Analiza este otro..."}]
      }
    }
  ]
}

Consulta la documentación oficial de Batch API para el flujo completo.

Observabilidad: monitoreo y logging

En producción, no puedes saber si algo va mal si no observas. Necesitas:

Logging estructurado: cada llamada a Claude debe registrar:
- Timestamp, usuario, modelo, tokens usados.
- Latencia (tiempo total de solicitud).
- Errores y códigos de estado.
- Resultado de tool use (si aplica).
Métricas clave:
- Latencia p50, p95, p99 (percentiles).
- Tasa de errores y tipos de error (429, 500, timeout, etc.).
- Coste acumulado por usuario/modelo.
- Número de reintentos.
Alertas:
- Tasa de error > 5%.
- Latencia p95 > umbral (ej. 10 segundos).
- Coste diario > presupuesto esperado.

Usa herramientas como:

CloudWatch, DataDog, New Relic: APM completo.
Prometheus + Grafana: monitoreo custom.
Logs estructurados: formatea en JSON para análisis fácil.

import json
import logging
import time
from datetime import datetime

logger = logging.getLogger(__name__)

def log_api_call(user_id: str, model: str, input_tokens: int, output_tokens: int, latency_ms: float, error: str = None):
    log_entry = {
        "timestamp": datetime.utcnow().isoformat(),
        "user_id": user_id,
        "model": model,
        "input_tokens": input_tokens,
        "output_tokens": output_tokens,
        "latency_ms": latency_ms,
        "error": error
    }
    logger.info(json.dumps(log_entry))

Evaluaciones (evals) en producción

Una vez en producción, ¿cómo sabes si Claude sigue funcionando bien? Los usuarios se quejarán, pero para entonces ya habrá habido daño.

Evaluaciones (evals) son tests automatizados que miden la calidad de salida:

Evals deterministas: compara salida exacta contra esperada.

response = client.messages.create(...)
assert "respuesta esperada" in response.content[0].text

Evals con modelo: usa Claude (u otro modelo) como juez.

eval_prompt = f"¿Es correcta esta respuesta? {response.content[0].text}"
evaluation = client.messages.create(
    model="claude-3-5-sonnet-20241022",
    messages=[{"role": "user", "content": eval_prompt}]
)

Evals de usuario: métrica más valiosa: ¿los usuarios aprueban?
- Thumbs up/down en la UI.
- Net Promoter Score (NPS).
- Tasa de rechazo manual.

En producción:

Ejecuta evals periódicamente (diario, si es posible) sobre muestras de solicitudes reales.
Compara con baseline histórico. Si cae > 5%, alerta.
Mantén versión anterior de modelo como fallback.
Cuando cambies prompt o modelo, valida con evals antes de lanzar.

La Anthropic Academy ofrece guías gratuitas sobre evaluación. Úsalas.

Seguridad y gobernanza de datos

Cuando pasas datos a la API de Claude, ¿qué sucede?

Tus datos no se usan para entrenar Claude (Anthropic no reclama eso).
Se procesan en servidores de Anthropic (a menos que uses on-premise).
Debe cumplir normas: GDPR, HIPAA, SOC 2, etc.

Checklist de seguridad para producción:

Anonimización: elimina datos identificables (nombres, emails, SSN) antes de enviar a Claude.

import re
def anonymize_text(text: str) -> str:
    text = re.sub(r'\b\d{3}-\d{2}-\d{4}\b', '[SSN]', text)  # SSN
    text = re.sub(r'\S+@\S+', '[EMAIL]', text)  # emails
    return text

Encriptación en tránsito: siempre usa HTTPS. La API de Anthropic lo requiere.
Encriptación en reposo: si almacenas responses, encrípta en base de datos.
Acceso y auditoría:
- Limita quién tiene acceso a claves API.
- Rota claves cada 90 días.
- Log de quién accedió qué y cuándo.
Cumplimiento: si maneja HIPAA o datos sensibles, documenta tu arquitectura. Anthropic proporciona información de compliance en su web.
Data retention: configura qué datos mantienes y por cuánto tiempo. Cumple GDPR (derecho al olvido).

Para el examen

Domina esto:

Selección de modelo: cómo elegir entre modelos según coste, latencia y capacidad. El examen pregunta escenarios reales: "¿Qué modelo para procesar 10k documentos legales al día?"
Rate limiting: entender errores 429, exponential backoff, qué es rate limiting vs. throttling.
Batch API: cuándo usarla, ventajas de coste, que no cuenta contra límites por minuto.
Observabilidad: qué métricas monitorear, alertas críticas, logs estructurados.
Evaluaciones: diferenciar evals deterministas vs. con modelo. Integración en CI/CD.
Seguridad: anonimización, encriptación, compliance, auditoría, acceso a claves.

Espera preguntas tipo:

"Un cliente reporta latencia alta. ¿Qué métricas revisarías primero?"
"Necesitas procesar 1M de emails. ¿Batch API o request normal? ¿Por qué?"
"¿Cómo validas que un cambio de prompt no degrada calidad en producción?"
"Un usuario se queja de que la respuesta es incorrecta. ¿Cómo lo investigas?"

Para recordar

Elige modelo según tarea, no por defecto: Sonnet cubre 80% de casos. Usa Opus solo si necesitas razonamiento extremo.
Rate limits son reales: implementa exponential backoff, monitorea uso, y no esperes a estar bloqueado para actuar.
Batch API reduce costes 50%: úsala para procesamiento masivo no urgente. No para chatbots interactivos.
Observabilidad es prevención: loguea todo, alertas sobre costes y errores, evals continuas. Descubre problemas antes que los usuarios.