Semana 2 · Módulo 2 de 11

Datos para modelos fundacionales, embeddings y almacenes vectoriales

Aprenderás a validar, limpiar y transformar datos (texto, imágenes, audio, tablas) para que un modelo fundacional los consuma, a trocearlos y convertirlos en embeddings, y a elegir, dimensionar y mantener al día el almacén vectorial adecuado en AWS. Es la mitad «de datos» del dominio 1 y la base de RAG.

Reparto de la semana

Por qué importa

Un modelo fundacional es tan bueno como los datos que le das. Si le pasas un PDF escaneado sin OCR, un audio sin transcribir o un texto lleno de basura HTML, la respuesta será mala por mucho que pagues el mejor modelo. Y en RAG (módulo 3), si trocear, vectorizar o indexar se hace mal, el modelo recibirá fragmentos irrelevantes y alucinará con total seguridad.

Los task statements 1.3 (data validation and processing pipelines) y 1.4 (vector store solutions) forman la mitad «de datos» del dominio 1. El examen te preguntará:

• Qué servicio usar para validar la calidad de los datos antes de que lleguen al modelo.
• Cómo procesar documentos, imágenes, audio y tablas (Textract, Transcribe, Bedrock Data Automation, modelos multimodales, SageMaker Processing).
• Cómo formatear las entradas según el modelo y la API.
• Qué almacén vectorial elegir según escala, latencia, coste, filtrado y operación.
• Cómo diseñar metadatos y cómo mantener el índice al día sin reindexarlo todo.

1. El viaje de los datos hasta el modelo

flowchart LR
  A["Fuentes: S3, SharePoint, wikis, bases de datos, SaaS, NAS, streams"] --> B["Ingesta: DataSync, Transfer Family, AppFlow, Kinesis, MSK"]
  B --> C["Aterrizaje en Amazon S3"]
  C --> D["Validación: Glue Data Quality, Lambda, CloudWatch"]
  D --> E["Procesamiento: Textract, Transcribe, BDA, modelos multimodales, SageMaker Processing"]
  E --> F["Mejora y metadatos: Comprehend, Bedrock, Lambda"]
  F --> G["Chunking"]
  G --> H["Embeddings: Titan, Cohere, Nova"]
  H --> I["Almacén vectorial: S3 Vectors, OpenSearch, Aurora pgvector…"]
  I --> J["Recuperación para el FM (RAG, módulo 3)"]

Dos maneras de construirlo:

• Gestionada: Amazon Bedrock Knowledge Bases hace casi todo (conectores, parsing, chunking, embeddings, almacén, sincronización). Es la opción con LEAST operational overhead y la verás a fondo en el módulo 3.
• A medida: Step Functions orquesta Lambda, Textract, Transcribe, Bedrock y el almacén vectorial que elijas. Más control y más trabajo. Es lo que construyes en los labs de esta semana para entender cada pieza.

2. Fuentes e ingesta

Lo básico de estos servicios ya lo conoces del SAA-C03. Aquí importa qué papel juegan en una solución de IA generativa:

3. Validar la calidad de los datos (Skill 1.3.1)

«Garbage in, garbage out». Antes de que un documento llegue al modelo o al índice vectorial, comprueba que cumple unos mínimos.

Qué significa «calidad» para un FM

AWS Glue Data Quality

Servicio serverless (basado en el proyecto de código abierto Deequ) para definir y evaluar reglas de calidad con DQDL (Data Quality Definition Language). Tiene dos puntos de entrada: sobre tablas del AWS Glue Data Catalog y dentro de trabajos ETL de Glue.

Rules = [
    IsComplete "document_id",
    IsUnique "document_id",
    Completeness "body_text" > 0.98,
    ColumnLength "body_text" > 50,
    ColumnValues "language" in ["es", "en"],
    RowCount > avg(last(3)),
    CustomSql "select count(*) from primary where body_text like '%<html%'" = 0
]

• Más de 30 tipos de regla: IsComplete, IsUnique, Completeness, Uniqueness, ColumnLength, ColumnValues, RowCount, CustomSql, DataFreshness, DetectAnomalies, ReferentialIntegrity…
• Reglas dinámicas que se comparan con ejecuciones anteriores (RowCount > avg(last(3))) y detección de anomalías.
• Recomendaciones automáticas de reglas (sobre el Data Catalog).
• Publica resultados en Amazon CloudWatch y eventos en Amazon EventBridge (por ejemplo, para parar el pipeline o avisar), y puede escribirlos en S3. En trabajos ETL, además, identifica qué registros fallan para desviarlos a cuarentena.

SageMaker Data Wrangler

