La technologie seule ne garantit pas l’adoption : les leçons tirées de la construction d’un chatbot interne IA

Lorsque l’adoption de l’IA s’est accélérée dans tous les secteurs, le déploiement d’un chatbot pour soutenir une application interne nouvellement lancée semblait une décision logique. Cependant, l’application elle-même a remis en question les attentes conventionnelles des utilisateurs. Elle a introduit de nouveaux flux de travail basés sur une technologie émergente qui était inconnue 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 utilisateur. 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 nécessaires pour commencer à traiter les questions des utilisateurs.

Ancrage du modèle : de l’hallucination au contexte fiable

Les grands modèles de langage sont puissants, mais sans ancrage contextuel, ils sont sujets aux hallucinations. Pour résoudre ce problème, 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 vectorielles numériques 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 à un simple appariement de mots clés.

Lorsqu’un utilisateur posait une question, le système convertissait la requête en une représentation vectorielle et la comparait aux documents stockés. Il récupérait les documents les plus pertinents sur le plan sémantique et les injectait dans l’invite du modèle. Le modèle générait ensuite 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 répondait 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 affinaient souvent leurs questions de manière incrémentale, et sans contexte, le bot ne pouvait pas interpréter les références comme « cette option » ou « l’étape précédente ».

Cependant, inclure trop d’historique créait un autre problème : les limites de jetons. Ceux-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 ne produisait pas d’erreur explicite, mais plutôt une dégradation de la qualité de la réponse ou une affectation de 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, privilégier le contenu pertinent et surveiller la longueur des questions. Nous avons expérimenté la sommation des 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 exécuter ces actions, mais la distinction entre l’assistance informationnelle 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 la 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 un design soigneux. De plus, nous devions ajuster les réponses pour gérer avec grâce les exceptions techniques et éviter d’exposer les erreurs système brutes aux utilisateurs.

La capacité multilingue n’est pas automatique

Lors des tests, nous avons réalisé que le bot performait de manière plus cohérente en anglais que dans 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 avions sélectionné é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. Par conséquent, les requêtes non anglaises récupéraient souvent des documents moins pertinents, conduisant à des réponses plus faibles.

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

Lorsque 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 qu’il était conçu pour soutenir.

Cet écart a progressivement réduit sa valeur perçue. L’utilisation a diminué, et le chatbot a finalement été déprécié, les efforts étant redirigés vers la révision 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 récupérait la documentation, incorporait l’historique de conversation, réduisait les hallucinations grâce aux intégrations, gérait les appels backend et contrôlait la taille de l’invite. L’architecture fonctionnait comme prévu.

Cependant, il manquait de conception d’interaction intentionnelle.

Le bot ne structurait pas clairement les conversations. Il ne renforçait pas de manière cohérente sa portée. Il ne guidait pas les utilisateurs avec des exemples structurés de ce qu’il pouvait et ne pouvait pas faire. Il répondait aux questions, mais ne définissait pas les 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 portée de manière cohérente.

Sans cette mise en cadre intentionnelle, même une mise en œuvre technique solide peut lutter pour 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’idée clé est simple mais puissante.

La construction d’IA conversationnelle 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 autant 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.