💻 computer science

GRID: Grammar-Railed Decoding for Enterprise SQL Generation

El artículo presenta GRID, un motor de decodificación restringido por gramática que aprovecha los estados del analizador LALR(1) y recorridos de trie a nivel de bytes para generar SQL sintácticamente válido y conforme a políticas con garantías demostrables, costos de decodificación casi constantes y pistas de auditoría a prueba de manipulaciones, mejorando significativamente la precisión de ejecución en entornos empresariales.

Autores originales: Mohsen Arjmandi

Publicado 2026-07-15

📖 7 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Mohsen Arjmandi

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina que tienes un amigo robot superinteligente (un Modelo de Lenguaje Extenso) al que le encanta escribir instrucciones de computadora llamadas SQL. Este robot es muy bueno adivinando la siguiente palabra en una oración, pero también es un poco un soñador caótico. En una conversación normal, si el robot dice algo tonto como "DELETE ALL THE TABLES" (BORRAR TODAS LAS TABLAS) cuando solo se suponía que debía decir "SELECT", nadie sale herido. Pero en un banco o un hospital, ese error es un desastre.

Presentamos GRID (Decodificación con Gramática en los Rieles). Piensa en GRID no como un profesor que grita "¡No!" después de que el robot comete un error, sino como un mágico carril de tren por el que el robot debe circular. El robot aún puede ser creativo, pero físicamente no puede desviar el tren de los rieles. Si el carril no existe, el robot ni siquiera puede pensar en esa palabra.

El Mágico Carril de Tren

Normalmente, cuando le pides a un robot que escriba código, dejas que adivine la siguiente palabra, y luego revisas si la oración completa tiene sentido. Si no es así, la borras e intentas de nuevo. Eso es lento y arriesgado.

GRID cambia las reglas del juego. En lugar de revisar la oración completa al final, revisa cada uno de los pasos antes de que el robot siquiera tenga permitido elegir una palabra. Lo hace mirando un "mapa" de la gramática (las reglas del lenguaje) y la posición actual del robot en ese mapa.

El problema con los mapas antiguos: Los métodos anteriores intentaban memorizar cada oración posible que el robot pudiera escribir. El artículo explica que esto es imposible. Si intentaras listar cada oración válida de incluso una longitud moderada, la lista sería más grande que el número de átomos en todo el universo.
La solución de GRID: En lugar de memorizar oraciones, GRID memoriza configuraciones. Imagina que el robot es un excursionista. Los métodos antiguos intentaban memorizar cada posible ruta que el excursionista pudiera tomar. GRID simplemente revisa: "¿Está el excursionista parado actualmente en una parte válida del sendero?". Si es así, el robot puede seguir caminando. Si no, el camino está bloqueado. Esto mantiene el sistema rápido, incluso para oraciones muy largas.

Las Zonas de "No Paso" (Política y Reglas)

En una gran empresa, diferentes personas tienen diferentes reglas. Un empleado de nivel inicial podría tener permitido solo ver los datos (SELECT), mientras que un gerente puede borrarlos (DELETE).

GRID construye estas reglas directamente en los rieles del tren.

Rieles basados en roles: Si el robot está actuando como un "Empleado Junior", los rieles para "DELETE" o "UPDATE" simplemente no existen. El robot ni siquiera puede imaginarlos. No es que se le esté diciendo al robot "No, no hagas eso"; es que la palabra "DELETE" es invisible para él en ese modo.
Rieles de Esquema: El robot también sabe exactamente qué tablas y columnas existen en la base de datos. Si una tabla no existe, el carril hacia ella ha desaparecido. El robot no puede escribir accidentalmente el nombre de una tabla falsa.

El artículo es muy honesto sobre lo que este carril mágico no puede hacer. Demuestra que el carril no puede detener al robot de elegir la columna incorrecta para una fila específica (como elegir "salario" cuando debería ser "nombre") porque esa decisión depende de un contexto que solo aparece después de que la oración ha terminado. Para esos casos complicados, GRID utiliza un "revisor" que mira la oración terminada y la corrige si es necesario.

Velocidad y Seguridad: El Costo "Plano"

Una de las mayores preocupaciones con estos controles de seguridad es la velocidad. Normalmente, cuanto más larga es la oración, más lento se vuelve el control de seguridad. El artículo llama a esto "Requisito R".

GRID promete algo especial: el costo de la verificación se mantiene plano.

