Configurer des agents REDA AI multilingues
Comment cela fonctionne-t-il ?
Chaque utilisateur possède une Langue sur sa fiche Salesforce, dans le champ API LanguageLocaleKey, avec des valeurs comme fr, de, es_MX, ja ou zh_CN. Sur les canaux où l’utilisateur est authentifié, cette valeur détermine la directive linguistique intégrée au prompt système.
-
Lire la langue de l’utilisateur
Sur les canaux Interne et Communauté, la langue provient de l’utilisateur Salesforce exécutant, sans réglage propre à chaque agent.
-
Vérifier le chargement sur la version installée
Le traitement des directives pour les utilisateurs anglophones dépend de la version installée. Ne supposez pas qu’un prompt sera toujours omis pour l’anglais : vérifiez les instructions effectivement assemblées.
-
Ajouter la directive
La plateforme charge la directive du canal, remplace les variables linguistiques applicables et l’intègre au prompt système assemblé.
-
Le modèle répond
L’agent lit la directive et répond dans la langue appropriée pendant la conversation.
Les deux variables linguistiques
Les prompts personnalisés peuvent référencer la langue de l’utilisateur exécutant avec deux variables :
| Variable | Valeur obtenue | Exemples |
|---|---|---|
{USER_LANGUAGE} |
Le code de langue Salesforce complet. | fr, de, es_MX, pt_BR, zh_CN |
{USER_LANGUAGE_CODE} |
La partie linguistique uniquement, avant le premier _. |
fr, de, es, pt, zh |
Ces variables peuvent être utilisées dans tous les prompts personnalisés, pas seulement la directive linguistique. Elles sont utiles pour des adaptations précises, comme une formule de signature différente pour le français canadien et le français de France. Vérifiez toujours le canal : la langue d’un compte de service ne représente pas celle d’un visiteur ou d’un destinataire externe.
Les directives linguistiques fournies
REDA AI fournit quatre courtes directives, une par canal, chargées lors de l’initialisation des données. Ce sont des enregistrements de prompts personnalisés ordinaires, modifiables comme les autres.
| Nom du prompt | Canal | Jetons estimés | Utilise {USER_LANGUAGE} ? |
|---|---|---|---|
_common:language-directive |
Interne | ~40 | Oui |
_common:language-directive-community |
Communauté | ~20 | Oui |
_common:language-directive-external |
Widget externe | ~70 | Non |
_common:language-directive-api |
API | ~70 | Non |
Les deux canaux sans utilisateur humain connecté possèdent des directives plus longues, sans variable linguistique. Sur Widget externe, l’exécution se fait sous un utilisateur invité Sites ; sur API, sous le compte d’intégration ou Automated Process. Utiliser {USER_LANGUAGE} risquerait d’imposer la langue du compte de service à tous les interlocuteurs. Ces directives demandent donc de répondre dans la langue du message reçu, d’ignorer celle du compte ou du site appelant, de se référer au message précédent si un salut est trop court pour identifier la langue, et de n’utiliser l’anglais qu’en l’absence de tout indice. Cela explique leur estimation d’environ 70 jetons au lieu de 20.
La directive Interne ajoute une exception pour l’interprétation des réponses : traduire le texte destiné à l’utilisateur tout en conservant les noms API, identifiants d’enregistrement et marqueurs structurels, notamment suggestions, alertes et liens internes. Les éléments que la plateforme utilise pour traiter la réponse restent ainsi intacts.
Les prompts initialisés sont des données, pas des métadonnées. Une mise à niveau du package ne les réécrit pas. Une organisation conserve donc l’ancienne formulation jusqu’à ce qu’un administrateur lance Données par défaut de la graine, le bouton de chargement des données par défaut, dans la console d’administration REDA AI. Si les agents Widget externe ou API répondent dans la mauvaise langue, vérifiez d’abord le texte de leur directive.
Vérifier le comportement selon la version
Certaines versions appliquaient une omission des directives pour les utilisateurs anglophones. Ce comportement peut évoluer ; vérifiez les points suivants dans votre organisation :
- Le prompt linguistique est-il actif et applicable au canal ?
- Son contenu apparaît-il dans les instructions assemblées pour l’utilisateur testé ?
- Les variables ont-elles une valeur attendue, ou sont-elles vides sur un canal sans personne authentifiée ?
Ne fondez ni le comportement ni une estimation de coût nul sur une règle universelle d’omission pour l’anglais. Utilisez une conversation de test sur votre version installée pour vérifier le prompt réellement envoyé.
Ce qui reste inchangé
La directive Interne indique explicitement de ne pas traduire certains éléments :
- Noms API — Les identifiants des champs, objets et outils restent inchangés pour correspondre au schéma Salesforce et aux définitions d’outils
- Identifiants d’enregistrement — Ils doivent rester strictement identiques
- Marqueurs structurels — Marqueurs de suggestions (
SUGGESTIONS:), balises d’alerte ([ALERT]), formes des liens internes ([[links]]) et autres éléments utilisés par l’interface pour afficher correctement la réponse
Les directives Communauté, Widget externe et API formulent plus simplement la règle : traduire le texte lisible par une personne, sans énumérer toutes ces exceptions, car ces canaux n’utilisent généralement pas les mêmes marqueurs d’interface.
Personnaliser les directives
Les directives fournies constituent un point de départ et peuvent être modifiées comme tout prompt personnalisé. Exemples :
- Ton selon la langue. Ajoutez des consignes stylistiques, comme le vouvoiement (vous en français, Sie en allemand) sur les canaux destinés aux clients.
- Termes à conserver. Précisez les marques, références produits ou expressions qui doivent rester inchangées, même dans les réponses aux clients.
- Formats locaux. Indiquez les formats de nombres, dates et devises attendus pour éviter de laisser le modèle les deviner.
Les modifications sont enregistrées dans les prompts personnalisés. Vérifiez leur application avec une nouvelle conversation pour chaque canal et langue concernés ; les règles de résolution et de chargement peuvent différer selon la version installée.
Aller au-delà de la directive
Vous pouvez adapter d’autres éléments à la langue :
- Prompts conditionnels. Ajoutez une consigne comme
Pour les utilisateurs parlant {USER_LANGUAGE_CODE}, faites X. Les variables peuvent être utilisées directement dans un prompt. - Suggestions traduites. Les boutons de suggestion prennent en charge les étiquettes personnalisées Salesforce, afin de localiser automatiquement l’écran initial de discussion.
- Valeurs de contexte localisées. Si l’agent lit des champs contenant des valeurs traduites, il reçoit ces données dans leur langue, sans configuration particulière.
Consultez Variables de contexte des prompts pour connaître tous les champs de fusion disponibles.
Canaux et langues
Chaque canal possède sa propre directive, car les besoins diffèrent :
- Interne — La langue Salesforce de l’utilisateur exécutant fait référence. Sa préférence est généralement stable et définie sur sa fiche.
- Communauté — Les utilisateurs du portail ont aussi une préférence linguistique ; le même mécanisme s’applique.
- Widget externe — Le visiteur utilise un site public. La directive fournie demande de suivre la langue de son message, puis celle de l’échange précédent si nécessaire, sans lui imposer la langue du compte invité.
- API — Le compte exécutant appartient au flux ou à l’intégration. La directive fournie suit la langue du message auquel l’agent répond, et non celle du compte technique. Pour un contexte linguistique particulier, explicitez-le dans les instructions de la conversation.
Bonnes pratiques
Évitez un personnage distinct pour chaque langue. Multiplier les versions augmente la maintenance. Rédigez une définition de rôle commune et laissez la directive adapter la langue à l’exécution.
Testez la conservation des identifiants. Si l’agent traduit des noms API ou altère les marqueurs structurels, ajustez l’exception de la directive Interne.
Utilisez les conditions linguistiques avec mesure. Une directive et les capacités multilingues du modèle suffisent dans la plupart des cas. Ajoutez des conditions par langue uniquement pour un besoin stylistique ou juridique précis.
Vérifiez la configuration et un échange réel. Consultez la directive active et l’aperçu pour le contexte prévu, puis testez des messages représentatifs. Le débogueur peut aider à analyser les traces, mais sa reconstruction de la configuration actuelle ne prouve pas le texte intégral du prompt transmis lors d’un ancien échange.
Surveillez la consommation par canal. La directive Interne est estimée à environ 40 jetons, Communauté à 20 et Widget externe/API à 70. L’impact est généralement inférieur à celui d’un personnage trop long, mais ces différences comptent à fort volume.
Changements inclus dans 1.16000
Pour les agents API et Widget externe, les consignes de langue suivent le message reçu. Les variables utilisateur concernent uniquement les parcours authentifiés Interne et Communauté. Vérifiez les directives de langue partagées et les instructions API : une réponse concise à l’automatisation ne doit pas rendre un message destiné à une personne abrupt ou sans salutation. Préservez vos instructions lors de la fusion des valeurs par défaut.
Questions fréquentes
Non. Sur Interne et Communauté, une directive avec variables couvre les langues prises en charge par le modèle. Sur Widget externe et API, la directive suit la langue des messages.
Celles prises en charge par le modèle sous-jacent. La plateforme ne limite pas la liste des langues ; elle indique au modèle celle de l’utilisateur authentifié ou celle à déduire du message, selon le canal.
Il n’existe pas de prompt distinct pour chaque langue. Sur les canaux authentifiés, la même directive s’adapte grâce à ses variables. Sur les canaux externes, elle suit les messages échangés.
Vous pouvez demander une langue fixe dans les instructions, par exemple remplacer {USER_LANGUAGE_CODE} par fr dans un prompt adapté. Vérifiez qu’il est réellement chargé sur le canal concerné. Une langue fixe remplace la préférence habituelle de l’utilisateur : réservez-la à un besoin explicite.
Le modèle génère les titres, résumés et descriptions dans la langue de sa réponse. Les noms API, identifiants d’enregistrement et métadonnées structurelles de l’action restent inchangés, conformément à l’exception de la directive Interne.
Oui. {USER_LANGUAGE} et {USER_LANGUAGE_CODE} sont disponibles dans les prompts personnalisés et sont remplacées lors de l’assemblage. Consultez Variables de contexte des prompts et vérifiez leur sens pour le canal concerné.
Cela dépend des instructions effectivement chargées et de la version installée. Un prompt transmis au modèle contribue aux jetons, même en anglais. Vérifiez la conversation et ses crédits plutôt que de supposer une omission systématique.
Prochaines étapes
Consultez Variables de contexte des prompts pour les champs de fusion disponibles, ou Prompts personnalisés par agent pour ajouter des comportements linguistiques ciblés.