TecNoticias, tu portal de información

El arte de consultar bases de datos SQL en lenguaje natural

Crédito de la imagen: Exploring the Unknown por Soma Biswas (Flickr: enlace, republicado con permiso) “el futuro de BI es conversacional”: esto es lo que Gartner y otros analistas nos han estado diciendo durante los últimos años. Centrémonos en datos estructurados, datos relacionales para ser más precisos. Esto forma el formato de almacenamiento subyacente para la mayor parte del mundo de Business Intelligence (BI), independientemente de si está consultando la base de datos de forma interactiva o creando un informe en Tableau, Power BI, Qlik Sense, etc. El idioma predominante para interactuar con dichas plataformas de almacenamiento es Sql. Ya hemos visto algunos productos en este espacio, por ejemplo, Power BI Q&A, Salesforce Photon.

Estamos hablando de traducir una consulta de lenguaje natural (NLQ) a SQL en este artículo, también conocida como interfaz de lenguaje natural para bases de datos (NLIDB).

Por ejemplo, consideremos una tabla de países con detalles de idioma y población: esquema ilustrativo a continuación:Mesa de campo: ID de país | Nombre | Idioma | Recuento de población
NLQ1: ¿Qué país tiene el número máximo de habitantes?
SQL1: Seleccione Nombre, max([Population Count]) del país; en el centro de la mayoría de los sistemas de preguntas y respuestas de lenguaje natural [1], es un módulo de Unidad de comprensión del lenguaje natural (NLU) que intenta comprender la intención del NLQ extrayendo y clasificando las ‘expresiones’. En palabras simples, uno puede pensar en los enunciados como frases clave en la oración, por ejemplo, país, máximo, población, número.Fig: Arquitectura de referencia Text-to-SQL (Imagen del autor) El siguiente paso es generar la consulta SQL correspondiente en base a esta información. Por lo tanto, necesitamos una lógica de transformación / mapeo para asignar ‘país’ a la tabla ‘País’ (la tabla que se consultará), ‘máximo’ al operador SQL ‘máximo’, ‘recuento de población’ a la columna ‘recuento de población’. Y aquí es donde las cosas comienzan a ponerse desafiantes.

La asignación de expresiones NLQ a los operadores SQL correctos, especialmente para determinar si una expresión corresponde a una tabla, columna, clave primaria/foránea, operador SQL, en primer lugar, no es trivial.

Por ejemplo, sin ningún conocimiento inherente del esquema de la base de datos, es muy difícil para la lógica de mapeo determinar que el ‘recuento’ en este caso se refiere a la columna ‘recuento de población’ y no al operador SQL COUNT. El problema se amplifica para consultas complejas, por ejemplo, NLQ2: ¿Qué idioma hablan la mayor cantidad de países? cuya traducción de SQL involucraría a ambos operadores de SQL: MAX y COUNT. Otros ejemplos de consultas complejas incluyen escenarios en los que necesitamos UNIR varias tablas. En esta sección, hacemos una inmersión profunda en el dominio del problema, reflexionando sobre la literatura / enfoques existentes, para comprender los desafíos técnicos involucrados. Hay dos conjuntos de datos de referencia que se hace referencia principalmente en este campo: WikiSQL: es un gran corpus anotado para desarrollar interfaces de lenguaje natural, que se presentó junto con el documento [2].Spider es un conjunto de datos de texto a SQL y análisis semántico anotado a gran escala. SParC es la versión dependiente del contexto/de múltiples turnos de Spider, y CoSQL es la versión de diálogo de los conjuntos de datos de Spider y SParC. Para una discusión detallada, consulte el documento adjunto [3]Como destaca Spider en su texto introductorio, cualquier solución de NLIDB no solo debe comprender el esquema de la base de datos subyacente, sino que también debe generalizarse a nuevos esquemas. El desafío de la generalización radica en (a) codificar el esquema de la base de datos para el analizador semántico y (b) modelar la alineación entre las columnas de la base de datos, las claves y sus menciones en un NLQ dado. [4]Con este contexto, echemos un vistazo a algunos trabajos que han intentado codificar el conocimiento del esquema de base de datos (faltante) en redes neuronales. Los gráficos dirigidos son un formalismo popular para codificar relaciones de esquemas de bases de datos.[4] presenta un marco unificado para abordar la codificación de esquemas, la vinculación y la representación de características dentro de un codificador de texto a SQL. [5] codifica el esquema de la base de datos con una red neuronal gráfica, y esta representación se utiliza tanto en el momento de la codificación como en el de la decodificación en un analizador semántico codificador-descodificador. [6] presenta un codificador gráfico de interacción de esquema de base de datos para utilizar información histórica de elementos de esquema de base de datos. En la fase de decodificación, se utiliza un mecanismo de puerta para sopesar la importancia de los diferentes vocabularios y luego hacer una predicción de tokens SQL. Modelos de lenguaje grandes preentrenados [7] ya que los generadores de texto a SQL ayudan hasta cierto punto, especialmente, con respecto a la codificación de nombres de tablas y columnas aprovechando el mecanismo de atención [8]. Sin embargo, todavía luchan con las relaciones de esquema para operaciones SQL complejas.

