Explicabilidade para Usuários

Visão geral: explicabilidade *para usuários* (não apenas para desenvolvedores)

“Explicabilidade para usuários” é a prática de apresentar informações sobre o comportamento de um sistema de I.A. de uma forma que ajude as pessoas que usam o sistema a tomar decisões melhores, entender limitações e calibrar adequadamente a confiança. Ela difere da interpretabilidade voltada para desenvolvedores (depuração (debugging), introspecção de atributos (feature introspection)) porque os critérios de sucesso são centrados no ser humano:

  • Qualidade da decisão: o usuário age com mais segurança e eficácia?
  • Compreensão: o usuário consegue prever quando o sistema vai falhar?
  • Contestabilidade e recurso (contestability and recourse): o usuário consegue contestar ou corrigir resultados?
  • Calibração: a confiança corresponde à confiabilidade real do modelo? (Veja Confiança, Dependência Excessiva e Calibração.)
  • Eficiência: as explicações reduzem o tempo até a ação sem sobrecarregar o usuário?

Um bom enquadramento é: o que mostrar, quando mostrar e como evitar explicações enganosas. O objetivo não é “justificar” o modelo, mas ajudar o usuário a formar um modelo mental preciso do que o sistema pode e não pode fazer.

Fundamentos teóricos (as ideias que orientam boas escolhas de UX)

Modelos mentais e atenção limitada

Usuários constroem “histórias” simplificadas de como um sistema funciona. Explicações devem ajudar os usuários a construir um modelo mental preditivo (“quando isso vai dar errado?”), e não um mecanicista (“como os transformadores (transformers) funcionam internamente?”). Usuários têm atenção limitada; explicações detalhadas demais frequentemente são ignoradas ou usadas de forma indevida.

Implicação: Prefira explicações acionáveis e baseadas em cenários em vez de detalhes técnicos brutos. Use divulgação progressiva (progressive disclosure): mostre o mínimo necessário, com profundidade opcional.

Fidelidade vs. interpretabilidade vs. utilidade

Uma explicação pode ser:

  • Alta fidelidade: corresponde de perto ao comportamento do modelo
  • Interpretável: fácil de humanos entenderem
  • Útil: melhora as decisões do usuário

Frequentemente, não é possível maximizar as três ao mesmo tempo. Por exemplo, um modelo profundo (deep model) complexo pode ser explicado com uma regra prática simples (interpretável), mas isso pode ter baixa fidelidade.

Implicação: Para explicações voltadas a usuários, priorize utilidade e honestidade sobre incerteza, e rotule claramente aproximações.

Explicações locais vs. globais

  • Explicação local: por que esta saída aconteceu (nível de instância).
  • Explicação global: como o sistema se comporta no geral (nível de classe/sistema).

Implicação: A maioria dos usuários precisa de explicações locais durante tarefas e de explicações globais durante o onboarding, revisão de políticas ou ao decidir se deve confiar no sistema.

Causalidade vs. correlação (uma fonte comum de explicações enganosas)

Muitas técnicas de explicação descrevem associações (atributos correlacionados com uma previsão), não causas.

Implicação: Evite linguagem causal (“porque X causou Y”) a menos que você tenha um modelo causal ou evidência forte. Prefira formulações como “o modelo se baseou em...” ou “este fator aumentou a pontuação...”.

Calibração e incerteza

Usuários interpretam números (pontuações, “confiança (confidence)”) como probabilidades mesmo quando não são calibrados.

Implicação: Se você mostrar confiança, garanta que ela seja significativa (por exemplo, calibrada) e contextualizada (por exemplo, “a confiança é menor para condições raras / imagens de baixa qualidade”).

O que mostrar: conteúdo de explicação que mais ajuda usuários

Usuários diferentes precisam de conteúdos diferentes. Um clínico, um solicitante de empréstimo e um agente de call center têm objetivos distintos. Ainda assim, a maior parte da explicabilidade voltada a usuários pode ser composta a partir de um pequeno conjunto de blocos de construção.

1) A saída, em um formato pronto para decisão

A explicabilidade começa com o resultado apresentado com clareza.

  • Use linguagem do usuário (“Provável spam”), não rótulos internos (“class=1”)
  • Forneça contexto de limiar se houver um corte (“marcado porque pontuação ≥ 0.80”)
  • Mostre alternativas quando apropriado (“Top 3 diagnósticos sugeridos”)

2) Sinais de incerteza e confiabilidade (com cuidado)