Herramienta visual de preparación de datos. En la experiencia actual de SageMaker Studio se usa desde SageMaker Canvas. Ofrece cientos de transformaciones predefinidas y un informe de calidad e insights (Data Quality and Insights Report) que detecta valores ausentes, duplicados, atípicos y problemas de tipos. Útil cuando un analista quiere explorar y preparar un conjunto tabular sin programar.

Validación a medida con Lambda y métricas de CloudWatch

Para reglas específicas de texto (idioma, longitud, presencia de PII, codificación, OCR vacío), una función Lambda valida cada documento, publica métricas personalizadas en CloudWatch (documentos válidos, rechazados por motivo) y deja los rechazados en un prefijo de cuarentena. Con alarmas de CloudWatch sobre la tasa de rechazo detectas que una fuente se ha estropeado.

flowchart LR
  S3["S3: entrada/"] -->|"evento"| EB["EventBridge"]
  EB --> SF["Step Functions"]
  SF --> V["Lambda: validar (idioma, longitud, OCR, PII)"]
  V -->|"válido"| P["Procesamiento y embeddings"]
  V -->|"no válido"| Q["S3: cuarentena/"]
  V --> CW["CloudWatch: métricas y alarma de tasa de rechazo"]
  G["Glue Data Quality (datos tabulares)"] --> CW

4. Procesar datos complejos: texto, imagen, audio y tablas (Skill 1.3.2)

Documentos: Amazon Textract

Amazon Textract extrae texto, formularios y tablas de documentos escaneados e imágenes (OCR con estructura).

Límites que conviene recordar: formatos JPEG, PNG, PDF y TIFF; las operaciones síncronas admiten 10 MB y una sola página en PDF o TIFF; las asíncronas, hasta 500 MB y 3.000 páginas. La detección de texto admite español, inglés, francés, alemán, italiano y portugués; las queries y la escritura a mano, solo inglés.

La función LAYOUT es especialmente útil para IA generativa: devuelve la estructura (títulos, secciones) que luego permite trocear por estructura (sección 7).

Audio: Amazon Transcribe

Amazon Transcribe convierte voz en texto, en lotes (fichero en S3) o en streaming (tiempo real).

• Diarización (speaker diarization): identifica quién habla (hasta 30 hablantes) con ShowSpeakerLabels.
• Vocabularios personalizados y modelos de lenguaje personalizados para jerga del sector.
• Redacción de PII: en lotes, para varios dialectos (inglés, es-US, francés, alemán, italiano, portugués). Ojo con el español de España (es-ES): admite lotes y streaming, pero no modelos de lenguaje personalizados y la redacción de PII solo en streaming. Es el tipo de detalle que decide una respuesta.
• Call Analytics para centros de contacto (en es-ES, solo post-llamada).
• Salida JSON con transcripts, items (palabras con marca de tiempo y confianza) y speaker_labels.

Todo en uno: Amazon Bedrock Data Automation (BDA)

Bedrock Data Automation extrae información estructurada de contenido no estructurado —documentos, imágenes, audio y vídeo— usando IA generativa, con una sola API.

• Salida estándar (standard output): lo que BDA extrae por defecto según el tipo (texto, resúmenes, transcripciones, descripción de escenas…).
• Salida personalizada (custom output) con blueprints: defines los campos que quieres (por ejemplo, «importe total», «CIF del proveedor») y BDA los extrae. Disponible para documentos, imágenes y audio (no para vídeo).
• Proyectos (projects): agrupan la configuración de salida estándar y los blueprints; los referencias al invocar.
• APIs: InvokeDataAutomationAsync (asíncrona, con resultados en S3) e InvokeDataAutomation (síncrona, para cargas pequeñas).
• Límites asíncronos para documentos: hasta 3.000 páginas y 500 MB.
• Se puede usar como parser en Knowledge Bases para convertir audio, vídeo o documentos complejos en texto antes del chunking.
• Precio por página, imagen o minuto (por ejemplo, en eu-south-2: 0,01 USD por página de documento con salida estándar y 0,04 USD con salida personalizada, según la API de precios a 1 de octubre de 2026).

Directamente con un modelo multimodal

Un modelo como Nova Lite, Nova 2 Lite o Claude puede leer imágenes y documentos que le envías en la Converse API y devolver lo que le pidas (un resumen, un JSON). Es flexible, pero pagas tokens por cada página o imagen y no tienes las garantías de estructura de Textract o BDA.

Procesamiento a medida: SageMaker Processing

SageMaker Processing ejecuta trabajos de procesamiento en contenedores gestionados (propios o predefinidos, por ejemplo con scikit-learn o Spark): lee de S3 (en /opt/ml/processing/input), ejecuta tu script y escribe en S3 (/opt/ml/processing/output). Úsalo cuando necesitas librerías específicas o más recursos de los que da Lambda (15 minutos, 10 GB de memoria): limpiar un corpus de millones de documentos, deduplicar, convertir formatos o evaluar calidad en lote.

