Онтология как проверяющий для ИИ-агента: на базе UniProt её флаги об ошибке лишь чуть точнее случайных

Исследователи из Sano Centre for Computational Medicine проверили, можно ли доверять онтологии как судье для ИИ-агента. Онтология — это машиночитаемое описание того, какие типы сущностей есть в графе знаний и как они могут быть связаны. Агент на основе большой языковой модели (LLM) отвечает на вопрос запросом на языке SPARQL к графу, например к базе UniProt. Онтология сверяет запрос и результат и либо пропускает ответ, либо ставит флаг. На реальных ответах агентов флаги экспертной онтологии UniProt оказались лишь немного точнее случайных. Именно это сравнение со случайными флагами и стоит за словами «чуть лучше жребия» в заголовке.

Почему ложная тревога опасна

Схема проверки простая. Агент пишет запрос, проверка сверяет его и результаты с онтологией. Если стоит флаг, агент получает одну повторную попытку. Тут и риск: когда флаг ложный, агент может переделать правильный ответ в неправильный. Похожее уже наблюдали при доработке запросов text-to-SQL. Итоговая точность этого не показывает, потому что пойманные ошибки и испорченные верные ответы в ней смешиваются. Поэтому авторы считают отдельно, сколько ошибок проверка нашла и сколько верных ответов пометила зря.

Онтологии особенно склонны к ложным срабатываниям. Их аксиомы читаются как жёсткие ограничения, а опубликованные онтологии описывают данные не полностью. В обходе связанных данных (Linked Data) 14,3% триплетов использовали свойства, которых нет ни в одном из просмотренных словарей. Проверка, которая требует объявить каждое свойство, отвергла бы и верные ответы, опирающиеся на такие свойства.

Есть и пример удачной проверки. Допустим, в онтологии записано, что дата рождения бывает только у человека, а город и человек — несовместимые классы. Тогда запрос даты рождения города противоречит онтологии, и флаг справедлив. Но запрос может выполниться без ошибок и всё равно отвечать на другой вопрос, не на тот, что задали. Такие ошибки проверки по структуре могут пропускать.

Три источника онтологии и три способа её применения

Сравнивали онтологии трёх видов:

• Экспертная. Её вручную составили люди, а использовали в том виде, в каком она опубликована. • Выведенная из данных. Её извлекли из самого графа. • Написанная LLM. Модель строила её по сводке графа, где идентификаторы заменены непрозрачными именами. Так авторы хотели исключить случай, когда LLM просто вспоминает идентификаторы из публичных графов.

Каждую онтологию использовали как контекст в запросе агента, как проверку ответа или в обеих ролях сразу. Кроме того, исследователи смотрели, помогает ли объединение источников и полезно ли показывать агенту конкретное сообщение проверки.

Как организован эксперимент

Агентов построили на пяти моделях с открытыми весами и двух проприетарных. Подтверждающая часть исследования выполнена на UniProt. Другие публичные графы и приватный граф, размер которого в тексте указан как «почти» некоторое число триплетов, дали разведочные результаты. План анализа зарегистрировали заранее.

Чтобы сравнение было честным, авторы учли три обстоятельства. Некоторые ошибки обнаруживает само выполнение запроса, например пустой результат. Их отделили от ошибок, пойманных проверкой. Проверки тестировали и на реальных ответах агентов, и на искусственных ошибках, внесённых в верные запросы. Наконец, каждую проверку прогнали на одних и тех же ответах и ошибках, а решение сравнили с заранее известным верным ответом.

Что получилось

На UniProt экспертная онтология пометила больше верных ответов, чем онтология из данных и онтология, которую LLM вывела из сводки с замаскированными идентификаторами. На реальных ответах агентов её флаги лишь немного точнее случайных. Каждый источник онтологии по-своему обменивает пойманные ошибки на ложные тревоги. Экспертная онтология в опубликованном виде местами противоречит данным собственного графа. Кроме того, проверки по структуре пропускают часть ошибок.

Что из этого следует

Готовая экспертная онтология ещё не делает хорошего судью. Прежде чем включать проверку, стоит измерить две вещи: сколько ошибок она ловит и сколько верных ответов портит повторной попыткой. Ориентир из разработки ПО: в статическом анализе в code review у Google эффективная доля ложных срабатываний должна быть ниже 10%, иначе разработчики перестают доверять инструменту.

Издателям графов полезно сверять онтологию с данными до публикации. Разработчикам агентов нужно отдельно решать, где онтология нужнее: в контексте, в проверке или в обоих местах. Авторы выложили набор искусственных ошибок с заранее известными верными ответами, код и протокол, который считает пойманные ошибки и ложные тревоги без запуска агента.