Análise de Erros (Slicing)

O que é análise de erros por fatiamento (error analysis slicing)?

Análise de erros (error analysis) por fatiamento (slicing) é uma técnica de avaliação baseada em coortes (cohorts): você divide seus dados de avaliação em fatias (slices) (também chamadas de coortes (cohorts), segmentos (segments) ou subgrupos (subgroups)) e mede o desempenho do modelo dentro de cada fatia para descobrir modos de falha (failure modes) e priorizar melhorias.

As métricas agregadas (aggregate metrics) (acurácia (accuracy), F1 (F1), área sob a curva ROC (AUROC), etc.) podem parecer saudáveis enquanto o modelo falha gravemente em subconjuntos importantes — como certos tipos de clientes, dispositivos, idiomas ou condições de casos-limite (edge cases). O fatiamento torna esses problemas visíveis e acionáveis.

O fatiamento é uma parte central da avaliação prática de aprendizado de máquina (machine learning, ML), junto com escolher Métricas apropriadas, usar Validação e Validação Cruzada robustas, lidar com Desbalanceamento de Classes e verificar a qualidade das probabilidades via Calibração.

Por que o desempenho geral esconde problemas

Métricas agregadas fazem média sobre a distribuição dos dados. Isso pode mascarar:

  • Falhas raras, mas críticas (ex.: “a acurácia é 99%”, mas perde a maioria dos casos de fraude).
  • Desempenho desigual entre coortes (ex.: pior reconhecimento de fala para certos sotaques).
  • Mudança de domínio (domain shift) (ex.: o modelo funciona em imagens da web, mas falha em imagens de câmera de celular).
  • Artefatos de rotulagem (labeling artifacts) (ex.: uma fonte de dados tem rótulos mais ruidosos).
  • Restrições operacionais (operational constraints) (ex.: restrições de latência forçam um pré-processamento diferente para alguns usuários).

Dois motivos comuns para agregados serem enganosos:

  1. Misturar exemplos fáceis e difíceis: o modelo pode ser excelente em casos fáceis que dominam o conjunto de dados.
  2. Paradoxo de Simpson (Simpson’s paradox): tendências dentro das fatias podem ser o oposto da tendência no agregado devido a fatores de confusão (ex.: tipo de dispositivo correlaciona com geografia e iluminação).

Conceitos-chave e terminologia

Fatia (coorte)

Uma fatia é um subconjunto de exemplos definido por uma condição em metadados (metadata) ou atributos, como:

  • country == "BR"
  • device_type == "low_end_android"
  • age_bucket == "65+"
  • text_language == "es"
  • image_brightness < threshold

As fatias podem ser:

  • De um único atributo (simples) ou multivariadas/interseccionais (ex.: language=es AND device=low_end_android).
  • Estáticas (demografia, região) ou dinâmicas (confiança do modelo, incerteza, tempo).

Modo de falha

Um modo de falha é um padrão recorrente de erros com uma causa coerente (dados, modelo ou sistema). As fatias ajudam você a localizar modos de falha; uma inspeção mais profunda explica por que eles acontecem.

Severidade vs. impacto

Ao priorizar fatias, normalmente você quer ambos:

  • Severidade: quão ruim é o desempenho na fatia? (ex.: FNR = 40%)
  • Impacto: o quanto isso importa? frequentemente aproximado pelo tamanho da fatia, custo de negócio ou exposição a risco

Uma fatia pequena com erros catastróficos pode, ainda assim, ficar acima de uma fatia grande com degradação leve se o custo for alto (ex.: segurança médica).

Fundamentos teóricos: o que o fatiamento está estimando

Em alto nível, o fatiamento estima desempenho condicional (conditional performance):

[ \text{Desempenho}(S) = \mathbb{E}[;m(y,\hat{y}) \mid x \in S;] ]

onde:

  • (S) é uma definição de fatia,
  • (m(\cdot)) é uma métrica (acurácia, revocação, erro de calibração, etc.),
  • ((x,y)) são dados e rótulos.

Na prática, você só tem uma amostra finita, então toda métrica por fatia é uma estimativa com incerteza. Isso torna dois pontos estatísticos centrais:

1) Tamanhos de amostra pequenos e variância

Fatias raras produzem estimativas ruidosas. Uma fatia com 20 exemplos pode mostrar 0% de acurácia por acaso.

Mitigações:

  • Reportar intervalos de confiança (confidence intervals) (bootstrap (bootstrap) é comum).
  • Exigir tamanhos mínimos de fatia para ranqueamento.
  • Usar modelos hierárquicos ou encolhimento bayesiano (Bayesian shrinkage) para estimativas estáveis de subgrupos em cenários de alto risco.

2) Comparações múltiplas (multiple comparisons) (muitas fatias)

Se você testa centenas de fatias, algumas parecerão “ruins” puramente por aleatoriedade.

Mitigações:

  • Tratar o fatiamento como geração de hipóteses (hypothesis generation), e então confirmar com dados retidos (held-out data).
  • Usar limiares de significância corrigidos (ex.: FDR de Benjamini–Hochberg (Benjamini–Hochberg FDR)) ao fazer testes formais.
  • Validar melhorias via metodologia adequada de experimentação; veja Desenho de Experimentos e Poder.

Em que fatiar (famílias comuns de fatias)

Boas fatias são significativas, acionáveis e mensuráveis.

Proveniência dos dados (data provenance) e pipelines (pipelines)

Muitas vezes, os ganhos mais rápidos vêm de fatias operacionais:

  • Fonte de dados (parceiro A vs. parceiro B)
  • Tipo de sensor/câmera, tipo de microfone
  • Versão do app / variante de pré-processamento
  • Versão do mecanismo de OCR (OCR engine), versão do tokenizador (tokenizer)
  • Janela de tempo (pré/pós mudança de política)

Essas fatias ajudam a separar “problema do modelo” de “problema do pipeline”.

Usuário, ambiente e contexto

  • Geografia, idioma, localidade
  • Tipo de dispositivo, condições de rede
  • Iluminação, ruído de fundo, desfoque de movimento
  • Comprimento da consulta, tópico, domínio (médico vs. jurídico)

Propriedades de rótulo e anotação

  • ID do anotador ou fornecedor
  • Confiança do rótulo / discordância
  • Classes de cauda longa
  • Categorias de rótulo ambíguas

Se o desempenho da fatia correlaciona com o anotador, você pode ter ruído de rótulos (label noise) ou deriva das diretrizes.

Sinais internos do modelo (model-internal signals) (fatias dinâmicas)

Eles são especialmente úteis para sistemas modernos de aprendizado de máquina:

  • Probabilidade prevista (predicted probability) / faixas de confiança (confidence buckets)
    Ajuda a diagnosticar se o modelo “sabe quando não sabe”.
  • Estimativas de incerteza (uncertainty estimates) (epistêmica/aleatória (epistemic/aleatoric))
    Veja Estimativa de Incerteza.
  • Fatias por tipo de erro: falsos positivos vs falsos negativos, ranks de quase-acerto em recuperação, etc.
  • Clusters de representação (representation clusters): agrupar por similaridade de representação vetorial (embedding) para encontrar regiões semânticas com erros sistemáticos.

Fatias dinâmicas frequentemente levam diretamente a políticas como “abster-se (abstain) / encaminhar para revisão humana quando a incerteza é alta”.

Fluxo de trabalho prático: fatiamento que leva a melhorias

1) Comece com um objetivo claro e um modelo de custo (cost model)

Defina:

  • O que conta como erro?
  • Quais erros são mais caros? (falsos negativos vs falsos positivos)
  • Qual métrica se alinha a esse custo? (veja Métricas)

Exemplo: em detecção de fraude, a revocação em casos de fraude pode importar mais do que a acurácia geral, especialmente sob Desbalanceamento de Classes.

2) Estabeleça um conjunto de avaliação confiável

O fatiamento é tão bom quanto os dados de avaliação:

  • Use particionamento apropriado para evitar vazamento de dados (leakage) e resultados otimistas demais; veja Validação e Validação Cruzada.
  • Garanta que os dados de avaliação contenham os metadados necessários para o fatiamento.
  • Verifique a qualidade e a consistência dos rótulos.

