Отчёт, который собрал ИИ-агент, приходит вовремя. Он аккуратно оформлен, в нём ровные таблицы и вежливый комментарий. Он звучит уверенно.
Это и есть главная сложность, и она не про качество моделей. Когда отчёт готовит человек, вы читаете его вместе с человеком: по интонации слышно, где он не уверен, где сам не проверил, где взял на глаз. У отчёта, собранного машиной, такой интонации нет вовсе.
ИИ агент для отчетов сегодня продаётся десятками сервисов. Под словом «агент» тут понимают программу, которая сама ходит в вашу базу или в ваши сервисы, забирает оттуда цифры и сама складывает из них готовый отчёт. От обычного чата она отличается тем, что не ждёт, пока вы вставите ей данные: она их берёт. Ниже разобрано, где такой агент действительно снимает с вас работу, где он молча подписывает вам чужую цифру, чем пустой отчёт опаснее ошибочного и какие пять вопросов стоит задать продавцу до того, как вы заплатите.
Почему отчёт от агента выглядит убедительнее, чем он есть?
Модель обучена всегда давать ответ
Причина устроена скучнее, чем принято думать. Языковая модель, то есть программа, которая продолжает текст по смыслу, обучена всегда давать ответ.
Исследователи описывают это прямо:
Like students facing hard exam questions, large language models sometimes guess when uncertain, producing plausible yet incorrect statements instead of admitting uncertainty.
По-русски: как студент на трудном экзамене, модель при неуверенности угадывает и выдаёт правдоподобное вместо признания, что не знает. Догадка повышает оценку на экзамене, поэтому машина догадывается.
У отчёта нет места для оговорки
Дальше это накладывается на устройство самого отчёта. Отчёт по природе своей формален: строки, суммы, проценты.
В формальном документе негде сказать «вот тут я не уверен». Читатель получает оформление работы, и о самой работе оформление не говорит ничего.
Отсюда следствие, которое стоит держать в голове весь разговор с подрядчиком: вы покупаете не отчёт, вы покупаете доверие к цифре в нём. Проверять надо не вид отчёта, а происхождение числа в нём. Про то, чем работа агента отличается от рапорта о ней, я разбирал отдельно в статье как работает ИИ-агент.
Что написано на пяти продуктовых страницах, которые я открывал
Что обещано числом
Возьмите любую страницу такого продукта и посмотрите, что там обещано числом. У сервиса MWS Data Copilot это ответ за минуты вместо одного-двух дней и сокращение времени подготовки отчётов на 40 процентов. Формулировки для рынка типовые.
Честные оговорки на таких страницах встречаются, и это стоит признать. На странице этого продукта написано, что качество ответов зависит от подготовки данных: нужны описания таблиц и каталоги данных. Стоит эта оговорка ниже обещаний, отдельным блоком.
Чего я не нашёл ни на одной из пяти открытых страниц
Я открывал пять продуктовых страниц, и вот они: openclaw для бизнеса, PIX Оператор для 1С («Первый БИТ»), MWS Data Copilot, финансовый агент fin-ctrl и ассистенты для 1С от МБС. Ни на одной не сказано, что произойдёт, когда отчёт придёт вовремя, будет оформлен правильно и окажется пустым или неполным.
Случай этот не редкий и не связан с конкретным продуктом. У него есть отдельное название: смысловой сбой. Так называют поломку, при которой каждая часть системы отработала правильно, а сложенный из них результат неверен. Разбор этого класса поломок сделал Николай Илиев для Telerik в июне 2026 года: когда «всё в порядке» провал.
Асимметрия здесь доказуема. Производители самих моделей о границах пишут прямо.
Всегда проверяйте ответы GigaChat. В связи с тем, что ответы генерируются нейросетью, информация в них может быть неактуальна или искажена.
Компания Anthropic в своей документации по снижению выдумок говорит то же самое: приёмы снижают их число, но не убирают совсем, и критичное надо проверять всегда, особенно там, где на этом основано серьёзное решение. Документ открыт по адресу про снижение выдумок.
Тот, кто делает модель, предупреждает прямо и в документации. На пяти продуктовых страницах, которые я открывал, такое предупреждение нашлось на одной: fin-ctrl.ru пишет «...проверьте каждую до проводки». Одна из пяти, и это стоит засчитать в её пользу.
Где ИИ-агент в отчётности правда снимает работу
Признак задачи, которая агенту по зубам
Признак у разных источников описан одними и теми же словами. Работа должна быть частой, ограниченной правилами и языковой по сути, а у человека должна оставаться возможность поймать ошибку до отправки.
Разберём три случая, где это выполняется.
- Регулярный отчёт заранее известной формы. Не «проанализируй продажи», а «собери те же восемь цифр, что и в прошлый вторник, в тот же макет». Форма известна, отклонение видно глазом за секунды, ошибка ловится до того, как отчёт ушёл наверх.
- Поиск нужного среди готовых отчётов. У компании их десятки, руководителю неудобно ходить между ними. Здесь агент ничего не считает. Он ищет и показывает.
- Пересказ и комментарий к уже посчитанным числам. Сводка, объяснение отклонения, черновик комментария к рассылке. Это работа с языком, и модель здесь сильна по устройству. Проверить её дёшево, потому что цифры посчитаны не ею.
Команда Dalee Group описывает выигрыш второго случая так:
...пользователь получает доступ ко всей информации в одном диалоговом окне. Может запросить трактовку показателей, сравнение и тут же все визуализировать.
Есть и четвёртый выигрыш, менее заметный. Там же сказано, что аналитика перестают привлекать на каждый кастомный запрос менеджера. Экономия здесь в том, что специалиста не дёргают двадцать раз в день.
Отчёты - разминка, и это говорит сам продавец
И неожиданная деталь, которую честнее назвать сразу. В рейтинге задач для ИИ-агента, составленном компанией Sista AI, регулярная отчётность стоит на последнем, двенадцатом месте.
Оговорка там прямая: сама по себе такая работа прибыль не двигает, она нужна, чтобы собрать связку систем и доверие команды перед более серьёзными задачами. Обращаю внимание, кто это говорит: продавец агентов. Разбор доступен по адресу двенадцать задач для агента.
Три признака задачи, на которой вы заплатите дважды
Ответ нельзя проверить дешевле, чем посчитать заново
Это самый простой признак и самый пропускаемый. Если единственный способ убедиться в цифре агента состоит в том, чтобы получить её вторым способом целиком, вы платите за работу дважды.
Годится такая задача для сверки в пилотном месяце, но не для постоянной работы.
Показатель спорный внутри самой компании
Яна Доценко, продакт-менеджер, формулирует эту беду одной фразой: деловые показатели почти никогда не равны полям в таблицах. За словом «выручка» стоит договорённость о расчёте, которой в базе нет.
Если такой договорённости нет и у вас, машина выберет одну из версий молча. Разбор лежит по адресу про деловые показатели.
Вопрос задают один раз
Разовый разбор, который больше не повторится, обходится дороже, чем кажется. Настройка, описание показателей и приёмка стоят одинаково независимо от того, сколько раз задачу повторят потом.
Почему «запрос выполнился» - это не приёмка
Неверный запрос обычно не падает
Формулировка, которую стоит запомнить:
Most LLM-generated SQL doesn't fail. It runs and returns results, and that's exactly what makes it dangerous.
По-русски: запрос, написанный машиной, обычно не падает с ошибкой. Он выполняется и возвращает результат, и опасен именно этим.
Как выглядят такие ошибки на живых данных
Инженеры X5 Tech, ИТ-компании торговой группы X5, разбирали классы этих ошибок на своей проверке. Машина обращается к несуществующим таблицам и столбцам. Пишет запрос под одну базу данных, когда работает другая. Путает порядок операций и вложенность.
Отдельный класс у них назван ошибками времени выполнения: деление на ноль, несовпадение типов, пустые значения. Разбор лежит по адресу опыт X5 Tech.
Пять секунд и рапорт об успехе
Мой собственный случай того же рода. Один из моих роботов три утра подряд стартовал по расписанию и через пять секунд записывал в журнал «завершено успешно».
Работы при этом не было вовсе. В последнюю строку настроек попал невидимый служебный символ, и число перестало быть числом для проверки. Внутри системы отказ был записан честно, наружу ушёл успех. Простой нашли на третьи сутки, и нашли его глазами.
Что из этого следует для приёмки
Формулировка «отчёт собрался без ошибок» приёмку не заменяет. Приёмка начинается там, где кто-то сравнил число из отчёта с числом, полученным другим способом.
Нет такого сравнения ни у вас, ни у подрядчика, значит отчёт никто не принимал. Отсюда рабочее правило: у каждой строки отчёта должен быть второй способ получить то же число, и хотя бы раз в месяц кто-то обязан этим способом воспользоваться.
Пустой отчёт: почему он опаснее ошибки
Три формы, в которых приходит пустота
У этой поломки есть разобранная механика. В том же разборе для Telerik описаны три типовые формы, и все три встречаются в живой отчётности.
- Источник подсел и ответил пустотой вместо ошибки. Технически всё в порядке: запрос ушёл, ответ получен, ответ пустой. Машина делает вывод, что вариантов не существует.
- Часть источников не ответила вовремя. В ответе стоит пометка о неполноте, но её никто не смотрит, потому что итоговая таблица выглядит целой.
- Сработала промежуточная память, где лежало вчерашнее. Отчёт свежий на вид и построен на позавчерашних данных.
Свежий на вид отчёт по позавчерашним данным
Живой пример третьего рода обошёлся мне дешевле всего, потому что я поймал его случайно. Мой агент однажды собрал грамотную сводку по позавчерашним данным, когда свежие лежали в соседней папке.
Ошибки не было ни в одной строке. Просто отчёт отвечал на вопрос «что было позавчера», а читал я его как «что происходит сейчас».
Вывод для читателя простой. Пустая или подозрительно круглая строка в отчёте - это повод остановиться. Она означает «здесь нужно спросить, откуда взялось это ничего».
Откуда берётся разрыв между демонстрацией и вашими данными
Восемьдесят два процента и десять целых восемь
Числа тут стоит привести прямо, потому что они объясняют почти всё поведение рынка.
На эталонном наборе задач BIRD, по состоянию на 2 сентября 2026 года, лучшие системы держатся около 82 процентов верных ответов, а человек-специалист на том же наборе даёт 92,96 процента. Решение Сбера идёт пятым среди систем с результатом 81,33 процента. Отставание машины от человека оказывается свойством технологии, и российской бедой его назвать нельзя. Таблица открыта по адресу результаты BIRD.
Теперь тот же вопрос, заданный на настоящем корпоративном хранилище, то есть на живой базе работающей компании, которая росла годами и никем не причёсывалась. Исследование BEAVER взяло базы, где в среднем 101,5 таблицы и 869,4 столбца, и получило 10,8 процента верных ответов. С подсказками, где заранее разложены подзадачи, точность поднимается до 30,1 процента, и это всё равно в 2,7 раза меньше учебного результата.
Разница между двумя проверками в одной таблице
| Что сравниваем | Учебный набор BIRD | Настоящее корпоративное хранилище (BEAVER) |
|---|---|---|
| Верных ответов у лучших систем | около 82% | 10,8% |
| Верных ответов у человека-специалиста | 92,96% | проверка не проводилась |
| С подсказками, где разложены подзадачи | не применимо | 30,1% |
| Сколько таблиц в базе | десятки, схема описана | в среднем 101,5 таблицы, 869,4 столбца |
| Связи между таблицами | объявлены | чаще подразумеваются |
| Дата | таблица снята 02.09.2026 | ревизия работы 13.05.2026 |
Причину авторы называют там же, и она про данные:
Their schemas are often large, heterogeneous, and continuously evolving, containing hundreds or thousands of tables with cryptic column names and limited documentation. Join relationships are frequently implicit rather than explicitly declared.
Проще говоря: схема разрослась, имена столбцов понятны только своим, а связи между таблицами нигде не объявлены. Живут они в голове вашего аналитика.
Отсюда практический вывод, который дороже всех процентов: демонстрация на ваших данных - единственная демонстрация, которая что-то доказывает. Причём на десяти обычных вопросах, включая те, где вы заранее знаете верный ответ.
Почему чужой процент точности вам ничего не обещает
Одни и те же задачи, разный результат
Александр Полоротов в разборе на Хабре от 31 августа 2026 года формулирует это одной фразой: переносимой цифры точности у таких систем не существует. Дальше он приводит проверку, где одни и те же 180 задач на двух разных хранилищах дали 12,78 против 6,6 процента.
Менялся при этом только диалект языка запросов, то есть местные отличия в способе спрашивать базу. Разбор лежит по адресу снова хороним BI.
Даже эталонный набор знает о себе меньше, чем принято думать
Есть и более неудобная деталь. В работе, разбиравшей качество самой разметки популярных наборов задач, выяснилось, что больше половины правильных ответов размечены неверно: 62,8 процента в одном наборе. После перепроверки часть систем переехала в таблице на девять позиций.
То есть таблица, на которую ссылаются продавцы, знает о себе меньше, чем принято думать. Работа опубликована по адресу про качество разметки.
Что с этим делать на переговорах
Гэри Завалета в разборе для Towards Data Science идёт дальше и говорит, что даже 90 процентов точности для рабочей системы недостаточно: планка тут двоичная, инструмент либо работает, либо теряет доверие. Разбор лежит по адресу почему 90 процентов мало.
Когда вам называют процент, спрашивайте «на чём». Ответ «на публичном наборе задач» описывает чужую проверку. Ответ «на ваших двадцати вопросах, десять из которых вы придумали сами» описывает ваш будущий отчёт.
Три состояния, которые обязан различать сторож отчёта
Этому меня научили собственные роботы, и урок оказался самым дорогим из всех. Молчащий источник означает «состояние неизвестно», а зелёный свет из него не следует.
Проверка, которая при своей поломке пропускает работу дальше, проверкой не является. Она успокаивает ровно в тот момент, когда должна тревожить.
Два соседних правила, оба стоили времени
Ложная тревога дороже отсутствующей. Сторож, который кричит о поломке, когда всё работает, за неделю приучает не смотреть на красное, и в следующий раз настоящую беду пролистают вместе с ложной.
У инженеров Google это записано числом:
Alerts that are less than 50% accurate are broken.
По-русски: если сигнал верен меньше чем в половине случаев, он сломан и подлежит переделке.
Отчёт, который перестали читать, равен отсутствующему. У меня был честный сигнал, который два утра подряд кричал верное, и утонул. В те же полтора часа приходило пять или шесть других сообщений, одно из них длиной в восемьдесят тысяч знаков. Лечится это сокращением. Ещё один отчёт поверх делает только хуже.
Как отличить измеренное число от выведенного
Один вопрос к каждой строке
Проверять это можно одним вопросом: где именно лежит это число прямо сейчас и что будет, если я туда посмотрю?
- Ответ «в кабинете рекламы, вот такой отчёт, за такие даты» означает измеренное число.
- Ответ «оно посчитано по формуле из справочника настроек» означает выведенное. Оно может быть верным и полезным, но помечать его надо иначе.
- Ответа нет вовсе, значит строку из отчёта надо снимать.
Сходящийся итог не доказывает верность строк
Отдельная ловушка, на которую я попался сам. У меня была таблица, где главная колонка врала построчно в семь или пятнадцать раз, а суммарно случайно сходилась с правдой.
Дефекта не видел никто несколько недель. Итог сверяли, а строки читали глазами и верили.
Данила Ильичев из Диасофта приводит возражение, которым это кончается на масштабе компании:
...вместе со свободой компании могут получить сотни несогласованных отчетов, цифры с неясным происхождением и решения, принятые на основе галлюцинаций языковой модели.
И добавляет фразу, которая объясняет, чем это кончается для доверия к цифре: первое же сомнение, первый вопрос «а как это считалось», и доверие рушится.
Пять вопросов продавцу агента до оплаты
Сами вопросы
- Покажите работу на моих данных, на десяти моих вопросах, из которых пять придумаю я. Демонстрация на подготовленном наборе доказывает только то, что набор подготовлен.
- Что произойдёт, если источник данных подсядет посреди сборки отчёта? Покажите, как это выглядит. Правильный ответ звучит как «отчёт не выйдет и придёт предупреждение». Настораживающий: «отчёт выйдет с тем, что успело собраться».
- Кто и как узнает, что отчёт пришёл, а число в нём неверное? Здесь вы услышите, есть ли у подрядчика приёмка вообще или он считает приёмкой отсутствие ошибок.
- Откуда система берёт определение моих показателей? Если договорённости о расчёте нет и у вас, это ваша работа, и делать её надо до внедрения.
- Что эта система делать не должна? Вопрос звучит странно, и в этом его смысл. У человека, который правда строил такие системы, список готов и назван быстро.
С чего начать, если отчёты всё-таки нужны
Порядок первых шагов
- Выберите один регулярный отчёт, форму которого знаете наизусть. Не самый важный, а самый привычный.
- Соберите его руками за три прошлых периода и отложите. Это ваш образец, и он стоит дороже любых чужих процентов.
- Договоритесь, что считается верным ответом, и запишите это словами до начала работ. Особенно определения показателей.
- Запустите агента параллельно с живым процессом. Первый месяц уходит на сравнение, и полагаться на агента в этот месяц рано.
- Заранее назовите цену ошибки. Если ошибка в этом отчёте стоит меньше, чем месяц сравнения, автоматизировать его пока рано.
Почему модель не должна сама собирать запросы к базе
Про порядок работ есть замечание, которое стоит услышать до разговора о цене. Практики, строившие такие системы на своих данных, приходят к одному выводу.
...мы уверены, что нейросеть не должна генерить SQL. Это плохо контролируемый процесс, а вольности тут недопустимы.
SQL здесь - это язык, на котором программы спрашивают базу данных. Вместо того чтобы машина сочиняла такой запрос каждый раз заново, аналитик один раз описывает расчёт показателя, и дальше агент пользуется описанием. Их же вывод про пропорции работы: правильная инфраструктура даёт 90 процентов успеха.
Это лечит и главную причину провала на настоящих данных. Модели ломаются на том, что связи между вашими таблицами нигде не записаны. Описание показателей и есть то место, где они наконец оказываются записаны.
Что запомнить перед разговором о цене
Три вещи, которые стоит унести с собой
Первое. Отчёт, который никто не сверял со вторым источником, не принят, как бы он ни выглядел.
Второе. Требуйте, чтобы состояние «проверить не удалось» система называла отдельным словом. Пока оно неотличимо от «всё в порядке», спокойный экран не сообщает ровно ничего.
Третье. Начинайте с одного привычного отчёта и месяца параллельной работы. Это дешевле любого пилотного проекта и честнее любой демонстрации.
Если хотите пройти этот разбор по своим задачам, а не по чужим примерам, я это и делаю: смотрю, где в вашем деле машина снимет работу, а где принесёт пустую цифру, и говорю прямо, что из этого автоматизировать стоит, а что нет. Чем я занимаюсь.
Разберу по вашим задачам, где ИИ снимет работу, а где принесёт пустую цифру.
Посмотреть, чем я занимаюсьГарантий по срокам и результату в этой области не даёт ни один из источников, на которые я тут ссылаюсь. Того, кто их даёт, стоит слушать особенно внимательно.
Источники
- Kalai A. T., Nachum O., Vempala S. S., Zhang E. «Why Language Models Hallucinate», 04.09.2025: arxiv.org/abs/2509.04664
- BEAVER: Chen P. B., Wenz F., Tatbul N. и др., arXiv:2409.02038v3, ревизия 13.05.2026: arxiv.org/html/2409.02038v3
- Таблица результатов BIRD-bench, снята 02.09.2026: bird-bench.github.io/
- Качество разметки эталонных наборов, arXiv:2601.08778, январь 2026: arxiv.org/abs/2601.08778
- Полоротов А. «Снова хороним BI», Хабр, 31.08.2026: habr.com/ru/articles/1075946/
- Ильичев Д., Диасофт, Хабр, 28.08.2026: habr.com/ru/companies/diasoft_company/articles/1075918/
- Куляскин М., X5 Tech, Хабр, 23.09.2025: habr.com/ru/companies/X5Tech/articles/949694/
- Dalee Group, Хабр, о семантическом слое вместо генерации запросов: habr.com/ru/companies/dalee_group/articles/1051832/
- Доценко Я. о деловых показателях и полях таблиц, Хабр: habr.com/ru/articles/1009224/
- Zavaleta G. «Why 90% Accuracy in Text-to-SQL is 100% Useless», Towards Data Science, 12.01.2026: towardsdatascience.com/why-90-accuracy-in-text-to-sql-is-100-useless/
- Iliev N. «When Status OK Is Still a Failure», Telerik, 18.06.2026: www.telerik.com/blogs/when-status-ok-still-failure-taxonomy-silent-ai-agent-breakage-how-detect
- Readyset, «Why LLMs Write Incorrect SQL»: readyset.io/blog/why-llms-write-incorrect-sql-and-what-that-means-for-your-database
- Sista AI, рейтинг задач для ИИ-агента в бэк-офисе: sista.ai/en/insights/back-office-ai-agent-use-cases
- Ewaschuk R. «My Philosophy on Alerting», Google SRE: docs.google.com/document/d/199PqyG3UsyXlwieHaqbGiWVa8eMWi8zzAn0YfcApr8Q/preview
- Документация GigaChat, Сбер, раздел ограничений: developers.sber.ru/docs/ru/gigachat/limitations
- Anthropic, документация «Reduce hallucinations»: platform.claude.com/docs/en/test-and-evaluate/strengthen-guardrails/reduce-hallucinations
- MWS Data Copilot, страница продукта, обещания и оговорки: mws.ru/data/mws-data-copilot/
- Случай с пятью секундами и случай с позавчерашними данными - наши собственные данные из журнала запусков моих роботов, записаны 02.09.2026
