Blog
Maîtriser les données catégorielles à forte cardinalité dans la génération SQL agentique avec des bases de données vectorielles

Maîtriser les données catégorielles à forte cardinalité dans la génération SQL agentique avec des bases de données vectorielles

Sep 17, 20248 min read

Les workflows agentiques et les grands modèles de langage (LLMs) ont fondamentalement changé notre façon d’aborder les systèmes text-to-SQL et permettent aux utilisateurs d’interroger des bases de données en langage naturel comme jamais auparavant. À mesure que ces systèmes évoluent, nous rencontrons divers nouveaux défis pour traduire l’intention humaine en requêtes SQL précises.

Un problème majeur est la gestion des données catégorielles à haute cardinalité. Cet article explore comment l’intégration de bases de données vectorielles avec des systèmes text-to-SQL agentiques peut relever ce défi. Plus précisément, nous montrerons comment la combinaison de Waii et de Zilliz Cloud (la base de données vectorielle Milvus entièrement gérée) gère automatiquement ce problème.

Le défi des données catégorielles à haute cardinalité

Les données catégorielles sont omniprésentes dans les bases de données - pensez aux catégories de produits, aux segments de clientèle ou aux types de transactions. Dans de nombreux cas, le nombre de valeurs uniques (cardinalité) dans ces catégories est gérable. Par exemple, une colonne pour les États américains comptera au maximum 50 valeurs uniques (plus les territoires). Ces colonnes à faible cardinalité sont relativement faciles à gérer pour les systèmes text-to-SQL, car l’écart entre les requêtes en langage naturel et les valeurs de la base de données est faible.

Le défi apparaît lorsque nous rencontrons des données catégorielles à haute cardinalité. Plus de 60 % des bases de données avec lesquelles nous avons travaillé présentent des exemples de cette situation : imaginez un catalogue de produits avec des millions d’identifiants de produits uniques ou une base de données financière avec des centaines de milliers d’identifiants d’entreprises.

Les bases de données nécessitent des recherches précises et rigides pour ces catégories, mais les requêtes en langage naturel sont souvent fluides et imprécises. Un utilisateur pourrait demander des « smartphones populaires » ou des « entreprises technologiques qui ont récemment bien performé », mais traduire ces termes vagues en valeurs spécifiques de base de données est là où les approches text-to-SQL traditionnelles montrent leurs limites, laissant une richesse de données hors de portée.

Pourquoi les méthodes existantes ne fonctionnent pas

Souvent, les systèmes text-to-SQL emploient l’une des deux méthodes suivantes lorsqu’ils traduisent des requêtes en langage naturel impliquant des données catégorielles à haute cardinalité :

Techniques de base de données prétraitées : Cette approche repose sur des capacités de base de données traditionnelle comme la recherche textuelle et les expressions régulières, combinées à un prétraitement des entrées. Bien qu’elle puisse gérer des correspondances simples, elle est souvent trop inflexible pour représenter avec précision l’intention de l’utilisateur, en particulier avec des requêtes complexes ou nuancées. La nature rigide de ces techniques peine à combler l’écart entre la variabilité du langage naturel et les valeurs précises de la base de données.
Traduction basée sur les LLM : Dans cette méthode, le système utilise un LLM pour prédire les valeurs catégorielles correctes à partir de données d’entraînement ou d’exemples few-shot. Bien que les LLM excellent dans la compréhension du contexte et du langage naturel, ils produisent souvent des résultats incorrects lorsqu’ils traitent des données à haute cardinalité. Cela s’explique par le fait que le LLM n’a pas connaissance de l’ensemble complet (et souvent privé) des données et peine à se souvenir avec précision de millions d’identifiants uniques qui ne faisaient pas partie de ses données d’entraînement.