Sinais úteis de confiabilidade incluem:

  • Bandas de confiança (não apenas um único número)
  • Alertas de qualidade (“a imagem está borrada; a previsão pode ser pouco confiável”)
  • Indicadores fora da distribuição (out-of-distribution) (“esta entrada parece diferente dos dados de treinamento”)
  • Etiquetas de limitação conhecida (“o sistema é menos preciso para fala de não nativos”)

O que usuários geralmente interpretam mal:

  • “Confiança” não calibrada a partir de probabilidades softmax
  • Números com aparência de precisão sem contexto (“0.8732”)

Padrão prático:

  • Use categorias grosseiras (“Alta / Média / Baixa confiabilidade”) com hover/clique para detalhes.
  • Acrescente o porquê de a confiabilidade ser baixa (campos faltantes, baixa qualidade do sinal, incompatibilidade de domínio).

3) Evidências: as entradas nas quais o sistema se baseou

Evidências frequentemente são mais úteis do que pesos de atributos abstratos.

Exemplos:

  • Para assistentes baseados em recuperação (retrieval-based): citações e trechos destacados que sustentam afirmações
  • Para modelos de documentos: trechos realçados usados para classificação
  • Para recomendadores: “Porque você assistiu X e gostou de Y”

As evidências devem ser inspecionáveis e verificáveis quando possível, o que é especialmente importante para sistemas generativos modernos.

4) Motivos (mas rotule como motivos do modelo, não como verdade)

Formas comuns de “motivos”:

  • Atribuição de atributos (feature attribution): quais entradas mais contribuíram
  • Explicações baseadas em exemplos (example-based explanations): casos passados semelhantes
  • Sumários baseados em regras (rule-based summaries): condições simplificadas que aproximam o comportamento
  • Racionalizações em linguagem natural (natural-language rationales): uma justificativa textual produzida por um modelo

Cada uma pode ajudar — mas cada uma pode enganar se apresentada como verdade absoluta.

Diretriz: Apresente motivos como “sinais que o modelo usou”, e não como “o motivo do mundo real”.

5) Contrafactuais e recurso (o que mudaria o resultado)

Explicações contrafactuais (counterfactual explanations) respondem: “Que mudança mínima produziria um resultado diferente?”

Exemplo (empréstimo):

  • “Se a renda declarada fosse $5.000 maior (ou a dívida $2.000 menor), a solicitação provavelmente seria aprovada.”

Contrafactuais frequentemente são a explicação mais acionável para usuários finais, mas devem ser restringidos a mudanças realistas e éticas. Também podem ser sensíveis (por exemplo, sugerir mudanças de estado civil é inadequado).

6) Limites e políticas do sistema (o que ele não fará)

Especialmente para modelos generativos, usuários se beneficiam de transparência de guarda-corpos (guardrails):

  • Categorias de conteúdo permitido/proibido
  • “Esta resposta é informativa, não é aconselhamento médico”
  • “Não podemos acessar sua conta bancária; estimativas podem estar incompletas”

Isso se conecta fortemente a padrões de design de produto em UX para Produtos de I.A..

7) Proveniência e tratamento de dados (quando relevante)

Em domínios como contratação, educação, finanças e saúde, usuários podem precisar de:

  • Quais fontes de dados foram usadas (e quais não foram)
  • Atualidade dos dados (“última atualização há 7 dias”)
  • Se os dados do usuário são armazenados ou usados para treinamento (expectativas de privacidade)

Tipos de explicações: o que funciona quando (e armadilhas comuns)

Atribuição de atributos (por exemplo, explicações no estilo SHAP)

Bom para: decisões tabulares (pontuação de crédito), entradas estruturadas
Valor para o usuário: transparência sobre fatores influentes
Armadilhas: pode sugerir causalidade; pode variar com atributos correlacionados; pode ser instável

Exemplo de formulação na UI:

  • “Fatores que aumentaram a pontuação: …”
  • “Fatores que diminuíram a pontuação: …”
  • Acrescente uma observação: “Esses fatores refletem padrões do modelo; não são necessariamente causais.”

Exemplo mínimo (semelhante a Python) usando saída no estilo SHAP para ranquear fatores:

# Pseudocode: produce top contributing features for a single prediction
prediction = model.predict_proba(x)[1]

shap_values = explainer.shap_values(x)  # vector per feature
top_pos = sorted(features, key=lambda f: shap_values[f], reverse=True)[:3]
top_neg = sorted(features, key=lambda f: shap_values[f])[:3]

explanation = {
  "prediction": prediction,
  "increased_score": [(f, shap_values[f]) for f in top_pos],
  "decreased_score": [(f, shap_values[f]) for f in top_neg],
  "note": "Contributions describe model behavior; not necessarily causal."
}

