tl;dr

Глобальных метрик недостаточно, чтобы понять, хорошо ли работает ваша модель автоматического распознавания речи в вашем случае использования. Есть три шага, которые помогут вам лучше понять, насколько надежна ваша модель:

  1. Проверьте, какие функции вызывают сбои модели (проверка одномерных/двумерных функций)
  2. Проверьте, какие срезы данных (комбинации многомерных функций) вызывают сбои модели.
  3. Проверьте, какие скрытые срезы данных вызывают сбои модели на основе встраивания ваших необработанных данных.

Если вы хотите сделать то же самое с вашими данными, рассмотрите возможность использования нашей библиотеки sliceguard или визуализируйте свои данные с помощью нашего программного обеспечения для обработки данных Spotlight.

Мотивация

Современные модели автоматического распознавания речи, такие как Whisper от OpenAI, обещают отличную производительность и очень хорошо обобщаются для самых разных языков, говорящих и сценариев записи. Это делает заманчивым просто применить эти модели к вашим данным и надеяться на лучшее. Однако можем ли мы действительно доверять этим потрясающим глобальным показателям производительности? В этом посте мы узнаем и дополнительно дадим вам руководство о том, как вы оцениваете модели автоматического распознавания речи для вашего варианта использования.
Здесь основное внимание будет уделяться выявлению критических фрагментов данных, которые вызывают сбои модели, глядя за пределами глобальных показателей оценки, таких как частота ошибок в словах.

Конкретно, мы проведем вас через это, выполнив оценку модели OpenAIWhisper(Medium) на подмножестве (50 тысяч образцов) MozillaCommon Voice набор данных.
Мы сделаем это, используя нашу библиотеку с открытым исходным кодом sliceguard, которая создана для автоматического обнаружения критически важных срезов данных, а также предлагает интерактивные функции отчетности с использованием renumics -в центре внимания.

Он обрабатывает Pandas DataFrames, и для этого руководства мы будем использовать следующий формат:

| sentence      | age      | gender | accent      | prediction    | audio |                                            |
|:--------------|:---------|:-------|:------------|:--------------|:------|
| This posit... | twenties | male   | Canadian... | This posit... | 1.wav |
| Multiple M... | sixties  | female | United S... | Multiple M... | 2.wav |
| The name H... | twenties | male   | United S... | The name H... | 3.wav |
| The death ... | twenties | male   | United S... | The death ... | 4.wav |
| The study ... | twenties | female | India a...  | The study ... | 5.wav |

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

Шаг 1. Проверьте, какие функции вызывают сбои модели

Первое, что вам нужно сделать, это проверить, есть ли определенные значения признаков, которые приводят к сбою вашей модели (одномерный анализ). Если вы еще этого не сделали, установите sliceguard, который сделает всю тяжелую работу за нас:

pip install sliceguard

Чтобы запустить проверку на основе функций, просто вызовите метод find_issues только с одной функцией:

from sliceguard import SliceGuard
sg = SliceGuard()
issue_df = sg.find_issues(
    df,
    ["accent"],
    "sentence",
    "prediction",
    wer_metric,
    metric_mode="min",
    min_support=10,
    min_drop=0.04,
)

Метод принимает следующие аргументы:

  1. df — это кадр данных, содержащий все данные
  2. accent – это столбец функции, по которому следует выполнить проверку.
  3. предложение – это столбец основной истины.
  4. prediction – столбец прогнозов.
  5. wer_metric – это метрическая функция в форме metric_function(y_true, y_pred), соответствующая scikit-learn.
  6. metric_mode определяет, оптимизирована ли метрика для максимизации или минимизации.

Метод выполнит всю необходимую предварительную обработку (например, одну категориальную функцию горячего кодирования) и вернет кадр данных, в котором проблемные области отмечены в следующем формате:

| issue | issue_metric | issue_explanation     |
|:------|:-------------|:----------------------|
| 2     | 0.15         | 0.15 -> accent (1.00) |
| 2     | 0.15         | 0.15 -> accent (1.00) |
| -1    | NaN          |                       |
| 2     | 0.15         | 0.15 -> accent (1.00) |
| 1     | 0.19         | 0.19 -> accent (1.00) |

По сути, проблема — это идентификатор для каждого критического среза данных, issue_metric — это метрика, вычисляемая для среза данных, а issue_explanation пытается назвать наиболее соответствующие функции, которые могут вызвать проблему.

Обратите внимание, что есть также определенные параметры, которые существенно влияют на то, какие проблемы показывает вам библиотека. Низкие значения для min_support и высокие значения для min_drop, как правило, показывают выбросы и значительно недопредставленные выборки с очень плохой производительностью модели. Высокие значения для min_support и более низкие значения для min_drop, как правило, указывают на проблемы со справедливостью, такие как нежелательная предвзятость. Для полного анализа включите оба!

