Как Google использует RAG-архитектуру с двумя LLM (Research и Response) для интеграции данных Google Maps, отзывов и веб-контента в локальный поиск

Описание

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

Патент решает критическую проблему галлюцинаций (hallucinations) и фактических ошибок больших языковых моделей (LLM) при ответах на локальные запросы (location-based requests). Стандартные LLM, обученные на статичных данных, не имеют доступа к актуальной информации о местах (часы работы, цены, свежие отзывы). Это снижает точность и надежность локального поиска на основе ИИ. Изобретение направлено на обеспечение LLM актуальными структурированными данными для повышения качества ответов.

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

Запатентована мультимодельная система (Place LLM Platform), реализующая архитектуру Retrieval-Augmented Generation (RAG) для локального поиска. Суть изобретения — дополнение (augmenting) знаний LLM путем извлечения актуальных структурированных данных о местоположении (structured location data). Система использует специализированную LLM Research Model для генерации запросов к внутренним базам данных (Карты, Веб, UGC) и основную LLM Response Model для синтеза финального ответа на основе полученного контекста.

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

Система функционирует по следующей схеме:

• Анализ запроса (Research): LLM Research Model получает запрос (например, «Спланируй свидание в Челси») и генерирует серию подзапросов к разным источникам (например, «романтические рестораны Челси», «погода Челси»).
• Извлечение данных (Retrieval): Подзапросы выполняются в соответствующих вертикалях (Local Search, Web Search, Weather Search), извлекая фактические (из MapFact, KG) и субъективные (из Geo UGC) данные.
• Формирование промпта (Augmentation): Извлеченные данные, исходный запрос и контекст беседы (Conversation Context) объединяются в промпт.
• Генерация ответа (Generation): LLM Response Model обрабатывает обогащенный промпт и генерирует связный, точный ответ.
• Селективная активация: Система может использовать Query Evaluation System для оценки риска фактической ошибки. Если риск высок, активируется полный RAG-процесс; если риск низок, система отвечает напрямую для экономии ресурсов.

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

Критически высокая. Патент подан в 2024 году и описывает архитектуру, которая лежит в основе интеграции генеративного ИИ в продукты Google, такие как AI Overviews (SGE) и Google Maps. Решение проблемы галлюцинаций через RAG и использование собственных структурированных данных является ключевой стратегией Google.

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

Влияние на локальное SEO (Local SEO) критическое (95/100). Патент подтверждает, что для генеративных ответов Google в первую очередь полагается на свои структурированные данные (Google Maps, Knowledge Graph) и пользовательский контент (отзывы, рейтинги). Точность фактических данных в Google Business Profile (GBP) и качество UGC становятся первостепенными факторами для видимости в генеративном локальном поиске.

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

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

LLM Research Model (Исследовательская модель LLM)

Специализированная LLM, обученная анализировать запрос пользователя и генерировать серию точных поисковых запросов (suggested search queries) к различным базам данных и сервисам для сбора контекстной информации.

LLM Response Model (Модель ответа LLM)

Основная LLM, которая принимает промпт, включающий исходный запрос, контекст беседы и данные, извлеченные Research Model. Генерирует финальный синтезированный ответ.

Retrieval-Augmented Generation (RAG)

Архитектурный подход, описанный в патенте, при котором генерация ответа LLM дополняется информацией, извлеченной из внешних источников в реальном времени для обеспечения точности (grounding).

Structured Location Data (Структурированные данные о местоположении)

Данные о локациях, хранящиеся в организованном формате. Включают объективные и субъективные данные. Источники: MapFact, Geo UGC, KG.

Objective Data / Factual Data (Объективные / Фактические данные)

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

Subjective Data (Субъективные данные)

Информация, основанная на мнениях пользователей: рейтинги, текстовые отзывы (user reviews), обратная связь (Geo UGC).

Query Evaluation System (Система оценки запроса)

Компонент (например, классификатор), который определяет вероятность фактической ошибки (likelihood value) при ответе на запрос. Используется для выбора между использованием RAG (Multi-Model) и прямой генерацией (Single Model) для оптимизации ресурсов.