Explicações baseadas em exemplos (protótipos, vizinhos mais próximos)

Bom para: domínios baseados em casos (tickets de suporte, imagem médica, moderação de conteúdo)
Valor para o usuário: “Mostre casos semelhantes” é intuitivo
Armadilhas: vazamento de privacidade (privacy leakage); “similaridade” depende da representação; pode codificar viés

Boa prática:

  • Mostrar por que algo é considerado semelhante (atributos compartilhados)
  • Usar sumários que preservem a privacidade quando necessário

Explicações contrafactuais

Bom para: recurso do usuário, suporte à decisão
Armadilhas: pode sugerir mudanças irrealistas; pode explorar peculiaridades do modelo; pode conflitar com restrições de política

Boa prática:

  • Restringir contrafactuais a ações viáveis (por exemplo, “fornecer documentos faltantes” em vez de “mudar idade”)
  • Validar se as mudanças propostas são estáveis, e não truques frágeis

Racionalizações em linguagem natural (texto de explicação gerado)

Bom para: resumos rápidos, interfaces conversacionais
Armadilhas: racionalizações podem soar plausíveis, mas não fiéis (“storytelling pós-hoc”). Para modelos de linguagem de grande porte (large language models, LLMs), a racionalização pode não refletir o cálculo interno real.

Boa prática:

  • Tratar racionalizações como texto de interface, não como verdade absoluta
  • Preferir racionalizações sustentadas por evidências (citações, trechos, campos extraídos)
  • Evitar linguagem antropomórfica (“Eu acho...”)

Mapas de atenção e de saliência (visão e transformadores)

Bom para: depuração por especialistas, às vezes para usuários especialistas
Armadilhas: saliência pode ser instável; atenção não é uma explicação garantida de causalidade ou importância

Boa prática:

  • Se exibidos a usuários, enquadrar como “áreas mais associadas à previsão” e validar, em estudos, que isso melhora o desempenho do usuário.

Quando mostrar: timing e divulgação progressiva

Um princípio-chave de UX é a divulgação progressiva: mostrar por padrão a explicação mais simples e útil, e permitir que usuários expandam quando necessário.

Momentos comuns para fornecer explicações

1) No ponto de decisão (inline, mínimo)

Melhor para: fluxos de trabalho rotineiros em que usuários precisam de validação rápida.

Exemplo (filtro de spam):

  • Rótulo + 1–2 pistas: “Marcado como spam: domínio de link suspeito, padrão de envio em massa.”
  • Link opcional “Detalhes”.

2) Quando o sistema está incerto ou o risco é alto (interruptivo)

Melhor para: triagem em saúde, decisões jurídicas/financeiras, ações críticas para segurança.

Exemplo:

  • “Baixa confiabilidade: sinais vitais ausentes e sintomas atípicos. Considere revisão manual.”

É aqui que a explicabilidade apoia caminhos seguros de escalonamento (veja UX para Produtos de I.A.).

3) Sob demanda (“Por quê?” / “Como?”)

Melhor para: usuários avançados, auditores, resultados contestados.

Padrão:

  • Um painel “Por que este resultado?” com:
    • evidências
    • principais fatores
    • contrafactuais
    • limitações conhecidas
    • mecanismo de denúncia/apelação

4) Durante o onboarding (expectativas globais)

Melhor para: definir expectativas corretas desde cedo.

Inclua:

  • Modos típicos de falha
  • Quais entradas importam
  • Como interpretar confiança/confiabilidade
  • Exemplos de usos corretos e incorretos

5) Após um erro ou correção do usuário (ciclo de aprendizado)

Quando usuários dão feedback (“isso está errado”), mostre:

  • o que o sistema achou que viu
  • como corrigir (“marcar como não spam”)
  • o que acontecerá com o feedback

Isso se conecta a Coleta de Feedback Humano: UX de feedback e gestão de expectativas fazem parte da explicabilidade.

Como evitar explicações enganosas (a parte mais difícil)

Explicações enganosas podem aumentar danos ao criar confiança injustificada. Modos de falha comuns incluem:

1) Explicações persuasivas em vez de fiéis

Se a “explicação” é otimizada para soar bem (ou reduzir reclamações) em vez de refletir o comportamento, usuários podem confiar demais.

Mitigações:

  • Prefira explicações ancoradas em evidência observável (citações, campos extraídos)
  • Separe “texto de ajuda” de “evidência do modelo”
  • Avalie se explicações melhoram a calibração, não apenas a satisfação

