Выбрать единицу привязки спикера к тексту #14

New Issue

2026-08-12T15:05:35+03:00

ddmitry commented

2026-08-12 15:05:35 +03:00

Часть карты: Карта: диаризация спикеров в транскрипте (#8)

Question

Делаем ли мы диаризацию — и если да, к чему приписывается метка говорящего?

Это главная развилка карты, и решение принимается сразу по двум вопросам:
стоит ли функция своей цены и в какой форме её строить. Схема из бэклога —
мажоритарный спикер на весь ASR-сегмент — разведкой не подтвердилась.

Варианты:

пословная привязка: onnx-asr отдаёт потокенные таймкоды
(TimestampedResult с timestamps, tokens, logprobs), сегмент режется на
границе токена при смене говорящего. ASR по-прежнему видит длинное аудио, так
что контекст RNN-T и пунктуация не страдают. OpenVINO GenAI 2026.x upstream
уже отдаёт word-level timestamps на CPU/GPU/NPU, но проектный backend сводит
результат к chunk-сегментам. Цена — протокол Backend/TranscribeResult,
вероятно, придётся сделать timestamp-aware;
диаризация первым проходом, ASR по интервалам говорящего: чистота
гарантирована конструкцией, но короткие куски лишают RNN-T контекста и портят
пунктуацию — ровно то, ради чего в ADR-006 выбрана модель e2e-rnnt;
привязка к сегменту с честной пометкой: оставить огрубление, но считать
чистоту и предупреждать в шапке — так проект уже поступает с повторами и
потерей хвоста (quality.py, маркеры «Внимание»);
не делать диаризацию — нулевой вариант. Цена известна и велика: удвоение
времени обработки плюс две модели в зависимостях. Если замер на целевом i5
окажется тяжёлым, а доля загрязнённых сегментов на других записях — низкой,
этот вариант становится честным ответом. Тогда разрыв с облаком по разделению
говорящих остаётся, а formatter.py получает только более дешёвую ручку
нарезки абзацев.

Решение опирается на замеренную долю загрязнённых сегментов, на проверку границ
на слух и на стоимость на целевом железе. Research о жизненном цикле движков
показал, что ограничение OpenVINO-пути лежит в проектной интеграции, а не в
движке. Это не блокирует выбор: решение должно назвать нужное изменение
контракта таймкодов, а fallback-поведение остаётся тикету про UX.

Ответ фиксирует, делаем ли мы диаризацию, выбранную единицу привязки,
отклонённые варианты с причинами и то, какие изменения в протоколе бэкендов
потребуются.

Часть карты: [Карта: диаризация спикеров в транскрипте](https://git.dementev.space/ddmitry/local-transcriber/issues/8) (#8) ## Question Делаем ли мы диаризацию — и если да, к чему приписывается метка говорящего? Это главная развилка карты, и решение принимается сразу по двум вопросам: стоит ли функция своей цены и в какой форме её строить. Схема из бэклога — мажоритарный спикер на весь ASR-сегмент — разведкой не подтвердилась. Варианты: - **пословная привязка**: `onnx-asr` отдаёт потокенные таймкоды (`TimestampedResult` с `timestamps`, `tokens`, `logprobs`), сегмент режется на границе токена при смене говорящего. ASR по-прежнему видит длинное аудио, так что контекст RNN-T и пунктуация не страдают. OpenVINO GenAI 2026.x upstream уже отдаёт word-level timestamps на CPU/GPU/NPU, но проектный backend сводит результат к chunk-сегментам. Цена — протокол `Backend`/`TranscribeResult`, вероятно, придётся сделать timestamp-aware; - **диаризация первым проходом**, ASR по интервалам говорящего: чистота гарантирована конструкцией, но короткие куски лишают RNN-T контекста и портят пунктуацию — ровно то, ради чего в ADR-006 выбрана модель `e2e-rnnt`; - **привязка к сегменту с честной пометкой**: оставить огрубление, но считать чистоту и предупреждать в шапке — так проект уже поступает с повторами и потерей хвоста (`quality.py`, маркеры «Внимание»); - **не делать диаризацию** — нулевой вариант. Цена известна и велика: удвоение времени обработки плюс две модели в зависимостях. Если замер на целевом i5 окажется тяжёлым, а доля загрязнённых сегментов на других записях — низкой, этот вариант становится честным ответом. Тогда разрыв с облаком по разделению говорящих остаётся, а `formatter.py` получает только более дешёвую ручку нарезки абзацев. Решение опирается на замеренную долю загрязнённых сегментов, на проверку границ на слух и на стоимость на целевом железе. Research о жизненном цикле движков показал, что ограничение OpenVINO-пути лежит в проектной интеграции, а не в движке. Это не блокирует выбор: решение должно назвать нужное изменение контракта таймкодов, а fallback-поведение остаётся тикету про UX. Ответ фиксирует, делаем ли мы диаризацию, выбранную единицу привязки, отклонённые варианты с причинами и то, какие изменения в протоколе бэкендов потребуются.

ddmitry added the wayfinder:grilling label 2026-08-12 15:05:35 +03:00

ddmitry added a new dependency 2026-08-12 15:07:16 +03:00

#9 Куда движутся ONNX Runtime и OpenVINO: сравнение жизненного цикла

ddmitry added a new dependency 2026-08-12 15:07:17 +03:00

#11 Чистота ASR-сегментов: подтвердить долю загрязнённых на трёх записях

ddmitry added a new dependency 2026-08-12 15:07:17 +03:00

#12 Проверить границы диаризации на слух

ddmitry added a new dependency 2026-08-12 15:07:18 +03:00

#15 Формат транскрипта со спикерами

ddmitry added a new dependency 2026-08-12 15:07:18 +03:00

#16 UX диаризации: флаг, число участников, зависимость и поведение на OpenVINO

ddmitry added a new dependency 2026-08-12 15:07:19 +03:00

#17 Свести решения карты в ADR и спеку

ddmitry removed a dependency 2026-08-12 15:16:46 +03:00

#9 Куда движутся ONNX Runtime и OpenVINO: сравнение жизненного цикла

ddmitry added a new dependency 2026-08-12 15:16:46 +03:00

#13 Производительность диаризации на целевом Intel Core i5

ddmitry referenced this issue

2026-08-12 16:13:34 +03:00

Куда движутся ONNX Runtime и OpenVINO: сравнение жизненного цикла #9

ddmitry self-assigned this 2026-08-14 14:01:35 +03:00

ddmitry commented

2026-08-14 14:17:07 +03:00

Решение

Диаризацию делать как явно включаемую функцию. Изначально она выключена; вопрос о включении по умолчанию пересматривается после реализации и пользовательского тестирования.

Единица привязки говорящего — слово с временной привязкой. Слово здесь не становится единицей запуска ASR: модель по-прежнему распознаёт целый сегмент распознавания, сохраняет контекст RNN-T, согласование и пунктуацию. Backend-специфичные токены или words приводятся к каноническим словам с положением на временной шкале; каждому слову назначается говорящий, соседние слова одного говорящего затем образуют реплику.

Проход распознавания и проход диаризации независимо получают одно аудио. Ни один не принимает результат другого; их результаты совмещаются только после завершения обоих. Поэтому первая реализация может быть последовательной, не блокируя будущий параллельный запуск.

Изменение общего контракта

результат распознавания должен уметь отдавать канонические слова с временной привязкой наряду с существующими сегментами;
результат диаризации остаётся отдельным набором интервалов говорящих;
сведение слов и интервалов — отдельная операция после обоих проходов, а не обязанность ASR-бэкенда или движка диаризации;
поведение бэкендов и моделей без подходящих таймкодов решается в тикете про UX.

Отклонённые варианты

Диаризация до ASR и распознавание коротких интервалов говорящего: ухудшает контекст и пунктуацию RNN-T.
Мажоритарный говорящий на весь сегмент распознавания: смешение подтверждено на всех трёх записях — 6–7% сегментов в разговорах на двоих и 27% во встрече втроём.
Не делать диаризацию: оставляет главный продуктовый разрыв, хотя на слабом Intel baseline последовательная обработка часа занимает около 23 минут и признана приемлемой для opt-in-функции.

Параллельная оркестрация, распределение CPU-потоков и условия последовательного fallback выносятся в отдельный тикет. Отображение перекрывающейся речи и пунктуации на границе реплик остаётся тикету про формат.

Канонические термины добавлены в CONTEXT.md: коммит 26d4ca2.

## Решение Диаризацию делать как явно включаемую функцию. Изначально она выключена; вопрос о включении по умолчанию пересматривается после реализации и пользовательского тестирования. **Единица привязки говорящего — слово с временной привязкой.** Слово здесь не становится единицей запуска ASR: модель по-прежнему распознаёт целый сегмент распознавания, сохраняет контекст RNN-T, согласование и пунктуацию. Backend-специфичные токены или words приводятся к каноническим словам с положением на временной шкале; каждому слову назначается говорящий, соседние слова одного говорящего затем образуют реплику. Проход распознавания и проход диаризации независимо получают одно аудио. Ни один не принимает результат другого; их результаты совмещаются только после завершения обоих. Поэтому первая реализация может быть последовательной, не блокируя будущий параллельный запуск. ### Изменение общего контракта - результат распознавания должен уметь отдавать канонические слова с временной привязкой наряду с существующими сегментами; - результат диаризации остаётся отдельным набором интервалов говорящих; - сведение слов и интервалов — отдельная операция после обоих проходов, а не обязанность ASR-бэкенда или движка диаризации; - поведение бэкендов и моделей без подходящих таймкодов решается в тикете про UX. ### Отклонённые варианты - **Диаризация до ASR и распознавание коротких интервалов говорящего:** ухудшает контекст и пунктуацию RNN-T. - **Мажоритарный говорящий на весь сегмент распознавания:** смешение подтверждено на всех трёх записях — 6–7% сегментов в разговорах на двоих и 27% во встрече втроём. - **Не делать диаризацию:** оставляет главный продуктовый разрыв, хотя на слабом Intel baseline последовательная обработка часа занимает около 23 минут и признана приемлемой для opt-in-функции. Параллельная оркестрация, распределение CPU-потоков и условия последовательного fallback выносятся в отдельный тикет. Отображение перекрывающейся речи и пунктуации на границе реплик остаётся тикету про формат. Канонические термины добавлены в `CONTEXT.md`: коммит `26d4ca2`.

ddmitry closed this issue

2026-08-14 14:17:08 +03:00

ddmitry added a new dependency 2026-08-14 14:17:49 +03:00

#21 Параллельный запуск ASR и диаризации: политика и бюджет CPU

ddmitry referenced this issue

2026-08-14 14:18:14 +03:00

Карта: диаризация спикеров в транскрипте #8

Sign in to join this conversation.