Короткий вывод

Резюмирование длинной переписки — один из тех сценариев, где генеративный ИИ может дать измеримый эффект без права самостоятельно принимать рискованные решения. Немецкая SaaS-компания Epilot встроила такую функцию в систему для энергетических компаний: по опубликованному AWS кейсу, пользователи экономят 87% времени на разборе email-цепочек, а сервис формирует около 55 000 сводок в месяц.

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

Какую работу автоматизировали

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

Вместо универсального «агента по почте» компания выбрала узкую функцию: по запросу сотрудника прочитать цепочку и выдать несколько ключевых пунктов. Это снижает риск по двум причинам:

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

По данным кейса AWS, эксперимент начался в декабре 2023 года. Команда провела пользовательское исследование, а MVP вывела примерно за два месяца. Перед production специалисты продукта и инженеры сравнивали модели и варианты инструкций в human-based evaluation: люди оценивали ответы на разных email-цепочках по заранее определённым критериям. В результате для функции выбрали Claude Sonnet через Amazon Bedrock.

AWS и Epilot сообщают, что около 80% пользователей считают функцию полезной, а экономия времени достигает 87%. Формулировка важна: это заявленный результат конкретного продукта и конкретной аудитории, не независимый отраслевой бенчмарк.

Архитектура: почему между почтой и моделью нужна очередь

В описанном решении API принимает запрос на сводку и помещает задание в Amazon SQS. Событие из очереди запускает AWS Lambda, которая оркестрирует вызов модели в Bedrock. Такая асинхронная схема отделяет пользовательский интерфейс от инференса: всплеск запросов не обязан одновременно создавать столько же прямых соединений с моделью.

Для собственного или локального контура названия компонентов могут быть другими, но роли остаются теми же:

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

Очередь не гарантирует «ровно один раз». Документация AWS для связки Lambda и SQS прямо предупреждает, что событие может быть обработано повторно. Поэтому воркер должен быть идемпотентным: повтор того же задания не создаёт вторую сводку, не удваивает запись в CRM и тем более не повторяет действие. Практический ключ можно строить из идентификатора цепочки, её последней версии и типа операции.

Что должна содержать хорошая сводка

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

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

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

Данные и безопасность

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

Минимальный набор мер:

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

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

Локальная модель уместна, если письма нельзя выводить за защищённый контур, нагрузка достаточно стабильна или требуется полный контроль журналов. Но локальность сама по себе не решает права доступа, удаление данных и качество сводки. Облачный API может быстрее дать пилот, а локальный контур — больше контроля; выбор стоит делать после классификации данных и измерения объёма, а не по лозунгу.

Как проверить качество до production

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

Оценивайте минимум пять показателей:

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

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

Полезен теневой режим: система строит сводки, но сотрудник продолжает работать привычно и сравнивает результат. После этого можно включить кнопку «принять сводку», затем — подготовку черновика действия. Автоматическое изменение данных следует рассматривать отдельно и оставлять подтверждение человеку, как это делает Epilot для своей функции suggested actions.

Экономика пилота

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

**экономия = число цепочек × минуты до автоматизации − число цепочек × минуты проверки после автоматизации**, умноженные на стоимость рабочего часа, минус инфраструктура, разработка, поддержка и цена исправления ошибок.

Допустим, команда разбирает 4 000 цепочек в месяц, тратит в среднем шесть минут на каждую, а проверка сводки занимает две минуты. Теоретически высвобождается около 267 часов. Это модельный расчёт: его нужно уменьшить на долю непригодных сводок, повторную обработку, контроль качества и время эксплуатации.

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

Практический следующий шаг

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

Главный вывод кейса Epilot — не «модель читает почту в 87% быстрее». Полезнее последовательность: узкая задача, асинхронная архитектура, человеческая оценка на реальных данных, прозрачные ограничения и только затем расширение полномочий. Именно такой порядок превращает эффектную демонстрацию в управляемый бизнес-инструмент.