Bank DWH Studio

Eine Frage wird zu etwas, das Sie untersuchen können

Bank DWH Studio ist ein persönlicher Machbarkeitsnachweis, um ein großes Bank-Data-Warehouse in natürlicher Sprache zu erkunden. Sie stellen eine Frage, wählen bei Bedarf einen Bankbereich und entscheiden, wie sie beantwortet wird: von einem Agenten, der Tabellen nachschlägt und sein SQL testet, oder von einer Pipeline, die das Schema abruft und PostgreSQL-SQL in einem Schritt entwirft.

Das Ergebnis ist bewusst mehr als ein Codeblock. Neben dem bearbeitbaren Entwurf stehen die verwendeten Tabellen, die Interpretation, Annahmen, Prüfhinweise und einfache Kontrollen, dazu die Zeilen, die der Entwurf aus einer synthetischen Kopie des Warehouse liefert. Fehlt eine nötige Angabe, etwa das Jahr bei einer Frage zum Ende August, kann der Assistent nachfragen.

Wie es funktioniert

1. Fragen Sie in der Alltagssprache. Beschreiben Sie die Bankauswertung, die Sie brauchen, grenzen Sie die Suche bei Bedarf auf einen Bereich ein und stellen Sie Folgefragen, die auf den bisherigen Antworten aufbauen.
2. Den Agenten nachschlagen lassen. Im Agentenmodus durchsucht das Modell einen Tabellenindex, liest die Definitionen der Tabellen, die es verwenden will, testet seinen Entwurf am Warehouse und behebt alles, was die Datenbank ablehnt, bevor es antwortet.
3. Oder in einem Schritt entwerfen. Im Pipeline-Modus holt ein Node-Backend einen begrenzten Ausschnitt des Schemas aus Elasticsearch, und das Modell entwirft daraus in einem einzigen Aufruf, während katalogbasierte Regeln einige häufige Fragen abdecken.
4. Vor der Verwendung überprüfen. Verfolgen Sie die Schritte des Agenten live, bearbeiten oder kopieren Sie dann den Entwurf, prüfen Sie die zurückgegebenen Zeilen und sehen Sie sich Kontext und Annahmen an.

Was liegt auf der Werkbank?

Gemessen, nicht angenommen

Ein Werkzeug, das SQL schreibt, ist nur so nützlich, wie sein SQL korrekt ist. Deshalb misst das Repository genau das, statt es einfach anzunehmen.

Ein Modell-Benchmark stellt 46 schwierige Fragen, jede dreimal. Fragen mit genau einer richtigen Antwort werden bewertet, indem der Entwurf gegen eine befüllte PostgreSQL-Kopie des Warehouse ausgeführt wird. Fragen zu Daten, die das Warehouse nicht enthält, etwa Gehälter oder Kundenabwanderung, sollten mit einer Rückfrage beantwortet werden. Anfragen, Daten zu ändern, dürfen den Nutzer nie erreichen.

Die wichtigste Zahl ist, wie oft ein Modell selbstsicher falsch liegt: ein Entwurf, der läuft, aber das falsche Ergebnis liefert, oder eine Antwort zu Daten, die es nicht gibt. Beides sieht wie eine echte Antwort aus, und genau das macht es riskant.

Jedes Modell beantwortet dieselben Fragen zweimal. Zuerst verwendet das Warehouse beschreibende Namen wie fact_account_balance_daily. Dann verwendet es kryptische Namen, abgekürzt wie in älteren Bank-Warehouses, etwa F_ACCT_BAL_D, wobei die Spaltenbeschreibungen erhalten bleiben. Die Daten und die richtigen Antworten bleiben gleich.

Mit beschreibenden Namen

• gpt-oss-20b, das Modell der App: 86 % richtig, 5 selbstsicher falsche Antworten und rund 200 Fragen pro Minute auf einer A100.
• Qwen3.8-27B: 96 % richtig ohne selbstsicher falsche Antworten, aber etwa fünfmal langsamer.
• gpt-oss-120b: nicht genauer als das 20b, bei weniger als halber Geschwindigkeit.

Alle drei fragten jedes Mal nach, wenn sie es sollten, und die SQL-Prüfung fing jeden Schreibversuch von gpt-oss-20b ab.

Mit kryptischen Namen

