Генерация ответов на запросы

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

Использование ограничений для ответов на запросы

В этом патенте задаются вопросы о содержании, связанном с фактами о объектах, о которых добавляются вопросы.

Документы об использовании ограничений для ответа на запрос:

GRIP: объяснение отсутствующих ответов на графические запросы на основе ограничений
Ответ на вопрос с использованием удовлетворенности ограничений: QA-by-Dossier-with-Constraints

Интересно, что первый документ ссылается на Google Knowlege Vault как на ссылку. Вероятно, потому что он фокусируется на получении правильных ответов на вопросы с помощью ограничений.

Поскольку в этом патенте так много внимания уделяется семантическому SEO. Это напомнило мне о других патентах Google на эту тему, включая эти два, которые стоит внимательно прочитать:

• Сверка сети знаний Google
• Извлечение сущностей для графов знаний в Google

Патент дает некоторое представление о том, как работают сущности и атрибуты сущностей, как кортежи используются в поиске графа, а также взгляд на семантическое SEO.

Генерация ответов на запросы путем предоставления фактов из базы данных

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

Эти факты могут быть сохранены в виде графика, который может обновляться в режиме реального времени.

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

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

Наиболее естественным ответом может быть ответ, сформулированный в виде грамматического изложения фактов, которые соответствуют вопросу пользователя, чтобы дать ответы на запрос.

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

Получение ответов на запросы с идентификацией атрибутов сущности

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

Затем действия включают доступ к шаблонам-кандидатам для ответов на запросы на основе атрибутов сущности. У каждого шаблона-кандидата есть поля; при этом каждая область связана по крайней мере с одним ограничением.

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

Семантические тройки, связанные с сущностями

Набор информации может быть набором троек сущность-атрибут-значение.

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

Словосочетание – это предложение или часть предложения. Наконец, действия включают передачу слов клиентскому устройству.

Фраза может передаваться в виде звукового сигнала, соответствующего словам.

Ограничения могут включать в себя:

• Ограничение типа
• Временное ограничение
• Гендерное ограничение
• Ограничение отношения
• Ограничение в единственном/множественном числе
• Ограничение единицы измерения
• Детерминирующее ограничение.

Некоторые реализации включают получение множества наборов информации в ответ на один атрибут в запросе.

Далее действия включают:

• Получение шаблона предложения на основе типа объекта, при этом шаблон предложения включает в себя множество полей для фраз
• Добавление фраз в поля шаблона предложения для формирования предложения
• Выбор для каждого набора информации шаблона из набора шаблонов-кандидатов
• Генерация для каждого выбранного шаблона фразы путем добавления соответствующего набора информации в поля соответствующего выбранного шаблона
• Передача предложения, включая фразы, на клиентское устройство

Это может включать ответы на запросы, которые включают множество атрибутов.

• Получение ответов на запросы, определяющих множество атрибутов объекта
• Доступ для каждого атрибута объекта к набору шаблонов-кандидатов для ответов на запросы на основе соответствующего атрибута объекта.
• Получение для каждого атрибута сущности набора информации, отвечающей на соответствующую часть запроса
• Выбор шаблона из соответствующего набора шаблонов-кандидатов
• Генерация для каждого атрибута сущности фразы путем добавления соответствующего набора информации в поля выбранного шаблона
• Получение шаблона предложения на основе типа объекта, при этом шаблон предложения включает в себя множество полей для фраз
• Добавление фраз в поля шаблона предложения для формирования предложения
• Передача предложения, включая фразы, на клиентское устройство

Преимущества этого процесса могут включать в себя:

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

Этот патент на создание ответов на запросы находится в

Генерация ответов на запросы
Изобретатели: Энгин Чинар Сахин, Винисиус Дж. Фортуна и Эмма С. Перски.
Правопреемник: Google LLC
Патент США: 11 321 331
Выдано: 3 мая 2022 г.
Подано: 23 июля 2018 г.

Абстрактный

Сервер получает ответы на запросы, идентифицирующие атрибуты сущности.

