Bank DWH Studio

質問は調べられるものになる

Bank DWH Studio は、大規模な銀行データウェアハウスを自然な言葉で探るための個人的な概念実証です。質問を入力し、必要なら銀行業務の分野を選び、答え方を決めます。テーブルを調べて SQL を試すエージェントか、スキーマを取得して 1 ステップで PostgreSQL の SQL を書くパイプラインかです。

結果は、あえて単なるコードブロック以上のものにしています。編集できる下書きの横に、使われたテーブル、解釈、前提、確認メモ、基本的なチェックが並び、下書きがウェアハウスの合成コピーから返す行も表示されます。8 月末についての依頼で年が抜けているときのように、必要な情報が足りない場合は、アシスタントが聞き返せます。

仕組み

1. 日常の言葉で尋ねてください。 必要な銀行業務の答えを説明し、役立つときは検索を分野に絞り、それまでの答えを踏まえた追加の質問ができます。
2. エージェントに調べさせる。 エージェントモードでは、モデルがテーブルの索引を検索し、使うつもりのテーブルの定義を読み、ウェアハウスで下書きを試し、データベースが受け付けなかった部分を直してから答えます。
3. あるいは 1 ステップで書く。 パイプラインモードでは、Node のバックエンドが Elasticsearch からスキーマの限られた部分を取得し、モデルがそれをもとに 1 回の呼び出しで下書きを作ります。よくある質問のいくつかは、カタログに基づくルールが処理します。
4. 使用する前に確認してください。 エージェントの手順をリアルタイムで見守り、そのあと下書きを編集またはコピーし、返された行を確認し、文脈と前提を点検します。

作業台の上にあるもの

推測ではなく測定

SQL を書くツールは、その SQL が正しくなければ役に立ちません。そこでリポジトリでは、正しさを前提にせず実際に測定しています。

モデルベンチマークでは 46 の難問をそれぞれ 3 回ずつ尋ねます。正解が 1 つに決まる質問は、データを投入した PostgreSQL のウェアハウスのコピーでドラフトを実行して採点します。給与や解約など、ウェアハウスにないデータに関する質問には、聞き返すのが正しい対応です。データを変更する要求は、決してユーザーに届いてはいけません。

最も重要な指標は、モデルが自信を持って間違える頻度です。実行はできても誤った結果を返すドラフトや、存在しないデータについての回答がそれにあたります。どちらも本物の回答に見えるため、危険なのです。

各モデルは同じ質問に 2 回答えます。1 回目はウェアハウスが fact_account_balance_daily のような説明的な名前を使い、2 回目は F_ACCT_BAL_D のように古い銀行ウェアハウス風に略した分かりにくい名前を使います。列の説明は残します。データと正解は変わりません。

説明的な名前の場合

• gpt-oss-20b（アプリが使用するモデル）： 正答率 86%、自信を持った誤答 5 件、A100 1 基で毎分約 200 問。
• Qwen3.8-27B： 正答率 96% で自信を持った誤答はゼロ。ただし速度は約 5 分の 1。
• gpt-oss-120b： 20b より正確ではなく、速度は半分以下。

3 つのモデルはいずれも、聞き返すべき場面では必ず聞き返しました。また、gpt-oss-20b が試みた書き込みはすべて SQL チェックで阻止されました。

分かりにくい名前の場合

オープンモデルはどれも 22～39 ポイント下がりました。新たなミスは、読みやすい名前なら防げていたものでした。推測した列や、略称から読み違えたテーブルです。書き込みを通したオープンモデルはありませんでした。

• gpt-oss-20b： 正答率が 86% から 46% に下がり、自信を持った誤答は 17 件。
• Qwen3.8-27B： 最も優れたオープンモデルで、正答率 70%、自信を持った誤答 8 件。
• Gemini 3.8 Flash： 全体で最も優秀。推測するより聞き返すことを選んだため、正答率 72% で自信を持った誤答はわずか 1 件。
• Claude Sonnet 5、GPT-5.5、GPT-4.1： 正答率 68～70% だが、自信を持った誤答は 9～18 件。
• GPT-6 Luna： 慎重すぎて、69 問中 53 問に聞き返しで答え、正答率はわずか 22%。

クローズドモデルは比較のためだけに含めています。銀行自身のハードウェアでは動かせないため、OpenRouter 経由で呼び出します。オープンウェイトのモデルはレンタル GPU 上の vLLM で動かし、終了後に GPU を削除します。通常は 12 分以内、費用は 1 ドルを大きく下回ります。

エージェントかパイプラインか

10 月からアプリはエージェントとしても答えられるようになり、ベンチマークは同じ質問、データ、モデルで両方のモードを実行します。過去の日付時点でのレコードの履歴、日次レートでの通貨換算、中央値、全四半期に取引のあった顧客など、より難しい 17 問も加わりました。これらの実行は A100 上で分かりにくい名前を使い、各質問を 3 回ずつ尋ねています。

自信を持った誤答は、元の 23 問と、存在しないデータについての質問でのエージェントの誤りを数えたものです。回答時間は中央値です。比較として、パイプラインとして動かしたクローズドモデルの難しい質問での正答率は、Claude Sonnet 5 が 71%、Gemini 3.8 Flash が 69%、GPT-4.1 mini が 55%、GPT-4.1 が 49%、GPT-6 Luna が 22% でした。GPT-6 Luna はほとんどの質問で聞き返します。エージェントとして動かしたオープンモデルは、どれもパイプラインとして動かしたどのクローズドモデルより高い点を取りました。

