​
Définir s’il faut utiliser Claude pour le routage des tickets

Voici quelques indicateurs clés qui indiquent que vous devriez utiliser un LLM comme Claude au lieu des approches ML traditionnelles pour votre tâche de classification :

​
Construire et déployer votre workflow de support LLM

​
Comprendre votre approche de support actuelle

Avant de vous lancer dans l’automatisation, il est crucial de comprendre votre système de tickets existant. Commencez par étudier la façon dont votre équipe de support gère actuellement le routage des tickets.

Posez-vous des questions comme :

  • Quels critères sont utilisés pour déterminer quel SLA/offre de service est appliqué ?
  • Le routage des tickets est-il utilisé pour déterminer à quel niveau de support ou à quel spécialiste produit un ticket est attribué ?
  • Existe-t-il déjà des règles ou des workflows automatisés ? Dans quels cas échouent-ils ?
  • Comment les cas limites ou les tickets ambigus sont-ils traités ?
  • Comment l’équipe priorise-t-elle les tickets ?

Plus vous en saurez sur la façon dont les humains gèrent certains cas, mieux vous pourrez travailler avec Claude pour effectuer la tâche.

​
Définir les catégories d’intention des utilisateurs

Une liste bien définie de catégories d’intention des utilisateurs est cruciale pour une classification précise des tickets de support avec Claude. La capacité de Claude à acheminer efficacement les tickets au sein de votre système est directement proportionnelle à la qualité de la définition des catégories de votre système.

Voici quelques exemples de catégories et de sous-catégories d’intention des utilisateurs.

Outre l’intention, le routage et la priorisation des tickets peuvent également être influencés par d’autres facteurs tels que l’urgence, le type de client, les SLA ou la langue. Veillez à prendre en compte d’autres critères de routage lors de la construction de votre système de routage automatisé.

​
Établir des critères de réussite

Collaborez avec votre équipe de support pour définir des critères de réussite clairs avec des repères, des seuils et des objectifs mesurables.

Voici quelques critères et repères standard lorsque vous utilisez des LLM pour le routage des tickets de support :

Voici quelques critères de réussite courants qui peuvent être utiles, que l’on utilise ou non un LLM :

​
Choisir le bon modèle Claude

Le choix du modèle dépend des compromis entre le coût, la précision et le temps de réponse.

De nombreux clients ont trouvé que claude-3-haiku-20240307 est un modèle idéal pour le routage des tickets, car il est le modèle le plus rapide et le plus rentable de la famille Claude 3 tout en offrant d’excellents résultats. Si votre problème de classification nécessite une expertise approfondie du sujet ou un grand volume de catégories d’intention avec un raisonnement complexe, vous pouvez opter pour le modèle Sonnet plus grand.

​
Construire une invite forte

Le routage des tickets est un type de tâche de classification. Claude analyse le contenu d’un ticket de support et le classe dans des catégories prédéfinies en fonction du type de problème, de l’urgence, de l’expertise requise ou d’autres facteurs pertinents.

Écrivons une invite de classification des tickets. Notre invite initiale doit contenir le contenu de la demande de l’utilisateur et renvoyer à la fois le raisonnement et l’intention.

Essayez le générateur d’invites sur la console Anthropic pour que Claude vous écrive un premier brouillon.

Voici un exemple d’invite de classification de routage des tickets :

