Padrões avançados — Graph RAG, Agentic RAG, multi-hop

TL;DR

RAG vanilla resolve ~80% dos casos. Para os 20% restantes, padrões avançados: Multi-hop RAG (resposta requer juntar 2+ chunks via passos sequenciais), Graph RAG (Microsoft, indexa entidades e relações em knowledge graph para queries complexas), Agentic RAG (agent decide iterativamente quando/o que buscar) e Vectorless / Tree RAG (PageIndex, navegação hierárquica por documento). Custo cresce significativamente — só use quando RAG simples falha. Default: tente Hybrid + Rerank antes de partir para complexidade.

Quando RAG vanilla falha

Sintomas que indicam padrão avançado:

  • Pergunta requer juntar 2+ chunks de docs diferentes (multi-hop)
  • Pergunta sobre relacionamentos (“quais empresas são fornecedoras de X que estão na Europa?“)
  • Pergunta exige exploração (“encontre todos os pacientes com sintoma Y após 2024”)
  • Single retrieval não cobre mesmo com hybrid+rerank
  • Documento é longo e estruturado, mas chunking destrói a hierarquia (contratos, relatórios, manuais)

Multi-hop RAG

Pergunta que requer N retrievals sequenciais, onde cada retrieval usa info do anterior.

Q: "Em qual empresa trabalha o autor do paper X de 2024?"

Hop 1: encontre paper X de 2024 → "autor: Maria Silva"
Hop 2: encontre info sobre "Maria Silva" → "trabalha em Empresa Y"
A: "Empresa Y"

Vanilla RAG falha porque:

  • Top-k do “paper X” tem o autor, mas não a empresa
  • Top-k do “Maria Silva” pode não estar relacionado se a query inicial é sobre paper

Implementação

Padrão decomposition:

def multi_hop_rag(question):
    # 1. Decompor em sub-questions
    sub_qs = llm.decompose(question)
    # ["Quem é autor do paper X?", "Onde trabalha esse autor?"]
 
    answers = []
    for sub_q in sub_qs:
        # 2. RAG normal em cada sub-question
        chunks = retrieve(sub_q)
        answer = generate(sub_q, chunks)
        answers.append(answer)
 
        # 3. Próxima sub-question pode usar answer anterior
        sub_q_next = llm.refine(sub_q_next, previous_answer=answer)
 
    # 4. Sintetizar
    return llm.synthesize(question, answers)

Padrão self-ask (mais elegante):

Q: Em qual empresa trabalha autor do paper X?
Self-ask: Quem é o autor do paper X?
[retrieve...]
Self-answer: Maria Silva.
Self-ask: Onde trabalha Maria Silva?
[retrieve...]
Self-answer: Empresa Y.
Final: Empresa Y.

Custo

3-5x query single. Latência multiplicada. Use só quando necessário.

Graph RAG (Microsoft GraphRAG)

Em vez de chunks soltos, knowledge graph de entidades e relações.

graph LR
    A["Maria Silva"] -->|"autor de"| B["Paper X"]
    A -->|"trabalha em"| C["Empresa Y"]
    C -->|"localizada em"| D["São Paulo"]
    B -->|"publicado em"| E["2024"]

Como funciona

Indexing:

  1. Parse docs e extrai entidades (NER + LLM)
  2. Extrai relações entre entidades
  3. Constrói grafo
  4. Cluster por communities (Leiden algorithm)
  5. Sumariza cada community

Query:

  1. Pergunta → identifica entidades mencionadas
  2. Localiza no grafo
  3. Expande N hops a partir das entidades
  4. Recupera community summaries relevantes
  5. Genera resposta

Quando usar Graph RAG

✅ Domínio com entidades e relações claras (legal, medical, scientific, business intelligence) ✅ Queries comparativas ou agregativas ✅ Dataset ≥1000 documentos com riqueza relacional

❌ Texto livre sem entidades (literatura, opiniões) ❌ Dataset pequeno (overhead não compensa) ❌ Time sem expertise em knowledge graphs

Tools

  • Microsoft GraphRAG — implementação oficial open source
  • Neo4j + LLM — knowledge graph clássico
  • LlamaIndex KnowledgeGraphIndex — building block
  • Graphiti (Zep) — temporal knowledge graph

Agentic RAG

Agent decide quando e o quê buscar — em vez de pipeline fixo.

# Pipeline fixo (vanilla)
chunks = retrieve(query)
answer = generate(query, chunks)
 
# Agentic
agent = Agent(tools=[search, expand_search, read_doc])
answer = agent.run(query, max_steps=10)
# Agent decide: buscar primeiro? expandir? ler doc específico?

Vantagens

  • Adapta a queries de complexidade variável
  • Pode “perceber” que precisa buscar mais
  • Permite refinamento iterativo
  • Multi-hop natural

Desvantagens

  • Custo alto (múltiplos LLM calls)
  • Latência alta (não é one-shot)
  • Difícil de debugar
  • Pode entrar em loops

