Resumo Técnico: Auditando a Auditoria – Cinco Modos de Falha em Auditorias de Validade de Benchmarks

1. Declaração do Problema

Os frameworks de governança (ex: Lei de IA da UE, NIST AI RMF, GB/T 45654 da China) exigem cada vez mais que os provedores de IA forneçam evidências de avaliação documentadas, frequentemente na forma de auditorias de validade de construto baseadas em perturbação. Essas auditorias aplicam edições controladas em itens de benchmark para verificar se as métricas de desempenho de um modelo mudam apenas quando o construto subjacente muda (ex: uma inversão semântica) e permanecem estáveis sob reescritas de nível superficial.

O artigo argumenta que esses pipelines de auditoria são, eles próprios, sistemas de medição frágeis. Suas conclusões podem ser silenciosamente manufaturadas por detalhes de implementação invisíveis nos números relatados. Um defeito no pipeline de auditoria não apenas corrompe uma pontuação de benchmark; ele desabilita a salvaguarda destinada a detectar falhas de benchmark, não deixando rastros nas métis finais porque o leitor confia nessas métricas para decidir se deve confiar no benchmark. O problema central é que a evidência de governança atual carece de um protocolo para verificar a confiabilidade do próprio pipeline de auditoria.

2. Metodologia

Os autores conduzem um estudo de caso de auto-auditoria para demonstrar que os pipelines de auditoria são propensos a falhas silenciosas.

• Escopo: Dois modelos de pesos abertos de 7B com ajuste de instrução (Qwen-2.5-7B-Instruct, Mistral-7B-Instruct-v0.3) avaliados contra cinco benchmarks de segurança (TruthfulQA, BBQ, ToxiGen, CrowS-Pairs, XSTest).
• Design: 10 células (2 modelos × 5 benchmarks), 200 itens por benchmark, decodificação determinística, semente única.
• Perturbações: Três famílias por item (formato, semântica, atributo) com três perturbações cada.
• Métrica: Razão de Seletividade de Contraste (CSR), definida como $| \Delta_{attr} | / \max(| \Delta_{fmt} |, | \Delta_{sem} |, \epsilon)$. Isso mede se as perturbações de atributo induzem mudanças de pontuação maiores do que as perturbações superficiais.
• Processo: Os autores executaram um pipeline "legado", identificaram falhas, repararam-nas para criar um pipeline "canônico" e reexecutaram a auditoria. Crucialmente, eles rastrearam toda a cronologia de bugs, incluindo um (F3c) introduzido durante a fase de reparo.

3. Principais Contribuições

A. Os Cinco Modos de Falha (F1–F5)

O artigo propõe uma taxonomia não exaustiva de falhas ao nível de pipeline que são silenciosas (invisíveis nos números relatados), realizadas (encontradas na prática) e controláveis (detectáveis via verificações específicas). Elas são categorizadas em duas camadas:

Camada de Garantia de Software (Detectável via revisão de engenharia):

1. F1: Perturbações de no-op silenciosas: A perturbação escreve em um campo que o pontuador não lê (ex: editando uma string de pergunta enquanto o pontuador lê apenas as probabilidades de escolha). Isso resulta em $\Delta = 0$ para a perturbação, inflando artificialmente as métricas de razão.
2. F2: Artefatos de extração por Regex: Usar regex para analisar gerações de formato livre mede a robustez da regex, não o comportamento do modelo. Se as perturbações alteram o estilo de geração, a capacidade de análise (parseability) cai, e o $\Delta_{fmt}$ rastreia a cobertura da regex, não o comportamento do modelo.
3. F4: Quebra de pareamento de bootstrap: O reamostragem independente de itens originais e perturbados quebra o acoplamento por item, inflando os intervalos de confiança e as estimativas de variância.