¿Qué uso para cada tipo de dato?

Arquitectura de un pipeline multimodal

flowchart TD
  S["S3: entrada/"] --> EB["EventBridge: Object Created"]
  EB --> SF["Step Functions"]
  SF --> T{"Tipo de fichero"}
  T -->|"PDF o imagen"| TX["Textract asíncrono (LAYOUT, TABLES)"]
  T -->|"Audio"| TR["Transcribe (diarización)"]
  T -->|"Vídeo o formatos complejos"| BDA["Bedrock Data Automation"]
  TX --> N["Lambda: normalizar y validar"]
  TR --> N
  BDA --> N
  N --> C["Comprehend: entidades y PII"]
  C --> OUT["S3: procesado/ (texto + metadata.json)"]
  OUT --> KB["Knowledge Base o pipeline de embeddings"]

Para miles de ficheros, el estado Distributed Map de Step Functions procesa objetos de S3 en paralelo (hasta 10.000 ejecuciones hijas simultáneas), con umbrales de fallos tolerados.

5. Formatear las entradas para cada modelo (Skill 1.3.3)

JSON para las APIs de Bedrock

Con InvokeModel, el cuerpo es el formato nativo del proveedor. Por ejemplo, para Titan Text Embeddings V2:

{
  "inputText": "¿Cuál es el plazo de devolución?",
  "dimensions": 512,
  "normalize": true,
  "embeddingTypes": ["float"]
}

La respuesta trae embedding (vector), inputTextTokenCount y embeddingsByType. Para Claude con InvokeModel el cuerpo lleva anthropic_version, max_tokens y messages; para Nova, messages e inferenceConfig. Cada uno distinto: por eso Converse es preferible para modelos de texto.

Formato conversacional (conversation formatting)

En la Converse API:

• system: lista de bloques con las instrucciones de sistema (rol, reglas, formato).
• messages: lista ordenada de mensajes con role (user o assistant) y content (lista de bloques). Los turnos se alternan, y el historial se reenvía completo en cada llamada.
• Bloques de contenido: text, image (formatos png, jpeg, gif, webp; bytes o ubicación de S3), document (pdf, csv, doc, docx, xls, xlsx, html, txt, md; con name obligatorio), video, toolUse, toolResult.
• Límites por mensaje: hasta 20 imágenes (máximo 3,75 MB y 8.000 × 8.000 píxeles cada una) y hasta 5 documentos (máximo 4,5 MB cada uno), solo en mensajes de user, y un documento debe ir acompañado de un bloque de texto.

mensajes = [
    {
        "role": "user",
        "content": [
            {"text": "Extrae el número de factura y el importe total en JSON."},
            {"document": {"format": "pdf", "name": "factura-0923", "source": {"bytes": pdf_bytes}}},
        ],
    }
]

Endpoints de SageMaker AI

Un endpoint de SageMaker recibe el formato que define su contenedor. Muchos contenedores de LLM aceptan un JSON del estilo {"inputs": "…", "parameters": {"max_new_tokens": 256, "temperature": 0.2}}, pero debes consultar la documentación del contenedor o del modelo de JumpStart. Prepara los datos estructurados (listas de registros, CSV) exactamente como los espera el ContentType configurado.

Lotes

La inferencia por lotes espera JSONL en S3: una línea por registro con recordId y modelInput (el cuerpo en formato InvokeModel o, si lo indicas, Converse).

{"recordId": "ticket-000001", "modelInput": {"messages": [{"role": "user", "content": [{"text": "Clasifica: no puedo pagar"}]}], "inferenceConfig": {"maxTokens": 10}}}

6. Mejorar la calidad de la entrada (Skill 1.3.4)

Pequeñas transformaciones antes del modelo o del índice mejoran mucho la calidad y la consistencia:

7. Trocear documentos: estrategias de chunking

Los documentos no se vectorizan enteros: se trocean en chunks (fragmentos) y se genera un embedding por chunk. ¿Por qué?

• Un embedding de un documento de 80 páginas mezcla decenas de temas y no se parece a ninguna pregunta concreta. Un chunk de un párrafo sí.
• Los modelos de embeddings tienen un máximo de entrada (8.192 tokens en Titan Text Embeddings V2; 512 en Cohere Embed v3).
• Al modelo generador solo le pasas los chunks relevantes: menos tokens, menos coste y menos ruido.

El dilema de siempre: chunks pequeños dan embeddings precisos pero sin contexto suficiente para responder; chunks grandes tienen contexto pero embeddings «diluidos» y más tokens por consulta.

Las estrategias

