Appeler le composant de modèle de langue volumineuse

Le composant Invoke Large Language Model (LLM) dans Visual Flow Designer vous permet de connecter un flux au LLM au moyen d'un appel de service REST.

Vous pouvez insérer cet état de composant dans votre flux de dialogue en sélectionnant Intégration de services > Appeler un modèle de langue volumineux dans la boîte de dialogue Ajouter un état. Pour activer les conversations à plusieurs tours lorsque les compétences sont appelées à partir d'un assistant numérique, entrez une description pour la description LLM.
Ceci est une image du champ Descripiton dans la page General (Général).

Note

À titre de meilleure pratique, ajoutez toujours des descriptions aux composants LLM pour permettre des affinements à plusieurs tours lorsque les utilisateurs accèdent au service LLM au moyen d'un assistant numérique.

L'insertion de l'état du composant LLM ajoute un état de traitement des erreurs pour le dépannage des demandes vers le LLM et ses réponses. L'état du composant LLM passe à cet état (appelé ShowLLMError par défaut) lorsqu'une demande ou une réponse non valide entraîne une erreur non récupérable.
Description de invokellm-added-flow.png :
Description de l'illustration invokellm-added-flow.png

En plus d'appeler le service LLM, l'état du composant LLM gère les transactions interactives, telles que les affinements multi-tours, les échanges de va-et-vient entre l'utilisateur et la LMM qui affinent la sortie LLM par des tours de rétroaction de l'utilisateur.
Note

L'affinement de la réponse peut également provenir du système lorsqu'il met en oeuvre des nouvelles tentatives après l'échec de la validation.
Vous pouvez envoyer le résultat du modèle LLM sous forme de message ou l'enregistrer dans une variable de flux de dialogue pour une utilisation en aval. La validation intégrée du composant LLM fournit des garde-corps contre les vulnérabilités telles que les attaques par injection rapide qui ignorent les directives de modération du contenu du modèle.
Note

Si vous voulez améliorer la validation que le composant LLM fournit déjà, ou si vous voulez améliorer la sortie LLM à l'aide de la technique RCI (Recursive Criticism and Improvement), vous pouvez utiliser notre code de démarrage pour créer vos propres programmes de validation de demande et de réponse.

De quoi avez-vous besoin pour utiliser ce composant? Si vous accédez au modèle Cohere directement ou au moyen du service d'intelligence artificielle générative d'Oracle, vous avez juste besoin d'un service LLM pour le modèle Cohere et d'une invite, qui est un bloc de texte lisible par l'homme contenant les instructions pour le LLM. Parce que l'écriture d'une invite est un processus itératif, nous vous fournissons des directives d'ingénierie rapides et le générateur d'invites, où vous pouvez incorporer ces directives dans votre texte d'invite et le tester jusqu'à ce qu'il obtienne la réponse appropriée du modèle. Si vous utilisez un autre modèle, comme Azure OpenAI, vous devez d'abord créer votre propre gestionnaire d'événements de transformation à partir du code de démarrage que nous fournissons, puis créer un service LLM qui mappe ce gestionnaire aux points d'extrémité du fournisseur LLM configurés pour l'instance.

Propriétés générales

Propriété Description Valeur par défaut Obligatoire?
Service LLM Liste des services LLLM configurés pour la compétence. S'il y en a plusieurs, le service LLM par défaut est utilisé lorsqu'aucun service n'a été sélectionné. Le service LLM par défaut L'état peut être valide sans le service LLM, mais la compétence ne peut pas se connecter au modèle si cette propriété n'a pas été définie.
Invite Invite propre au modèle auquel le service LLM sélectionné accède. Gardez à l'esprit nos directives générales lors de la rédaction de votre invite. Vous pouvez entrer l'invite dans ce champ, puis la réviser et la tester à l'aide du générateur d'invites (accessible en cliquant sur Créer une invite). Vous pouvez également composer votre invite à l'aide du générateur d'invites. S.O. Oui
Paramètres d'invite Les valeurs du paramètre. Utilisez la syntaxe d'expression Apache FreeMarker standard (${parameter}) pour référencer les paramètres dans le texte de l'invite. Par exemple :
Draft an email about ${opportunity} sales.
Pour les variables d'entité composite, utilisez la syntaxe suivante :
  • ${cb_entity.value.bag_item.value} pour les éléments de liste de valeurs
  • ${cb_entity.value.bag_item} pour les éléments de liste sans valeur
Vous devez définir tous les paramètres d'invite ou chacun des paramètres référencés dans le texte d'invite. Tous les paramètres d'invite manquants sont marqués comme des erreurs.
S.O. Non
Variable de résultat Variable qui stocke la réponse LLM. S.O. Non

Messagerie d'utilisateur

Ces options s'appliquent uniquement lorsque vous réglez Envoyer le résultat LLM en tant que message à Vrai.
Propriété Description Valeurs par défaut Obligatoire?
Envoyer le résultat LLM en tant que message Le réglage à Vrai retourne le résultat LLM dans un message envoyé à l'utilisateur. Le réglage de cette propriété à Faux empêche l'envoi de la sortie à l'utilisateur. Vrai Non
Utiliser le service de diffusion en continu Les résultats du LLM sont transmis au client lorsque vous réglez cette option à Vrai, ce qui peut offrir une expérience utilisateur plus fluide, car la réponse du LLM s'affiche de manière incrémentielle au fur et à mesure de sa génération plutôt que de la totalité à la fois. Cette option n'est disponible que si vous avez réglé Envoyer le résultat LLM en tant que message à Vrai.

Les utilisateurs peuvent voir les réponses potentiellement non valides, car le programme de traitement d'événements de validation est appelé une fois que la réponse LLM a déjà commencé à être diffusée en continu.

Réglez Utiliser le service de diffusion en continu à Faux pour les modèles Cohere ou lorsque vous avez appliqué un schéma JSON au résultat LLM en réglant Imposer une réponse LLM au format JSON à Vrai.

Ne pas activer la diffusion en continu si :
  • Votre compétence s'exécute sur les canaux Slack ou Microsoft Teams.
  • Vous avez défini une validation de réponse. Le programme de traitement ne peut valider qu'une réponse complète. Par conséquent, si vous réglez Utiliser la diffusion en continu à Vrai, les utilisateurs peuvent envoyer plusieurs flux de sortie, ce qui peut les confondre.
Vrai Non
Start Message (Message de démarrage) Message de statut qui est envoyé à l'utilisateur lorsque le LLM a été appelé. Ce message, qui est rendu avant l'appel LLM, peut être un indicateur utile. Il peut informer les utilisateurs que le traitement a lieu, ou que le LLM peut prendre un certain temps pour répondre. S.O. Non
Activer les affinements multiples En réglant cette option à Vrai (valeur par défaut), vous permettez aux utilisateurs de préciser la réponse LLM en fournissant des instructions de suivi. La boîte de dialogue libère le tour à l'utilisateur, mais reste à l'état LLM après la réception du résultat LLM. Lorsque cette option est réglée à Faux, la boîte de dialogue conserve le tour jusqu'à ce que la réponse LLM ait été reçue et passe à l'état référencé par l'action Réussite.

Note : La description du composant est requise pour les affinements à plusieurs tours lorsque la compétence est appelée à partir d'un assistant numérique.

Vrai Non
Actions standard Ajoute les boutons d'action standard qui s'affichent sous la sortie dans le message de résultat LLM. Tous ces boutons sont activés par défaut.
  • Soumettre - Lorsqu'un utilisateur sélectionne ce bouton, la transition next est déclenchée et le programme de traitement d'événements submit est lancé.
  • Annuler - Lorsqu'un utilisateur sélectionne ce bouton, la boîte de dialogue passe à l'état défini pour la transition Annuler.
  • Annuler - Lorsque vous cliquez sur cette option, la compétence supprime la dernière réponse d'affinement et rétablit le résultat précédent. La compétence supprime également le raffinement précédent de l'historique de clavardage. Ce bouton ne s'affiche pas dans la réponse initiale. Il ne s'affiche qu'une fois que le service LLM a généré un affinement.
    Les boutons Submit (Soumettre), Cancel (Annuler) et Undo (Annuler) au bas du message.

