Semana 3 · Módulo 3 de 11

Recuperación aumentada (RAG) a fondo

Aprenderás a diseñar el mecanismo de recuperación que alimenta a un modelo con tus propios datos: chunking, embeddings, búsqueda semántica e híbrida, filtros de metadatos, reranking, transformación de consultas y GraphRAG, con Amazon Bedrock Knowledge Bases como pieza central. Es el task statement 1.5 y uno de los temas que más preguntas genera en el examen.

Reparto de la semana

Por qué importa

Un modelo fundacional (FM, foundation model) solo sabe lo que vio durante su entrenamiento: no conoce tus manuales internos, ni el catálogo de hoy, ni la normativa que cambió el mes pasado. Si le preguntas por ello, o dice que no lo sabe o, peor, se lo inventa con total seguridad (una alucinación, hallucination).

RAG (Retrieval Augmented Generation, generación aumentada por recuperación) resuelve eso sin reentrenar el modelo: antes de preguntar al modelo, buscas los fragmentos relevantes de tus documentos y se los pegas en el prompt como contexto. El modelo responde apoyándose en ellos y puede citar de dónde sale cada afirmación.

El task statement 1.5 (Design retrieval mechanisms for FM augmentation) pide seis habilidades: segmentar documentos, elegir embeddings, desplegar búsqueda vectorial, construir búsquedas avanzadas (híbrida, reranking), tratar consultas complejas y ofrecer un acceso estándar a la recuperación. Además, RAG reaparece en seguridad (grounding para reducir alucinaciones, 3.1.3), en rendimiento (4.2.2), en evaluación (5.1.5-5.1.6) y en troubleshooting (5.2.4). Si dominas este módulo, tienes una parte grande del examen encarrilada.

1. RAG desde cero: vocabulario imprescindible

Antes de ver servicios, fija estos términos. Aparecerán en inglés en el examen.

La idea clave: un embedding coloca textos con significado parecido cerca en un espacio de muchas dimensiones. «¿Cuántos días libres tengo?» y «Política de vacaciones: 23 días laborables» quedan próximos aunque no compartan palabras. Eso es lo que la búsqueda por palabras clave no consigue.

2. El flujo RAG completo

RAG tiene dos fases que ocurren en momentos distintos: la ingesta (ingestion, en diferido, cada vez que cambian los documentos) y la consulta (query time, en cada pregunta del usuario).

flowchart LR
  subgraph ING["Ingesta (offline, al sincronizar)"]
    A["Documentos en S3, SharePoint, Confluence..."] --> B["Parsing: extraer texto, tablas e imágenes"]
    B --> C["Chunking: partir en fragmentos"]
    C --> D["Embeddings: modelo de embeddings"]
    D --> E[("Índice vectorial + texto + metadatos")]
  end
  subgraph QRY["Consulta (online, en cada pregunta)"]
    Q["Pregunta del usuario"] --> QT["Transformación de la consulta (opcional)"]
    QT --> QE["Embedding de la pregunta"]
    QE --> R["Recuperación top-k + filtros de metadatos"]
    E -.-> R
    R --> RR["Reranking (opcional)"]
    RR --> AU["Aumentación: prompt = instrucciones + chunks + pregunta"]
    AU --> G["Generación con el FM"]
    G --> CI["Respuesta con citas"]
  end

Paso a paso, con lo que puede fallar en cada uno:

1. Ingesta de fuentes. Un conector lee los documentos (S3, SharePoint, Confluence, web…). Fallo típico: documentos sin permisos o formatos no admitidos que se saltan en silencio.
2. Parsing. Se extrae el texto. Un PDF escaneado o con tablas complejas necesita un parser avanzado (un FM o Bedrock Data Automation); el parser por defecto solo saca texto.
3. Chunking. Se corta en fragmentos. Si los chunks son enormes, diluyes la relevancia y gastas tokens; si son diminutos, pierdes contexto.
4. Embeddings. Cada chunk se convierte en un vector con el mismo modelo que luego usarás para la pregunta. Cambiar de modelo obliga a reindexar todo.
5. Índice. Se guarda vector + texto + metadatos (fecha, departamento, cliente…). Los metadatos permiten filtrar después.
6. Recuperación. La pregunta se convierte en vector y se buscan los k chunks más cercanos, opcionalmente filtrando por metadatos y combinando con palabras clave (híbrida).
7. Reranking. Un modelo reranker reordena los candidatos leyendo pregunta y chunk juntos; mejora la precisión de los primeros puestos.
8. Aumentación. Se construye el prompt: instrucciones («responde solo con el contexto; si no está, dilo»), los chunks recuperados y la pregunta.
9. Generación. El FM redacta la respuesta.
10. Citas. Se devuelven las referencias (documento, ubicación, fragmento) para que el usuario verifique. Es la base de la transparencia (3.4.1) y de la verificación de exactitud (3.1.3).

3. RAG, fine-tuning o prompt largo: tabla de decisión

Hay tres formas de que un modelo «sepa» algo que no sabía. El examen las enfrenta constantemente.

• Prompt largo (long context o context stuffing): metes el documento entero en el prompt en cada llamada. Sencillo, pero pagas todos esos tokens cada vez y está limitado por la ventana de contexto.
• RAG: recuperas solo lo relevante y lo pegas en el prompt. Conocimiento actualizable al instante (basta con reindexar), con citas.
• Fine-tuning (ajuste fino) o destilación: reentrenas el modelo con ejemplos para cambiar su comportamiento: estilo, formato, tono, vocabulario de dominio, tarea muy específica. No es buena forma de meter hechos que cambian.

Reglas rápidas para el examen:

• «Documentos internos que cambian con frecuencia», «sin reentrenar», «respuestas con fuentes» → RAG.
• «El modelo debe adoptar el estilo de la marca» o «formato de salida muy específico que el prompt no consigue» → fine-tuning (se ve en el módulo 06).
• «Pocos documentos pequeños, prototipo rápido, un único usuario» → prompt largo o chat with your document de Knowledge Bases (sin configurar almacén).
• Combinaciones válidas: fine-tuning para el tono + RAG para los hechos.

4. Segmentación de documentos (chunking)

Skill 1.5.1. El tamaño y la forma del chunk deciden la calidad de la recuperación más que casi cualquier otro ajuste.

4.1 Por qué importa el tamaño

• Chunk pequeño: embedding muy preciso (habla de una sola cosa), pero puede faltar contexto para responder («el plazo es de 30 días»… ¿de qué?).
• Chunk grande: más contexto, pero el embedding mezcla varios temas y «pierde nitidez»; además, cada chunk recuperado consume más tokens del prompt.
• Solapamiento (overlap): repetir un trozo del final del chunk anterior al inicio del siguiente evita cortar una idea por la mitad.

4.2 Estrategias de Amazon Bedrock Knowledge Bases

Detalles verificados que suelen preguntarse:

• La estrategia de chunking no se puede cambiar después de crear la fuente de datos (data source). Hay que crear otra fuente o reindexar.
• Con chunking jerárquico, numberOfResults se refiere a los chunks hijo; como varios hijos se sustituyen por el mismo padre, puedes recibir menos resultados.
• Para contenido multimodal (audio, vídeo, imágenes) con Nova Multimodal Embeddings, el troceado ocurre en el modelo de embeddings (duración de segmento configurable); con el parser de BDA, primero se convierte a texto y luego se aplica el chunking de texto.

4.3 Chunking personalizado con Lambda

Si ninguna estrategia te sirve (por ejemplo, quieres cortar un contrato por cláusulas numeradas, o un código fuente por funciones), Knowledge Bases permite una transformación personalizada con Lambda (custom transformation) en el paso POST_CHUNKING:

• Eliges NONE como estrategia y tu Lambda hace todo el chunking; o
• Eliges una estrategia nativa y tu Lambda solo añade metadatos por chunk (los metadatos de chunk prevalecen sobre los de fichero si coinciden).
• La Lambda lee y escribe los lotes en un bucket S3 intermedio (intermediateStorage).

