indic-turn-detector - открытая модель определения конца реплики (end-of-turn, EOU) для голосовых агентов. Она дообучена на базе Qwen2.5-0.5B, получает живой транскрипт разговора и предсказывает, закончил ли собеседник фразу. Практический смысл простой: агент перестаёт вступать на паузе, когда человек ещё не произнёс главное слово.
Поддерживаются английский, хинглиш, хинди, телугу, тамильский, маратхи, бенгальский, гуджарати и панджаби. Инференс полностью локальный: CPU, ONNX Runtime, около 2 ГБ памяти в fp32, без облачных вызовов. Модель работает только с текстом, поэтому STT нужен свой. Для LiveKit Agents есть drop-in плагин с тем же интерфейсом, что у их текстового turn detector, лицензия Apache-2.0.
Цифры, которые приводит автор публикации: 91,3% TPR на отложенной валидации при калибровке на ~10% ложных обрывов на незавершённых репликах, AUC 0.967. На официальном речевом харнессе LiveKit для хинди заявлено 85,3% детекции при том же бюджете ошибок (пост о релизе).
Что такое indic-turn-detector и зачем он нужен
Задача EOU-детектора формулируется в одну строку: по уже распознанному тексту понять, поставил ли человек точку. Модель получает транскрипт, накопленный с начала реплики, и выдаёт оценку завершённости. Агент смотрит на эту оценку и решает, отвечать сейчас или дождаться продолжения.
В английском такая проверка часто кажется избыточной: пауза в конце фразы обычно и означает конец фразы. В индийских языках эта эвристика ломается, и именно на ней построена мотивация релиза.
Чем EOU-детектор отличается от VAD
VAD (voice activity detection) отвечает на вопрос «есть ли сейчас речь в аудиопотоке». Он видит энергию сигнала и тишину, слов он не видит вообще. Формулировка из публикации точная: VAD слышит тишину, а не смысл.
| Критерий | VAD | indic-turn-detector |
|---|---|---|
| Что анализирует | Аудиосигнал, наличие и отсутствие речи | Текст транскрипта |
| На что реагирует | На тишину | На смысловую завершённость реплики |
| Порядок слов в языке | Не учитывает | Учитывает косвенно, через обучение на индийских языках |
| Нужен ли STT | Нет | Да, свой |
| Ресурсы | Минимальные | Около 2 ГБ в fp32, CPU через ONNX Runtime |
| Роль в пайплайне | Сегментация аудио | Решение «ждать или отвечать» |
Отсюда ключевое следствие: indic-turn-detector не заменяет VAD. VAD режет поток на сегменты и подсказывает, когда отправлять аудио в распознавание. EOU-детектор добавляет поверх текста смысловой слой, которого у VAD нет в принципе.
На какой базе построена модель
Модель дообучена из Qwen2.5-0.5B. Параметров у базовой LLM около 0,5 млрд, и это объясняет скромные требования: 0,5 млрд весов во fp32 дают примерно 2 ГБ, что совпадает с заявленным потреблением памяти. Небольшая языковая модель уверенно живёт на CPU, поэтому облачный инференс здесь не нужен.
Деталей обучения в публикации нет: ни состава датасета, ни схемы разметки, ни гиперпараметров. Воспроизвести тренировку по посту не получится. Для практики важнее другое: открытые веса, Apache-2.0 и готовый путь до ONNX Runtime.
Почему обычный VAD обрывает звонящего на индийских языках
В индийских языках глагол стоит в конце фразы. Сказуемое приходит последним, а до него идёт всё остальное: кто, когда, по какому вопросу. Человек делает естественную паузу перед завершающим словом, и для VAD эта пауза ничем не отличается от конца реплики.
«aapko kal phone…» - тишина, VAD фиксирует конец реплики, бот вступает. А дальше должно было прозвучать «kar dunga».
Дальше сценарий повторяется в любом звонке: агент перебивает, человек слышит ответ поверх своей фразы, приходится начинать заново. Проблема не в плохом STT и не в слабой LLM, а в том, что слой определения конца реплики смотрел не туда.
Что такое ложный обрыв и почему он дорого стоит
Ложный обрыв (false cut) - ситуация, когда агент решил, что реплика закончена, и вступил, хотя человек ещё не договорил. В проде это самая заметная ошибка EOU: пользователь слышит наложение речи, диалог сбивается, приходится переспрашивать. Именно поэтому метрика в модели задаётся не сама по себе, а при фиксированном бюджете ложных обрывов: около 10% ошибок на незавершённых репликах.
Бюджет - это осознанный компромисс. Ужесточите его, и детектор начнёт чаще ждать, а вместе с этим вырастет задержка ответа на нормальных завершённых репликах. Ослабьте, и агент снова начнёт перебивать.
Как работает indic-turn-detector в пайплайне голосового агента
- Аудио с микрофона проходит через VAD и уходит в ваш STT.
- Распознанный текст накапливается с начала реплики и подаётся в indic-turn-detector.
- Модель выдаёт оценку завершённости: реплика закончена или ещё нет.
- Агент либо отвечает, либо держит паузу и продолжает слушать.
Модель text-only. Без собственного STT она бесполезна, и это не мелкое ограничение, а архитектурное свойство. Качество распознавания напрямую влияет на решение о конце реплики: если STT потерял последнее слово, детектор увидит обрубок фразы. О том, почему для индийских языков одного общего WER недостаточно и какие метрики добавились в Open ASR Leaderboard для Hindi и Indian English, стоит прочитать отдельно перед выбором STT.
Требования к окружению и локальный запуск
| Параметр | Значение |
|---|---|
| Среда инференса | ONNX Runtime, только CPU |
| Память | Около 2 ГБ в fp32 |
| Облако | Не требуется |
| Вход | Текст транскрипта |
| Языки | 9, включая хинглиш и хинди |
| Лицензия | Apache-2.0 |
Команд установки и версий пакетов в публикации нет, поэтому конкретные шаги берутся из репозитория модели и плагина. Общий порядок такой: поднять STT, отдать накопленный транскрипт в ONNX-инференс, выставить порог решения под свой бюджет ложных обрывов и проверить поведение на записях реальных звонков.
Лицензия Apache-2.0 разрешает использование в коммерческих продуктах, включая закрытые. 2 ГБ памяти означают, что детектор уживётся на том же хосте, где уже крутится STT или телефония, отдельная видеокарта под него не нужна.
Интеграция с LiveKit Agents
Для LiveKit Agents выпущен drop-in плагин с тем же интерфейсом, что у их текстового turn detector. То есть замена встраивается в существующую логику без переписывания обработки ходов диалога. В публикации также сказано, что модель проверена вживую на LiveKit Cloud: она удерживала паузы в середине запроса и фиксировала завершённые запросы.
Для других фреймворков готовой обвязки в публикации не описано. Сама модель работает через ONNX Runtime, так что вызвать её из собственного кода можно, но интеграцию придётся писать самостоятельно.
Заявленные метрики: что на самом деле показывают 91,3% и 85,3%
TPR, AUC и бюджет ложных обрывов простыми словами
TPR (true positive rate) - доля завершённых реплик, которые детектор правильно распознал как завершённые. Бюджет ложных обрывов - допустимая доля ошибок на незавершённых репликах: сколько раз агент может вступить раньше времени. AUC 0.967 показывает, насколько хорошо модель разделяет два класса по всему диапазону порогов, без привязки к конкретной точке отсечения.
Цифра 91,3% TPR сама по себе не значит ничего. Смысл она получает только в связке с бюджетом: при калибровке на ~10% ложных обрывов на незавершённых репликах модель находит 91,3% завершённых. Поменяйте бюджет, и процент сдвинется.
Почему речевой харнесс даёт более скромный результат
91,3% получены на отложенной валидации автора. 85,3% - результат на официальном речевом харнессе LiveKit, и относится он только к хинди, при том же бюджете ложных обрывов (исходные данные автора). Разрыв около 6 процентных пунктов - это цена перехода от валидационного набора к реальной телефонной речи: шум, акценты, огрехи STT, обрывы связи.
Из 85,3% нельзя выводить качество на телугу, тамильском или бенгальском. По этим языкам в публикации отдельных речевых замеров нет. Независимых проверок метрик тоже нет: все цифры приведены по данным автора и относятся к указанным наборам оценки.
Кому стоит подключать indic-turn-detector, а кому - нет
Стоит пробовать, если совпадает большинство пунктов:
- голосовой агент работает на индийских языках, в первую очередь на хинди или хинглише;
- свой STT уже есть и выдаёт стабильный транскрипт;
- нужен локальный инференс без облака и без видеокарты;
- стек собран на LiveKit Agents, и плагин ставится заменой существующего детектора;
- лицензия Apache-2.0 подходит под требования продукта.
Скорее не подходит, если хотя бы одно из условий критично:
- своего STT нет: модель анализирует только текст;
- языки сценария не входят в список девяти;
- нужна точность, подтверждённая независимыми замерами, а не автором релиза;
- инференс строится на GPU или на облачном сервисе, а не на CPU через ONNX Runtime.
Ограничения, о которых нужно знать заранее
- Только текст. Без STT модель бесполезна, и качество распознавания напрямую задаёт потолок качества детекции.
- Метрики от автора. 91,3% TPR и AUC 0.967 получены на его отложенной валидации, 85,3% - на харнессе LiveKit. Внешних подтверждений нет.
- Речевой замер только по хинди. На остальные восемь языков списка 85,3% не распространяются.
- Ресурсы. Около 2 ГБ в fp32, ориентация на CPU-инференс через ONNX Runtime; квантизованные варианты в публикации не заявлены.
- Привязка к LiveKit. Готовый drop-in плагин есть для LiveKit Agents, для других фреймворков интеграцию пишут сами.
Часть ошибок приходит не от EOU-детектора, а из предыдущего слоя. Промахи ASR на ключевых словах и общая задержка связки STT → LLM → TTS остаются главными барьерами голосовых агентов, и смена детектора конца реплики их не снимает. Подробнее об этом в разборе почему у голосового AI всё ещё нет своего момента ChatGPT.
Чем indic-turn-detector отличается от альтернатив и что дальше
| Подход | Что учитывает | Ограничение |
|---|---|---|
| Обычный VAD | Наличие речи и тишину в аудиосигнале | Не понимает слов, обрывает на паузе перед глаголом |
| Текстовый turn detector LiveKit | Смысл по транскрипту, интерфейс которого повторяет новый плагин | Характеристики по языкам и метрики в источнике не приводятся |
| indic-turn-detector | Смысл по транскрипту и специализацию на девяти языках, включая хинглиш | Только текст, метрики по данным автора, речевой замер лишь по хинди |
Главное отличие от обычного VAD - уровень анализа: смысл вместо тишины. Отличие от общего текстового детектора - специализация: хинглиш, хинди, телугу, тамильский, маратхи, бенгальский, гуджарати, панджаби в списке поддерживаемых языков. Плюс локальный CPU-инференс и Apache-2.0.
Открытая лицензия и drop-in плагин снижают порог входа до нескольких часов работы. Независимых проверок пока нет, поэтому решение разумно принимать по своим данным: возьмите записи реальных звонков с паузами перед завершающим словом, прогоните через свой STT и сравните число ложных обрывов с текущим порогом. Если на ваших записях детектор удерживает паузу там, где старый слой вступал, замена оправдана. Если разницы не видно на хинди, на остальные языки лучше не экстраполировать (публикация с деталями и фидбеком).