Capítulo 0.8 — Matriz de decisão arquitetural

🎯 Objetivo do capítulo

Oferecer um instrumento prático para decidir entre ML tradicional, regras, workflow, LLM simples, RAG, fine-tuning, agente, multi-agent ou solução híbrida.

🧠 Matriz

Pergunta	Regras	ML tradicional	LLM simples	RAG	Fine-tuning	Agente	Multi-agent	Híbrido (ML + LLM + agente)
Problema é determinístico e bem definido?	✅	✅	⚠️	⚠️	⚠️	❌	❌	⚠️
Há dataset rotulado suficiente?	N/A	✅	⚠️	⚠️	✅	⚠️	⚠️	✅
Input é texto aberto / ambíguo?	❌	⚠️	✅	✅	⚠️	✅	✅	✅
Resposta depende de documentos mutáveis?	❌	⚠️	❌	✅	❌	✅	✅	✅
Precisa baixa latência?	✅	✅	⚠️	⚠️	⚠️	❌	❌	⚠️
Custo por tarefa precisa ser mínimo?	✅	✅	⚠️	⚠️	⚠️	❌	❌	⚠️
Precisa agir em sistemas externos?	✅	⚠️	❌	❌	❌	✅	✅	✅
Precisa explicabilidade auditável?	✅	✅	⚠️	⚠️	⚠️	⚠️	⚠️	⚠️
Relações entre entidades importam?	⚠️	⚠️	⚠️	⚠️	❌	✅	✅	✅
Há requisito regulatório forte?	✅	✅	⚠️	⚠️	⚠️	⚠️	⚠️	⚠️
Pode envolver decomposição paralela real?	❌	❌	❌	❌	❌	⚠️	✅	⚠️

Legenda: ✅ = forte candidato; ⚠️ = cabível com cuidado; ❌ = evitar.

🔭 Matriz expandida - dimensões operacionais

A matriz acima responde "isso é tecnicamente cabível?". A matriz abaixo responde "isso é operacionalmente sustentável?".

Dimensão	Regras	ML tradicional	LLM simples	RAG	Fine-tuning	Agente	Multi-agent	Híbrido
Custo por chamada (relativo)	Mínimo	Baixo	Médio	Médio-alto	Médio (após treino)	Alto	Muito alto	Variável
Latência típica	<10 ms	<50 ms	0,5–3 s	1–5 s	0,5–3 s	5–60 s	10–300 s	Por etapa
Frequência de mudança do conhecimento	Baixa	Baixa-média	Estática (treino)	Alta (RAG indexa)	Baixa (precisa retreinar)	Alta via tools	Alta via tools	Variável
Necessidade de estilo/comportamento	Não	Não	Limitada (prompt)	Limitada	Alta	Variável	Variável	Variável
Necessidade de ação externa	Direta	Limitada	Não	Não	Não	Direta	Direta	Direta
Risco regulatório	Baixo	Médio	Alto	Alto	Alto	Muito alto	Muito alto	Médio-alto
Capacidade de avaliação automatizada	Alta	Alta	Média	Média	Média	Baixa	Muito baixa	Média
Maturidade operacional exigida	Baixa	Alta (MLOps)	Média (LLMOps)	Alta (LLMOps+retrieval)	Alta (MLOps+evals)	Muito alta (AgentOps)	Extremamente alta	Alta
Capacidade de rollback	Fácil	Médio	Médio	Médio	Difícil (versão de pesos)	Difícil (estado, side-effects)	Muito difícil	Médio
Auditabilidade	Total	Alta (modelo+features)	Parcial	Parcial (com citações)	Parcial	Parcial (tracing semântico)	Frágil	Variável

Como ler. As duas matrizes são complementares. Uma decisão tecnicamente viável mas operacionalmente cara é um anti-padrão recorrente - agentes em contextos onde um classificador resolveria por décimo do custo, por exemplo.

🧭 Regra de bolso

1. Comece pelo mais simples. Regras > ML tradicional > LLM simples > RAG > fine-tuning > agente > multi-agent.
2. Suba o degrau apenas quando o anterior não resolver.
3. Híbrido é normal. ML para classificação rápida + LLM para extração semântica + workflow + HITL é o padrão enterprise mais defensável.

🧪 Exemplos arquiteturais estudados

• Classificador roteando tarefas para LLM. Um modelo tfidf + linear classifier em < 5 ms decide se o caso é "trivial" (resposta determinística), "documental" (RAG) ou "ação" (agente). Reduz consumo de LLM em 40–80% em fluxos típicos de suporte.
• RAG com reranker e metadata filtering. Retrieval top-50 com BM25 + vetorial, filtros obrigatórios por tenant_id e language, reranker cross-encoder reduzindo para top-8. Sem filtros, o sistema apresenta documentos de outros clientes; com reranker fraco, recall@8 cai 25–40%.
• Agente com tool calling sob policy-as-code. Um agente de atualização de CRM expõe três tools (search, update, escalate). Toda chamada de update passa por uma policy Rego que valida tenant, role e campos permitidos. update com risco alto exige aprovação humana.
• Fine-tuning para formato/estilo. Um modelo é fine-tunado para gerar relatórios no formato interno da empresa (cabeçalho, seções, abreviações). Fatos continuam vindo de RAG. Trocar conhecimento factual pelo fine-tuning seria erro recorrente.
• Distillation para reduzir custo de serving. Um modelo de 70B foi destilado em um modelo de 7B para uma tarefa específica (classificação multi-rótulo de tickets), reduzindo custo de inferência ~10x mantendo F1 em margem aceitável. Modelo é reavaliado contra o teacher periodicamente.

📌 Checklist

• [ ] A decisão foi registrada em ADR?
• [ ] Está claro qual problema cada componente resolve?
• [ ] A complexidade adicional foi justificada?
• [ ] Quem é o owner técnico, de produto e de operação?
• [ ] Quais sinais disparam revisão da decisão?

---