Uber QueryGPT: linguagem natural para SQL — de 10 minutos para 3

• QueryGPT — Natural Language to SQL at Uber — Uber Engineering Blog, 2024-09-19
• A Deep Dive into QueryGPT: Uber's AI-Powered SQL Generator — Sequel (независимый разбор), 2024

Contexto

A Uber é uma empresa orientada por dados no sentido literal: precificação, roteirização, pagamento de motoristas e balanceamento de demanda funcionam em uma plataforma de dados que processa aproximadamente 1.2 milhão de consultas SQL interativas por mês. O maior consumidor é a organização de operações, que contribui com cerca de 36% de todas as consultas. São milhares de funcionários que precisam de dados diariamente, mas para os quais SQL não é sua profissão principal.

A analítica interna da Uber repousa em milhares de conjuntos de dados, e as tabelas-chave (tier-1) cresceram para mais de 200 colunas cada uma. Criar uma consulta não é apenas sintaxe: você deve encontrar as tabelas certas entre milhares e compreender o schema e a lógica de negócios dos campos — como datas são calculadas em um domínio específico, ou o que um sinalizador particular significa.

QueryGPT nasceu de forma ascendente, não por decreto executivo: a ideia foi proposta no hackathon interno Generative AI Hackdays em maio de 2023, quando a Uber estava buscando sistematicamente aplicações de LLM em toda a empresa. Do protótipo do hackathon ao serviço de produção descrito no artigo de engenharia de setembro de 2024, o time de Data Platform passou por mais de 20 iterações de arquitetura.

O caso é valioso precisamente pela sua honestidade de engenharia: a Uber publicou não um anúncio de marketing, mas um detalhamento completo com evolução de versão, métricas de avaliação e problemas não resolvidos — incluindo alucinações e não-determinismo de avaliação. O artigo é assinado por um time de oito engenheiros de Data Platform — de um engenheiro principal a desenvolvedores focados em produtividade de LLM; é o produto de uma organização de engenharia, não de um laboratório de IA. Para quem quer construir text-to-SQL para sua própria empresa, é um dos documentos públicos mais úteis da indústria.

Problema

Uma consulta média levava cerca de 10 minutos para seu autor. A anatomia desses minutos: encontrar as tabelas certas entre milhares de conjuntos de dados, compreender um schema de duzentas colunas, relembrar convenções de domínio (como filtrar pedidos de teste, em qual fuso horário as datas estão) — e só então escrever o SQL em si. Em escala de centenas de milhares de consultas por mês, isso é uma enorme taxa de produtividade: times de operações gastavam tempo em mecânica de consultas em vez de análise e decisões.

A abordagem ingênua — 'apenas dar o schema e a pergunta ao LLM' — atingiu limites fundamentais. O schema de uma única tabela grande consumia 40–60 mil tokens, enquanto as janelas de contexto de modelo antes dos modelos da era 128K eram 32 mil. As consultas frequentemente unem várias tabelas: o schema não cabia fisicamente no modelo, para não falar do custo e latência de tais chamadas.

O segundo problema era as pessoas. Os prompts de usuários reais variam de formulações detalhadas e ricas em palavras-chave para perguntas de cinco palavras com erros de digitação. Um pipeline ingênuo esperando entrada organizada se desintegra em tráfego ativo: uma pergunta curta e sem contexto carrega muito pouco sinal tanto para seleção de tabelas quanto para gerar SQL correto.

E terceiro: o custo do erro. SQL gerado que parece plausível, mas usa uma coluna inexistente ou lógica de negócios errada é pior que nenhuma resposta — ou falha ou, mais perigosamente, retorna números errados que decisões são baseadas. Os usuários, como o time coloca, estabelecem um padrão alto: as consultas devem 'apenas funcionar'.

Solução

A primeira versão, montada no hackathon, era RAG clássico: busca de vetor k-nearest-neighbor sobre um pequeno conjunto de 7 tabelas tier-1 e 20 consultas SQL de referência, das quais 3 tabelas e 7 amostras foram puxadas para o prompt, mais instruções com convenções específicas da Uber (manipulação de datas, termos de negócios). O protótipo provou demanda, mas a acurácia caiu na variedade real de perguntas e tabelas — e as próximas mais de vinte iterações transformaram 'um prompt com RAG' em um pipeline de agentes especializados.

O primeiro movimento estrutural foi 'workspaces': conjuntos curados de tabelas e amostras SQL para um domínio de negócio específico. A produção executa 12+ workspaces de sistema (Mobility, Core Services, Platform Engineering, IT, Ads, e outros), além de workspaces personalizados para casos de uso específicos. A curação é trabalho manual por especialistas de domínio, e é ela — não o modelo — que entrega a maior parte do ganho de acurácia: a busca não funciona em toda a plataforma, mas dentro de um subconjunto pré-processado.

Uma pergunta então passa pelo pipeline. O Intent Agent classifica a consulta em domínios de negócios e escolhe um workspace, estreitando o raio de busca RAG. O Table Agent seleciona tabelas específicas — e mostra a lista para o usuário, que pode confirmar ou editá-la: o time adicionou essa etapa de human-in-the-loop após reclamações sobre seleção errada de tabelas. O Column Prune Agent remove colunas irrelevantes de schemas — isso resolveu o problema de tokens: mesmo com a janela de 128K do GPT-4 Turbo (modelo 1106), schemas completos eram caros e lentos, e poda reduziu tanto latência quanto custos de chamada substancialmente. Um 'prompt enhancer' separado enriquece formulações terse de usuários com contexto antes da geração.

