Как Google идентифицирует и устраняет дубликаты статей в агрегаторах контента, сравнивая заголовки и URL

Описание

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

Патент решает проблему избыточности и дублирования контента внутри платформ агрегации медиаконтента (в патенте называемых magazine editions). Проблема возникает, когда идентичные или очень похожие статьи поступают из разных источников (Content Sources, например, RSS-фиды, социальные потоки). Цель — автоматическая идентификация и управление этими дубликатами для повышения эффективности системы и улучшения пользовательского опыта в агрегаторе.

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

Запатентован метод дедупликации статей на платформе онлайн-публикаций. Система (De-duplication Manager) сравнивает две статьи, анализируя исключительно их заголовки и связанные URL-адреса (часто указывающие на изображения). Заголовки нормализуются, после чего система оценивает степень их схожести (используя метрику Levenshtein distance) и схожесть URL-адресов. Статьи признаются дубликатами, если оба параметра удовлетворяют строгим критериям схожести.

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

Механизм работает следующим образом:

• Идентификация: Система извлекает заголовки и связанные URL двух статей.
• Нормализация заголовков: Заголовки обрабатываются для устранения различий в форматировании (пунктуация, регистр, орфография).
• Сравнение URL: Система проверяет, идентичны ли URL. Если да, статьи могут быть сразу признаны дубликатами. Если нет, проверяется строгая схожесть: указывают ли они на один и тот же ресурс в одном и том же месте, отличаясь лишь аспектами доступа (например, полная и сокращенная версия).
• Сравнение заголовков: Нормализованные заголовки сравниваются на предмет полного совпадения или близости по метрике Levenshtein distance (с возможным учетом совпадения префиксов/суффиксов).
• Решение: Если и заголовки, и URL считаются похожими (considered similar), статьи помечаются как дубликаты.
• Действие: При обнаружении дубликатов система может объединить статьи, выбрать более свежую версию или предложить выбор издателю.

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

Средняя. Патент описывает инфраструктуру для продуктов типа Google Currents/Producer (актуальных на 2011 год). Однако базовые принципы дедупликации контента, поступающего через фиды, остаются критически важными для современных агрегаторов, таких как Google News. Описанные техники (нормализация, Levenshtein distance) являются стандартными методами в Information Retrieval.

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

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

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

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

Access Aspects (Аспекты доступа)

Характеристики URL, которые влияют на способ доступа к ресурсу, но не на сам ресурс или его местоположение. Примеры: полная версия URL, сокращенная версия URL (shortened URL), URL с переадресацией.

Article (Статья)

Единица контента, объект дедупликации. Ассоциирована как минимум с заголовком (Title) и URL.

Content Sources (Источники контента)

Источники, предоставляющие контент для агрегации (например, RSS-фиды, социальные потоки).

De-duplication Manager (Менеджер дедупликации)

Системный компонент на Producer Server, отвечающий за идентификацию и обработку дублирующихся статей.

Levenshtein distance (Расстояние Левенштейна)

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

Magazine Edition (Цифровое издание)

Контекст применения патента — платформа для агрегации и отображения медиаконтента.

Normalized Title (Нормализованный заголовок)

Заголовок статьи после процесса очистки и стандартизации (нормализации).

Producer Server (Сервер производства)

Сервер, который агрегирует контент, обрабатывает его (включая дедупликацию) и распространяет издания.

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

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

1. Система идентифицирует две статьи, каждая с Заголовком и URL.
2. Оба заголовка нормализуются.
3. Нормализованные заголовки сравниваются между собой, и URL сравниваются между собой.
4. Ядро метода: Определяется, что статьи являются дубликатами, если первый нормализованный заголовок считается схожим (considered similar) со вторым И первый URL считается схожим со вторым URL.
5. В противном случае статьи не считаются дубликатами.

Claim 2 (Зависимый от 1): Добавляет альтернативное условие для определения дубликатов.

Статьи также считаются дубликатами, если первый URL точно совпадает (is the same as) со вторым URL. При полном совпадении URL схожесть заголовков может не требоваться.

Claim 3 (Зависимый от 1): Определяет процесс нормализации.

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

Claim 4 (Зависимый от 1): Определяет критерии схожести URL (в контексте изображений).

Первый и второй URL считаются похожими, если они идентифицируют одно и то же изображение в одном и том же месте (same image at the same location), но отличаются только аспектами доступа (access aspects).

Техническая интерпретация: Это строгое определение. Согласно этому пункту формулы, если одно и то же изображение размещено по двум разным URL (в разных локациях), они НЕ будут считаться похожими в рамках этого механизма.

Claim 6 (Зависимый от 4): Определяет критерии схожести заголовков с использованием метрики.

Вычисляется Levenshtein distance между нормализованными заголовками. Они считаются похожими, если расстояние меньше заданного порога (predetermined threshold).

Claim 7 (Зависимый от 6): Добавляет дополнительные условия к расстоянию Левенштейна.

