Contexte de session de l’agent de contrôle - Amazon Bedrock

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Contexte de session de l’agent de contrôle

Pour mieux contrôler le contexte de session, vous pouvez modifier l’objet SessionState dans votre agent. L’objet SessionState contient des informations qui peuvent être conservées à tour de rôle (demande et réponses InvokeAgent distinctes). Vous pouvez utiliser ces informations pour fournir un contexte conversationnel à l’agent lors des conversations avec les utilisateurs.

La forme générale de l’objet SessionState est la suivante.

{ "sessionAttributes": { "<attributeName1>": "<attributeValue1>", "<attributeName2>": "<attributeValue2>", ... }, "conversationHistory": { "messages": [{ "role": "user | assistant", "content": [{ "text": "string" }] }], }, "promptSessionAttributes": { "<attributeName3>": "<attributeValue3>", "<attributeName4>": "<attributeValue4>", ... }, "invocationId": "string", "returnControlInvocationResults": [ ApiResult or FunctionResult, ... ], "knowledgeBases": [ { "knowledgeBaseId": "string", "retrievalConfiguration": { "vectorSearchConfiguration": { "overrideSearchType": "HYBRID | SEMANTIC", "numberOfResults": int, "filter": RetrievalFilter object } } }, ... ] }

Sélectionnez une rubrique pour en savoir plus sur les champs de l’objet SessionState.

Attributs de session et de session d’invite

Amazon Bedrock Agents vous permet de définir les types d’attributs contextuels suivants qui persistent pendant certaines parties d’une session :

  • sessionAttributes : attributs qui persistent tout au long d’une session entre un utilisateur et un agent. Toutes les demandes InvokeAgent effectuées avec le même sessionId appartiennent à la même session, tant que la durée limite de session (idleSessionTTLinSeconds) n’a pas été dépassée.

  • conversationHistory : pour la collaboration multi-agent, accepte un contexte supplémentaire pour le traitement des demandes d’exécution si conversationalHistorySharing est activé pour un agent collaborateur. Par défaut, ce champ est automatiquement construit par l’agent superviseur lors de l’invocation de l’agent collaborateur. Vous pouvez éventuellement utiliser ce champ pour fournir un contexte supplémentaire. Pour plus d’informations, consultez Utilisation de la collaboration multi-agent avec les agents Amazon Bedrock .

  • promptSessionAttributes : attributs qui persistent pendant un seul tour (un appel InvokeAgent). Vous pouvez utiliser l’espace réservé $prompt_session_attributes$ lorsque vous modifiez le modèle d’invite de base d’orchestration. Cet espace réservé sera renseigné au moment de l’exécution avec les attributs que vous spécifiez dans le champ promptSessionAttributes.

Vous pouvez définir les attributs d’état de session en deux étapes différentes :

  • Lorsque vous configurez un groupe d’actions et que vous écrivez la fonction Lambda, incluez sessionAttributes ou promptSessionAttributes dans l’événement de réponse renvoyé à Amazon Bedrock.

  • Pendant l’exécution, lorsque vous envoyez une demande InvokeAgent, incluez un objet sessionState dans le corps de la demande pour modifier dynamiquement les attributs d’état de session au milieu de la conversation.

Définition d’un exemple d’attribut de session

L’exemple suivant utilise un attribut de session pour personnaliser un message destiné à votre utilisateur.

  1. Rédigez le code de votre application pour demander à l’utilisateur de fournir son prénom et la demande qu’il souhaite faire à l’agent et pour stocker les réponses sous forme de variables <first_name> et <request>.

  2. Rédigez le code de votre application pour envoyer une demande InvokeAgent avec le corps suivant :

    { "inputText": "<request>", "sessionState": { "sessionAttributes": { "firstName": "<first_name>" } } }
  3. Lorsqu’un utilisateur utilise votre application et fournit son prénom, votre code envoie le prénom en tant qu’attribut de session et l’agent enregistre son prénom pendant toute la durée de la session.

  4. Comme les attributs de session sont envoyés lors de l’événement d’entrée Lambda, vous pouvez faire référence à ces attributs de session dans une fonction Lambda pour un groupe d’actions. Par exemple, si le schéma d’API d’action nécessite un prénom dans le corps de la demande, vous pouvez utiliser l’attribut session firstName lors de l’écriture de la fonction Lambda pour un groupe d’actions afin de remplir automatiquement ce champ lors de l’envoi de la demande d’API.

Exemple de d’attribut de session d’invite

