Retour d’expérience sur l’escalade avec des LLM : tests et ajustements

Cette semaine, j'ai travaillé sur des agents de réponse automatique pour répondre à des questions générales sur nos services et les...

Retour d'expérience sur l'escalade avec des LLM : tests et ajustements

Cette semaine, j'ai travaillé sur des agents de réponse automatique pour répondre à des questions générales sur nos services et les problèmes rencontrés dans l'entreprise. L'objectif est de rendre possible l'accès à de l'information en instantané sans pour autant prendre le risque de raconter n'importe quoi.

C'est dans ce cadre que j'ai développé un mécanisme d'escalade. C'est à dire le fait que l'agent qui produit une réponse automatique arrive à tirer la sonnette d'alarme pour dire de lui même qu'il ne peut pas répondre.

Je ne vais pas rentrer dans le design de nos systèmes multi-agent aujourd'hui, mais il faut assumer qu'on séquence l'utilisation de différents modèles pour créer la réponse la plus adaptée à l'utilisateur.

Méthode #1 : tout dans un seul prompt

Au départ, j'ai voulu tester une approche simple : tout gérer dans un seul prompt. Le modèle générait la réponse et je faisais en même temps une vérification rapide de sa qualité. Quelque chose comme, "write an answer and if no answer seems relevant for reason x or y suggests an escalation"

Le problème, c'est que cette méthode n'était pas optimale. Le modèle avait trop de choses à gérer en même temps : répondre à la question, intégrer le contexte de documents suite à une étape de retrieval et vérifier la qualité de la réponse. Cela a donnée de bons résultats, de moins bons. Disons qu'on s'intéressait pas forcément à l'escalade à ce moment là.

Mais le sujet de l'escalade est devenu important et il fallait plus de marge de manoeuvre.

Méthode #2 : découper, mais des réponses imprécises

Pour adapter cela, j'ai testé une approche plus stricte où je voulais découper le processus. L'idée était de s'assurer que le modèle couvrait bien le sujet avant même de générer la réponse. Si la question n'était pas suffisamment couverte par les documents, je renvoyais la demande à un humain.

Elle avait l'avantage (trop tôt) de sembler plus économe en ressources car elle évite la génération d'une réponse.

Mais cette méthode a posé un nouveau problème : le modèle a commencé à générer des réponses imprécises ou incomplètes. Par exemple, si la langue de la question ne correspondait pas à celle des documents fournis, ou si les documents ne couvraient pas le sujet, le modèle refusait strictement de proposer une réponse pour escalader.

C'était honnêtement une vrai tête de mule. Difficile à calibrer.

J'ai pas mal douté qu'il faille revenir sur le découpage, mais en expliquant le problème à une collègue, j'ai compris que je faisais les choses de travers.

Méthode #3 : générer d'abord, évaluer ensuite

J'ai donc pris un autre chemin. Plutôt que de bloquer tout en amont, j'ai laissé le modèle générer sa réponse, pour finalement évaluer la réponse ensuite. L'évaluation est bien plus efficace, et c'est flagrant ! En générant d'abord, on donne de la liberté au modèle. Ensuite, on peut juger de la pertinence de la réponse, et si nécessaire, activer l'escalade vers un humain. Cela permet de mieux contrôler le processus sans sacrifier la réactivité.

Même si cette approche semble plus efficace pour l'instant, il faut encore la tester à l'échelle pour voir si elle tient la route dans des conditions réelles. Ce qui fait vraiment la différence, c'est de laisser d'abord les agents essayer de répondre. L'évaluation finale se fait après coup, pour juger si la réponse mérite d'être désactivée et envoyée à un humain. Cette méthode permet de garder de la souplesse tout en filtrant les erreurs importantes au dernier moment, sans trop de rigidité en amont.

Conclusion

En bref, laisser le modèle répondre d'abord et évaluer ensuite semble être la bonne approche. Ça offre plus de flexibilité et permet un meilleur contrôle des escalades. Il reste à tester à grande échelle, mais les premiers résultats sont prometteurs.

Texte corrigé avec chatgpt.com