Ask HN: Como vocês estão implementando RAG localmente?

 (news.ycombinator.com)
37 pontos por GN⁺ 2026-01-16 | 3 comentários | Compartilhar no WhatsApp
  • Pergunta no Hacker News sobre como os usuários estão implementando Retrieval-Augmented Generation (RAG) em ambientes locais
  • Há uma tendência forte de que, em RAG local, é perfeitamente viável operar mesmo sem banco de dados vetorial, usando busca textual como SQLite FTS5, BM25 e grep
  • Para busca de código, muitos relatos dizem que embeddings são lentos e ruidosos, e há várias opiniões de que abordagens baseadas em palavras-chave, como BM25 + trigramas, funcionam melhor
  • Mesmo quando a busca vetorial é necessária, seguem aparecendo casos resolvidos com configurações leves, como Postgres + pgvector, armazenamento de vetores como BLOB no SQLite e carregamento do FAISS em memória
  • É possível melhorar a qualidade da busca com combinações como busca híbrida unindo BM25 + vetores, RRF (Reciprocal Rank Fusion), reranking e expansão multiquery
  • Em vez de fixar a ideia de “RAG = banco de dados vetorial”, aparece a tendência de escolher entre busca simples → híbrida → estilo agente conforme o tipo de documento, a escala e a carga operacional

Conclusões comuns na etapa de busca

  • Em vez de partir da premissa de que banco de dados vetorial ou grafo é obrigatório, muitos preferem começar de forma simples, de acordo com a infraestrutura existente, os tipos de arquivo e o desempenho exigido
  • Há menções de que a abordagem em que o agente consulta diretamente o sistema de arquivos ou APIs é mais fácil de configurar e manter, embora possa ser um pouco mais lenta
  • A percepção de que “o que o RAG entrega ao LLM são apenas pequenos trechos de texto dos resultados de busca” leva o foco de otimização para a qualidade da busca
  • Sobre a “definição de RAG”, coexistem tanto a reação de que retrieval + generation já é RAG, mesmo sem banco vetorial, quanto a de que o termo normalmente pressupõe um banco vetorial

Modelos de embedding e busca vetorial

  • O modelo de embedding mdbr-leaf-ir, desenvolvido pela MongoDB, roda apenas em CPU e ficou em 1º lugar em vários leaderboards dentro do seu porte
    • Em um servidor padrão de 2 vCPU, consegue processar cerca de 22 documentos por segundo e 120 consultas por segundo
    • Registrou 53,55 pontos no benchmark BEIR (o all-MiniLM-L12-v2 ficou com 42,69)
  • Embeddings estáticos de palavras como model2vec/minish têm inferência mais rápida, mas menor precisão de busca
    • Como fazem apenas tokenização + tabela de lookup + média, são mais rápidos que abordagens baseadas em transformers
  • Também é usado um método em que vetores são gerados por chunk de texto com Meta-Llama-3-8B, armazenados em uma coluna BLOB do SQLite e pesquisados com FAISS
    • Para 5 milhões de chunks, o uso de memória fica em cerca de 40 GB
    • No A6000, o faiss-gpu é muito rápido; no M1 Ultra, o faiss-cpu é lento, mas ainda suficiente para algumas consultas por dia

Recomendações para busca de código

  • Recomenda-se evitar banco de dados vetorial para código e usar a combinação BM25 + trigramas
    • Embeddings são lentos e não se adaptam bem a código
    • Sem reranker, o ruído aumenta, e o custo de reindexar arquivos é alto
    • A resposta de busca é rápida e a qualidade dos resultados também é boa
  • No PostgreSQL, é possível implementar busca BM25 com plpgsql_bm25
    • Há suporte a busca híbrida combinada com pgvector + Reciprocal Rank Fusion
  • Aplicar embeddings a caminhos de arquivo + assinaturas e depois fundir com BM25 também pode gerar bons resultados
  • A abordagem agentic que executa gpt-oss 20B com ripgrep em um loop while também se mostra eficaz