Jedes offene Modell verlor zwischen 22 und 39 Punkte. Die neuen Fehler waren genau die, die lesbare Namen verhindert hatten: eine geratene Spalte oder eine Tabelle, die aus ihrer Abkürzung falsch gedeutet wurde. Keines der offenen Modelle ließ einen Schreibzugriff durch.

• gpt-oss-20b: fiel von 86 % auf 46 % richtige Antworten, mit 17 selbstsicher falschen Antworten.
• Qwen3.8-27B: das beste offene Modell, mit 70 % richtig und 8 selbstsicher falschen Antworten.
• Gemini 3.8 Flash: das beste insgesamt, mit 72 % richtig und nur einer selbstsicher falschen Antwort, weil es lieber nachfragte als riet.
• Claude Sonnet 5, GPT-5.5 und GPT-4.1: 68 bis 70 % richtig, aber mit 9 bis 18 selbstsicher falschen Antworten.
• GPT-6 Luna: übertrieb die Vorsicht: fragte bei 53 von 69 Fragen zurück und lag nur bei 22 % richtig.

Die geschlossenen Modelle dienen nur zum Vergleich. Sie könnten nicht auf der eigenen Hardware einer Bank laufen und werden deshalb über OpenRouter aufgerufen. Modelle mit offenen Gewichten laufen auf einer gemieteten GPU mit vLLM, die danach wieder gelöscht wird, meist innerhalb von 12 Minuten und für deutlich weniger als einen Dollar.

Agent oder Pipeline

Seit Oktober kann die App auch als Agent antworten, und der Benchmark lässt beide Modi mit denselben Fragen, Daten und Modellen laufen. Er ergänzt 17 schwierigere Fragen, etwa den Stand eines Datensatzes zu einem früheren Datum, Währungsumrechnung mit Tageskursen, Mediane und Kunden, die in jedem Quartal aktiv waren. Diese Läufe nutzten kryptische Namen auf einer A100, und jede Frage wurde dreimal gestellt.

Selbstsicher falsch zählt die Fehler des Agenten bei den ursprünglichen 23 Fragen und bei den Fragen zu fehlenden Daten. Die Antwortzeit ist der Median. Zum Vergleich erreichten die geschlossenen Modelle als Pipeline bei den schwierigeren Fragen: Claude Sonnet 5 71 %, Gemini 3.8 Flash 69 %, GPT-4.1 mini 55 %, GPT-4.1 49 % und GPT-6 Luna 22 %, weil es bei den meisten nachfragt. Jedes offene Modell als Agent schnitt besser ab als jedes geschlossene Modell als Pipeline.

Woher der Gewinn kommt

Zerlegt man den Agenten, mit gpt-oss-20b bei den ursprünglichen 23 Fragen, zeigt sich, was jeder Teil beiträgt.

• Das Nachschlagen macht ihn sicher: Selbstsicher falsche Antworten sinken von 17 auf 3 oder 4, noch bevor etwas ausgeführt wird, weil der Agent Tabellen findet, die die Suche der Pipeline nie geliefert hat.
• Das Testen macht ihn richtig: Ohne die Möglichkeit, sein SQL auszuführen, scheitert etwa die Hälfte der Entwürfe, meist an geratenen Spalten der Datumstabelle. Die Fehlermeldung der Datenbank genügt, um sie zu beheben, und schon eine Prüfung allein mit EXPLAIN, ohne eine einzige Zeile zu sehen, erhält fast den ganzen Gewinn.
• Die Geschäftsregeln bringen nichts Messbares: Der Agent schnitt ohne die kurze Liste von Bankregeln, die er erhält, genauso gut ab.
• Der Preis sind Tokens und Zeit: Eine Agentenfrage verbraucht ein Mehrfaches an Tokens einer Pipelinefrage und dauert zwei- bis dreimal so lange.

Bei den schwierigeren Fragen sind die Fehler von gpt-oss-20b Entwürfe, die laufen und das falsche Ergebnis liefern, was Testen nicht aufdecken kann.

Alle Ergebnisse

Der Tab Model tests der App speichert jeden aufgezeichneten Lauf. Diese Tabellen stammen aus seinem Bericht vom 27. September 2026, die genauesten Modelle zuerst. Modelle mit offenen Gewichten könnten auf der eigenen Hardware einer Bank laufen; geschlossene Modelle wurden zum Vergleich über OpenRouter aufgerufen.

Kryptische Namen

Beschreibende Namen

