Semana 10 · Módulo 10 de 11

Evaluación y resolución de problemas de aplicaciones de IA generativa

Aprenderás a medir la calidad de modelos, RAG y agentes (métricas automáticas, LLM como juez, evaluación humana, Amazon Bedrock Evaluations y AgentCore Evaluations), a integrar la evaluación en CI/CD y a diagnosticar los fallos típicos: throttling, contexto excedido, truncado, alucinaciones, mala recuperación, errores de herramientas, latencia y costes. Es todo el dominio 5 del examen (11 %).

Reparto de la semana

Por qué importa

El dominio 5 (Testing, Validation, and Troubleshooting) pesa el 11 %, pero es el que separa una demo de un sistema en producción. En un servicio clásico, una prueba compara la salida con un valor esperado. En IA generativa:

• No hay una única respuesta correcta. «Canberra es la capital» y «La capital de Australia es Canberra» son igual de buenas.
• La salida no es determinista. La misma pregunta puede dar respuestas distintas.
• Los errores no dan excepción. Una alucinación llega con HTTP 200.
• Todo cambia: el modelo (versiones nuevas, retiradas), el prompt, los documentos de la base de conocimiento.

Por eso el examen pregunta cómo medir la calidad de forma sistemática, cómo evitar regresiones al cambiar algo y cómo encontrar la causa cuando algo va mal. Este módulo cubre el task statement 5.1 (evaluación) y el 5.2 (troubleshooting), y conecta con la monitorización del módulo 9.

Qué medir: dimensiones de calidad

Métricas para las salidas de un FM

La evaluación de un FM (foundation model, modelo fundacional) va más allá de la exactitud de un modelo de ML clásico (beyond traditional ML evaluation approaches, skill 5.1.1):

Tres familias de métodos

1. Métricas automáticas algorítmicas: comparan la salida con una referencia mediante fórmulas. Ejemplos que usa Bedrock: F1 (solapamiento de palabras en preguntas y respuestas), BERTScore (similitud semántica con embeddings, para resúmenes), word error rate, exactitud de clasificación. Son baratas y reproducibles, pero penalizan paráfrasis correctas y no entienden el matiz.
2. LLM-as-a-judge (LLM como juez): un modelo potente puntúa la respuesta de otro siguiendo una rúbrica y explica la puntuación. Escala a miles de respuestas y entiende paráfrasis. Riesgos: sesgos del juez (favorecer respuestas largas o su propio estilo), coste de tokens y necesidad de calibrarlo con una muestra revisada por personas.
3. Evaluación humana: personas expertas valoran con escalas o comparaciones. Es la referencia en calidad subjetiva (tono, utilidad, dominio especializado), pero es cara y lenta.

La estrategia madura combina las tres: métricas automáticas y LLM como juez para todo el volumen, y humanos para calibrar al juez y para los casos críticos.

Conjuntos de referencia (golden datasets)

Un golden dataset (conjunto de referencia) es una colección fija y versionada de entradas con su respuesta esperada (ground truth) que ejecutas cada vez que cambias algo:

• Representativo: preguntas reales (anonimizadas) de los distintos tipos de uso, con su categoría para ver resultados por segmento.
• Con casos difíciles: preguntas ambiguas, fuera de ámbito (el sistema debe decir «no lo sé»), intentos de prompt injection, preguntas cuya respuesta cambió.
• Versionado en S3 o en el repositorio junto al prompt, para comparar versiones de forma justa.
• Mantenido: se amplía con los fallos que aparecen en producción (cada incidente se convierte en un caso de prueba).

Amazon Bedrock Evaluations

Amazon Bedrock Evaluations (la guía la llama Amazon Bedrock Model Evaluations) evalúa modelos y fuentes RAG con trabajos gestionados. Sirve para modelos fundacionales, de Marketplace, personalizados, importados, prompt routers y modelos con Provisioned Throughput, y también para respuestas generadas fuera de Bedrock mediante BYOI (bring your own inference responses).

Tipos de trabajo

Evaluación automática (programática)

Eliges un tipo de tarea por trabajo y un dataset integrado (Bedrock toma una muestra aleatoria de 100 prompts) o propio:

Robustness mide cuánto cambia la respuesta ante pequeñas perturbaciones de la entrada (erratas, mayúsculas): un modelo robusto responde igual. Las puntuaciones algorítmicas no tienen recargo: solo pagas la inferencia del modelo evaluado.

