Desenvolvedor cria sistema RAG com modelos locais e aumenta a precisão de busca de 20% para 53%

Desenvolvedor cria sistema RAG com modelos locais e aumenta a precisão

de busca de 20% para 53%

Um desenvolvedor conhecido no GitHub como tzar26 publicou uma análise detalhada do seu sistema de análise de notícias, totalmente autônomo e sem nenhuma chamada a APIs em nuvem como OpenAI ou Anthropic. Todos os modelos rodam localmente via Ollama: Qwen 2.5 14B para raciocínio e classificação, e BGE-M3 para gerar representações vetoriais do texto. O artigo deixa claro o motivo dessa escolha: resiliência contra sanções e independência de provedores externos. O stack resultante — Python, FastAPI, PostgreSQL com a extensão pgvector, Celery para tarefas em segundo plano, LangGraph para o agente e Langfuse para monitoramento — foi empacotado em contêineres Docker e coberto por testes via GitHub Actions.

Por que a busca vetorial comum falhou com homônimos

O sistema reuniu mais de 12.000 artigos e, inicialmente, buscava entre eles apenas por distância de cosseno entre os embeddings do BGE-M3. Em consultas simples tudo funcionava bem, mas temas mais complexos, como "taxa básica do banco central", retornavam resultados sem sentido. O exemplo mais claro foi a busca por "ouro": em vez de notícias sobre o preço do metal, a busca trazia tranquilamente artigos sobre um patinador artístico que ganhou ouro em uma competição — uma confusão clássica causada pelo fato de a palavra ter múltiplos significados, algo que um vetor não distingue pelo contexto.

A solução foi uma busca híbrida: à comparação vetorial se somou uma busca textual precisa com BM25, baseada no PostgreSQL (via tsvector nativo), e os resultados dos dois métodos foram combinados pelo algoritmo RRF (Reciprocal Rank Fusion), que considera a posição de cada documento em cada um dos conjuntos de resultados e calcula um ranking combinado. O BM25 é ótimo para capturar termos exatos como "OPEP" ou "taxa", enquanto a busca vetorial capta sinônimos e relações semânticas. Juntos, eles elevaram a proporção de documentos relevantes entre os cinco primeiros resultados de busca (a métrica Recall@5) de 0,2 para 0,53 — mais do que o dobro.

Como parar de jogar tudo na categoria "outros"

Um problema separado surgiu durante a classificação automática dos artigos por tema. Na primeira versão do prompt, o modelo enviava 74% de todos os artigos para a categoria "outros" (other) — ou seja, quase três quartos da base ficavam sem um rótulo útil. A causa se revelou simples: as instruções continham a frase "em caso de dúvida, escolha outros", e o modelo, com medo de errar, recorria a ela em massa.

O desenvolvedor reescreveu o prompt: adicionou descrições claras para cada categoria, incluindo varejo (retail), macroeconomia (macro) e incidentes (incident), e removeu completamente a frase sobre a dúvida. Depois disso, a proporção de artigos não classificados caiu para 0,03%. Para confirmar que os números eram confiáveis, o autor também revisou manualmente uma amostra aleatória de artigos rotulados — a precisão da classificação ficou em 85%.

Um agente que calcula, não apenas busca

Uma busca comum no banco de dados responde a perguntas como "o que estão escrevendo sobre petróleo", mas isso não basta para análises mais profundas. Por isso, o autor construiu, com LangGraph, um agente com três ferramentas à disposição:

• `search_articles` — busca híbrida de texto padrão
• `get_metrics` — agregação via SQL, por exemplo, contar artigos sobre energia nos últimos três dias
• `search_by_entity` — busca por nomes de empresas extraídos, com o sentimento associado (resultado de modelos separados de NER e análise de sentimento)

Diante de uma pergunta como "há notícias negativas sobre o banco central?", o agente decide por conta própria qual ferramenta acionar — sem que seja necessário indicar explicitamente que ele precisa calcular o sentimento em vez de apenas buscar o texto. Para depurar essa lógica, foi implantada uma instância auto-hospedada do Langfuse, que mostra cada etapa da cadeia — planejador → chamada de ferramenta → resposta final —, quantos tokens foram usados em cada etapa e quais argumentos exatos o modelo passou para as funções.

As dores técnicas de rodar tudo em hardware local

Executar os modelos localmente trouxe seus próprios problemas, atípicos em APIs de nuvem:

• O Ollama descarregava os modelos da memória de vídeo ao alternar entre eles, e uma única requisição podia levar até 60 segundos — resolvido com a variável `OLLAMA_MAX_LOADED_MODELS=2`
• A biblioteca LangChain usa internamente uma agregação de respostas em streaming que causava uma lentidão de até nove vezes — ela foi retirada do pipeline em favor do cliente direto `ollama.AsyncClient`
• O SQLAlchemy vincula o pool de conexões ao event loop, e quando o Celery interrompia uma tarefa, as conexões ficavam "zumbis" — resolvido chamando `await engine.dispose()` após cada tarefa
• Por padrão, o Ollama processa as requisições de forma sequencial; classificar um único artigo levava cerca de 10 segundos, e aumentar o parâmetro `OLLAMA_NUM_PARALLEL` de 1 para 2 acelerou o processo em pelo menos 1,5 vez

O projeto está atualmente em fase de MVP público e disponível no GitHub. O próximo passo, segundo o autor, já está em desenvolvimento de forma reservada: vincular as empresas mencionadas aos tickers da Bolsa de Moscou (como SBER e GAZP) e construir painéis de previsão para ações específicas. Para engenheiros que estão considerando um stack local em vez de APIs em nuvem, a principal conclusão prática é esta: a economia nas chamadas de API é real, mas é preciso pagar por ela com tempo dedicado ao ajuste da infraestrutura — desde configurar o paralelismo do Ollama até lidar com o gerenciamento de conexões em código assíncrono.