ИТ-контур поддержки Росмолодёжи. Три контура, одна цель: чтобы больше вопросов закрывалось без оператора, а база знаний обновлялась не вручную, а по данным.
Собственная разработка. С 14 июля автономно определяет тему и мероприятие для всех входящих обращений — текстовых и голосовых. Снял с операторов ручную разметку по иерархии из 100+ тем и справочнику из 101 мероприятия.
Несёт нагрузку сегодня: около 6 000 обращений в месяц. Работающая система, которую мы продолжаем развивать, а не сворачиваем — идёт мониторинг качества и чистка базы ответов.
Доказана вся цепочка: вопрос пользователя → поиск по базе знаний → ответ → доставка в VK → аналитика. Ядро работает, идёт калибровка качества перед пилотом.
Сильную сторону действующей платформы стоит назвать прямо: NLU-логика ChatMe сделана качественно, а сам бот обкатан на реальном потоке. Именно поэтому он остаётся в проде и продолжает работать.
Но каждое новое мероприятие, исключение или непривычная формулировка требует ручного расширения дерева. Чем больше форумов, тем дороже и нестабильнее поддержка такой схемы.
Второе ограничение важнее первого. LLM- и RAG-механизмы ChatMe находятся на стадии MVP — это экспериментальная надстройка над сценарным конструктором, а не промышленный AI-продукт. Нет прозрачного управления источниками, устойчивой проверки фактов, фиксации использованных документов и предсказуемой логики эскалации. Для государственной поддержки федерального масштаба этого недостаточно.
Отдельно: исправления на внешней платформе зависят от поставщика. Технические проблемы держались около трёх дней, и команда не могла устранить причину самостоятельно.
Каждый элемент нужен остальным. Каждое обращение — не только задача поддержки, но и источник улучшения всей системы.
и фиксирует результат: какие источники использовал, был ли нужен оператор
какие вопросы повторяются, где бот не справился, по каким темам зовут человека
в базе нет информации / информация устарела / информация есть, но бот её не нашёл
какая тема, сколько обращений, каких фактов не хватает
привычный рабочий инструмент — ничего нового осваивать не нужно
и автоматически проверяется на контрольных вопросах
и цикл повторяется на новых данных
Всё остальное производно и обновляется автоматически. Бот имеет к Yonote доступ только на чтение и не может ничего изменить самостоятельно. Новые факты всегда проходят через человека.
Автономная разметка обоих каналов. Точность определения категории: 87% на тексте (динамика 36% → 65% → 87%) и 85,8% на голосе. Более 560 обращений за первую неделю без ручного вмешательства.
Голосовая линия была слепым пятном — тикеты приходили пустыми, статистики не было вообще. Сейчас работает полная цепочка: звонок → расшифровка → обезличивание персональных данных → классификация → запись в систему. Исправлена обработка исходящих звонков, которые ранее терялись. Бот определяет мероприятие прямо по тексту разговора, включая разговорные сокращения.
Правки операторов собираются автоматически — бот учится на реальной разметке без дополнительной работы людей. Обучающая и проверочная выборки разделены, поэтому результат не завышен. База эталонных примеров — 286 размеченных обращений, пополняется ежедневно. Ручную разметку операторов бот не перезаписывает: заполняет только пустые поля.
Решения принимаются на замерах, а не на предположениях. Замена системы распознавания речи — теряет фрагменты разговора и не разделяет реплики. Более крупная языковая модель — точность ниже текущей. Двухступенчатая классификация и динамический подбор примеров — обе схемы хуже действующей.
Форумная линейка выросла быстрее, чем обновлялась база. В отдельных сценариях осталась устаревшая, дублирующаяся или недостаточно подтверждённая информация — бот мог смешивать разные мероприятия или отвечать по уже завершённым.
Сформирован перечень проблемных ответов, техническое задание на очистку передано в работу. Параллельно идёт постоянный мониторинг: где бот отвечает слишком общо, где сценарии пересекаются, какие ветки нужно удалить или заменить.
Отдельный сервис-помощник, который автоматически отслеживает базу Yonote и сообщает, какие форумы закрываются. Это снимает ручную работу по контролю сроков и убирает риск, что бот продолжит выдавать информацию по завершённому мероприятию.
Сезонность. Форумная линейка идёт волнами, и вопросы предсказуемы: за две недели до старта спрашивают про регистрацию, за неделю — про документы и проезд, во время события — про логистику. Значит, базу можно готовить заранее, а не догонять поток.
Работает вся цепочка целиком: обращение из VK через HelpDeskEddy → поиск в базе знаний → формирование ответа → доставка пользователю → сохранение аналитики. Проверены сценарии: обычный вопрос, продолжение диалога с уточнением, просьба позвать оператора, вопрос вне тематики. Бот держит контекст обращения, а не рассматривает каждое сообщение отдельно.
Бот не придумывает факты. Сначала ищет подтверждённую информацию в базе — более двух тысяч опубликованных фрагментов по мероприятиям, форумам, ФГАИС, грантам. Если подтверждённых данных нет — уточняет вопрос, сообщает об отсутствии информации или передаёт обращение специалисту. Это важнее, чем отвечать на любой вопрос любой ценой.
Две модели GigaChat через российскую платформу Cloud.ru: быстрая и экономичная для типовых вопросов, более мощная — для сложных и составных. Ориентировочные эксплуатационные расходы, пересчитанные на фактический поток ~6 000 обращений в месяц: от ~3 тыс. ₽ в экономичном режиме до ~13 тыс. ₽ на максимальной модели — включая сервер, резервные копии и мониторинг.
Работает админ-панель: база знаний, источники, отчёты, проблемные темы, контрольные вопросы, связь с Yonote. По каждому обращению сохраняется полный технический след — тема, источники, нужен ли оператор, время обработки, использованная модель и её стоимость.
Это MVP. Цепочка доказана, качество ответов — в работе. Дата замены действующего бота не назначается: переход произойдёт по критериям, а не по календарю.
После инцидента инфраструктура пересобрана полностью — не из копии старого сервера: не переносились операционная система, контейнеры, базы, ключи, пароли и сертификаты.
Персональные данные. Приложение, база знаний, история работы и поисковый индекс находятся в нашем контуре. В облачную модель уходит только минимально необходимый контекст запроса, персональные данные предварительно маскируются.
Дальше. Безопасность — не разовая проверка. Готовится техническое задание на внешний независимый аудит серверного контура. Мониторинг активности ведётся ежедневно.
Новая архитектура получает трафик только тогда, когда на одинаковой выборке реальных обращений покажет:
До выполнения этих условий действующий бот остаётся в продакшене и продолжает развиваться. Перенос трафика — поэтапный, с возможностью вернуться назад.
Насколько верно определяется направление обращения: мероприятия, гранты, техническая поддержка. Практический показатель — именно категории используются в аналитике и маршрутизации.
Насколько точно бот совпадает с детальной разметкой оператора. Введён в июле, строже первого, служит для настройки и отслеживания прогресса. Оба показателя измеряются автоматически; обучающая и проверочная выборки разделены — результат не завышен.
Действующая метрика показывает 47,6% за июнь. Но правило подсчёта в HelpDeskEddy засчитывает как успешно закрытое ботом любое обращение, завершённое без оператора — включая те, где пользователь написал приветствие и ушёл, не задав вопроса. Такие обращения не отражают реальную работу бота.
Это значит, что фактическая доля содержательных вопросов, закрытых ботом самостоятельно, ниже. Точную величину мы намеренно не оцениваем на глаз: в ближайший месяц вводится единая методика замера по содержательным обращениям и снимается честный базовый показатель. Дальнейший прогресс будет считаться от него.
Одновременно фиксируем качественную проблему: бот периодически даёт неточные ответы даже на типовые запросы. При сценарной архитектуре каждый такой случай закрывается ручной правкой конкретной ветки — системного решения здесь нет.
Всё, что описано выше, работает на её рост — от честного базового замера.
Около 9% обращений в проверочной выборке размечены операторами спорно или ошибочно — например, звонок без содержательного разговора помечен как организационный вопрос. Это ограничивает измеримый потолок точности примерно на 90%. Решается согласованием правил разметки с методологами.
Часть подтем разграничена нечётко, поэтому одинаковые обращения разные операторы размечают по-разному. Нужны формальные определения — тогда единообразие вырастет и у бота, и у людей.
Расшифровки телефонных разговоров содержат искажения, ограничивающие точность на голосовом канале. Частично компенсировано автоматической коррекцией терминов и названий систем.
Анализатор найдёт пробелы быстрее, чем их успеют закрыть. Полезность системы зависит от того, насколько быстро подтверждаются факты и обновляется Yonote.
Разработка и сопровождение контура сегодня держатся на одном человеке. Снимается подключением второго исполнителя к задачам тестирования и разработки и внешним аудитом инфраструктуры.
Система учится не на персональных данных пользователей, а на выявленных и подтверждённых пробелах в знаниях. Каждый новый факт проходит через человека, Yonote и контроль качества.
За первый месяц создан фундамент. Следующие полгода превратят его в устойчивый продукт, который снижает нагрузку на операторов, улучшает качество информации и даёт руководству понятную картину реальных потребностей пользователей.
Задать вопрос Артёму