RAG é Mais Simples do que Você Imagina

Artigo original ↗ Discussão no Hacker News ↗

A geração aumentada por recuperação (RAG) é retratada como menos nova do que o hype sugere, com muitos argumentando que ela é essencialmente recuperação de informação tradicional mais um LLM e que as equipes frequentemente a complicam demais com bancos vetoriais e embeddings. Os comentaristas enfatizam repetidamente que busca por texto completo e BM25 continuam sendo poderosos, mais baratos e mais fáceis de controlar em muitos casos reais, especialmente em busca técnica e de código, e que embeddings muitas vezes são superestimados, difíceis de ajustar e caros operacionalmente. Também há ceticismo em relação a conteúdo de instruções gerado por IA sobre RAG, junto com pedidos por padrões de projeto mais claros, melhores avaliações e uma abordagem de “comece simples, adicione complexidade só quando necessário”.

O que RAG Realmente É

  • Muitos comentários dizem que RAG é essencialmente “recuperação de informação clássica + LLMs”, não algo fundamentalmente novo.
  • Vários observam que “RAG ≠ busca vetorial”: qualquer recuperação (grep, SQL, FTS, busca na web) cujos resultados sejam alimentados ao LLM é RAG.
  • Outros na discussão ainda tratam implicitamente RAG como “embeddings + banco vetorial”, mostrando confusão contínua.

Embeddings vs Busca por Texto Completo / Palavra‑Chave

  • Tema forte: busca por texto completo (FTS/BM25/Lucene/Elasticsearch/Postgres FTS) é subestimada e normalmente deveria ser tentada primeiro.
  • Argumentos a favor de FTS: mais simples, determinística, ferramentas maduras, mais fácil de depurar, escala bem e muitas vezes funciona melhor para consultas técnicas ou parecidas com código.
  • Argumentos a favor de embeddings: boas para consultas subespecificadas ou descritivas, sinônimos, busca multilíngue e quando os usuários não conhecem os termos exatos.
  • Alguns relatam decepção no mundo real com embeddings: similaridade semântica mais fraca do que o esperado, sobrecarga operacional alta, pipelines de reranking complexos.
  • Outros relatam bons resultados com busca semântica simples baseada em embeddings ou abordagens híbridas BM25+vetor.

Chunking, Escala e Estrutura de Documento

  • O tamanho dos chunks é citado repetidamente como crítico; um chunking ruim pode arruinar a recuperação independentemente do modelo.
  • Documentos longos (livros, relatórios, PDFs) trazem problemas: limites de tokens, referências entre chunks (“it” remetendo a algo anterior) e explosão do tamanho do índice ao embutir muitos segmentos sobrepostos.
  • Há debate sobre se chunks moderadamente grandes (512–1024 tokens) costumam ser suficientes para capturar o contexto do tópico; alguns acham que sim, outros dizem que informações relacionais ainda se perdem.

Casos de Uso: Código, Documentos Corporativos, Multilíngue

  • Para código: várias ferramentas e equipes relatam que grep simples ou FTS com agentes inteligentes muitas vezes superam RAG; alguns até removeram a recuperação por completo sem que os usuários percebessem.
  • Para codebases enormes e buscas abstratas por “conceitos”, a recuperação ainda pode ajudar.
  • Em documentos corporativos/financeiros com muita gíria técnica e siglas, BM25 pode ter dificuldades; embeddings ou configurações entre idiomas podem funcionar melhor.
  • Embeddings são apresentados como um “espaço comum” agnóstico a idioma para busca cruzada entre línguas, mas a depuração é mais difícil.

Design de Sistema, Agentes e Orquestração

  • Muitos veem os verdadeiros “dragões” não nos embeddings, mas no design da recuperação: atualização, controle de acesso, versionamento, documentos sobrepostos, avaliações e ranqueamento.
  • Reescrita de consultas por agentes em cima de busca clássica é popular: deixe o LLM criar e iterar consultas, e use por baixo uma infraestrutura lexical/FTS estável.
  • Alguns veem RAG como um problema de orquestração: combinar módulos (busca exata, vetor, SQL, tags, regras) dependendo do caso de uso e dos requisitos de qualidade.

Custos, Ferramentas e Dicas Práticas

  • Um grupo diz “embede tudo uma vez, acompanhe mudanças e armazene vetores em algo como BigQuery”, assumindo tamanhos modestos de corpus.
  • Outros alertam sobre dependência de fornecedor e sugerem escolher tecnologia portável, Postgres/BM25/pgvector simples, ou SQLite FTS5 com SQL gerado por LLM.
  • Há frustração de que muitos tutoriais de RAG não conectam os métodos às avaliações; as pessoas querem benchmarks e orientação sobre quando cada estratégia de recuperação realmente melhora os resultados.

Ceticismo, Hype e Estilo de Escrita

  • Alguns comentaristas argumentam que o artigo parece “AI slop” gerado por LLM: títulos exagerados, listas superficiais de “o quê” com “por quê” fraco, e receitas híbridas que parecem montadas por máquina.
  • Outros ainda acham o conteúdo útil na prática, apesar do estilo.
  • Há uma reação mais ampla: cansaço com prosa gerada por IA, alegações de que RAG é usado em excesso, “magic beans” ou “coisa de 2024”, e pedidos para começar com a busca mais simples que funcione e só adicionar complexidade quando isso for claramente necessário.