Как Google использует пользовательские видео (UGC) для обучения системы распознавания музыки по голосу («Hum to Search»)

Описание

Какую задачу решает

Патент решает проблему создания качественных обучающих данных для систем распознавания аудио, когда входным сигналом является человеческий голос (напев, пение – технология «Query by Humming» или «Hum to Search»). Основная техническая задача — автоматическое получение чистых, точных монофонических линий мелодии (monophonic melody lines) для обучения ML-моделей, так как студийные записи являются полифоническими (содержат множество инструментов) и сложны для анализа.

Что запатентовано

Запатентована система автоматической генерации обучающего набора данных для моделей распознавания мелодий. Система использует коллекцию пользовательского видеоконтента (collection of videos / UGC), чтобы найти исполнения песен а капелла. Она извлекает линии мелодии из этих видео, валидирует их точность с помощью кластеризации и связывает полученные чистые мелодии с идентификатором песни (Identifier).

Как это работает

Система работает в несколько этапов:

• Фильтрация контента: Отбираются видео, которые ассоциированы с конкретной песней (по ID или названию) И содержат текстовые метки (textual labels), предполагающие исполнение а капелла (только голос, без фоновых звуков).
• Извлечение признаков: Из аудиодорожки отобранных видео извлекается monophonic melody line (акустические признаки).
• Кластеризация и Валидация: Извлеченные линии мелодии из разных видео одной и той же песни сравниваются между собой (Clusterer). Схожие мелодии группируются.
• Отбор эталона: Выбирается самый большой или консистентный кластер схожих мелодий, предполагая, что он представляет наиболее точное исполнение (консенсус).
• Обучение модели: Эталонные линии мелодии и идентификатор песни передаются системе распознавания (Recognizer) для обучения.

Актуальность для SEO

Высокая. Google активно использует и развивает технологию «Hum to Search». Этот патент описывает фундаментальный метод сбора и валидации необходимых обучающих данных для этой технологии, используя ресурсы UGC (например, YouTube).

Важность для SEO

Влияние на SEO минимальное (1/10). Патент касается исключительно аудио-фингерпринтинга и обучения моделей для распознавания аудио. Он не описывает механизмы ранжирования результатов веб-поиска, анализа текстового контента или оценки качества сайтов. Он практически не влияет на традиционные SEO-стратегии для веб-сайтов.

Детальный разбор

Термины и определения

A cappella video recordings (А капелла видеозаписи)

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

Acoustic Features (Акустические признаки)

Извлекаемые характеристики аудиосигнала. В контексте патента это преимущественно monophonic melody line.

Clusterer (Кластеризатор)

Компонент системы, который группирует извлеченные линии мелодии на основе их схожести. Используется для валидации качества данных.

Collection of videos / Items of uploaded content (Коллекция видео / Элементы загруженного контента)

Исходная база данных видео, загруженных пользователями (UGC, например, YouTube).

Entity / Particular Entity (Сущность)

Обобщенный термин в Claims. В контексте патента это конкретная песня.

Identifier (Идентификатор)

Метаданные, идентифицирующие конкретную песню (например, название песни, исполнитель).

Metadata Filter (Фильтр метаданных)

Компонент, который выбирает видео-кандидаты на основе идентификаторов и ключевых слов в текстовых метках.

Melody Line Extractor (Экстрактор линии мелодии)

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

Monophonic melody line (Монофоническая линия мелодии)

Линейная последовательность музыкальных тонов (основная мелодия).

Recognizer (Распознаватель)

Система (например, модель машинного обучения), обученная идентифицировать песни по входному аудиосигналу (например, по напеву пользователя).

Textual label (Текстовая метка)

Метаданные (заголовок, тег, описание, транскрипция), связанные с загруженным контентом.

Ключевые утверждения (Анализ Claims)

Claim 1 (Независимый пункт): Описывает автоматизированный процесс генерации обучающих данных из загруженного контента для системы распознавания.

1. Отбор (Первый набор): Система выбирает первый набор кандидатов (First candidate training subset) из загруженного контента на основе двух критериев:
   • (i) Наличие текстовых меток (textual label), указывающих на присутствие звука человеческого голоса И отсутствие фоновых/нечеловеческих звуков (например, ключевые слова «а капелла»).
   • (ii) Ассоциация с определенной сущностью (particular entity, например, конкретной песней).
