Gestire i dati categoriali ad alta cardinalità nella generazione SQL agentica con VectorDBs
I workflow agentici e i large language model (LLM) hanno cambiato radicalmente il modo in cui affrontiamo i sistemi text-to-SQL e consentono agli utenti di interrogare i database usando il linguaggio naturale come mai prima d'ora. Man mano che questi sistemi evolvono, incontriamo varie nuove sfide nel tradurre l'intento umano in query SQL accurate.
Un problema significativo è la gestione dei dati categorici ad alta cardinalità. Questo articolo esplora come l'integrazione dei database vettoriali con sistemi text-to-SQL agentici possa affrontare questa sfida. In particolare, mostreremo come la combinazione di Waii e Zilliz Cloud (il database vettoriale Milvus completamente gestito) gestisca automaticamente questo problema.
La sfida dei dati categorici ad alta cardinalità
I dati categorici sono onnipresenti nei database: pensate a categorie di prodotti, segmenti di clienti o tipi di transazioni. In molti casi, il numero di valori univoci (cardinalità) in queste categorie è gestibile. Ad esempio, una colonna per gli stati degli Stati Uniti avrà al massimo 50 valori univoci (più i territori). Queste colonne a bassa cardinalità sono relativamente facili da gestire per i sistemi text-to-SQL, poiché il divario tra le query in linguaggio naturale e i valori del database è ridotto.
La sfida emerge quando incontriamo dati categorici ad alta cardinalità. Oltre il 60% dei database con cui abbiamo lavorato presenta esempi di questa situazione: immaginate un catalogo prodotti con milioni di ID prodotto univoci o un database finanziario con centinaia di migliaia di identificatori aziendali.
I database richiedono ricerche precise e rigide per queste categorie, ma le query in linguaggio naturale sono spesso fluide e imprecise. Un utente potrebbe chiedere "smartphone popolari" o "aziende tecnologiche che sono andate bene di recente", ma tradurre questi termini vaghi in valori specifici del database è il punto in cui gli approcci text-to-SQL tradizionali non sono all'altezza, lasciando fuori portata una grande quantità di dati.
Perché i metodi esistenti non funzionano
Spesso, i sistemi text-to-SQL impiegano uno dei due metodi seguenti quando traducono query in linguaggio naturale che coinvolgono dati categorici ad alta cardinalità:
Tecniche di database preelaborate: Questo approccio si basa su funzionalità dei database tradizionali come la ricerca testuale e le espressioni regolari, combinate con la preelaborazione dell'input. Sebbene possa gestire corrispondenze semplici, è spesso troppo inflessibile per rappresentare accuratamente l'intento dell'utente, specialmente con query complesse o sfumate. La natura rigida di queste tecniche fatica a colmare il divario tra la variabilità del linguaggio naturale e i valori precisi del database.
Traduzione basata su LLM: In questo metodo, il sistema utilizza un LLM per prevedere i valori categorici corretti sulla base dei dati di addestramento o di esempi few-shot. Sebbene gli LLM eccellano nella comprensione del contesto e del linguaggio naturale, spesso producono risultati errati quando hanno a che fare con dati ad alta cardinalità. Questo perché l'LLM non conosce il dataset completo (e spesso privato) e fatica a richiamare accuratamente milioni di identificatori univoci che non facevano parte dei suoi dati di addestramento.
Per i dati ad alta cardinalità, entrambi i metodi non sono all'altezza. Le tecniche di database preelaborate sono troppo inflessibili e letterali per gestire efficacemente le sfumature delle query in linguaggio naturale. Gli LLM, d'altra parte, possono comprendere l'intento della query ma non riescono a mapparlo in modo affidabile ai valori corretti in un dataset ampio e specifico su cui non sono stati addestrati. Questo ci lascia con un divario significativo nella traduzione di query in linguaggio naturale in SQL accurato per dati categorici ad alta cardinalità.
Entrano in gioco i database vettoriali
È qui che entrano in gioco i database vettoriali. Il moderno recupero delle informazioni utilizza embedding vettoriali per eseguire ricerche semantiche anziché corrispondenze di parole chiave. I database vettoriali sono progettati per archiviare e interrogare in modo efficiente rappresentazioni vettoriali ad alta dimensionalità dei dati. Nel nostro contesto, possiamo sfruttarli per collegare query in linguaggio naturale e dati categorici ad alta cardinalità.
Ecco come funziona:
Creare embedding vettoriali: Crea un embedding vettoriale per ciascun valore univoco nella tua colonna ad alta cardinalità. Questo embedding cattura il significato semantico del valore mappandolo a un vettore in uno spazio ad alta dimensionalità.
Indicizzare in un VectorDB: Archivia questi embedding in un database vettoriale come Milvus, ottimizzato per ricerche di similarità rapide in spazi ad alta dimensionalità.
Elaborazione della query: Quando un utente invia una query in linguaggio naturale, usa un LLM per comprendere l’intento e generare una query SQL preliminare. Per le colonne ad alta cardinalità, invece di cercare di generare valori specifici, l’LLM genera una descrizione o caratteristiche dei valori desiderati.
Ricerca vettoriale: Usa l’embedding di questa descrizione per eseguire una ricerca di similarità dell’embedding di un’enorme quantità di valori univoci nel database vettoriale, recuperando i valori categorici più rilevanti.
Affinamento: L’LLM può quindi affinare questi risultati, filtrando eventuali corrispondenze irrilevanti in base al contesto completo della query dell’utente.
Generazione SQL: Genera la query SQL finale utilizzando l’elenco affinato di valori categorici per costruire i filtri e le aggregazioni appropriati.
Vantaggi dell’uso della ricerca vettoriale nel Text-to-SQL
Questo approccio potenziato da vectorDB offre diversi vantaggi:
Scalabilità: Può gestire categorie con milioni di valori univoci senza un significativo degrado delle prestazioni.
Accuratezza: Combinando la comprensione semantica degli LLM con il richiamo preciso dei database vettoriali, possiamo tradurre più accuratamente l’intento dell’utente in valori specifici del database.
Flessibilità: Questo metodo può adattarsi ai cambiamenti nel database senza richiedere il riaddestramento dell’intero sistema.
Considerazioni sull’implementazione
È naturalmente possibile costruire da zero i flussi necessari per implementare l’approccio descritto, ma riteniamo che combinare Waii e Zilliz Cloud offra vantaggi significativi.
Waii è la prima API text-to-SQL al mondo basata su workflow agentici. Combina la tecnologia dei compilatori con un knowledge graph generato automaticamente per la generazione di query più accurata.
A complemento delle capacità di Waii, Zilliz Cloud è il database vettoriale alla base dei workflow di IA. La sua capacità di scalare e fornire risultati accurati con bassa latenza lo rende la scelta naturale nello stack di IA.
La combinazione ti offre una soluzione scalabile pronta all’uso:
Waii per un Text-to-SQL intelligente
Rilevamento automatico: Waii identifica automaticamente queste colonne ad alta cardinalità, eliminando la necessità di configurazione manuale.
Generazione intelligente di embedding: Impiega workflow su misura per creare e aggiornare embedding per diversi tipi di colonne, ottimizzando sia l’accuratezza sia l’efficienza delle risorse.
Tecniche adattive: Waii seleziona automaticamente tecniche appropriate per vari tipi di colonne, garantendo prestazioni ottimali senza richiedere una profonda competenza da parte dell’utente.
Zilliz Cloud per la ricerca semantica vettoriale
Scalabilità: Zilliz Cloud può gestire miliardi di vettori con facilità, rendendolo ideale per scenari di dati ad alta cardinalità.
Query fulminee: La sua indicizzazione ottimizzata garantisce ricerche di similarità rapide, fondamentali per mantenere una bassa latenza negli ambienti di produzione.
Sicurezza e controllo degli accessi: Zilliz Cloud fornisce sicurezza dei dati di livello enterprise e conformità alla privacy tramite opzioni di networking sicuro e protocolli di crittografia. Ciò garantisce la sicurezza dei dati sia durante il trasferimento sia quando sono a riposo. Inoltre, Zilliz Cloud offre sofisticati controlli dell’identità e gestione degli accessi, tra cui il controllo degli accessi basato sui ruoli (RBAC) e OAuth 2.0 per funzionalità di Single Sign-On (SSO) sicure e centralizzate.
Integrazione di Waii e Zilliz Cloud
Flusso di lavoro senza interruzioni: La combinazione della pre-elaborazione automatica di Waii e del potente storage vettoriale di Zilliz crea una soluzione fluida end-to-end per gestire dati ad alta cardinalità nei sistemi text-to-SQL.
Pronto per la produzione: Questa integrazione è progettata per sfide reali e su larga scala, rendendola adatta a distribuzioni in produzione in diversi settori.
Sfruttando il rilevamento automatico e la generazione di embedding di Waii con Zilliz, puoi implementare una soluzione robusta per gestire dati categorici ad alta cardinalità nel tuo sistema text-to-SQL senza codice personalizzato per la gestione dei metadati o la generazione di embedding.
Un esempio pratico
Consideriamo una piattaforma globale di gestione eventi con milioni di eventi. Lo schema del database include:
CREATE TABLE events (
event_id INT PRIMARY KEY,
event_name VARCHAR(255),
event_date DATE,
category VARCHAR(100),
total_spent DECIMAL(10, 2)
);
event_name è una colonna categorica ad alta cardinalità, con milioni di nomi unici e descrittivi come "Global AI Ethics Summit 2024", "Sustainable Living Expo: Greening Our Future" o "5th Annual Quantum Computing Breakthrough Conference".
Un analista potrebbe chiedere: "Quanto denaro è stato speso per eventi sull’AI il mese scorso?"
Ecco come diversi approcci potrebbero gestire questa richiesta:
Corrispondenza tradizionale per parole chiave
In questo approccio utilizziamo il termine fornito dall’utente e lo inseriamo nella query come termine di ricerca. Qui utilizziamo una ricerca full text senza distinzione tra maiuscole e minuscole, ma in questo scenario è comune anche generare filtri di uguaglianza.
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);
Problema: Questo approccio non intercetta eventi come "Machine Learning Symposium" o "Neural Network Workshop", che sono correlati all’AI ma non contengono "AI" nel nome. Potrebbe anche includere erroneamente eventi come "HAIR styling convention".
Approccio LLM ingenuo
In questo approccio, l’LLM genera più termini che potrebbero essere rilevanti per la ricerca e costruisce un filtro a partire da essi. Questo può essere facoltativamente fatto con valori di esempio dalla colonna e con contesto aggiuntivo sul database. In genere produrrebbe qualcosa del tipo:
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);
Problema: Sebbene questo approccio intercetti più eventi correlati all’AI, è comunque limitato a un elenco predefinito di termini e potrebbe non rilevare eventi con nomi più specifici o nuovi correlati all’AI. Anche il problema di trovare eventi non correlati continua a esistere.
Approccio Vector DB + LLM
Il diagramma seguente illustra il flusso complessivo. Il lato sinistro rappresenta la pre-elaborazione eseguita sulla tabella degli eventi, mentre il lato destro mostra il flusso di generazione della query.
Figura- Come funziona l'integrazione di Zilliz Cloud e Waii
Il flusso di generazione della query è:
Waii interpreta la query e riscrive una descrizione: "Eventi relativi all'intelligenza artificiale, al machine learning, alle reti neurali e ad altre tecnologie di IA."
Questa descrizione viene utilizzata per interrogare Zilliz Cloud, restituendo un elenco di ID evento rilevanti basati sulla similarità semantica.
Waii perfeziona questo elenco, filtrando eventuali eventi non legati all'IA che potrebbero essere stati inclusi inavvertitamente.
Waii utilizza un workflow agentico che incorpora questi ID evento nella query 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);
Questo approccio può identificare accuratamente gli eventi correlati all'IA, anche se utilizzano una terminologia specialistica o non contengono parole chiave evidenti. Può catturare eventi come "3° Simposio sulle Generative Adversarial Networks" o "Workshop sulle considerazioni etiche nel Reinforcement Learning", che gli altri approcci potrebbero non rilevare.
Sfruttando la ricerca per similarità vettoriale, possiamo interpretare più accuratamente l'intento dell'utente e abbinarlo ai nomi degli eventi ad alta cardinalità nel nostro database, fornendo risultati più completi e accurati.
Conclusione
Poiché i volumi di dati continuano a crescere e le aspettative degli utenti per interazioni intuitive con i dati aumentano, la gestione dei dati categoriali ad alta cardinalità nei sistemi text-to-SQL diventerà sempre più comune. Sfruttando la potenza di Zilliz Cloud insieme a Waii, possiamo creare sistemi più robusti, scalabili e accurati.
Abbiamo riscontrato risultati promettenti con questo approccio e riteniamo che sia utile per altri che affrontano sfide simili. Non esitate a contattarci e a farci sapere se avete provato questo approccio o approcci simili e a condividere le vostre intuizioni.
Jiang ChenJiang is currently Director of Technical GTM at Zilliz. He has years of experience in data infrastructures and cloud security. Before joining Zilliz, he had previously served as a tech lead and product manager at Google, where he led the development of web-scale semantic understanding and search indexing that powers innovative search products such as short video search. He has extensive industry experience handling massive unstructured data and multimedia content retrieval. He has also worked on cloud authorization systems and research on data privacy technologies. Jiang holds a Master's degree in Computer Science from the University of Michigan.
Gunther HagleitnerGunther Hagleitner is the current CEO and co-founder of Waii. He is a seasoned product and engineering leader with a 20+ year track record in SQL and analytics. Previously, as SVP at Cribl and CVP at Cloudera, he focused on simplifying data through innovation and open-source. Gunther excels at both scaling products and teams as well as new product introductions. He is passionate about creating user-centric solutions that solve real-world problems.
Continua a leggere
Zilliz Cloud Now Available in AWS Asia Pacific (Seoul)
Zilliz Cloud is now available in AWS Seoul — low-latency vector search, in-country data residency, and one-step migration for Korean AI teams. 31 regions across 5 clouds.
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.
Vector Databases vs. Graph Databases
Use a vector database for AI-powered similarity search; use a graph database for complex relationship-based queries and network analysis.