Las dos versiones están alineadas bloque a bloque, en el orden del texto: titular, lo esencial y después párrafo a párrafo. Cuando la traducción ha fusionado o dividido un párrafo, la casilla correspondiente queda vacía — nunca emparejamos dos pasajes a ojo.
An ordinary request—“Find the best-selling product from last year”—can die at the database door if an AI assistant refers to a single item that does not exist. At KAIST, Ph.D. student Geonho Lee and Professor Min-Soo Kim have developed SafeQL, a prototype that repairs the faulty part of an AI-generated query instead of throwing the whole thing away. The findings were presented at the VLDB conference in Boston, U.S.
Una petición corriente —«Encuentra el producto más vendido del año pasado»— puede quedarse en la puerta de la base de datos si un asistente de IA hace referencia a un único elemento que no existe. En KAIST, el doctorando Geonho Lee y el profesor Min-Soo Kim han desarrollado SafeQL, un prototipo que repara la parte defectuosa de una consulta generada por IA en lugar de desecharla por completo. Los resultados se presentaron en la conferencia VLDB, en Boston, Estados Unidos.
The problem sits inside text-to-SQL, the process of turning everyday questions into SQL, the language databases use to retrieve information. An AI might point to a table or column that is absent, or join tables incorrectly. Conventional correction sends the database error back to an LLM—large language model—and asks for a complete rewrite. That can alter sections that were already right, introduce new errors and consume additional processing time.
El problema se encuentra en text-to-SQL, el proceso de convertir preguntas cotidianas en SQL, el lenguaje que utilizan las bases de datos para recuperar información. Una IA puede señalar una tabla o columna inexistente, o combinar tablas de forma incorrecta. La corrección convencional envía el error de la base de datos a un LLM —modelo de lenguaje grande— y solicita una reescritura completa. Eso puede modificar secciones que ya eran correctas, introducir nuevos errores y consumir tiempo adicional de procesamiento.
SafeQL reads the database management system’s feedback to locate the failure precisely: a relation, meaning a table; an attribute, meaning a column; a function; or a value. It then searches a “safe query space” made up of corrections that can actually run on the database, favoring the candidate closest to the original AI-generated query. Unsuitable options are filtered out before they consume more search time. When search-based refinement cannot resolve the error within a predefined threshold, SafeQL calls the LLM again.
SafeQL lee los comentarios del sistema de gestión de bases de datos para localizar con precisión el fallo: una relación, es decir, una tabla; un atributo, es decir, una columna; una función; o un valor. Después busca en un «espacio de consultas seguras» formado por correcciones que realmente pueden ejecutarse en la base de datos y prioriza el candidato más cercano a la consulta original generada por la IA. Las opciones inadecuadas se filtran antes de consumir más tiempo de búsqueda. Cuando el refinamiento basado en búsquedas no puede resolver el error dentro de un umbral predefinido, SafeQL vuelve a llamar al LLM.
The team tested the system on BIRD and Spider, two benchmarks for AI database querying. On BIRD, SafeQL resolved execution errors in up to 87.4% of initially erroneous SQL queries and improved execution accuracy by up to 5.8 percentage points over the unrefined baseline. Compared with regenerating the entire query, it reduced token use by a factor of up to 15.1 and refinement latency by a factor of up to 29.6.
El equipo probó el sistema en BIRD y Spider, dos pruebas de referencia para las consultas de bases de datos mediante IA. En BIRD, SafeQL resolvió los errores de ejecución de hasta el 87,4 % de las consultas SQL inicialmente erróneas y mejoró la precisión de ejecución en hasta 5,8 puntos porcentuales frente a la línea de base sin refinar. En comparación con la regeneración de toda la consulta, redujo el uso de tokens hasta 15,1 veces y la latencia de refinamiento hasta 29,6 veces.
For companies handling large volumes of sales, customer or inventory requests, the concrete change is simple: an assistant can keep the part of a query that works and repair the part that fails. The team says that could reduce the cost and processing time of enterprise AI systems and support more reliable work automation. The study describes a PostgreSQL implementation and benchmark results, while enterprise use remains an expected application rather than a reported deployment; the system can still fall back to the LLM when its search cannot finish the repair.
Para las empresas que gestionan grandes volúmenes de consultas sobre ventas, clientes o inventario, el cambio concreto es sencillo: un asistente puede conservar la parte de una consulta que funciona y reparar la que falla. El equipo afirma que esto podría reducir el coste y el tiempo de procesamiento de los sistemas empresariales de IA y favorecer una automatización del trabajo más fiable. El estudio describe una implementación para PostgreSQL y resultados de pruebas de referencia, mientras que el uso empresarial sigue siendo una aplicación prevista, no una implementación comunicada; el sistema aún puede recurrir al LLM cuando su búsqueda no logra completar la reparación.