Contra alucinações (tabelas e colunas inexistentes são o principal modo de falha), o time usa um modo de chat iterativo onde o usuário refina a consulta, e experimenta com um agente de validação que recursivamente encontra e corrige erros no SQL gerado.

O sistema de avaliação merece atenção especial. O time montou um conjunto 'ouro' de pares pergunta→SQL dos logs reais do serviço em domínios e o executa em dois modos: Vanilla (o caminho completo de pergunta para SQL) e Decoupled (intenção e tabelas pré-configuradas, para medir componentes isoladamente). Os sinais: acurácia de intenção, sobreposição de tabelas selecionadas com a referência (0–1), sucesso de execução de consulta, retorno de resultado não-vazio, e um escore de similaridade baseado em LLM contra o SQL de referência. Uma descoberta separada: execuções de avaliação são não-determinísticas, com até ~5% de variância entre execuções sem mudanças de código — então o time rastreia padrões de erro por longos períodos em vez de reagir a flutuações de métrica.

Resultado

QueryGPT produz consultas suficientemente confiáveis em cerca de 3 minutos versus ~10 minutos de autoria manual — aproximadamente 70% de tempo economizado por consulta. Em lançamento limitado, o serviço tem em média cerca de 300 usuários ativos diários, 78% dos quais dizem que as consultas geradas reduzem o tempo que teriam gasto escrevendo à mão. Na escala da plataforma de 1.2 milhão de consultas por mês, o potencial de escalonamento é óbvio — mas o time está deliberadamente lançando gradualmente, e em seus aprendizados publicados explicitamente nomeia escolher a audiência inicial certa (personas) como uma lição em si: comece onde o benefício é maior e as necessidades SQL são rotineiras — com times de operações, não com engenheiros de dados, que precisam de um rascunho de LLM menos que todos.

Os aprendizados publicados do time importam tanto quanto. Primeiro: LLMs funcionam excelentemente como classificadores em tarefas estreitas — um pipeline de agentes especializados (intenção → tabelas → colunas) consistentemente bate um prompt grande. Segundo: a pergunta do usuário sozinha é entrada insuficiente para geração; deve ser enriquecida com contexto antes da chamada do modelo. Terceiro: multiplicidade de respostas (a mesma pergunta é corretamente resolvida com diferentes tabelas e estilos SQL) torna a avaliação automatizada inerentemente fuzzy — daí um juiz de LLM e comparação visual contra a referência em vez de um match/no-match binário.

Enquadre os números corretamente: 10 e 3 minutos são estimativas do time da Uber; 78% é auto-relato de usuário, não uma medição de cronômetro; o serviço estava em lançamento limitado na publicação. A Uber não publica nem uma porcentagem de acurácia de geração nem um impacto financeiro — e, em nossa opinião, isso é mais honesto do que extrapolações de blog de terceiros que pintam o caso com centenas de milhares de horas economizadas.

Em nossa opinião, a principal lição transferível de QueryGPT é que text-to-SQL de produção é 20% modelo e 80% engenharia de contexto: workspaces de domínio curados, poda de schema, enriquecimento de prompt, e disciplina de avaliação em um conjunto ouro. Tudo isso se transfere para qualquer empresa com uma grande plataforma de dados — e não requer nem seu próprio modelo nem a escala da Uber. A segunda lição é ritmo: do hackathon para produção levou mais de um ano e 20+ iterações. Times esperando que text-to-SQL 'funcione dentro de um sprint' subestimam precisamente a cauda longa de tuning de domínio, não a dificuldade de LLMs.

Lições aprendidas

1. Text-to-SQL de produção é um pipeline de agentes especializados (intenção → tabelas → colunas), não um prompt grande: LLMs são mais confiáveis como classificadores em tarefas estreitas.
2. Workspaces curados com amostras SQL por domínio batem alimentar o modelo com todo o schema: o investimento principal é curação manual por especialistas de domínio.
3. Poda de schema (Column Prune) é sobre acurácia e custo: menos tokens — mais barato, mais rápido, melhor; até uma janela de 128K não cancela economia de contexto.
4. Entrada de usuário não pode ir para o modelo como está: perguntas reais variam de verbosas para cinco palavras com erros de digitação, e um 'prompt enhancer' antes da geração é obrigatório.
5. Human-in-the-loop no lugar certo: confirmação de usuário sobre seleção de tabelas foi adicionada após reclamações reais — uma etapa barata que remove a fonte de erro principal.
6. Avalie em um conjunto 'ouro' construído a partir de logs reais, medindo componentes isoladamente; e cuidado com o não-determinismo de avaliação de LLM (~5% entre execuções) — rastreie padrões de erro, não flutuações de métrica.
7. O enquadramento honesto de qualidade é 'um rascunho suficientemente confiável em 3 minutos', não 'SQL perfeito': um humano permanece como revisor — uma condição de confiança, não uma fraqueza do produto.

Perguntas frequentes