Cree una capa semántica para IA agente en AWS con Stardog y Amazon Bedrock AgentCore

En esta publicación, mostramos cómo crear una capa semántica en AWS utilizando la aplicación Semantic AI de Stardog sobre Amazon Aurora y Amazon Redshift, y cómo ejecutar un agente de Strands Agents en Amazon Bedrock AgentCore que consulta la capa para responder a las preguntas 360 de los clientes en ambas fuentes sin extracción, transformación y carga (ETL). La misma implementación de Stardog funciona detrás de las computadoras de AWS (Amazon Elastic Kubernetes Service (Amazon EKS), Amazon Elastic Container Service (Amazon ECS) y AWS Lambda). Usamos AgentCore aquí porque agrupa las credenciales de autenticación entrante, alojamiento y herramientas en un solo servicio administrado.

La analítica empresarial ha estado persiguiendo el mismo objetivo durante dos décadas: reducir el tiempo entre una pregunta empresarial y una respuesta confiable. Los informes programados dieron paso a los paneles, luego los paneles dieron paso a la inteligencia empresarial (BI) de autoservicio. Incluso el autoservicio dependía de que un ingeniero de datos ya hubiera creado el modelo correcto para la pregunta correcta, y el analista humano seguía siendo el cuello de botella para todo lo que estaba fuera del conjunto de datos preparado. Los agentes de IA generativa son el siguiente paso. En lugar de visualizar datos, razonan sobre ellos. Planifican, escriben consultas, evalúan resultados, refinan e iteran con los datos en vivo de la empresa bajo demanda. Análisis agente es el término para este cambio: un agente autónomo al lado de cada usuario de negocio, haciendo el trabajo del analista sin esperar en la cola de solicitudes.

La parte difícil ya no es el modelo básico (FM). Los modelos básicos disponibles en Amazon Bedrock ya pueden planificar flujos de trabajo de varios pasos, razonar sobre esquemas y producir SQL lo suficientemente bien como para actuar como lo haría un analista junior. La parte difícil se encuentra debajo: los datos sobre los que razona el modelo. Los datos empresariales se encuentran dispersos en sistemas que definen las mismas cosas de manera diferente. El "cliente" en su sistema de gestión de relaciones con el cliente (CRM) no es el mismo registro que el "cliente" en su sistema de facturación. Los “ingresos” calculados por el equipo norteamericano no son los mismos que produciría el equipo europeo. Un agente de IA al que se le dé acceso directo a estos datos fragmentados escribirá consultas técnicamente válidas que arrojarán respuestas incorrectas, conflictivas o inexplicables. La confianza se erosiona la primera vez que dos agentes devuelven dos números diferentes para la misma pregunta.

En AWS, esos datos se encuentran en una combinación familiar. Los registros operativos se encuentran en Amazon Aurora y otros motores de Amazon Relational Database Service (Amazon RDS). La historia de la analítica vive en Amazon Redshift. Los datos no estructurados residen en Amazon Simple Storage Service (Amazon S3), consultados a través de Amazon Athena y, cada vez más, en formatos de tablas abiertas como Apache Iceberg, en Amazon S3 Tables, una capacidad de Amazon S3, que Athena, Amazon EMR y Amazon Redshift pueden leer. Cada capa está diseñada específicamente para lo que almacena y la mayoría de las empresas mantendrán esa forma. El desafío es ayudar a un agente de IA a razonar sobre todos ellos a la vez con la misma fluidez que un analista humano senior plantearía a la misma pregunta.

Los modelos básicos aportan el lenguaje y la aplicación de datos de AWS aporta los hechos. La forma habitual de conectarlos hoy en día es la generación aumentada de recuperación (RAG): indexar documentos de políticas, manuales y tickets de soporte en las bases de conocimiento de Amazon Bedrock y extraer pasajes coincidentes en el contexto del modelo en el momento de la consulta. RAG funciona bien cuando la respuesta se encuentra en el texto que la búsqueda puede encontrar. Funciona menos bien para preguntas analíticas donde la respuesta depende de unir registros activos entre sistemas, aplicar una regla de negocio de manera consistente y respetar las políticas de acceso a nivel de fila o columna.

Lo que se encuentra entre el lenguaje y los hechos, y que normalmente falta en esas preguntas analíticas, es el contexto empresarial y las métricas empresariales. Tomemos un ejemplo típico del comercio minorista: una definición compartida de qué es un cliente, cómo se vincula un pedido con uno, qué se considera una cuenta de gran gasto o de alto riesgo, qué sistema posee qué hecho y cómo se calculan las cifras que informa la empresa. La misma brecha aparece en otros dominios (reclamos y pólizas en seguros, pacientes y encuentros en atención médica, repuestos y envíos en la cadena de suministro) con diferentes nombres. Una capa semántica captura ese contexto una vez y permite que cada agente y herramienta lo reutilice. Con él, un agente de IA puede redactar respuestas de muchas fuentes y respaldar las cifras que arroja. Una capa semántica no reemplaza a RAG. Lo complementa. La mayoría de los sistemas de producción necesitan ambos, accesibles a través del mismo agente.