3) Defina um catálogo de fatias (slice catalog) (guiado por hipóteses)

Crie uma lista inicial de fatias a partir de:

  • Conhecimento de domínio (coortes de alto risco conhecidas)
  • Conhecimento do produto (dispositivos, regiões, fluxos de onboarding)
  • Auditorias de dados (ausências, outliers)
  • Incidentes anteriores ou tickets de clientes

Mantenha as definições de fatias versionadas e reprodutíveis.

4) Calcule métricas por fatia com incerteza

Para cada fatia, calcule:

  • Tamanho n
  • Métrica primária (ex.: revocação)
  • Métricas secundárias (precisão, erro de calibração, latência (latency))
  • Intervalos de confiança (bootstrap)
  • Contagens de erro (FP/FN)

5) Ranqueie fatias por prioridade (severidade × impacto × acionabilidade)

Uma heurística prática de pontuação:

  • Severidade: lacuna em relação ao baseline (geral ou alvo)
  • Impacto: n ou custo de negócio estimado
  • Acionabilidade: conseguimos corrigir com mudanças de dados/modelo/pipeline?

Cuidado: fatias muito grandes podem dominar puramente por volume; fatias muito pequenas podem dominar por ruído.

6) Faça inspeção qualitativa (qualitative inspection) (por exemplo)

Números identificam onde; exemplos explicam por quê. Para as principais fatias:

  • Inspecione exemplos classificados incorretamente
  • Procure padrões repetidos (formatação, gírias, oclusões, casos-limite)
  • Verifique rótulos (alguns “erros” são erros de rótulo)
  • Cheque diferenças no pipeline de entrada

7) Formule hipóteses e implemente correções direcionadas

Correções típicas por causa raiz (root cause):

  • Lacuna de cobertura de dados: coletar ou sintetizar dados para a fatia; aumento de dados (data augmentation) direcionado.
  • Ruído de rótulos: rotular novamente, refinar diretrizes, arbitrar discordâncias.
  • Capacidade/arquitetura do modelo: ajustar modelo, atributos ou ponderação de perda (loss weighting).
  • Limiarização/política: limiares por fatia (com cautela), opção de rejeição, humano no ciclo (human-in-the-loop).
  • Problemas de calibração: calibração pós-hoc (post-hoc calibration) (Platt scaling, isotonic) ou recalibração por contexto; veja Calibração.

8) Confirme melhorias sem regressões (regressions)

Reexecute o fatiamento em:

  • Um conjunto retido não usado durante o diagnóstico
  • Principais contra-fatias (para detectar regressões em outros pontos)
  • Se online, execute testes com poder estatístico adequado; veja Desenho de Experimentos e Poder

Exemplo trabalhado: fatiando um classificador binário (binary classifier)

Imagine um modelo prevendo se um ticket de suporte ao cliente é urgente. Você tem:

  • y_true (0/1)
  • y_pred (0/1)
  • metadados: language, channel, customer_tier, ticket_length

Métricas básicas por fatia em Python

import pandas as pd
import numpy as np

def confusion_counts(y_true, y_pred):
    tp = int(((y_true == 1) & (y_pred == 1)).sum())
    tn = int(((y_true == 0) & (y_pred == 0)).sum())
    fp = int(((y_true == 0) & (y_pred == 1)).sum())
    fn = int(((y_true == 1) & (y_pred == 0)).sum())
    return tp, tn, fp, fn

def slice_report(df, slice_col, min_n=50):
    rows = []
    for val, g in df.groupby(slice_col):
        n = len(g)
        if n < min_n:
            continue
        tp, tn, fp, fn = confusion_counts(g.y_true.values, g.y_pred.values)
        recall = tp / (tp + fn) if (tp + fn) else np.nan
        precision = tp / (tp + fp) if (tp + fp) else np.nan
        fpr = fp / (fp + tn) if (fp + tn) else np.nan
        rows.append({
            "slice": f"{slice_col}={val}",
            "n": n,
            "prevalence(y=1)": g.y_true.mean(),
            "recall": recall,
            "precision": precision,
            "fpr": fpr,
            "tp": tp, "fp": fp, "fn": fn, "tn": tn
        })
    return pd.DataFrame(rows).sort_values(["recall", "n"], ascending=[True, False])