Los documentos muestran un progreso significativo en la incorporación de esquemas de bases de datos, sin embargo, todavía son específicos para los conjuntos de datos en consideración; y no generaliza bien a nuevos dominios/esquemas.

En esta sección, consideramos enfoques para agregar mejor estas relaciones de esquema de base de datos/conocimiento de dominio faltantes a un generador de texto a SQL.

Enfoque manual

La mayoría de los sistemas de preguntas y respuestas actuales consisten en una unidad de comprensión del lenguaje natural (NLU) capacitada para reconocer la consulta del usuario de manera supervisada. Esto incluye los sistemas de preguntas y respuestas disponibles actualmente en el mercado, por ejemplo, Google DialogFlow, Amazon Lex, Microsoft LUIS, RASA.

Por lo tanto, primero deben capacitarse proporcionando un conjunto de NLQ, variaciones de preguntas y sus respuestas correspondientes, que en este caso serían las consultas SQL correspondientes.

Junto con las ‘intenciones’ y las ‘expresiones’, una parte esencial en la personalización de los sistemas de preguntas y respuestas es proporcionar ‘entidades’ [9]. Las entidades se refieren al vocabulario específico del dominio, por ejemplo, pueden referirse a las ubicaciones de las oficinas de una organización, en el contexto de una aplicación de recursos humanos.Fig: (Ilustrativo) Configuración manual en IBM Watson AssistantEl punto aquí es que similar a la configuración/entrenamiento de Chatbots, también podemos ingresar el conocimiento del dominio en forma de un esquema de base de datos a mano en este caso, para mejorar la generación de texto a SQL en los sistemas NLIDB. Para aclarar, un analizador SQL puede extraer la tabla, los nombres de las columnas, las relaciones clave, etc., del archivo de especificación del lenguaje de definición de datos (DDL) subyacente.

Entonces, el conocimiento que debe ingresarse manualmente en este caso es la descripción en lenguaje natural de tablas, columnas y sus relaciones, que falta en la mayoría de las documentaciones de bases de datos.

Si bien el enriquecimiento manual funciona y suele ser el enfoque más confiable; es importante recordar aquí que los sistemas NLIDB están destinados principalmente a usuarios comerciales, consumidores de informes / tableros; que pueden no estar muy cómodos con la entrada de datos técnicos. Además, esta no es una entrada de datos única, y el conocimiento del dominio codificado deberá adaptarse cada vez que cambie el esquema de la base de datos subyacente.

Enfoques automatizados basados ​​en Aprendizaje Activo/Reforzado

Una buena manera de iniciar generadores de texto a SQL es aprendiendo de los registros de consultas SQL existentes y los informes de BI. Es justo decir que la mayoría de los sistemas NLIDB complementarán las plataformas de BI existentes. Por lo tanto, tiene sentido aprovechar los registros SQL históricos y los informes/paneles existentes para comprender las consultas SQL más frecuentes y, en consecuencia, los NLQ que se pueden usar para la capacitación inicial. La capacidad de generalización de este modelo inicial se puede mejorar introduciendo una tarea auxiliar, que puede aprender explícitamente el mapeo entre entidades en el NLQ y tablas, columnas, nombres clave en el esquema [10]. Trabajos recientes han extendido esto a tareas de aprendizaje de pocas tomas (entorno de aprendizaje activo en general), por ejemplo, [11] propone una estrategia de metaaprendizaje eficiente que utiliza una actualización de gradiente de dos pasos para obligar al modelo a aprender una capacidad de generalización hacia tablas de tiro cero. Los enfoques de aprendizaje por refuerzo (RL) también son interesantes en este contexto, donde una red Q profunda ( El agente DQN) se puede entrenar para “puntuar” consultas novedosas (no vistas), de modo que se puedan agregar de manera efectiva para aumentar el conjunto de datos de entrenamiento (fuera de línea). Por ejemplo, [12] propone un chatbot empresarial de mejora automática basado en RL que muestra un aumento en el rendimiento de una tasa de éxito inicial del 50 % al 75 % en 20 a 30 épocas de capacitación.Fig: Aumento basado en el aprendizaje reforzado del conjunto de datos de entrenamiento de preguntas y respuestas (Imagen del autor) Concluimos con algunas ideas para el futuro. Con text-to-SQL, el objetivo principal ha sido recrear el paradigma de consultas SQL a bases de datos, a uno que utiliza consultas de lenguaje natural (NLQ).

