Pular para conteúdo

Capítulo 0.1 — Modelo, produto e sistema

🎯 Objetivo do capítulo

Diferenciar três níveis de abstração que costumam ser confundidos: modelo, produto e sistema - e mostrar por que essa diferença é a raiz dos erros mais caros em IA enterprise.

🧠 Conceito principal

  • Modelo é uma função que mapeia entradas em saídas. Tem pesos, arquitetura, fronteira de competência, hipóteses sobre os dados e uma janela de validade.
  • Produto é a aplicação consumida por uma pessoa ou outro sistema. Tem UX, contratos de API, regras de negócio, SLAs e contexto.
  • Sistema é o conjunto operacional total: produto + modelo + serviços de dados + serviços de avaliação + segurança + governança + custo + operação + ciclo de vida.

A tese central deste livro é que valor real de IA aparece no sistema, não no modelo isolado.

🏗️ Como isso aparece em produção

Um classificador com 98% de acurácia offline pode falhar em produção porque:

  • os dados de produção diferem dos dados de treino;
  • a feature mais informativa só está disponível com atraso;
  • o consumidor downstream interpreta a saída de forma inválida;
  • não existe rollback se a qualidade cair;
  • não existe pessoa responsável quando há incidente.

Nenhum desses problemas é resolvido por trocar o modelo.

⚖️ Trade-offs

Dimensão Foco em "modelo" Foco em "sistema"
Tempo até demo Curto Mais longo
Tempo até produção Geralmente longo Mais curto
Custo de manutenção Alto e oculto Visível desde o início
Risco operacional Concentrado em incidentes Distribuído e mitigado
Sucesso ao escalar Imprevisível Previsível

🚨 Modos de falha

  • "Funciona no notebook" como prova de produção.
  • Métricas offline desconectadas do KPI de negócio.
  • Modelo trocado sem regressão de comportamento.
  • Falha em upstream de dados causando degradação silenciosa.
  • Modelo bom servindo dados errados (tenant cruzado, versão antiga, idioma diferente).

🛡️ Controles e mitigações

  • Tratar IA como software crítico: versionamento, testes, observabilidade, CI/CD, rollback, runbooks.
  • Documentar modos de falha aceitos e modos de falha inaceitáveis.
  • Distinguir o que é responsabilidade do modelo, do produto e do sistema.

🔭 Como observar e medir

  • Métricas técnicas: latência, throughput, taxa de erro, custo por chamada.
  • Métricas de qualidade: accuracy, F1, groundedness, recall@k.
  • Métricas de negócio: conversão, satisfação, deflexão de tickets, MTTR.
  • Métricas de governança: violações de política, eventos de DLP, aprovações pendentes.

🧪 Como testar

  • Testes unitários e de integração no produto.
  • Eval harness (offline e online) no modelo.
  • Replay de traces reais.
  • Canary deploy para mudanças.

🧰 Exemplo prático relacionado (planejado)

  • EX-FUND-01 - comparar resultado de um modelo isolado vs do mesmo modelo embarcado em um produto com pré-processamento e pós-processamento.

📌 Checklist

  • [ ] O sistema tem owner de modelo, produto e operação?
  • [ ] Existe documentação de contrato de entrada/saída?
  • [ ] Existe pipeline de validação de dados upstream?
  • [ ] Existe processo de rollback?
  • [ ] Existe runbook?

📚 Referências