Domina los datos categóricos de alta cardinalidad en la generación agéntica de SQL con VectorDBs
Los flujos de trabajo agénticos y los modelos de lenguaje grandes (LLMs) han cambiado fundamentalmente la forma en que abordamos los sistemas de texto a SQL y permiten a los usuarios consultar bases de datos usando lenguaje natural como nunca antes. A medida que estos sistemas evolucionan, encontramos diversos desafíos novedosos al traducir la intención humana en consultas SQL precisas.
Un problema significativo es manejar datos categóricos de alta cardinalidad. Este artículo explora cómo la integración de bases de datos vectoriales con sistemas agénticos de texto a SQL puede abordar este desafío. Específicamente, mostraremos cómo la combinación de Waii y Zilliz Cloud (la base de datos vectorial Milvus completamente gestionada) maneja automáticamente este problema.
El desafío de los datos categóricos de alta cardinalidad
Los datos categóricos son omnipresentes en las bases de datos: piense en categorías de productos, segmentos de clientes o tipos de transacciones. En muchos casos, el número de valores únicos (cardinalidad) en estas categorías es manejable. Por ejemplo, una columna para estados de EE. UU. tendrá como máximo 50 valores únicos (más territorios). Estas columnas de baja cardinalidad son relativamente fáciles de manejar para los sistemas de texto a SQL, ya que la brecha entre las consultas en lenguaje natural y los valores de la base de datos es pequeña.
El desafío surge cuando encontramos datos categóricos de alta cardinalidad. Más del 60% de las bases de datos con las que hemos trabajado tienen ejemplos de esta situación: imagine un catálogo de productos con millones de IDs de productos únicos o una base de datos financiera con cientos de miles de identificadores de empresas.
Las bases de datos requieren búsquedas precisas y rígidas para estas categorías, pero las consultas en lenguaje natural a menudo son fluidas e imprecisas. Un usuario podría pedir "smartphones populares" o "empresas tecnológicas a las que les fue bien recientemente", pero traducir estos términos vagos en valores específicos de la base de datos es donde los enfoques tradicionales de texto a SQL se quedan cortos, dejando una gran cantidad de datos fuera de alcance.
Por qué los métodos existentes no funcionan
A menudo, los sistemas de texto a SQL emplean uno de los siguientes dos métodos al traducir consultas en lenguaje natural que involucran datos categóricos de alta cardinalidad:
Técnicas de bases de datos preprocesadas: Este enfoque se basa en capacidades de bases de datos tradicionales, como la búsqueda de texto y las expresiones regulares, combinadas con el preprocesamiento de la entrada. Si bien puede manejar coincidencias simples, a menudo es demasiado inflexible para representar con precisión la intención del usuario, especialmente con consultas complejas o matizadas. La naturaleza rígida de estas técnicas tiene dificultades para cerrar la brecha entre la variabilidad del lenguaje natural y los valores precisos de la base de datos.
Traducción basada en LLM: En este método, el sistema usa un LLM para predecir los valores categóricos correctos basándose en datos de entrenamiento o ejemplos few-shot. Si bien los LLMs destacan en comprender el contexto y el lenguaje natural, a menudo producen resultados incorrectos cuando tratan con datos de alta cardinalidad. Esto se debe a que el LLM carece de conocimiento del conjunto de datos completo (y a menudo privado) y tiene dificultades para recordar con precisión millones de identificadores únicos que no formaban parte de sus datos de entrenamiento.
Para datos de alta cardinalidad, ambos métodos se quedan cortos. Las técnicas de bases de datos preprocesadas son demasiado inflexibles y literales para manejar eficazmente los matices de las consultas en lenguaje natural. Los LLMs, por otro lado, pueden entender la intención de la consulta, pero no pueden mapearla de manera fiable a los valores correctos en un conjunto de datos grande y específico en el que no han sido entrenados. Esto nos deja con una brecha significativa al traducir consultas en lenguaje natural a SQL preciso para datos categóricos de alta cardinalidad.
Entran las bases de datos vectoriales
Aquí es donde entran en juego las bases de datos vectoriales. La recuperación de información moderna utiliza incrustaciones vectoriales para realizar búsquedas semánticas en lugar de coincidencias de palabras clave. Las bases de datos vectoriales están diseñadas para almacenar y consultar de forma eficiente representaciones vectoriales de datos de alta dimensionalidad. En nuestro contexto, podemos aprovecharlas para conectar consultas en lenguaje natural y datos categóricos de alta cardinalidad.
Así es como funciona:
Crear incrustaciones vectoriales: Crea una incrustación vectorial para cada valor único en tu columna de alta cardinalidad. Esta incrustación captura el significado semántico del valor al mapearlo a un vector en un espacio de alta dimensionalidad.
Indexar en una VectorDB: Almacena estas incrustaciones en una base de datos vectorial como Milvus, que está optimizada para búsquedas de similitud rápidas en espacios de alta dimensionalidad.
Procesamiento de consultas: Cuando un usuario envía una consulta en lenguaje natural, usa un LLM para comprender la intención y generar una consulta SQL preliminar. Para columnas de alta cardinalidad, en lugar de intentar generar valores específicos, el LLM genera una descripción o características de los valores deseados.
Búsqueda vectorial: Usa la incrustación de esta descripción para realizar una búsqueda de similitud de la incrustación de una enorme cantidad de valores únicos en la base de datos vectorial, recuperando los valores categóricos más relevantes.
Refinamiento: Luego, el LLM puede refinar estos resultados, filtrando cualquier coincidencia irrelevante según el contexto completo de la consulta del usuario.
Generación de SQL: Genera la consulta SQL final usando la lista refinada de valores categóricos para construir los filtros y agregaciones adecuados.
Beneficios de usar búsqueda vectorial en Text-to-SQL
Este enfoque mejorado con vectorDB ofrece varias ventajas:
Escalabilidad: Puede manejar categorías con millones de valores únicos sin una degradación significativa del rendimiento.
Precisión: Al combinar la comprensión semántica de los LLM con la recuperación precisa de las bases de datos vectoriales, podemos traducir con mayor precisión la intención del usuario a valores específicos de la base de datos.
Flexibilidad: Este método puede adaptarse a cambios en la base de datos sin requerir el reentrenamiento de todo el sistema.
Consideraciones de implementación
Naturalmente, es posible crear desde cero los flujos necesarios para implementar el enfoque descrito, pero creemos que combinar Waii y Zilliz Cloud ofrece ventajas significativas.
Waii es la primera API de text-to-SQL del mundo construida sobre flujos de trabajo agénticos. Combina tecnología de compiladores con un grafo de conocimiento generado automáticamente para la generación de consultas más precisa.
Complementando las capacidades de Waii, Zilliz Cloud es la base de datos vectorial que sustenta los flujos de trabajo de IA. Su capacidad para escalar y entregar resultados precisos con baja latencia la convierte en la elección natural en la pila de IA.
La combinación te ofrece una solución escalable lista para usar:
Waii para Text-to-SQL inteligente
Detección automática: Waii identifica automáticamente estas columnas de alta cardinalidad, eliminando la necesidad de configuración manual.
Generación inteligente de incrustaciones: Emplea flujos de trabajo personalizados para crear y actualizar incrustaciones para diferentes tipos de columnas, optimizando tanto la precisión como la eficiencia de recursos.
Técnicas adaptativas: Waii selecciona automáticamente las técnicas adecuadas para varios tipos de columnas, garantizando un rendimiento óptimo sin requerir conocimientos profundos por parte del usuario.
Zilliz Cloud para búsqueda semántica vectorial
Escalabilidad: Zilliz Cloud puede manejar miles de millones de vectores con facilidad, lo que la hace ideal para escenarios de datos de alta cardinalidad.
Consultas ultrarrápidas: Su indexación optimizada garantiza búsquedas de similitud rápidas, fundamentales para mantener una baja latencia en entornos de producción.
Seguridad y control de acceso: Zilliz Cloud proporciona seguridad de datos de nivel empresarial y cumplimiento de privacidad mediante opciones de red seguras y protocolos de cifrado. Esto garantiza la seguridad de los datos tanto durante la transferencia como cuando están en reposo. Además, Zilliz Cloud ofrece un sofisticado control de identidad y gestión de acceso, incluido el control de acceso basado en roles (RBAC) y OAuth 2.0 para capacidades seguras y centralizadas de inicio de sesión único (SSO).
Integración de Waii y Zilliz Cloud
Flujo de trabajo fluido: La combinación del preprocesamiento automático de Waii y el potente almacenamiento vectorial de Zilliz crea una solución integral y fluida para manejar datos de alta cardinalidad en sistemas de texto a SQL.
Listo para producción: Esta combinación está diseñada para desafíos reales y a gran escala, lo que la hace adecuada para implementaciones en producción en diversas industrias.
Al aprovechar la detección automática y la generación de embeddings de Waii con Zilliz, puedes implementar una solución robusta para manejar datos categóricos de alta cardinalidad en tu sistema de texto a SQL sin código personalizado para la gestión de metadatos ni la generación de embeddings.
Un ejemplo práctico
Consideremos una plataforma global de gestión de eventos con millones de eventos. El esquema de la base de datos incluye:
CREATE TABLE events (
event_id INT PRIMARY KEY,
event_name VARCHAR(255),
event_date DATE,
category VARCHAR(100),
total_spent DECIMAL(10, 2)
);
El event_name es una columna categórica de alta cardinalidad, con millones de nombres únicos y descriptivos como "Cumbre Global de Ética de la IA 2024", "Expo de Vida Sostenible: Haciendo más verde nuestro futuro" o "5.ª Conferencia Anual sobre Avances en Computación Cuántica".
Un analista podría preguntar: "¿Cuánto dinero se gastó en eventos de IA el mes pasado?"
Así es como diferentes enfoques podrían manejar esto:
Coincidencia tradicional de palabras clave
En este enfoque usamos el término proporcionado por el usuario y lo incorporamos a la consulta como término de búsqueda. Aquí usamos búsqueda de texto completo sin distinción entre mayúsculas y minúsculas, pero generar filtros de igualdad también es común en este escenario.
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: Este enfoque pasa por alto eventos como "Simposio de aprendizaje automático" o "Taller de redes neuronales", que están relacionados con la IA pero no contienen "IA" en el nombre. También podría incluir incorrectamente eventos como "Convención de peinados HAIR".
Enfoque ingenuo con LLM
En este enfoque, el LLM genera múltiples términos que podrían ser relevantes para la búsqueda y construye un filtro a partir de ellos. Esto puede hacerse opcionalmente con valores de muestra de la columna y con contexto adicional sobre la base de datos. Normalmente produciría algo como:
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: Si bien esto captura más eventos relacionados con la IA, sigue estando limitado a una lista predefinida de términos y podría pasar por alto eventos con nombres relacionados con la IA más específicos o novedosos. El problema de encontrar eventos no relacionados también sigue existiendo.
Enfoque de base de datos vectorial + LLM
El siguiente diagrama muestra el flujo general. El lado izquierdo es el preprocesamiento que se realiza en la tabla de eventos, el lado derecho muestra el flujo de generación de la consulta.
Figura: Cómo funciona la integración de Zilliz Cloud y Waii
El flujo de generación de consultas es:
Waii interpreta la consulta y reescribe una descripción: "Eventos relacionados con inteligencia artificial, machine learning, redes neuronales y otras tecnologías de IA."
Esta descripción se utiliza para consultar Zilliz Cloud, devolviendo una lista de ID de eventos relevantes basados en la similitud semántica.
Waii refina esta lista, filtrando cualquier evento que no sea de IA y que pudiera haberse incluido inadvertidamente.
Waii utiliza un flujo de trabajo agéntico que incorpora estos ID de eventos en la consulta SQL final:
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);
Este enfoque puede identificar con precisión eventos relacionados con la IA, incluso si utilizan terminología especializada o no contienen palabras clave obvias. Puede capturar eventos como "3.er Simposio sobre redes generativas antagónicas" o "Taller sobre consideraciones éticas en el aprendizaje por refuerzo", que los otros enfoques podrían pasar por alto.
Al aprovechar la búsqueda por similitud vectorial, podemos interpretar con mayor precisión la intención del usuario y hacerla coincidir con los nombres de eventos de alta cardinalidad en nuestra base de datos, proporcionando resultados más completos y precisos.
Conclusión
A medida que los volúmenes de datos continúan creciendo y aumentan las expectativas de los usuarios respecto a interacciones de datos intuitivas, manejar datos categóricos de alta cardinalidad en sistemas de texto a SQL será cada vez más común. Al aprovechar el poder de Zilliz Cloud junto con Waii, podemos crear sistemas más robustos, escalables y precisos.
Hemos visto resultados prometedores con este enfoque, y creemos que es beneficioso para otras personas que enfrentan desafíos similares. No dudes en ponerte en contacto y contarnos si has probado este enfoque u otros similares, y en compartir tus perspectivas.
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.
Sigue leyendo
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.
How Zilliz Ended Up at the Center of NVIDIA’s Unstructured Data Story at GTC 2026
If unstructured data is the context of AI, then the ceiling of AI applications will be set not just by models, but by how mature the infrastructure for unstructured data becomes.
How Zilliz Saw the Future of Vector Databases—and Built for Production
An inside look at how Zilliz built vector databases for real-world use, focusing on scalability, stability, and running them reliably at scale.