Resumo Técnico: Grandes Bancos de Dados Precisam de Modelos de Linguagem Pequenos e de Pesos Abertos

Declaração do Problema

A integração de modelos de linguagem (LMs) em sistemas de bancos de dados relacionais (LM-DB) é dificultada pelos modelos predominantes de custo e latência de LMs proprietários baseados em API. Os sistemas atuais frequentemente dependem de preços baseados em tokens, onde o processamento de grandes bancos de dados por meio de operadores relacionais aprimorados por LM pode incorrer em custos proibitivos (por exemplo, excedendo US$ 10.000 para um único conjunto experimental) e introduzir latência significativa. Essa barreira econômica restringe a pesquisa profunda e a implantação prática. Além disso, a literatura existente sobre sistemas híbridos LM-DB utiliza predominantemente modelos fechados e grandes (frequentemente >20B de parâmetros), deixando uma lacuna na compreensão de se modelos pequenos e de pesos abertos podem ser efetivamente aproveitados através de infraestrutura de software otimizada para alcançar desempenho comparável a uma fração do custo.

Metodologia

Os autores propõem o BlendSQL v0.1.0, um sistema projetado para integrar modelos locais, quantizados e de pesos abertos em um mecanismo de consulta de banco de dados. A metodologia foca em três pilares principais:

1. Arquitetura do Sistema e Linguagem de Consulta

O BlendSQL é uma linguagem de consulta que compila para SQL padrão, permitindo a combinação de operadores SQL tradicionais com funções generalizáveis de LM.

• Funções Polimórficas: Em vez de inúmeros operadores específicos, o BlendSQL utiliza duas funções principais:
  • llmqa: Uma função de agregação que transforma subconjuntos de dados em saídas escalares ou coleções (ex: ranking, RAG).
  • llmmap: Uma função linha a linha que aplica perguntas de linguagem natural a valores de colunas específicos.
• Decodificação Restrita: O sistema impõe a adesão estrita a tipos de dados e conjuntos de opções usando llguidance, garantindo que as saídas sejam válidas dentro do contexto da consulta (ex: esquemas JSON válidos ou escolhas categóricas específicas).
• Prompting de Um Único Exemplo (One-Shot Prompting): O sistema emprega prompting de um único exemplo alinhado ao tipo para melhorar a precisão sem aumentar o overhead de tokens.

2. Estratégias de Otimização de Consulta

Para mitigar o custo computacional das chamadas de LM, o BlendSQL implementa um otimizador baseado em regras que abstrai o modelo de custo ($C(f) \ll C(llmqa) < C(llmmap)$) e aplica quatro estratégias principais:

• Filtragem em Cascata (Cascade Filtering): Sequencia os predicados de LM para que as funções subsequentes processem apenas linhas que satisfaçam todos os filtros precedentes, evitando chamadas redundantes.
• Saída Antecipada (Early Exiting): Para consultas com cláusulas LIMIT, o sistema encerra a geração do LM assim que o número necessário de linhas é satisfeito, cancelando solicitações assíncronas pendentes.
• Deduplicação Antecipada (Early Deduplication): Antes de passar os valores para o llmmap, o sistema deduplica as entradas (via SELECT DISTINCT) e re-junta os resultados, reduzindo o número de invocações de LM proporcionalmente ao fator de duplicação.
• Pré-filtragem e Materialização: O otimizador aplica o push-down de predicados SQL comuns e materializa subconjuntos filtrados em tabelas temporárias antes de invocar funções de LM, minimizando I/O e transferência de dados.

3. Configuração Experimental

• Hardware: Os experimentos foram conduzidos em uma estação de trabalho local com uma NVIDIA RTX 5080 (16GB VRAM), 64GB RAM e um AMD Ryzen 5 7600X.
• Modelos: O estudo utilizou as famílias quantizadas Gemma 3 e Gemma 4 (especificamente Gemma 4 E4B e E2B) rodando via vLLM.
• Benchmark: O benchmark SemBench foi utilizado, cobrindo cinco cenários (Filmes, Vida Selvagem, E-Commerce, Carros, MMQA) com modalidades de texto, imagem e áudio.
• Linhas de Base (Baselines): Comparações foram feitas contra APIs proprietárias (Gemini 2.5 Flash) e sistemas de código aberto (LOTUS, Palimpzest, ThalamusDB) onde compatíveis.

Principais Resultados

O estudo demonstra que modelos pequenos e de pesos abertos, quando acoplados a otimizações de sistema eficazes, podem superar ou igualar contrapartes de código fechado em contextos específicos.

• Redução de Custo e Latência: O BlendSQL com o Gemma 4 E4B alcançou uma redução de 390x no custo (caindo de US$ 226,64 para US$ 0,58 para a suíte completa do benchmark) e uma redução de 3,8x na latência em comparação com o sistema médio do SemBench usando Gemini 2.5 Flash.
• Desempenho de Qualidade:
  • Texto: O modelo local Gemma 4 E4B alcançou uma taxa de vitória ou empate de 57% contra alternativas de código fechado em todos os cenários. Ele superou a média da linha de base nos cenários MMQA (0,85 vs. 0,70) e Vida Selvagem (0,54 vs. 0,51) e quase igualou a linha de base no cenário de Filmes (0,72 vs. 0,74).
  • Lacunas Multimodais: Uma lacuna significativa de qualidade surgiu em cenários intensivos em áudio (ex: o cenário "Carros"), onde o modelo de peso aberto pontuou 0,53 comparado ao 0,67 da linha de base. Os autores atribuem isso a uma lacuna de modalidade nos atuais modelos pequenos de pesos abertos em relação à compreensão de áudio e imagem.
• Escalabilidade: Ao contrário dos sistemas de linha de base (LOTUS, Palimpzest, ThalamusDB) que exibiram escalonamento de memória linear (atingindo até 268GB de memória CPU no fator de escala 4.000), o BlendSQL manteve uma pegada de memória quase constante (~18GB), permitindo a execução em hardware de nível de consumidor.
• Estudos de Ablação: A ablação de recursos confirmou que a Deduplicação Antecipada proporcionou as maiores economias de latência (até 40s no cenário de Filmes), enquanto a Decodificação Restrita foi crítica para a qualidade, aumentando as pontuações em até 0,35 em tarefas de classificação ao evitar saídas inválidas.

Significância e Alegações

O artigo argumenta que a suposição de que APIs de LM de código fechado são necessárias para uma integração eficaz de LM-banco de dados é falha. Ao mudar de um modelo de preço baseado em tokens para um modelo baseado em tempo (computação por hora) habilitado por hardware local, pesquisadores podem alcançar:

1. Acessibilidade: Reduzindo drasticamente a barreira de entrada para a pesquisa em LM-DB, tornando experimentos de grande escala viáveis sem custos proibitivos.
2. Reprodutibilidade: Garantindo que os resultados experimentais não estejam sujeitos à volatilidade de endpoints de API proprietários ou flutuações de qualidade ao longo do tempo.
3. Inovação de Infraestrutura: Demonstrando que a infraestrutura de software (otimizadores, decodificação restrita, cache) é tão preditiva do desempenho downstream quanto a escolha do modelo base.

Os autores concluem que, embora os modelos pequenos de pesos abertos atualmente fiquem atrás na compreensão multimodal (áudio/imagem), eles são estritamente superiores para tarefas baseadas em texto quando devidamente aproveitados, oferecendo um caminho viável e de baixo custo para sistemas híbridos de LM-DB.