text to sql bedrock workshop
Module 4: Security for Text-to-SQL
Los almacenes de datos empresariales representan muchas de las mayores inversiones en tecnología para empresas de todos los sectores en los últimos 20 años. Si bien la IA generativa se ha mostrado muy prometedora en la creación de contenido novedoso y la comprensión de grandes corpus de información en formato no estructurado, ¿cómo mejorará el consumo de los datos en los que las organizaciones han invertido tanto para hacerlos útiles? Estas fuentes de datos se encuentran entre las más confiables de una organización y, en muchos casos, impulsan decisiones en los niveles más altos de liderazgo.
Desde sus inicios en los años 70, el lenguaje de consulta de estructura (SQL) ha sido el lenguaje más ubicuo para interactuar con bases de datos, pero aún se necesita una comprensión profunda de la teoría de conjuntos, los tipos de datos y las relaciones de clave externa para poder entender los datos. . La IA generativa ofrece una manera de cerrar esta brecha de conocimientos y habilidades al traducir preguntas en lenguaje natural a una consulta SQL válida.
Los sistemas y las personas que se beneficiarán de este patrón de acceso a las bases de datos incluyen personas sin conocimientos técnicos que buscan incorporar fuentes de datos relacionales en su proceso, como agentes de servicio al cliente y asociados de centros de llamadas. Además, los casos de uso técnico incluyen canalizaciones de extracción, transformación y carga, arquitecturas de generación aumentada de recuperación (RAG) existentes que integran bases de datos relacionales y organizaciones que trabajan con una plataforma de datos demasiado grande para navegar razonablemente de forma aislada.
Los componentes más difíciles de crear una consulta SQL precisa a partir de lenguaje natural son los mismos con los que podríamos haber tenido problemas como recién llegados al lenguaje. Conceptos como identificar relaciones de clave externa, dividir la pregunta en consultas anidadas más pequeñas y unir tablas correctamente se encuentran entre los componentes más difíciles de la generación de consultas SQL. Según los investigadores, más del 50% de las pruebas de generación de SQL fallan únicamente en la vinculación y unión de esquemas.
Además de estos componentes centrales de la consulta, cada motor de base de datos tiene su propia sintaxis que puede garantizar el dominio para escribir una consulta válida. Además, en muchas organizaciones, hay muchos atributos de datos superpuestos (un valor se agrega en una tabla y no en otra, por ejemplo), así como nombres de columnas abreviados que requieren conocimientos tribales para usarlos correctamente.
Entonces, ¿qué tan cerca estamos de resolver este problema? La comunidad se ha unido en torno a dos tablas de clasificación principales que clasifican los enfoques más exitosos con conjuntos de datos etiquetados: Spider y BIRD. Ambas tablas de clasificación priorizan la métrica más importante para medir la precisión de cualquier enfoque determinado para resolver este problema, llamada Precisión de Ejecución (EX). Esta métrica simplemente compara la consulta SQL generada con la consulta SQL etiquetada para determinar si coincide o no. Además, SPIDER mide la precisión de coincidencia de conjuntos exactos (EM): ¿el conjunto de resultados devuelto realmente respondió a la pregunta, independientemente de cómo se escribió la consulta? Y BIRD ofrece puntuación de eficiencia válida (VES), una medida del rendimiento de la consulta SQL generada. Puede leer más sobre cada conjunto de datos de referencia en sus respectivas páginas.
Los conjuntos de datos Spider y BIRD han demostrado ser conjuntos de datos sólidos y autorizados para comparar técnicas de texto a SQL e incluso ajustar modelos. A lo largo de este módulo nos referiremos a estos conjuntos de datos y sus tablas de clasificación correspondientes para demostrar los enfoques más sólidos de Texto a SQL.
Según la tabla de clasificación BIRD, el estado del arte para el problema de texto a SQL se sitúa en un 60% de precisión de ejecución. Si bien eso todavía está muy por debajo del desempeño humano, tenga en cuenta que en un año hemos pasado del modelo T5 de referencia con un rendimiento del 7% de EM a un año después viendo que el EM supera el 60%. Estamos entusiasmados de ver cómo esto mejora aún más el próximo año a medida que se continúan investigando estos modelos y técnicas.
Es importante tener en cuenta que estas técnicas están optimizadas para una sola cosa: generar la consulta SQL correcta. Estas tablas de clasificación no evalúan algunos aspectos críticos de estas técnicas, sobre todo la velocidad. Muchas de estas técnicas demuestran una velocidad de cadena de avisos de extremo a extremo de más de unos pocos segundos, que muchos casos de uso de inteligencia empresarial de cero impacto no pueden tolerar. Además, muchos de ellos también hacen múltiples inferencias a un LLM para completar el razonamiento necesario, lo que puede aumentar considerablemente el costo por consulta.
Este taller está diseñado para ser una progresión de técnicas de texto a SQL, comenzando con una sólida ingeniería rápida. Todo el código está en forma de Jupyter Notebooks, alojado en SageMaker Studio. Cuando esté listo para comenzar, diríjase a Configuración para comenzar la implementación de los recursos necesarios para este taller.
A continuación se muestra un resumen del contenido del taller:
