В проекте не было общего файла для будущих идей: docs/plan.md — историческая летопись (всё [x]), docs/gpu.md — потенциальные направления привязаны к GPU/CPU производительности, открытые вопросы из ADR легко теряются среди следующих ADR. Создан docs/backlog.md как канонический хаб для будущих экспериментов с обоснованием, цифрами и ссылками на источники. Первые записи: - GigaAM v3 RNN-T — потенциальная замена CTC-дефолта (WER 2.6% vs 13.2% на сложных текстах, e2e_rnnt c пунктуацией, 70:30 vs Whisper-large-v3 LLM-judge) - Canary 1B — multilingual + пунктуация на CPU - Whisper medium галлюцинации на длинных файлах (chunk_length / pipeline-фильтры) - Качественный pipeline для OpenVINO (давно зафиксировано в gpu.md) - Включение onnx в --device auto после стабилизации Все направления связаны ссылками на источники (ADR-006, gpu.md, публикации SberDevices), чтобы при возврате к работе не пришлось воспроизводить контекст. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
7.8 KiB
Backlog — будущие эксперименты и направления
Список открытых направлений, которые имеют смысл, но не реализованы. Каждый пункт содержит обоснование и ссылку на источник (ADR / статья), чтобы при возврате не пришлось воспроизводить контекст с нуля.
Когда направление становится в работу — переносится в spec/план или соответствующий ADR. Когда отклоняется — остаётся в backlog с пометкой «отклонено» и причиной (для истории решений).
ASR-бэкенды и модели
GigaAM v3 RNN-T — потенциальная замена CTC-дефолта для --device onnx
Что: Прогнать gigaam-v3-rnnt (или v3_e2e_rnnt если доступен через onnx-asr) по той же методологии, что и в ADR-006: 3 файла × agent-judge × 4 критерия.
Почему интересно:
- 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) — оценка, нужна верификация.
Если подтвердится бенчмарком:
- Дефолт в
--device onnxменяется сgigaam-v3-ctcнаgigaam-v3-rnnt. openvino-cpu mediumуходит из рекомендаций для русского.- Формулировка «GPU faster-whisper large-v3 — эталон» в README может стать неточной.
- Пишется ADR-007 с переоценкой дефолта.
Уточнить перед запуском: какой именно вариант RNN-T доступен в onnx-asr (gigaam-v3-rnnt без пунктуации vs v3_e2e_rnnt с пунктуацией). Проверить через huggingface_hub listing для istupakov/gigaam-v3-onnx.
Canary 1B — multilingual + пунктуация на CPU
Что: Протестировать nemo-canary-1b-v2 через onnx-asr на тех же 3 файлах.
Почему: Multilingual + пунктуация в одной модели. Кандидат на «лучшее качество за разумную скорость» для пользователей, которым нужны и не-русский контент, и пунктуация одновременно. Упомянут в ADR-006.
Tradeoff: Тяжелее GigaAM (~1 GB vs ~300 MB), скорость на CPU ожидаемо ниже. Если RNN-T закроет потребность в пунктуации — Canary становится менее приоритетным.
Качество и устойчивость
Whisper medium галлюцинации на длинных файлах с тихими фрагментами
Что: Воспроизвести и зафиксировать класс ошибок: 12-02-37 теряет 17 минут хвоста, Vasya имеет 5-минутные блоки повторов, появляются несуществующие имена (Валерий Сюткин). Источник: agent-judge в ADR-006.
Возможные направления:
- Ограничить длину чанка для openvino-medium (chunk_length параметр в WhisperPipeline).
- Внедрить
compression_ratio_threshold/log_prob_thresholdфильтры через переписывание pipeline (как у CTranslate2). Уже частично описано в docs/gpu.md «Качественный pipeline для OpenVINO». - Предупреждать пользователя при
--device openvino-cpuдля файлов >30 мин.
Приоритет: средний — пока есть gigaam-v3 как альтернатива для русского. Критично, если openvino остаётся единственным вариантом для пунктуации (отпадает после теста RNN-T).
Качественный 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.
Авто-детект и UX
Включение onnx в --device auto
Что: После периода стабилизации --device onnx (несколько недель production-использования без жалоб) — рассмотреть включение в auto-detect chain.
Порядок в chain (предложение): CUDA → onnx (если CPU x86_64) → OpenVINO → CPU.
Почему откладывается: политика experimental backend — не сюрпризить существующих пользователей до накопления опыта. Источник: ADR-006.
Отклонённые направления
(пока пусто — добавлять сюда то, что попробовали и решили не делать, с причиной)