Desde hojas dispersas hasta SQL conversacional, con confiabilidad agencial

Por qué «hablar con hojas de cálculo» suele decepcionar

Las hojas de cálculo son la interfaz universal de los datos empresariales. Los equipos las utilizan para la elaboración de presupuestos, el inventario, el seguimiento de las ventas e incluso como bases de datos ad hoc. Sin embargo, la misma flexibilidad que los hace indispensables también dificulta la automatización.

Las interfaces de lenguaje natural para las hojas de cálculo suelen fallar porque esperan que el LLM adivine el significado a partir de un caos desestructurado: encabezados inconsistentes, filas ocultas, celdas combinadas, formatos de fecha ambiguos y fórmulas rotas silenciosamente.

En la práctica, esto ocurre cuando los usuarios suben un archivo de hoja de cálculo (como una hoja de cálculo de Excel o Google) directamente a un LLM de uso general, como ChatGPT, Gemini o Claude, esperando que «comprenda» el contenido del archivo. El modelo solo recibe una representación textual plana de la hoja, lo que pierde su estructura tabular, sus fórmulas y su contexto. Sin un esquema o una capa de validación definidos, el LLM se ve obligado a deducir el significado a partir de datos sin procesar desordenados, lo que conduce a un razonamiento poco fiable y a respuestas inconsistentes

Lo que la gente imagina es: «Pregunte en inglés y obtenga una respuesta».

Lo que en realidad ocurre es: «La modelo alucinó con una columna que no existe».

Antes de que un modelo pueda razonar de forma fiable, necesita lo mismo que necesitan los analistas y las herramientas de BI: un esquema. Definir ese esquema (tablas explícitas, tipos claros, datos de muestra) es la diferencia entre las demostraciones de juguetes y la confiabilidad de la producción. Solo una vez que los datos tengan un contrato estructurado, podremos añadir una capa conversacional que parezca inteligente en lugar de frágil.

El fracaso no es el LLM, es la estructura y las barandillas que faltan. Hablar con hojas de cálculo solo es factible cuando trátelos como una base de datos primero y deje que el LLM funcione dentro de un entorno controlado y validado.

Subir hojas de cálculo directamente a ChatGPT o Claude suele ser decepcionante porque estas herramientas se enfrentan a estrictos límites técnicos y estructurales. Ambas limitan el tamaño de los archivos (alrededor de 30 a 50 MB) y tienen dificultades con archivos grandes, con muchas hojas o con muchas fórmulas, ya que a veces truncan el contenido para adaptarlo a sus ventanas de contexto. También malinterpretan las funciones complejas de las hojas de cálculo, como las filas ocultas, las celdas combinadas o las fórmulas, ya que estos modelos extraen texto sin formato en lugar de conservar la estructura de los datos. Incluso cuando las subidas se realizan correctamente, los límites de contexto o de símbolos significan que solo se analiza una parte de los datos, lo que da lugar a respuestas incompletas o engañosas. Los problemas frecuentes, como la lentitud del rendimiento, los bloqueos o las fallas de los modelos, socavan aún más la confiabilidad.

Fundamentalmente, esto sucede porque los LLM funcionan semánticamente, no estructuralmente. Entienden el lenguaje natural, no la lógica relacional de las tablas de datos. El nuevo modos de agente en ChatGPT y Claude intentan compensar con generación y ejecución de código Python para inspeccionar e interpretar hojas de cálculo, pero este enfoque sigue siendo propenso a errores y no determinista, ya que el modelo primero debe inferir la estructura de los datos y, a continuación, escribir código para analizarlos correctamente. Por el contrario, un Agente SQL funciona según un esquema explícito y validado en el que el razonamiento se basa en consultas estructuradas en lugar de en guiones improvisados. Esto permite una computación segura, auditable y precisa, convirtiendo la intención semántica en resultados deterministas en lugar de tener que adivinar mediante la generación de código ad hoc.

Entonces, ¿cómo podemos hacer que funcione realmente?

