💻 computer science

Auditing Empirical Comparisons in Quantum Software

Este artigo introduz o CLAIMSTAB-QC, um framework para auditar comparações empíricas em software quântico ao travar os designs de estudo antes da computação dos resultados, o qual revela um gap de materialização significativo onde a maioria das alegações relatadas carece de evidência suficiente para verificação direta e frequentemente produz resultados não resolvidos ou invertidos sob escrutínio rigoroso.

Autores originais: Boshuai Ye, Peng Liang, Maryam Tavassoli Sabzevari, Arif Ali Khan

Publicado 2026-07-02

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Boshuai Ye, Peng Liang, Maryam Tavassoli Sabzevari, Arif Ali Khan

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você está lendo uma crítica gastronômica que diz: "O hambúrguer do Chef A é mais saboroso que o do Chef B". Geralmente, assumimos que isso é uma verdade universal sobre os hambúrgueres. Mas e se o Chef A usou um blend de temperos secreto, um tipo específico de pão e uma grelha ajustada a uma temperatura precisa, enquanto o Chef B usou um pão diferente e uma grelha a carvão? Se você tentar fazer o teste de degustação por conta própria usando seus próprios utensícos de cozinha, pode descobrir que o hambúrguer do Chef B na verdade venceu.

Este é o problema que o artigo "Auditing Empirical Comparisons in Quantum Software" aborda, mas em vez de hambúrgueres, trata-se de computadores quânticos e o software que os executa.

Aqui está uma explicação simples do que os autores fizeram, usando analogias do cotidiano.

1. O Problema: A Armadilha do "Maçãs vs. Laranjas"

No mundo do software quântico, pesquisadores costumam publicar artigos afirmando: "Nossa ferramenta (Ferramenta A) é mais rápida/melhor que aquela ferramenta (Ferramenta B)".

No entanto, o software quântico é como um sanduíche gigante e de múltiplas camadas. Para fazer um sanduíche, você precisa de pão, recheio, molho e uma forma específica de fatiar. No software quântico, essas camadas são:

O código (o pão).
O compilador (o fatiador).
O simulador ou o hardware (o prato).
O ruído e os erros (as migalhas).

Os autores argumentam que dizer "A Ferramenta A é melhor" é frequentemente enganoso porque o resultado depende inteiramente de como o sanduíche foi feito. Se você mudar o pão (o circuito) ou o fatiador (as configurações do compilador), a Ferramenta A pode subitamente parecer pior que a Ferramenta B.

2. A Solução: O "Inspetor Rigoroso" (CLAIMSTAB-QC)

Os autores construíram um novo framework chamado CLAIMSTAB-QC. Pense nisso como um inspetor de alimentos rigoroso que não apenas prova a comida; ele verifica o cartão da receita primeiro.

Veja como funciona essa "inspeção":

O Cartão da Alegação: Quando um artigo diz "A vence B", o inspetor anota exatamente o que foi alegado: os ingredientes específicos, as ferramentas específicas e as regras específicas utilizadas.
O Cadeado: Antes de o inspetor provar qualquer coisa, ele tranca a receita. Ele não tem permissão para mudar os ingredientes ou as ferramentas. Ele deve usar exatamente o que o artigo original descreveu.
A Verificação de Evidências: O inspetor olha para o "recibo" do artigo (os dados e o código fornecidos).
- Cenário A: O artigo forneceu o recibo exato. O inspetor pode provar o hambúrguer exatamente como descrito.
- Cenário B: O artigo disse "A é melhor", mas não listou os ingredientes ou a temperatura. O inspetor não pode provar o hambúrguer. Ele deve parar e dizer: "Não podemos verificar esta alegação porque as evidências estão faltando".

3. A Grande Descoberta: A Lacuna do "Recibo Ausente"

Os autores testaram este framework em 455 alegações de 119 artigos de pesquisa diferentes. Os resultados foram surpreendentes:

175 alegações puderam ser escritas como uma receita clara (Cartões de Alegação).
79 alegações pareciam poder ser testadas.
53 alegações tinham dados suficientes para configurar um teste.
MAS... apenas 8 alegações tinham o "recibo" completo necessário para testar a alegação sem adivinhar ou inventar dados ausentes.

A Analogia: Imagine que uma rede de restaurantes afirma que seus hambúrgueres são os melhores da cidade. Eles lhe entregam uma lista de 100 unidades. Você vai a 53 delas para verificar. Mas, quando tenta provar o hambúrguer, percebe que 45 delas não disseram quais ingredientes usaram. Você só consegue realmente provar e verificar o hambúrguer em 8 unidades.