Pour les données à haute cardinalité, les deux méthodes sont insuffisantes. Les techniques de base de données prétraitées sont trop inflexibles et littérales pour gérer efficacement les nuances des requêtes en langage naturel. Les LLM, quant à eux, peuvent comprendre l’intention de la requête, mais ne peuvent pas la mapper de manière fiable aux valeurs correctes dans un vaste jeu de données spécifique sur lequel ils n’ont pas été entraînés. Cela nous laisse avec un écart important dans la traduction des requêtes en langage naturel en SQL précis pour les données catégorielles à haute cardinalité.

Voici les bases de données vectorielles

C’est là que les bases de données vectorielles entrent en jeu. La recherche d’information moderne utilise les vector embeddings pour effectuer des recherches sémantiques plutôt que des correspondances de mots-clés. les bases de données vectorielles sont conçues pour stocker et interroger efficacement des représentations vectorielles de données à haute dimension. Dans notre contexte, nous pouvons les exploiter pour faire le lien entre les requêtes en langage naturel et les données catégorielles à haute cardinalité.

Voici comment cela fonctionne :

Créer des vector embeddings : Créez un vector embedding pour chaque valeur unique de votre colonne à haute cardinalité. Cet embedding capture le sens sémantique de la valeur en la mappant à un vecteur dans un espace à haute dimension.
Indexer dans une VectorDB : Stockez ces embeddings dans une base de données vectorielle comme Milvus, qui est optimisée pour les recherches de similarité rapides dans des espaces à haute dimension.
Traitement des requêtes : Lorsqu’un utilisateur soumet une requête en langage naturel, utilisez un LLM pour comprendre l’intention et générer une requête SQL préliminaire. Pour les colonnes à haute cardinalité, au lieu d’essayer de générer des valeurs spécifiques, le LLM génère une description ou des caractéristiques des valeurs souhaitées.
Recherche vectorielle : Utilisez l’embedding de cette description pour effectuer une recherche de similarité sur l’embedding d’une quantité massive de valeurs uniques dans la base de données vectorielle, afin de récupérer les valeurs catégorielles les plus pertinentes.
Affinement : Le LLM peut ensuite affiner ces résultats, en filtrant toute correspondance non pertinente en fonction du contexte complet de la requête de l’utilisateur.
Génération SQL : Générez la requête SQL finale en utilisant la liste affinée de valeurs catégorielles pour construire les filtres et agrégations appropriés.

Avantages de l’utilisation de la recherche vectorielle dans le Text-to-SQL

Cette approche améliorée par vectorDB offre plusieurs avantages :

Scalabilité : Elle peut gérer des catégories avec des millions de valeurs uniques sans dégradation significative des performances.
Précision : En combinant la compréhension sémantique des LLMs avec le rappel précis des bases de données vectorielles, nous pouvons traduire plus précisément l’intention de l’utilisateur en valeurs spécifiques de la base de données.
Flexibilité : Cette méthode peut s’adapter aux changements dans la base de données sans nécessiter de réentraînement de l’ensemble du système.

Considérations de mise en œuvre

Il est naturellement possible de construire à partir de zéro les flux nécessaires à la mise en œuvre de l’approche décrite, mais nous pensons que la combinaison de Waii et Zilliz Cloud offre des avantages significatifs.

Waii est la première API text-to-SQL au monde construite sur des workflows agentiques. Elle combine la technologie des compilateurs avec un knowledge graph généré automatiquement pour produire les requêtes les plus précises.

En complément des capacités de Waii, Zilliz Cloud est la base de données vectorielle qui sous-tend les workflows d’IA. Sa capacité à monter en charge et à fournir des résultats précis avec une faible latence en fait le choix naturel dans la stack IA.

La combinaison vous offre une solution scalable prête à l’emploi :

Waii pour un Text-to-SQL intelligent

Détection automatique : Waii identifie automatiquement ces colonnes à haute cardinalité, éliminant le besoin de configuration manuelle.
Génération intelligente d’embeddings : Elle utilise des workflows adaptés pour construire et mettre à jour des embeddings pour différents types de colonnes, en optimisant à la fois la précision et l’efficacité des ressources.
Techniques adaptatives : Waii sélectionne automatiquement les techniques appropriées pour différents types de colonnes, garantissant des performances optimales sans nécessiter une expertise approfondie de la part de l’utilisateur.

