Bank DWH Studio

Una pregunta se convierte en algo que puedes inspeccionar.

Bank DWH Studio es una prueba de concepto personal para explorar un gran almacén de datos bancario en lenguaje natural. Haz una pregunta, elige si quieres un área bancaria y decide cómo se responde: un agente que consulta las tablas y prueba su SQL, o un pipeline que recupera el esquema y redacta SQL de PostgreSQL en un solo paso.

El resultado es, a propósito, más que un bloque de código. Junto al borrador editable muestra las tablas usadas, la interpretación, los supuestos, las notas de revisión y comprobaciones básicas, además de las filas que devuelve el borrador en una copia sintética del almacén. Cuando falta un dato necesario, como el año en una consulta sobre finales de agosto, el asistente puede pedir una aclaración.

como funciona

1. Pregunta en el lenguaje cotidiano. Describe la respuesta bancaria que necesitas, limita la búsqueda a un área cuando convenga y haz preguntas de seguimiento que partan de las respuestas anteriores.
2. Deja que el agente lo consulte. En modo agente, el modelo busca en un índice de tablas, lee las definiciones de las que piensa usar, prueba su borrador en el almacén y corrige lo que la base de datos rechace antes de responder.
3. O redacta en un solo paso. En modo pipeline, un backend Node recupera de Elasticsearch una parte acotada del esquema y el modelo redacta a partir de ella en una sola llamada, mientras unas reglas basadas en el catálogo resuelven algunas preguntas habituales.
4. Revisar antes de usar. Sigue los pasos del agente a medida que ocurren y después edita o copia el borrador, comprueba las filas que devuelve y revisa su contexto y sus supuestos.

¿Qué hay en el banco de trabajo?

Medido, no supuesto

Una herramienta que escribe SQL solo es útil si ese SQL es correcto, así que el repositorio lo mide en lugar de darlo por hecho.

Un benchmark de modelos plantea 46 preguntas difíciles, tres veces cada una. Las preguntas con una única respuesta correcta se puntúan ejecutando el borrador en una copia de PostgreSQL con datos del almacén. Las preguntas sobre datos que el almacén no contiene, como salarios o abandono de clientes, deberían recibir una pregunta de vuelta. Las solicitudes para modificar datos nunca deben llegar al usuario.

La cifra más importante es con qué frecuencia un modelo se equivoca con seguridad: un borrador que se ejecuta pero da un resultado erróneo, o una respuesta sobre datos que no existen. Ambos parecen respuestas reales, y eso es lo que los hace arriesgados.

Cada modelo responde dos veces a las mismas preguntas. Primero, el almacén usa nombres descriptivos, como fact_account_balance_daily. Después usa nombres crípticos, abreviados como los escriben los almacenes bancarios antiguos, como F_ACCT_BAL_D, conservando las descripciones de las columnas. Los datos y las respuestas correctas no cambian.

Con nombres descriptivos

• gpt-oss-20b, el modelo que usa la aplicación: 86 % de aciertos, 5 respuestas erróneas con seguridad y unas 200 preguntas por minuto en una sola A100.
• Qwen3.8-27B: 96 % de aciertos sin ninguna respuesta errónea con seguridad, pero unas cinco veces más lento.
• gpt-oss-120b: no es más preciso que el 20b y tiene menos de la mitad de su velocidad.

Los tres pidieron una aclaración siempre que debían, y la comprobación SQL detuvo todas las escrituras que intentó gpt-oss-20b.

Con nombres crípticos

Todos los modelos abiertos perdieron entre 22 y 39 puntos. Los nuevos errores fueron justo los que los nombres legibles evitaban: una columna adivinada o una tabla malinterpretada a partir de su abreviatura. Ningún modelo abierto dejó pasar una escritura.

• gpt-oss-20b: bajó del 86 % al 46 % de aciertos, con 17 respuestas erróneas con seguridad.
• Qwen3.8-27B: el mejor modelo abierto, con un 70 % de aciertos y 8 respuestas erróneas con seguridad.
• Gemini 3.8 Flash: el mejor de todos, con un 72 % de aciertos y solo una respuesta errónea con seguridad, porque prefirió preguntar a adivinar.
• Claude Sonnet 5, GPT-5.5 y GPT-4.1: entre un 68 y un 70 % de aciertos, pero con 9 a 18 respuestas erróneas con seguridad.
• GPT-6 Luna: llevó la prudencia demasiado lejos: respondió con una pregunta en 53 de 69 casos y solo acertó el 22 %.

Los modelos cerrados están solo para comparar. No podrían ejecutarse en el hardware propio de un banco, así que se llaman a través de OpenRouter. Los modelos de pesos abiertos se ejecutan en una GPU alquilada con vLLM, que se elimina al terminar, normalmente en 12 minutos como mucho y por bastante menos de un dólar.

Agente o pipeline

Desde octubre la aplicación también puede responder como agente, y el benchmark ejecuta ambos modos con las mismas preguntas, datos y modelo. Añade 17 preguntas más difíciles, como el historial de un registro en una fecha pasada, la conversión de divisas con tipos diarios, medianas y los clientes activos en todos los trimestres. Estas ejecuciones usaron nombres crípticos, en una A100, y cada pregunta se hizo tres veces.

Errores con seguridad cuenta los fallos del agente en las 23 preguntas originales y en las preguntas sobre datos que faltan. El tiempo de respuesta es la mediana. Como comparación, los modelos cerrados trabajando como pipeline obtuvieron en las preguntas más difíciles: Claude Sonnet 5 un 71 %, Gemini 3.8 Flash un 69 %, GPT-4.1 mini un 55 %, GPT-4.1 un 49 % y GPT-6 Luna un 22 %, porque en la mayoría pregunta de vuelta. Todos los modelos abiertos trabajando como agente superaron a todos los modelos cerrados trabajando como pipeline.

