Capítulo 03 — Ground: la capa de datos de un agente

Por: Artiko
awsfdegroundlakehousepgvectorknowledge-basesontologia

Ground: la capa de datos de un agente

Ground responde la primera pregunta del cliente: ¿el agente entiende mi negocio y usa información confiable? Sus tres actividades (250 puntos) son dos microcredentials y una SimuLearn. Es el pathway recomendado para Validated: el único testimonio público lo describe como el más directo.

flowchart LR
    S3[(S3 · Iceberg)] --> Glue[AWS Glue ETL]
    Glue --> LF[Lake Formation]
    LF --> Athena[Athena]
    Docs[(Documentos)] --> KB[Bedrock Knowledge Bases]
    KB --> Aurora[(Aurora PostgreSQL · pgvector)]
    DDB[(DynamoDB · memoria)] --> Agent[Agente]
    Aurora --> Agent
    Athena --> Agent
    Onto[Ontología de dominio] -.gobierna.-> KB
    Onto -.gobierna.-> Aurora

3.1 Lakehouse gobernado

Prepara AWS Data Lakehouse Demonstrated (110 minutos, 100 puntos). Descripción oficial: diagnosticar y reparar una plataforma lakehouse rota resolviendo la ingestión ETL con AWS Glue, la optimización de tablas Apache Iceberg y la gobernanza con AWS Lake Formation. Servicios: Amazon Athena, AWS Glue, Apache Iceberg, Amazon EventBridge, AWS Lake Formation, Amazon S3.

Por qué importa para un agente: un agente que responde con cifras de negocio necesita datos con linaje, permisos finos por columna y frescura garantizada. Sin eso, Prove no tiene nada que evaluar.

Ejercicio en cuenta propia:

  1. Crear un bucket, un crawler y un job de Glue que escriba una tabla Iceberg particionada.
  2. Romper el job de tres formas (esquema incompatible, rol sin permisos, partición mal declarada) y repararlo leyendo solo CloudWatch Logs.
  3. Ejecutar OPTIMIZE y VACUUM sobre la tabla en Athena; contar archivos pequeños antes y después.
  4. Registrar la ubicación en Lake Formation, otorgar permisos de columna a un rol de analista y verificar la denegación desde Athena.
  5. Disparar el job con una regla de EventBridge al llegar un objeto a S3.

Recursos: Data Engineering for Generative AI Applications (300 min, gratis), AWS SimuLearn: Federated Queries, documentación de Glue con Iceberg y de Lake Formation.

  • Reparé un job de Glue roto sin pistas dentro del tiempo del lab.
  • Explico por qué un agente necesita datos gobernados.

3.2 Bases de datos para agentes

Prepara AWS Databases for Agentic AI Demonstrated (140 minutos, 100 puntos). Descripción oficial: restaurar un agente de inteligencia de clientes roto configurando Amazon Aurora PostgreSQL y Amazon DynamoDB para acceso y memoria del agente, pgvector y Amazon Bedrock Knowledge Bases para recuperación de documentos, servidores MCP para depurar las interacciones del agente con la base de datos y optimizar sus consultas. Servicios: Aurora, Bedrock, CloudWatch, DynamoDB, Lambda, Secrets Manager.

ComponenteRol en el agenteQué suele romperse
Aurora PostgreSQL + pgvectorDatos transaccionales y embeddings en el mismo motorExtensión no creada, índice vectorial ausente, consultas sin filtro previo
DynamoDBMemoria de sesión y estado por conversaciónClave de partición mal elegida, TTL sin configurar
Bedrock Knowledge BasesRAG gestionado sobre S3 con Aurora como vector storeSincronización pendiente, rol sin acceso al bucket o al secreto
MCP serverEl agente consulta la base y el ingeniero depura con el mismo contratoCredenciales expuestas, consultas sin límite
Secrets ManagerCredenciales de la baseRotación rota, política IAM incompleta

Ejercicio en cuenta propia:

  1. Aurora PostgreSQL Serverless v2; CREATE EXTENSION vector; tabla de embeddings con índice HNSW; consulta de similitud con <=>.
  2. Knowledge Base de Bedrock sobre un bucket S3 con Aurora como almacén vectorial; probar Retrieve y RetrieveAndGenerate.
  3. Tabla DynamoDB para memoria de sesión (clave sessionId, orden timestamp, TTL) y una Lambda que la lea y escriba.
  4. Un MCP server (Lambda o contenedor) que exponga run_query sobre Aurora; usarlo desde un agente Strands para localizar una consulta lenta; crear el índice que falta y comparar con EXPLAIN ANALYZE.
  5. Credenciales en Secrets Manager; métricas de latencia de consulta en CloudWatch.

Recursos: Build and scale agentic AI apps with Amazon Aurora: Multi-agent orchestration (60 min, gratis), Build AI Agents That Remember: Agentic Memory with Valkey (60 min, gratis), AWS SimuLearn: Build and Deploy Tools Using LLM Agents.

  • pgvector y Knowledge Base funcionando de punta a punta.
  • Diagnostiqué una consulta lenta desde un MCP server y la optimicé.

3.3 Persistencia políglota anclada en ontologías

Prepara AWS SimuLearn: Ontology-Grounded Polyglot Persistence for Agentic Applications (1 hora, 50 puntos).

Escenario oficial: una aseguradora comercial quiere que sus suscriptores confíen en un asistente de IA solo si cumple el bar de un auditor: cada cifra se rastrea a una fuente auditada, cada póliza resuelve a la métrica gobernada que le aplica y cada conversación es privada. El sistema actual falla en cuatro puntos: un agente puede leer la memoria privada de otro, los documentos recuperados no están ligados a las reglas que los gobiernan, la búsqueda de documentos no devuelve nada usable y el grafo de conocimiento acepta consultas arbitrarias sin control.

Conceptos:

  • Ontología de dominio: entidades, relaciones y métricas gobernadas del negocio (póliza, asegurado, siniestro, prima, límite). Es lo que permite que “prima del período” signifique lo mismo para el agente y para el auditor.
  • Persistencia políglota: cada dato en el motor adecuado. Relacional y vectorial en Aurora, memoria por sesión en DynamoDB, relaciones en un grafo (Neptune o tablas de aristas en Aurora).
  • Aislamiento de memoria: políticas IAM y claves por agente que impiden lecturas cruzadas.
  • Consultas acotadas al grafo: lista blanca de plantillas de consulta en lugar de consultas libres.

Ejercicio: modelar la ontología de un dominio del partner en un classDiagram de Mermaid; decidir qué va en cada almacén; escribir las políticas IAM que impiden lecturas cruzadas de memoria; definir cinco plantillas de consulta permitidas sobre el grafo.

classDiagram
    class Poliza { id; vigencia; limite; primaGobernada }
    class Asegurado { id; segmento }
    class Siniestro { id; monto; estado }
    class Documento { id; fuente; version }
    class Regla { id; metrica; alcance }
    Asegurado "1" --> "*" Poliza
    Poliza "1" --> "*" Siniestro
    Documento --> Regla : gobernado por
    Poliza --> Regla : resuelve a
  • Ontología del dominio dibujada y defendida ante el equipo.
  • SimuLearn aprobada en la fase DIY.

Cierre del pathway

Con las tres actividades aprobadas, la pestaña Ground marca 3 de 3 y el contador 250 puntos. Para Validated faltan 350 puntos: el capítulo 5 explica cómo conseguirlos. Las microcredentials aprobadas otorgan además sus propias insignias de Credly.