Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Семантический слой для агентов данных научили автоматически собирать по рабочим заданиям и менять после неудачных запусков. EvoOntology обошла обычного агента на всех проверенных моделях, хотя работа не рецензирована и числа в ней получили сами авторы. Для продукта это предлагает альтернативу двум привычным вариантам: поиску по сырым источникам при каждом запросе и загрузке всей семантики в контекст модели.
Онтология связывает понятия бизнеса с таблицами и файлами
Агент данных — это программа на базе LLM, которая отвечает на вопросы по таблицам, базам и документам. Без промежуточного слоя она вынуждена изучать названия столбцов, проверять значения и заново искать связи между источниками при каждом задании.
В EvoOntology онтология служит рабочей картой данных, а не только словарём терминов. Она хранит понятия предметной области, соответствующие им поля и пути соединения таблиц, правила использования и свидетельства из исходных данных. Например, понятие «валовая маржа» можно связать с конкретными показателями, формулой и запросом, который подтвердил значения.
Схема отдельно задаёт типы объектов и допустимые связи между ними. Благодаря этому система может расширить саму структуру онтологии, если прежней модели объектов не хватает, и при этом не переписывать всё содержимое.
Онтология работает как сервер MCP. В начальный контекст попадает только короткий манифест с описанием источников и правилами доступа, а подробности агент запрашивает по мере работы. Инструмент fbrowse ищет подходящие понятия, а fresolve возвращает выбранные записи вместе со связанными объектами.
Начальную версию строит отдельный агент. Он выделяет повторяющиеся сущности, показатели, операции и условия из набора рабочих заданий, затем выполняет пробные запросы к данным. Запись попадает в онтологию только после проверки типа, фильтра и распределения значений; правильные ответы на задания строителю не показывают.
Изменения проходят через журнал траекторий и парную проверку
После запуска EvoOntology анализирует полные траектории агента: запросы к инструментам, найденные объекты и итоговый результат. Повторяющуюся ошибку система относит к содержимому, инструментам или схеме и формулирует ожидаемый эффект исправления.
Каждая кандидатная правка затрагивает только один уровень. Система может добавить отсутствующее соответствие столбцу, изменить способ выдачи результатов или расширить модель объектов. Ограниченный размер правки помогает связать изменение результата с конкретной гипотезой.
Кандидат и предыдущую версию запускают на одинаковом отложенном наборе, с одной конфигурацией модели и равным бюджетом взаимодействий. Новую версию принимают только при заданном приросте качества, а отклонённую правку сохраняют в журнале, чтобы не предлагать её повторно.
Метод проверяли на трёх наборах задач: DDR-Bench для исследования финансовых документов, InsightBench для аналитики CSV и BIRD для генерации SQL по реальным базам. В опытах участвовали шесть LLM семейств GPT, Claude, DeepSeek и Qwen; онтологию замораживали до итоговой проверки на другой части набора.
На DDR-Bench средний прирост точности полной цепочки действий составил 17,8 процентного пункта относительно агента без онтологии. Простая вставка статического семантического слоя иногда мешала: на Claude-Sonnet-5 результат снизился на 15,0 пункта. Если принимать все изменения без проверочного барьера, качество падало на 11,2 пункта, поэтому отбор правок здесь важнее самого цикла обновления.
Командам стоит разделить знания, доступ и обновление
Работа меняет план продукта, если агент сейчас каждый раз исследует сырые источники или получает большой справочник внутри запроса. Вместо расширения контекста можно вынести семантику в отдельный версионируемый сервис и разрешить модели выбирать нужные записи через инструменты.
- Строить слой вокруг реальной нагрузки. Начальный набор понятий следует извлекать из типовых пользовательских заданий, а не пытаться заранее описать всю предметную область.
- Хранить не только определения. Понятия нужно связывать с полями, соединениями и проверяемыми примерами из данных. Именно эти соответствия позволяют агенту перейти от делового термина к исполнимому запросу.
- Отдавать знания по запросу. В контексте остаётся компактное описание возможностей, а записи онтологии загружаются только для текущего шага. Это отделяет объём семантического слоя от доступного контекста LLM.
- Обновлять через версионирование. Траектории дают материал для правок, но каждая версия должна пройти парное сравнение и поддерживать откат.
Эволюцию придётся вести отдельно для выбранной LLM. При переносе готовой онтологии между моделями точность в опытах снижалась минимум на 6,6 пункта: разные модели по-разному используют манифест, инструменты и степень детализации записей. Поэтому смена базовой модели становится не только заменой API, но и поводом заново прогнать цикл адаптации семантического слоя.
Проверка охватывает аналитические задания по документам, CSV и реляционным базам. В этих границах EvoOntology даёт архитектурный рецепт: накопить найденные связи между понятиями и данными, вынести их из запроса в MCP-сервис и допускать автоматические изменения только после сравнения с предыдущей версией.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
