Blog
Controle dados categóricos de alta cardinalidade na geração agêntica de SQL com VectorDBs

Controle dados categóricos de alta cardinalidade na geração agêntica de SQL com VectorDBs

Sep 17, 20248 min read

Fluxos de trabalho agênticos e grandes modelos de linguagem (LLMs) mudaram fundamentalmente a forma como abordamos sistemas de texto-para-SQL e permitem que os usuários consultem bancos de dados usando linguagem natural como nunca antes. À medida que esses sistemas evoluem, encontramos diversos desafios novos na tradução da intenção humana em consultas SQL precisas.

Um problema significativo é lidar com dados categóricos de alta cardinalidade. Este artigo explora como a integração de bancos de dados vetoriais com sistemas agênticos de texto-para-SQL pode enfrentar esse desafio. Especificamente, mostraremos como a combinação de Waii e Zilliz Cloud (o banco de dados vetorial Milvus totalmente gerenciado) lida automaticamente com essa questão.

O Desafio dos Dados Categóricos de Alta Cardinalidade

Dados categóricos são onipresentes em bancos de dados - pense em categorias de produtos, segmentos de clientes ou tipos de transações. Em muitos casos, o número de valores únicos (cardinalidade) nessas categorias é gerenciável. Por exemplo, uma coluna para estados dos EUA terá no máximo 50 valores únicos (mais territórios). Essas colunas de baixa cardinalidade são relativamente fáceis para sistemas de texto-para-SQL lidarem, pois a lacuna entre consultas em linguagem natural e valores do banco de dados é pequena.

O desafio surge quando encontramos dados categóricos de alta cardinalidade. Mais de 60% dos bancos de dados com os quais trabalhamos têm exemplos dessa situação: imagine um catálogo de produtos com milhões de IDs de produtos únicos ou um banco de dados financeiro com centenas de milhares de identificadores de empresas.

Bancos de dados exigem buscas precisas e rígidas para essas categorias, mas consultas em linguagem natural são frequentemente fluidas e imprecisas. Um usuário pode pedir por "smartphones populares" ou "empresas de tecnologia que se saíram bem recentemente", mas traduzir esses termos vagos em valores específicos do banco de dados é onde as abordagens tradicionais de texto-para-SQL ficam aquém, deixando uma grande quantidade de dados fora de alcance.

Por Que os Métodos Existentes Não Funcionam

Frequentemente, sistemas de texto-para-SQL empregam um dos dois métodos a seguir ao traduzir consultas em linguagem natural que envolvem dados categóricos de alta cardinalidade:

Técnicas de Banco de Dados Pré-processado: Esta abordagem depende de recursos de bancos de dados tradicionais, como busca de texto e expressões regulares, combinados com pré-processamento de entrada. Embora consiga lidar com correspondências simples, muitas vezes é inflexível demais para representar com precisão a intenção do usuário, especialmente em consultas complexas ou sutis. A natureza rígida dessas técnicas tem dificuldade para preencher a lacuna entre a variabilidade da linguagem natural e os valores precisos do banco de dados.
Tradução Baseada em LLM: Neste método, o sistema usa um LLM para prever os valores categóricos corretos com base em dados de treinamento ou exemplos few-shot. Embora LLMs se destaquem na compreensão de contexto e linguagem natural, eles frequentemente produzem resultados incorretos ao lidar com dados de alta cardinalidade. Isso ocorre porque o LLM não tem conhecimento do conjunto de dados completo (e muitas vezes privado) e tem dificuldade em recordar com precisão milhões de identificadores únicos que não fizeram parte de seus dados de treinamento.

Para dados de alta cardinalidade, ambos os métodos ficam aquém. As técnicas de banco de dados pré-processado são inflexíveis e literais demais para lidar efetivamente com as nuances das consultas em linguagem natural. Os LLMs, por outro lado, podem entender a intenção da consulta, mas não conseguem mapeá-la de forma confiável para os valores corretos em um conjunto de dados grande e específico no qual não foram treinados. Isso nos deixa com uma lacuna significativa na tradução de consultas em linguagem natural para SQL preciso para dados categóricos de alta cardinalidade.

Entram os Bancos de Dados Vetoriais

É aqui que bancos de dados vetoriais entram em cena. A recuperação de informações moderna usa embeddings vetoriais para realizar buscas semânticas em vez de correspondências por palavras-chave. bancos de dados vetoriais são projetados para armazenar e consultar com eficiência representações vetoriais de dados de alta dimensionalidade. Em nosso contexto, podemos aproveitá-los para conectar consultas em linguagem natural e dados categóricos de alta cardinalidade.

