Как Яндекс ускоряет поиск по структурированным данным и фильтрам в вертикальных сервисах (Авто.ру, Маркет, Недвижимость) с помощью иерархических индексов и статистических снимков

Описание

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

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

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

Запатентован способ формирования специфической иерархической структуры данных (древовидного индекса) и способ поиска с ее помощью. Суть изобретения заключается в организации данных таким образом, что каждый уровень иерархии соответствует определенному типу данных (например, «Марка автомобиля»), а узлы на этом уровне содержат конкретные дескрипторы (например, «BMW»). Ключевая особенность — хранение в конечных (листовых) узлах статистического снимка (Statistical Snapshot) — агрегированной информации об элементах, соответствующих пути к этому узлу.

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

Система строит дерево, где каждый уровень жестко привязан к типу данных. При индексации объявления система проходит по дереву, создавая узлы для его дескрипторов (Марка -> Модель -> Год). В конечном (листовом узле) система сохраняет и обновляет статистический снимок: считает общее количество объявлений в этой ветке и отслеживает минимальную и максимальную цену. При получении поискового запроса с фильтрами система быстро обходит дерево и мгновенно извлекает готовую статистику из листовых узлов. Если запрос затрагивает несколько веток, система агрегирует снимки из соответствующих узлов.

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

Высокая для вертикальных поисковых систем и E-commerce. Описанный механизм критически важен для реализации быстрого фасетного поиска и мгновенного обновления счетчиков результатов при применении фильтров. Технологии пре-агрегации данных остаются фундаментальными для пользовательского опыта в таких сервисах как Яндекс.Маркет, Авто.ру, Яндекс.Недвижимость.

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

Влияние на традиционное SEO (поиск по вебу) минимально (2/10). Патент описывает инфраструктуру для работы со структурированными данными в рамках вертикальных сервисов Яндекса, а не алгоритмы ранжирования веб-документов. Однако для SEO-специалистов, работающих с e-commerce и агрегаторами, которые предоставляют данные в эти вертикали (например, через YML/XML фиды), патент имеет высокое значение (7/10). Он демонстрирует, как именно структурированные атрибуты (дескрипторы) используются для построения поисковой структуры и системы фильтрации, подчеркивая критическую важность качества данных в фидах.

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

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

Data Type (Тип данных)

Категория или атрибут, описывающий элемент данных. Например, «Марка автомобиля», «Модель автомобиля», «Год выпуска», «Цена». В патенте каждый уровень иерархической структуры соответствует одному типу данных.

Descriptor (Дескриптор)

Конкретное значение атрибута элемента данных, связанное с определенным типом данных. Например, «BMW» (тип «Марка»), «X5» (тип «Модель»).

Hierarchical Data Structure (Иерархическая структура данных / Дерево индексов)

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

Index Tree Management Device (Устройство управления деревом индексов)

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

Leaf Node (Листовой узел)

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

Sequential Data Structure (Последовательная структура данных)

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

Statistical Snapshot (Статистический снимок)

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

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

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

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

1. Определяется множество элементов данных, каждый из которых имеет набор дескрипторов разных типов.
2. Создается иерархическая структура с уровнями (например, Уровень 1 и Уровень 2).
3. На Уровне 1 размещается родительский узел, который хранит первый дескриптор (например, «Audi»), относящийся к первому типу данных (например, «Марка»).
4. На Уровне 2 размещаются дочерние узлы, зависящие от родительского.
5. Ключевое требование: Каждый дочерний узел хранит второй дескриптор (например, «A4», «A6»), и все эти вторые дескрипторы относятся к одному и тому же второму типу данных (например, «Модель»), который отличается от первого типа.

Claim 12 и 13 (Зависимые пункты): Определяют Статистический снимок и его содержимое.

Листовой узел (конечный узел ветви) обновляется с помощью статистического снимка. Этот снимок включает: (i) количество элементов данных, связанных с этим листовым узлом; (ii) указание на минимальное значение определенного дескриптора (например, минимальная цена); (iii) указание на максимальное значение этого же дескриптора (максимальная цена).

Claim 20 (Независимый пункт): Описывает способ поиска.

1. Получение поискового запроса с параметром (например, «Марка=Audi»).
2. Обнаружение ветви в иерархической структуре, где узел содержит дескриптор, совпадающий с параметром запроса.
3. Получение доступа к листовому узлу этой ветви.
4. Извлечение данных (статистического снимка) из листового узла.