Evaluación con humanos

• Usas tu propio equipo de trabajo (Bring your own work team): una fuerza de trabajo privada gestionada con Cognito o SageMaker Ground Truth, con un máximo de 50 evaluadores por equipo.
• Comparas hasta 2 modelos (o 2 fuentes BYOI) por trabajo.
• Métodos de valoración: pulgar arriba/abajo, botones de elección (comparación entre dos respuestas), escala Likert individual o comparativa, y ordenación.
• Precio: 0,21 USD por tarea humana completada, más la inferencia.
• Si lo creas desde la consola, el bucket de salida necesita una configuración CORS.

LLM como juez

• Dataset JSONL en S3 con hasta 1.000 prompts: prompt (obligatorio), referenceResponse (opcional; la usan Correctness y Completeness) y category (opcional, para ver resultados por categoría).
• Modelos evaluadores admitidos: una lista cerrada que incluye Nova Pro, Nova 2 Lite, Nova Micro, varios Claude (Haiku 4.5, Sonnet 4.5/4.6, Opus 4.5-4.8…), Llama 3.1 70B, Mistral Large y GPT-5.4/5.5. Se admiten perfiles de cross-Region inference.
• Custom metrics: hasta 10 por trabajo, definidas con tu propio prompt de juez y una escala numérica o de texto. Útiles para criterios de negocio («¿menciona el número de ticket?», «¿usa el tono de la marca?»).
• BYOI: añades modelResponses con la respuesta ya generada y un modelIdentifier único; Bedrock se salta la invocación. Así evalúas modelos de otros proveedores, de SageMaker AI o de tu propia infraestructura.
• Resultados en S3 y un report card en la consola (histograma por métrica y explicaciones del juez).
• Coste: los tokens del juez a precio on-demand (más los del generador si Bedrock lo invoca).

