От совпадения к решению: разработка политик разрешения, блокировки и проверки

Источник: AudD•

От совпадения к решению: разработка политик разрешения, блокировки и проверки

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

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

На этой странице описываются инженерные шаблоны, а не юридические требования. Это не юридическая консультация. Обязательства по процедурам уведомления и удаления (notice-and-takedown), Статье 17 и Закону о цифровых услугах (DSA) различаются в зависимости от сервиса и страны; проконсультируйтесь с юристом. По состоянию на 12 октября 2026 г.

На этой странице описываются инженерные шаблоны, а не юридические требования. Это не юридическая консультация. Обязательства по процедурам уведомления и удаления (notice-and-takedown), Статье 17 и Закону о цифровых услугах (DSA) различаются в зависимости от сервиса и страны; проконсультируйтесь с юристом. По состоянию на 12 октября 2026 г.

Кратко (TL;DR)

  • Разделите эти два шага: распознавание генерирует факты (совпадения, оценки, смещения); версия политики преобразует факты и ваш собственный контекст в определенное действие.
  • На основе одного корпоративного сканирования вы можете рассчитать количество секунд воспроизведения для каждого совпавшего трека, а для всей загрузки — долю совпавшей музыки.
  • Сначала проверьте белый список (allow list): лицензированные треки по ISRC или по audio_id в пользовательском каталоге.
  • Типичные действия: разрешить, только записать, заглушить фрагмент, отправить на проверку, заблокировать.
  • Все цифры на этой странице носят иллюстративный характер. Выполните калибровку на собственных размеченных загрузках, прежде чем что-либо автоматизировать.
  • Отсутствие совпадений означает неизвестный контент, а не очищенный от авторских прав. См. раздел Что распознает музыкальное распознавание.

Входные данные политики от AudD

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

Корпоративная конечная точка (endpoint) разбивает файл на 12-секундные фрагменты и возвращает совпадение для каждого фрагмента, где было что-то распознано. При использовании accurate_offsets (Python SDK запрашивает это по умолчанию) каждое совпадение содержит параметры start_seconds и end_seconds: где начинается и заканчивается совпавший фрагмент аудио в вашем файле. Трек, который звучит в течение двух минут, возвращается как серия последовательных совпадений; объедините их интервалы, чтобы получить общее время звучания в секундах.

Примечания к цифрам:

  • Продолжительность файла определяете вы. Корпоративные результаты не включают длину файла. Получайте ее при загрузке, например с помощью ffprobe -v error -show_entries format=duration -of csv=p=0 upload.mp4.
  • Для расчета доли совпадения требуются все фрагменты. Если вы сокращаете сканирование с помощью параметров skip и every для экономии запросов (см. раздел контроля затрат корпоративного уровня), несканированные фрагменты считаются несовпавшими, и доля окажется заниженной. Сокращенное сканирование подходит для простой проверки «да/нет»; используйте полное сканирование с лимитом, покрывающим весь файл, когда доля влияет на итоговое решение.
  • Секунды указаны приблизительно. Каждое совпадение охватывает распознанную часть 12-секундного фрагмента, поэтому при непрерывном воспроизведении на стыках фрагментов могут возникать небольшие промежутки. Воспринимайте секунды совпадения как измерение с определенной погрешностью, а не как абсолютную величину.
  • Общая доля рассчитывается с использованием объединения интервалов, поэтому два трека, накладывающиеся друг на друга на переходе, не учитываются дважды.

Без использования SDK

Если вы вызываете HTTP API самостоятельно, запросите смещения (offsets) и вычислите позицию в файле на основе смещения фрагмента плюс начального и конечного смещений песни (start_offset и end_offset), которые представляют собой миллиметры внутри этого 12-секундного фрагмента:

Документация по полям корпоративных совпадений описывает полную структуру ответа.

Пример таблицы решений

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

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

Политика в виде кода

Интервалы заглушения передаются напрямую в фильтр громкости ffmpeg; в рецепте записи в реальном времени показана соответствующая команда. Запас (padding) учитывает примерные границы каждого совпадения.

Создание белого списка (allow list)

У вас есть два способа заявить «эта музыка здесь допустима»:

  • По идентификатору. Сохраняйте коды ISRC (для тарифного плана Startup и выше) лицензированных вами треков. Указывайте каждую версию, покрываемую лицензией, так как ремастеринг или правка могут иметь другой ISRC. Совпадение по исполнителю и названию может служить дополнительной проверкой, которая направляет пограничные случаи на ручную проверку.
  • По пользовательскому каталогу. Загрузите сами лицензированные файлы (или музыку, принадлежащую вашим авторам) в ваш пользовательский каталог и разрешите эти audio_id. Это работает для музыки, которой нет в публичной базе данных, например для производственных библиотек. Если та же запись также присутствует в публичной базе данных, совпадение может вернуться из любого источника, поэтому добавьте в белый список как audio_id, так и ISRC.

Очереди проверки

Предоставьте проверяющим все необходимое для быстрого принятия решения: название трека и song_link, интервалы в загруженном файле (в виде таймкодов, к которым они могут перейти), таймкод в самом совпавшем треке, оценку достоверности и историю загрузчика. Записывайте решение и причину проверяющего рядом с результатами автоматической проверки. Результаты ручной проверки — ваши лучшие данные для калибровки: высокий процент вердиктов «это было нормально» в определенном диапазоне оценок означает, что порог срабатывания слишком низок.

Апелляции и споры

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

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

Логирование решений

Сохраняйте достаточно данных, чтобы объяснить любое решение в дальнейшем и пересчитать его в соответствии с новой политикой:

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

Повторные нарушители

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

Региональная политика

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

Калибровка перед автоматизацией

  • Просканируйте несколько сотен реальных загрузок и попросите людей отметить правильное действие для каждой из них.
  • Примените свою политику к зарегистрированным совпадениям и сравните результаты.
  • Настраивайте ACT_SCORE, REVIEW_SCORE, BLOCK_SHARE и MUTE_MAX_SECONDS до тех пор, пока автоматические блокировки почти никогда не будут отменяться, а затем повышайте версию политики.
  • Начните с «проверки» там, где планируете «блокировку», следите за уровнем отмен и переходите к автоматическим действиям, когда показатели это подтверждают.

В разделе «Интерпретация оценки распознавания» эта часть оценки рассматривается более подробно.

  • Что распознает музыкальный сервис, а что нет
  • Интерпретация оценки распознавания
  • Создание сканера авторских прав для пользовательского контента
  • AudD для видеоплатформ и модерации пользовательского контента (UGC)
  • Создание доказательств для удаления контента по DMCA
  • Корпоративный ответ и поля совпадений
  • Глоссарий музыкальных прав и распознавания

О чём эта статья