Как Google находит, классифицирует и ранжирует контент «Глубокой паутины» (Deep Web), скрытый за веб-формами

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

Deep Web (Глубокая паутина)

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

Form Database (База данных форм)

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

Form Score (Оценка формы)

Метрика ранжирования, которая оценивает способность формы ответить на запрос пользователя. Рассчитывается путем сравнения входов/выходов, требуемых запросом, с входами/выходами, которые поддерживает форма.

Query Analyzer (Анализатор запросов)

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

Query-Through Link (Ссылка для сквозного запроса)

Ссылка, предоставляемая пользователю, при нажатии на которую автоматически заполняется и отправляется соответствующая веб-форма с использованием данных из исходного запроса пользователя. Содержит invocation string.

Schema Matching (Сопоставление схемы)

Процесс установления соответствия между полями веб-формы и свойствами в Search Ontology.

Search Ontology (SO) (Поисковая онтология)

Онтология классов (SO-classes) и свойств (SO-properties), используемая для классификации веб-источников, веб-форм и запросов пользователей (например, классы: Недвижимость, Персона; свойства: Цена, Местоположение, Имя).

Structured Query (Структурированный запрос)

Внутреннее представление запроса пользователя, где ключевые слова сопоставлены со свойствами предсказанного класса Search Ontology.

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

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

1. Система получает запрос с ключевыми словами.
2. Анализирует запрос для создания структурированного запроса (Structured Query):
   • Предсказывает класс (Class) для запроса.
   • Сопоставляет ключевые слова со свойствами (Properties) этого класса.
   • Генерирует структурированный запрос на основе этого сопоставления.
3. Выполняет поиск в базе данных веб-форм (Form Database) на основе структурированного запроса.
4. Ранжирует возвращенные формы. Ранжирование включает определение Form Score, который отражает способность формы ответить на запрос. Это делается путем сравнения входов и выходов, требуемых запросом (на основе предсказанного класса), и входов и выходов конкретной формы из базы данных.
5. Облегчает поиск контента, доступного через эти формы, используя ранжирование.

Claim 4 и 5 (Зависимые): Детализируют способ предоставления результатов поиска.

Система представляет пользователю ссылку Query-Through Link для интересующей формы. Эта ссылка конструируется путем сопоставления ключевых слов из запроса с полями ввода формы и содержит строку вызова (invocation string). При нажатии на ссылку автоматически отправляется запрос к этой форме.

Claim 7 (Зависимый от 1): Определяет формулу для расчета Form Score (FS(f)).

Оценка формы рассчитывается по формуле:

$FS(f) = \frac{|I_f \cap Q_I|}{|I_f \cup Q_I|} \cdot \frac{|O_f|}{|Q_O|}$

Где: I_f и O_f — входные и выходные свойства формы f; Q_I и Q_O — входные и выходные свойства, извлеченные из запроса пользователя.

Первый член (Коэффициент Жаккара) измеряет, достаточно ли данных в запросе пользователя для заполнения формы. Второй член измеряет способность формы предоставить выходные данные, требуемые пользователем.

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

Предсказание класса может выполняться с помощью одного или нескольких методов:

• Word-based prediction: Предсказание классов, которые с наибольшей вероятностью генерируют ключевые слова запроса (используя схему типа наивного Байеса).
• Property-based prediction: Предсказание классов на основе распознанных значений свойств в запросе (например, распознавание имен, локаций, дат).
• Feedback-based prediction: Предсказание класса на основе анализа Топ-20 результатов обычного поиска по ключевым словам.
• Location detection: Предсказание класса на основе ключевых слов, определенных как названия местоположений.

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

Изобретение охватывает почти все этапы поисковой архитектуры, так как требует комплексного подхода к сканированию, индексированию, пониманию запросов и ранжированию.

CRAWLING – Сканирование и Сбор данных
На этом этапе Web Crawler (или Site Crawler) активно ищет веб-формы на сайтах. Он фильтрует неинтересные формы (например, подписка на email) и устраняет дубликаты. Также может выполняться «глубокое сканирование» — отправка запросов в формы для извлечения контента. Упоминается использование эмуляции Javascript для обхода скриптов, мешающих сканированию.