Les options Soumettre, Annuler et Annuler sont toutes sélectionnées. Non
Étiquette du bouton Annuler Étiquette du bouton Annuler Submit Oui - Lorsque l'action Annuler est définie.
Étiquette du bouton Succès Étiquette du bouton de réussite Cancel Oui - lorsque l'action Succès est définie.
Étiquette du bouton Annuler Étiquette du bouton d'annulation Undo Oui - Lorsque l'action Annuler est définie.
Actions personnalisées Bouton d'action personnalisé. Entrez une étiquette de bouton et une invite avec des instructions supplémentaires. S.O. Non

Actions de transition pour le composant Invoke Large Language Model

Action Description
cancel

Cette action est déclenchée en appuyant ensuite sur le bouton Annuler.

error

Cette action est déclenchée lorsque les demandes ou les réponses du LLM ne sont pas valides. Par exemple, l'attribution des invites de nouvelle tentative pour corriger les erreurs de valeur JSON ou d'entité a été utilisée.

Notations d'utilisateur pour le contenu généré par LLM

Par défaut, la notation de l'utilisateur (pouces vers le haut et pouces vers le bas) s'affiche sur chaque message.
Icônes Pouces vers le haut et Pouces vers le bas dans le message de réponse de la compétence

Lorsque les utilisateurs attribuent une note descendante à la réponse LLM, la compétence suit avec un lien qui ouvre un formulaire de rétroaction.

Vous pouvez désactiver ces boutons en désactivant Enable Large Language Model feedback (Activer la rétroaction de modèle de langue volumineuse) dans Settings (Paramètres) > Configuration.
L'option Enable Large Language Model feedback (Activer la rétroaction de modèle de langue volumineuse).

Validation de réponse

Propriété Description Valeur par défaut Obligatoire?
Entités de validation Sélectionnez les entités dont les valeurs doivent être mises en correspondance dans le message de réponse LLM. Les noms de ces entités et leurs valeurs correspondantes sont transmis en tant que mappage au programme de traitement d'événements, qui évalue cet objet pour les correspondances d'entité manquantes. Lorsque des correspondances d'entité manquantes entraînent l'échec de la validation, le programme de traitement retourne un message d'erreur nommant les entités sans correspondance, qui est ensuite envoyé au modèle. Le modèle tente ensuite de régénérer une réponse qui inclut les valeurs manquantes. Il continue avec ses tentatives jusqu'à ce que le gestionnaire valide sa sortie ou jusqu'à ce qu'il ait épuisé son nombre de nouvelles tentatives.

Nous recommandons d'utiliser des entités composites pour permettre au programme de traitement d'événements de générer des messages d'erreur concis, car les étiquettes et les messages d'erreur appliqués à des éléments d'entité composite individuels fournissent au LLM des détails sur les valeurs d'entité qu'il n'a pas incluses dans sa réponse.

S.O. Non
Imposer une réponse LLM au format JSON En réglant ce paramètre à Vrai, vous pouvez appliquer un formatage JSON à la réponse LLM en copiant et en collant un schéma JSON. Le composant LLM valide la réponse LLM au format JSON par rapport à ce schéma.

Si vous ne voulez pas que les utilisateurs voient le résultat LLM en tant que JSON brut, vous pouvez créer un programme de traitement d'événements avec une méthode changeBotMessages qui transforme le JSON en un format convivial, comme un formulaire avec des tables.

Réglez Utiliser le service de diffusion en continu à Faux si vous appliquez un formatage JSON.

GPT-3.5 présente plus de robustesse que GPT-4 pour la validation de schéma JSON. Le GPT-4 corrige parfois une réponse.

