VAD: как ИИ находит речь в аудиозаписи

VAD: как ИИ находит речь в аудиозаписи — это задача определить, в каких окнах записи присутствует голос. Модель получает звук короткими фрагментами и для каждого выносит решение «речь» или «тишина». Дальше эти метки задают границы участков, которые уходят в распознавание.

Что именно решает детектор речи

Документация Miuda описывает VAD как инструмент, который определяет наличие речи во входном аудио. При появлении голоса срабатывает событие Speaking, а после периода тишины — событие Silence. Эти два события и есть весь выход детектора: интервалы, где голос есть, и интервалы, где его нет.

Документация LLMRTC формулирует вопрос ещё короче: детектор отвечает, говорит ли пользователь прямо сейчас. Там же приведена таблица параметров, где positiveSpeechThreshold по умолчанию равен 0.5, а negativeSpeechThreshold — 0.35. Первый задаёт уверенность, нужную для старта речи, второй — уровень, ниже которого речь считается завершённой.

Проект Silero VAD на GitHub добавляет к этому практическую рамку. Модель поставляется как предобученный детектор, работает с частотой дискретизации 8000 Гц и 16000 Гц, а один фрагмент длиной от 30 мс обрабатывается на одном потоке CPU менее чем за 1 мс. JIT-модель занимает около двух мегабайт.

Из этих трёх описаний складывается точная граница возможностей. Детектор выдаёт временные метки присутствия голоса. Расшифровку слов он не делает. Имя говорящего он не определяет. Смысл сказанного он не оценивает.

Временная схема: разметка шести окон

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

Ручной эталон speech/no-speech выглядит так: 0, 1, 1, 0, 1, 0. Три окна отмечены как речь, три — как её отсутствие. Теперь возьмём вымышленное предсказание детектора: 0, 1, 0, 0, 1, 1. Тоже три окна с меткой речи.

Совпадение по сумме скрывает расхождение по существу. Заполненная сверка выглядит так: A даёт TN, B даёт TP, C даёт FN, D даёт TN, E даёт TP, F даёт FP. Итог: TP = 2, FN = 1, FP = 1, TN = 2. Тихая речь в окне C потеряна, шум в окне F принят за голос. Суммарная длительность речи по эталону и по предсказанию совпадает, а результат работы расходится.

Этот разбор показывает, почему одной цифры «сколько секунд речи найдено» недостаточно. Нужны обе ошибки по отдельности: пропуск и ложное срабатывание. Пропуск режет начало фразы или теряет тихую реплику. Ложное срабатывание отправляет в распознавание шум, из которого модель вытягивает случайные слова.

Три разные задачи: detection, ASR, diarization

Путаница начинается там, где все три задачи называют одним словом «распознавание». Разведём их по выходу.

Один VAD не выдаёт расшифровку, имя говорящего или оценку правильности его слов. Документация LiveKit прямо указывает, что плагин Silero VAD вносит вклад в определение реплик (turn detection) в голосовых приложениях, и рекомендует использовать его вместе с отдельной моделью turn detector. Это два разных компонента: детектор речи и определитель конца реплики.

Отсюда следует практический вывод. Утверждение «VAD распознал Анну» описывает задачу, которой детектор не занимается. Чтобы назвать имя Анна, нужны сведения о личности, которых метки VAD не содержат. Детектор лишь отмечает, что в этом интервале кто-то говорил.

Пауза и конец реплики

В учебной шкале окно D — пауза между двумя участками речи. По условию примера человек продолжает мысль в окне E. Если объявить конец всего хода по первой паузе, система оборвёт говорящего на середине.

Документация Miuda описывает отдельные параметры speech_padding, silence_padding и silence_timeout. speech_padding задаёт задержку начала обнаружения после начала речи и по умолчанию равен 250 мс; silence_padding относится к длительности тишины; silence_timeout — дополнительный таймаут в миллисекундах, по умолчанию он не задан.

Документация LiveKit даёт свои значения по умолчанию для метода load: min_speech_duration 0.05, min_silence_duration 0.55, prefix_padding_duration 0.5, max_buffered_speech 60.0, activation_threshold 0.5, sample_rate 16000, force_cpu True. Значения из LiveKit и Miuda разные. Переносить их между SDK как универсальную настройку нельзя.

Параметр prefix_padding_duration добавляет звук перед моментом срабатывания, чтобы не отрезать начало слова. Параметр min_silence_duration задаёт, сколько тишины ждать перед выводом о завершении речи. Эти два параметра решают разные проблемы: первый защищает начало фразы, второй — её конец.

Порог срабатывания и его цена

Порог — самый заметный регулятор детектора. Документация Miuda описывает зависимость прямо: большее значение строже и может пропустить обнаружение, меньшее — мягче и может дать ложные срабатывания. Документация LiveKit формулирует то же самое: высокий порог ведёт к консервативному обнаружению с риском пропустить тихую речь, низкий — к чувствительному с риском принять шум за речь.

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

