Ontologías empresariales portátiles para agentes de IA

El término «ontología» está de moda. ¿Por qué? Los agentes, y los LLM que los impulsan, necesitan contexto empresarial pertinente.

Antes de decidirte por una ontología, pregúntale al proveedor: «Cuando la ontología interpreta mal nuestro negocio, ¿cómo pueden corregirla nuestros equipos y qué sigue dependiendo de ustedes?». La respuesta te dirá mucho sobre el modelo de negocio que estás adoptando. También apunta a lo que está en juego: tu capacidad para mejorar ese modelo a medida que cambia el negocio y para mantener útil esa inversión si cambias de plataforma.

Conviene distinguir entre una ontología y un grafo de conocimiento, aunque a menudo se superpongan.

Ontología: qué tipos de cosas existen, qué significan las relaciones y qué reglas se aplican. Equipos, componentes, equipos de trabajo, funciones, procesos. Por ejemplo, una ontología puede definir un tipo «Equipo» y una relación «Contiene» con un «Componente». Luego, un grafo de conocimiento puede afirmar: «La bomba P-101 contiene el sello S-7»: dos entidades específicas y la relación entre ellas.

Imagina que le dices a un agente: «Calcula el crecimiento de las ventas en tiendas comparables, pero muéstrame una comparación lado a lado: primero, con todas las tiendas; luego, otra en la que excluyas las tiendas que llevan abiertas menos de 2 años. Después, desglosa ambas partes en tiendas nacionales, internacionales y el total combinado».

Esa solicitud depende de detalles que un agente no puede adivinar:

• qué tiendas existen y cuándo abrieron
• dónde están
• la definición interna de «ventas en tiendas comparables»

Una política podría excluir las tiendas hasta que lleven un año abiertas; el grupo solicitado de dos años añade un filtro más. Aun así, ¿se comparan los meses naturales en cuanto una tienda cumple el requisito o solo se la incluye después de un ejercicio fiscal anterior completo?

La ontología debe vincular esas tiendas con la política que rige el cálculo. Encontrar datos relacionados ayuda; aplicar la regla correcta es lo que hace útil la respuesta.

Antes de responder una pregunta, un agente puede aprovechar las relaciones del grafo para recuperar el contexto pertinente. Y no es de extrañar que resulten útiles, dado que los dominios de conocimiento pueden volverse muy complejos.

Figura 1: Grafo: modelos públicos de SysML combinados: TMT Thirty Meter Telescope (Open-MBEE/JPL, Apache-2.0), CubeSat System Reference Model (© 2022 INCOSE SSWG & OMG SDTF, CC BY 4.0), Architecting Spacecraft with SysML (Friedenthal & Oster, BSD-2-Clause), además de contenido ficticio de la constelación MDC y especificaciones públicas (IS-GPS-200, IS-GPS-705, GSFC-STD-7000B). Representado en Kamiwaza Kaizen.

Pero la extracción también puede codificar errores. Los equipos pueden usar nombres distintos para una misma entidad, lo que genera duplicados. Las fuentes pueden discrepar o quedar desactualizadas. Incluso un LLM puede interpretar mal una fuente impecable. Hacer que esos errores parezcan autorizados no los vuelve menos peligrosos.

Esos riesgos aumentan cuando un modelo del negocio se convierte en un sistema que actúa sobre él. Entonces, una relación incorrecta puede desencadenar una acción equivocada, no solo una respuesta errónea.

Riesgos de los productos de ontología

En primer lugar, desconfía de los modelos inflexibles. Con el pretexto de ofrecer una solución «lista para usar», un proveedor puede dar prioridad a sus propias entidades y limitar lo que las tuyas pueden hacer. La personalización no basta si los tipos personalizados pierden capacidades de búsqueda, validación o ejecución de acciones.

En segundo lugar, busca una vía que lleve del descubrimiento a la gobernanza. Una herramienta debería permitirte crear un grafo inicial a partir de lo que detecta un LLM y, después, validarlo con restricciones explícitas. Deberías poder escalar las excepciones a personas y conservar el conocimiento exploratorio sin tratarlo como datos empresariales aprobados.

El mayor riesgo es vincular los procesos empresariales a una plataforma de la que no puedas salir. Tu ontología representa tu negocio: sus conocimientos, procesos y relaciones. Esa inversión en curación y lógica de negocio debería seguir siendo útil aunque cambies de herramientas. ¿Por qué habría de poder un proveedor mantenerla bajo llave?

Cuándo ayudan las incrustaciones de grafos