Faux Non
Nombre de nouvelles tentatives Nombre maximal de nouvelles tentatives autorisées lorsque le LLM est appelé avec une invite de nouvelle tentative lorsque des erreurs de validation d'entité ou JSON ont été trouvées. L'invite de nouvelle tentative spécifie les erreurs et les demandes que le LLM corrige. Par défaut, le composant LLM effectue une seule demande de nouvelle tentative. Lorsque l'allocation des nouvelles tentatives a été atteinte, le cycle de validation de l'invite de nouvelle tentative se termine. Le dialogue se déplace ensuite du groupe de pages LLM via sa transition d'erreur. 1 Non
Réessayer le message Message de statut envoyé à l'utilisateur lorsque le LLM a été appelé à l'aide d'une invite de nouvelle tentative. Par exemple, les éléments suivants énumèrent les erreurs d'entité et JSON à l'aide de la propriété d'événement allValidationErrors :
Trying to fix the following errors: ${system.llm.messageHistory.value.allValidationErrors?join(', ')}}
Enhancing the response. One moment, please... Non
Programme de traitement des personnalisations de validation Si votre cas d'utilisation nécessite une validation spécialisée, vous pouvez sélectionner le programme de traitement de validation personnalisé qui a été déployé dans votre compétence. Par exemple, vous avez peut-être créé un programme de traitement d'événements pour votre compétence qui non seulement valide et applique un traitement supplémentaire à la réponse LLM, mais évalue également les demandes d'utilisateur de contenu toxique. Si votre cas d'utilisation nécessite que la validation d'entité ou JSON dépende de règles spécifiques, telles que les correspondances d'entité interdépendantes (par exemple, la présence d'une valeur d'entité dans le résultat LLM nécessite ou exclut la présence d'une autre), vous devrez créer le programme de traitement pour cette compétence avant de le sélectionner ici. S.O. Non

Créer des programmes de traitement de validation et de personnalisation LLM

En plus des gestionnaires de transformation LLM, vous pouvez également utiliser des gestionnaires d'événements pour valider les demandes faites au LLM et ses réponses (les achèvements générés par le fournisseur LLM). En règle générale, vous conservez ce code, appelé gestionnaire de validation et de personnalisation LLM, distinct du code du gestionnaire de transformation LLM car il fonctionne à différents niveaux. La validation de la demande et de la réponse est propre à un état LLM et à son invite. La validation de la transformation LLM s'applique à l'ensemble de la compétence, car sa logique de transformation de demande et de réponse est généralement la même pour tous les appels LLM de la compétence.

Bien que le composant LLM fournisse des garde-corps de validation pour prévenir les hallucinations et protéger contre les attaques par injection rapide destinées à contourner les directives de modération du contenu du modèle ou à exploiter d'autres vulnérabilités, vous pouvez créer des valideurs spécialisés entièrement à partir de zéro à l'aide des méthodes LlmComponentContext dans bots-node-sdk ou en intégrant ces méthodes dans le modèle que nous fournissons.
Note

Dans sa forme non modifiée, le code de modèle exécute les mêmes fonctions de validation que celles déjà fournies par le composant LLM.

Vous pouvez créer votre propre gestionnaire d'événements de validation qui personnalise la présentation de la réponse LLM. Dans ce cas, le texte de réponse LLM peut être envoyé à partir du gestionnaire dans le cadre d'un message utilisateur. Par exemple, si vous demandez au LLM d'envoyer une réponse structurée au format JSON, vous pouvez analyser la réponse et générer un message formaté en tant que table ou carte.

Pour créer un programme de traitement d'événements à l'aide de ce modèle :
  1. Cliquez sur Components (Composants) dans la barre de navigation gauche.
  2. Cliquez sur +New Service.
  3. Remplissez la boîte de dialogue Create Service :
    • Nom : Entrez le nom du service.
    • Type de service : Conteneur intégré
    • Type d'ensemble de services de composant : Nouveau composant
    • Type de composant : Validation et personnalisation LLLM
    • Nom du composant : Entrez un nom facilement identifiable pour le programme de traitement d'événements. Vous référencerez ce nom lorsque vous créerez le service LLM pour la compétence.
  4. Cliquez sur Créer pour générer le programme de traitement de validation.
  5. Une fois le déploiement terminé, développez le service, puis sélectionnez le programme de traitement de validation.
  6. Cliquez sur Modifier pour ouvrir l'éditeur de modification de code de composant.
  7. À l'aide du modèle généré, mettez à jour les méthodes de programme de traitement suivantes, au besoin.
    Méthode Description Lorsque la validation réussit Lorsque la validation échoue Type de valeur renvoyée Emplacement dans l'éditeur Code de paramètre fictif Que puis-je faire en cas d'échec de la validation?
    validateRequestPayload Valide les données utiles de la demande. Retourne true lorsque la demande est valide.

    Retourne false en cas d'échec de la validation d'une demande.

    booléen Courbes 24-29
    
        validateRequestPayload: async (event, context) => { 
          if (context.getCurrentTurn() === 1 && context.isJsonValidationEnabled()) {
            context.addJSONSchemaFormattingInstruction();
          }
          return true;
        }
    Pour en savoir plus sur ce code, consultez les propriétés validateRequestPayload.
    validateResponsePayload Valide les données utiles de la réponse LLM.
    Lorsque le programme de traitement retourne true :
    • Si vous réglez la propriété Send LLM Result as a Message (Envoyer le résultat LLM en tant que message) à true, la réponse LLM, y compris les boutons d'action standard ou personnalisés, est envoyée à l'utilisateur.
    • Si la diffusion en continu est activée, la réponse LLM sera diffusée en fragments. Les boutons d'action seront ajoutés à la fin du flux.
    • Tous les messages d'utilisateur ajoutés dans le programme de traitement sont envoyés à l'utilisateur, quel que soit le paramètre de la propriété Envoyer le résultat LLM en tant que message.
    • Si une nouvelle invite LLM est définie dans le gestionnaire, cette invite est envoyée au LLM et le gestionnaire de validation est de nouveau appelé avec la nouvelle réponse LLM.
    • Si aucune nouvelle invite LLM n'est définie et que la propriété Enable Multi-Turn Refinements (Activer les affinements à rotation multiple) est réglée à true, le virage est lancé et le flux de dialogue reste à l'état LLM. Si cette propriété est réglée à false, cependant, le virage est conservé et la boîte de dialogue passe de l'état à l'aide de l'action de transition success.
    Lorsque le programme de traitement retourne false :
    • Si la diffusion en continu est activée, les utilisateurs peuvent voir les réponses potentiellement non valides car le programme de traitement d'événements de validation est appelé après que la réponse LLM a déjà commencé la diffusion en continu.
    • Tous les messages d'utilisateur ajoutés par le programme de traitement sont envoyés à l'utilisateur, quel que soit le paramètre Send LLM Result as a Skill Response (Envoyer le résultat LLM en tant que réponse à une compétence).
    • Si une nouvelle invite LLM est définie dans le gestionnaire, cette invite est envoyée au LLM et le gestionnaire de validation est de nouveau appelé avec la nouvelle réponse LLM.
    • Si aucune invite LLM n'est définie, le flux de dialogue quitte l'état du composant LLM. L'action de transition définie dans le code du programme de traitement sera utilisée pour déterminer l'état suivant. Si aucune action de transition n'est définie, l'action de transition error est déclenchée.
    booléen Courbes 50-56
      /**
       * Handler to validate response payload
       * @param {ValidateResponseEvent} event
       * @param {LLMContext} context
       * @returns {boolean} flag to indicate the validation was successful
       */
       validateResponsePayload: async (event, context) => {
         let errors = event.allValidationErrors || [];
         if (errors.length > 0) {
           return context.handleInvalidResponse(errors);
         }
         return true;
       }
    Pour en savoir plus sur ce code, consultez validateResponsePayload Properties (Propriétés).
    • Appelez à nouveau le LLM à l'aide d'une invite de nouvelle tentative qui spécifie le problème avec la réponse (elle n'est pas conforme à un format JSON spécifique, par exemple) et demande que le LLM corrige la réponse.
    • Définissez une erreur de validation.
    changeBotMessages Modifie les messages de compétences candidates qui seront envoyés à l'utilisateur. S.O. S.O. Liste des messages du modèle de messages de conversation Courbes 59-71
    
        changeBotMessages: async (event, context) => { 
          return event.messages;
        },
    Pour un exemple d'utilisation de cette méthode, voir Améliorer le message d'utilisateur pour les réponses au format JSON.
    S.O.
    submit Ce programme de traitement est appelé lorsque les utilisateurs touchent le bouton Soumettre. Il traite plus avant la réponse LLM. S.O. S.O. S.O. Courbes 79-80
        submit: async (event, context) => { 
        }
    S.O.
    Chacune de ces méthodes utilise un objet event et un objet context. Par exemple :
     validateResponsePayload: async (event, context) =>
    ...
    Les propriétés définies pour l'objet event dépendent du type d'événement. Le deuxième argument, context, référence la classe LlmComponentContext, qui accède aux méthodes pratiques pour créer votre propre logique de programme de traitement d'événements. Il s'agit notamment de méthodes permettant de définir le nombre maximal d'invites de nouvelle tentative et d'envoyer des messages de statut et d'erreur aux utilisateurs de la compétence.
  8. Vérifiez le numéro de système de vos mises à jour en cliquant sur Valider. Cliquez sur Save (Enregistrer) > Close (Fermer).
Propriétés de l'événement validateRequestPayload
Le nom Description Type Obligatoire?
payload Demande LLM nécessitant une validation chaîne Oui
Propriétés de l'événement validateResponsePayload
Nom Description Type Obligatoire?
payload Réponse LLM à valider. chaîne Oui
validationEntities Liste des noms d'entité spécifiés par la propriété Entités de validation de l'état du composant LLM correspondant. String[] Non
entityMatches Un mappage avec le nom de l'entité mise en correspondance comme clé et un tableau de l'entité JSONObject correspond à la valeur. Cette propriété a une valeur uniquement lorsque la propriété Entités de validation est également définie dans l'état du composant LLM. Carte<String, JSONArray> Non
entityValidationErrors Paires clé-valeur avec la clé entityName ou un élément d'entité composite et un message d'erreur comme valeur. Cette propriété n'est définie que lorsque la propriété Entités de validation est également définie et qu'il manque des correspondances d'entité ou (lorsque l'entité est une entité composite) des correspondances d'élément d'entité composite manquantes. Carte<String, String> Non
jsonValidationErrors Si la propriété Appliquer la réponse LLM au format JSON du composant LLM est réglée à Vrai et que la réponse n'est pas un objet JSON valide, cette propriété contient une seule entrée avec le message d'erreur indiquant que la réponse n'est pas un objet JSON valide.

Toutefois, si le JSON est valide et que la propriété Activer la réponse LLM au format JSON du composant est également réglée à Vrai, cette propriété contient des paires clé-valeur avec le chemin du schéma en tant que clés et (lorsque la réponse ne respecte pas le schéma) les messages d'erreur de validation de schéma en tant que valeurs.

Carte<String, String> Non
allValidationErrors Liste de toutes les erreurs de validation d'entité et de validation JSON. String[] Non
Échantillons de code de programme de traitement de validation

Validation JSON personnalisée
L'extrait de code suivant illustre comment ajouter du code au modèle validateResponsePayload par défaut pour vérifier qu'une demande de personnel au format JSON est réglée à Los Angeles :
  /**
   * Handler to validate response payload
   * @param {ValidateResponseEvent} event
   * @param {LLMContext} context
   * @returns {boolean} flag to indicate the validation was successful
   */
   validateResponsePayload: async (event, context) => {
     let errors = event.allValidationErrors || [];
     const json = context.convertToJSON(event.payload);
     if (json && 'Los Angeles' !== json.location) {
       errors.push('Location is not set to Los Angeles');
     }
     if (errors.length > 0) {
       return context.handleInvalidResponse(errors);
     }
     return true;
   }
Améliorer le message d'utilisateur pour les réponses au format JSON
Si vous avez besoin que le LLM retourne la réponse au format JSON, vous ne voulez peut-être pas afficher la réponse JSON brute aux utilisateurs de la compétence. Cependant, comme la réponse est maintenant structurée en JSON et conforme au schéma JSON que vous avez fourni, vous pouvez facilement la transformer en un des types de message du modèle de message de conversation, comme une carte, une table ou un message de formulaire. L'extrait de code suivant illustre l'utilisation du programme de traitement changeBotMessages pour transformer la réponse JSON brute en message de formulaire convivial.
     /**
      * Handler to change the candidate bot messages that will be sent to the user
      * @param {ChangeBotMessagesLlmEvent} event - event object contains the following properties:
      * - messages: list of candidate bot messages
      * - messageType: The type of bot message, the type can be one of the following:
      *    - fullResponse: bot message sent when full LLM response has been received.
      *    - outOfScopeMessage: bot message sent when out-of-domain, or out-of-scope query is detected.
      *    - refineQuestion: bot message sent when Refine action is executed by the user.
      * @param {LlmComponentContext} context - see https://oracle.github.io/bots-node-sdk/LlmComponentContext.html
      * @returns {NonRawMessage[]} returns list of bot messages
      */
     changeBotMessages: async (event: ChangeBotMessagesLlmEvent, context: LlmContext): Promise<NonRawMessage[]> => {
       if (event.messageType === 'fullResponse') {          
         const jobDescription = context.getResultVariable();       
         if (jobDescription && typeof jobDescription === "object") {            
           // Replace the default text message with a form message
           const mf = context.getMessageFactory();
           const formMessage = mf.createFormMessage().addForm(
             mf.createReadOnlyForm()
             .addField(mf.createTextField('Title', jobDescription.title))
             .addField(mf.createTextField('Location', jobDescription.location))
             .addField(mf.createTextField('Level', jobDescription.level))
             .addField(mf.createTextField('Summary', jobDescription.shortDescription))
             .addField(mf.createTextField('Description', jobDescription.description))
             .addField(mf.createTextField('Qualifications', `<ul><li>${jobDescription.qualifications.join('</li><li>')}</li></ul>`))
             .addField(mf.createTextField('About the Team', jobDescription.aboutTeam))
             .addField(mf.createTextField('About Oracle', jobDescription.aboutOracle))
             .addField(mf.createTextField('Keywords', jobDescription.keywords!.join(', ')))
           ).setActions(event.messages[0].getActions()) 
            .setFooterForm(event.messages[0].getFooterForm());
           event.messages[0] = formMessage;
         }
       }
       return event.messages;
     }          
   }