Сервер обращается к набору шаблонов-кандидатов для ответа на запрос на основе атрибутов объекта, причем каждый шаблон-кандидат имеет поля, причем каждое поле связывается по меньшей мере с одним ограничением.

Сервер получает набор информации и ответов на запросы и выбирает шаблон из набора шаблонов-кандидатов.

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

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

Наконец, сервер передает фразу клиентскому устройству.

Преобразование фактов из базы данных в предложения

Когда пользователь задает фактический вопрос, поисковая система может предоставить ответы на запрос, обратившись к базе данных.

Некоторые системы, такие как голосовые диалоговые системы, позволяют пользователям планировать запросы как вопросы на естественном языке (например, «Кто президент Японии?»).

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

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

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

Чтобы ответить на такой вопрос, как кто-то женился, система может получить данные, включая все прошлые браки, людей, участвовавших в прошлых свадьбах, даты союзов и типы брачных соглашений. Гибкая база данных, которая представляет факты с использованием структуры графа, может предоставить эти факты.

Доступ к шаблонам кандидатов для генерации ответов на запросы на основе атрибута или атрибутов

После сбора фактов механизм ответов может получить доступ к шаблонам-кандидатам для генерации ответа на основе атрибута или атрибутов, предоставленных в запросе. Например, если первоначальный вопрос звучит так: «На ком был женат Вуди Аллен», речь может идти о «браках». Если фактический запрос «Сколько лет Вуди Аллену», атрибутом может быть «возраст». Как описано ниже, каждый пункт вопроса может соответствовать нескольким шаблонам-кандидатам, например, для поддержки более или менее подробных ответов.

Например, если атрибутом является «возраст», механизм ответов может получить шаблон, который включает дату рождения и возраст (например, {<сущность> родился <дата> и в настоящее время ему <значение> лет}), шаблон который включает только возраст (например, {<entity> в настоящее время <value> лет}) и шаблон, который включает дату рождения и дату смерти (например, {<entity> родился <date> и умер < /дата>}).

Как более подробно описано ниже, части шаблонов, заключенные в «< >» (т. е. поля), могут быть связаны с различными ограничениями на данные, которые они могут содержать.

Как только механизм ответов получает шаблоны-кандидаты, он выбирает наиболее подходящий шаблон на основе нескольких эвристик и генерирует предложение, вставляя факты в шаблон. Затем механизм ответов может предоставить пользователю ответ с исправлением.

Система поиска графов данных

Система может привыкнуть к реализации механизма поиска графа данных с использованием описанных здесь методов.

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

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

Кроме того, системы индексации, системы поиска и кластеры индексов могут быть реализованы на персональном компьютере, например, на портативном компьютере.

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

Узлы могут называться объектами, а ребра могут называться отношениями между двумя объектами. Такие отношения могут быть сохранены несколькими способами.

Хранилище данных на основе графа хранит тройные кортежи, представляющие сущности и отношения в одном примере.

Тройные кортежи, представляющие сущности и отношения

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

Одним из примеров тройки является сущность Вуди Аллен в качестве субъекта (или сущности), отношение, действовавшее в качестве предиката (или атрибута), и сущность Энни Холл в качестве объекта (или значения).

Конечно, граф данных со многими сущностями и даже с ограниченным числом отношений может иметь миллиарды троек.

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

Поиск ответов на запросы

Поисковая система может включать в себя серверы (не показаны), которые принимают запросы от пользователя или клиента и предоставляют эти запросы поисковой системе.

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

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

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

Поисковая система может отправлять запросы только в индексный кластер и может предоставлять результаты поиска из индексного кластера клиенту.

Поисковая система может поддерживать связь с клиентами по сети.

Кластер индекса в поиске ответов на запросы

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

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

Каждый индексный кластер может включать процессоры, сконфигурированные для выполнения машиноисполняемых инструкций или частей программного обеспечения, микропрограммы или их комбинации.

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

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

Преобразователь запросов, который обращается к индексу для получения результатов в ответ на запрос

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

Преобразователь запросов также может быть частью поисковой системы или может быть распределен между поисковой системой и индексным кластером.

