# 02. Конструктор таксономии и правил без релиза

| | |
|---|---|
| **Статус** | в MVP: базовые типы; кастомная таксономия — v1.1 (Q2 2027) |
| **Тариф** | «Бизнес» и выше |
| **Зависимости** | [03-models.md](../03-models.md) §3 (каскад «правила → LLM → человек») |

## Проблема

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

## Решение

Конструктор из трёх слоёв, который правит **бизнес-аналитик клиента, а не разработчик**:

**Слой 1 — правила (детерминированные).** Словари и регулярные выражения: «оставьте
сообщение», стоп-слова, обязательные фразы скрипта. Нечёткий поиск (rapidfuzz) с порогом
схожести — чтобы «здрасьте» ловилось так же, как «здравствуйте». Применяются мгновенно, на
уже обработанных звонках — кнопкой «применить к периоду».

**Слой 2 — LLM-метки.** Метка описывается текстом на русском: название, определение,
2–3 примера «да» и «нет», список того, что меткой не считается. Система сама собирает
промпт со строгой JSON-схемой (`{label, value, confidence, evidence}`) и прогоняет по
транскриптам. Никакого «обучения модели» и выгрузки данных наружу.

**Слой 3 — проверка на эталоне.** Перед публикацией версии таксономии запускается A/B на
регресс-наборе: 300–500 размеченных звонков клиента. Видно precision/recall по каждой метке,
и решение принимается по цифрам, а не по вкусу. Отклонённая версия не попадает в прод.

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

## Как это выглядит

- **Экран «Таксономия»:** список меток, каждая — карточка «определение + примеры + метрика
  качества на эталоне».
- **Экран «Правила»:** редактор словарей с тестом на живом звонке — сразу видно, где сработало.
- **Дашборд «Качество метки»:** precision/recall, доля низкой уверенности, список спорных
  звонков — сразу в очередь ручного контроля.
- **API:** `GET/PUT /v1/taxonomy`, `POST /v1/taxonomy/{version}/evaluate` (прогон на эталоне).

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

| Метрика | Цель |
|---|---|
| Время от идеи метки до прода | ≤ 1 день (у конкурентов — недели) |
| Доля меток с precision < 0,8 после настройки | ≤ 10 % |
| Правки таксономии, сделанные клиентом самостоятельно | ≥ 80 % (без обращений в поддержку) |
| Число версий таксономии на клиента за год | 4–12 (признак живого использования) |

## Этапы

1. **MVP:** правила (словари, стоп-слова) + базовые типы соединений; версионирование.
2. **v1.1:** LLM-метки через конструктор, регресс-набор и A/B, откат.
3. **v1.2:** библиотека отраслевых шаблонов (недвижимость, коллекшн, телемедицина,
   автосервис, e-commerce) — «поставьте галочку, что вы продаёте».

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

Кастомная таксономия — граница между тарифами «Старт» и «Бизнес» (разница 40 000 ₽/мес).
Библиотека отраслевых шаблонов — ускоритель продаж: шаблон снимает 2 недели воркшопов и
позволяет входить в отрасль «пакетом».

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

- **Модули телефонии** (Mango, UIS) дают фиксированный набор чек-листов: добавить свою метку
  нельзя.
- **SaaS для продаж** настраиваются в пределах своей модели оценки (чек-листы, скрипты), но
  не дают конструктора произвольных меток с измерением качества на эталоне.
- **Enterprise-вендоры** формализуют таксономию в проекте внедрения: каждое изменение —
  отдельные работы и бюджет.