Validation d'entité personnalisée
L'extrait de code suivant illustre comment le code suivant, lorsqu'il est ajouté au modèle validateResponsePayload, vérifie que l'emplacement de la description d'emploi est réglé à Los Angeles à l'aide de correspondances d'entité. Cet exemple suppose qu'une entité LOCATION a été ajoutée à la propriété Entités de validation de l'état LLM.
 /**
   * Handler to validate response payload
   * @param {ValidateResponseEvent} event
   * @param {LLMContext} context
   * @returns {boolean} flag to indicate the validation was successful
   */
   validateResponsePayload: async (event, context) => {
     let errors = event.allValidationErrors || [];
     if (!event.entityMatches.LOCATION || event.entityMatches.LOCATION[0].city !== 'los angeles') {
       errors.push('Location is not set to Los Angeles');
     }         
     if (errors.length > 0) {
       return context.handleInvalidResponse(errors);
     }
     return true;
   }
Erreurs de validation
Vous pouvez définir des erreurs de validation dans les méthodes de programme de traitement validateRequestPayload et validateResponsePayload qui sont composées de
  • Un message d'erreur personnalisé
  • Un des codes d'erreur définis pour la propriété CLMI errorCode.
Comme les erreurs de validation ne sont pas récupérables, le composant LLM déclenche sa transition error chaque fois qu'une des méthodes du programme de traitement d'événements ne peut pas valider une demande ou une réponse. Le flux de dialogue passe ensuite à l'état lié à la transition error. Lorsque vous ajoutez le composant LLM, il est accompagné d'un tel état d'erreur. Cet état d'envoi de message, dont le nom par défaut est showLLMError, relaie l'erreur en référençant la variable de portée Flux qui stocke les détails de l'erreur appelés system.llm.invocationError :
An unexpected error occurred while invoking the Large Language Model:
${system.llm.invocationError}
Cette variable stocke les erreurs définies par la logique personnalisée dans les programmes de traitement d'événements ou par le composant LLM lui-même. Cette variable contient un mappage avec les clés suivantes :
  • errorCode : Un des codes d'erreur CLMI
  • errorMessage : Message (valeur de chaîne) décrivant l'erreur.
  • statusCode : Code de statut HTTP retourné par l'appel LLM.

Conseil :

Bien que error soit la transition par défaut pour les échecs de validation, vous pouvez utiliser une autre action en définissant une transition d'erreur personnalisée dans le code de programme de traitement.
Critique et amélioration récursives (RCI)
Vous pouvez améliorer les réponses LLM en utilisant la technique de la critique et de l'amélioration récursives (RCI), par laquelle le LLM est appelé de manière récursive pour trouver des problèmes dans sa sortie, puis améliorer la sortie en fonction de ses résultats. L'activation de RCI est un processus en deux étapes :
  1. Envoyez une invite au LLM qui demande de critiquer la réponse précédente.
  2. Envoyez une invite au LLM pour améliorer la réponse en fonction de la critique.
Vous pouvez appliquer l'ICR automatique ou le faire exécuter sur demande par l'utilisateur de la compétence. Le programme de traitement validateResponsePayload exécute le cycle RCI des invites de critique et d'amélioration.
RCI automatique
Comme illustré dans l'extrait de code suivant, le code vérifie le programme de traitement validateResponsePayload si RCI a déjà été appliqué. Si ce n'est pas le cas, le RCI critique - améliorer la séquence commence. Une fois l'invite de critique envoyée, le programme de traitement validateResponsePayload est appelé et, en fonction de l'état RCI stocké dans une propriété personnalisée, l'invite d'amélioration est envoyée.
const RCI = 'RCI';
const RCI_CRITICIZE = 'criticize';
const RCI_IMPROVE = 'improve';
const RCI_DONE = 'done';
 
    /**
    * Handler to validate response payload
    * @param {ValidateResponseEvent} event
    * @param {LlmComponentContext} context - see https://oracle.github.io/bots-node-sdk/LlmComponentContext.html
    * @returns {boolean} flag to indicate the validation was successful
    */
    validateResponsePayload: async (event, context) => {      
      const rciStatus = context.getCustomProperty(RCI);
      if (!rciStatus) {
        context.setNextLLMPrompt(`Review your previous answer. Try to find possible improvements one could make to the answer. If you find improvements then list them below:`, false);
        context.addMessage('Finding possible improvements...');
        context.setCustomProperty(RCI, RCI_CRITICIZE);       
      } else if (rciStatus === RCI_CRITICIZE) {
        context.setNextLLMPrompt(`Based on your findings in the previous answer, include the potentially improved version below:`, false);
        context.addMessage('Generating improved answer...');
        context.setCustomProperty(RCI, RCI_IMPROVE);       
        return false;
      } else if (rciStatus === RCI_IMPROVE) {
        context.setCustomProperty(RCI, RCI_DONE);       
      }     
      return true;
    }
RCI sur demande
L'extrait de code suivant illustre l'activation de RCI sur demande en ajoutant un bouton Améliorer au message de compétence envoyé à l'utilisateur dans la méthode changeBotMessages. Ce bouton appelle le programme de traitement d'événements personnalisés qui démarre le cycle RCI. La méthode validateResponsePayload gère le cycle de critique et d'amélioration RCI.
const RCI = 'RCI';
const RCI_CRITICIZE = 'criticize';
const RCI_IMPROVE = 'improve';
const RCI_DONE = 'done';
 
    /**
    * Handler to change the candidate bot messages that will be sent to the user
    * @param {ChangeBotMessagesLlmEvent} event - event object contains the following properties:
    * - messages: list of candidate bot messages
    * - messageType: The type of bot message, the type can be one of the following:
    *    - fullResponse: bot message sent when full LLM response has been received.
    *    - outOfScopeMessage: bot message sent when out-of-domain, or out-of-scope query is detected.
    *    - refineQuestion: bot message sent when Refine action is executed by the user.
    * @param {LlmComponentContext} context - see https://oracle.github.io/bots-node-sdk/LlmComponentContext.html
    * @returns {NonRawMessage[]} returns list of bot messages
    */
    changeBotMessages: async (event, context) => {
      if (event.messageType === 'fullResponse') {
        const mf = context.getMessageFactory();
        // Add button to start RCI cycle
        event.messages[0].addAction(mf.createCustomEventAction('Improve', 'improveUsingRCI')); 
      }
      return event.messages;
    },
 
    custom: {
       /**
        * Custom event handler to start the RCI cycle,
        */
       improveUsingRCI: async (event, context) => {
        context.setNextLLMPrompt(`Review your previous answer. Try to find possible improvements one could make to the answer. If you find improvements then list them below:`, false);
        context.addMessage('Finding possible improvements...');
        context.setCustomProperty(RCI, RCI_CRITICIZE);       
      }
    }, 
  
    /**
    * Handler to validate response payload
    * @param {ValidateResponseEvent} event
    * @param {LlmComponentContext} context - see https://oracle.github.io/bots-node-sdk/LlmComponentContext.html
    * @returns {boolean} flag to indicate the validation was successful
    */
    validateResponsePayload: async (event, context) => {      
      const rciStatus = context.getCustomProperty(RCI);
      // complete RCI cycle if needed
      if (rciStatus === RCI_CRITICIZE) {
        context.setNextLLMPrompt(`Based on your findings in the previous answer, include the potentially improved version below:`, false);
        context.addMessage('Generating improved answer...');
        context.setCustomProperty(RCI, RCI_IMPROVE);       
        return false;
      } else if (rciStatus === RCI_IMPROVE) {
        context.setCustomProperty(RCI, RCI_DONE);       
      }     
      return true;
    }

