Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Корпоративного агента научили сохранять принятые в компании определения и правила на всём пути от вопроса до готового отчёта. В препринте China Unicom и Nankai University, который не прошёл рецензирование и содержит замеры самих авторов, UniDataAgent достиг строгой точности 95% против 72,5% у поиска по документам с генерацией ответа (RAG). Для команд это смещает задачу с настройки подсказок к созданию отдельного, версионируемого слоя бизнес-семантики.
Онтология становится исполняемым контрактом
Обычный агент может найти подходящие таблицы и составить корректный SQL, но всё равно неверно понять показатель. Например, он возьмёт другую группу клиентов, период, территорию или способ агрегации. Документы помогают найти термины, однако не гарантируют, что агент одинаково применит их в нескольких запросах.
UniDataAgent выносит эти правила в корпоративную онтологию — формальную модель сущностей, метрик, связей и допустимых операций. Она связывает деловое понятие с физическими полями, задаёт состав показателя, доступные разрезы, правила расчёта и происхождение определения.
Систему разделили на офлайн-подготовку знаний и выполнение запросов. На первом этапе она читает метаданные баз, внутренние материалы и описанные экспертами процедуры анализа. Затем строит семантический план, создаёт элементы онтологии и прикрепляет к ним источники.
Кандидатную версию проверяют на типовых деловых вопросах. Проверяющий агент ищет пропущенные понятия, противоречивые определения, неподтверждённые связи и вопросы, на которые онтология не позволяет ответить. Локальные ошибки запускают исправление отдельных элементов, а системные — перестройку плана. Спорные и влияющие на бизнес изменения передают эксперту, после чего онтология выходит как новая версия.
Для конкретного вопроса система извлекает не набор похожих фрагментов текста, а компактный семантический контракт. В него входят нужная метрика, объект анализа, период, территория, ограничения запроса, физические поля и порядок вычислений. Такой контракт образует типизированную границу между знаниями компании и LLM вместо свободной передачи контекста на естественном языке.
Полнота оказалась важнее удачного запроса
Систему сравнили с документным RAG на 40 реальных вопросах из шести операционных областей. В обоих вариантах использовали DeepSeek-V4 и одну корпоративную среду данных. Ответ считали правильным, только если он полностью совпадал с эталоном по результату, охвату, условиям и составу метрики.
На вопросах, где требовалось определить метрику и область расчёта, разрыв был умеренным. Сильнее он проявился там, где агент должен был охватить все регионы или совместно интерпретировать несколько показателей. UniDataAgent получил 100% в каждой из этих сложных групп, тогда как документный RAG показал 63,6% на региональных сравнениях и 57,1% на диагностике по нескольким метрикам.
Ошибки RAG возникали не только из-за неверных значений. Агент мог пропустить часть регионов, смешать способы расчёта или связать показатели без достаточного основания. Онтологический контракт заранее фиксировал допустимый охват и связи, а проверка наблюдений не позволяла перенести в отчёт результат с неправильной единицей, периодом или областью.
После выполнения запросов система собирает принятые наблюдения в отдельный пакет доказательств. LLM строит выводы, динамику и рекомендации только на его основе, а интерфейс превращает результаты в таблицы и графики. Черновые вычисления и отклонённые результаты в итоговый отчёт не попадают.
Когда подход меняет архитектурный план
Подход проверяли в среде с 27 корпоративными таблицами и тысячами типов метрик. Построение онтологии заняло несколько часов вместо примерно недели ручной работы. Показанный сквозной сценарий сформировал отчёт за 200 секунд, тогда как ручная подготовка такого результата занимала несколько рабочих дней.
Эти границы важны для переноса результата. Работа охватывает одну корпоративную среду, одну модель и вопросы, для которых существуют эталонные ответы. Она лучше всего поддерживает архитектурное решение для систем со стабильными метриками, повторяющимися отчётами и высокой ценой неполного охвата.
Если команда строит агента поверх корпоративного хранилища, онтологию стоит планировать как самостоятельный продукт. Ей нужны владельцы определений, история версий, правила публикации, проверочные вопросы и процедура экспертного согласования. Подключить документы к RAG и заменить модель недостаточно: при каждом запросе агент снова будет угадывать те же бизнес-правила.
Второе изменение касается границы ответственности LLM. Модель может планировать анализ, выбирать инструменты и формулировать выводы, но определения метрик, допустимые связи и происхождение данных должны приходить из проверяемого контракта. Это позволяет обновлять модель или исполнительные инструменты, не переписывая корпоративную семантику внутри подсказок.
Третье изменение — отчёт становится результатом проверенного процесса, а не одним ответом модели. Система хранит выполненные запросы, принятые наблюдения и связь выводов с данными. Для продуктов, где аналитик должен перепроверить расчёт, такая трассировка может быть важнее способности LLM написать убедительный текст.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