INDEXING – Индексирование и извлечение признаков
Ключевой этап для этого патента. Система индексирует сами формы и создает Form Database. Происходит анализ (Form Analyzer) и классификация:

• Классификация веб-страницы и самой формы с использованием Search Ontology (с помощью классификаторов TF/IDF).
• Schema Matching: сопоставление полей формы со свойствами онтологии.
• Извлечение метаданных: обязательные поля, типы полей, географическая привязка (Location Prediction).

QUNDERSTANDING – Понимание Запросов
Query Analyzer интерпретирует запрос пользователя. Он предсказывает класс Search Ontology, к которому относится запрос, распознает сущности (имена, локации) и преобразует ключевые слова в Structured Query.

RANKING – Ранжирование
Система выполняет поиск в Form Database. Ранжирование найденных форм использует сложную комбинацию сигналов, включая стандартные (PageRank, ключевые слова) и специфические для этого изобретения (Ontology Score, Location Score и, самое главное, Form Score).

METASEARCH – Метапоиск и Смешивание
Результаты (ссылки на формы или предварительно извлеченный контент) интегрируются в общую выдачу. Система может предоставлять Query-Through Links или отображать результат в виде специального блока (упоминается «one-box»).

На что влияет

• Конкретные ниши или тематики: Наибольшее влияние оказывается на ниши, где контент традиционно предоставляется через базы данных и формы: недвижимость, автомобили, вакансии, каталоги специалистов, локальный поиск, e-commerce с фасетным поиском.
• Специфические запросы: Влияет на запросы, которые подразумевают поиск структурированных данных или объектов с определенными атрибутами (например, «квартиры в аренду Сиэтл до 2000 долларов»).
• Типы контента: Влияет на видимость динамически генерируемого контента и страниц с поисковыми формами.

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

Алгоритм применяется, когда система идентифицирует, что запрос пользователя лучше всего может быть удовлетворен контентом, скрытым за веб-формами.

• Триггеры активации: Когда Query Analyzer с высокой уверенностью предсказывает класс Search Ontology, связанный с формами (например, пользователь ищет объект с атрибутами).
• Условия работы: Наличие релевантных форм в Form Database, которые соответствуют структурированному запросу пользователя.

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

Процесс А: Офлайн-сканирование и индексирование форм (Web Crawler)

1. Обнаружение и фильтрация форм: Краулер обходит веб-сайты, идентифицируя HTML-формы, отсеивая нерелевантные и устраняя дубликаты.
2. Классификация источника и формы: Использование классификаторов (например, TF/IDF) для определения класса Search Ontology для веб-страницы и для самой формы. Учитывается текст всей страницы и текст внутри/вокруг формы.
3. Предсказание местоположения: Определение географической привязки источника и объектов, возвращаемых формой.
4. Анализ полей формы: Извлечение имен полей, видимого текста, типов полей (text, select box) и примеров значений (опции в select box). Предсказание обязательных полей и выходных свойств.
5. Сопоставление схемы (Schema Matching): Сопоставление полей формы со свойствами (SO-properties) предсказанного класса онтологии (например, поле «City» -> свойство «Location»).
6. Сохранение метаданных: Запись всей информации в Form Database.
7. (Опционально) Извлечение контента: Генерация констант для заполнения обязательных полей, отправка формы (возможно, с эмуляцией Javascript) и индексация полученных результатов в веб-индекс.

Процесс Б: Онлайн-обработка запроса (Query Engine)

1. Получение запроса: Система получает запрос пользователя.
2. Анализ запроса (Query Analyzer):
   • Предсказание класса SO: Определение наиболее релевантного класса онтологии с использованием методов Word-based, Property-based и Feedback-based prediction.
   • Распознавание свойств и локаций: Идентификация констант в запросе (имена, локации, даты и т.д.) и разрешение неоднозначностей локаций.