Chunking en Amazon Bedrock Knowledge Bases

Bedrock Knowledge Bases ofrece estas opciones de fábrica:

• Por defecto: chunks de aproximadamente 300 tokens respetando los límites de frase.
• Tamaño fijo: indicas el máximo de tokens por chunk y el porcentaje de solapamiento.
• Jerárquico: indicas el tamaño máximo del chunk padre, el del hijo y los tokens de solapamiento. En la recuperación se buscan los hijos y se sustituyen por sus padres, así que puedes recibir menos resultados de los pedidos.
• Semántico: indicas el máximo de tokens, el tamaño del búfer (buffer size: cuántas frases vecinas se incluyen al calcular el embedding de cada frase; con 1, se combinan la anterior, la actual y la siguiente) y el umbral de percentil de ruptura (breakpoint percentile threshold: cuanto más alto, menos cortes y chunks más grandes). Tiene coste adicional porque usa un modelo fundacional.
• Sin chunking: cada documento es un chunk (pierdes el número de página en las citas).
• Transformación personalizada con Lambda: tu función recibe el contenido tras el parsing (usando un bucket S3 intermedio) y devuelve tus propios chunks; combinada con «sin chunking», te da control total. Es como implementas un chunking por estructura a tu medida.

Con contenido ya analizado por un parser avanzado, Bedrock respeta los límites lógicos (páginas, secciones) y no fusiona contenido entre ellos.

Tamaño y solapamiento: puntos de partida

• Empieza con el valor por defecto (~300 tokens) o con 300–500 tokens y un 10–20 % de solapamiento, y mide con preguntas reales (evaluación de recuperación, módulo 10).
• Preguntas muy concretas (códigos de error, cláusulas) → chunks más pequeños o jerárquico.
• Preguntas que necesitan contexto amplio (explicar un procedimiento) → chunks más grandes o jerárquico.
• Añade contexto al chunk: título del documento y de la sección al principio del texto que vectorizas. Mejora mucho la búsqueda.

La Skill 1.5.1 (segmentación de documentos para la recuperación) se amplía en el módulo 3; aquí te basta con elegir la estrategia y entender su impacto en el almacén vectorial.

8. Embeddings a fondo

Qué es exactamente un vector

Un embedding es una lista de números en coma flotante, por ejemplo de 1.024 dimensiones. Cada dimensión no tiene un significado legible por sí sola; lo que importa es la posición relativa: textos similares, vectores cercanos. Mismo modelo para indexar y para consultar, siempre: los vectores de modelos distintos no son comparables.

Modelos de embeddings en Amazon Bedrock

Datos de la documentación oficial, consultados el 01/10/2026:

Cómo elegir el modelo de embeddings (dimensionality y domain fit)

Documentos frente a consultas

Algunos modelos distinguen el uso del embedding: Cohere con input_type (search_document al indexar, search_query al buscar) y Nova Multimodal Embeddings con embeddingPurpose (GENERIC_INDEX al indexar, *_RETRIEVAL al consultar). Usar el tipo correcto mejora la recuperación. Titan Text Embeddings V2 no tiene ese parámetro.

Generar embeddings a escala

• Lambda que recibe lotes de chunks (por ejemplo, de una cola SQS o del estado Map de Step Functions) e invoca el modelo; controla la concurrencia para no superar las RPM.
• Batch inference de Bedrock para vectorizar un corpus grande con descuento (el precio batch de Titan V2 es la mitad).
• Knowledge Bases lo hace por ti en la ingesta.

Normalización

Normalizar un vector es escalarlo para que su longitud sea 1. Titan V2 lo hace por defecto (normalize: true). Con vectores normalizados, coseno y producto escalar dan el mismo orden de resultados y la distancia euclídea también es equivalente para ordenar.

9. Métricas de distancia

La métrica de distancia (o de similitud) decide qué vectores se consideran «cercanos». Elige la que recomienda el modelo de embeddings.

Cómo se llama en cada servicio:

10. Índices: cómo se busca rápido entre millones de vectores

Búsqueda exacta frente a aproximada

• k-NN exacto (flat, fuerza bruta): compara la consulta con todos los vectores. Recall perfecto, pero el coste crece linealmente: inviable con decenas de millones de vectores y baja latencia.
• ANN (approximate nearest neighbor, vecinos más cercanos aproximados): estructuras de índice que encuentran casi siempre los más cercanos examinando solo una parte. Se mide con el recall (qué porcentaje de los verdaderos vecinos devuelve).

El triángulo de decisión: recall ↔ latencia ↔ memoria/coste. Subir uno suele empeorar otro.

HNSW (Hierarchical Navigable Small World)