Una capa semántica es una vista basada en ontologías de los datos de su empresa. La ontología captura los conceptos, relaciones, atributos y reglas que son importantes para su negocio. Las asignaciones declaran cómo se asignan esos conceptos a partir de filas en cada fuente en vivo. El agente consulta la capa. La capa traduce cada consulta a SQL en los sistemas subyacentes en tiempo de ejecución. Los datos permanecen donde están. El significado se captura una vez y se reutiliza.

Cuando esa capa semántica se implementa como lo hace Stardog (una ontología, identificadores estables para cada entidad y reglas que derivan nuevos hechos y restricciones que validan los datos frente a la ontología), el resultado es un gráfico de conocimiento. Los datos están conectados como un gráfico de entidades comerciales en lugar de filas en tablas, cada entidad tiene un identificador único estable de estilo URL llamado IRI, y las consultas atraviesan esas conexiones en un lenguaje de consulta basado en estándares definido por el W3C llamado SPARQL. Dos términos más aparecen repetidamente en el resto de la publicación:

Un gráfico con nombre es un subconjunto etiquetado del gráfico, identificado por un IRI propio. Stardog utiliza gráficos con nombre como unidad de control de acceso. La misma consulta produce resultados diferentes para diferentes roles dependiendo de qué gráficos con nombre puede leer cada rol. Un gráfico virtual es un gráfico con nombre cuyo contenido no se almacena en Stardog en absoluto. Viven en un sistema externo (Aurora, Amazon Redshift, Athena) y Stardog recupera las filas según demanda utilizando las asignaciones. La federación en esta publicación se implementa como un conjunto de gráficos virtuales, uno por fuente.

El glosario de Stardog define cada uno de estos términos y la serie Stardog Getting Started los pone en contexto.

Al final de esta publicación sabrás:

Cómo encaja una capa semántica junto con RAG y cuándo elegir cada una. Cómo federar Stardog en Amazon Aurora y Amazon Redshift, con notas sobre cómo extenderlo a Amazon Athena y otras fuentes de datos de AWS. Por qué recomendamos AgentCore Runtime, Gateway e Identity para ejecutar el agente en producción. Dos rutas de integración desde el agente a Stardog: una herramienta SPARQL directa y el servidor Stardog Cloud Model Context Protocol (MCP) como destino de la herramienta Gateway. Compensaciones sobre gobernanza, implementación y lo que está generalmente disponible (GA) frente a la versión beta actual.

Tres capas que necesita un agente

Un agente de IA que brinde respuestas confiables y conscientes del contexto empresarial depende de tres cosas que funcionen juntas. Cada uno resuelve un problema que los demás no pueden.

1. Capa modelo. Un modelo básico que puede planificar y escribir. Amazon Bedrock proporciona una única API para varias familias de modelos. Usamos Anthropic Claude Sonnet 4.6. El modelo conoce el idioma, no conoce tu negocio.

2. Capa de significado. Una capa semántica que brinda al modelo acceso gobernado y confiable a los datos detrás de sus preguntas comerciales. La ontología declara los conceptos y las reglas que derivan nuevos hechos de ellos, y la federación extrae filas activas de cada fuente en el momento de la consulta. La capa hace el trabajo: descubre qué datos son relevantes, reescribe la consulta SPARQL en SQL para cada fuente y une las filas de los identificadores compartidos. El modelo tiene un trabajo más limitado. Lee la pregunta del usuario, llama a la capa cuando necesita datos y escribe la respuesta en inglés sencillo. El razonamiento real sobre los datos, como la aplicación de la regla Big_Spender en las fuentes federadas, permanece dentro de Stardog en lugar de dentro del mensaje. Para ello utilizamos el gráfico de conocimiento federado de Stardog sobre Aurora y Amazon Redshift.

3. Capa de tiempo de ejecución del agente. La computación que aloja al agente, finaliza las solicitudes entrantes, administra las credenciales de la herramienta y proporciona la superficie operativa para la seguridad y la gobernanza. En AWS tiene un espectro de opciones: tiempos de ejecución administrados como Amazon Bedrock AgentCore en un extremo y opciones autoadministradas como Amazon ECS, Amazon EKS o AWS Lambda en el otro. La elección correcta depende de la cantidad de operaciones del agente que desee poseer. Usamos Amazon Bedrock AgentCore en esta publicación porque es la opción más prescriptiva para los agentes de producción en AWS.