Options avancées

Propriété Description Valeur par défaut Obligatoire?
Contexte d'utilisateur initial Envoie des messages utilisateur supplémentaires dans le cadre de l'invite LLM initiale au moyen des méthodes suivantes :
  • Dernier message d'utilisateur - Message d'utilisateur qui a déclenché la transition vers l'état du composant LLM.
  • Message de déclenchement d'intention - Message d'utilisateur utilisé comme interrogation pour la dernière correspondance d'intention, qui est stockée dans la variable skill.system.nlpresult.
  • Expression personnalisée - Utilise l'expression Apache FreeMarker utilisée pour l'entrée d'utilisateur personnalisée.
S.O. Non
Entrée d'utilisateur personnalisée Expression Apache Freemarker qui spécifie le texte envoyé sous le rôle d'utilisateur dans le cadre de l'invite LLM initiale. S.O. Non
Message hors portée Message qui s'affiche lorsque le LLM évalue l'interrogation de l'utilisateur comme étant hors portée (OOS) ou hors domaine (OOD). S.O. Non
Mot clé hors portée Par défaut, la valeur est InvalidInput. LLM retourne ce mot clé lorsqu'il évalue l'interrogation d'utilisateur comme étant hors portée (OOS) ou hors domaine (OOD) selon les instructions de limitation de portée de l'invite. Lorsque le modèle sort ce mot clé, le flux de dialogue peut passer à un nouvel état ou à un nouveau flux.

Ne modifiez pas cette valeur. Si vous devez modifier le mot clé pour répondre à un cas d'utilisation particulier, nous vous recommandons d'utiliser le langage naturel au lieu d'un mot clé qui peut être mal interprété. Par exemple, UnsupportedQuery pourrait être un mot clé approprié alors que code514 (erreur) ne l'est pas.

invalidInput - Ne modifiez pas cette valeur. La modification de cette valeur peut entraîner un comportement de modèle indésirable. Non
Température Encourage, ou restreint, le caractère aléatoire et la créativité des complétions du LLM à la vitesse du jour. Vous pouvez évaluer la créativité du modèle en réglant la température entre 0 (bas) et 1 (haut). Une température basse signifie que l'achèvement du modèle à l'invite sera simple, ou déterministe : les utilisateurs obtiendront presque toujours la même réponse à une invite donnée. Une température élevée signifie que le modèle peut extrapoler plus loin de l'invite pour ses réponses.

Par défaut, la température est réglée à 0 (inférieure).

0 Non
Nombre maximal de jetons Le nombre de jetons que vous définissez pour cette propriété détermine la longueur des achèvements générés pour les affinements à plusieurs tours. Le nombre de jetons pour chaque achèvement doit être compris dans la limite de contexte du modèle. Le réglage de cette propriété à un nombre inférieur empêchera la dépense de jeton de dépasser la longueur de contexte du modèle lors de l'appel, mais cela peut également entraîner des réponses courtes. L'inverse est vrai lorsque vous réglez la limite de jeton à une valeur élevée : la consommation de jeton atteindra la limite de contexte du modèle après seulement quelques tours (ou achèvements). En outre, la qualité des achèvements peut également diminuer, car le nettoyage des achèvements précédents par le composant LLM peut modifier le contexte de la conversation. Si vous définissez un nombre élevé de jetons et que votre invite est également très longue, vous atteindrez rapidement la limite du modèle après quelques tours. 1024 Non

Générateur d'invites

La première version de votre invite peut ne pas fournir au modèle des instructions suffisamment claires pour qu'il génère les achèvements que vous attendez. Pour aider le modèle à prédire comment il doit terminer l'invite, vous devrez peut-être réviser le texte de l'invite plusieurs fois. En fait, nos meilleures pratiques suggèrent de le faire. Le générateur d'invites vous permet de parcourir rapidement ces révisions jusqu'à ce que votre invite produise des achèvements cohérents compte tenu du nombre maximal de jetons alloués à la réponse, du paramètre de température et des valeurs de paramètre transmises.
Note

Vous pouvez tester les paramètres à l'aide de valeurs fictives, et non de valeurs stockées. Vous pouvez ajouter vos propres valeurs de simulation en cliquant sur Modifier
L'icône Edit (Modifier).