Claim 27 (Зависимый пункт): Описывает агрегацию статистики при поиске.

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

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

Изобретение применяется в инфраструктуре вертикального поиска Яндекса (в патенте явно упоминается Яндекс.Авто, но технология применима к Маркету, Недвижимости и т.д.) и затрагивает этапы индексации и поиска/фильтрации.

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

1. Кластер индексации: Обрабатывает входящие объявления (например, из XML/YML фидов). Выполняет разбор, унификацию (приведение атрибутов к единому формату) и сохранение в базу.
2. Индексатор: Создает первичные индексы.
3. Устройство управления деревом индексов: Ключевой компонент. Он получает данные из хранилища индексов и строит описанную в патенте иерархическую структуру данных (Дерево Индексов). Устройство определяет уровни дерева (порядок типов данных) и заполняет его, вычисляя статистические снимки для листовых узлов. Этот процесс может запускаться периодически (например, каждый час).

RANKING – Ранжирование (Стадия Поиска/Retrieval)
На этом этапе структура используется для быстрого ответа на запросы с фильтрами (фасетный поиск).

• Поисковик: Получает запрос пользователя и обращается к Дереву Индексов. Он выполняет быстрый обход дерева в соответствии с параметрами запроса для извлечения готовых статистических снимков из соответствующих листовых узлов.

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

На что влияет

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

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

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

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

Процесс А: Построение Иерархической Структуры (Выполняется Устройством управления деревом индексов)

1. Инициализация: Определение порядка уровней дерева на основе Типов Данных (например, Уровень 1=Марка, Уровень 2=Модель, Уровень 3=Год). Создание корневого узла.
2. Обработка элемента данных: Получение нового элемента данных (объявления) для индексации (например, «Audi, A4, 2008, 15000»).
3. Обход и построение дерева (Уровни 1..N): Система последовательно ищет дескрипторы элемента («Audi», затем «A4», затем «2008») на соответствующих уровнях. Если узел для дескриптора не найден, он создается под соответствующим родительским узлом.
4. Обработка Листового Узла: Достижение листового узла, соответствующего полному пути.
5. Обновление Статистического Снимка:
   1. Счетчик элементов данных увеличивается на 1.
   2. Извлечение значения дескриптора для статистики (например, Цена=15000).
   3. Сравнение значения с текущими минимальным (Min) и максимальным (Max) значениями в снимке. Если новое значение меньше Min или больше Max, снимок обновляется.
6. Повторение: Шаги 2-5 повторяются для всех элементов данных.

Процесс Б: Поиск Данных (Выполняется Поисковиком)

1. Получение и разбор запроса: Получение запроса и извлечение ключевых параметров (например, «Audi, A6, 2007»).
2. Обход дерева (Уровни 1..N): Система последовательно обходит дерево, находя узлы, соответствующие дескрипторам запроса («Audi» -> «A6» -> «2007»).
3. Обработка пропущенных уровней: Если дескриптор для какого-то уровня в запросе не указан (например, запрос «Audi 2008», пропущена Модель), система выбирает ВСЕ дочерние узлы на этом уровне (все модели Audi) и продолжает обход для каждой из них.
4. Извлечение Статистики: Достижение релевантных листовых узлов. Извлечение статистических снимков (Количество, Мин/Макс Цена).
5. Агрегация (если необходимо): Если было найдено несколько листовых узлов (как на шаге 3), их статистические снимки объединяются: счетчики суммируются, вычисляются общие минимум и максимум.
6. Выдача результата: Возврат агрегированной статистики пользователю (например, для отображения счетчиков на фильтрах или диапазона цен в превью).

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

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

Система использует исключительно структурированные данные, полученные от партнеров (например, через XML/YML фиды) или введенные пользователями на сервисах Яндекса.

• Контентные факторы (Структурированные атрибуты): Используются дескрипторы элементов данных. В патенте в качестве примеров для автомобилей указаны: Год выпуска, Марка, Модель, Цена, Цвет. Часть из них используется для построения иерархии (например, Марка, Модель, Год), а часть — для расчета статистики (например, Цена).
• Системные данные: Словари и каталоги, используемые на этапе индексации для унификации (нормализации) названий дескрипторов (например, приведения синонимов марок и моделей к единому виду).

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

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

Система вычисляет и хранит метрики в составе Статистического снимка:

