Modelos explicáveis e caixas-pretas

Uma seguradora constrói um modelo que decide quais sinistros são aprovados automaticamente e quais vão para um analista humano. A versão A é uma logistic regression sobre 11 entradas. A versão B é um gradient-boosted ensemble que pontua 3 pontos acima no mesmo conjunto de teste, então a versão B vai para produção. Oito meses depois, o advogado de um cliente manda uma carta perguntando com base em que um sinistro específico foi separado para investigação, e ninguém na empresa consegue responder numa frase que sobreviva a ser lida de volta sob juramento.

É disso que esta lição trata. Os 3 pontos eram reais. A carta também é. A tarefa 4.2 do guia do exame pede que você descreva a diferença entre modelos transparentes e explicáveis e modelos que não são, e que identifique as concessões envolvidas, o que significa que o exame espera que você segure os dois fatos ao mesmo tempo em vez de escolher um lado.

Três palavras que o exame mantém separadas

O domínio 4 usa três palavras próximas, e o tópico anterior já separou duas delas. Aqui está o conjunto completo, com a terceira acrescentada.

Transparência e explicabilidade são duas das oito dimensões de IA responsável da AWS. Interpretabilidade não é: ela aparece na redação do objetivo do exame ("medir interpretabilidade e desempenho") e na orientação de engenharia da AWS, mas não na lista de dimensões. Guarde isso, porque uma questão perguntando qual dimensão está em jogo não vai oferecer interpretabilidade como resposta.

A relação entre as três cabe numa frase. Interpretabilidade é uma propriedade que você constrói ou não constrói; explicabilidade é o que você consegue produzir depois, nos dois casos; transparência é o que você conta às pessoas sobre o resultado.

Como é um modelo interpretável por dentro

Pegue a versão A, a logistic regression. Ela produz um score em log-odds, e o modelo inteiro é esta linha:

score = -1,8
      + 0,9 x (valor do sinistro acima de $5.000)
      + 1,4 x (apólice com menos de 90 dias)
      + 0,7 x (sinistro anterior nos últimos 12 meses)
      - 0,6 x (sinistro aberto pelo aplicativo)

Agora passe um sinistro por ela. Um sinistro de $7.400, sobre uma apólice aberta há 46 dias, de um cliente com 1 sinistro anterior no último ano, aberto por telefone:

score       = -1,8 + 0,9 + 1,4 + 0,7 - 0 = 1,2
probabilidade = 1 / (1 + e^-1,2) = 0,77

Com limiar de 0,5, o sinistro vai para o analista. E você consegue dizer exatamente por quê, sem rodar mais nada. O termo de idade da apólice contribuiu com +1,4, o maior empurrão individual. Tire ele e o score cai para -0,2, uma probabilidade de 0,45, abaixo do limiar. Então a frase honesta é: este sinistro foi separado porque a apólice tem 46 dias, e não teria sido separado de outra forma.

Repare no que aconteceu. O contrafactual saiu da aritmética, não de uma segunda ferramenta. É isso que a interpretabilidade compra. Uma decision tree te dá a mesma coisa em outro formato: uma previsão é um caminho da raiz até a folha, e você pode imprimir o caminho como regra ("apólice com menos de 90 dias, e valor acima de $5.000, e canal diferente do aplicativo, então revisar").

O que faz de um modelo uma caixa-preta

A versão B é um ensemble de 800 árvores, cada uma com cerca de 6 níveis, cujas saídas são somadas. Você tem todas as árvores. Você tem todos os cortes. Nada está escondido de você.

É aqui que mora o erro previsível, então diga em voz alta: uma caixa-preta não é um modelo que alguém está escondendo de você. Sigilo e opacidade são problemas diferentes. Você pode ser dono dos pesos, hospedar o modelo por conta própria, imprimir cada parâmetro, e ainda assim não conseguir declarar a razão de uma previsão, porque a razão está distribuída entre milhares de decisões pequenas que interagem e não existe nenhum lugar no modelo onde ela esteja escrita. Um modelo de linguagem de 70 bilhões de parâmetros é a mesma situação numa escala maior.

Então a opacidade vem da estrutura, não do acesso. É por isso que abrir o código de um modelo o torna transparente num sentido (dá para ver o que ele é) e não faz absolutamente nada pela interpretabilidade dele.

Recuperar a explicação depois do fato

Se o modelo não se explica sozinho, você calcula uma explicação sobre ele por fora. Isso é explicação posterior, e o método que o exame nomeia é o SHAP.

O Amazon SageMaker Clarify usa uma abordagem de atribuição de features agnóstica ao modelo, construída sobre o SHAP (SHapley Additive exPlanations), que vem da teoria dos jogos cooperativos. Um valor de Shapley responde a uma pergunta de repartição: se vários jogadores cooperam para produzir um pagamento, quanto desse pagamento cabe a cada um? Troque jogadores por features de entrada e o pagamento pela previsão, e você tem um número de contribuição por feature para uma previsão específica. Como ele trata o modelo como uma função que consegue chamar, e não como uma estrutura que precisa ler, funciona sobre modelos cujo interior não significa nada para ele.

