2. Núcleo do Retrieval — Como Encontro e Componho a Resposta

Este documento responde à pergunta central: "Como é que encontro e componho a resposta?"

---

1.1 Visão Conceitual

O retrieval em sistemas RAG tem duas funções:

1. Encontrar — localizar evidência relevante em fontes (vector store, SQL, graph)
2. Compor — combinar evidência, sintetizar e devolver resposta com citações

Query → [Encontrar] → Chunks / Rows / Graph results
                    → [Compor] → Contexto packed
                    → LLM synthesis → Resposta + Citações

---

1.2 DocStore — Vector Retrieval

Implementação Atual

Fluxo de Indexação

Markdown files (.md)
    → chunk_text() (quebrar em frase/nova linha)
    → SentenceTransformer.encode()
    → Chroma.upsert(ids, documents, embeddings, metadatas)

Script: ingest-rag/scripts/ingest_docs.py

Fluxo de Retrieval

Query (string)
    → model.encode([query])
    → collection.query(query_embeddings, n_results=top_k, include=["documents","metadatas","distances"])
    → Converter distance → score: 1 - (dist/2) para cosseno
    → Retornar [(doc_id, passage, score), ...]

Metadados nos Chunks

Futuro (ver ingestion): version, freshness_ts, is_active, valid_from, valid_to

Limitações Atuais

• Sem reranker (usa score do Chroma diretamente)
• Sem hybrid search (BM25 + vector)
• Sem filtros por metadata (ex.: document_type)
• Chunking fixo (sem semantic chunking por documento)

---

1.3 Chunking — Teoria e Prática

Estratégia Atual

• Tipo: RecursiveCharacterTextSplitter-style (break em \n, . , ; )
• chunk_size: 600 caracteres
• chunk_overlap: 100 caracteres
• Objetivo: Balanço entre contexto suficiente e granularidade

Teoria Alternativa (não implementada)

Versioning de Chunking

Quando muda a estratégia de chunking (ex.: 600→800), deve-se:

• Criar nova chunking_version no registry
• Reprocessar documentos ativos
• Não misturar chunks de versões diferentes na mesma coleção

---

1.4 Embedding — Modelo e Similaridade

Modelo Atual

• ID: all-MiniLM-L6-v2
• Dimensão: 384
• Vantagens: Rápido, local, sem API
• Limitações: Menos preciso que modelos maiores (e5-large, multilingual-e5)

Teoria: Escolha de Modelo

Versioning de Embedding

Regra: Não misturar embeddings de modelos diferentes na mesma coleção.

Quando mudar modelo:

1. Nova coleção ou embedding_version no metadata
2. Re-embed total ou progressivo
3. Registry com embedding_version por asset

---

1.5 Top-K e Ranking

Atual

• simple_rag: top_k=5 (configurável)
• enriched_rag: top_k_per_query=4, merge, dedupe, total ~ retrieval_top_k*2
• multi_backend: top_k=retrieval_top_k*2 para docs

Teoria: Reranker

Após retrieval inicial (top_k=20 ou 50):

1. Cross-encoder (ex.: Cohere rerank, cross-encoder/ms-marco) reordena
2. Top 5–10 passam para synthesis
3. Melhora precisão sem aumentar custo de embedding

Estado: Planeado, não implementado.

---

1.6 Composição da Resposta

Packing de Contexto

Contextos das fontes são formatados para o LLM:

[Source: expense_policy]
Passage 1...

---
[Source: security_policy]
Passage 2...

Synthesis

O LLM recebe:

• System prompt (instruções)
• Prompt do utilizador: Contexto + Consulta
• Deve responder baseado no contexto e citar fontes

Citações

Cada resposta inclui citations: lista de {doc_id, passage, score} para os chunks usados.

---

1.7 Configuração Relevante

---

1.8 Resumo do Fluxo Completo

Consulta do Utilizador
    |
    v
Query Analyzer → QueryAnalysis (needs_grounding, sources, complexity, ...)
    |
    v
Strategy Router → strategy (direct_answer | simple_rag | enriched_rag | multi_backend_agent)
    |
    v
Pipeline:
    • direct_answer: nenhum retrieval
    • simple_rag: DocStore.retrieve(query, top_k) → pack → LLM
    • enriched_rag: decompose → multi-retrieve → merge → pack → LLM
    • multi_backend: planner → [DocStore | SQLTool | Neo4jTool] → pack → LLM
    |
    v
Resposta + Citações + ExecutionResult