2) Confundir correlação com causalidade

Atribuição de atributos frequentemente reflete proxies correlacionados (por exemplo, CEP servindo de proxy para raça).

Mitigações:

  • Evite formulações causais a menos que sejam justificadas
  • Inclua avisos de equidade e de proxies quando relevante (veja Equidade em Aprendizado de Máquina)
  • Teste a estabilidade das explicações sob perturbações plausíveis

3) Histórias globais simplificadas demais

Uma única narrativa global (“o modelo verifica renda e dívida”) pode ser reconfortante, mas falsa se o modelo usa muitas interações.

Mitigações:

  • Use linguagem de “fatores típicos”
  • Forneça explicitamente “exceções e casos de falha”
  • Ofereça um cartão do modelo (model card) global / resumo de comportamento (veja Cartões de Modelo)

4) Exibições de confiança não calibrada

Um selo de “92% confiante” pode ser interpretado como “92% de chance de estar correto”, o que pode estar errado.

Mitigações:

  • Calibre probabilidades quando possível (veja Calibração)
  • Use categorias de confiabilidade com contexto
  • Mostre desempenho histórico por segmento quando apropriado (sem vazar atributos sensíveis)

5) Racionalizações pós-hoc para sistemas generativos

LLMs podem produzir explicações coerentes que não refletem o cálculo interno e podem citar fontes inexistentes.

Mitigações:

  • Prefira respostas sustentadas por recuperação (retrieval-backed) com citações (veja Geração Aumentada por Recuperação)
  • Marque claramente quando não há fontes disponíveis
  • Adicione comportamentos de “posso estar errado” vinculados a sinais de incerteza e políticas de recusa

6) Vazamento de informações sensíveis por meio de explicações

Mostrar “casos semelhantes” ou exemplos de treinamento pode vazar dados privados. Até mesmo a atribuição de atributos pode revelar inferência sensível.

Mitigações:

  • Aplique restrições de privacidade, redação e agregação
  • Evite expor exemplares brutos em domínios sensíveis
  • Considere Privacidade Diferencial para estratégias de treinamento e logging

7) Explicações que aumentam risco de fraude e segurança

Contrafactuais e listas detalhadas de fatores podem permitir manipulação adversária (por exemplo, fraudadores ajustando entradas).

Mitigações:

  • Limite a taxa e o nível de detalhe; forneça passos de recurso mais gerais
  • Detecte comportamento suspeito; varie a divulgação por papel do usuário
  • Use explicações cientes de políticas (“Forneça comprovação de renda”) em vez de limiares numéricos

Padrões práticos de design (como é uma boa explicabilidade voltada a usuários)

Padrão: “Confiança com motivo”

Em vez de “Confiança: 0.82”, mostre:

  • Confiabilidade: Média
  • “Motivo: 2 campos obrigatórios ausentes; combinação incomum de sintomas.”

Padrão: “Por quê?” com evidência primeiro

Para um sumarizador de I.A.:

  • “Resumo” + “Mostrar trechos de suporte” que destaca as sentenças de origem usadas.
  • Se o sistema for generativo sem fontes, rotule explicitamente: “Sem fontes disponíveis; verifique antes de usar.”

Padrão: “O que mudaria isso?”

Para uma apelação de moderação de conteúdo:

  • “Marcado devido a: texto de ameaça violenta.”
  • “Para estar em conformidade: remova ameaças e reenvie.”
  • Forneça um caminho de apelação se o usuário discordar.

Padrão: Divulgação baseada em papéis

  • Usuários finais: explicação acionável, não técnica
  • Revisores/auditores: fatores detalhados, logs, versão do modelo, limiares
  • Desenvolvedores: ferramentas de interpretabilidade em nível de depuração

O acesso baseado em papéis reduz sobrecarga e risco de segurança.

Exemplos trabalhados (de ponta a ponta)

Exemplo 1: Pré-aprovação de empréstimo (modelo tabular)

O que mostrar (padrão):

  • Decisão: “Não pré-aprovado”
  • Confiabilidade: “Alta” (solicitação completa, perfil típico)
  • Principais fatores (linguagem não causal):
    • Aumentou a pontuação: “Longo histórico de emprego”
    • Diminuiu a pontuação: “Alta relação dívida/renda”
  • Recurso:
    • “Se a relação dívida/renda fosse ~5% menor, a aprovação se tornaria provável”
    • “Ou adicione um co-solicitante”

