Как Google извлекает факты из веб-страниц для прямых ответов и автоматического наполнения Knowledge Graph

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

Answer System (Система ответов)

Основная система, описанная в патенте, которая определяет ответы на вопросительные запросы.

Interrogative Query (Вопросительный запрос)

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

Entity Database (База данных сущностей)

Структурированная база данных, определяющая сущности и связи между ними (например, Knowledge Graph).

(Subject, Relationship, Object) Triple (Триплет)

Основная структура данных в Entity Database для хранения фактов (например, (Барт Симпсон, Сестры, Лиза Симпсон)).

Annotator (Аннотатор)

Компонент, выполняющий NLP-анализ текста. Включает Part of speech tagger, Dependency parser, Entity tagger и Coreference resolver.

Snippets (Сниппеты)

Текстовые фрагменты, извлеченные из веб-ресурсов, которые релевантны Interrogative Query.

Candidate Answers (Кандидаты в ответы)

Потенциальные ответы, извлеченные из аннотированных сниппетов.

Relationship Entity (Связанная сущность)

Сущность, которая является ответом на вопрос и выступает объектом в триплете.

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

Основной фокус патента (в частности, Claim 1) направлен на автоматическое наполнение базы знаний, хотя в описании также рассматривается ответ на запросы пользователей.

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

1. Определение, что у сущности отсутствует достаточная связь (sufficient association) для определенного отношения (relationship) в базе данных.
2. Генерация как минимум одного interrogative query на основе этой сущности и отношения.
3. Идентификация textual snippets из результатов поиска, релевантных запросу.
4. Определение одного или нескольких candidate answers на основе этих сниппетов.
5. Выбор как минимум одного ответа из кандидатов.
6. Определение связи для этого отношения в базе данных между исходной сущностью и relationship entity, ассоциированной с выбранным ответом.

Claim 3 (Зависимый): Описывает рекурсивный процесс обнаружения новых сущностей.

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

Claim 5 (Зависимый): Описывает процесс валидации новой сущности.

Если relationship entity не определена в базе, система генерирует дополнительные запросы для определения того, является ли она валидной сущностью (valid entity). Связь в базу данных добавляется только после подтверждения валидности.

Claim 7 (Зависимый): Описывает механизм разрешения неоднозначности (Disambiguation).

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

Claim 12 (Зависимый): Детализирует метод извлечения кандидатов.

Кандидаты определяются на основе того, связаны ли они с грамматической характеристикой (grammatical characteristic), которая соответствует искомому отношению. Например, если ищется отношение "место рождения", система будет искать кандидатов с характеристикой "локация".

Claims 13, 14, 15 (Зависимые): Детализируют методы выбора (скоринга) ответа.

Выбор лучшего ответа может основываться на:

• Количестве сниппетов, включающих ссылку на этот ответ (Claim 13).
• Количестве уникальных ресурсов (сайтов), включающих сниппеты с этим ответом (Claim 14).
• Показателях (measures), ассоциированных с ресурсами, которые содержат ответ (например, рейтинг или качество ресурса) (Claim 15).

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

Изобретение применяется на нескольких этапах поиска и в офлайн-процессах.

INDEXING – Индексирование и извлечение признаков
Компонент Annotator может использоваться на этапе индексирования для глубокого NLP-анализа контента (разметка частей речи, синтаксический анализ, распознавание сущностей). Также на этом этапе (или в связанных офлайн-процессах) происходит формирование и обновление Entity Database.

QUNDERSTANDING – Понимание Запросов
Система должна определить, является ли запрос пользователя вопросительным (Interrogative Query), чтобы активировать Answer System.

RANKING – Ранжирование
Стандартная поисковая система (Search System) используется для поиска релевантных веб-ресурсов и генерации Snippets, которые затем передаются в Answer System.

METASEARCH – Метапоиск и Смешивание
Если Answer System успешно находит ответ на запрос пользователя, этот ответ может быть интегрирован в выдачу, часто на выделенной позиции (например, Featured Snippet), как показано на примере FIG. 6.

Офлайн-процессы (Наполнение Базы Знаний)
Система активно работает офлайн (как описано в FIG. 2 и FIG. 4) для итеративного поиска пробелов в Entity Database, генерации запросов и наполнения базы новыми фактами, извлеченными из веба.

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

• Interrogative Query (пользовательский или сгенерированный).
• Snippets из результатов поиска.
• Данные из Entity Database (существующие триплеты, алиасы сущностей).

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