"vectorIngestionConfiguration": {
  "chunkingConfiguration": { "chunkingStrategy": "NONE" },
  "customTransformationConfiguration": {
    "intermediateStorage": { "s3Location": { "uri": "s3://mi-bucket-intermedio/" } },
    "transformations": [{
      "stepToApply": "POST_CHUNKING",
      "transformationFunction": {
        "transformationLambdaConfiguration": { "lambdaArn": "arn:aws:lambda:eu-central-1:111122223333:function:chunker-clausulas" }
      }
    }]
  }
}

Si montas tu propio pipeline sin Knowledge Bases (por ejemplo, Step Functions + Lambda + OpenSearch), el chunking de tamaño fijo en Lambda es una función de pocas líneas; el jerárquico basado en estructura se implementa leyendo encabezados (Markdown, HTML, estructura que devuelve Textract o BDA) y generando chunks padre-hijo con un identificador común en los metadatos.

4.4 Tabla de decisión de chunking

5. Embeddings: elegir y configurar el modelo

Skill 1.5.2. El modelo de embeddings determina qué significa «parecido».

5.1 Modelos de embeddings admitidos por Knowledge Bases

Criterios de elección (el ejemplo del temario habla de «dimensionalidad y encaje de dominio»):

• Dimensiones. Más dimensiones capturan más matices, pero ocupan más almacenamiento y memoria y hacen la búsqueda algo más lenta. Titan V2 a 256 dimensiones reduce el tamaño del índice a una cuarta parte frente a 1.024 con una pérdida de precisión que debes medir.
• Binario frente a float. Los vectores binarios reducen mucho el almacenamiento, pero solo los admiten OpenSearch Serverless y OpenSearch Managed Clusters. S3 Vectors solo admite float32.
• Idioma y dominio. Para un corpus mezclado español-inglés, un modelo multilingüe. Evalúa con tus preguntas reales: el ranking público no sustituye a tu conjunto de prueba.
• Coherencia. Documentos y preguntas con el mismo modelo y las mismas dimensiones. El índice se crea con una dimensión fija: en S3 Vectors, la dimensión, la métrica y las claves no filtrables no se pueden cambiar tras crear el índice.

5.2 Generar embeddings a escala

Knowledge Bases genera los embeddings por ti durante la ingesta. Si construyes tu pipeline:

• Lambda por lotes (ejemplo del temario): una Lambda lee N chunks de SQS o S3, llama a InvokeModel con el modelo de embeddings y escribe en el almacén (PutVectors en S3 Vectors admite lotes; conviene insertar en lotes grandes).
• Batch inference de Bedrock para volúmenes enormes y sin urgencia (más barato que on-demand; se ve en el módulo 09).
• Controla el throttling del modelo de embeddings (cuotas de tokens por minuto) con reintentos y backoff.

import boto3, json
bedrock = boto3.client("bedrock-runtime", region_name="eu-central-1")

def embed(texto: str, dims: int = 1024) -> list[float]:
    body = {"inputText": texto, "dimensions": dims, "normalize": True}
    r = bedrock.invoke_model(modelId="amazon.titan-embed-text-v2:0", body=json.dumps(body))
    return json.loads(r["body"].read())["embedding"]

6. Almacenes vectoriales al servicio de la recuperación

Skill 1.5.3. El diseño a fondo de almacenes vectoriales es del módulo 02 (task 1.4); aquí nos interesa qué capacidades de recuperación te da cada uno cuando lo usas con Knowledge Bases.

Fuera de Knowledge Bases, el temario cita OpenSearch Service con capacidades vectoriales (k-NN, y el neural plugin que llama a Bedrock para generar embeddings dentro de OpenSearch) y Aurora con pgvector como opciones de búsqueda semántica «hechas por ti». Elígelas cuando necesites control total del índice (shards, algoritmo HNSW, puntuación personalizada) o integrar búsqueda vectorial en una base de datos que ya existe.

7. Amazon Bedrock Knowledge Bases a fondo

Amazon Bedrock Knowledge Bases es el servicio gestionado de RAG de AWS: conecta fuentes, trocea, genera embeddings, indexa y ofrece APIs de recuperación y de generación con citas.

