Approche de Configuration des Tokens de Contexte LLM

Qu'est-ce que le Contexte ?

Le contexte d'un LLM (Large Language Model) fait généralement référence à l'ensemble des informations préalables que le modèle peut prendre en compte lors de la génération de texte. Pour un LLM, le contexte sert de "mémoire", lui permettant de décider de sa prochaine action en fonction du contenu déjà vu ou généré. Le contexte peut être une seule phrase, un paragraphe, un document, ou même un ensemble de plusieurs documents, selon l'architecture et la conception du modèle.

Le contexte est crucial pour les modèles de langage car il aide le modèle à comprendre la tâche en cours et à générer des réponses cohérentes et pertinentes sur la base des informations précédentes. Par exemple, dans une conversation, le contexte peut inclure tous les échanges jusqu'à ce point, permettant au modèle de générer des réponses alignées sur le thème et le ton de la conversation.

Cependant, en raison des limitations des ressources informatiques et de la mémoire, les modèles de langage disposent généralement d'une longueur de contexte fixe. La longueur de contexte des modèles courants aujourd'hui varie d'environ 128K à 1M de tokens. À mesure que les LLM évoluent, la prise en charge de contextes plus longs deviendra une tendance courante. Pourtant, du point de vue du coût des tokens, de la qualité des réponses LLM et du temps de réponse dans les scénarios commerciaux, une gestion du contexte plus précise et efficace est essentielle.

Un token peut être un mot, un signe de ponctuation ou toute autre unité linguistique.

Approche de Configuration du Contexte

Puisque nous savons que le contexte est la "quantité d'informations qu'un LLM peut traiter en une seule fois", la manière d'allouer les ressources dans cet espace d'information limité est un aspect critique de la conception d'un Agent. GPTBots définit le contexte LLM comme : Mémoire à long terme, Mémoire à court terme, Invites d'identité, Question Utilisateur, Données Outils et Données de Connaissance. Une seule interaction LLM peut inclure tous ces types de contexte, chacun avec des priorités différentes.

Remarque : Si la longueur totale de tous les types de contexte lors d'une seule interaction avec le LLM dépasse la limite du LLM, GPTBots tronquera les types de contexte de plus basse priorité afin d'assurer le taux de réussite des appels LLM.

Question Utilisateur

Le contenu d'entrée le plus récent de l'utilisateur lors d'une conversation avec l'Agent inclut divers types de messages envoyés via la boîte de saisie :

• Messages texte saisis manuellement
• Messages audio enregistrés via audio
• Messages image, Messages vidéo, Messages document, Messages audio et Messages fichier téléchargés en tant que pièces jointes.

Remarque :
Lorsque l'option "Agent-Configuration-Input-Attachment" est réglée sur Reconnaissance Système, GPTBots reconnaîtra toutes les pièces jointes téléchargées comme du contenu texte à traiter comme Question Utilisateur.
Pour les messages de type fichier, GPTBots convertira le fichier en lien URL à traiter comme Question Utilisateur.

Invites d'identité

Les informations d'identité définies pour le LLM dans l'Agent GPTBots servent de principe directeur important pour le travail de l'Agent IA. GPTBots adaptera automatiquement ceci en message système ou message développeur selon la version du modèle.

• Les invites d'identité sont cruciales dans les scénarios professionnels et doivent être rédigées de manière claire et complète pour guider le travail et les réponses de l'IA.
• En général, vous n'avez pas à vous soucier de la longueur des invites d'identité. Comparé à la longueur, la qualité des invites d'identité est plus importante et mérite d'y investir plus de tokens.
• Lors de la rédaction des invites d'identité, une expression claire, une logique correcte et des instructions précises sont essentielles. Une bonne invite d'identité doit clairement exprimer vos objectifs, principes, compétences et logique de travail tout en évitant les instructions ambiguës.

Mémoire à court terme

Les informations des X derniers tours de conversation entre l'utilisateur et l'Agent sont incluses à chaque requête LLM. Si la fonction de mémoire à court terme est désactivée ou si la conversation vient d'être créée, cette partie sera vide.

À la configuration, tenez compte des points suivants :