Post-Processing Model (Модель постобработки)

Компонент, который обрабатывает, ранжирует и выбирает наиболее релевантные данные, полученные в результате подзапросов, перед их передачей в Response Model.

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

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

1. Получение запроса с ассоциированным местоположением.
2. Доступ к данным о местоположении (location-based data) из базы данных.
3. Генерация входных данных для модели (model input), включающих запрос и извлеченные данные.
4. Передача входных данных в LLM.
5. Получение ответа от LLM и его отображение пользователю.

Claim 2 и 3 (Зависимые): Конкретизируют механизм доступа к данным, вводя мультимодельную архитектуру.

Доступ к данным осуществляется путем передачи запроса в machine-learned research model. Эта модель генерирует один или несколько suggested search queries для целевых баз данных. Система извлекает данные, используя эти сгенерированные запросы.

Claim 4 (Зависимый от 2): Описывает механизм селективной активации RAG для оптимизации ресурсов (Query Evaluation System).

1. Система определяет likelihood value — вероятность того, что основная LLM выдаст фактически неверный ответ без использования Research Model.
2. Если вероятность превышает порог (predetermined threshold): активируется Research Model (RAG-процесс).
3. Если вероятность не превышает порог: запрос передается напрямую в основную LLM (без RAG), экономя ресурсы.

Claims 12 и 13 (Зависимые): Детализируют генерацию промпта.

Входные данные генерируются в виде промпта, который может включать дополнительные инструкции (additional instructions). Эти инструкции могут содержать директиву цитировать конкретные источники (cite specific sources) информации в ответе.

Claims 15, 16, 17 (Зависимые): Определяют типы данных и состав ответа.

Структурированные данные включают objective data и subjective data (отзывы и рейтинги). Финальный ответ LLM является комбинацией объективных данных, субъективных данных и синтезированного текста (data generated by the machine-learned model).

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

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

INDEXING – Индексирование и извлечение признаков
Система полагается на существование обширных и актуальных баз данных Structured Location Data (MapFact, Geo UGC, KG). Эти данные индексируются и структурируются на этом этапе.

QUNDERSTANDING – Понимание Запросов
На этом этапе происходит ключевая работа. Query Evaluation System анализирует запрос для принятия решения о необходимости активации RAG. LLM Research Model анализирует интент и преобразует его в серию точных подзапросов к различным вертикалям (Local Search, Web Search и т.д.).

RANKING / METASEARCH – Ранжирование / Метапоиск и Смешивание
После выполнения подзапросов и извлечения данных (Retrieval), Post-Processing Model может ранжировать и выбирать наиболее релевантные фрагменты. Затем LLM Response Model выполняет синтез (Generation), объединяя информацию из разных источников для создания связного ответа.

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

• Исходный запрос пользователя (текст, возможно мультимодальный).
• Данные о местоположении пользователя.
• Контекст беседы (Conversation Context).

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

• Синтезированный ответ, объединяющий фактическую, субъективную и сгенерированную информацию. Форматы: список рекомендаций, сравнение мест (place comparison), план маршрута (itinerary planning).

На что влияет

• Local SEO и GBP: Прямое и критическое влияние на видимость локального бизнеса. Система использует данные из Google Maps и GBP как основной источник фактов для LLM.
• Типы контента: Генерация маршрутов, списков рекомендаций и сравнений мест.
• Типы запросов: Сложные локальные запросы, требующие учета множества факторов (местоположение, тип места, погода, события, отзывы).
• Ниши: Все локальные ниши (рестораны, ритейл, услуги, туризм).

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

• Триггер активации: Наличие локального интента в запросе пользователя.
• Условия применения RAG (Multi-Model): Полный цикл с участием Research Model активируется селективно. Он используется, когда Query Evaluation System определяет высокий риск фактической ошибки (likelihood value выше порога), если LLM будет полагаться только на свои внутренние знания.
• Исключения (Single-Model): Если риск ошибки низкий, система может использовать только Response Model для повышения эффективности и снижения затрат.

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

