Domínio 5 — Context Management & Reliability · Lição 3 de 5

Escalonamento, ambiguidade e human-in-the-loop

Objetivos de aprendizagem

• Listar os gatilhos corretos de escalação: pedido explícito do cliente, lacuna/exceção de política e incapacidade de progredir.
• Explicar por que sentimento e confiança auto-reportada são proxies não confiáveis de complexidade real.
• Aplicar o padrão correto para múltiplos matches de cliente: pedir identificadores adicionais, nunca escolher por heurística.
• Reconhecer que métricas agregadas mascaram segmentos ruins — estratificar por tipo de documento e campo.
• Projetar roteamento de revisão humana com confiança field-level calibrada em validation set rotulado.

Gatilhos corretos de escalação

Escalar tudo destrói a resolução autônoma; escalar nada gera decisões fora de alçada. Os gatilhos que a prova considera corretos:

• Pedido explícito por um humano — honre imediatamente, sem tentar "investigar primeiro". Se o cliente está frustrado mas o problema é simples, o padrão intermediário é reconhecer a frustração e oferecer resolver, escalando se o cliente reiterar a preferência.
• Lacuna ou exceção de política — quando a política é ambígua ou silenciosa sobre o pedido específico (ex.: cliente pede price match com concorrente e a política só cobre ajustes do próprio site). Note: o gatilho é a lacuna de política, não "caso complexo".
• Incapacidade de progredir — o agente esgotou o que pode fazer (ferramentas falharam, informação inacessível) e não consegue avançar de forma significativa.

A técnica de implementação é adicionar critérios explícitos de escalação com exemplos few-shot ao system prompt, demonstrando quando escalar versus resolver autonomamente — antes de qualquer infraestrutura adicional (classificadores, ML, etc.).

Proxies não confiáveis

Ambiguidade de identidade: múltiplos matches

Quando get_customer retorna múltiplos clientes possíveis (mesmo nome, dados parciais), o agente deve pedir identificadores adicionais (e-mail, número do pedido, CPF parcial) — nunca selecionar por heurística ("o mais recente", "o da mesma cidade"). Seleção heurística leva a contas mal identificadas e ações irreversíveis no cliente errado.

Métricas agregadas mascaram segmentos ruins

Um pipeline de extração com "97% de acurácia geral" pode ter 99,5% em notas fiscais digitais e 74% em recibos manuscritos — o agregado esconde o segmento problemático. Antes de reduzir revisão humana ou automatizar extrações de alta confiança:

• Estratifique a análise de acurácia por tipo de documento e por campo, verificando desempenho consistente em todos os segmentos;
• Implemente amostragem aleatória estratificada das extrações de alta confiança para medir taxa de erro contínua e detectar padrões novos de erro que não existiam no conjunto original.

Confiança field-level calibrada

O padrão robusto de human-in-the-loop para extração:

1. O modelo emite score de confiança por campo (não um único score por documento);
2. Os thresholds de roteamento são calibrados contra um validation set rotulado — descobrindo empiricamente, por exemplo, que confiança ≥ 0,9 corresponde a 99% de acurácia no campo "total", mas só 92% no campo "data";
3. Vão para revisão humana: extrações com baixa confiança e documentos-fonte ambíguos ou contraditórios — priorizando a capacidade limitada dos revisores onde o risco é maior.

Exemplo: roteamento de revisão com thresholds calibrados

import anthropic

client = anthropic.Anthropic()

# Thresholds POR CAMPO, calibrados contra um validation set rotulado
# (nao sao a "confianca auto-reportada" crua: foram ajustados ate que
# cada threshold correspondesse a taxa de erro tolerada pelo negocio)
CALIBRATED_THRESHOLDS = {"total_amount": 0.93, "issue_date": 0.88, "vendor_name": 0.85}

def route_extraction(extraction: dict) -> dict:
    """Decide, campo a campo, o que vai para revisao humana."""
    needs_review = []
    for field, threshold in CALIBRATED_THRESHOLDS.items():
        data = extraction["fields"].get(field)
        if data is None or data["confidence"] < threshold:
            needs_review.append(field)
    if extraction.get("source_contradictory"):
        needs_review = list(extraction["fields"].keys())  # fonte ambigua: revisar tudo
    return {"auto_approved": not needs_review, "fields_for_review": needs_review}

# System prompt com criterios EXPLICITOS de escalacao + few-shot
system = """Voce e um agente de suporte. Criterios de escalacao:
1. Cliente pede um humano -> escale IMEDIATAMENTE, sem investigar antes.
2. Politica ambigua ou silenciosa sobre o pedido -> escale com o contexto coletado.
3. Voce nao consegue progredir (ferramentas falharam, dados inacessiveis) -> escale.
Caso contrario, resolva autonomamente.

Exemplo (escalar): "Quero falar com uma pessoa AGORA" -> transferir imediatamente.
Exemplo (resolver): "Produto chegou quebrado, tenho fotos" -> troca padrao, resolver.
Exemplo (escalar): "A loja X cobre o preco de voces?" e a politica so trata de
ajustes no proprio site -> lacuna de politica, escalar."""

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    system=system,
    messages=[{"role": "user", "content": "Quero falar com um atendente humano."}],
)
print(response.content[0].text)

Pegadinhas da prova

• Distrator típico: "escalar quando o sentimento ficar negativo". Sentimento não se correlaciona com complexidade — resolve o problema errado.
• Distrator típico: "o agente auto-reporta confiança 1–10 e escala abaixo do threshold". Confiança auto-reportada é mal calibrada; sozinha, não é gatilho confiável. Scores só viram roteamento válido depois de calibrados contra validation set rotulado.
• Distrator típico: "primeiro investigar o caso, depois transferir se necessário" quando o cliente pediu explicitamente um humano. O pedido explícito se honra imediatamente.
• Distrator típico: com múltiplos matches, "selecionar o cliente com atividade mais recente". Heurística de seleção é o anti-padrão; a resposta é pedir identificadores adicionais.
• Distrator típico: "97% de acurácia geral, podemos automatizar". Sem estratificação por tipo de documento e campo, o agregado pode mascarar segmentos com desempenho inaceitável.
• Distrator típico: treinar um classificador ML de escalação antes de tentar critérios explícitos + few-shot no prompt — over-engineering como "primeiro passo".

Resumo em 5 linhas

Documentação oficial

• Prompt engineering — overview (critérios explícitos e few-shot)
• Define success criteria (métricas e validação)
• Develop test cases e evals

Questões de fixação