En esta charla mostraremos cómo AWS Bedrock puede conectarse a una base de datos tradicional, comprender su estructura, y generar consultas a partir de …

speakerdeck.com

Integrando IA Generativa con Bases de Datos Relacionales en AWS

Foundation Models y el ecosistema de Bedrock

Antes de entrar en la implementación, vale la pena aclarar los conceptos base. La IA Generativa, en términos prácticos, es un tipo de IA capaz de crear nuevo contenido: textos, conversaciones, resúmenes, imágenes.

Los Foundation Models son los modelos de aprendizaje automático que hacen esto posible, entrenados sobre cantidades masivas de datos no etiquetados y luego adaptados para tareas específicas como generación de texto, extracción de información, Q&A o chatbots.

AWS Bedrock es el servicio que te da acceso a varios de estos modelos — desde Claude de Anthropic hasta Titan de Amazon, Llama 2 de Meta, Mistral, Cohere y Stable Diffusion — a través de una API unificada, sin tener que administrar infraestructura de ML por tu cuenta.

Arquitectura

La arquitectura que propuse es deliberadamente simple: un usuario interactúa con una aplicación, esta invoca una Lambda Function, la Lambda se conecta a Amazon Aurora, y Aurora llama a Bedrock directamente usando Aurora ML. Este componente es la pieza central del patrón — Aurora ML es una característica de Amazon Aurora (disponible desde la versión 3.06 en adelante) que permite invocar algoritmos de machine learning directamente desde SQL. Esto significa que puedes hacer un SELECT que internamente llama a un Foundation Model en Bedrock y regresa el resultado como si fuera cualquier otro valor de la base de datos. La simpleza de esto es lo que hace la integración tan poderosa: los datos nunca salen de Aurora, no hay ETL, no hay pipelines intermedios.

Pre-requisitos

La configuración requiere cuatro pasos previos:

1. Crear un IAM Role con los permisos necesarios para que Aurora pueda llamar a Bedrock, y asignar ese rol al cluster.


2. Habilitar los modelos base en la consola de Bedrock para la región donde está tu cluster — esto es un paso explícito que AWS requiere antes de poder usarlos.


3. Crear las funciones SQL que mapean a cada modelo de Bedrock.

Este último paso es lo más interesante: con apenas un CREATE FUNCTION que usa el alias AWS_BEDROCK_INVOKE_MODEL y especifica el MODEL ID, ya tienes disponible en tu base de datos una función que puedes llamar desde cualquier query o stored procedure. En la demo creé dos funciones, una para Amazon Titan y otra para Claude 3 Haiku.

CREATE FUNCTION invoke_titan (request_body TEXT)

RETURNS TEXT

ALIAS AWS_BEDROCK_INVOKE_MODEL

MODEL ID 'amazon.titan-text-express-v1'

CONTENT_TYPE 'application/json'

ACCEPT 'application/json';



CREATE FUNCTION claude3_haiku (request_body TEXT)

RETURNS TEXT

ALIAS AWS_BEDROCK_INVOKE_MODEL

MODEL ID 'anthropic.claude-3-haiku-20240307-v1:0'

CONTENT_TYPE 'application/json'

ACCEPT 'application/json';

Casos de uso

Para ilustrar los patrones usé el dataset público de películas de IMDb, que incluye títulos, calificaciones, géneros e información de personas.

Insights de cultura pop

El primer caso fue generar análisis culturales sobre películas de los 90s. Un stored procedure itera sobre las películas más populares de la década, construye un prompt con el título, año y géneros de cada una, lo pasa a Claude 3 Haiku vía la función SQL, y guarda el resultado en una tabla de title_insights. El modelo recibe el contexto de que la película fue lanzada en los 90s y genera análisis sobre qué reflejaba sobre el momento histórico, qué tendencias capturaba y por qué resonó con su audiencia. Todo esto ejecutado desde un simple CALL generate_90s_insights().

Consultas en lenguaje natural

El segundo caso fue más interesante: un stored procedure natural_language_query recibe una pregunta en texto libre — por ejemplo, "Encuentra las 10 películas mejor calificadas de la década de 1990" — y hace dos cosas. Primero, le pasa esa pregunta a Bedrock junto con el schema de la base de datos como contexto, pidiendo que genere únicamente el SQL necesario para responderla. Segundo, ejecuta ese SQL generado dinámicamente con PREPARE y EXECUTE.

El truco está en el prompt engineering: hay que ser muy explícito en las instrucciones — solo SQL ejecutable, sin explicaciones, sin markdown, sin backticks — y luego limpiar la respuesta con REGEXP_REPLACE antes de ejecutarla. El resultado es que un usuario sin conocimiento de SQL puede hacer preguntas en lenguaje natural y obtener resultados reales de la base de datos.

Resumen de películas

El tercer caso fue enriquecimiento en batch: un procedimiento que toma películas sin resumen en la base de datos, construye un prompt con título, año y géneros, y le pide a Claude que genere una descripción breve. El resultado se guarda directamente con un UPDATE. Un CALL generate_movie_summaries() es todo lo que necesitas para enriquecer un catálogo entero.

Casos avanzados

Más allá de estos tres patrones básicos, la integración abre posibilidades más sofisticadas: análisis de query plans con sugerencias de índices, detección de anomalías en datos con propuestas de corrección automática, o análisis de evolución de schemas. En todos los casos el patrón es el mismo — datos de Aurora como contexto, Foundation Model como motor de razonamiento, resultado guardado de vuelta en la base de datos.

Mejores prácticas

Hay cuatro áreas que vale subrayar:

Safe defaults. Configurar defaults seguros tanto a nivel de base de datos como del cliente, para evitar que errores del modelo afecten datos críticos.

Chain of Transformations. Pensar en los flujos de enriquecimiento como cadenas de transformaciones explícitas: get_data() → enrich_with_ai() → validate_data() → store_in_db(). No mezclar estas responsabilidades en un solo procedimiento.

Prompt Engineering con templates. La calidad del output depende directamente de la calidad del prompt. Vale la pena invertir tiempo en construir plantillas bien estructuradas y reutilizables.

Caching, rate limiting y manejo de errores. Implementar caching inteligente para consultas similares, rate limiting para evitar resource exhaustion cuando el volumen escala, y manejo de errores robusto para cuando el modelo devuelve algo inesperado.

Observabilidad

Las métricas que más importan en este tipo de integración son:

• Latencia de generación de prompts


• Tasa de éxito y fallo de llamadas al LLM


• Calidad de respuestas (requiere algún tipo de evaluación downstream)


• Consumo de tokens y costos asociados


• Cache hit/miss ratio

Consideraciones

El control de acceso a datos sensibles es una preocupación válida. Bedrock Guardrails y el abuse detection nativo son los mecanismos disponibles para esto. También hay que tener en cuenta las limitaciones inherentes de precisión de los modelos, que hacen necesario validar outputs antes de usarlos en decisiones críticas.

Para quienes prefieran alternativas open source, el patrón equivalente sería PostgreSQL o MariaDB conectado a LangChain, con LLaMA 2 o Mistral como modelo, y un Vector Store para búsqueda semántica. Es una arquitectura perfectamente válida, con más flexibilidad pero también más infraestructura que administrar.

Resumen

Este patrón es valioso por tres razones concretas: facilita el acceso a datos complejos sin mover nada fuera de la base de datos, puede incorporarse a infraestructuras Aurora existentes sin rediseño mayor, y aprovecha Foundation Models de clase mundial con la misma interfaz SQL que tu equipo ya conoce.

El código de la demo está disponible en GitHub bajo Amazon Bedrock and Aurora MySQL Integration.