Knowledge Bases en Bedrock: RAG administrado sin servidores

By Carlos Montiel | Especialista en IA Empresarial
Publicado: 2026-07-28 | Por: Carlos Montiel | Lectura: ~5 minutos

Construir RAG desde cero implica administrar ingestión, embeddings, un vector store y la lógica de recuperación. Knowledge Bases for Amazon Bedrock convierte eso en configuración declarativa.

Qué automatiza una Knowledge Base

Retrieval-Augmented Generation (RAG) resuelve un problema concreto: los modelos fundacionales no conocen los documentos internos de su empresa. La alternativa de fine-tuning es cara y se vuelve obsoleta cada vez que cambian los documentos; RAG en cambio recupera fragmentos relevantes en tiempo de consulta y los inyecta como contexto del prompt.

Knowledge Bases for Amazon Bedrock automatiza el pipeline completo: ingesta documentos desde una fuente de datos (S3, Confluence, SharePoint, Salesforce, o un rastreador web), los divide en fragmentos (chunking), genera embeddings vectoriales con un modelo como Titan Text Embeddings o Cohere Embed, los almacena en un vector store, y expone una API de recuperación semántica. Sin esto, un equipo tendría que orquestar manualmente Textract o un parser de documentos, un job de embeddings, y una capa de indexación vectorial.

Fuentes de datos y sincronización

La fuente de datos más común es un bucket S3 con documentos PDF, DOCX, TXT, CSV o HTML. Cada vez que se agregan o modifican documentos, se dispara un job de sincronización (`StartIngestionJob`) que reprocesa solo los archivos nuevos o cambiados — Bedrock rastrea el estado de sincronización por documento, evitando reprocesar todo el corpus en cada actualización.

import boto3 client = boto3.client("bedrock-agent") client.start_ingestion_job( knowledgeBaseId="ABCD1234", dataSourceId="XYZ9876", description="Sincronización de manuales técnicos actualizados", )

Elegir el vector store correcto

Bedrock soporta múltiples backends de vector store: Amazon OpenSearch Serverless (la opción administrada por defecto, sin necesidad de aprovisionar clústeres), Amazon Aurora PostgreSQL con la extensión pgvector, Amazon Neptune Analytics, Pinecone y Redis Enterprise Cloud. La elección importa en costo y latencia: OpenSearch Serverless cobra por OCU (OpenSearch Compute Unit) con un mínimo de capacidad reservada incluso en baja actividad, mientras que Aurora pgvector reutiliza infraestructura relacional existente si ya opera bases de datos ahí, con un costo marginal menor para volúmenes moderados.

Para equipos que ya tienen Aurora PostgreSQL en su stack, pgvector suele ser la opción de menor fricción operativa. Para volúmenes de vectores grandes (decenas de millones) con necesidad de baja latencia consistente, OpenSearch Serverless escala mejor sin intervención manual.

Estrategias de chunking y su impacto en la calidad

El chunking determina qué tan relevante es lo que se recupera. Bedrock ofrece varias estrategias: fixed-size chunking (tamaño fijo en tokens, con overlap configurable), semantic chunking (divide por límites semánticos usando el propio modelo de embeddings), y hierarchical chunking (fragmentos pequeños anidados dentro de fragmentos padre más grandes, útil cuando la respuesta necesita contexto amplio pero la búsqueda debe ser precisa).

Un error frecuente es usar fragmentos demasiado grandes (2000+ tokens): diluyen la relevancia semántica y encarecen cada consulta al inyectar más tokens de contexto de los necesarios. Fragmentos de 300-500 tokens con 10-20% de overlap suelen ser un punto de partida razonable para documentación técnica y políticas internas.

La API Retrieve and Generate

response = client.retrieve_and_generate( input={"text": "¿Cuál es la política de reembolsos para clientes empresariales?"}, retrieveAndGenerateConfiguration={ "type": "KNOWLEDGE_BASE", "knowledgeBaseConfiguration": { "knowledgeBaseId": "ABCD1234", "modelArn": "arn:aws:bedrock:us-east-1::foundation-model/anthropic.claude-sonnet-5", "retrievalConfiguration": { "vectorSearchConfiguration": {"numberOfResults": 5} }, }, }, ) print(response["output"]["text"]) for citation in response["citations"]: print(citation["retrievedReferences"])

Este endpoint hace en una sola llamada lo que antes requería tres pasos manuales: buscar en el vector store, ensamblar el prompt con el contexto recuperado, e invocar el modelo generador. La respuesta incluye citaciones con las referencias exactas a los fragmentos usados, esencial para auditoría en sectores regulados.

Cuándo RAG no es suficiente

Knowledge Bases resuelve bien preguntas sobre conocimiento estático y semánticamente localizable. No resuelve bien preguntas que requieren agregación numérica sobre grandes volúmenes de datos estructurados (para eso, considere una herramienta de consulta SQL vía un Agent), ni preguntas que requieren razonamiento multi-hop complejo sobre relaciones no explícitas en el texto. Evalúe la tasa de recuperación (recall) con un conjunto de preguntas reales de su dominio antes de asumir que RAG cubre el caso de uso completo — Bedrock Evaluations permite medir esto de forma sistemática, tema que profundizamos en el artículo sobre comparación de modelos.

Carlos Montiel
Arquitecto de Soluciones IA Empresarial
Especialista en LLMs, Agentes y Orquestación
guatemalia.com/#contacto · info@guatemalia.com

¿Necesitas implementar IA en tu empresa?

Carlos Montiel es arquitecto de soluciones IA empresarial. Implementa LLMs, Agentes, RAG y orquestadores en empresas de Guatemala y Latinoamérica. Contáctalo para una consultoría.

Contactar a Carlos Montiel

info@guatemalia.com