Tras entender por qué «hablar con las hojas de cálculo» suele fallar, la siguiente pregunta es obvia: ¿cómo podemos hacer que funcione?

En lugar de subir archivos sin procesar de Excel o Google Sheets a ChatGPT, Claude o Gemini y esperar que el modelo pueda interpretar el caos, podemos crear un agente confiable eso realmente razona sobre nuestros datos.

La clave no es la magia, es la ingeniería... La idea es convertir las hojas de cálculo en esquemas relacionales, cárguelos en un entorno validado y deje que un modelo funcione dentro de restricciones claras y auditables. A diferencia de ChatGPT o Claude's modos de agente, que primero debe generar y ejecutar código Python para «adivinar» la estructura de una hoja de cálculo, un Agente SQL funciona según un esquema validado y explícito. Esto permite un razonamiento determinista, una ejecución más segura y una trazabilidad total.

1. Modele los datos → Hoja (s) de cálculo → Esquema relacional (tablas, columnas, claves, descripciones, algunas filas de muestra por tabla)‍
2. Cargar y validar → ETL/ELT a un almacén (p. ej., Postgres/BigQuery/Snowflake)‍
3. Fundamenta el LLM → Vinculación de rag/esquema a seleccionar solo las tablas/columnas relevantes‍
4. Generar SQL → LLM propone una consulta (pocas fotos más contexto empresarial)‍
5. Validación previa a la ejecución → Analizador SQL + comprobaciones de políticas (solo selecciones, LIMIT, comprobaciones de existencia)‍
6. Ejecute con el mínimo privilegio → Usuario de base de datos de solo lectura‍
7. Responder → Convierte las filas en una respuesta concisa y adecuada para las empresas

Paso 1: De hojas de cálculo a un esquema confiable

Antes de que un agente pueda «hablar» con los datos, primero debe entender su estructura. Imagina heredar una docena de hojas de cálculo desordenadas, columnas con nombres vagos, totales aleatorios y filas ocultas. El primer paso es convertir ese caos en una historia clara que el modelo pueda seguir. Diseñar un esquema donde el nombre de cada columna habla por sí mismo, cada tabla tiene un propósito y las relaciones son explícitas. Agregar descripciones breves y un algunos ejemplos filas para regalar contexto, muy parecido a una escena rápida ambientada en una película. La normalización evita la duplicación, mientras que un poco de desnormalización facilita la respuesta a las preguntas frecuentes. Una vez que existe esa base, el agente finalmente tiene algo confiable sobre lo que razonar.

En resumen:

• Las columnas deben ser descriptiva: customer_id, order_date, gross_amount_usd
• Añadir descripciones de tablas/columnas que utilizan términos comerciales
• Incluir 3 filas de muestras sintéticas como comentarios por tabla (ayuda a establecer una base de pocos tiros)
• Normalice lo suficiente para evitar la duplicación; desnormalice con moderación para consultas comunes

Ejemplo de esqueleto de DDL

-- Customers
CREATE TABLE dim_customer (
  customer_id SERIAL PRIMARY KEY,
  full_name TEXT NOT NULL, -- e.g., legal or preferred name
  email TEXT, -- unique if enforced upstream
  created_at TIMESTAMP NOT NULL
);
-- Example rows (for the agent; do not load in prod)
-- INSERT INTO dim_customer (customer_id, full_name, email, created_at) VALUES
-- (101, 'Ana Pereira', '[email protected]', '2024-01-04 09:12:00'),
-- (102, 'Carlos Méndez', '[email protected]', '2024-01-12 15:33:00'),
-- (103, 'Lucía Díaz', '[email protected]', '2024-02-01 11:05:00');