Un grafo por capas: las capas superiores tienen pocos nodos con enlaces largos (para «saltar» rápido a la zona correcta) y las inferiores, todos los nodos con enlaces cortos (para afinar). La búsqueda baja de capa en capa acercándose a la consulta.

Ventajas: muy buen recall con baja latencia y admite inserciones incrementales. Inconveniente: consume mucha memoria (el grafo vive en RAM). En pgvector, los valores por defecto de HNSW son m = 16 y ef_construction = 64; en DocumentDB, m = 16, efConstruction = 64 y efSearch = 40.

IVF (Inverted File)

Agrupa los vectores en nlist clústeres (con k-means) y, al consultar, solo examina los nprobes clústeres más cercanos a la consulta.

• Necesita una fase de entrenamiento con datos representativos.
• Menos memoria que HNSW; se combina bien con cuantización (IVF-PQ).
• Recall algo menor y peor comportamiento si los datos cambian mucho respecto al entrenamiento.
• En pgvector se llama IVFFlat (parámetros lists y ivfflat.probes).

Cuantización (quantization)

Guardar cada componente del vector con menos bits: float32 → fp16 (2×), byte/int8 (4×), binario (hasta 32×) o product quantization (PQ, hasta 64×). En OpenSearch existe además el modo en disco (on_disk) con niveles de compresión, que reduce drásticamente la memoria a cambio de algo de latencia.

Filtrar y buscar a la vez

Cuando combinas búsqueda vectorial y filtro por metadatos («solo documentos de 2026 del departamento legal»), importa cuándo se filtra. Con post-filtrado (buscar los K más cercanos y luego filtrar) puedes quedarte con menos de K resultados. Los índices ENHANCED de S3 Vectors (los predeterminados en buckets creados desde el 30/09/2026) aplican pre-filtrado y mejoran el recall en consultas filtradas; los índices CLASSIC pueden devolver menos de K resultados.

11. Almacenes vectoriales en AWS

Amazon S3 Vectors

Buckets vectoriales (vector buckets) con índices vectoriales dentro, gestionados como S3: sin servidores ni capacidad que aprovisionar.

• Hasta 2.000 millones de vectores por índice, 10.000 índices por bucket y 10.000 buckets por región.
• Dimensiones de 1 a 4.096; métrica coseno o euclídea; tipo float32. Nombre, dimensión, métrica y claves no filtrables no se pueden cambiar tras crear el índice.
• Metadatos: hasta 40 KB por vector (filtrable + no filtrable), de los que 2 KB filtrables, hasta 50 claves y hasta 10 claves no filtrables por índice (típico: guardar ahí el texto del chunk).
• Filtros: $eq, $ne, $gt, $gte, $lt, $lte, $in, $nin, $exists, $startsWith, $and, $or.
• Latencia: subsegundo en consultas poco frecuentes y en torno a 100 ms en las frecuentes. Escrituras con consistencia fuerte.
• Hasta 500 vectores por PutVectors; top-K de hasta 10.000 por consulta.
• Precio: almacenamiento a 0,06 USD por GB-mes (us-east-1) y cobros por escritura, por consulta y por datos procesados. Para un corpus de miles de chunks: céntimos al mes.
• Integración: almacén de Bedrock Knowledge Bases (con límites propios: 1 KB de metadatos personalizados y 35 claves por vector) y con OpenSearch (exportación puntual a OpenSearch Serverless para búsquedas avanzadas, o S3 Vectors como motor de índices en dominios gestionados).

Ideal para: RAG con volumen grande y consultas moderadas, coste mínimo y cero operación. No es para latencias de un solo dígito de milisegundos ni para búsqueda híbrida con palabras clave.

Amazon OpenSearch Service (dominios gestionados)

El motor de búsqueda más completo: k-NN con los motores Faiss y Lucene (NMSLIB es el histórico; Bedrock Knowledge Bases exige Faiss), métodos HNSW e IVF, hasta 10.000 dimensiones, cuantización y modo en disco. Y además búsqueda por palabras clave (BM25), agregaciones y búsqueda híbrida.

• Neural search y ML Commons: conectores que invocan modelos de Amazon Bedrock (por ejemplo, Titan Embeddings) desde OpenSearch. Un ingest pipeline con el procesador text_embedding vectoriza al indexar, y la consulta neural vectoriza la pregunta. Hay plantillas de CloudFormation en la consola para la integración con Bedrock.
• Búsqueda híbrida: un search pipeline con el procesador de normalización (min_max o l2) y combinación (arithmetic_mean…) mezcla los resultados léxicos y vectoriales.
• Memoria: la mitad de la RAM de cada nodo va al heap de Java; los grafos k-NN usan como máximo la mitad del resto. Vigila la métrica KNNGraphMemoryUsage.
• Sharding: la guía general recomienda shards de 10–30 GiB cuando la latencia de búsqueda es prioritaria (30–50 GiB para cargas de escritura). Más shards = más paralelismo, pero demasiados shards pequeños desperdician recursos. Las réplicas aumentan la capacidad de consulta y la disponibilidad (y multiplican la memoria).
• Varios índices para dominios distintos (legal, técnico, RR. HH.): cada uno con su mapeo, su modelo y su tamaño de shard.
• Los índices k-NN pueden moverse a UltraWarm y cold storage en dominios 2.17 o posteriores.

