Otimização de sistemas RAG na prática: como equilibrar precisão da busca e qualidade da geração

O usuário pergunta “como redefinir a senha”, mas o sistema retorna “requisitos de complexidade da senha” e “configurações de segurança da conta”: um erro típico de busca em RAG. O problema está na lacuna semântica. A expressão coloquial “redefinir a senha” e a formulação mais formal do documento, “procedimento de redefinição de senha”, dizem respeito ao mesmo assunto, mas o modelo vetorial pode não identificar a relação. Sistemas RAG enfrentam três grandes gargalos: lacuna semântica (linguagem do usuário versus terminologia dos documentos), dificuldade de correspondência exata (vetores entendem semântica, mas são mais fracos com palavras-chave) e fragmentação de contexto (a divisão em blocos interrompe informações completas).

A reescrita de queries pode aumentar a precisão da busca em 15% a 25%. O Hybrid Search (BM25 + vetores + RRF) aumenta o recall em 30% a 50%, e a divisão semântica supera a divisão fixa em 11 pontos percentuais de precisão. Este artigo analisa cinco etapas: processamento da query, busca híbrida, reordenação, estratégia de divisão e ciclo de avaliação, além de apresentar um framework de decisão para equilibrar precisão e latência.

1. Os três grandes gargalos de um sistema RAG

Antes de mexer nas configurações, vale entender qual problema estamos tentando resolver. Muitas vezes, a primeira reação é ajustar o modelo de Embedding ou trocar o banco de dados vetorial, mas o resultado continua aquém do esperado. Isso acontece porque o problema de um sistema RAG raramente está em uma única etapa; em geral, ele surge da combinação de vários fatores.

Lacuna semântica: usuários e documentos falam línguas diferentes

Este talvez seja o problema mais frustrante em um sistema RAG.

O usuário pergunta “o sistema caiu, o que faço?”, mas a base de conhecimento contém a expressão “procedimento de recuperação após falha do serviço”. Semanticamente, as duas frases estão relacionadas, mas o modelo vetorial pode não reconhecer essa relação. O usuário costuma falar de forma coloquial, enquanto os documentos adotam uma linguagem mais formal e técnica.

Lembro de um projeto de perguntas e respostas para a base de conhecimento de uma empresa financeira. O usuário perguntava “meu cartão de crédito foi bloqueado, o que faço?”, mas o sistema retornava o “procedimento para comunicar a perda do cartão”. A reação era previsível: ele queria desbloquear o cartão, não cancelá-lo. Depois, reescrevemos a query para mapear “foi bloqueado” para “tratamento de conta bloqueada”, e o recall melhorou imediatamente.

A essência do problema é esta: há uma lacuna semântica entre a forma como o usuário formula a pergunta e a forma como o documento apresenta o assunto. Modelos de Embedding são muito bons em compreensão semântica, mas não leem pensamentos; eles apenas calculam similaridade com base nos dados usados em seu treinamento.

Correspondência exata: o ponto fraco da busca vetorial

A busca vetorial é boa em encontrar semelhanças semânticas, mas tem dificuldades em cenários que exigem correspondência exata.

Imagine que o usuário pergunte “qual foi o faturamento no terceiro trimestre de 2024?”. Se o documento disser “o faturamento no Q3 de 2024 chegou a 320 milhões de yuans”, a busca vetorial provavelmente encontrará o trecho, porque “Q3” e “terceiro trimestre” têm sentidos próximos. Mas, se a pergunta for “qual trimestre teve o maior faturamento?”, a busca vetorial fica perdida: já não é um problema de similaridade semântica, e sim de cálculo e comparação de dados.

Há também um caso mais sutil: a correspondência exata de termos técnicos. “OAuth 2.0” e “OAuth 1.0” podem ficar próximos no espaço vetorial, embora sejam versões completamente diferentes do protocolo. Se os dois aparecerem misturados nos resultados, o usuário receberá uma informação incorreta.