def classify_support_request(ticket_contents):
    # Définir l'invite pour la tâche de classification
    classification_prompt = f"""Vous agirez en tant que système de classification des tickets de support client. Votre tâche consiste à analyser les demandes de support client et à produire l'intention de classification appropriée pour chaque demande, ainsi que votre raisonnement. 

        Voici la demande de support client que vous devez classer :

        <request>{ticket_contents}</request>

        Veuillez analyser attentivement la demande ci-dessus pour déterminer l'intention principale du client et ses besoins. Considérez ce que le client demande et ce qui le préoccupe.

        Tout d'abord, écrivez votre raisonnement et votre analyse sur la façon de classer cette demande à l'intérieur des balises <reasoning>.

        Ensuite, produisez l'étiquette de classification appropriée pour la demande à l'intérieur d'une balise <intent>. Les intentions valides sont :
        <intents>
        <intent>Support, Commentaires, Plainte</intent>
        <intent>Suivi de commande</intent>
        <intent>Remboursement/Échange</intent>
        </intents>

        Une demande ne peut avoir QU'UNE SEULE intention applicable. N'incluez que l'intention la plus applicable à la demande.

        Par exemple, considérez la demande suivante :
        <request>Bonjour ! J'ai fait installer la fibre Internet haut débit samedi et mon installateur, Kevin, a été absolument fantastique ! Où puis-je envoyer mon avis positif ? Merci de votre aide !</request>

        Voici un exemple de la façon dont votre sortie doit être formatée (pour l'exemple de demande ci-dessus) :
        <reasoning>L'utilisateur cherche des informations pour laisser un commentaire positif.</reasoning>
        <intent>Support, Commentaires, Plainte</intent>

        Voici quelques autres exemples :
        <examples>
        <example 2>
        Exemple 2 Entrée :
        <request>Je voulais vous écrire pour vous remercier personnellement de la compassion dont vous avez fait preuve envers ma famille lors des funérailles de mon père ce week-end. Votre personnel a été si prévenant et serviable tout au long de ce processus ; cela nous a vraiment enlevé un poids des épaules. Les brochures de visite étaient magnifiques. Nous n'oublierons jamais la gentillesse dont vous avez fait preuve à notre égard et nous vous sommes très reconnaissants du bon déroulement des procédures. Merci encore, Amarantha Hill au nom de la famille Hill.</request>

        Exemple 2 Sortie :
        <reasoning>L'utilisateur laisse un avis positif sur son expérience.</reasoning>
        <intent>Support, Commentaires, Plainte</intent>
        </example 2>
        <example 3>

        ...

        </example 8>
        <example 9>
        Exemple 9 Entrée :
        <request>Votre site web n'arrête pas d'envoyer des pop-ups publicitaires qui bloquent tout l'écran. Il m'a fallu vingt minutes rien que pour trouver le numéro de téléphone pour appeler et me plaindre. Comment puis-je accéder à mes informations de compte avec tous ces pop-ups ? Pouvez-vous accéder à mon compte pour moi, puisque votre site web est en panne ? J'ai besoin de savoir quelle est l'adresse enregistrée.</request>

        Exemple 9 Sortie :
        <reasoning>L'utilisateur demande de l'aide pour accéder aux informations de son compte web.</reasoning>
        <intent>Support, Commentaires, Plainte</intent>
        </example 9>

        N'oubliez pas d'inclure toujours votre raisonnement de classification avant votre sortie d'intention réelle. Le raisonnement doit être encadré par des balises <reasoning> et l'intention par des balises <intent>. Ne renvoyez que le raisonnement et l'intention.
        """

Décomposons les éléments clés de cette invite :

  • Nous utilisons les f-strings de Python pour créer le modèle d’invite, permettant d’insérer ticket_contents dans les balises <request>.
  • Nous donnons à Claude un rôle clairement défini en tant que système de classification qui analyse attentivement le contenu du ticket pour déterminer l’intention principale et les besoins du client.
  • Nous donnons des instructions à Claude sur le formatage correct de la sortie, dans ce cas pour fournir son raisonnement et son analyse à l’intérieur des balises <reasoning>, suivis de l’étiquette de classification appropriée à l’intérieur des balises <intent>.
  • Nous spécifions les catégories d’intention valides : “Support, Commentaires, Plainte”, “Suivi de commande” et “Remboursement/Échange”.
  • Nous incluons quelques exemples (une invite à quelques coups) pour illustrer comment la sortie doit être formatée, ce qui améliore la précision et la cohérence.

La raison pour laquelle nous voulons que Claude divise sa réponse en différentes sections de balises XML est que nous pouvons utiliser des expressions régulières pour extraire séparément le raisonnement et l’intention de la sortie. Cela nous permet de créer des étapes suivantes ciblées dans le flux de travail de routage des tickets, comme l’utilisation de la seule intention pour décider à quelle personne acheminer le ticket.

​
Déployer votre invite

Il est difficile de savoir à quel point votre invite fonctionne sans la déployer dans un environnement de production de test et effectuer des évaluations.

Construisons la structure de déploiement. Commencez par définir la signature de la méthode pour envelopper notre appel à Claude. Nous prendrons la méthode que nous avons déjà commencé à écrire, qui a ticket_contents comme entrée, et nous renverrons maintenant un tuple de reasoning et intent comme sortie. Si vous avez une automatisation existante utilisant le ML traditionnel, vous voudrez suivre cette signature de méthode à la place.

import anthropic
import re

# Créer une instance du client API Anthropic
client = anthropic.Anthropic()

# Définir le modèle par défaut
DEFAULT_MODEL="claude-3-haiku-20240307"

