Vertex AI Search vs Text-to-SQL: Um Estudo Comparativo para Busca em Linguagem Natural
Quando trabalhamos com grandes volumes de dados corporativos, uma das demandas mais recorrentes é permitir que usuários não-técnicos façam consultas usando linguagem natural. Mas qual a melhor abordagem para implementar isso?
Neste artigo, compartilho os resultados de um estudo técnico que conduzi avaliando três abordagens diferentes para busca em linguagem natural sobre dados armazenados no BigQuery.
O Problema
O cenário era claro: tínhamos milhões de registros no BigQuery (relatórios de testes, Change Requests, KPIs) e os stakeholders precisavam consultar esses dados sem escrever SQL. A pergunta central era: como transformar perguntas em linguagem natural em resultados precisos e confiáveis?
As Três Abordagens Avaliadas
1. Vertex AI Search
O Vertex AI Search é a solução gerenciada do Google para busca semântica. Ele indexa dados e permite buscas em linguagem natural com entendimento de contexto.
Prós:
- Setup relativamente simples — basta conectar o data source
- Entendimento semântico nativo, sem necessidade de engenharia de prompt complexa
- Integração direta com dados no BigQuery e Cloud Storage
Contras:
- Custo elevado para grandes volumes de dados
- Menor controle sobre a lógica de ranking e relevância
- Latência pode ser alta para queries complexas
2. BigQuery ML com Embeddings
Nessa abordagem, usamos o BigQuery ML para gerar embeddings dos dados e da query do usuário, comparando-os por similaridade vetorial.
Prós:
- Dados ficam no BigQuery, sem necessidade de mover para outro serviço
- Controle total sobre o modelo e os embeddings
- Custo previsível (baseado em processamento de queries)
Contras:
- Requer engenharia de dados para gerar e manter os embeddings
- A qualidade depende diretamente do modelo de embedding escolhido
- Complexidade de implementação significativamente maior
3. Text-to-SQL com LLM
A abordagem mais direta: usar um LLM (como Gemini) para converter a pergunta do usuário diretamente em uma query SQL.
Prós:
- Flexibilidade máxima — qualquer pergunta pode virar qualquer query
- Resultado preciso quando o SQL gerado está correto
- Experiência do usuário mais próxima de uma "conversa"
Contras:
- Risco de alucinação: o LLM pode gerar SQL inválido ou semanticamente incorreto
- Requer engenharia de prompt detalhada (schema, exemplos, validações)
- Necessidade de camadas de segurança para evitar queries destrutivas
Resultados Comparativos
| Critério | Vertex AI Search | BigQuery ML | Text-to-SQL |
|---|---|---|---|
| Precisão | Alta | Média-Alta | Variável |
| Custo | Alto | Médio | Baixo-Médio |
| Complexidade de Setup | Baixa | Alta | Média |
| Manutenção | Baixa | Alta | Média |
| Flexibilidade | Média | Alta | Muito Alta |
| Latência | Média | Baixa | Média |
A Decisão Arquitetural
Optamos por uma abordagem híbrida: Text-to-SQL como camada principal (pela flexibilidade e custo), com um mecanismo de validação que verifica o SQL gerado contra o schema real antes da execução.
Para mitigar as alucinações, implementamos:
- Schema injection no prompt: o LLM recebe o schema completo das tabelas relevantes
- Few-shot examples: exemplos de perguntas e SQLs esperados para guiar o modelo
- Validação sintática: o SQL gerado é parseado antes de ser executado
- Fallback para busca simples: se o SQL falhar na validação, oferecemos uma busca por keywords
Lições Aprendidas
-
Não existe bala de prata. Cada abordagem tem seu espaço. O importante é entender os trade-offs e escolher com base nos requisitos do negócio.
-
O custo é uma variável arquitetural. Vertex AI Search resolve elegantemente, mas o custo em escala pode ser proibitivo. Text-to-SQL é mais barato, mas exige investimento em engenharia de prompt.
-
Cache é indispensável. Independente da abordagem, implementar cache semântico (queries similares retornam resultados cacheados) reduziu custos em mais de 60%.
-
Validação é tão importante quanto geração. Em sistemas baseados em IA generativa, a camada de validação e segurança é o que separa um protótipo de um produto.
Esse estudo foi conduzido dentro do contexto de um sistema interno de larga escala. Os números e trade-offs podem variar dependendo do volume de dados e dos requisitos específicos do seu caso.