Seu app de RAG precisa de banco vetorial separado? A Databricks mediu a busca no Postgres com 4M de passagens
Um engenheiro da Databricks dimensionou busca híbrida no Lakebase Postgres com um app real e corpora públicos. Os números ajudam os times a decidir onde a recuperação deve viver.
Ouça este artigo · 4 min
Narração completa do artigo, gerada por IA.
Muitos projetos de RAG enterprise começam com uma decisão de arquitetura que ninguém examinou: adicionar um banco vetorial. Os dados da aplicação ficam no seu banco transacional, os embeddings vão para um armazenamento separado, e um pipeline de sincronização junta os dois. São três sistemas, duas cópias dos dados e um problema de atualidade antes mesmo de a primeira pergunta ser respondida.
Um post de engenharia da Databricks de 15 de outubro testa a alternativa com números. Philipp Tiefenbacher dimensionou busca híbrida, busca vetorial mais busca por palavra-chave BM25 fundidas com Reciprocal Rank Fusion, dentro do Lakebase Postgres, com os dados da aplicação, o índice vetorial e o índice de palavra-chave em uma mesma instância. Ele usou um app interno com cerca de 23,000 linhas de slides e passagens públicas do MIRACL em inglês com 1, 2 e 4 milhões de linhas, com índices vetoriais de 5.8, 11.5 e 23 GB. O próprio Lakebase Search entrou em disponibilidade geral (GA) em setembro; este é um estudo de medição, não um lançamento.
O que as medições dizem
Quatro achados valem a pena levar para qualquer revisão de design, com a ressalva de que vêm de um único corpus, um único modelo de embeddings e combinações sintéticas de consultas:
- Dimensione o cache pelo índice vetorial, não pela contagem de linhas. A razão entre cache e tamanho do índice previu a taxa de acerto ao longo dos tamanhos de corpus: 45% com razão de 0.07, 86% com 0.57 e 97% com 1.14. A latência mediana de vetor com cache quente caiu de 187 ms para 4 ms conforme a razão subia.
- Menos candidatos custam pouco. Reduzir o pool de candidatos de 1,000 para 200 manteve 90.5% de sobreposição nos 10 melhores resultados, tocou cerca de um terço das páginas e cortou a latência fria de 740 ms para 387 ms. A sobreposição com o pool maior não é o mesmo que qualidade de recuperação, mas é um limite útil.
- Recall é uma configuração. O índice padrão deu recall@10 de cerca de 0.74 a 0.75; um modo de build de qualidade o elevou para 0.80, e para 0.97 com mais probes, a um custo de latência.
- O gargalo se move. Até cerca de 4 compute units o banco era o limite; acima de 8, eram os workers da aplicação. O connection pooling com 50 usuários quase dobrou o throughput e cortou a latência p95 de 2.4 para 0.7 segundos.
Sobre custo, um teste de carga de 14 minutos atendeu 109,602 requisições por $0.13, dos quais $0.02 foram de compute do Lakebase. Isso cobre um teste curto, não um mês de produção; o autor recomenda manter um mínimo pequeno sempre ativo, cerca de $31 a $40 por mês a preço de lista, para evitar cold starts de cerca de um segundo.
Um framework para onde a recuperação vive
O estudo não compara o Lakebase com bancos vetoriais dedicados. Mas torna a decisão concreta o suficiente para enquadrar:
| Aponta para buscar no banco da aplicação | Aponta para um serviço separado | |
|---|---|---|
| Atualidade | Os resultados precisam refletir cada escrita imediatamente | Alguns minutos de atraso são aceitáveis |
| Onde o corpus vive | Nas próprias tabelas da aplicação | Em muitas fontes, compartilhadas por muitos apps |
| Escala | O índice cabe na memória que você está disposto a pagar | O índice muito além do cache de uma instância |
| Permissões | Regras em nível de linha já no banco | Um modelo de permissão separado por fonte |
| Time | Sem apetite para operar outro sistema | Um time de plataforma já opera a recuperação |
A linha de permissões é a que os times subestimam. Quando a busca roda no banco que já aplica quem pode ver quais linhas, a recuperação herda essas regras. Um índice separado precisa da sua própria cópia do modelo de permissão, mantida em sincronia, e cada sincronização é uma chance de vazamento. É a questão da custódia aplicada aos embeddings: cada cópia é um novo lugar onde os dados vivem.
Meça antes de escolher
O conselho do próprio autor é a parte mais transferível: meça o recall nos seus próprios dados, porque ele depende do corpus e do modelo de embeddings. Isso ecoa nosso argumento de que a recuperação deve ser medida como um sistema próprio, com suas próprias métricas, antes de qualquer debate sobre qual produto a hospeda.
Uma sequência prática para um novo app de RAG: começar com a busca onde os dados já vivem, montar um pequeno conjunto de avaliação a partir de perguntas reais, medir recall e latência no tamanho de corpus que você espera, e mover a recuperação para um serviço separado só quando um requisito específico do lado direito da tabela obrigar. O sistema extra deve ser uma conclusão, não uma suposição de partida.