Decision models: seu agente decide ou só responde?

Decision models: seu agente decide ou só responde?

Notícia: Trend emergente em AI: decision models (modelos pequenos otimizados pra tomar decisões, não conversar). Microsoft lançou Decision-1. Sakana tá pesquisando. Agora aparecem tutorials: "Build your own decision model". Implicação: Seu agente hoje RESPONDE (conversa). Mas DEVERIA estar DECIDINDO (roteando, classificando, priaorizando). Duas tarefas diferentes. Dois models diferentes. Seu agente tá usando o modelo errado.

Problema: Você tá usando Claude/GPT pra TUDO (responder, decidir, classificar). Resultado: (1) Lento (LLMs são lentos), (2) Caro (LLMs são caros), (3) Overkill (você não precisa de superinteligência pra decidir). Decision models: modelo pequeno (9B), rápido (85ms), barato (10x menos). Tarefas de decisão rodam MUITO melhor.

**"Você é CEO de SaaS com agente em produção.

Cenário: Usando LLM pra tudo ├─ Ticket chega: "Meu app tá down" ├─ Agente (usando Claude): │ ├─ Processa com LLM full (~2s latência) │ ├─ Entende: "Crítico, precisa urgente" │ ├─ Usa 2000 tokens (~R$ 0.10) │ ├─ Rota pra Tier 1 (correto) │ └─ Total: 2s + R$ 0.10 + overkill │ ├─ Problema: ├─ Você tá pagando por reasoning sofisticado ├─ Mas tá fazendo classificação simples ├─ Será que ticket é crítico ou não? ├─ (Precisa de superinteligência pra isso? NÃO) ├─ (Precisa de 2 segundos? NÃO) │ ├─ Comparação com decision model: ├─ Agente (usando Decision-1 9B): │ ├─ Processa com decision model (~85ms) │ ├─ Entende: "Crítico" │ ├─ Usa 200 tokens (~R$ 0.01) │ ├─ Rota pra Tier 1 (correto) │ └─ Total: 85ms + R$ 0.01 + eficiente │ ├─ Diferença: ├─ Latência: 2s → 85ms (23x mais rápido) ⚡ ├─ Custo: R$ 0.10 → R$ 0.01 (10x mais barato) 💰 ├─ Accuracy: Mesma (>95% em ambos) ✓ ├─ Escala: 100 tickets/dia │ ├─ LLM approach: R$ 10 + 200s latência │ ├─ Decision model: R$ 1 + 8.5s latência (total) │ └─ Economia: R$ 9 + 191s (massivo) └─ Moralejo: SEMPRE use decision model pra routing/classificação "**

---

O que é decision model (e por que é diferente de LLM)

LLM vs Decision Model

LLM (Large Language Model): ├─ Tamanho: 7B - 405B parâmetros (huge) ├─ Latência: 500ms - 3s (slow) ├─ Custo: R$ 0.01 - R$ 1.00 por request (expensive) ├─ Caso de uso: Conversação, criatividade, reasoning ├─ Accuracy: 95%+ └─ Vantagem: Superinteligente (mas overkill pra classificação)

Decision Model: ├─ Tamanho: 1B - 50B parâmetros (pequeno) ├─ Latência: 50ms - 200ms (very fast) ├─ Custo: R$ 0.0001 - R$ 0.01 (super cheap) ├─ Caso de uso: Classificação, routing, decisões lógicas ├─ Accuracy: 80-95% (suficiente pra maioria dos casos) └─ Vantagem: Rápido + barato + otimizado pra decisões

Analógico: ├─ LLM = Consultor expert (caro, lento, muito inteligente) ├─ Decision Model = Cartório (rápido, cheap, decisões padronizadas) └─ Use o certo pra cada tarefa

Decision models na prática

EXEMPLOS DE TAREFAS:

❌ USE LLM PARA (conversação, criatividade): ├─ "Crie um email de vendas pra esse lead" ├─ "Resuma esse contrato" ├─ "Explain this complex concept" └─ (Precisa reasoning complexo)