2. Извлечение признаков: Для каждого элемента в первом наборе извлекаются акустические признаки (acoustic features, например, линии мелодии).
3. Отбор (Второй набор): Система выбирает второй, отфильтрованный набор (Second, filtered candidate training subset) из первого набора. Ключевой дополнительный критерий:
   • (iii) Акустические признаки элемента схожи с акустическими признаками других элементов первого набора (результат кластеризации/валидации).
4. Использование: Акустические признаки из второго (отфильтрованного и валидированного) набора используются для распознавания того, связан ли впоследствии полученный аудиосэмпл (например, напев пользователя) с этой конкретной сущностью (песней).

Claim 5 (Зависимый): Уточняет, что выбор второго набора (шаг 3 выше) включает кластеризацию (clustering) элементов первого набора.

Claim 6 (Зависимый): Уточняет, что использование признаков (шаг 4 выше) включает обучение автоматизированной системы распознавания (training an automated recognition system).

Claim 9 (Зависимый): Уточняет, что текстовые метки, указывающие на отсутствие фоновых звуков, подразумевают отсутствие инструментальных звуков (absence of instrumental sounds).

Где и как применяется

Патент не вписывается в стандартную архитектуру веб-поиска, так как относится к другой модальности — Аудио-поиску (например, «Hum to Search»). Процессы происходят преимущественно офлайн.

CRAWLING – Сканирование и Сбор данных
Система получает доступ к Collection of videos или Video Recordings Database (например, внутренней базе данных YouTube) и связанным метаданным. Это источник входных данных (UGC).

INDEXING – Индексирование и извлечение признаков
Здесь происходит основная обработка и генерация обучающих данных (офлайн или пакетный режим).

• Metadata Filter анализирует существующие метаданные и теги (textual labels).
• Аудиодорожка отделяется от видеоряда (Audio Track Isolator).
• Melody Line Extractor извлекает monophonic melody line (акустические признаки).
• Clusterer анализирует извлеченные признаки на предмет схожести и выбирает валидированное подмножество.
• Результаты (чистые линии мелодии, связанные с ID песен) сохраняются в Melody Database и используются для обучения Recognizer.

QUNDERSTANDING / RANKING (в контексте Аудио-поиска)
Когда пользователь отправляет аудио-запрос (напев), обученный Recognizer обрабатывает этот сигнал и сравнивает его с данными в Melody Database для поиска и ранжирования совпадений.

Входные данные:

• Коллекция видео (UGC) с соответствующими метаданными (теги, названия, описания, транскрипции).
• Базы данных ключевых слов и идентификаторов песен.

Выходные данные:

• Melody Database, содержащая высококачественные, валидированные monophonic melody lines, связанные с Identifiers (ID песен).
• Обученная модель Recognizer.

На что влияет

• Типы контента: Пользовательский видеоконтент (UGC), в частности, музыкальные кавер-версии, исполненные а капелла.
• Специфические запросы: Аудио-запросы («Query by Humming» или «Hum to Search»). Не влияет на текстовые веб-запросы.
• Ниши или тематики: Музыка.

Когда применяется

• Условия работы алгоритма: Алгоритм генерации базы данных применяется офлайн или в пакетном режиме для анализа существующей базы видео. Алгоритм распознавания (Recognizer) применяется в реальном времени при получении аудио-запроса от пользователя.
• Триггеры активации (для генерации базы): Наличие достаточного количества видео, которые по метаданным потенциально являются а капелла исполнением конкретной песни.

Пошаговый алгоритм

Процесс генерации базы мелодий (Офлайн)

1. Сбор данных: Система получает доступ к базе данных видеозаписей и их метаданным.
2. Фильтрация метаданных (Выбор первого набора кандидатов): Metadata Filter выбирает набор видео-кандидатов для конкретной песни (Entity/Identifier). Отбор происходит по двум критериям:
   • Видео ассоциировано с идентификатором песни.
   • Текстовые метки содержат ключевые слова, указывающие на а капелла исполнение (например, «a cappella», «sings», «cover») и не содержат исключающих слов (например, «plays», «band», «instrumental»).