# df columns: y_true, y_pred, language, channel, customer_tier, ticket_length
report = slice_report(df, "language", min_n=100)
print(report.head(10))

Isso revela fatias em que a revocação é baixa (tickets urgentes perdidos), juntamente com o quão comuns são tickets urgentes naquela fatia.

Adicionando incerteza com intervalos por bootstrap

def bootstrap_ci(values, stat_fn, n_boot=2000, alpha=0.05, rng=None):
    rng = np.random.default_rng(rng)
    stats = []
    values = np.array(values)
    n = len(values)
    for _ in range(n_boot):
        idx = rng.integers(0, n, size=n)
        stats.append(stat_fn(values[idx]))
    lo = np.quantile(stats, alpha/2)
    hi = np.quantile(stats, 1 - alpha/2)
    return float(lo), float(hi)

def recall_ci(g):
    y_true = g.y_true.values
    y_pred = g.y_pred.values
    # bootstrap over rows
    pairs = np.stack([y_true, y_pred], axis=1)
    def stat(pairs_sample):
        yt = pairs_sample[:, 0]
        yp = pairs_sample[:, 1]
        tp = ((yt == 1) & (yp == 1)).sum()
        fn = ((yt == 1) & (yp == 0)).sum()
        return tp / (tp + fn) if (tp + fn) else np.nan
    return bootstrap_ci(pairs, stat, n_boot=1000, rng=0)

rows = []
for lang, g in df.groupby("language"):
    if len(g) < 200:
        continue
    r = ( (g.y_true==1) & (g.y_pred==1) ).sum() / max(1, (g.y_true==1).sum())
    lo, hi = recall_ci(g)
    rows.append((lang, len(g), r, lo, hi))

ci_report = pd.DataFrame(rows, columns=["language", "n", "recall", "recall_ci_lo", "recall_ci_hi"]) \
              .sort_values("recall")
print(ci_report.head(10))

Se uma fatia com baixa revocação tiver um intervalo amplo, você pode precisar de mais dados de avaliação antes de agir.

Transformando resultados em ações

Suponha que você encontre:

  • Baixa revocação para language=es e channel=chat
  • Muitos falsos negativos contêm abreviações informais e texto com mistura de códigos (code-mixed)

Correções potenciais:

  • Coletar mais dados de chat em espanhol; priorizar negativos/positivos difíceis.
  • Melhorar tokenizador ou normalização para gírias de chat.
  • Adicionar aumento de dados direcionado (abreviações, ruído de ortografia).
  • Considerar uma abordagem de identificação de idioma (language-ID) + roteamento (routing) se o modelo não for multilíngue.

Então, reexecute o fatiamento para verificar se a lacuna fecha sem prejudicar outras fatias.

Descobrindo fatias automaticamente (quando você não sabe o que procurar)

Fatias manuais são essenciais, mas você também pode descobrir coortes suspeitas.

Abordagem “erro como rótulo” (error-as-label) (árvore de decisão para interpretabilidade (interpretability))

Crie um conjunto de dados em que o alvo é se o modelo cometeu um erro:

  • error = 1 se y_pred != y_true
  • Treine uma árvore de decisão (decision tree) rasa para prever error a partir de metadados/atributos
  • As divisões da árvore sugerem regras de fatias (ex.: device=low_end e brightness<0.2)

Isso não “prova causalidade”, mas é uma forma forte de gerar hipóteses.

Clusterização (clustering) de predições incorretas

Para texto/imagem/áudio:

  • Gere representações vetoriais (ou use representações internas do modelo)
  • Faça clusterização de exemplos com predição incorreta
  • Inspecione clusters e derive definições de fatias (tópico, estilo, condição visual)

Cuidado: fatias espúrias (spurious slices)

Métodos automatizados podem encontrar fatias que superajustam (overfit) o conjunto de avaliação. Sempre confirme em dados novos e exija acionabilidade (“o que mudaríamos?”).

Fatiamento além da classificação

Regressão (Regression)

