Cómo conversar con tu base de datos usando IA: un generador de SQL a partir de lenguaje natural

JhonyVargas — Sat, 04 Jul 2026 21:12:35 +0000

Artículo técnico — Unidad 3, Base de Datos II

Introducción

Una de las barreras más comunes entre las personas de negocio y sus datos es
el propio SQL: saber que existe la información no sirve de mucho si hay que
escribir un JOIN para llegar a ella. En los últimos años, los modelos de
lenguaje (LLMs) han empezado a cerrar esa brecha con la tarea conocida como
Text-to-SQL: el usuario escribe una pregunta en lenguaje natural y el
modelo genera la consulta SQL correspondiente.

En este artículo muestro una implementación pequeña pero completa de este
patrón, usando un modelo público de Hugging Face, una base de datos SQLite de
ejemplo y una capa de validación que evita que la IA ejecute algo peligroso.
El código completo está disponible en el repositorio público enlazado al
final.

Arquitectura

pregunta (ingles)
   -> modelo T5 afinado en WikiSQL (Hugging Face)
   -> SQL "crudo" generado por el modelo
   -> adaptacion (nombre de tabla real + comillas en valores) y validacion (solo SELECT)
   -> ejecucion en modo solo-lectura sobre SQLite
   -> resultado tabular

La base de datos de ejemplo simula las ventas de una tienda de tecnología,
con una tabla ventas que incluye producto, categoría, precio, cantidad,
ciudad, cliente y fecha:

CREATE TABLE ventas (
    id INTEGER PRIMARY KEY,
    product TEXT NOT NULL,
    category TEXT NOT NULL,
    price REAL NOT NULL,
    quantity INTEGER NOT NULL,
    city TEXT NOT NULL,
    customer TEXT NOT NULL,
    sale_date TEXT NOT NULL
)

El modelo: Hugging Face + T5 afinado en WikiSQL

Para generar SQL usé mrm8488/t5-base-finetuned-wikiSQL, un modelo T5
disponible en Hugging Face y entrenado sobre el dataset WikiSQL. Se usa así:

from transformers import T5ForConditionalGeneration, T5Tokenizer

MODEL_NAME = "mrm8488/t5-base-finetuned-wikiSQL"

class TextToSQL:
    def __init__(self, model_name: str = MODEL_NAME):
        self.tokenizer = T5Tokenizer.from_pretrained(model_name)
        self.model = T5ForConditionalGeneration.from_pretrained(model_name)

    def generate(self, question: str) -> str:
        prompt = f"translate English to SQL: {question} </s>"
        features = self.tokenizer([prompt], return_tensors="pt")
        output_ids = self.model.generate(
            input_ids=features["input_ids"],
            attention_mask=features["attention_mask"],
            max_length=128,
        )
        return self.tokenizer.decode(output_ids[0], skip_special_tokens=True)

Para la pregunta how many products were sold in Madrid, el modelo entrega
algo como:

SELECT COUNT(product) FROM table WHERE city = Madrid

Dos detalles a resolver antes de poder ejecutar esto: la tabla genérica
table (así es como WikiSQL nombra sus tablas de entrenamiento) y el valor
Madrid sin comillas.

La parte que casi nadie muestra: el modelo no conoce tu esquema

Al probar el modelo con preguntas reales aparecieron tres problemas que no se
ven en los ejemplos "de juguete" que suelen circular en tutoriales:

A veces omite los paréntesis de las funciones de agregación: SELECT COUNT Product FROM table WHERE City = Madrid en vez de SELECT COUNT(Product) FROM table WHERE City = 'Madrid'.
El modelo no sabe que nuestra tabla se llama ventas ni que sus columnas son product, category, price, quantity, city, customer y sale_date. WikiSQL entrena con miles de tablas distintas, así que el modelo "inventa" un nombre de columna plausible a partir de las palabras de la pregunta (city a veces sale como City, otras como Location).
No siempre respeta la capitalización real de los datos: generó City = barcelona (minúscula) cuando en la base de datos el valor guardado es Barcelona. Si se ejecuta tal cual, la consulta no falla, pero devuelve 0 filas silenciosamente — el peor tipo de error porque parece que funcionó.

Es tentador tomar el string que devuelve el modelo y pasarlo directo a
cursor.execute(). Es también la forma más rápida de abrir una puerta a
inyección SQL, a que el modelo "alucine" un DROP TABLE, o a que un falso
negativo silencioso pase como resultado correcto. Por eso textsql/sanitize.py
hace cuatro cosas antes de que cualquier SQL toque la base de datos:

1. Reparar los paréntesis faltantes en las funciones de agregación:

_AGG_NO_PARENS = re.compile(
    r"\b(COUNT|SUM|AVG|MIN|MAX)\s+(?!\()([A-Za-z_]\w*)(?:\s+[A-Za-z_]\w*)*\s+FROM",
    re.IGNORECASE,
)

def _fix_missing_parens(sql: str) -> str:
    return _AGG_NO_PARENS.sub(lambda m: f"{m.group(1)}({m.group(2)}) FROM", sql)