Ideal para: búsqueda híbrida, filtros complejos, latencia baja con alto volumen de consultas y equipos que ya usan OpenSearch. Coste por instancia-hora aunque no haya consultas.

Amazon OpenSearch Serverless (colecciones de búsqueda vectorial)

OpenSearch sin gestionar clústeres. Se crea una colección de tipo vector search y se paga por OCU (OpenSearch Compute Unit, 6 GiB de memoria más CPU) de indexación y de búsqueda, más almacenamiento. Precio orientativo: 0,268 USD por OCU-hora en eu-south-2.

• Grupos de colecciones (collection groups): permiten fijar mínimos y máximos de OCU, con mínimo de 0 OCU para indexación y búsqueda (sin coste de cómputo en reposo).
• Colecciones NextGen (escalan a cero, compresión 32× por defecto) y Classic (solo HNSW con Faiss; no admiten IVF).
• Si una herramienta crea la colección por ti (por ejemplo, la creación rápida del almacén desde la consola de Knowledge Bases), revisa la capacidad configurada: una colección con mínimos de OCU encendidos 24/7 cuesta cientos de dólares al mes.

Amazon Aurora PostgreSQL y Amazon RDS for PostgreSQL con pgvector

La extensión pgvector añade el tipo vector y los índices HNSW e IVFFlat a PostgreSQL.

CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE bedrock_integration.bedrock_kb (
  id uuid PRIMARY KEY,
  embedding vector(1024),
  chunks text,
  metadata json,
  custom_metadata jsonb
);
CREATE INDEX ON bedrock_integration.bedrock_kb USING hnsw (embedding vector_cosine_ops);
CREATE INDEX ON bedrock_integration.bedrock_kb USING gin (to_tsvector('simple', chunks));

• Como almacén de Knowledge Bases (solo Aurora PostgreSQL): pgvector 0.5.0 o superior, RDS Data API activada, credenciales en Secrets Manager y un índice GIN de texto completo para la búsqueda híbrida.
• Ventaja decisiva: SQL y vectores en la misma base de datos. Unes la búsqueda semántica con tus tablas relacionales (permisos, precios, stock) y con transacciones.
• Aurora Serverless v2 admite mínimo de 0 ACU con pausa automática: sin coste de cómputo cuando no hay conexiones (pagas almacenamiento). Precio orientativo: 0,14 USD por ACU-hora en eu-south-2.
• Con pgvector 0.8.0, las consultas filtradas mejoran con el escaneo iterativo (hnsw.iterative_scan).

Ideal para: equipos con PostgreSQL, datos relacionales + vectores, RDS con documentos en S3 (metadatos y referencias en la base de datos, originales en S3).

Amazon DocumentDB

Búsqueda vectorial en clústeres basados en instancias (versión 5.0 o superior) con índices HNSW o IVFFlat, métricas euclidean, cosine y dotProduct e índices de hasta 2.000 dimensiones. Ideal si tus datos ya son documentos JSON en DocumentDB (compatible con MongoDB).

Amazon Neptune Analytics

Base de datos de grafos en memoria con un índice vectorial por grafo (dimensión fija, de 1 a 65.535, definida al crear el grafo). Bedrock Knowledge Bases lo usa para GraphRAG: combina búsqueda vectorial con las relaciones entre entidades para preguntas que requieren conectar información (módulo 3).

Amazon ElastiCache y Amazon MemoryDB

• ElastiCache for Valkey 8.2 incluye búsqueda vectorial (HNSW y FLAT; coseno, euclídea y producto escalar) en clústeres basados en nodos sin coste adicional, con latencias de microsegundos. Su uso estrella: caché semántica (guardar respuestas a preguntas parecidas para no volver a invocar el modelo, módulo 9).
• MemoryDB también ofrece búsqueda vectorial en memoria con durabilidad, limitada a un único shard.

Amazon DynamoDB