✓ USE DECISION MODEL PARA (classificação, routing): ├─ "Esse email é spam ou legítimo?" │ → Decision model: "Spam" ou "Legit" (binary) │ → Latência: 50ms, Custo: R$ 0.0001 │ → Accuracy: 92% (suficiente) │ ├─ "Que categoria de ticket é esse?" │ → Decision model: "Bug", "Feature", "Billing" (multiclass) │ → Latência: 80ms, Custo: R$ 0.0005 │ → Accuracy: 88% (good o suficiente) │ ├─ "Esse lead é sales-qualified?" │ → Decision model: "Sim" ou "Não" (binary) │ → Latência: 60ms, Custo: R$ 0.0001 │ → Accuracy: 90% (probably better than human) │ ├─ "Qual é o score de urgência? (1-5)" │ → Decision model: Numeral (1, 2, 3, 4 ou 5) │ → Latência: 100ms, Custo: R$ 0.0003 │ → Accuracy: 85% (good enough) │ └─ "Rote esse ticket pra qual time?" → Decision model: "Sales", "Support", "Engineering" → Latência: 90ms, Custo: R$ 0.0002 → Accuracy: 91% (significantly better than rule-based)

✓ HYBRID APPROACH (combinado): ├─ Decision model: Classifica ticket (85ms, R$ 0.0001) ├─ Se crítico: LLM: Gera resposta personalized (2s, R$ 0.05) ├─ Se routine: Template + dados (0s, R$ 0) ├─ Total latência: 85ms - 2.085s (depends on path) ├─ Total custo: R$ 0.0001 - 0.0501 (scales efficiently) └─ Resultado: Fast + cheap + smart (melhor dos dois mundos)

---

Como construir decision model (guia prático)

Step 1: Definir tarefa de decisão

SUA TAREFA: "Classificar tickets de suporte em 3 categorias"

Step 1a: Definir outputs ├─ Output 1: "Bug" (algo quebrado) ├─ Output 2: "Feature request" (quer nova funcionalidade) ├─ Output 3: "Billing" (problema de pagamento) └─ Apenas 3 opções (não é escala contínua)

Step 1b: Definir threshold de confiança ├─ Se confidence > 90%: Auto-rota ├─ Se 70-90%: Human review (double-check) ├─ Se < 70%: Escalação pra agent (não temos certeza) └─ Ajustar conforme resulta

Step 1c: Coletar dados ├─ Histórico: 500 tickets já classificados (manualmente ou por humano) ├─ Format: [ticket_text, true_category] ├─ Exemplos: │ ├─ ["App crashed when I clicked export", "Bug"] │ ├─ ["Can you add dark mode?", "Feature request"] │ ├─ ["Why was I charged twice?", "Billing"] │ └─ ...(500 exemplos) └─ Mínimo: 100-200 exemplos (mais = melhor accuracy)

Step 2: Treinar decision model (3 abordagens)

ABORDAGEM 1: Fine-tune pequeno modelo (recomendado)

Library: LangChain + Mistral 7B

python from langchain.llms import Ollama from langchain.callbacks import StreamingStdOutCallbackHandler from datasets import load_dataset

Load seu dataset

dataset = load_dataset('your_tickets.json')

Fine-tune Mistral 7B (small, fast decision model)

