Как мы построили multilabel guardrail-классификатор и сделали его в три раза быстрее и дешевле
Любой продукт, который принимает пользовательский текст или генерирует ответы с помощью нейросети, сталкивается с риском появления нежелательного контента. Это могут быть инструкции к насилию, призывы к экстремизму, мошеннические схемы, опасные советы, дискриминационные высказывания или материалы для взрослых.
Проблема касается не только пользовательских сообщений. Основная модель тоже способна сформировать ответ, который нельзя показывать человеку. Поэтому проверять необходимо оба направления: входящий запрос до передачи в LLM и исходящий ответ перед отображением пользователю.
Для бизнеса последствия отсутствия такой защиты обычно сводятся к трём группам:
- регуляторные риски - штрафы, ограничения и блокировки из-за несоблюдения требований законодательства и отраслевых стандартов;
- репутационные потери - один скриншот с недопустимым ответом может быстро разойтись по социальным сетям;
- операционные расходы - ручная модерация плохо масштабируется и требует всё больше сотрудников при росте трафика.
Именно для автоматической предварительной проверки мы разработали multilabel guardrail-классификатор. Он анализирует текст сразу по 15 категориям риска, работает на русском и английском языках и выдаёт результат в режиме, пригодном для онлайн-сервисов.
Почему недостаточно бинарного фильтра
Простейший вариант модерации - бинарная модель, отвечающая только на вопрос: "Текст безопасен или нет?". Такой подход удобен для прототипа, но быстро становится слишком грубым для реального продукта.
Один и тот же запрос может одновременно содержать признаки нескольких нарушений. Например, инструкция по краже денег с использованием вредоносной программы относится и к финансовым, и к киберпреступлениям. Если модель обязана выбрать только один класс, часть информации будет потеряна.
Keyword-фильтры также не решают задачу. Они плохо работают с контекстом, ошибаются на нейтральных упоминаниях запрещённых слов и легко обходятся заменой символов, транслитерацией, намеренными опечатками или сменой раскладки клавиатуры.
В multilabel-подходе для каждого текста выполняются 15 независимых бинарных предсказаний. Модель не выбирает единственную категорию, а оценивает вероятность принадлежности к каждой из них. Благодаря этому один запрос может получить несколько меток одновременно.
Какие категории проверяет система
Категории можно разделить на две группы.
Вредоносные классы:
- эксплуатация детей;
- насильственные преступления;
- оружие;
- наркотики;
- причинение вреда себе;
- дискриминация;
- нацистская и экстремистская риторика;
- ненасильственные преступления;
- финансовые преступления;
- киберпреступления;
- контент 18+, включая материалы с признаками педофилии.
Тематические классы:
- нецензурная лексика;
- религиозная тематика, потенциально связанная с оскорблением религиозных чувств;
- ЛГБТ-контент.
Последняя группа не всегда означает автоматическую блокировку. В зависимости от продукта, юрисдикции и внутренних правил организации такой текст может потребовать иной политики обработки: дополнительного предупреждения, ограничения аудитории или ручной проверки.
Для тематических категорий важен юридический контекст. В качестве ориентиров могут использоваться положения статьи 6.21 КоАП РФ, статьи 148 УК РФ, норм 149-ФЗ, статей 5.61, 13.21 и части 3 статьи 20.1 КоАП РФ, а также закона № 436-ФЗ о защите детей от информации, причиняющей вред их здоровью и развитию. Конкретная политика определяется владельцем сервиса и применимым законодательством.
Модель не принимает решение о блокировке самостоятельно. Она возвращает вероятности и метки, а вызывающая система уже выбирает действие: пропустить текст, записать событие в журнал, отправить материал модератору или отклонить запрос.
Главные сложности разработки
Дисбаланс классов
Нецензурные выражения встречаются значительно чаще, чем эксплуатация детей или нацистская пропаганда. Если обучать модель на исходном распределении и ориентироваться на среднюю точность, она быстро научится хорошо распознавать частые классы, но будет почти бесполезна на редких и наиболее критичных категориях.
Поэтому для каждого класса требуются отдельные метрики, собственные веса ошибок и независимый подбор порога. Универсального значения, одинаково подходящего для всех 15 категорий, не существует.
Разная цена ошибок
Ложное срабатывание может ухудшить пользовательский опыт, но пропуск опасного контента способен привести к гораздо более серьёзным последствиям. Поэтому оптимизация только общей accuracy создаёт ложное ощущение качества.
Для каждого класса мы отдельно оцениваем precision, recall, F1 и показатели при фиксированном уровне ложных срабатываний. На практике пороги выбираются не только по результатам тестовой выборки, но и с учётом бизнес-политики конкретного сценария.
Обфускация
Пользователь может заменить буквы цифрами, вставить дополнительные символы, использовать транслит или написать фразу в неправильной раскладке. Для борьбы с этим мы применяем нормализацию текста, обработку распространённых вариантов и обучаем модель на примерах с искусственными и реальными искажениями.
Важно не переусердствовать с очисткой. Агрессивная нормализация способна уничтожить контекст и увеличить число ложных тревог. Поэтому предварительная обработка должна быть устойчивой, но обратимой и предсказуемой.
Смешанные языки
Реальные запросы редко ограничиваются одним языком. В одном сообщении могут сочетаться русский и английский, технические термины, транслит и фрагменты кода. Монолингвальная модель в таких случаях теряет часть сигналов, а отдельный классификатор для каждого языка усложняет поддержку.
Мы измеряли качество как минимум на русском и английском, включая смешанные формулировки. При этом важна не только средняя оценка по языкам, но и равномерность качества между ними: сильный результат на английском не компенсирует провал на русскоязычном трафике.
Архитектура решения
В основе системы лежит компактная языковая модель-классификатор с общей текстовой частью и 15 независимыми выходными головками. Каждая головка возвращает вероятность отдельной категории.
Такое устройство позволяет:
- включать только необходимые классы;
- назначать каждому классу собственный порог;
- изменять политику обработки без переобучения;
- отдельно контролировать редкие и критичные категории;
- сохранять единый inference pipeline.
На уровне продукта можно задать разные действия для разных меток. Например, нецензурную лексику отправлять на мягкую очистку, потенциальное мошенничество - на дополнительную проверку, а признаки эксплуатации детей - блокировать сразу и фиксировать событие для расследования.
Как мы ускорили инференс
Первоначальная версия работала корректно, но была слишком дорогой для большого потока запросов. Основной резерв находился не в самой классификации, а в обслуживании модели.
Мы оптимизировали несколько компонентов:
1. Уменьшили размер модели. Для guardrail-задачи не требуется универсальная генеративная система: классификатору достаточно извлечь признаки и выдать вероятности.
2. Настроили динамическую пакетную обработку. Запросы объединяются в batch, что позволяет эффективнее использовать вычислительные ресурсы.
3. Сократили лишние операции препроцессинга. Токенизация и нормализация были вынесены в оптимизированный конвейер.
4. Настроили длину входа. Ограничение максимального количества токенов уменьшило задержку без заметного падения качества на целевых данных.
5. Применили оптимизированный формат вычислений. Квантизация и подходящий тип чисел снизили требования к памяти и ускорили выполнение.
6. Разделили онлайн- и офлайн-сценарии. Для интерактивных запросов важна минимальная задержка, а для пакетной перепроверки выгоднее максимальный throughput.
В результате итоговая система стала примерно в три раза быстрее и дешевле исходной реализации. При этом экономический эффект зависит от размера batch: слишком маленькие пакеты дают минимальную задержку, но хуже используют оборудование; слишком крупные повышают пропускную способность, однако увеличивают время ожидания отдельного запроса.
Как выбирать batch size
Для онлайн-чата обычно важен компромисс между latency и throughput. Batch size 1 даёт наиболее предсказуемое время ответа, но вычислительный ресурс часто простаивает. Увеличение размера пакета снижает стоимость обработки одного текста, однако запрос может ждать, пока накопится необходимое количество элементов.
Поэтому на практике полезно использовать динамический batching с ограничением по времени ожидания. Если новые запросы поступают активно, система формирует более крупную пачку. При низкой нагрузке она не задерживает сообщение слишком долго и отправляет его на инференс сразу.
Для разных сценариев применяются разные настройки:
- интерактивный чат - небольшой batch и жёсткое ограничение задержки;
- массовая модерация архива - крупный batch и максимальная загрузка ускорителя;
- потоковая обработка - динамическая стратегия с контролем очереди;
- критичные категории - возможность отдельного приоритета и повторной проверки.
Что учитывать при эксплуатации
Классификатор нельзя считать полностью автономным решением. Его качество зависит от того, насколько хорошо отражены реальные сценарии использования. После запуска необходимо регулярно анализировать:
- новые способы обхода фильтров;
- распределение классов в продакшене;
- долю ложных срабатываний;
- случаи пропуска опасного контента;
- различия между языками и типами пользователей;
- изменение тематики запросов со временем.
Особенно важен процесс работы с ошибками. Каждое существенное ложное срабатывание или пропущенный пример следует классифицировать: проблема данных, порога, токенизации, контекста или самой архитектуры. Такой разбор позволяет улучшать систему точечно, а не бесконечно увеличивать размер модели.
Практические выводы
Первый урок - multilabel-классификация лучше соответствует реальной природе рисков, чем единый бинарный флаг.
Второй - редкие классы нельзя оценивать по средней метрике. Для них нужны отдельные тестовые наборы, контроль recall и ручная проверка наиболее опасных ошибок.
Третий - модель и политика модерации должны быть разделены. Классификатор сообщает о вероятностях, а бизнес-логика определяет дальнейшее действие.
Четвёртый - защита должна учитывать обфускацию, смешанные языки и контекст. Простая проверка ключевых слов быстро перестаёт работать.
Пятый - стоимость инференса необходимо проектировать с самого начала. Компактная архитектура, динамический batching, ограничение длины входа и оптимизированное представление модели способны дать многократный выигрыш без пропорциональной потери качества.
В итоге guardrail-классификатор становится не отдельным фильтром, а самостоятельным уровнем безопасности вокруг генеративной системы. Он помогает разделить техническое распознавание риска и продуктовую политику, масштабировать модерацию вместе с трафиком и снизить вероятность того, что опасный ответ доберётся до пользователя.