Патент описывает внутренний механизм Google для преобразования запросов на естественном языке в структурированные операции (например, SQL) для доступа к Базе Знаний. Система анализирует запрос, строит дерево концептов и гиперграф. При возникновении сбоев (двусмысленность, ошибки парсинга) она пытается автоматически их исправить, пробуя альтернативные варианты разбора, или запрашивает уточнения у пользователя.
Описание
Какую задачу решает
Патент решает проблему сбоев, возникающих при попытке компьютерной системы конвертировать запросы на естественном языке (Natural Language Queries) в структурированные запросы (например, SQL) для выполнения в базах знаний (Knowledge Base). Система стремится минимизировать взаимодействие с пользователем при обработке ошибок, опечаток, синтаксической двусмысленности или слишком сложных формулировок, повышая надежность интерпретации запроса.
Что запатентовано
Запатентованы система и метод для конвертации запросов на естественном языке в структурированные операции. Описан детальный пайплайн обработки, включающий парсинг, анализ зависимостей, лексическое разрешение, построение дерева концептов (Concept Tree) и гиперграфа (Hypergraph). Ядром изобретения является механизм обработки сбоев (Failure Handling), который при обнаружении проблем пытается автоматически разрешить их, используя альтернативные варианты разбора (Alternative Parse), или взаимодействует с пользователем для устранения неоднозначностей только в крайнем случае.
Как это работает
Система получает NL-запрос и пропускает его через многоэтапный пайплайн: Парсинг → Анализ зависимостей → Лексическое разрешение → Построение Concept Tree → Анализ и трансформация Concept Tree → Генерация и анализ Hypergraph (для определения связей/joins) → Генерация Virtual Query → Генерация Structured Query.
На любом этапе могут быть обнаружены сбои (Errors) или предупреждения (Warnings). При возникновении проблемы система проверяет наличие альтернативных вариантов разбора запроса. Если альтернативы существуют, они также анализируются и оценивается их качество (Quality Score). Выбирается вариант с наилучшей оценкой. Если автоматическое разрешение невозможно (например, из-за фундаментальной двусмысленности или отсутствия доступа к данным), система может инициировать взаимодействие с пользователем.
Актуальность для SEO
Средняя. Патент подан в 2016 году, до массового применения трансформеров и больших языковых моделей (LLM) в поиске. Описанные методы NLP (парсеры зависимостей, лексиконы, деревья концептов) могут быть частично устаревшими. Однако базовые принципы разбора запросов, необходимость обработки сбоев и итеративного уточнения интента остаются высокоактуальными, особенно при взаимодействии со структурированными источниками данных (например, интерфейсы NL-to-SQL).
Важность для SEO
Влияние на современные SEO-стратегии минимальное (1/10). Патент описывает внутренние инфраструктурные процессы NLP, используемые для преобразования естественного языка в структурированные команды (например, для выполнения запросов к структурированной базе данных), а не алгоритмы ранжирования веб-документов. Он дает глубокое понимание этапов разбора запроса в Google, но не содержит прямых рекомендаций по оптимизации сайтов.
Детальный разбор
Термины и определения
- Alternative Parse (Альтернативный разбор)
- Другой вариант синтаксической интерпретации исходного запроса. Используется системой при сбое основного варианта для попытки корректной обработки.
- Concept Tree (Дерево концептов)
- Промежуточная структура данных, представляющая смысл запроса. Узлы дерева — это концепты (Concepts), сгенерированные из фраз запроса, а ребра отражают зависимости между ними. Дерево трансформируется в процессе анализа.
- Error (Ошибка)
- Критический сбой в процессе конвертации, который блокирует дальнейшую обработку текущего варианта разбора.
- Hypergraph (Гиперграф)
- Представление схемы базы данных (database schema). Используется для определения путей соединения (Joins) между таблицами при формировании структурированного запроса (path resolution for joins).
- Knowledge Base (База знаний)
- Структурированное хранилище информации о сущностях (упоминается Entity Database), к которому система выполняет запросы через структурированные API.
- Lexical Resolution (Лексическое разрешение)
- Процесс сопоставления фраз (n-грамм) из запроса с известными лексиконами и генерация соответствующих концептов (Concepts).
- Natural Language Query (Запрос на естественном языке)
- Ввод пользователя в свободной форме.
- Parsing (Парсинг/Разбор)
- Процесс синтаксического анализа запроса: разбиение на токены/фразы и построение дерева разбора. Упоминаются Dependency parser и Constituency parser.
- Quality Score (Оценка качества)
- Метрика для оценки качества конкретного варианта разбора, основанная на наличии предупреждений (Warnings).
- Structured Operations/Query (Структурированные операции/запрос)
- Формализованный запрос (например, SQL), который генерируется системой для выполнения на API базы знаний.
- Virtual Query (Виртуальный запрос)
- Абстрактное представление компонентов запроса (выбранные атрибуты, фильтры, агрегации, соединения) перед генерацией финального структурированного запроса.
- Warning (Предупреждение)
- Индикатор проблемы, который снижает оценку качества (Quality Score), но позволяет продолжить обработку текущего варианта разбора.
Ключевые утверждения (Анализ Claims)
Claim 1 (Независимый пункт): Описывает основной метод конвертации NL-запроса в структурированные операции для базы знаний. Защищается весь пайплайн:
- Получение Natural Language Query.
- Конвертация, включающая строгую последовательность шагов:
- Парсинг запроса.
- Анализ разобранного запроса для определения зависимостей.
- Выполнение Lexical Resolution.
- Формирование Concept Tree на основе зависимостей и лексического разрешения.
- Анализ Concept Tree для генерации Hypergraph.
- Генерация Virtual Query на основе гиперграфа.
- Обработка Virtual Query для генерации одной или нескольких структурированных операций.
- Выполнение структурированных операций на API базы знаний.
- Возврат результатов поиска.
Claim 4 (Зависимый от 1): Детализирует этап анализа Concept Tree. Он включает анализ концептов и их отношений (родитель-потомок или сестринские связи) и трансформацию дерева. Трансформация может включать аннотирование концептов новой информацией, их перемещение, удаление или слияние с другими концептами.
Claim 7 (Зависимый от 1): Утверждает, что в процессе конвертации система обнаруживает сбой (failure).
Claim 8 (Зависимый от 7): Описывает метод разрешения сбоя путем дополнительной обработки. Эта обработка включает определение того, доступен ли альтернативный разбор (Alternative Parse) для исходного NL-запроса.
Claim 9 (Зависимый от 7): Описывает альтернативный метод разрешения сбоя через взаимодействие с пользователем. Система предоставляет пользователю информацию, идентифицирующую сбой, и в ответ на взаимодействие пользователя модифицирует NL-запрос (или процесс конвертации) для генерации структурированных операций.
Claim 10 (Зависимый от 7): Перечисляет типы сбоев. К ним относятся: плохой разбор (bad parse), неоднозначная ссылка на колонку (ambiguous column reference), неоднозначная константа, неоднозначное время/дата, неиспользованные ключевые слова сравнения или отрицания, ошибки агрегации, пропущенный шаг соединения (missing join step), необработанный концепт, несовпадающая именная группа или отсутствие доступа к данным (missing data access).
Где и как применяется
Изобретение применяется исключительно на этапе QUNDERSTANDING – Понимание Запросов.
Патент детально описывает внутренний пайплайн (NL frontend), который используется для преобразования ввода пользователя на естественном языке в формальную, структурированную команду, пригодную для выполнения запроса к структурированной базе знаний (Knowledge Base).
Входные данные:
- Natural Language Query от пользователя.
- Внутренние данные: Схемы базы данных (Database schema) и лексиконы (Lexicons).
- Права доступа пользователя к данным.
Выходные данные:
- Structured Operations (например, SQL-запрос), готовые к выполнению.
- Или сообщение об ошибке / запрос на уточнение, направленный пользователю.
На что влияет
- Типы запросов и контента: Влияет исключительно на обработку запросов, направленных на извлечение фактов и данных из структурированных баз знаний. Это применимо к интерфейсам NL-to-SQL (например, в аналитических системах). Патент не описывает влияние на ранжирование стандартных веб-документов.
- Языковые и географические ограничения: Система принимает запросы на естественном языке (упоминается английский) и может быть адаптирована для разных языков.
Когда применяется
- Условия работы: Алгоритм применяется каждый раз, когда система получает запрос на естественном языке, который предназначен для обработки структурированной базой знаний.
- Триггеры активации (обработки сбоев): Механизмы обработки сбоев активируются при возникновении ошибок (Error) или предупреждений (Warning) на любом этапе пайплайна конвертации. Примеры триггеров: парсер не смог разобрать предложение (Bad Parse), термин в запросе двусмысленен (Ambiguous Column Reference), не удалось определить путь соединения данных (Missing Join Step).
Пошаговый алгоритм
Описанный процесс является итеративным и направлен на поиск наилучшей интерпретации запроса.
- Получение запроса: Система получает исходный Natural Language Query.
- Итеративная обработка (Парсинг, Анализ, Трансформация):
- Система выполняет парсинг текущей версии запроса (исходного или альтернативного).
- Проводится анализ зависимостей и Lexical Resolution.
- Строится и трансформируется Concept Tree.
- Генерируется и анализируется Hypergraph.
- Система пытается сформировать Virtual Query.
- Проверка на сбои: На этапах обработки система определяет наличие Ошибок или Предупреждений.
- Если Нет сбоев: Переход к Шагу 7 (Генерация структурированного запроса).
- Если Предупреждение: Вычисляется и сохраняется Quality Score для текущего разбора. Переход к Шагу 4.
- Если Ошибка: Ошибка логируется. Переход к Шагу 4.
- Проверка альтернатив: Система определяет, доступен ли Alternative Parse. (Альтернативы могут генерироваться автоматически путем модификации исходного запроса: добавление глаголов типа «Show me…» или «What is…», изменение пунктуации, наложение ограничений на диапазоны токенов).
- Если Да: Возврат к Шагу 2 с новой версией запроса.
- Если Нет: Переход к Шагу 5.
- Выбор лучшего варианта: Когда альтернатив больше нет, система анализирует все полученные разборы и выбирает лучший доступный вариант на основе их Quality Score.
- Финальная проверка: Определяется, является ли выбранный вариант «лучшим разбором» (т.е. не содержит ошибок, хотя может содержать предупреждения).
- Если Да: Переход к Шагу 7.
- Если Нет (все варианты содержат ошибки): Переход к Шагу 8.
- Генерация структурированного запроса: Система генерирует Structured Query на основе лучшего разбора. Может сопровождаться предупреждением для пользователя, если Quality Score не идеален.
- Генерация сообщения об ошибке / Взаимодействие: Система генерирует сообщение об ошибке. В зависимости от типа ошибки (например, при Ambiguous Column Reference или Missing Data Access), система может запросить у пользователя уточнение (Claim 9) или предоставить инструкции по разрешению проблемы.
Какие данные и как использует
Данные на входе
Патент фокусируется на обработке запроса и инфраструктуре конвертации. Он не использует стандартные факторы ранжирования SEO.
- Контентные факторы (Запроса): Текст NL-запроса, его структура, токены, фразы, n-граммы, пунктуация. Идентифицируются ключевые слова сравнения и отрицания, константы, даты.
- Системные данные: Лексиконы (Lexicons), используемые на этапе Lexical Resolution для сопоставления фраз запроса с известными концептами. Схемы базы данных (Database schema), используемые для построения Hypergraph и определения возможных соединений (Joins) между данными.
- Пользовательские факторы: Упоминаются права доступа пользователя к конкретным данным или таблицам. Это используется для определения сбоя типа Missing Data Access.
Какие метрики используются и как они считаются
- Quality Score: Ключевая метрика, используемая для оценки качества конкретного варианта разбора (Parse). Она вычисляется при наличии предупреждений (Warnings). Эта оценка позволяет системе сравнить несколько альтернативных интерпретаций запроса и выбрать наилучшую, минимизируя необходимость взаимодействия с пользователем.
- Правила вывода (Inference Rules): Система использует набор правил вывода, основанных на семантическом представлении Concept Tree, для его трансформации и устранения синтаксических неоднозначностей.
- Методы анализа текста (NLP): Используются методы парсинга (Dependency/Constituency Parsing) и распознавания концептов (Lexical Resolution).
Выводы
- Инфраструктурный фокус на Query Understanding: Патент описывает сложный инфраструктурный процесс понимания запросов, специфичный для взаимодействия со структурированными данными (Knowledge Base), например, в системах NL-to-SQL. Это не патент о ранжировании веб-документов.
- Многоэтапный NLP-пайплайн: Для перевода естественного языка в формальные команды используется детальный пайплайн, включающий промежуточные структуры, такие как Concept Tree (для семантики запроса) и Hypergraph (для моделирования связей в данных).
- Приоритет автоматической обработки сбоев: Ключевой фокус патента — robust-обработка ошибок. Система разработана так, чтобы активно искать альтернативные интерпретации запроса (Alternative Parses) при возникновении сбоев или предупреждений.
- Автоматическое переписывание запроса: Система может автоматически модифицировать исходный запрос пользователя (например, добавляя глаголы), чтобы улучшить качество синтаксического разбора и найти рабочую интерпретацию.
- Взаимодействие с пользователем как крайняя мера: Система прибегает к запросу уточнений у пользователя только тогда, когда автоматическое разрешение неоднозначностей (например, Ambiguous Column Reference) или других сбоев невозможно.
- Минимальная ценность для SEO: Для специалистов по SEO практическая ценность патента минимальна. Он не раскрывает факторов ранжирования веб-сайтов, методов анализа контента сайтов или сигналов качества.
Практика
Патент описывает внутренние процессы Google (Query Understanding) без прямых рекомендаций для SEO.
Best practices (это мы делаем)
Прямых рекомендаций по оптимизации контента, ссылочного профиля или технических аспектов сайтов на основе этого патента сформулировать нельзя.
Worst practices (это делать не надо)
Патент не направлен против каких-либо SEO-тактик или манипуляций и не описывает их, поэтому не определяет худшие практики в контексте SEO.
Стратегическое значение
Стратегическое значение патента заключается в демонстрации технической сложности процесса понимания запросов (Query Understanding) в Google. Система проходит множество итеративных этапов (парсер, дерево концептов, гиперграф, оценка качества альтернатив), чтобы интерпретировать интент пользователя. Это подчеркивает, что понимание запроса — это не простое сопоставление ключевых слов, а сложный процесс семантической и синтаксической интерпретации с многоуровневой обработкой ошибок.
Практические примеры
Практических примеров применения данного патента в работе по SEO продвижению сайтов нет, так как он описывает внутренние механизмы обработки запросов к структурированным базам данных (NL-to-SQL), а не оптимизацию веб-сайтов.
Вопросы и ответы
Описывает ли этот патент, как Google ранжирует сайты?
Нет. Патент не имеет отношения к алгоритмам ранжирования веб-документов. Он описывает исключительно внутренний процесс преобразования запросов на естественном языке в структурированные команды (например, SQL) для обращения к базам знаний (Knowledge Base) и методы обработки ошибок, возникающих во время этого преобразования.
Связан ли этот патент с алгоритмами BERT или MUM?
Патент был подан в 2016 году, до широкого внедрения BERT и других трансформерных архитектур. Он описывает более традиционные методы NLP, такие как парсеры зависимостей, деревья концептов и использование лексиконов. Хотя современные системы Google, вероятно, используют нейросетевые подходы, базовая задача, описанная в патенте (преобразование NL в структуру и обработка сбоев), остается актуальной.
Что такое «Concept Tree» и «Hypergraph» в контексте этого патента?
Concept Tree (Дерево концептов) — это способ представить смысл запроса, где узлы — это концепты (сущности, атрибуты, фильтры), а связи — зависимости между ними. Hypergraph (Гиперграф) используется для моделирования связей внутри базы данных, чтобы понять, как соединить различные данные для ответа на запрос (аналог операции JOIN в SQL).
Что происходит, когда система сталкивается с ошибкой при понимании запроса?
Согласно патенту, система не прекращает работу. Она активирует механизм обработки сбоев и ищет альтернативные варианты разбора (Alternative Parse). Например, она может автоматически перефразировать запрос (добавить «Что такое…» в начало) или изменить пунктуацию. Затем она оценивает качество этих вариантов (Quality Score) и выбирает лучший.
Поможет ли этот патент лучше оптимизировать контент под Граф Знаний (Knowledge Graph)?
Нет, напрямую не поможет. Патент описывает, как обрабатываются *запросы* к базе знаний, а не то, как эта база знаний *наполняется* из веб-контента. Он не дает рекомендаций по оптимизации контента для лучшего извлечения фактов.
Что такое «Alternative Parse» и почему это важно?
Alternative Parse — это другой способ интерпретации синтаксической структуры предложения. Это важно, потому что пользователи часто формулируют запросы неидеально (с ошибками, пропусками слов, двусмысленно). Система пытается найти наилучшую рабочую интерпретацию, итеративно перебирая варианты, чтобы максимально точно понять интент пользователя и избежать сбоя обработки.
Какие типы ошибок система пытается исправить автоматически?
Патент упоминает множество типов, для которых система пробует альтернативные разборы. К ним относятся: плохой синтаксический разбор (Bad Parse), неиспользованные ключевые слова сравнения или отрицания (например, слово «не» не связано с нужным концептом), ошибки агрегации (например, попытка усреднить текстовое поле) и пропущенные шаги соединения данных (Missing Join Step).
В каких случаях система запрашивает уточнение у пользователя?
Система прибегает к этому, когда автоматическое разрешение невозможно. Это касается ошибок, связанных с фундаментальной двусмысленностью: Ambiguous Column Reference (термин может относиться к разным сущностям), Ambiguous Constant, лингвистическая двусмысленность (пример: запрос «bacon and egg sandwich» может означать одно блюдо или два разных), а также при отсутствии доступа к данным (Missing Data Access).
Влияет ли пунктуация в запросе на его понимание системой?
Да, влияет. Патент явно указывает, что одним из способов генерации альтернативных разборов является автоматическое изменение пунктуации. Например, система может удалить вопросительный знак в конце фразы, которая синтаксически не является вопросом, чтобы улучшить качество парсинга и итоговой интерпретации.
Где может применяться такая технология?
Такая технология обычно применяется в системах бизнес-аналитики (BI), внутренних инструментах анализа данных или публичных интерфейсах к большим наборам структурированных данных (например, Google Analytics, BigQuery), позволяя пользователям задавать вопросы к данным без знания SQL. Это не основной механизм веб-поиска.