Partager via

Ajout de fournisseurs de contexte

La page précédente a montré comment le middleware encapsule le pipeline d’exécution de l’agent avec des préoccupations transversales (journalisation, garde-fous, gestion des erreurs) sans toucher à la logique principale de l’agent. Mais l’intergiciel traite de la façon dont l’agent fonctionne, et non de ce que l’agent sait. Jusqu’à présent, les connaissances de l’agent proviennent de deux sources : ses données d’apprentissage et ce que l’utilisateur dit au cours de l'interaction actuelle.

C’est un problème. Un agent utile a besoin de plus que cela. Il doit rappeler ce que l’utilisateur a dit il y a trois tours, connaître les préférences de l’utilisateur ou extraire les faits pertinents d’une base de connaissances , tous avant de commencer à générer une réponse. Les outils peuvent récupérer des informations, mais elles sont réactives : le modèle doit décider de les appeler. Si le modèle ne se rend pas compte qu’il a besoin d’un contexte, il ne le demande pas.

Les fournisseurs de contexte résolvent ce problème. Ce sont des composants qui s’exécutent avant et après chaque appel d’agent, injectant de manière proactive des informations pertinentes dans la fenêtre de contexte et éventuellement en extrayant l’état de la réponse à stocker pour une utilisation ultérieure. Ils donnent à votre agent la mémoire, la personnalisation et l’accès aux connaissances externes, sans modifier les instructions ou le code de l’agent.

Cas d’utilisation :

Ajoutez des fournisseurs de contexte à votre agent quand :

  • L’agent a besoin de l’historique des conversations : il doit se rappeler ce qui a été dit au cours des tours précédents, pas seulement le message actuel.
  • Vous souhaitez injecter des données spécifiques à l’utilisateur ( profils, préférences, détails du compte ou état de session) afin que l’agent puisse personnaliser ses réponses.
  • Vous avez besoin d’une génération augmentée par récupération (RAG) : extraction automatique de documents ou de faits pertinents à partir d’une base de connaissances avant chaque réponse.
  • L’agent nécessite des instructions dynamiques : contexte qui change entre les appels en fonction de l’heure de la journée, de l’emplacement de l’utilisateur ou d’autres conditions d’exécution.
  • Vous souhaitez dissocier l’approvisionnement des données à partir de la logique de l’agent : l’agent n’a pas besoin de savoir où provient le contexte, uniquement s’il est disponible.

Pourquoi ne pas simplement utiliser des outils ?

Les outils et les fournisseurs de contexte donnent tous deux aux agents l’accès aux informations externes, mais ils fonctionnent de manière fondamentalement différente :

Aspect Outils Fournisseurs de contexte
Déclencheur Réactif : le modèle décide quand appeler un outil Proactive : s’exécute automatiquement avant chaque appel
Contrôle Piloté par le modèle : le modèle choisit l’outil, quand et avec quels arguments Piloté par les développeurs : vous décidez du contexte toujours disponible
Visibilité Le modèle doit savoir qu’il existe un outil et juger qu’il est pertinent Le contexte est injecté de manière transparente : le modèle le voit comme faisant partie de l'invite
Cas d'utilisation Actions et recherches à la demande : « rechercher sur le web », « interroger la base de données » Contexte toujours présent : historique des conversations, profils utilisateur, connaissances préchargées
Coût du jeton Jetons dépensés uniquement lorsque l’outil est appelé Jetons dépensés sur chaque appel (le contexte est toujours dans l’invite)

Ni l’un ni l’autre n’est strictement meilleur. De nombreux agents utilisent les deux : fournisseurs de contexte pour les informations qui doivent toujours être présentes (historique, profil utilisateur, connaissances de base) et outils pour les informations que l’agent doit extraire à la demande (résultats de recherche en direct, requêtes de base de données, appels d’API).

Conseil / Astuce

Une bonne règle de pouce : si l’agent doit avoir ces informations chaque fois qu’il s’exécute, utilisez un fournisseur de contexte. Si l’agent doit l’extraire uniquement en cas de pertinence, utilisez un outil.

Fonctionnement des fournisseurs de contexte

Les fournisseurs de contexte participent à un cycle de vie en deux phases autour de chaque appel d’agent :

┌──────────────────────────────────────────────────────────────┐
│  Caller: agent.run("What's the return policy?")              │
└──────────────┬───────────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────────┐
│  BEFORE RUN — each context provider injects context          │
│                                                              │
│  • History provider loads past conversation messages         │
│  • Memory provider retrieves relevant facts/preferences      │
│  • RAG provider searches knowledge base and adds results     │
│  • Custom provider injects user profile, time, location      │
└──────────────┬───────────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────────┐
│  Agent core — model sees original input + all injected       │
│  context and generates a response                            │
└──────────────┬───────────────────────────────────────────────┘
               ▼
