Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
L’état au sein d’un assistant suit les mêmes paradigmes que les applications web modernes. Agents SDK fournit certaines abstractions pour faciliter la gestion de l’état.
Comme pour les applications web, un assistant est intrinsèquement sans état. Une autre instance de votre assistant peut gérer n'importe quel tour de conversation. Pour certains assistants, cette simplicité est préférable : l'assistant peut soit fonctionner sans informations supplémentaires, soit être assuré que les informations requises se trouvent dans le message entrant. Pour d'autres, l'état (tel que l'endroit où la conversation s'est arrêtée ou les données précédemment reçues sur l'utilisateur) est nécessaire pour que l'assistant puisse avoir une conversation utile.
Pourquoi ai-je besoin d'un état ?
La conservation de l'état permet à votre assistant d'avoir des conversations plus pertinentes en mémorisant certaines informations sur un utilisateur ou une conversation. Par exemple, si vous avez parlé à un utilisateur précédemment, vous pouvez enregistrer des informations précédentes à leur sujet, afin que vous n’ayez pas à le demander à nouveau. L’état conserve également les données plus longtemps que le tour actuel, afin que votre assistant conserve des informations au cours d’une invite multitour.
En ce qui concerne les assistants, l'utilisation de l'état comporte plusieurs niveaux : le niveau stockage, la gestion de l'état et AgentApplication.
Couche de stockage
En commençant par le backend, où les informations d'état sont réellement stockées, se trouve la couche de stockage. Vous pouvez considérer cela comme votre stockage physique, tel que dans la mémoire, Azure ou un serveur tiers.
Agents SDK inclut certaines implémentations pour la couche de stockage :
Le stockage de mémoire implémente le stockage en mémoire à des fins de test. Le stockage de données en mémoire est destiné aux tests locaux uniquement, car ce stockage est volatile et temporaire. Les données sont effacées chaque fois que l’assistant redémarre.
Stockage Blob Azure se connecte à une base de données d’objets Stockage Blob Azure.
Le stockage partitionné Azure Cosmos DB se connecte à une base de données NoSQL Cosmos DB partitionnée.
Pour obtenir des instructions sur la façon de se connecter à d’autres options de stockage, consultez Vue d’ensemble du stockage Agents SDK
Gestion de l'état
La gestion de l’état automatise la lecture et l’écriture de l’état de votre assistant dans la couche de stockage sous-jacente. L'état est stocké sous forme de propriétés d'état, qui sont en fait des paires clé-valeur que votre assistant peut lire et écrire via l'objet de gestion d'état sans se soucier de l'implémentation sous-jacente spécifique. Ces propriétés d’état définissent la façon dont ces informations sont stockées. Par exemple, lorsque vous récupérez une propriété que vous avez définie comme une classe ou un objet spécifique, vous savez comment ces données seront structurées.
Ces propriétés d’état sont regroupées en « compartiments » délimités, qui sont simplement des collections pour faciliter l’organisation de ces propriétés. Le Kit de développement logiciel (SDK) comprend trois de ces « compartiments » :
- État de l’utilisateur
- État de la conversation
Tous ces compartiments sont des sous-classes de la classe d'état de l'assistant, qui peut être dérivée pour définir d'autres types de compartiments avec des portées différentes.
Ces compartiments prédéfinis sont limités à une certaine visibilité, en fonction du compartiment :
- L'état de l'utilisateur est disponible à chaque tour où l'assistant converse avec cet utilisateur sur ce canal, quelle que soit la conversation
- L’état de la conversation est disponible à tout tour dans une conversation spécifique, quel que soit l’utilisateur, par exemple dans les conversations de groupe
L'état de l'utilisateur et l'état de la conversation sont définis par canal. Une même personne utilisant différents canaux pour accéder à votre assistant apparaît comme plusieurs utilisateurs distincts, un pour chaque canal, chacun avec un statut utilisateur distinct.
Les clés utilisées pour chacun de ces compartiments prédéfinis sont spécifiques à l’utilisateur et à la conversation, ou assistant. Lorsque vous définissez la valeur de votre propriété d’état, la clé est définie pour vous en interne, avec des informations contenues dans le contexte de tour pour vous assurer que chaque utilisateur ou conversation est placé dans le compartiment et la propriété appropriés. Plus précisément, les clés sont définies comme suit :
- L’état utilisateur crée une clé à l’aide de l’ID de canal et de l’ID. Par exemple,
{Activity.ChannelId}/users/{Activity.From.Id}#YourPropertyName - L’état de la conversation crée une clé à l’aide de l’ID de canal et de l’ID de conversation. Par exemple,
{Activity.ChannelId}/conversations/{Activity.Conversation.Id}#YourPropertyName
Quand utiliser chaque type d’état
L’état de la conversation est adapté au suivi du contexte de la conversation, par exemple :
- Si l'assistant a posé une question à l'utilisateur, et quelle était cette question
- Quel est le sujet actuel de la conversation, ou ce que le dernier était
- Enregistrement de l’historique des conversations
L’état de l’utilisateur est approprié pour le suivi des informations sur l’utilisateur, telles que :
- Informations utilisateur non critiques, telles que le nom et les préférences, un paramètre d’alarme ou une préférence d’alerte
- Informations sur la dernière conversation qu'il a eue avec l'assistant
- Par exemple, un assistant du service d'assistance produit peut suivre les produits sur lesquels l'utilisateur a posé des questions.
AgentApplication
- Les gestionnaires de routage que vous ajoutez sont fournis avec une instance
TurnState. Accéder à l’état d’une conversation ou d’un utilisateur à partir de cette instance. - L’état est automatiquement chargé et enregistré.