Интерпретация оценки распознавания

Каждое совпадение, возвращаемое AudD, содержит оценку. На этой странице объясняется, что это за оценка, чем она не является и — что действительно важно — как превратить ее в решение: когда автоматически принимать совпадение, когда блокировать его, а когда отправлять на проверку человеку. Это руководство предназначено для всех, кто создает рабочий процесс, где цена ошибочного совпадения не является симметричной, например, при фильтрации авторских прав или отображении виджета «сейчас играет».

Кратко

• Совпадение включает оценку — целое число, которое можно рассматривать как индикатор достоверности от 0 до 100, где более высокое значение означает, что AudD более уверен в совпадении. Реальные ответы содержат такие значения, как 81.
• Эта оценка не является вероятностью и не представляет собой процент совпадения песни. Это относительный сигнал достоверности, полезный для ранжирования и установки пороговых значений.
• Совпадение возвращается только тогда, когда AudD достаточно уверен в нем. Оценка позволяет вам установить более строгий критерий поверх этого.
• Правильный порог зависит от конкретного приложения. В процессе блокировки авторских прав следует установить высокую планку (ложноположительные результаты обходятся дорого). Виджет «сейчас играет» может установить низкую планку (неправильная песня безвредна).
• Не используйте жестко закодированное число из статьи в блоге. Проведите калибровку на собственных данных — пропустите реальные входные данные через API, посмотрите на оценки для заведомо правильных и заведомо неправильных совпадений и выберите точки отсечения, соответствующие вашим допускам.

Почему это важно

Распознавание дает ответ «да» или «нет»: либо возвращается совпадение, либо result: null. Но «совпадение найдено» и «я должен действовать на основе этого совпадения» — это не одно и то же. Стоимость действий при ошибочном совпадении сильно варьируется в зависимости от приложения.

Рассмотрим два процесса, которые вызывают один и тот же эндпоинт:

• Фильтр авторских прав, который блокирует загрузки, содержащие найденный трек. Ложноположительный результат здесь блокирует легальный контент автора — это реальный ущерб, возможная апелляция, возможная потеря пользователя. Вы хотите быть абсолютно уверены, прежде чем действовать.
• Виджет «сейчас играет», который показывает слушателю, какая песня звучит. Ложноположительный результат показывает неверное название на несколько секунд. Никто не пострадал; следующее совпадение исправит это. Вы предпочтете показать хоть что-то, чем ничего.

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

Что такое оценка

Оценка — это целое число, которое сопровождает каждое совпадение и выступает в качестве индикатора достоверности по шкале от 0 до 100: более высокая оценка означает, что AudD более уверен в том, что это правильная песня. Вы увидите конкретные значения, такие как 81, в реальных ответах. Используйте ее так же, как любой сигнал достоверности — для ранжирования кандидатов и установки порога отсечения.

Два свойства делают ее полезной:

• Более высокое значение означает большую уверенность. Из двух совпадений AudD больше уверен в том, у которого оценка выше.
• Она сопоставима в рамках ваших собственных результатов. Внутри вашего приложения, на ваших типах входных данных, оценка позволяет отделить совпадения, которым вы доверяете, от тех, которым нет.

Чем оценка не является

Слишком буквальное восприятие числа ведет к хрупкому коду. Оценка не является:

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

Не выводите необработанную оценку конечным пользователям как «процент совпадения». Это не он. Если вы вообще показываете достоверность, сопоставьте ее с определенными вами грубыми категориями («подтверждено» / «вероятно»), а не просто выводите целое число как процент.

Не выводите необработанную оценку конечным пользователям как «процент совпадения». Это не он. Если вы вообще показываете достоверность, сопоставьте ее с определенными вами грубыми категориями («подтверждено» / «вероятно»), а не просто выводите целое число как процент.

Совпадение — это уже уверенный ответ

