TL;DR
AgentOnto — это агент для анализа данных, которому перед работой собирают явный словарь бизнес-знаний (онтологию). В нём три части: сущности (клиент, заказ), определения метрик («выручка» = что считаем и что исключаем) и привязка к таблицам и столбцам базы. Агент не пишет SQL сразу. Он сначала составляет план со ссылками на словарь, затем проверяет план по словарю и только после этого выполняет запрос.
Главная боль: SQL-запрос выполнился без ошибок, но цифра неверная. Агент не знал, что «выручка» у вас считается без возвратов, а «активный клиент» — это покупка за 90 дней. В схеме базы этого нет. Эти правила живут в документах и в головах аналитиков. Агент их угадывает и тихо ошибается. Авторы называют это тихой смысловой ошибкой. Ещё хуже, когда агент отвечает на вопрос, на который по данным вообще нельзя ответить.
Метод решает это так. Знания из базы, документов и старых примеров задач сводятся в один словарь, где у каждой записи указан источник и статус подтверждения. Агент всегда выбирает одно из трёх действий: выполнить, уточнить или отказаться. Словарь потом обновляют по подтверждённым замечаниям. Каждое изменение проверяют двумя наборами вопросов: что должно измениться и что обязано остаться как было. Перед боевой работой словарь прогоняют на самосочинённых задачах.
Схема метода
ШАГ 1. СБОРКА СЛОВАРЯ: база + документы + примеры задач
→ сущности / метрики / привязка к таблицам
(у каждой записи: источник + статус «подтверждено»)
Подтверждение — отдельным проходом модели.
ШАГ 2. ПОДГОТОВКА (2 раунда × 4 задачи): модель сама придумывает вопросы,
решает их по словарю, отдельный проход проверяет ответы
→ найденные дыры вносятся в словарь
ШАГ 3. РАБОТА С ЗАПРОСОМ:
запрос → решение: выполнить / уточнить / «не поддерживается»
→ план со ссылками на словарь
→ проверка плана по словарю (сущности есть? метрика по правилам? маппинг есть?)
→ SQL по маппингу → выполнение
ШАГ 4. ОБНОВЛЕНИЕ по подтверждённой обратной связи:
правка одной записи
→ проверки «должно измениться» + проверки «должно остаться»
→ принять правку, только если прошли обе группы; иначе откат
В оригинале это система на коде. Шаги 1–4 выполняются автоматически, а на каждом шаге вызывается модель.
Пример применения
Метод сильнее всего там, где у данных есть неочевидные бизнес-правила, которых нет в названиях столбцов. Бессмысленно применять его к разовой простой выгрузке.
Задача: Вы селлер на Ozon и Wildberries. Выгрузка продаж лежит в Google Sheets или в базе, а на неё смотрит агент (Claude Code, Cursor или кастомный GPT). Собственник спрашивает: «Какая у нас выручка по категории „Дом“ за апрель и сколько активных покупателей?» В таблицах есть статусы «доставлен», «возврат», «отменён» и цены с НДС. Агент не знает, что у вас выручка считается по доставленным, за вычетом возвратов, без НДС.
Промпт (кладём в системную инструкцию или CLAUDE.md):
Заказ(orders): order_id, status ∈ {доставлен, возврат, отменён}, price_gross, vat_rate, sku_id, buyer_id, delivered_at
SKU(skus): sku_id, category
Покупатель: buyer_id (только внутри orders; персональных данных нет)
Выручка = SUM(price_gross / (1 + vat_rate)) по заказам status='доставлен' МИНУС такая же сумма по status='возврат'.
Источник: «Регламент отчётности v3», п.2. Статус: подтверждено.
Активный покупатель = buyer_id с ≥1 доставленным заказом за последние 90 дней от даты отчёта.
Источник: пример задачи №14. Статус: НЕ подтверждено (нужна проверка).
Выручка → orders.price_gross, orders.vat_rate, orders.status; категория → JOIN skus ON orders.sku_id = skus.sku_id
Для каждого запроса:
1. Реши действие: EXECUTE / CLARIFY / UNSUPPORTED.
CLARIFY — если в запросе не хватает данных (период, канал).
UNSUPPORTED — если запрос требует данных, которых нет в словаре (например, маржа: себестоимости нет).
2. Составь ПЛАН: какие записи Ontology используешь, какие выборы сделал сам (период, фильтры).
3. ПРОВЕРЬ ПЛАН: все сущности есть в Entities? Метрика посчитана ровно по определению? Для каждого поля есть Mapping?
Если нет — исправь план или смени действие.
4. Только после проверки напиши запрос и выполни.
5. В ответе покажи: действие, план, какие записи Ontology применены, итог. Метрики со статусом «не подтверждено» помечай как предварительные.
Результат: Агент сначала напишет решение («выполнить» или «уточнить») и план со ссылками на определения. Затем покажет проверку плана: что учтены возвраты и НДС. Только после этого придёт запрос и итоговая цифра. Если спросить про маржу, агент должен ответить «не поддерживается: нет себестоимости». Показатель «активные покупатели» он пометит как предварительный, потому что определение не подтверждено.
Почему это работает
Слабость. LLM пишет правдоподобный запрос по названиям столбцов и угадывает бизнес-смысл. Если запрос выполнился, никто не видит, что цифра посчитана «не по-вашему». К тому же «доступный ответ» ≠ «верный ответ»: высокий процент ответов не гарантирует правильных ответов.
Сильная сторона. Модель хорошо следует явно записанным определениям и умеет сверять план с чек-листом. Она также умеет придумывать тестовые вопросы по документам и разбирать расхождения.
Как метод это использует. Знания выносятся из головы аналитика в один проверяемый документ, а план проходит сверку до выполнения. Правки проверяются на «регрессии»: исправили метрику «активный покупатель», но не сломали «выручку».
Рычаги управления: - Статус подтверждения → оставь только подтверждённые определения как «жёсткие», а остальные помечай как предварительные. - Число раундов и задач подготовки (в статье 2×4) → увеличь для большой базы, уменьши для маленькой. - Три действия (выполнить / уточнить / отказаться) → добавь свои, например «передать человеку». - Проверки «изменится» и «останется» → накапливай набор вопросов с известными ответами, он станет вашим тестом.
Шаблон промпта
Авторы не публикуют промпты, а описывают систему на коде. Ниже перенос идеи в текстовую инструкцию по её структуре. Это не дословный промпт из статьи.
Ты аналитик данных. Ты не пишешь запрос, пока не сверился с Ontology.
{сущности: таблицы, ключевые поля, допустимые значения}
{метрика} = {формула и условия применения}. Источник: {документ/пример}. Статус: {подтверждено / не подтверждено}.
{понятие} → {таблица.столбец, связи JOIN}
Для каждого запроса {запрос}:
1. action = EXECUTE | CLARIFY | UNSUPPORTED.
2. plan: какие записи Ontology используются; какие допущения сделаны сверх неё.
3. check(plan): сущности из Entities? метрики по определению? для каждого поля есть Mapping?
Если check не пройден — исправь plan или смени action.
4. compile: запрос строй строго по Mappings.
5. Выведи: action, plan, результат check, применённые записи Ontology, итог.
Когда я присылаю подтверждённое замечание {замечание}:
1. Найди ОДНУ запись Ontology, к которой оно относится.
2. Предложи точечную правку.
3. Составь corr_checks: вопросы, ответ на которые ДОЛЖЕН измениться.
4. Составь ret_checks: вопросы, ответ на которые ДОЛЖЕН остаться прежним.
5. Прогони обе группы по правилам .
Принимай правку только если обе группы пройдены. Иначе откати и объясни почему.
Что подставлять: в {сущности} — схему базы и допустимые значения полей. В {метрика} — определения из регламентов. В {замечание} — ваши подтверждённые исправления, например «выручка должна быть без НДС».
🚀 Быстрый старт — вставь в чат:
Вот шаблон ontology-guided аналитика. Адаптируй под мою задачу: [твоя задача и данные].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про таблицы и поля, определения метрик и откуда они взяты, какие вопросы нельзя решать по этим данным. Это нужно, потому что метод держится на трёх частях словаря: сущности, метрики, привязка к таблицам. Без метрик и границ данных агент вернётся к угадыванию.
Ограничения
⚠️ Нужна инженерная реализация: в оригинале всё автоматизировано (сборка словаря из базы, документов и примеров, подтверждающий проход, цикл подготовки, откат правок). В чате вы повторите идею, но не автоматику. Словарь придётся вести вручную или собрать скрипт.
⚠️ Результаты получены на данных, подготовленных самими авторами: базы, документы и примеры задач они собирали сами, на открытых данных. Сравнение с другими методами проводилось на одной и той же модели, поэтому на вашей модели и данных эффект может быть иным.
⚠️ Словарь стареет и может ошибаться: если определение в нём неверное, агент будет уверенно считать неверно. Статус «подтверждено» не заменяет проверки человеком.
⚠️ Не для простых запросов: если в базе нет скрытых бизнес-правил, словарь не даст выигрыша, а добавит поддержки.
⚠️ Не все результаты вошли в разбор: предоставленный текст статьи обрывается на первом разделе экспериментов. Результаты по построению словаря, по анализу и по обновлению, а также описание реального внедрения здесь не рассмотрены.
Как исследовали
Исследователи взяли две открытые базы из разных областей: World Development Indicators (экономика стран) и данные о качестве воздуха EPA. Для каждой они собрали «корпоративную» среду: базу, бизнес-документы и примеры задач. Получилось 606 запросов (282 и 324) и 44 подтверждённых замечания с 174 запросами после правок. Анализ розничного набора показал: для запросов нужно 46 бизнес-понятий, которых нет в схеме базы. Это и есть та самая пропасть, которую закрывает словарь.
Сравнивали с четырьмя методами: DIN-SQL, ReFoRCE, MAC-SQL (многоэтапная генерация SQL) и Vanna (агент с инструментами). Во всех случаях подставляли ту же модель, что и у AgentOnto, поэтому разница идёт от метода, а не от силы модели. Запрос считался верным, только если правильно решено действие (выполнить, уточнить, отказать) и, где нужно, верен результат.
Итог: у AgentOnto 87,5% точности в среднем (79,1% и 96,0% по двум областям), у лучшего конкурента 55,0%. Прирост составил 32,6 и 30,3 процентного пункта. Инсайт для практики: запись бизнес-смысла в явном виде даёт больше, чем более хитрая генерация SQL. Две проверки при обновлении словаря, «должно измениться» и «должно остаться», защищают от ситуации, когда исправление одного ломает другое.
Адаптации и экстраполяции
🔧 Техника: добавить «набор эталонных вопросов» → правка не ломает старое
Ведите отдельный список из 10–20 вопросов с известными верными ответами. Перед тем как принять любое изменение в определениях, просите агента прогнать этот список:
Прежде чем принять правку: прогони все вопросы из .
Если хоть один ответ изменился без моего указания — откати правку и покажи, какой.
Это переносит идею проверок «должно остаться» в обычный чат. Оригинал строит такие проверки автоматически.
Экстраполяция: самопроверка словаря перед стартом. Перед боевой работой попросите: «Придумай 4 вопроса, которые проверят слабые места этого словаря. Реши их по правилам. Покажи, где словарь неоднозначен или пуст, и предложи правки». Это урезанная версия подготовки на самосочинённых задачах: один раунд, без отдельной модели-проверяющего. Для надёжности второй проход лучше делать в новом чате.
Ресурсы
- AgentOnto: Ontology-Guided LLM Agents for Enterprise Data Analytics — Dayan Pan, Bincheng Zuo, Xiaojian Wang, Daogang Zhang, Jingyuan Wang. Beihang University (Пекин) и Omaha AIGC (Шанхай). KDD '27.
- Упоминаемые в статье системы и методы: DIN-SQL, ReFoRCE, MAC-SQL, Vanna, SiriusBI, CoeusBI, SODA, ATHENA.
- Данные: World Development Indicators, U.S. EPA Air Quality System.