La technologie seule ne garantit pas l’adoption : Leçons tirées de la création d’un chatbot interne basé sur l’IA

Alors que l’adoption de l’IA s’accélérait dans tous les secteurs, le déploiement d’un chatbot pour soutenir une application interne nouvellement lancée semblait être une décision logique. Cependant, l’application elle-même remettait en question les attentes conventionnelles des utilisateurs. Elle introduisait de nouveaux flux de travail basés sur des technologies émergentes inconnues de la plupart des utilisateurs.

Pour réduire les frictions et améliorer l’adoption, le chatbot a été conçu pour répondre aux questions sur l’application et la technologie sous-jacente. L’objectif était d’aider les utilisateurs à comprendre non seulement ce qu’ils devaient faire, mais aussi pourquoi le système se comportait de telle ou telle manière. Nous croyions que la fourniture d’explications contextuelles accélérerait l’apprentissage et réduirait la confusion.

Dès le début, l’agent IA a été conçu comme une solution à portée limitée. Il a été conçu strictement pour soutenir la documentation et fournir une assistance aux utilisateurs. Conceptuellement, le chatbot était destiné à servir de remplacement dynamique d’un document de questions fréquentes traditionnel, offrant une interface conversationnelle, recherchable et continuellement disponible avec une fonctionnalité étendue au-delà du contenu statique.

Pour intégrer l’agent dans l’environnement de chat interne de l’organisation, nous devions comprendre comment les messages structurés étaient rendus, comment l’historique de conversation était stocké et comment le système identifiait les participants dans les threads. Cela nous a permis de déterminer les variables principales requises pour commencer à traiter les questions des utilisateurs.

Ancrage du modèle : De l’hallucination à un contexte fiable

Les grands modèles de langage sont puissants, mais sans ancrage contextuel, ils sont sujets aux hallucinations. Pour remédier à cela, nous avons mis en œuvre une technique d’intégration de vecteurs.

Les guides d’utilisation, la documentation interne et la vision du produit ont été transformés en représentations numériques vectorielles de texte. Ces intégrations ont capturé la signification sémantique, permettant au système de faire correspondre des concepts plutôt que de se fier à une simple correspondance de mots clés.

Lorsqu’un utilisateur posait une question, le système convertissait la requête en représentation vectorielle et la comparait aux intégrations stockées. Il a récupéré les documents les plus pertinents sur le plan sémantique et les a injectés dans l’invite du modèle. Le modèle a ensuite généré une réponse ancrée dans ces documents spécifiques, résumant souvent les informations pertinentes.

Cette approche a considérablement amélioré la précision des réponses. Au lieu de générer des réponses basées uniquement sur des connaissances générales, le modèle a répondu en utilisant la documentation propre de notre organisation comme contexte.

La complexité cachée de la gestion du contexte

Il était essentiel d’inclure l’historique de conversation dans l’invite pour que le bot puisse interpréter les questions de suivi et maintenir la continuité. Sans historique, les interactions devenaient fragmentées et répétitives. Les utilisateurs affinent souvent leurs questions de manière incrémentale, et sans contexte, le bot ne pouvait pas interpréter des références comme « cette option » ou « l’étape précédente ».

Cependant, inclure trop d’historique créait un autre problème : limites de jetons. Celles-ci se produisent lorsque les modèles de langage tronquent les entrées qui dépassent leur fenêtre de contexte maximale. Si une question ou une conversation devenait trop longue, des informations importantes pouvaient être perdues. Cela n’a pas produit d’erreur explicite, mais a plutôt dégradé la qualité de la réponse ou affecté la précision de la récupération.

Pour atténuer cela, nous avons mis en œuvre des stratégies pour contrôler la taille de l’invite, donner la priorité au contenu pertinent et surveiller la longueur des questions. Nous avons expérimenté la synthèse de messages plus anciens et l’inclusion sélective des parties les plus pertinentes de la conversation. Le contexte était critique, mais il devait être soigneusement géré.

Élargir les capacités et créer de la confusion

Au-delà de la réponse aux questions basées sur la documentation, nous avons étendu les capacités du bot en ajoutant des fonctions backend qui pouvaient extraire certaines informations publiques directement de l’application. Cela a permis aux utilisateurs de récupérer des données du chat sans se connecter à l’application elle-même. L’idée était de réduire les frictions et de renforcer le chatbot en tant qu’interface utile, et non seulement une couche de connaissances statique.