L’exemple général suivant utilise un attribut de session d’invite pour fournir un contexte temporel à l’agent.

  1. Écrivez le code de votre application pour stocker la demande de l’utilisateur dans une variable appelée <request>.

  2. Écrivez le code de votre application pour extraire le fuseau horaire de l’utilisateur si celui-ci utilise un mot indiquant l’heure relative (tel que « demain ») dans <request>, et stockez-le dans une variable appelée <timezone>.

  3. Rédigez votre candidature pour envoyer une demande InvokeAgent avec le corps suivant :

    { "inputText": "<request>", "sessionState": { "promptSessionAttributes": { "timeZone": "<timezone>" } } }
  4. Si un utilisateur utilise un mot indiquant le temps relatif, votre code enverra l’attribut de session d’invite timeZone et l’agent le stockera pendant toute la durée du tour.

  5. Par exemple, si un utilisateur demande I need to book a hotel for tomorrow, votre code envoie le fuseau horaire de l’utilisateur à l’agent et celui-ci peut déterminer la date exacte à laquelle « demain » fait référence.

  6. L’attribut de session d’invite peut être utilisé lors des étapes suivantes.

    • Si vous incluez l’espace réservé $prompt_session_attributes$ dans le modèle d’invite d’orchestration, l’invite d’orchestration envoyée au modèle de fondation inclut les attributs de session d’invite.

    • Les attributs de session d’invite sont envoyés dans l’événement d’entrée Lambda et peuvent être utilisés pour renseigner les demandes d’API ou renvoyés dans la réponse.

Résultats de l’invocation d’un groupe d’actions

Si vous avez configuré un groupe d’actions pour rétablir le contrôle dans une réponse InvokeAgent, vous pouvez envoyer les résultats de l’invocation du groupe d’actions dans la valeur sessionState d’une réponse InvokeAgent ultérieure en incluant les champs suivants :

  • invocationId : cet ID doit correspondre au invocationId renvoyé dans l’objet ReturnControlPayload dans le champ returnControl de la réponse InvokeAgent.

  • returnControlInvocationResults : inclut les résultats que vous obtenez en invoquant l’action. Vous pouvez configurer votre application pour qu’elle transmette l’objet ReturnControlPayload afin d’exécuter une demande d’API ou d’appeler une fonction que vous définissez. Vous pouvez ensuite fournir les résultats de cette action ici. Chaque membre de la liste returnControlInvocationResults est l’un des suivants :

    • Un objet ApiResult contenant l’opération d’API dont l’agent a prédit qu’elle devait être appelée dans une séquence InvokeAgent précédente et les résultats de l’invocation de l’action dans vos systèmes. Le format général est le suivant :

      { "actionGroup": "string", "agentId" : :string", "apiPath": "string", "confirmationState" : "CONFIRM | DENY", "httpMethod": "string", "httpStatusCode": integer, "responseBody": { "TEXT": { "body": "string" } } }
    • Un objet FunctionResult contenant la fonction dont l’agent a prédit qu’elle devait être appelée dans une séquence InvokeAgent précédente et les résultats de l’invocation de l’action dans vos systèmes. Le format général est le suivant :

      { "actionGroup": "string", "agentId" : :string", "confirmationState" : "CONFIRM | DENY", "function": "string", "responseBody": { "TEXT": { "body": "string" } } }

Les résultats fournis peuvent être utilisés comme contexte pour une orchestration ultérieure, envoyés au post-traitement pour que l’agent formate une réponse, ou utilisés directement dans la réponse de l’agent à l’utilisateur.

Configurations d’extraction de la base de connaissances

Pour modifier la configuration d’extraction des bases de connaissances associées à votre agent, incluez le champ knowledgeBaseConfigurations avec une liste de configurations pour chaque base de connaissances dont vous souhaitez spécifier les configurations. Spécifiez knowledgeBaseId. Dans le champ vectorSearchConfiguration, vous pouvez spécifier les configurations de requête suivantes (pour plus d’informations sur ces configurations, consultez Configuration et personnalisation de la génération de requêtes et de réponses) :

  • Type de recherche : indique si la base de connaissances recherche uniquement les vectorisations (SEMANTIC) ou à la fois les vectorisations et le texte brut (HYBRID). Utilisez le champ overrideSearchType.

  • Nombre maximum de résultats extraits : nombre maximal de résultats issus de l’extraction de la requête à utiliser dans la réponse.

  • Métadonnées et filtrage : filtres que vous pouvez configurer pour filtrer les résultats en fonction des attributs de métadonnées des fichiers de source de données.