Camada de Fidelidade de Medição (Requer raciocínio sobre o construto do benchmark):
3. F3: Pontuação não fiel: O pontuador não implementa o protocolo pretendido pelo benchmark.
* F3a (Convenção invertida): Tratar uma sentença estereotipada como "correta" devido a um carregamento ingênuo (ex: CrowS-Pairs).
* F3b (Ordenação de Harness): Viés posicional em carregadores (ex: TruthfulQA MC2 retornando índices corretos como $[0, \dots, k-1]$).
* F3c (Truncamento do pontuador): Tokens alvo caindo fora dos log-probabilidades top-$k$ (ex: ToxiGen), fazendo com que o pontuador recorra por padrão a uma classe majoritária e produza artefatos de $\Delta = 0$.
4. F5: Descompasso de arquétipo de métrica: Aplicar uma métrica de diagnóstico (projetada para detectar inversões) a um benchmark de invariância (projetado para não inverter). Um CSR baixo em um benchmark de invariância é ambíguo (benchmark quebrado vs. modelo justo) e não pode ser resolvido por reparos de pontuação.

B. O Portão de Devida Diligência de Seis Pontos (G1–G6)

Um protocolo hierárquico para determinar a elegibilidade da evidência de auditoria. Uma célula só é "confirmatória" se passar por todos os seis testes. O portão inclui:

• G1: Auditoria fiel ao pontuador (taxa de no-op silencioso < 20%, parseabilidade $\ge$ 0.95).
• G2: Pontuação original acima da linha de base.
• G3: Denominador não trivial (deltas superficiais $\ge$ 0.02).
• G4: Incerteza pareada (bootstrap pareado ao nível do item).
• G5: Divulgação de arquétipo (benchmark rotulado como diagnóstico, invariância ou misto).
• G6: Verificação de regressão de reparo (inspeção por célula e testes unitários para correções).

C. Protocolo de Cronologia de Auto-Auditoria

Os autores propõem um protocolo de "retenção e divulgação" que exige que as auditorias publiquem uma cronologia de auto-auditoria (Box 1) detalhando cada bug encontrado, seu método de descoberta, a correção e o delta antes/depois. Isso distingue um pipeline "limpo" de um onde os bugs foram silenciosamente absorvidos.

4. Resultados

No estudo de caso de 10 células, zero células atingiram o status "confirmatório". A decomposição foi:

• 3 Inelegíveis: Devido a F1 (CrowS-Pairs) ou F5 (BBQ).
• 3 Não validados pelo pontuador: Devido à falta de validação externa para os pontuadores de ToxiGen e XSTest.
• 2 Falharam em G2–G4: Devido a falhas nos portões numéricos (pontuação de linha de base ou limiares de denominador).
• 2 Exploratórias: Passaram em G1–G4, mas foram mantidas como não confirmatórias porque G5 e G6 foram "propostos" (ainda não implementados como portões obrigatórios nesta submissão).

Descoberta Principal: Uma falha (F3c, truncamento do pontuador) foi auto-introduzida durante o reparo de F1. Ela só foi detectada após a inspeção das meta log-probabilidades por célula. Sem essa inspeção, o pipeline produziria números plausíveis e publicáveis que eram inteiramente artefatos do bug.

5. Significância e Alegações

O artigo posiciona suas contribuições como complementares à evidência clássica de validade de construto (estudos convergentes/discriminantes), não como um substituto.

• Alegação Modesta: Os autores não alegam provar que qualquer benchmark é inválido ou que F1–F5 é uma taxonomia completa. Eles declaram explicitamente que a taxonomia é "deliberadamente não exaustiva".
• Argumento Central: A principal contribuição é um protocolo de retenção. A evidência de governança não deve ser aceita como "grau de garantia" a menos que o próprio pipeline de auditoria tenha passado por um portão de devida diligência e publicado uma cronologia de auto-auditoria.
• Implicação: Um número "limpo" em um relatório não garante um pipeline confiável. Sem o portão proposto e a cronologia, um pipeline silenciosamente quebrado é indistinguível de um robusto.

O artigo conclui com um pedido único e acionável: Qualquer auditoria que produza evidência baseada em benchmark para uso de governança deve publicar sua cronologia de auto-auditoria (no mínimo os oito campos contidos no Box 1) juntamente com seus números.