7.1 Tipos de Knowledge Base (estado octubre de 2026)

Desde marzo de 2026 hay dos grandes tipos, y AWS recomienda la gestionada para casos nuevos:

Además existen tres variantes especiales de la Customer-managed:

• Datos estructurados (type: SQL): la KB traduce lenguaje natural a SQL (NL2SQL) sobre un almacén estructurado y ejecuta la consulta. La API GenerateQuery te devuelve solo el SQL generado para que lo metas en tu flujo. Encaja con el ejemplo del temario de text-to-SQL para resultados deterministas (3.1.2).
• Amazon Kendra GenAI index (type: KENDRA): usa un índice de Kendra como recuperador. Kendra está cerrado a clientes nuevos (sección 11).
• GraphRAG con Neptune Analytics (sección 8).

7.2 Plano de control y plano de datos

Como en otros servicios de AWS, las APIs se reparten en dos clientes de SDK:

Permisos: la KB tiene un rol de servicio que Bedrock asume (bedrock.amazonaws.com) para leer S3, invocar el modelo de embeddings y escribir en el almacén. Tu aplicación necesita bedrock:Retrieve y/o bedrock:RetrieveAndGenerate sobre la KB, más bedrock:InvokeModel sobre el modelo de generación.

7.3 Fuentes de datos y conector de S3

Lo que debes saber del conector de S3 (el más preguntado):

• Solo buckets de uso general (General Purpose) y en la misma región que la KB (puede ser de otra cuenta con la política de bucket adecuada).
• Prefijos de inclusión (inclusion prefixes): indexa solo documentos/ en vez del bucket entero.
• Metadatos por documento: un fichero nombre.ext.metadata.json junto al documento, de 10 KB como máximo.
• Tamaño máximo por documento de texto estándar: 50 MB (consulta la página de cuotas para multimodal).
• Sincronización incremental: en cada sync se procesan solo los ficheros nuevos, modificados o borrados.
• Política de borrado (dataDeletionPolicy): DELETE elimina los vectores al borrar la fuente; RETAIN los conserva.

Formato del fichero de metadatos (va siempre en un bloque de código, nunca en texto):

{
  "metadataAttributes": {
    "departamento": { "value": { "type": "STRING", "stringValue": "rrhh" }, "includeForEmbedding": false },
    "anio": { "value": { "type": "NUMBER", "numberValue": 2026 }, "includeForEmbedding": false },
    "confidencial": { "value": { "type": "BOOLEAN", "booleanValue": false }, "includeForEmbedding": false }
  }
}

includeForEmbedding: true concatena el par clave-valor al texto antes de calcular el embedding (mejora la relevancia si la pregunta menciona ese valor); con false el metadato solo sirve para filtrar. El formato simplificado "metadataAttributes": { "clave": "valor" } equivale a false.

Esto conecta con la skill 1.4.2 (marcos de metadatos: fechas desde metadatos de S3, autoría, clasificación por dominio) y con la 3.3.2 (atribución de fuentes).

7.4 Sincronización y mantenimiento del índice

Un RAG con datos viejos responde mal con mucha seguridad. Opciones:

Reglas verificadas: la primera vez con una fuente S3 debes hacer un sync completo; no lances IngestKnowledgeBaseDocuments y StartIngestionJob a la vez.

flowchart LR
  S3["Bucket S3 de documentos"] -- "ObjectCreated / ObjectRemoved" --> EB["Amazon EventBridge"]
  EB --> SQS["Cola SQS (agrupa cambios)"]
  SQS --> L["Lambda: StartIngestionJob"]
  SCH["EventBridge Scheduler (cada noche)"] --> L
  L --> KB["Knowledge Base"]
  KB --> CW["CloudWatch: estado del job y estadísticas"]

GetIngestionJob devuelve estadísticas (documentos escaneados, indexados, fallidos, borrados). Alarmar sobre documentos fallidos es parte del mantenimiento de almacenes vectoriales (1.4.5, 4.3.5).

7.5 Parsing avanzado