Ya sea que el robot esté escribiendo la quinta palabra o la número 16,000, el tiempo que toma verificar si la siguiente palabra está permitida es aproximadamente el mismo.
Los autores midieron esto en computadoras potentes (GPUs H100). Encontraron que, por cada token (parte de una palabra), la verificación toma entre 3.6 y 6.7 microsegundos (eso es millonésimas de segundo) cuando el sistema está "caliente" y listo.
Incluso cuando el robot encuentra una base de datos nueva que nunca ha visto, el sistema la maneja con elegancia. Los primeros pasos pueden tardar un poco más (unos 27.3 milisegundos para configurarse), pero una vez hecho esto, funciona a máxima velocidad. Crucialmente, este tiempo de configuración no ralentiza a los otros robots que trabajan al mismo tiempo.

El Recibo de la "Caja Negra" (Pista de Auditoría)

En un banco, necesitas saber exactamente qué sucedió. Si un robot tomó una decisión, necesitas poder reproducirla más tarde para demostrar que fue segura.

GRID mantiene una pista de auditoría encadenada por hash. Imagina un recibo digital para cada una de las palabras que el robot tiene permitido decir. Este recibo se encadena entre sí como una cadena de clips de papel. Si alguien intenta cambiar una sola palabra en el pasado, toda la cadena se rompe y sabrás inmediatamente que el registro ha sido manipulado. El artículo muestra que pueden reproducir 1,000 generaciones de estas decisiones y obtener exactamente el mismo resultado cada vez, con una detección de manipulación del 100%.

¿Qué tan bien funciona?

El artículo no solo afirma que funciona; lo probaron con datos reales (el conjunto de datos Spider, que tiene más de 1,000 preguntas complejas).

Para robots más pequeños (0.5B de parámetros): Usar GRID mejoró el número de respuestas correctas en 13 puntos porcentuales. ¿La razón principal? El robot dejó de cometer errores de gramática absurdos.
Para robots más grandes y más inteligentes (7B de parámetros): El control de gramática por sí solo ayudó un poco (aproximadamente +1 punto), pero cuando añadieron el "revisor" para corregir los errores complicados de columnas, la tasa de éxito saltó al 94.5%.

La Verdad Honesta

Los autores son muy cuidadosos de no prometer de más. Admiten algunas cosas:

No es perfecto para todos los lenguajes: Funciona mejor para lenguajes que siguen reglas específicas (LALR(1)), como SQL. Todavía no puede manejar cualquier tipo de gramática del mundo.
Cambia el "sabor": Al obligar al robot a mantenerse en los rieles, cambia ligeramente la forma en que el robot elige las palabras. El artículo midió esto y encontró que para robots muy pequeños, este cambio importa, pero para robots grandes y más inteligentes, el beneficio de ser correcto supera el ligero cambio en el estilo.
Arranques en frío (Cold Starts): Cuando llega una base de datos completamente nueva, hay una ralentización diminuta y temporal (aproximadamente un 34% por un instante) mientras el sistema construye los nuevos rieles. Pero esto solo sucede una vez por cada nueva base de datos, y no detiene el trabajo de los otros robots.

En resumen, GRID es como construir un sistema de trenes superseguro y de alta velocidad para la IA. No solo le dice a la IA "no choques"; construye los rieles de modo que chocar sea físicamente imposible, manteniendo al mismo tiempo el tren moviéndose lo suficientemente rápido como para ser útil en el mundo real.

Resumen Técnico: GRID (Grammar-Railed Decoding for Enterprise SQL)

1. Planteamiento del Problema

El artículo aborda la brecha entre la generación de texto "plausible" por parte de los Grandes Modelos de Lenguaje (LLMs) y los requisitos estrictos de la generación de SQL empresarial. En despliegues de CRUD/RBAC (Control de Acceso Basado en Roles) empresariales, las salidas deben ser sintácticamente válidas, adherirse a las políticas por rol y por esquema, y proporcionar garantías probables en lugar de resultados basados en el "mejor esfuerzo". Los autores identifican seis desafíos críticos que las soluciones existentes no logran resolver simultáneamente:

Validez y Política Conjunta: Las salidas deben parsearse bajo el dialecto SQL específico mientras se aplican estrictamente las restricciones de verbos por rol y el vocabulario específico del esquema (tablas/columnas reales) por construcción, no mediante filtrado post-hoc.
Garantías Probables: Los sistemas deben ofrecer teoremas formales de corrección (soundness) (nunca emitir tokens inválidos), completitud (nunca bloquear continuaciones válidas) y terminación, verificados mediante pruebas específicas.
Costo Plano por Token (Requisito R): El costo del "riel de seguridad" (enmascaramiento) debe amortizarse en $O(1)$ por token, independientemente de la longitud de la generación $n$ . Los sistemas existentes suelen sufrir costos que crecen de forma lineal o cuadrática con la longitud del contexto.
Rastro de Auditoría Reproducible: El cumplimiento requiere un registro encadenado por hash y bit-idéntico de cada decisión de permiso/bloqueo para responder "qué se permitió y por qué" a posteriori.
Servicio de la Realidad: Los entornos de producción involucran solicitudes heterogéneas por lotes. El sistema debe manejar llegadas de "esquemas fríos" (nuevos esquemas no vistos antes) sin detener las solicitudes de esquemas calientes co-procesadas ni sustituir los enmascaramientos aproximados.
Límites Hon Estos: El sistema debe reconocer explícitamente lo que no puede ser impuesto por una máscara de contexto libre de izquierda a derecha (específicamente el RBAC a nivel de columna) y proporcionar mecanismos para manejar este residuo.

2. Metodología: Decodificación con Rieles de Gramática (Grammar-Railed Decoding)

GRID introduce una arquitectura novedosa donde todo se indexa mediante configuraciones de parser en lugar de secuencias de tokens.

Idea Arquitectónica Central

En lugar de precomputar tablas de validez sobre secuencias de tokens (que escalan combinatoriamente), GRID indexa todos los enmascaramientos, entradas de caché y registros de auditoría basándose en la configuración del parser. Una configuración $\kappa$ se define como el par $(\sigma, \rho)$ :

$\sigma$ : La pila del parser LALR(1).
$\rho$ : El estado de escaneo del lexer sobre el lexema parcial actual (bytes restantes).

Esta configuración determina de manera única el conjunto de prefijos viables (continuaciones que pueden conducir a una sentencia válida).

Componentes Clave

Oráculo de Prefijos Viables: El propio parser incremental LALR(1) actúa como el oráculo. Al simular la cadena de reducción en una pila virtual, el sistema determina el conjunto de terminales permitidos. Esto evita el "bloqueo de semántica de aceptación" donde los prefijos de un solo token podrían ser rechazados si el sistema solo verificara oraciones completas.
Puente Token-Terminal: Dado que los tokens de los LLM (cadenas de bytes) no se alinean con los lexemas de la gramática, GRID utiliza un recorrido de trie a nivel de bytes.
- Tokens Independientes del Contexto (CI): Tokens que se resuelven dentro del lexema actual o terminan exactamente en un límite de terminal. Estos son cacheables.
- Tokens Dependientes del Contexto (CD): Tokens que cruzan un límite de terminal (por ejemplo, completando una palabra clave y comenzando una nueva). Estos nunca se cachean; se verifican contra la pila viva en cada paso para asegurar la corrección.
Compilación de Políticas:
- Proyecciones de Rol (L2): Subconjunto de las producciones de la gramática (por ejemplo, eliminando verbos DELETE) y eliminación de símbolos inútiles.
- Lexicones de Esquema (L3): Restringe los terminales de identificadores para permitir listas blancas derivadas del catálogo de la base de datos.
- Regla de Composición de Identificadores: En las posiciones de identificadores, la máscara se deriva estrictamente de la intersección del trie del token y el trie del lexicón del esquema, evitando que las entradas de caché genéricas admitan identificadores prohibidos.
Estrategia de Caché (OBL-KEY1): Una caché de escritura diferida de dos niveles (T1 para gramáticas específicas, T2 para familias de gramáticas compartidas) utiliza claves derivadas de la configuración. El sistema impone un "refinamiento estilo Myhill–Nerode" donde cualquier par de configuraciones que compartan una clave deben producir máscaras de bytes idénticas.
Cadena de Auditoría: Cada paso añade un registro (paso, hash de configuración, ID de entrada de máscara, token, conteo de bloqueos) encadenado mediante BLAKE2b. Esto permite una reproducción bit-idéntica de las generaciones contra artefactos archivados.

Implementación del Sistema

Núcleos en Rust: La ruta crítica (recorrido del trie, veredictos CD, avance LALR, llenado de bitmask) está implementada en Rust para minimizar la latencia y liberar el GIL de Python.
Contrato de Servicio (vLLM): El sistema superpone el cálculo de la máscara en la CPU con el pase hacia adelante (forward pass) de la GPU. Si la máscara de una solicitud de esquema frío no está lista, se difiere por un ciclo, asegurando que las solicitudes calientes co-procesadas nunca se detengan.
Reparación Guiada por Verificador: Para el residuo que las máscaras no pueden imponer (RBAC a nivel de columna), el sistema utiliza un verificador semántico post-parse. Si se detecta una violación, el sistema puede guiar un pase de reparación para corregir la consulta.

3. Contribuciones Clave