Passe o mesmo sinistro pela versão B e o Clarify devolve algo assim:

valor base (previsão média)          0,31
  apólice com menos de 90 dias      +0,28
  valor do sinistro $7.400          +0,11
  1 sinistro anterior em 12 meses   +0,06
  aberto por telefone, não pelo app -0,03
  todas as demais features          +0,04
                                    -----
previsão                             0,77

As contribuições somam a previsão, e essa é a propriedade que define o método. Agora você tem uma frase para colocar na carta ao advogado.

O Clarify também produz partial dependence plots, que mostram o efeito marginal de uma feature sobre o resultado previsto ao longo do intervalo dela, e aplica o mesmo algoritmo de Shapley a entradas de visão computacional e de processamento de linguagem natural, não só a dados tabulares.

Daí saem dois tipos de explicação, e o exame diferencia os dois:

Um regulador perguntando como o modelo funciona quer a visão global. Um cliente perguntando sobre o próprio sinistro quer a local. Entregar a errada soa como evasiva.

Toda explicação responde a "em vez do quê?"

Esta é a parte que a maioria das pessoas encontra pela primeira vez e que muda a leitura de qualquer gráfico SHAP daí em diante.

A AWS afirma isso diretamente: explicações costumam ser contrastivas, ou seja, elas consideram desvios em relação a um baseline, então para a mesma previsão do modelo você pode esperar explicações diferentes contra baselines diferentes. Durante o cálculo de Shapley, o Clarify constrói instâncias entre o baseline e a sua instância, onde a ausência de uma feature é modelada pegando o valor do baseline para ela e a presença pegando o valor da sua instância. Ausência de tudo é o baseline; presença de tudo é o seu sinistro.

Então o baseline não é um detalhe técnico. O baseline é a pergunta.

• Um baseline não informativo é uma instância de baixa informação, como a mediana para features numéricas e a moda para categóricas. Ele responde: por que este sinistro, comparado com um sinistro típico? Se você não fornecer nenhum, o Clarify constrói um automaticamente usando K-means ou K-prototypes sobre os dados de entrada.
• Um baseline informativo representa um grupo que te interessa. A AWS dá o caso de admissões universitárias: explicar por que este candidato foi rejeitado em comparação com outros candidatos de contexto parecido, igualando os atributos sobre os quais não se pode agir aos valores da própria instância. O que sobra na explicação é o que realmente difere.

De volta ao sinistro. Contra um sinistro típico, a idade da apólice domina a resposta com +0,28, e essa é uma constatação verdadeira e meio inútil: toda apólice nova tem 46 dias em algum momento. Contra um baseline de outros sinistros em apólices com menos de 90 dias, a idade da apólice some da explicação e o valor do sinistro e o histórico anterior passam a carregá-la. Mesmo modelo, mesma previsão, duas respostas diferentes e as duas corretas, porque responderam a duas perguntas diferentes.

A concessão que o exame nomeia

A AWS declara a tensão sem rodeios no Well-Architected Machine Learning Lens: modelos complexos como redes neurais profundas podem entregar acurácia maior mas costumam ser mais difíceis de interpretar, enquanto modelos mais simples como decision trees ou linear regression dão explicações mais diretas e podem abrir mão de algum desempenho. Um whitepaper mais antigo da AWS coloca isso de forma mais crua: os métodos de melhor desempenho costumam ser os menos explicáveis, e os mais explicáveis são menos precisos.

O lens não manda escolher sempre uma das pontas. Ele manda deixar o caso de uso decidir, e dá dois exemplos contrastantes: um sistema de aprovação de crédito pode precisar de explicações claras sobre por que pedidos foram negados, enquanto um sistema de controle de qualidade industrial pode razoavelmente priorizar acurácia. Riscos diferentes, resposta diferente.

Ele também lista os antipadrões, e vale ler cada um como um distrator de prova invertido:

• Tratar modelos como incógnitas, sem entender como eles decidem.
• Ignorar requisitos de explicabilidade até depois do deploy.
• Priorizar métricas de desempenho sobre interpretabilidade quando o negócio ou a regulação exige explicabilidade.
• Deixar de documentar as explicações do modelo para fins regulatórios.
• Usar modelos complexos quando alternativas mais simples e interpretáveis atenderiam ao requisito.

Esse último é o que as pessoas violam por padrão, e é por isso que "escolher o modelo mais interpretável que atenda à barra de acurácia" é um hábito melhor do que "escolher o modelo mais preciso e pendurar SHAP nele".

Uma ressalva honesta. A concessão é uma tendência forte, não uma lei da natureza. Muitos problemas tabulares são resolvidos igualmente bem por um modelo linear bem regularizado e por um ensemble grande, e você só descobre isso medindo. É exatamente para isso que aponta a expressão "medir interpretabilidade e desempenho" no objetivo do exame, e o lens detalha a prática: defina métricas de explicabilidade como estabilidade da importância de features, fidelidade da explicação ou consistência, e avalie essas métricas ao lado de acurácia ou F1 em vez de presumir o ranking.