De los tres, la capa de significado es la brecha de la que trata esta publicación, y el resto del tutorial la construye. La capa de tiempo de ejecución del agente es la que la mayoría de los equipos subestiman: cómo se llama al agente, cómo se autentica, dónde reside su credencial en la capa semántica y cómo se escala. AgentCore empaqueta respuestas a esas preguntas en un servicio administrado, razón por la cual lo usamos aquí.

Caso de uso de ejemplo: un agente de atención al cliente 360 ​​en Aurora y Amazon Redshift

Elegimos el cliente 360 ​​(C360) para el resto de este tutorial porque muestra cada brecha con la que se topa un agente de IA en el momento en que intenta realizar un trabajo analítico real, y nos permite mostrar cómo la capa semántica cierra cada una de ellas en unos pocos cientos de líneas de asignaciones y reglas. En una configuración minorista típica, el perfil del cliente, la dirección, la tarjeta de crédito y la información de recompensas se encuentran en una base de datos operativa. Los pedidos, productos, categorías y proveedores viven en un almacén de datos para análisis. Cada lado está bien sintonizado con lo que hace. Ninguna de las partes, por sí sola, puede responder una pregunta sobre el cliente en su conjunto. Un agente que intenta responder “¿quiénes son nuestros clientes más valiosos y qué compran?” tiene que conciliar dos bases de datos, dos esquemas, dos definiciones de “cliente” y una idea derivada (“más valiosa”) que vive en la columna de nadie. C360 concreta esas brechas.

El agente C360 corre para el equipo de análisis. Acepta una pregunta en inglés sencillo de un líder de ventas, un especialista en marketing o un analista de fraude. Escribe las consultas, las analiza en los datos de la empresa y responde con una breve respuesta narrativa más los números de respaldo. El usuario no ve SQL ni SPARQL y el agente no ve los datos que no tiene permiso para ver.

Un usuario pregunta al agente de C360, en un lenguaje sencillo: "¿Quiénes son nuestros mayores gastadores en Wisconsin?" Perfil y dirección del cliente en vivo en Aurora. Los totales de los pedidos se encuentran en Amazon Redshift. El agente tiene que unirlos con un identificador de cliente estable, y esa unión es una de las tres cosas que agrega una capa semántica:

1. Une sistemas a través de significados compartidos. La capa semántica asigna registros de clientes de Aurora y Amazon Redshift a una identidad de cliente común mediante claves comerciales compartidas. Esto permite que la unión se exprese a través del modelo semántico en lugar de un canal de integración física. Sin él, esa unión a menudo requiere una canalización mantenida que materialice una tercera copia de los datos y debe mantenerse sincronizada cada vez que cambia cualquiera de las fuentes.

2. Hechos derivados como reglas, no consultas. Una definición como "gran gastador" puede vivir en la ontología como regla en lugar de ser reexpresada en cada consulta, y cada consulta que la menciona obtiene la misma respuesta. Sin él, esa definición se duplica en paneles, cuadernos e informes. Cuando el umbral cambia, las copias se separan y la misma pregunta comienza a arrojar respuestas diferentes.

3. Control de acceso a nivel de gráfico. La seguridad del gráfico con nombre controla el acceso a nivel del gráfico, por lo que diferentes roles ven diferentes subconjuntos del gráfico de conocimiento empresarial. Para una protección más detallada, puede designar propiedades sensibles como :ssn y :cardNumber como propiedades protegidas. Los usuarios con permiso ven los valores reales, mientras que otros ven valores enmascarados de forma predeterminada. Con este enfoque, diferentes roles pueden ejecutar la misma consulta mientras el gráfico de conocimiento aplica políticas de seguridad consistentes en cada aplicación que accede a él.

Tomamos el kit de conocimientos C360 de Stardog, que originalmente carga archivos CSV locales, y lo adaptamos para federarlo en Aurora PostgreSQL (lado del cliente) y Amazon Redshift (lado de la compra). El kit incluye una ontología, datos de muestra y consultas listas para usar. Puede utilizarlo como punto de partida para su propio trabajo.

El modelo de datos que el agente no ve.

Debajo del agente, los datos de C360 se dividen en dos bases de datos de AWS. Aurora ocupa las mesas operativas de cara al cliente. Amazon Redshift contiene la tabla de datos analíticos y las dimensiones del producto.

Aurora PostgreSQL (operacional)

Columnas clave de la tabla: cid del cliente, nombre, apellido, correo electrónico, número de serie, teléfono, identificación de la dirección de ubicación, ciudad, estado, código postal, nombre de la calle, identificación de la tarjeta de crédito, cid, número de tarjeta, tipo de tarjeta, identificación de la cuenta de recompensas, cid, identificación de la cuenta, fecha de creación.

Amazon Redshift (análisis)

Columnas clave de la tabla ID de compra, CID, PID, fecha, cantidad, precio, ID del producto de la tarjeta, nombre, marca, precio, ID de la categoría del departamento, nombre_del_departamento, ID del proveedor principal, nombre_del_proveedor, industria

El identificador compartido entre las dos bases de datos es el número entero cid. Aparece como clave principal en la tabla de clientes en Aurora y como columna de clave no externa en la tabla de compras en Amazon Redshift. No hay ninguna restricción SQL que los vincule. No puede haberlo: viven en motores diferentes. Las respuestas que unen a los clientes con sus pedidos deben conciliar ese número entero en el momento de la consulta, cada vez, sin ETL.

Esto es lo que absorbe la capa semántica. La ontología declara un concepto, :Cliente, y una identidad estable para él: un IRI de la forma urn:stardog:demos:c360:customer:{cid}. Tanto el mapeo de clientes de Aurora como el mapeo de compras de Amazon Redshift generan el mismo IRI a partir de sus respectivos valores cid. El agente ve una entidad de cliente con un perfil, direcciones, tarjetas, cuentas de recompensas y pedidos. Los almacenes ven sus propias filas, sin cambios. Las asignaciones generan el mismo IRI de cliente del cid en ambas bases de datos. Stardog utiliza esa identidad compartida para unir los resultados federados sin necesidad de que las bases de datos subyacentes se conozcan entre sí.

Arquitectura de referencia

Figura 1. Punto clave: los datos permanecen en Aurora y Amazon Redshift. Sólo las consultas fluyen a través de la capa semántica.

Esta es la arquitectura de producción recomendada. La prueba de concepto (POC) para esta publicación utilizó la Ruta A con el agente ejecutándose como un script independiente.

El diagrama muestra dos flujos.

Entrante. Un cliente (una aplicación, otro agente o Stardog Studio) llama al agente a través de AgentCore Gateway. Gateway valida el token web JSON (JWT) entrante y enruta la llamada a AgentCore Runtime, que aloja el agente de Strands. El agente invoca Claude Sonnet 4.6 en Amazon Bedrock para planificar y redactar respuestas.

Saliente a la capa semántica. Se muestran dos caminos.

Ruta A (hoy, discontinua naranja): el agente de Strands llama a una herramienta SPARQL query_kg que se comunica directamente con Stardog. Úselo cuando aún no tenga acceso a la API de Voicebox (descrito más adelante en esta publicación). Ruta B (Stardog Cloud MCP, cuando el acceso API está disponible, azul): AgentCore Gateway tiene el servidor Stardog Cloud MCP registrado como destino MCP. Gateway extrae el token Stardog de AgentCore Identity y reenvía la llamada. El agente no toca la credencial.

El propio Stardog se federa con los almacenes en el momento de la consulta a través de Java Database Connectivity (JDBC). SPARQL se reescribe en SQL por fuente. Los resultados se unen dentro de Stardog en IRI compartidos. No hay trabajo ETL ni una tercera copia de los datos.

Construir la capa semántica

Tres piezas hacen funcionar la federación. La ontología declara los conceptos (:Cliente, :Pedido, :Producto) y las relaciones entre ellos. Las asignaciones declaran cómo las filas de cada almacén de datos se convierten en instancias de esos conceptos. Las reglas de razonamiento derivan nuevos hechos de los datos que ya están dentro del alcance. Stardog Designer es la superficie de creación de los tres.

la ontología

Figura 2. El modelo C360 en Stardog Designer. Conceptos como Cliente, Pedido, Producto y Dirección aparecen como nodos coloreados conectados por relaciones etiquetadas (comprado, titular de la tarjeta, tiene dirección, en categoría). Los nodos sombreados más claros alrededor de los bordes (Big Spender, Large Order, 2022 Orderer, the Sports Category shopper) son clases derivadas inferidas por reglas de razonamiento en el modelo en lugar de columnas en cualquier fuente.

La ontología C360 está escrita en Stardog Designer, una herramienta de mapeo y modelado visual sin código. El modelador crea conceptos (:Cliente, :Pedido, :Producto), los conecta con relaciones (:purchasedBy vincula un :Pedido a :Cliente) y declara campos como :ssn y :cardNumber como propiedades sensibles. Ningún OWL o RDF está escrito a mano. El modelo C360 completo define aproximadamente diez clases y treinta propiedades. Designer también puede generar un modelo inicial a partir de metadatos de origen existentes, como esquemas de tablas, definiciones FHIR, descripciones de casos de uso y preguntas de competencia, lo cual es un camino más rápido que escribir el modelo desde cero.

La portabilidad es una ventaja clave de Designer, que utiliza Turtle, la serialización estándar W3C para que RDF persista en los modelos. Este enfoque basado en estándares ayuda a evitar la dependencia de proveedores y respalda la interoperabilidad con la red RDF más amplia:

Importe ontologías directamente desde herramientas como Protégé. Exportar datos a servicios como Amazon Neptune. Realice flujos de trabajo de ida y vuelta entre otras utilidades compatibles con RDF.

La ontología crece con el tiempo a medida que las preguntas que necesita responder se vuelven más específicas. La mayoría de los equipos comienzan con un pequeño caso de uso y preguntas de competencia que se utilizan para construir un modelo y luego lo amplían de forma incremental.

Debajo del capó: lo que genera Designer. La parte del modelo en la que se basa la federación es pequeña (las declaraciones de prefijo se omiten por brevedad).

:Cliente un búho:Clase . :comprado por un búho:ObjectProperty ; entonces:dominioIncluye:Orden; entonces:rangoIncluye:Cliente. :ssn a búho:DatatypeProperty, m:SensitiveProperty; entonces:dominioIncluye:Cliente.

Los puntos que vale la pena destacar: cada concepto obtiene un identificador estable, la relación de :Order a :Customer se declara una vez y se reutiliza en todas partes, y :ssn se clasifica como m:SensitiveProperty (del vocabulario de metadatos de Stardog) en el modelo mismo en lugar de en un archivo de política posterior. La ontología completa se encuentra en el kit de conocimientos de C360.

Las asignaciones (bloque de construcción de la federación)

Figura 3. El editor de mapas en Stardog Designer. La fuente del Cliente a la derecha está vinculada al concepto de Cliente a la izquierda. La columna id se establece como Identificador primario, que es lo que produce el IRI estable que se utiliza en todos los demás lugares. Debajo del identificador, relaciones como Tiene estado del programa de fidelización e Interactúa con vinculan al cliente con otros conceptos en el mismo modelo.

En Designer, las asignaciones se crean visualmente. El modelador asigna la tabla de clientes de Aurora al concepto :Customer y le dice al Diseñador que la identificación es la clave de la entidad. Designer hace lo mismo en el lado de Amazon Redshift: asigna la tabla de compras, marca cid como clave de cliente. (En términos de bases de datos, cid en :compra hace referencia a id en :Cliente.) El mismo flujo de asignar y marcar la clave funciona para ambos almacenes. Las asignaciones permanecen independientes, pero se alinean porque el IRI producido a partir de los valores en cid en :Purchase es el mismo IRI que se produce para los valores de id en :customer.

La propiedad arquitectónica a entender es la plantilla IRI. Es lo que permite al agente responder preguntas entre almacenes sin ETL. Ambas asignaciones producen el mismo identificador para el mismo cliente. Un cliente con cid=42 se convierte en urn:stardog:demos:c360:customer:42 ya sea que la fila provenga de la tabla de clientes de Aurora o de la tabla de compras de Amazon Redshift. El agente ve una entidad. Los almacenes se mantienen sin cambios. Ningún SQL JOIN cruza nunca los dos almacenes. La “unión” es el acuerdo IRI.

Debajo del capó: lo que genera Designer. Cuando Designer guarda una asignación, emite Stardog Mapping Syntax (SMS), un superconjunto del estándar W3C R2RML que utiliza una sintaxis similar a SPARQL. Stardog lee R2RML directamente y puede exportar SMS nuevamente a R2RML, por lo que las asignaciones se trasladan en cualquier dirección. Los dos extractos que contienen el componente básico de la federación se ven así:

# Mapeo de clientes de Aurora (extracto) BIND(TEMPLATE("urn:stardog:demos:c360:customer:{cid}") AS ?iri) # Mapeo de órdenes de desplazamiento al rojo (extracto) BIND(TEMPLATE("urn:stardog:demos:c360:customer:{cid}") AS ?cust_iri)

Los archivos de mapeo completos para cada mesa C360 están en el kit.

El siguiente diagrama rastrea una pregunta desde el agente hasta las fuentes de datos y viceversa. La banda media es la capa semántica. Nada en él almacena filas. Las filas viven en Aurora y Amazon Redshift. Stardog usa la ontología y las asignaciones para decidir qué SQL ejecutar y dónde, luego une los conjuntos de resultados en el IRI compartido antes de devolverlos.

Figura 4. El flujo de consultas desde el agente C360 a Aurora y Amazon Redshift y viceversa. SPARQL se reescribe en SQL por fuente. Los conjuntos de resultados se unen dentro de Stardog en el IRI del cliente compartido.

Razonamiento sobre el gráfico.

Stardog admite el razonamiento OWL y reglas definidas por el usuario escritas en Stardog Rule Syntax (SRS) o SWRL. El razonamiento es el proceso de inferir nuevos hechos a partir de datos existentes utilizando el esquema. El kit define clases derivadas como Big_Spender (un cliente que ha realizado al menos un pedido por encima de un umbral) y Large_Order. Con el razonamiento habilitado en el momento de la consulta, preguntar "¿cuántos grandes gastadores por estado?" funciona sin precalcular o materializar esos hechos. Las reglas se definen una vez en el modelo semántico y se evalúan sobre datos activos cuando se ejecuta la consulta.