Проверить, куда сместился баланс, помогает тот же учебный timeline. Если после настройки окно C по-прежнему даёт FN, порог завышен для тихой речи. Если окно F даёт FP, порог занижен для фонового шума. Правка одного параметра обычно двигает обе ошибки в противоположные стороны, поэтому смотреть нужно на пару значений.

Практика: как получить метки речи

Проект Silero VAD на GitHub показывает минимальный путь. Установка идёт командой pip install silero-vad, либо pip install silero-vad, если аудио загружается самостоятельно. Дальше модель загружается, файл читается, и вызов get_speech_timestamps возвращает метки. Параметр return_seconds=True переводит вывод в секунды, по умолчанию значения идут в сэмплах.

Полный учебный скрипт с проверкой по эталону:

import os

# Полностью заданная ручная пара; это не результат Silero.
reference = [0, 1, 1, 0, 1, 0]
prediction = [0, 1, 0, 0, 1, 1]

def confusion_counts(reference, prediction):
    if len(reference) != len(prediction):
        raise ValueError("Разметки должны иметь одинаковое число окон")
    if any(x not in (0, 1) for x in reference + prediction):
        raise ValueError("Разрешены только метки 0 и 1")
    return {
        "TP": sum(r == 1 and p == 1 for r, p in zip(reference, prediction)),
        "FN": sum(r == 1 and p == 0 for r, p in zip(reference, prediction)),
        "FP": sum(r == 0 and p == 1 for r, p in zip(reference, prediction)),
        "TN": sum(r == 0 and p == 0 for r, p in zip(reference, prediction)),
    }

print({"manual_example": confusion_counts(reference, prediction)})

# Необязательная обработка собственного файла после установки silero-vad.
# Её результат нельзя сравнивать с вымышленным reference выше.
audio_path = os.environ.get("VAD_AUDIO_PATH")
if audio_path:
    from silero_vad import load_silero_vad, read_audio, get_speech_timestamps

    model = load_silero_vad()
    wav = read_audio(audio_path)
    speech_timestamps = get_speech_timestamps(wav, model, return_seconds=True)
    print({"speech_timestamps_seconds": speech_timestamps})
else:
    print("VAD_AUDIO_PATH не задан; реальное аудио не обрабатывалось.")

Без VAD_AUDIO_PATH скрипт пересчитывает полностью заданную ручную пару: TP = 2, FN = 1, FP = 1, TN = 2. Если задать путь к собственному файлу через VAD_AUDIO_PATH, дополнительная ветвь выводит фактические временные метки Silero в секундах. Для оценки этого файла сначала нужна собственная ручная разметка; вымышленный эталон из шести окон к произвольному аудио не применяется.

Порядок работы с реальной записью выглядит так. Сначала прослушать спорные участки, отмеченные как границы речи. Затем отдельно оценить детектор по меткам, расшифровку по тексту и порядок реплик по последовательности. Удалять из исходного файла все окна без речи без прослушивания не требуется, чтобы понять термин.

Отрицательная контрольная проба

Контрольная проба проверяет, что счёт не подменён удобным выводом. Возьмём утверждение: «детектор нашёл три секунды, значит все слова сохранены». По учебной шкале оно неверно. Три секунды найдены и в эталоне, и в предсказании, но окно C потеряно, а окно F добавлено. Слова из тихой речи в расшифровку не попадут.

Вторая проба: «VAD распознал Анну». Одних меток активности речи недостаточно, чтобы установить имя говорящего.

Если расхождение обнаружено, порядок исправления такой. Сначала прослушать окна с FN и FP. Затем поднять или опустить порог и пересчитать счётчики. После этого отдельно проверить расшифровку на участках, которые детектор пропустил, и порядок реплик на участках, где он сработал ложно. Каждая проверка отвечает за свой компонент.

Частые вопросы

Что такое VAD простыми словами?

VAD — детектор активности голоса. Он получает аудио короткими фрагментами и для каждого решает, есть ли в нём речь. На выходе получаются временные метки участков с голосом. Документация Miuda описывает это через события Speaking и Silence.

Чем VAD отличается от распознавания речи?

Детектор отвечает на вопрос, есть ли речь в окне. Система распознавания отвечает, какие слова произнесены. Документация LiveKit описывает плагин Silero VAD как компонент определения реплик и рекомендует сочетать его с отдельной моделью turn detector.

Почему детектор пропускает тихую речь?

Высокий порог срабатывания требует большей уверенности для старта речи. Документация LiveKit указывает, что высокий порог даёт консервативное обнаружение с риском пропустить тихую речь. Снижение порога повышает чувствительность и увеличивает риск принять шум за голос.

Как проверить качество детектора на своей записи?

Нужен ручной эталон: разметить окна как речь и тишину, затем сравнить с предсказанием. Считать TP, FN, FP и TN по отдельности. Одинаковая суммарная длительность речи в эталоне и предсказании может скрывать и пропуск, и ложное срабатывание.

Можно ли переносить настройки VAD между SDK?

Значения по умолчанию у разных проектов различаются. Документация LiveKit приводит min_silence_duration 0.55 и activation_threshold 0.5, документация Miuda — задержку от начала речи 250 мс и порог 0.5. Эти наборы описывают разные реализации и переносятся только после проверки на своей записи.