• Desde el 5 de agosto de 2026, DynamoDB ofrece búsqueda vectorial nativa (índices vectoriales de hasta 4.096 dimensiones, métricas COSINE, EUCLIDEAN y DOT_PRODUCT, filtros de coincidencia exacta y hasta 100 resultados por consulta). No figura como almacén de Bedrock Knowledge Bases.
• Su papel clásico en IA generativa, y el que cita la guía del examen: almacenar metadatos (propietario, versión, permisos, estado de indexación), historial de conversaciones y registro de qué se ha vectorizado, junto a un almacén vectorial.
• La integración zero-ETL con OpenSearch (mediante OpenSearch Ingestion y DynamoDB Streams) mantiene un índice de OpenSearch sincronizado con una tabla sin escribir código.

Otros almacenes compatibles con Knowledge Bases

Pinecone, Redis Enterprise Cloud y MongoDB Atlas (servicios de terceros).

Tabla de decisión (con coste)

Precios orientativos a 1 de octubre de 2026; confírmalos en la página de precios de cada servicio.

flowchart TD
  A["¿Qué necesitas?"] --> B{"¿Búsqueda híbrida o filtros complejos con alto volumen de consultas?"}
  B -->|"Sí"| C{"¿Quieres gestionar clústeres?"}
  C -->|"Sí"| D["OpenSearch Service"]
  C -->|"No"| E["OpenSearch Serverless"]
  B -->|"No"| F{"¿Datos relacionales o PostgreSQL existente?"}
  F -->|"Sí"| G["Aurora PostgreSQL + pgvector"]
  F -->|"No"| H{"¿Relaciones entre entidades?"}
  H -->|"Sí"| I["Neptune Analytics (GraphRAG)"]
  H -->|"No"| J{"¿Caché semántica de microsegundos?"}
  J -->|"Sí"| K["ElastiCache (Valkey)"]
  J -->|"No"| L["S3 Vectors (coste mínimo)"]

12. Arquitecturas vectoriales avanzadas (Skills 1.4.1 y 1.4.3)

La guía del examen cita varios patrones concretos:

• Organización jerárquica con Knowledge Bases: chunking jerárquico (padre-hijo) para buscar con precisión y devolver contexto amplio; o dos niveles de índice (hierarchical indexing): un índice de resúmenes de documento para localizar los documentos relevantes y otro de chunks detallados dentro de ellos.
• OpenSearch con el plugin Neural e integración con Bedrock para segmentación por temas: el pipeline de ingesta vectoriza con Bedrock y cada documento se etiqueta por tema (clasificación con un FM o con Comprehend); las consultas se dirigen al índice o al filtro del tema correcto.
• Amazon RDS con un repositorio de documentos en S3: la base de datos guarda metadatos, vectores (pgvector) y la clave S3 del original; el documento completo vive en S3 (barato y versionado).
• DynamoDB para metadatos + base de datos vectorial para embeddings: DynamoDB guarda el estado de cada documento (hash, versión, fecha de indexación, permisos) y el almacén vectorial, los vectores con el ID como clave común.
• Multi-índice para dominios especializados: un índice por dominio (legal, técnico, médico), cada uno con su modelo de embeddings y su chunking, y un enrutador que decide dónde buscar.
• Sharding en OpenSearch: dimensionar shards y réplicas según volumen y latencia; separar índices calientes y fríos.

flowchart LR
  Q["Consulta"] --> R["Lambda: enrutador por dominio"]
  R --> I1["Índice legal (OpenSearch)"]
  R --> I2["Índice técnico (OpenSearch)"]
  I1 --> M["Fusión y reranking"]
  I2 --> M
  M --> FM["Modelo fundacional"]
  DDB["DynamoDB: metadatos, versiones, permisos"] -.-> R
  S3["S3: documentos originales"] -.-> FM

13. Metadatos: precisión y contexto (Skill 1.4.2)

Los vectores dicen «de qué trata» un chunk; los metadatos dicen de dónde viene, de quién es, de cuándo es y a quién va dirigido. Con ellos puedes filtrar (solo documentos vigentes, solo del país del usuario), citar la fuente y controlar el acceso.

Dónde viven en AWS:

• Metadatos de objeto de S3 definidos por el usuario (cabeceras x-amz-meta-, hasta 2 KB; no se pueden cambiar sin copiar el objeto) y etiquetas de objeto. S3 Metadata genera tablas Iceberg de solo lectura con los metadatos de los objetos, consultables con Athena.
• Ficheros de metadatos de Knowledge Bases: junto a cada documento, un fichero nombre.extension.metadata.json (máximo 10 KB) con metadataAttributes:

{
  "metadataAttributes": {
    "departamento": "legal",
    "anio": 2026,
    "autor": "Lucía Martín",
    "confidencialidad": "interna"
  }
}

• Metadatos del vector en el almacén: en S3 Vectors, filtrables (hasta 2 KB, para filtrar) y no filtrables (para devolver, como el texto del chunk).

