{"id":911,"date":"2022-07-10T01:00:22","date_gmt":"2022-07-10T01:00:22","guid":{"rendered":"https:\/\/ingenieriadesoftware.es\/?p=911"},"modified":"2022-08-27T16:35:44","modified_gmt":"2022-08-27T16:35:44","slug":"traduccion-texto-a-sql-habla-base-de-datos-lenguaje-natural","status":"publish","type":"post","link":"https:\/\/ingenieriadesoftware.es\/traduccion-texto-a-sql-habla-base-de-datos-lenguaje-natural\/","title":{"rendered":"Habla con tu base de datos: Herramientas Texto-a-SQL"},"content":{"rendered":"

Cada d\u00eda que pasa nos acercamos m\u00e1s al “viejo” objetivo del End-user development,\u00a0<\/em>es decir, permitir que un usuario no t\u00e9cnico sea capaz de tener cierta autonom\u00eda<\/a> en la creaci\u00f3n o adaptaci\u00f3n de las aplicaciones de las que depende para su trabajo diario.\u00a0Bajo diferentes nombres (low-code, no-code, no-work,…<\/a>) todas las grandes empresas siguen esta tendencia<\/a>.<\/p>\n

\u00bfY qu\u00e9 mejor manera de empoderar un usuario que permitirle hablar con el software en lenguaje natural?. \u00bfTe imaginas que una persona, sin ning\u00fan conocimiento t\u00e9cnico, pueda pedir lo que quiera y que el software que necesita se cree autom\u00e1ticamente para \u00e9l?. Pues de momento, toca seguir so\u00f1ando ????. Por mucho que haya algunas demos de generadores de c\u00f3digo impresionantes<\/a> y que herramientas como GitHub Copilot<\/a> (basado en los modelos OpenAI Codex<\/a>) sean cada vez m\u00e1s populares, estamos todav\u00eda hablando de trozos de c\u00f3digo peque\u00f1os y parciales. Y a veces incorrectos. Queda mucho por recorrer.<\/p>\n

Con una excepci\u00f3n. Hay una \u00e1rea donde s\u00ed que pienso que este tipo de herramientas est\u00e1n muy cerca de ser \u00fatiles y a la vez utilizables para el gran p\u00fablico: la consulta de bases de datos SQL<\/strong>. Por dos razones:<\/p>\n

    \n
  1. El gran inter\u00e9s que tiene este campo<\/strong>. La consulta eficiente de datos es una actividad clave en muchos puestos de trabajo. A\u00fan recuerdo las maravillas que he visto hacer al personal de administraci\u00f3n con el Query Builder de Access<\/a> (para los “j\u00f3venes”: una especie de interfaz gr\u00e1fica para dise\u00f1ar consultas) y as\u00ed no tener que esperar a que les gener\u00e1semos la consulta SQL equivalente.<\/li>\n
  2. Lo acotado que es este problema<\/strong>. Lo podemos reducir a una transformaci\u00f3n que tenga como entrada una cadena de texto que expresa la consulta en lenguaje natural (ingl\u00e9s, espa\u00f1ol,…) y como salida una cadena de texto equivalente en lenguaje SQL<\/a>.<\/li>\n<\/ol>\n

    No digo que sea f\u00e1cil, pero s\u00ed que es m\u00e1s realista. Hace unos a\u00f1os se hab\u00eda intentado con sistemas de reglas que intentaban reconocer patrones pero con resultados m\u00e1s bien pobres. La llegada de la IA ha revolucionado tambi\u00e9n este sector. Tenemos ya varios modelos de lenguaje capaces de realizar este tipo de traducci\u00f3n, todos siguiendo la arquitectura Transformers<\/a>, preentrenados (o “fine-tuned”) con los datasets WikiSQL<\/a> o Spider<\/a>.<\/p>\n

    Los dos incluyen miles de pares de ejemplos de consultas en ingl\u00e9s y su correspondiente traducci\u00f3n a SQL. WikiSQL es m\u00e1s grande pero se limita a ejemplos sobre una \u00fanica tabla. Spider es m\u00e1s peque\u00f1o pero incluye ejemplos de consultas multi-tabla y m\u00e1s complejas.<\/p>\n

    Los diferentes modelos var\u00edan dependiendo de si:<\/p>\n