向上の源

エージェントを分解し、gpt-oss-20b で元の 23 問を試すと、各部分の貢献が分かります。

• テーブルを調べることで安全になる: 何も実行しないうちから、自信を持った誤答が 17 件から 3〜4 件に減ります。パイプラインの検索では一度も返されなかったテーブルを、エージェントが見つけるからです。
• 下書きを試すことで正しくなる: SQL を実行できないと、下書きの約半数が失敗します。多くは日付テーブルの列を推測で書いたためです。データベースのエラーメッセージがあれば直せますし、行を 1 つも見ずに EXPLAIN だけで確認しても、向上のほぼすべてが保たれます。
• 業務ルールに測れる効果はない: エージェントは、渡される短い銀行業務ルールの一覧がなくても同じくらいの成績でした。
• 代償はトークンと時間: エージェントへの質問は、パイプラインへの質問の数倍のトークンを使い、2〜3 倍の時間がかかります。

難しい質問での gpt-oss-20b の誤りは、実行はできるが間違った答えを返す下書きで、試行では見つけられません。

すべての結果

アプリの Model tests タブには、記録されたすべての実行が残ります。以下の表は 2026 年 9 月 27 日のレポートからのもので、正答率の高い順に並んでいます。オープンウェイトのモデルは銀行自身のハードウェアで動かせますが、クローズドモデルは比較のため OpenRouter 経由で呼び出しました。

分かりにくい名前

説明的な名前

各質問は 3 回ずつ尋ねます。「正答」は、正解が 1 つに決まる質問への 69 件の回答のうち正しかった割合です。「自信を持った誤答」は、実行できたものの誤った結果を返したドラフトと、ウェアハウスにないデータについてのドラフトの数です。「聞き返し」は存在しないデータに関する質問への 18 件の回答が基準で、「危険な書き込み」はデータ変更の要求に対する 15 件の回答のうちユーザーに届いた数です。

ほかに 2 件の実行は採点対象外です。Gemma 4 26B は厳格な JSON 出力でループしました。これは品質ではなく提供時の不具合です。Devstral Small 2 は A100 ではそもそも動きません。

レポートには質問ごとの結果も載っており、分かりにくい名前の影響はそこで最もよく分かります。分かりにくい名前では、説明的な名前なら Qwen3.8-27B が毎回正解していた 5 つの質問に、どのモデルも答えられませんでした。たとえば、90 日を超えて延滞している貸付の件数です。

同じモデル、異なるサーバー

アプリは OpenAI 互換のエンドポイントであれば接続できるため、ホスト型プロバイダーから銀行自身のサーバーへの移行は単なる設定変更に見えます。本当にそうなのかを、別の評価ツールで検証しています。同じ gpt-oss-20b の重みを、ホスト型プロバイダー、CPU、そして llama.cpp、vLLM、SGLang を使ったレンタル GPU で提供しました。

どのサーバーも正しいテーブルを選びました。違いが現れたのは別の点です。ドラフトに追加される任意の結合、破壊的な要求がその場で拒否されるか後で SQL チェックに阻止されるか、そして負荷時の挙動です。vLLM は同時 64 リクエストでも厳格な JSON 形式を守り、RTX 4090 1 枚で毎分約 270 問に達しました。SGLang は負荷時にこの形式を崩し、より厳しい設定で起動するまで直りませんでした。この不具合は、1 件ずつのリクエストでは一度も現れませんでした。

別の実験では、カタログをメインフレーム風の略称に書き換えました。テーブルと列の説明を残した場合、両モデルとも 12 の基本質問にすべて合格しました。説明を削除すると合格は半分にとどまり、良いメタデータがモデルと同じくらい重要であることがはっきり示されました。

ギャラリー

ベンチマークから選んだ 10 の難問を、ワイドなデスクトップから小型スマートフォンまで表示しています。各 SQL ドラフトはアプリ自身のパイプラインとモデルが作成し、データを投入したウェアハウスで実行して検証しました。10 件すべてが正しい答えを返しました。スクリーンショットは記録済みの応答を再生したもので、再現可能であり、実際の銀行データは含みません。

人間は常にループの中にいます

アプリは SQL の下書きを書いて試しますが、それはウェアハウスの合成コピー上だけで、読み取りしかできないユーザーとしてです。実際の銀行ウェアハウスには一切接続しません。利用者はこれまでどおり結果を確認し、編集またはコピーして自分のデータベースクライアントで実行します。ブラウザーがモデルの API キーを受け取ることはありません。

自動チェックの対象は、読み取り専用ステートメントの基本形と既知のテーブル参照です。SQL の構文、列参照、業務上の意味は引き続き人による確認が必要です。ウェアハウス内の名称、関係、指標はすべて合成したテスト資料であり、承認済みの銀行業務定義ではありません。

ボンネットの下で

公開中の概念実証は、Node のバックエンド、Elasticsearch、読み取り専用の PostgreSQL ウェアハウスを、Oracle Ampere A1 インスタンス上の root 権限なしコンテナとして動かし、ホスティング事業者経由の gpt-oss-20b で SQL を書きます。リポジトリには将来のより広いアーキテクチャも記載されていますが、公開中の小さな POC とは明確に分けられています。