Gestion de l'état pour les agents de données

Lorsque vous créez une application avec l'API Conversational Analytics, la gestion des états est un élément architectural clé. Vous gérez l'état de la conversation de l'API et, pour les applications qui utilisent l'Agent Development Kit (ADK), l'état de la session du framework.

Modes d'état de l'API

La méthode chat de l'API Conversational Analytics est compatible avec des paramètres de contexte mutuellement exclusifs qui déterminent la façon dont les états de conversation sont gérés.

Le tableau suivant compare ces modes :

Mode État Historique de la conversation Agent Paramètre Description
Discuter avec une référence à une conversation Avec état Géré par l'API Oui ConversationReference Poursuit une conversation avec état en faisant référence à une conversation existante et à l'agent associé. Google Cloud stocke et gère l'historique de la conversation. Vous n'envoyez que le nouveau message pour chaque tour.
Discuter avec une référence à un agent de données Sans état Géré par votre application Oui DataAgentContext Envoie un message sans état qui se réfère à un agent de données enregistré pour le contexte. Votre application doit gérer et fournir l'intégralité de l'historique de la conversation à chaque requête.
Discuter avec un contexte intégré Sans état Géré par votre application Non InlineContext Envoie un message sans état qui fournit tout le contexte directement dans la requête. Ce mode n'utilise pas d'agent de données enregistré. Votre application doit gérer et fournir l'intégralité de l'historique de la conversation.

État de la session ADK

Si vous utilisez le framework ADK pour l'orchestration, il fournit une couche de gestion des états qui fonctionne indépendamment de l'état de l'API Conversational Analytics. Il est essentiel de comprendre les deux couches pour créer des systèmes multi-agents qui fonctionnent correctement.

L'ADK utilise des conventions de préfixe de clé pour contrôler le champ d'application et la durée de vie des variables d'état. Le tableau suivant permet d'évaluer ces champs d'application :

Préfixe de clé Champ d'application Durée de vie Visible par Exemples
(aucun préfixe) Session Session actuelle uniquement Tous les agents de la session Sujet de la conversation actuelle ou résultats de la dernière requête
user: Utilisateur Dans toutes les sessions du même utilisateur Tous les agents et toutes les sessions de l'utilisateur spécifié Préférences de l'utilisateur, ID d'agent de données enregistrés ou paramètres de langue
app: Application Dans toutes les sessions de tous les utilisateurs Tous les agents et tous les utilisateurs Configuration globale de l'application, ID d'agent de données partagés ou flags de fonctionnalité
temp: Appel Appel actuel uniquement L'agent actuel dans l'appel actif Données de réponse intermédiaires, telles que des blocs de streaming ou des calculs en cours

Pour en savoir plus sur le partage d'état dans les systèmes multi-agents, consultez la documentation de l'ADK.

Interaction entre l'état de l'API et l'état de l'ADK

Lorsque vous utilisez l'API Conversational Analytics avec le framework ADK, les couches d'état fonctionnent indépendamment :

  • État de l'API : si votre application utilise des références à des conversations (mode avec état), l'API gère l'historique des conversations. Si votre application utilise un contexte d'agent de données ou un contexte intégré (modes sans état), l'API reste sans état pour chaque appel.
  • État de la session ADK : le framework ADK gère sa propre session, ses propres événements et ses propres variables d'état, quel que soit le mode utilisé par l'API Conversational Analytics.

Par exemple, lorsque vous utilisez les outils ask_data_insights ou ask_data_agent dans l'ADK, chaque appel est indépendant et sans état au niveau de l'API, même si l'ADK conserve le contexte plus large de la session. La démonstration de streaming de l'ADK illustre le modèle recommandé pour cette interaction : un sous-agent de données écrit les données de réponse analysées dans l'état temp:, que les agents en aval lisent ensuite dans le même appel.

Étape suivante