Ontology as a checker for an AI agent: on UniProt, its error flags are only slightly more accurate than random

Researchers at the Sano Centre for Computational Medicine tested whether an ontology can be trusted as a judge for an AI agent. An ontology is a machine-readable description of which types of entities exist in a knowledge graph and how they may be connected. An agent built on a large language model (LLM) answers a question by sending a SPARQL query to the graph, for example the UniProt database.

The ontology checks the query and its result and either lets the answer through or raises a flag. On real agent answers, the flags from UniProt's expert ontology were only slightly more accurate than random. That comparison with random flags is what the headline means by "only slightly more accurate than random."

Why a false alarm is dangerous

The verification setup is simple. The agent writes a query, and the checker compares the query and its results against the ontology. If a flag is raised, the agent gets one retry. That is where the risk lies: when the flag is false, the agent can rework a correct answer into a wrong one. Similar behavior has already been observed when refining text-to-SQL queries. Final accuracy does not reveal this, because caught errors and spoiled correct answers get mixed together in it. So the authors count separately how many errors the check found and how many correct answers it flagged needlessly.

Ontologies are especially prone to false positives. Their axioms read as hard constraints, while published ontologies describe the data incompletely. In a crawl of Linked Data, 14.3% of triples used properties that appear in none of the vocabularies examined. A check that requires every property to be declared would also reject correct answers that rely on such properties.

There is also an example of a check working as intended. Suppose the ontology says that only a person can have a date of birth, and that city and person are disjoint classes. A query for a city's date of birth then contradicts the ontology, and the flag is justified. But a query can run without errors and still answer a different question from the one that was asked. Structural checks may miss such errors.

Three sources of an ontology and three ways to use it

The researchers compared three kinds of ontology:

• Expert. People wrote it by hand, and it was used exactly as published. • Derived from data. It was extracted from the graph itself. • Written by an LLM. The model built it from a summary of the graph in which identifiers were replaced with opaque names. The authors did this to rule out the case where the LLM simply recalls identifiers from public graphs.

Each ontology was used as context in the agent's prompt, as a check on the answer, or in both roles at once. The researchers also looked at whether combining sources helps and whether it is useful to show the agent the specific message from the check.

How the experiment was set up

The agents were built on five open-weight models and two proprietary ones. The confirmatory part of the study was run on UniProt. Other public graphs and a private graph, whose size the text gives as "almost" a certain number of triples, produced exploratory results. The analysis plan was registered in advance.

To keep the comparison fair, the authors accounted for three things. Some errors are caught by query execution itself, for example an empty result. These were separated from the errors caught by the check. The checks were tested both on real agent answers and on synthetic errors injected into correct queries. Finally, every check was run on the same answers and errors, and its decision was compared with a correct answer known in advance.

What the results show

On UniProt, the expert ontology flagged more correct answers than the ontology derived from data and the ontology that an LLM inferred from a summary with masked identifiers. On real agent answers, its flags are only slightly more accurate than random. Each ontology source trades caught errors for false alarms in its own way. The expert ontology, as published, in places contradicts the data in its own graph. In addition, structural checks miss some errors.

What follows from this

A ready-made expert ontology does not by itself make a good judge. Before turning a check on, it is worth measuring two things: how many errors it catches and how many correct answers it spoils through the retry. A benchmark from software engineering: in static analysis in Google's code review, the effective false-positive rate must stay below 10%, or developers stop trusting the tool.

Graph publishers would do well to check the ontology against the data before publishing. Agent developers need to decide separately where an ontology is most useful: in the context, in the check, or in both places. The authors released a set of synthetic errors with correct answers known in advance, the code, and a protocol that counts caught errors and false alarms without running the agent.