Le modèle Gemma 3 affiné de Kasisto répond aux questions bancaires dans plus de 40 établissements

Le problème

Les banques veulent des assistants virtuels qui répondent aux questions de leurs clients à partir de grilles de taux et de politiques à jour. Les modèles d'IA généralistes peuvent inventer des réponses, sont lents et coûtent de l'argent à chaque requête. Dans un secteur réglementé, une réponse erronée sur, par exemple, la pénalité de remboursement anticipé d'un prêt immobilier peut créer un risque juridique et financier. L'assistant doit aussi refuser de répondre lorsque les documents ne contiennent pas la réponse.

Ce qu'ils ont construit

Kasisto, une entreprise qui fournit des assistants virtuels aux banques, a construit FinRAG-12B. Il s'agit du modèle Gemma 3 12B à poids ouverts de Google, affiné pour lire les passages que le moteur de recherche d'une banque récupère, rédiger une réponse à partir de ces passages, citer l'origine de chaque affirmation et refuser lorsqu'aucun élément ne l'étaye. Ce schéma s'appelle la génération augmentée par récupération (RAG).

Le modèle fait partie des assistants que Kasisto exploite pour des banques. L'article indique qu'il est déployé dans plus de 40 établissements financiers. Dans la coopérative de crédit, il a été comparé à un modèle de production historique ; l'article nomme séparément un modèle Kasisto antérieur, FinRAG-v3, construit sur Mistral-7B-Instruct.

Comment ils s'y sont pris

Kasisto a entraîné le modèle en deux étapes. La première a utilisé des données financières publiques pour apprendre les formats de réponse et les citations. La seconde a utilisé les propres conversations bancaires de Kasisto pour apprendre quand refuser. Environ 22 % des exemples d'entraînement étaient des questions dont la réponse ne figurait pas dans les documents. L'équipe a filtré les données d'entraînement avec un juge IA pour maintenir la qualité, et n'a utilisé que 143 millions de tokens.

Les auteurs chiffrent la facture d'entraînement à environ 1 800 $ de temps GPU. Pour la production, le modèle est compressé en poids de 4 bits, ce qui le fait passer de 24 Go à 8,4 Go et lui permet de tourner sur un seul GPU.

Résultats

Dans une grande coopérative de crédit américaine, les auteurs ont comparé un modèle de production historique à FinRAG-12B sur 3 297 requêtes échantillonnées sur sept mois. La part de requêtes résolues sans passage à un humain est passée de 77,4 % à 84,5 %, soit un gain de 7,1 points de pourcentage. Dans les tests de latence hors ligne des auteurs, qui ne sont pas des mesures de production, le nouveau modèle était aussi 3 à 5 fois plus rapide que GPT-4.1, environ 20 à 50 fois moins cher par requête selon les prix publiés de l'API, et mettait 3,2 fois moins de temps à terminer une réponse que FinRAG-v3.

Lors de tests hors ligne sur 258 questions bancaires, le modèle a refusé de répondre à 12 % des questions, entre les 4,3 % du modèle de base (trop peu de refus) et les 20,2 % de GPT-4.1 (trop de refus).

Ce qui a mal tourné

Les scores de satisfaction ont moins bougé que la résolution. La satisfaction globale est passée de 59,5 % à 62,9 %, mais l'article précise que la différence pourrait relever du hasard. La satisfaction des requêtes résolues et non résolues est restée presque stable ; les auteurs en concluent que la baisse du nombre de requêtes non résolues explique l'amélioration. Le modèle affiné a aussi cité moins de passages que le modèle de base non affiné, un compromis que les auteurs acceptent au profit de citations plus sélectives.

Ce qu'il faut retenir

N'affinez un petit modèle à poids ouverts sur vos propres contenus de support qu'après avoir fixé un objectif clair en matière de refus. Faites-le fonctionner à côté de votre modèle actuel dans le même circuit et comparez les taux de résolution sur des requêtes réelles. Calculez le coût par requête avant de choisir entre l'auto-hébergement et une API à l'usage.