Под микроскопом: AI Product Hack

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

Сегодня мы посмотрим на результаты AI Product Hack и постараемся разобраться в том, кто после присуждения мест оказался прав: раздосадованные поражением участники команд или судьи.

В частности мы будем рассматривать кейс компании Raft - “Мониторинг токсичного контента в AI-продуктах”. 

Первый справедливый вопрос, почему токсичный контент? Все просто. Для тебя, дорогой читатель, не секрет, что LLM на пике популярности. И когда ты захочешь внедрить умного ассистента или RAG систему в прод, тебе вряд ли будет приятно увидеть галлюцинирующие ответы модели, представляющие потенциальную опасность. Например, представим команду интеграции LLM пайплайнов которые сидят у себя в кабинете и радуются тому, что смог сэкономить после замены кучи операторов поддержки одним чат ботом. Но вдруг, внезапно оказывается, что на любую блажь приходят недоброжелатели, которым не терпится послать 100500 атак на бота, содержащих джейлбрейки, промпт-инъекции и пр. После этого никто уже не радуется, ведь его инновационное решение продает товары за минимальную стоимость, сливает пользователям конфиденциальную информацию, ведет себя как гигачад с форчана и выдает опасные инструкции. Все это ведет к огромным финансовым потерям и опускает рейтинг доверия к компании в самый низ.

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

Суммарно было 6 команд:

• йцукен123 (презентация) 

• KazanPlova (презентация)

• analab (презентация)

• to the moon (презентация)

• Monitox (презентация)

• ML Hedgehogs (презентация)

Поскольку в кейсах от заказчика суммарное количество команд было относительно небольшим, места были распределены не по одному, а по всем кейсам. По результатам судейских решений первое место забрала команда LLaMacтеры (за кейс по Red Teaming, у которых кстати вышла статья на хабр). Второе место досталось команде analab, а третье - to the moon.

Описание решений

йцукен123

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

Эти модели интегрировали в пользовательский интерфейс, обеспечивая взаимодействие с контентом, который поступает от общения пользователя с LLM. Доступно подключение алертов.

Также ребята реализовали функционал для отображения истории сообщений в виде графиков, иллюстрирующих уровень токсичности.

Kazan Plova

Тут адаптировали модель DeBERTa, дообучив её на собственном датасете для определения необходимых классов токсичного контента. Чтобы упростить доступ к оптимизации, модель конвертировали в ONNX. Для хранения и анализа данных команда использовала InfluxDB.

Также ребята внедрили систему Telegram алертов. Дополнительные аналитические данные визуализировали при помощи Grafana.

Analab

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

Конкретно анализатор токсичного контента был создан с использованием классического Bert. 

Итого у них получилось решение, позволяющее использовать уже готовые анализаторы и/или добавлять новые.

Также тут подкрутили базовый UI для удобства пользователя и добавили возможность подключения алертов.

To the Moon

Ребята разработали систему мониторинга, интегрированную в Grafana. Кроме того, их решение включает возможность локального запуска и взаимодействие с пользователем через Telegram бота. Для реализации ML составляющей решили использовать две модели Bert для детекции токсичного промпта пользователя на входе и сгенерированного LLM на выходе. Аналогом является комбинация из эмбеддера multilingual-e5-large, который по определенному порогу размечает входной промпт, а также Llamaguard 3 на выходе. Также ребята смотрели в сторону LLama Prompt-Guard-86M, LLama 3.1.

Monitox 

Аналогично ребятам выше, тут разработали сервис на Grafana, а также связали с ней Telegram бот, с которым взаимодействует пользователь. С точки зрения ML они представили две Bert модели. Одну дообучали для классификации промпта пользователя, а для LLM подняли toxicbert. Система использует Mistral API, подключаясь к Mistral 7B, в который также вшиты промпт инструкции по защите и классификации harmful контента.

ML Hedgehogs

В этой команде для реализации базовой модели использовали комбинацию TF-IDF и Log Reg. Затем они дообучили модель Saiga Llama 3 8B для задачи бинарной классификации. Также была дообучена модель Mistral 7B Instruct, а после этого снова использовали Saiga Llama 3 8B, но уже для решения задачи мультиклассовой классификации.

Подняли решение через Langsmith. Стоит отметить, что это единственная команда, использующая Langsmith и дообучение LLM с помощью Lora, которое явно себя оправдало. Также важно упомянуть, что не обошлось без системного промпта, который, вероятно, сыграл свою роль в достижении результата.

Сводка

Здесь мы решили обозначить наилучшие решения, а также показать, что Bert уже не SOTA для данной задачи

Input- проверка входного промпта от пользователя
Output- проверка ответа LLM на токсичность

В качестве метрики используется f-beta, где beta=2

По итогу мы имеем множество однотипных решений с точки зрения ML и только несколько команд, а именно To the Moon и ML Hedgehogs показали действительно уникальный результат.