Quando mostrar mais:

  • Em “Por quê?”: mostrar detalhamento adicional de fatores + como a relação é calculada
  • Em apelação: mostrar dados usados e permitir correções (campos de renda e dívida)

Evitar enganos:

  • Não afirme “você foi rejeitado por causa de X” como uma única causa
  • Não mostre limiares exatos se isso aumentar o risco de manipulação
  • Garanta que explicações de conformidade estejam alinhadas com política e regulação

Exemplo 2: Triagem de imagem clínica (modelo de visão)

O que mostrar (padrão):

  • “Precisa de revisão urgente” vs “Revisão de rotina”
  • Confiabilidade: “Baixa” se a qualidade da imagem for ruim
  • Evidência: sobreposição de saliência apenas para clínicos (opcional), além de métricas de qualidade

Quando mostrar:

  • Sempre mostrar confiabilidade e alerta de qualidade (alto risco)
  • Incentivar segunda leitura quando incerto

Evitar enganos:

  • Não apresente mapas de calor como “prova”; rotule como “áreas associadas à previsão”
  • Validar com clínicos se as sobreposições melhoram resultados

Exemplo 3: Assistente de suporte ao cliente (modelo de linguagem de grande porte + recuperação)

O que mostrar (padrão):

  • Rascunho de resposta sugerida
  • “Fontes: 2 documentos internos” com citações clicáveis

Quando mostrar:

  • Citações inline sempre (reduz dano por alucinação)
  • “Como isso foi formado” expandido sob demanda: passagens recuperadas, restrições de política

Evitar enganos:

  • Não mostre uma racionalização fluente sem fontes
  • Se as fontes entrarem em conflito ou estiverem ausentes, mostre um alerta e sugira escalonamento

Construindo explicabilidade no sistema (não adicionando depois)

A explicabilidade é mais fácil quando tratada como requisito de produto:

  • Registro (logging) e rastreabilidade: armazenar versão do modelo, atributos usados, documentos recuperados, limiares
  • Estimativa de incerteza: construir sinais de confiabilidade (verificações fora da distribuição, calibração de confiança)
  • Caminhos de humano no loop (human-in-the-loop): fluxos de “revisão manual” e “reportar problema”
  • Avaliação com usuários: testar se explicações melhoram calibração e decisões, não apenas confiança percebida

Isso está fortemente conectado a Coleta de Feedback Humano (fechando o ciclo) e Confiança, Dependência Excessiva e Calibração (medindo dependência apropriada).

Avaliando explicações voltadas a usuários

Uma boa avaliação vai além de “usuários gostam?”

Medidas quantitativas

  • Melhoria de calibração: usuários dependem menos quando o modelo provavelmente está errado?
  • Acurácia / segurança da decisão: taxa de sucesso na tarefa com vs sem explicações
  • Detecção de erros: com que frequência usuários identificam saídas erradas do modelo
  • Tempo até a decisão: a explicação adiciona ou reduz fricção?

Medidas qualitativas

  • Entrevistas com usuários: eles entendem modos de falha?
  • Testes de usabilidade: eles percebem pistas de incerteza?
  • Testes de red team (red-team testing): explicações permitem manipulação?

Cuidados com testes A/B (A/B testing)

Explicações podem aumentar conformidade mesmo quando o modelo está errado. Acompanhe dano downstream e dependência excessiva, não apenas engajamento.

Checklist: o que mostrar, quando mostrar, como não enganar

O que mostrar

  • Saída + contexto de limiar
  • Confiabilidade/incerteza com motivos
  • Evidência (fontes, destaques)
  • “Motivos” do modelo formulados de modo não causal
  • Recurso contrafactual (quando apropriado)
  • Limitações, escopo e limites de política
  • Informações de proveniência/privacidade dos dados (conforme necessário)

Quando mostrar

  • Inline mínimo no momento da decisão
  • Alertas mais fortes quando incerto ou de alto risco
  • Detalhes mais profundos sob demanda
  • Comportamento global e modos de falha durante o onboarding
  • Após erros e envios de feedback

Evitar enganos

  • Não implique causalidade sem suporte causal
  • Não mostre confiança não calibrada como probabilidade
  • Não use racionalizações persuasivas sem evidência
  • Não exponha dados sensíveis nem permita manipulação fácil
  • Valide com estudos com usuários: meça calibração e resultados, não apenas satisfação

A explicabilidade para usuários é, em última análise, uma disciplina de interação humano–I.A.: ela combina métodos de interpretabilidade com UX cuidadosa, gestão de risco e testes empíricos para garantir que o que usuários veem os ajude a tomar decisões melhores — sem serem enganados.