Transparência e segurança também puxam em direções opostas

O objetivo do exame fala em "concessões entre segurança do modelo e transparência", e essa é uma segunda tensão, não uma reformulação da primeira. Divulgar tem custo, e os próprios produtos da AWS mostram isso.

• O AI Service Card do Amazon Nova Reel afirma que os filtros de segurança dele não podem ser configurados nem desligados. Um controle que você não consegue inspecionar nem ajustar é uma perda real de transparência, aceita porque um filtro de segurança ajustável é um filtro que um atacante ou um operador descuidado consegue enfraquecer.
• A detecção de abuso do Amazon Bedrock é totalmente automatizada, sem revisão humana nem acesso humano às entradas e saídas dos usuários. Isso protege a privacidade e custa a você a possibilidade de uma pessoa olhar o que o sistema viu.
• O Amazon Bedrock Guardrails trata vazamento de prompt como um ataque de prompt a filtrar, porque um system prompt publicado é um mapa para quem quer contorná-lo.
• Publicar pesos, detalhes de arquitetura e composição dos dados de treinamento ajuda pesquisadores a auditar um modelo e ajuda adversários a montar ataques contra ele com a mesma informação.

Existe uma versão mais sutil disso no design das explicações. Uma explicação detalhada o bastante para satisfazer a pessoa afetada costuma ser detalhada o bastante para ser burlada. Diga aos candidatos negados que 7 consultas de crédito em 6 meses foi o que virou a decisão, e alguns vão corrigir o comportamento financeiro enquanto outros vão simplesmente esperar 7 meses e voltar com o mesmo risco por baixo. Detecção de fraude deixa isso mais nítido: um modelo de fraude totalmente explicado é um tutorial de como cometer a fraude que ele não vai pegar.

Nada disso defende opacidade. Isso defende que a quantidade certa de divulgação é uma decisão com dois lados, tomada por caso de uso e por público, que é onde a terceira lição deste tópico continua.

Onde os modelos generativos entram nisso

Tudo acima pressupunha colunas de features às quais atribuir uma previsão. Um chatbot respondendo a uma pergunta de suporte não tem essas colunas, então SHAP sobre features tabulares não tem onde se apoiar.

O que entra no lugar é outro conjunto de ferramentas, todas já conhecidas:

• Citações de recuperação. Uma aplicação de RAG que devolve os trechos de origem por trás da resposta oferece a coisa mais próxima de uma explicação local que um LLM dá, porque a resposta é rastreável até um documento que você consegue ler.
• Scores de fundamentação. Os contextual grounding checks do Guardrails pontuam se a resposta é sustentada pelo material de origem, e isso é uma afirmação mensurável sobre a saída em vez de uma história sobre o modelo.
• Similaridade de embeddings. Os AI Service Cards do Nova sugerem comparar embeddings do prompt e da saída gerada para verificar se a saída é consistente com o que foi pedido.
• Avaliação. As evaluations do Bedrock dizem como um modelo se comporta ao longo de muitas entradas, que é uma explicação global na única forma disponível.

Repare no que falta na lista da AWS: pedir que o modelo explique a si mesmo. O raciocínio declarado por um modelo é texto que ele gerou, produzido pelo mesmo processo que produziu a resposta, então pode ser fluente, plausível e não ser relato nenhum do que foi computado. Trate raciocínio autonarrado como sinal útil de depuração, não como evidência.

Dicas para a prova

• "Entender por que esta saída específica aconteceu" é explicabilidade. "Permitir que as partes interessadas tomem decisões informadas sobre o sistema" é transparência. Interpretabilidade é propriedade da arquitetura do modelo e não é uma das oito dimensões.
• Linear regression, logistic regression, decision trees e sistemas baseados em regras são os modelos interpretáveis da prova. Redes neurais profundas, ensembles grandes e modelos de fundação são as caixas-pretas. Uma questão que nomeia uma família de modelos geralmente está testando essa divisão.
• Uma caixa-preta é opaca por estrutura, não por sigilo. Uma alternativa afirmando que abrir o código de um modelo o torna interpretável está errada.
• O SHAP é agnóstico ao modelo e por previsão, então é a resposta para "por que o modelo rejeitou este candidato". Importância de features agregada e partial dependence plots respondem a "como o modelo se comporta no geral".
• Duas concessões vivem na tarefa 4.2 e elas são diferentes: interpretabilidade contra desempenho (arquitetura) e transparência contra segurança (divulgação). Leia o enunciado para ver qual está em jogo.
• "Usar um modelo complexo quando um mais simples atenderia ao requisito" é um antipadrão nomeado pela AWS, então uma alternativa que recomenda o modelo mais simples que atende à barra costuma ser a correta.

O que levar desta lição: explicabilidade não é uma chave que você liga depois do treinamento, é um requisito que você decide antes de escolher o modelo, porque a decisão que determina o quanto o seu sistema pode ser explicável é a escolha da arquitetura. A próxima lição trata dos artefatos que registram essas decisões, para que seis meses depois alguém que não seja você consiga descobrir para que o modelo servia e no que ele é ruim.