Zilliz Cloud pour la recherche sémantique vectorielle

Scalabilité : Zilliz Cloud peut gérer des milliards de vecteurs avec aisance, ce qui en fait une solution idéale pour les scénarios de données à haute cardinalité.
Requêtes ultra-rapides : Son indexation optimisée garantit des recherches de similarité rapides, essentielles pour maintenir une faible latence dans les environnements de production.
Sécurité et contrôle d’accès : Zilliz Cloud fournit une sécurité des données de niveau entreprise et une conformité en matière de confidentialité grâce à des options de mise en réseau sécurisé et à des protocoles de chiffrement. Cela garantit la sécurité des données pendant le transfert comme au repos. De plus, Zilliz Cloud offre un contrôle sophistiqué des identités et une gestion des accès, notamment le contrôle d’accès basé sur les rôles (RBAC) et OAuth 2.0 pour des capacités d’authentification unique (SSO) sécurisées et centralisées.

Intégration de Waii et Zilliz Cloud

Flux de travail fluide : La combinaison du prétraitement automatique de Waii et du puissant stockage vectoriel de Zilliz crée une solution fluide et de bout en bout pour gérer les données à haute cardinalité dans les systèmes text-to-SQL.
Prêt pour la production : Cette association est conçue pour relever des défis réels à grande échelle, ce qui la rend adaptée aux déploiements en production dans divers secteurs.

En exploitant la détection automatique et la génération d’embeddings de Waii avec Zilliz, vous pouvez mettre en œuvre une solution robuste pour gérer les données catégorielles à haute cardinalité dans votre système text-to-SQL sans code personnalisé pour la gestion des métadonnées ou la génération d’embeddings.

Un exemple pratique

Considérons une plateforme mondiale de gestion d’événements avec des millions d’événements. Le schéma de la base de données comprend :

CREATE TABLE events (
    event_id INT PRIMARY KEY,
    event_name VARCHAR(255),
    event_date DATE,
    category VARCHAR(100),
    total_spent DECIMAL(10, 2)
);

Le event_name est une colonne catégorielle à haute cardinalité, avec des millions de noms uniques et descriptifs comme "Global AI Ethics Summit 2024", "Sustainable Living Expo: Greening Our Future" ou "5th Annual Quantum Computing Breakthrough Conference".

Un analyste pourrait demander : "Combien d’argent a été dépensé pour des événements liés à l’IA le mois dernier ?"

Voici comment différentes approches pourraient traiter cela :

Correspondance traditionnelle par mots-clés

Dans cette approche, nous utilisons le terme fourni par l’utilisateur et l’intégrons dans la requête comme terme de recherche. Nous utilisons ici une recherche plein texte insensible à la casse, mais la génération de filtres d’égalité est également courante dans ce scénario.

SELECT SUM(total_spent) 
FROM events 
WHERE event_name ILIKE '%AI%' 
  AND event_date >= 
 DATE_TRUNC('month', CURRENT_DATE - INTERVAL '1 month')
  AND event_date < 
 DATE_TRUNC('month', CURRENT_DATE);

Problème : Cette approche manque des événements comme "Machine Learning Symposium" ou "Neural Network Workshop", qui sont liés à l’IA mais ne contiennent pas "AI" dans leur nom. Elle pourrait également inclure à tort des événements comme "HAIR styling convention".

Approche LLM naïve

Dans cette approche, le LLM génère plusieurs termes qui pourraient être pertinents pour la recherche et construit un filtre à partir de ceux-ci. Cela peut éventuellement être fait avec des valeurs d’exemple de la colonne et avec un contexte supplémentaire sur la base de données. Cela produirait généralement quelque chose comme :

SELECT SUM(total_spent) 
FROM events 
WHERE (event_name ILIKE '%AI%' 
       OR event_name ILIKE '%Artificial Intelligence%' 
       OR event_name ILIKE '%Machine Learning%' 
       OR event_name ILIKE '%Neural Network%')
  AND event_date >= 
