Показатели точности от поставщика описывают его собственные тестовые аудиозаписи. Ваши пользователи присылают записи с телефонов, музыку на фоне разговоров, 6-секундные фрагменты и ускоренные версии. Единственные цифры, на которые стоит опираться при принятии решения, — это те, что вы измерили на своих аудиозаписях.
Эта страница представляет собой план на пять рабочих дней (плюс запас времени), результатом которого станет письменная рекомендация: какой эндпоинт использовать, какие пороговые значения баллов применять, во сколько обойдется час аудио и в каких случаях распознавание не справляется с вашим контентом. В примерах используется AudD, но тестовый набор и методика подходят для любого поставщика. Сопутствующий чек-лист покупателя содержит вопросы, которые следует задать в дополнение к цифрам.
Обзор недели
День 1: токен, первый вызов и постановка задачи
Начните с публичного тестового токена. Он работает со стандартным эндпоинтом и позволяет выполнять 10 запросов в день, чего достаточно для проверки интеграции и ознакомления со структурой ответа:
Тестовый токен не подходит для запуска тестового набора и не работает с корпоративным эндпоинтом. Получите собственный токен в личном кабинете dashboard.audd.io для остальной части недели и проверьте свой тарифный план: ISRC, UPC и показатель совпадения (match score) требуют наличия плана Startup или выше. Если вы планируете устанавливать пороговые значения в 5-й день, вам необходим показатель score в результатах.
Затем сформулируйте в одном абзаце решение, которое должен обосновать этот пилотный проект. «Можем ли мы автоматически помечать песни в пользовательских загрузках и сколько это будет стоить в месяц?» — хороший пример. «Точно ли это работает?» — плохой, так как в нем нет порогового значения и конкретных последствий. Этот абзац определяет, какие категории попадут в тестовый набор и какая метрика важнее всего: для фильтра авторских прав важны ложные срабатывания, а для функции «что сейчас играет» — частота совпадений.
День 2: создание размеченного тестового набора
Тестовый набор — это аудио плюс ожидаемый результат. Постарайтесь подготовить несколько десятков фрагментов по каждой категории, которая вас интересует; всего за неделю можно обработать от 200 до 500 фрагментов. Используйте аудио из вашего собственного продукта (с учетом всех согласий, требуемых вашей политикой конфиденциальности), а не из демонстрационных плейлистов.
Запишите метки в CSV-файл:
- Оставьте поля expected_artist и expected_title пустыми для известных случаев отсутствия совпадений.
- Параметр mode должен быть standard для коротких фрагментов и enterprise для длинных файлов.
- Параметр duration_s нужен только для длинных файлов; он используется для оценки стоимости.
- Для длинных файлов укажите один трек, который точно есть в записи. Чтобы оценить целый плейлист, добавьте по одной строке на каждый ожидаемый трек для одного и того же файла.
Размер фрагментов для стандартного эндпоинта не должен превышать 10 МБ. Стандартный эндпоинт анализирует первые 12 секунд отправленного файла, поэтому обрезайте фрагменты до нужного момента. В разделе «Форматы аудио и качество» перечислены поддерживаемые форматы.
День 3: запуск набора
Этот скрипт прогоняет каждую строку через стандартный эндпоинт или через корпоративный эндпоинт с ограничением по чанкам для длинных файлов и записывает по одной строке на каждый входной файл в results.csv. Он фиксирует результат, название найденной песни, оценку (score), время, затраченное на каждый вызов в вашей сети, и количество израсходованных запросов.
Несколько вещей, которые скрипт делает намеренно:
- Сопоставление по содержащемуся названию и исполнителю. Названия релизов различаются («Warriors» против «Warriors - Remastered»), поэтому точное совпадение строк может ошибочно пометить правильные ответы как неверные. Проверяйте каждую строку wrong_song вручную; некоторые из них могут быть другим релизом той же записи.
- Ограничение на каждый корпоративный вызов. Корпоративный эндпоинт тарифицирует один запрос на каждые 12 секунд обрабатываемого аудио. Без ограничения один длинный файл может израсходовать сотни запросов. Увеличьте ENTERPRISE_LIMIT после того, как увидите первые результаты. В разделе «Контроль затрат в Enterprise» объясняются параметры limit, every и skip.
- Запросы в Enterprise — это оценочная величина. Скрипт рассчитывает чанки на основе duration_s и настроек дискретизации. Сравните итоговое значение с данными об использовании в личном кабинете после запуска.
- Ошибки записываются, но не повторяются. Строка с ошибкой — это результат (отклоненный формат, файл более 10 МБ). SDK уже выполняет повторные попытки для тех сбоев, которые безопасно повторять.
- Последовательные вызовы. Измерение времени одного вызова за раз дает чистый показатель задержки. У стандартного эндпоинта нет ограничений по частоте запросов, поэтому для большого набора вы можете запускать строки параллельно с помощью пула потоков после того, как задержка будет измерена; если вы планируете большой объем, заранее сообщите об этом AudD по адресу [email protected].
Альтернатива через CLI
Если вы не хотите писать код, инструмент командной строки audd запускает обработку папки как пакет и выводит JSON-строки (по одной на файл), за которыми следует сводка с параметром requests_spent:
CLI кэширует результаты по содержимому файлов, поэтому повторный запуск тех же фрагментов ничего не стоит и помечается как "cached": true. Используйте флаг --no-cache, если хотите получить свежие замеры времени. --max-requests N останавливает выполнение до того, как будет израсходовано более N запросов. Полный список флагов: docs.audd.io/cli.
День 4: измерения
Сгруппируйте results.csv по категориям:
Важны четыре показателя.
Частота совпадений по категориям: корректные / (корректные + пропуски + неверные песни) по строкам, где ожидалась песня. Отчитывайтесь по каждой категории отдельно. Хороший общий показатель может скрывать низкую эффективность на записях с телефонов, а они могут составлять большую часть вашего трафика.
Ложные срабатывания: строки false_match среди известных случаев отсутствия совпадений, плюс строки wrong_song. Для фильтра авторских прав это число определяет, можно ли действовать автоматически. Посмотрите на оценку (score) каждого ложного срабатывания; 5-й день использует эти данные.
Задержка в вашей сети: медиана и 95-й перцентиль из столбца с секундами. Они включают время загрузки из того места, где работал скрипт, поэтому проводите пилотный проект из того региона и сети, где будет работать ваш сервис. Отправка URL вместо байтов меняет число; тестируйте так, как будете вызывать API в продакшене.
Стоимость часа аудио. Единицей измерения являются запросы; умножьте их на цену за запрос согласно вашему тарифу на audd.io.
Затем масштабируйте до месяца. Например, 2000 часов загруженного видео в месяц, сканируемого с параметрами every=1, skip=4, — это 2000 × 60 = 120 000 запросов. Тот же объем, сканируемый полностью, — 600 000. Выборка (sampling) позволяет сэкономить за счет полноты: короткий фрагмент, попавший в пропущенный интервал, не будет найден. Ваши результаты за 4-й день покажут, достаточно ли выборочного сканирования для ваших задач.
Стримы тарифицируются за поток в месяц, а не за запрос; актуальные цены см. на docs.audd.io/streams.
День 5: выбор эндпоинта и установка пороговых значений
Выберите интерфейс в зависимости от типа ваших входных данных, а затем подтвердите выбор цифрами.
Обоснование приведено в разделах «Standard», «Enterprise» или «Streams».
Затем установите пороговые значения. Отсортируйте совпавшие строки по оценке (score) и пометьте каждую как корректную или нет. Точка, выше которой почти всё верно, — это ваш порог автоматического принятия. Точка, ниже которой почти всё неверно, — ваш порог отклонения. Диапазон между ними передается на проверку человеку или помечается как менее достоверный. Для блокирующего потока нужен высокий порог принятия; для отображения информации можно принимать почти всё, что возвращается. AudD не публикует рекомендуемые значения отсечки, поэтому используйте те, которые дают ваши данные. В разделе «Интерпретация оценки распознавания» приведен пример кода.
Если столбец score пуст, значит, ваш тарифный план его не включает; перейдите на план Startup или выше для пилотного проекта, иначе установленные вами пороги не будут работать в продакшене.
Дни 6–7: повторный запуск неудачных попыток и оформление результатов
Проанализируйте каждый промах, wrong_song и ложное совпадение. Большинство из них сводится к нескольким причинам: фрагмент слишком короткий или тихий, музыка звучит под громкую речь, запись является кавером или концертной версией (распознавание сопоставляет записи, а не композиции), либо трек отсутствует в базе данных. Исправьте то, что можете изменить (обрежьте запись до лучшего моментов, отправьте больший объем файла) и запустите эти строки повторно. Все остальное — это ограничение, которое вы фиксируете.
Достаточно отчета на одной странице:
- Решение и рекомендация. Вопрос первого дня и ответ на него.
- Тестовый набор. Размер, категории, источник аудио.
- Результаты по категориям. Процент совпадений, ложные срабатывания, медианная задержка и задержка p95.
- Эндпоинт и настройки. Стандартный, корпоративный (с параметрами limit, skip, every) или потоковый, а также причины выбора.
- Пороговые значения. Оценки для принятия и отклонения, а также ожидаемый объем модерации при этих значениях.
- Стоимость. Количество запросов в час аудио, запросы в месяц при ожидаемом и пиковом объеме, а также подходящий тарифный план.
- Известные пробелы. Категории, на которых произошел сбой, и ваши дальнейшие действия (ручная модерация, собственный каталог для неизданных треков или принятие промаха).
Сохраните labels.csv и скрипт. При замене устройств захвата, выходе на новый рынок или появлении нового типа контента запустите набор заново и сравните результаты.
Часто задаваемые вопросы
Сколько фрагментов нужно для оценки API распознавания музыки? Достаточно того, чтобы в каждой важной для вас категории было по несколько десятков примеров. Общий размер от 200 до 500 фрагментов, разделенных на известные совпадения, известные несовпадения и граничные случаи, является практичным объемом для одной недели. Единый общий процент совпадений скрывает категории, в которых происходит сбой.
Могу ли я запустить пилотный проект на тестовом токене AudD? Только первый вызов. Тестовый токен работает на стандартном эндпоинте с ограничением в 10 запросов в день, чего достаточно для подтверждения интеграции, но недостаточно для запуска тестового набора. Получите собственный токен на dashboard.audd.io непосредственно для пилотного проекта.
Как оценить стоимость распознавания часа аудио? На стандартном эндпоинте подсчитайте вызовы: каждый вызов — это один запрос. На корпоративном эндпоинте один час аудио, просканированный от начала до конца, составляет 3600 / 12 = 300 запросов; с параметрами every=1 и skip=4 — 60 запросов, а с every=1 и skip=9 — 30 запросов. Умножьте результат на цену за запрос в вашем тарифном плане.
Какой точности следует ожидать? Не существует единой цифры, применимой к вашему аудио, поскольку результаты зависят от того, что вы отправляете. Измерьте процент совпадений и ложных срабатываний на собственных размеченных фрагментах с разбивкой по категориям и используйте эти данные при принятии решения.
- Вопросы, которые стоит задать перед выбором API распознавания музыки
- Стандартный, корпоративный или потоковый: как сделать выбор
- Интерпретация оценки распознавания
- Контроль затрат в корпоративном тарифе
- Распознавание музыки через командную строку
- Ценообразование API распознавания музыки