Marco Formal: Un marco de decodificación restringida indexado por configuración que utiliza un parser LALR(1) incremental como oráculo de prefijo viable, con un puente de bytes token-a-terminal y una división de contexto independiente/dependiente.
Garantías Probables: Cuatro garantías (Corrección, Completitud, Terminación, Costo Plano) expresadas como proposiciones con precondiciones explícitas, emparejadas con pruebas específicas para su verificación.
Realización del Sistema: Un sistema listo para producción (núcleos v4–v7) que cuenta con un pipeline de gramática, núcleos en Rust, una caché de dos niveles y un registro de auditoría encadenado por hash.
Récord de Benchmarking: Evaluación exhaustiva que incluye latencia por token, mediciones de la pendiente del Requisito R, MaskBench (Esquema JSON), precisión de ejecución de Spider y registros de servicio vLLM de extremo a extremo.

4. Resultados

Latencia: En un ejecutor H100 SXM5, GRID logra una latencia mediana de máscara por token de 3.6–6.7 µs (p50) y 80–109 µs (p90), superando a llguidance y XGrammar en p50 y p90 tanto para tokenizadores gpt2 como Qwen. llguidance mantiene la cola p99 más plana.
Requisito R (Costo Plano): A $n=16,000$ tokens, la pendiente del costo por token es efectivamente cero ( $\approx 0$ ), confirmando un costo amortizado $O(1)$ . En contraste, versiones anteriores de guía mostraban un crecimiento cuadrático.
Precisión de Ejecución (Spider):
- Modelo de 0.5B: La decodificación restringida por sí sola aporta +13 puntos de precisión de ejecución (EX) sobre la generación no restringida (29.0% vs 16.0%).
- Modelo de 7B: La máscara por sí sola aporta aproximadamente +1 punto. Sin embargo, añadir un pase de reparación guiado por verificador para violaciones a nivel de columna eleva la ejecución al 94.5% (EX +2.3 sobre la no restringida).
Sobrecarga de Servicio: Bajo vLLM con tamaño de lote 32, la sobrecarga es de +1.51% de tiempo por token de salida.
Manejo de Arranque en Frío: Un esquema nuevo incurre en un tiempo de especialización de ~27.3 ms y una latencia del primer token de ~0.7 ms. Aunque esto causa una desaceleración transitoria de ~34% para las solicitudes calientes co-procesadas durante la ventana de especialización (debido a la contención de ancho de banda de CPU/memoria), las solicitudes calientes nunca se detienen y la nueva solicitud corre a una velocidad de 1.00× de la velocidad cálida de ahí en adelante.
Integridad de Auditoría: 1,000 generaciones fueron reproducidas de forma bit-idéntica con detección de manipulación del 100%.

5. Significado y Límites Honestos

El artículo afirma que GRID demuestra que la decodificación restringida de grado empresarial es alcanzable comprometiéndose con la decodificación indexada por configuración. Este compromiso único permite la compilación de políticas, garantías probables, costos planos y auditorías reproducibles.

Los autores son explícitos sobre las limitaciones y fronteras del sistema:

Fidelidad de la Distribución: El artículo no pretende que el enmascaramiento preserve la distribución de probabilidad original $P(x | x \in L)$ ; renormaliza localmente. El impacto se mide mediante la precisión de ejecución descendente, no mediante la neutralidad distributiva.
RBAC a Nivel de Columna: El artículo demuestra (Proposición 11) que las restricciones a nivel de columna no pueden imponerse mediante una máscara CFG de izquierda a derecha porque el enlace alias-a-tabla necesario es desconocido al momento de la máscara de columna. Esto se maneja mediante verificación y reparación post-parse, no mediante la máscara misma.
Alcance del Lenguaje: El sistema está limitado a lenguajes LALR(1). Aunque maneja dialectos estándar de SQL, declara errores de compilación para constructos no LALR(1) (por ejemplo, ciertos patrones de JSON Schema).
Contención de la Ventana de Arranque en Frío: Se reconoce la desaceleración transitoria para las solicitudes co-procesadas durante la especialización de un nuevo esquema como un problema genuino de contención de ancho de banda de CPU/memoria del host, no como un defecto de software, representando un compromiso de aislamiento de cómputo.
Terminación: Las garantías de terminación completa (paradas de reserva completada) solo se mantienen en el bucle de decodificación propiedad de GRID; los modos de servicio de solo procesador pueden truncar.

En resumen, GRID proporciona un marco riguroso y de alto rendimiento para la generación de SQL empresarial que prioriza la corrección, la aplicación de políticas y la auditabilidad, mientras delimita honestamente los límites de lo que puede ser impuesto mediante el enmascaramiento de gramática.