Quando usar

✅ Queries variadas (alguns simples, outros complexos) ✅ Resultados podem ser refinados iterativamente ✅ Time tem expertise com agents (Anatomia de Agents)

❌ Queries sempre similares (pipeline fixo é mais barato) ❌ Latência crítica ❌ Compliance exige resposta determinística

Detalhes em 06 - Dynamic retrieval beyond RAG.

Vectorless / Tree RAG (PageIndex)

Em documentos longos e estruturados, a falha nem sempre é “preciso de mais embeddings”; muitas vezes é “o chunking destruiu o mapa do documento”. PageIndex organiza o documento como uma árvore tipo table of contents e usa o LLM para navegar essa árvore por raciocínio. A pergunta deixa de ser “quais chunks são parecidos com a query?” e vira “qual ramo do documento contém a informação relevante?“.

graph TD
    D[Documento longo] --> A[Capítulo A]
    D --> B[Capítulo B]
    B --> B1[Seção B.1]
    B --> B2[Seção B.2]
    B2 --> P[Páginas relevantes]

Quando usar

✅ PDFs longos com estrutura real (financeiro, jurídico, regulatório, acadêmico, manuais técnicos) ✅ Citação por página/seção importa ✅ Similaridade vetorial traz trechos parecidos mas não decisivos ✅ Corpus controlado onde operar uma árvore por documento é aceitável

❌ Corpus enorme de snippets curtos ❌ Conteúdo sem hierarquia ❌ Latência crítica ❌ Quando o problema é memória conversacional, não retrieval documental

Detalhes em 13 - PageIndex — RAG vectorless por árvore de documentos.

Comparativo de custo

Vanilla RAG:        1 retrieval + 1 generation = $0.005
Multi-hop RAG:      3 retrievals + 3 generation = $0.015 (3x)
Graph RAG:          1 retrieval + 1 generation = $0.005 (mas indexing é 5-10x mais caro)
Agentic RAG:        5-10 LLM calls + tools = $0.020-0.050 (4-10x)
PageIndex:          tree build + tree search = custo concentrado no index e calls de navegação

Hybrid de patterns

Padrão maduro: Vanilla RAG + Agentic fallback.

def smart_rag(query):
    # 1. Tentar vanilla
    chunks = retrieve(query)
    answer = generate(query, chunks)
 
    # 2. Se confidence baixa, escalar para agentic
    if confidence(answer, chunks) < 0.7:
        answer = agentic_rag(query)
 
    return answer

90% das queries pegam vanilla (rápido, barato). 10% caem em agentic (lento mas resolve).

Decision tree

graph TD
    A["Query"] --> B{"Vanilla RAG<br/>resolve?"}
    B -->|sim| C["Vanilla RAG<br/>(default)"]
    B -->|"não, multi-hop"| D{"Domínio tem<br/>entidades/relações?"}
    D -->|sim| E["Graph RAG"]
    D -->|não| F["Multi-hop RAG<br/>(self-ask)"]
    B -->|"variável"| G["Agentic RAG"]
    B -->|"documento longo<br/>estruturado"| H["PageIndex<br/>(Tree RAG)"]

Anti-patterns

  • Graph RAG em corpus pequeno — overhead enorme sem ganho
  • Agentic RAG sempre — custo escala assustadoramente
  • Multi-hop sem evaluation — não sabe se está melhorando
  • PageIndex em corpus sem estrutura — cria árvore artificial que não ajuda retrieval
  • “Vamos fazer Graph RAG porque é cool” — sem evidência de que vanilla falha
  • Hybrid sem confidence threshold — escala sem critério

Quando ficar no vanilla

Princípio de simplicidade

“Vanilla RAG bem feito (chunking + hybrid + rerank) resolve 80%+ dos casos. Padrões avançados são para os 20% restantes — não para o conjunto inteiro.”

Investir em chunking estrutural + hybrid retrieval + Cohere Rerank + golden set é maior ROI que partir direto para Graph RAG.

Métricas

MétricaVanillaMulti-hopGraph RAGAgentic
Cost/query$0.005$0.015$0.005 + indexing pesado$0.02-0.05
Latência p951-3s3-8s1-4s5-15s
Recall em multi-hop<50%>80%>85%>85%
Setup complexityBaixaMédiaAltaAlta

PageIndex não entra bem nessa tabela porque mede outro eixo: navegação dentro de documento longo. Compare contra baseline de long-context, chunking estrutural e hybrid+rerank no mesmo corpus.

Veja também

Referências

  • MicrosoftGraphRAG (microsoft.github.io/graphrag, 2024)
  • Edge et al.From Local to Global: A Graph RAG Approach (paper 2024)
  • Press et al.Self-Ask paper (2022)
  • LlamaIndexMulti-document agents (2026)
  • ZepGraphiti documentation (2026)
  • VectifyAIPageIndex: Vectorless, Reasoning-based RAG (github.com/VectifyAI/PageIndex, 2026)