Одна модель, два агента: почему ИИ в 1С без готовых инструментов делает 23 запроса и ошибается

Подключить нейросеть к 1С сейчас может любой разработчик: поднял MCP-сервер, дал права на чтение, и модель сама находит таблицы и пишет запросы. На демо-базе это выглядит убедительно, поэтому мне захотелось проверить то же самое на настоящей базе с сотнями тысяч записей, где неудачный запрос уже не спрячешь.

Один и тот же набор из 15 вопросов я прогнал дважды. В первый раз агент собирал ответы сам, через поиск по метаданным и свои запросы, а во второй у него были готовые инструменты, то есть проверенные запросы под конкретные вопросы. Модель, база и формулировки остались прежними.

Как проверяли

• База: копия рабочей базы торговой сети на УТ 11.5, в справочнике 680 тысяч позиций номенклатуры и 286 тысяч контрагентов.
• Вопросы. Под десять из них у агента не было готового инструмента. Ещё пять типовых: остатки, продажи по менеджерам, долги клиентов, деньги на счетах и график выручки.
• Каждый вопрос я задавал в новом диалоге, чтобы ответы не подсказывали друг другу.
• Запросом считаю любое обращение агента к базе: поиск объекта в метаданных, чтение структуры, выборку данных, выгрузку в файл. Агент сам пишет под ответом, сколько таких шагов ему понадобилось.

Что делает агент, когда готового ответа нет

Возьмём вопрос «Покажи сотрудников и их должности». Кадрового учёта в УТ 11 нет, и модель об этом не знает, поэтому начинает искать: перебирает объекты по слову «сотрудник», читает их структуру, пробует запросы и возвращается назад.

Через 23 запроса агент выдал файл на 158 строк. В другом прогоне тот же вопрос занял 9 запросов, и в файле оказалось 394 строки вместе с уволенными и служебными учётками вроде Admin1C.

Работающих сотрудников в базе 242, ещё 152 записи недействительны. Выходит, первый ответ потерял больше трети людей, а второй смешал работающих с уволенными и роботами интеграций.

Ещё два случая

Тридцать запросов ради «не нашёл»

На вопрос «Какие виды цен есть в базе и какой используется в продажах по умолчанию?» агент сделал 30 запросов, а в конце попросил уточнить, для какого клиента нужна цена: единой настройки «вид цены по умолчанию» он не нашёл.

Такой настройки в УТ действительно нет. Цену в документ продажи подставляет соглашение с клиентом, в рознице её берут из вида цен магазина, и до соглашений модель так и не добралась.

Запрос, который повесил агента

Вопрос «Какие товары есть в справочнике, но ни разу не поступали?». В первом прогоне агент сделал 13 запросов и выгрузил файл, обрезанный на 200 000 строках из 408 тысяч.

Во втором он написал запрос с НЕ В (ВЫБРАТЬ …) по всей номенклатуре. Я несколько минут смотрел на «Получаю данные из базы», после чего остановил запрос и перешёл к следующему вопросу.

Что такое готовый инструмент

Ничего хитрого в нём нет: это обычный запрос, который разработчик один раз написал и проверил, зная, в каких регистрах лежат данные, какие записи служебные и как посчитать быстро. Модель видит описание инструмента и вызывает его вместо поиска по метаданным.

Инструмент для сотрудников сам выбирает источник по конфигурации: в ЗУП и БП берёт кадровые данные, в УНФ кадровую историю, в УТ и Рознице пользователей с должностью из карточки. Служебные учётки он отбрасывает и тут же считает сводку по должностям, так что агенту остаётся один вызов.

Товары без поступлений инструмент считает через временную таблицу и левое соединение, без НЕ В. На 680 тысячах позиций это занимает секунды:

ВЫБРАТЬ РАЗЛИЧНЫЕ
    Т.Номенклатура КАК Номенклатура
ПОМЕСТИТЬ ВТПоступали
ИЗ
    РегистрНакопления.ТоварыНаСкладах КАК Т
ГДЕ
    Т.ВидДвижения = ЗНАЧЕНИЕ(ВидДвиженияНакопления.Приход)
ИНДЕКСИРОВАТЬ ПО
    Номенклатура
;
ВЫБРАТЬ
    КОЛИЧЕСТВО(*) КАК Всего,
    СУММА(ВЫБОР КОГДА П.Номенклатура ЕСТЬ NULL ТОГДА 1 ИНАЧЕ 0 КОНЕЦ) КАК НеПоступали
ИЗ
    Справочник.Номенклатура КАК Н
        ЛЕВОЕ СОЕДИНЕНИЕ ВТПоступали КАК П
        ПО Н.Ссылка = П.Номенклатура
ГДЕ
    НЕ Н.ЭтоГруппа
    И НЕ Н.ПометкаУдаления

Те же вопросы, другие ответы

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

Если собираете ИИ-агента для 1С сами

• Модель с доступом к базе хорошо отвечает, пока путь к данным короткий. На большой типовой конфигурации сложный вопрос превращается в поиск дороги, и результат меняется от раза к разу.
• Считайте запросы: если вопрос стабильно требует больше пяти, под него нужен готовый инструмент.
• Ограничьте время запросов модели. Один НЕ В по всей номенклатуре вешает агента на минуты, поэтому такие запросы лучше выполнять в фоновом задании с таймаутом и возвращать модели подсказку, как их переписать.
• Перед каждым запросом модель заново получает всю историю диалога, так что 23 запроса обходятся в разы дороже одного, а ответ приходит позже.