Transformer du texte en langage naturel vers SQL

Les subtilités du langage humain, notamment ses ambiguïtés et coréférences, posent toujours des difficultés majeures pour le traitement du langage naturel (TLN). Cet obstacle se manifeste particulièrement lorsqu’il s’agit de générer des requêtes automatisées en SQL à partir d’un énoncé en langage naturel. L’engouement pour cette problématique a été renouvelé grâce à l’avènement de modèles linguistiques performants.

La conversion de questions exprimées en langage naturel en requêtes SQL pourrait par exemple :

• permettre à des non-développeurs d’exploiter des données analytiques;
• optimiser la vitesse d’extraction d’informations propres à un domaine;
• valoriser la masse de données disponibles.

Dans ce billet, nous explorons des techniques d’analyse sémantique et de mappage syntaxique pour créer une solution universelle de conversion du langage naturel vers SQL.

Contexte

Une portion conséquente du volume de données produit reste non analysée à cause :

• d’infrastructures inadaptées;
• de méthodes de traitement inefficaces;
• du manque de main-d’œuvre compétente pour les exploiter.

Les spécialistes du TLN ont combiné des techniques comme le mappage basé sur des règles et l’encodage bidirectionnel avec l’apprentissage par renforcement pour mieux interpréter le langage naturel. Malgré leur précision, le déploiement de modèles d’apprentissage profond pose problème en raison :

• des délais de production;
• de la nécessité d’utiliser des bases de données conséquentes, bien structurées et étiquetées.

De nombreux travaux de recherche, dont ceux mentionnés par (Androutsopoulos, Ritchie & Thanisch, 1995), offrent un panorama des techniques de création d’interfaces en langage naturel pour les bases de données. (Blackburn et Bos, 2005) ont exploré la sémantique computationnelle, tandis que (Lappin, 1996) ou (Benthem & Meulen, 1997) ont étudié des techniques plus sophistiquées de parsage sémantique, notamment la gestion des temps verbaux et l’intégration de quantificateurs universels dans les annotations grammaticales.

Toutefois, la plupart des systèmes supervisés et semi-supervisés sont, comme le notent (Vadim Sheinin et al., 2018), propres à un domaine. Par conséquent, il faut répéter le processus pour d’autres secteurs et types de données. Cette méthode pose des problèmes comme :

(i) la nécessité d’avoir des corpus et des questions annotés spécifiquement pour chaque domaine;

(ii) la nécessité d’associer des vecteurs-mots aux mots de contexte pour capter l’information contextuelle;

(iii) le coût en temps et en ressources pour créer un prototype viable, souvent difficile à justifier en termes de retour sur investissement pour les entreprises.

Notre approche

Nombre de travaux sur le parsage sémantique dans les bases de données structurées ont montré l’efficacité de l’entraînement semi-supervisé utilisant des ensembles de données étiquetés sous forme de paires questions-réponses. Cependant, la collecte de jeux de données spécifiques en temps réel est sous-optimale.

Dans notre méthode, la conversion d’une question en langage naturel en SQL se fait en trois étapes :

• (i) analyse basée sur des règles prédéfinies;
• (ii) élaboration de logiques d’interprétation;
• (iii) combinaison des informations déduites avec des opérateurs syntaxiques.

Exemples :

Voici quelques exemples basés sur des données relatives à la COVID-19 :
Q1 : « Combien y avait-il de cas de COVID-19 à Beijing il y a 3 mois? »

SELECT * FROM data
WHERE ((LastUpdate LIKE '%2021-02%'
    OR ObservationDate LIKE '%2021-02%')
    AND Province_State LIKE '%Beijing%');

Q2 : « Quel est le taux moyen de guérisons en %Chine continentale%? » se traduit par :

SELECT AVG(Recovered) AS AVG_OF_COLUMN
FROM data
WHERE Country_Region = ‘Mainland China;

Q3 : « Peux-tu me fournir des détails sur le Tibet et la %Chine continentale%? » devient :

SELECT * 
FROM data
WHERE Province_State = 'Tibet' 
  AND (Country_Region ='Mainland China')

Prochaines étapes

Le secteur du TLN est en effervescence, avec de nombreux travaux visant à permettre l’intégration de plusieurs tables à l’aide de jointures et de sous-requêtes. C’est un atout majeur quand il s’agit de combiner des sources de données hétérogènes pour obtenir une solution.

Si l’on travaille sur des solutions sur mesure, le processus est simplifié puisque les modèles peuvent être entraînés à reconnaître un vocabulaire spécifique comme des mots-clés. En revanche, les choses se corsent lorsqu’on essaie de développer une solution universelle. Dans cette optique, une approche itérative combinant tests et entraînements s’avère être la plus judicieuse.

Références similaires en source libre :

1. https://blog.einstein.ai/how-to-talk-to-your-database/
2. https://paperswithcode.com/task/text-to-sql
3. https://web.stanford.edu/class/archive/cs/cs224n/cs224n.1194/reports/custom/15844304.pdf