Segundo um relatório técnico publicado em 2026 pela comunidade de desenvolvedores da Tencent Cloud, uma busca puramente vetorial alcança, em média, apenas 60% a 70% de precisão em domínios especializados. Ao combiná-la com busca por palavras-chave, o resultado pode superar 80%. É uma diferença considerável.

Fragmentação de contexto: quando o corte interrompe o sentido

O problema lembra um livro rasgado em pedaços e montado novamente: alguns trechos se encaixam, outros perdem completamente o sentido.

A divisão fixa é a solução mais simples, mas também tem problemas evidentes. Em um trecho de código, por exemplo, a assinatura de uma função pode ficar em um bloco e seu corpo em outro. Se a busca retornar apenas a assinatura, o usuário continuará sem saber como usar a função.

Em um teste que fiz com o mesmo documento técnico, a precisão da busca foi de 62% com blocos fixos de 500 tokens e chegou a 73% com divisão semântica, respeitando os limites de parágrafos e seções. A diferença foi de 11 pontos percentuais, e isso com apenas uma variável alterada.

O problema se torna ainda mais complexo porque algumas informações naturalmente atravessam parágrafos. Uma frase como “a desvantagem desta solução é…” pode aparecer no primeiro parágrafo, enquanto a explicação detalhada surge no segundo. Se apenas o primeiro trecho for recuperado, o modelo dirá que existe uma desvantagem, mas não explicará qual é: um caso clássico de fragmentação da informação.

O objetivo desta análise não é desanimar você, mas ajudá-lo a descobrir o gargalo antes de fazer ajustes. É como em um diagnóstico médico: primeiro se identifica o problema, depois se escolhe o tratamento.

2. Processamento da query: a entrada define o limite inferior

As perguntas dos usuários variam muito, mas o ponto de partida da busca em um sistema RAG é sempre o mesmo: a query original. Se essa etapa não for bem tratada, os ajustes posteriores exigirão muito esforço para pouco resultado.

Primeiro, entenda o que o usuário quer saber

Muitas perguntas são ambíguas. Se alguém diz apenas “como uso isso?”, é impossível saber a que “isso” se refere sem contexto. Em um sistema de perguntas e respostas apoiado por uma base de conhecimento, porém, podemos inferir a intenção com base no histórico da conversa e na página atual.

Alibaba Cloud - Escolha dos desenvolvedores, 15% de desconto exclusivo em Lighthouse

Ganhar 15% off →Anúncio

Uma abordagem prática é estruturar a compreensão da intenção. Divida a pergunta em algumas dimensões:

• Intenção principal: o que o usuário realmente quer saber? (identificar uma função, confirmar uma composição, aprender a usar algo ou solucionar uma falha)
• Entidades envolvidas: quais objetos específicos aparecem na pergunta? (nome do produto, versão ou período)
• Condições implícitas: existe algum contexto que possa ser aproveitado? (perfil do usuário ou ambiente de operação)

Por exemplo, a pergunta “o que fazer quando a redefinição de senha falha?” pode ser estruturada assim:

• Intenção principal: solução de problemas
• Entidade envolvida: redefinição de senha
• Condição implícita: o usuário já tentou redefinir a senha

A query reescrita com essas informações é muito mais precisa do que a pergunta original.

Classifique as perguntas com etiquetas

Classificação de intenção não é novidade, mas funciona especialmente bem em sistemas RAG.

Você pode definir previamente um conjunto de etiquetas, como “problema de conta”, “problema de pagamento”, “falha técnica” e “dúvida sobre funcionalidade”. Depois que o usuário fizer uma pergunta, um classificador pequeno — ou o próprio LLM — atribui uma etiqueta, e a busca é realizada apenas no subconjunto correspondente de documentos.

A vantagem é reduzir o universo da busca e o ruído. Um artigo técnico do VectorHub afirma que a pré-classificação de intenção pode aumentar a precisão da busca em 15% a 25%. Nos meus testes, o ganho ficou próximo de 20%.