Процесс обработки локального запроса (Place LLM Platform)

1. Получение и оценка запроса: Система получает запрос. Query Evaluation System оценивает вероятность фактической ошибки (likelihood value).
2. Принятие решения о маршрутизации:
   • Если риск ошибки высок: Активируется многомодельный процесс (RAG flow) (Шаг 3).
   • Если риск ошибки низок: Запрос направляется напрямую в LLM Response Model (Single-Model flow) (Шаг 8).
3. Генерация подзапросов (Research Model): LLM Research Model анализирует запрос и генерирует набор suggested search queries для целевых баз данных (например, [Романтические рестораны рядом с Челси]).
4. Выполнение подзапросов (Retrieval): Подзапросы выполняются в соответствующих сервисах (Local Search, Weather Search, Web Search).
5. Получение результатов: Извлекаются данные из MapFact, Geo UGC, KG, Web.
6. Постобработка: Post-Processing Model ранжирует и выбирает наиболее релевантные данные (факты, сниппеты, отзывы).
7. Формирование промпта (Augmentation): Создается единый промпт, включающий исходный запрос, контекст, извлеченные данные и инструкции (например, о цитировании источников).
8. Генерация ответа (Response Model): LLM Response Model обрабатывает промпт и генерирует финальный ответ, комбинируя синтетический текст с извлеченными данными.
9. Предоставление ответа: Ответ форматируется и предоставляется пользователю.

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

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

Система использует широкий спектр данных для обеспечения точности LLM (grounding), извлекаемых с помощью Research Model:

• Структурированные данные (Objective Data):
  • Источники: MapFact, Knowledge Graph (KG).
  • Типы данных: Адреса, координаты, часы работы, цены, категории, услуги, атрибуты мест. (Ключевые данные из GBP).
• Пользовательский контент (Subjective Data / Geo UGC):
  • Источники: Geo UGC.
  • Типы данных: Отзывы пользователей (user reviews), рейтинги (ratings), пользовательские фотографии.
• Веб-данные (Web Search):
  • Источники: Веб-индекс.
  • Типы данных: Веб-сниппеты, статьи, обзоры со сторонних сайтов, данные с официального сайта бизнеса.
• Контекстуальные и Временные факторы:
  • Данные о погоде (Weather Search), информация о событиях.
• Пользовательские факторы:
  • История разговора (Conversation Context), местоположение пользователя.

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

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

• Likelihood Value (Значение вероятности ошибки): Метрика, рассчитываемая Query Evaluation System. Определяет вероятность того, что Response Model допустит фактическую ошибку без использования RAG.
• Predetermined Threshold (Предопределенный порог): Значение, с которым сравнивается Likelihood Value для принятия решения об активации Research Model.
• Ранжирование входных данных: Post-Processing Model ранжирует извлеченные данные (сниппеты, факты, отзывы) по отношению к темам запроса (ranking against topics), чтобы выбрать наиболее релевантный контекст для Response Model.

Выводы

1. RAG как стандарт для локального поиска на базе ИИ: Google формализует использование Retrieval-Augmented Generation (RAG) как основного механизма для ответов на локальные запросы. Это необходимо для предотвращения галлюцинаций и обеспечения фактической точности (grounding).
2. Архитектура из двух LLM (Research и Response): Подтверждено разделение ролей: Research Model отвечает за планирование и извлечение данных, а Response Model — за синтез ответа. Это позволяет оптимизировать обе задачи независимо.
3. Приоритет структурированных данных Google: Система явно полагается на внутренние данные (MapFact, KG, Geo UGC) как на основной источник истины для LLM. Это смещает фокус Local SEO на оптимизацию этих источников.
4. Субъективные данные (UGC) как ключевой ресурс: Отзывы и рейтинги критически важны. Они используются LLM наравне с фактами для понимания качества, контекста и нюансов локации (атмосфера, удобство).
5. Баланс точности и эффективности (Selective Activation): Патент описывает механизм управления ресурсами (Query Evaluation System). Сложный RAG-процесс активируется только при высоком риске фактической ошибки, что позволяет масштабировать систему.
6. Сдвиг к оптимизации сущностей: Для SEO это означает необходимость фокусироваться на качестве и доступности данных о бизнесе во всей экосистеме Google (Entity Optimization), а не только на веб-сайте.

