Taxbit lance un assistant IA pour les fiscalistes : 55 % des utilisateurs reviennent avec une nouvelle question

Si vous avez déjà conçu un chatbot d’assistance, vous connaissez probablement le scénario habituel. Le bot répond avec assurance, cite une source difficile à identifier, puis envoie l’utilisateur vers une page à laquelle celui-ci n’a pas accès. Dans le domaine fiscal, ce type d’erreur coûte cher : les utilisateurs prennent des décisions concernant leurs déclarations. L’équipe de Taxbit, une plateforme de comptabilité fiscale destinée aux plateformes d’échange de cryptomonnaies et aux courtiers, a expliqué comment elle avait conçu Assist, un assistant suffisamment fiable pour un environnement réglementé.

Les exigences qui ont façonné l’architecture

L’assistant est soumis à quatre contraintes strictes. Chaque réponse doit citer une source que l’utilisateur peut ouvrir et, en l’absence de réponse, le bot doit le dire explicitement. Il tient compte du rôle et de l’organisation : un agent du support ne doit pas être dirigé vers un parcours réservé aux administrateurs. Il ne fournit pas de conseil fiscal : il peut expliquer comment Taxbit calcule le coût de revient, mais pas recommander la méthode à choisir. Enfin, les données doivent rester dans leur région d’origine.

L’agent repose sur Strands Agents SDK au sein d’AgentCore Runtime. Il s’agit d’une petite application Python composée d’un prompt système, d’un modèle et de huit outils spécialisés. Ceux-ci comprennent la recherche dans la base de connaissances, deux contrôles d’accès et quatre outils de gestion des tickets d’assistance. L’agent n’a absolument aucun accès aux données fiscales des clients.

La décision de sécurité essentielle consiste à empêcher le modèle de gérer l’identité. L’adresse e-mail, l’ID de l’organisation et le rôle proviennent d’un service de confiance et sont injectés dans les outils au moyen d’une fermeture. Le modèle peut décider de vérifier les autorisations, mais il ne peut pas choisir l’identité dont il vérifie les droits. Les entrées utilisateur sont assainies afin qu’une injection de prompt ne puisse pas falsifier le contexte de confiance.

D’où vient réellement le gain de qualité

L’équipe a consacré l’essentiel de ses efforts à la base de connaissances : Amazon Bedrock Knowledge Bases sur S3 Vectors, avec les embeddings Cohere Embed English v3. Trois sources l’alimentent : le site public de documentation et le centre d’aide, la documentation générée à partir du code source du produit et des articles rédigés manuellement.

Le premier gain inattendu est venu du nettoyage du corpus. Le sitemap contenait environ 400 URL, mais seules quelque 70 convenaient aux réponses. Plus de 300 pages du répertoire /blogs/ relevaient du marketing et concurrençaient le centre d’aide comme sources des réponses aux questions de conformité. Exclure le blog n’a pris que quelques minutes et n’a nécessité aucun travail sur le modèle.

Le deuxième gain, et le plus important, est venu du découpage contextuel. Un fragment extrait du milieu d’un document perd les informations indiquant à quoi il se rapporte. Il est dangereux de renvoyer un paragraphe consacré aux règles applicables aux régimes de déclaration non américains en réponse à une question sur le formulaire IRS 1099.

Une fonction Lambda ajoute donc, à l’étape POST_CHUNKING, le titre H1 du document et un paragraphe introductif d’environ 128 tokens à chaque fragment. Le corps du fragment est limité à 384 tokens afin que l’ensemble tienne dans la fenêtre de 512 tokens du modèle d’embedding. Une vérification en production a montré qu’environ 28 % des fragments comptaient entre 385 et 512 tokens et que leur fin aurait autrement été tronquée sans avertissement.

La recherche fonctionne comme un entonnoir : 75 candidats issus de la recherche vectorielle, reclassement avec Cohere Rerank 3.5 dans le même appel Retrieve, sélection des 12 premiers, au maximum deux fragments par document, puis transmission des cinq meilleurs au modèle. Ce large vivier est nécessaire parce que les articles pertinents occupent souvent les positions 20 à 50 dans les résultats vectoriels et ne remontent qu’après le reclassement. Seules les sources publiques peuvent être citées, et cette règle est inscrite dans le code, pas dans le prompt.

Sécurité et contrôle qualité

Bedrock Guardrails vérifie chaque message entrant au moyen d’un appel ApplyGuardrail distinct, limité à la réplique en cours. Les mots de passe, codes CVV et clés cloud sont bloqués. Les SSN, ITIN, coordonnées bancaires et IBAN sont masqués sur place, de sorte que l’agent puisse aider sur le processus sans voir les valeurs. Pour l’historique des conversations, il est essentiel que l’actor ID provienne du service appelant : le runtime s’exécute sous un rôle de service unique et, sans cette précaution, l’historique de tous les utilisateurs serait regroupé dans une seule section.

La qualité est mesurée sur le trafic réel sans bloquer les réponses. Les évaluations en ligne d’AgentCore échantillonnent 10 % des sessions et les notent à l’aide de six juges LLM intégrés : utilité, nocivité, cohérence, respect des instructions, choix des outils et exactitude de leurs paramètres. Des juges internes s’y ajoutent : l’un mesure séparément la faithfulness, c’est-à-dire la fidélité aux sources, et l’autre la relevance, autrement dit la pertinence des résultats récupérés. Cette séparation est volontaire : une réponse peut être fidèle à des sources qui n’auraient jamais dû être récupérées, auquel cas le problème vient de la recherche et non du modèle. Un classificateur distinct vérifie que la réponse ne dérive pas vers le conseil fiscal.

Les enseignements à retenir

Premier enseignement : nettoyez d’abord le corpus, puis ajustez le modèle. Des pages marketing présentes dans l’index dégradent davantage les réponses que n’importe quel prompt. Deuxième enseignement : si un fragment ne sait pas à quoi il se rapporte, ajoutez-lui un titre et un périmètre d’application. Troisième enseignement : tout ce qui concerne les autorisations et l’identité doit rester hors du périmètre décisionnel du modèle. Quatrième enseignement : séparez les métriques de recherche et de génération, faute de quoi vous corrigerez le mauvais composant.

Il faut également garder les limites à l’esprit. Le chiffre de 55 % de questions de suivi provient des analyses internes de Taxbit et mesure l’engagement, pas l’exactitude. La solution est fortement liée à la pile AWS. Pour l’instant, l’agent ne lit aucune donnée client et ne peut donc pas répondre à des questions telles que « pourquoi mon calcul donne-t-il ce résultat ? ». Mais comme modèle d’assistant IA destiné à n’importe quel domaine réglementé — finance, médecine ou droit — cette analyse est particulièrement concrète.