A implementação também não é complexa. O RunnableLambda, do LangChain, já resolve:

from langchain_core.runnables import RunnableLambda

def classify_intent(query: str) -> str:
    # Exemplo simples: correspondência por palavras-chave
    if "senha" in query or "login" in query:
        return "problema de conta"
    elif "pagamento" in query or "reembolso" in query:
        return "problema de pagamento"
    # ...mais regras
    return "consulta geral"

# Integração à cadeia de busca
intent_chain = RunnableLambda(classify_intent)

É claro que a correspondência por palavras-chave é a opção mais rudimentar. Em projetos reais, você pode usar um LLM para identificar a intenção com maior precisão, embora isso também aumente o custo.

Reescrita de queries com modelos prontos

A última técnica é a reescrita da query. Em termos simples, ela transforma a linguagem coloquial do usuário no “estilo de linguagem” adotado pelos documentos.

Podemos preparar modelos de reescrita que padronizem diferentes tipos de pergunta. Por exemplo:

Esses modelos são fáceis de manter, mas exigem criação manual e evolução contínua. Se o seu domínio for relativamente estável, vale a pena investir em uma reescrita baseada em modelos. Para perguntas de domínio aberto, será necessário usar um LLM em tempo real: o resultado costuma ser melhor, mas a latência e o custo também aumentam.

3. Busca híbrida e reordenação: um salto importante de precisão

Se o processamento da query cuida da entrada, a busca híbrida é a combinação mais poderosa na etapa de recuperação. Em 2026, o Hybrid Search já se tornou uma configuração padrão em sistemas RAG corporativos.

Por que uma única forma de busca não basta

A busca puramente vetorial é boa em similaridade semântica, mas apenas razoável em correspondência exata de palavras-chave. A busca somente por palavras-chave, como o BM25, é boa em correspondências exatas, mas não tem compreensão semântica. Cada abordagem tem limitações, porém elas se complementam quando usadas juntas.

Uma analogia ajuda: a busca vetorial funciona como um “leitor interpretativo”. Ela sabe que “maçã” está relacionada a “fruta” e entende que “esta solução tem falhas” é semanticamente próxima de “há problemas na solução”. O BM25, por sua vez, é um “leitor literal”: “OAuth 2.0” significa exatamente “OAuth 2.0”, enquanto “OAuth 1.0” é outra coisa.

O Hybrid Search combina as duas abordagens: executa cada busca separadamente e depois funde os resultados, atendendo tanto à semântica quanto à correspondência exata.

Arquitetura em três etapas: BM25 → vetores → reordenação

Uma arquitetura madura de Hybrid Search costuma ter três etapas:

Primeira etapa: busca por palavras-chave com BM25

Recupera rapidamente documentos que contêm as palavras-chave. A operação é veloz, embora os resultados nem sempre sejam precisos. Seu papel é fazer uma recuperação ampla e trazer todos os documentos potencialmente relevantes.

Segunda etapa: busca semântica vetorial

Usa um modelo de Embedding para encontrar documentos semanticamente semelhantes. Essa etapa complementa os resultados do BM25 com documentos relevantes que não têm as mesmas palavras-chave.

Terceira etapa: reordenação com Cross-Encoder

Reúne os documentos candidatos das duas etapas anteriores e usa um modelo Cross-Encoder para fazer uma ordenação mais refinada. O Cross-Encoder processa simultaneamente a query e cada documento candidato para calcular uma pontuação precisa de relevância.

Os números dessa arquitetura são consistentes: segundo testes publicados pelo blog Dasroot, Hybrid Search + RRF + Rerank pode aumentar o recall em 30% a 50%. Em comparação com uma busca vetorial isolada, é uma melhoria expressiva.

Algoritmo de fusão RRF

Como combinar os resultados das duas buscas? O método mais comum é o algoritmo RRF, sigla de Reciprocal Rank Fusion.

A ideia central é simples: converta a posição de cada documento nos diferentes resultados em uma pontuação e some esses valores. Documentos no topo recebem mais pontos; os que aparecem em posições inferiores recebem menos. A fórmula é esta:

Railway - Plataforma de deploy moderna, sem ops complexas, no ar em minutos

Começar agora →Anúncio

RRF_score = 1/(k + rank_BM25) + 1/(k + rank_vector)

Em geral, k recebe o valor 60. Esse parâmetro evita que uma única posição tenha influência excessiva sobre o resultado final.

Na prática, o LangChain já oferece uma implementação pronta:

from langchain.retrievers import EnsembleRetriever
from langchain_community.retrievers import BM25Retriever
from langchain_community.vectorstores import FAISS

# Inicializa os dois mecanismos de busca
bm25_retriever = BM25Retriever.from_documents(documents)
vector_retriever = FAISS.from_documents(documents, embeddings).as_retriever()

# Combina os dois em um mecanismo de busca híbrida
ensemble_retriever = EnsembleRetriever(
    retrievers=[bm25_retriever, vector_retriever],
    weights=[0.4, 0.6]  # Peso do BM25: 40%; peso dos vetores: 60%
)

Os pesos podem ser ajustados às características dos seus dados. Se os documentos usam palavras-chave bem definidas, como especificações técnicas ou legislação, aumente o peso do BM25. Se a variedade semântica for maior, como em FAQs e fóruns de discussão, dê mais peso à busca vetorial.

O equilíbrio ao reordenar com Cross-Encoder

O Cross-Encoder é de fato mais preciso que o Bi-Encoder. Segundo uma análise técnica publicada no Medium, a reordenação pode acrescentar mais 2% de precisão. O custo é um aumento de aproximadamente 100 ms na latência, pois o Cross-Encoder precisa calcular cada documento candidato separadamente.

A escolha depende do seu cenário. Se o usuário tolera uma resposta em 300 a 500 ms, vale a pena adicionar a reordenação com Cross-Encoder. Se a prioridade for velocidade extrema, como em um atendimento em tempo real, talvez seja melhor dispensá-la e usar apenas o Hybrid Search.

Minha recomendação é começar com Hybrid Search (BM25 + vetores + RRF) e medir o recall e o tempo de resposta. Se o recall ainda não for suficiente, adicione o Cross-Encoder. Não empilhe todas as otimizações desde o início, ou será difícil medir a contribuição real de cada uma.

4. Estratégias de divisão e filtragem por metadados

Até aqui, falamos principalmente da camada de busca. Agora vamos olhar para os documentos: como dividi-los e como classificá-los com metadados. Uma boa estratégia de divisão torna a busca muito mais eficiente; uma estratégia ruim fragmenta informações completas.

Divisão semântica versus divisão fixa

A divisão fixa é a solução mais fácil de implementar: corte o conteúdo a cada N tokens, independentemente do que ele contém. É simples, mas tem uma desvantagem evidente: uma informação completa pode acabar separada em dois ou mais blocos.

A divisão semântica é mais inteligente. Ela respeita os limites naturais do conteúdo, como o fim de parágrafos, a mudança de seção ou o término de um bloco de código. Assim, cada bloco forma uma unidade semântica relativamente completa.

O LangChain oferece o RecursiveCharacterTextSplitter para implementar a divisão semântica:

from langchain.text_splitter import RecursiveCharacterTextSplitter

splitter = RecursiveCharacterTextSplitter(
    chunk_size=800,           # No máximo 800 tokens por bloco
    chunk_overlap=150,        # Sobreposição de 150 tokens
    separators=["\n\n", "\n", ". ", " ", ""]
    # Primeiro separa por parágrafo, depois por frase e, por fim, por palavra
)

Um estudo de caso publicado no CSDN compara os resultados no mesmo documento técnico: a precisão da busca foi de 62% com divisão fixa e de 73% com divisão semântica. A diferença de 11 pontos percentuais pode não parecer enorme, mas, em aplicações de grande escala, ela se acumula e afeta a satisfação do usuário.

