Cómo crear un motor Text2SQL de nivel de producción

La interacción con bases de datos suele requerir un nivel de conocimientos técnicos que puede hacer que los datos queden fuera del alcance de muchas personas. Pensemos en un ejecutivo de finanzas que necesita comprender las cifras y tendencias financieras de la empresa. Tradicionalmente, este ejecutivo tendría que depender de analistas de SQL para extraer los datos necesarios de la base de datos. Esta dependencia puede provocar retrasos y brechas de comunicación, especialmente si el ejecutivo necesita refinar sus consultas varias veces para obtener la información deseada. Pero text2SQL, una función que convierte el lenguaje natural en instrucciones de lenguaje de consulta estructurado, ha cambiado las reglas del juego. Con text2SQL, el ejecutivo de finanzas puede interactuar directamente con la base de datos utilizando lenguaje natural. Por ejemplo, un usuario puede introducir una pregunta de interés comercial como "¿Cuál fue el valor medio de los pedidos de cada cliente el mes pasado?". El motor de inteligencia artificial de texto a SQL procesará la pregunta y generará la consulta SQL correspondiente: Select customer_id, AVG(order_value) AS average_order_value FROM orders WHERE order_date >= DATE_SUB(CURRDATE(), INTERVAL 1 MONTH) GROUP BY customer_id; Luego ejecútelo contra la base de datos y muestre los resultados al usuario. En este artículo, explicaremos el papel de los LLM en text2SQL, analizaremos los desafíos inherentes a esta capacidad y exploraremos SherloQ, un motor text2SQL altamente preciso y robusto desarrollado por el equipo . de Skypoint El papel de los LLM en text2SQL La capacidad de convertir texto a SQL ha mejorado significativamente con la ayuda de (LLM, por sus siglas en inglés). Estos modelos utilizan grandes cantidades de datos y potentes arquitecturas de redes neuronales para comprender y generar texto similar al de los humanos. Al entrenarse con diversos conjuntos de datos, los LLM pueden generalizarse en diversas tareas, incluida la traducción de lenguaje natural a consultas SQL. los modelos de lenguaje de gran tamaño Por ejemplo, el artículo " " demuestra cómo los modelos lingüísticos pueden realizar tareas con ejemplos mínimos, destacando su capacidad para adaptarse a nuevas tareas con datos limitados. Este enfoque reduce significativamente la necesidad de datos extensos específicos de la tarea, lo que facilita la implementación de los modelos lingüísticos en diversas aplicaciones. Los modelos lingüísticos son aprendices con pocos ejemplos " " proporciona un conjunto de datos completo para entrenar y evaluar modelos en consultas SQL complejas en diferentes dominios. Este conjunto de datos ha sido fundamental para avanzar en el estado del arte en text2SQL al proporcionar un sólido punto de referencia para el rendimiento del modelo. Spider: A Large-Scale Human-Labeled Dataset for Complex and Cross-Domain Semantic Parsing and Text-to-SQL Task Además, " ", explora cómo las técnicas de entrenamiento avanzadas, como ampliar el tamaño de los modelos y optimizar las rutas de entrenamiento, pueden mejorar el rendimiento del modelo en varias aplicaciones, incluido text2SQL. PALM: Escalamiento del modelado del lenguaje con rutas Si bien estos LLM son sumamente eficaces en entornos controlados, suelen enfrentar desafíos en entornos de producción. Estos incluyen el manejo de indicaciones ambiguas, la gestión de esquemas de bases de datos complejos y la garantía de un rendimiento en tiempo real. Además, la integración de estos modelos en sistemas existentes requiere un esfuerzo significativo y un mantenimiento constante para adaptarse a los cambios en los datos y los requisitos de los usuarios. A continuación, se presentan tres LLM que funcionan bien para esta tarea: Codificador SQL El objetivo principal de SQLcoder es convertir la entrada en lenguaje natural en consultas SQL. A diferencia de otros modelos de propósito general, SQLCoder se ha perfeccionado con datos específicos de SQL, por lo que es especialmente eficaz para comprender y generar consultas SQL. SQLCoder demuestra un rendimiento notable en el conjunto de datos Spider, un punto de referencia complejo y multidominio para sistemas text2SQL. SQLCoder genera la consulta SQL correcta para esquemas nuevos que no se ven en el entrenamiento con una . Supera a GPT-3.5-turbo y text-davinci-003, que son modelos con más de 10 veces su tamaño. Esto resalta la capacidad de SQLCoder para manejar consultas SQL diversas y complejas, lo cual es fundamental para los entornos de producción. precisión del 64,6 % GPT3.5/GPT4 GPT-3.5 y GPT-4 (Transformador preentrenado generativo) son algunos de los modelos de lenguaje de propósito general más avanzados y efectivos. Ambos modelos se destacan en el aprendizaje rápido, adaptándose rápidamente a nuevas tareas con ejemplos mínimos, lo que resulta ideal para crear consultas SQL a partir de una entrada limitada. Por ejemplo, cuando se evalúa en el conjunto de datos Spider, GPT-3.5-turbo tiene un porcentaje de consultas SQL generadas correctamente en esquemas nuevos que no se vieron en el entrenamiento del 60,6 %, mientras que GPT-4 alcanza el 74,3 %. Estos modelos muestran un rendimiento sólido, en particular en la comprensión del contexto y la generación de consultas SQL precisas a partir de entradas de lenguaje natural complejas. Sin embargo, su diseño de propósito general a veces requiere un ajuste adicional para obtener resultados óptimos en aplicaciones especializadas como la generación de SQL. SQL de PaLM PaLM (Pathways Language Model) SQL es otro modelo potente desarrollado por Google. Las capacidades y la arquitectura avanzadas de PaLM SQL lo hacen sumamente eficiente para traducir lenguaje natural en consultas SQL y manejar esquemas de bases de datos complejos y diversos con mayor precisión. A pesar de los avances en los LLM, depender de un único LLM para text2SQL en producción puede resultar problemático. Un único modelo no podrá gestionar de forma eficaz la amplia variedad de consultas, esquemas de bases de datos y requisitos de latencia en tiempo real de un entorno de datos empresarial. Los entornos de producción exigen solidez, adaptabilidad y capacidad para gestionar solicitudes ambiguas de usuarios empresariales del mundo real. Por lo tanto, un motor text2SQL debe presentar tres propiedades para ser considerado apto para producción: : las solicitudes de usuario sintácticamente diferentes se pueden reducir a la misma consulta SQL; un buen motor text2SQL debería poder comprender la motivación detrás de una solicitud de usuario, teniendo en cuenta el contexto del modelo de datos, y debería formular la consulta SQL en consecuencia. La capacidad de comprender diversas formulaciones de consultas los modelos de datos de producción son propensos a ser caóticos con múltiples equipos diferentes dentro de una organización que contribuyen a ellos y los datos cambian de propietario varias veces a lo largo de su ciclo de vida. La capacidad de trabajar con esquemas de bases de datos y modelos de datos ambiguos: Un buen motor text2SQL debe tener la capacidad de desambiguar el modelo de datos para el usuario y garantizar que el ruido y la ambigüedad no produzcan alucinaciones, una característica de los LLM actuales que disuaden a muchos usuarios de producción. las respuestas que un usuario espera en tiempo real deben regresar en tiempo real. Esto significa que el motor debe formular consultas óptimas dentro de los primeros tres intentos como máximo. Debe garantizar que el funcionamiento del motor no agregue latencias significativas a la ejecución de la consulta: Presentamos SherloQ SherloQ es el motor text2SQL de Skypoint que traduce consultas de lenguaje natural a SQL. Si bien el uso de un LLM interno personalizado para la generación de consultas es una parte importante de su arquitectura, la eficacia de SherloQ proviene de una combinación de componentes avanzados diseñados para mejorar las capacidades de consulta de datos. SherloQ cuenta con una alta precisión en la traducción de consultas, un manejo sólido de errores y una integración perfecta con los sistemas de bases de datos de producción, lo que lo hace adecuado para entornos de datos a gran escala. En las siguientes secciones, profundizaremos en los detalles arquitectónicos internos de SherloQ y compartiremos algunos de los resultados que hemos logrado al usarlo en entornos de producción. Componentes arquitectónicos de SherloQ La arquitectura de SherloQ contiene múltiples componentes móviles que funcionan para mejorar la precisión, la confiabilidad y la latencia del sistema. A continuación, se ofrece una descripción general de la arquitectura: : la entrada del usuario es una consulta en lenguaje natural. Entrada del usuario nuestra implementación de una interfaz LangChain que rastrea el estado durante todo el proceso de ejecución. Aprovecha Redis y DataStax Astra DB para rastrear el estado del razonamiento y la memoria durante la ejecución. El ejecutor administra el flujo de operaciones mediante la coordinación entre diferentes módulos. Agente de estado Ejecutor: Asegura que las entradas del usuario se analicen, procesen y reenvíen correctamente a los componentes subsiguientes, manteniendo un flujo desde la entrada hasta la generación de consultas SQL. : una clase extendida de la herramienta base Langchain que tiene una variable de estado y pasa ese estado a la herramienta correspondiente. Al mantener una variable de estado, la herramienta de estado realiza un seguimiento de los datos necesarios que deben enviarse a las herramientas respectivas. Esto garantiza la coherencia en el flujo de datos y evita cualquier pérdida de información durante la transición entre agentes. Herramienta de estado : Las herramientas de estado de SherloQ utiliza las consultas recuperadas, el contexto del modelo de datos y el esquema de la base de datos para generar la consulta SQL inicial. Mejora la precisión y la relevancia de las consultas SQL generadas mediante el uso de información de esquema analizada y el aprendizaje a partir de ejemplos contextuales. La herramienta de generación de consultas analiza cualquier error producido durante la ejecución de la consulta y regenera una consulta que soluciona el error. La herramienta de reintento ayuda a recuperar el esquema de la base de datos y los metadatos correspondientes (anotaciones, comentarios, etc.) que serían útiles para la generación de consultas. La información del esquema recuperada se almacena en caché mediante un mecanismo de almacenamiento en caché basado en el tiempo para optimizar el rendimiento y reducir las consultas a la base de datos. También ejecuta la consulta en la base de datos y devuelve los resultados o un seguimiento de la pila de errores. La herramienta DB Entradas de datos y técnicas para mejorar el rendimiento de SherloQ Para mejorar el rendimiento de SherloQ, empleamos varias técnicas y proporcionamos al modelo datos de entrada importantes. Estos consisten en descomposición estructurada, ejemplos de pocos intentos, recuperación del contexto del modelo de datos, reflexión y un mecanismo de reintento. Cada parte es esencial para mejorar la capacidad del modelo de producir consultas SQL precisas y relevantes a partir de datos de entrada en lenguaje natural. Descomposición estructurada En la descomposición estructurada, la solicitud de usuario se divide en sus partes fundamentales. Centrarse en los componentes esenciales de la consulta e identificarlos ayuda al modelo a generar SQL preciso. Por ejemplo: Entrada: ¿Cuál es la cantidad actual disponible de todos los artículos suministrados por XYZ Corp? Salida: ["cantidad actual disponible", "todos los artículos", "suministrado por XYZ Corp"] Ejemplos de pocos disparos El modelo recibe preguntas de referencia en forma de algunos ejemplos de SQL, que lo ayudan a generar consultas SQL basadas en patrones similares. Estos ejemplos mejoran la capacidad del modelo para generar con precisión nuevas consultas SQL para varias indicaciones, ya que lo ayudan a reconocer la estructura y el formato de las consultas previstas. A continuación, se incluyen algunos ejemplos: Ejemplo 1 Entrada: Mostrar artículos con una cantidad menor a 20 unidades disponibles. Salida: SELECCIONAR * DE stock DONDE Cantidad_Disponible 100); Seleccionamos dinámicamente los ejemplos de tomas más similares mediante la comparación de similitud semántica de que es nuestra base de datos vectorial. La base de datos vectorial nos permite encontrar los ejemplos que tienen una estructura y un contenido más cercanos a la nueva consulta de entrada, lo que garantiza que el modelo pueda aprovechar los patrones más relevantes para generar consultas SQL precisas. Astra DB, En nuestro entorno de producción, utilizamos un promedio de dos ejemplos de pocos intentos por consulta. Según nuestra experiencia, simplemente agregar más ejemplos de pocos intentos para mejorar la precisión no es una práctica escalable. Contexto del modelo de datos El contexto del modelo de datos contiene detalles específicos del dominio que pueden resultar útiles para crear una consulta SQL. Por ejemplo, en el contexto de los datos financieros de una red hospitalaria, estos pueden ser elementos como códigos de métricas financieras y sus descripciones. El modelo utiliza este contexto para asegurarse de que las consultas SQL que se crean coincidan con la estructura de datos del dominio. La inclusión del contexto del modelo de datos es opcional y solo se requiere cuando la tabla es compleja y requiere conocimiento del dominio para formar una consulta SQL. Por ejemplo: "MGMTFEE" -> Descripción: "Tarifas cobradas por la administración de propiedades – Tarifas de administración" Códigos métricos: Esquema de base de datos SQL El esquema de base de datos SQL es la representación estructurada de los datos disponibles. El esquema se enriquece con anotaciones tanto en la tabla como en sus columnas. Incluye nombres y descripciones de las tablas, junto con las columnas, sus descripciones y los tipos de datos. Proporcionar el esquema ayuda al modelo a comprender la estructura de la base de datos y el significado asociado con cada tabla y columna, lo que garantiza que las consultas SQL generadas sean sintácticamente correctas y utilicen los elementos de base de datos correctos. Reflexión La reflexión se refiere a la capacidad del modelo de evaluar sus propias respuestas, comportamiento o contenido generado en el pasado. Permite que el modelo refine sus respuestas identificando y corrigiendo errores o debilidades. El proceso incluye la consideración de consultas vistas previamente por el motor Sherloq junto con la retroalimentación durante la fase de generación de consultas. Estos escenarios ayudan al modelo a replicar los éxitos o evitar los fracasos de preguntas similares que ha visto en el pasado. Este paso también aprovecha Astra DB para encontrar las consultas semánticamente más similares a la actual. Mecanismo de reintento SherloQ incorpora un mecanismo de reintento que utiliza los errores recibidos de la base de datos. Cuando una consulta SQL generada genera un error, el motor utiliza un agente con una plantilla predefinida para corregir la consulta: “”” Su tarea consiste en corregir una consulta SQL incorrecta generada a partir de una pregunta para que sea compatible con ANSI SQL. Siga estas pautas: analice con atención la pregunta, el esquema de la base de datos y el mensaje de error recibido para garantizar respuestas precisas. Utilice alias de tabla para evitar confusiones. Por ejemplo, . SELECT t1.col1, t2.col1 FROM table1 AS t1 JOIN table2 AS t2 ON t1.id = t2.id Al calcular las proporciones, convierta siempre el numerador a un número flotante. Utilice el siguiente formato: Tarea: Generar una consulta SQL para abordar la pregunta [QUESTION] [/QUESTION] La consulta que debe ser correcta es: {sql_query} El mensaje de error recibido durante la última ejecución es: {error_message} {user_input} Respuesta: En base a las entradas anteriores, aquí está la consulta SQL corregida: {response_sql} “”” Comparación de resultados: antes y después de la implementación de SherloQ Con el uso de LLM avanzados y un sistema bien diseñado, SherloQ produce consultas SQL que son más precisas y relevantes para el contexto. Aquí, comparamos los resultados de las solicitudes de usuario antes y después de SherloQ utilizando las métricas de latencia y precisión. Comparación utilizando una pregunta de producción En este artículo, analizamos el caso de uno de nuestros clientes de producción, un conocido operador de residencias para personas mayores. Uno de sus casos de uso es el de su equipo de finanzas, que utiliza la plataforma de Skypoint para comprender y analizar las métricas financieras consolidadas de sus diferentes residencias para personas mayores. "Determinar la tendencia trimestral de los gastos de limpieza de la instalación CM a lo largo de 2022". Mensaje para el usuario: Antes de SherloQ Consulta generada SELECCIONAR SUMA(Numerador_de_importe_total) / SUMA(Denominador_de_importe_total) COMO Gastos_de_limpieza DE skypoint_metric_fact_denormalized_vw DONDE Nombre_de_instalación = 'CM' Y Año = 2022 Y Nombre_de_métrica = 'Gastos de limpieza' AGRUPAR POR Número_de_trimestre'; Problemas identificados La consulta agrupa por Quarter_Number pero no lo selecciona, lo que puede generar resultados incompletos. Uso de Metric_Name en lugar de un identificador más específico como Metric_Code. La división potencial por cero no se maneja en SUM(Total_Amount_Denominator). Latencia media: 29 segundos La configuración anterior a SherloQ utilizaba una combinación de GPT-3.5 junto con ingeniería rápida y más de 5 consultas de pocos intentos por solicitud de usuario. Con SherloQ Consulta generada SELECCIONAR Año, Número_de_trimestre, SUMA(Numerador_de_importe_total) / COALESCE(SUMA(NULLIF(Denominador_de_importe_total,0)),1) COMO Gastos_de_mantenimiento DE skypoint_metric_fact_denormalized_vwDONDE Código_de_métrica = 'EXPOTHHOU' Y Nombre_de_instalación = 'CM' Y Año = 2022 AGRUPAR POR Número_de_trimestre, Año ORDENAR POR Número_de_trimestre ASC; Se observaron mejoras La consulta incluye Quarter_Number, que proporciona el desglose trimestral necesario. Se utiliza el campo Metric_Code, que proporciona un identificador más preciso para la métrica. La función COALESCE(SUM(NULLIF(Total_Amount_Denominator,0)),1) maneja posibles errores de división por cero. Los resultados se ordenan por Quarter_Number para reflejar la tendencia trimestral. Latencia media: 10 segundos Con base en evaluaciones comparativas sobre cargas de trabajo de producción, a continuación se presentan los resultados que informamos sobre precisión y confiabilidad antes y con SherloQ: Antes de SherloQ Precisión: 65% Confiabilidad: 60% Con SherloQ Precisión: 92% Confiabilidad: 90% Los resultados anteriores se obtuvieron de un conjunto de pruebas comparativas internas que ejecuta cada mensaje 100 veces con identificadores separados para anular los efectos del almacenamiento en caché (en nuestros sistemas internos y en los modelos). El conjunto mide la precisión comparando la respuesta devuelta con una respuesta comparativa y la confiabilidad midiendo la frecuencia con la que devolvería respuestas similares. La comparación ilustra claramente las ventajas de SherloQ a la hora de transformar consultas en lenguaje natural en consultas SQL precisas. El rendimiento general mejoró un 30 % después de SherloQ. Las consultas generadas anteriormente presentaban problemas como resultados incompletos y falta de gestión de errores, lo que afectaba tanto a la precisión como a la fiabilidad. Con SherloQ, las consultas generadas son más precisas, eficientes y robustas, con mejoras notables en latencia, precisión y confiabilidad. Esta mejora demuestra la capacidad de SherloQ para ofrecer una recuperación de datos confiable, lo que la convierte en una herramienta valiosa para las organizaciones que buscan optimizar sus procesos de consulta de datos. Para explorar otras partes de la plataforma Skypoint o reservar una demostración de SkyPoint AI, visite el . sitio web de Skypoint Por Alok Raj, ingeniero principal de inteligencia artificial de Skypoint, y Sayandip Sarkar, director de ingeniería de Skypoint