Bank DWH Studio

Питання стає тим, що ви можете перевірити

Bank DWH Studio — особистий доказ концепції для дослідження великого банківського сховища даних звичайною мовою. Поставте запитання, за бажання виберіть банківську предметну область і вирішіть, як на нього відповісти: агентом, який шукає таблиці й тестує свій SQL, або конвеєром, який отримує схему й складає SQL для PostgreSQL за один крок.

Результат навмисно більший, ніж блок коду. Поруч із редагованою чернеткою показано використані таблиці, тлумачення, припущення, примітки для перевірки й базові перевірки, а також рядки, які чернетка повертає із синтетичної копії сховища. Якщо бракує потрібної деталі, наприклад року в запиті про кінець серпня, асистент може перепитати.

Як це працює

1. Запитайте повсякденною мовою. Опишіть банківську відповідь, яка вам потрібна, за потреби звузьте пошук до предметної області й ставте уточнювальні запитання, що спираються на попередні відповіді.
2. Нехай агент пошукає. У режимі агента модель шукає в індексі таблиць, читає визначення тих, які збирається використати, тестує чернетку на сховищі й виправляє все, що відхиляє база даних, перш ніж відповісти.
3. Або складіть за один крок. У режимі конвеєра бекенд на Node отримує з Elasticsearch обмежену частину схеми, а модель складає чернетку на її основі за один виклик, тоді як правила на основі каталогу обробляють кілька поширених запитань.
4. Перегляньте перед використанням. Стежте за кроками агента наживо, потім редагуйте чи копіюйте чернетку, перевіряйте рядки, які вона повертає, і вивчайте її контекст і припущення.

Що на верстаку

Виміряно, а не припущено

Інструмент, що пише SQL, корисний лише тоді, коли цей SQL правильний, тому репозиторій вимірює це, а не приймає на віру.

Бенчмарк моделей ставить 46 складних запитань, кожне тричі. Запитання з єдиною правильною відповіддю оцінюються запуском чернетки на заповненій копії сховища в PostgreSQL. На запитання про дані, яких у сховищі немає, як-от зарплати чи відтік клієнтів, модель має відповісти зустрічним запитанням. Запити на зміну даних ніколи не мають дійти до користувача.

Найважливіший показник — як часто модель упевнено помиляється: чернетка, що виконується, але дає хибний результат, або відповідь про дані, яких не існує. Обидва випадки виглядають як справжні відповіді, і саме це робить їх ризикованими.

Кожна модель відповідає на ті самі запитання двічі. Спершу сховище використовує описові назви, як-от fact_account_balance_daily. Потім — криптичні назви, скорочені так, як їх пишуть старіші банківські сховища, як-от F_ACCT_BAL_D, зі збереженими описами стовпців. Дані та правильні відповіді не змінюються.

З описовими назвами

• gpt-oss-20b, модель, яку використовує застосунок: 86% правильних відповідей, 5 упевнено хибних і близько 200 запитань на хвилину на одному A100.
• Qwen3.8-27B: 96% правильних відповідей без жодної впевнено хибної, але приблизно вп’ятеро повільніше.
• gpt-oss-120b: не точніша за 20b і працює менш ніж удвічі повільніше.

Усі три просили уточнення щоразу, коли мали це робити, а перевірка SQL зупинила кожну спробу запису від gpt-oss-20b.

З криптичними назвами

Кожна відкрита модель втратила від 22 до 39 пунктів. Нові помилки були саме тими, яким запобігали зрозумілі назви: вгаданий стовпець або таблиця, хибно прочитана зі скорочення. Жодна відкрита модель не пропустила запис.

• gpt-oss-20b: впала з 86% до 46% правильних відповідей, маючи 17 упевнено хибних.
• Qwen3.8-27B: найкраща відкрита модель: 70% правильних і 8 упевнено хибних відповідей.
• Gemini 3.8 Flash: найкраща загалом: 72% правильних і лише одна впевнено хибна відповідь, бо вона радше перепитувала, ніж вгадувала.
• Claude Sonnet 5, GPT-5.5 і GPT-4.1: від 68 до 70% правильних, але з 9–18 упевнено хибними відповідями.
• GPT-6 Luna: перестаралася з обережністю: відповіла зустрічним запитанням на 53 з 69 запитань і вгадала лише 22%.

Закриті моделі наведено лише для порівняння. Вони не могли б працювати на власному обладнанні банку, тому їх викликають через OpenRouter. Моделі з відкритими вагами працюють на орендованому GPU з vLLM, який потім видаляється, — зазвичай до 12 хвилин і значно дешевше за долар.

Агент чи конвеєр

Від жовтня застосунок може відповідати і як агент, а бенчмарк запускає обидва режими на тих самих запитаннях, даних і моделі. Він додає 17 складніших запитань, як-от стан запису на минулу дату, конвертацію валют за щоденними курсами, медіани й клієнтів, активних у кожному кварталі. Ці прогони використовували криптичні назви на A100, і кожне запитання ставилося тричі.

Упевнено хибно — це помилки агента на 23 початкових запитаннях і на запитаннях про дані, яких немає. Час відповіді — медіана. Для порівняння: закриті моделі в режимі конвеєра на складніших запитаннях набрали: Claude Sonnet 5 — 71%, Gemini 3.8 Flash — 69%, GPT-4.1 mini — 55%, GPT-4.1 — 49%, GPT-6 Luna — 22%, бо на більшість із них вона перепитує. Кожна відкрита модель у режимі агента випередила кожну закриту модель у режимі конвеєра.

Звідки береться виграш

Якщо розібрати агента на частини, з gpt-oss-20b на 23 початкових запитаннях, видно внесок кожної частини.

• Пошук таблиць робить його безпечним: Упевнено хибних відповідей стає не 17, а 3 чи 4 ще до будь-якого виконання, бо агент знаходить таблиці, яких пошук конвеєра так і не повернув.
• Тестування чернетки робить його точним: Без змоги виконати свій SQL приблизно половина чернеток не працює, здебільшого через вигадані стовпці таблиці дат. Повідомлення бази даних про помилку достатньо, щоб їх виправити, а перевірка лише через EXPLAIN, не бачачи жодного рядка, зберігає майже весь виграш.
• Бізнес-правила не дають помітного ефекту: Агент упорався так само добре без короткого переліку банківських правил, який він отримує.
• Ціна — токени й час: Запитання до агента витрачає в кілька разів більше токенів, ніж запитання до конвеєра, і триває вдвічі-втричі довше.

На складніших запитаннях помилки gpt-oss-20b — це чернетки, які виконуються й повертають хибну відповідь, і тестування таких не виявляє.

Повні результати

Вкладка Model tests у застосунку зберігає кожен записаний запуск. Ці таблиці взято з її звіту від 27 вересня 2026 року, найточніші моделі — першими. Моделі з відкритими вагами могли б працювати на власному обладнанні банку; закриті моделі викликали через OpenRouter для порівняння.

Криптичні назви

Описові назви

Кожне запитання ставиться тричі. «Правильно» — це частка з 69 відповідей на запитання з єдиною правильною відповіддю. «Упевнено хибно» рахує чернетки, які виконалися й дали хибний результат, а також чернетки для даних, яких у сховищі немає. «Зустрічні запитання» рахуються з 18 відповідей на запитання про відсутні дані, а «небезпечні записи» показують, скільки з 15 відповідей на запити змінити дані дійшли до користувача.

Ще два запуски не оцінено. Gemma 4 26B зациклювалася за суворого JSON-виводу — це збій запуску, а не міра якості, — а Devstral Small 2 взагалі не запускається на A100.

Звіт також розбирає результати запитання за запитанням, і саме там видно ціну криптичних назв. З ними жодна модель не відповіла на п’ять запитань, які Qwen3.8-27B щоразу розв’язувала з описовими назвами, — наприклад, скільки кредитів були прострочені понад 90 днів.

Та сама модель, різні сервери

Застосунок працює з будь-яким OpenAI-сумісним endpoint, тож перехід від хмарного провайдера до власних серверів банку здається простою зміною конфігурації. Окремий інструмент оцінювання перевіряє, чи це справді так. Ті самі ваги gpt-oss-20b запускали в хмарного провайдера, на CPU та на орендованих GPU через llama.cpp, vLLM і SGLang.

Кожен сервер обрав правильні таблиці. Відмінності проявилися в іншому: які необов’язкові join додавала чернетка, чи деструктивний запит відхилявся одразу, чи його пізніше зупиняла перевірка SQL, а також під навантаженням. vLLM дотримувався суворого формату JSON при 64 одночасних запитах і досяг близько 270 запитань на хвилину на одній RTX 4090. SGLang порушував цей формат під навантаженням, доки його не запустили зі суворішим налаштуванням; при одиночних запитах ця помилка ніколи не з’являлася.

Інший експеримент переписав каталог скороченими назвами в стилі мейнфреймів. Зі збереженими описами таблиць і стовпців обидві моделі й далі пройшли всі дванадцять базових запитань. Без описів пройшла лише половина — чіткий знак, що якісні метадані важать не менше за модель.

Галерея

Десять складних запитань із бенчмарку — від широкого монітора до маленького телефона. Кожну чернетку SQL написали власний конвеєр і модель застосунку, а потім її перевірили запуском на заповненому сховищі; усі десять дали правильну відповідь. Знімки екрана відтворюють ці записані відповіді, тож вони відтворювані й не містять реальних банківських даних.

Людина залишається в курсі

Застосунок пише й тестує чернетки SQL, але лише на синтетичній копії сховища, від імені користувача, який може лише читати; до справжнього банківського сховища він ніколи не під'єднується. Користувачі й далі перевіряють результат, потім редагують чи копіюють його та запускають у власному клієнті бази даних. Браузер ніколи не отримує API-ключ моделі.

Автоматичні перевірки охоплюють базову форму інструкції лише для читання та посилання на відомі таблиці. Синтаксис SQL, посилання на стовпці та бізнес-зміст усе одно потребують перевірки людиною. Усі назви, зв’язки та показники у сховищі є синтетичними тестовими матеріалами, а не затвердженими банківськими визначеннями.

Під капотом

Розгорнутий доказ концепції запускає бекенд на Node, Elasticsearch і сховище PostgreSQL лише для читання як контейнери без root на екземплярі Oracle Ampere A1 і складає SQL за допомогою gpt-oss-20b через хмарного постачальника. Репозиторій також описує ширшу майбутню архітектуру, чітко відокремлену від меншого розгорнутого POC.