Ontología como verificador de un agente de IA: en UniProt, sus alertas de error son apenas más precisas que el azar

Investigadores del Sano Centre for Computational Medicine comprobaron si se puede confiar en una ontología como juez de un agente de IA. Una ontología es una descripción legible por máquina de los tipos de entidades que existen en un grafo de conocimiento y de cómo pueden relacionarse. Un agente basado en un modelo de lenguaje de gran tamaño (LLM) responde a una pregunta con una consulta en lenguaje SPARQL al grafo, por ejemplo a la base de datos UniProt.

La ontología contrasta la consulta y el resultado, y o bien deja pasar la respuesta o bien la marca con una alerta. Con respuestas reales de agentes, las alertas de la ontología experta de UniProt resultaron solo algo más precisas que las aleatorias. Esa comparación con alertas aleatorias es lo que hay detrás de la expresión «apenas mejor que el azar» del titular.

Por qué una falsa alarma es peligrosa

El esquema de verificación es sencillo. El agente escribe una consulta y la verificación la contrasta, junto con los resultados, con la ontología. Si hay una alerta, el agente recibe un único reintento. Ahí está el riesgo: cuando la alerta es falsa, el agente puede convertir una respuesta correcta en una incorrecta. Algo parecido ya se observó al refinar consultas text-to-SQL. La precisión final no lo refleja, porque en ella se mezclan los errores detectados y las respuestas correctas estropeadas. Por eso los autores cuentan por separado cuántos errores encontró la verificación y a cuántas respuestas correctas marcó sin motivo.

Las ontologías son especialmente propensas a los falsos positivos. Sus axiomas se leen como restricciones rígidas, y las ontologías publicadas no describen los datos por completo. En un rastreo de datos enlazados (Linked Data), el 14,3% de las tripletas usaba propiedades que no aparecían en ninguno de los vocabularios revisados. Una verificación que exigiera declarar cada propiedad rechazaría también respuestas correctas que se apoyan en ellas.

También hay un ejemplo de verificación acertada. Supongamos que la ontología establece que la fecha de nacimiento solo la tiene una persona y que ciudad y persona son clases incompatibles. Entonces, una consulta de la fecha de nacimiento de una ciudad contradice la ontología y la alerta está justificada. Pero una consulta puede ejecutarse sin errores y, aun así, responder a una pregunta distinta de la formulada. Las verificaciones estructurales pueden pasar por alto esos errores.

Tres orígenes de la ontología y tres formas de aplicarla

Se compararon ontologías de tres tipos:

• Experta. La redactaron personas a mano y se usó tal como está publicada. • Inferida de los datos. Se extrajo del propio grafo. • Escrita por un LLM. El modelo la construyó a partir de un resumen del grafo en el que los identificadores se sustituyeron por nombres opacos. Con ello, los autores quisieron descartar que el LLM se limitara a recordar identificadores de grafos públicos.

Cada ontología se usó como contexto en la consulta del agente, como verificación de la respuesta o en ambas funciones a la vez. Además, los investigadores analizaron si ayuda combinar las fuentes y si resulta útil mostrar al agente el mensaje concreto de la verificación.

Cómo se organizó el experimento

Los agentes se construyeron con cinco modelos de pesos abiertos y dos propietarios. La parte confirmatoria del estudio se realizó en UniProt. Otros grafos públicos y un grafo privado, cuyo tamaño el texto indica como «casi» un determinado número de tripletas, dieron resultados exploratorios. El plan de análisis se registró de antemano.

Para que la comparación fuera justa, los autores tuvieron en cuenta tres circunstancias. Algunos errores los detecta la propia ejecución de la consulta, por ejemplo un resultado vacío; se separaron de los errores detectados por la verificación. Las verificaciones se probaron tanto con respuestas reales de agentes como con errores artificiales introducidos en consultas correctas. Por último, cada verificación se aplicó a las mismas respuestas y errores, y su decisión se comparó con la respuesta correcta conocida de antemano.

Qué resultó

En UniProt, la ontología experta marcó más respuestas correctas que la ontología derivada de los datos y que la ontología que el LLM infirió a partir de un resumen con identificadores enmascarados. Con respuestas reales de agentes, sus alertas son solo algo más precisas que las aleatorias. Cada fuente de ontología intercambia a su manera errores detectados por falsas alarmas. La ontología experta, en su versión publicada, contradice en algunos puntos los datos de su propio grafo. Además, las verificaciones estructurales dejan pasar una parte de los errores.

Qué se deduce de todo esto

Tener a mano una ontología experta no basta para contar con un buen juez. Antes de activar la verificación conviene medir dos cosas: cuántos errores detecta y cuántas respuestas correctas estropea con el reintento. Una referencia del desarrollo de software: en el análisis estático dentro del code review de Google, la tasa efectiva de falsos positivos debe ser inferior al 10%; de lo contrario, los desarrolladores dejan de confiar en la herramienta.

A quienes publican grafos les conviene contrastar la ontología con los datos antes de publicarla. Los desarrolladores de agentes tienen que decidir por separado dónde resulta más útil la ontología: en el contexto, en la verificación o en ambos sitios. Los autores han publicado un conjunto de errores artificiales con respuestas correctas conocidas de antemano, el código y un protocolo que calcula los errores detectados y las falsas alarmas sin ejecutar el agente.