14. Conectar con las fuentes de la empresa (Skill 1.4.4)

15. Mantener el índice al día (Skill 1.4.5)

Un índice desactualizado produce respuestas con información vieja, con total seguridad. Mecanismos:

flowchart LR
  S3["S3: corpus"] -->|"Object Created o Deleted"| EB["EventBridge"]
  EB --> L["Lambda"]
  L -->|"cambios sueltos"| DI["IngestKnowledgeBaseDocuments / DeleteKnowledgeBaseDocuments"]
  SCH["EventBridge Scheduler (noche)"] --> SJ["StartIngestionJob (incremental)"]
  DI --> KB["Knowledge Base"]
  SJ --> KB
  KB --> CW["CloudWatch: estado de ingesta y alarmas"]

No olvides los borrados: si un documento se retira, su vector debe desaparecer, o el modelo seguirá citando una política derogada. Y vigila la calidad: métricas de documentos ingeridos y fallidos en CloudWatch, y pruebas de recuperación periódicas (módulo 10).

16. Gestionar el corpus en S3

Trampas típicas del examen

• «Validar datos con reglas declarativas y alertas» → Glue Data Quality (DQDL). No confundir con SageMaker Clarify (sesgo, en mantenimiento) ni con Macie (PII en S3).
• «OCR con tablas y formularios» → Textract; «extraer campos de documentos, imágenes y audio con blueprints» → Bedrock Data Automation; «transcribir llamadas con quién habla» → Transcribe con diarización.
• Transcribe en español de España: redacción de PII solo en streaming y sin modelos de lenguaje personalizados. Si el enunciado exige redacción en lotes, fíjate en el dialecto.
• Comprehend PII funciona en inglés y español; Topic Modeling y Prompt Safety Classification están en mantenimiento.
• Cambiar de modelo de embeddings → re-vectorizar todo el corpus. No se pueden mezclar vectores.
• Dimensiones: menos dimensiones = menos coste y latencia; binario solo con OpenSearch en Knowledge Bases.
• Chunking jerárquico devuelve menos resultados de los pedidos (varios hijos, un padre) y no se recomienda con S3 Vectors.
• Chunking semántico cuesta más (usa un modelo).
• S3 Vectors: dimensión, métrica y claves no filtrables inmutables; solo coseno o euclídea; sin búsqueda por palabras clave.
• Búsqueda híbrida → OpenSearch (o Aurora con índice de texto completo en Knowledge Bases).
• OpenSearch Serverless con mínimos de OCU encendidos cuesta 24/7: usa grupos de colecciones con mínimo 0 OCU si el tráfico es intermitente.
• HNSW = rápido y preciso pero memoria alta; IVF = menos memoria, requiere entrenamiento.
• Índice obsoleto → sincronización incremental dirigida por eventos, no reindexar todo cada noche.
• Metadatos de Knowledge Bases → fichero .metadata.json junto al documento (máximo 10 KB).

Resumen

• Datos buenos antes que modelos caros: valida (Glue Data Quality, Lambda + CloudWatch), procesa (Textract, Transcribe, BDA, modelos multimodales, SageMaker Processing) y mejora (normalizar, Comprehend, reformatear con un FM).
• Formatea según la API: cuerpo nativo con InvokeModel, mensajes y bloques con Converse, JSONL para lotes, el esquema del contenedor en SageMaker.
• Chunking: fijo (simple), jerárquico (precisión + contexto), semántico (coherente pero más caro), por estructura (respeta secciones). Mide con preguntas reales.
• Embeddings: mismo modelo para indexar y consultar; elige por idioma, modalidad, dimensiones y región. Titan V2: 256, 512 o 1.024 dimensiones.
• Métricas: coseno (la habitual), euclídea, producto escalar (igual que coseno con vectores normalizados), Hamming para binarios.
• Índices ANN: HNSW (recall y latencia, más memoria) frente a IVF (menos memoria, entrenamiento); cuantización para escalar.
• Almacenes: S3 Vectors (coste mínimo), OpenSearch (híbrida y escala), Aurora pgvector (relacional + vectores), Neptune (grafos), ElastiCache (caché semántica), DynamoDB (metadatos y ahora también vectores).
• Metadatos para filtrar, citar y controlar acceso; sincronización incremental dirigida por eventos para no servir información caducada.

Cobertura del temario

Practica lo aprendido

Documentación oficial para ampliar

• AWS Glue Data Quality
• Amazon Bedrock Data Automation
• Chunking en Bedrock Knowledge Bases
• Amazon Titan Text Embeddings
• Amazon S3 Vectors
• Búsqueda vectorial en Amazon OpenSearch Service
• pgvector en Aurora PostgreSQL
• Almacenes vectoriales soportados por Knowledge Bases