Resumo Técnico: Recuperação Baseada em Esquema para Análise de Linguagem Natural

Declaração do Problema

Sistemas de text-to-SQL empresariais frequentemente falham não durante a geração de SQL, mas durante a fase precedente de seleção de contexto. Em data warehouses modernos, os modelos são frequentemente apresentados com nomes de tabelas brutos que falham em capturar o contexto crítico: nomes de colunas abreviados, métricas de negócios informais, convenções de junção ocultas e limites de permissão. Quando um modelo recebe o contexto de esquema errado (por exemplo, as tabelas erradas, chaves de junção ou definições de negócio), ele produz um SQL sintaticamente válido, mas analiticamente inútil. Benchmarks existentes como o Spider 2.0 destacam que fluxos de trabalho realistas exigem busca de metadados e contexto de projeto, em vez de esquemas acadêmicos compactos. As abordagens atuais frequentemente tratam a seleção de esquema como um detalhe de formatação de prompt ou dependem de pipelines centrados na geração que assumem que o esquema correto já foi fornecido.

Metodologia: Recuperação Baseada em Esquema (Schema-First Retrieval)

O artigo propõe a Recuperação Baseada em Esquema, uma camada de recuperação que trata o catálogo de dados — e não as linhas brutas do warehouse — como o alvo primário de recuperação. O sistema opera em duas fases:

1. Indexação Offline

O sistema define uma taxonomia de objetos de catálogo de cinco tipos, renderizando cada tipo de objeto em um template de texto específico antes da incorporação (embedding):

• Tabelas: Ancoram o domínio (nomes, esquemas, descrições, proprietários).
• Colunas: Fundamentam predicados e projeções (tipos de dados, valores de amostra, contexto pai).
• Métricas: Fazem a ponte entre a linguagem de negócios e o esquema físico (fórmulas, colunas de origem).
• Relacionamentos: Protegem as junções ao codificar chaves estrangeiras e caminhos documentados.
• Histórico de Consultas: Capturam a memória de carga de trabalho (perguntas anteriores e objetos acessados).

Esses objetos são incorporados em coleções vetoriais separadas usando templates específicos por tipo.

2. Pipeline de Recuperação Online

• Busca Paralela: Uma consulta do usuário é incorporada e pesquisada contra todas as cinco coleções de catálogo simultaneamente usando um bi-encoder (Amazon Titan Embedings V2).
• Expansão de Linhagem: Se relacionamentos forem necessários, o sistema expande as tabelas candidatas através de um caminho de junção de busca em largura (breadth-first) para incluir tabelas de ponte e chaves de junção não explicitamente nomeadas na consulta.
• Reclassificação (Reranking): Um cross-encoder (Cohere Rerank V3.5) reclassifica os candidatos agrupados. Isso é particularmente crítico para colunas, que são frequentemente curtas, duplicadas ou abreviadas.
• Fusão de Pontuação: A pontuação final de recuperação combina similaridade semântica, relevância do cross-encoder e evidência do histórico de consultas (ponderada pela recência).
• Governança Determinística: O controle de acesso é aplicado fora do Grande Modelo de Linguagem (LLM). Um filtro determinístico remove objetos de catálogo não autorizados com base em Listas de Controle de Acesso (ACLs) antes da montagem do contexto. O SQL gerado é adicionalmente verificado e reescrito para aplicar predicados de nível de linha.

3. Geração

O gerador de SQL recebe um subconjunto focado e validado pelo catálogo do esquema (DDL, definições de métricas, caminhos de junção) em vez do warehouse completo. O gerador é tratado como um componente substituível; o sistema depende de roteamento orientado por intenção (classificando a complexidade da consulta) e montagem de contexto com orçamento de tokens para otimizar a entrada.

Principais Contribuições

1. Taxonomia de Objetos de Catálogo Tipados: O artigo define templates de incorporação separados para tabelas, colunas, métricas, relacionamentos e histórico de consultas, argumentando que esses objetos respondem a perguntas de recuperação distintas e não devem ser achatados em um bloco de texto genérico.
2. Pipeline de Recuperação de Múltiplos Sinais: Um sistema que integra busca vetorial paralela, reclassificação por cross-encoder, expansão de linhagem e memória de carga de trabalho em um contexto unificado para geração de SQL.
3. Governança Determinística: Uma abordagem de nível de sistema onde o controle de acesso é tratado via filtragem de catálogo e reescrita de SQL, em vez de depender do LLM para lembrar ou seguir instruções de política.

Resultados Experimentais

O sistema foi avaliado em três benchmarks: CRUSH4SQL (1.534 perguntas), SEDE (857 perguntas) e BIRD (96 perguntas).

• Qualidade de Recuperação (CRUSH4SQL):

  • A recuperação semântica (bi-encoder) superou a linha de base BM25 em +32,8 pontos em Table Recall@5.
  • A reclassificação por cross-encoder adicionou +11,1 pontos em Column Recall@10.
  • O sistema completo alcançou 96,4% de Table Recall@20.
  • Estudos de ablação confirmaram que a remoção de qualquer um dos cinco tipos de objetos degradou o desempenho, validando a natureza não redundante da taxonomia.

• Memória de Carga de Trabalho (SEDE):

  • A incorporação do histórico de consultas elevou o Table Recall@5 de 52,1% para 92,3% (+40,2 pontos), demonstrando que padrões históricos melhoram significativamente o ranking das tabelas relevantes.

• Geração de Ponta a Ponta (BIRD):

  • A Recuperação Baseada em Esquema reduziu os erros de execução de SQL de 15,6% para 6,2% (uma redução de 2,5×).
  • A redução foi estatisticamente significativa (teste de McNemar, p=0,035).
  • A análise de erros revelou que o sistema eliminou 8 de 9 erros fixos relacionados à fundamentação lexical (ex: citação de identificadores e referências de colunas de tabelas erradas) ao apresentar as formas de superfície corretas no contexto recuperado.

• Eficiência:

  • O pipeline de recuperação adiciona aproximadamente 1,28 segundos por consulta.
  • O custo experimental total foi inferior a US$ 3 em todos os conjuntos de dados (~US$ 0,006 por pergunta).

Significância e Alegações

O artigo argumenta que a seleção de catálogo é um problema de recuperação de primeira classe, e não meramente um detalhe de formatação de prompt. Ao deslocar o alvo da recuperação de fragmentos de esquema bruto para um catálogo governado e tipado, o sistema aborda a lacuna entre a linguagem do analista (métricas de negócio, termos informais) e o esquema físico (colunas abreviadas, jargões operacionais).

Os autores afirmam que a análise de linguagem natural confiável requer uma camada de recuperação construída especificamente para como os data warehouses são documentados, consultados e governados. A separação de preocupações — onde a recuperação fornece um recorte de catálogo portador de proveniência e a geração escreve sobre esse recorte — permite que o sistema melhore tanto as métricas de recuperação quanto o comportamento de execução. Além disso, ao aplicar o controle de acesso deterministicamente fora do modelo, o sistema evita as armadilhas de confiar em LLMs para aderir a políticas de segurança.

O artigo conclui que, embora a abordagem reduza significamente os erros lexicais e de fundamentação, ela não resolve erros de semântica de dados (ex: comparações de NULL ou violações de aridade de agregados), identificando o limite onde a recuperação deixa de ser o gargalo.