Soluções baseadas em banco de dados

  • SQLite FTS5: adequado para documentos baseados em arquivos Markdown, permitindo implementar RAG mesmo sem banco vetorial
    • Cada arquivo pode ter um campo curto de descrição para navegação de documentos por busca de palavras-chave
    • Também é possível projetar uma arquitetura em que vetores fp16 são armazenados como BLOB no SQLite, um filtro cria um subconjunto e o cálculo de similaridade é feito em memória
    • Outras opções incluem sqlite-vec, sqlite-vector, vec0 e o bm25 do SQLite
    • “O SQLite funciona surpreendentemente bem”
  • PostgreSQL + pgvector: permite aproveitar conhecimento prévio de Postgres e facilita a transição para a equipe de operações
    • Também existe a biblioteca llmemory, que oferece BM25 híbrido, expansão multiquery e reranking
  • LanceDB: pode ser usado de forma conveniente como banco vetorial embarcado
    • Utilizado junto com o embedding nomic-embed-text do Ollama
  • DuckDB: oferece extensão para busca por similaridade vetorial e é adequado para projetos pequenos abaixo de 3 GB
  • Meilisearch, Typesense, Manticore: operação mais simples que Elasticsearch/OpenSearch

Busca híbrida e agentic

  • nori (usenori.ai): combina busca semântica e por palavras com SQLite + vec0 + fts5
  • Turbopuffer: oferece busca híbrida de vetor + BM25
  • Mesmo só com a combinação de busca agentic e busca textual já é possível obter resultados muito bons
    • Ao adicionar busca vetorial e graph RAG, é possível conseguir pequenas melhorias em velocidade e qualidade
  • Claude Code/Codex usam internamente ripgrep
  • Aplicar embeddings em caminhos de arquivo também é eficaz; com fusão via BM25, melhora ainda mais

Casos de uso com BM25

  • shebe: ferramenta CLI/MCP para indexação e busca em codebases baseada em BM25
    • Especialmente útil em fluxos de refatoração (ex.: listar os pontos que precisam mudar em um upgrade do Istio)
  • Em 85% dos casos, basta correspondência por tags, sem banco vetorial
    • Operadores adicionaram tags tanto às entradas quanto à documentação, alcançando 100% de correspondência
  • Há a opinião de que a maioria dos bancos vetoriais é um “martelo tentando resolver o problema de não conseguir encontrar algo”

Ferramentas e bibliotecas específicas

  • qmd: ferramenta CLI para busca em arquivos Markdown, com resultados de consulta fuzzy melhores que o fzf
  • ck: ferramenta de grep semântico baseada em Rust
  • Kiln: permite adicionar arquivos por drag and drop e comparar várias configurações
    • Suporta comparação de métodos de extração, modelos de embedding e formas de busca (BM25, híbrida, vetorial)
    • Inclui avaliação de precisão de busca e geração automática de dataset de avaliação
  • libragen: CLI/servidor MCP para criar bibliotecas de conteúdo RAG versionadas
    • Pode transformar repositórios GitHub em bancos RAG
  • piragi: biblioteca Python simples para RAG, com suporte a várias fontes como local/S3/API
  • ragtune: ferramenta CLI para depuração e benchmark de busca em RAG local

Processamento de documentos e OCR

  • discovery: faz OCR de documentos com Qwen-3-VL-8B e armazena vetores no ChromaDB
    • Implementa RAG híbrido com BM25 + embeddings
  • docling: ferramenta de extração de documentos usada em vários projetos de RAG
  • Na conversão de PDF, é difícil lidar com tabelas, múltiplas colunas e tabelas que atravessam páginas
    • O modelo Mistral OCR entrega os melhores resultados (modelo fechado)

