Close Menu
    Telegram
    SEO HARDCORE
    • Разборы патентов
      • Патенты Google
      • Патенты Яндекс
    • Скоро
      SEO инструменты
    • Скоро
      SEO аналитика
    SEO HARDCORE
    Разборы патентов • Патенты Google

    Как Google использует приватные данные с вашего устройства для переписывания запросов и глубокой персонализации поиска

    ON-DEVICE QUERY REWRITING (Переписывание запросов на устройстве)
    • US11120090B2
    • Google LLC
    • 2021-09-14
    • 2016-04-05
    2016 Knowledge Graph Matthew Sharifi Патенты Google Персонализация Поведенческие сигналы

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

    • Описание
    • Детальный разбор
    • Выводы
    • Практика
    • Вопросы и ответы
    • Наверх

    Описание

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

    Патент решает проблему недостатка глубокого персонального контекста у серверных поисковых систем при обработке ассистивных и неоднозначных запросов. Например, для ответа на запрос «где поужинать с Дэвидом?» системе нужно знать предпочтения Дэвида. Эта информация часто хранится локально на устройстве пользователя и является приватной. Изобретение позволяет обогатить запрос необходимым контекстом, используя локальные данные, но минимизируя раскрытие приватной информации за счет обработки на устройстве.

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

    Запатентована система переписывания запросов непосредственно на клиентском устройстве (on-device query rewriting). Система использует локально хранящуюся Private Knowledge Base (Приватную Базу Знаний), содержащую факты о сущностях (людях, местах и т.д.), извлеченные из локальных данных пользователя. При получении запроса система идентифицирует упомянутые сущности, извлекает релевантные факты из локальной базы и аннотирует запрос этими фактами перед отправкой на сервер.

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

    Ключевой механизм работы системы:

    • Построение локальной базы: Устройство постоянно анализирует локальные данные (введенный текст, контент на экране, данные сенсоров, голосовые взаимодействия) и строит Private Knowledge Base (локальный граф знаний).
    • Анализ запроса: При получении запроса система идентифицирует сущности (например, контакт «Боб») и категорию запроса (например, «Ресторан»).
    • Выборка фактов (Fact Selection): Система выбирает только те факты о Бобе, которые релевантны категории «Ресторан» (например, «любит итальянскую кухню»), игнорируя нерелевантные (например, его хобби).
    • Аннотирование и Анонимизация: Запрос аннотируется выбранными фактами. Сущности могут быть анонимизированы (Боб -> PersonA).
    • Отправка на сервер: Аннотированный запрос отправляется в поисковую систему, которая использует этот добавленный контекст для персонализации выдачи.

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

    Высокая. Ассистивный поиск (Google Assistant), глубокая персонализация и обработка данных на устройстве (On-device processing / Edge Computing) являются ключевыми технологическими трендами в 2025 году. Этот патент описывает конкретную архитектуру для баланса между полезностью поиска и конфиденциальностью данных.

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

    Влияние на SEO умеренно-высокое (65/100). Патент критически важен для понимания этапа Понимания Запросов (Query Understanding) и Персонализации. Он демонстрирует, что запрос, который фактически обрабатывается алгоритмами ранжирования на сервере, может радикально отличаться от того, что ввел пользователь, из-за добавления приватного контекста. Это усложняет традиционный анализ ключевых слов и повышает важность оптимизации под сущности (Entity SEO) и контекстуальные интенты.

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

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

    Annotated Search Query (Аннотированный поисковый запрос)
    Исходный запрос, дополненный контекстной информацией (фактами) из локальной базы знаний перед отправкой на сервер.
    Category (Категория)
    Классификация намерения запроса (например, рестораны, фильмы, развлечения). Используется для фильтрации релевантных фактов.
    Client-side assistant device (Клиентское ассистивное устройство)
    Устройство пользователя (смартфон, умная колонка), на котором происходит локальная обработка данных и переписывание запроса.
    Entity (Сущность)
    Именованный объект (человек, место, организация и т.д.). В Claims этого патента акцент сделан на сущностях, которые не являются пользователем устройства.
    Fact Selector (Селектор фактов)
    Компонент на устройстве (часть On-device query rewrite engine), который выбирает релевантное подмножество фактов из локальной базы знаний для аннотирования запроса.
    Private Knowledge Base / Local Knowledge Graph (Приватная База Знаний / Локальный Граф Знаний)
    Модель данных, хранящаяся исключительно на устройстве пользователя. Содержит сущности, факты и отношения, извлеченные из локальных данных.
    On-device Query Rewrite Engine (Механизм переписывания запросов на устройстве)
    Система на клиентском устройстве, отвечающая за анализ, выбор фактов и аннотирование запроса.
    Server-side assistant device (Серверное ассистивное устройство)
    Удаленная поисковая система, которая получает и обрабатывает аннотированный запрос.

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

    Патент US11120090B2 является продолжением (continuation) более ранних заявок. Приведенные ниже Claims определяют узкое ядро именно этого изобретения.

    Claim 1 (Независимый пункт): Описывает основной метод, выполняемый на клиентском устройстве (client-side assistant device).

    1. Доступ к локальному хранилищу (local storage). Хранилище содержит данные о сущностях, которые НЕ являются пользователем устройства, и связи между ними.
    2. Важное уточнение: эти данные извлекаются из локальных голосовых взаимодействий (local, spoken interactions) между пользователем и устройством.
    3. Получение запроса от пользователя.
    4. Определение, ссылается ли запрос на конкретную сущность (не являющуюся пользователем), данные о которой есть в локальном хранилище.
    5. Если да, то:
      • Определение «выбранных данных» (select data) об этой сущности из локального хранилища.
      • Передача на серверное устройство (server-side assistant device) представления запроса И этих «выбранных данных».
    6. Получение от сервера ответа на запрос, который был адаптирован (tailored) сервером с учетом «выбранных данных».

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

    Claim 3 (Зависимый от 2): Уточняет, что аннотированное представление генерируется механизмом переписывания запросов на устройстве (on-device query rewrite engine).

    Claim 4 (Зависимый): Уточняет, что происходит выбор «надлежащего подмножества фактов» (proper subset of facts). Это подразумевает, что передаются не все данные о сущности, а только релевантная часть.

    Claim 6 (Зависимый): Метод включает удаление приватной информации (private information), связанной с выбранными данными, перед их передачей на сервер. Это указывает на механизм фильтрации для защиты конфиденциальности.

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

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

    INDEXING (Клиентский уровень)
    Патент подразумевает наличие процесса индексирования на самом устройстве. Система постоянно собирает и обрабатывает локальные данные (включая spoken interactions) для построения и обновления Private Knowledge Base. Это фоновый офлайн-процесс.

    QUNDERSTANDING – Понимание Запросов (Клиентский уровень)
    Это основной этап применения патента. Обработка запроса начинается на устройстве:

    1. NLP и Распознавание Сущностей: Локальная система обрабатывает запрос для выявления сущностей и категорий.
    2. Извлечение Контекста: On-device query rewrite engine извлекает релевантные факты из Private Knowledge Base.
    3. Переписывание Запроса: Запрос аннотируется, фильтруется и модифицируется перед отправкой на сервер.

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

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

    • Исходный запрос пользователя.
    • Private Knowledge Base (локальный граф знаний).
    • Локальные данные устройства (сенсоры, местоположение).

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

    • Annotated Query (Аннотированный запрос), отправляемый на сервер.

    На что влияет

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

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

    • Триггеры активации: Алгоритм активируется, когда система распознает в запросе сущность (особенно ту, что не является пользователем), о которой есть данные в Private Knowledge Base, И когда эти локальные факты релевантны для категории запроса.
    • Условия: Применяется при условии, что пользователь дал разрешение (явное или неявное). Патент утверждает, что пользователь, задавая вопрос о сущности (например, о друге), неявно разрешает раскрыть релевантную информацию о ней для ответа на запрос.

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

    Процесс А: Фоновая обработка (Построение Приватной Базы Знаний)

    1. Сбор локальных данных: Непрерывный сбор данных на устройстве: введенный текст, контент на экране, данные сенсоров, и, как особо отмечено в патенте, голосовые взаимодействия (spoken interactions).
    2. Извлечение сущностей и фактов: Обработка данных для идентификации сущностей (например, контактов, мест) и фактов о них (предпочтения, хобби).
    3. Определение отношений и метрик: Выявление связей между сущностями и присвоение метрик, таких как уровни интереса (interest level).
    4. Хранение: Сохранение данных в локальной модели (Local Knowledge Graph).

    Процесс Б: Обработка запроса в реальном времени

    1. Получение запроса: Система получает поисковый запрос на устройстве.
    2. Идентификация сущностей и категорий: Система NLP анализирует запрос и определяет ссылки на конкретные сущности и категорию запроса.
    3. Доступ к локальной модели: Fact Selector обращается к Private Knowledge Base.
    4. Выборка релевантных фактов: Система выбирает подмножество фактов о сущности, основываясь на категории запроса. (Например, для категории «ужин» выбираются предпочтения в еде, но не хобби).
    5. Фильтрация и Анонимизация (Privacy Control): Система удаляет нерелевантную приватную информацию. Идентификаторы сущностей могут быть анонимизированы (например, Боб Смит -> PersonA).
    6. Аннотирование запроса: On-device Query Rewrite Engine дополняет исходный запрос выбранными фактами (структурированными или неструктурированными).
    7. Передача запроса: Аннотированный запрос передается на серверную поисковую систему.
    8. Получение и постобработка результатов: Устройство получает персонализированный результат. Анонимизированные идентификаторы в результатах (PersonA) маппируются обратно в локальные сущности (Боб Смит) перед отображением пользователю.

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

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

    Патент фокусируется на использовании локальных данных пользователя для обогащения запроса.

    • Пользовательские и Контекстуальные факторы (Локальные):
      • Ранее введенный текст (переписка, заметки).
      • Полученные уведомления.
      • Контент, отображаемый на экране (On-screen information).
      • Данные сенсоров (текущее окружение, местоположение).
      • Голосовые взаимодействия (Spoken interactions): Claim 1 особо выделяет этот источник данных для построения локальной базы знаний.
      • Данные о контактах и их предпочтениях, извлеченные из локальных взаимодействий.

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

    • Interest Level (Уровень интереса): Факты в локальной базе знаний могут иметь числовой показатель интереса сущности. В патенте приводится пример: интерес к верховой езде 0.9, интерес к пчеловодству 0.3. Система использует эти значения для приоритизации фактов.
    • Релевантность Факта Категории Запроса: Метрика, определяющая, насколько конкретный факт полезен для ответа на запрос данной категории. Рассчитывается с помощью машинного обучения (machine learning) или набора правил (rule set).
    • Оценка Конфиденциальности: Система оценивает, какие данные пользователь неявно разрешил использовать, исходя из формулировки запроса, и удаляет нерелевантную приватную информацию.

    Выводы

    1. Сдвиг к обработке на устройстве (On-Device Processing): Патент подтверждает стратегический перенос части процессов Query Understanding с сервера на клиентское устройство. Это ключевой механизм для обеспечения глубокой персонализации при соблюдении конфиденциальности (Edge Computing).
    2. Запросы на сервере отличаются от ввода пользователя: Ключевой вывод для SEO — запрос, который обрабатывают алгоритмы ранжирования Google, может быть значительно богаче и специфичнее, чем то, что пользователь ввел или произнес. Система добавляет скрытый приватный контекст.
    3. Приватный Граф Знаний как основа ассистивного поиска: Успех Google Assistant зависит от качества Private Knowledge Base, которая строится локально из действий пользователя, включая переписку и голосовые взаимодействия.
    4. Персонализация на основе контекста контактов: Система активно использует информацию о предпочтениях и связях третьих лиц (контактов пользователя) для модификации запроса, что является важным аспектом ассистивного поиска.
    5. Встроенные механизмы конфиденциальности: Система включает селективное раскрытие информации (передачу только релевантных фактов) и анонимизацию сущностей (использование идентификаторов типа PersonA) для защиты приватности при передаче данных на сервер.

    Практика

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

    Хотя прямое влияние на SEO ограничено из-за использования приватных данных, патент подтверждает важность следующих стратегических направлений:

    • Оптимизация под сущности и атрибуты (Entity SEO): Критически важно, чтобы ваш бизнес, бренд или контент были четко определены как сущность (Entity) с ясными атрибутами. Используйте структурированные данные (Schema.org) для однозначного определения типа бизнеса и предложений. Если система на устройстве определит предпочтение «Итальянская кухня», в выдаче появятся только те рестораны, которые четко ассоциированы с этим атрибутом.
    • Фокус на удовлетворении нюансированных интентов: Создавайте контент, который отвечает на очень специфические запросы. Поскольку система переписывает общие запросы в более конкретные на основе личного контекста, контент, удовлетворяющий этим конкретным интентам, получает преимущество.
    • Усиление локального SEO и контекста: Локальный контекст и предпочтения активно используются для аннотирования запросов. Наличие точной и полной информации в Google Business Profile и четкое позиционирование (например, «семейный ресторан», «ресторан с веганским меню») критически важно.
    • Развитие Topical Authority: Становитесь авторитетным источником в своей нише. Чем полнее ваш контент покрывает различные аспекты темы и смежные интересы, тем выше шанс соответствовать глубоко персонализированному, переписанному запросу.

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

    • Ориентация только на буквальное совпадение ключевых слов: Стратегии, основанные на точном вхождении ключевых фраз, становятся менее эффективными, так как запрос может быть существенно дополнен или переписан на устройстве пользователя.
    • Игнорирование структурированных данных и сущностей: Неспособность четко определить категорию и сущность вашего контента затруднит его ранжирование по аннотированным запросам, где эта информация является ключевым контекстом.
    • Анализ видимости только по «чистым» запросам: Полагаться на инструменты отслеживания позиций, которые не учитывают персонализацию, становится опаснее. Реальная выдача пользователя может кардинально отличаться из-за локального контекста.

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

    Патент подчеркивает стратегический сдвиг Google в сторону гиперперсонализации, основанной на локальных данных. Для SEO это означает усиление эффекта «черного ящика» и фрагментацию поисковой выдачи. Анализ «усредненной» или «generic» выдачи становится менее надежным. Долгосрочная стратегия должна фокусироваться на построении сильного бренда, четкой тематической экспертизе и оптимизации под сущности и намерения, чтобы оставаться релевантными в мире, где каждый запрос уникально контекстуализирован.

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

    Сценарий 1: Оптимизация сайта ресторана

    1. Ситуация: Пользователь ищет «лучшее место для ужина с Бобом». Устройство знает из локальной базы (например, из переписки), что Боб веган.
    2. Действие системы: Устройство переписывает запрос, добавляя аннотацию: Категория: Ресторан (Контекст: Веганский).
    3. Задача SEO: Ресторан, который хочет привлечь этого клиента, должен быть четко идентифицирован как предлагающий веганские опции.
    4. Реализация:
      • Использование Schema.org/Restaurant с указанием servesCuisine (Веганская) или соответствующих атрибутов меню.
      • Наличие отдельной страницы веганского меню на сайте.
      • Контент в Google Business Profile, явно упоминающий веганские блюда.
    5. Ожидаемый результат: Повышение вероятности ранжирования сайта ресторана по этому персонализированному (аннотированному) запросу.

    Сценарий 2: Персонализированная рекомендация на основе хобби друга

    1. Локальные данные: На смартфоне пользователя хранится информация, что его друг Боб (PersonA) увлекается наблюдением за птицами (Birdwatching).
    2. Исходный запрос: «Какой фильм посмотреть с Бобом?».
    3. Обработка на устройстве: Система идентифицирует Сущность (PersonA) и Категорию (Фильм). Выбирается релевантный факт «Хобби: Birdwatching».
    4. Аннотированный запрос (на сервер): «Movie query; Category: Movie (Context: Birdwatching)».
    5. Обработка на сервере: Поисковая система ищет фильмы, интересные любителям наблюдения за птицами.
    6. Результат: Пользователю рекомендуется документальный фильм о птицах, даже если он не был бы в топе по общему запросу.

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

    Как этот патент влияет на традиционное исследование ключевых слов?

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

    Могу ли я как SEO-специалист узнать, какие данные хранятся в локальной базе знаний пользователя?

    Нет. Private Knowledge Base хранится локально на устройстве пользователя и недоступна сторонним лицам или даже самой Google в полном объеме. Система специально разработана для выборочной передачи только релевантных фактов (select data) в момент запроса. Оптимизация должна основываться на общих паттернах поведения и четкой классификации вашего контента.

    Как Google определяет, какие приватные данные можно отправить на сервер, а какие нет?

    За это отвечает компонент Fact Selector на устройстве. Он анализирует категорию запроса (например, «Ресторан») и выбирает только те факты о сущности (например, о контакте пользователя), которые релевантны этой категории (например, предпочтения в еде). Нерелевантные данные (например, хобби, если запрос про еду) отфильтровываются локально и не передаются. Этот процесс может использовать машинное обучение или заданные правила.

    Что означает упоминание «сущностей, которые не являются пользователем» в Claims?

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

    Как этот механизм влияет на отслеживание позиций и видимости сайта?

    Он значительно усложняет мониторинг. Традиционные инструменты отслеживают позиции по «стерильным» запросам без персонального контекста. Данный патент показывает, что реальная выдача пользователя может быть радикально иной из-за локального переписывания запросов. Это делает данные о средней позиции менее надежными и требует большего внимания к анализу общей видимости, трафика и конверсий.

    Откуда система берет данные для построения локальной базы знаний?

    Патент упоминает широкий спектр локальных данных: ранее введенный текст, уведомления, контент, отображаемый на экране, данные сенсоров устройства. В Claims особо выделяются локальные голосовые взаимодействия (local, spoken interactions). На практике это может включать анализ локальной активности в приложениях на устройстве.

    Что такое структурированные и неструктурированные аннотации?

    Структурированные аннотации используют предопределенные поля и категории, например, добавление к запросу метки «Category: Italian Restaurant». Это легко интерпретируется поисковой системой. Неструктурированные аннотации могут включать фрагменты сырого текста (например, выдержки из локальных данных), которые система считает релевантными для ответа на запрос, предоставляя более богатый, но менее формализованный контекст.

    Что такое «уровень интереса» (interest level) и как он используется?

    Это метрика, хранящаяся в локальной базе знаний, которая количественно оценивает предпочтения сущности (например, контакт пользователя любит верховую езду на 0.9 из 1.0, а пчеловодство на 0.3). При аннотировании запроса Fact Selector может отдавать приоритет фактам с более высоким уровнем интереса, чтобы рекомендовать наиболее предпочтительные варианты.

    Как используется анонимизация в этом процессе?

    Для защиты конфиденциальности устройство может заменить реальные имена сущностей на анонимные идентификаторы перед отправкой на сервер (например, Боб Смит становится PersonA). Сервер обрабатывает запрос, используя предпочтения PersonA. Когда ответ возвращается на устройство, оно может обратно заменить PersonA на Боба Смита перед показом пользователю.

    Какова роль машинного обучения в этом процессе?

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

    Навигация
    • Описание
    • Детальный разбор
    • Выводы
    • Практика
    • Вопросы и ответы
    • Наверх
    Telegram
    © 2025 SEO HARDCORE

    Type above and press Enter to search. Press Esc to cancel.