Isso é chamado de "Lacuna de Materialização". Os pesquisadores frequentemente relatam o resultado (o vencedor) sem fornecer a evidência (as configurações exatas) necessária para provar a alegação.

4. Os Resultados: Quem Realmente Venceu?

Para as 8 alegações que possuíam evidências completas, os autores realizaram a "auditoria rigorosa":

2 alegações: O vencedor original foi confirmado (o veredito "Sustentado").
4 alegações: Foi impossível dizer quem venceu porque os dados eram muito misturados ou os resultados foram muito próximos (o veredito "Irresoluto").
2 alegações: O vencedor original na verdade perdeu quando testado rigorosamente (o veredito "Revertido").

O Exemplo do "Revertido": Um artigo alegou que a Ferramenta A produzia menos erros do que a Ferramenta B. Quando os autores travaram as configurações e rodaram o teste novamente exatamente como descrito, descobriram que a Ferramenta A produzia mais erros. A alegação original só era verdadeira devido a uma configuração específica não relatada que os autores não haviam travado.

5. A Lição: "Mostre seu Trabalho"

O artigo conclui que a forma atual de relatar comparações de software quântico está quebrada. É como um professor de matemática dizendo: "A resposta é 5", mas não mostrando os passos.

Os autores sugerem que os artigos futuros devem:

Declarar a comparação claramente.
Fornecer o "recibo" exato (as configurações, sementes e dados específicos) necessário para travar o teste.
Admitir claramente onde a evidência termina (ex: "Testamos apenas em circuitos pequenos; não sabemos se funciona em circuitos grandes").

Resumo

O artigo não está dizendo que o software quântico é ruim. Está dizendo que as alegações sobre qual software é "melhor" são frequentemente impossíveis de provar porque os pesquisadores não compartilham detalhes suficientes sobre como executaram os testes.

Eles construíram uma ferramenta (CLAIMSTAB-QC) para agir como um auditor rigoroso. Quando a utilizaram, descobriram que a maioria das alegações não podia ser auditada porque os "recibos" estavam faltando. Para as poucas que podiam ser auditadas, os resultados foram mistos: às vezes a alegação original se sustentava, às vezes não, e muitas vezes era impossível dizer.

A lição principal: Se você quer saber se a Ferramenta A é realmente melhor que a Ferramenta B, você precisa ver a receita completa, não apenas o sabor final.

Resumo Técnico: Auditoria de Comparações Empíricas em Software Quântico

Declaração do Problema
Artigos empíricos em Engenharia de Software Quântico (QSE) frequentemente relatam alegações comparativas (ex.: "O Compilador A produz circuitos menores que o Compilador B"). No entanto, essas conclusões de "A vence B" não são propriedades intrínsecas das ferramentas sozinhas; são resultados emergentes de um stack complexo envolvendo construção de circuitos, escolhas de compilação, estratégias de amostragem, suposições de ruído de backend, estocasticidade do otimizador e orçamentos de recursos. Embora métodos existentes abordem a reprodutibilidade (executar novamente experimentos) e o teste de ferramentas, eles não auditam diretamente se a comparação relatada em si é sustentada pela evidência específica exposta no artigo e no artefato de origem.

O desafio central é a lacuna de materialização: um artigo pode relatar uma ordenação clara, mas a fonte carece da evidência correspondente (baselines pareadas, configurações idênticas e regras de resultado travadas) necessária para auditar essa relação específica sem reconstrução por procuração ou introdução de suposições não suportadas. Consequentemente, muitas comparações relatadas permanecem inauditáveis, apesar da disponibilidade de artefatos executáveis.

Metodologia: Framework CLAIMSTAB-QC
Os autores apresentam o CLAIMSTAB-QC, um framework limitado à fonte projetado para auditar comparações empíricas ao tratar a relação relatada como a unidade de auditoria. O framework opera através das seguintes etapas:

Representação de Cartão de Alegação (Claim Card): Uma comparação relatada é formalizada como um cartão de alegação $C = \langle P, BA, BB, M, R \rangle$ , onde $P$ é o contexto do problema, $BA/BB$ são as baselines, $M$ é a métrica e $R$ é a relação relatada. Isso fixa o escopo antes que qualquer resultado seja computado.
Materialização e Travamento (Locking): O framework tenta "materializar" a alegação identificando evidências suportadas pela fonte. Ele define um Espaço de Auditoria ( $S_{audit} = S_{scope} \times E_{env}$ $S_{a u d i t} = S_{sco p e} \times E_{e n v}$ ) compreendendo seis grupos de eixos: Escopo (tamanho do problema, instâncias), L1 (construção/compilação), L2 (amostragem/estimativa), L3 (backend/ruído), ALGO (estocasticidade do otimizador) e Budget (orçamento de recursos).
- Um procedimento de Execução Prévia (Dry-Run-First) inspeciona esses eixos. Apenas variações que são suportadas pela fonte, que afetam a métrica e que preservam a relação são ativadas.
- O design é travado (locked) antes que os resultados sejam computados. Se a fonte carecer dos dados pareados necessários (ex.: circuitos correspondentes sob sementes idênticas), a auditoria para em uma Fronteira de Evidência (Evidence Boundary).
Computação de Resultado:
- Para registros Escalares-Direcionais (alegações estritas de "melhor/pior"), o framework computa uma margem com sinal para cada célula correspondida.
- Aplica-se uma regra de decisão de Wilson para classificar a relação como Sustentada (limite inferior $\ge \tau$ ), Revertida (limite superior $\le 1-\tau$ ) ou Não Resolvida. O limiar $\tau$ é definido como 0,95 para alegações estritas.
- Registros não escalares (agregados, cruzamento) usam regras suportadas pela fonte se forem passíveis de travamento; caso contrário, são marcados como fronteiras.
Relato: A saída inclui o veredito escopado (S/U/R) ou uma explicação explícita da fronteira de evidência explicando por que a comparação não pôde ser auditada (ex.: protocolos de tempo ausentes, sementes não correspondentes).

Principais Contribuições

Framework: Um novo framework de QSE que desloca o foco da auditoria de "podemos reproduzir o resultado?" para "a evidência da fonte suporta a relação relatada?" usando registros limitados pela fonte e designs travados.
Estudo Empírico: Uma aplicação do framework a 455 alegações comparativas de 119 artigos de software quântico (2020–2024).
Artefato Reutilizável: Um pacote liberado contendo representações de alegações, registros de auditoria, traços travados e anotações de evidência ausente para facilitar a inspeção de comparações empíricas de QSE.

Resultos
O estudo revela um significativo funil de materialização e lacuna:

Representação: Das 455 alegações aceitas, 175 puderam ser representadas como cartões de alegação.
Planejamento: 79 foram identificadas como registros de planejamento escalar-direcional.
Capacidade de Travamento (Lockability): 53 geraram designs de auditoria ou diagnóstico traváveis.
Auditoria Sem Procuração (Proxy-Free): Apenas 8 registros expuseram evidência correspondente suficiente para auditar a comparação original sem reconstrução por procuração (Nível-1).
- Destes 8, 2 foram Sustentados, 4 foram Não Resolvidos e 2 foram Revertidos.
- Notavelmente, dois casos "Revertidos" (EX-C7 e EX-C8) mostraram que a direção relatada foi contradita em 0/80 e 0/80 células travadas, respectivamente, impulsionados por contradições estritas em vez de empates.
Diagnósticos Controlados: Experimentos em 24 comparações relevantes de benchmark mostraram que protocolos de auditoria mais simples (configuração única ou eixo único) frequentemente preservavam direções aparentes que eram enfraquecidas ou tornavam-se Não Resolvidas quando o stack completo de eixos travados (L1–L3, ALGO, BUDGET) era inspecionado.
Robustez: Os vereditos mostraram-se robustos às escolhas estatísticas (limiares, agrupamento) quando a evidência era suficiente, mas a sensibilidade ao tratamento de empates e aos limiares foi explicitamente relatada como uma condição de fronteira.

Significância e Alegações
O artigo argumenta que as comparações de QSE empírica são frequentemente relatadas como resultados sem a evidência necessária para auditar a própria comparação. A principal significância deste trabalho é a demonstração de que ordenações de desempenho e sua evidência de suporte são separáveis.

Os autores concluem que, para a QSE empírica avançar, as fontes devem relatar não apenas quem vence, mas a evidência correspondente necessária para travar o escopo dessa ordenação. O framework fornece um mecanismo para distinguir entre uma comparação que é auditável (Sustentada/Revertida/Não Resolvida) e uma que é fundamentalmente inauditável devido à falta de evidência (Fronteira). Isso desloca o alvo do relato para futuros estudos de QSE: os artigos devem expor explicitamente as baselines, configurações, instâncias, orçamentos e regras de resultado necessários para travar a comparação, e marcar claramente onde as fronteiras de evidência impedem a auditoria adicional.