Fatie por:

  • Faixa de valores verdadeiros (erros frequentemente crescem nos extremos)
  • Fonte de dados, sazonalidade, região
  • Indicadores de heterocedasticidade (heteroscedasticity) (variância muda entre contextos)

Métricas por fatia: MAE/RMSE, viés (erro médio) e cobertura se você tiver intervalos de predição (prediction intervals).

Ranqueamento e recuperação (retrieval)

Fatie por:

  • Tipo de consulta (navegacional vs informacional)
  • Comprimento da consulta, idioma, vertical (compras/notícias)
  • Consultas de cabeça (head) vs cauda (tail)

Métricas por fatia: NDCG@k, MRR, recall@k e também latência.

Modelos generativos (generative models) (LLMs)

O fatiamento é cada vez mais usado para:

  • Tipo de prompt (prompt) (QA, sumarização, código)
  • Categorias de segurança (autoagressão, ódio, ilícitos)
  • Idioma e dialeto
  • Uso de ferramentas vs sem uso de ferramentas
  • Contexto longo vs contexto curto

A avaliação frequentemente combina métricas automáticas com avaliação humana ou baseada em rubricas (rubric-based grading); as fatias ajudam a priorizar onde investir em prompts melhores, ajuste fino (fine-tuning) ou barreiras de segurança (guardrails).

Armadilhas comuns e como evitá-las

Otimizando para o conjunto de avaliação

Se você repetidamente fatiar e “remendar” com base em um conjunto de dados, você corre o risco de superajustar. Mantenha:

  • Um conjunto de teste bloqueado (locked test set) (usado raramente)
  • Um conjunto de diagnóstico (diagnostic set) separado, usado para iteração

Fatores de confusão e paradoxo de Simpson

Se device_type correlaciona com country, fatie das duas formas. Considere fatias multivariadas ou comparações estratificadas (stratified comparisons).

Fatias pequenas e decisões ruidosas

Use limiares mínimos de amostra e intervalos de confiança. Se uma fatia é importante, mas pequena, colete mais dados rotulados antes de tirar conclusões.

Incompatibilidade de métrica

Uma fatia pode parecer “boa” em acurácia, mas ser inaceitável em revocação, taxa de falsos positivos ou calibração. Escolha métricas que reflitam os custos reais; veja Métricas e Calibração.

Ignorar taxas-base (base rates)

Diferenças na prevalência de classes entre fatias podem mudar como as métricas se comportam. Seja explícito sobre a prevalência e considere análise sensível a custo (cost-sensitive analysis), especialmente sob Desbalanceamento de Classes.

Definições de fatias instáveis ao longo do tempo

Se as fatias dependem de campos que mudam de semântica (ex.: versão do app, mapeamento de região), sua análise fica difícil de reproduzir. Versione sua lógica de fatias e o esquema de metadados.

Checklist de boas práticas

  • Defina métricas primárias e secundárias alinhadas com custos reais.
  • Comece com fatias guiadas por hipóteses a partir de conhecimento de domínio.
  • Inclua fatias de proveniência (fonte de dados, dispositivo, versão de pipeline).
  • Sempre reporte tamanho da fatia e incerteza (no mínimo ICs por bootstrap).
  • Ranqueie fatias por severidade × impacto × acionabilidade.
  • Inspecione exemplos concretos para identificar causas raiz (dados vs modelo vs pipeline).
  • Implemente correções direcionadas e então refaça o fatiamento para verificar melhorias e detectar regressões.
  • Confirme com dados novos e experimentação com princípios (Desenho de Experimentos e Poder).
  • Operacionalize: acompanhe métricas por fatia em painéis de monitoramento (monitoring dashboards) para deriva (drift) e regressões.

Como a análise de erros por fatiamento se encaixa na caixa de ferramentas de avaliação

O fatiamento não substitui a avaliação padrão — ele é a ponte entre “um número” e “um plano”:

Quando bem feita, a análise de erros por fatiamento transforma a avaliação do modelo em um processo sistemático de descoberta de modos de falha — para que você gaste esforço de engenharia e coleta de dados onde isso produz os maiores ganhos, com maior confiabilidade.