← Voltar a RAG — Arquitetura de Ingestion e Retrieval

🔄 Pipelines de Retrieval

RAG — Arquitetura de Ingestion e Retrieval

Apresentação

4. Retrieval por Pipeline

Cada pipeline usa retrieval de forma diferente. Este documento detalha o fluxo de encontrar e compor em cada um.

3.1 Direct Answer

Retrieval: Nenhum.

A resposta baseia-se apenas no conhecimento do LLM. Não acede a docs, SQL ou graph.

Quando: needs_grounding=false, complexity=low, risk_level=low.

3.2 Simple RAG

Fluxo

Query
    → DocStore.retrieve(query, top_k=5)
    → [(doc_id, passage, score), ...]
    → Pack context: "[Source: doc_id]\npassage"
    → LLM synthesis (system + user com context + query)
    → Answer + citations (top 3 chunks)

Características

Aspeto	Detalhe
Queries	1 (a original)
Merge	N/A
Rerank	Não (usa score Chroma)
Citações	Top 3 chunks por score

Quando

Query factual, fonte única (docs), complexidade baixa.

3.3 Enriched RAG

Fluxo

Query
    → Decompose (LLM): [subq1, subq2, subq3, ...]
    → Para cada subquery: DocStore.retrieve(subq, top_k=4)
    → Merge: dedupe por (doc_id, passage), manter maior score
    → Ordenar por score descendente
    → Tomar até retrieval_top_k*2 chunks
    → Pack context
    → LLM synthesis
    → Answer + citations (top 5 chunks)

Características

Aspeto	Detalhe
Queries	Múltiplas (decomposition)
Merge	Dedupe por passage, best score wins
Rerank	Não
Citações	Top 5 chunks

Decomposição

O LLM recebe prompt para decompor query complexa em sub-queries. Exemplo:

"Compara a policy de despesas com a de segurança" → ["policy de despesas", "policy de segurança", "diferenças entre políticas"]

Quando

task_type comparative/analytical, ou complexity=high.

3.4 Multi-Backend Agent

Fluxo

Query
    → Planner (LLM): {"use_docs": bool, "use_sql": bool, "use_graph": bool}
    → Tools (conceptualmente em paralelo):
        • use_docs → DocStore.retrieve(query, top_k=10)
        • use_sql → LLM text-to-SQL → SQLTool.query(sql)
        • use_graph → LLM text-to-Cypher → Neo4jTool.query(cypher)
    → Format: docs_context, sql_context, graph_context
    → Synthesis (LLM): combina os três contextos na resposta
    → Answer + citations (só dos doc chunks)

Características

Aspeto	Detalhe
Fontes	Docs + SQL + Graph (conforme planner)
Planner	LLM decide quais tools usar
Text-to-SQL	Schema no prompt, LLM gera SELECT
Text-to-Cypher	Graph schema no prompt, LLM gera MATCH
Synthesis	Um único prompt com docs_context, sql_context, graph_context
Citações	Só documentos (SQL/graph não têm passage para citar)

Fallback

Se use_sql mas Postgres indisponível → sql_context = "(No database results)"
Se use_graph mas Neo4j indisponível → graph_context = "(No graph results)"
Se retrieval vazio e request.query diferente de query usada → retry com query original

Quando

requires_multi_source ou requires_structured_data, ou risk_level=high com multi-source.

3.5 Comparação Resumida

Pipeline	Fontes	Retrieval docs	SQL	Graph	Composição
direct_answer	Nenhuma	—	—	—	LLM only
simple_rag	docs	1 query, top_k	—	—	context + synthesis
enriched_rag	docs	multi-query, merge	—	—	context + synthesis
multi_backend	docs+sql+graph	1 query (se use_docs)	text-to-SQL	text-to-Cypher	3 contextos + synthesis

3.6 Teoria: Híbrido e Ordem de Execução

Híbrido (não implementado)

Em vez de planner binário, poderia haver:

Primeiro retrieval (docs)
Se scores baixos ou query sugere números → acionar SQL
Se query sugere relações → acionar graph

Ordem de Tools

Atualmente tools executam em sequência (planner → tools → synthesize). Em teoria, docs/SQL/graph poderiam correr em paralelo quando todos true para reduzir latência.

Zona de prática

Sem perguntas. Clica em Editar para adicionar.