A medida que los grafos de conocimiento crecen mucho, puede convenir elegir una herramienta o un proveedor que admita incrustaciones de grafos. Estas son muy parecidas a las incrustaciones semánticas que impulsan muchas aplicaciones de RAG. Conviene tener en cuenta dos ventajas.

En primer lugar, unos pocos saltos por un grafo densamente conectado pueden arrojar demasiadas entidades para procesarlas. Al aprender representaciones numéricas de entidades y relaciones, las incrustaciones ofrecen otra forma de encontrar partes pertinentes del grafo. Para la tarea adecuada, esto puede ser más eficiente que recorrer el grafo.

En segundo lugar, los modelos de incrustación pueden clasificar relaciones candidatas que falten. El mismo aprendizaje puede revelar patrones en los atributos y las relaciones habituales de un tipo de entidad, lo que ayuda a crear un grafo más completo.

A favor de la mejora progresiva

Si quieres tomar las riendas de tu propio destino, evitar la dependencia de un proveedor y modelar tu negocio real en lugar de una caricatura dictada por un proveedor, ¿por dónde empiezas si no tienes todo un ejército de ingenieros de despliegue avanzado? Aquí es donde, en mi opinión, la IA moderna destaca, siempre que las herramientas permitan avanzar del descubrimiento a la verificación.

En primer lugar, utiliza herramientas automatizadas de detección y extracción. A partir de documentos empresariales, políticas, correos electrónicos o mensajes de Slack, puedes construir una visión inicial de un ámbito. Lo fundamental es que no puedes confiar en que sea precisa hasta que se verifique.

La verificación es la segunda parte. Tus herramientas deben ofrecerte una transición fluida desde los posibles datos extraídos hasta afirmaciones respaldadas por fuentes y conocimientos validados por una persona responsable o un sistema autorizado. Conserva la fuente de cada afirmación.

Mantener la información actualizada es una tarea continua. El proceso para gestionar un ticket de soporte, o la respuesta a «¿cuántas tiendas hay en Nueva Jersey?», puede no ser hoy el mismo que hace tres años. Pero actualizar los conocimientos actuales no debe borrar la realidad de ayer. La fecha en que se registró un hecho y el período en que se aplicaba pueden ser distintos; una ontología útil debe permitir tanto responder sobre el presente como ofrecer una visión histórica precisa. Alguien aún debe mantener esos conocimientos actualizados.

El alcance puede ser enorme. Empieza con un corpus más pequeño, modela un ámbito útil y avanza hacia una visión integral, creando valor durante el proceso.

La atención al cliente es un ámbito útil: llamadas entrantes, correos electrónicos, un sistema de gestión de tickets, resoluciones automatizadas, un equipo de soporte que pueda responder a los clientes y una vía para escalar los errores reales al equipo de ingeniería. Conecta los conocimientos con la acción y permite observar los mismos riesgos y beneficios en un ámbito manejable.

El Common Service Data Model de ServiceNow ilustra esta limitación. Su documento técnico CSDM 5 advierte: «Si estos datos no están en las tablas indicadas, es posible que no obtengas todo el valor de ServiceNow AI Platform». La advertencia impone por sí misma una limitación de diseño y operativa: adoptar el modelo del proveedor o aceptar un riesgo. ¿Y si eso significa intentar encajar tu pieza redonda en su hueco cuadrado?

Supongamos ahora que una plataforma de ontologías también ofrece funciones de ingesta, transformación, acciones y reglas de negocio. Es posible que puedas exportar entidades, atributos y relaciones. Pero ¿también puedes trasladar las transformaciones y las secuencias de acciones que ejecutan cambios en tus bases de datos, llaman a webhooks y generan otros efectos secundarios? Las integraciones estrechamente acopladas pueden dejar a la propia empresa atrapada en la plataforma.

Por qué la flexibilidad importa ahora

El software está devorando el mundo, y la IA está devorando el software. A medida que los equipos utilizan la IA tanto para crear software como para impulsarlo, una mayor parte de la lógica de negocio puede quedar ligada a estas plataformas. Cada automatización útil también puede convertirse en otra dependencia para una migración. Es peligroso dejar que un proveedor se interponga entre tú y la agilidad.

Conclusiones

¡Es una época increíble para vivir! No es de extrañar que la gente esté explorando las ontologías para proporcionar contexto a los agentes. Extender ese contexto a los procesos y las integraciones puede generar un valor real. Volvamos a la pregunta inicial. Las correcciones de tu equipo deberían hacer que el modelo refleje mejor tu empresa. Ese conocimiento acumulado es demasiado valioso como para quedar atrapado al cambiar de plataforma. Además, este es un momento terrible para quedar encasillado sin salida.