• Ответ для презентации пользователю.
• Новый триплет (Subject, Relationship, Object) для добавления в Entity Database.

На что влияет

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

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

Алгоритм применяется в двух основных сценариях:

1. В реальном времени: Когда пользователь вводит запрос, идентифицированный как Interrogative Query.
2. В офлайн-режиме: Когда система выполняет задачу по расширению или верификации Entity Database и обнаруживает сущность, у которой отсутствует связь (lacks sufficient association) для определенного отношения (например, не указано место рождения).

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

Описание процесса автоматического наполнения Базы Знаний (на основе FIG. 4):

1. Идентификация пробела: Система анализирует Entity Database и находит сущность, для которой отсутствует объект в триплете (например, (Барт Симпсон, Сестры, ?)).
2. Генерация запроса: Interrogative Query Engine генерирует один или несколько вопросительных запросов, используя алиасы сущности и термины, связанные с отношением (например, "кто сестры Барта Симпсона?").
3. Получение сниппетов: Запрос отправляется в поисковую систему, которая возвращает Snippets из топовых релевантных документов.
4. Аннотирование: Annotator обрабатывает сниппеты, выполняя NLP-анализ (например, идентифицирует "Лиза" и "Мэгги" как сущности типа "Персона" и определяет их синтаксическую связь со словом "сестры").
5. Извлечение кандидатов: Candidate Answers Engine извлекает потенциальные ответы. Отбор происходит на основе соответствия типа ответа типу отношения (например, для "сестры" ищутся "Персоны") и синтаксических связей в тексте сниппета.
6. Оценка и выбор ответа: Answer(s) Selection Engine рассчитывает оценку уверенности (score) для каждого кандидата. Оценка базируется на количестве подтверждающих сниппетов, количестве уникальных ресурсов и качестве этих ресурсов. Выбираются ответы, превысившие порог.
7. Валидация и разрешение сущности: Система проверяет, существуют ли найденные ответы в Entity Database. Если ответ двусмысленный или новый, могут быть сгенерированы дополнительные запросы для его уточнения (Claim 7) или валидации (Claims 3, 5).
8. Обновление Базы Данных: Система определяет новую связь в Entity Database (например, (Барт Симпсон, Сестры, {Лиза Симпсон, Мэгги Симпсон})).

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

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

• Контентные факторы: Текст сниппетов (Snippets) из веб-ресурсов. Это основной источник для извлечения фактов.
• Структурные данные (из Entity Database):
  • Существующие сущности и их уникальные идентификаторы.
  • Алиасы сущностей (используются для генерации запросов и поиска упоминаний в сниппетах).
  • Существующие отношения (триплеты).
• Системные данные (из Search System): Показатели качества или рейтинг ресурсов (measures associated with the search result resources), из которых получены сниппеты. Используются для оценки достоверности извлеченных фактов.

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

Система использует два основных набора метрик: NLP-метрики для анализа текста и метрики достоверности для выбора ответа.

NLP-метрики (Annotator):

• Part of Speech Tagging (Разметка частей речи): Определение грамматической роли термина (существительное, глагол и т.д.).
• Dependency Parsing (Синтаксический анализ зависимостей): Определение синтаксических отношений между терминами (например, построение дерева разбора для понимания, кто субъект, а кто объект в предложении).
• Entity Tagging (Распознавание именованных сущностей): Аннотирование упоминаний сущностей в тексте и их типизация (Персона, Локация, Организация и т.д.).
• Coreference Resolution (Разрешение кореференции): Группировка упоминаний, относящихся к одной и той же сущности (например, "Барт Симпсон", "Барт" и "он").

Метрики выбора ответа (Answer Selection):

• Snippet Count (Количество сниппетов): Частота, с которой кандидат упоминается в сниппетов (Claim 13).
• Resource Count (Количество ресурсов): Количество уникальных веб-ресурсов (сайтов), подтверждающих ответ (Claim 14).
• Resource Quality/Ranking (Качество/Рейтинг ресурсов): Использование показателей авторитетности или ранжирования источников, подтверждающих ответ (Claim 15).
• Score (Оценка уверенности): Агрегированная метрика, рассчитываемая для каждого кандидата на основе вышеперечисленных факторов.

