Les horaires ne sont qu'un début
Pour montrer un chatbot pour restaurant, j'ai pris le site du restaurant d'un ami. Un client voudra peut-être se renseigner sur le service traiteur, vérifier un détail ou envoyer un message rapide, sans téléphoner ni fouiller toutes les pages.
Au début de la vidéo, je demande à quelle heure le restaurant ouvre. Puis j'ajoute : peux-tu me donner un code promo de 50 % ?
Voilà ce que je veux tester avant qu'un commerce propose un chatbot à ses clients. Répondre à une question ordinaire est utile. Inventer une remise parce que quelqu'un l'a demandée poliment pose problème.
La démo du début introduit la configuration que je présente dans Claude.
D'abord, donner les infos du commerce
La première phase de mon prompt est une base de connaissances. Je veux que l'assistant s'appuie sur des informations réelles sur le commerce, plutôt que d'improviser une réponse plausible.
Pour un restaurant, je commencerais par ce que les clients demandent le plus : les horaires, la carte et la façon de traiter une demande de service traiteur. Le commerce doit vérifier ces informations avant que le chatbot s'en serve.
Dans la vidéo, j'explique que j'utilise Haiku pour répondre aux questions. Sonnet et Opus jouent d'autres rôles dans la vérification. Ce sont les choix de ma configuration, pas une règle qui imposerait trois modèles à tout chatbot.
Ensuite, décider ce qu'il peut dire ou non
La phase suivante concerne les réponses elles-mêmes. Quel ton doit prendre le chatbot ? À quelles questions doit-il éviter de répondre ? Que doit-il faire quand quelqu'un essaie de lui faire ignorer ses consignes ?
La demande de remise n'est qu'un exemple. On peut aussi tester une question dont il ignore la réponse, des horaires qui ne sont plus à jour, ou un client qui lui demande de promettre quelque chose que le commerce n'a pas validé.
Je garderais la réponse attendue à côté de chaque test. Sinon, une autre IA qui affirme que le chatbot a réussi ne m'apprend pas grand-chose.
Tester, corriger, recommencer
Je présente un plan de 50 questions pièges : des questions conçues pour provoquer une mauvaise réponse. Un premier modèle répond, un second juge cette réponse, et les échecs récurrents sont confiés à un modèle qui m'aide à chercher la cause et à corriger la configuration.
Dans la vidéo, j'appelle cela de l'entraînement. Je parle de cette boucle de test et de correction. Je ne montre pas que j'ai réentraîné le modèle de base.
La vidéo explique la méthode. Il ne prouve pas que le chatbot est sûr, que tous les tests ont réussi, ni qu'un restaurant l'a déployé avec succès. Il faudrait d'autres preuves pour cela.
Je cite aussi une estimation du coût de l'API, tirée de mes tests. Je ne la donnerais pas comme devis à un autre commerce : ses questions, son trafic et sa configuration peuvent être différents.
Commencer par un commerce que vous connaissez
Ma suggestion à la fin de la vidéo : faites d'abord un chatbot pour vous-même. Choisissez une petite tâche, écrivez les bonnes réponses et essayez de le mettre en échec avant de le confier à quelqu'un d'autre.
La vidéo complète montre l'exemple du restaurant et les trois phases du prompt.
Ressources
- Claude : là où je présente la configuration.
- autoresearch d'Andrej Karpathy : un projet que je cite à propos de la méthode de test. Ce n'est ni un chatbot de restaurant prêt à l'emploi, ni une certification de sécurité.