Ojo: si eliges FM o BDA, se usan para todos los PDF de la fuente, aunque sean solo texto, y se cobran. Con parser FM, el tamaño total de ficheros no puede superar 100 GB. La Managed KB usa un parser gestionado que elige estrategia por tipo de fichero.

7.6 Retrieve frente a RetrieveAndGenerate

Ejemplo Retrieve con boto3 (Customer-managed KB):

import boto3
rt = boto3.client("bedrock-agent-runtime", region_name="eu-central-1")

resp = rt.retrieve(
    knowledgeBaseId="KBID123456",
    retrievalQuery={"text": "¿Cuántos días de teletrabajo tengo a la semana?"},
    retrievalConfiguration={"vectorSearchConfiguration": {"numberOfResults": 5}},
)
for r in resp["retrievalResults"]:
    print(round(r["score"], 3), r["location"]["s3Location"]["uri"], r["content"]["text"][:80])

Ejemplo RetrieveAndGenerate con un perfil de inferencia europeo:

cuenta = boto3.client("sts").get_caller_identity()["Account"]
modelo = f"arn:aws:bedrock:eu-central-1:{cuenta}:inference-profile/eu.amazon.nova-micro-v1:0"

resp = rt.retrieve_and_generate(
    input={"text": "¿Cuántos días de teletrabajo tengo a la semana?"},
    retrieveAndGenerateConfiguration={
        "type": "KNOWLEDGE_BASE",
        "knowledgeBaseConfiguration": {"knowledgeBaseId": "KBID123456", "modelArn": modelo},
    },
)
print(resp["output"]["text"])
for c in resp["citations"]:
    for ref in c["retrievedReferences"]:
        print("Fuente:", ref["location"]["s3Location"]["uri"])

Para la Managed KB la consulta es Retrieve con managedSearchConfiguration (no vectorSearchConfiguration). Si pides más contexto del que cabe y la generación falla por longitud, la documentación propone: reducir numberOfResults, usar chunks más pequeños, acortar la plantilla o la pregunta.

7.7 Filtros de metadatos

Los filtros restringen la búsqueda a chunks cuyos metadatos cumplen una condición. Son la herramienta para multi-tenant, vigencia temporal y precisión por dominio.

No admiten startsWith ni stringContains: S3 Vectors y la Managed KB. En la Managed KB, los campos reservados empiezan por guion bajo (_source_uri); en la Customer-managed, por x-amz-bedrock (p. ej. x-amz-bedrock-kb-document-page-number en PDF con OpenSearch Serverless o Aurora).

filtro = {
    "andAll": [
        {"equals": {"key": "departamento", "value": "rrhh"}},
        {"greaterThanOrEquals": {"key": "anio", "value": 2025}},
    ]
}
resp = rt.retrieve(
    knowledgeBaseId="KBID123456",
    retrievalQuery={"text": "política de gastos de viaje"},
    retrievalConfiguration={"vectorSearchConfiguration": {"numberOfResults": 5, "filter": filtro}},
)

Filtrado implícito (implicit metadata filtering): con implicitFilterConfiguration describes el esquema de metadatos (clave, tipo, descripción) y un modelo genera el filtro a partir de la pregunta («políticas de 2025 de RR. HH.» → filtro por año y departamento). Está soportado con modelos Anthropic Claude.

7.8 Búsqueda semántica, por palabras clave e híbrida

Skill 1.5.4.

• Semántica (vectores): entiende sinónimos y paráfrasis, pero falla con identificadores exactos, siglas raras o números de pieza («ERR-4012», «RD 1/2026»).
• Por palabras clave (léxica, BM25): encuentra coincidencias exactas, pero no entiende que «coche» y «automóvil» son lo mismo.
• Híbrida: ejecuta ambas y fusiona las puntuaciones. Es la mejor opción por defecto cuando hay jerga, códigos de producto o nombres propios.

En Knowledge Bases, overrideSearchType acepta HYBRID o SEMANTIC; si no lo indicas, decide Bedrock. La híbrida solo está disponible en Customer-managed con Amazon RDS (Aurora PostgreSQL), OpenSearch Serverless y MongoDB que tengan un campo de texto filtrable; en el resto (por ejemplo, S3 Vectors) la consulta es semántica. En la Managed KB la búsqueda es siempre híbrida.