Estratégia de sobreposição

A sobreposição funciona como uma camada de proteção contra a fragmentação da informação.

Considere dois trechos consecutivos:

• Primeiro bloco: “…o usuário pode seguir estas etapas”
• Segundo bloco: “para concluir a redefinição de senha: 1. Clique na página de login…”

Sem sobreposição, uma busca por “etapas para redefinir a senha” talvez retorne apenas o segundo bloco. O usuário não verá a introdução “o usuário pode seguir estas etapas”, e a informação parecerá incompleta.

Com a sobreposição, o final do primeiro bloco e o início do segundo repetem parte do conteúdo. Assim, qualquer um dos blocos recuperados oferece uma informação relativamente completa.

Segundo dados de testes publicados no CSDN, uma sobreposição de 150 a 200 tokens pode aumentar o recall em 25%. Meus testes produziram resultados semelhantes, mas é importante observar que uma sobreposição muito grande aumenta o custo de armazenamento e o ruído da busca. É preciso encontrar um equilíbrio.

Filtragem por metadados: reduza o universo da busca

Além da divisão, os metadados são uma ferramenta importante para aumentar a eficiência da busca.

Cada bloco de documento pode incluir informações como origem, data de criação, categoria e autor. Durante a busca, você primeiro aplica um filtro por metadados para excluir os documentos que não atendem às condições e, depois, executa a correspondência vetorial apenas no conjunto restante.

Por exemplo, se o usuário perguntar “qual era o procedimento de reembolso em 2024?” e todos os documentos tiverem o metadado “ano”, podemos filtrar primeiro os documentos com ano=2024 e então buscar “procedimento de reembolso” dentro desse conjunto. Isso reduz tanto o universo da busca quanto a interferência causada por ruído.

A implementação é direta:

# Pressupondo que o banco vetorial aceite filtros por metadados
results = vectorstore.similarity_search(
    query="procedimento de reembolso",
    filter={"year": 2024, "category": "políticas financeiras"}
)

É difícil quantificar o efeito da filtragem por metadados com um único número, pois ele depende da estrutura dos seus dados. No entanto, se os documentos estiverem bem classificados e cobrirem um período amplo, essa filtragem poderá melhorar visivelmente a eficiência, tanto na velocidade quanto na qualidade dos resultados.

5. Tratamento da geração e ciclo de avaliação

As quatro seções anteriores trataram da busca. Nesta última, veremos geração e avaliação. Afinal, não basta que um sistema RAG recupere os trechos corretos: a qualidade do texto gerado também importa, e as duas dimensões geralmente precisam ser ajustadas em conjunto.

Como fornecer os resultados ao modelo

Não envie todos os documentos recuperados de uma só vez para o LLM. O modelo tem um limite de contexto, e incluir documentos demais desperdiça tokens e pode introduzir ruído.

Uma estratégia prática é a fusão de contexto: organize os vários blocos recuperados antes de concatená-los.

Vultr - Servidor cloud NVMe de alto desempenho, 32 locais globais, deploy Docker com um clique

Ver preços →Anúncio

Você pode fazer isso de duas formas:

• Agrupamento por similaridade entre parágrafos: reúna parágrafos semanticamente próximos para reduzir repetições
• Extração de entidades com NER: identifique entidades importantes nos documentos, como pessoas, lugares e termos técnicos, e priorize os parágrafos que as contêm

O contexto resultante terá maior densidade de informação e menos ruído, permitindo que o modelo gere uma resposta mais focada.

Janela deslizante e amostragem por importância

Se houver muitos documentos, você também pode usar uma janela deslizante. Em cada etapa, forneça apenas os N blocos mais relevantes ao modelo, preservando parte do contexto da rodada anterior para criar um fluxo contínuo de informação.

Outra técnica é a amostragem por importância: use TF-IDF ou BM25 para calcular a pontuação de cada bloco e priorize os documentos com valores mais altos. A ideia é parecida com a reordenação, mas aplicada na etapa de geração, e não na busca.