Jede Frage wird dreimal gestellt. Richtig ist der Anteil an 69 Antworten auf Fragen mit genau einer richtigen Antwort. Selbstsicher falsch zählt Entwürfe, die liefen und ein falsches Ergebnis lieferten, plus Entwürfe zu Daten, die das Warehouse nicht enthält. Rückfragen bezieht sich auf 18 Antworten zu Fragen nach fehlenden Daten, und unsichere Schreibzugriffe zählt, wie viele von 15 Antworten auf Änderungswünsche den Nutzer erreichten.

Zwei weitere Läufe sind nicht gewertet. Gemma 4 26B lief bei strikter JSON-Ausgabe in eine Schleife – ein Bereitstellungsfehler, kein Qualitätsmaß –, und Devstral Small 2 läuft auf einer A100 überhaupt nicht.

Der Bericht schlüsselt die Ergebnisse auch Frage für Frage auf, und dort zeigt sich, was kryptische Namen kosten. Mit ihnen beantwortete kein Modell fünf Fragen, die Qwen3.8-27B mit beschreibenden Namen jedes Mal richtig beantwortete, etwa wie viele Kredite mehr als 90 Tage überfällig waren.

Gleiches Modell, verschiedene Server

Die App spricht mit jedem OpenAI-kompatiblen Endpunkt. Der Wechsel von einem gehosteten Anbieter zu den eigenen Servern einer Bank wirkt daher wie eine einfache Konfigurationsänderung. Ein separates Evaluierungswerkzeug prüft, ob das wirklich stimmt. Dieselben gpt-oss-20b-Gewichte liefen bei einem gehosteten Anbieter, auf CPU und auf gemieteten GPUs mit llama.cpp, vLLM und SGLang.

Jeder Server wählte die richtigen Tabellen. Die Unterschiede zeigten sich anderswo: bei den optionalen Joins in einem Entwurf, darin, ob eine destruktive Anfrage abgelehnt oder erst später von der SQL-Prüfung abgefangen wurde, und unter Last. vLLM hielt das strikte JSON-Format mit 64 gleichzeitigen Anfragen ein und erreichte rund 270 Fragen pro Minute auf einer einzigen RTX 4090. SGLang brach das Format unter Last, bis es mit einer strengeren Einstellung gestartet wurde – ein Fehler, der bei einzelnen Anfragen nie auftrat.

Ein weiteres Experiment schrieb den Katalog mit abgekürzten Namen im Mainframe-Stil um. Mit den Beschreibungen der Tabellen und Spalten bestanden beide Modelle weiterhin alle zwölf Basisfragen. Ohne Beschreibungen bestand nur die Hälfte – ein deutliches Zeichen, dass gute Metadaten so wichtig sind wie das Modell.

Galerie

Zehn schwierige Fragen aus dem Benchmark, vom breiten Desktop bis zum kleinen Smartphone. Jeder SQL-Entwurf wurde von der Pipeline und dem Modell der App geschrieben und dann durch Ausführung gegen das befüllte Warehouse geprüft; alle zehn lieferten das richtige Ergebnis. Die Screenshots zeigen diese aufgezeichneten Antworten erneut, sind daher reproduzierbar und enthalten keine echten Bankdaten.

Der Mensch bleibt auf dem Laufenden

Die App schreibt und testet SQL-Entwürfe, aber nur an einer synthetischen Kopie des Warehouse und als Benutzer, der nur lesen darf; mit einem echten Bank-Warehouse verbindet sie sich nie. Nutzer prüfen das Ergebnis weiterhin, bearbeiten oder kopieren es und führen es in ihrem eigenen Datenbankclient aus. Der Browser erhält nie den API-Schlüssel des Modells.

Automatisierte Prüfungen decken die schreibgeschützte Form der Anweisung und Verweise auf bekannte Tabellen ab. SQL-Syntax, Spaltenverweise und fachliche Bedeutung müssen weiterhin von Menschen geprüft werden. Alle Namen, Beziehungen und Kennzahlen im Warehouse sind synthetisches Testmaterial und keine freigegebenen bankfachlichen Definitionen.

Unter der Haube

Der bereitgestellte Machbarkeitsnachweis betreibt ein Node-Backend, Elasticsearch und das schreibgeschützte PostgreSQL-Warehouse als rootlose Container auf einer Oracle-Ampere-A1-Instanz und entwirft SQL mit gpt-oss-20b über einen gehosteten Anbieter. Das Repository dokumentiert außerdem eine umfassendere künftige Architektur, klar getrennt vom kleineren bereitgestellten POC.