3. Изоляция аудио: Отделение аудиодорожки от видеоряда для выбранных кандидатов.
4. Извлечение признаков: Melody Line Extractor обрабатывает аудиодорожку каждого кандидата и извлекает монофоническую линию мелодии (Acoustic Features).
5. Кластеризация: Clusterer сравнивает извлеченные линии мелодии всех кандидатов между собой (парное сравнение). Создается граф схожести, где узлы — это видео, а ребра представляют степень схожести (similarity) мелодий.
6. Валидация и Выбор второго набора: Система фильтрует связи с низкой схожестью (ниже порога). Из оставшихся кластеров (групп схожих мелодий) выбирается лучшее подмножество (например, самый большой кластер или clique). Это считается эталонной мелодией.
7. Сохранение и Обучение: Идентификатор песни и линии мелодии из выбранного подмножества сохраняются в Melody Database и передаются Recognizer для обучения модели распознавания.

Какие данные и как использует

Данные на входе

• Контентные факторы (Метаданные видео): Критически важны для первичной фильтрации. Используются textual labels, включающие заголовки (titles), теги (tags), метаданные (metadata), комментарии (comments), метки (labels), атрибуты (attributes). Также явно упоминается использование транскрипции аудиодорожки (transcription of an audio portion).
• Мультимедиа факторы: Аудиодорожки видеофайлов (Audio channel). Используются для извлечения акустических признаков.

Какие метрики используются и как они считаются

• Ключевые слова (Keywords): Используются для классификации видео как «a cappella». Включают слова, указывающие на присутствие человеческого голоса и отсутствие инструментов.
• Идентификаторы (Identifiers): Используются для определения конкретной песни (сущности).
• Monophonic melody line / Acoustic Features: Извлеченные акустические характеристики (например, основная частота, высота тона мелодии).
• Similarity (Схожесть): Метрика, вычисляемая при сравнении двух извлеченных линий мелодии.
• Threshold (Порог схожести): Пороговое значение, используемое для фильтрации связей в графе при кластеризации.
• Размер и структура кластера: Метрики графа (например, размер кластера, плотность связей), используемые для выбора финального набора эталонных мелодий (поиск консенсуса).

Выводы

Патент описывает внутренние инфраструктурные процессы Google без прямых рекомендаций для SEO.

1. Инфраструктура для Аудио-поиска: Патент описывает метод сбора и очистки данных, необходимых для работы системы распознавания музыки по голосу («Hum to Search»). Он не связан с ранжированием веб-страниц.
2. Использование UGC для обучения ML: Система полагается на пользовательский контент (видео) как на источник обучающих данных. А капелла исполнения акустически проще анализировать (монофонические), чем студийные записи (полифонические).
3. Важность Метаданных Видео: Точность текстовых метаданных (тегов, названий, транскрипций) видео критически важна для первичного отбора кандидатов. Система использует эти данные для классификации контента (например, как «а капелла»).
4. Кластеризация как Фильтр Качества (Консенсус): Механизм кластеризации используется для валидации акустических данных и защиты от неточных метаданных или некачественного исполнения. Предполагается, что наиболее часто повторяющаяся (схожая) мелодия среди разных исполнений является наиболее точной (поиск консенсуса).

Практика

Патент является инфраструктурным и описывает внутренние процессы Google для аудио-поиска. Он не дает практических выводов для традиционного SEO веб-сайтов. Выводы ниже касаются Video SEO (например, YouTube) и общей стратегии.

Best practices (это мы делаем)

• Точное и детальное описание видеоконтента (YouTube SEO): Патент подтверждает, что Google использует метаданные (заголовки, теги, описания) для классификации контента на детальном уровне. Для креаторов важно точно описывать формат видео (например, «A Cappella Cover», «Instrumental Tutorial», «Review»). Это помогает системам Google правильно интерпретировать и использовать контент.
• Качество аудио и транскрипции: Обеспечение чистого звука и наличие точных транскрипций/субтитров помогает системам Google анализировать контент. Патент упоминает использование транскрипций как источника метаданных.

Worst practices (это делать не надо)

• Некорректные или вводящие в заблуждение метаданные видео: Использование нерелевантных тегов или кликбейтных заголовков (например, пометка инструментального исполнения как «a cappella» или указание неверной песни). Хотя система имеет механизмы фильтрации (кластеризация акустических признаков), это создает шум и вредит общей экосистеме контента.

Стратегическое значение

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

Практические примеры

Практических примеров для применения в SEO веб-сайтов нет.

Вопросы и ответы