Mise en correspondance de références abstraites ou indéfinies avec des entités lorsqu'une entrée plus spécifique est souhaitée.

Question

Nous avons une application dans laquelle nous allons collecter les adresses des utilisateurs. Dans la mise en œuvre actuelle, nous utilisons un agent en direct pour ce faire. Certains utilisateurs, lorsqu'ils sont invités à indiquer une adresse de facturation définitive, disent des choses comme "Utilisez simplement mon adresse de facturation" ou "la même que mon adresse actuelle". La nouvelle mise en œuvre consistera en un chatbot qui tentera de répondre à certaines de ces demandes avant qu'elles ne parviennent à un agent.

Nous disposons de ces informations via la consultation de l'API. Je me demande plutôt, du point de vue de la conception, comment faire savoir à notre application de gestion (généralement un lambda AWS) que nous devons effectuer la consultation avant de demander la confirmation de l'exécution.

J'ai pensé à quelques trucs :

1. Entraînez le NLP à détecter les chaînes "adresse actuelle" et "adresse de facturation" en tant qu'entités d'adresse.
2. Créez une nouvelle intention pour les énoncés de ce type et traitez-les séparément.
3. Créer un nouveau type d'entité dans l'intention actuelle (par exemple, pas postalAddress) pour les énoncés de ce type et les traiter comme faisant partie du même accomplissement.
4. Il suffit de relancer l'utilisateur ou de lui demander de préciser son adresse.

Je cherche simplement l'approche la plus pragmatique, car ce problème est différent de la plupart des autres que nous avons résolus.

Answer 1

J'ai eu un cas d'utilisation similaire, et après enquête, j'ai trouvé que l'option 3 est la manière la plus simple de gérer cela.

Vous pouvez ajouter un validation hook qui se déclenche lorsque la nouvelle slot est remplie. Ce crochet peut remplir la valeur de l'élément postalAddress slot avec l'adresse associée. De cette façon, vous pouvez conserver le postalAddress comme un créneau obligatoire, sans que l'utilisateur ait à indiquer manuellement l'adresse.

Vous pouvez aussi avoir ceci validation hook sur la population de postalAddress et ajouter quelques tests manuels pour facturation y actuel mais j'ai l'impression qu'il s'agit d'une solution manuelle pour quelque chose qui devrait être automatisé par Lex.