Pular para conteúdo

Capítulo 0.2 — Sistemas probabilísticos em ambientes determinísticos

🎯 Objetivo do capítulo

Mostrar que sistemas de IA são probabilísticos, mas se inserem em ambientes determinísticos (APIs, bancos, contratos, regulação) - e que essa fronteira exige decisões arquiteturais explícitas.

🧠 Conceito principal

Um modelo ML/LLM produz saídas que carregam incerteza. Uma API REST que consome essa saída espera uma resposta com contrato claro. Quando essas duas camadas se misturam sem mediação, surge o problema clássico:

  • a resposta probabilística vira efeito determinístico no mundo real;
  • um erro semântico vira um update em CRM, um e-mail enviado, um pagamento acionado.

A arquitetura deve isolar a variância entre as duas camadas com:

  • validação de schema;
  • regras de negócio determinísticas;
  • aprovações humanas para ações críticas;
  • camadas de tradução (parsing, normalização, mapeamento controlado).

🏗️ Como isso aparece em produção

Camada Natureza Exemplo
LLM/ML Probabilística Resposta gerada por LLM, classificação de risco
Pós-processamento Determinístico Validação de schema, normalização
Política Determinístico "Se valor > X, exigir aprovação"
Execução Determinístico Update em banco, chamada de API externa
Auditoria Determinístico Log imutável da decisão

⚖️ Trade-offs

  • Mais camadas determinísticas -> mais segurança, menos flexibilidade.
  • Menos camadas determinísticas -> mais agilidade, mais risco residual.

🚨 Modos de falha

  • Tratar resposta de LLM como verdade.
  • Permitir que a saída do modelo dispare ação irreversível sem mediação.
  • Confundir output validado por schema com output correto (schema valida forma, não conteúdo).

🛡️ Controles e mitigações

  • Structured outputs + validação de schema como primeira linha.
  • Policy-as-code para regras críticas.
  • Human-in-the-loop para ações de alto impacto.
  • Audit trail completo para investigações.

🔭 Como observar e medir

  • Taxa de respostas que falham na validação de schema.
  • Taxa de policy violations bloqueadas.
  • Tempo entre proposta do modelo e aprovação humana.

🧪 Como testar

  • Testes de contrato (contract tests) em todas as fronteiras.
  • Testes adversariais que forçam saídas inválidas.
  • Testes de policy-as-code com casos positivos e negativos.

🧰 Exemplo prático relacionado (planejado)

  • EX-FUND-02 - wrapper de LLM com structured output + validador Pydantic + política simples de aprovação.

📌 Checklist

  • [ ] Saída do modelo passa por validação de schema antes de qualquer ação?
  • [ ] Regras críticas estão em código, não em prompt?
  • [ ] Ações irreversíveis exigem aprovação?

📚 Referências