Практика

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

• Оптимизация под извлечение (Retrieval Optimization): Рассматривайте Google Business Profile (GBP) как основной источник Objective Data. Обеспечьте абсолютную точность, актуальность и полноту всех полей (часы работы, услуги, цены, атрибуты). Research Model извлекает эту информацию напрямую.
• Максимизация и оптимизация субъективных сигналов (UGC): Проактивно управляйте отзывами и рейтингами (Subjective Data). Стимулируйте генерацию качественных, детализированных отзывов, описывающих пользовательский опыт (например, «романтическая атмосфера», «подходит для детей»), так как они напрямую используются для синтеза ответов.
• Обеспечение консистентности данных (NAP Consistency): Гарантируйте совпадение информации в GBP, на сайте (включая микроразметку LocalBusiness) и авторитетных веб-источниках, так как система агрегирует данные из KG, MapFact и Web Search.
• Создание контента для сложных интентов: Разрабатывайте контент на сайте, который помогает планировать маршруты или сравнивать услуги. Это повышает вероятность его извлечения через вертикаль Web Search для дополнения ответа LLM.
• Использование микроразметки (Schema.org): Внедряйте разметку LocalBusiness, Review, Event на сайте для облегчения извлечения и верификации данных из веб-источников.

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

• Неточные или устаревшие данные в GBP: Если структурированные данные неверны, RAG-система извлечет неверные данные, и ответ LLM будет фактически ошибочным, что критично для пользовательского опыта и доверия.
• Игнорирование управления репутацией (Reviews/UGC): Рассматривать отзывы только как сигнал ранжирования недостаточно. Они теперь являются источником контента для синтеза ответов. Отсутствие отзывов или преобладание негатива лишает LLM необходимых данных для положительной рекомендации.
• Фокус только на традиционном веб-ранжировании: Стратегии, ориентированные только на ТОП-10 синих ссылок, теряют эффективность в локальном поиске, так как LLM-интерфейсы (AI Overviews, Google Maps Chat) синтезируют ответы напрямую из структурированных данных.
• Манипуляции с отзывами: Попытки обмануть систему фейковыми отзывами рискованны, так как система может сопоставлять субъективные данные с фактическими данными и информацией из авторитетных веб-источников.

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

Этот патент подтверждает, что будущее локального поиска — это синтезированные ответы ИИ, основанные на архитектуре RAG и данных экосистемы Google. Стратегическое значение заключается в переходе от ранжирования веб-страниц к управлению сущностями (Entity Management) и пользовательским опытом (Experience Management). Для Senior SEO-специалистов это означает необходимость перераспределения ресурсов в сторону оптимизации GBP, UGC и Knowledge Graph как основных источников данных для LLM.

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

Сценарий: Оптимизация ресторана для генеративного ответа на запрос «Лучшее место для свидания в [Город]».

1. Действие (Objective Data): В GBP ресторана активировать атрибуты «Романтическая атмосфера», «Уютное место». Обеспечить актуальность меню и цен.
2. Действие (Subjective Data): Стимулировать отзывы гостей, посетивших ресторан для свидания. Анализировать UGC на упоминания атмосферы.
3. Действие (Web Data): Опубликовать на сайте контент о романтическом ужине, получить упоминания в сторонних обзорах (например, «Топ-10 романтических ресторанов»).
4. Как работает система: LLM Research Model генерирует подзапросы к Local Search и Web Search. Система извлекает атрибуты из GBP, подтверждающие отзывы из UGC и сниппеты из веб-обзоров.
5. Ожидаемый результат: LLM Response Model использует эти данные для включения ресторана в генеративный ответ (AI Overview), цитируя атрибуты и отзывы как обоснование рекомендации.

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