Creemos que BI conversacional será mucho más disruptivo, al permitir nuevas formas de interactuar con bases de datos (o almacenes de datos en general).

Por ejemplo: Bot de metadatos: Dada la complejidad de las bases de datos empresariales y la consiguiente dificultad para codificarlas; puede ser que hayamos estado abordando mal el problema para iniciarlos. Si podemos proporcionar a los usuarios un sistema de preguntas y respuestas (llamémoslo Meta Bot, meta como en consultas de metadatos, y nada que ver con Meta / Facebook) que pueda responder consultas reg. el esquema de la base de datos, por ejemplo, ‘¿Qué tabla contiene los datos de ventas de Suiza?’ junto con algún tipo de autocompletado para operadores SQL, por ejemplo, ‘¿Tenemos los datos de ventas de Alemania y España en una tabla?’, respondido por una combinación/filtro en la(s) tabla(s) respectiva(s); los usuarios podrán redactar sus consultas SQL de forma eficiente, sin necesidad de conocimientos avanzados de SQL. Consultas incrementales: El punto anterior ya alude a ello. Las consultas de hoy en día son en su mayoría de una sola vez. Nuestras conversaciones, por otro lado, tienen un flujo, continuamos con lo que se ha dicho antes, según el contexto histórico. Sí, un procedimiento almacenado realiza consultas SQL en secuencia; sin embargo, es una lógica predefinida. BI conversacional permitiría refinar gradualmente los resultados de la consulta en tiempo real, hasta que el usuario encuentre los datos que está buscando en tiempo real.Fig: Consultas incrementales (Imagen del autor)D. Biswas. Chatbots y búsqueda de lenguaje natural. Hacia la ciencia de datos, https://towardsdatascience.com/chatbots-natural-language-search-cc097f671b2bVictor Zhong, Caiming Xiong y Richard Socher. 2017. Seq2SQL: generación de consultas estructuradas a partir del lenguaje natural mediante el aprendizaje por refuerzo. https://arxiv.org/abs/1709.00103Tao Yu, et al. 2018. Spider: un conjunto de datos a gran escala etiquetado por humanos para el análisis semántico complejo y entre dominios y la tarea de texto a Sql. https://arxiv.org/abs/1809.08887Bailin Wang, et. Alabama. 2020. RAT-SQL: codificación y vinculación de esquemas con reconocimiento de relaciones para analizadores de texto a SQL. En Proc. de la 58ª Reunión Anual de la Asociación de Lingüística Computacional. https://doi.org/10.18653/v1/ 2020.acl-main.677Ben Bogin, Matt Gardner, Jonathan Berant (2019). Representación de la estructura del esquema con redes neuronales gráficas para el análisis de texto a SQL. ACL, https://arxiv.org/pdf/1905.06241.pdfYitao Cai y Xiaojun Wan. 2020. IGSQL: modelo neuronal basado en gráfico de interacción de esquema de base de datos para la generación de texto a SQL dependiente del contexto. En Proc. de la Conferencia de 2020 sobre métodos empíricos en el procesamiento del lenguaje natural (EMNLP), https://aclanthology.org/2020.emnlp-main.560.pdfLin, XV, Socher, R. y Xiong, C. (2020). Conexión de datos textuales y tabulares para el análisis semántico de texto a SQL entre dominios. RECOMENDACIONES. https://arxiv.org/abs/2012.12627Bahdanau, Dzmitry, Kyunghyun Cho y Yoshua Bengio. Traducción automática neuronal mediante el aprendizaje conjunto para alinear y traducir. https://arxiv.org/pdf/1409.0473.pdfW. Shalaby, A. Arantes, TG Díaz y C. Gupta. Creación de chatbots a partir de bases de conocimiento específicas de dominio a gran escala: Desafíos y oportunidades, 2020, https://arxiv.org/pdf/2001.00100.pdfChang, S., Liu, P., Tang, Y., Huang, J., He , X. y Zhou, B. (2020). Aprendizaje de texto a SQL de tiro cero con tarea auxiliar. AAAI, https://arxiv.org/pdf/1908.11052.pdfChen, Y., Guo, X., Wang, C., Qiu, J., Qi, G., Wang, M. y Li, H. ( 2021). Aprovechamiento del contenido de la tabla para conversión de texto a SQL de disparo cero con metaaprendizaje. AAAI, https://arxiv.org/pdf/2109.05395.pdfE. Ricciardelli, D. Biswas. Chatbots de automejora basados ​​en Aprendizaje por Refuerzo. RLDM 2019, https://towardsdatascience.com/self-improving-chatbots-based-on-reinforcement-learning-75cca62debce