- Skald foi desenvolvido com o objetivo de ser um sistema RAG totalmente auto-hospedável, sem enviar dados a terceiros
- Os componentes de um RAG são divididos em banco de dados vetorial, modelo de embeddings, LLM, reranker e parser de documentos, e são apresentadas alternativas open source para cada elemento
- A stack local padrão do Skald é composta por Postgres+pgvector, Sentence Transformers, Docling e um LLM personalizado
- Nos resultados de benchmark, os modelos baseados em nuvem (Voyage+Claude) receberam média de 9,45 pontos, enquanto o GPT-OSS 20B totalmente local foi avaliado entre 7,10 e 8,63 pontos
- Essa abordagem mostra que é possível construir um RAG de alto desempenho mantendo a privacidade dos dados
Componentes de RAG e alternativas open source
- Um RAG básico é composto por banco de dados vetorial, modelo de embeddings e LLM, podendo incluir adicionalmente reranker e parser de documentos
- Cada componente pode ser substituído por alternativas locais em vez de SaaS
- Alternativas apresentadas na tabela de exemplo
- Vector DB: Pinecone, Weaviate Cloud → Qdrant, Weaviate, Postgres+pgvector
- Embeddings: OpenAI, Cohere → Sentence Transformers, BGE, E5
- LLM: GPT, Claude → Llama, Mistral, GPT-OSS
- Reranker: Cohere → BGE Reranker, Sentence Transformers Cross-Encoder
- Document Parsing: Reducto → Docling
- O Skald busca uma stack totalmente open source, executando cada componente localmente
Composição da stack local do Skald
- Vector DB: uso de Postgres + pgvector
- Fácil de integrar à infraestrutura existente e capaz de lidar com centenas de milhares de documentos
- Vector Embeddings: o padrão é Sentence Transformers (all-MiniLM-L6-v2)
- Exclusivo para inglês, com equilíbrio entre velocidade e desempenho de busca
- O modelo bge-m3 (com suporte multilíngue) também foi testado
- LLM: não há um fornecido por padrão; o usuário executa o seu próprio
- Nos testes, o GPT-OSS 20B foi executado em uma EC2
- Reranker: o padrão é Sentence Transformers Cross-Encoder, e modelos multilíngues como bge-reranker-v2-m3 também podem ser usados
- Document Parsing: uso de Docling, executado com docling-serve
Resultados de desempenho e implantação
- A implantação de uma instância de produção do Skald com a stack completa levou 8 minutos
- Incluindo Postgres, serviços de embeddings e reranking, e Docling
- O LLM é executado separadamente (usando llama.cpp)
- O conjunto de dados de teste foi composto por conteúdo do site da PostHog (cerca de 2.000 documentos) e um conjunto próprio de perguntas e respostas
- Configuração dos experimentos
- Vector search topK=100, Reranking topK=50, Query rewriting=Off
- O critério de avaliação foi focado em precisão
Comparação dos resultados de benchmark
- Voyage + Claude (configuração em nuvem)
- Pontuação média de 9,45, com todas as respostas corretas
- Voyage + GPT-OSS 20B (parcialmente local)
- Pontuação média de 9,18, majoritariamente correta, mas com algumas informações ausentes
- Totalmente local + GPT-OSS 20B
- Modelo básico em inglês (all-MiniLM-L6-v2 + ms-marco-MiniLM-L6-v2) : média de 7,10
- Preciso em consultas em inglês, mas com fraquezas em consultas multilíngues, ambíguas e agregação entre múltiplos documentos
- Modelo multilíngue (bge-m3 + mmarco-mMiniLMv2-L12-H384-v1) : média de 8,63
- Sucesso no processamento de consultas em português, mas com algumas omissões na agregação entre múltiplos documentos
- A principal limitação é o processamento integrado de informações espalhadas por vários documentos
- Os modelos em nuvem compensam isso com alto desempenho, mas em ambientes locais são necessárias técnicas adicionais
Próximos planos
- O Skald planeja melhorar o desempenho de RAG local e divulgar benchmarks de modelos open source
- O objetivo é oferecer uma solução para empresas que precisam operar ferramentas de IA em ambientes air-gapped
- Quem quiser participar pode colaborar via GitHub(skaldlabs/skald) ou pela comunidade no Slack
7 comentários
De onde surgiu essa ideia absurda de que RAG precisa de um banco de dados vetorial…
Seja vetor DB ou qualquer outra coisa, no fim das contas provavelmente basta implementar apenas a busca...
Gemini:
Sim, no RAG (Retrieval-Augmented Generation), o uso de banco de dados vetorial (Vector Database) teve sua base conceitual estabelecida quando o primeiro artigo relacionado foi publicado em 2020.
O RAG basicamente combina recuperação (Retrieval) e geração (Generation), e nessa etapa de recuperação os embeddings vetoriais e um banco de dados vetorial capaz de armazená-los e consultá-los com eficiência passam a ter um papel essencial.
💡 O ponto de partida do RAG e dos bancos de dados vetoriais
A ideia de que um banco de dados vetorial é necessário no RAG surgiu dos seguintes artigos e conceitos principais.
A razão fundamental pela qual um banco de dados vetorial se tornou um elemento essencial do RAG é a seguinte.
Resumo: por que um banco de dados vetorial é necessário
Para permitir que um LLM acesse conhecimento recente ou específico de um domínio que não foi aprendido no treinamento, é preciso buscar informações com base em similaridade semântica, e não apenas em correspondência de palavras-chave (busca tradicional). O banco de dados vetorial é a tecnologia central que foi naturalmente integrada ao framework RAG para executar com eficiência essa busca baseada em similaridade semântica.
Na verdade, o que o RAG precisa é de funcionalidade de busca, e fazer embedding com vetores densos, enviar para um vectorDB e buscar por similaridade de cosseno é apenas um dos vários jeitos de implementar um mecanismo de busca... não há exatamente um motivo para evitar usar vectorDB, mas, se a pergunta é se ele é realmente indispensável, eu fico meio na dúvida, porque existem muitos algoritmos de busca tradicionais que vêm sendo usados com sucesso há muito tempo.
É barato e a maioria dos LLMs de produção usa isso.
Na real, seguindo essa lógica, até servidor web, se você adicionar funções de infraestrutura, dá para fazer tudo no disco, então também não precisa de DBMS kkk
Está certo dizer que é preciso um banco de dados para fazer uma espécie de busca por similaridade/semântica, usando como chave o valor de embedding (vetor) da query do usuário; e, como a chave está no formato de vetor, um banco de dados vetorial também faz sentido.
Opinião no Hacker News
Ao criar um sistema desses, eu diria para não ficar obcecado com banco de dados vetorial ou embeddings
Busca de texto completo ou ferramentas como
grep/rgsão muito mais rápidas e baratas, e nem exigem manter índicesSe você der ferramentas de busca a um bom LLM, ele consegue montar sozinho consultas como “dog OR canine” e refiná-las iterativamente
Além disso, isso elimina a necessidade de resolver o problema de chunking
Dá para ver em Search Sensei
No primeiro carregamento ele baixa cerca de 50 MB de pesos de modelo e o onnx runtime, mas depois funciona bem
Por exemplo, o BM25 não entende que “j lo” e “jlo” significam Jennifer Lopez, mas a busca baseada em embeddings lida bem com esse tipo de erro de digitação ou apelido
A busca é feita sobre 1.000 notícias de 2016 a 2024
Mas é uma pena que o desempenho do BM25 sozinho não tenha sido divulgado
Nos meus testes pequenos, houve casos em que embeddings deixaram passar páginas contendo exatamente as palavras da consulta — no fim, o Ctrl+F venceu
A busca lexical tem alta precisão e baixa revocação, e a busca semântica fica no ponto oposto
Senti falta de um operador “NOT”. Também quero aprender mais sobre RAG
Já vi algumas ferramentas agentic gerarem essas consultas automaticamente, mas não sei se isso veio do prompt ou se é comportamento padrão
Um dos motivos da baixa performance pode ser a falta de semantic chunking
Se você embutir o documento inteiro, vários conceitos se misturam e a precisão cai
É preciso dividir por unidades de sentido com ferramentas como Spacy e, em seguida, fazer embeddings adicionando em que contexto cada chunk está dentro do documento
A abordagem de contextual retrieval da Anthropic foi muito eficaz em sistemas RAG
Dá para gerar o contexto com o modelo GPT OSS 20B
Acho que houve um mal-entendido porque testamos com perguntas que exigiam agregar contexto de vários documentos
Fico em dúvida sobre por que se pressupõe que busca semântica é superior à busca lexical
Em 2023, quando comparei com Tantivy (BM25), a diferença nos resultados foi mínima
Mesmo que haja algum ganho de revocação, não sei se vale a pena montar toda essa estrutura complexa
Em testes de desenvolvedor tivemos 90% de revocação, mas em testes com usuários reais caiu para algo em torno de 30%
Como os usuários não conheciam os termos exatos dos documentos, só busca lexical não bastava
Dá para colocar um agente por cima, mas a latência aumenta e a satisfação do usuário cai
No Wanderfugl, a busca semântica encontra bem trechos em que a pontuação BM25 é baixa
No fim, a resposta pode ser um ranking híbrido
No fim, depende do caso de uso
Estou procurando uma ferramenta open source para consultar localmente e offline todos os dados de e-mail, Slack, GDrive, código, wiki etc.
Quero evitar construir ou customizar tudo do zero, e seria bom ter bons padrões e recomendações de modelo
Link do GitHub
Ele suporta CRUD por padrão e, se você ativar busca vetorial, faz embeddings de documentos ou notas
Suporta Ollama e OpenAI como provedores de embedding
O servidor MCP oferece tanto busca semântica + BM25 (qdrant fusion) quanto geração de respostas via MCP sampling
O próprio servidor não gera a resposta, então pode ser integrado a qualquer cliente LLM/MCP
Esse padrão de MCP sampling/RAG é muito poderoso, e há boa chance de surgir uma versão open source generalizada para outras fontes de dados
A ferramenta que usamos é haiku.rag
Ela oferece código Python amigável para desenvolvedores, estrutura baseada em pydantic-ai, benchmarks e recursos avançados de citação
Suporta agentes de pesquisa profunda e é um projeto open source de verdade, mantido no longo prazo
Estou usando Sentence Transformers (all-MiniLM-L6-v2) como modelo de embedding padrão, mas percebi que ele é só para inglês, o que pode ser um problema ao criar um RAG em alemão
Fico curioso sobre o desempenho de modelos para idiomas não ingleses
Veja os itens RTEB Multilingual ou RTEB German na seção “Retrieval”
Se você for fazer self-hosting em CPU, é melhor filtrar para modelos com menos de 100M de parâmetros
Mas o alemão tem relativamente muitos dados de treinamento, e também existem modelos multilíngues suficientes
Principalmente os modelos baseados em APIs comerciais quase sempre têm suporte multilíngue
Dá para consultar o artigo relacionado neste link da Springer
Na época do GPT-4 (contexto de 8K), fiz um script que dividia um livro inteiro em chunks e jogava tudo no GPT-4 para buscar trechos relevantes
Naquele tempo, cada busca custava cerca de 1 dólar, mas hoje ficou muito mais barato
No texto sobre contextual retrieval da Anthropic, eles também dizem que, se o documento inteiro couber no contexto, é melhor simplesmente colocá-lo lá em vez de usar RAG
Ainda assim, quando o contexto fica longo, a qualidade cai, e custo e velocidade também viram problema
Hoje já dá para colocar um livro inteiro no contexto por algo no nível de 1 centavo
A parte mais difícil do RAG é parsear documentos
Se for só texto, tudo bem, mas quando há tabelas, tabelas em várias páginas, gráficos, sumário, notas de rodapé etc., a precisão despenca
Para melhorar isso, existe uma abordagem em que o LLM resume e formula perguntas sobre o conteúdo, salvando tudo no banco vetorial, como no padrão RAPTOR
Mesmo assim, ainda é difícil criar um pipeline RAG genérico que funcione para todos os casos
Também fico curioso sobre se bancos vetoriais lidam melhor com grupos longos de texto ou com formato tabular
Achei interessante essa nova perspectiva de aplicar busca de texto completo ao RAG
A visão sobre loops de ferramentas agentic e a forma de lidar com busca fuzzy foi marcante
Fico curioso se existe um dataset de avaliação padronizado para esse tipo de sistema
Seria bom ter um benchmark com conjunto de documentos e perguntas em que um determinado documento ou chunk deveria aparecer como resultado mais relevante