Nous avons triplé l'efficacité du traitement des tickets d'après-vente des clients avec Claude 3, mais nous avons fait deux erreurs que nous n'aurions pas dû commettre.

Lors de la rédaction du rapport à la fin du Black Friday de la semaine dernière, trois développeurs de notre équipe SaaS pour le e-commerce en Asie du Sud-Est étaient stupéfaits en regardant les données du backend : les demandes d'assistance après vente, qui d'habitude nécessitaient trois jours de travail consécutif de toute l'équipe de service client, ont été automatiquement gérées pour la majeure partie cette année, entraînant une baisse de 42 % du nombre de plaintes des clients. Le seul changement majeur concerne le remplacement de l'ancienne logique de reconnaissance sémantique des demandes par Claude 3 Opus.

Pour ceux qui n’y ont jamais été confrontés, disons les choses clairement…

C'est le troisième modèle de langage large lancé par Anthropic en 2024. Les paramètres clés que nous avons utilisés sont très simples : avec une fenêtre de contexte d'environ 200 000 mots, nous avons traité des tickets d'après-vente contenant trois captures d'écran de produits, et le taux de précision était de 18 % plus élevé que celui des modèles de même niveau de paramètres que nous utilisions auparavant.

Pour une petite équipe comme la nôtre, ces trois avantages sont très précieux et concrets.

Le premier avantage est qu’il n’est plus nécessaire de procéder à une prétraitement multimodal séparément. Auparavant, pour les images de produits endommagés ou les captures d’écran de la logistique téléchargées par les utilisateurs, nous devions d’abord utiliser un modèle OCR pour convertir les images en texte, puis combiner ce texte avec les tickets d’assistance pour l’alimenter au grand modèle. La maintenance de cette seule chaîne de traitement occupait déjà la moitié des ressources du backend. Avec l’utilisation de Claude 3, nous pouvons maintenant transmettre directement les images et le texte ensemble, ce qui réduit les erreurs et les omissions dans la reconnaissance.

Le deuxième point est que le taux de rejet est si bas qu’il peut être considéré comme négligeable. Les modèles précédents avaient souvent du mal à comprendre les tickets rédigés par des utilisateurs de manière très confuse (par exemple, des textes mixtes en anglais et en langue locale, avec des abréviations en ligne), ce qui les obligeait à passer par une intervention manuelle. Nous avons constaté que pendant cette période, le pourcentage de cas nécessitant une intervention humaine s’élevait à 27 %, tandis qu’il n’est maintenant que de 4 %.

Le troisième point est que le coût des appels est bien plus bas que nous l'avions prévu. Nous payons en fonction de la consommation réelle ; le jour du pic des ventes du Black Friday, nous avons traité en moyenne 12 000 tickets par jour, pour un coût total de moins de 800 dollars, ce qui représente une économie de 90 % par rapport au coût d'embauche de 10 agents de service client temporaires.

Mais ne vous précipitez pas, les deux erreurs que nous avons commises suffisent à vous faire perdre une semaine entière en vain.

Le premier problème était celui de l'alignement des textes en plusieurs langues. La moitié de nos utilisateurs parlent indonésien, et nous avons lancé le service sans avoir effectué de ajustements préalables. Résultat : lorsque le modèle rencontrait des expressions argotiques locales, il interprétait fréquemment des phrases comme “le produit a été envoyé dans la mauvaise couleur” comme “l'utilisateur souhaite changer son adresse de livraison”, ce qui a entraîné 17 plaintes des clients en une semaine. Nous avons ensuite résolu le problème en fournissant 3000 exemples d'ordres de travail annotés en langue locale pour ajuster le modèle.

Le deuxième problème est la perte d'informations dans un contexte long. Si plus de 5 images sont jointes à une demande d'assistance, le modèle peut parfois omettre certaines d'entre elles. Par exemple, si l'utilisateur a pris deux photos montrant une emballage endommagé et le produit endommagé, le modèle ne reconnaîtra que le problème de l'emballage. Nous avons ensuite ajouté une règle de vérification simple : si le nombre d'images dépasse 3, nous faisons en sorte que le modèle affiche d'abord les résultats de la reconnaissance pour chaque image individuellement, puis les synthétise pour une analyse globale, et depuis, nous n'avons plus rencontré de problèmes.

Pour être honnête, tous les équipes ne sont pas adaptées à l'utilisation de...

Dans les situations où vous en avez besoin :

• Votre activité nécessite de gérer à la fois du texte, des images et de courts fichiers audio, et vous ne souhaitez pas mettre en place plusieurs chaînes de modèles distinctes.
• Vous avez des exigences élevées en termes de précision des résultats, notamment dans des scénarios où les erreurs peuvent entraîner de coûts importants, tels que le traitement des tickets ou l'examen des contrats.
• Votre équipe manque de personnel et n'a pas les ressources pour entretenir des chaînes de prétraitement de modèles complexes.

Situations où vous ne devriez pas gaspiller votre argent :

• Vous n’avez qu’à effectuer des tâches simples telles que des réponses à des questions basées sur des mots-clés ou la création de textes marketing, et de petits modèles peu coûteux suffisent pour cela.
• Vos données commerciales nécessitent une gestion stricte de la localisation de leur stockage, ce qui ne permet pas de les transmettre à des interfaces de modèles tiers.
• Votre volume de demandes est particulièrement faible, inférieur à 1000 par mois, et le coût de développement d'un nouveau modèle est supérieur aux bénéfices qu'il pourrait apporter.

Deux conseils pratiques pour ceux qui commencent pour la première fois

Le premier pas consiste à tester les scénarios marginaux pendant 7 jours avant de les intégrer dans le réseau principal. Au début, nous avons utilisé les tickets d’incidents des 3 derniers mois pour effectuer des tests hors ligne ; la précision atteignait plus de 95 % avant que nous ne mettions en œuvre 10 % du trafic en ligne, puis nous avons progressivement augmenté cette proportion jusqu’à couvrir tout le trafic, sans rencontrer de problèmes majeurs.

Le deuxième point est de ne pas choisir d'emblée la version la plus chère d'Opus. Nous avons constaté que, pour gérer des demandes d'assistance ordinaires sans images, la précision de la version Sonnet n'est pas très différente de celle d'Opus (à peine 2 % de différence) et le coût est seulement la moitié, ce qui est suffisant.

Pour conclure, voici une question que beaucoup de gens se posent : devrions-nous attendre le modèle de la prochaine génération ? Notre réponse est que si votre activité est actuellement limitée par des problèmes de traitement multimodal ou par une faible précision, il est préférable de l'utiliser dès maintenant. Après tout, le temps économisé grâce à son utilisation précoce est bien plus important que les frais de fonctionnement supplémentaires liés à l'attente du modèle suivant.