Интерактивный отчет можно просмотреть, вызвав sg.report().

Это откроет Renumics Spotlight для изучения обнаруженных проблем.

Запустив повторный анализ для трех признаков возраста, пола и акцента, мы получаем следующие основные выводы:

  1. Некоторые английские акценты, такие как шотландский и ливерпульский английский, транскрибируются значительно хуже.
  2. На большей части набора данных говорят люди с индийским/пакистанским акцентом, где модель работает хуже.
  3. Есть определенные отклонения, такие как израильский английский, которые очень недопредставлены и, следовательно, также плохо распознаются.
  4. Есть определенные возрастные группы, которые находятся ближе к краю диапазона и работают хуже, например, возрастные категории "подростки" и "80-е годы".

Шаг 2. Проверьте, какие срезы данных вызывают сбои модели

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

from sliceguard import SliceGuard
sg = SliceGuard()
issue_df = sg.find_issues(
    df,
    ["age", "gender", "accent"],
    "sentence",
    "prediction",
    wer_metric,
    metric_mode="min",
    feature_types={"age": "ordinal"},
    feature_orders={
        "age": [
            "teens",
            "twenties",
            "thirties",
            "fourties",
            "fifties",
            "sixties",
            "seventies",
            "eighties",
            "nineties",
        ]
    },
    min_support=10,
    min_drop=0.04,
)
sg.report()

Анализируя найденные проблемы в Spotlight и используя сгенерированные объяснения в качестве первой подсказки, мы внезапно получаем более подробное представление данных. Вот некоторые выводы, которые мы получаем:

  1. Проблемы, которые можно наблюдать с шотландским акцентом, в основном вызваны одной шотландкой сорокалетнего возраста. Для других динамиков падение точности не столь велико.
  2. Существует группа говорящих женщин с индийским/пакистанским акцентом, которые распознаются гораздо хуже, чем их коллеги-мужчины.
  3. Существует довольно большая группа говорящих с австралийским акцентом в подростковом возрасте, которые показывают довольно низкие результаты по сравнению с другими говорящими в Австралии. Аналогичные проблемы существуют и для других акцентов, таких как сингапурский английский.

Как вы можете видеть, хотя одномерный анализ является важной частью, без проведения многомерного анализа мы склонны делать неправильные выводы и упускать общую картину. Таким образом, вы должны вести оба!

Шаг 3. Найдите скрытые фрагменты данных

Теперь становится еще интереснее. Хотя относительно легко проводить эти проверки структурированных данных с явно заданными значениями признаков, обнаружение скрытых фрагментов данных представляет собой еще более сложную задачу. В основном это относится к неструктурированным данным, таким как изображения, аудио или текст, которые не могут быть в достаточной степени охарактеризованы путем просмотра отдельных значений функций или метаданных. Но вложения в помощь! В sliceguard вы также можете просто запускать проверки столбцов, содержащих необработанные данные:

from sliceguard import SliceGuard
sg = SliceGuard()
issue_df = sg.find_issues(
    df,
    ["sentence"],
    "sentence",
    "prediction",
    wer_metric,
    metric_mode="min",
    min_support=10,
    min_drop=0.04,
)
sg.report()

предложение здесь содержит необработанный текст, но это также могут быть пути к изображениям или аудиофайлам. Sliceguard просто автоматически вычислит вложения и проверит их. Мы также можем запустить то же самое для столбца audio.

Это дает нам следующие представления:

  1. Whisper пишет с ошибками некоторые названия мест или людей.
  2. Whisper неправильно заключает цитаты в кавычки, что приводит к снижению показателя оценки.
  3. Особенно проблема неправильного написания некоторых сложных названий мест/людей возрастает, если аудиозапись плохого качества или говорящий говорит с сильным акцентом. Есть также несколько крайних случаев, когда звук просто очень плохой, или в комнате есть другие динамики, из-за которых модель выходит из строя.
  4. Некоторые ораторы решили, что было бы неплохо прошептать определенные записи вместо того, чтобы говорить нормальным голосом. Это приводит к значительному падению точности.

Заключение

Как видите, определенно имеет смысл проверить, действительно ли возможности модели соответствуют вашим ожидаемым производственным настройкам.

Если вы считаете, что это руководство может ускорить отладку вашей модели, просто попробуйте библиотеку, посетив наш Репозиторий GitHub. Также сообщите нам, если обнаружите какие-либо проблемы или есть какие-либо запросы на добавление функций, которые сделают его применимым к вашему варианту использования.

Мы с нетерпением ждем возможности сделать библиотеку более зрелой и вскоре также опубликуем общедоступную дорожную карту, а также дополнительные примеры приложений. Дайте нам знать, если у вас есть какие-либо идеи для этого.