def classify_support_request(ticket_contents):
    # Définir l'invite pour la tâche de classification
    classification_prompt = f"""Vous agirez en tant que système de classification des tickets de support client. 
        ...
        ... Le raisonnement doit être encadré par des balises <reasoning> et l'intention par des balises <intent>. Ne renvoyez que le raisonnement et l'intention.
        """
    # Envoyer l'invite à l'API pour classer la demande de support.
    message = client.messages.create(
        model=DEFAULT_MODEL,
        max_tokens=500,
        temperature=0,
        messages=[{"role": "user", "content": classification_prompt}],
        stream=False,
    )
    reasoning_and_intent = message.content[0].text

    # Utiliser la bibliothèque d'expressions régulières de Python pour extraire `reasoning`.
    reasoning_match = re.search(
        r"<reasoning>(.*?)</reasoning>", reasoning_and_intent, re.DOTALL
    )
    reasoning = reasoning_match.group(1).strip() if reasoning_match else ""

    # De même, extraire également `intent`.
    intent_match = re.search(r"<intent>(.*?)</intent>", reasoning_and_intent, re.DOTALL)
    intent = intent_match.group(1).strip() if intent_match else ""

    return reasoning, intent

Ce code :

  • Importe la bibliothèque Anthropic et crée une instance client en utilisant votre clé API.
  • Définit une fonction classify_support_request qui prend une chaîne ticket_contents.
  • Envoie ticket_contents à Claude pour classification en utilisant classification_prompt
  • Renvoie reasoning et intent du modèle extraits de la réponse.

Puisque nous devons attendre que l’ensemble du texte de raisonnement et d’intention soit généré avant l’analyse, nous définissons stream=False (la valeur par défaut).

​
Évaluer votre invite

L’invite nécessite souvent des tests et une optimisation pour être prête pour la production. Pour déterminer l’état de préparation de votre solution, évaluez les performances en fonction des critères de réussite et des seuils que vous avez établis précédemment.

Pour effectuer votre évaluation, vous aurez besoin de cas de test sur lesquels l’exécuter. Le reste de ce guide suppose que vous avez déjà développé vos cas de test.

​
Construire une fonction d’évaluation

Notre exemple d’évaluation pour ce guide mesure les performances de Claude selon trois métriques clés :

  • Précision
  • Coût par classification

Vous devrez peut-être évaluer Claude sur d’autres axes en fonction des facteurs qui sont importants pour vous.

Pour évaluer cela, nous devons d’abord modifier le script que nous avons écrit et ajouter une fonction pour comparer l’intention prédite avec l’intention réelle et calculer le pourcentage de prédictions correctes. Nous devons également ajouter des fonctionnalités de calcul des coûts et de mesure du temps.

import anthropic
import re

# Créer une instance du client API Anthropic
client = anthropic.Anthropic()

# Définir le modèle par défaut
DEFAULT_MODEL="claude-3-haiku-20240307"

def classify_support_request(request, actual_intent):
    # Définir l'invite pour la tâche de classification
    classification_prompt = f"""Vous agirez en tant que système de classification des tickets de support client. 
        ...
        ...Le raisonnement doit être encadré par des balises <reasoning> et l'intention par des balises <intent>. Ne renvoyez que le raisonnement et l'intention.
        """

    message = client.messages.create(
        model=DEFAULT_MODEL,
        max_tokens=500,
        temperature=0,
        messages=[{"role": "user", "content": classification_prompt}],
    )
    usage = message.usage  # Obtenir les statistiques d'utilisation pour l'appel API pour savoir combien de jetons d'entrée et de sortie ont été utilisés.
    reasoning_and_intent = message.content[0].text

    # Utiliser la bibliothèque d'expressions régulières de Python pour extraire `reasoning`.
    reasoning_match = re.search(
        r"<reasoning>(.*?)</reasoning>", reasoning_and_intent, re.DOTALL
    )
    reasoning = reasoning_match.group(1).strip() if reasoning_match else ""

    # De même, extraire également `intent`.
    intent_match = re.search(r"<intent>(.*?)</intent>", reasoning_and_intent, re.DOTALL)
    intent = intent_match.group(1).strip() if intent_match else ""

      # Vérifier si la prédiction du modèle est correcte.
    correct = actual_intent.strip() == intent.strip()

    # Renvoyer le raisonnement, l'intention, correct et l'utilisation.
    return reasoning, intent, correct, usage

Décomposons les modifications que nous avons apportées :

  • Nous avons ajouté actual_intent de nos cas de test dans la méthode classify_support_request et mis en place une comparaison pour évaluer si la classification d’intention de Claude correspond à notre classification d’intention de référence.
  • Nous avons extrait les statistiques d’utilisation pour l’appel API afin de calculer le coût en fonction des jetons d’entrée et de sortie utilisés

​
Exécuter votre évaluation