3. Конструирование структурированного запроса: Сопоставление ключевых слов запроса со свойствами предсказанного класса (например, Запрос: «Телефон Дэвида Ко 98102» -> Структурированный запрос: Person{Телефон ?, Имя=Дэвид, Фамилия=Ко, ZipCode=98102}).
4. Поиск в базе данных форм: Выполнение поиска релевантных форм в Form Database на основе структурированного запроса.
5. Ранжирование форм: Расчет оценок для найденных форм на основе линейной комбинации факторов:
   • PageRank источника.
   • Keyword Scores (релевантность текста страницы, анкоров).
   • Ontology Score (релевантность класса запроса классу формы).
   • Form Score (способность формы ответить на запрос, формула в Claim 7).
   • Location Score (близость локации формы к локации в запросе).
6. Подготовка результатов:
   • Вариант 1 (Query-Through): Сопоставление слов запроса с полями ввода формы. Конструирование строки вызова (invocation string), включая внутренние значения для select boxes и обработку Javascript. Генерация Query-Through Links.
   • Вариант 2 (Pre-extracted content): Поиск в веб-индексе среди контента, предварительно извлеченного на Шаге А.7.
7. Представление результатов: Отображение ранжированных ссылок или специального блока («one-box»).

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

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

• Контентные факторы: Текст веб-страницы, текст внутри и вокруг формы, заголовки (title), текст анкоров входящих ссылок (anchor-score), видимый текст (метки) полей формы. Используются для классификации (TF/IDF) и расчета Keyword Scores.
• Технические факторы: HTML-структура форм (имена параметров полей, типы полей, значения опций, скрытые поля), URL форм, фрагменты Javascript на странице (используются для конструирования строки вызова и эмуляции).
• Ссылочные факторы: Количество входящих ссылок на страницу с формой (используется для оценки PageRank).
• Географические факторы: Названия городов, штатов, стран, почтовые индексы на странице и в запросе пользователя. Используются для Location Prediction и расчета Location Score. Данные о населении городов также используются для разрешения неоднозначностей локаций.
• Системные данные: Search Ontology (иерархия классов и свойств). Данные для обучения классификаторов и распознавателей.

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

Система использует несколько ключевых метрик для ранжирования форм:

• Approximate Page Rank Score: Оценка важности страницы, например, логарифм количества входящих ссылок.
• Keyword Scores: Оценка релевантности текста страницы (page-text-score), анкоров и заголовка запросу пользователя.
• Ontology Score: Оценка релевантности класса Search Ontology, предсказанного для запроса, классу формы. Включает query-match-score (уверенность в классе запроса) и ontology-match-score (уверенность в классе формы).
• Form Score (FS(f)): Оценка способности формы ответить на запрос. Рассчитывается по формуле, сочетающей Коэффициент Жаккара для входных параметров и соотношение выходных параметров (подробно описано в анализе Claim 7).
• Location Score: Оценка близости местоположения, связанного с формой, к местоположению, обнаруженному в запросе (например, расчет на основе расстояния в милях).

Агрегация оценок: Различные компоненты оценки объединяются с использованием линейной комбинации. Веса в комбинации динамические и зависят от анализа запроса (например, если класс предсказан с высокой уверенностью, вес Ontology Score увеличивается; если обнаружено местоположение, вес Location Score увеличивается).

Методы анализа: Упоминаются классификаторы TF/IDF, наивный Байес, распознаватели свойств (Property Recognizers), а также методы машинного обучения для сопоставления схем (Schema Matching).

1. Доступ к «Глубокой паутине» систематизирован: Патент описывает конкретную архитектуру для систематического обнаружения, анализа и использования контента, скрытого за веб-формами. Это позволяет поисковой системе выходить за рамки статического веба.
2. Критичность Поисковой Онтологии (SO): Search Ontology является ядром системы. Она используется для классификации форм (офлайн), понимания запросов (онлайн) и сопоставления между ними (Schema Matching). Способность системы понять семантику формы и её полей критически важна.
3. Два пути индексации контента: Система может либо индексировать саму форму и предоставлять пользователю возможность взаимодействия с ней (Query-Through Link), либо предварительно извлекать контент из формы и индексировать его как обычные веб-страницы.
4. Сложное ранжирование форм: Ранжирование форм не зависит только от релевантности страницы. Вводятся специфические метрики: Form Score (насколько форма функционально соответствует запросу), Ontology Score (семантическое соответствие) и Location Score, которые комбинируются с традиционными сигналами (PageRank, ключевые слова).
5. Техническая реализация форм имеет значение: Патент признает трудности при автоматическом взаимодействии с формами (например, из-за Javascript) и предлагает решения, такие как эмуляция Javascript. Технически доступные формы имеют преимущество.
6. Контекст формы важен для классификации: Текст на странице и вокруг формы, а также метки полей играют важную роль в определении назначения формы.

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