Codificar las definiciones de negocio una vez, en lugar de volver a implementarlas en consultas, paneles y mensajes SQL, es una de las partes más difíciles de ir más allá de RAG.

Gobierna el acceso con seguridad de gráficos con nombre

Los datos del cliente 360 ​​están regulados. Dos requisitos aparecen temprano.

1. Algunos usuarios (RRHH, fraude) necesitan ver información de identificación personal (PII), como un número de Seguro Social (SSN) y un número de tarjeta completo. La mayoría de los usuarios (marketing, análisis) no deben hacerlo.

2. El control no debería requerir cambios en los almacenes subyacentes.

El mecanismo de Stardog para esto es la seguridad de gráficos con nombres. Un gráfico con nombre es un subconjunto etiquetado de datos. Las puertas de seguridad de gráficos con nombre leen cada gráfico con nombre por usuario. Cada gráfico virtual de la federación tiene su propio IRI de gráfico con nombre. Dividimos el mapeo de Aurora en dos gráficos virtuales.

aurora_c360_safe: perfil del cliente menos PII (todo excepto :ssn y :cardNumber). aurora_c360_pii: Solo la PII se triplica, vinculada al mismo IRI del cliente.

El mapeo de Amazon Redshift es un gráfico, redshift_c360. Luego creamos dos roles.

hr_user: lee los tres gráficos virtuales. marketing_user: lea solo aurora_c360_safe y redshift_c360.

Cuando marketing_user ejecuta una consulta SPARQL que solicita ?c :ssn ?ssn, el planificador de Stardog trata aurora_c360_pii como si no existiera para ese usuario. La inserción JDBC para la columna SSN no ocurre. Sin filtro a nivel de aplicación, sin cambios en el almacén, sin posibilidad de filtrar el valor a través de una herramienta de BI mal configurada. Misma consulta SPARQL, dos roles, dos conjuntos de resultados diferentes.

Para los filtros a nivel de fila (un analista del este de EE. UU. solo ve clientes de la costa este, por ejemplo), se escala el mismo mecanismo de gráfico con nombre: divide la fuente en más gráficos virtuales a lo largo de la dimensión de la fila y luego otorga lecturas por gráfico. Esta es una repetición del patrón PII, no una característica nueva.

Stardog también admite el etiquetado de propiedades individuales como sensibles en la ontología, y la etiqueta genera enmascaramiento a nivel de columna en el momento de la consulta. Vale la pena evaluar esto como una alternativa a la división de gráfico con nombre anterior. Se adapta mejor cuando los campos confidenciales están dispersos en muchas entidades y prefiere marcarlos en la ontología que particionar los datos. Consulte los documentos de seguridad detallados de Stardog para conocer los pasos de configuración.

Ejecute el agente y llame a Stardog desde allí.

Strands Agents es un pequeño marco para agentes de construcción. Un breve script de Python conecta Claude Sonnet 4.6 (en Amazon Bedrock) a una herramienta que ejecuta SPARQL contra Stardog. Se carga un resumen de la ontología en el indicador del sistema del agente. El modelo escribe SPARQL, la herramienta devuelve filas, el modelo resume los resultados.

Ese código es portátil. El mismo agente se puede ejecutar como un script de Python en una computadora portátil, en un contenedor en Amazon ECS o Amazon EKS, detrás de un balanceador de carga de aplicaciones o como una función de AWS Lambda. Para producción, recomendamos implementarlo en Amazon Bedrock AgentCore porque agrupa el andamiaje operativo en un servicio administrado.

AgentCore Runtime aloja el agente y maneja la simultaneidad y el estado de la sesión. AgentCore Gateway es la superficie entrante que valida el JWT de su proveedor de identidad (IdP) y enruta la llamada a Runtime. AgentCore Identity contiene el token Stardog como proveedor de credenciales, por lo que la credencial no reside en el código del agente.

Si elige un tiempo de ejecución diferente, los mismos componentes básicos seguirán necesitando un hogar: una capa de alojamiento, un autenticador de entrada y una bóveda de credenciales. Los patrones de integración que siguen no cambian. Lo que cambia es qué servicio de AWS contiene cada pieza.

La integración con Stardog es donde las implementaciones difieren. Vale la pena conocer dos caminos. La ruta A es la predeterminada, a menos que ya tenga acceso a la API de Voicebox.

Ruta A: herramienta SPARQL directa. Una pequeña herramienta de Python envuelve al cliente pystardog y se expone al agente a través del decorador de herramientas de Strands. El agente escribe SPARQL, la herramienta lo ejecuta y devuelve filas. Esto funciona en instancias de Stardog a las que puede acceder a través de HTTPS, incluido el nivel gratuito de Stardog Cloud. Usamos esta ruta en la prueba de concepto porque no requiere ninguna habilitación especial en la cuenta Stardog.

