Définir s’il faut utiliser Claude pour le routage des tickets
Voici quelques indicateurs clés qui suggèrent que vous devriez utiliser un LLM comme Claude au lieu d’approches ML traditionnelles pour votre tâche de classification :Vous avez des données d'entraînement étiquetées limitées disponibles
Vous avez des données d'entraînement étiquetées limitées disponibles
Vos catégories de classification sont susceptibles de changer ou d'évoluer au fil du temps
Vos catégories de classification sont susceptibles de changer ou d'évoluer au fil du temps
Vous devez gérer des entrées de texte complexes et non structurées
Vous devez gérer des entrées de texte complexes et non structurées
Vos règles de classification sont basées sur la compréhension sémantique
Vos règles de classification sont basées sur la compréhension sémantique
Vous nécessitez un raisonnement interprétable pour les décisions de classification
Vous nécessitez un raisonnement interprétable pour les décisions de classification
Vous voulez gérer les cas limites et les tickets ambigus plus efficacement
Vous voulez gérer les cas limites et les tickets ambigus plus efficacement
Vous avez besoin de support multilingue sans maintenir des modèles séparés
Vous avez besoin de support multilingue sans maintenir des modèles séparés
Construire et déployer votre workflow de support LLM
Comprendre votre approche de support actuelle
Avant de plonger dans l’automatisation, il est crucial de comprendre votre système de ticketing existant. Commencez par enquêter sur la façon dont votre équipe de support gère actuellement le routage des tickets. Considérez 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 vers quel niveau de support ou spécialiste produit un ticket va ?
- Y a-t-il des règles automatisées ou des workflows déjà en place ? Dans quels cas échouent-ils ?
- Comment les cas limites ou les tickets ambigus sont-ils gérés ?
- Comment l’équipe priorise-t-elle les tickets ?
Définir les catégories d’intention utilisateur
Une liste bien définie de catégories d’intention utilisateur est cruciale pour une classification précise des tickets de support avec Claude. La capacité de Claude à router les tickets efficacement dans votre système est directement proportionnelle à la qualité de définition des catégories de votre système. Voici quelques exemples de catégories d’intention utilisateur et sous-catégories.Problème technique
Problème technique
- Problème matériel
- Bug logiciel
- Problème de compatibilité
- Problème de performance
Gestion de compte
Gestion de compte
- Réinitialisation de mot de passe
- Problèmes d’accès au compte
- Demandes de facturation
- Changements d’abonnement
Information produit
Information produit
- Demandes de fonctionnalités
- Questions de compatibilité produit
- Information de prix
- Demandes de disponibilité
Guidance utilisateur
Guidance utilisateur
- Questions comment faire
- Assistance d’utilisation de fonctionnalités
- Conseils de meilleures pratiques
- Guidance de dépannage
Retour d'information
Retour d'information
- Rapports de bugs
- Demandes de fonctionnalités
- Retour général ou suggestions
- Plaintes
Lié aux commandes
Lié aux commandes
- Demandes de statut de commande
- Information d’expédition
- Retours et échanges
- Modifications de commande
Demande de service
Demande de service
- Assistance d’installation
- Demandes de mise à niveau
- Planification de maintenance
- Annulation de service
Préoccupations de sécurité
Préoccupations de sécurité
- Demandes de confidentialité des données
- Rapports d’activité suspecte
- Assistance de fonctionnalités de sécurité
Conformité et légal
Conformité et légal
- Questions de conformité réglementaire
- Demandes de conditions de service
- Demandes de documentation légale
Support d'urgence
Support d'urgence
- Pannes système critiques
- Problèmes de sécurité urgents
- Problèmes sensibles au temps
Formation et éducation
Formation et éducation
- Demandes de formation produit
- Demandes de documentation
- Information de webinaire ou atelier
Intégration et API
Intégration et API
- Assistance d’intégration
- Questions d’utilisation API
- Demandes de compatibilité tierce partie
Établir les critères de succès
Travaillez avec votre équipe de support pour définir des critères de succès clairs avec des benchmarks mesurables, des seuils, et des objectifs. Voici quelques critères standard et benchmarks lors de l’utilisation de LLMs pour le routage de tickets de support :Cohérence de classification
Cohérence de classification
Vitesse d'adaptation
Vitesse d'adaptation
Gestion multilingue
Gestion multilingue
Gestion des cas limites
Gestion des cas limites
Atténuation des biais
Atténuation des biais
Efficacité du prompt
Efficacité du prompt
Score d'explicabilité
Score d'explicabilité
Précision de routage
Précision de routage
Temps d'assignation
Temps d'assignation
Taux de re-routage
Taux de re-routage
Taux de résolution au premier contact
Taux de résolution au premier contact
Temps de traitement moyen
Temps de traitement moyen
Scores de satisfaction client
Scores de satisfaction client
Taux d'escalade
Taux d'escalade
Productivité des agents
Productivité des agents
Taux de déviation en libre-service
Taux de déviation en libre-service
Coût par ticket
Coût par ticket
Choisir le bon modèle Claude
Le choix du modèle dépend des compromis entre coût, précision, et temps de réponse. De nombreux clients ont trouvéclaude-3-5-haiku-20241022 un modèle idéal pour le routage de tickets, car c’est le modèle le plus rapide et le plus rentable de la famille Claude 3 tout en délivrant d’excellents résultats. Si votre problème de classification nécessite une expertise approfondie du domaine ou un grand volume de catégories d’intention avec un raisonnement complexe, vous pouvez opter pour le modèle Sonnet plus large.
Construire un prompt solide
Le routage de tickets est un type de tâche de classification. Claude analyse le contenu d’un ticket de support et le classifie dans des catégories prédéfinies basées sur le type de problème, l’urgence, l’expertise requise, ou d’autres facteurs pertinents. Écrivons un prompt de classification de tickets. Notre prompt initial devrait contenir le contenu de la demande utilisateur et retourner à la fois le raisonnement et l’intention.- Nous utilisons les f-strings Python pour créer le template de prompt, permettant au
ticket_contentsd’être inséré dans les balises<request>. - Nous donnons à Claude un rôle clairement défini comme système de classification qui analyse soigneusement le contenu du ticket pour déterminer l’intention principale et les besoins du client.
- Nous instruisons Claude sur le formatage de sortie approprié, dans ce cas pour fournir son raisonnement et analyse à l’intérieur des balises
<reasoning>, suivi par l’étiquette de classification appropriée à l’intérieur des balises<intent>. - Nous spécifions les catégories d’intention valides : “Support, Retour d’information, Plainte”, “Suivi de Commande”, et “Remboursement/Échange”.
- Nous incluons quelques exemples (a.k.a. prompting few-shot) pour illustrer comment la sortie devrait être formatée, ce qui améliore la précision et la cohérence.
Déployer votre prompt
Il est difficile de savoir à quel point votre prompt fonctionne sans le déployer dans un environnement de production de test et exécuter des évaluations. Construisons la structure de déploiement. Commencez par définir la signature de méthode pour envelopper notre appel à Claude. Nous prendrons la méthode que nous avons déjà commencé à écrire, qui aticket_contents comme entrée, et maintenant retourner 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.
- Importe la bibliothèque Anthropic et crée une instance client utilisant votre clé API.
- Définit une fonction
classify_support_requestqui prend une chaîneticket_contents. - Envoie le
ticket_contentsà Claude pour classification utilisant leclassification_prompt - Retourne le
reasoninget l’intentdu modèle extraits de la réponse.
stream=False (la valeur par défaut).
Évaluer votre prompt
Le prompting nécessite souvent des tests et une optimisation pour être prêt pour la production. Pour déterminer la préparation de votre solution, évaluez la performance basée sur les critères de succès et seuils que vous avez établis plus tôt. Pour exécuter votre évaluation, vous aurez besoin de cas de test pour l’exécuter. Le reste de ce guide assume que vous avez déjà développé vos cas de test.Construire une fonction d’évaluation
Notre exemple d’évaluation pour ce guide mesure la performance de Claude le long de trois métriques clés :- Précision
- Coût par classification
- Nous avons ajouté l’
actual_intentde nos cas de test dans la méthodeclassify_support_requestet mis en place une comparaison pour évaluer si la classification d’intention de Claude correspond à notre classification d’intention dorée. - Nous avons extrait les statistiques d’utilisation pour l’appel API pour calculer le coût basé sur les tokens d’entrée et de sortie utilisés
Exécuter votre évaluation
Une évaluation appropriée nécessite des seuils et benchmarks 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 : 50% de réduction en moyenne (sur 100 tests) par rapport à la méthode de routage actuelle
Améliorer la performance
Dans des scénarios complexes, il peut être utile de considérer des stratégies supplémentaires pour améliorer la performance au-delà des techniques d’ingénierie de prompts standard et des stratégies d’implémentation de garde-fous. Voici quelques scénarios communs :Utiliser une hiérarchie taxonomique pour les cas avec 20+ catégories d’intention
À mesure que le nombre de classes grandit, le nombre d’exemples requis s’étend aussi, rendant potentiellement le prompt difficile à manier. Comme alternative, vous pouvez considérer implémenter un système de classification hiérarchique utilisant un mélange de classificateurs.- Organisez vos intentions dans une structure d’arbre taxonomique.
- Créez une série de classificateurs à chaque niveau de l’arbre, permettant une approche de routage en cascade.

