Bedrock en producción: qué resuelven las piezas gestionadas y qué no

Bedrock es la vía más rápida para tener un asistente funcionando en AWS. Una Knowledge Base apuntando a un bucket de S3 te da troceado, embeddings, un almacén vectorial y una API de recuperación en una tarde, sin alojar modelos ni pedir cuota de GPU.

Esa tarde es real y merece la pena. Lo que no hace es tomar por ti las cuatro decisiones difíciles, y los equipos que asumen que sí son los que siguen en piloto seis meses después. Escribimos sobre esas decisiones en general en las cuatro que deciden un proyecto de RAG; aquí están vistas específicamente en Bedrock.

Lo que las piezas gestionadas sí resuelven

Knowledge Bases se encargan de la ingesta, el troceado, los embeddings y un almacén vectorial gestionado (OpenSearch Serverless por defecto, o Aurora pgvector, Pinecone, Redis). La API de recuperación y generación devuelve citas con el URI de origen, que es la función que más cambia la confianza del usuario. Si tu corpus son documentos en S3 y tu modelo de acceso es "quien puede usar el asistente puede ver todo", esto es de verdad casi todo el trabajo hecho.

Guardrails te da filtros de contenido, temas denegados, redacción de datos personales y, sobre todo, comprobaciones de anclaje contextual que puntúan si la respuesta está respaldada por los pasajes recuperados. Esa puntuación de anclaje es el control de alucinaciones más barato que existe y se aplica con independencia del modelo.

Rendimiento aprovisionado frente a bajo demanda es una decisión real de coste, no un trámite. Bajo demanda está bien hasta que tienes tráfico estable; aprovisionado tiene sentido a partir de unos cientos de miles de tokens por hora y es la única forma de tener capacidad garantizada para un SLA de latencia.

Lo que sigues teniendo que decidir tú

Permisos. Esta es la que hunde proyectos. Una Knowledge Base recupera de todo su índice; si tus documentos tienen audiencias distintas, necesitas filtrado por metadatos — adjunta metadatos a cada documento en la ingesta y pasa un filtro en consulta derivado de la identidad de quien pregunta. Construir ese filtro a partir de los grupos del usuario, mantenerlo sincronizado cuando alguien cambia de equipo y demostrarlo en una auditoría es trabajo tuyo, no de Bedrock. No lo pospongas: añadir permisos a un índice ya vivo significa reingerirlo todo.

Troceado para tus documentos. El troceado de tamaño fijo por defecto vale para prosa y es malo para tablas, contratos y cualquier cosa con estructura. Bedrock admite troceado jerárquico y semántico, más una transformación propia en Lambda. Para documentación técnica y contratos casi siempre acabamos con una transformación propia que mantiene las cabeceras de sección pegadas a cada fragmento, lo que mejora la recuperación más que ningún cambio de modelo.

Calidad de recuperación y búsqueda híbrida. La recuperación solo vectorial se pierde los términos exactos: códigos de producto, números de error, nombres. Activa la búsqueda híbrida en el backend de OpenSearch Serverless para que la coincidencia por palabra clave corra junto a los vectores. Y después mide — con un conjunto de cincuenta preguntas reales y el documento correcto para cada una, comprobado en cada cambio.

Modelo por paso. No estás obligado a usar un solo modelo. Uno barato y rápido para reescribir consultas y clasificar, uno fuerte para la respuesta final y quizá un tercero como juez en tu arnés de evaluación. Bedrock convierte el cambio en un parámetro, que es el argumento principal para usarlo frente a integrar un proveedor directamente.

Coste, con honestidad

Tres líneas: tokens, almacén vectorial y embeddings. El almacén vectorial sorprende — OpenSearch Serverless tiene un suelo mínimo de capacidad que cuesta dinero real al mes pregunte alguien o no. Para corpus pequeños, Aurora Serverless con pgvector suele salir más barato. Cotiza ambos antes de comprometerte; en un asistente pequeño la diferencia puede ser mayor que la factura de tokens.

Mide el coste por pregunta desde el primer día, etiquetado por equipo. Un asistente cuyo coste nadie puede atribuir es un asistente que se apaga en la siguiente ronda de presupuesto.

Dónde encaja

Bedrock es el valor por defecto correcto en AWS cuando tus datos ya están allí, tu historia de cumplimiento es más fácil si nada sale de la cuenta y tu equipo es lo bastante pequeño como para que la fontanería gestionada valga más que el control máximo. Cuando necesitas lógica de recuperación propia, un reordenador que afinas tú o un modelo que Bedrock no aloja, la capa de recuperación es la parte que recuperas, no la pila entera — y así es como solemos construirlo en un proyecto de IA aplicada.

Qué hacer esta semana

Escribe tu conjunto de cincuenta preguntas de evaluación con el documento esperado para cada una, antes de construir nada. Es una mañana con un experto de dominio, es lo único que te dice si un cambio ayudó y es el artefacto que todo proyecto de RAG atascado resulta no tener.