model = Ollama( model="mistral", # Small, optimized for classification temperature=0.1, # Deterministic (not creative) top_p=0.5 # Conservative (prefer top choices) )

Treinar prompt (in-context learning)

prompt = """ Classifique esse ticket em UMA categoria:

• Bug: Algo quebrado, erro, crash
• Feature request: Cliente quer nova funcionalidade
• Billing: Problema com pagamento, faturamento

Ticket: {ticket_text} Categoria: [responda apenas com uma palavra] """

Fine-tune

(LangChain + Mistral docs para full setup)

ABORDAGEM 2: Usar API decision model (easiest)

Library: Claude API com system prompt otimizado

python from anthropic import Anthropic

client = Anthropic()

system_prompt = """ You are a ticket classifier. Your job is ONLY to categorize tickets.

Rules:

• Output ONLY the category name (one word)
• No explanation, no reasoning
• Confidence is implicit (you always decide)

Categories:

1. Bug: Application broken, error, crash
2. Feature: New functionality request
3. Billing: Payment, invoice problem

Examples (for in-context learning):

• "App crashed on export" → Bug
• "Can you add dark mode?" → Feature
• "Charged twice" → Billing """

def classify_ticket(ticket_text: str) -> str: message = client.messages.create( model="claude-3-5-haiku", # Fast + cheap (decision model) max_tokens=10, # Only need one word system=system_prompt, messages=[ { "role": "user", "content": f"Classify: {ticket_text}" } ] ) return message.content[0].text.strip()

Test

print(classify_ticket("My app keeps crashing")) # Output: Bug print(classify_ticket("Add voice messages")) # Output: Feature print(classify_ticket("Double charge on invoice")) # Output: Billing

ABORDAGEM 3: Rule-based + LLM fallback (hybrid)

python def classify_ticket_hybrid(ticket_text: str) -> str: # Step 1: Rule-based (fast, cheap, 70% accuracy) if any(word in ticket_text.lower() for word in ["crash", "error", "broken"]): return "Bug" elif any(word in ticket_text.lower() for word in ["add", "feature", "request"]): return "Feature" elif any(word in ticket_text.lower() for word in ["charge", "billing", "invoice"]): return "Billing"

# Step 2: LLM fallback (slow, expensive, 95% accuracy)
# Only for ambiguous cases (30% of tickets)
return classify_ticket_llm(ticket_text)

Result: 70% of tickets = 70ms + R$ 0

30% of tickets = 2000ms + R$ 0.01

Average: 800ms + R$ 0.003 (better than pure LLM!)

Step 3: Deploy e monitorar

DEPLOYMENT:

1. Test em staging ├─ Run 100 tickets ├─ Compare outputs vs human classification ├─ Calcule accuracy: target >85% └─ If <85%: Ajuste prompt ou treina mais

2. Canary deployment (5% traffic) ├─ Route 5% dos tickets pelo decision model ├─ Monitor: accuracy, latência, cost ├─ Setup alerts se accuracy < 80% └─ Se good: expand para 25%

3. Full deployment (100% traffic) ├─ Todos os tickets rodam decision model ├─ Human review apenas pra low-confidence (<70%) ├─ Monitor weekly: accuracy, cost, volume └─ Iterate: Ajuste prompts conforme feedback

MONITORING (Métricas importantes):

┌─────────────────────────────────────┐ │ Accuracy: Porcentagem correto │ │ Target: >85% (>90% é excellent) │ │ Check: Weekly spot-check (20 tickets)│ │ │ │ Latência: Time pra decisão │ │ Target: <200ms (real-time user ok) │ │ Check: Log every request │ │ │ │ Custo: Custo por decisão │ │ Target: <R$ 0.001 (10x barato) │ │ Check: Cost tracking (daily) │ │ │ │ Volume: Quantos rodam decision model│ │ Target: 95%+ (rest escalate) │ │ Check: Dashboard (real-time) │ │ │ │ Escalation rate: % que precisam human│ │ Target: <15% (most são auto) │ │ Check: Daily review │ └─────────────────────────────────────┘

Ação se accuracy cair: 1. Investigate: O que mudou? ├─ Novo tipo de ticket? (dataset drift) ├─ Model degradation? (dados ruins) └─ User behavior change? (tickets diferentes) 2. Retrain: Coletar 50 novos exemplos, re-fine-tune 3. A/B test: Novo model vs old, ver qual ganha 4. Deploy: Winner fica, loser é archived

---

Decision models em seu agente: casos reais

Caso 1: Agente de suporte com roteamento

FLOW: Lead → Agente → Decisão → Rota

1. Lead escreve no WhatsApp: "Meu app tá down!"

2. Agente recebe └─ Decision model: "Qual é a urgência?" ├─ Input: "Meu app tá down!" ├─ Latência: 80ms ├─ Custo: R$ 0.0001 └─ Output: "CRÍTICO" (confidence: 98%)

3. Rota automática └─ "CRÍTICO" → Tier 1 (senior engineer) └─ Latência: 50ms (decision) └─ Lead é roteado em < 200ms total └─ Engineer responde em 5 min (vs 30 min with manual)

4. Resultado ├─ Lead resolvido 6x mais rápido ✓ ├─ Cost: R$ 0.0001 (decision model) ├─ vs LLM: R$ 0.10 + 2s latência └─ Economia: R$ 0.09 + 1.8s por ticket └─ 100 tickets/dia: R$ 9 + 3 minutos poupadas

Caso 2: Agente de vendas com lead qualification

FLOW: Lead form → Agente → Decision model → Ação

1. Lead preenchendo form (em site) └─ Company: "Startup de 5 pessoas" └─ Budget: "R$ 100/mês" └─ Timeline: "ASAP" └─ Product interest: "Enterprise plan"

2. Agente processa (decision model) └─ Decision: "Sales-qualified? SIM ou NÃO?" ├─ Input: {company, budget, timeline, interest} ├─ Latência: 100ms ├─ Custo: R$ 0.0002 └─ Output: "NÃO (confidence: 87%)" └─ Reason: Budget MUITO BAIXO pra enterprise

3. Rota automática └─ "NÃO" → Nurture sequence (automated email) └─ vs "SIM" → Sales rep (hot lead) └─ Lead "NÃO" recebe email nurture (free) └─ Lead "SIM" recebe rep pessoal (expensive)

4. Resultado ├─ Sales rep focus em warm leads only ✓ ├─ Cost: R$ 0.0002/lead (decision) ├─ vs LLM: R$ 0.05 + 2s latência ├─ Economia: R$ 0.05 per lead ├─ 1000 leads/mês: R$ 50 economizado └─ Plus: Sales rep eficiência ↑ 20%

Caso 3: Agente de conteúdo com moderação

FLOW: User post → Agente → Decision model → Publish/Hold

1. User publica comentário └─ "This product sucks!!! 🔥"

2. Agente processa (decision model) └─ Decision: "Spam ou legítimo? Toxic ou okay?" ├─ Latência: 60ms ├─ Custo: R$ 0.0001 └─ Output: "Legítimo + Toxic (confidence: 92%)"

3. Ação automática └─ "Legítimo": Publica (authentic feedback) └─ "Toxic": Publica com aviso ("Strong language") └─ "Spam": Rejeta (silently) └─ "Fake": Rejeita + alertar moderator

4. Resultado ├─ Moderação em escala (no human needed) ✓ ├─ 1000 posts/dia em <200ms ├─ Cost: R$ 0.10/dia (muito cheap) ├─ vs LLM: R$ 50/dia ├─ vs human: R$ 500/dia └─ Economia: R$ 49.90/dia (massive)

---

Checklist: Quando usar decision model vs LLM

🤔 Decision model se: ☐ Tarefa é classificação ou roteamento ☐ Output é pré-definido (não é free-form) ☐ Latência importa (<200ms target) ☐ Custo é concern (escala de muitos requests) ☐ Você quer 80-95% accuracy (not 99%) ☐ Tem dados de treino (100+ exemplos) ☐ Tarefa é repetitiva (mesmos tipos de decision)

Score: >5 ☐ → USE DECISION MODEL

🧠 LLM se: ☐ Tarefa requer reasoning complexo ☐ Output é criativo ou variable ☐ Latência <2s é okay ☐ Você quer 95%+ accuracy ☐ Tarefa é única/ad-hoc ☐ Precisa de explicação (not just decision) ☐ Quer conversação (não decisão)

Score: >4 ☐ → USE LLM

⚖️ HYBRID se: ☐ Tarefas simples → Decision model (70% tickets) ☐ Tarefas complexas → LLM (30% tickets) ☐ Resultado: 70% fast + cheap, 30% smart ☐ Average latência: ~800ms (not bad) ☐ Average custo: ~R$ 0.003 (very cheap) ☐ Satisfaction: alta (smart when needed, fast usually)

---

Conclusão: Decision models são game-changer pra agentes

Fatos:

✓ Decision models: Novo trend (Microsoft Decision-1, Sakana, agora você) ✓ Decision vs LLM: 23x mais rápido, 10x mais barato ✓ Use case: Classificação, routing, decisões simples ✓ Accuracy: 80-95% (suficiente pra maioria) ✓ Implementação: 1-2 semanas (not hard) ✓ ROI: Imediato (custo reduzido + latência melhor) ✓ Escala: Decision models escalam 10x melhor (cost-wise) ✓ Seu agente: Provavelmente tá usando LLM pra TUDO (errado) ✓ Solução: Separe tarefas (decision model + LLM híbrido)

Proximo passo:

1. HOJE: Identifique tarefas de decisão (routing, classificação)
2. SEMANA 1: Coletar dados (100-200 exemplos)
3. SEMANA 2: Treinar decision model (fine-tune ou API)
4. SEMANA 3: Deploy em staging, teste accuracy
5. SEMANA 4: Deploy em produção, monitor, iterate
6. RESULTADO: 10x mais barato, 23x mais rápido

Problema resolvido quando: └─ Seu agente separa tarefas (decision + LLM) └─ Decision models rodam 95%+ das decisões └─ LLM rodam 5% das tarefas complexas └─ Latência caiu (85ms vs 2s) └─ Custo caiu (R$ 0.001 vs R$ 0.10 por decision) └─ Accuracy mantém >85% └─ You sleep knowing agente é otimizado

→ OpenClaw: Agentes com Decision Models Built-in

Microsoft, Sakana, Google: todos entrando em decision models. Seu agente? Ainda usando LLM pra TUDO. IMPLEMENTE DECISION MODELS AGORA. 23x mais rápido, 10x mais barato. 🚀