Génération de réponses aux requêtes
Publié: 2022-05-05Ce brevet récemment accordé à Google concerne généralement la génération de réponses aux requêtes, et ce brevet introduit également le concept de contraintes pour aider à répondre aux requêtes.
Utilisation de contraintes pour les réponses aux requêtes
Ce brevet pose des questions sur le contenu lié à des faits sur des entités sur lesquelles des questions sont ajoutées.
Les documents sur l'utilisation des contraintes pour la réponse aux requêtes sont les suivants :
- GRIP : explication basée sur les contraintes des réponses manquantes pour les requêtes de graphe
Réponse aux questions en utilisant la satisfaction des contraintes : QA-by-Dossier-with-Constraints
Fait intéressant, le premier document fait référence au Google Knowlege Vault comme référence. Probablement parce qu'il se concentre sur l'obtention de réponses correctes aux questions en utilisant des contraintes.
Puisque ce brevet se concentre tellement sur le référencement sémantique. Cela m'a rappelé d'autres brevets de Google sur ce sujet, y compris ces deux-là, qui valent la peine d'être lus attentivement :
- Réconciliation Google Knowledge Graph
- Extractions d'entités pour les graphes de connaissances chez Google
Le brevet fournit des informations sur le fonctionnement des entités et des attributs d'entité, sur la manière dont les tuples sont utilisés dans la recherche de graphes et sur le référencement sémantique.
Génération de réponses aux requêtes en fournissant des faits à partir d'une base de données
Les systèmes de recherche peuvent générer des réponses à des requêtes factuelles en fournissant des faits à partir d'une base de données.
Ces faits peuvent être stockés dans un graphique qui peut être mis à jour en temps réel.
Ces réponses peuvent être formatées sous forme de listes de résultats de recherche plutôt que de phrases.
Lorsqu'un utilisateur pose une question factuelle, par exemple, via la voix à un système de dialogue, il peut être souhaitable d'avoir une réponse naturelle à la question.
La réponse la plus naturelle peut être une réponse formulée comme une déclaration grammaticale des faits qui répondent à la question de l'utilisateur pour fournir des réponses à la requête.
Ainsi, selon un aspect général de l'objet décrit dans ce brevet, en réponse à une requête factuelle, des faits stockés dans une base de données sont convertis en une phrase dans la langue de l'utilisateur.
Réception des réponses aux requêtes identifiant les attributs d'une entité
Un aspect du sujet décrit dans cette spécification peut être incorporé dans des procédés qui incluent les actions de réception d'une requête identifiant les attributs d'une entité. Ces attributs sont les faits concernant l'entité.
Les actions incluent ensuite l'accès aux modèles candidats pour les réponses aux requêtes basées sur les attributs de l'entité. Chaque modèle de candidat comporte des champs ; dans lequel chaque zone est associée à au moins une contrainte.
Ensuite, les actions comprennent l'obtention d'un ensemble d'informations qui fournissent des réponses aux requêtes et la sélection d'un modèle à partir de la collection de modèles candidats. Le modèle choisi a le nombre le plus important de champs avec des contraintes qui satisfont l'ensemble d'informations.
Triples sémantiques liés aux entités
L'ensemble d'informations peut être un ensemble de triplets entité-attribut-valeur.
Les actions comprennent en outre la génération d'une phrase en ajoutant l'ensemble d'informations aux champs du modèle sélectionné, de sorte que les mots comprennent des réponses à des requêtes.
La phrase est une phrase ou une partie de phrase. Enfin, les actions comprennent la communication des mots à un dispositif client.
La phrase peut être communiquée sous la forme d'un signal audio correspondant aux mots.
Les contraintes peuvent inclure :
- Contrainte de type
- Contrainte temporelle
- Contrainte de genre
- Contrainte de relation
- Contrainte singulier/pluriel
- Contrainte d'unité de mesure
- Contrainte déterminante.
Certaines implémentations impliquent l'obtention de nombreux ensembles d'informations en réponse à un seul attribut dans la requête.
Les actions comprennent en outre :
- Obtention d'un modèle de phrase sur la base d'un type d'entité, le modèle de phrase comprenant une pluralité de champs pour des phrases
- Ajouter les phrases aux champs du modèle de phrase pour former la phrase
- Sélection, pour chaque ensemble d'informations, d'un modèle parmi l'ensemble des modèles candidats
- Génération, pour chaque modèle sélectionné, d'une phrase en ajoutant l'ensemble d'informations respectif aux champs du modèle sélectionné respectif
- Communiquer la phrase, y compris les phrases, à un dispositif client
Cela peut impliquer des réponses aux requêtes qui incluent de nombreux attributs.
- Réception des réponses aux requêtes identifiant de nombreux attributs d'une entité
- Accéder, pour chaque attribut de l'entité, à un ensemble de modèles candidats pour les réponses aux requêtes en fonction de l'attribut respectif de l'entité
- Obtenir, pour chaque attribut de l'entité, un ensemble d'informations qui répondent à une partie respective de la requête
- Sélection d'un modèle dans l'ensemble respectif de modèles candidats
- Générer, pour chaque attribut de l'entité, une phrase en ajoutant l'ensemble d'informations respectif aux champs du modèle sélectionné
- Obtention d'un modèle de phrase sur la base d'un type d'entité, le modèle de phrase comprenant une pluralité de champs pour des phrases
- Ajouter les phrases aux champs du modèle de phrase pour former une phrase
- Communiquer une phrase comprenant les phrases à un dispositif client
Les avantages de ce processus peuvent inclure :
Le système est configurable et extensible aux affirmations et réponses factuelles complexes.
Cela peut permettre une séparation nette de la base de données réelle du mécanisme de génération de phrases.
Il peut permettre l'ajout de nouveaux modèles via toute méthode appropriée.
Ce brevet de génération de réponses aux requêtes est à
Génération des réponses aux requêtes
Inventeurs : Engin Cinar Sahin, Vinicius J. Fortuna et Emma S. Persky
Cessionnaire : Google LLC
Brevet américain : 11 321 331
Attribué : 3 mai 2022
Date de dépôt : 23 juillet 2018
Abstrait
Un serveur reçoit des réponses à des requêtes identifiant les attributs d'une entité.
Le serveur accède à un ensemble de modèles candidats pour répondre à la requête sur la base des attributs de l'entité, chaque modèle candidat ayant des champs, chaque champ étant associé à au moins une contrainte.
Le serveur obtient un ensemble d'informations et de réponses à des requêtes et sélectionne un modèle parmi l'ensemble de modèles candidats.
Le modèle sélectionné contient le plus grand nombre de champs avec des contraintes satisfaites par l'ensemble d'informations.
Le serveur génère une phrase en ajoutant l'ensemble d'informations aux champs du modèle sélectionné, de telle sorte que la phrase comprenne une réponse à la requête.
Enfin, le serveur communique la phrase à un dispositif client.
Conversion des faits d'une base de données en phrases
Lorsqu'un utilisateur pose une question factuelle, un moteur de recherche peut fournir des réponses à la requête en accédant à une base de données.
Certains systèmes, tels que les systèmes de dialogue basés sur la voix, permettent aux utilisateurs de planifier des requêtes sous forme de questions en langage naturel (par exemple, « Qui est le président du Japon ? »).
Dans de tels cas, il peut être souhaitable de fournir une réponse en langage naturel sous la forme d'une phrase plutôt qu'une réponse formatée comme des résultats de recherche faisant référence à des documents.
Ainsi, les systèmes décrits dans cette spécification peuvent convertir des faits d'une base de données en phrases. Cela peut être avantageux, par exemple, pour que la réponse puisse être rendue à l'utilisateur sous forme de parole.
Pour produire des phrases qui répondent aux questions des utilisateurs, il peut être souhaitable de récupérer des faits aléatoires dans une base de données. Les faits ne sont cependant pas aléatoires - ils utilisent les informations sur les contraintes pour fournir des réponses aux requêtes. Cela semblerait signifier de meilleures réponses aux requêtes sur les entités.
Pour répondre à une question telle que la personne avec qui quelqu'un s'est marié, un système peut obtenir des données comprenant tous les mariages passés, les personnes impliquées dans les mariages passés, les dates des unions et les types d'accords matrimoniaux. Une base de données flexible qui représente des faits à l'aide d'une structure graphique peut fournir ces faits.
Accéder aux modèles de candidats pour générer des réponses aux requêtes en fonction de l'attribut ou des attributs
Une fois que les faits ont été collectés, un moteur de réponse peut accéder à des modèles candidats pour générer une réponse basée sur l'attribut ou les attributs fournis dans la requête. Par exemple, si la question initiale est "Avec qui Woody Allen était-il marié", le point peut être "mariages". Si la requête réelle est "Quel âge a Woody Allen", l'attribut peut être "âge". Comme décrit ci-dessous, chaque point d'une question peut correspondre à plusieurs modèles de candidats, par exemple, pour prendre en charge des réponses plus ou moins détaillées.
Par exemple, si l'attribut est "age", le moteur de réponse peut obtenir un modèle qui inclut la date de naissance et l'âge (par exemple, {<entity> est né le <date> et a actuellement <value> ans}), un modèle qui inclut uniquement l'âge (par exemple, {<entity> a actuellement <value> ans}) et un modèle qui inclut la date de naissance et la date de décès (par exemple, {<entity> est né le <date> et est décédé le < /date>}).
Comme décrit plus en détail ci-dessous, les parties des modèles entourées de "< >" (c'est-à-dire les champs) peuvent être associées à diverses contraintes sur les données qu'elles peuvent contenir.
Une fois que le moteur de réponse a obtenu les modèles candidats, il sélectionne le modèle le plus pertinent en fonction de plusieurs heuristiques et génère une phrase en insérant les faits dans le modèle. Le moteur de réponse peut alors fournir une réponse dans une correction à l'utilisateur.
Un système de recherche de graphes de données
Le système peut s'habituer à implémenter un moteur de recherche pour un graphe de données en utilisant les techniques décrites ici.
Un système est décrit comme un système de moteur de recherche pour un graphique de données qui traite les demandes de requête d'un client. D'autres configurations et applications de la technologie associée peuvent être utilisées. Par exemple, la demande de requête peut provenir d'un autre serveur, d'un travail par lots ou d'un terminal utilisateur en communication avec un système de recherche de graphe de données.
Le système de recherche de graphe de données peut comprendre un système d'indexation, un système de recherche et un groupe d'index. Le système d'indexation, le système de recherche et la grappe d'index peuvent être des dispositifs informatiques qui prennent la forme de plusieurs dispositifs différents, par exemple, un serveur standard, un groupe de tels serveurs ou un système de serveur en rack.
De plus, les systèmes d'indexation, les systèmes de recherche et les grappes d'index peuvent être mis en œuvre dans un ordinateur personnel, par exemple un ordinateur portable.
Le système de recherche de graphe de données peut comprendre un magasin de données basé sur un graphe. Un tel graphe de données stocke les nœuds et les arêtes, à partir desquels un graphe peut être créé.
Les nœuds peuvent être appelés entités et les arêtes peuvent être appelées relations entre deux entités. De telles relations peuvent être stockées de plusieurs manières.
Le magasin de données basé sur des graphes stocke des tuples triples représentant des entités et des relations dans un exemple.
Triple tuples représentant des entités et des relations
Un triplet peut également inclure un
Un exemple de triplet est l'entité Woody Allen en tant que sujet (ou entité), la relation agissant en tant que prédicat (ou attribut) et l'entité Annie Hall en tant qu'objet (ou valeur).
Bien sûr, un graphe de données avec de nombreuses entités et même un nombre limité de relations peut avoir des milliards de triplets.
Les systèmes d'indexation peuvent comprendre des processeurs configurés pour exécuter des instructions exécutables par machine ou des morceaux de logiciel, de micrologiciel ou une combinaison de ceux-ci.
Trouver des réponses aux requêtes
Le système de recherche peut comprendre des serveurs (non représentés) qui reçoivent des requêtes d'un utilisateur d'un client et fournissent ces requêtes au système de recherche.
Le système de recherche peut être chargé de rechercher le graphe de données et d'autres sources de données, telles qu'un corpus de documents provenant d'Internet ou d'un Intranet, en réponse à une requête.
Par exemple, le système de recherche peut recevoir une requête d'un client, tel qu'un client, effectuer un traitement de requête et envoyer la requête au cluster d'index et à d'autres clusters d'indexation qui stockent des index pour rechercher d'autres sources.
Le système de recherche peut avoir un module qui compile les résultats de toutes les sources et fournit les résultats compilés au client.
Le système de recherche peut uniquement envoyer des requêtes au cluster d'index et peut fournir des résultats de recherche du cluster d'index au client.
Le système de recherche peut être en communication avec les clients sur le réseau.
Un cluster d'index dans la recherche de réponses aux requêtes
Le système peut également comprendre un groupe d'index. Le cluster d'index peut être un dispositif informatique unique ou un système de base de données distribué avec des dispositifs informatiques, chacun avec son propre processeur et sa propre mémoire.
Le nombre de dispositifs informatiques qui composent le cluster d'index peut varier et, par souci de brièveté, le cluster d'index est affiché comme une seule entité.
Chaque grappe d'index peut comprendre des processeurs configurés pour exécuter des instructions exécutables par machine ou des morceaux de logiciel, de micrologiciel ou une combinaison de ceux-ci.
La grappe informatique peut comprendre un système d'exploitation (non représenté) et des mémoires d'ordinateur, par exemple la mémoire principale, configurées pour stocker des éléments de données, de manière temporaire, permanente, semi-permanente ou une combinaison de ceux-ci.
La mémoire peut comprendre n'importe quel type de dispositif de stockage qui stocke des informations dans un format qui peut être lu et exécuté par un processeur, y compris une mémoire volatile, une mémoire non volatile ou une combinaison de celles-ci.
Un résolveur de requête qui accède à l'index pour récupérer les résultats en réponse à la requête
Le cluster d'index peut également inclure des modules, tels qu'un résolveur de requêtes, qui accèdent à l'index pour récupérer des résultats en réponse à la requête.
Un résolveur de requête peut également faire partie du système de recherche ou peut être distribué entre le système de recherche et le cluster d'index.
Requêtes et réponses aux requêtes de plus en plus compliquées
Une requête simple qui implique un attribut ("âge") et aboutit à une seule triple réponse.
Un exemple d'une requête simple qui implique un attribut ("mariages") mais aboutit à plusieurs réponses triples.
Un exemple d'une requête compliquée qui implique deux attributs ("ville natale et alma mater") et aboutit à plusieurs réponses triples.
Un exemple de système qui génère des phrases en réponse à des requêtes factuelles.
Le système comprend un dispositif client, un système de recherche, un groupe d'index et un moteur de réponse.
Les entités peuvent être implémentées dans le cadre du système.
Un utilisateur lance une requête ayant des termes de requête à l'aide d'un dispositif client.
L'utilisateur peut formater la requête d'origine sous la forme d'une phrase.
Interagir avec un système de dialogue basé sur la voix
L'utilisateur peut interagir avec le dispositif client à l'aide d'un système de dialogue vocal.
Par exemple, l'utilisateur peut prononcer la requête "Quel âge a Woody Allen" dans un microphone du dispositif client.
Le dispositif client peut alors effectuer une reconnaissance vocale pour convertir l'énoncé en transcription, puis transmettre la transcription au moteur de recherche.
En variante, le dispositif client peut transmettre des données vocales audio codant l'énoncé.
Le système de recherche reçoit la requête (par exemple, "Quel âge a Woody Allen") du dispositif client.
Si la requête est codée sous forme de données vocales audio, le système de recherche peut convertir les données vocales audio en une transcription.
Le système de recherche analyse et formate ensuite la requête d'origine en une <entity ; attribut> (tel que <woody Allen/age<) en utilisant, par exemple, un moteur d'analyse de langage naturel approprié.
Le système de recherche envoie ensuite la requête formatée au cluster d'index.
Le cluster d'index accède à l'index pour récupérer les résultats en réponse à la requête.
Réponses aux requêtes sous forme de triplets
Ces résultats peuvent être un ensemble d'informations factuelles sous forme de triplets (par exemple, </woody><woody Allen/born on/Dec. 1,>
Le cluster d'index transmet ensuite la requête formatée (par exemple, </woody><woody Allen/age> et les informations factuelles qui répondent à la requête (par exemple, </woody><woody Allen/born on/Dec. 1, 1935>) au moteur de réponse.
A partir de la requête formatée et des informations factuelles, le moteur de réponse génère alors une réponse sous la forme d'une phrase ou de phrases.
Le moteur de réponse génère une réponse comme suit. Tout d'abord, le moteur de réponse obtient l'attribut ou les attributs à partir de la requête formatée.
Ensuite, le moteur de réponse utilise l'attribut ou les attributs pour accéder aux modèles de phrase ou d'expression candidats à partir de la base de données de modèles.
Ensuite, le moteur de réponse sélectionne l'un des modèles sur la base des informations factuelles et de diverses contraintes associées aux modèles candidats.
Enfin, le moteur de réponse remplit les champs du modèle sélectionné à l'aide des informations factuelles.
Un moteur de réponse obtenant un ou plusieurs attributs
Plus en détail, le moteur de réponse obtient d'abord l'attribut ou les attributs de la requête formatée en analysant la requête. Par exemple, en supposant que la requête a été formatée en tant que paire <entity/attribute>, le moteur de réponse extrait la partie attribut de la paire.
Dans certains cas, la requête formatée peut inclure plusieurs attributs. Par exemple, la requête formatée peut être sous la forme <entité/attribut/attribut>. Dans de tels cas, le moteur de réponse peut extraire chaque attribut de la requête.
Ensuite, le moteur de réponse accède aux modèles candidats pour chaque attribut de la requête à partir de la base de données de modèles.
Chaque modèle peut correspondre à une phrase complète ou à une partie d'une phrase (par exemple, une phrase).
Chaque modèle comprend des champs (affichés sous forme de parties entre crochets « < > ») qui peuvent contenir des informations factuelles insérées.
Par exemple, un modèle peut être "Le <date>, <entité> s'est mariée avec <valeur>". Les modèles peuvent être générés manuellement ou par algorithme.
Modèles de candidats dans la langue de l'utilisateur
Le moteur de réponse identifie la langue de l'utilisateur et sélectionne des modèles candidats dans la langue de l'utilisateur.
Par exemple, le moteur de réponse peut recevoir des données du moteur de recherche indiquant la langue de la requête d'origine. Avantageusement, une telle configuration peut faciliter l'internationalisation de la réponse.
Les champs peuvent être associés à des contraintes qui régissent les données que chaque champ peut contenir.
Telle qu'utilisée dans cette spécification, la notation « <X/Y > » indique un champ ayant une contrainte « X » et une contrainte « Y ».
Les contraintes d'échantillon peuvent inclure des contraintes de type, des contraintes temporelles, des contraintes de genre, des contraintes de relation, des contraintes de singulier/pluriel, des contraintes d'unités de mesure et des contraintes de déterminant.
Différentes contraintes peuvent nécessiter différents types de données
Une contrainte de type peut nécessiter un type spécifique de données, par exemple, une contrainte <date> peut nécessiter une date, une contrainte <entity> peut nécessiter un nom d'entité ou un autre identifiant, et un
Une contrainte temporelle peut exiger, par exemple, qu'une date ou une heure soit dans le passé ou dans le futur, par exemple, un champ contenant <date/past> peut exiger que le champ inclue une date qui est dans le passé. Une contrainte de genre peut nécessiter, par exemple, un sexe masculin ou féminin.
Une contrainte de relation peut exiger, par exemple, un type de relation avec une autre entité, par exemple, un champ contenant <entity/spouse> peut exiger que le champ inclue une entité qui est le conjoint d'une autre entité. Une contrainte singulier/pluriel peut exiger, par exemple, que les données du champ soient au singulier ou au pluriel.
Une contrainte d'unité de mesure peut, par exemple, exiger que les données sur le terrain soient mesurées dans une unité de mesure spécifique (par exemple, pouces, pieds, centimètres, mètres, etc.). Une contrainte déterminante peut exiger, par exemple, que le mot "le" précède le champ.
Chaque attribut de la requête peut fonctionner comme une clé pour accéder à un ensemble de modèles candidats. Par exemple, l'attribut « âge » peut entraîner la récupération des modèles. Les exemples de modèles incluent un premier modèle "
Le deuxième modèle, « <entity> a actuellement <value< ans », nécessite un nom d'entité pour le champ <entity> et un nombre (par exemple, un âge) pour le champ <value>.
Le troisième modèle, "<entity> est né le <date/past> et est décédé le <date/past>", nécessite un nom d'entité pour le champ </entity><entity> et deux dates passées pour le <date/ passé> champs.
Plusieurs modèles pour des attributs donnés
Avantageusement, avoir plusieurs modèles pour un attribut donné permet aux implémentations de prendre en charge des faits partiels. Par exemple, pour les modèles d'âge, si l'année de naissance est connue mais que la date spécifique est inconnue, un modèle approprié peut être "</entity><entity> is born in <year/past>". Fournir plusieurs modèles pour un attribut donné permet également de changer les temps pour différentes parties de faits (par exemple, "Woody Allen se marie" et "Woody Allen s'est marié").
Après avoir obtenu les modèles candidats, le moteur de réponse sélectionne un modèle parmi les modèles candidats sur la base de diverses heuristiques. Par exemple, le moteur de réponse peut vérifier l'accord entre les sexes et le temps correct. De plus, le moteur de réponse peut déterminer que le nombre de réponses à la requête d'origine correspond au nombre de champs du modèle sélectionné.
Le moteur de réponse peut également déterminer si les contraintes et les champs du modèle sélectionné sont satisfaits. Le moteur de réponse peut sélectionner le modèle ayant le nombre maximum de champs avec des contraintes qui sont satisfaites par les informations factuelles (par exemple, le modèle le plus riche en données). L'information factuelle est "<woody Allen/né le/déc. 1, 1935>.”
Dans cet exemple, le premier modèle de candidat est "<entité> est né le <date/passé> et est actuellement
Le moteur de réponse peut dériver des valeurs basées sur des informations factuelles. Le moteur de réponse peut donc calculer une valeur d'âge pour satisfaire la contrainte de champ <valeur< basée sur la date de naissance. Étant donné que les informations factuelles satisfont à toutes les contraintes des champs du premier modèle, le moteur de réponse sélectionne le premier modèle.
Le moteur de réponse sélectionne le premier modèle avec des champs qui peuvent être remplis par les informations factuelles et n'effectue aucun traitement supplémentaire. Alternativement, le moteur de réponse peut traiter chaque modèle dans les modèles candidats et sélectionner le modèle ayant la plus grande quantité de champs pouvant être remplis par les informations factuelles.
Après avoir sélectionné le modèle, le moteur de réponse génère ensuite une phrase ou une expression basée sur le modèle. Par exemple, le moteur de réponse peut remplacer les champs du modèle par les données appropriées des informations factuelles. Le moteur de réponse génère la phrase "Woody Allen est né le 1er décembre 1935 et a actuellement 77 ans" en utilisant le modèle sélectionné.
Le moteur de réponse transmet ensuite une réponse au dispositif client, la réponse comprenant la phrase générée. La réponse peut être une transcription que le dispositif client convertit en parole et restitue à l'utilisateur.
Système qui génère des phrases en réponse à des requêtes factuelles
Le système comprend un dispositif client, un système de recherche, un groupe d'index et un moteur de réponse. Les entités illustrées peuvent, par exemple, être implémentées dans le cadre du système.
Un dispositif client lance une requête ayant des termes de requête.
Par exemple, un utilisateur peut saisir la requête "Avec qui Woody Allen était-il marié" dans un navigateur Web sur l'appareil client.
Le système de recherche reçoit la requête (par exemple, "Avec qui Woody Allen était-il marié") du dispositif client.
Le système de recherche analyse et formate ensuite la requête d'origine dans un
Dans cet exemple, la requête formatée comprend un identifiant de l'entité (par exemple, Woody Allen), un type d'entité (par exemple, une personne) et un attribut (par exemple, des mariages).
Les informations de type peuvent être utilisées pour générer un méta-modèle comme décrit ci-dessous. Le système de recherche envoie ensuite la requête formatée au cluster d'index.
Le cluster d'index accède à l'index pour récupérer un ensemble d'informations factuelles en réponse à la requête
Le cluster d'index accède à l'index pour récupérer un ensemble d'informations factuelles en réponse à la requête. Ces résultats incluent au moins deux triplets (par exemple,
Le cluster d'index transmet ensuite la requête formatée (par exemple, <woody Allen/age> et les informations factuelles qui répondent à la requête (par exemple, <Soon-Yi Previn/femme/1997>, et <louise Lasser/femme/1966/1970> ) au moteur de réponse.
A l'aide de la requête formatée et des informations factuelles, le moteur de réponse génère ensuite une réponse sous la forme d'une phrase ou de phrases comme suit.
Tout d'abord, le moteur de réponse obtient les informations de type à partir de la requête formatée (par exemple, personne).
Les informations de type identifient le type d'entité sur lequel la requête est basée. À l'aide des informations de type, le moteur de réponse accède aux méta-modèles candidats qui sont associés à un type d'entité « personne ».
Comme mentionné dans cette spécification, les méta-modèles sont des modèles qui ont des champs configurés pour contenir d'autres modèles.
Chacun des méta-modèles candidats comprend un champ pour un nom ou un identifiant d'une entité et au moins un champ pour ajouter d'autres modèles.
Ces modèles permettent au moteur de réponse de générer des phrases pour incorporer diverses phrases contenant des informations sur une personne.
Le moteur de réponse obtient également l'attribut ou les attributs à partir de la requête formatée et utilise l'attribut ou les attributs pour accéder aux modèles d'expression candidats à partir de la base de données de modèles.
Ces modèles de phrases sont conçus pour être incorporés dans les méta-modèles.
Comme décrit ci-dessus, chaque attribut dans la requête peut fonctionner comme une clé pour accéder à un ensemble de modèles de phrases candidats.
Par exemple, l'attribut « mariages » peut entraîner la récupération des modèles de phrases.
Les exemples de modèles d'expression incluent un premier modèle "s'est marié avec <entity/spouse> depuis le <date/past>", qui nécessite une entité qui se marie avec l'entité dans la requête formatée pour le
Le deuxième modèle, "se marie avec <entity/spouse>", nécessite une entité qui se marie avec l'entité dans la requête formatée pour le
Le troisième modèle, "est marié", ne nécessite aucune information supplémentaire.
Le quatrième modèle, « était marié à <entity/spouse > from <date/past > to <date/past > », nécessite une entité qui se marie avec l'entité dans la requête formatée pour le
Ensuite, le moteur de réponse sélectionne l'un des méta-modèles candidats sur la base du type d'informations incluses dans les informations factuelles. En particulier, le moteur de réponse sélectionne un méta-modèle candidat sur la base du nombre de triplets inclus dans les informations factuelles. Deux triplets sont inclus dans les informations factuelles. Le moteur de réponse sélectionne donc le méta-modèle "personne" ayant des champs pour deux modèles, c'est-à-dire "<entity><template> et </template><template>".
Pour chaque triplet inclus dans les informations factuelles, le moteur de réponse sélectionne également un modèle parmi les modèles d'expression candidats. Le moteur de réponse peut sélectionner le modèle de phrase ayant le nombre maximal de champs avec des contraintes qui sont satisfaites par les informations factuelles (par exemple, le modèle le plus riche en données).
Le premier triplet inclus dans les informations factuelles est <Soon-Yi Previn/femme/1997>. » Dans cet exemple, le premier modèle d'expression candidat est "a été marié à
Le premier triplet a une entité avec une relation de conjoint à l'entité dans la requête formatée qui satisfait la contrainte de champ <entity/spouse> et une date dans le passé qui satisfait les contraintes de champ <date/past>. Étant donné que le premier triplet satisfait toutes les contraintes des champs du premier modèle, le moteur de réponse sélectionne le premier modèle pour le premier triplet.
Le deuxième triple inclus dans les informations factuelles est <louise Lasser/épouse/1966/1970>. » Le quatrième modèle de phrase candidat est « était marié à <entity/spouse> from <date/past> to <date/past> », qui a un champ <entity/spouse> et deux champs <date/past>. Le deuxième triplet dans les informations factuelles fournit une entité avec une relation de conjoint à l'entité dans la requête formatée qui satisfait la contrainte de champ <entity/spouse>, et deux dates dans le passé qui satisfont la
Étant donné que le deuxième triplet satisfait toutes les contraintes des champs du quatrième modèle, le moteur de réponse sélectionne le quatrième modèle pour le deuxième triplet.
Le moteur de réponse sélectionne le premier modèle avec des champs qui peuvent être remplis par les informations factuelles et n'effectue aucun traitement supplémentaire. Alternativement, le moteur de réponse peut traiter chaque modèle dans les modèles candidats et sélectionner le modèle ayant la plus grande quantité de champs pouvant être remplis par les informations factuelles.
Après avoir sélectionné les modèles, le moteur de réponse génère ensuite une phrase basée sur les modèles. Par exemple, le moteur de réponse peut remplacer les champs des modèles sélectionnés par les données appropriées des informations factuelles.
Le moteur de réponse peut remplacer les champs du premier modèle de phrase sélectionné (c'est-à-dire « s'est marié avec <entité/conjoint> depuis <<date/passé> ») par les informations du premier triplet pour générer la phrase « s'est marié à Soon-Yi Previn depuis 1997." Ainsi, le moteur de réponse génère la phrase "Woody Allen s'est marié avec Soon-Yi Previn depuis 1997 et a été marié à Louise Lasser de 1966 à 1970." Le moteur de réponse transmet alors une réponse à l'appareil client qui inclut la phrase générée. La réponse peut être incluse dans une page de résultats de recherche qui inclut la phrase et d'autres résultats de recherche. La page de résultats de recherche comprend également une zone de recherche affichant la requête de recherche d'origine (par exemple, "Qui était Woody Allen marié à"). La page de résultats de recherche peut alors être restituée par l'appareil client. La phrase peut également être transmise sous forme de transcription permettant à l'appareil client de générer de la parole, ou sous forme de signal audio codant la phrase pour rendu sur le périphérique client.
Un système qui génère des phrases en réponse à des requêtes factuelles
Le système comprend un dispositif client, un système de recherche, un groupe d'index et un moteur de réponse.
Un dispositif client lance une requête ayant deux termes de requête ("Où est la ville natale et l'alma mater de Woody Allen") dans un navigateur Web au niveau du dispositif client.
Le système de recherche reçoit la requête (par exemple, "Où est la ville natale et l'alma mater de Woody Allen") du dispositif client. Le système de recherche analyse et formate ensuite la requête d'origine dans un format <entité/type/attribut> (par exemple, >woody Allen/personne/ville natale/université<) en utilisant, par exemple, un moteur d'analyse de langage naturel approprié.
Dans cet exemple, la requête formatée comprend un identifiant de l'entité (par exemple, Woody Allen), un type d'entité (par exemple, une personne) et deux attributs (par exemple, la ville natale et l'université). Le système de recherche envoie ensuite la requête formatée au cluster d'index.
A l'aide de la requête formatée et des informations factuelles, le moteur de réponse génère ensuite une réponse sous la forme d'une phrase ou de phrases comme suit. 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.