Помимо расстояния ниже порога, нормализованные заголовки должны также совпадать по определенному количеству символов в префиксе и/или суффиксе, чтобы считаться похожими. Это повышает точность на коротких текстах.

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

Изобретение применяется в инфраструктуре платформы агрегации контента (например, Google News), а не в основном веб-поиске Google. Оно соответствует этапам сбора и индексирования данных внутри агрегатора.

CRAWLING – Сканирование и Сбор данных (Data Acquisition)
На этом этапе система (Producer Server) получает контент из внешних источников (Content Sources), таких как RSS-фиды или социальные потоки, через компонент Data Connector.

INDEXING – Индексирование и извлечение признаков (Processing)
Это основной этап применения патента. После получения контента и перед его сохранением активируется De-duplication Manager. Происходит извлечение признаков (Заголовок, URL), их нормализация и сравнение для выявления дубликатов с использованием описанных метрик (Levenshtein distance, сравнение URL). После этого принимается решение об управлении дубликатами (объединение, выбор версии).

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

• Статьи (Articles), поступающие из источников контента.
• Заголовки (Titles) статей.
• URL-адреса (URLs), ассоциированные со статьями (например, URL изображений).

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

• Набор дедуплицированного контента (Edition Content).

На что влияет

• Конкретные типы контента: Влияет на статьи, новости, посты в блогах, поступающие через фиды (RSS) и социальные потоки в системах агрегации контента.
• Платформы: Наибольшее влияние оказывается на контент внутри агрегаторов (например, Google News) или внутренних CMS, собирающих данные из множества источников (синдикация).

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

• Триггеры активации: Алгоритм активируется при поступлении нового контента из источников (в реальном времени или периодически) или во время процесса синхронизации контента.
• Пороговые значения: Ключевым является predetermined threshold для Levenshtein distance. Если разница между нормализованными заголовками ниже этого порога (и URL схожи), система срабатывает.

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

Процесс дедупликации двух статей (А1 и А2):

1. Идентификация и Извлечение: Система извлекает Заголовки (Т1, Т2) и URL (U1, U2) для статей А1 и А2.
2. Сравнение URL (Проверка на идентичность): Система проверяет, идентичны ли U1 и U2.
   • Если ДА: Статьи признаются дубликатами (согласно Claim 2). Процесс переходит к шагу 7.
   • Если НЕТ: Процесс переходит к шагу 3.
3. Нормализация Заголовков: Т1 и Т2 обрабатываются (удаление пунктуации, изменение регистра и т.д.). Результат: Нормализованные заголовки (NT1, NT2).
4. Сравнение URL (Проверка на схожесть): Система проверяет, указывают ли U1 и U2 на один и тот же ресурс в одном и том же месте, отличаясь лишь аспектами доступа.
   • Если НЕТ (не похожи): Статьи не являются дубликатами. Процесс завершен.
   • Если ДА (похожи): Процесс переходит к шагу 5.
5. Сравнение Заголовков (Проверка на идентичность): Система проверяет, идентичны ли NT1 и NT2.
   • Если ДА: Статьи признаются дубликатами (так как URL уже признаны похожими). Процесс переходит к шагу 7.
   • Если НЕТ: Процесс переходит к шагу 6.
6. Сравнение Заголовков (Продвинутая проверка схожести): Вычисляется Levenshtein distance между NT1 и NT2. Проверяется, меньше ли расстояние заданного порога. Опционально проверяется совпадение префиксов и/или суффиксов.
   • Если условия схожести выполнены: Статьи признаются дубликатами. Процесс переходит к шагу 7.
   • Если НЕТ: Статьи не являются дубликатами. Процесс завершен.
7. Обработка дубликатов: Система выполняет одно из действий: объединение статей (Merge Articles), выбор более свежей версии (Use More Recent Article) или запрос выбора у пользователя (Allow User to Choose Article).

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

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

Патент фокусируется на ограниченном наборе факторов для дедупликации в контексте агрегации контента.

• Контентные факторы: Заголовки (Titles) статей. Используются для сравнения после нормализации. Тело статьи не анализируется в этом механизме.
• Технические факторы: URL-адреса (URLs), ассоциированные со статьей (часто URL изображений). Сравниваются на предмет идентичности или схожести.
• Временные факторы: Метки времени создания или редактирования. Используются для выбора более свежей (more recent) версии при обнаружении дубликатов.

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

• Нормализация текста: Применение правил для стандартизации заголовков (удаление символов, изменение регистра, исправление орфографии).
• Levenshtein distance: Метрика для оценки степени различия между двумя нормализованными заголовками.
• Пороговые значения (Thresholds): Предопределенный порог для Levenshtein distance. Если расстояние меньше порога, заголовки считаются потенциально похожими.
• Совпадение префиксов/суффиксов: Дополнительная метрика, требующая совпадения заданного количества символов в начале и/или конце заголовков.
• Оценка схожести URL (URL Similarity Assessment): Метрика, определяющая, являются ли два разных URL функционально эквивалентными (указывают на один и тот же ресурс в том же месте, игнорируя Access Aspects).