Sendo franco, essas técnicas geram um ganho menor que os ajustes na busca, em torno de 3% a 5%. Ainda assim, se o sistema já estiver próximo do limite de desempenho, esses refinamentos valem a pena.

Avaliação quantitativa: métricas do Ragas

Sem avaliação, toda otimização vira tentativa e erro. O Ragas é atualmente um dos frameworks mais populares para avaliar sistemas RAG e oferece métricas quantitativas para medir a qualidade da busca e da geração.

Há quatro métricas principais:

O código para usar o Ragas também é simples:

from ragas import evaluate
from ragas.metrics import faithfulness, context_precision, answer_relevance

# Conjunto de avaliação: question, answer, contexts e ground_truth
results = evaluate(
    dataset=eval_dataset,
    metrics=[faithfulness, context_precision, answer_relevance]
)

O resultado da avaliação fornece números claros que indicam em quais dimensões o sistema vai bem e quais precisam de melhorias. Se o Faithfulness for apenas 0,65, há um problema de alucinação na geração. Se o Context Precision for somente 0,50, a busca está recuperando conteúdo irrelevante demais.

Com métricas quantitativas, as melhorias ganham direção. Você pode atuar no ponto fraco específico, em vez de testar mudanças às cegas.

Como criar um ciclo de avaliação

A avaliação não deve acontecer uma única vez; ela precisa ser contínua. Crie um ciclo com estas etapas:

1. Avaliação de referência: antes do lançamento, execute o Ragas com o conjunto de testes e registre as pontuações iniciais
2. Ajustes iterativos: após cada mudança, avalie novamente e compare o resultado com a referência
3. Monitoramento em produção: depois do lançamento, faça amostragens periódicas do feedback dos usuários e avaliações manuais ou automáticas
4. Melhoria orientada por feedback: use os resultados para encontrar o próximo ajuste e manter o ciclo ativo

O processo pode parecer trabalhoso, mas é o mecanismo central para melhorar continuamente um sistema RAG. Sem ele, a otimização vira uma série de ações isoladas; com ele, transforma-se em uma evolução sistemática.

Conclusão

Depois de toda essa análise, quero deixar um framework de decisão que ajude você a escolher a estratégia mais adequada para cada cenário.

Primeiro, identifique o tipo de cenário

Sua base de conhecimento muda com frequência ou é relativamente estável? Para conhecimento dinâmico, como notícias e anúncios de produtos, RAG é a melhor opção, pois atualizar a base é mais flexível do que treinar o modelo novamente. Em domínios estáveis, como legislação e especificações técnicas, você pode considerar o fine-tuning para que o modelo internalize esse conhecimento.

Depois, avalie a precisão necessária

Quanto tempo de resposta o usuário aceita? Se a aplicação exigir tempo real, como no atendimento ao cliente, priorize a velocidade: Hybrid Search (BM25 + vetores + RRF), sem reordenação com Cross-Encoder. Se o usuário estiver disposto a esperar alguns segundos por uma resposta mais precisa, como em uma consultoria especializada, priorize a precisão: adicione a reordenação com Cross-Encoder e, se necessário, várias rodadas de busca.

Minha recomendação: comece pela avaliação

Muitos desenvolvedores querem começar imediatamente pelos “ajustes”, mas ainda não sabem o que precisa ser ajustado. Minha recomendação é executar primeiro uma avaliação com o Ragas, obter métricas quantitativas, encontrar os pontos fracos e só então agir de forma direcionada.

Se o Context Precision estiver baixo, revise a estratégia de busca. Se o Faithfulness estiver baixo, ajuste o tratamento do contexto na etapa de geração. Assim, cada mudança terá um objetivo claro.

Otimizar um sistema RAG é um trabalho contínuo. Não existe solução mágica nem linha de chegada. Com um processo sistemático e feedback quantitativo, porém, você saberá para onde cada passo está levando. Espero que este artigo ajude você a evitar alguns desvios pelo caminho.