Ejemplo de trabajo con LLM como juez y un modelo de Bedrock como generador (aws bedrock create-evaluation-job --cli-input-json file://trabajo.json):

{
  "jobName": "eval-soporte-v2",
  "roleArn": "arn:aws:iam::111122223333:role/BedrockEvalRole",
  "applicationType": "ModelEvaluation",
  "evaluationConfig": {
    "automated": {
      "datasetMetricConfigs": [{
        "taskType": "General",
        "dataset": {"name": "golden-soporte", "datasetLocation": {"s3Uri": "s3://mi-bucket/eval/golden.jsonl"}},
        "metricNames": ["Builtin.Correctness", "Builtin.Completeness", "Builtin.Faithfulness"]
      }],
      "evaluatorModelConfig": {"bedrockEvaluatorModels": [{"modelIdentifier": "eu.amazon.nova-pro-v1:0"}]}
    }
  },
  "inferenceConfig": {"models": [{"bedrockModel": {"modelIdentifier": "eu.amazon.nova-lite-v1:0"}}]},
  "outputDataConfig": {"s3Uri": "s3://mi-bucket/eval/salida/"}
}

Evaluación de RAG

Un RAG puede fallar en dos sitios, y hay que medirlos por separado:

flowchart LR
    Q["Pregunta"] --> R["Recuperación"]
    R -->|"Context relevance, Context coverage"| C["Pasajes recuperados"]
    C --> G["Generación"]
    G -->|"Faithfulness, Correctness, Completeness, Citation precision/coverage"| A["Respuesta"]

• Retrieve only: evalúa solo la recuperación.
  • Context relevance: ¿los pasajes recuperados tienen que ver con la pregunta?
  • Context coverage: ¿los pasajes contienen toda la información de la respuesta de referencia? (requiere referenceResponses).
• Retrieve and generate: evalúa la respuesta final.
  • Faithfulness: ¿la respuesta se apoya solo en los pasajes? Es la métrica de alucinación en RAG.
  • Correctness / Completeness: frente a la respuesta de referencia.
  • Citation precision / coverage: ¿las citas apuntan a pasajes que de verdad respaldan lo dicho y cubren todas las afirmaciones?
• Fuente: una Knowledge Base de Bedrock (Bedrock llama a Retrieve o RetrieveAndGenerate, con la configuración que quieras probar: número de resultados, búsqueda híbrida, reranking, descomposición de consultas) o un RAG externo vía BYOI (una fuente por trabajo). El dataset usa conversationTurns con prompt, referenceResponses y, en BYOI, output con retrievedPassages (o retrievedResults si es solo recuperación) y knowledgeBaseIdentifier.
• Si Bedrock invoca tu Knowledge Base, pagas además los cargos normales de la KB.

Diagnóstico con las dos familias de métricas:

Además de métricas de calidad, mide la latencia de recuperación (retrieval latency measurements, skill 5.1.6): tiempo de Retrieve, de la búsqueda vectorial y del reranking, por separado.

Herramientas de código abierto: AWS publica ejemplos con RAGAS (métricas de RAG con LLM como juez) y la librería fmeval, motor de la evaluación de FM de SageMaker Clarify, que sigue disponible para modelos alojados en SageMaker AI. SageMaker Clarify ya no admite clientes nuevos; AWS indica que Bedrock Evaluations y Guardrails sustituyen su capacidad de evaluar FM.

Evaluación de agentes

Un agente no se evalúa solo por su respuesta final: importa cómo llegó (skill 5.1.7).

Amazon Bedrock AgentCore Evaluations (GA desde marzo de 2026) puntúa con LLM como juez las trazas OpenTelemetry de agentes hechos con cualquier framework (Strands, LangGraph…), alojados o no en AgentCore Runtime:

• 13 evaluadores integrados a tres niveles: sesión (Builtin.GoalSuccessRate), traza (Coherence, Conciseness, Correctness, Faithfulness, Harmfulness, Helpfulness, InstructionFollowing, Refusal, ResponseRelevance, Stereotyping) y llamada a herramienta (Builtin.ToolSelectionAccuracy, Builtin.ToolParameterAccuracy). En agosto de 2026 se añadieron evaluadores de skills.
• Evaluadores personalizados: LLM como juez con tu rúbrica, basados en código (Lambda) o derivados de uno integrado.
• Modos: online (muestrea tráfico real, por ejemplo el 10 %, con filtros y dashboards), on-demand (trazas concretas) y batch (sesiones guardadas en CloudWatch Logs, con ground truth).
• A/B testing y batch evaluations (GA en julio de 2026) y simulación de usuarios para generar conversaciones de prueba.
• Precio aproximado: evaluadores integrados por tokens (0,0024 USD por 1.000 de entrada y 0,012 USD por 1.000 de salida) y personalizados a 1,50 USD por 1.000 evaluaciones más el modelo.

Otras opciones: Strands Evals (strands-agents-evals), SDK de código abierto con evaluadores y simulación de usuarios; y, para Bedrock Agents Classic (en mantenimiento, cerrado a clientes nuevos desde el 30/07/2026), la traza de InvokeAgent (enableTrace) con los pasos de preprocesado, orquestación (con su rationale), postprocesado y fallos. En la guía del examen aparece como Amazon Bedrock Agent evaluations: reconócelo, pero para agentes nuevos la respuesta es AgentCore Evaluations.

Evaluación continua y en producción

Comparar configuraciones: multi-model y coste-rendimiento

Para elegir modelo, prompt o parámetros (skill 5.1.2):

1. Mismo golden dataset para todas las variantes.
2. Mismo juez y mismas métricas.
3. Mide también coste por respuesta (tokens × precio), eficiencia de tokens (calidad por token) y latencia (p50/p90 de InvocationLatency y TTFT). Un indicador útil es la relación latencia-calidad (latency-to-quality ratio).
4. Traduce a resultados de negocio: tasa de resolución sin agente humano, conversión, tiempo ahorrado.
5. Visualízalo: tabla o gráfico de dispersión calidad frente a coste por modelo (model comparison visualizations).

A/B testing y canary

• A/B testing: repartes el tráfico real entre dos variantes (prompt A y B, modelo A y B) y comparas métricas de producción: valoraciones de los usuarios, tasa de resolución, coste, latencia. Decide con volumen suficiente.
• Canary testing: despliegas la nueva variante a un porcentaje pequeño (por ejemplo, el 5 %) y la amplías solo si las métricas no empeoran; si empeoran, vuelves atrás.
• Con Bedrock no hay «endpoint con variantes»: el reparto lo hace tu aplicación. Opciones: AWS AppConfig (feature flags con despliegue gradual y rollback automático ligado a alarmas de CloudWatch), alias ponderados de Lambda con CodeDeploy, canary de etapas de API Gateway, o versiones de Bedrock Prompt Management seleccionadas por configuración. En SageMaker AI, los endpoints admiten varias production variants con pesos de tráfico.
• AgentCore Evaluations ofrece A/B testing gestionado para agentes.

Pruebas de regresión y puertas de calidad en CI/CD

flowchart LR
    C["Cambio de prompt, modelo o datos"] --> B["CodeBuild: genera respuestas del golden dataset"]
    B --> E["Bedrock Evaluations: LLM como juez + RAG"]
    E --> Q{"¿Métricas por encima del umbral y sin regresión?"}
    Q -->|"Sí"| D["Despliegue canary"]
    Q -->|"No"| F["Falla el pipeline"]
    D --> M["Monitorización y evaluación online"]

• Regression testing for model outputs: cada cambio se evalúa contra el golden dataset y se compara con la versión en producción. Umbrales absolutos («Faithfulness ≥ 0,9») y relativos («no empeorar más de 2 puntos»).
• Automated quality gates for deployments: una etapa de CodePipeline que falla si las métricas no pasan (skill 5.1.4).
• Continuous evaluation workflows: evaluaciones programadas (EventBridge Scheduler → Step Functions → trabajo de evaluación) sobre una muestra de tráfico real de los invocation logs, para detectar degradación aunque nadie haya cambiado nada (por ejemplo, porque cambiaron los documentos).
• Validación de salidas: además del juez, comprobaciones deterministas baratas: esquema JSON (salida estructurada), longitud, idioma, ausencia de PII, presencia de citas.

Validación de despliegues (skill 5.1.9)

Al actualizar un FM (versión nueva, migración por retirada del modelo antiguo) o un prompt:

• Synthetic user workflows: canaries de CloudWatch Synthetics que ejecutan conversaciones de prueba contra el entorno nuevo y comprueban el contenido de la respuesta, no solo el código HTTP.
• Hallucination rate: Faithfulness/Correctness sobre el golden dataset antes y después.
• Semantic drift: compara los embeddings de las respuestas nuevas con los de las anteriores para las mismas preguntas; una caída de similitud indica que el comportamiento ha cambiado, aunque no sea necesariamente peor.
• Response consistency: ejecuta cada pregunta varias veces y mide la variación (con temperatura baja debería ser pequeña).

Evaluación centrada en el usuario (skill 5.1.3)

• Feedback interfaces: botones de pulgar arriba/abajo y un campo de comentario en la interfaz. Guarda la valoración con el requestId o un identificador de conversación (por ejemplo, en DynamoDB) para unirla con el prompt y la respuesta de los invocation logs.
• Rating systems: escalas de 1 a 5 por respuesta o por conversación; publica la media como métrica personalizada en CloudWatch.
• Annotation workflows: expertos revisan una muestra de conversaciones (sobre todo las mal valoradas) y etiquetan el tipo de fallo. En AWS: trabajos de evaluación con humanos de Bedrock. SageMaker Ground Truth y Amazon Augmented AI (A2I), las herramientas clásicas de etiquetado y revisión humana, están en modo mantenimiento (no admiten clientes nuevos).
• Cierra el ciclo: los fallos confirmados se añaden al golden dataset y alimentan cambios de prompt, de recuperación o de modelo.

Informes para los interesados (skill 5.1.8)

• Report cards de Bedrock Evaluations y resultados en S3 consultables con Athena.
• Dashboards en Amazon Quick Sight (negocio), Amazon Managed Grafana o CloudWatch (operación) con la evolución de calidad, coste y latencia por versión.
• Amazon Quick Sight (antes QuickSight, hoy parte de Amazon Quick) es el servicio de BI serverless de AWS: conecta con Athena, S3 o bases de datos, publica dashboards interactivos para usuarios de negocio y permite preguntas en lenguaje natural sobre los datos. Es la opción natural para model comparison visualizations e informes periódicos a dirección («calidad frente a coste por modelo y por mes»). Managed Grafana encaja mejor con equipos técnicos que ya combinan métricas de CloudWatch, Prometheus o X-Ray; los dashboards de CloudWatch, con la operación diaria y las alarmas.
• Automated reporting mechanisms: un proceso programado (Lambda) resume los resultados de cada evaluación y lo envía por SNS o a un canal de chat.

Troubleshooting: guía de síntomas, causas y soluciones

Tabla maestra

Problemas con el contenido y la ventana de contexto (skill 5.2.1)

La ventana de contexto es el máximo de tokens que el modelo puede manejar en una petición (entrada más salida). Ejemplos: Nova Micro 128.000; Nova Lite y Nova Pro 300.000; Claude Haiku 4.5 200.000. La salida máxima también está limitada (en Claude Haiku 4.5, 64.000 tokens según su model card).

• Context window overflow diagnostics: cuenta tokens con CountTokens antes de enviar; registra en los logs el tamaño de cada parte del prompt (system, historial, contexto RAG, herramientas) para ver cuál crece.
• En Converse, stopReason te dice qué pasó. Los valores posibles: end_turn, tool_use, max_tokens, stop_sequence, guardrail_intervened, content_filtered, malformed_model_output, malformed_tool_use y model_context_window_exceeded.
• Truncation-related error analysis: si stopReason = max_tokens, la respuesta está incompleta. Un JSON truncado hará fallar al parser: detecta el stopReason antes de parsear.
• Dynamic chunking strategies: si un documento no cabe, divídelo y procésalo por partes (map-reduce: resumir cada parte y luego los resúmenes), o recupera solo los fragmentos relevantes. En Knowledge Bases, elige la estrategia de chunking adecuada (fija, jerárquica, semántica o personalizada con Lambda).
• Historial de conversación: ventana deslizante (últimos N turnos) o resumen periódico de los turnos antiguos.
• Prompt design optimization: instrucciones importantes al principio y al final; contexto delimitado con etiquetas; sin información redundante.

Problemas de integración con la API (skill 5.2.2)

Excepciones de bedrock-runtime (Converse, ConverseStream, InvokeModel):

En streaming, los errores pueden llegar a mitad de la respuesta como eventos del stream (modelStreamErrorException, throttlingException…): tu código debe tratarlos, no solo la excepción inicial.

Buenas prácticas:

• Error logging: registra el requestId, el modelo, el tamaño de la petición y el tipo de excepción; correlaciónalo con los invocation logs y con CloudTrail.
• Request validation: valida antes de enviar (tamaño, parámetros dentro de rango, formato de mensajes alternando user y assistant).
• Response analysis: comprueba stopReason, el formato y el uso de tokens de cada respuesta.
• Reintentos: el SDK aplica backoff exponencial con jitter; el modo standard hace 3 intentos por defecto y el modo adaptive añade un limitador de tasa en el cliente. No reintentes los errores de validación o permisos.

from botocore.config import Config
import boto3

brt = boto3.client(
    "bedrock-runtime",
    region_name="eu-central-1",
    config=Config(
        retries={"max_attempts": 6, "mode": "adaptive"},
        read_timeout=3600,     # respuestas largas
        tcp_keepalive=True,    # conexiones largas a través de NAT o NLB
    ),
)

Problemas de prompt (skills 5.2.3 y 5.2.5)

Más allá de «retocar el prompt»:

• Prompt testing frameworks: una batería de casos (golden dataset) que se ejecuta sobre cada versión del prompt con métricas automáticas.
• Version comparison: Bedrock Prompt Management guarda versiones inmutables del prompt; compara la versión nueva con la anterior sobre los mismos casos antes de publicar el ARN de la versión nueva en la configuración que usa la aplicación (AppConfig) o en el alias del Flow que la invoca. Prompt Management no tiene aliases propios.
• Systematic refinement: cambia una cosa cada vez, mide, conserva lo que mejora. Analiza los fallos por categoría (formato, datos inventados, tono) antes de tocar nada.
• Prompt confusion: el modelo mezcla instrucciones o las ignora. Diagnóstico con CloudWatch Logs (invocation logs): busca patrones en las respuestas fallidas (Logs Insights, detección de anomalías de logs) y revisa el prompt real que se envió, no el que crees que se envió (las plantillas con variables mal rellenadas son una causa frecuente).
• Prompt observability pipelines con X-Ray: trazas que muestran cada paso (plantilla, recuperación, llamada al modelo, postprocesado) con sus tiempos y atributos; hoy se instrumenta con OpenTelemetry y se consulta con Transaction Search.
• Schema validation: valida cada respuesta contra un esquema JSON y cuenta los fallos como métrica. Para evitarlos en origen, usa structured outputs de Bedrock (en Converse, outputConfig.textFormat con type: json_schema), que obliga al modelo a seguir el esquema en los modelos que lo admiten.
• Template testing: pruebas unitarias de las plantillas (todas las variables se sustituyen, el resultado no supera el presupuesto de tokens).

Problemas de recuperación (skill 5.2.4)

• Model response relevance analysis: las respuestas son correctas pero no responden a la pregunta → revisa los pasajes recuperados (Context relevance).
• Embedding quality diagnostics:
  • La consulta y los documentos deben vectorizarse con el mismo modelo y la misma configuración (dimensiones, normalización). Si cambias de modelo de embeddings, hay que reindexar todo.
  • La dimensión del índice debe coincidir con la del modelo (Titan Text Embeddings V2: 1.024 por defecto, o 512 o 256).
  • Titan V2 acepta hasta 8.192 tokens por entrada: los fragmentos más largos se truncan y pierden información.
  • Prueba manual: busca frases que sabes que están en un documento y comprueba en qué posición aparece.
• Drift monitoring: las preguntas de los usuarios cambian (productos nuevos, temporadas) o los documentos envejecen. Vigila la puntuación de similitud de los resultados y la tasa de «no lo sé».
• Vectorization issue resolution: logs de ingesta de Knowledge Bases (EMBEDDING_FAILED, INDEXING_FAILED, RESOURCE_IGNORED) y estadísticas del trabajo de ingesta (numberOfDocumentsFailed). Los ficheros de metadatos (documento.ext.metadata.json) no pueden superar 10 KB.
• Chunking and preprocessing remediation:
  • Fragmentos demasiado pequeños → pierden contexto; demasiado grandes → diluyen la relevancia y gastan tokens.
  • Tablas y PDF escaneados mal extraídos → mejora el parsing (con un FM o Bedrock Data Automation).
  • La estrategia de chunking de una fuente de datos no se puede cambiar después de crearla: crea una fuente nueva y reingiere.
• Vector search performance optimization: búsqueda híbrida (overrideSearchType = HYBRID) para términos exactos (códigos de producto, siglas); filtros de metadatos; reranking; ajustar numberOfResults (5 por defecto, de 1 a 100); descomposición de consultas complejas.

Problemas de agentes y herramientas

• La herramienta no se llama o se llama mal: descripción poco clara, nombres parecidos entre herramientas, esquema de parámetros ambiguo. Mejora las descripciones y valida los parámetros en la herramienta.
• Errores de la herramienta: devuelve el error al modelo con toolResult y status: error para que pueda corregir o informar, en lugar de romper el bucle.
• Bucles infinitos: limita el número de iteraciones y el presupuesto de tokens por tarea; alerta por anomalías de llamadas.
• Diagnóstico: trazas de AgentCore Observability (cada paso, cada herramienta, latencia y errores), métricas de AgentCore Gateway y logs de las Lambdas. Para Agents Classic, la traza de orquestación.
• Evaluación: tool selection accuracy y tool parameter accuracy de AgentCore Evaluations cuantifican el problema y comprueban la mejora.

Guardrails que bloquean de más

• Activa la traza ("trace": "enabled" en guardrailConfig) para ver qué política intervino (inputAssessment, outputAssessments). En Converse, stopReason = guardrail_intervened.
• Ajusta la fuerza de cada filtro de contenido (NONE, LOW, MEDIUM, HIGH) por separado para entrada y salida.
• Usa el modo detección (acción NONE): el guardrail registra lo que habría bloqueado sin bloquearlo; mide los falsos positivos antes de activar el bloqueo.
• Afina los denied topics con definiciones precisas y ejemplos.
• Revisa los umbrales del contextual grounding (de 0 a 0,99): demasiado altos bloquean respuestas correctas.
• Evalúa solo lo necesario con bloques guardContent (o etiquetas de entrada en InvokeModel): si el guardrail analiza el contexto RAG o el system prompt, puede bloquear por contenido que no escribió el usuario (y cuesta más).
• Con ApplyGuardrail y outputScope = FULL ves también las detecciones que no provocaron intervención, útil para depurar.

Latencia y costes inesperados

Latencia (ver módulo 9): compara TTFT con latencia total. TTFT alto → entrada larga o carga; generación lenta → salida larga o modelo grande; latencia total alta con modelo normal → mira la traza (recuperación, reranking, herramientas, reintentos por throttling).

Costes: Cost Anomaly Detection avisa del desvío; los invocation logs dicen quién y qué (identity.arn, requestMetadata, tokens por petición); las trazas del agente revelan bucles. Causas típicas: historial que crece sin límite, agente en bucle, reintentos masivos, reranking o guardrails aplicados a todo, logs sin retención.

Trampas típicas del examen

• Métricas algorítmicas (F1, BERTScore) no sirven para juzgar respuestas abiertas con paráfrasis: para calidad semántica a escala, LLM como juez; para matices subjetivos, humanos.
• Faithfulness ≠ Correctness. Una respuesta puede ser correcta en el mundo real pero no fiel al contexto (el modelo usó su conocimiento), o fiel a un contexto erróneo. En RAG, la fidelidad es la métrica de alucinación.
• Context relevance baja = problema de recuperación, no del modelo. Cambiar a un modelo más grande no lo arregla.
• Evaluar un RAG o un modelo que no está en Bedrock → BYOI en Bedrock Evaluations.
• Evaluación con humanos en Bedrock usa tu propio equipo; ya no hay equipo gestionado por AWS. CORS en el bucket solo para trabajos humanos creados en la consola.
• Agentes nuevos → AgentCore Evaluations; Bedrock Agents Classic y sus trazas solo para cargas existentes.
• Ground Truth, A2I, Clarify y Model Monitor están en mantenimiento: pueden aparecer en el examen, pero para cuentas nuevas se usan Bedrock Evaluations, AgentCore Evaluations y soluciones propias.
• ThrottlingException (429) es tu cuota; ServiceUnavailableException (503) es capacidad del servicio. Ambas se reintentan; solo la primera se resuelve pidiendo más cuota.
• Subir max_tokens «por si acaso» empeora el throttling: reserva cuota al empezar la petición.
• Cambiar de modelo de embeddings exige reindexar; mezclar modelos entre índice y consulta degrada la recuperación sin dar error.
• Guardrail que bloquea de más: traza + modo detección + ajuste por política, no desactivarlo.
• Palabras clave: regression → golden dataset en CI/CD; gradually roll out → canary; compare two prompts with real users → A/B; hallucination in RAG → Faithfulness y contextual grounding; which step of the agent fails → trazas.

Resumen

• Evalúa relevancia, exactitud, completitud, fidelidad, consistencia, fluidez, seguridad, coste y latencia; combina métricas algorítmicas, LLM como juez y humanos.
• El golden dataset versionado es la base de las pruebas de regresión y de la validación de despliegues.
• Bedrock Evaluations: automática (tareas y datasets integrados), humana (tu equipo, 0,21 USD por tarea), LLM como juez (11 métricas integradas y hasta 10 personalizadas) y RAG (recuperación y generación); BYOI para fuentes externas; hasta 1.000 prompts por trabajo.
• Agentes: AgentCore Evaluations con evaluadores de sesión, traza y herramienta; online, on-demand y batch; A/B y simulación de usuarios.
• Producción: A/B y canary (AppConfig, CodeDeploy, API Gateway), puertas de calidad en CodePipeline, evaluación continua, feedback de usuarios e informes.
• Troubleshooting: excepciones y reintentos, stopReason, cuotas y burndown, ventana de contexto, prompts versionados y validados, recuperación (embeddings, chunking, híbrida), agentes (trazas, toolResult de error) y guardrails (traza y modo detección).

Cobertura del temario

Servicios y temas dueños de este módulo: Amazon Quick Sight (informes), Amazon Bedrock Evaluations (automática, humana, LLM como juez, RAG), AgentCore Evaluations, métricas y conjuntos de referencia, pruebas A/B y de regresión, y la resolución de problemas de throttling, cuotas, ventana de contexto, alucinaciones, recuperación, herramientas, latencia y costes. Los guardrails y los agentes se explican a fondo en los módulos 7 y 5; aquí se ven desde el diagnóstico.

Practica lo aprendido

Documentación oficial para ampliar

• Evaluate the performance of Amazon Bedrock resources
• Evaluate model performance using another LLM as a judge
• Evaluate RAG sources with Amazon Bedrock evaluations
• AgentCore Evaluations
• Troubleshooting Amazon Bedrock API Error Codes
• How tokens are counted in Amazon Bedrock
• Monitor knowledge bases using CloudWatch Logs