Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
MasterControl AI Lab исследовала архитектуру корпоративной аналитики, в которой языковая модель отвечает за понимание запроса, но не определяет способ расчёта. По замерам авторов, выполнение утверждённых программ дало точный контракт ответа в 110 из 110 случаев, тогда как агенты с планированием во время запроса не справились ни в одном случае; работа опубликована как препринт, который не проходил рецензирования. Результат важен командам, которые строят аналитические помощники для регламентированных показателей, аудита и других задач, где вместе с числом нужно вернуть проверяемые основания.
Что сделали
Авторы разделили обработку вопроса на две части. Языковая модель преобразует формулировку пользователя в канонический запрос: выбирает управляемое определение показателя и извлекает допустимые параметры, например площадку или период. После этого детерминированная политика, то есть набор правил с однозначным результатом, выбирает заранее написанную и проверенную аналитическую программу.
Модель в такой схеме не генерирует SQL, не выбирает инструменты и не определяет последовательность операций. Если подходящей программы в каталоге нет, система должна запросить уточнение или отклонить запрос, а не составлять новый метод расчёта во время выполнения.
Ответ представлен не одним значением, а контрактом из принятого смысла вопроса, результата и подтверждающих записей с указанными ролями. Отдельный сертификат фиксирует снимок данных, версии политики и программы, правила вычислений и формат выдачи. При неизменном состоянии повторный запуск должен вернуть тот же результат и те же подтверждения.
Авторы также описали ограниченный язык аналитических программ. Он охватывает фильтрацию и соединение отношений, агрегирование, сравнение, временные окна, ранжирование и поиск по фиксированному правилу сходства. В работе утверждается, что этого достаточно для любой конечной спецификации внутри заявленного класса. Речь не идёт об универсальном языке или способности отвечать на произвольные вопросы: фактическое покрытие зависит от каталога утверждённых программ.
В эксперименте эту схему сравнили с тремя моделями класса 8B, которые самостоятельно изучали данные, писали SQL, запускали его и при необходимости пересматривали процедуру. Было два режима: полный путь от естественного языка и выполнение уже принятого канонического запроса. Второй режим позволял отделить ошибки понимания вопроса от ошибок при выборе метода.
Что показали
Основным критерием была не правильность видимого числа сама по себе. Процедура должна была сохранить определение показателя, выбрать нужные записи, правильно назначить им роли в подтверждении и одинаково пройти проверку на разных вариантах базы.
В 330 эпизодах с планированием во время запроса агенты часто отклоняли задачу или исчерпывали бюджет инструментов. Только 55 эпизодов завершились выдачей процедуры, но каждая такая процедура нарушила полный контракт хотя бы на одном из пяти снимков данных. Среди ошибок были неверная роль подтверждающих записей и некорректная обработка пустой выборки, даже когда число на исходном снимке совпадало с эталоном.
Сравнение одной и той же Qwen3-8B по разные стороны архитектурной границы показало и вычислительную цену выбора метода моделью. В режиме естественного языка вариант с политикой использовал в 4,8 раза меньше токенов и выполнялся в 29 раз быстрее, чем агент, создававший процедуру во время запроса. Авторы отдельно предупреждают, что небольшое число повторных попыток у агентов нельзя считать эффективностью: многие запуски прекращались до появления пригодной процедуры.
Ограничения
Эксперимент проведён на одном синтетическом наборе производственных данных и охватывает одиннадцать аналитических задач: подсчёты, группировки, отсутствие записей, ранжирование, доли, изменения по периодам, соединения, средние значения и пороги сходства. Проверка включала исходный снимок и четыре варианта с заранее подобранными пограничными случаями. Это проверяет устойчивость процедур к известным классам ошибок, но не показывает покрытие реальных запросов конкретной организации.
Сравнение относится к выбранным моделям, подсказкам, бюджету инструментов и способу взаимодействия с SQL. Авторы не сравнивали подход с более крупными моделями, нативным вызовом функций, формальной проверкой сгенерированных программ или иным алгоритмом поиска. Работа также не измеряет стоимость создания, согласования и сопровождения каталога политик. Поэтому из неё нельзя заключить, что планирующие агенты в принципе не способны выполнять аналитику или что управляемая схема будет дешевле на любом производственном потоке.
Что это значит
Работа меняет планы команд, которые собирались позволить модели самостоятельно писать запросы для уже определённых показателей. Если метод расчёта заранее известен и должен проходить аудит, свобода планирования не добавляет выразительности внутри поддерживаемого класса, но создаёт дополнительную поверхность ошибок. Практический проект в таком случае стоит строить вокруг канонической схемы намерений, версионируемого каталога программ и обязательного контракта подтверждений.
При этом модель остаётся полезной на границе с пользователем: она разбирает вариативные формулировки и связывает их с управляемыми понятиями. Контроль нужен в точке перехода от смысла к исполнению. Параметры запроса должны быть типизированы, выбор программы — определяться политикой, а неподдерживаемые запросы — явно останавливаться.
Для открытых исследований, проектирования нового показателя или поиска метода агентное планирование по-прежнему соответствует самой задаче. Предложенная архитектура предназначена для другой ситуации: организация уже знает, как считать показатель, и хочет воспроизводимо применять это правило. Решение о внедрении упирается не в возможности LLM, а в долю реальных запросов, которую команда готова покрыть проверенными программами, и в стоимость расширения этого покрытия.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
