ИИ-агент, который собирает отчёт по выручке голосом

Агент — витрина, а не источник цифр

Первое, что я закладываю в такого агента: он не хранит и не «помнит» цифры выручки. Он умеет только одно — превратить вопрос в запрос к уже существующему хранилищу и вернуть ответ на человеческом языке. Источник один и тот же, что для собственника с телефона, что для маркетолога в Roistat: ClickHouse, куда стекаются данные из amoCRM, рекламных кабинетов и звонков, либо API Roistat и Yandex DataLens напрямую.

Это принципиальная развилка. Можно сделать бота, который отвечает из общих знаний модели о бизнесе — тогда он рано или поздно начнёт подставлять правдоподобные, но неверные цифры, потому что языковая модель по устройству генерирует наиболее вероятный текст, а не факт. А можно подключить агента к реальному хранилищу через function calling: модель не считает выручку сама, она формирует параметры запроса (диапазон дат, канал, метрика), запрос уходит в ClickHouse или в API Roistat, а в ответ агент получает число и уже его пересказывает. Ошибиться в арифметике агент физически не может — он не считает, он спрашивает у того же источника, на который смотрит аналитик в DataLens.

Я собираю такие агенты как надстройку над тем, что уже строю в рамках ИИ-агентов — сама сквозная аналитика не заменяется, а получает голосовой интерфейс поверх готовых витрин.

Как агент понимает вопрос

Вопрос «сколько заявок за неделю по каналам» — это не свободный текст, который агент интерпретирует «на глаз». Я развожу два слоя. Первый — распознавание намерения и сущностей: период (неделя, месяц, конкретные даты), метрика (заявки, выручка, ROMI, средний чек), срез (канал, менеджер, воронка amoCRM). Второй — маппинг этих сущностей на конкретный SQL-запрос к ClickHouse или на вызов метода API Roistat с нужными фильтрами. Модель не изобретает структуру запроса каждый раз заново — она выбирает из набора заранее описанных функций с параметрами, а дальше я контролирую, какие поля и агрегации вообще доступны агенту.

Это отличается от того, что делают конструкторы на no-code — там сценарий диалога жёстко прописан заранее, любое отклонение от формулировки ломает бота. Здесь модель понимает вариации формулировки («сколько денег занесли», «какая выручка», «сколько заплатили клиенты» — один и тот же запрос), но диапазон возможных запросов ограничен схемой данных, которую я закладываю в описание функций. Агент не может «на всякий случай» придумать метрику, которой нет в хранилище — он либо находит подходящую функцию, либо честно отвечает, что такого среза нет.

Где агент врёт и как это выключить

Главный риск голосового агента над бизнес-данными — не грубость ответа, а тихая уверенная ошибка. Модель может смешать период («за неделю» интерпретировать как календарную, а не скользящую), перепутать метрику (выручка вместо оплаченной выручки), или, если доступ к данным настроен небрежно, вообще ответить из общих рассуждений, когда запрос к хранилищу не удался. Антипаттерн, который я вижу у самодельных ботов на n8n или Zapier с накрученным чат-GPT-промптом сверху: агент дёргает какой-то отчёт один раз, кэширует ответ в переменной сценария и потом отвечает по памяти, даже когда данные в CRM давно изменились. Внешне выглядит как рабочий бот, по факту — генератор неактуальных цифр с уверенным тоном.

Рабочая схема требует, чтобы каждый ответ агента шёл через живой запрос к источнику в момент вопроса, без кэша с истёкшим сроком жизни, и чтобы при сбое запроса агент прямо говорил «не смог получить данные», а не подставлял правдоподобное число. Я также логирую пару «вопрос — сгенерированный запрос — ответ», чтобы можно было свериться вручную, если цифра выглядит подозрительно — это тот же принцип, что я закладываю в саму сквозную аналитику: любая цифра должна быть прослеживаема до сделки в amoCRM или до звонка в Roistat, а не существовать сама по себе в дашборде.

РФ-контур и связка с CRM

Для голосового агента над финансовыми данными вопрос модели — это ещё и вопрос 152-ФЗ. Я собираю такие агенты на моделях, которые можно развернуть в российском контуре или у которых есть RU-совместимый API — YandexGPT, GigaChat, либо self-hosted модель на своём сервере, а не зарубежный API, куда улетают выписки по выручке компании. Данные при этом никуда не покидают ту же инфраструктуру, где уже стоит ClickHouse и куда льётся amoCRM — агент не создаёт новый канал утечки, он читает то, что и так лежит в РФ.

Практическая ценность такого агента не в новизне интерфейса, а в том, что он снимает разрыв между «аналитика есть» и «в неё смотрят». Дашборд с двадцатью виджетами открывают раз в квартал перед советом директоров. Вопрос голосом в мессенджере — раз в день, между делом. Обе формы читают одни и те же цифры из одного и того же хранилища, поэтому расхождений между ними быть не может по конструкции, а не по договорённости.