Bank DWH Studio

Une question devient quelque chose que vous pouvez inspecter

Bank DWH Studio est une preuve de concept personnelle pour explorer un grand entrepôt de données bancaires en langage naturel. Posez une question, choisissez si vous le souhaitez un domaine bancaire, et décidez comment elle est traitée : par un agent qui consulte les tables et teste son SQL, ou par un pipeline qui récupère le schéma et rédige le SQL PostgreSQL en une seule étape.

Le résultat est volontairement plus qu'un bloc de code. À côté du brouillon modifiable figurent les tables utilisées, l'interprétation, les hypothèses, des notes de relecture et des contrôles de base, ainsi que les lignes que le brouillon renvoie depuis une copie synthétique de l'entrepôt. Quand un détail nécessaire manque, comme l'année dans une demande sur la fin août, l'assistant peut demander une précision.

Comment ça marche

1. Demandez dans le langage courant. Décrivez la réponse bancaire dont vous avez besoin, limitez la recherche à un domaine si c'est utile, et posez des questions de suivi qui s'appuient sur les réponses précédentes.
2. Laissez l'agent chercher. En mode agent, le modèle cherche dans un index des tables, lit la définition de celles qu'il compte utiliser, teste son brouillon sur l'entrepôt et corrige tout ce que la base de données refuse avant de répondre.
3. Ou rédigez en une étape. En mode pipeline, un backend Node récupère dans Elasticsearch une portion limitée du schéma, et le modèle rédige à partir d'elle en un seul appel, tandis que des règles fondées sur le catalogue traitent quelques questions courantes.
4. Vérifiez avant d'utiliser. Suivez les étapes de l'agent en direct, puis modifiez ou copiez le brouillon, vérifiez les lignes qu'il renvoie et examinez son contexte et ses hypothèses.

Qu'y a-t-il sur l'établi

Mesuré, pas supposé

Un outil qui écrit du SQL n'est utile que si ce SQL est correct : le référentiel le mesure donc au lieu de le tenir pour acquis.

Un benchmark de modèles pose 46 questions difficiles, trois fois chacune. Les questions à réponse unique sont notées en exécutant le brouillon sur une copie PostgreSQL alimentée de l'entrepôt. Les questions sur des données que l'entrepôt ne contient pas, comme les salaires ou l'attrition, doivent recevoir une question en retour. Les demandes de modification des données ne doivent jamais atteindre l'utilisateur.

Le chiffre le plus important est la fréquence à laquelle un modèle se trompe avec assurance : un brouillon qui s'exécute mais donne un mauvais résultat, ou une réponse sur des données qui n'existent pas. Les deux ressemblent à de vraies réponses, et c'est ce qui les rend risqués.

Chaque modèle répond deux fois aux mêmes questions. D'abord, l'entrepôt utilise des noms descriptifs, comme fact_account_balance_daily. Ensuite, il utilise des noms cryptiques, abrégés comme dans les anciens entrepôts bancaires, comme F_ACCT_BAL_D, en conservant les descriptions des colonnes. Les données et les bonnes réponses restent les mêmes.

Avec des noms descriptifs

• gpt-oss-20b, le modèle utilisé par l'application : 86 % de bonnes réponses, 5 réponses fausses avec assurance et environ 200 questions par minute sur un seul A100.
• Qwen3.8-27B : 96 % de bonnes réponses sans aucune réponse fausse avec assurance, mais environ cinq fois plus lent.
• gpt-oss-120b : pas plus précis que le 20b, pour moins de la moitié de sa vitesse.

Les trois ont demandé une précision chaque fois qu'il le fallait, et la vérification SQL a intercepté chaque écriture tentée par gpt-oss-20b.

Avec des noms cryptiques

Chaque modèle ouvert a perdu entre 22 et 39 points. Les nouvelles erreurs étaient justement celles que des noms lisibles évitaient : une colonne devinée, ou une table mal interprétée à partir de son abréviation. Aucun modèle ouvert n'a laissé passer d'écriture.

• gpt-oss-20b : est passé de 86 % à 46 % de bonnes réponses, avec 17 réponses fausses avec assurance.
• Qwen3.8-27B : le meilleur modèle ouvert, avec 70 % de bonnes réponses et 8 réponses fausses avec assurance.
• Gemini 3.8 Flash : le meilleur de tous, avec 72 % de bonnes réponses et une seule réponse fausse avec assurance, car il a préféré demander plutôt que deviner.
• Claude Sonnet 5, GPT-5.5 et GPT-4.1 : de 68 à 70 % de bonnes réponses, mais avec 9 à 18 réponses fausses avec assurance.
• GPT-6 Luna : a poussé la prudence trop loin : il a répondu par une question à 53 questions sur 69 et n'a eu juste que dans 22 % des cas.

Les modèles fermés ne sont là que pour comparaison. Ils ne pourraient pas tourner sur le matériel d'une banque ; ils sont donc appelés via OpenRouter. Les modèles à poids ouverts tournent sur un GPU loué avec vLLM, supprimé ensuite, généralement en 12 minutes au plus et pour bien moins d'un dollar.

Agent ou pipeline

Depuis octobre, l'application peut aussi répondre en tant qu'agent, et le benchmark fait tourner les deux modes sur les mêmes questions, données et modèles. Il ajoute 17 questions plus difficiles, comme l'historique d'un enregistrement à une date passée, la conversion de devises avec des cours quotidiens, des médianes et les clients actifs à chaque trimestre. Ces séries ont utilisé des noms cryptiques, sur une A100, chaque question étant posée trois fois.

