10. Técnicas Avançadas de Retrieval

Este documento descreve técnicas de retrieval para RAG que complementam o núcleo (vector search, multi-query). A maioria está em teoria ou planeada; algumas têm implementação parcial.

---

1. HyDE — Hypothetical Document Embeddings

1.1 Conceito

Em vez de embeddar a query do utilizador, embeddar um documento hipotético que seria uma boa resposta.

Problema: Queries são curtas e abstractas; documentos são longos e concretos. O espaço de embeddings pode não alinhar bem query↔documento.

Solução: O LLM gera um ou mais documentos hipotéticos que respondem à query. Esses documentos são embeddados e usados para retrieval. Os documentos reais mais próximos dos hipotéticos tendem a ser mais relevantes.

1.2 Fluxo

Query: "Qual o limite de reembolso em despesas?"
    → LLM: Gera documento hipotético (ex.: "O limite de reembolso para despesas é de 500€ por mês...")
    → Embed documento hipotético
    → Vector search: encontrar docs reais mais próximos do hipotético
    → Top-K chunks

1.3 Variações

• Single HyDE: Um documento hipotético
• Multi-HyDE: Vários (ex.: 5), média dos embeddings ou retrieve por cada e fazer merge
• Ensemble: Combinar score da query original com score do HyDE

1.4 Quando Usar

• Queries vagas ou de domínio
• Melhora recall em muitos cenários
• Custo: chamada LLM extra na retrieval

Estado: ❌ Não implementado.

---

2. Reciprocal Rank Fusion (RRF)

2.1 Conceito

Combinar vários rankings (ex.: BM25 + vector) sem normalizar scores. RRF é rank-based: usa posição, não o valor do score.

2.2 Fórmula

Para cada documento d em M listas ordenadas:

s_RRF(d) = Σ(i=1 to M) 1 / (k + rank_i(d))

• rank_i(d) = posição (1-based) de (d) na lista (i), ou (+\infty) se ausente
• (k) = constante de suavização (tipicamente 60, intervalo 40–100)

2.3 Algoritmo

1. Para cada lista (i), iterar por posições (r \leq R)
2. Para cada doc na posição (r), somar (1/(k+r)) ao score acumulado
3. Ordenar por score RRF descendente
4. Retornar top-K

2.4 Uso em Hybrid Search

BM25 retorna:     [(doc_A, 1), (doc_B, 2), (doc_C, 3), ...]
Vector retorna:   [(doc_C, 1), (doc_A, 2), (doc_D, 3), ...]

RRF(k=60):
  doc_A: 1/61 + 1/62 ≈ 0.033
  doc_B: 1/62       ≈ 0.016
  doc_C: 1/61 + 1/61 ≈ 0.033  ← empate no topo
  doc_D: 1/63       ≈ 0.016

2.5 Parâmetros

• k menor (ex.: 40): mais peso nos top rankings
• k maior (ex.: 100): influência mais espalhada

Estado: ❌ Não implementado (hybrid search em 09-FUTURE-THEORY).

---

3. Query Expansion e Transformação

3.1 Query Rewriting

Reformular a query para melhor retrieval:

• Normalizar: typos, abreviações
• Expandir: "policy despesas" → "expense policy reimbursement rules"
• Traduzir: PT → EN se o corpus for maioritariamente EN
• Desambiguar: usar contexto da conversa

3.2 Multi-Query (Implementado)

Enriched RAG já faz: decompor query em sub-queries, retrieve por cada, merge e dedupe.

3.3 HyDE como Query Expansion

HyDE é uma forma de expansion: a query "expande" para um documento hipotético.

3.4 Pseudo-Relevance Feedback

1. Retrieve inicial com query original
2. Usar top-K como "feedback"
3. Extrair termos ou embeddars dos top-K
4. Nova query (expandida) e retrieve novamente

Estado: Query rewriter planeado; multi-query ✅; HyDE e PRF ❌.

---

4. ColBERT e Late Interaction

4.1 Limitação do Dense Retrieval Clássico

Um embedding por documento: informação comprimida num vector. Perde nuance token-a-token.

4.2 ColBERT

Late interaction: em vez de um vector por doc, múltiplos vectors (um por token ou por token stride). Na query, compara cada token da query com cada token do documento e agrega (max sim, sum, etc.).

Vantagem: Matching mais fino, especialmente para keywords e entidades.

Custo: Índice maior, retrieval mais caro.

4.3 Implementação

• ColBERT v2, ColPali
• Índices especializados (ex.: Faiss com múltiplos vectores por doc)

Estado: ❌ Não implementado.

---

5. Contextual Compression

5.1 Problema

Retrieval traz chunks que podem ser longos ou parcialmente irrelevantes. O LLM recebe ruído e gasta tokens.

5.2 Solução

Comprimir o contexto antes de passar ao LLM:

• Extractive: Manter só as frases/parágrafos mais relevantes (ex.: por similaridade com a query, ou por classificador)
• Abstractive: LLM resume os chunks (mais caro)
• Selective: Filtrar chunks por score ou por critério

5.3 Técnicas

5.4 Benefícios

• Menos tokens → menor latência e custo
• Menos ruído → respostas mais focadas
• Pode melhorar QA ao remover distrações

Estado: ❌ Não implementado.

---

6. Parent Document Retrieval

6.1 Conceito

Com parent-child chunking (ver ingestion/12): pesquisar por child chunks (pequenos, precisos) mas devolver o parent (maior, mais contexto) ao LLM.

6.2 Fluxo

Query → Vector search em children (256 tokens)
    → Top-K children
    → Mapear para parents (1024 tokens)
    → Devolver parents (dedupe se vários children do mesmo parent)
    → Synthesis

6.3 Vantagem

Precisão do retrieval + contexto rico do parent. Especialmente útil para perguntas que precisam de múltiplos parágrafos relacionados.

Estado: ❌ (parent-child chunking não implementado na ingestion).

---

7. Metadata Filtering

7.1 Pre-filter vs Post-filter

7.2 Filtros Úteis

• doc_id, document_type
• version, is_active
• freshness_ts, valid_from, valid_to
• related_entities (ex.: team_finance)
• header_path (ex.: apenas "## Apêndice")

7.3 Chroma

collection.query(
    query_embeddings=[embedding],
    n_results=10,
    where={"document_type": "policy", "is_active": True}
)

7.4 Self-Query

LLM analisa a query e extrai filtros (ex.: "documentos de 2024" → year=2024). Útil quando a query menciona restrições temporais ou categóricas.

Estado: Chroma suporta where; uso sistemático ❌. Self-query ❌.

---

8. Ensemble de Embeddings

8.1 Múltiplos Modelos

Combinar retrievers de modelos diferentes (ex.: MiniLM + E5) e fazer RRF sobre os rankings.

8.2 Multi-Vector por Documento

• ColBERT: vários vectors por doc
• HyDE ensemble: média de embeddings de vários docs hipotéticos
• Chunk + summary: Embedding do chunk e do resumo do doc

Estado: ❌ Não implementado.

---

9. Modelos de Embedding — Alternativas

Nota: Mudar modelo implica nova coleção ou embedding_version (não misturar na mesma coleção).

---

10. Matriz de Técnicas por Estado

---

11. Prioridade de Implementação Sugerida