Ruta B: servidor Stardog Cloud MCP como destino de la herramienta Gateway. Stardog publica un servidor MCP oficial, stardog-union/stardog-cloud-mcp, que expone Voicebox (la capa de consulta en lenguaje natural de Stardog) como tres herramientas: voicebox_ask, voicebox_generate_query y voicebox_settings. Voicebox ejecuta su propio canal de lenguaje natural a SPARQL consciente de la ontología y devuelve la cadena de razonamiento y la procedencia con cada respuesta. AgentCore Gateway puede registrar este servidor MCP como objetivo de herramienta, lo que significa que el agente dentro de Runtime ve Voicebox como una herramienta sin código adhesivo y AgentCore Identity inyecta el token en el salto de Gateway.

El modo local del servidor MCP es estable. El modo remoto está en versión beta. La ruta B también requiere un token API de Voicebox, que está vinculado a cuentas específicas. Comuníquese con Stardog si su portal no muestra "Administrar claves API".

Elija la Ruta A cuando aún no tenga acceso a la API o cuando desee tener control total sobre la generación de SPARQL. Elija la ruta B cuando tenga acceso a la API y desee la cadena de razonamiento y la procedencia de Voicebox sin costo adicional.

Recomendamos habilitar el almacenamiento en caché de avisos de Amazon Bedrock para implementaciones de producción. El agente reutiliza el mismo mensaje grande del sistema, el resumen de ontología C360, en cada llamada. El almacenamiento en caché de mensajes de Amazon Bedrock mantiene activa la parte almacenada en caché de ese mensaje durante las llamadas, lo que reduce el costo del token de entrada en invocaciones repetidas. En las implementaciones de Stardog, el almacenamiento en caché rápido puede reducir el costo del token de entrada por consulta cuando se reutiliza el mismo contexto de ontología en todas las solicitudes. El almacenamiento en caché se configura por solicitud. Verifique los parámetros BedrockModel del marco de su agente para saber cómo exponer el punto de caché.

Consultas de muestra y verificación.

Para confirmar que la federación se comportó según lo diseñado, ejecutamos tres categorías de preguntas sobre la implementación en vivo.

Sólo Aurora. "Enumere diez clientes y su estado". Los datos de origen están en Aurora. Stardog emite una consulta SQL contra las tablas de direcciones y clientes de Aurora y devuelve las filas. El gráfico virtual de Amazon Redshift no se toca.

Solo Amazon Redshift. "Diez productos principales por unidades vendidas". Los datos de origen están en Amazon Redshift. Stardog emite una agregación agrupada única contra la tabla de compras y devuelve los totales. Aurora no se conmueve.

Federados. "Los diez clientes que más gastan, con su estado". Esto necesita que los clientes y direcciones de Aurora se unan a los pedidos de Amazon Redshift en el IRI de cliente compartido. El SPARQL real que ejecuta el agente:

PREFIJO: SELECCIONAR ?cliente ?fnombre ?lnombre ?estado (SUM(?precio * ?cantidad) COMO ?gasto) DONDE { GRÁFICO { ?cust a :Cliente ; :primerNombre ?fnombre ; :apellido ?lnombre ; :dirección ?a . ?a :estado ?estado . } GRÁFICO { ?o :compradoPor ?cust ; :preciodecompra?precio; :cantidad ?cantidad . } } GROUP BY ?cust ?fname ?lname ?state ORDER BY DESC(?spend) LIMIT 10

Stardog emite una consulta SQL a cada fuente (una contra las tablas de direcciones y clientes de Aurora, otra que agrega las compras de Amazon Redshift por cid), recibe ambos conjuntos de resultados y los une en la variable ?cust, es decir, el IRI asignado desde cid en cada lado. El mejor resultado de nuestros datos de semillas fue Carolyn Inworth, con un gasto total de 502 529 dólares en sus compras. La misma consulta con los mismos datos devuelve el mismo número en cada ejecución.

Luego analizamos el razonamiento: "¿cuántos grandes gastadores hay por estado?" con el razonamiento habilitado. Stardog aplicó la regla Big_Spender en todo el gráfico federado en el momento de la consulta y devolvió recuentos por estado sin precalcular ni materializar la clase derivada.

Para la gobernanza, ejecutamos la misma consulta SPARQL dos veces, una como hr_user y otra como marketing_user. La función de RR.HH. vio limitado el valor del SSN. La función de marketing volvió a tener la misma forma de fila con un enlace ?ssn vacío, sin cambios en el texto de la consulta y sin filtro del lado del almacén.

Ampliar la capa semántica a través de fuentes de datos de AWS y más allá

