Bank DWH Studio

O întrebare devine un rezultat pe care îl poți verifica

Bank DWH Studio este o dovadă de concept personală pentru explorarea unui depozit mare de date bancare prin limbaj natural. Pui o întrebare, alegi opțional un domeniu bancar și decizi cum primești răspunsul: un agent care caută tabelele și își testează SQL-ul sau un pipeline care preia schema și redactează SQL PostgreSQL dintr-un singur pas.

Rezultatul este, intenționat, mai mult decât un bloc de cod. Lângă schița editabilă apar tabelele folosite, interpretarea, ipotezele, notele de verificare și controalele de bază, împreună cu rândurile pe care schița le întoarce dintr-o copie sintetică a depozitului. Când lipsește un detaliu necesar, cum ar fi anul într-o cerere despre sfârșitul lui august, asistentul poate cere o clarificare.

Cum funcționează

1. Întreabă în limbaj obișnuit. Descrie răspunsul bancar de care ai nevoie, restrânge căutarea la un domeniu când e util și pune întrebări suplimentare care pornesc de la răspunsurile anterioare.
2. Lasă agentul să caute. În modul agent, modelul caută într-un index al tabelelor, citește definițiile celor pe care vrea să le folosească, își testează schița pe depozit și repară tot ce respinge baza de date înainte să răspundă.
3. Sau redactează dintr-un singur pas. În modul pipeline, un backend Node preia din Elasticsearch o porțiune limitată a schemei, iar modelul redactează pe baza ei într-un singur apel, în timp ce reguli bazate pe catalog acoperă câteva întrebări obișnuite.
4. Verifică înainte de utilizare. Urmărește pașii agentului pe măsură ce au loc, apoi editează sau copiază schița, verifică rândurile pe care le întoarce și analizează contextul și ipotezele.

Ce se află pe bancul de lucru

Măsurat, nu presupus

Un instrument care scrie SQL este util doar dacă SQL-ul este corect, așa că repository-ul măsoară acest lucru în loc să-l ia de bun.

Un benchmark de modele pune 46 de întrebări dificile, de câte trei ori fiecare. Întrebările cu un singur răspuns corect sunt evaluate rulând schița pe o copie PostgreSQL populată a depozitului de date. Întrebările despre date pe care depozitul nu le conține, cum ar fi salariile sau pierderea clienților, ar trebui să primească o întrebare înapoi. Cererile de modificare a datelor nu trebuie să ajungă niciodată la utilizator.

Cea mai importantă cifră este cât de des un model greșește cu încredere: o schiță care rulează, dar dă un răspuns greșit, sau un răspuns despre date care nu există. Ambele arată ca răspunsuri reale și tocmai de aceea sunt riscante.

Fiecare model răspunde de două ori la aceleași întrebări. Prima dată, depozitul de date folosește nume descriptive, cum ar fi fact_account_balance_daily. A doua oară folosește nume criptice, abreviate cum le scriu depozitele bancare mai vechi, cum ar fi F_ACCT_BAL_D, cu descrierile coloanelor păstrate. Datele și răspunsurile corecte rămân aceleași.

Cu nume descriptive

• gpt-oss-20b, modelul folosit de aplicație: 86% corecte, 5 răspunsuri greșite cu încredere și aproximativ 200 de întrebări pe minut pe un singur A100.
• Qwen3.8-27B: 96% corecte, fără niciun răspuns greșit cu încredere, dar de aproximativ cinci ori mai lent.
• gpt-oss-120b: nu este mai precis decât 20b și are mai puțin de jumătate din viteza lui.

Toate trei au cerut clarificări de fiecare dată când trebuiau, iar verificarea SQL a oprit orice scriere încercată de gpt-oss-20b.

Cu nume criptice

Fiecare model deschis a pierdut între 22 și 39 de puncte. Greșelile noi au fost exact cele pe care numele lizibile le preveneau: o coloană ghicită sau un tabel înțeles greșit din abreviere. Niciun model deschis nu a lăsat să treacă o scriere.