Рекомендации актуальны для сайтов, предоставляющих доступ к базам данных через формы (агрегаторы, порталы, E-commerce с фильтрами).

• Четкая семантика форм и полей: Используйте ясные и описательные названия для полей формы (как в атрибуте name, так и в видимом тексте label). Это помогает системе выполнить Schema Matching и корректно сопоставить поля со свойствами Search Ontology.
• Контекстная оптимизация страницы с формой: Страница, на которой размещена форма, должна быть хорошо оптимизирована и иметь сильный ссылочный профиль, так как Keyword Scores и PageRank учитываются при ранжировании формы. Текст вокруг формы должен четко описывать её назначение, помогая классификации.
• Обеспечение технической доступности форм: Избегайте сложного Javascript, который динамически генерирует форму или изменяет строку вызова непредсказуемым образом. Хотя патент упоминает эмуляцию JS, простота реализации повышает надежность анализа.
• Содействие предварительному извлечению контента (GET-запросы): Если возможно, реализуйте функциональность поиска и фильтрации через GET-запросы. Это создает URL с параметрами запроса (GET-string), что значительно упрощает предварительное извлечение контента краулером и индексацию результатов.
• Использование стандартных элементов для списков: Реализуйте выпадающие списки через стандартный <select>. Система использует значения опций для Schema Matching и для генерации констант при предварительном извлечении контента.

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

• Блокировка доступа к контенту за формами: Использование CAPTCHA, сложных многошаговых форм или чрезмерно сложного Javascript для валидации может помешать системе как проанализировать форму, так и предварительно извлечь контент.
• Неоднозначные названия полей: Использование неясных или технических названий полей (например, «field1», «param_x») затрудняет для системы понимание назначения поля и снижает вероятность корректного Schema Matching.
• Размещение форм на пустых страницах: Размещение важной формы на странице без контекстного контента или со слабым ссылочным профилем приведет к низким оценкам Keyword Scores и PageRank, что ухудшит ранжирование формы.
• Использование нестандартных форматов данных: Использование нестандартных форматов для дат, локаций или других структурированных данных затрудняет их распознавание системой.

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

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

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

Сценарий: Оптимизация формы поиска недвижимости

1. Анализ текущей формы: Сайт использует форму с полями «Местоположение» (текстовое поле), «Диапазон цен» (два текстовых поля) и «Тип недвижимости» (select box). Названия полей в коде: «loc», «p1», «p2», «type». Форма отправляется через POST.
2. Проблема: Система Google может испытывать трудности с Schema Matching из-за неясных названий полей. Использование POST затрудняет предварительное извлечение контента.
3. Оптимизация (на основе патента):
   • Перевести форму на использование метода GET, чтобы результаты поиска имели индексируемые URL.
   • Переименовать поля в коде и добавить четкие labels: «city», «price_min», «price_max», «property_type».
   • Изменить поле «Местоположение» на структурированный ввод (например, автозаполнение с географическими данными), чтобы улучшить Location Score.
   • Добавить описательный текст на страницу вокруг формы, объясняющий её возможности.
4. Ожидаемый результат: Google более точно классифицирует форму в Search Ontology (класс: Недвижимость). Schema Matching выполняется корректно. При запросе пользователя «квартиры в Бостоне до 3000 долларов» система сможет сгенерировать корректный Structured Query, а форма получит высокий Form Score. Краулер сможет проиндексировать страницы результатов благодаря GET-запросам.