Veja como funciona:

Criar Embeddings Vetoriais: Crie um embedding vetorial para cada valor único em sua coluna de alta cardinalidade. Esse embedding captura o significado semântico do valor ao mapeá-lo para um vetor em um espaço de alta dimensionalidade.
Indexar em um VectorDB: Armazene esses embeddings em um banco de dados vetorial como o Milvus, que é otimizado para buscas por similaridade rápidas em espaços de alta dimensionalidade.
Processamento de Consultas: Quando um usuário envia uma consulta em linguagem natural, use um LLM para entender a intenção e gerar uma consulta SQL preliminar. Para colunas de alta cardinalidade, em vez de tentar gerar valores específicos, o LLM gera uma descrição ou características dos valores desejados.
Busca Vetorial: Use o embedding dessa descrição para realizar uma busca por similaridade pelo embedding de uma quantidade massiva de valores únicos no banco de dados vetorial, recuperando os valores categóricos mais relevantes.
Refinamento: O LLM pode então refinar esses resultados, filtrando quaisquer correspondências irrelevantes com base no contexto completo da consulta do usuário.
Geração de SQL: Gere a consulta SQL final usando a lista refinada de valores categóricos para criar os filtros e agregações apropriados.

Benefícios de Usar Busca Vetorial em Text-to-SQL

Essa abordagem aprimorada por vectorDB oferece várias vantagens:

Escalabilidade: Ela pode lidar com categorias com milhões de valores únicos sem degradação significativa de desempenho.
Precisão: Ao combinar a compreensão semântica dos LLMs com a recuperação precisa dos bancos de dados vetoriais, podemos traduzir com mais precisão a intenção do usuário em valores específicos do banco de dados.
Flexibilidade: Este método pode se adaptar a mudanças no banco de dados sem exigir retreinamento de todo o sistema.

Considerações de Implementação

É naturalmente possível criar do zero os fluxos necessários para implementar a abordagem descrita, mas acreditamos que combinar Waii e Zilliz Cloud oferece vantagens significativas.

Waii é a primeira API text-to-SQL do mundo construída sobre fluxos de trabalho agênticos. Ela combina tecnologia de compilador com um grafo de conhecimento gerado automaticamente para a geração de consultas mais precisa.

Complementando as capacidades da Waii, Zilliz Cloud é o banco de dados vetorial que sustenta fluxos de trabalho de IA. Sua capacidade de escalar e entregar resultados precisos com baixa latência o torna a escolha natural na pilha de IA.

A combinação oferece uma solução escalável pronta para uso:

Waii para Text-to-SQL Inteligente

Detecção Automática: Waii identifica automaticamente essas colunas de alta cardinalidade, eliminando a necessidade de configuração manual.
Geração Inteligente de Embeddings: Ela emprega fluxos de trabalho personalizados para criar e atualizar embeddings para diferentes tipos de colunas, otimizando tanto a precisão quanto a eficiência de recursos.
Técnicas Adaptativas: Waii seleciona automaticamente técnicas apropriadas para vários tipos de colunas, garantindo desempenho ideal sem exigir profundo conhecimento especializado do usuário.

Zilliz Cloud para Busca Semântica Vetorial

Escalabilidade: Zilliz Cloud pode lidar facilmente com bilhões de vetores, tornando-o ideal para cenários de dados de alta cardinalidade.
Consultas extremamente rápidas: Sua indexação otimizada garante buscas rápidas por similaridade, essenciais para manter baixa latência em ambientes de produção.
Segurança e controle de acesso: O Zilliz Cloud oferece segurança de dados de nível empresarial e conformidade com privacidade por meio de opções de rede segura e protocolos de criptografia. Isso garante a segurança dos dados tanto durante a transferência quanto em repouso. Além disso, o Zilliz Cloud oferece controle de identidade e gerenciamento de acesso sofisticados, incluindo Controle de Acesso Baseado em Função (RBAC) e OAuth 2.0 para recursos seguros e centralizados de Single Sign-On (SSO).

Integração do Waii e do Zilliz Cloud

Fluxo de trabalho contínuo: A combinação do pré-processamento automático do Waii e do poderoso armazenamento vetorial do Zilliz cria uma solução fluida e de ponta a ponta para lidar com dados de alta cardinalidade em sistemas de texto-para-SQL.
Pronto para produção: Essa combinação foi projetada para desafios reais e de grande escala, tornando-a adequada para implantações em produção em vários setores.

