RAG avançado e agêntico
Query rewriting, HyDE, multi-query e quando o agente decide como recuperar.
6 min de leitura
Escolha como aprender
combine como quiserDica: o vídeo é um resumo visual rápido; o áudio e o texto trazem a aula completa. Terminar o áudio ou o vídeo, ou passar no quiz, já conta a aula como concluída.
RAG básico funciona bem quando o usuário sabe exatamente o que quer e escreve isso de forma limpa. Na prática, isso raramente acontece. Perguntas são vagas, incompletas ou mal formuladas, e o pipeline ingênuo devolve lixo com confiança. As técnicas desta lição existem para resolver exatamente esse problema: deixar a recuperação mais robusta antes mesmo de o LLM gerar a resposta final.
Reescrita de query: consertar a pergunta antes de buscar
O usuário digita: "e o prazo?". Sem contexto, esse fragmento não encontra nada útil no índice vetorial. A reescrita de query usa um LLM para transformar a pergunta original em algo que o sistema de busca consegue processar bem.
A ideia é simples: antes de ir ao vector store, você passa a query por um prompt que pede ao modelo para reescrevê-la de forma mais explícita, completa e desambiguada. Se houver histórico de conversa, ele é incluído no contexto, o modelo infere que "o prazo" se refere ao contrato discutido dois turnos atrás e gera "qual é o prazo de entrega previsto no contrato de fornecimento mencionado?".
Na AWS, isso pode ser uma chamada InvokeModel ao Bedrock (Claude Haiku ou Titan Text Lite são baratos o suficiente para esse passo) antes de consultar o OpenSearch ou o Knowledge Bases. O custo extra é baixo; o ganho de precisão costuma ser alto.
Um cuidado: reescrita pode alterar a intenção se o prompt não for cuidadoso. Teste com exemplos reais do seu domínio. Se o modelo estiver reescrevendo demais, adicionando suposições que o usuário não fez, reduza a temperatura e seja mais diretivo no prompt de reescrita.
Multi-query e HyDE: atacar o índice de ângulos diferentes
Multi-query é a ideia de que uma pergunta pode ser reformulada de várias formas legítimas, e cada formulação pode recuperar chunks diferentes. Você pede ao LLM para gerar N variações da query original (tipicamente 3 a 5), executa cada uma no vector store em paralelo, une os resultados e remove duplicatas. O reranker da lição 05 entra aqui para ordenar o conjunto final antes de enviar ao LLM.
O ganho é real: variações capturam sinônimos, perspectivas e níveis de abstração que a query original não cobria. O custo é proporcional ao número de buscas, planeje isso.
HyDE (Hypothetical Document Embeddings) é mais elegante e um pouco contraintuitivo. Em vez de buscar pela pergunta, você pede ao LLM para inventar uma resposta hipotética plausível, sem acesso ao índice, só com o conhecimento paramétrico do modelo. Depois, você embute essa resposta hipotética e usa o vetor dela para buscar no índice.
A intuição: documentos reais se parecem mais com outros documentos do que com perguntas. O embedding de uma resposta hipotética fica mais próximo dos chunks relevantes no espaço vetorial do que o embedding da pergunta original. Funciona especialmente bem quando o vocabulário da pergunta difere muito do vocabulário dos documentos, por exemplo, perguntas coloquiais sobre documentos técnicos.
Na prática, reescrita de query é quase sempre vale, o custo é mínimo e o ganho em conversas multi-turno é imediato. Multi-query eu uso quando o domínio tem vocabulário rico e inconsistente (ex.: documentos jurídicos ou médicos com muitos sinônimos). HyDE eu reservo para casos onde a query do usuário é muito curta ou coloquial e os documentos são densos e técnicos, é a técnica com maior potencial de ganho, mas também a mais sensível à qualidade do LLM hipotético. Se o modelo alucinar na resposta hipotética, o vetor gerado vai buscar lixo com precisão cirúrgica.
Loop do RAG Agêntico: decidir → buscar → avaliar → responder
O agente controla o loop: decide se precisa buscar, qual ferramenta usar, avalia se os chunks recuperados são suficientes e repete se necessário, antes de gerar a resposta final.
- Agente LLM · Raciocínio + Planejamento
- Decidir · Buscar? Qual fonte?
- Avaliar chunks · Suficientes? Relevantes?
- Reescrita / Multi-query · Query transformation
- Vector Store · OpenSearch / KB
- Reranker · Ordenar chunks
- Resposta Final · com citações
RAG agêntico: quando o sistema decide como recuperar
Nas técnicas anteriores, o pipeline ainda é fixo: query entra, chunks saem, LLM gera. O RAG agêntico quebra esse fluxo linear. Aqui, um agente LLM recebe a pergunta e decide o que fazer: buscar agora? Em qual fonte? Com qual estratégia? Os chunks recuperados são suficientes ou precisa de mais uma rodada?
O diagrama acima mostra o loop central: o agente raciocina, decide buscar, transforma a query, recupera, avalia a qualidade dos chunks e só então gera, ou repete o ciclo se os resultados forem insuficientes.
Isso habilita comportamentos que o RAG linear não consegue:
- Perguntas compostas: "compare a política de reembolso dos planos A e B", o agente faz duas buscas separadas e sintetiza.
- Refinamento iterativo: se os primeiros chunks não cobrem a pergunta, o agente reformula e busca de novo.
- Roteamento de fonte: o agente escolhe entre buscar no vector store, chamar uma API externa ou usar conhecimento paramétrico direto.
Na AWS, isso se implementa com Bedrock Agents: você registra as ferramentas de busca como action groups, e o modelo (Claude, por padrão) decide quando e como chamá-las. A lição 09 entra em detalhe sobre Knowledge Bases integradas a agentes. A lição 07 aqui cobre o raciocínio por trás do loop; a implementação concreta vem depois.
O ponto crítico: agentes adicionam latência e custo por design. Cada iteração do loop é uma chamada ao LLM. Para perguntas simples e diretas, RAG linear com boa reescrita de query é mais rápido, mais barato e igualmente eficaz.
Técnicas avançadas de recuperação: comparação rápida
| Técnica | Quando usar | Custo extra | Risco principal |
|---|---|---|---|
| Reescrita de query | Conversas multi-turno, queries vagas | Baixo (1 chamada LLM leve) | Alteração de intenção se prompt ruim |
| Multi-query | Domínio com vocabulário rico e inconsistente | Médio (N buscas paralelas) | Ruído se variações forem irrelevantes |
| HyDE | Queries coloquiais, docs técnicos densos | Médio (1 geração + 1 embedding) | Alucinação na resposta hipotética |
| RAG Agêntico | Perguntas compostas, múltiplas fontes, refinamento iterativo | Alto (múltiplas chamadas LLM) | Latência e custo imprevisíveis sem limites de loop |
Técnicas de recuperação avançada
Toque num conceito e depois na definição.
O que levar desta lição
Como introduzir técnicas avançadas de forma incremental
- 1
Comece com RAG linear e meça
Antes de adicionar qualquer técnica avançada, estabeleça uma baseline de avaliação (faithfulness, relevância, lição 08). Você precisa saber o que está melhorando.
- 2
Adicione reescrita de query primeiro
É a técnica de menor risco e maior retorno imediato. Implemente como um passo de pré-processamento antes da chamada ao vector store. Meça o impacto nas suas métricas de avaliação.
- 3
Experimente multi-query se o vocabulário for o problema
Se a análise de falhas mostrar que o sistema não encontra chunks relevantes porque o usuário usa termos diferentes dos documentos, multi-query é o próximo passo natural.
- 4
Considere HyDE para queries muito curtas ou coloquiais
Teste HyDE em um subconjunto do seu dataset de avaliação. Compare precision@k antes e depois. Se não houver ganho mensurável, não adicione a complexidade.
- 5
Migre para RAG agêntico apenas quando o pipeline linear não for suficiente
Perguntas compostas, múltiplas fontes e refinamento iterativo são os sinais claros. Implemente com Bedrock Agents, defina limites de loop e monitore custo por sessão desde o dia um.
Perguntas frequentes
HyDE não vai alucinar e trazer chunks errados?
Pode sim. A resposta hipotética não precisa ser factualmente correta, ela só precisa estar no mesmo espaço semântico dos documentos relevantes. Mas se o modelo alucinar de forma selvagem (inventar termos, conceitos ou entidades que não existem nos documentos), o vetor gerado vai buscar lixo. Por isso HyDE funciona melhor em domínios onde o LLM tem algum conhecimento paramétrico do assunto, mesmo que incompleto.
Posso combinar reescrita + multi-query + reranker?
Sim, e é uma combinação comum em produção. A ordem natural é: reescrita → multi-query → busca paralela → merge → reranker → LLM. O reranker é especialmente valioso aqui porque o conjunto de chunks merged pode ser grande e ruidoso.
RAG agêntico com Bedrock Agents tem suporte nativo a Knowledge Bases?
Sim. Você pode associar um Knowledge Base diretamente a um Bedrock Agent como fonte de conhecimento. O agente decide automaticamente quando consultar o KB com base no raciocínio do modelo. A lição 09 cobre isso em detalhe.
Como evitar loops infinitos em RAG agêntico?
Defina explicitamente um max_iterations no seu agente. No Bedrock Agents, isso é configurável. Além disso, monitore o número médio de iterações por sessão, se estiver crescendo, o agente está tendo dificuldade em satisfazer as perguntas e você precisa revisar as ferramentas disponíveis ou o prompt do sistema.