Что произошло

Румынская i-Tom Solutions развивает FGO — SaaS-платформу для выставления счетов, бухгалтерских интеграций и связанных финансовых операций малого бизнеса. По опубликованному AWS кейсу, рост сервиса довёл поток письменных обращений поддержки до 200–600 в день. В эту очередь попадали и короткие вопросы, и запросы, требующие технического разбора. Команда искала способ отвечать на типовые вопросы быстрее и не терять обращения вне рабочего времени.

Вместо универсального чат-бота компания выбрала узкую задачу: ассистент должен отвечать, опираясь на централизованную базу знаний FGO. Для этого собрали RAG-контур — поиск релевантных фрагментов документации перед генерацией ответа. В опубликованной архитектуре упомянуты Amazon Bedrock для работы с моделями, OpenSearch для семантического поиска и Lambda для обработки документов.

Пилот занял четыре–пять недель. После него проверенную инфраструктуру развернули в производственной среде за одну неделю с помощью шаблонов infrastructure as code. На момент описания ассистент работал в контролируемом продакшене с выбранными клиентами: команда наблюдала за точностью и дорабатывала систему. По заявлению поставщика кейса, ассистент уже обрабатывал сотни обращений в день.

Это важная оговорка. «Контролируемый продакшен» здесь не означает, что модель получила право автономно решать любые проблемы клиента. Это ограниченный режим, в котором реальный трафик сочетается с наблюдением, измерением ошибок и возможностью передать сложный случай человеку.

Что подтверждено, а чего в кейсе нет

Из источника можно уверенно вынести несколько фактов:

  • исходный поток составлял от 200 до 600 письменных обращений в день;
  • первой бизнес-целью были ответы вне рабочего времени;
  • ассистент использовал централизованную базу знаний и RAG;
  • пилот занял четыре–пять недель, производственное развёртывание после пилота — одну неделю;
  • запуск проводился для выбранных клиентов с мониторингом точности;
  • в архитектуре использовались Bedrock, OpenSearch и Lambda.

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

Для руководителя это полезный пример редакционной дисциплины. Кейс показывает жизнеспособный процесс внедрения, но не даёт готовой модели окупаемости. Собственную экономику придётся измерять на своих данных.

Переносимая архитектура для малого SaaS

Из кейса можно собрать нейтральный шаблон, не привязанный к конкретному облаку.

1. Обращение приходит из почты, формы или чата и получает идентификатор, канал, язык и временную метку.
2. До модели выполняются правила: проверка клиента, удаление лишних персональных данных, определение темы и риска.
3. По теме запроса поиск извлекает несколько фрагментов из утверждённой базы знаний вместе с источником, версией и датой обновления.
4. Модель формирует проект ответа только на основании найденного контекста и указывает использованные источники.
5. Политика публикации решает, можно ли отправить ответ автоматически. Низкая уверенность, отсутствие источника, финансовые изменения, спорные операции и признаки инцидента направляются сотруднику.
6. В журнал пишутся запрос, найденные документы, версия промпта и модели, решение политики, правки сотрудника и итог обращения.

Облачный вариант может использовать управляемую модель и поисковый сервис. Локальный вариант строится на локально развёрнутой LLM, векторной базе и собственном шлюзе. Гибридный вариант оставляет документы и поиск внутри контура, а во внешний API отправляет только минимальный обезличенный контекст. Бизнес-логика, тестовый набор и правила эскалации нужны во всех трёх случаях.

Какие данные придётся подготовить

RAG не исправляет плохую базу знаний. До пилота полезно разделить материалы на четыре слоя:

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

Каждый документ должен иметь владельца, дату актуальности, область действия и правило удаления. Для финансового SaaS особенно важно понимать, какие данные попадают к субпроцессорам. FGO публикует отдельный список: базовый контур размещён в регионе AWS Frankfurt, Bedrock указан как внутренний виртуальный ассистент, а для AI-сервисов заявлены настройки, исключающие использование данных операторов для обучения моделей. Это заявление самой компании, и при переносе практики его следует заменять собственной договорной и технической проверкой.

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

Как измерять качество до автосенда

Документация AWS по оценке RAG предлагает проверять отдельно качество извлечения и качество сгенерированного ответа, используя набор запросов с эталонными фрагментами и ответами. Это полезнее одной средней оценки «нравится / не нравится».

Для пилота достаточно семи показателей:

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

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

Экономика: считать закрытый вопрос

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

Практичная единица — стоимость принятого ответа или закрытого типового обращения:

`(инфраструктура + модель + поиск + сопровождение + минуты сотрудников) / число принятых ответов`.

Рядом следует считать долю повторных обращений по той же теме. Если бот отвечает быстро, но клиент возвращается, экономия иллюзорна. Сравнивайте не «до и после AI» вообще, а одинаковые категории вопросов за одинаковый период.

Следующий шаг на 30 дней

Малому SaaS не нужен сразу круглосуточный автономный оператор. Разумный пилот можно ограничить одной категорией, например вопросами по настройке интеграции или навигации в интерфейсе.

  • Неделя 1: выбрать 100–200 реальных обезличенных вопросов, привести в порядок документы и назначить владельцев.
  • Неделя 2: собрать поиск и режим черновиков без автосенда.
  • Неделя 3: измерить извлечение, подтверждённость, правки и эскалации; исправить документы, а не только промпт.
  • Неделя 4: разрешить автосенд лишь для низкорисковой категории и небольшого процента трафика, сохранив мгновенную передачу человеку.

Условие продолжения пилота задаётся заранее: например, ноль критических утечек, высокий процент ответов с корректным источником и снижение времени оператора на принятый ответ. Если условие не выполнено, проект остаётся помощником сотрудника. Это не поражение: качественный черновик с источниками часто приносит бизнесу больше пользы, чем поспешная автономность.

Вывод для руководителя

Кейс i-Tom/FGO показывает правильную последовательность: узкая цель, база знаний, короткий пилот, воспроизводимое развёртывание и ограниченный реальный трафик под наблюдением. Самый ценный элемент — не конкретный сервис, а контролируемый переход между стадиями.

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