Comprendre les champs de contexte
Que sont les champs de contexte ?
Dans REDA AI, les champs de contexte permettent de configurer le chargement automatique de certains champs d’un enregistrement Salesforce dans le contexte de l’IA lorsque l’utilisateur consulte une page d’enregistrement. Au lieu d’appeler un outil de requête pour récupérer les données, l’IA dispose immédiatement de ces données préchargées.
Les champs de contexte remplissent deux fonctions :
- Connaissance du contexte : l’IA sait quel enregistrement l’utilisateur consulte.
- Efficacité : l’IA dispose des données sans appeler d’outil, ce qui réduit la consommation de jetons et le coût.
Par exemple, si un utilisateur ouvre une opportunité et que votre agent dispose de champs de contexte pour « Amount », « StageName » et « CloseDate », ces trois champs sont automatiquement accessibles à l’IA. Elle peut immédiatement discuter de l’opportunité sans devoir l’interroger au préalable.
Pourquoi utiliser les champs de contexte
Sans champs de contexte, lorsqu’un utilisateur demande « Quelle est la prochaine étape pour cette affaire ? », l’IA doit :
- Appeler soql_query ou get_record pour récupérer les données de l’opportunité.
- Attendre le résultat, ce qui ajoute de la latence.
- Formuler ensuite une réponse.
- Coût : des jetons supplémentaires pour l’appel d’outil et son résultat.
Avec les champs de contexte :
- Les données de l’opportunité sont préchargées dans le contexte de l’IA.
- L’IA accède immédiatement aux données, sans appel d’outil.
- Réponse immédiate, sans latence liée à la requête.
- Coût : aucun jeton supplémentaire pour récupérer les données, puisqu’elles sont déjà dans le contexte.
Structure des champs de contexte
Les champs de contexte sont stockés sous forme d’enregistrements de configuration dans REDA AI. Chaque configuration précise :
| Propriété | Description |
|---|---|
| Définition d'agent | L’agent auquel s’applique cette configuration. Laissez ce champ vide pour la rendre universelle : elle s’applique alors à tous les agents pour cet objet. |
| Nom de l'API de l'objet | L’objet Salesforce couvert par la configuration, par exemple Opportunity, Account ou Case. |
| Noms des API de champ | La liste des noms API des champs à charger, par exemple StageName, Amount, CloseDate. Un seul enregistrement de configuration contient toute la liste : vous ne créez pas un enregistrement par champ. |
| Champs max. | Le nombre maximal de champs que cette configuration peut fournir. Valeur par défaut : 10. |
| Inclure les noms apparentés | Lorsque cette option est activée, ce qui est le cas par défaut, les champs de relation fournissent le nom de l’enregistrement associé en complément de son identifiant. L’agent lit ainsi « Acme Properties » au lieu d’une clé de 18 caractères. |
| Description du contexte | Un texte libre facultatif qui explique à l’agent ce que représente le contexte de cet enregistrement et comment l’utiliser. |
| Type d'enregistrement Nom du développeur | Permet de limiter la configuration à un seul type d’enregistrement. Une configuration propre à un type d’enregistrement est prioritaire sur une configuration générale pour le même agent. |
| Ordre de tri | L’ordre d’application des configurations. Les valeurs les plus basses passent en premier ; la valeur par défaut est 100. |
| Est actif | Seules les configurations actives sont chargées. Cette option est activée par défaut. |
Trois règles que les libellés des champs ne précisent pas.
- Champs max. est ramené à une valeur comprise entre 1 et 25 lors de l’exécution. La valeur par défaut est 10. Si vous saisissez 40, l’agent reçoit tout de même 25 champs ; si vous saisissez 0, il en reçoit 1. La valeur n’est pas rejetée à l’enregistrement : une configuration demandant 40 champs semble donc fonctionner tout en n’en fournissant que 25.
- Ordre de tri est le dernier critère de départage, pas la première règle. Une configuration propre à l’agent est prioritaire sur une configuration universelle ; une configuration limitée à un type d’enregistrement est prioritaire sur une configuration sans restriction. Ces critères sont appliqués avant Ordre de tri, qui ne départage que les configurations encore à égalité. Une configuration universelle avec Ordre de tri à 1 reste moins prioritaire qu’une configuration propre à l’agent avec Ordre de tri à 100.
- Type d'enregistrement Nom du développeur attend le DeveloperName, pas le libellé. Si un type d’enregistrement s’affiche sous le nom « Commercial Lease » dans Configuration, la valeur attendue ici est probablement
Commercial_Lease. Un libellé saisi par erreur ne correspond jamais et empêche silencieusement l’activation de la configuration.
Au maximum, 50 configurations sont prises en compte pour un objet au cours d’un même tour. Ce plafond dépasse largement les besoins d’une configuration raisonnable, mais il existe.
Où les champs de contexte sont-ils utilisés ?
Les champs de contexte sont chargés uniquement sur les pages d’enregistrement. Plus précisément :
- Page d’une opportunité : les champs de contexte de l’objet Opportunity sont chargés.
- Page d’un compte : les champs de contexte de l’objet Account sont chargés.
- Page d’une requête : les champs de contexte de l’objet Case sont chargés.
Les champs de contexte ne sont PAS chargés sur :
- Les pages d’accueil
- Les vues de liste
- Les pages de rapport
- Les déploiements du widget externe
Ce comportement est volontaire : les champs de contexte ajoutent les données propres à un enregistrement lorsque l’utilisateur se concentre sur celui-ci.
Hiérarchie des priorités
Les champs de contexte suivent une hiérarchie qui détermine les champs à charger :
- Agent + type d’enregistrement : champs liés à l’agent concerné ET à un type d’enregistrement précis, avec la priorité la plus élevée.
- Agent + tout type d’enregistrement : champs liés à l’agent, sans restriction de type d’enregistrement.
- Universel + type d’enregistrement : champs universels, sans agent associé, limités à un type d’enregistrement précis.
- Universel + tout type d’enregistrement : champs universels sans restriction, avec la priorité la plus basse.
Si un champ de contexte est défini à plusieurs niveaux, la définition ayant la priorité la plus élevée est utilisée. Les champs universels s’appliquent ainsi à tous les agents, sauf lorsqu’une définition propre à un agent les remplace.
La sécurité au niveau des champs s’applique
REDA AI respecte la sécurité au niveau des champs de Salesforce, ou FLS. Un champ inaccessible n’est pas transmis dans le contexte. En mode strict, un champ configuré supprimé, renommé ou inaccessible interrompt l’exécution. Avec Autoriser le contexte d'enregistrement d activé, l’agent peut poursuivre avec un contexte partiel et un avertissement ; si tous les champs configurés sont inaccessibles, il s’arrête même en mode dégradé. Cela garantit que :
- Les champs sensibles ne sont pas exposés aux utilisateurs sans autorisation.
- Les données de contexte peuvent différer selon les autorisations FLS de chaque utilisateur.
- L’IA ne contourne pas ces restrictions de sécurité.
Par exemple, si votre agent possède un champ de contexte « Salary » pour les contacts, mais que le profil de l’utilisateur ne permet pas de lire ce champ, les données salariales ne sont pas présentes dans le contexte de l’IA pour cet utilisateur.
Coût en jetons des champs de contexte
Plus le contexte contient de champs, plus chaque interaction consomme de jetons. Chaque champ inclus consomme des jetons et influe directement sur le coût en crédits. Par conséquent :
- Incluez uniquement les 5 à 10 champs les plus pertinents par objet.
- Utilisez l’optimiseur de champs de contexte pour obtenir des recommandations.
- Retirez les champs rarement consultés par l’agent.
- Trouvez un équilibre entre richesse du contexte et maîtrise des coûts.
En règle générale, chaque champ supplémentaire augmente proportionnellement le nombre de jetons de chaque interaction. Limiter la liste aux champs réellement utilisés par l’agent peut donc réduire sensiblement les coûts dans la durée.
Champs de contexte universels
Un champ de contexte dont Définition d'agent est vide est « universel » : il s’applique à TOUS les agents de l’organisation pour ce type d’objet. Cela permet de :
- Partager des standards : fournir les champs dont tous les agents ont besoin, par exemple « Name » et « CreatedDate ».
- Assurer la cohérence : donner à tous les agents un ensemble de champs de contexte de base.
- Simplifier la maintenance : modifier la configuration une seule fois au lieu de mettre à jour plusieurs copies propres à chaque agent.
Les champs propres à un agent peuvent remplacer les champs universels selon la hiérarchie des priorités.
Exemples courants de champs de contexte
- AccountId (relation vers le compte ; son nom est ajouté si Inclure les noms apparentés est activé)
- StageName (étape de l’opportunité)
- Amount (montant de l’affaire)
- CloseDate (date de clôture prévue)
- Probability (probabilité utilisée dans les prévisions)
- CaseNumber (numéro de référence)
- Status (ouvert/fermé)
- Priority (urgence)
- Description (résumé du problème)
- ContactId (contact du client ; son nom est ajouté si Inclure les noms apparentés est activé)
- Name
- Industry
- AnnualRevenue
- NumberOfEmployees
Configurer des instructions réutilisables
Les Prompts exclusifs affectent des instructions réutilisables aux agents choisis. Vérifiez Prompt exclusif et Résumé sur Prompt personnalisé, puis Définition d’agent, Prompt personnalisé, Actif et Mode de chargement sur l’affectation. À la demande nécessite l’outil de prompts de contexte dans l’agent. Les portées avec types d’enregistrement entre crochets partagent les mêmes règles, y compris dans les aperçus. L’ordre des prompts et outils est déterministe et l’aperçu peut utiliser un identifiant réel. Les instructions linguistiques suivent le message sur API/canaux externes ; les variables utilisateur ne s’appliquent que dans les contextes prévus. Préservez vos prompts personnalisés lors de la fusion des valeurs actuelles.
Questions fréquentes
Commencez par les 5 à 10 champs que votre agent consulte le plus souvent pendant les conversations. Utilisez l’optimiseur de champs de contexte pour obtenir des recommandations de l’IA à partir de l’objectif de votre agent et du schéma Salesforce.
La liste attend les noms API des champs directs de l’objet, pas des chemins de relation tels que Account.BillingAddress. Configurez le champ de relation direct, comme AccountId, et activez Inclure les noms apparentés pour ajouter le nom de la cible lorsque la relation n’a qu’un seul objet cible. Pour d’autres données de relation, utilisez un outil de requête ou Apex adapté, puis testez le résultat et son coût en jetons.
Les modifications prennent effet immédiatement. Lors du prochain chargement de l’agent sur une page d’enregistrement, le nouveau champ est inclus, sous réserve des autorisations FLS et des priorités.
Si un champ de contexte n’a pas de valeur pour un enregistrement, l’IA le voit comme vide ou non fourni. Elle peut gérer cette absence en posant des questions complémentaires ou en poursuivant sans cette information.
Prochaines étapes
Découvrez comment ajouter des champs de contexte à vos agents, ou utilisez l’optimiseur de champs de contexte pour obtenir des recommandations de l’IA.