Si construyes la búsqueda tú mismo con OpenSearch, la híbrida se implementa con una consulta compuesta (k-NN + match) y un search pipeline de normalización y combinación de puntuaciones, que es donde entra la «puntuación personalizada» de la skill 4.2.2.

7.9 Reranking

Skill 1.5.4 (ejemplo «Amazon Bedrock reranker models»).

La recuperación vectorial es rápida porque compara vectores precalculados, pero es aproximada. Un reranker (cross-encoder) lee la pregunta y cada chunk juntos y puntúa su relevancia con más precisión. El patrón es de dos etapas: recuperas muchos candidatos (p. ej. 20-50) y el reranker se queda con los mejores (p. ej. 5).

Configuración en Retrieve/RetrieveAndGenerate (Customer-managed):

"vectorSearchConfiguration": {
  "numberOfResults": 20,
  "rerankingConfiguration": {
    "type": "BEDROCK_RERANKING_MODEL",
    "bedrockRerankingConfiguration": {
      "numberOfRerankedResults": 5,
      "modelConfiguration": { "modelArn": "arn:aws:bedrock:eu-central-1::foundation-model/amazon.rerank-v1:0" }
    }
  }
}

Si numberOfRerankedResults supera numberOfResults, se devuelven como mucho numberOfResults (salvo con descomposición de consultas, donde puede ser hasta cinco veces más). También existe la API independiente Rerank para reordenar documentos que no están en una KB. Coste: el reranking se factura por search units (1 USD por 1.000 en Fráncfort según la API oficial de precios a 1 de octubre de 2026; consulta https://aws.amazon.com/bedrock/pricing/). En la Managed KB el reranker gestionado viene activado y sin coste extra si usas el embedding gestionado.

7.10 Tratamiento de consultas: reformulación, expansión y descomposición

Skill 1.5.5. Las preguntas de los usuarios son cortas, ambiguas o compuestas. Tres técnicas:

"retrieveAndGenerateConfiguration": {
  "type": "KNOWLEDGE_BASE",
  "knowledgeBaseConfiguration": {
    "knowledgeBaseId": "KBID123456",
    "modelArn": "arn:aws:bedrock:eu-central-1:111122223333:inference-profile/eu.amazon.nova-micro-v1:0",
    "orchestrationConfiguration": {
      "queryTransformationConfiguration": { "type": "QUERY_DECOMPOSITION" }
    }
  }
}

Técnicas adicionales que conviene reconocer por el nombre:

• HyDE (Hypothetical Document Embeddings): el FM genera una respuesta hipotética y se busca con su embedding; ayuda cuando la pregunta es muy corta.
• Recuperación agéntica (Managed KB): un agente planifica varias recuperaciones, evalúa si tiene suficiente y vuelve a buscar (razonamiento multisalto).
• Enrutado de consultas: una Lambda o un FM clasifica la pregunta y la envía a la KB adecuada (RR. HH., legal, producto) o a un almacén estructurado.

flowchart TD
  U["Pregunta del usuario + historial"] --> SF["Step Functions"]
  SF --> RW["Bedrock: reformular pregunta autónoma"]
  RW --> DEC["Lambda: ¿pregunta compuesta?"]
  DEC -- "No" --> R1["Retrieve"]
  DEC -- "Sí" --> MAP["Map: una Retrieve por subpregunta"]
  MAP --> FUS["Fusión y deduplicado de chunks"]
  R1 --> RR["Rerank"]
  FUS --> RR
  RR --> GEN["Converse: respuesta con citas"]

7.11 Seguridad y calidad en Knowledge Bases (avance)

• Guardrails: se aplican a la entrada y a la respuesta generada, no a los chunks recuperados. Detalles en el módulo 07.
• Contextual grounding check de Guardrails: bloquea respuestas no sustentadas por el contexto recuperado (3.1.3).
• Cifrado: KMS para la KB, las fuentes, el almacenamiento transitorio de ingesta y el almacén (S3 Vectors admite SSE-S3 o SSE-KMS, elegido al crear el bucket e inmutable).
• Evaluación de RAG: Amazon Bedrock Evaluations tiene evaluación de recuperación y de recuperación + generación (módulo 10).

8. GraphRAG con Amazon Neptune Analytics

El RAG vectorial encuentra chunks parecidos a la pregunta, pero falla cuando la respuesta exige conectar hechos repartidos en varios documentos: «¿Qué proveedores de los proyectos que dirige Ana tienen contratos que vencen este año?». Ningún chunk contiene todo eso.

GraphRAG en Knowledge Bases combina vectores y grafo:

1. Durante la ingesta, un FM que eliges (graph construction model) extrae entidades y relaciones de los documentos y construye un grafo en Amazon Neptune Analytics, junto con el índice vectorial. Elegir el modelo de construcción activa el enriquecimiento contextual.
2. En la consulta, primero hace una búsqueda vectorial de nodos relevantes, luego recorre el grafo para traer chunks relacionados y responde con ese contexto enriquecido.

Cuándo elegirlo: preguntas multisalto (multi-hop), dominios con muchas entidades relacionadas (cadena de suministro, fraude, investigación, normativa con referencias cruzadas) y requisitos de razonamiento entre documentos. No lo elijas para una FAQ simple: añade coste (capacidad m-NCU de Neptune) y un FM en la ingesta.

9. Acceso estándar a la recuperación: function calling, MCP y APIs

Skill 1.5.6: create consistent access mechanisms to enable seamless integration with FMs. La recuperación no siempre la invoca tu código: cada vez más la invoca el propio modelo cuando la necesita.

Declaración de la herramienta de búsqueda para el modelo (el bucle completo de tool use se ve en el módulo 04):

{
  "toolSpec": {
    "name": "buscar_documentacion_interna",
    "description": "Busca en la documentación interna de RR. HH. y devuelve fragmentos con su fuente.",
    "inputSchema": {
      "json": {
        "type": "object",
        "properties": {
          "consulta": { "type": "string", "description": "Pregunta autónoma y precisa" },
          "departamento": { "type": "string", "enum": ["rrhh", "legal", "ventas"] }
        },
        "required": ["consulta"]
      }
    }
  }
}

10. ¿Knowledge Bases o RAG a medida?

11. Amazon Kendra, Amazon Q Business y Amazon Quick: estado actual

La guía oficial sigue listando estos servicios como in-scope, así que pueden salir. Pero su estado ha cambiado (fuentes en docs/investigacion.md):

Cómo razonar en el examen:

• Si el enunciado pide «asistente de empresa listo para usar, sin desarrollo, para que los empleados pregunten a SharePoint y Confluence respetando permisos», la respuesta de la guía era Q Business; hoy la vigente es Amazon Quick (que puede asociar una Managed KB de forma nativa).
• Si pide «búsqueda empresarial con conectores y ACL como recuperador de un RAG propio», antes era Kendra; hoy es la Managed Knowledge Base.
• Amazon Q Business Apps (Q Apps) permitían a los empleados crear, describiéndolas en lenguaje natural o a partir de una conversación con Q Business, pequeñas aplicaciones de IA generativa (formularios que generan un borrador, un resumen o una checklist) y compartirlas sin programar. Si el enunciado pide «que usuarios de negocio sin programar creen y compartan pequeñas herramientas de IA», esa era la respuesta de la guía; hoy el equivalente está en Amazon Quick (sus flujos y agentes).
• Si una opción propone Kendra o Q Business para una cuenta nueva, sabes que no es viable en la práctica; si la pregunta es conceptual («qué servicio ofrece…»), puede seguir siendo la respuesta esperada. Lee con atención.

12. Diagnóstico de problemas de RAG (avance de 5.2.4)

Trampas típicas del examen

• «Datos que cambian a diario, sin reentrenar, con citas» → RAG con Knowledge Bases, nunca fine-tuning.
• «Códigos de producto, referencias legales, números de pieza» → búsqueda híbrida. Si la opción usa S3 Vectors con HYBRID, es incorrecta: S3 Vectors solo hace semántica.
• «Los resultados relevantes aparecen pero mal ordenados» → reranking, no cambiar de modelo de generación.
• «Aislar datos por cliente con un único índice» → filtro de metadatos aplicado por el backend. Desconfía de opciones que dejan al cliente elegir el filtro.
• «Preguntas que combinan varias partes» → descomposición de consultas (QUERY_DECOMPOSITION) o recuperación agéntica.
• «Relaciones entre entidades a través de muchos documentos» → GraphRAG con Neptune Analytics (y recuerda: solo fuente S3).
• Cambiar la estrategia de chunking de una fuente existente no se puede: nueva fuente o reindexado.
• Vectores binarios → solo OpenSearch. S3 Vectors → solo float32, sin startsWith/stringContains, 1 KB y 35 claves de metadatos, sin jerárquico recomendado.
• Reranking en Europa → eu-central-1. Amazon Rerank 1.0 no está en us-east-1.
• Guardrails no filtran los chunks recuperados, solo entrada y respuesta.
• Kendra y Q Business: explicables, pero cerrados a clientes nuevos; alternativas actuales: Managed KB y Amazon Quick.
• «Conectar SharePoint o Confluence a una Knowledge Base nueva» → Managed KB. Desde el 30/09/2026 una KB del cliente ya no admite conectores nuevos de esas fuentes: si el enunciado exige un almacén propio, lleva los documentos a S3 (AppFlow, Lambda) o usa la fuente Custom.
• Chunking semántico en la Managed KB: no está disponible; si el enunciado lo exige, es una KB del cliente.
• Borrar una KB con GraphRAG no borra el grafo de Neptune (coste residual).
• Palabras clave: ground responses, reduce hallucinations, source attribution, up-to-date information, LEAST operational overhead, MOST relevant results, multi-hop reasoning, semantic search beyond keyword matching.

Resumen

• RAG = recuperar fragmentos relevantes y añadirlos al prompt; se separa en ingesta (parse, chunk, embed, index) y consulta (transformar, recuperar, rerankear, aumentar, generar, citar).
• RAG para hechos cambiantes y citas; fine-tuning para comportamiento y estilo; prompt largo para poco contenido.
• El chunking decide la calidad: por defecto, fijo, jerárquico, semántico, ninguno o Lambda personalizada. No se cambia después.
• El modelo de embeddings y su dimensión se fijan al crear el índice; mismo modelo para documentos y preguntas.
• Knowledge Bases: Managed (recomendada, híbrida, reranker y ACL gestionados, conectores, recuperación agéntica) o Customer-managed (tú eliges el almacén: S3 Vectors, OpenSearch, Aurora, Neptune…).
• Retrieve devuelve chunks; RetrieveAndGenerate devuelve respuesta con citas y admite descomposición, plantillas, guardrails y sesiones.
• Filtros de metadatos para multi-tenant y vigencia; híbrida para términos exactos; reranking para ordenar mejor; transformación de consultas para preguntas complejas.
• GraphRAG con Neptune Analytics para razonamiento entre entidades.
• Acceso estándar mediante tool use, MCP (servidor oficial y AgentCore Gateway) o una API propia.
• Kendra y Q Business están cerrados a clientes nuevos: Managed KB y Amazon Quick son las alternativas.

Cobertura del temario

Practica lo aprendido

Documentación oficial para ampliar

• Amazon Bedrock Knowledge Bases
• Managed Knowledge Base frente a Customer-managed
• Chunking en Knowledge Bases
• Configurar consultas (filtros, búsqueda híbrida, reranking, descomposición)
• Prerrequisitos de almacenes vectoriales (S3 Vectors, Aurora, OpenSearch, Neptune)
• Modelos de reranking y regiones
• GraphRAG con Amazon Neptune Analytics
• Knowledge Bases sobre datos estructurados
• Ingesta directa de documentos
• Transformación personalizada con Lambda durante la ingesta
• Servidor MCP oficial para Knowledge Bases (awslabs/mcp)