En un post anterior, y con base en este libro, hablamos de una arquitectura dual en que un agente usaba dos grafos:
- El grafo de conocimiento: que representa entidades y relaciones del dominio de trabajo
- El grafo de workflow: que representa tareas y panes construidos mediante relaciones entre ellas
A estos dos grafos fundamentales (de ahí el nombre de arquitectura dual), los autores añadían, quizá de forma más tímida y menos clara, o tal vez menos nuclear, un tercer grafo, el grafo de log, orientado a la monitorización y diagnóstico de agentes en operación.
En este post, profundizamos un poco en el primero de ellos: el grafo de conocimiento.
El papel del grafo de conocimiento para un agente
El papel del grafo de conocimiento es, quizá, el más claro de los tres. No deja de ser una forma de representación de conocimiento, un conocimiento del dominio estructurado en base a entidades y relaciones (expresados como nodos y arcos del grafo).
Se trata de una forma de representación del conocimiento que, por un lado, extiende, estructura y personaliza el conocimiento del agente más allá del contenido que de manera implícita contiene su modelo de lenguaje (o, mejor, su modelo razonador, LRM).
Y, por otro, sustituye o complementa ventajosamente el conocimiento que aportan las bases de conocimiento vectoriales implementadas en el mecanismos RAG ('Retrieval Augmented Generation').
Si en las bases de conocimiento RAG el conocimiento se almacena como 'chunks' de texto sin estructura, representados por un vector 'embedding' a efectos de búsqueda semántica, en un grafo de conocimiento, ese conocimiento se representa de manera mucho más estructurada con representación explícita de las entidades y objetos del dominio de trabajo y de las relaciones entre ellas.
Modelos de datos de grafos
Una base de conocimiento basada en grafos de conocimiento, no deja de ser una base de datos, aunque diseñada y construida con un paradigma diferente al relacional.
A la hora de construir existen alguna alternativas como modelo de datos.
En la obre citada nos hablan, por ejemplo, de LGP ('Labeled Property Graphs') que almacenan los nodos con una serie de propiedades y esas propiedades se conectan mediante arcos etiquetados.
Otros es RDF ('Resource Description Framework') que representa todo mediante tripletas formadas por sujeto, predicado y objeto y apoyada en una semántica de lógica formal que posibilita el razonamiento nativo.
La última alternativa que se nos presenta son los hipergrafos ('Hypergraphs') que permiten conectar varias entidades en una única relación, superando el enfoque binario.
Tres sub-grafos
Aunque hablamos del grafo de conocimiento como una unidad, los autores nos proponen la arquitectura en tres grafos, donde el conocimiento se organiza en tres estructuras de conocimiento diferenciadas, a saber:
- Grafo del dominio ('domain graph'): Que se corresponde, en el fondo, a lo que hemos explicado hasta ahora como grafo de conocimiento. Contiene entidades que representan objetos o conceptos del dominio y arcos que representan relaciones entre ellas. Lo relevante, además de su estructura, es que se trata de un conocimiento editado, validado y confiable. Con frecuencia se construye a partir de datos estructurados.
- Grafo léxico ('lexical graph'): Que contiene el texto no estructurado del que podemos haber partido, pero añadiéndole una pequeña estructura que relaciona los 'chunks' de texto con el documento del que provienen. Es prácticamente lo que hacemos en las bases de conocimiento vectoriales usadas en RAG.
- Grafo de la materia ('subject graph') Funciona como una especie de grafo intermedio entre el léxico y el de dominio. Contiene entidades extraídas por un LLM del grafo léxico pero que se mantienen separadas del grafo hasta que el proceso de resolución de entidades proporcione unos enlaces confiables como veremos luego.
Estos tres grafos los puede usar un agente de forma coordinada. Típicamente empezaría consultado el grafo de dominio pero saltar al grafo de materia (a través de un arco del tipo 'se corresponde a') para obtener información de alguna entidad extraída por el LLM y, de ahí, saltar a su vez a conocer el 'chunk' de texto en el grafo léxico donde encontramos la información en bruto.
La vuelta a las ontologías y la representación del conocimiento
Especialmente en el caso del grafo del dominio, hablamos de entidades y relaciones que se corresponden con objetos y conceptos del mundo real.
En el ámbito de una organización como es una empresa, interesa que esas entidades y esas relaciones se basen en el vocabulario propio de la organización y su sector. Por ello se suele recurrir a la definición de ontologías que recojan de forma ordenada ese vocabulario organizativo. Eso permite un mejor entendimiento y, además, la interoperabilidad de agentes e integración entre sistemas.
Y la definición de ontologías de un rol, el ingeniero de conocimiento ('knowledge engineer') que debe trabajar estrechamente con los ingenieros de IA.
Y esta idea de la definición de ontologías y la mera existencia de un ingeniero de conocimiento no deja de retrotraernos de alguna forma a la era de la inteligencia artificial simbólica y la construcción de bases de conocimiento para sistemas expertos, tal y como un poco comente en el post 'El retorno de la representación del conocimiento'.
Resolución de entidades
Teniendo clara esa ontología, para que en el proceso de creación del grafo podamos asociar registros de información a una entidad de esa ontología, se necesita el proceso de resolución de entidades ('entity resolution').
Este proceso no es sencillo pero es clave para la creación de un buen grafo de conocimiento a partir de información externa.
Construcción del grafo
En cualquier caso, y partiendo de todo lo anterior, para que un agente que utilice grafos de conocimiento, lógicamente, lo primero es construir ese grafo (o esos grafos), recopilando conocimiento del dominio y estructurándolo formalmente.
Los autores nos proponen una suerte de 'pipeline' con tres fases: extracción, resolución de entidades y validación.
En la fase de extracción, en general, debemos acudir a fuentes diversas con la información 'en bruto', unas fuentes que pueden ir desde puro texto a bases de datos relacionales o bases de datos NoSQL, por ejemplo.
No voy a entrar en detalles, pero existen planteamientos sobre la mejor forma de extraer la información de bases de datos o del uso de LLMs para extraer la información del texto. Igualmente existen planteamientos y 'frameworks' para construir un grafo a partir de este tipo de información.
Luego viene la fase de resolución de entidades que mencionábamos en la sección anterior. En esta fase se trata de conectar entidades extraídas típicamente a partir de texto libre con entidades confiables del grafo de dominio Cuando se consigue esa resolución, la información obtenida por el LLM se conecta con entidades del grafo de dominio mediante los denominados arcos 'CORRESPONDS_TO'.
Finalmente, se debería realizar la validación.
Indexado
Aunque no vamos a entrar en detalles, comentar que en las bases de conocimiento de grafos, se suelen construir, de forma similar a otro tipo de bases de datos como las relacionales, los denominados índices que vienen a ser unas estructuras paralelas que facilitan la búsqueda y el acceso rápido a la información del grafo.
Consulta
Aunque la fuente que estoy usando no detalla mucho cómo se realiza, a nivel de arquitectura técnica una consulta a la base de conocimiento, sí comentar que en esa labor nos solemos apoyar en lenguajes de consulta especializados como son Cypher de Neo4j, GSQL ('Graph SQL') de TigerGraph o SPARQL.
Conclusiones
Uno de los grafos importantes para los agentes, el el grafo de conocimiento que recoge, de forma estructurada, la información del dominio de trabajo. Aunque hablamos de un grafo de conocimiento hemos visto una propuesta que, en realidad, usa tres estructuras: el grafo de dominio, el grafo léxico y el grafo de materia.
Además, hemos visto que estos grafos se deben apoyar en una ontología que refleje el vocabulario de la empresa o sector
No hay comentarios:
Publicar un comentario