Постепенно усложняющиеся запросы и ответы на них

Простой запрос, который включает один атрибут («возраст») и дает один тройной ответ.

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

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

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

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

Сущности могут быть реализованы как часть системы.

Пользователь инициирует запрос с терминами запроса, используя клиентское устройство.

Пользователь может отформатировать исходный запрос как предложение.

Взаимодействие с системой голосового диалога

Пользователь может взаимодействовать с клиентским устройством с помощью голосовой диалоговой системы.

Например, пользователь может произнести запрос «Сколько лет Вуди Аллену?» в микрофон клиентского устройства.

Затем клиентское устройство может выполнить распознавание речи, чтобы преобразовать высказывание в транскрипцию, а затем передать транскрипцию в поисковую систему.

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

Поисковая система получает запрос (например, «Сколько лет Вуди Аллену») от клиентского устройства.

Если запрос закодирован как аудиоречевые данные, поисковая система может преобразовать аудиоречевые данные в транскрипцию.

Затем поисковая система анализирует и форматирует исходный запрос в <entity; attribute> (например, <woody Allen/age<), используя, например, подходящий механизм синтаксического анализа естественного языка.

Затем поисковая система отправляет отформатированный запрос в индексный кластер.

Кластер индекса обращается к индексу для получения результатов в ответ на запрос.

Ответы на запросы в виде троек

