Как деплоить RLHF-модель в production? (A/B тест с SFT-моделью, мониторинг качества и safety)

Краткий тезис

Деплой RLHF-модели — не просто замена базовой SFT-модели на новый чекпоинт. Требуется многофазная валидация: сначала A/B-тест на ограниченном трафике, затем канареечное развёртывание с поэтапным расширением доли, параллельный мониторинг метрик качества (helpfulness, honesty), безопасности (токсичность, джейлбрейки) и производительности (latency). Критически важным элементом становится Human-in-the-loop для обработки краевых случаев, в которых ни автоматические детекторы, ни reward-модель не дают уверенной оценки.

| --- | --- | --- | | Helpfulness (оценка разметчиков, 1–5) | 4.1 | 4.3 | +0.15, p<0.05 | | Toxicity (автоматический детектор) | 2.1% | 1.3% | снижение на 30% | | Safety (доля отказов на опасные запросы) | 88% | 95% | увеличение на 5% | | Latency p50 | 420 ms | 480 ms | < 15% ухудшения | | Award hacking (offline reward) | 0.75 | 0.80 | незначимо выше контроля |

1.4 Критерии остановки

• Если RLHF проигрывает по любой safety-метрике — немедленный откат.
• Если latency p99 вырос более чем на 30% — остановка для оптимизации инфраструктуры.
• Если результаты не достигают статистической значимости за 14 дней — тест считается провальным.

2. Метрики: качество, токсичность, latency

2.1 Качество (Helpfulness & Honesty)

• Online-оценка: от пользователей (лайки/дизлайки, репорты).
• Offline-оценка: reward-модель на отложенной выборке, human evaluation по шкале LMS (см. Reward Model).
• Honesty: доля ответов с признанием незнания («Я не знаю», «Точный ответ не могу дать») — идеально для RLHF.

2.2 Токсичность и безопасность

• Автоматические детекторы: Perspective API, Llama Guard, OpenAI Moderation API — на каждое сообщение.
• Пороги: если детектор выдаёт >0.8, ответ блокируется и передаётся на ручную модерацию.
• Мониторинг атак: джейлбрейк-попытки (DAN, roleplay), тестирование границ модели.

2.3 Latency

• p50 / p99 время генерации.
• Throughput: количество токенов/сек на инстанс.
• Load test: до и после деплоя (см. Canary Deployment).
• Дополнительно: отслеживать время вызова reward-модели, если она используется в режиме real-time reranking.

3. Canary deployment

3.1 Стратегия

После успешного A/B-теста RLHF-модель выкатывается не сразу на весь трафик, а через канареечный сервер:

1. Shadow mode (1–2 дня): модель работает параллельно с SFT, но её ответы не видны пользователям — только логи.
2. 1% трафика (1 день): проверка критических ошибок.
3. 10% трафика (2 дня): мониторинг метрик безопасности и латентности.
4. 50% трафика (3 дня): финальная валидация.
5. 100% трафика: если все метрики стабильны, SFT-модель выводится из эксплуатации.

3.2 Откат

Автоматический откат на SFT в случае:

• Рост доли toxic-ответов >2% от baseline.
• Увеличение p99 latency >50%.
• Падение пользовательских удовольствий (лайков) на 5%.

3.3 Инструменты

Kubernetes (deployment config для изменения image), feature flags (LaunchDarkly, Leptos или self‑managed), MLflow для версионирования моделей.

4. Human-in-the-loop для краевых случаев

Даже самая качественная RLHF-модель может допускать ошибки на нестандартных запросах. Human-in-the-loop (HITL) позволяет:

1. Флаговать спорные ответы — если reward-модель дала оценку в середине шкалы (0.4–0.6), ответ отправляется разметчику.
2. Активное обучение — краевые случаи (джейлбрейки, сложные фактические вопросы) добавляются в датасет для следующего раунда RLHF.
3. Аудит случайной выборки — каждый день N% (например, 1%) всех ответов проверяется человеком.
4. Сбор объяснений — разметчик пишет, что именно не так (безопасность, неверный факт, стиль).

4.1 Архитектура интеграции

User query → RLHF model → Reward model → Decision  
    ↓ if uncertainty > threshold          ↓ if safe & certain
    Queue → Human moderator → Label       → Return to user

4.2 Лучшие практики

• Использовать "очередь" с приоритетами (toxic‑скрининг в первую очередь).
• Давать разметчикам калькулятор (короткая инструкция) и примеры.
• Записывать метаданные: время, модель, температура, контекст диалога.

Пет-проект для закрепления

Задача: Разверните две версии простого Q&A-бота (SFT и RLHF) на Hugging Face Spaces или локальном сервере. Используйте открытые модели (например, Mistral 7B, SFT-черепок и RLHF-черепок через DPO). Организуйте A/B-тест с разделением трафика через простой NGINX split‑traffic. Добавьте мониторинг:

• Метрики качества (собирайте лайки пользователей через форму обратной связи).
• Токсичность (простой blacklist + Detoxify).
• Latency (p50, p99 через логи Nginx).

Инструменты

• Models: Hugging Face Transformers + PEFT.
• Inference: vLLM (подойдёт даже для 7B).
• A/B split: Nginx split_clients или Python‑роутер.
• Метрики: Prometheus + Grafana (или Loki для логов).

Шаги

1. Тренируем SFT и RLHF (DPO) модели на небольшом датасете (например, Anthropic HH‑RLHF).
2. Запускаем два инстанса vLLM: sft-vllm и rlhf-vllm.
3. Пишем A/B‑роутер (FastAPI), который с вероятностью X отправляет запрос на RLHF.
4. Добавляем middleware для логирования статуса ответа (time, toxic_score, user_feedback).
5. Разворачиваем Prometheus и Grafana для визуализации.

Ожидаемый результат

• Вы получите дашборд с разделением трафика между SFT и RLHF, сравнением доли токсичных ответов и средней задержки.
• Сможете имитировать «краевой случай» (запрос на взлом) и увидеть, как срабатывает HITL (в простой версии — просто блокировка и лог).
• Поймёте, как организовать откат при падении метрик.

Связь с другими вопросами

Навигация

• Предыдущий: 995
• Следующий: 997
• Индекс: 00. Индекс разборов