Gestão de memória e contexto

  • O que o RAG passa ao LLM são apenas strings curtas de resultados de busca
    • Em modelos pequenos, TOP_K=5 costuma ser o limite; acima disso começa o esquecimento de contexto
  • É possível melhorar com uma abordagem de resumo prévio de arquivos e pastas
  • Também há quem use Sonnet + janela de contexto de 1M para colocar tudo diretamente no contexto
  • Há casos de construção de sistema de memória para Claude Code com busca semântica em arquivos de sessão

Uso corporativo e em larga escala

  • Ao processar 300 mil interações com clientes por dia, latência e precisão são críticas
    • É usada uma abordagem híbrida com embeddings + busca full-text + IVF-HNSW
    • Um desafio é gerenciar a propagação de informação entre cerca de 600 sistemas distribuídos
  • Está em experimentação uma abordagem KAG (Knowledge Augmented Generation) para mapear regras de negócio
  • Houve sucesso na implementação de RAG totalmente local com banco vetorial em Postgres para mais de 500 mil artigos de notícias

Outras ferramentas e abordagens

  • AnythingLLM: inclui bundle de banco vetorial para documentos
  • LibreChat: também inclui bundle de banco vetorial para documentos
  • ChromaDB: usado em extensão do Obsidian para busca semântica/híbrida
  • SurrealDB: usado em conjunto com vetorização local
  • Interface de consulta OData: é eficaz quando fornecida ao LLM como ferramenta, permitindo analisar planilhas Excel com 40 mil linhas
  • Nextcloud MCP Server: usa Qdrant como banco vetorial para oferecer busca semântica em documentos pessoais
  • LSP (Language Server Protocol): foi adicionado ao Claude Code, mas atualmente há bugs
    • TreeSitter pode ser mais útil (consulta por nome de símbolo, navegação para definição/uso)

Leituras relacionadas

3 comentários

 
tensun 2026-01-16

Tenho dúvidas se o coreano está funcionando bem.
 
ryj0902 2026-01-20

Vendo o desempenho de um sistema interno de RAG bem tosco, posts como este acabam mudando um pouco a minha perspectiva.
 