Эти результаты могут представлять собой набор фактической информации в виде троек (например, </woody><woody Allen/born/dec. 1,>

Затем индексный кластер передает отформатированный запрос (например, </woody><woody Allen/age> и фактическую информацию, которая отвечает на запрос (например, </woody><woody Allen/born/1 декабря 1935>). к автоответчику.

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

Механизм ответов генерирует ответ следующим образом. Сначала механизм ответов получает атрибут или атрибуты из отформатированного запроса.

Затем механизм ответов использует атрибут или атрибуты для доступа к шаблонам предложения или фразы-кандидата из базы данных шаблонов.

Затем механизм ответов выбирает один из шаблонов на основе фактической информации и различных ограничений, связанных с шаблонами-кандидатами.

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

Механизм ответов, получающий атрибут или атрибуты

Более подробно, механизм ответов сначала получает атрибут или атрибуты из отформатированного запроса, анализируя запрос. Например, если предположить, что запрос отформатирован как пара <сущность/атрибут>, механизм ответов извлекает часть атрибута пары.

В некоторых случаях отформатированный запрос может включать несколько атрибутов. Например, отформатированный запрос может иметь вид <entity/attribute/attribute>. В таких случаях механизм ответов может извлечь каждый атрибут из запроса.

Затем механизм ответов обращается к шаблонам-кандидатам для каждого атрибута в запросе из базы данных шаблонов.

Каждый шаблон может соответствовать полному предложению или части предложения (например, фразе).

Каждый шаблон включает поля (показаны как части в квадратных скобках «< >»), в которые можно вставить фактическую информацию.

Например, шаблон может иметь вид «<дата>, <объект> вышла замуж за <значение>». Шаблоны могут быть созданы вручную или алгоритмически.

Шаблоны кандидатов на языке пользователя

Механизм ответов определяет язык пользователя и выбирает шаблоны-кандидаты на языке пользователя.

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

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

Как используется в этой спецификации, обозначение «<X/Y >» указывает на поле, имеющее ограничение «X» и ограничение «Y».

Ограничения выборки могут включать ограничения типа, временные ограничения, гендерные ограничения, ограничения отношений, ограничения единственного/множественного числа, ограничения единиц измерения и детерминантные ограничения.

Различные Constratinis могут требовать различных видов данных

Для ограничения типа может потребоваться определенный тип данных, например, для ограничения <date> может потребоваться дата, для ограничения <entity> может потребоваться имя объекта или другой идентификатор, а ограничение может потребовать число.

Временное ограничение может требовать, например, чтобы дата или время были в прошлом или в будущем, например, поле, содержащее <дата/прошлое>, может требовать, чтобы поле включало дату, которая находится в прошлом. Половое ограничение может требовать, например, мужского или женского пола.

Ограничение отношения может потребовать, например, тип отношения к другому объекту, например, поле, содержащее <сущность/супруга>, может потребовать, чтобы поле включало объект, который является супругом другого объекта. Ограничение единственного/множественного числа может потребовать, например, чтобы данные в поле были в единственном или множественном числе.

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

Каждый атрибут в запросе может функционировать как ключ для доступа к набору шаблонов-кандидатов. Например, атрибут «возраст» может привести к извлечению шаблонов. Примеры шаблонов включают первый шаблон « родился <дата/прошлое&glt; и в настоящее время ему <value> лет», для чего требуется имя объекта для <entity&lgt; поле, дата в прошлом для поле и число (например, возраст) для поля <значение<.

Второй шаблон, «<entity> в настоящее время <value< лет», требует имени объекта для поля <entity> и числа (например, возраста) для поля <value>.

Третий шаблон, «<entity> родился <date/pas> и умер <date/past>», требует имени объекта для поля </entity><entity> и двух прошлых дат для <date/ прошлое > поля.

Несколько шаблонов для заданных атрибутов

Преимущественно наличие нескольких шаблонов для данного атрибута позволяет реализациям поддерживать частичные факты. Например, для возрастных шаблонов, если известен год рождения, но неизвестна конкретная дата, подходящим шаблоном может быть «</entity><entity> родился в <год/прошлое>». Предоставление нескольких шаблонов для данного атрибута также позволяет изменять времена для разных частей фактов (например, «Вуди Аллен женится» и «Вуди Аллен женится»).

После получения шаблонов-кандидатов механизм ответов выбирает шаблон из шаблонов-кандидатов на основе различных эвристик. Например, механизм ответов может проверять согласование пола и правильное время. Кроме того, механизм ответов может определить, что количество ответов на исходный запрос соответствует количеству полей выбранного шаблона.

Механизм ответов также может определить, удовлетворяются ли ограничения и поля выбранного шаблона. Механизм ответов может выбрать шаблон, имеющий максимальное количество полей с ограничениями, которые удовлетворяются фактической информацией (например, шаблон с наибольшим объемом данных). Фактическая информация такова: «<Вуди Аллен/родился/дек. 1, 1935>».

В этом примере первый шаблон-кандидат: «<сущность> родилась <дата/прошлое> и в настоящее время лет." Этот шаблон имеет поле, поле <дата/прошедшее> и поле <значение>. Фактическая информация предоставляет объект, который удовлетворяет ограничению поля <entity>, и дату в прошлом, которая удовлетворяет ограничения поля.

Механизм ответов может получать значения на основе фактической информации. Таким образом, механизм ответов может вычислить значение возраста, чтобы удовлетворить ограничение поля <значение< на основе даты рождения. Поскольку фактическая информация удовлетворяет всем ограничениям для полей в первом шаблоне, механизм ответов выбирает первый шаблон.

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

После выбора шаблона механизм ответов генерирует предложение или фразу на основе шаблона. Например, механизм ответов может заменить поля в шаблоне соответствующими данными из фактической информации. Механизм ответов генерирует предложение «Вуди Аллен родился 1 декабря 1935 года, и в настоящее время ему 77 лет», используя выбранный шаблон.

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

Система, генерирующая предложения в ответ на фактические запросы

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

Клиентское устройство инициирует запрос, содержащий термины запроса.

Например, пользователь может ввести запрос «На ком был женат Вуди Аллен» в веб-браузере на клиентском устройстве.

Поисковая система получает запрос (например, «На ком был женат Вуди Аллен») от клиентского устройства.

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

В этом примере форматированный запрос включает идентификатор объекта (например, Вуди Аллен), тип объекта (например, лицо) и атрибут (например, браки).

Информация о типе может использоваться для создания меташаблона, как описано ниже. Затем поисковая система отправляет отформатированный запрос в индексный кластер.

Кластер индекса обращается к индексу для получения набора фактической информации в ответ на запрос

Кластер индекса обращается к индексу, чтобы получить набор фактической информации в ответ на запрос. Эти результаты включают как минимум две тройки (например, и <луиза Лассер/жена/1966/1970>).

Затем индексный кластер передает отформатированный запрос (например, <вуди Аллен/возраст> и фактическую информацию, отвечающую на запрос (например, <Сун-Йи Превин/жена/1997> и <луиза Лассер/жена/1966/1970>). ) в механизм ответов.

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

Сначала механизм ответов получает информацию о типе из отформатированного запроса (например, человек).

Информация о типе идентифицирует тип объекта, на основе которого выполняется запрос. Используя информацию о типе, механизм ответов получает доступ к меташаблонам-кандидатам, которые связаны с типом сущности «человек».

Как упоминается в этой спецификации, меташаблоны — это шаблоны, поля которых сконфигурированы так, чтобы содержать другие шаблоны.

Каждый из меташаблонов-кандидатов включает в себя поле для имени или идентификатора объекта и по меньшей мере одно поле для добавления других шаблонов.

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

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

Эти шаблоны фраз предназначены для включения в меташаблоны.

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

Например, атрибут «браки» может привести к извлечению шаблонов фраз.

Примеры шаблонов фраз включают первый шаблон «женился на <сущность/супруга> с <дата/прошлое>», для которого требуется сущность, вступающая в брак с сущностью в отформатированном запросе для поле и дату в прошлом для поле.

Второй шаблон «выходит замуж за <сущность/супруга>» требует, чтобы сущность вступала в брак с сущностью в отформатированном запросе для поле.

Третий шаблон «замужем» не требует дополнительной информации.

Четвертый шаблон «был женат на <сущность/супруга> с <дата/прошлое> по <дата/прошлое>» требует, чтобы сущность вступала в брак с сущностью в отформатированном запросе для поле и две даты в прошлом для полей <дата/прошлое>. Пятый шаблон «был женат на <сущность/супруга>» требует, чтобы сущность вступала в брак с сущностью в отформатированном запросе для поля <сущность/супруга>. А шестой шаблон «был женат» не требует дополнительной информации.

Затем механизм ответов выбирает один из возможных меташаблонов на основе типа информации, включенной в фактическую информацию. В частности, механизм ответов выбирает меташаблон-кандидат на основе количества троек, включенных в фактическую информацию. В фактическую информацию включаются две тройки. Поэтому механизм ответов выбирает меташаблон «человек», содержащий поля для двух шаблонов, то есть «<entity><template> и </template><template>».

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

Первая тройка, включенная в фактическую информацию, — это <Сун-Йи Превин/жена/1997>». В этом примере первый шаблон фразы-кандидата — «был женат на поскольку ». Этот шаблон имеет тег <ntity/spouse&g; поле и поле <дата/прошедшее>.

Первая тройка содержит сущность с отношением супруга к сущности в отформатированном запросе, которая удовлетворяет ограничению поля <entity/spouse>, и дату в прошлом, которая удовлетворяет ограничениям поля <date/past>. Поскольку первая тройка удовлетворяет всем ограничениям для полей в первом шаблоне, механизм ответов выбирает первый шаблон для первой тройки.

Вторая тройка, включенная в фактическую информацию, — это <луиза Лассер/жена/1966/1970>». Четвертый шаблон фразы-кандидата — «был женат на <сущность/супруга> с <дата/прошлое> по <дата/прошлое>», который содержит поле <сущность/супруга> и два поля <дата/прошлое>. Вторая тройка в фактической информации предоставляет объект с отношением супруга к объекту в форматированном запросе, который удовлетворяет ограничению поля <entity/spouse>, и две даты в прошлом, которые удовлетворяют ограничения поля.

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

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

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

Механизм ответов может заменить поля в первом выбранном шаблоне фразы (т. е. «вышел замуж за <субъект/супруга> с <<дата/прошлое>») информацией из первой тройки, чтобы сгенерировать фразу «вышла замуж». на Сун-Йи Превин с 1997 года». Таким образом, машина ответов генерирует предложение «Вуди Аллен женился на Сун-Йи Превен с 1997 года и ранее был женат на Луизе Лассер с 1966 по 1970 год». Затем машина ответов передает ответ на клиентское устройство, которое включает сгенерированное предложение. Ответ может быть включен на страницу результатов поиска, которая включает предложение и другие результаты поиска. Страница результатов поиска также содержит окно поиска, показывающее исходный поисковый запрос (например, «Кто был Вуди Аллен женат на"). Затем клиентское устройство может отобразить страницу результатов поиска. В качестве альтернативы предложение может быть передано в виде транскрипции, которая позволяет клиентскому устройству генерировать речь, или в виде аудиосигнала, кодирующего предложение для рендеринг на клиентском устройстве.

Система, генерирующая предложения в ответ на фактические запросы

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

Клиентское устройство инициирует запрос, содержащий два термина запроса («Где находится родной город и альма-матер Вуди Аллена») в веб-браузере на клиентском устройстве.

Поисковая система получает запрос (например, «Где находится родной город и альма-матер Вуди Аллена») от клиентского устройства. Затем поисковая система анализирует и форматирует исходный запрос в формат <сущность/тип/атрибут> (например, >Вуди Аллен/человек/родной город/колледж<), используя, например, подходящий механизм анализа естественного языка.

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

Затем, используя отформатированный запрос и фактическую информацию, механизм ответов генерирует ответ в виде предложения или предложений следующим образом. First, the answer engine obtains the type information from the formatted query (eg, person).

Using the type information, the answer engine accesses candidate meta-templates that are associated with a “person” type of entity.

As referred to in this specification, meta-templates are templates that have fields configured to contain other templates.

The answer engine also obtains the attributes from the formatted query and uses the attributes to access candidate phrase templates from template databases.

These phrase templates get designed to get incorporated into the meta-templates.

As described above, each attribute in the query may function as a key for accessing a set of candidate phrase templates. For example, the attribute “hometown” may result in the retrieval of the phrase templates. The sample phrase templates include a first template “currently lives in >location<,” which requires a geographic location for the поле.

The second template, “has lived in </location><location> since <date/past>,” requires a geographic location for the </location<>location> field and a date in the past for the <date/past> field. The third template, “used to live in </location><location>,” requires a geographic location for the location field.

Next, the answer engine selects one of the candidate meta-templates based on the type of information included in the factual information. In particular, the answer engine selects a candidate meta-template based on the number of triples included in the factual information. Two triples get included in the factual information.

For each triple included in the factual information, the answer engine also selects a template from the candidate phrase templates The answer engine may select the phrase template having the maximum number of fields with constraints that get satisfied by the factual information (eg, the most data-rich template). The answer engine also may perform other heuristics, such as analyzing gender agreement and correct tense of the candidate templates.

The first triple included in the factual information is <woody Allen/hometown/NYC>.” In this example, the first candidate template in the hometown templates is “currently lives in <location>.” The first triple has a location (ie, NYC) that satisfies the </location><location> field constraint. Since the first triple satisfies all of the constraints for the fields in the first template, the answer engine selects the first template from the hometown templates for the first triple.

The second triple included in the factual information is <woody Allen/college/NYU>.” The first candidate template in the college templates is “his alma mater is </college><college>.” The second triple in the factual information provides a college name (ie, NYU) that satisfies the </college<>college> field constraint.

Also, the answer engine may determine that the gender of the entity (Woody Allen) agrees with the gender of the phrase in this template. The answer engine selects the first template from the college templates for the second triple.

The answer engine selects the first template with fields that can get filled by the factual information, and does not perform any additional processing. Alternatively, the answer engine may process each template in the candidate templates and select the template having the largest quantity of fields that can get filled by the factual information.

After selecting the templates, the answer engine then generates a sentence based on the templates. For example, the answer engine may replace the fields in the selected templates with the appropriate data from the factual information. The answer engine may replace the fields in the first selected phrase template (ie, “currently lives in <location>”) with the information from the first triple to generate the phrase “currently lives in New York City.”

The answer engine then replaces the template fields in the selected meta-template (ie, “<entity><template> and &kt;/template><template>”) with the phrases generated from the first and second phrase templates. Thus, the answer engine generates the sentence “Woody Allen currently lives in New York City and his alma mater is New York University.”

The answer engine then transmits an answer to the client device that includes the generated sentence.

The answer may get included in a search results page that includes the sentence and other search results. The search results page also includes a search box showing the original search query (ie, “Where is Woody Allen's hometown and alma mater”). The search results page may then get rendered by the client device.

As getting provided in search results, the sentence could alternatively get transmitted as a transcription that allows the client device to generate speech, or as an audio signal encoding the sentence for rendering at the client device.

An Example Data Graph

The example data graph includes nodes (eg, entities) and edges connecting the nodes (eg, relationships or attributes). Naturally, the example data graph shows only a partial graph–a full graph with a large number of entities and even a limited number of relationships may have billions of triples.

An indexing system may traverse the data graph to obtain factual information as various triples. One example of a triple that may get obtained is the entity “Woody Allen” as the subject (or entity), the relationship “was born” as the predicate (or attribute), and the entity “Dec. 1, 1935” as the object (or value).

Another example of a triple that may be obtained is the entity “Woody Allen” as the subject, the relationship “has type” as the predicate, and the entity “person” as the value. This triple may get used, for example, by the answer engine as described above to select candidate meta-templates.

Another example of a triple that may get obtained is the entity “Woody Allen” as the subject, the relationship “was married to” as the predicate, and the entity “Louise Lasser” as the value.

Note that to obtain this triple, the indexing system must traverse two edges in the data graph, ie, from the “Woody Allen” entity to the “Woody Allen marriages” entity, and then from the “Woody Allen marriages” entity to the “Louise Lasser” entity.

Generating Sentences In Response To Factual Queries

A server (eg, an answer engine) receives an original query that identifies the attributes of an entity. For example, the server may receive a query that identifies multiple attributes of an entity (eg, age, date of birth, place of birth, marriages, etc.).

The server accesses a set of candidate templates for answering the query based on the attributes of the entity. Each candidate template includes fields, wherein each field gets associated with at least one constraint. When multiple attributes get identified in the original query, the server accesses a set of candidate templates for each attribute of the entity. The constraints may include of a type constraint, a temporal constraint, a gender constraint, a relationship constraint, a singular/plural constraint, a unit of measure constraint, and a determinant constraint.

The server then obtains a set of information that answers the query, for example by accessing a graph-based datastore as described above. The set of information that answers the query may be, for example, a set of entity-attribute-value triples. When multiple attributes get identified in the original query, the server obtains a set of information for each attribute (ie, to answer each portion of the original query).

Multiple sets of information (eg, multiple triples) may be responsive to a single attribute. For example, if the attribute is “marriages” or “children,” then multiple triples may get obtained in response to the attribute.

the server selects a template from the set of candidate templates, where the selected template has a maximum number of fields with constraints that may get satisfied by the set of information that answers the query. When multiple attributes get identified in the original query, the server selects a template for each attribute from the appropriate set of candidate templates.

Also, when multiple sets of information get obtained in response to a single attribute, the server may select multiple templates from the same set of candidate templates.

The server then generates a phrase. The phrase may get generated by adding the set of information that answers the query to the fields of the selected template so that the phrase answers the original query. The phrase may get sentenced. Alternatively or in addition, the phrase may be portions of a sentence. When multiple attributes get identified in the original query, the server generates a phrase for each attribute. The server may then combine the phrases to generate a complete sentence.

The server may obtain a sentence template (eg, a meta-template) based on the type of the entity (eg, person or location). The sentence template may include multiple fields for inserting phrases. For example, the server may access a set of candidate meta-templates based on the type of entity, and then select a meta-template from the set based on the number of triples that answer the original query.

The server may then add the generated phrases described with reference to step to the fields of the sentence template to form a sentence.
The server communicates the phrase or sentence to a client device. The client device may then output the phrase to a display or as speech audio. The server transmits an audio signal corresponding to the phrase or sentence to the client device.