┌──────────────────────────────────────────────────────────────┐
│  AFTER RUN — each context provider processes the response    │
│                                                              │
│  • History provider saves the new messages                   │
│  • Memory provider extracts facts to remember for later      │
│  • Custom provider updates session state                     │
└──────────────────────────────────────────────────────────────┘

Points clés :

  1. Les fournisseurs de contexte s’exécutent automatiquement. Vous les inscrivez une fois lors de la création de l’agent. Après cela, ils participent à chaque appel sans code supplémentaire de votre part.
  2. Plusieurs fournisseurs collaborent ensemble. Vous pouvez inscrire plusieurs fournisseurs de contexte ( un fournisseur d’historique, un fournisseur RAG et un fournisseur personnalisé) et tous contribuent à la même fenêtre de contexte. Leurs contributions sont fusionnées dans l’ordre d’inscription.
  3. Les fournisseurs ont deux crochets. Le before hook injecte le contexte (messages, instructions, outils) dans l’invite. Le crochet après traite la réponse : stockage de messages, extraction de mémoires ou mise à jour de l'état.
  4. Les fournisseurs sont sensibles aux sessions. Les fournisseurs de contexte reçoivent la session active afin qu’ils puissent charger et stocker des données délimitées à une conversation spécifique. Consultez sessions pour savoir comment fonctionne la gestion des sessions.

Conseil / Astuce

Pour obtenir une vue détaillée de l’emplacement où les fournisseurs de contexte se trouvent dans le pipeline d’exécution de l’agent complet, ainsi que l’intergiciel et le client de conversation, consultez l’architecture du pipeline de l’agent.

Gestion de la fenêtre de contexte

Chaque élément de contexte que vous injectez consomme des jetons à partir de la fenêtre de contexte du modèle. L'histoire se développe à chaque étape. Les résultats RAG ajoutent des blocs de document. Les profils utilisateur ajoutent des métadonnées. Si le total dépasse la limite du modèle, les informations les plus anciennes ou les moins pertinentes sont tronquées, ce qui peut perdre un contexte important.

La gestion du contexte est un facteur crucial lors de l’utilisation de fournisseurs de contexte : les stratégies de compactage résument ou suppriment l’historique plus ancien pour respecter les limites des jetons tout en préservant les informations clés. Voir Compaction.

Conseil / Astuce

Pour une expérience pratique avec les fournisseurs de mémoire et de contexte, consultez l’étape 4 : Mémoire dans le didacticiel Prise en main.

Important

Il n’est pas recommandé de conserver une fenêtre de contexte très longue, car les performances du modèle peuvent se dégrader à mesure que la fenêtre de contexte augmente. Si l’agent commence à subir des performances détériorées, envisagez d’utiliser des stratégies de compactage pour réduire la taille du contexte.

Considérations

Point à considérer Détails
Budget de jetons Chaque contexte injecté consomme des jetons. Surveillez attentivement la taille totale du contexte, en particulier lors de la combinaison de plusieurs fournisseurs. Si le contexte augmente sans limite, les informations importantes sont tronquées silencieusement.
Latence de récupération Les fournisseurs de contexte qui interrogent des services externes (bases de données, index de recherche, API) ajoutent une latence à chaque appel. Utilisez la mise en cache, le regroupement de connexions et les opérations asynchrones pour accélérer la récupération.
Relevance L’injection d’un contexte non pertinent ne gaspille pas seulement les jetons ; elle peut dégrader activement les réponses du modèle en diluant le signal. Assurez-vous que vos fournisseurs injectent des informations ciblées et pertinentes.
Périssabilité Le contexte mis en cache ou préchargé peut devenir obsolète. Concevez des mécanismes pour actualiser les données à des intervalles appropriés et déterminez si un contexte légèrement obsolète est acceptable pour votre cas d’usage.
Composabilité Lorsque plusieurs fournisseurs contribuent à la même fenêtre de contexte, leurs contributions peuvent interagir de manière inattendue. Testez les fournisseurs ensemble, et pas seulement individuellement, pour vous assurer que le contexte combiné a du sens.

Étapes suivantes

Maintenant que votre agent dispose d’outils, de compétences, d’intergiciels et de fournisseurs de contexte, l’étape suivante est des agents en tant qu’outils : composer des agents à l’aide d’un agent comme outil pour un autre, permettant la spécialisation et la délégation.

Agents en tant qu’outils

Aller plus loin :

  • Last updated on