Présentation des ensembles de contextes

Un ensemble de contextes correspond aux connaissances du domaine qui alimentent QueryData. Il définit le fonctionnement de votre logique métier avant la mise en ligne de votre application, afin que QueryData puisse répondre aux questions en langage naturel avec une précision de près de 100 % et une faible latence en ligne.

Bien que le contexte de domaine puisse prendre de nombreuses formes, les ensembles de contextes acceptent trois types de contextes spécialisés :

  • Modèles de requêtes : requêtes SQL préapprouvées pour les questions courantes de l'entreprise.
  • Facettes de requête : filtres modulaires, tels que "maison pour jeune famille" ou "vue sur l'océan", qui s'associent de manière dynamique aux modèles.
  • Recherches de valeurs : recherches d'entités qui mappent les expressions des utilisateurs avec des valeurs de base de données exactes et résolvent les ambiguïtés.

Les bases de données suivantes sont compatibles :

  • AlloyDB pour PostgreSQL
  • Cloud SQL pour MySQL
  • Cloud SQL pour PostgreSQL
  • Spanner
  • Firestore compatible avec MongoDB
  • Bigtable

Que sont les ensembles de contextes ?

Vous créez et optimisez des ensembles de contextes au moment de la conception à l'aide de l'agent d'ingénierie contextuelle. L'agent d'ingénierie de contexte exécute un benchmark de référence représentatif via QueryData, évalue les résultats et affine de manière itérative (hill-climbing) votre ensemble de contexte. Il vérifie ensuite la version finale par rapport à un ensemble de test d'exclusion non visible pour éviter le surapprentissage, puis importe automatiquement l'ensemble de contexte dansGoogle Cloud.

Associer votre base de données à un ensemble de contexte sélectionné offre deux avantages principaux en production :

  • Précision de près de 100 % qui se généralise : les schémas de base de données décrivent les tables et les colonnes, mais ils ne peuvent pas indiquer à un modèle quelle distance est considérée comme "proche " ou quelle note fait d'une école une "bonne" école. Les ensembles de contexte ancrent QueryData dans les règles métier validées de votre organisation, tandis que les modèles paramétrés permettent à un ensemble de contexte compact de généraliser les variations de formulation, les combinaisons de filtres et les valeurs d'entité.
  • Exécution en ligne rapide et faible latence : l'ingénierie de contexte déplace le raisonnement de schéma coûteux hors connexion vers le moment de la conception :
    • Exécution adaptée au contexte avec un ensemble de contextes : exécution rapide en un seul passage grâce à la correspondance de modèles précompilés et à la recherche de valeurs indexées.
    • Synthèse zero-shot pour les requêtes imprévues sans modèles : prend deux à trois fois plus de temps, car le modèle doit explorer les métadonnées du schéma et synthétiser le code SQL au moment de l'exécution.
    • Exploration agentique ouverte à l'aide d'outils SQL bruts : prend souvent plus de 30 secondes en raison des requêtes d'essai et d'erreur multitours et des boucles de correction d'erreur.

Types de contexte dans un ensemble de contextes

Au moment de l'exécution, QueryData combine les trois types de contexte en une seule passe. Par exemple, si un utilisateur demande :

"Trouve-moi des maisons près de bonnes écoles à Del Mar pour une jeune famille, avec vue sur l'océan"

QueryData résout la requête en quatre étapes coordonnées :

  1. Un modèle de requête fournit la structure de requête de base pour "maisons près de bonnes écoles à $1", en appliquant des règles métier pour la distance (dans un rayon de 3 km) et le classement des écoles (5 ou plus).
  2. Les facettes de requête injectent des filtres modulaires pour "starter family" (3 à 4 chambres, 2 salles de bain ou plus) et "ocean view" (recherche de similarité vectorielle).
  3. Une recherche de valeur trouve 'Del Mar' dans la colonne cities.city_name et vérifie son type de concept.
  4. Les explications d'intentions sont combinées en une seule explication certifiée renvoyée avec les résultats de la requête : "Maisons à Del Mar à moins de 3 km d'écoles classées 5 ou plus, avec 3 à 4 chambres et vue sur l'océan".

Modèles de requêtes

Les modèles de requêtes sont un ensemble de questions représentatives en langage naturel avec les requêtes SQL correspondantes. Ils incluent également des explications pour fournir une justification certifiée de la manière dont une question a été interprétée.