• Количество элементов (Count): Простой счетчик количества объявлений, которые соответствуют определенной ветви дерева.
• Минимальное значение дескриптора (Min Value): Минимальное значение определенного числового атрибута (например, цены) среди всех объявлений в данной ветви.
• Максимальное значение дескриптора (Max Value): Максимальное значение этого же числового атрибута.

Методы расчета:

• Обновление снимка: При добавлении нового объявления счетчик увеличивается, а значения мин/макс обновляются только в том случае, если значение нового объявления выходит за пределы текущего диапазона (инкрементальное обновление).
• Агрегация при поиске: Если запрос охватывает несколько листовых узлов, система агрегирует их снимки:

  $$Count_{Total} = \sum Count_i$$

  $$Min_{Total} = \min(Min_i)$$

  $$Max_{Total} = \max(Max_i)$$

Выводы

1. Инфраструктура для вертикального поиска: Патент описывает решение, критически важное для работы вертикальных сервисов Яндекса (Маркет, Авто.ру и т.д.), но не имеющее отношения к ранжированию в основном веб-поиске. Это патент об оптимизации баз данных, а не о SEO.
2. Скорость за счет пре-агрегации: Ключевой механизм ускорения фасетного поиска — это пре-агрегация статистики (статистический снимок) на этапе индексации. Хранение готовых счетчиков и диапазонов цен в листовых узлах позволяет мгновенно отвечать на запросы с фильтрами.
3. Иерархия по типам данных: Структура данных строится путем последовательного разделения по типам атрибутов (Марка -> Модель -> Год). Это обеспечивает эффективную организацию данных для фильтрации.
4. Важность унификации данных: Для корректной работы системы входящие данные должны быть унифицированы (нормализованы). Система должна корректно распознавать синонимы и разные форматы записи, чтобы поместить их в один узел дерева.
5. Оптимизация хранения: Упоминается возможность физической реализации структуры в виде компактного последовательного массива (Sequential Data Structure) для дополнительного ускорения доступа к данным и экономии памяти.

Практика

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

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

• Обеспечение полноты структурированных данных: Передавайте максимально возможное количество атрибутов (дескрипторов) для каждого товара или объявления. Чем больше атрибутов доступно системе, тем в большем количестве срезов (фильтров) будет участвовать ваш контент, так как он попадет в соответствующие ветви иерархической структуры.
• Точность и корректность атрибутов: Критически важно передавать точные данные, особенно числовые (цена, год, размеры). Ошибки в ценах напрямую повлияют на статистические снимки (Мин/Макс Цена) и могут привести к исключению ваших предложений из выдачи при использовании ценовых фильтров.
• Унификация и стандартизация данных в фиде: Приводите названия атрибутов и их значения к общепринятым стандартам или рекомендациям Яндекса. Это гарантирует, что система Яндекса корректно унифицирует ваши данные и поместит их в нужные узлы иерархической структуры. Например, используйте стандартные названия моделей и брендов.
• Актуальность данных и частота обновлений: Обеспечьте своевременное обновление фидов при изменении цен или наличия. Поскольку система перестраивает дерево индексов и обновляет статистические снимки на основе этих данных, неактуальная информация может негативно сказаться на представлении ваших товаров.

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

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

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

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

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

Сценарий: Оптимизация фида для Яндекс.Авто (Авто.ру)

1. Задача: Улучшить видимость объявлений автодилера в поиске Авто.ру при использовании фильтров.
2. Анализ (на основе патента): Видимость зависит от того, насколько корректно объявления попадают в узлы иерархической структуры (Марка/Модель/Год) и как они влияют на Статистический Снимок (Цена, Количество).
3. Действия:
   1. Провести аудит XML-фида. Убедиться, что все ключевые поля (make, model, year, price) заполнены для 100% объявлений.
   2. Стандартизировать значения. Проверить, что названия моделей и марок соответствуют каталогу Авто.ру (например, «X5», а не «Икс Пятый» или «X5 New»).
   3. Убедиться, что в поле «price» передается финальная актуальная цена.
4. Ожидаемый результат: Объявления корректно индексируются в иерархической структуре. При выборе пользователем фильтра «BMW» -> «X5» -> «2012», объявления дилера корректно учитываются в статистическом снимке, отображаются в счетчике результатов и попадают в выдачу, если их цена соответствует запрошенному диапазону.

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