Dmitriy Dementiev
136e93765c
- Зачем: - пользователям без NVIDIA нужен самый быстрый и читаемый CPU-профиль без дополнительных параметров. - Что: - auto-политика изменена на CUDA при наличии nvidia-smi, иначе ONNX GigaAM RNN-T int8. - сохранён приоритет явных значений CLI и конфигурации для OpenVINO и FasterWhisper CPU. - обновлены тесты, README, PRD, ADR, GPU-документация и вывод benchmark. - Проверка: - uv run pytest -q: 232 passed, 1 skipped. - uv lock --check и git diff --cached --check.
258 lines
21 KiB
Markdown
258 lines
21 KiB
Markdown
# Backlog — будущие эксперименты и направления
|
||
|
||
Список открытых направлений, которые имеют смысл, но не реализованы. Каждый пункт содержит обоснование и ссылку на источник (ADR / статья), чтобы при возврате не пришлось воспроизводить контекст с нуля.
|
||
|
||
Когда направление становится в работу — переносится в spec/план или соответствующий ADR. Когда отклоняется — остаётся в backlog с пометкой «отклонено» и причиной (для истории решений).
|
||
|
||
---
|
||
|
||
## ASR-бэкенды и модели
|
||
|
||
### Переоценка CPU-дефолта после обновления `onnx-asr` 0.12
|
||
|
||
**Промежуточный статус 2026-08-11:** короткая матрица на трёх записях завершена
|
||
и описана в [benchmark GigaAM и Whisper](benchmarks/2026-08-11-gigaam-model-comparison.md).
|
||
Multilingual Large добавлена как явный качественный профиль; решение о default
|
||
по-прежнему ждёт целевого Intel Core i5 и длинных негативных примеров.
|
||
|
||
**Проблема:** текущий CPU-путь через OpenVINO Whisper medium нестабилен на
|
||
длинных записях с тихими участками: модель генерирует правдоподобные повторы и
|
||
несуществующий текст. На файле `2026-07-29 13-58-39.mp4` разговор заканчивается
|
||
примерно на 02:28, после чего OpenVINO создаёт десятки повторяющихся блоков до
|
||
конца 59-минутной записи. Изолированный тест окна 02:00–03:30 дал одинаковую
|
||
серию из 14 повторов на `openvino-genai` 2026.0 и 2026.3; обновление движка само
|
||
по себе проблему не устраняет. Подробнее — в пункте
|
||
[«Whisper medium галлюцинации»](#whisper-medium-галлюцинации-на-длинных-файлах-с-тихими-фрагментами).
|
||
|
||
**Порядок работы:**
|
||
|
||
1. Сначала обновить совместимый стек по
|
||
[исследованию обновлений](research/2026-08-10-engine-model-updates.md): снять
|
||
ограничение `onnx-asr<0.12.0`, проверить VAD и квантованные модели; OpenVINO и
|
||
OpenVINO GenAI обновлять согласованно. Не фиксировать ONNX Runtime 1.28 для
|
||
Python 3.10.
|
||
Шаг 1 в части onnx-пути вынесен в отдельную работу —
|
||
[спека «Onnx-каталог, Python 3.13 и границы версий»](specs/2026-08-11-onnx-model-catalog.md): движок
|
||
обновляется, четыре модели становятся поддерживаемыми, дефолт и OpenVINO не
|
||
трогаются намеренно, чтобы сохранить точку отсчёта для будущего сравнения.
|
||
2. После интеграционных тестов провести сравнительный бенчмарк моделей. Не
|
||
менять CPU-дефолт только по model card или результату на одном файле.
|
||
3. Решение зафиксировать в ADR-007, обновить рекомендации README и только затем
|
||
менять auto-detect/defaults.
|
||
|
||
**Кандидаты:**
|
||
|
||
- `gigaam-v3-ctc` — текущий baseline для русского CPU.
|
||
- `gigaam-v3-rnnt` — контекстный декодер без пунктуации.
|
||
- `gigaam-v3-e2e-ctc` и `gigaam-v3-e2e-rnnt` — варианты с пунктуацией и
|
||
нормализацией текста.
|
||
- `gigaam-multilingual-ctc` и `gigaam-multilingual-large-ctc`, добавленные в
|
||
`onnx-asr` 0.12 — кандидаты для смешанной речи, но не априори для русского
|
||
дефолта.
|
||
- OpenVINO medium + VAD — альтернатива смене модели, сохраняющая Whisper и
|
||
пунктуацию.
|
||
- Parakeet v3 — контрольный multilingual-вариант, но не кандидат на русский
|
||
дефолт без новых данных, опровергающих ADR-005/006.
|
||
|
||
**Матрица качества:**
|
||
|
||
- те же три полные записи и четыре критерия agent-judge из
|
||
[ADR-006](adr/006-onnx-asr-backend.md): completeness, term accuracy, fluency,
|
||
summary utility;
|
||
- новый негативный пример `2026-07-29 13-58-39.mp4` с длинной тишиной;
|
||
- небольшой вручную проверенный набор сложных фрагментов для WER/CER и разбора
|
||
критичных смысловых ошибок: тихие реплики, имена компаний, латиница и
|
||
IT-термины, числа, русско-английское переключение;
|
||
- автоматические проверки потери хвоста, повторов, пустых/нулевых VAD-сегментов
|
||
и выдуманного текста на тишине.
|
||
|
||
**Матрица производительности:**
|
||
|
||
- обязательный прогон на реальном Intel Core i5 11-го поколения; точный SKU,
|
||
число ядер, объём RAM, power mode и число потоков записать вместе с результатом;
|
||
- Ryzen 7 8845H разработчика и ограничение числа потоков использовать только для
|
||
предварительного smoke-теста, не как приёмку производительности i5;
|
||
- измерять отдельно cold start/загрузку модели и warm transcription, медиану
|
||
трёх прогонов, RTFx, peak RSS и размер скачиваемой модели;
|
||
- короткий 15-минутный фрагмент нужен для итераций, полные записи 22–81 мин —
|
||
для итогового решения и проверки устойчивости.
|
||
|
||
**Почему интересно:**
|
||
|
||
- **WER 2.6% vs 13.2%** для CTC на сложных текстах — в 5 раз ниже на разговорной речи и доменной лексике (источник: SberDevices / Хабр-публикация GigaAM-v3).
|
||
- **Контекстный декодер** — структурно решает основную проблему GigaAM-CTC из ADR-006: кириллизация латиницы и искажения имён компаний (`Запромбанк` → `Газпромбанк`, `яндекс тим под яндекс тим` → `Яндекс ТимКод`). RNN-T видит контекст уже сгенерированных токенов и может «дотянуть» имена.
|
||
- **`v3_e2e_rnnt` с пунктуацией и нормализацией** — закрывает главное ограничение GigaAM-CTC, ради которого в README сейчас стоит fallback на `openvino-cpu medium` (с задокументированными в ADR-006 галлюцинациями на длинных файлах).
|
||
- **70:30 vs Whisper-large-v3** — GigaAM-v3 (CTC и RNN-T) выигрывает у `large-v3` по LLM-as-Judge (Gemini 2.5 Pro). Если переносится на наш use case — RNN-T на CPU становится сильнее GPU faster-whisper large-v3.
|
||
- **30% лучше на «новых доменах»** (callcenter-like речь, нестандартные характеристики) — это и есть домен установочных встреч.
|
||
|
||
**Tradeoff:**
|
||
|
||
- Скорость ниже CTC (RNN-T декодинг последовательный). Реалистичная оценка: 10-15× RTF на CPU вместо 17-29× у CTC. Всё ещё в 1.5-2× быстрее Whisper medium.
|
||
- Размер модели больше (~500 MB int8 против ~300 MB у CTC) — оценка, нужна верификация.
|
||
|
||
**Если подтвердится бенчмарком:**
|
||
|
||
- Если E2E RNN-T сохраняет качество и приемлемую скорость на i5 — сделать его
|
||
русским CPU-дефолтом, OpenVINO оставить явной опцией.
|
||
- Если лучший вариант зависит от языка — выбрать language-aware default:
|
||
GigaAM v3 для русского, multilingual-модель для смешанной речи.
|
||
- Если модели GigaAM проигрывают по пунктуации/смыслу — сохранить текущий
|
||
model default и лечить OpenVINO через VAD/качественный pipeline.
|
||
- Если ни один вариант не проходит порог качества и скорости — не менять
|
||
дефолт, оставить предупреждения и явный выбор backend.
|
||
|
||
---
|
||
|
||
### Canary 1B — multilingual + пунктуация на CPU
|
||
|
||
**Что:** Протестировать `nemo-canary-1b-v2` через onnx-asr на тех же 3 файлах.
|
||
|
||
**Почему:** Multilingual + пунктуация в одной модели. Кандидат на «лучшее качество за разумную скорость» для пользователей, которым нужны и не-русский контент, и пунктуация одновременно. Упомянут в [ADR-006](adr/006-onnx-asr-backend.md#открытые-вопросы--следующие-шаги).
|
||
|
||
**Tradeoff:** Тяжелее GigaAM (~1 GB vs ~300 MB), скорость на CPU ожидаемо ниже. Если RNN-T закроет потребность в пунктуации — Canary становится менее приоритетным.
|
||
|
||
---
|
||
|
||
## Качество и устойчивость
|
||
|
||
### Whisper medium галлюцинации на длинных файлах с тихими фрагментами
|
||
|
||
**Статус:** воспроизведено 2026-08-10. Помимо примеров из
|
||
[ADR-006](adr/006-onnx-asr-backend.md#класс-ошибок-whisper-medium--галлюцинации-на-длинных-файлах-с-тихими-фрагментами),
|
||
на записи `2026-07-29 13-58-39.mp4` минимальный тест 02:00–03:30 стабильно
|
||
получает 14 одинаковых сегментов после окончания речи. На 30-секундном окне
|
||
только с речью повторов нет. `openvino-genai` 2026.3 и
|
||
`no_repeat_ngram_size=3` результат не меняют. Корень проблемы — длинные
|
||
безречевые участки, которые текущий OpenVINO backend целиком передаёт в
|
||
`WhisperPipeline` без VAD.
|
||
|
||
**Возможные направления:**
|
||
|
||
- Добавить VAD перед OpenVINO WhisperPipeline и сохранить исходные таймкоды —
|
||
наиболее прямое лечение подтверждённой причины.
|
||
- Ограничить длину чанка для openvino-medium (chunk_length параметр в WhisperPipeline).
|
||
- Внедрить `compression_ratio_threshold` / `log_prob_threshold` фильтры через переписывание pipeline (как у CTranslate2). Уже частично описано в [docs/gpu.md «Качественный pipeline для OpenVINO»](gpu.md#качественный-pipeline-для-openvino).
|
||
- Переключить русский CPU-дефолт на победителя сравнительного GigaAM-бенчмарка.
|
||
- Предупреждать пользователя при `--device openvino-cpu` для файлов >30 мин.
|
||
|
||
**Приоритет:** высокий — проблема затрагивает текущий OpenVINO CPU-путь, а
|
||
целевая аудитория включает ноутбуки с Intel Core i5 11-го поколения. GigaAM v3
|
||
остаётся рабочей явной альтернативой для русского, но выбор безопасного
|
||
auto/default требует сравнительного бенчмарка.
|
||
|
||
---
|
||
|
||
### Интеллектуальное чанкование длинных файлов по паузам
|
||
|
||
**Что:** Резать длинные файлы на чанки (~90 с) не по фиксированной сетке, а по ближайшей тишине: `ffmpeg -af silencedetect=noise=-40dB:d=0.5` → парсинг stderr → выбор точки разреза в окне ±30 с вокруг целевой границы (с минимальным зазором между разрезами, чтобы не получить нулевые чанки).
|
||
|
||
**Почему:** Разрез посреди слова/фразы портит распознавание на границах чанков; разрез по паузе — нет. Потенциально смягчает класс ошибок Whisper medium на длинных файлах (потеря хвоста, блоки повторов — см. пункт выше): короткие чанки не дают декодеру «уплыть».
|
||
|
||
**Источник:** референсная реализация Parakeet-сервера (Flask, OpenAI-совместимый API), лежавшая в репо как `app.py` в период эксперимента ADR-005/006 (апрель 2026); удалена при чистке 2026-07-09 — рабочие константы: порог -40dB, мин. тишина 0.5 с, окно поиска 30 с, мин. зазор 5 с.
|
||
|
||
**Tradeoff:** дополнительный проход ffmpeg по всему файлу (silencedetect) перед транскрипцией; для часового файла — десятки секунд.
|
||
|
||
---
|
||
|
||
### Качественный pipeline для OpenVINO (temperature fallback + фильтры)
|
||
|
||
**Что:** Реализовать temperature fallback, compression_ratio и log_prob фильтры поверх OpenVINO GenAI WhisperPipeline. Эвристики — логика на Python (~50-100 строк), не зависящая от inference engine.
|
||
|
||
**Почему:** Дать Intel Arc / AMD GPU и AMD CPU то же качество, что сейчас есть только у CUDA-пользователей через CTranslate2. Полностью описано в [docs/gpu.md](gpu.md#качественный-pipeline-для-openvino).
|
||
|
||
---
|
||
|
||
## Структура транскрипта (конспекты и MoM)
|
||
|
||
Источник раздела: внешнее сравнение локального транскрипта (medium,
|
||
openvino-cpu, запись 25:59) с облачным сервисом Hypescribe, критерий —
|
||
пригодность как сырья для конспекта и протокола встречи (GPT-ревью,
|
||
2026-07-10). Итог: по смыслу локальная модель почти равна облаку
|
||
(6.5/10 против 7/10), главный разрыв — **не качество распознавания,
|
||
а структура**: разделение говорящих (2/10 против 8/10) и нарезка на
|
||
реплики. Приоритеты ревьюера: 1) смысл, 2) спикеры, 3) техтермины,
|
||
4) разбивка на фразы, 5) таймкоды. Вывод: локальная диаризация +
|
||
словарь терминов закрывают потребность в облачном сервисе для
|
||
внутренних встреч.
|
||
|
||
Сознательно вне ядра CLI (максимум — рецепт в README): второй проход
|
||
LLM для чистки текста, сопоставление Speaker N с именами — это работа
|
||
поверх готового транскрипта.
|
||
|
||
### Диаризация — разделение говорящих
|
||
|
||
**Что:** Опциональный пост-процессинг (не четвёртый бэкенд): сегменты
|
||
уже несут таймкоды; диаризация даёт интервалы «кто когда говорил»;
|
||
merge по перекрытию интервалов; formatter ломает абзац на смене спикера
|
||
и подписывает `Speaker 1:`. Ставится как extra:
|
||
`uv sync --extra diarization`.
|
||
|
||
**Почему:** Без спикеров MoM не собрать — это ключевой разрыв с облаком
|
||
по внешнему ревью, и никакое качество распознавания его не компенсирует.
|
||
Заодно естественно решает «разбивку на реплики» (приоритет №4).
|
||
|
||
**Варианты реализации (ключевое решение, нужен ADR):**
|
||
|
||
- **sherpa-onnx** — диаризация целиком на onnxruntime (сегментация
|
||
pyannote в ONNX + спикер-эмбеддинги), без torch, в духе нашего
|
||
onnx-стека и «no cloud, no API keys».
|
||
- **pyannote.audio** — стандарт качества, но тянет torch и требует
|
||
HF-токен с принятием лицензии моделей — трение с духом проекта.
|
||
|
||
**Уточнить перед запуском:** качество обоих вариантов на русской речи
|
||
и перекрывающихся репликах; скорость на CPU (диаризация — второй проход
|
||
по всему аудио); лицензии моделей сегментации/эмбеддингов.
|
||
|
||
---
|
||
|
||
### Ручка нарезки абзацев в formatter
|
||
|
||
**Что:** «Минутные простыни» в транскрипте — не свойство модели, а наши
|
||
константы группировки `_PAUSE_THRESHOLD_S = 2.0` / `_MAX_PARAGRAPH_S =
|
||
60.0` в `formatter.py` (сырых сегментов много: 23-минутная запись — 360
|
||
сегментов, ~4 с на реплику). Вынести в опцию/конфиг или уменьшить
|
||
дефолт.
|
||
|
||
**Почему откладывается:** при диаризации абзацы будут ломаться по смене
|
||
спикера естественно — сначала решить с диаризацией, чтобы не делать
|
||
ручку, которая устареет.
|
||
|
||
---
|
||
|
||
### Словарь замен технических терминов — запасной план
|
||
|
||
**Что:** Пост-обработка текста сегментов словарём замен по границам слов
|
||
(`CSW → CSV`, `софтп → SFTP`, `ямлик → YAML`, `Spark и Scale → Spark
|
||
SQL`), словарь пользовательский в `.transcriber.toml`.
|
||
|
||
**Почему запасной:** это тот же класс ошибок, что «кириллизация латиницы
|
||
и искажение имён» из [ADR-006](adr/006-onnx-asr-backend.md), и первым
|
||
его должен попробовать закрыть контекстный декодер GigaAM v3 RNN-T
|
||
(первый пункт бэклога). Заводить словарь — только если бенчмарк RNN-T
|
||
термины не вытянет.
|
||
|
||
---
|
||
|
||
## Авто-детект и UX
|
||
|
||
### Профили намерения вместо выбора модели
|
||
|
||
**Что:** Вместо `--model gigaam-v3-e2e-rnnt` пользователь выбирает намерение —
|
||
условные `ru-fast`, `ru-readable`, `mixed`, — а проект разворачивает его в пару
|
||
модель + квантизация с учётом устройства.
|
||
|
||
**Почему:** Имена onnx-моделей ничего не говорят о том, что получит
|
||
пользователь, и различие «поддерживаемая модель ≠ рекомендуемая» через них не
|
||
выражается.
|
||
|
||
**Почему откладывается:** профиль осмыслен, когда известно, какой профиль чем
|
||
закрывается — то есть после сравнительной оценки. Введение понятия раньше
|
||
данных закрепит догадку в интерфейсе. Источник:
|
||
[спека «Onnx-каталог, Python 3.13 и границы версий»](specs/2026-08-11-onnx-model-catalog.md).
|
||
|
||
---
|
||
|
||
## Отклонённые направления
|
||
|
||
*(пока пусто — добавлять сюда то, что попробовали и решили не делать, с причиной)*
|