Par exemple, si un utilisateur demande à une application immobilière "Trouve-moi des maisons près de bonnes écoles à Del Mar", le schéma de base de données ne définit pas à lui seul la distance qui correspond à "près ", la note qui fait qu'une école est "bonne" ou la façon de classer les propriétés correspondantes. Un modèle de requête capture cette interprétation métier exacte, telle que les propriétés situées à moins de 3,2 km d'une école classée 5 ou mieux, classées par un score pondéré de classement et de proximité, et la généralise à n'importe quelle ville.

Les principaux composants d'un modèle de requête sont les suivants :

  • Exemple de question en langage naturel : question représentative posée en anglais simple, par exemple "Trouve-moi des maisons près de bonnes écoles à Del Mar".
  • Exemple de requête SQL : requête SQL validée qui répond à la question conformément à vos règles métier.
  • Modèle de question généralisé : modèle généré automatiquement dans lequel des valeurs spécifiques sont remplacées par des descriptions génériques, telles que "Trouver des maisons près de bonnes écoles dans une ville donnée", utilisé pour faire correspondre les questions entrantes à des variantes de formulation.
  • Explication de l'intention : explication certifiée en langage clair des règles métier appliquées par la requête, par exemple "Trouver des maisons à $1 à moins de 3 km d'une école classée au moins au rang 5".
  • Requête SQL paramétrée : requête SQL exécutable correspondant à l'explication de l'intention, à l'aide de paramètres tels que $1.

Attributs de requête

Les facettes de requête sont un ensemble de conditions représentatives en langage naturel avec des prédicats SQL correspondants. Les facettes gèrent le filtrage et les conditions, ce qui permet aux modèles de requête d'effectuer des recherches par facettes sans nécessiter de modèle distinct pour chaque combinaison de filtres.

Par exemple, un utilisateur peut étendre la requête "Trouve-moi des maisons près de bonnes écoles à Del Mar" avec des conditions supplémentaires :

  • "...pour une famille qui s'agrandit", qui correspond à un filtre SQL structuré tel que properties.bedrooms BETWEEN 3 AND 4 AND properties.bathrooms >= 2.0.
  • "...with an ocean view" (avec vue sur l'océan), qui utilise des opérateurs d'IA de base de données tels que ai.if ou la recherche de similarité vectorielle (<=>) sur des colonnes non structurées telles que listing_description, listing_image_embeddings et customer_reviews.

Les principaux composants d'un attribut de requête sont les suivants :

  • Extrait SQL : condition de filtre SQL réutilisable, telle que properties.bedrooms BETWEEN 3 AND 4 AND properties.bathrooms >= 2.0.
  • Modèle de condition généralisé : modèle en langage naturel auquel la facette correspond, par exemple "Convient à une famille débutante".
  • Explication de l'intention : explication certifiée de la condition de filtre, renvoyée dans le cadre de la justification globale de la réponse.
  • Extrait SQL paramétré : fragment SQL exécutable correspondant à l'explication de l'intention.

Requêtes de recherche de valeur

Les requêtes de recherche de valeurs sont des requêtes définies par le développeur qui utilisent des fonctions de correspondance, telles que la correspondance exacte, la similarité de trigramme approximative ou la recherche vectorielle sémantique, pour trouver des valeurs et leur contexte dans une base de données. QueryData utilise l'association de valeurs sur ces résultats pour identifier les tables et les colonnes contenant une valeur correspondante, comprendre le type de concept de la valeur, corriger les fautes d'orthographe et détecter les ambiguïtés avant d'exécuter SQL.

Par exemple, si un utilisateur demande à une application immobilière "les propriétés vendues à Westwod au cours du mois dernier", un modèle basé uniquement sur le schéma peut filtrer par `WHERE name = 'Westwod'` et ne renvoyer aucun résultat. Les requêtes de recherche de valeur utilisent la correspondance approximative pour résoudre la faute d'orthographe "Westwod" en valeur de base de données 'Westwood'. De plus, si 'Westwood' existe dans plusieurs types de concepts de la base de données, tels que City, Municipality et Brokerage, l'association de valeurs détecte l'ambiguïté afin que QueryData puisse demander à l'utilisateur de clarifier le concept qu'il voulait dire plutôt que de deviner.

Les principaux composants d'une requête de recherche de valeur sont les suivants :