Валидация проводилась на внутреннем датасете, который ни одна из представленных моделей не видела. Большая часть данных составляет нежелательный контент как со стороны пользователя, так и со стороны модели. Поскольку метрика recall не может быть единственным решением в данной ситуации, мы решили использовать метрику f-beta с параметром beta = 2. Это позволяет сделать больший акцент на recall по сравнению с precision, не снижая важности последней. Говоря о precision, все модели для входного промпта показывали более 90% точности, что достаточно неплохо и говорит о том, что ошибок первого будет меньше, однако стоит помнить, что большая часть данных это токсичный набор текста, который ломает LLM, или пытается это сделать.

Архитектура решений

Архитектура всех решений имеет схожие концепции. Рассмотрим их поочередно для каждой команды.

йцукен123

Клиентом может быть как человек, так и бот, который обращается к Nginx, выступающий в качестве API Gateway. 

Центральным компонентом является LLM Guard, отвечающий за фильтрацию запросов к модели LLM. Важную роль в этом процессе играет LLM Request Filter API, выполняющий валидацию запросов на FastAPI. Запросы отправляются в очередь через Message Queue, на базе RabbitMQ, после чего их анализируют различные сервисы, такие как Toxic Service, Topic Classifier Service и пр.

LLM Adapter API отправляет запросы в LLM. Для уведомлений предусмотрены сервисы, которые информируют пользователей о состоянии системы через Telegram и по электронной почте.

Система также включает UI, разработанный при помощи Streamlit и FastAPI. Данные пользователей хранятся в PostgreSQL. Мониторинг системы осуществляется через Prometheus. 

Kazan Plova

Система мониторинга на базе дообученной модели DeBERTa анализирует входящие сообщения и отправляет результаты в базу данных InfluxDB. Полученные результаты дополнительно визуализируются через Grafana. Уведомления об обнаружении токсичного контента приходят через алерты в Telegram.

Analab

LightHouse Server - управляющий компонент системы. Реализована возможность интеграции с ClickHouse. Пользователи взаимодействуют через Lighthouse UI для настройки мониторинга и визуализации данных, а Lighthouse Monitoring собирает информацию и отправляет уведомления пользователям через бота в Telegram.

To the moon

Ребята выделили два варианта архитектуры в формате user story и самой архитектуры. Такой подход позволяет с одной стороны увидеть верхнеуровневую концепцию, а с другой увидеть подробности.

Здесь история понятная и простая, они решили разделить запрос на два, один идет в LLM, а другой к их сервису. Такой подход позволяет сохранить время ожидания, однако возникает вопрос о том, а стоит ли отправлять в LLM запрос и тратить ресурсы(вычислительные мощности или токены) для получения ответа.

Здесь мы видим более подробное перекладывание json'ов от пользователя до разработчика (человека который проводит мониторинг). Данные от пользователя, пройдя ML блок, собираются в БД, а затем идут в Grafana, параллельно на Telegram бот будут приходить alert'ы.

Monitox

Ребята представили полную схему потока json'ов.

Формула такая же: пользователь взаимодействует с ботом в телеграме, оттуда данные сначала идут в Rest сервис с ML, а также в Mistral API. Затем все это собирается через Postgres и выводится в Grafana.

ML Hedgehogs

Ежики отобразили больше ML составляющую, чем суммарную архитектуру. Однако как было сказано выше, все интегрировано в Langsmith и также имеет возможность локального запуска.

Качество кода и оформления репозитория

За то время пока мы изучали эти решения успело накопиться множество вопросов, большинство из которых удалось решить. Тем не менее стоит отметить, что некоторые команды не совсем удачно расписали readme, у кого то его в принципе не было, что затрудняло анализ результатов. Не смотря на расписанный репозиторий команды To The Moon, мы бы посоветовали в следующий раз добавить в него особенности установки некоторых моделей, в особенности Llamaguard3, которая требовала исключительно локальный запуск через ollama. Это не критично, однако для проверки пришлось покопаться в репозитории и попытаться понять, почему HF токен на модельки Llama не работает.

Сравнение оценок на хакатоне и технической реализации

Каждая команда привнесла что-то свое, и это “свое” делает выбор победителя не таким очевидным. Возьмем ML-Hedgehogs. На первый взгляд команда Ежиков, вооруженная тремя моделями, обученными при помощи Lora, выглядела как безусловный лидер. Но стоит ли спешить с выводами? Давайте разберемся.

Команда ML-Hedgehogs обучала свои модели на англоязычных датасетах, но, несмотря на это, они приятно удивили нас результатами с русскоязычного теста. Модель действительно хорошо справилась с инференсом на атаках. Однако за все хорошее нужно платить: решение Ежиков оказалось самым ресурсоемким. Стоило ли оно того? Возможно.

Тем временем у команд analab и To the Moon вышло не так интересно в плане инференса. С другой стороны, они выкатили всецело проработанные решения, и их сервисы уже готовы к использованию. Докрути модели помощнее - и получится впечатляюще.

Что касается остальных команд, есть куда расти: кому-то не хватило силы базового решения, кто-то уделил слишком мало времени обучению собственных моделей.

Так кто же должен был победить?
Смещая лидерборд с хакатона мы решили распределить призовые места следующим образом внутри кейса :

1. To the Moon

2. Analab

3. ML Hedgehogs

Авторы: Анна Тищенко и Минко Богдан участники AI Security Lab из магистратуры Talent Hub,