-- Orders
CREATE TABLE fct_order (
  order_id SERIAL PRIMARY KEY,
  customer_id INT NOT NULL REFERENCES dim_customer(customer_id),
  order_date DATE NOT NULL,
  gross_amount_usd NUMERIC(12,2) NOT NULL,
  channel TEXT CHECK (channel IN ('web','store','partner'))
);
-- Example rows
-- INSERT INTO fct_order (order_id, customer_id, order_date, gross_amount_usd, channel) VALUES
-- (5001, 101, '2024-03-01', 120.00, 'web'),
-- (5002, 102, '2024-03-02', 60.50, 'store'),
-- (5003, 101, '2024-03-05', 240.00, 'partner');

Paso 2: canalización ETL (de las hojas a la base de datos)

Aquí es donde la disciplina se une a los datos. El objetivo es tomar cada hoja de cálculo y moverla según un flujo: extracción, validación, y cargando. Con herramientas como pandas y SQLAlchemy, los datos se leen, limpian y escriben en el almacén con tipos uniformes e integridad referencial. Piense en ello como si estuviera capacitando a los funcionarios de aduanas sobre sus datos: cada archivo debe pasar una inspección antes de entrar en la base de datos. La canalización no solo estructura el flujo (Etapa → Limpieza → Disminución del nivel de detalle), sino que también garantiza que las tablas resultantes reflejen el DDL que definió anteriormente. Una vez validada, la base de datos se convierte en una única fuente confiable que su agente puede explorar de manera segura.

• Extraer: Lea .xlsx/.csv desde Drive/SharePoint/S3 (por ejemplo, Python pandas)
• Validar: Tipos, nulabilidad, integridad referencial‍
• Cargar: Almacén de elección; ejecute primero DDL por encima
• ‍Transformar: Stage → Clean → Dim/Facts (utilice scripts dbt o SQL)

Paso 3: Conexión a tierra y recuperación (enlace de esquemas/Mini-RAG)

Si el esquema de la base de datos es lo suficientemente pequeño, puede incluir todas sus descripciones de tablas y columnas directamente en la línea de comandos del sistema del LLM; de lo contrario, necesitará una capa de base y recuperación para evitar sobrecargar el modelo con un contexto irrelevante.

Este paso garantiza que el LLM solo vea las partes del esquema que importan para cada pregunta, lo que mejora la precisión y reduce las alucinaciones. El proceso consiste en indexar los metadatos más sencillos del esquema (como los nombres de tablas y columnas, las descripciones, los valores de muestra y las relaciones entre claves) y recuperar los fragmentos más relevantes mediante la búsqueda vectorial o por palabra clave.

Cuando un usuario hace una pregunta, el sistema la analiza, recupera las tablas y columnas pertinentes y construye un contexto compacto y centrado para que el modelo genere consultas SQL de forma segura. En resumen, la base de datos actúa como el mapa del LLM para su base de datos, ya que pasa de ser un simple esquema pequeño integrado en el indicador a un enfoque basado en la recuperación para almacenes más grandes, lo que garantiza una generación de consultas eficiente, precisa y confiable.

Objetos de recuperación

• Nombres de tablas, descripción de tablas, nombres de columnas, descripciones, casos de uso de tablas
• Opcional: muestras de mayor valor por columna (p. ej., canales comunes), ejemplos de consultas

Bucle de recuperación

1. Analizar la pregunta del usuario
2. Recuperar tablas/columnas de candidatos (búsqueda vectorial o por palabra clave)
3. Cree el contexto del modelo: solamente esas tablas más algunos ejemplos

Paso 4: Preguntar por la confiabilidad (pocos tiros más política)

Ahora el agente necesita aprender a «hablar SQL» de manera responsable. Mediante un diseño rápido, no solo se dan instrucciones, sino que se moldean sus hábitos de razonamiento. El mensaje del sistema proporciona el tono, el contexto y las reglas de interacción: siempre debe limitar los resultados, comprobar la sintaxis y nunca modificar los datos. Unos pocos ejemplos actúan como experiencias previas que guían al agente hacia respuestas seguras y estructuradas. Políticas como las cláusulas SELECT only y LIMIT transforman el mensaje que deja de ser una conversación casual en un contrato de confianza entre una persona y una modelo.