Полезно знать, на чем основывается оценка. AudD возвращает совпадение только тогда, когда достаточно уверен в нем — ниже этого внутреннего порога вы получаете result: null, чистое «нет совпадений», а не догадку с низкой оценкой. Таким образом, полученные вами совпадения уже прошли минимальный порог.

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

result: null — это «нет совпадений», а не низкая оценка. Нет совпадений означает, что нет оценки для чтения — объекта result не существует. Обрабатывайте «совпадений не найдено» и «совпадение найдено с низкой оценкой» как две отдельные ветки в вашем коде.

result: null — это «нет совпадений», а не низкая оценка. Нет совпадений означает, что нет оценки для чтения — объекта result не существует. Обрабатывайте «совпадений не найдено» и «совпадение найдено с низкой оценкой» как две отдельные ветки в вашем коде.

Выбор порогового значения

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

Шаг 1: решите, во сколько вам обходится ложноположительный результат

• Дорого (блокировка контента, взимание платы, отправка юридического уведомления): склоняйтесь к высокому порогу. Лучше пропустить реальное совпадение, чем действовать на основе ошибочного. Направляйте неопределенные случаи на проверку человеком.
• Дешево (показ метки, логирование воспроизведения, заполнение виджета): склоняйтесь к низкому порогу. Ошибочное совпадение самокорректируется и безвредно; отсутствие результата — худший исход.

Шаг 2: откалибруйте на своих данных

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

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

Шаг 3: внедрите диапазоны

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

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

Разделение на три варианта — принять / проверить / отклонить — является общей схемой. Мягкое применение может свести их к двум (принимать почти всё, что возвращается); строгое — удерживает полосу проверки широкой, а планку приемки высокой.

Пример из практики

Тот же результат распознавания, два приложения, две политики.

Строгий фильтр авторских прав

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

Здесь оценка отрабатывает свое в среднем диапазоне: совпадения, которые были найдены, но недостаточно уверенны для автоматической блокировки, вместо ошибочного автоматического решения передаются на рассмотрение человеку. Соедините оценку с другими сигналами из результата — ненулевой меткой, присутствующими isrc/upc (возвращаются при вызовах для корпоративных клиентов и на тарифе Startup или выше) — чтобы сделать решение о блокировке более точным, чем только по одной оценке.

Мягкое отображение «сейчас играет»

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

Тот же поле оценки, тот же API. Фильтр авторских прав рассматривает 81 как «интересно, но нужно проверить»; виджет «сейчас играет» рассматривает это как «достаточно хорошо, показать». Разница заключается исключительно в ваших пороговых значениях, устанавливаемых исходя из стоимости ошибки в каждом контексте.

Распространенные ошибки

• Жесткое кодирование числа, прочитанного где-то как «рекомендуемый порог». Официального порога не существует. Выполняйте калибровку на собственных входных данных и пересматривайте ее при изменении этих данных.
• Восприятие оценки как вероятности или процентного соответствия. Это показатель уверенности, а не откалиброванная вероятность и не «какая часть песни совпала». Не выполняйте с ним арифметических операций, которые подразумевают обратное.
• Использование одного и того же порога для процесса блокировки и процесса отображения. Стоимость ложноположительного результата определяет все решение; используйте повторно эндпоинт, а не пороговое значение.
• Путаница между низкой оценкой и отсутствием совпадения. Отсутствие совпадения — это result: null, и оно вообще не содержит оценки. Возвращенное совпадение с низкой оценкой — это другая ветка, обрабатывайте их отдельно.
• Отображение исходного целого числа пользователям в виде «совпадение N%». Вместо этого сопоставляйте его с крупными, содержательными категориями.
• Опора только на оценку при принятии важных решений. Для авторских прав объединяйте ее с меткой, isrc и upc, а не устанавливайте пороговое значение для числа изолированно.
• От совпадения к решению: правила разрешения, блокировки и проверки
• Что музыкальное распознавание сопоставляет, а что нет
• Создание сканера авторских прав для загружаемого пользователями контента
• Генерация доказательств для DMCA-уведомлений об удалении
• Поля результатов распознавания
• Справочник по API