Chatbot documentaire : préparer la base et vérifier les réponses

Avant de développer un chatbot documentaire, précisez les questions auxquelles il doit répondre. « Connaître tous les documents » ne permet pas de vérifier le résultat. En revanche, on peut tester s’il explique la procédure actuelle d’accès au CRM et renvoie au bon passage.

Le RAG recherche des passages et les fournit au modèle avec la question. Une réponse peut citer ses sources, sans que cette citation garantisse son exactitude.

• Microsoft — Retrieval augmented generation

Commencer par un ensemble limité de documents à jour

Désignez une personne responsable de la base et choisissez les documents nécessaires. Un assistant interne peut expliquer les outils de travail, tandis qu’un bot destiné aux clients utilise les descriptions de services. Leurs documents n’ont pas à être regroupés dans une base ouverte à tous.

Précisez titre, version ou date d’effet, responsable, public et emplacement. Organisez les archives pour qu’elles ne remplacent pas les consignes actuelles. Les contradictions doivent être tranchées par le responsable du processus.

Accompagner la réponse de preuves

Le lien doit mener au document qui confirme la réponse, si possible au passage concerné. Lorsque les règles changent, indiquez la version ou la date du document pour que l’utilisateur puisse les vérifier.

Si les documents ne permettent pas de répondre, le bot doit demander une précision ou expliquer ce qui manque et orienter l’utilisateur vers un responsable. Définissez ce comportement avant les tests.

Appliquer les droits avant de transmettre les documents

Les restrictions s’appliquent à la recherche, pas seulement par une consigne au bot. Microsoft documente le filtrage selon les groupes autorisés.

• Microsoft — Document security filters

Testez avec un compte ordinaire, un compte disposant de droits supplémentaires et un compte dont l’accès a été retiré. Ni la réponse ni les liens ne doivent révéler de documents interdits à cet utilisateur. Les journaux de test doivent aussi avoir des accès limités.

Vérifier cinq situations sur un exemple fictif

Ces règles sont inventées, pas celles de Neaptide. La version 1 demandait l’accès CRM par email ; la version 2 actuelle utilise un portail avec accord du responsable. Une consigne d’administration est réservée.

Préparez les questions avant le réglage du bot et gardez-en certaines pour le test final. Une démonstration sur quelques questions connues dit peu de chose sur les nouvelles demandes. Conservez séparément les passages trouvés et la réponse finale pour localiser les erreurs.

Mettre la base à jour après le lancement

Désignez un responsable et convenez du délai de mise à jour. Un fichier remplacé n’est pas forcément déjà pris en compte par la recherche. Vérifiez son traitement, les éventuelles erreurs et la réponse à une question de contrôle. Testez aussi la suppression de documents et les changements de droits.

Examinez les questions sans réponse documentée, les documents mal sélectionnés et les demandes transmises à un humain. Une correction de la consigne source peut suffire. Le niveau de confiance annoncé par le modèle ne prouve pas qu’il a raison.

Quand le chatbot n’est pas nécessaire

Avec quelques consignes courtes et peu de demandes, une navigation claire et une recherche classique peuvent suffire. Envisagez un bot si les questions se répètent ou si les réponses nécessitent plusieurs documents. Évaluez ce besoin à partir des demandes réelles.

Pour discuter du RAG avec Neaptide, apportez questions, documents actuels, groupes et réponses attendues. Cela aide à chiffrer préparation, intégrations, tests et maintenance.

• Discuter d’un chatbot documentaire

• Comprendre le coût d’un projet IA

• Vérifier les réponses IA