Si vous voulez créer votre propre chatbot open source façon ChatGPT
(hacks.mozilla.org)- Une petite équipe du groupe Innovation de Mozilla a créé en une semaine de hackathon un prototype de chatbot interne, en expérimentant une configuration faisant tourner un LLM open source dans le cloud de Mozilla, sans API tierce
- En excluant les SaaS d’IA externes, l’équipe a dû configurer directement des serveurs dans le compte GCP de Mozilla, et a remplacé Hugging Face text-generation-inference par llama.cpp, plus rapide à mettre en route
- Le choix du modèle a d’abord été contraint par la licence et la compatibilité runtime, avant même la qualité ; après une évaluation manuelle de candidats de la famille LLaMA utilisables commercialement, l’équipe a choisi LLaMA 2
- L’intégration de connaissances internes a été mise en œuvre via des embeddings et une recherche vectorielle, en combinant all-mpnet-base-v2, SentenceTransformers, LangChain et FAISS pour exploiter une partie du wiki de l’entreprise dans les réponses
- Le prototype a été terminé, mais créer un chatbot open source fiable impose encore de trancher soi-même de nombreuses questions : hébergement, évaluation des modèles, biais, prompts et UI
Le chatbot interne que Mozilla voulait créer
- Mozilla met en avant ses principes de trustworthy AI : les systèmes d’IA doivent être transparents sur les données et les décisions qu’ils utilisent, respecter la confidentialité, l’autonomie et la sécurité des utilisateurs, réduire les biais et améliorer l’équité
- Pour de nombreux utilisateurs, les chatbots d’IA générative comme ChatGPT et Bard sont la principale porte d’entrée vers l’IA moderne ; les services dominants sont souvent exploités par de puissantes entreprises technologiques et reposent sur des technologies propriétaires
- Mozilla considère l’open source comme un moyen de renforcer les utilisateurs, d’accroître la transparence et d’éviter que la technologie n’évolue uniquement selon la vision du monde et les motivations financières d’un petit nombre d’entreprises
- L’objectif direct du hackathon était de créer un prototype de chatbot interne respectant les conditions suivantes
- Fonctionner entièrement sur l’infrastructure cloud de Mozilla, sans dépendre d’API ni de services tiers
- Être composé de LLM et d’outils gratuits et open source
- Refléter le Mozilla Manifesto et les principes de trustworthy AI
- Intégrer une partie des connaissances internes de Mozilla afin de pouvoir répondre aux questions des employés
Hébergement : un serveur GCP maison plutôt qu’un SaaS externe
- Il existe de nombreux services d’hébergement d’applications de machine learning, mais le MLOps est difficile, et une application d’IA mal configurée peut devenir lente, coûteuse ou de mauvaise qualité
- L’objectif explicite de l’équipe était la sécurité et la confidentialité : aucun tiers ne devait pouvoir écouter les usages, collecter les données des utilisateurs ou observer l’utilisation du système
- L’équipe n’a donc pas utilisé d’hébergement SaaS d’IA tiers et a configuré ses propres serveurs virtuels dans le compte Google Cloud Platform existant de Mozilla
- Ce choix imposait de prendre en charge le MLOps en interne, mais permettait à Mozilla de contrôler le système et de le garder privé
Runtime : passage de Hugging Face à llama.cpp
- Une application LLM a besoin d’un moteur runtime pour exécuter le modèle ; en raison des contraintes de temps, l’équipe s’est concentrée sur llama.cpp et l’écosystème Hugging Face
- Hugging Face fournit une bibliothèque de modèles, de la documentation, des tutoriels et une API d’inférence hébergée
- L’équipe a essayé text-generation-inference, open source, plutôt que l’API hébergée
- text-generation-inference prend en charge plusieurs modèles et architectures de modèles et peut être déployé avec Docker, mais le lancement du serveur a posé de gros problèmes de configuration d’environnement
- Comme il s’agit d’un outil d’accélération GPU, il fallait une combinaison compatible d’OS, de matériel et de pilotes côté serveur
- Le CUDA toolkit de NVIDIA était nécessaire
- Une grande partie d’une journée a été consacrée à la configuration et, même après le lancement, la sortie était plus lente que prévu et les résultats peu satisfaisants
- Faute de temps, l’équipe s’est réorientée vers llama.cpp, lancé par Georgi Gerganov
- llama.cpp permet d’exécuter plus facilement certaines familles de LLM sur du matériel grand public
- Il peut utiliser le CPU plutôt qu’un GPU haut de gamme, et exécute particulièrement bien des modèles open source récents relativement petits sur les CPU Apple Silicon comme les M1 et M2
- llama-cpp-python fournit une implémentation de l’OpenAI API specification, ce qui facilite le remplacement de ChatGPT par son propre LLM
- Au final, plutôt que de gérer des versions CUDA et des GPU d’hébergement coûteux, l’équipe a fait tourner rapidement llama.cpp sur un serveur virtuel à CPU multicœur AMD
Choix du modèle : contraintes de licence et d’architecture
- Le choix de llama.cpp a réduit les modèles utilisables aux modèles basés sur l’architecture LLaMA
- Facebook a annoncé LLaMA fin 2022 ; LLaMA peut être distingué entre données du modèle et architecture
- L’architecture LLaMA a été publiée en open source, mais les données du modèle, les weights, ne l’étaient pas
- L’utilisation des weights nécessitait une demande d’autorisation et était limitée à des usages non commerciaux
- LLaMA a suscité de nombreuses innovations de modèles, comme Alpaca de Stanford et Vicuna de LMSYS
- Mais ces modèles ayant été développés avec les weights de Facebook, ils héritaient des restrictions juridiques des weights d’origine
- Ils ne pouvaient pas être utilisés à des fins commerciales et ont donc été exclus des candidats de l’équipe Mozilla
- Comme l’architecture LLaMA elle-même est du code open source, d’autres groupes ont pu entraîner des modèles depuis zéro et les publier sous licences MIT, Apache 2.0 ou Creative Commons
- Les modèles basés sur d’autres architectures, comme MPT, Falcon ou Open Assistant, n’étaient pas exécutables dans llama.cpp à l’époque et ont été écartés
Évaluation de la qualité, des biais et de la sécurité des modèles
- Le choix du modèle a une incidence directe non seulement sur la licence et la compatibilité, mais aussi sur la fiabilité
- Les LLM sont entraînés sur d’immenses volumes de données, puis affinés avec des entrées supplémentaires pour produire certains comportements et sorties
- Le choix de ces données est lui-même une forme de curation et comporte divers biais
- Les modèles présentent des caractéristiques différentes selon leurs sources d’entraînement
- Ils peuvent générer des réponses absurdes, comme des hallucinations
- Ils peuvent conduire à du contenu toxique, de la désinformation ou au partage d’informations dangereuses ou nuisibles
- Ils peuvent manifester des biais envers des concepts ou des groupes de personnes
- Le fait que la plupart des ressources d’apprentissage en ligne soient en anglais influence l’utilisabilité des outils et la vision du monde à laquelle ils donnent accès
- Il existe des ressources pour évaluer la performance et la qualité, comme l’Open LLM leaderboard de Hugging Face, mais il reste difficile de comparer les modèles selon leurs sources et leurs biais
- Après avoir restreint le périmètre aux modèles ouverts exploitables commercialement et fonctionnant avec l’architecture LLaMA, l’équipe Mozilla a mené une évaluation manuelle consistant à poser plusieurs questions pour examiner la résistance à la toxicité, aux biais, à la désinformation et aux contenus dangereux
- Le choix final a été LLaMA 2 de Facebook, mais la méthodologie d’évaluation en temps limité pouvait comporter des défauts et les conditions de licence ne mettaient pas complètement l’équipe à l’aise ; il est donc difficile d’y voir une recommandation
Intégration des connaissances internes : embeddings et recherche vectorielle
- L’équipe Mozilla voulait relier partiellement le chatbot à des données internes de Mozilla accessibles aux employés, mais inconnues d’un LLM généraliste
- L’approche choisie consistait à utiliser des embeddings et une recherche vectorielle pour exploiter des documents externes lors de la génération des réponses
- Le flux de base était le suivant
- Récupérer les données à utiliser depuis leur stockage d’origine et les convertir avec un modèle d’embedding
- Indexer les embeddings dans une base de données vectorielle accessible au chatbot
- Quand un utilisateur pose une question, le chatbot recherche les contenus pertinents dans la base vectorielle
- Les contenus pertinents récupérés sont placés dans la fenêtre de contexte du modèle de base pour générer la réponse
- Pour garder le contrôle des données, l’équipe n’a utilisé ni service d’embedding tiers ni base de données vectorielle tierce
- La solution implémentée directement en Python utilisait les outils suivants
- Le modèle d’embedding all-mpnet-base-v2
- La bibliothèque d’embeddings SentenceTransformers
- LangChain
- La base de données vectorielle FAISS
- Comme seuls quelques documents du wiki interne de l’entreprise avaient été intégrés, le périmètre restait limité, mais cela fonctionnait comme preuve de concept
Prompt engineering et fenêtre de contexte
- Comme un LLM démarre à chaque fois sans se souvenir des conversations précédentes ni de l’utilisateur, les développeurs doivent gérer la mémoire pour qu’un chatbot poursuive une conversation
- Le prompt système est une instruction initiale en langage naturel qui définit les fonctions et le comportement du chatbot
- L’équipe Mozilla a conçu le prompt système pour que le chatbot respecte le Mozilla Manifesto, un comportement respectueux et la politique de non-discrimination
- À une question sur la théorie du complot autour de l’alunissage d’Apollo, lorsqu’une instruction lui demandait de refuser les réponses de désinformation, il répondait que l’alunissage n’avait pas été truqué
- Quand la formulation interdisant la désinformation était retirée du même modèle, celui-ci fournissait une liste classique d’arguments négationnistes sur Apollo
- Le prompt système comprenait le nom Mozilla Assistant, le respect des principes du Mozilla Manifesto, le respect, le professionnalisme et l’inclusion, le refus d’actions nuisibles, immorales, contraires à l’éthique ou potentiellement illégales, ainsi que l’interdiction de la désinformation et du langage discriminatoire
- Tous les LLM ont une fenêtre de contexte, c’est-à-dire la longueur maximale qu’ils peuvent mémoriser dans la conversation courante
- Elle est généralement fixée au moment de l’entraînement et ne peut pas être modifiée ensuite
- Plus la fenêtre de contexte est grande, plus il est possible de se référer longtemps aux questions et réponses précédentes
- Elle permet aussi d’insérer de plus gros fragments de contenu issus de la recherche vectorielle
- La fenêtre de contexte de LLaMA 2 était de 4096 tokens, soit environ 3000 mots
- Pour économiser cette fenêtre de contexte, l’équipe a réduit à plusieurs reprises la longueur du prompt système, et prévoit d’examiner à l’avenir des modèles prenant en charge de plus grandes fenêtres de contexte
Choix de l’orchestration et de l’UI
- L’ensemble du chatbot nécessite une orchestration coordonnant plusieurs couches : injection de prompts d’agent, gestion de la fenêtre de contexte, embedding de contenus internes, appels au LLM et traitement des réponses
- LangChain, un outil majeur du domaine des LLM, est puissant et flexible, mais aussi très complexe
- L’équipe Mozilla n’a utilisé LangChain qu’au minimum, pour les embeddings et la recherche vectorielle
- Le projet étant court et très contraint, l’essentiel a été géré avec du code Python écrit en interne
- Avec plus de temps, il est probable que l’équipe n’aurait pas tout fait manuellement
- L’UI doit assurer davantage de fonctions qu’il n’y paraît : affichage de la conversation, suivi des anciens fils, gestion d’un backend produisant des sorties à vitesse irrégulière, etc.
- Parmi les UI de chatbot open source, chatbot-ui implémente l’API OpenAI et peut servir de remplacement à l’UI de ChatGPT, tout en étant facile à utiliser comme frontend pour son propre système LLM
- En temps normal, l’équipe Mozilla aurait probablement utilisé un projet comme chatbot-ui, mais elle disposait du code de chatbot expérimental interne Companion et de son auteur ; elle l’a donc utilisé comme UI
- Companion a permis d’itérer et d’expérimenter rapidement sur l’UI
Résultat du hackathon et défis restants
- À la fin du hackathon, l’équipe Mozilla avait terminé un prototype de chatbot interne
- Entièrement hébergé chez Mozilla
- Utilisable de façon sûre et privée
- Cherchant à refléter les valeurs de Mozilla dans son comportement
- Atteindre ces objectifs a nécessité plusieurs choix difficiles et compromis
- Les enseignements se résument en trois points
- Les chatbots open source sont encore en évolution : il reste beaucoup de décisions à prendre, la documentation claire manque et les façons d’échouer sont nombreuses
- Il est trop difficile d’évaluer et de choisir un modèle selon des critères autres que la performance brute, ce qui rend difficile le bon choix pour une application d’IA fiable
- À l’heure actuelle, un prompt engineering efficace reste important pour le succès d’un chatbot
- Mozilla a commencé à créer des moyens pour aider les développeurs à entrer plus facilement dans l’écosystème du machine learning open source, et souhaite contribuer à la communauté open source à partir du travail réalisé pendant le hackathon
- Alors que les LLM open source sont largement disponibles, construire un avenir meilleur exige que chacun participe collectivement et activement à sa formation
1 commentaires
Avis de Hacker News
Si j’essaie de contacter une entreprise, c’est parce que je n’ai pas trouvé la réponse sur le site, ou parce que je dois demander à quelqu’un de faire quelque chose qu’on ne peut pas faire sur le site. Par exemple résilier un service.
Une page FAQ qui parle ressemble à une tentative de combler une mauvaise expérience utilisateur, et si l’entreprise n’a pas mis l’information que je cherche sur son site, il y a de fortes chances qu’elle ne l’ait pas mise non plus dans son chatbot.
Cela dit, un chatbot peut aider à orienter vers la bonne personne, mais le placer comme barrière avant d’obtenir l’aide d’un humain me semble être un antipattern.
C’est pour cela que beaucoup de sites affichent tout un tas de questions qui recommandent des réponses pertinentes à partir de la description avant de permettre de contacter le support, et le support AWS fait aussi cela.
Les bots peuvent être agaçants, mais ils peuvent aussi réduire fortement les coûts du support client. Si l’expérience utilisateur est bonne et que le bot peut transférer rapidement vers un conseiller lorsqu’il ne sait pas répondre, je suis pour. À condition, bien sûr, que le bot n’hallucine pas en donnant de fausses informations.
J’utilise un chatbot parce que je n’ai pas de personnel de support pour répondre aux questions. Sans bot, il n’y aurait rien.
En revanche, je surveille les logs du bot. S’il manque une fonctionnalité dans le produit ou sur le site, je l’ajoute afin que les utilisateurs suivants puissent tout faire en self-service.
Les utilisateurs peuvent annuler leur compte ou se faire rembourser à tout moment.
Pour ce genre de questions, les grands modèles de langage conviennent presque parfaitement. J’aimerais simplement qu’ils détectent mieux les questions auxquelles le bot ne peut pas répondre directement.
Bien sûr, il existe des cas où un chatbot peut remplacer un humain ou une FAQ bien rédigée. Mais cette autosatisfaction passe à côté de la raison principale pour laquelle le support est si mauvais : il est conçu ainsi dès le départ.
Prenons l’exemple de « résiliation uniquement par téléphone » : l’inscription ou l’upsell sont des problèmes techniquement plus difficiles, et pourtant ils sont beaucoup plus simples. Le but est d’ajouter de la friction aux actions perçues comme un coût ou une perte à court terme. Les entreprises savent que beaucoup de gens abandonnent ou remettent à plus tard lorsqu’il y a de la friction.
C’est le paradigme du nudge et du dark pattern. Il suffit de regarder les bannières de cookies, où « tout refuser » est le plus souvent caché. Le nudge permet aux entreprises de donner l’impression de respecter la loi tout en contournant son effet global, aux dépens du temps et de l’attention des utilisateurs.
Le chatbot n’est qu’une couche supplémentaire ajoutée au labyrinthe du support.
Je n’ai aucune envie d’un futur où toutes les entreprises auront un support par chatbot.
C’est déjà assez courant et frustrant, mais pour l’instant, dans environ la moitié des cas, on voit encore qu’il ne comprend pas la question, ce qui laisse une échappatoire vers un humain.
L’ère du « l’ordinateur dit non » est déjà arrivée.
Et pour préciser, je ne veux pas seulement être négatif ni hors sujet : l’article lui-même a l’air plutôt bon. Bravo à son auteur. L’ingénierie est impressionnante, c’est simplement l’usage concret que je n’aime pas.
Les chatbots ne sont pas une solution miracle, mais ils peuvent réduire beaucoup de bruit inutile. Ce qu’il faut, c’est quelque chose capable de répondre aux questions de base que l’utilisateur moyen pose dans un domaine précis.
Mon ancien employeur était une assez grande entreprise, et son instance Confluence était énorme. On perdait beaucoup de temps à y chercher des informations. Un chatbot entraîné sur toutes ces informations aurait sans doute été très utile.
Amazon me vient à l’esprit. Je suis client depuis longtemps, et j’ai récemment reçu un périphérique informatique défectueux.
J’ai brièvement expliqué le problème au chatbot ; il a immédiatement passé une nouvelle commande, m’a dit que je pouvais simplement garder l’article reçu, et que la livraison serait prioritaire sans frais supplémentaires.
C’était tout, et le produit est arrivé le lendemain et fonctionnait correctement.
Bien sûr, ils savaient probablement que j’étais un ancien client qui avait déjà dépensé beaucoup d’argent, mais c’était à peu près l’expérience la moins douloureuse imaginable. Bien mieux que de cliquer sur des options à travers plusieurs pages web.
« Monsieur le juge, toute ma plaidoirie était du grand n’importe quoi et citait des dispositions légales inexistantes, mais c’est parce que j’ai utilisé ChatGPT » — c’est vraiment arrivé avec un avocat, qui n’a même pas été radié du barreau.
L’expression « est déjà en train de changer le web que nous connaissions et aimions » est certes du pinaillage et clairement hors sujet, mais je n’aime pas le web actuel.
Le web est de plus en plus contrôlé par une poignée d’entreprises. Elles décident quels contenus sont visibles (Meta, Google), quels e-mails finissent dans le filtre antispam (MS, Google).
Le web actuel est loin d’être aimable. Je dois me battre en permanence pour atteindre même les personnes qui ont choisi de me suivre.
Au final, la plupart de mes communications se font dans le monde réel ou dans des chats privés. Et j’ajouterais volontiers à quel point Messenger pour les entreprises est horrible et instable.
Il faut qu’il se passe quelque chose avec le web d’aujourd’hui. Je ne sais pas quoi ni comment, mais le changement est clairement le bienvenu.
Il faut quand même continuer à proposer tous les autres moyens permettant aux gens de vous suivre, mais si vous mettez en avant le flux RSS, les gens peuvent commencer à l’utiliser.
Si vous voulez tenter quelque chose de plus technique, vous pouvez mettre en place un bridge ActivityPub pour permettre aussi le suivi depuis les réseaux sociaux. Si vous utilisez WordPress, il existe https://wordpress.org/plugins/activitypub/.
Comme la plupart des commentaires tout en haut semblent négatifs envers les chatbots, je vais le dire : au travail, on avait un excellent chatbot
Pour moi, c’était bien mieux que de chercher dans Confluence, et il pouvait aussi répondre à des questions portant sur des données dynamiques, comme le nombre de jours de congé restants ou le fait d’être en avance ou en retard sur ses heures de travail
Dans mon souvenir, il utilisait la techno de manière intelligente en coulisses, si bien qu’il comprenait la plupart du temps même quand on posait les questions en langage naturel
La recherche de Confluence est une blague totale, et une mauvaise blague en plus
Si les clients utilisent un chatbot, c’est parce que l’UI du site web est confuse. Ils veulent obtenir une information mais ne trouvent pas comment faire
Avant, on cherchait sur Google « nom du service + numéro de téléphone » ou « nom du service + résilier l’abonnement »
Neuf fois sur dix, le site web ne veut pas donner facilement le numéro de téléphone, ni rendre la résiliation facile. Si, dès le départ, on ne veut pas que le client fasse l’action qu’on a cachée, à quoi sert donc le chatbot ?
J’ai travaillé pendant la vague des chatbots, et j’ai dû dire à plusieurs clients que, s’ils n’avaient pas réellement la volonté d’aider leurs clients, nous ne pouvions pas faire grand-chose
Le véritable objectif des chatbots, du moins pour les entreprises qui interagissent avec des personnes, est de reléguer les UI web et mobile hors du premier point de contact
L’utilisateur devrait pouvoir parler à l’entreprise, avec une identité unique, via SMS ou un chat similaire, ou par téléphone
Le web et les apps mobiles ne sont que des utilitaires secondaires ou tertiaires venant compléter le mode de communication principal
Si les entreprises ne pouvaient pas le faire auparavant, c’est parce que la précision de la compréhension du langage n’était pas suffisante. Les grands modèles de langage ont levé cette limite
Le fait que le bot réduise un peu les interactions avec les conseillers grâce à des règles empiriques est un bonus. Grâce à de meilleurs grands modèles de langage, le taux d’évitement de transfert augmente aussi petit à petit
Le widget de chatbot agaçant collé en bas à droite n’est qu’une solution provisoire, en attendant de proposer un numéro de téléphone unique et que la communication via celui-ci devienne fluide
Enfin, le titre prête à confusion. Il ne s’agit pas de créer un chatbot open source, mais de créer un chatbot en utilisant uniquement des bibliothèques open source plutôt que des outils fermés/commerciaux, au bénéfice de la communauté et d’un progrès plus rapide de l’IA
Il est dit : « Nous avons créé notre propre serveur virtuel dans le compte Google Cloud Platform (GCP) existant de Mozilla. Ce faisant, nous avons en pratique décidé de faire nous-mêmes le MLOps. Mais nous avons pu avancer avec la certitude que le système était privé et entièrement sous notre contrôle. » En quoi le fait de monter un serveur dans l’infrastructure de Google est-il privé et entièrement sous le contrôle de Mozilla ?
Expliquer jusqu’à l’auto-hébergement sur bare metal dépasse le cadre d’un article sur la construction d’un chatbot, et faire comme si un VPS sur Google Cloud n’était pas sûr est un peu tiré par les cheveux
ISO 27001 est une norme internationale relative aux systèmes de management de la sécurité de l’information, et la conformité de GCP montre son engagement en matière de sécurité de l’information
ISO 27017 est spécialisée dans la sécurité cloud et se concentre sur les contrôles propres aux fournisseurs de services cloud
ISO 27018 est une norme liée à la protection des informations personnelles identifiables dans le cloud public
Les rapports SOC 2 peuvent fournir une assurance sur les contrôles liés à la sécurité, la disponibilité, l’intégrité du traitement, la confidentialité et la protection de la vie privée
Si l’on traite des informations de santé, la conformité HIPAA est nécessaire ; si l’on traite des données européennes ou de citoyens européens, la conformité GDPR est importante
Pour des clients du gouvernement américain, la conformité FedRAMP peut être indispensable, et si l’on traite des informations de carte bancaire, la conformité PCI DSS est importante
Il faut vérifier que les services utilisés dans GCP entrent bien dans le périmètre des certifications requises pour le secteur ou le cas d’usage concerné. Ces certifications sont généralement consultables sur le site de Google Cloud, et l’on peut aussi obtenir la documentation officielle auprès des équipes commerciales ou du support de Google
Si vous voulez savoir comment construire concrètement ce type de modèle de chat avec base de données vectorielle, j’ai montré dans un live stream la semaine dernière comment en créer un presque de zéro dans un environnement Colab et faire l’inférence avec Llama 2 https://www.youtube.com/live/kBB1A2ot-Bw?feature=share
Le grand défi de cette architecture est d’effectuer une recherche de similarité sémantique à grande échelle. Pinecone a de plutôt bons documents sur les structures de données permettant de faire passer à l’échelle de grandes bases de données vectorielles
J’attendais que Mozilla se lance dans ce mouvement et développe son propre grand modèle de langage. Vu la mission de l’organisation, « garder Internet ouvert et accessible à tous », cela a beaucoup de sens. Je ne sais toutefois pas s’ils ont les ressources ou la volonté de le faire
Il est dit : « Il y a une raison pour laquelle les opérations de machine learning, c’est-à-dire le MLOps, sont un domaine en croissance. Déployer et gérer ce type d’app est difficile. Cela exige des connaissances et des compétences spécifiques que beaucoup de développeurs et d’équipes ops ne possèdent pas encore. » Mais qu’est-ce qui est si difficile ou différent ?
Je pensais qu’il s’agissait d’exécuter une API web qui charge un modèle, c’est-à-dire un artefact compilé. Sous cet angle, ça ne me paraît pas très différent