DATE_TRUNC('month', CURRENT_DATE - INTERVAL '1 month')
  AND event_date < 
DATE_TRUNC('month', CURRENT_DATE);

Problème : Bien que cela détecte davantage d’événements liés à l’IA, cela reste limité à une liste prédéfinie de termes et pourrait manquer des événements avec des noms liés à l’IA plus spécifiques ou nouveaux. Le problème de trouver des événements non liés existe également toujours.

Approche Vector DB + LLM

Le diagramme suivant illustre le flux global. Le côté gauche correspond au prétraitement effectué sur la table des événements, le côté droit montre le flux de génération de la requête.

Figure- Fonctionnement de l’intégration de Zilliz Cloud et Waii

Le flux de génération de requêtes est le suivant :

Waii interprète la requête et reformule une description : « Événements liés à l’intelligence artificielle, à l’apprentissage automatique, aux réseaux neuronaux et à d’autres technologies d’IA. »
Cette description est utilisée pour interroger Zilliz Cloud, qui renvoie une liste d’ID d’événements pertinents en fonction de la similarité sémantique.
Waii affine cette liste, en filtrant tous les événements non liés à l’IA qui auraient pu être inclus par inadvertance.
Waii utilise un workflow agentique qui intègre ces ID d’événements dans la requête SQL finale :

SELECT SUM(total_spent) 
FROM events 
WHERE event_id IN (1234, 5678, 9101, 1121, 3141, 5161, 7181, 9202, 1222, 3242) 
AND event_date >= 
DATE_TRUNC('month', CURRENT_DATE - INTERVAL '1 month') 
AND event_date < 
DATE_TRUNC('month', CURRENT_DATE);

Cette approche permet d’identifier avec précision les événements liés à l’IA, même s’ils utilisent une terminologie spécialisée ou ne contiennent pas de mots-clés évidents. Elle peut capturer des événements tels que « 3rd Symposium on Generative Adversarial Networks » ou « Workshop on Ethical Considerations in Reinforcement Learning », que les autres approches pourraient manquer.

En tirant parti de la recherche par similarité vectorielle, nous pouvons interpréter plus précisément l’intention de l’utilisateur et la faire correspondre aux noms d’événements à forte cardinalité dans notre base de données, fournissant ainsi des résultats plus complets et plus exacts.

Conclusion

À mesure que les volumes de données continuent de croître et que les attentes des utilisateurs en matière d’interactions intuitives avec les données augmentent, la gestion des données catégorielles à forte cardinalité dans les systèmes text-to-SQL deviendra de plus en plus courante. En exploitant la puissance de Zilliz Cloud conjointement avec Waii, nous pouvons créer des systèmes plus robustes, évolutifs et précis.

Nous avons observé des résultats prometteurs avec cette approche, et nous pensons qu’elle est bénéfique pour d’autres personnes confrontées à des défis similaires. N’hésitez pas à nous contacter pour nous faire savoir si vous avez essayé cette approche ou des approches similaires, et à partager vos observations.

Mis à jour le Jul 13, 2026

Continuer à lire

Zilliz Cloud BYOC Now Available Across AWS, GCP, and Azure

Zilliz Cloud BYOC is now generally available on all three major clouds. Deploy fully managed vector search in your own AWS, GCP, or Azure account — your data never leaves your VPC.

Zilliz Cloud Introduces Advanced BYOC-I Solution for Ultimate Enterprise Data Sovereignty

Explore Zilliz Cloud BYOC-I, the solution that balances AI innovation with data control, enabling secure deployments in finance, healthcare, and education sectors.

Legal Document Analysis: Harnessing Zilliz Cloud's Semantic Search and RAG for Legal Insights

Enhance legal document analysis with Zilliz Cloud’s Semantic Search and RAG. Improve accuracy, efficiency, and scalability for contracts, case law, and compliance.