Выводы

1. Контекстная дедупликация для агрегаторов: Патент описывает систему дедупликации, специфичную для платформ агрегации контента (например, Google News), обрабатывающих статьи из фидов (RSS), а не для основного веб-поиска.
2. Комбинированные сигналы: Заголовок + URL: Для идентификации дубликатов система полагается на комбинацию схожести заголовка и связанного URL (часто изображения). Совпадения только одного элемента обычно недостаточно.
3. Исключение: Идентичные URL как сильный сигнал: Если связанные URL абсолютно идентичны, система может признать статьи дубликатами, даже если заголовки различаются (Claim 2).
4. Строгие критерии схожести URL: Согласно Claims, URL считаются похожими только если они ведут к одному и тому же ресурсу в одном и том же месте. Это критически важное уточнение для издателей, использующих разные CDN или хостинг для ресурсов.
5. Использование стандартных методов IR: Система использует классические методы обработки текста: нормализацию и Levenshtein distance для оценки степени схожести неидентичных заголовков.
6. Повышение точности для коротких текстов: Для заголовков простое расстояние Левенштейна может давать ложные срабатывания. Патент предусматривает проверку совпадения префиксов и суффиксов для повышения точности.

Практика

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

Рекомендации применимы в первую очередь для издателей, оптимизирующих контент для агрегаторов типа Google News (Google News Optimization).

• Обеспечение консистентности URL ресурсов: Используйте стабильные и канонические URL для основных изображений статей в ваших фидах (RSS). Так как схожесть URL требует совпадения локации (Claim 4), использование разных URL (например, из разных CDN) для одного и того же изображения может помешать системе корректно связать версии контента.
• Использование точных меток времени: Поскольку система может выбирать более свежую (more recent) версию при обнаружении дубликатов, критически важно корректно указывать время публикации и обновления (например, pubDate в RSS).
• Стратегия обновления заголовков новостей: При обновлении заголовков новостных статей старайтесь сохранять основную часть заголовка (префикс). Это поможет системе распознать, что это та же самая статья (так как Levenshtein distance будет низким и префикс совпадет), а не новая дублирующая история.
• Четкие и уникальные префиксы заголовков: Убедитесь, что уникальные статьи имеют различающиеся начала заголовков. Так как система может использовать совпадение префиксов (Claim 7) для подтверждения схожести, это снижает риск ошибочной кластеризации разных статей.

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

• Незначительный рерайтинг заголовков для создания «уникальности»: Попытка представить один и тот же контент как новый путем минимального изменения заголовка неэффективна, если изменения попадают в пределы порога Levenshtein distance и используется тот же URL изображения.
• Использование разных URL для одного и того же изображения: Если вы используете разные URL, ведущие в разные локации, для одного и того же изображения в разных версиях статьи, это снижает вероятность того, что система корректно свяжет эти версии, согласно строгим критериям Claim 4.
• Частое изменение URL основных ресурсов: Использование динамических или часто меняющихся URL для одних и тех же ресурсов затруднит процесс дедупликации для агрегатора.

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

Этот патент имеет ограниченное стратегическое значение для общего SEO, но критически важен для понимания процессов внутри продуктов-агрегаторов. Он подтверждает, что Google использует стандартные техники Information Retrieval для обеспечения качества данных. Для издателей, чья стратегия зависит от трафика из Google News или Discover, это подчеркивает важность технической гигиены и согласованности данных в фидах для корректной агрегации и своевременного индексирования.

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

Сценарий 1: Оптимальное обновление новостной статьи для Google News

Издатель публикует срочную новость и затем обновляет ее заголовок.

1. Первоначальная публикация: Заголовок: «В городе N произошел пожар на складе», URL изображения: /img/fire-1.jpg
2. Обновление (Неоптимально): Заголовок изменен кардинально. Новый заголовок: «Пожарные локализовали возгорание, пострадавших нет».
   • Риск: Levenshtein distance высокое, префиксы не совпадают. Агрегатор может посчитать это новой статьей.
3. Обновление (Оптимально): Заголовок обновлен с сохранением префикса. Новый заголовок: «Пожар на складе в городе N: возгорание локализовано, пострадавших нет».
   • Результат: Levenshtein distance низкое, префикс совпадает, URL идентичен. Система распознает это как ту же самую статью.

Сценарий 2: Обработка синдикации через разные фиды

Издатель публикует новость в двух RSS-фидах.

1. Фид 1: Заголовок: «ЦБ РФ повысил ставку до 8%!», URL изображения: img/v1/cb-rate.jpg
2. Фид 2: Заголовок: «Центральный Банк повысил ставку до 8 процентов», URL изображения: img/v1/cb-rate.jpg
3. Результат: URL идентичны. Система признает статьи дубликатами (согласно Claim 2), несмотря на различия в заголовках, и выбирает одну версию для показа.

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