Lo que hemos aprendido sobre cómo dar indicaciones a los modelos de lenguaje grande (LLM) para la conversión de texto a SQL
Summary
- El uso eficaz de indicaciones mejora considerablemente la precisión de la conversión de texto a SQL en el análisis de datos basado en la inteligencia artificial.
- Incluir detalles del esquema, relaciones de claves externas y valores de columna de ejemplo ayuda a los modelos a generar consultas más eficaces.
- Los ejemplos con pocos datos mejoran aún más el rendimiento al enseñar al modelo patrones específicos del ámbito.
- Los sistemas fiables de conversión de texto a SQL también requieren definiciones semánticas, la reutilización de consultas y una infraestructura contextual que vaya más allá de las simples indicaciones.
En Actian, estamos desarrollando agentes de IA que convierten el lenguaje natural en SQL de forma automática. Es una de esas cosas que parecen mágicas, pero que requieren un minucioso trabajo de ingeniería para que funcionen correctamente. Una de las lecciones más importantes que hemos aprendido es que la forma en que se le da la indicación al modelo marca una gran diferencia.
Hace poco, hemos estudiado un montón de estrategias diferentes para la formulación de indicaciones. Zero-shot, few-shot, de dominio único, entre dominios. Formatos de indicaciones, ejemplos de datos, relaciones entre tablas... lo hemos probado todo. Y déjame decirte que hemos sacado conclusiones muy claras sobre lo que funciona y lo que no.
En este blog compartimos algunas de esas experiencias. Tanto si estás desarrollando tu propia herramienta de conversión de texto a SQL como si simplemente sientes curiosidad por saber cómo lo hacemos en Actian, sigue leyendo.
Introducción a las indicaciones (Repaso rápido)
Cuando hablamos aquí de «prompting», nos referimos a lo siguiente: ¿qué le mostramos al modelo de lenguaje antes de pedirle que genere código SQL?
Una línea de comandos básica de «texto a SQL» suele incluir:
- Una breve indicación («Escribe una consulta SQL utilizando las tablas que aparecen a continuación»).
- Una descripción de la base de datos (nombres de tablas, columnas, relaciones).
- A veces: ejemplos de consultas + el código SQL correspondiente.
- Y luego: la pregunta que queremos que se responda.
Hay dos configuraciones habituales:
En Actian utilizamos ambas opciones, dependiendo de lo que esté haciendo el usuario y de los datos de que dispongamos.
El esquema por sí solo no basta
En las indicaciones de tipo «zero-shot», no basta con enumerar la tabla y las columnas. Hemos descubierto que añadir relaciones entre tablas (por ejemplo, claves externas) mejora la precisión de forma significativa.
Mejor aún: incluye valores de datos de ejemplo. Esto ayuda al modelo a comprender cómo se ven los valores de las columnas en la práctica, lo cual es fundamental a la hora de escribir cláusulas WHERE con el formato adecuado (por ejemplo, «EE. UU.» frente a «Los Estados Unidos de América»).
Probamos diferentes formas de mostrar el contenido de las tablas. ¿Cuál fue la ganadora? Un formato que muestra valores distintos en cada columna (lo que el artículo denomina «SelectCol»). Esto dio mejores resultados que mostrar las filas sin procesar («InsertRow») o simplemente ejecutar «SELECT * LIMIT 3».
Así pues, en la configuración «zero-shot» de Actian, siempre incluimos:
- El esquema completo (CREATE TABLE)
- Relaciones de clave externa
- Unos pocos valores distintos por columna
(Y sí, lo normalizamos todo: minúsculas, espaciado uniforme, sin formatos raros.)
Pocas muestras: cuantas más, mejor (en la mayoría de los casos)
Si puedes incluir ejemplos, hazlo. Hemos observado mejoras constantes incluso con solo uno o dos ejemplos. ¿Y si pudieras llegar a incluir entre cuatro y ocho buenos ejemplos del mismo ámbito? Eso suele ser suficiente para obtener la mayor parte de los beneficios.
Pero aquí viene el giro:
- El contenido de las tablas sigue siendo importante, incluso cuando se incluyen ejemplos.
- La forma en que se muestra ese contenido pierde importancia: el modelo se vuelve menos exigente una vez que ha visto unos cuantos ejemplos.
- Las relaciones entre tablas (como las uniones) se pueden aprender a partir de los propios ejemplos.
En el modo de dominio único, basta con un formato de esquema más sencillo, siempre y cuando se incluyan ejemplos reales y útiles; no obstante, recomendamos incluir el contenido de la tabla si es posible.
Los datos de muestra mejoran la precisión
Si además muestras algunos valores de la tabla —como unas cuantas filas de ejemplo—, los resultados mejoran. Esto ayuda al modelo a comprender qué tipo de valores se almacenan, lo cual es importante a la hora de escribir filtros (por ejemplo, cláusulas WHERE).
Probamos varias formas de demostrarlo:
- Instrucciones INSERT sin formato
- SELECT * LIMIT 3
- Valores distintos por columna
La última opción (valores distintos por columna) fue la que mejor funcionó. Ofrece más variedad y evita la redundancia.
Pero las indicaciones no lo son todo
La cuestión es esta: por muy bien que le des instrucciones a un modelo de lenguaje grande (LLM), no es realista esperar que siempre escriba código SQL perfecto partiendo de cero.
En Actian, hemos aprendido que no basta con dar indicaciones. Se necesita un marco de trabajo que rodee al agente:
- La capacidad de almacenar consultas SQL generadas anteriormente y reutilizarlas cuando un usuario plantee una pregunta similar más adelante.
- Una forma de definir términos importantes (como qué significan realmente «churn» o «usuario activo») e incluir esa definición en la indicación cuando sea pertinente.
Este tipo de infraestructura marca una gran diferencia en cuanto a fiabilidad y rendimiento. La sugerencia es solo el punto de partida, pero es gracias a una gestión sólida del contexto y a su reutilización como se consigue que el sistema sea escalable e inteligente.
Y sí, en Actian también hacemos otras cosas entre bastidores. Pero aún no vamos a desvelarlo todo… algunas cosas están pendientes de patente.
Nos apasiona mejorar el funcionamiento de la conversión de texto a SQL: queremos que sea más precisa, más fiable y más útil para los equipos de datos. Las indicaciones son solo una pieza de ese rompecabezas, pero es una pieza importante.
Si estás desarrollando tus propias herramientas de datos basadas en modelos de lenguaje grande (LLM), esperamos que esto te dé algunas ideas. Y si quieres ver cómo funciona en la práctica, ya sabes dónde encontrarnos 🙂