• Si le scénario métier de l'Agent ne nécessite pas de contexte ou si le contexte impacte négativement la qualité des réponses de l'IA, vous pouvez désactiver la mémoire à court terme pour économiser des tokens et améliorer les performances de l'Agent.
• Si l'Agent dépend fortement du contexte (par exemple, besoin du contexte pour répondre aux questions), vous devez définir le nombre de tours de mémoire aussi élevé que possible.

Données de Connaissance

En fonction de l'entrée utilisateur, l'Agent extrait des fragments de connaissance de la base de connaissances correspondante via une recherche vectorielle. Si l'Agent ne dispose pas de contenu dans la base de connaissances ou ne peut pas obtenir de résultats, cette partie sera vide.

À la configuration, tenez compte des points suivants :

• Si l'Agent n'implique pas de requêtes à la base de connaissances, vous pouvez désactiver la récupération de connaissances pour économiser des tokens.
• Si l'Agent dépend fortement des résultats de requête à la base de connaissances (par exemple, scénarios de questions-réponses sur documents), vous devez configurer le nombre maximal de rappels de connaissances, le score de pertinence et d'autres paramètres dans la "Base de Connaissances" pour garantir la quantité et la qualité du RAG (retrieved augmented generation).

Mémoire à long terme

En fonction de l'entrée utilisateur, les historiques de conversation récupérés de toutes les conversations de l'Agent via une recherche vectorielle seront inclus. Si la fonction de mémoire à long terme est désactivée ou si la conversation vient d'être créée, cette partie sera vide.

À la configuration, tenez compte des points suivants :

• Si le scénario métier de l'Agent dépend du contenu des conversations historiques (par exemple, personnages virtuels), vous devez activer la fonction de mémoire à long terme.
• Si le scénario de l'Agent n'implique pas l'utilisation de contenu de conversation historique, vous pouvez la désactiver pour économiser des tokens.

Données Outils

Lorsque le système soumet des données de requête au LLM, il inclut les données Outils sélectionnées par l'Agent pour aider le LLM à choisir correctement l'Outil à invoquer. Après une invocation réussie de l'Outil, les résultats retournés par le service API doivent être soumis à nouveau au LLM. Si l'Agent désactive la fonction Outils, cette section restera vide.
Lors de la configuration, il convient de considérer :

• Si le scénario de l'Agent n'implique pas l'utilisation d'Outils, vous pouvez omettre l'ajout d'Outils à l'Agent pour économiser des tokens.
• Lorsqu'un Outil contient plusieurs API, certaines API spécifiques inutiles peuvent être désactivées dans la configuration de l'Outil. Les API désactivées ne seront pas soumises au LLM, ce qui permet d'économiser des tokens.

Sortie LLM

La longueur des tokens des données de sortie du LLM est déterminée et réservée lors de la requête au LLM. GPTBots prend déjà en charge la personnalisation de la longueur des tokens de réponse LLM, et cette section n'est pas affectée par la section d'entrée ci-dessus.

Étude de Cas

Illustrons l'allocation des tokens de contexte avec un exemple concret. Supposons que nous utilisions un modèle LLM avec une limite de contexte de 8K tokens :

Scénario : Assistant Service Client

Un Agent assistant de service client en ligne doit :

• Se souvenir du contenu récent de la conversation utilisateur
• Interroger la base de connaissances produit
• Invoquer l'interface de consultation de commande
• Maintenir une image professionnelle de service client

Plan de Gestion des Tokens

Suggestions d'Optimisation

1. Ajustement Dynamique
   • Lorsque la requête utilisateur est courte, les tokens économisés peuvent être automatiquement alloués aux données de connaissance.
   • Lorsque les Outils ne sont pas utilisés, l'espace réservé peut être alloué automatiquement à la mémoire à court terme.
2. Exécution par Priorité
   • Lorsque le total des tokens dépasse la limite, troncature selon la priorité :
   • À conserver : Question Utilisateur, Mémoire à court terme, Invite d'identité, Données de Connaissance, Données Outils
   • À compresser/supprimer : Mémoire à long terme
3. Garantie d'Effet
   • Garantir l'intégralité des fonctions principales (par exemple, la consultation de commande) en cas d'insuffisance de tokens.
   • La mémoire à long terme peut être sacrifiée pour garantir la qualité des réponses.

Grâce à une telle planification, les fonctions principales de l'assistant service client peuvent être réalisées dans l'espace de tokens limité, tout en maintenant la cohérence de la conversation et le professionnalisme.