Ao aproveitar a detecção automática e a geração de embeddings do Waii com o Zilliz, você pode implementar uma solução robusta para lidar com dados categóricos de alta cardinalidade em seu sistema de texto-para-SQL sem código personalizado para gerenciamento de metadados ou geração de embeddings.

Um exemplo prático

Vamos considerar uma plataforma global de gerenciamento de eventos com milhões de eventos. O esquema do banco de dados inclui:

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

O event_name é uma coluna categórica de alta cardinalidade, com milhões de nomes únicos e descritivos como "Cúpula Global de Ética em IA 2024", "Expo de Vida Sustentável: Tornando Nosso Futuro Mais Verde" ou "5ª Conferência Anual de Avanços em Computação Quântica".

Um analista poderia perguntar: "Quanto dinheiro foi gasto em eventos de IA no mês passado?"

Veja como diferentes abordagens poderiam lidar com isso:

Correspondência tradicional de palavras-chave

Nesta abordagem, usamos o termo fornecido pelo usuário e o inserimos na consulta como termo de busca. Usamos aqui busca de texto completo sem diferenciação entre maiúsculas e minúsculas, mas gerar filtros de igualdade também é comum nesse cenário.

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: Essa abordagem não encontra eventos como "Simpósio de Machine Learning" ou "Workshop de Redes Neurais", que são relacionados à IA, mas não contêm "IA" no nome. Ela também pode incluir incorretamente eventos como "convenção de styling de HAIR".

Abordagem ingênua com LLM

Nesta abordagem, o LLM gera vários termos que podem ser relevantes para a busca e constrói um filtro a partir deles. Opcionalmente, isso pode ser feito com valores de amostra da coluna e com contexto adicional sobre o banco de dados. Normalmente, produziria 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: Embora isso capture mais eventos relacionados à IA, ainda é limitado a uma lista predefinida de termos e pode deixar de encontrar eventos com nomes mais específicos ou novos relacionados à IA. O problema de encontrar eventos não relacionados também ainda existe.

Abordagem com banco de dados vetorial + LLM

O diagrama a seguir mostra o fluxo geral. O lado esquerdo é o pré-processamento feito na tabela de eventos, o lado direito mostra o fluxo de geração da consulta.

Figura - Como funciona a integração entre Zilliz Cloud e Waii

O fluxo de geração de consultas é:

Waii interpreta a consulta e reescreve uma descrição: "Eventos relacionados a inteligência artificial, aprendizado de máquina, redes neurais e outras tecnologias de IA."
Essa descrição é usada para consultar o Zilliz Cloud, retornando uma lista de IDs de eventos relevantes com base na similaridade semântica.
Waii refina essa lista, filtrando quaisquer eventos que não sejam de IA e que possam ter sido incluídos inadvertidamente.
Waii usa um fluxo de trabalho agêntico que incorpora esses IDs de eventos na 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);

Essa abordagem pode identificar com precisão eventos relacionados à IA, mesmo que usem terminologia especializada ou não contenham palavras-chave óbvias. Ela pode capturar eventos como "3º Simpósio sobre Redes Generativas Adversariais" ou "Workshop sobre Considerações Éticas em Aprendizado por Reforço", que as outras abordagens poderiam deixar passar.

Ao aproveitar a busca por similaridade vetorial, podemos interpretar com mais precisão a intenção do usuário e associá-la aos nomes de eventos de alta cardinalidade em nosso banco de dados, fornecendo resultados mais abrangentes e precisos.

Conclusão

À medida que os volumes de dados continuam a crescer e as expectativas dos usuários por interações intuitivas com dados aumentam, lidar com dados categóricos de alta cardinalidade em sistemas de texto para SQL se tornará cada vez mais comum. Ao aproveitar o poder do Zilliz Cloud em conjunto com Waii, podemos criar sistemas mais robustos, escaláveis e precisos.

Vimos resultados promissores com essa abordagem, e acreditamos que ela é benéfica para outros que enfrentam desafios semelhantes. Fique à vontade para entrar em contato e nos informar se você já testou esta ou abordagens semelhantes, e compartilhar suas percepções.

Atualizado em Jul 13, 2026

Continue lendo

Introducing Loon: A New Storage Engine for Vector Data That Never Stops Changing

Loon is a new storage engine for Milvus 3.0 and Zilliz Vector Lakebase, built to manage evolving vector datasets with ColumnGroups, row ID alignment, and Manifests.

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.

What Exactly Are AI Agents? Why OpenAI and LangChain Are Fighting Over Their Definition?

AI agents are software programs powered by AI that can perceive their environment, make decisions, and take actions to achieve a goal—often autonomously.