El mecanismo de gráficos virtuales de Stardog no es específico de Aurora o Amazon Redshift. Para agregar una nueva fuente o ampliar la ontología, el modelador trabaja en Stardog Designer, la misma superficie de creación utilizada para el modelo C360 inicial. Designer genera la asignación de SMS. Cuando el modelador marca la misma clave de entidad (por ejemplo, cid para el concepto de cliente), la plantilla IRI coincide y la nueva fuente pasa a formar parte de la capa semántica federada sin cambiar la ontología ni las consultas existentes. En AWS, esto incluye Amazon Athena (lago de datos en Amazon S3) y motores Amazon RDS que incluyen un controlador JDBC. Fuera de AWS, esto incluye Snowflake, Google BigQuery, MongoDB y SAP HANA. La lista completa se encuentra en la página de fuentes de datos compatibles de Stardog.

La propiedad arquitectónica que se debe preservar al agregar fuentes es la plantilla IRI. Siempre que las nuevas asignaciones generen IRI que coincidan con los existentes para la misma entidad lógica, la nueva fuente puede participar de forma natural en el gráfico federado existente. Stardog llama a esto “cooperación sin coordinación”: cada equipo es dueño de su fuente y sus mapeos, y el gráfico lo compone.

Stardog Cloud comparado con el autoadministrado en Amazon EKS

Stardog se ejecuta en dos formas en AWS y la opción es operativa, no funcional.

Nube Stardog (SaaS). Stardog opera el servicio compatible con SOC 2 con acuerdos de nivel de servicio (SLA) del 99,9 por ciento. Traes fuentes de datos y credenciales. Existen niveles Gratis, Essentials y Enterprise. Utilícelo cuando desee omitir operaciones, cuando se pueda acceder a sus fuentes de datos desde Stardog Cloud (a través de Internet público o a través de AWS PrivateLink for Enterprise) y cuando la cadencia de actualización administrada por Stardog funcione para usted. Usamos Stardog Cloud para el trabajo detrás de esta publicación.

Autogestionado en Amazon EKS. Imágenes de contenedores de barcos Stardog y cartas de Helm. Usted ejecuta el clúster, administra las actualizaciones y maneja las copias de seguridad. Utilícelo cuando necesite mantener el tráfico del plano de datos dentro de su nube privada virtual (VPC), cuando desee controlar la cadencia de versiones, cuando el cumplimiento requiera una postura de implementación específica o cuando solo se pueda acceder a las fuentes de datos desde dentro de su VPC.

La salida importa de cualquier manera. Stardog Cloud se conecta a Aurora y Amazon Redshift a través de JDBC, por lo que los grupos de seguridad en esas fuentes de datos deben permitir conexiones entrantes desde el rango de IP de salida de Stardog Cloud. Stardog publica el conjunto actual de IP de salida en su documentación. Incluya esos CIDR en cada grupo de seguridad de origen de datos y la federación funcionará. Consulte Lista de llamadas de gráficos virtuales permitidas desde Stardog Cloud para conocer los valores actuales y los pasos de configuración.

Conclusión

El análisis de agentes confiable necesita tres cosas que funcionen juntas: un modelo básico que pueda planificar y generar consultas, una capa semántica que proporcione una vista empresarial gobernada a través de datos empresariales en vivo y un tiempo de ejecución de producción que aloje al agente y administre la seguridad. Amazon Bedrock, Stardog y Amazon Bedrock AgentCore desempeñan cada uno uno de esos roles.

La idea arquitectónica clave es que el agente se comunica con la capa semántica, no directamente con las bases de datos subyacentes. A medida que las fuentes de datos y los esquemas evolucionan, la ontología y las asignaciones absorben esos cambios, lo que permite a los agentes continuar razonando sobre conceptos comerciales estables en lugar de tablas y columnas físicas.

Por donde empezar

La mayoría de los equipos que logran que esto funcione comienzan con un flujo de trabajo en lugar de una implementación amplia.

Una secuencia práctica:

1. Elija un flujo de trabajo cuya respuesta sea lenta hoy en día porque los datos abarcan dos o tres sistemas. Cuanto más estrecho, mejor.

2. Escriba de tres a cinco preguntas de competencia que el flujo de trabajo necesita respuesta. Estas son las consultas que la capa semántica debe admitir desde el primer día.

3. Arranque la ontología a partir de sus esquemas fuente en Designer, luego refinela con respecto a las preguntas de competencia hasta que cada una de ellas arroje una respuesta sensata.

4. Presentar la federación como gráficos virtuales sobre las fuentes en vivo. Sin ETL, sin tercera copia.

5. Conecte el agente a la capa a través de la Ruta A o la Ruta B, según su acceso a la API de Voicebox.

El kit de conocimientos Stardog C360 es un punto de partida útil. Es el mismo kit que adapta este post.

Lectura adicional

Sobre los autores