Cette extension a créé de la confusion pour certains utilisateurs. Une fois que le bot a commencé à récupérer des données en temps réel, les utilisateurs ont commencé à lui demander d’exécuter des actions qui nécessitaient une interaction directe à l’intérieur de la plate-forme. Ils supposaient que le chatbot pouvait remplacer les étapes opérationnelles, y compris celles qui nécessitaient une authentification ou une exécution délibérée à l’intérieur de la plate-forme.

Le bot n’a jamais été conçu pour effectuer ces actions, mais la distinction entre l’assistance informative et l’exécution opérationnelle n’était pas toujours claire.

L’intégration de données en temps réel a également introduit de nouvelles considérations techniques. Nous devions définir quand une question devait passer par une récupération basée sur l’intégration et quand elle devait déclencher un appel backend. Cette logique de décision nécessitait une conception soigneuse. De plus, nous devions ajuster les réponses pour gérer avec grâce les exceptions techniques et éviter d’exposer les erreurs brutes du système aux utilisateurs.

La capacité multilingue n’est pas automatique

Lors des tests, nous avons réalisé que le bot se comportait de manière plus cohérente en anglais qu’en d’autres langues utilisées au sein de Jalasoft. La raison principale était structurelle : la plupart de la documentation utilisée pour générer les intégrations était rédigée en anglais, et le modèle d’intégration que nous avons choisi était optimisé pour la similarité sémantique en anglais.

Il ne prenait pas en charge la récupération translinguistique ou la comparaison sémantique entre les langues. En conséquence, les requêtes non anglaises ont souvent récupéré une documentation moins pertinente, conduisant à des réponses plus faibles.

Cela a mis en évidence une idée importante : la capacité multilingue n’est pas automatique.

Quand les attentes dépassent la portée

Pour contrôler les coûts d’utilisation, nous avons mis en œuvre une limite quotidienne sur le nombre de questions que les utilisateurs pouvaient poser. Cependant, nous n’avons pas explicitement restreint la portée de ces questions. Les utilisateurs étaient libres de poser n’importe quelle question.

Cette ouverture a conduit à des modèles d’utilisation inattendus. Certains utilisateurs ont commencé à interagir avec le bot pour des raisons personnelles ou d’exploration sans rapport avec l’application. Au fil du temps, les attentes ont dépassé le rôle prévu du bot, créant un écart entre ce que les utilisateurs espéraient qu’il puisse faire et ce pour quoi il était conçu.

Ce décalage a progressivement réduit son utilité perçue. L’utilisation a diminué, et le chatbot a finalement été déprécié, les efforts étant redirigés vers la reconception de l’application elle-même pour la rendre plus intuitive et plus facile à utiliser.

La véritable leçon : La conception d’interaction.

Du point de vue de l’ingénierie, le système fonctionnait de manière raisonnable. Il a récupéré la documentation, incorporé l’historique de conversation, réduit les hallucinations grâce aux intégrations, géré les appels backend et géré la taille de l’invite. L’architecture a fonctionné comme prévu.

Mais il lui manquait une conception d’interaction intentionnelle.

Le bot n’a pas clairement façonné les conversations. Il n’a pas constamment renforcé sa portée. Il n’a pas guidé les utilisateurs avec des exemples structurés de ce qu’il pouvait et ne pouvait pas faire. Il a répondu aux questions, mais il n’a pas établi d’attentes.

Nous avons appris que les systèmes d’IA conversationnels nécessitent plus que de solides modèles et des données structurées. Ils nécessitent des attentes soigneusement conçues.

Les utilisateurs ont besoin de clarté sur le rôle de l’agent, ses limites et ses forces. Le système doit fournir proactivement des exemples d’invites, clarifier les limites et rediriger les questions hors de la portée de manière cohérente.

Sans cette mise en cadre intentionnelle, même une mise en œuvre techniquement solide peut avoir du mal à maintenir sa valeur. Les utilisateurs peuvent surestimer les capacités ou se désengager lorsque les attentes non déclarées ne sont pas satisfaites.

L’insight clé est simple mais puissant.

La construction d’un système d’IA conversationnel n’est pas seulement un défi technique. C’est également un défi de conception d’interaction.

Un contexte solide, une récupération précise et une architecture robuste sont nécessaires, mais pas suffisants. L’efficacité du système dépend également de la manière dont il définit son rôle, communique ses limites et façonne les attentes des utilisateurs.

La technologie seule ne garantit pas l’adoption. Une conception d’interaction claire le fait.