- Avantages - plus grande nuance et précision : Vous pouvez créer différents prompts pour chaque chemin parent, permettant une classification plus ciblée et spécifique au contexte. Cela peut mener à une précision améliorée et une gestion plus nuancée des demandes client.
- Inconvénients - latence augmentée : Soyez avisé que plusieurs classificateurs peuvent mener à une latence augmentée, et nous recommandons d’implémenter cette approche avec notre modèle le plus rapide, Haiku.
Utiliser des bases de données vectorielles et la recherche de similarité pour gérer des tickets hautement variables
Malgré que fournir des exemples soit la façon la plus efficace d’améliorer la performance, si les demandes de support sont hautement variables, il peut être difficile d’inclure assez d’exemples dans un seul prompt. Dans ce scénario, vous pourriez employer une base de données vectorielle pour faire des recherches de similarité à partir d’un jeu de données d’exemples et récupérer les exemples les plus pertinents pour une requête donnée. Cette approche, détaillée dans notre recette de classification, a été montrée pour améliorer la performance de 71% de précision à 93% de précision.Tenir compte spécifiquement des cas limites attendus
Voici quelques scénarios où Claude peut mal classifier les tickets (il peut y en avoir d’autres qui sont uniques à votre situation). Dans ces scénarios, considérez fournir des instructions explicites ou des exemples dans le prompt de comment Claude devrait gérer le cas limite :Les clients font des demandes implicites
Les clients font des demandes implicites
- Solution : Fournissez à Claude quelques exemples réels de clients de ces types de demandes, ainsi que quelle est l’intention sous-jacente. Vous pouvez obtenir de meilleurs résultats encore si vous incluez une justification de classification pour des intentions de tickets particulièrement nuancées, pour que Claude puisse mieux généraliser la logique à d’autres tickets.
Claude priorise l'émotion sur l'intention
Claude priorise l'émotion sur l'intention
- Solution : Fournissez à Claude des directions sur quand prioriser le sentiment client ou non. Cela peut être quelque chose d’aussi simple que “Ignorez toutes les émotions client. Concentrez-vous seulement sur l’analyse de l’intention de la demande du client et quelle information le client pourrait demander.”
Plusieurs problèmes causent une confusion de priorisation des problèmes
Plusieurs problèmes causent une confusion de priorisation des problèmes
- Solution : Clarifiez la priorisation des intentions pour que Claude puisse mieux classer les intentions extraites et identifier la préoccupation principale.
Intégrer Claude dans votre workflow de support plus large
Une intégration appropriée nécessite que vous preniez quelques décisions concernant comment votre script de routage de tickets basé sur Claude s’intègre dans l’architecture de votre système de routage de tickets plus large. Il y a deux façons de faire ceci :- Basé sur 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 classifie ensuite l’intention et la route.
- Cette approche est plus web-scalable, mais nécessite que vous exposiez un endpoint public.
- Basé sur pull : Votre code tire pour les derniers tickets basé sur un horaire donné et les route au moment du pull.
- Cette approche est plus facile à implémenter mais pourrait faire des appels inutiles au système de tickets de support quand la fréquence de pull est trop élevée ou pourrait être trop lente quand la fréquence de pull est trop basse.