В мире высоких технологий все больше и больше компаний внедряют голосовых и чат‑ассистентов в различные сегменты рабочих процессов. Они помогают обрабатывать рутинные задачи, ускоряют взаимодействие с пользователями и снижают нагрузку на сотрудников. Компания «Эвотор» находится в числе тех, кто активно занимается разработкой ассистента поддержки на базе llm — Евы, которая уже помогает тысячам пользователей ежедневно.

Но в каждом клиентском сервисе рано или поздно встает вопрос — а что делать с «неудобными» запросами? Кто‑то спрашивает про политику, кто‑то пишет откровенно неприемлемые вещи или пытается узнать рецепт наркотиков. Ответить на такое — значит рисковать имиджем компании. Игнорировать — тоже плохой вариант. А перевод на оператора может быть бесполезным, если он не готов к обсуждению подобных тем.

Меня зовут Калинина Наталия, ml‑engineer в компании Эвотор, и в статье приоткрою дверцу внутренней кухни нашей поддержки. У нас ежедневно обрабатываются тысячи пользовательских запросов и операторам отследить сообщения с высоким риском достаточно сложно. При таких объемах критически важна автоматизированная обработка чувствительных запросов и, что немаловажно, ответов самого ассистента.

В связи с этим решила помочь коллегам в разработке safety layer и встроить детектор чувствительных тематик прямо в чат-бота, чтобы он сам мог отлавливать потенциально опасные или нежелательные сообщения до того, как будет сгенерирован ответ или запросы попадут к оператору.

В этой статье расскажу:

какие темы считаются чувствительными и почему;
как подбирала подход — от регулярных выражений до LLM;
как устроена архитектура решения;
на какие "грабли наступала" на этапе тестирования;
и как сейчас реагирует бот, когда получает что-то вроде «Как заниматься онлайн сексом безопасно по SSL/TLS?»

Спойлер: бот не краснеет, а работает.

Что такое «чувствительные темы» и почему их важно вовремя замечать

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

Так зачем все это нужно? Прежде всего стоит подумать о репутации компании и этике, ведь ассистент может выдать не совсем релевантную и нейтральную генерацию на сложную тему или, что еще хуже, предоставить ответ с опасной информацией, например, как сделать бомбу без смс и регистрации. Также сюда попадают и юридические риски. Нарушение норм и законов — особенно при упоминании чувствительных тем — может повлечь жалобы или даже поездки в Магадан. Еще одним немаловажным фактором является защита команды. Саппорту не всегда просто читать такие сообщения, поэтому детекция снижает эмоциональное давление и уменьшает выгорание сотрудников. И конечно же — качество сервиса. Если бот чётко понимает, где надо молчать, где — перенаправить, а где — дать мягкий отказ, это вызывает доверие.

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

Эксперименты с оптимальным подходом

Все начинается с базы — поресерчить текущие решения на рынке и попробовать прикрутить что-то готовое. Существует множество тулзов для обеспечения безопасности генерации асисстентов, основанных на llm-моделях. Например, LLM Guard, Vigil, Lakera Guard и другие.

Они умеют детектировать токсичность и prompt injection, утечки PI (персональных данных), опасные тематики, а так же инструкции по взлому или вредоносные действия. Их легко встроить в пайплайн приложения и в отдельных случаях настроить панель мониторинга.

На первый взгляд — мечта. Но когда начала копаться глубже, выяснилось, что почти все эти инструменты:

ориентированы на английский язык (в лучшем случае — с частичной поддержкой других языков);
плохо справляются с русским матом, сленгом, сарказмом и культурными особенностями (у нас же "бомба" — это и про взрывы, и про шашлык);
и, конечно, не локальны — почти все работают через облачные API, что не подходит для закрытых контуров или офлайн-интеграций.

Плюс ко всему, готовые решения — это ещё и черные ящики. Понять, почему система что-то отфильтровала или нет, — достаточно сложно. А в данном случае важно мягко и корректно сгенерировать ответ, зная, почему система посчитала тему чувствительной.

Еще один вариант — использовать регулярные выражения по определенным ключевым словам. Такой метод прост в реализации и понятен: ищешь “наркотики”, “религию”, “политику” с видоизмененными частями — и машешь красным флажком. Но на практике регулярки — это как радар с близорукостью. Они не понимают контекст и не проводят границу между различными семантическими полями. Более того, в русском языке часто встречается полисемичность, а здесь уже одними регулярками не отделаешься. Запросы вроде “я не хочу обсуждать религию” или “как продавать женские колготки” попадали под бан, хотя не содержали ничего опасного. Или наоборот: “как смешать вещества, чтобы забыться” пролетали мимо фильтра, потому что ключевые слова не были столь очевидными.

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

