# 07. Мониторинг качества и дрейфа моделей — «мы подписываемся цифрами»

| | |
|---|---|
| **Статус** | v1.0 (MVP, январь 2027) — это часть обещания, а не «плюшка» |
| **Тариф** | входит во все тарифы, включая API |
| **Зависимости** | [03-models.md](../03-models.md) §4 (методика оценки), [02-architecture.md](../02-architecture.md) §7 (R1, R8) |

## Проблема

Никто из конкурентов не публикует точность распознавания на **ваших** записях. Продавец
говорит «WER 5 %», клиент получает «не понимает фамилии и путает цифры». Дальше — разочарование
и недоверие ко всей категории.

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

## Решение

**Три измеримых контура качества, доступных клиенту.**

**1. Пилотный замер (до денег).** На записях заказчика: ручная эталонная транскрипция
60–90 минут, стратифицированная по типам звонков; WER/CER общие и по слоям; сравнение
3–4 моделей ASR между собой. Оценка классификации — на 300–500 звонках с разметкой бизнеса.
Результат — приложение к договору с цифрами, а не презентация.

**2. Регресс-набор клиента в CI.** Зафиксированная выборка (ASR + классификация) остаётся в
контуре клиента. Любой апгрейд моделей и промптов проходит через неё **до** выкатки: если
качество падает — обновление не выходит. Отчёт по каждому релизу — доступен клиенту.

**3. Ежемесячный отчёт о качестве и алерты на дрейф.** Автоматически:
- WER на контрольной выборке (если есть разметка) и доля сегментов с низкой уверенностью;
- метрики классификации: precision/recall по ключевым классам, доля ручного контроля;
- алерт, если показатель ухудшился больше чем на порог (например, WER +2 п.п. или
  low-confidence +30 %).

**Что видит клиент:** страницу «Качество» со значениями за период, историей по месяцам и
объяснением, почему показатель мог измениться (новая кампания, изменился профиль звонков).
Никаких «модель стала хуже, но мы промолчали».

## Метрики успеха

| Метрика | Цель |
|---|---|
| Обнаружение деградации качества | ≤ 7 дней от появления (алерт, а не жалоба) |
| Доля обновлений моделей, прошедших регресс без падения качества | 100 % |
| Расхождение «обещали в пилоте / получили в проде» | ±1 п.п. по WER |
| Клиенты, у которых замерялся WER на своих данных | 100 % (иначе нет договора) |

## Этапы

1. **MVP:** страница «Качество», low-confidence метрика, отчёт по релизам.
2. **v1.1:** регресс-набор клиента, авто-прогон при обновлении, алерты на дрейф.
3. **v1.2:** дообучение словарей и промптов под клиента (затравки имён, продуктов, сленга),
   с публикацией «до/после» на регресс-наборе.

## Монетизация

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

## Почему этого нет у других

- **SaaS для продаж** дают точность «в среднем по рынку» и не показывают метрики по вашему
  контуру.
- **API-конструкторы** дают метрики модели в документации; контроль качества применительно
  к вашему бизнесу — задача клиента.
- **Enterprise-вендоры** измеряют, но обычно внутри проекта и не в виде ежемесячного отчёта
  с SLA-качеством.