Fragmento de mensaje del sistema

You are an agent designed to interact with a SQL database.
Given an input question, create a syntactically correct {db.dialect} query to run, then look at the results of the query and return the answer. Unless the user specifies a specific number of examples they wish to obtain, always limit your query to at most 5 results.

You can order the results by a relevant column to return the most interesting examples in the database. Never query for all the columns from a specific table, only ask for the relevant columns given the question.

You MUST double check your query before executing it. If you get an error while executing a query, rewrite the query and try again.

DO NOT make any DML statements (INSERT, UPDATE, DELETE, DROP etc.) to the
database.

# DATABASE SCHEMA

Below is the complete database schema for the Zonamerica database:

## Master Tables (edificios, locales, clientes)
{master_tables_sql}

## Secondary Tables
{secondary_tables_sql}

## Indexes
{indexes_sql}

# EXAMPLE QUERIES

Below are example queries that demonstrate that solve a set of questions. You can use this same queries:

{example_queries_sql}

Use these schemas and examples to guide your query construction.

Bajo la variable example_queries_sql es importante añadir algunos ejemplos reales de consultas que el agente necesita responder.

Paso 5: Crear el agente (LangChain v1 + SQL Toolkit)

A continuación se muestra un patrón compacto que puede adaptar. Si todo el contexto del esquema cabe en la línea de comandos, el tablas de listas, esquema, comprobador de consultas, y desempeñar las herramientas son suficientes. (Agente SQL de Langchain)

from langchain_openai import ChatOpenAI
from langchain_community.agent_toolkits import SQLDatabaseToolkit
from langchain_community.utilities import SQLDatabase
from langchain.agents import create_sql_agent

# 1) DB with READ-ONLY user
sql_db = SQLDatabase.from_uri("postgresql+psycopg2://agent_ro:***@host:5432/warehouse")

# 2) LLM
llm = ChatOpenAI(model="gpt-4o-mini", temperature=0)

# 3) Toolkit exposes: list tables, get schema, check query, run query
toolkit = SQLDatabaseToolkit(db=sql_db, llm=llm)
tools = toolkit.get_tools()

# 4) Create the agent with built-in SQL tools
agent = create_agent(
    llm=llm,
    tools=tools,
    system_prompt=system_prompt,
)

# 5) Ask a question
question = "Show total sales by channel last month"
for step in agent.stream(
	{"messages": [{"role": "user", "content": question}]},
	stream_mode="values",
):
	step["messages"][-1].pretty_print()

Ruta de actualización: Para esquemas más grandes, vaya a Gráfico de largo máquina de estado: nodos para (lista de tablas → elegir → buscar esquema → generar → comprobar → ejecutar → refinar). Agregue reintentos a los mensajes de error de la base de datos.

Si el esquema de su base de datos con algunos ejemplos breves cabe en la línea de comandos del sistema, puede ignorar las siguientes herramientas del kit de herramientas de SQL: sql_db_list_tables y sql_db_schema.

Paso 6: Validación y seguridad previas a la ejecución

Antes de que cualquier SQL toque la base de datos, cada consulta debe pasar por un capa de validación y política. Este paso garantiza que el agente nunca ejecute comandos inseguros, absurdos o que aumenten los privilegios. LangChain v1 presenta el middleware concepto, que encaja perfectamente aquí: puede adjuntar una lógica que inspeccione, modifique o bloquee una llamada a una herramienta antes de que se ejecute.

En esta capa, puede:‍

• Haga cumplir las políticas. Permita solo las sentencias SELECT, exija cláusulas LIMIT, restrinja el acceso a esquemas o tablas específicos y bloquee palabras clave peligrosas como DELETE, DROP, ALTER o UPDATE. ‍
• Analiza y enlaza consultas. Ejecute el SQL generado por LLM a través de un analizador para verificar la sintaxis y garantizar que los nombres de tablas y columnas existan en el esquema. Este paso también puede normalizar el uso de mayúsculas o el formato para facilitar la trazabilidad.‍
• Realice un análisis estático. Detecte uniones cartesianas, escaneos excesivos o agregaciones sin filtrar que pueden arrojar conjuntos de resultados enormes.‍
• Valide según las reglas empresariales. Por ejemplo, rechace las consultas que expongan campos confidenciales (PII) o que infrinjan las políticas de seguridad a nivel de fila.
• Opcionalmente, involucre a un motor humano o de políticas. El middleware puede interrumpir la ejecución para solicitar la confirmación o la aprobación de ciertos tipos de consultas, lo que permite un flujo de trabajo continuo en producción.

Al centralizar estos controles en middleware, desvincula la lógica de validación del flujo de razonamiento del agente. El modelo puede generar SQL libremente, pero la ejecución real solo se produce si el middleware considera que cumple con las políticas organizativas y de seguridad. Combinado con un usuario de base de datos de solo lectura, esto crea un fuerte límite de defensa en profundidad entre la generación de idiomas y el acceso a los datos.

Paso 7: Observabilidad y trazabilidad

Tienes que ver qué es lo que hace el agente pensamiento y hizo (Lang Smith):

• Trazas de LLM (entradas, llamadas de herramientas, salidas)
• Registros de consultas (SQL validado, tiempo de ejecución, recuento de filas)
• Análisis de errores (principales modos de fallo: columna desconocida, unión incorrecta, conjunto vacío)
• Barandas PII (enmascarar, redactar trazas)

Posibles mejoras y próximos pasos

Su arquitectura actual (esquema ⇒ ETL ⇒ puesta en tierra ⇒ SQL gen ⇒ validación ⇒ ejecución ⇒ refinar) es una base sólida para lanzar un piloto interno. A continuación se presentan actualizaciones concretas que la hacen más apta para la producción, la escala de producción y los datos empresariales desordenados.

Una base más sólida: Schema-RAG y enlaces con reconocimiento de valores

• Esquema RAG a escala. Descripciones de tablas/columnas de índice, gráfico PK/FK y valores principales, recupera solo lo que sea relevante por pregunta. Esto reduce las alucinaciones y mejora la precisión de las uniones. Encuestas recientes destacan que la recuperación y la vinculación de esquemas son la mayor ventaja al pasar de las demos a las incisiones. (ArXiv)
• Vinculación sólida de esquemas. Prefiera los enlazadores que sean resistentes a la deriva de nombres y a los sinónimos y trate los enlaces como un problema de recuperación de primera clase. (ArXiv)

Decodificación restringida + Lint/validación de SQL

• Generación segura de sintaxis (PICARD). Restringir la decodificación para que el modelo no poder emitir SQL no válido. Esto aumenta considerablemente el éxito de la ejecución. (aclanthology.org)
• Barandas programáticas. Analice y alinee con un analizador real (por ejemplo, SQLGlot) y añada políticas de permisión/denegación (solo selección, LÍMITE obligatorio, lista de permitidos de esquemas). También puedes adoptar validadores listos para usar (por ejemplo, el valid_sql de Guardrails) en el middleware de llamadas a herramientas. (GitHub)
• Ruta de excepciones de políticas. Cuando se activen las reglas (columnas de PII, riesgo de recuento de filas), diríjase a la aprobación (consulte la sección 4). (Se combina de forma natural con el paso de «validación previa a la ejecución»).

Autocorrección y planificación con detección de errores

• Bucles de retroalimentación de ejecución. En caso de errores de base de datos (columna desconocida, unión incorrecta), reparación de automóviles la consulta utilizando el mensaje de error + el contexto del esquema; mantenga un presupuesto de reintento limitado. Los patrones de la industria y los documentos recientes muestran que este ciclo de «reflejar → reparar → volver a ejecutar» arroja grandes beneficios. (Amazon Web Services, Inc.)
• Andamios de razonamiento. Utilice una planificación ligera (esquema → borrador de SQL → verificación) y unos pocos disparos dinámicos extraídos de consultas anteriores exitosas contra las mismas mesas. Las encuestas muestran que esto siempre ayuda en los esquemas reales. (ArXiv)

