Vers la construction du moteur de requête de base de données de nouvelle génération

Et si les moteurs de base de données d’hier ne sont pas capables de résoudre les problèmes actuels?

Dans les années 1970, la base de données relationnelle était née. À l’heure actuelle, ils constituent toujours l’épine dorsale de nos systèmes d’information, des entreprises typiques du Fortune 500 exploitant des milliers de bases de données SQL. Plus de la moitié des entreprises commencent à explorer l’apprentissage automatique, mais si c’est parce que leurs bases de données actuelles ne répondent pas à leurs besoins en informations?

Les bases de données relationnelles ont émergé des ingénieurs qui construisaient des applications simples pilotées par les données. Les mêmes schémas se dégageraient: par exemple nous avons des utilisateurs, et ils achètent des articles, et ces achats ont des transactions par carte de crédit, et nous devons relier toutes ces données entre elles. En prenant en charge ces relations dans la base de données, par exemple, un achat appartient à un utilisateur, l’ingénieur peut éviter d’écrire les mêmes fonctions logicielles de base dans chaque programme.

De même: le même argument s’applique également aux bases de données de graphes d’aujourd’hui, car elles fonctionnent selon des principes très similaires de bases de données relationnelles.

Les bases de données relationnelles ont connu un vif succès, constituant un élément essentiel de presque toutes les applications. Avec ce succès, un riche déluge de données a été introduit dans les systèmes de bases de données. Les bases de données relationnelles sont très utiles pour soutenir les relations symboliques définies par le développeur dans les données (par exemple, l'achat appartient à l'utilisateur), mais supportent peu les relations bruyantes, rares et probabilistes qui se produisent au sein même des données (par exemple, les utilisateurs avec un revenu disponible plus élevé ont tendance à faire plus d'achats).

Cette limitation est reflétée dans les langages de requête (SQL, par exemple) eux-mêmes. Ils sont réputés désagréables pour les utilisateurs professionnels non techniques, à tel point que des équipes entières d’analystes de données, d’experts en BI et de spécialistes des données sont invitées à aider les employés non techniques à accéder à leurs données. Ce n'est pas une surprise si une requête simple telle que «obtenez le deuxième salaire le plus élevé» se traduit par:

SELECT DISTINCT Salaire DE Employé e1 WHERE 2 = Sélectionnez COUNT (Salaire DISTINCT) DE Employé e2 WHERE e1.salary <= e2.salary

Une nouvelle approche

Chez Octavian, nous travaillons sur une nouvelle génération de moteur de requête de base de données. Il aborde les limitations ci-dessus en adoptant une approche différente. À la base, il est très différent des moteurs de requête de base de données actuels:

  • Il accepte le langage naturel (anglais, par exemple) au lieu de SQL pour les requêtes.
  • Il représente les données sous forme de mélange de caractéristiques éparses plutôt que d'éléments de catégories fixes.
  • Il apprend des algorithmes profonds multi-étapes à partir d'exemples

Je vais expliquer chacun de ces aspects et en quoi ils sont bénéfiques.

Il accepte le langage naturel (anglais, par exemple) au lieu de SQL pour les requêtes.

Les interfaces en langage naturel ont récemment pris son envol sous la forme de haut-parleurs intelligents - Amazon rapporte plus de 20 millions d’échos vendus et 50% des consommateurs américains envisagent d’acheter un haut-parleur intelligent au cours de la prochaine année. L'utilisation du langage naturel rend les systèmes accessibles à un large éventail de personnes présentant de faibles obstacles à l'entrée.

Nous essayons d’apporter les mêmes avantages au monde des données d’entreprise.

Il représente les données sous forme de mélange de caractéristiques éparses plutôt que d'éléments de catégories fixes.

Dans le monde réel, rien ne rentre dans des boîtes soignées. Les mots ont beaucoup de significations. Les phrases peuvent être ambiguës. Les concepts et les pensées sont liés aux autres, de différentes manières nuancées. Les feuilles mortes, le tabac et le cuir semblent aller de pair, mais pourquoi exactement?

Notre représentation des données soutient et embrasse cette interdépendance profonde. Nous y parvenons en représentant les données sous forme de mélanges de caractéristiques éparses (c’est-à-dire de nombreux vecteurs dimensionnels). Ces représentations sont créées à l'aide d'implications et de fonctions de transformation apprises.

Cela permet au moteur de requête de mieux utiliser la nuance des mots de la requête pour trouver les données pertinentes. Il lui permet d'agréger et de filtrer des données en fonction de sous-catégories apprises, dont l'appartenance n'est pas binaire.

Il apprend des algorithmes profonds multi-étapes à partir d'exemples

De nombreuses fois dans la vie, nous pouvons spécifier les entrées et les sorties, mais il est difficile de trouver le moyen de les séparer (par exemple, essayez d’écrire une série de règles pour déterminer si une photo est un hot-dog). Le grand cadeau des techniques d’apprentissage automatique réside dans le fait qu’il est possible de régler la partie centrale dans les bonnes circonstances.

Les algorithmes classiques, ceux qui sont facilement implémentés dans les moteurs de requête de base de données traditionnels, sont très rigides. Chaque étape doit être une décision claire avec des entrées faciles à spécifier. Cela contraste avec un algorithme appris, où chaque étape de l’algorithme peut incorporer de nombreux signaux faibles pour déterminer la suite des opérations. En outre, il peut effectuer de nombreuses sous-étapes différentes en parallèle, ce qui constitue une solution beaucoup plus complexe que celle qu'un ingénieur pourrait écrire.

C'est comme comparer le nombre de personnes qui cuisinent dans la cuisine à un livre de recettes: nous mesurons les ingrédients à l'œil nu, choisissons les combinaisons d'ingrédients en fonction du toucher et nous les cuisinons jusqu'à ce que cela sent bon et bon. Nous improvisons. Rien de tout cela n’est capturé par les étapes et le temps de cuisson du livre de recettes.

Comment le construire

Un tel changement radical par rapport au fonctionnement des moteurs de requête actuels nécessite un changement similaire dans la technologie sous-jacente.

Nous utilisons un réseau de neurones comme cœur du moteur de requête. Nous présentons les informations de la base de données sous forme de tables de données et de matrices d'adjacence (par exemple un tableau de connexions) au réseau de neurones, et laissons le traitement des données et la requête pour produire un résultat.

Le réseau traite la requête via un RNN et l'incorporation de mots appris. Cela fournit à la fois un tableau de jetons de requête et un vecteur de requête global.

Les données sont ensuite traitées via un réseau rappelant l’architecture de Transformer. Après avoir d'abord appliqué les données acquises aux images intégrées, celles-ci sont ensuite transmises à une série de systèmes d'attention hiérarchique. Cela permet au réseau de tirer parti des sous-réseaux spécifiques à une tâche et de combiner des calculs antérieurs pour former des agrégats complexes.

Vous pouvez voir un exemple de travail de base dans cet article récent.

Alors qu'il y a trop de détails à couvrir dans cette vue d'ensemble de haut niveau, certains des sous-réseaux incluent (pour notre réseau de traitement de graphes):

  • Rappel de propriété de nœud
  • Rappel de Edge (c.-à-d. Relation)
  • Utilisation de la sortie de l'étape précédente comme instructions d'adressage pour ce qui précède
  • Message itératif passant
  • Rappelant les résultats de l’étape précédente et les transformant de différentes façons

Avoir hâte de

En résumé, nous pensons que cette architecture pourrait présenter l'évolution future des bases de données. Il est capable de répondre aux requêtes à la manière d’Alexia ou de Siri, pour de vrais utilisateurs professionnels non techniques. Il est capable d'effectuer le type d'opérations floues requises par les questions du monde réel.

Construire cette technologie nécessite de repenser radicalement les fondements des bases de données, d'innover et de résoudre des problèmes.

Si travailler sur quelque chose comme cela vous passionne, contactez-nous ou discutez avec nous.