1. Автоматизация Knowledge Graph: Патент демонстрирует конкретный механизм, как Google автоматически извлекает факты из неструктурированного веба для построения и обновления своей структурированной базы знаний (Entity Database). Система не полагается только на ручную модерацию или структурированные данные (например, Schema.org).
2. Рекурсивное обнаружение сущностей: Система способна не только находить атрибуты известных сущностей, но и обнаруживать совершенно новые сущности и рекурсивно исследовать их связи для добавления в базу знаний (Claim 3).
3. NLP как основа извлечения фактов: Ключевую роль в понимании контента играет Annotator. Извлечение фактов основано на глубоком лингвистическом анализе (синтаксис, грамматика, распознавание сущностей), а не просто на поиске ключевых слов. Система ищет определенные языковые паттерны.
4. Важность консенсуса и качества источников: При выборе правильного ответа система полагается на консенсус (количество сниппетов и ресурсов, подтверждающих факт) и качество этих ресурсов (Claims 13-15). Это подчеркивает важность E-E-A-T и консистентности информации в вебе.
5. Единый механизм для FS и KG: Описанный механизм используется как для ответов на запросы пользователей в реальном времени (Featured Snippets), так и для офлайн-наполнения Knowledge Graph. Оптимизация под одно улучшает видимость в другом.

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

• Обеспечение ясности и простоты формулировок (Clarity): Пишите контент так, чтобы Annotator мог легко выполнить синтаксический разбор предложений и определить связи между сущностями. Используйте четкие, недвусмысленные утверждения при описании фактов (например, "[Сущность] является [Объектом]" или "[Сущность] родилась в [Локация]").
• Использование паттернов "Вопрос-Ответ": Структурируйте контент так, чтобы он явно отвечал на потенциальные Interrogative Queries. Это увеличивает шансы на попадание в Featured Snippets, так как система ищет именно такие ответы.
• Консистентность и точность фактов: Поскольку система ищет консенсус (Resource Count, Snippet Count) для выбора ответа, важно, чтобы предоставляемые вами факты были точными и соответствовали информации на других авторитетных ресурсах.
• Развитие авторитетности ресурса (E-E-A-T): Качество ресурса (Resource Quality) используется как фактор при оценке достоверности извлеченного факта (Claim 15). Авторитетные сайты имеют больший вес в формировании ответов и Knowledge Graph.
• Насыщение контента сущностями и связями: Помогайте системе обнаруживать новые связи и подтверждать существующие, подробно описывая сущности и их взаимоотношения с другими сущностями в тексте.

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

• Сложные и двусмысленные формулировки: Использование слишком сложных предложений, метафор или иронии при описании фактов затрудняет работу Dependency Parser и Entity Tagger, снижая вероятность корректного извлечения информации.
• Изоляция фактов от текста: Предоставление ключевых фактов только в виде изображений, видео или сложной инфографики без текстового сопровождения делает их недоступными для анализа Annotator.
• Противоречие авторитетным источникам: Публикация фактов, которые противоречат общепринятому консенсусу в авторитетных источниках. Система, скорее всего, проигнорирует такие данные, так как они не будут подтверждены достаточным количеством качественных ресурсов.

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

Этот патент подтверждает стратегический приоритет Google на переход от поиска по ключевым словам к поиску, основанному на сущностях и фактах. Для SEO это означает, что оптимизация должна фокусироваться не только на релевантности запросу, но и на способности контента служить надежным источником структурированных знаний. Стратегия должна включать работу над тем, чтобы Google воспринимал сайт как источник достоверных фактов, что достигается через ясность контента и высокий уровень E-E-A-T.

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

Сценарий: Оптимизация страницы для извлечения фактов (Featured Snippet и Knowledge Graph)

Задача: Обеспечить извлечение факта о месте рождения известной личности.

1. Анализ Интента: Определить вероятный запрос пользователя: "где родился [Имя]?" или потребность системы: ([Имя], Место Рождения, ?).
2. Плохая реализация (сложно для извлечения): "[Имя], чья карьера охватила десятилетия, начал свой жизненный путь в шумном мегаполисе [Город], куда его родители переехали за год до этого..." (Слишком много дополнительной информации, синтаксис усложнен).
3. Хорошая реализация (легко для извлечения): "[Имя] родился в [Город], [Страна]." (Четкое утверждение, прямой синтаксис: Субъект - Глагол - Объект).
4. Действие: Разместить хорошую реализацию в prominent месте (например, в первом абзаце или в блоке краткой информации).
5. Ожидаемый результат: Annotator легко идентифицирует [Город] как Локацию и определит его синтаксическую связь с [Имя] и глаголом "родился". При достаточном авторитете сайта этот факт будет использован в Featured Snippet и/или для обновления Knowledge Graph.