2. Renombrar la tabla genérica y poner comillas en los valores de
texto sueltos (igual que en la primera versión).

3. Normalizar columnas con un diccionario de sinónimos, ya que el modelo
no ve el esquema real:

COLUMN_SYNONYMS = {
    "product": "product", "item": "product",
    "category": "category", "type": "category",
    "price": "price", "cost": "price", "amount": "price",
    "quantity": "quantity", "qty": "quantity",
    "city": "city", "location": "city", "town": "city",
    "customer": "customer", "client": "customer", "buyer": "customer",
    "date": "sale_date", "sale": "*", "sales": "*",
}

Con esto, COUNT Sale (una columna que no existe) termina traduciéndose a
COUNT(*), que es exactamente lo que alguien quiere decir con "cuántas
ventas hubo".

4. Comparar sin distinguir mayúsculas, para no devolver falsos negativos
silenciosos:

def _case_insensitive_compare(sql: str) -> str:
    return _STRING_EQUALITY.sub(
        lambda m: f"LOWER({m.group(1)}) = LOWER('{m.group(2)}')", sql
    )

Y finalmente, validar que lo único que se ejecute sea un SELECT, sin
comandos encadenados ni palabras clave destructivas:

FORBIDDEN_KEYWORDS = re.compile(
    r"\b(insert|update|delete|drop|alter|attach|detach|pragma|create|replace|vacuum)\b",
    re.IGNORECASE,
)

def validate_select_only(sql: str) -> None:
    if not sql.strip().upper().startswith("SELECT"):
        raise UnsafeQueryError("Solo se permiten consultas SELECT generadas por el modelo.")
    if ";" in sql:
        raise UnsafeQueryError("No se permiten multiples sentencias en una misma consulta.")
    if FORBIDDEN_KEYWORDS.search(sql):
        raise UnsafeQueryError("La consulta generada contiene palabras clave no permitidas.")

Como defensa adicional, la conexión a SQLite se abre en modo solo-lectura
(file:ventas.db?mode=ro), de forma que incluso si algo se filtrara por la
validación, la base de datos no podría modificarse.

De la terminal a una demo web con Streamlit

Con el motor ya funcionando, envolverlo en una interfaz web con Streamlit
toma menos de 30 líneas:

import streamlit as st
from textsql.db import TABLE_NAME, run_query
from textsql.model import TextToSQL
from textsql.sanitize import adapt_sql, validate_select_only

st.title("🗄️ Pregunta a tu base de datos en lenguaje natural")

question = st.text_input("Escribe tu pregunta en ingles")

if st.button("Generar y ejecutar") and question:
    sql = adapt_sql(engine.generate(question), TABLE_NAME)
    st.code(sql, language="sql")
    validate_select_only(sql)
    st.dataframe(run_query(sql))

El resultado es una página donde se escribe, por ejemplo, what is the total price where city is Barcelona, se ve el SQL generado y la tabla de
resultados en tiempo real.

Resultados y limitaciones

Con la tabla ventas de ejemplo (120 filas sintéticas) y la capa de
normalización en su lugar, preguntas como estas se ejecutan correctamente de
principio a fin:

"how many products were sold in city Madrid"
  -> SELECT COUNT(product) FROM ventas WHERE LOWER(city) = LOWER('Madrid')

"how many sale in category Phones"
  -> SELECT COUNT(*) FROM ventas WHERE LOWER(category) = LOWER('Phones')

"what is the customer where product is Smartwatch"
  -> SELECT customer FROM ventas WHERE LOWER(product) = LOWER('Smartwatch')

Aún así, el prototipo tiene límites claros:

Si la pregunta usa una palabra que no está en COLUMN_SYNONYMS, la consulta puede fallar al ejecutarse (se muestra el error en pantalla en vez de arriesgarse a ejecutar algo incorrecto).
Preguntas que requieren varias tablas o subconsultas (WikiSQL solo entrena con una tabla por ejemplo).
Preguntas en español: el modelo fue entrenado en inglés, así que hay que traducir la pregunta antes de enviarla (una extensión natural del proyecto sería añadir un paso de traducción automática).

Estas limitaciones son, en sí mismas, una buena lección: los modelos
Text-to-SQL de hoy son excelentes asistentes para consultas exploratorias
sencillas, pero todavía necesitan una capa de validación humana o automática
antes de confiar en ellos para producción.

Conclusión

Combinar una base de datos SQL con un modelo de IA no requiere infraestructura
compleja: con un modelo público de Hugging Face, unas 100 líneas de Python y
una capa de sanitización cuidadosa, es posible construir un prototipo
funcional de "conversación con la base de datos" en una tarde. El reto
interesante no está en generar el SQL, sino en decidir cuánto confiar en él
antes de ejecutarlo.

Referencias

Cómo comunicarse con cualquier base de datos mediante IA: crea tu propio extractor de datos con consultas SQL.
Texto a SQL — Hugging Face.
Cómo crear un generador de consultas SQL a partir de texto con Streamlit y Hugging Face (Medium), por Kuhelidey.
Código completo: https://github.com/JhonyVargas/text-to-sql-ia

DEV Community: JhonyVargas