Human-in-the-Loop (HITL) donde importa

• Revisión basada en el riesgo. Apruebe automáticamente los patrones seguros y exija la aprobación humana para las consultas que afecten a tablas delicadas, tengan un costo elevado o tengan una intención ambigua.
• Comentarios → datos de entrenamiento. Capture las ediciones/aprobaciones de los usuarios y extráigalas en nuevos ejemplos de entrenamiento sintéticos o de pocas tomas; los oleoductos de HITL ahora son estándar para aumentar la precisión en su propio cargas de trabajo. (ArXiv)

Observabilidad y gobernanza

• Rastros en los que puede confiar. Registra las solicitudes, los fragmentos de esquema recuperados, el SQL generado, las decisiones de políticas, el tiempo de ejecución, el recuento de filas y las etiquetas de comentarios de los usuarios.
• Puntos de referencia que reflejan la realidad. Pista precisión de ejecución y respuesta útil en sus registros; si lo desea, añada evaluaciones al estilo Bird/Spider para detectar regresiones. (Mediano)
• Taxonomía de errores. Clasifique los principales modos de error (vinculación, sintaxis, conjunto vacío, consulta lenta) y diríjase a ellos con pruebas.
• El menor privilegio por diseño. Función de solo lectura, lista de esquemas permitidos, seguridad a nivel de fila y enmascaramiento de columnas para la PII; redacte la PII de los rastros.
• Marco de barandilla. Centralice la validación de entrada/salida (filtros de mensajes, validadores de esquema/SQL, límites de tamaño de los resultados, comprobaciones de jailbreak). Consulta las encuestas y patrones recientes sobre guardarrail. (ArXiv)

Lista de verificación de producción

Antes de enviar su agente SQL a producción, es útil comprobar rápidamente su estado físico, es decir, una breve lista de los elementos no negociables que garantizan que su sistema se comporta de forma predecible en condiciones reales.

La siguiente lista de verificación resume todo lo discutido en esta publicación en pasos concretos y verificables.

• Función de base de datos de solo lectura para el agente (privilegio mínimo)
• Analizador SQL + comprobaciones de políticas (reglas de solo selección, LIMIT, WHERE)
• Contexto de esquema con ámbito o RAG
• Algunos ejemplos de fotos alineados con las preguntas empresariales
• ETL con comprobaciones de tipo y claves primarias/externas
• Observabilidad (trazas de LLM, registros de consultas, taxonomía de errores)
• Seguridad a nivel de hila/alcance de inquilinos si es necesario
• Solución alternativa clara cuando la pregunta es ambigua (hacer una pregunta aclaratoria)

Conclusión

«Hablar» con hojas de cálculo no consiste en hacer que los modelos lingüísticos entiendan mágicamente el caos, sino en darles estructura, barreras y circuitos de retroalimentación que reflejen la fiabilidad del funcionamiento de los sistemas de software. Una vez que una hoja de cálculo se convierte en un esquema y las consultas fluyen a través de canales validados y observables, la conversación deja de ser frágil y pasa a ser productiva.

El mensaje central es simple: trata tu hoja de cálculo como una base de datos y tu LLM como un analista que necesita contexto y supervisión. Con un ETL mínimo, una recuperación basada en esquemas, una validación de SQL y una ejecución con el mínimo privilegio, puede pasar de copiar y pegar archivos CSV en el chat a una capa conversacional que se pueda mantener y escalable.

Esta es la dirección que está tomando la próxima generación de agentes SQL: fundamentados, gobernables y medibles. Ya sea que esté probando una pequeña herramienta interna o diseñando una interfaz de datos empresarial, la confiabilidad no es una característica adicional, es la base. Construya esa base una vez y su LLM finalmente empezará a hablar con sus datos, no solo sobre ellos.