Une évaluation appropriée nécessite des seuils et des repères clairs pour déterminer ce qui est un bon résultat. Le script ci-dessus nous donnera les valeurs d’exécution pour la précision, le temps de réponse et le coût par classification, mais nous aurions encore besoin de seuils clairement établis. Par exemple :

  • Précision : 95 % (sur 100 tests)
  • Coût par classification : réduction de 50 % en moyenne (sur 100 tests) par rapport à la méthode de routage actuelle

Avoir ces seuils vous permet de déterminer rapidement et facilement à grande échelle, et avec un empirisme impartial, quelle méthode est la meilleure pour vous et quels changements pourraient être nécessaires pour mieux répondre à vos exigences.

​
Améliorer les performances

Dans des scénarios complexes, il peut être utile d’envisager des stratégies supplémentaires pour améliorer les performances au-delà des techniques standard d’ingénierie des invites et des stratégies de mise en œuvre des garde-fous. Voici quelques scénarios courants :

​
Utiliser une hiérarchie taxonomique pour les cas avec plus de 20 catégories d’intention

À mesure que le nombre de classes augmente, le nombre d’exemples requis augmente également, ce qui peut rendre l’invite peu maniable. Comme alternative, vous pouvez envisager de mettre en œuvre un système de classification hiérarchique utilisant un mélange de classificateurs.

  1. Organisez vos intentions dans une structure d’arbre taxonomique.
  2. Créez une série de classificateurs à chaque niveau de l’arbre, permettant une approche de routage en cascade.

Par exemple, vous pouvez avoir un classificateur de niveau supérieur qui catégorise largement les tickets en “Problèmes techniques”, “Questions de facturation” et “Demandes générales”. Chacune de ces catégories peut ensuite avoir son propre sous-classificateur pour affiner davantage la classification.

  • Avantages - plus grande nuance et précision : Vous pouvez créer différentes invites pour chaque chemin parent, permettant une classification plus ciblée et spécifique au contexte. Cela peut conduire à une précision améliorée et à un traitement plus nuancé des demandes des clients.

  • Inconvénients - latence accrue : Sachez que plusieurs classificateurs peuvent entraîner une latence accrue, et nous recommandons de mettre en œuvre cette approche avec notre modèle le plus rapide, Haiku.

​
Utiliser des bases de données vectorielles et la recherche par similarité pour gérer les tickets très variables

Bien que fournir des exemples soit le moyen le plus efficace d’améliorer les performances, si les demandes de support sont très variables, il peut être difficile d’inclure suffisamment d’exemples dans une seule invite.

Dans ce scénario, vous pourriez utiliser une base de données vectorielle pour effectuer des recherches de similarité à partir d’un ensemble de données d’exemples et récupérer les exemples les plus pertinents pour une requête donnée.

Cette approche, décrite en détail dans notre recette de classification, a montré une amélioration des performances de 71 % à 93 % de précision.

​
Tenir compte spécifiquement des cas limites attendus

Voici quelques scénarios où Claude peut mal classer les tickets (il peut y en avoir d’autres qui sont propres à votre situation). Dans ces scénarios, envisagez de fournir des instructions ou des exemples explicites dans l’invite sur la façon dont Claude doit gérer le cas limite :

​
Intégrer Claude dans votre flux de travail de support plus large

Une intégration appropriée nécessite que vous preniez des décisions concernant la façon dont votre script de routage des tickets basé sur Claude s’intègre dans l’architecture de votre système de routage des tickets plus large. Il y a deux façons de procéder :

  • Basé sur le push : Le système de tickets de support que vous utilisez (par exemple Zendesk) déclenche votre code en envoyant un événement webhook à votre service de routage, qui classe ensuite l’intention et la route.
    • Cette approche est plus évolutive sur le web, mais nécessite que vous exposiez un point de terminaison public.
  • Basé sur le pull : Votre code extrait les derniers tickets en fonction d’un calendrier donné et les achemine au moment de l’extraction.
    • Cette approche est plus facile à mettre en œuvre mais peut effectuer des appels inutiles au système de tickets de support lorsque la fréquence d’extraction est trop élevée ou peut être trop lente lorsque la fréquence d’extraction est trop faible.

Pour l’une ou l’autre de ces approches, vous devrez intégrer votre script dans un service. Le choix de l’approche dépend des API fournies par votre système de tickets de support.

Livre de recettes de classification

Visitez notre livre de recettes de classification pour plus d’exemples de code et des conseils détaillés d’évaluation.

Console Anthropic

Commencez à construire et à évaluer votre flux de travail sur la console Anthropic.

Modération de contenuModèles