GN⁺ 2026-01-16
Comentários do Hacker News

  • Nossa equipe mantém um banco de dados de perguntas e respostas
    As perguntas e respostas são indexadas tanto com índice trigram quanto com embeddings e armazenadas no Postgres
    Na busca, usamos pgvector junto com busca por trigram e combinamos os resultados com uma pontuação de relevância

  • Na etapa de busca, desenvolvemos um modelo de embedding de texto altamente eficiente e amigável à CPU
    É o modelo MongoDB/mdbr-leaf-ir, que ocupa o 1º lugar no leaderboard entre modelos do mesmo porte
    É compatível com o modelo Snowflake/snowflake-arctic-embed-m-v1.5
    Pelo demo do search-sensei, dá para comparar busca semântica vs BM25 vs híbrida
    Por exemplo, o modelo de embedding reconhece que “j lo” significa “Jennifer Lopez”
    Também publicamos a receita de treinamento, e dá para treinar facilmente até com hardware mediano

    • Tenho curiosidade sobre como a velocidade de embedding e o recall desse modelo se comparam com embeddings estáticos de palavras como minish ou model2vec

  • Desde abril de 2024, venho gerando vetores com Meta-Llama-3-8B
    Usei Python e Transformers em uma RTX-A6000; era rápido, mas o ruído e o calor eram intensos
    Depois migrei para um M1 Ultra e passei a usar a biblioteca MLX da Apple; a velocidade é parecida, mas é muito mais silencioso
    Os modelos Llama têm 4k dimensões, então isso dá 8KB por chunk em fp16, e eu salvo isso com numpy.save() em uma coluna BLOB do SQLite
    Na busca, carrego todos os vetores do SQLite, transformo em numpy.array e depois pesquiso com FAISS
    O faiss-gpu da RTX6000 é muito rápido, e o faiss-cpu do M1 Ultra também é rápido o bastante para meu uso (algumas consultas por dia)
    Com 5 milhões de chunks, o uso de memória fica em cerca de 40GB, algo que ambas as máquinas conseguem lidar com folga

  • A maioria dos documentos complexos é formada por arquivos Markdown
    Recomendo uma ferramenta CLI simples chamada tobi/qmd
    Antes eu usava um workflow baseado em fzf, mas essa ferramenta oferece busca fuzzy melhor
    Não uso isso para busca em código

    • Pela apresentação, achei que seria uma ferramenta em golang para substituir grep, e esperava recursos como ponderação de headings em Markdown

  • Recomendo não usar banco de dados vetorial para busca em código
    Embeddings são lentos e não se encaixam bem em código
    A combinação BM25 + trigram dá resultados melhores e responde mais rápido

    • Também dá para fazer busca híbrida no Postgres
      Você pode olhar o projeto plpgsql_bm25
      Ele inclui exemplos e notebooks Jupyter combinando BM25 e pgvector com Reciprocal Rank Fusion
    • Também concordo. No passado, usei busca híbrida em uma ferramenta substituta de grep, mas a reindexação contínua era incômoda
      Se você usar modelos que não são para código, a busca vetorial gera muito ruído
      Hoje, rodar gpt-oss 20B em loop junto com ripgrep é muito mais rápido e preciso
    • Alguém conhece algum serviço simples ou imagem Docker que ofereça BM25 e busca vetorial juntos?
    • Tive bons resultados ao aplicar isso a caminhos de arquivo ou assinaturas
      Quando combinado com BM25 em uma fusão (fusion), melhora ainda mais
    • Queria saber a opinião das pessoas sobre usar RAG para busca em documentos

  • Para experimentar RAG localmente, criei local-LLM-with-RAG
    Gero embeddings com o “nomic-embed-text” do Ollama e uso LanceDB como banco de dados vetorial
    Recentemente atualizei para “agentic RAG”, mas isso talvez seja exagero para projetos pequenos

    • Eu faço algo parecido. Estou usando lance-context, que é uma versão bem mais simples
    • Obrigado por explicar o que significa “RAG”. Eu estava confuso lendo esta thread

  • Armazeno vetores fp16 como BLOB no SQLite, aplico filtros e carrego na memória para calcular similaridade com produto matriz-vetor (matvec)
    Se numpy ou torch aproveitarem multithreading/BLAS/GPU, isso fica muito rápido
    Se aparecer gargalo, pretendo migrar para sqlite-vector
    Como os dados diminuem bastante com filtros como data ou localização, isso é eficiente
    O backend fica escondido atrás de uma interface substituível

  • Como 95% dos meus documentos são arquivos Markdown pequenos, uso SQLite FTS5 como índice de busca de texto puro
    Eu já tinha esse índice, então liguei direto a um agente mastra
    Cada arquivo tem um campo curto de descrição; depois da busca por palavra-chave, se a descrição bater, eu carrego o documento inteiro
    Levei cerca de uma hora para configurar, e funciona muito bem

    • Na verdade, isso já é RAG (Retrieval-Augmented Generation)
      Busca baseada em embeddings é mais comum, mas a essência é a mesma

  • Já tínhamos familiaridade com Postgres, então começamos com PGVector
    Mais tarde descobrimos que o conteúdo correspondia 100% aos campos semiestruturados do prompt
    Isso aconteceu porque os operadores começaram a colocar tags tanto na entrada quanto nos documentos (cerca de 50 documentos)
    Então primeiro buscamos pelos campos, colocamos esse arquivo no prompt e só depois fazemos busca por embeddings
    No fim, em 85% dos casos não precisamos de vectordb

    • A maioria dos vectordb parece um martelo à procura de um prego

  • Eu criei o llmemory e o uso tanto localmente quanto em apps da empresa
    Ele é baseado em PostgreSQL + pgvector e inclui BM25 híbrido, expansão de múltiplas consultas e reranking
    Estou divulgando isso publicamente pela primeira vez, então pode haver alguns bugs
    Estou bem satisfeito com o desempenho