RAG sobre 10+ bases de dados: o que a produção nos ensinou

TL;DR — Em 2026 o consenso é claro: RAG vector-only não escala em produção. Na Darwin construímos um sistema agentic de compliance com retrieval híbrido sobre 10+ bases de dados. As melhores decisões que tomamos não tiveram a ver com o modelo, mas com a camada de dados.

O problema

Nosso sistema agentic de compliance tem que responder perguntas como:

“Quais lotes de manga do produtor X, processados entre maio e julho, cumpriram os CTEs exigidos pela FSMA 204, e quais têm gaps de evidência?”

Uma única pergunta que combina:

• Conhecimento regulatório (definições CTE/KDE da FSMA 204 — texto estruturado)
• Eventos de rastreabilidade (CTEs registrados com timestamp, geolocalização, fornecedor, lote)
• Regras de negócio internas (gap analysis, risk scoring — lógica dinâmica)
• Relações entre entidades (produtor → planta → envio → varejista)

Um vector store com embeddings de tudo misturado não serve para responder isso bem. A resposta correta requer join de dados estruturados + retrieval semântico + cálculo agregado.

A arquitetura

Nosso stack de retrieval:

O agente não sabe onde vive cada coisa — o orchestrator resolve.

LangGraph como orchestrator

Usamos LangGraph para rotear queries em múltiplos passos:

1. Classify — que tipo de pergunta é (regulatória / operacional / mista)
2. Plan — quais retrievals são necessários (vector + SQL + graph traversal)
3. Fan-out — executar retrievals em paralelo
4. Synthesize — passar resultados ao LLM com contexto estruturado
5. Validate — guardrails para prevenir hallucinations em dados numéricos

O passo-chave foi o #2: dar ao LLM um query planner que decide a estratégia de retrieval antes de ir buscar. Sem isso, o modelo alucina dados ou traz contexto irrelevante.

O que não funcionou

Vector-only com chunking agressivo — nossa primeira tentativa. Falhou em duas dimensões:

• Queries de counting / aggregation (quantos lotes? média por semana?) — LLM inventava números quando não os tinha explícitos no contexto
• Joins relacionais (produtor X + janela temporal Y + certificação Z) — impossível sem query estruturada

A solução não foi “melhor chunking” — foi separar retrieval semântico de consultas estruturadas.

O que sim funcionou

Query routing explícito → o planner decide se uma pergunta requer vector search, SQL, graph traversal ou combinação.

Guardrails numéricos → se a resposta do LLM contém números, verificamos que batem com o que a query estruturada devolveu. Se não, falhamos fast em vez de devolver dados incorretos.

Semantic caching no nível de perguntas similares → reduz custos de LLM ~40% sem impacto na qualidade.

Observabilidade full-trace com OpenTelemetry → cada query é rastreada end-to-end (planner → retrieval → LLM → guardrails). Crítico para debug.

Lessons learned

1. O gargalo do RAG em produção não é o retrieval — é a decisão de qual retrieval usar
2. Os guardrails numéricos salvam vidas quando a correctness da resposta afeta decisões regulatórias
3. LangGraph é melhor que cadeias lineares para orquestrar retrievals condicionais
4. Multi-store + planner > single vector store com melhor chunking
5. Os LLMs vão alucinar sobre aggregations estruturadas — não importa quão bom seja o modelo

E agora?

A próxima iteração é substituir algumas regras do planner por fine-tuning do router com exemplos reais de produção. O planner como LLM é flexível mas caro — cachear suas decisões em um modelo menor é um step lógico.

Se você está construindo RAG para domínios regulados, meu conselho é: comece pelo query planner, não pelo vector store.

Está construindo algo parecido? Vamos conversar — estamos abertos a compartilhar arquitetura e aprender com outros casos.