De dónde sale la mejora

Al desmontar el agente, con gpt-oss-20b en las 23 preguntas originales, se ve lo que aporta cada parte.

• Consultar las tablas lo hace seguro: Las respuestas erróneas con seguridad bajan de 17 a 3 o 4 antes de ejecutar nada, porque el agente encuentra tablas que la búsqueda del pipeline nunca devolvió.
• Probar el borrador lo hace correcto: Sin poder ejecutar su SQL, cerca de la mitad de los borradores fallan, sobre todo por columnas inventadas de la tabla de fechas. El mensaje de error de la base de datos basta para corregirlos, y comprobar solo con EXPLAIN, sin ver ni una fila, conserva casi toda la mejora.
• Las reglas de negocio no aportan nada medible: El agente rindió igual sin la breve lista de reglas bancarias que recibe.
• El coste son tokens y tiempo: Una pregunta al agente usa varias veces los tokens de una pregunta al pipeline y tarda de dos a tres veces más.

En las preguntas más difíciles, los fallos de gpt-oss-20b son borradores que se ejecutan y devuelven una respuesta errónea, algo que las pruebas no pueden detectar.

Todos los resultados

La pestaña Model tests de la aplicación guarda cada ejecución registrada. Estas tablas proceden de su informe del 27 de septiembre de 2026, con los más acertados primero. Los modelos de pesos abiertos podrían ejecutarse en el hardware propio de un banco; los cerrados se llamaron a través de OpenRouter para comparar.

Nombres crípticos

Nombres descriptivos

Cada pregunta se plantea tres veces. Aciertos es el porcentaje de 69 respuestas a preguntas con una única respuesta correcta. Errores con seguridad cuenta los borradores que se ejecutaron y dieron un resultado erróneo, más los borradores sobre datos que el almacén no contiene. Preguntas de vuelta se mide sobre 18 respuestas a preguntas sobre datos que faltan, y escrituras inseguras cuenta cuántas de las 15 respuestas a peticiones de modificar datos llegaron al usuario.

Otras dos ejecuciones no se puntúan. Gemma 4 26B entró en bucle con la salida JSON estricta, un fallo al servirlo y no una medida de calidad, y Devstral Small 2 no llega a ejecutarse en una A100.

El informe también desglosa los resultados pregunta por pregunta, y ahí se ve lo que cuestan los nombres crípticos. Con ellos, ningún modelo respondió cinco preguntas que Qwen3.8-27B acertaba siempre con nombres descriptivos, como cuántos préstamos tenían más de 90 días de impago.

El mismo modelo, servidores distintos

La aplicación se comunica con cualquier endpoint compatible con OpenAI, así que pasar de un proveedor alojado a los servidores propios de un banco parece un simple cambio de configuración. Una herramienta de evaluación independiente comprueba si realmente lo es. Los mismos pesos de gpt-oss-20b se sirvieron desde un proveedor alojado, en CPU y en GPU alquiladas con llama.cpp, vLLM y SGLang.

Todos los servidores eligieron las tablas correctas. Las diferencias aparecieron en otros puntos: en los joins opcionales que añadía un borrador, en si una solicitud destructiva se rechazaba o la detenía después la comprobación SQL, y bajo carga. vLLM mantuvo el formato JSON estricto con 64 solicitudes simultáneas y alcanzó unas 270 preguntas por minuto en una sola RTX 4090. SGLang rompió ese formato bajo carga hasta que se inició con un ajuste más estricto, un fallo que nunca apareció con una sola solicitud a la vez.

Otro experimento reescribió el catálogo con nombres abreviados al estilo mainframe. Conservando las descripciones de tablas y columnas, ambos modelos siguieron superando las doce preguntas de referencia. Sin las descripciones, solo la mitad las superó: una señal clara de que unos buenos metadatos importan tanto como el modelo.

Galería

Diez preguntas difíciles del benchmark, desde un escritorio ancho hasta un móvil pequeño. Cada borrador SQL lo escribió el propio flujo y modelo de la aplicación, y después se verificó ejecutándolo en el almacén con datos; las diez dieron la respuesta correcta. Las capturas reproducen esas respuestas grabadas, así que son repetibles y no contienen datos bancarios reales.

El ser humano se mantiene informado

La aplicación escribe y prueba borradores SQL, pero solo en una copia sintética del almacén y como un usuario que solo puede leer; nunca se conecta a un almacén bancario real. Los usuarios siguen revisando el resultado y después lo editan o lo copian y lo ejecutan en su propio cliente de base de datos. El navegador nunca recibe la clave de API del modelo.

Las comprobaciones automáticas cubren la estructura de una instrucción de solo lectura y las referencias a tablas conocidas. La sintaxis SQL, las referencias de columnas y el significado de negocio todavía requieren revisión humana. Todos los nombres, relaciones e indicadores del almacén son material de prueba sintético, no definiciones bancarias aprobadas.

Debajo del capó

La prueba de concepto desplegada ejecuta un backend Node, Elasticsearch y el almacén PostgreSQL de solo lectura como contenedores sin root en una instancia Oracle Ampere A1, y redacta SQL con gpt-oss-20b a través de un proveedor alojado. El repositorio también documenta una arquitectura futura más amplia, claramente separada del POC desplegado, más pequeño.