ИТ-контур поддержки Росмолодёжи. Три контура, одна цель: чтобы больше вопросов закрывалось без оператора, а база знаний обновлялась не вручную, а по данным.
Собственная разработка. С 14 июля в проде — полностью заменил операторов в ручной разметке: сам определяет тему (иерархия из 100+ тем) и мероприятие (справочник из 101 позиции) для всех входящих обращений, текстовых и голосовых. Операторы лишь помогают и контролируют процесс.
Несёт нагрузку сегодня: около 6 000 обращений в месяц. Работающая система, которую продолжаем развивать: мониторинг качества, чистка базы ответов, тестирование гипотез.
Доказана вся цепочка: вопрос пользователя → поиск по базе знаний → ответ → доставка в VK → аналитика. Ядро работает, идёт калибровка качества перед пилотом.
Сильную сторону действующей платформы стоит назвать прямо: бот обкатан на реальном потоке данных, и внутри него — множество слоёв и слотов, которые команда наполняла около полугода.
Но каждое новое мероприятие, исключение или непривычная формулировка требует ручного расширения дерева. Чем больше форумов, тем дороже и нестабильнее поддержка такой схемы.
Второе ограничение важнее первого. LLM- и RAG-механизмы ChatMe находятся на стадии MVP — это экспериментальная надстройка над сценарным конструктором, а не промышленный AI-продукт. Нет прозрачного управления источниками, устойчивой проверки фактов, фиксации использованных документов и предсказуемой логики эскалации.
Отдельно: исправления на внешней платформе зависят от поставщика. Технические проблемы держались около трёх дней, и команда не могла устранить причину самостоятельно.
Каждый элемент нужен остальным. Каждое обращение — не только задача поддержки, но и источник улучшения всей системы.
каждый ответ фиксируется: источники, результат, был ли нужен оператор
каждое обращение с темой и итогом ложится в базу данных
какие вопросы повторяются, где бот не справился, по каким темам зовут человека
в базе нет информации / информация устарела / информация есть, но бот её не нашёл
какая тема, сколько обращений, каких фактов не хватает
привычный рабочий инструмент — ничего нового осваивать не нужно
одним управляемым действием, с автоматической проверкой на контрольных вопросах
и цикл повторяется на новых данных
Всё остальное производно и обновляется автоматически. Бот имеет к Yonote доступ только на чтение и не может ничего изменить самостоятельно. Новые факты всегда проходят через человека.
Автономная разметка обоих каналов. Точность определения категории: голос ~85%, текст ~76%. Точность подтемы: ~56% на обоих каналах — строгая автоматическая сверка с правками операторов. Ранее публиковавшиеся 87% отражали долю обращений без корректировок операторов; метрика заменена на прямую сверку как более честную. 918 обращений с 14 по 24 июля без ручного вмешательства — 505 текстовых и 413 голосовых.
Голосовая линия была слепым пятном — тикеты приходили пустыми, статистики не было вообще. Сейчас работает полная цепочка: звонок → расшифровка → обезличивание персональных данных → классификация → запись в систему. Исправлена обработка исходящих звонков, которые ранее терялись. Бот определяет мероприятие прямо по тексту разговора, включая разговорные сокращения.
Правки операторов собираются автоматически на голосовой линии — бот учится на реальной разметке без дополнительной работы людей; включение того же сбора на текстовом канале — ближайший шаг, одна правка конфигурации. Обучающая и проверочная выборки разделены, поэтому результат не завышен. Эталонная база пополняется ежедневно, цель — 400–500 размеченных примеров. Ручную разметку операторов бот не перезаписывает: заполняет только пустые поля.
Решения принимаются на замерах, а не на предположениях. Замена системы распознавания речи — теряет фрагменты разговора и не разделяет реплики. Более крупная языковая модель — точность ниже текущей. Двухступенчатая классификация и динамический подбор примеров — обе схемы хуже действующей.
Форумная линейка выросла быстрее, чем обновлялась база. В отдельных сценариях осталась устаревшая, дублирующаяся или недостаточно подтверждённая информация — бот мог смешивать разные мероприятия или отвечать по уже завершённым.
Сформирован перечень проблемных ответов, техническое задание на очистку передано в работу. Параллельно идёт постоянный мониторинг: где бот отвечает слишком общо, где сценарии пересекаются, какие ветки нужно удалить или заменить.
Отдельный сервис-помощник, который автоматически отслеживает базу Yonote и сообщает, какие форумы закрываются. Это снимает ручную работу по контролю сроков и убирает риск, что бот продолжит выдавать информацию по завершённому мероприятию.
Сезонность. Форумная линейка идёт волнами, и вопросы предсказуемы: за две недели до старта спрашивают про регистрацию, за неделю — про документы и проезд, во время события — про логистику. Значит, базу можно готовить заранее, а не догонять поток.
Работает вся цепочка целиком: обращение из VK через HelpDeskEddy → поиск в базе знаний → формирование ответа → доставка пользователю → сохранение аналитики. Проверены сценарии: обычный вопрос, продолжение диалога с уточнением, просьба позвать оператора, вопрос вне тематики. Бот держит контекст обращения, а не рассматривает каждое сообщение отдельно.
Бот не придумывает факты. Сначала ищет подтверждённую информацию в базе — более двух тысяч опубликованных фрагментов по мероприятиям, форумам, ФГАИС, грантам. Если подтверждённых данных нет — уточняет вопрос, сообщает об отсутствии информации или передаёт обращение специалисту. Это важнее, чем отвечать на любой вопрос любой ценой.
Используются две внутренние модели GigaChat через российскую платформу Cloud.ru: быстрая и экономичная — для типовых вопросов, более мощная — для сложных и составных. При нагрузке около 6 000 обращений в месяц предварительный общий бюджет эксплуатации оценивается в диапазоне 3–13 тыс. ₽ в месяц. Итоговая стоимость зависит от длины диалогов, доли сложных запросов, использования мощной модели и расходов на серверную инфраструктуру. Точная оценка будет подтверждена после первого полного месяца пилотной эксплуатации. По результатам текущих испытаний расходы на сами AI-модели находятся ближе к нижней границе диапазона: типовые вопросы обрабатываются без дорогостоящей модели. (При необходимости можно протестировать и более мощные модели и отдельно просчитать их экономику — например, флагманский GigaChat 3.5 Ultra на 432 млрд параметров, доступный в Cloud.ru с июля 2026: 96 ₽ за млн входных и 289 ₽ за млн выходных токенов; даже при обработке всего потока на нём оценочные расходы на модель — порядка 1,5–3 тыс. ₽ в месяц.)
Функционирует админ-панель: база знаний, источники, отчёты, проблемные темы, контрольные вопросы, связь с Yonote. По каждому обращению сохраняется полный технический след — тема, источники, нужен ли оператор, время обработки, использованная модель и её стоимость.
Параллельно с калибровкой сравниваю собственное ядро с готовыми self-hosted платформами (Dify, Flowise, RAGFlow) на нашей же базе знаний и реальных запросах. Критерии — качество ответов, управляемость (встраивание деперсонализации ПДн и интеграции с HDE) и стоимость поддержки. Итог — обоснованное решение: развивать собственное ядро или встать на готовую платформу. Специфичная логика — маскирование ПДн, HDE, каскад моделей — переиспользуется в любом случае.
Это MVP. Цепочка доказана, качество ответов — в работе. Дата замены действующего бота не назначается: переход произойдёт по критериям, а не по календарю.
Инфраструктура пересобрана полностью: свежая операционная система, новые контейнеры, базы данных, ключи, пароли и сертификаты.
Персональные данные. Приложение, база знаний, история работы и поисковый индекс находятся в нашем контуре. В облачную модель уходит только минимально необходимый контекст запроса, персональные данные предварительно маскируются.
Дальше. Безопасность — не разовая проверка. Готовится техническое задание на внешний независимый аудит серверного контура. Мониторинг активности ведётся ежедневно.
Отдельная задача: научиться инициировать общение — поздравления, уведомления о мероприятиях — по своей аудитории, законно и без переплаты за чужой шлюз.
Действующая платформа тарифицирует каждое исходящее сообщение — до 11 ₽ через MAX-рассылку, — и писать можно только тем, кто обратился в текущем периоде. При росте аудитории и регулярных рассылках это дорого и негибко.
Исходящую коммуникацию выносим из-под ChatMe и отправляем напрямую через официальный механизм рассылок MAX — ту же интеграцию по API, на которой уже построен бот. Стоимость с нашей стороны близка к нулю: для рассылки готовым утверждённым текстом модель почти не используется, остаётся только тариф самого канала.
Фундамент, без которого рассылка невозможна по 152-ФЗ. Бот собирает согласие прямо в диалоге — кнопкой в подходящий момент, без ручной работы. Храним по каждому пользователю статус согласия (дано / отозвано), канал, дату и критерии: когда обращался, по каким темам, из какого канала.
Раз известны темы, канал, давность обращения и статус согласия — формируем любые срезы аудитории и рассылаем только по тем, кто согласие подтвердил. Отдельно от ответов на обращения: ответ — реакция на входящее, рассылка — по сегменту с подтверждённым согласием, с отпиской и аудитом отправок.
Бот уже подключён к каналам по API и уже хранит по каждому обращению тему, канал и историю. Модуль согласий и рассылок ложится поверх существующей архитектуры. Для отправки в MAX есть и готовые открытые решения — это упрощает задачу.
Что уточняем. Точные тарифы, лимиты и правила рассылок MAX (частотные ограничения, верификация сообщества, сервисные и рекламные типы сообщений). Подтвердим по документации, прежде чем закладывать в план.
Новая архитектура получает трафик только тогда, когда на одинаковой выборке реальных обращений покажет:
До выполнения этих условий действующий бот остаётся в продакшене и продолжает развиваться. Перенос трафика — поэтапный, с возможностью вернуться назад.
Показатели точности ниже — про бота-анализатора, систему разметки обращений. Метрика конверсии — про основной чат-бот в ВК и MAX. Это два разных продукта.
Насколько верно определяется направление обращения: мероприятия, гранты, техническая поддержка. Практический показатель — именно категории используются в аналитике и маршрутизации. Текстовый канал временно отстаёт: правки последней недели вносились только в голосовой промпт; после их переноса ожидание по тексту — 83–85%.
Насколько точно бот совпадает с детальной разметкой оператора — строгая автоматическая сверка; оба канала сошлись на одном уровне. Ранее публиковавшиеся 87% отражали долю обращений без корректировок операторов; метрика заменена на прямую сверку как более честную. Оба показателя измеряются автоматически, обучающая и проверочная выборки разделены.
Действующая метрика показывает 47,6% за июнь. Но правило подсчёта в HelpDeskEddy засчитывает как успешно закрытое ботом любое обращение, завершённое без оператора — включая те, где пользователь написал приветствие и ушёл, не задав вопроса. Такие обращения не отражают реальную работу бота.
Это значит, что фактическая доля содержательных вопросов, закрытых ботом самостоятельно, ниже. Точную величину мы намеренно не оцениваем на глаз: в ближайший месяц вводится единая методика замера по содержательным обращениям и снимается честный базовый показатель. Дальнейший прогресс будет считаться от него.
Одновременно фиксируем качественную проблему: бот периодически даёт неточные ответы даже на типовые запросы. При сценарной архитектуре каждый такой случай закрывается ручной правкой конкретной ветки — системного решения здесь нет.
Всё, что описано выше, работает на её рост — от честного базового замера.
Около 9% обращений в проверочной выборке размечены операторами спорно или ошибочно — например, звонок без содержательного разговора помечен как организационный вопрос. Без формальных определений спорных пар потолок по подтемам — около 75%: одинаковые обращения размечаются вразнобой. Решается согласованием правил разметки с методологами.
Часть подтем разграничена нечётко, поэтому одинаковые обращения разные операторы размечают по-разному. Нужны формальные определения — тогда единообразие вырастет и у бота, и у людей.
Расшифровки телефонных разговоров содержат искажения, ограничивающие точность на голосовом канале. Частично компенсировано автоматической коррекцией терминов и названий систем.
Анализатор найдёт пробелы быстрее, чем их успеют закрыть. Полезность системы зависит от того, насколько быстро подтверждаются факты и обновляется Yonote.
Разработка и сопровождение контура сегодня держатся на одном человеке. Снимается подключением второго исполнителя к задачам тестирования и разработки и внешним аудитом инфраструктуры.
Система учится не на персональных данных пользователей, а на выявленных и подтверждённых пробелах в знаниях. Каждый новый факт проходит через человека, Yonote и контроль качества.
За первый месяц создан фундамент. Следующие полгода превратят его в устойчивый продукт, который снижает нагрузку на операторов, улучшает качество информации и даёт руководству понятную картину реальных потребностей пользователей.
Задать вопрос Артёму