Почему обычного чат-бота было мало

i‑Tom Solutions обслуживает платформу FGO для выставления счетов и смежных бухгалтерских процессов. По опубликованному AWS разбору, у сервиса более 170 тысяч клиентов из малого и среднего бизнеса, а ежедневно поступало от 200 до 600 письменных запросов. Часть вопросов повторялась, но другие требовали технической проверки или разбора конкретной ситуации клиента. Когда специалисты заняты одинаковыми объяснениями, сложные обращения ждут в той же очереди.

Первая цель компании была узкой: отвечать на типовые вопросы вне рабочего времени. Это важная граница проекта. Помощник не должен изображать бухгалтера, менять данные счёта или выдавать персональный диагноз по одному сообщению. Он должен найти актуальную инструкцию, сформулировать ответ и передать сложный случай человеку.

AWS описывает этот проект как собственный клиентский кейс, а не как независимый аудит. Поэтому цифры ниже — сведения компании и поставщика инфраструктуры; открытого набора обращений и протокола оценки точности нет.

Иначе бот может очень вежливо отработать ночную смену — и оставить утреннюю смену разгребать последствия.

Что собрали и как запускали

Команда i‑Tom вместе с архитекторами AWS и партнёром Auvaria сделала прототип за четыре–пять недель. Основой стал RAG: поиск по централизованной базе знаний, затем генерация ответа на найденном контексте. В опубликованной архитектуре названы Amazon Bedrock для генерации, AWS Lambda для обработки документов и Amazon OpenSearch Service для семантического поиска. После прототипа проверенную конфигурацию развернули в продакшене за одну неделю с помощью шаблонов инфраструктуры.

Здесь важна последовательность, а не конкретная облачная марка:

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

Сейчас помощник, по описанию AWS, находится в ограниченном продакшен-пилоте для выбранных клиентов. Компания сообщает, что он обрабатывает сотни обращений в день. Из текста нельзя вывести, что все эти обращения закрываются без участия человека, что 600 запросов — постоянная нагрузка или что система полностью покрыла поддержку.

Как перенести подход в российский бизнес

Для внедрения внутри российского контура не требуется повторять стек AWS. Те же роли можно закрыть своим парсером документов, поисковым индексом и локально развёрнутой моделью. Но «локально» не означает «автоматически безопасно»: нужно проверить права на документы, маршруты персональных и коммерческих данных, сроки хранения переписки и доступ операторов. Выбор модели и железа делается после измерения фактического потока и качества ответов на русском языке.

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

Минимальный технический контур состоит из входящей очереди, классификации намерения, поиска с учётом прав доступа, генерации черновика с ссылкой на документ, правил эскалации, журнала решений и экрана оператора. CRM или тикет-система должны оставаться системой учёта обращения. Модель не должна получать прямое право менять финансовые записи. Для круглосуточного режима также нужны мониторинг, ограничение нагрузки и резервный маршрут, когда модель или индекс недоступны.

Экономика: считать не сообщения, а безопасно решённые вопросы

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

**Полные месячные затраты / число вопросов, которые помощник правильно разрешил без доработки и без повторного обращения.**

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

Модельный расчёт для выбора пилота: если за месяц поступает 6 000 письменных запросов, из них 40% — типовые, а 70% типовых ответов проходят проверку, то потенциально без доработки закрываются 1 680 запросов. Это не результат i‑Tom и не прогноз для другой компании: доли нужно измерить на своих обращениях. При 100 тысячах рублей совокупных ежемесячных расходов условная стоимость такого ответа — около 60 рублей. Сравнивать её следует со стоимостью обработки сопоставимого вопроса человеком и с ценой ошибки.

Что проверить до расширения

Соберите 100–200 обезличенных реальных вопросов, включая неоднозначные и те, на которые отвечать нельзя. Для каждого зафиксируйте правильный источник, допустимый ответ и условие передачи оператору. Затем запустите помощника в теневом режиме: он предлагает ответ, но клиент видит только проверенное человеком сообщение. Сверяйте точность, полноту ссылок на документы, ложные уверенные ответы, время до решения и повторные обращения. Документация AWS по оценке RAG отдельно предусматривает проверку покрытия и точности цитат; эти метрики полезны независимо от платформы.

Следующий шаг для руководителя — выбрать одну категорию типовых вопросов, назначить владельца базы знаний и согласовать порог, после которого автоматический ответ отключается. Если на тесте не удаётся подтвердить пользу с учётом исправлений, расширять канал рано. В истории i‑Tom главный урок именно в этом: рабочий помощник появился после ограниченного прототипа и контролируемого запуска, а не после покупки «универсального ИИ».