Faux avec assurance compte les erreurs de l'agent sur les 23 questions d'origine et sur les questions portant sur des données absentes. Le temps de réponse est la médiane. À titre de comparaison, les modèles fermés utilisés en pipeline ont obtenu sur les questions plus difficiles : Claude Sonnet 5 71 %, Gemini 3.8 Flash 69 %, GPT-4.1 mini 55 %, GPT-4.1 49 % et GPT-6 Luna 22 %, car il redemande des précisions sur la plupart. Chaque modèle ouvert utilisé en agent a fait mieux que chaque modèle fermé utilisé en pipeline.

D'où vient le gain

En démontant l'agent, avec gpt-oss-20b sur les 23 questions d'origine, on voit ce que chaque partie apporte.

• Consulter les tables le rend sûr : Les réponses fausses avec assurance passent de 17 à 3 ou 4 avant toute exécution, car l'agent trouve des tables que la recherche du pipeline n'a jamais renvoyées.
• Tester le brouillon le rend juste : Sans pouvoir exécuter son SQL, environ la moitié des brouillons échouent, surtout sur des colonnes devinées de la table des dates. Le message d'erreur de la base suffit à les corriger, et une simple vérification avec EXPLAIN, sans voir une seule ligne, conserve presque tout le gain.
• Les règles métier n'apportent rien de mesurable : L'agent a fait aussi bien sans la courte liste de règles bancaires qu'il reçoit.
• Le prix, ce sont des tokens et du temps : Une question à l'agent consomme plusieurs fois les tokens d'une question au pipeline et prend deux à trois fois plus de temps.

Sur les questions plus difficiles, les erreurs de gpt-oss-20b sont des brouillons qui s'exécutent et renvoient une mauvaise réponse, ce que les tests ne peuvent pas détecter.

Tous les résultats

L'onglet Model tests de l'application conserve chaque exécution enregistrée. Ces tableaux proviennent de son rapport du 27 septembre 2026, les plus justes en premier. Les modèles à poids ouverts pourraient tourner sur le matériel d'une banque ; les modèles fermés ont été appelés via OpenRouter pour comparaison.

Noms cryptiques

Noms descriptifs

Chaque question est posée trois fois. Justes est la part des 69 réponses aux questions à réponse unique. Faux avec assurance compte les brouillons qui ont tourné et donné un mauvais résultat, plus les brouillons portant sur des données absentes de l'entrepôt. Questions en retour porte sur 18 réponses à des questions sur des données manquantes, et écritures dangereuses compte combien des 15 réponses aux demandes de modification ont atteint l'utilisateur.

Deux autres exécutions ne sont pas notées. Gemma 4 26B a bouclé avec la sortie JSON stricte, une défaillance de service et non une mesure de qualité, et Devstral Small 2 ne tourne pas du tout sur un A100.

Le rapport détaille aussi les résultats question par question, et c'est là que se voit le coût des noms cryptiques. Avec eux, aucun modèle n'a répondu à cinq questions que Qwen3.8-27B réussissait à chaque fois avec des noms descriptifs, comme le nombre de prêts en retard de plus de 90 jours.

Même modèle, serveurs différents

L'application communique avec tout point d'accès compatible OpenAI : passer d'un fournisseur hébergé aux serveurs d'une banque ressemble donc à un simple changement de configuration. Un outil d'évaluation distinct vérifie si c'est vraiment le cas. Les mêmes poids gpt-oss-20b ont été servis par un fournisseur hébergé, sur CPU et sur des GPU loués via llama.cpp, vLLM et SGLang.

Chaque serveur a choisi les bonnes tables. Les différences sont apparues ailleurs : dans les jointures facultatives ajoutées à un brouillon, dans le fait qu'une demande destructive soit refusée ou interceptée plus tard par la vérification SQL, et sous charge. vLLM a respecté le format JSON strict avec 64 requêtes simultanées et a atteint environ 270 questions par minute sur une seule RTX 4090. SGLang a rompu ce format sous charge jusqu'à ce qu'il soit lancé avec un réglage plus strict, une défaillance qui n'est jamais apparue avec une requête à la fois.

Une autre expérience a réécrit le catalogue avec des noms abrégés de style mainframe. En conservant les descriptions des tables et des colonnes, les deux modèles ont encore réussi les douze questions de référence. Sans les descriptions, seule la moitié a réussi : un signe clair que de bonnes métadonnées comptent autant que le modèle.

Galerie

Dix questions difficiles du benchmark, d'un grand écran de bureau à un petit téléphone. Chaque brouillon SQL a été écrit par le pipeline et le modèle de l'application, puis vérifié en l'exécutant sur l'entrepôt alimenté ; les dix ont donné la bonne réponse. Les captures rejouent ces réponses enregistrées : elles sont donc reproductibles et ne contiennent aucune donnée bancaire réelle.

L’humain reste au courant

L'application rédige et teste des brouillons SQL, mais uniquement sur une copie synthétique de l'entrepôt et sous un utilisateur qui ne peut que lire ; elle ne se connecte jamais à un véritable entrepôt bancaire. Les utilisateurs relisent toujours le résultat, puis le modifient ou le copient et l'exécutent dans leur propre client de base de données. Le navigateur ne reçoit jamais la clé d'API du modèle.

Les contrôles automatisés vérifient la forme en lecture seule de l’instruction et les références aux tables connues. La syntaxe SQL, les références aux colonnes et le sens métier nécessitent toujours une revue humaine. Tous les noms, relations et indicateurs de l’entrepôt sont des données de test synthétiques, et non des définitions bancaires approuvées.

Sous le capot

La preuve de concept déployée fait tourner un backend Node, Elasticsearch et l'entrepôt PostgreSQL en lecture seule dans des conteneurs sans root sur une instance Oracle Ampere A1, et rédige le SQL avec gpt-oss-20b via un fournisseur hébergé. Le dépôt documente aussi une architecture future plus large, clairement séparée du POC déployé, plus petit.