• gpt-oss-20b: a scăzut de la 86% la 46% răspunsuri corecte, cu 17 răspunsuri greșite cu încredere.
• Qwen3.8-27B: cel mai bun model deschis, cu 70% corecte și 8 răspunsuri greșite cu încredere.
• Gemini 3.8 Flash: cel mai bun dintre toate, cu 72% corecte și un singur răspuns greșit cu încredere, pentru că a preferat să întrebe în loc să ghicească.
• Claude Sonnet 5, GPT-5.5 și GPT-4.1: între 68 și 70% corecte, dar cu 9 până la 18 răspunsuri greșite cu încredere.
• GPT-6 Luna: a exagerat cu prudența: a răspuns cu o întrebare la 53 din 69 de întrebări și a nimerit doar 22%.

Modelele închise sunt incluse doar pentru comparație. Nu ar putea rula pe hardware-ul propriu al unei bănci, așa că sunt apelate prin OpenRouter. Modelele cu ponderi deschise rulează pe un GPU închiriat, cu vLLM, care este șters la final, de obicei în cel mult 12 minute și pentru mult sub un dolar.

Agent sau pipeline

Din octombrie, aplicația poate răspunde și ca agent, iar benchmarkul rulează ambele moduri pe aceleași întrebări, date și model. Adaugă 17 întrebări mai grele, de exemplu istoricul unei înregistrări la o dată din trecut, conversia valutară cu cursuri zilnice, mediane și clienții activi în fiecare trimestru. Aceste rulări au folosit nume criptice, pe un A100, fiecare întrebare fiind pusă de trei ori.

Greșite cu încredere numără greșelile agentului la cele 23 de întrebări inițiale și la întrebările despre date care lipsesc. Timpul de răspuns este mediana. Pentru comparație, modelele închise care lucrează ca pipeline au obținut la întrebările mai grele: Claude Sonnet 5 71%, Gemini 3.8 Flash 69%, GPT-4.1 mini 55%, GPT-4.1 49% și GPT-6 Luna 22%, fiindcă la cele mai multe întreabă înapoi. Fiecare model deschis care lucrează ca agent a obținut mai mult decât orice model închis care lucrează ca pipeline.

De unde vine câștigul

Desfăcând agentul în bucăți, cu gpt-oss-20b pe cele 23 de întrebări inițiale, se vede ce aduce fiecare parte.

• Căutarea tabelelor îl face sigur: Răspunsurile greșite cu încredere scad de la 17 la 3 sau 4 înainte să se ruleze ceva, pentru că agentul găsește tabele pe care căutarea pipeline-ului nu le-a întors niciodată.
• Testarea schiței îl face corect: Fără posibilitatea de a-și rula SQL-ul, cam jumătate dintre schițe eșuează, mai ales pe coloane ghicite din tabelul de date calendaristice. Mesajul de eroare al bazei de date e suficient pentru a le repara, iar verificarea doar cu EXPLAIN, fără a vedea niciun rând, păstrează aproape tot câștigul.
• Regulile de business nu aduc nimic măsurabil: Agentul s-a descurcat la fel de bine și fără lista scurtă de reguli bancare pe care o primește.
• Costul înseamnă tokeni și timp: O întrebare pentru agent folosește de câteva ori mai mulți tokeni decât una pentru pipeline și durează de două-trei ori mai mult.

La întrebările mai grele, greșelile lui gpt-oss-20b sunt schițe care rulează și întorc un răspuns greșit, pe care testarea nu le poate prinde.

Rezultatele complete

Fila Model tests a aplicației păstrează fiecare rulare înregistrată. Tabelele de mai jos provin din raportul ei din 27 septembrie 2026, cu cele mai precise modele primele. Modelele cu ponderi deschise ar putea rula pe hardware-ul propriu al unei bănci; modelele închise au fost apelate prin OpenRouter, pentru comparație.

Nume criptice