Следующий шаг — включить нейросети. Началось все с GPT — отправляла запросы по API с определенным промптом на детекцию чувствительных тематик. GPT справлялся довольно неплохо, но: (1) дорого, (2) долго, (3) нестабильно (4) внешний сервис — одна и та же фраза могла то пройти, то нет. Плюс ко всему, модель переодически галлюцинировала, что порождало новые проблемы с обработкой такой выдачи. Да, она умеет «думать», но как сделать, чтобы это было быстро, качественно и дёшево 24/7 — отдельная статья. Не стоит забывать в данном случае об интеграции зарубежных сервисов, что являлось одним из red flags при разработке собственного решения.

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

Архитектура

Приоритетными параметрами при реализации своего подхода являлись:

относительная легковесность решения (ориентир на небольшую модель для запуска на самым малых мощностях);
«русскоязычность» модели (как упоминалось выше, есть множество решений для английского языка, но для русского сегмента круг сильно сужается из‑за его специфики).

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

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

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

Учитывая то, что у нас была обучена внутренняя модель сентимента, выбор пал именно на нее, так как негатив из разных областей она уже видела.

А что с датасетом? В данном случае получился достаточно интересный микс данных:

внутренние диалоги ассистента поддержки с клиентами;
часть датасета коллег из Сколтеха, состоящий из 2ch.hk (платформа для общения на русском языке, похожая на Reddit. Другими словами, настоящая кладезь текстовых данных с различными тональностями и темами для обсуждений) и Otvet.Mail.ru (платформа для ответов на вопросы);

Так как детекция «опасных» тематик является достаточно важным слоем безопасности, процесс подготовки и разметки проходил в несколько этапов:

удаление дублей, замена url, маскирование имен клиентов и их личных данных;
аннотирование внутренней сентимент‑моделью с метками «позитив/негатив/нейтраль»;
оценка соотношения классов (в данном случае получилось ~60% негатива и около 40% позитива и нейтрали соответственно);
GPT‑разметка негативной части по тематикам (напомню: политика, религия, наркотики, порнография и расизм+нейтраль в качестве альтернативы)+проверка итоговых лейблов;
ручная проверка оставшейся части с более приятным контекстом и ее доп.разметка по тематикам.

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

В подобных условиях возникло желание обратиться к нейросетям и остановилась на BERT‑семействе. Важно было соблюсти баланс скорости и качества, поэтому, пройдясь по бенчмаркам и проведя ресерч, взяла ai‑forever/ruBert‑base. Это русскоязычная моделька от команды SberDevices на 178M параметров (более подробно здесь). Плюс она хорошо справляется с семантикой слов и уделяет большее внимание к смыслу текста в целом, что очень важно при работе с чувствительными тематиками. И конечно же, скорость — модель достаточно быстро работает из‑за расширения словаря, а главное — предоставляет качественные эмбеддинги.

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

Mixup работает следующим образом: допустим, есть два примера:

«Как оплатить через СБП?» $(x1)$ → класс «Оплата» $(y1)$
«Как сменить номер телефона?» $(x2)$ → класс «Настройки» $(y2)$

Метод создаёт:

Новый вход: $x=λx1+(1−λ)x2$
Новую метку: $y=λy1+(1−λ)y2$

Где $λ∈[0,1]$ — случайное число.

То есть на выходе получается новый тренировочный пример, который частично похож и на запрос про оплату, и на запрос про номер телефона. Его метка — не «жёсткий» класс, а сглаженный вектор, указывающий, что 70% вероятности — «оплата», 30% — «настройки».

При выборе основной метрики был сделан упор на «состояние» данных, так как из‑за отсутствия в них баланса, точность может быть обманчиво высокой. Поэтому в качестве базы выбрала F1-macro (даёт более честную картину и производит усреднение по классам — важен каждый класс одинаково, независимо от частоты). По итогам обучения модели получилась красивая матрица ошибок и F1 со значением ~96%.

Этап тестирования

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

После прогонки на многочисленных кейсах выяснилось, что немного не хватило данных по некоторым классам. Здесь уже под бан попали потенциальные клиенты с запросами про сингулярность, коров, шоколадную колбасу и продажу маркированного пива. Но так как подобных кейсов было мало, все‑таки отпустили модель в настоящее продовское плавание, а там она показала себя достаточно неплохо: основные проблемные запросы (особенно много было про политику) начали определяться как «опасные» и теперь Ева может самостоятельно попросить клиента придерживаться релевантной темы беседы. Безусловно, есть моменты, требующие улучшений, но в первом приближении результатом довольны.

А что же дальше?

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

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

Немаловажным направлениям остается анализ пользовательского опыта. Полученные данные и фидбек будут использованы для дальнейшей корректировки модели и добавления новых правил и фильтров для более сложных кейсов.

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

Фильтруем политику и нецензурщину: как в «Эвоторе» защищают клиентский чат