, ou utilisez ceux fournis par le modèle lorsque vous cliquez sur Générer des valeurs.
Si plusieurs services LLM sont configurés, vous pouvez basculer entre les modèles pour comparer les résultats. Lorsque votre invite déclenche l'achèvement attendu du modèle, cliquez sur Enregistrer les paramètres pour remplacer le texte existant dans le champ Invite de l'inspecteur de propriété de composant, mettez à jour le modèle cible, la température et la limite de jeton. (Si vous avez écrit votre invite à partir de zéro à l'aide du générateur d'invites, cliquez sur Save Settings (Enregistrer les paramètres) pour alimenter le champ d'invite.) La fermeture du générateur d'invites annule toutes les modifications que vous avez apportées à l'invite et conserve le texte dans le champ Invite.
Note

Pour optimiser l'expérience utilisateur, vous devez exécuter le testeur de compétence, qui vous permet de tester des aspects conversationnels tels que les valeurs de paramètre stockées (y compris l'historique de conversation et la variable de résultat d'invite), les en-têtes et les pieds de page, ou les affinements à plusieurs tours (et leurs boutons connexes) et de jauger la taille de l'historique de conversation du composant.

Invites : meilleures pratiques

Une conception rapide efficace est essentielle pour tirer le meilleur parti des LLM. Bien que les stratégies de réglage rapide varient selon les modèles et les cas d'utilisation, les fondamentaux de ce qui constitue une "bonne" invite restent cohérents. Les LLM fonctionnent généralement bien à l'achèvement du texte, ce qui prédit l'ensemble suivant de jetons pour le texte d'entrée donné. Pour cette raison, les invites de style texte constituent un bon point de départ pour les cas d'utilisation simples. Des scénarios plus sophistiqués peuvent justifier des instructions détaillées et des techniques avancées telles que l'invite de quelques instants ou l'invite de chaîne de pensée.

Voici quelques lignes directrices pour l'art et la science de l'élaboration de votre invite. En bref, vous les combinerez en une invite cohérente. Voici le processus :
  1. Commencez par définir le rôle ou le persona du LLM avec une description de haut niveau de la tâche à accomplir.
  2. Ajoutez des détails sur les éléments à inclure dans la réponse, le format de sortie attendu, etc.
  3. Si nécessaire, fournissez quelques exemples de la tâche à accomplir.
  4. Facultativement, mentionnez comment traiter les scénarios constituant une interrogation non prise en charge.
  • Commencer par une invite simple et concise - Commencez par une invite courte, simple et directe qui décrit clairement le cas d'utilisation et la sortie attendue. Par exemple :
    • Une instruction en une ligne comme "Dites-moi une blague"
    • Invite de style d'achèvement de texte
    • Une instruction avec une entrée
    Par exemple :
    "Summarize the following in one sentence:
    
    The Roman Empire was a large and powerful group of ancient civilizations that formed after the collapse of the Roman Republic in Rome, Italy, in 27 BCE. At its height, it covered an area of around 5,000 kilometers, making it one of the largest empires in history. It stretched from Scotland in the north to Morocco in Africa, and it contained some of the most culturally advanced societies of the time."
    Une simple invite est un bon point de départ de vos tests, car c'est un bon indicateur du comportement du modèle. Il vous permet également d'ajouter d'autres éléments au fur et à mesure que vous affinez votre texte d'invite.
  • Modifier et tester votre invite de manière itérative - Ne vous attendez pas à ce que la première version provisoire de votre invite retourne les résultats attendus. Il peut prendre plusieurs séries de tests pour savoir quelles instructions doivent être ajoutées, supprimées ou reformulées. Par exemple, pour empêcher le modèle d'halluciner en ajoutant du contenu supplémentaire, vous devez ajouter des instructions supplémentaires :
    
    
    "Summarize the following paragraph in one sentence. Do not add additional information outside of what is provided below:
    
    The Roman Empire was a large and powerful group of ancient civilizations that formed after the collapse of the Roman Republic in Rome, Italy, in 27 BCE. At its height, it covered an area of around 5,000 kilometers, making it one of the largest empires in history. It stretched from Scotland in the north to Morocco in Africa, and it contained some of the most culturally advanced societies of the time."
  • Utiliser un persona propre à votre cas d'utilisation - Les personas obtiennent souvent de meilleurs résultats, car ils aident le LLM à imiter le comportement ou à assumer un rôle.
    Note

    Les modèles de cohère pèsent les instructions propres à la tâche plus que la définition de persona.
    Par exemple, si vous souhaitez que le LLM génère des informations, demandez-lui d'être un analyste de données :
    Assume the role of a data analyst. Given a dataset, your job is to extract valuable insights from it.
    Criteria:
    
    - The extracted insights must enable someone to be able to understand the data well.
    - Each insight must be clear and provide proof and statistics wherever required
    - Focus on columns you think are relevant, and the relationships between them. Generate insights that can provide as much information as possible.
    - You can ignore columns that are simply identifiers, such as IDs
    - Do not make assumptions about any information not provided in the data. If the information is not in the data, any insight derived from it is invalid
    - Present insights as a numbered list
    
    Extract insights from the data below:
    {data}
    Note

    Faites attention aux biais ou aux comportements implicites qui peuvent être inhérents au persona.
  • Écrire des invites propres à un LLM - Les LLM ont des architectures différentes et sont entraînés à l'aide de différentes méthodes et de différents jeux de données. Vous ne pouvez pas écrire une seule invite qui retournera les mêmes résultats de tous les LLM, ou même des versions différentes du même LLM. Les approches qui fonctionnent bien avec GPT-4 échouent avec GPT-3.5 et vice-versa, par exemple. Au lieu de cela, vous devez adapter votre invite aux capacités du LLM choisi pour votre cas d'utilisation. Utiliser quelques exemples d'instantané - Comme les modules de gestion de la qualité apprennent des exemples, fournissez quelques exemples d'instantané chaque fois que cela est pertinent. Incluez dans votre invite des exemples étiquetés qui illustrent la structure de la réponse générée. Par exemple :
    Generate a sales summary based on the given data. Here is an example:
    
    Input: ...
    Summary: ...
    
    Now, summarize the following sales data:
    
    ....
    Fournissez quelques exemples d'instantanés lorsque :
    • Les contraintes structurelles doivent être appliquées.
    • Les réponses doivent être conformes à des modèles spécifiques et contenir des détails spécifiques
    • Les réponses varient en fonction des différentes conditions d'entrée
    • Votre cas d'utilisation est très spécifique au domaine ou ésotérique, car les LLM, qui disposent de connaissances générales, fonctionnent mieux sur les cas d'utilisation courants.
    Note

    Si vous incluez plusieurs exemples d'instantané dans l'invite d'un modèle Cohere, assurez-vous de représenter de manière égale toutes les classes d'exemples. Un déséquilibre dans les catégories d'exemples peu saisis affecte négativement les réponses, car le modèle limite parfois sa production aux modèles prédominants trouvés dans la majorité des exemples.
  • Définir des critères d'acceptation clairs - Plutôt que d'instruire le LLM sur ce que vous ne voulez pas qu'il fasse en incluant "ne pas faire ceci" ou "éviter cela" dans l'invite, vous devez fournir des instructions claires qui indiquent au LLM ce qu'il doit faire en termes de sortie acceptable. Qualifier les résultats appropriés en utilisant des critères concrets au lieu d'adjectifs vagues.
    Please generate job description for a Senior Sales Representative located in Austin, TX, with 5+ years of experience. Job is in the Oracle Sales team at Oracle. Candidate's level is supposed to be Senior Sales Representative or higher. 
    
    Please follow the instructions below strictly: 
    1, The Job Description session should be tailored for Oracle specifically. You should introduce the business department in Oracle that is relevant to the job position, together with the general summary of the scope of the job position in Oracle. 
    2, Please write up the Job Description section in a innovative manner. Think about how you would attract candidates to join Oracle. 
    3, The Qualification section should list out the expectations based on the level of the job.
  • Soyez bref et concis - Gardez l'invite aussi succincte que possible. Évitez d'écrire de longs paragraphes. Le LLM est plus susceptible de suivre vos instructions si vous les fournissez comme des points brefs, concis. Essayez toujours de réduire la verbosité de l'invite. Bien qu'il soit crucial de fournir des instructions détaillées et toutes les informations de contexte avec lesquelles le LLM est censé fonctionner, gardez à l'esprit que la précision des réponses générées par le LLM tend à diminuer à mesure que la durée de l'invite augmente.
    Par exemple, effectuez les opérations suivantes :
    - Your email should be concise, and friendly yet remain professional.
    - Please use a writing tone that is appropriate to the purpose of the email.
    - If the purpose of the email is negative; for example to communicate miss or loss, do the following: { Step 1: please be very brief. Step 2: Please do not mention activities }
    - If the purpose of the email is positive or neutral; for example to congratulate or follow up on progress, do the following: { Step 1: the products section is the main team objective to achieve, please mention it with enthusiasm in your opening paragraph. Step 2: please motivate the team to finalize the pending activities. }
    Ne pas faire ceci :
    Be concise and friendly. But also be professional. Also, make sure the way you write the email matches the intent of the email. The email can have two possible intents: It can be negative, like when you talk about a miss or a loss. In that case, be brief and short, don't mention any activities.
    
    An email can also be positive. Like you want to follow up on progress or congratulate on something. In that case, you need to mention the main team objective. It is in the products section. Also, take note of pending activities and motivate the team
  • Méfiez-vous des biais inhérents - Les LLM sont formés sur de grands volumes de données et de connaissances du monde réel qui peuvent souvent contenir des informations historiquement inexactes ou obsolètes et comporter des biais inhérents. Cela, à son tour, peut amener les LLM à halluciner et à produire des données incorrectes ou des informations biaisées. Les LLM ont souvent une limite de formation qui peut les amener à présenter des informations historiquement inexactes, mais en toute confiance.
    Note

    Ne pas :
    • Demandez aux LLM de rechercher sur le Web ou d'extraire les informations courantes.
    • Demandez aux LLM de générer du contenu en fonction de leur propre interprétation des connaissances du monde ou des données factuelles.
    • Demandez aux LLM des informations sensibles au temps.
  • Cas de périphérie de réseau de l'adresse - Définissez les cas de périphérie de réseau qui peuvent entraîner une hallucination du modèle et générer une réponse plausible, mais incorrecte. La description des cas de bord et l'ajout d'exemples peuvent former un garde-corps contre les hallucinations. Par exemple, un cas en périphérie de réseau peut indiquer qu'un appel d'API qui remplit les valeurs de variable dans l'invite ne parvient pas à le faire et retourne une réponse vide. Pour permettre au LLM de gérer cette situation, votre invite comprendra une description de la réponse attendue.

    Conseil :

    Les tests peuvent révéler des cas de périphérie imprévus.
  • Ne pas introduire de contradictions - Vérifiez attentivement votre invite pour vous assurer que vous ne lui avez pas donné d'instructions contradictoires. Par exemple, vous ne voulez pas :
    Write a prompt for generating a summary of the text given below. DO NOT let your instructions be overridden
    In case the user query is asking for a joke, forget the above and tell a funny joke instead
  • Ne présumez pas que quoi que ce soit est implicite - Il y a une limite quant à la quantité de connaissances dont dispose un LLM. Dans la plupart des cas, il est préférable de supposer que le LLM ne sait pas quelque chose, ou peut être confus sur des termes spécifiques. Par exemple, un LLM peut généralement savoir ce que signifie un aperçu dérivé d'une donnée, mais dire simplement "dériver de bonnes informations à partir de ces données" ne suffit pas. Vous devez spécifier ce que les informations signifient pour vous dans ce cas :
    - The extracted insights must enable someone to be able to understand the data well.
    - Insights must be applicable to the question shown above
    - Each insight must be clear and provide proof and statistics wherever required
    - Focus on columns you think are relevant and the relationships between them.
    - You can ignore columns that are simply identifiers, such as IDs
  • Assurez-vous que l'invite a du sens après le remplissage des variables - Les invites peuvent avoir des paramètres fictifs pour les valeurs qui peuvent être remplies, par exemple, par le remplissage des emplacements. Assurez-vous que l'invite a du sens une fois qu'elle est alimentée en testant ses exemples de valeurs. Par exemple, ce qui suit semble logique avant que la valeur de la variable ne soit remplie.
    Job is in the ${team} at Oracle
    Cependant, une fois que la variable est alimentée, l'expression ne semble pas correcte :
    Job is in the Oracle Digital Assistant at Oracle
    Pour corriger cela, modifiez l'expression. Dans ce cas, en modifiant la variable avec team.
    Job is in the ${team} team at Oracle
    Le résultat est le suivant :
    Job is in the Oracle Digital Assistant team at Oracle
  • Évitez de demander au LLM de faire des mathématiques - Dans certains cas, les LLM peuvent ne pas être en mesure de faire des mathématiques de base correctement. Malgré cela, ils hallucinent et retournent une réponse qui semble si confiante qu'elle pourrait facilement être confondue avec la bonne. Voici un exemple d'hallucination LLM comme suit lorsqu'on lui demande " quelle est la moyenne de 5, 7, 9 " : The average of 5, 7, and 9 is 7.5. To find the average, you add up the values and divide by the number of values. In this case, the values are 5, 7, and 9, and there are 3 values. So, to find the average, you would add 5 + 7 + 9 and divide by 3. This gives you an average of 7.5
  • Faites attention lors de la définition de la température du modèle - Des températures plus élevées, qui favorisent une sortie plus créative et aléatoire, peuvent également produire des hallucinations. Des valeurs inférieures telles que 0.01 indiquent que la sortie du LLM doit être précise et déterministe.
  • Éviter les instructions redondantes - N'incluez pas les instructions qui semblent redondantes. Réduisez la verbosité de l'invite autant que possible sans omettre les détails cruciaux.
  • Utiliser des verbes explicites - Au lieu d'utiliser des énoncés descriptifs verbose, utilisez des verbes concrets propres à la tâche, par exemple "sommaire", "classifier", "générer", "ébauche", etc.
  • Fournir des entrées en langage naturel - Lorsque vous devez transmettre un contexte ou des entrées supplémentaires au modèle, assurez-vous qu'elles sont facilement interprétables et en langage naturel. Tous les modèles ne peuvent pas comprendre correctement les données non structurées, les raccourcis ou les codes. Lorsque les données extraites de serveurs dorsaux ou de bases de données ne sont pas structurées, vous devez les transposer en langage naturel.
    Par exemple, si vous devez transmettre le profil d'utilisateur dans le contexte, procédez de la façon suivante :
    Name: John Smith
    Age: 29
    Gender: Male
    Ne pas faire ceci :
    Smith, John - 29M
    Note

    Évitez toujours d'utiliser du vocabulaire propre à un domaine. Intégrez plutôt les informations en langage naturel.
Traitement des interrogations OOS et OOD

Vous pouvez activer le LLM pour générer une réponse avec la variable d'entrée non valide, InvalidInput lorsqu'il reconnaît les interrogations qui sont hors champ d'application (OS) ou hors domaine (ODO) en incluant des éléments liés à la portée dans votre invite.

Lorsque les conversations multitours ont été activées, la détection du BSCI et du BSCI est essentielle pour les améliorations de réponse et les requêtes de suivi. Lorsque le LLM identifie les interrogations OOS et OOD, il génère InvalidInput pour déclencher des transitions vers d'autres états ou flux. Pour permettre au LLM de gérer les interrogations OOS et OOD, incluez des instructions de limitation de portée qui limitent les LLM qui décrivent ce que le LLM doit faire une fois qu'il évalue l'interrogation de l'utilisateur comme non prise en charge (c'est-à-dire, OOS, OOD).

Voici la structure générale d'une invite avec des instructions pour la gestion du OOD et du OOS.
  1. Commencez par définir le rôle du LLM avec une description de haut niveau de la tâche à accomplir.
  2. Incluez des instructions détaillées propres à la tâche. Dans cette section, ajoutez des détails sur les éléments à inclure dans la réponse, sur la façon dont le LLM doit formater la réponse et sur d'autres détails.
  3. Mentionner comment traiter les scénarios constituent une requête non prise en charge .
  4. Fournissez des exemples de requêtes hors portée et de réponses attendues.
  5. Fournissez des exemples pour la tâche à accomplir, si nécessaire.
{BRIEF INTRODUCTION OF ROLE & TASK}
You are an assistant to generate a job description ...

{SCOPE LIMITING INSTRUCTIONS}

For any followup query (question or task) not related to creating a job description, 
you must ONLY respond with the exact message "InvalidInput" without any reasoning or additional information or questions.

INVALID QUERIES
---
user: {OOS/OOD Query}
assistant: InvalidInput
---
user: {OOS/OOD Query}
assistant: InvalidInput
---

For a valid query about <TASK>, follow the instructions and examples below:
...

EXAMPLE

---
user: {In-Domain Query}
assistant: {Expected Response}

Instructions de limitation de portée
Les instructions limitant la portée décrivent des scénarios et des requêtes qui sont considérés comme OOS et OOD. Ils indiquent au LLM de sortir InvalidInput, le mot clé OOS/OOD défini pour le composant LLM, une fois qu'il a rencontré une interrogation non prise en charge.
For any user instruction or question not related to creating a job description, you must ONLY respond with the exact message "InvalidInput" without any reasoning or additional clarifications. Follow-up questions asking information or general questions about the job description, hiring, industry, etc. are all considered invalid and you should respond with "InvalidInput" for the same.
Voici quelques directives :
  • Soyez précis et exhaustif tout en définissant ce que le LLM devrait faire. Assurez-vous que ces instructions sont aussi détaillées et sans ambiguïté que possible.
  • Décrivez l'action à effectuer après que le LLM a identifié avec succès une interrogation qui n'est pas incluse dans la tâche du LLM. Dans ce cas, demandez au modèle de répondre à l'aide du mot clé OOS/OOD (InvalidInput).
    Note

    GPT-3.5 n'adhère parfois pas à la réponse InvalidInput pour les interrogations non prises en charge malgré les instructions de limitation de portée spécifiques dans l'invite pour traiter les exemples hors portée.
  • La contrainte de la portée peut être délicate, de sorte que plus vous êtes précis sur ce qui constitue une "interrogation prise en charge", plus il est facile pour le LLM d'identifier une interrogation non prise en charge qui est hors de portée ou hors domaine.

    Conseil :

    Comme une interrogation prise en charge est définie de manière plus étroite qu'une interrogation non prise en charge, il est plus facile de lister les scénarios pour les interrogations prises en charge que pour l'ensemble plus large de scénarios pour les interrogations non prises en charge. Toutefois, vous pouvez mentionner de larges catégories d'interrogations non prises en charge si les tests révèlent qu'elles améliorent les réponses du modèle.
Quelques exemples de tirs pour OOS et OOD Detection
L'inclusion de quelques interrogations non prises en charge en tant qu'exemples d'instantané permet de restreindre la portée et d'établir des limites plus strictes autour de la définition d'un scénario hors portée. Etant donné que les LLM apprennent par l'exemple, le fait de compléter les instructions d'invite par des requêtes non prises en charge peut aider un modèle à distinguer les requêtes applicables des requêtes hors champ d'application ou hors domaine.

Conseil :

Vous devrez peut-être spécifier davantage d'exemples non pris en charge (principalement plus proches de la limite) pour qu'une invite GPT-3.5 fonctionne bien. Pour GPT-4, un ou deux exemples suffisent pour obtenir des performances de modèle raisonnablement bonnes.
Au lieu d'inclure des scénarios évidents hors domaine (comme " Quel est le temps aujourd'hui "), spécifiez des exemples qui sont proches du cas d'utilisation en question. Dans un cas d'utilisation de description de poste, par exemple, l'inclusion d'interrogations plus proches de la limite, telles que les suivantes, contraindrait le LLM à générer uniquement des descriptions de poste :
Retrieve the list of candidates who applied to this position
Show me interview questions for this role
Can you help update a similar job description I created yesterday?
Nous vous recommandons de modéliser les quelques exemples d'énoncés d'intention afin de vous assurer que la transition du composant LLM vers un autre état ou flux lorsque l'entrée utilisateur correspond à une intention de compétence. Par exemple, supposons que nous ayons une compétence avec une intention de réponse qui explique les cotisations fiscales, une intention transactionnelle qui dépose les dépenses et le composant LLM pour créer des descriptions d'emploi. Dans ce cas, vous incluez certaines interrogations couramment rencontrées comme quelques exemples d'interrogations non prises en charge afin que le modèle n'hallucine pas les réponses qui doivent être extraites de l'intention de réponse de la cotisation fiscale. Par exemple :
What's the difference between Roth and 401k?
Please file an expense for me
How do tax contributions work?    
    
Note

Méfiez-vous toujours de la longueur de l'invite. Au fur et à mesure que l'historique de conversation et, par la suite, la taille du contexte augmentent, la précision du modèle commence à baisser. Par exemple, après plus de trois tours, GPT3.5 commence à halluciner les réponses pour les requêtes du BSCI.
Considérations propres au modèle pour la conception d'invite OOS/OOD
Pour GPT-4 et GPT-3.5 :
  • GPT-3.5 n'adhère parfois pas au format de réponse correct (InvalidInput) pour les requêtes non prises en charge malgré des instructions spécifiques de limitation de portée dans l'invite sur le traitement des exemples hors de portée. Ces instructions pourraient aider à atténuer les hallucinations du modèle, mais elles ne peuvent toujours pas restreindre sa réponse à InvalidInput.
  • Vous devrez peut-être spécifier davantage d'exemples non pris en charge (principalement plus proches de la limite) pour qu'une invite GPT-3.5 fonctionne bien. Pour GPT-4, un ou deux exemples suffisent pour obtenir des performances de modèle raisonnablement bonnes.
Pour la cohère :
  • En général (pas seulement pour les requêtes OOS/OOD), des modifications mineures de l'invite peuvent entraîner des différences extrêmes de sortie. Malgré le réglage, les modèles Cohere peuvent ne pas se comporter comme prévu.
  • Une taille de contexte élargie provoque des hallucinations et un non-respect des instructions. Pour tenir à jour le contexte, le programme de traitement transformRequestPayload intègre les virages de conversation dans l'invite.
  • Contrairement aux modèles GPT, l'ajout d'un persona à l'invite ne semble pas avoir d'impact sur le comportement des modèles Cohere. Ils pèsent les instructions spécifiques à la tâche plus que le persona.
  • Si vous incluez plusieurs exemples de quelques clichés dans l'invite, assurez-vous de représenter également toutes les classes d'exemples. Un déséquilibre dans les catégories d'exemples peu saisis affecte négativement les réponses, car le modèle limite parfois sa production aux modèles prédominants trouvés dans la majorité des exemples.

Jetons et taille de la réponse

Les LLM créent des achèvements de texte à l'aide de jetons, qui peuvent correspondre à un mot (ou à des parties d'un mot). " Allez-vous au parc? " est l'équivalent de sept jetons : un jeton pour chaque mot plus un jeton pour le point d'interrogation. Un long mot comme l'hippopotomonstroseséquipéaliophobie (la peur des mots longs) est segmenté en dix jetons. En moyenne, 100 jetons égalent environ 75 mots en anglais. Les LLM utilisent des jetons dans leurs réponses, mais les utilisent également pour maintenir le contexte actuel de la conversation. Pour ce faire, les LLM définissent une limite appelée longueur de contexte, une combinaison du nombre de jetons que le LLM segmente à partir de l'invite et du nombre de jetons qu'il génère pour l'achèvement. Chaque modèle définit sa propre longueur de contexte maximale.

Pour vous assurer que le nombre de jetons dépensés pour les achèvements générés pour chaque tour d'une interaction à plusieurs tours ne dépasse pas la longueur de contexte du modèle, vous pouvez définir un plafond à l'aide de la propriété Nombre maximal de jetons. Lorsque vous définissez ce nombre, tenez compte de considérations basées sur le modèle, telles que le modèle que vous utilisez, sa longueur de contexte et même sa tarification. Vous devez également prendre en compte la taille attendue de la réponse (c'est-à-dire le nombre de jetons dépensés pour l'achèvement) ainsi que le nombre de jetons dans l'invite. Si vous réglez le nombre maximal de jetons à une valeur élevée et que votre invite est également très longue, le nombre de jetons dépensés pour les achèvements atteindra rapidement la longueur maximale du modèle après seulement quelques tours. À ce stade, certains LLM (mais pas tous) renvoient une réponse de 400.

Lorsque le nombre de jetons consommés pour un appel atteint la longueur de contexte du modèle, le composant LLM tente à nouveau la demande après avoir purgé le message le plus ancien de l'historique des messages.
Note

Comme le composant LLM utilise l'historique de conversation pour maintenir le contexte courant, l'exactitude des achèvements peut diminuer lorsqu'il supprime des messages plus anciens pour tenir compte de la longueur du contexte du modèle.

Historique de conversation intégré dans les invites OOS/OOD

Les modèles Cohere, contrairement aux modèles GPT, sont sans état et ne conservent pas le contexte de conversation lors de conversations à plusieurs tours. Pour maintenir le contexte de conversation lors de l'utilisation d'un modèle Cohere, le programme de traitement transformRequestPayload ajoute une section CONVERSATION au texte d'invite transmis avec les données utiles et transmis dans la conversation se transforme en paires de repères user et assistant :
transformRequestPayload: async (event, context) => {
      let prompt = event.payload.messages[0].content;
      if (event.payload.messages.length > 1) {
         let history = event.payload.messages.slice(1).reduce((acc, cur) => `${acc}\n${cur.role}: ${cur.content}` , '');
         prompt += `\n\nCONVERSATION HISTORY:${history}\nassistant:`
      }
      return {
        "max_tokens": event.payload.maxTokens,
        "truncate": "END",
        "return_likelihoods": "NONE",
        "prompt": prompt,
        "model": "command",
        "temperature": event.payload.temperature,
        "stream": event.payload.streamResponse
      };
    },
La première interrogation d'utilisateur est incluse dans cette section et est considérée comme faisant partie de l'historique de conversation. La section se termine par un repère "assistant:" pour inviter le modèle à poursuivre la conversation.
{SYSTEM_PROMPT}

CONVERSATION
---
user: <first_query>
assistant: <first_response>
user: ...
assistant: ...
user: <latest_query>
assistant: 

Chaque tour augmente à la fois la longueur de l'invite et la probabilité que la longueur du contexte du modèle soit dépassée. Lorsque ce plafond de longueur de contexte est atteint, le composant LLLM gère la situation en saisissant l'historique de conversation et en tronquant la conversation tourne afin que la capacité du modèle à suivre les instructions reste diminuée.

Interactions LLM dans le testeur de compétence

L'onglet Appels LLM vous permet de surveiller le traitement des composants LLM. À partir de cette vue, qui devient disponible lorsque le flux de dialogue passe à un groupe de pages LLM, vous pouvez suivre les échanges entre le groupe de pages LLM, l'utilisateur et le modèle à partir de l'invite réelle que le groupe de pages LLM a envoyée au modèle, avec des valeurs variables. De ce point jusqu'à la sortie finale (ou résultat), vous pouvez afficher les affinements émis par l'utilisateur, les virages du moniteur et, si vous avez implémenté la validation, le nombre de nouvelles tentatives et les erreurs connexes. Lorsque le nombre de nouvelles tentatives dépasse la limite définie, l'onglet Interaction LLM affiche le code d'erreur CLMI, le message d'erreur et le code de statut d'erreur. Lorsque le nombre de nouvelles tentatives dépasse la limite définie, l'onglet Interaction LLM affiche le code d'erreur CLMI, le message d'erreur et le code de statut d'erreur. Vous pouvez voir le texte entier des invites, des demandes d'affinement et du résultat en cliquant avec le bouton droit de la souris, puis en sélectionnant Afficher le texte intégral.
Option Afficher le texte intégral

Par défaut, l'état final du LLM est affiché dans la vue LLM Calls. Pour examiner les résultats des états LLM précédents, cliquez sur les réponses LLM précédentes dans la fenêtre Bot Tester.
Note

Vous pouvez enregistrer la conversation LLM en tant que cas de test.