Le système de support multiniveaux de l’entreprise peut employer un assistant conversationnel (ou chatbot) alimenté par un grand modèle de langage pour compléter le travail de ses agents, afin d’offrir un service d’assistance complet et efficace aux utilisateurs finaux.
- Génération augmentée de récupération
- Discussion avec un agent conversationnel
- Recherche générative
- IA agentique
- Synthèse de documents
- Modernisation et génération de code
- Génération de code pour Ansible
- Génération de code pour Z
- Développement de logiciels augmenté par l’IA avec des agents
L’architecture d’agent conversationnel est illustrée dans le schéma ci-dessus. Les principales étapes du flux d’architecture sont les suivantes :
Les documents d’entreprise tels que les manuels des produits, les FAQ, les documents d’offre, les prospectus, les tickets d’assistance résolus, etc. sont ingérés dans une instance d'IBM watsonx Discovery et préparés pour la recherche sémantique.
Les utilisateurs soumettent leurs requêtes, problèmes ou questions par le biais d’une interface sur le site Web de l’entreprise, d’une application dédiée ou d’autres plateformes. Cette interaction est facilitée par IBM watsonx Assistant, qui sert d’interface principale pour les échanges par chat.
Pour les demandes nécessitant la récupération de données dans les documents ou la base de connaissances de l’entreprise, IBM watsonx Discovery est appelé pour rechercher et récupérer les passages d’informations les plus pertinents pour la demande de l’utilisateur.
La requête de l’utilisateur, ainsi que les informations pertinentes récupérées à partir de Watson Discovery, sont ensuite transmises par watsonx Assistant à un grand modèle de langage (LLM) hébergé sur watsonx.ai.
Le LLM synthétise la requête de l’utilisateur, les informations fournies et les connaissances intégrées au LLM pour générer une réponse semblable à celles d’un humain. Cette réponse est renvoyée à watsonx.ai, puis présentée à l’utilisateur après un éventuel traitement tel que le formatage.
Si l’utilisateur n’est pas satisfait de la réponse générée (par exemple, si sa demande est nuancée, complexe ou nécessite des connaissances spécifiques), il peut choisir de demander à watsonx Assistant de transmettre l’appel à un agent humain. De même, les interactions peuvent être automatiquement remontées si la réponse du LLM est jugée peu fiable ou potentiellement offensante. Les utilisateurs peuvent choisir d’interagir avec un représentant humain à tout moment. watsonx Assistant transfère avec fluidité l’interaction à un agent humain via le système de gestion du centre de contact de l’entreprise.
Un agent humain, avec un accès complet à l’historique des conversations avec watsonx Assistant, aide l’utilisateur dans sa demande, son problème ou sa question.
Après la résolution du problème, le système, via watsonx Assistant, peut solliciter un retour de l’utilisateur. Ces commentaires permettront d’affiner les interactions futures en analysant les requêtes fréquemment non résolues ou remontées, et permettront à l’organisation d’optimiser le LLM hébergé sur watsonx.ai et/ou de régler les paramètres de recherche de watsonx Discovery pour améliorer les performances.
Les relations entre le portefeuille de produits d’IA IBM watsonx et l’architecture conceptuelle sont illustrées dans le schéma ci-dessous. watsonx Assistant fournit les capacités d’interaction du composant d’assistant virtuel, tandis que watsonx Discovery, un module complémentaire de watsonx Assistant, fournit les capacités d’ingestion de documents et de recherche sémantique. L’environnement de développement et d’hébergement de modèles watsonx.ai permet de sélectionner, régler, tester et déployer le grand modèle de langage.
Certains clients n’ont pas accès à watsonx.ai dans leur région, ou peuvent être dans l’impossibilité d’utiliser la solution watsonx.ai SaaS pour des raisons de sécurité ou d’exigencesréglementaires. Nous leur proposons watsonx.ai sous la forme d’un ensemble de services conteneurisés qui peuvent être déployés sur Red Hat Openshift dans leur propre centre de données, dans un cloud privé virtuel (VPC) sur l’infrastructure d’un fournisseur de service cloud, ou un autre emplacement.
Décisions et considérations relatives à l’architecture
Choix du modèle de génération
Le choix du modèle dépend de nombreux facteurs.
La licence du modèle peut restreindre son utilisation. Par exemple, elle peut interdire son utilisation dans le cadre d’une application commerciale.
Le jeu de données utilisé pour entraîner le modèle affecte directement la performance de ce dernier sur une tâche donnée. Le risque que le modèle génère des réponses absurdes, offensantes ou tout simplement indésirables en dépend également. De la même manière, les modèles entraînés sur des données privées ou protégées par le droit d’auteur peuvent engager la responsabilité des utilisateurs. IBM assure une transparence totale des données d’entraînement et une indemnisation en cas de réclamation portant sur ses modèles.
La taille du modèle, le nombre de paramètres utilisés pour son entraînement et la taille de sa fenêtre contextuelle (la longueur des passages de texte qu’il peut accepter) affectent sa performance, ses besoins en ressources et son débit. Bien qu’il soit tentant de suivre le principe « plus c’est grand, mieux c’est » et de choisir un modèle à 20 milliards de paramètres, les besoins en ressources et l’amélioration (éventuelle) en termes de précision ne le justifient pas nécessairement. Selon plusieurs études récentes, les modèles plus petits peuvent s’avérer nettement plus performants que les grands dans le cas de certaines solutions.
Tout réglage fin appliqué aux modèles peut affecter leur adéquation à une tâche donnée. Par exemple, IBM propose deux versions du modèle Granite : l’une adaptée aux applications de chat générales, et une autre conçue pour suivre des instructions.
Autres aspects à prendre en compte pour bien choisir votre modèle :
Sélection des paramètres du modèle, comme sa température, pour concilier génération de textes semblables à ceux rédigé par un humain et réponses factuelles. Définir la température du modèle sur une valeur élevée entraîne la production de réponses cohérentes, mais potentiellement sans intérêt ou trop lacunaires, tandis que le réglage sur une valeur faible permet des réponses plus variées, dont la longueur et le contenu seront toutefois plus imprévisibles.
Sélection et mise en œuvre des garde-fous dans le modèle pour éviter les résultats inefficaces ou offensants.
La langue des données client et des prompts utilisateur doit également être prise en compte. La majorité des LLM sont entraînés sur des textes en anglais et peuvent souvent traduire entre l’anglais et d’autres langues avec des niveaux d’expertise variables. Les applications nécessitant une prise en charge multilingue ou localisée peuvent nécessiter l’utilisation de plusieurs modèles entraînés dans chacune des langues prises en charge, ou la mise en œuvre d’une étape pour traduire les entrées multilingues en anglais ou dans une autre langue « de base ».