Nume descriptive

Fiecare întrebare este pusă de trei ori. Corecte înseamnă procentul din cele 69 de răspunsuri la întrebări cu un singur răspuns corect. Greșite cu încredere numără schițele care au rulat și au dat un răspuns greșit, plus schițele pentru date pe care depozitul nu le conține. Întrebări înapoi se raportează la 18 răspunsuri la întrebări despre date lipsă, iar scrieri nesigure arată câte dintre cele 15 răspunsuri la cereri de modificare a datelor au ajuns la utilizator.

Alte două rulări nu sunt punctate. Gemma 4 26B a intrat în buclă sub ieșirea JSON strictă, o problemă de servire, nu o măsură a calității, iar Devstral Small 2 nu rulează deloc pe un A100.

Raportul detaliază rezultatele și întrebare cu întrebare, iar acolo se vede costul numelor criptice. Cu ele, niciun model nu a răspuns la cinci întrebări pe care Qwen3.8-27B le-a nimerit de fiecare dată cu nume descriptive, cum ar fi câte credite aveau peste 90 de zile de întârziere.

Același model, servere diferite

Aplicația comunică cu orice endpoint compatibil OpenAI, așa că trecerea de la un furnizor găzduit la serverele proprii ale unei bănci pare o simplă schimbare de configurare. Un sistem separat de evaluare verifică dacă chiar așa este. Aceleași ponderi gpt-oss-20b au fost servite de un furnizor găzduit, pe CPU și pe GPU-uri închiriate prin llama.cpp, vLLM și SGLang.

Fiecare server a ales tabelele corecte. Diferențele au apărut în altă parte: în joinurile opționale adăugate de o schiță, în faptul că o cerere distructivă a fost refuzată sau oprită mai târziu de verificarea SQL și sub sarcină. vLLM a respectat formatul JSON strict cu 64 de cereri simultane și a ajuns la aproximativ 270 de întrebări pe minut pe un singur RTX 4090. SGLang a încălcat acest format sub sarcină până când a fost pornit cu o setare mai strictă, o eroare care nu a apărut niciodată cu o singură cerere odată.

Un alt experiment a rescris catalogul cu nume abreviate, în stil mainframe. Cu descrierile tabelelor și coloanelor păstrate, ambele modele au trecut toate cele douăsprezece întrebări de bază. Fără descrieri, doar jumătate au trecut, un semn clar că metadatele bune contează la fel de mult ca modelul.

Galerie

Zece întrebări dificile din benchmark, de la un desktop lat la un telefon mic. Fiecare schiță SQL a fost scrisă de fluxul și modelul aplicației, apoi verificată prin rulare pe depozitul populat; toate zece au dat răspunsul corect. Capturile de ecran redau aceste răspunsuri înregistrate, deci sunt reproductibile și nu conțin date bancare reale.

Omul păstrează controlul

Aplicația scrie și testează schițe SQL, dar doar pe o copie sintetică a depozitului, ca un utilizator care poate doar să citească; nu se conectează niciodată la un depozit bancar real. Utilizatorii verifică în continuare rezultatul, apoi îl editează sau îl copiază și îl rulează în propriul client de baze de date. Browserul nu primește niciodată cheia API a modelului.

Verificările automate acoperă forma instrucțiunilor doar pentru citire și referințele la tabele cunoscute. Sintaxa SQL, referințele la coloane și semnificația de business necesită în continuare verificare umană. Toate numele, relațiile și indicatorii din depozitul inclus în proiect sunt date sintetice pentru testare, nu definiții bancare aprobate.

Cum este construit

Dovada de concept publicată rulează un backend Node, Elasticsearch și depozitul PostgreSQL doar pentru citire ca containere fără root pe o instanță Oracle Ampere A1 și redactează SQL cu gpt-oss-20b printr-un furnizor găzduit. Depozitul de cod documentează și o arhitectură viitoare mai amplă, clar separată de POC-ul publicat, mai mic.