Um benchmark é um contrato com um denominador

As alegações de desempenho só são úteis quando a carga de trabalho, o âmbito, o hardware, a condição de qualidade, a referência e a incerteza permanecem...

Um benchmark é um contrato com um denominador

The number that forgets its denominator

A benchmark result can be measured correctly and still answer the wrong question. The usual culprit is not a faulty timer or a dishonest engineer. It is the denominator that disappeared between the test harness and the presentation slide. “Twice as fast” sounds like a comparison, but it does not say twice as fast at what work, on which machine, with which software, under which quality condition, against which baseline, or for which users. Remove those conditions and a performance number becomes a polished fragment. It may remain numerically true. It no longer tells a buyer or an operator what they can expect.

The denominator is the work against which the result is expressed. For throughput, it is the work completed and the time over which completion is counted. For latency, it is the request definition, the path included, and the population of observations. For accuracy, it is the labelled set, the label rule, and the unit being judged. For energy, it is the boundary of the measured system and the work delivered inside that boundary. For cost, it is the cost period, the included resources, and the volume of useful work. A benchmark is honest when its numerator and denominator travel together.

That is why a benchmark is best treated as a contract. The contract names the question, the workload, the scope, the hardware and software, the metric, the baseline, the uncertainty and the method by which another party could check the result. A contract can be narrow. It can be exploratory. It can be useful only for one deployment. What it cannot be is an impressive number whose conditions are left for the reader to guess. Guessing is a poor way to allocate public money, and an even poorer way to design a service that somebody else must keep alive.

The European habit of writing down definitions is occasionally mocked as paperwork. In measurement work, definitions are the part that stops paperwork from becoming folklore. The benchmark table is not an administrative appendix to the result. It is the result’s identity card.

Read the unit before the headline

Start with the unit, but do not stop there. Requests per second, tokens per second, milliseconds, joules per query, euros per thousand records and percentage points all tell you something. None tells you what the system was asked to do. A result of 100 requests per second can describe tiny cached requests or large uncached requests that include retrieval, validation and a human hand-off. A latency of 20 milliseconds can cover a single kernel or an entire decision path. The unit is a door. The workload is the room behind it.

Suppose a procurement slide says that a new service is 40 per cent faster than the existing one. The sentence is not yet evidence. It needs at least the operation being timed, the input size and distribution, the work excluded from the clock, the concurrency, the warm-up state, the software versions, the hardware, and the baseline configuration. It also needs the quality condition. If the faster path returns fewer valid results, drops long inputs or skips an expensive verification step, the numerator has been made smaller by changing the work.

This is not a request for an enormous table before anyone may speak. It is a request to identify the few fields that change the meaning of the claim. A small parser benchmark may need record shape, input source, validation policy, compiler and processor. An inference benchmark may need model, precision, batch, scenario, quality target and power boundary. A public-sector queue may need the case definition, service clock, routing rule and escalation path. The fields differ. The obligation to name them does not.

Há aqui uma disciplina útil: escrever o resultado como uma frase que sobrevive a um segundo leitor. «Sob esta carga de trabalho e este requisito de qualidade, neste sistema e versão, o valor medido foi este, com esta variação.» Se a frase não puder ser completada sem palavras como típico, melhor, semelhante a produção ou representativo, o método não está concluído. Essas palavras podem ser válidas, mas precisam de uma definição operacional, não de um tom acolhedor.

Um cartão de benchmark não é decoração à volta de um número. É a forma útil mais pequena do contrato desse número.

O âmbito faz parte do resultado

O âmbito responde a uma pergunta simples: o que cobre este resultado e o que fica fora do enquadramento? Na avaliação de aprendizagem automática, o âmbito inclui a tarefa, o conjunto de dados, a divisão, o idioma, o comprimento da entrada, o cenário de funcionamento e as escolhas de implementação permitidas. Num serviço de software, inclui a rota, os armazenamentos de dados, a rede, a cache e o trabalho que uma equipa a jusante executa depois de o ponto final medido devolver a resposta. Um resultado medido numa camada não deve transformar-se silenciosamente numa promessa sobre todo o serviço.

A MLCommons torna isto visível na sua documentação de Inferência MLPerf. O guia de submissão separa os tipos de sistema de datacenter e de edge, lista cenários como offline, servidor, interativo, single-stream e multi-stream, e distingue uma divisão fechada de uma divisão aberta. A divisão fechada destina-se a uma comparação direta usando o mesmo modelo e configuração de referência. A divisão aberta permite escolhas como re-treino ou substituição do modelo. Nenhuma é a divisão universalmente correta. Respondem a perguntas diferentes. Um título que as mistura não é uma visão ampla. É um erro de categoria com excelente tipografia.

A mesma documentação mostra porque é que um benchmark precisa de um lado explícito de qualidade. Uma entrada listada de ResNet50 nomeia o conjunto de validação ImageNet-2012, os seus tamanhos de conjunto de dados e de lista de amostras de consulta, uma precisão de referência e uma restrição de latência de servidor. Para a entrada listada de ResNet50, a página dá um conjunto de validação de 50 000 imagens, uma lista de amostras de consulta de 1 024, uma precisão de referência de 76,46 por cento e uma restrição de latência de servidor de 15 ms. Esses campos não são trivialidades para quem gosta de ler regras. Explicam o que a velocidade reportada tinha permissão para significar. Mude o conjunto de dados, o cenário ou o requisito de qualidade e a comparação mudou, mesmo que o nome do modelo pareça familiar.

Um comprador europeu deve desconfiar de âmbito implícito num rótulo de produto. «Plataforma de IA», «acelerador» e «nível empresarial» não definem o trabalho. Um sistema excelente numa operação limitada pode ser exatamente o que um serviço precisa. Um sistema que afirma cobrir tudo pode ter medido quase nada que se assemelhe ao serviço. A verdade estreita é mais saudável do que a névoa universal.

Coverage changes the meaning

Coverage is not a footnote about whether the test set was large. It describes whose cases and which situations enter the measurement. A benchmark can cover many examples from one narrow distribution and still say little about the edges that matter in operation. Conversely, a small, carefully selected set can expose an important failure mode without supporting a general performance claim. The choice is a design decision. It must be stated as such.

The OECD’s framework for characterising AI evaluation instruments is useful because it refuses to reduce an evaluation to one score. It proposes 18 facets, including coverage, purpose, realism, validity, reliability, transparency and the conditions under which results can be interpreted. Coverage asks whether the evaluation represents what it intends to measure. Purpose distinguishes a benchmark intended for research from one intended for conformity or another use. Realism asks whether the setting is a toy problem, a simulated or laboratory setting, or real life. These distinctions do not make a benchmark weaker. They make its claim legible.

Coverage also includes the cases an evaluation excludes. A service may report average latency after removing timeouts. A classifier may report accuracy after dropping ambiguous labels. A retrieval system may count only queries with at least one relevant document. An image pipeline may skip corrupt files. Each exclusion can be defensible. The result must say what was removed and why. Otherwise the denominator quietly becomes a list of cases that were convenient to finish.

This is where the denominator becomes political, even before anyone uses the word politics. The included population receives the benefit of being measured. The excluded population receives a story about a system that may not describe them. European public institutions already know this from official statistics. Eurostat’s European Statistics Code of Practice sets 16 principles and 84 indicators for the institutional environment, processes and outputs. Its Quality Assurance Framework supplies methods and tools, while quality reports tell users how data was collected and validated. The message for AI is not that every model must become a statistical office. It is that a number intended for public decisions needs a visible production and quality story.

Accuracy is not one gate

Performance claims often pair speed with a single quality number, then treat the pair as complete. Quality is usually a family of questions. Does the output meet the task definition? Does it preserve required constraints? Does it fail safely when evidence is missing? Does it behave acceptably across the relevant population? Does it remain within the quality boundary while the system is loaded? A fast answer that fails the task is not a faster solution. It is a different workload wearing the same noun.

MLPerf’s structure is instructive because its performance runs sit beside accuracy validation and model-specific requirements. The submission guide tells participants to identify the division, system type and scenario, run the intended benchmark, validate accuracy against thresholds and then prepare a checked submission. The benchmark page lists reference accuracy and latency or throughput conditions per task. The separation is practical. It keeps a system from winning the performance column by quietly losing the task.

Accuracy itself needs a denominator. “Ninety-eight per cent accurate” can mean a percentage of records, tokens, images, requests, or decisions. It can use micro or macro averaging. It can count an abstention as an error, as a safe refusal, or as an unmeasured outcome. It can compare to labels created by one reviewer or several. A benchmark card should name the unit, label rule, aggregation, confidence or variation, and any threshold that turns a measurement into a release decision.

Não utilize um número de qualidade como se fosse uma autorização decorativa. Um modelo pode cumprir um limiar publicado e continuar a ser inadequado para um serviço específico, porque a tarefa, a população ou o perfil de dano são diferentes. Inversamente, uma pontuação agregada mais baixa pode ser aceitável para uma ferramenta de rascunho que mantém um humano como autor, enquanto a mesma pontuação é inaceitável para um controlo automático. A qualidade é uma relação entre o resultado, o propósito e a consequência.

O tempo não é um único número

A latência é frequentemente apresentada como se um sistema tivesse uma única velocidade. Os sistemas reais têm uma distribuição. O primeiro pedido pode pagar o custo de arranque. Uma cache pode alterar os pedidos seguintes. Utilizadores simultâneos podem competir por memória ou por uma ligação à base de dados. Uma entrada longa pode seguir um caminho diferente de uma curta. A média pode melhorar enquanto a cauda piora. Se a cauda é onde um serviço falha o prazo, a média é uma distração com uma unidade.

Um relatório de latência útil indica o que foi medido e como as observações foram resumidas. Pode incluir a mediana, percentis superiores, a taxa de tempo limite e o número de pedidos. Deve indicar se os pedidos de aquecimento foram excluídos, se as repetições foram incluídas e se o tempo de fila ou de rede pertence ao caminho medido. Essas escolhas não são intercambiáveis. Uma avaliação de um componente pode ser valiosa, mas não deve ser apresentada como comportamento de ponta a ponta.

O débito tem uma armadilha semelhante. Uma taxa elevada pode ser alcançada através do processamento em lote, do aumento da concorrência ou da redução de um requisito de qualidade. Isso pode ser exatamente o certo para um trabalho offline. Pode ser inútil para um serviço interativo que deve responder a cada pedido dentro de um prazo. A avaliação deve indicar o cenário e o ponto de funcionamento e, em seguida, explicar o que aconteceria se a procura se afastasse desse ponto. Não há vergonha num ponto de funcionamento estreito. Há vergonha em fingir que é o mapa inteiro.

O tempo também tem um lado humano. Um serviço que responde rapidamente, mas que cria mais trabalho de revisão, correção ou recurso, pode ser mais lento do ponto de vista da instituição. Uma avaliação que para o cronómetro antes da entrega pode fazer o sistema medido parecer ágil, enquanto o serviço real acumula uma fila. O denominador deve acompanhar o trabalho até que a pergunta em causa seja respondida. Caso contrário, o cronómetro está a medir uma ilha.

O hardware e o software fazem parte do numerador

“Num servidor” não é um ambiente reproduzível. A geração do processador, o conjunto de instruções, o acelerador, a memória, o armazenamento, o estado térmico, o limite de energia, o sistema operativo, o controlador, o compilador, o runtime, a biblioteca e a configuração podem todos alterar um resultado. O mesmo acontece com um formato de modelo, uma definição de quantização, o tamanho do lote, a seleção do kernel ou a política de threads. A avaliação não precisa de listar todos os cabos. Precisa de identificar as partes que podem alterar a medição.

O MLPerf designa o conjunto completo de medição como sistema em teste e organiza os resultados por tipo de sistema e categoria de disponibilidade. Esse vocabulário é útil para além do MLPerf. Um sistema em teste tem um limite. O limite define qual o hardware e software incluídos, quais os serviços externos e qual o trabalho omitido. Um valor de energia medido na tomada tem um significado diferente de um valor que conta apenas um acelerador. Uma latência medida dentro de um kernel tem um significado diferente de uma que inclui o agendamento de pedidos.

As versões são importantes porque uma avaliação é uma comparação entre estados, não uma propriedade intemporal de um nome de produto. Registe a versão do modelo ou da aplicação, as versões das dependências, os sinalizadores do compilador, o controlador e o firmware onde estes afetam o resultado. Registe a configuração que selecionou um backend ou uma precisão. Se um runtime escolher um kernel diferente noutra máquina, isso faz parte do resultado, não é um detalhe de implementação a arrumar mais tarde.

Divulgar o hardware não é um convite para transformar uma publicação de blogue num catálogo de peças. É uma forma de evitar falsas equivalências. Quem compra não precisa de se preocupar com cada instrução se a alegação diz respeito a um serviço completo. Precisa, isso sim, de saber se a comparação inclui o mesmo trabalho, a mesma precisão, o mesmo percurso de entrada e um sistema que possa efetivamente ser obtido e operado no contexto europeu pretendido.

As referências são promessas

Uma referência é a comparação que dá direção a um resultado. Sem ela, um número pode descrever um sistema, mas não uma melhoria. A referência tem de responder à mesma pergunta em condições comparáveis. Se o novo percurso utiliza um compilador mais recente, uma distribuição de entrada diferente ou um objetivo de qualidade distinto, o resultado pode continuar a ser interessante, mas a comparação deixa de ser limpa. Diga o que mudou. O leitor poderá então decidir se a diferença é útil.

A escolha da referência é um ato de interpretação. Comparar com o sistema atual que os utilizadores realmente executam, com uma implementação de referência, com uma versão anterior ou com um limite teórico produz aprendizagens diferentes. Um sistema novo pode ser melhor do que a referência e pior do que o serviço que está a substituir. Pode ser mais rápido num teste limpo e mais lento quando se incluem validação e armazenamento. A avaliação deve nomear a referência e explicar por que razão responde à questão operacional.

Execuções emparelhadas são muitas vezes mais informativas do que uma única volta da vitória. Mantenha a carga de trabalho e a definição de avaliação fixas, altere um fator material e registe a diferença. Se vários fatores mudarem em conjunto, descreva a comparação como um pacote, em vez de atribuir todo o efeito a um único componente. Isto parece óbvio até uma atualização, uma renovação de dados e uma nova política de cache chegarem na mesma versão. O gráfico fica então com uma seta e três causas possíveis, um pequeno mistério para o qual ninguém orçamentou.

Uma referência também tem prazo de validade. Um feed de dados, um fornecedor, um modelo, uma política ou uma plataforma de hardware podem mudar. A comparação permanece válida para as versões e o período testados. Não deve ser reutilizada como garantia atual sem verificar o contrato. É aqui que o histórico de versões mostra o seu valor. Um resultado ultrapassado não é um fracasso. É uma alegação histórica cujas condições devem permanecer visíveis.

A incerteza não é um pedido de desculpas

Toda a medição contém variação. Parte da variação vem do sistema, parte da carga de trabalho e parte do processo de medição. Execuções repetidas podem revelá-la, mas a repetição por si só não explica a causa. Uma cache quente pode ser estável. Um vizinho ruidoso pode não ser. Um conjunto de avaliação pequeno pode produzir uma ampla gama de resultados plausíveis. Um conjunto maior pode reduzir o ruído de amostragem sem tocar numa população enviesada. A incerteza diz ao leitor até onde o resultado pode viajar com segurança.

Apresente a incerteza numa forma adequada à alegação. Pode ser um intervalo entre execuções repetidas, um intervalo de confiança, um erro padrão, uma distribuição de latência, uma análise de sensibilidade ou uma lista de limites conhecidos. Não adicione um intervalo de confiança só porque a tabela parece vazia. Indique o que foi repetido, o que foi mantido fixo e o que o intervalo representa e não representa. A linguagem estatística não é um feitiço. É um contrato sobre a variação.

Existe um segundo tipo de incerteza que os números não conseguem eliminar: a incerteza sobre se a medição representa o serviço pretendido. Um resultado pode ter uma variação mínima entre execuções e uma cobertura fraca no mundo real. Uma avaliação pode ser perfeitamente reproduzível num laboratório e, ainda assim, ignorar os idiomas, os formatos de entrada, os padrões de turnos ou as consequências de falha da implementação. Um ruído de medição baixo não cria validade. Apenas faz com que a pergunta errada seja respondida de forma mais consistente.

A incerteza deve, portanto, ficar ao lado da afirmação, e não numa nota de rodapé no fim. Se um limiar está próximo do limite medido, isso importa. Se um resultado muda materialmente com uma combinação diferente de dados de entrada, isso importa. Se o limite energético exclui arrefecimento ou movimentação de dados, isso importa. A frase honesta pode ser menos triunfante, mas dá a quem decide algo melhor do que otimismo: um lugar para a cautela.

A reprodução é uma cadeia, não um botão de descarregar

A reprodutibilidade é frequentemente reduzida à publicação de código. O código importa. É apenas um elo da cadeia. Uma segunda parte também precisa da carga de trabalho ou de uma descrição legal da mesma, da versão dos dados, da configuração, do ambiente, do comando ou do mecanismo de execução, da política relativa ao estado aleatório, da regra de saída esperada, do ficheiro de resultados e do método usado para decidir se a execução corresponde. Se faltar um elo, a segunda parte pode reproduzir uma experiência semelhante, e não a que foi comunicada.

A cadeia deve distinguir a repetição exata da replicação independente. A repetição exata usa o artefacto capturado, o estado, os dados de entrada, a configuração e o caminho de execução para verificar se a mesma execução pode ser reconstruída. A replicação independente usa um ambiente preparado em separado para testar se o resultado sobrevive fora da máquina ou da equipa original. Ambas são valiosas. Respondem a perguntas diferentes. Um resultado byte a byte idêntico com dados de entrada capturados prova uma forte afirmação de identidade sobre essa execução. Não prova que o mundo real permanecerá inalterado.

O quadro de avaliação da OCDE torna esta distinção mais fácil de ver ao tratar propósito, realismo, cobertura e fiabilidade como facetas separadas. Uma avaliação pode ser excelente para testes de regressão e fraca para estimar o desempenho de um serviço em produção. Pode ser útil para investigação e inadequada para conformidade. A reprodução não apaga o propósito. Ajuda o leitor a verificar a afirmação que o método realmente suporta.

Para dados que não podem ser divulgados, publique o limite e o percurso. Descreva a população, o processo de amostragem, o método de rotulagem, as regras de exclusão e as verificações de validação. Forneça um pacote de reprodução seguro quando possível e explique o que permanece protegido. «Os dados são confidenciais» é um limite legítimo, não um método concluído. O leitor deve ainda assim conseguir compreender o que foi medido e por que razão o resultado deve ou não ser generalizado.

A reprodução não é um botão rotulado «executar novamente». É uma cadeia de identidades que permite a outra equipa contestar a afirmação.

As instituições públicas devem recusar teatro de demonstração

As instituições públicas não precisam de rejeitar benchmarks. Precisam de recusar benchmarks que não consigam declarar o seu contrato. Uma demonstração polida pode ajudar um comité a compreender uma possibilidade. Não pode substituir a evidência sobre o serviço que a instituição tem de operar, as pessoas que serve e as falhas que tem de reparar. A distinção é importante porque uma demo é otimizada para um encontro curto, enquanto um serviço público é avaliado ao longo de estações, mudanças de pessoal, recursos, manutenção e lei.

Antes de comprar, peça ao fornecedor para definir a carga de trabalho na linguagem do serviço. O que entra no sistema? O que é medido? O que é excluído? Que regra de qualidade tem de ser cumprida? Que papel humano revê um resultado? Como é detetada a deriva? Como pode a instituição exportar a sua evidência? O que acontece quando o modelo, a fonte, o fornecedor ou a política mudam? Contra que versão é feita a comparação? Qual é o caminho de reversão? Um fornecedor pode responder a algumas perguntas com um contrato, a outras com um teste e a outras com um limite honesto. Essa mistura é mais saudável do que uma resposta feita inteiramente de adjetivos.

O Regulamento IA da UE expressa este ponto em linguagem jurídica para sistemas de alto risco. O artigo 15.º exige um nível adequado de exatidão, robustez e cibersegurança, com um desempenho consistente nesses aspetos ao longo de todo o ciclo de vida. Um benchmark não pode, por si só, estabelecer toda a obrigação legal. Pode apoiar parte da evidência se o seu âmbito, condições de qualidade e posição no ciclo de vida forem claros. Tratar uma pontuação como conformidade seria outro erro de denominador. A lei nomeia o resultado; a engenharia tem de mostrar o caminho.

Os processos de aquisição também devem perguntar quem é o dono do benchmark após a adjudicação. Um teste preparado por um fornecedor pode ser útil, mas a instituição precisa de informação suficiente para monitorizar o sistema no seu próprio contexto. Precisa de uma base que possa ser reexecutada quando uma versão muda, de um caminho de revisão quando os resultados se alteram e de um registo das decisões tomadas sobre o desempenho aceitável. Caso contrário, o primeiro benchmark é um exame de admissão e o sistema em produção pode formar-se sem mais perguntas.

Faça o cartão de benchmark suficientemente pequeno para ser utilizado

Métodos longos podem ser necessários. Nem sempre são a primeira coisa de que um leitor precisa. Um cartão de benchmark é um índice compacto do contrato. Pode ficar ao lado de um resultado num relatório, num registo de avaliação ou num processo de aquisição. O cartão deve indicar a pergunta, a carga de trabalho, o âmbito, o sistema, a métrica, o requisito de qualidade, a base, a incerteza, o caminho de reprodução, o responsável e o prazo de validade ou o gatilho de alteração. O método detalhado pode ficar por trás. O cartão impede que a afirmação viaje sozinha.

Bons cartões são seletivos em vez de sobrecarregados. Expõem os campos que podem alterar a interpretação e depois ligam ao pacote de evidência. Um cartão de latência pode destacar o tamanho da entrada, a concorrência, o percentil, o aquecimento, a versão e a regra de tempo limite. Um cartão de energia pode destacar o limite do sistema, a carga de trabalho, o instrumento de medição, a duração e a infraestrutura excluída. Um cartão de exatidão pode destacar a população, a regra de rotulagem, a agregação, o tratamento de abstenções e a gravidade do erro. A forma comum não é um modelo fixo. É uma promessa de que o leitor pode encontrar o denominador.

O cartão deve marcar o estatuto epistémico. O valor é medido, estimado, esperado, proposto ou ilustrativo? A base está atual? O conjunto de avaliação está preparado mas ainda não foi executado? Os resultados estão protegidos porque o material de teste contém dados pessoais? Estes rótulos impedem que um método seja confundido com um resultado. Também permitem que uma organização publique progresso sem fabricar sucesso. Um teste preparado é informação útil. Não é evidência de que o sistema o passou.

Por fim, atribua ao cartão um proprietário e uma regra de alteração. Um resultado sem proprietário degrada-se num diapositivo. Um resultado sem regra de alteração permanece no mural depois de a carga de trabalho ter avançado. O proprietário não tem de defender o número para sempre. Tem, isso sim, de indicar quando a afirmação deve ser reexecutada, retirada ou restringida. A medição passa a fazer parte das operações quando alguém tem autoridade para a manter honesta.

Duas formas honestas de publicar um resultado

Existem dois modos de publicação comuns. O primeiro é uma comparação estrita. Fixa a tarefa, os dados, a regra de qualidade, a fronteira do sistema e a referência de base, de modo a que o leitor possa comparar alternativas. O segundo é uma medição exploratória. Pergunta o que acontece quando um design, uma carga de trabalho ou um ambiente muda, e regista as observações com os seus limites. O trabalho exploratório pode ser valioso antes de existir uma referência estrita. Não deve, contudo, tomar emprestada a linguagem de um resultado de conformidade.

As comparações estritas são exigentes porque tornam as diferenças visíveis. Se uma equipa alterar o modelo e o hardware em conjunto, pode ser impossível atribuir o resultado. Se uma nova carga de trabalho for mais realista mas deixar de corresponder à referência de base, a afirmação deve ser reformulada como uma nova medição. Se uma otimização melhorar a velocidade mas alterar a qualidade do resultado, reporte ambos os aspetos. A disciplina não serve para impedir o progresso. Serve para impedir que uma história de progresso apague a condição que o tornou possível.

As medições exploratórias exigem a sua própria honestidade. Diga que a amostra é pequena, que o ambiente é provisório, que a carga de trabalho é sintética, que o resultado não foi replicado de forma independente ou que a verificação de qualidade está incompleta. Não são fraquezas a esconder até um lançamento polido. São a informação que ajuda o leitor a decidir o que fazer a seguir. Uma cultura de engenharia europeia não precisa de fingir que cada teste é um veredicto final. Precisa de deixar de chamar respondida a uma pergunta antes de o teste ter sido lido.

Ambos os modos beneficiam de um arquivo de resultados. Mantenha as definições, configurações e resultados antigos identificáveis. Registe a substituição em vez de apagar o passado. Uma referência alterada pode ser a referência certa para um serviço alterado, mas não pode ser usada para reescrever o significado do resultado antigo. O histórico de versões é a memória do denominador.

A nossa pequena nota

Na Dweve, descrevemos o Core com uma célula de execução e um contrato de determinismo. A parte útil desse vocabulário não é o nome do produto. É a insistência em que uma operação transporta a sua representação numérica, o backend, o conjunto de instruções, a política de expedição e a postura de repetição como parte do caminho que está a ser avaliado. É o mesmo hábito de que uma referência precisa: manter as condições ligadas ao resultado, em vez de descrever o desempenho como se flutuasse acima do sistema.

Esta é uma pequena nota de design, não uma afirmação sobre uma implementação externa ou um resultado medido. A lição mais ampla não depende da Dweve. Quer o sistema seja um serviço estatístico público, um controlador industrial, uma ferramenta de linguagem ou um protótipo de investigação, um número ganha confiança ao nomear o seu trabalho e os seus limites. A nossa própria documentação é simplesmente um lugar onde tentamos tornar essa fronteira explícita.

O denominador é a parte que viaja

Um título de referência é fácil de copiar. O denominador é mais difícil de transportar, e é por isso que fica muitas vezes para trás. Um comprador copia um valor de débito para um caso de negócio. Um regulador vê uma pontuação de precisão num dossiê. Um engenheiro compara dois gráficos de cargas de trabalho diferentes. Um jornalista repete uma percentagem sem a população. Cada leitor recebe um número que perdeu o contrato que o tornava significativo.

A reparação não é complicada, embora exija disciplina. Dê nome à pergunta. Defina o trabalho. Indique o âmbito e as exclusões. Identifique o sistema e as versões. Escolha uma métrica que corresponda ao serviço. Mantenha uma base de referência. Meça a variação. Publique o método e as provas. Assinale o que permanece desconhecido. Atribua um responsável à afirmação e um motivo para a repetir. Se o resultado não puder sustentar uma afirmação ampla, torne a afirmação mais restrita.

É assim que a Europa pode resistir ao teatro de demonstrações sem se tornar alérgica à ambição. Uma instituição pública pode adquirir novas capacidades e ainda assim exigir uma referência que respeite o serviço. Uma equipa de investigação pode publicar um resultado empolgante e ainda assim indicar a carga de trabalho que o produziu. Um fornecedor pode mostrar um caminho rápido e ainda assim dizer onde esse caminho termina. Um âmbito honesto não é um travão à inovação. É a superfície da estrada que permite a qualquer outra pessoa avançar.

A referência é um contrato com um denominador, porque o denominador diz-nos o que foi realmente feito. Mantenha-o ao lado do número. O resultado tornar-se-á menos mágico, mais comparável e muito mais útil. É uma troca justa. Os sistemas de que as pessoas dependem merecem números que resistam a uma leitura lenta.

Quando uma métrica viaja entre mundos

Os números das referências saem frequentemente da equipa que os mediu e entram num sistema de decisão diferente. Um investigador publica uma tabela. Uma equipa de produto transforma uma linha num objetivo. As compras transformam o objetivo num contrato. As operações transformam o contrato numa expectativa de nível de serviço. Cada passo altera o que se pede ao número. O denominador original pode ainda estar presente no artigo ou no repositório, mas tornou-se socialmente distante da decisão. Uma métrica precisa de uma nota de tradução sempre que atravessa essa fronteira.

A nota de tradução pode ser simples. Este resultado diz respeito ao débito de componentes, não a casos concluídos. Este valor de precisão utiliza um conjunto fixo de rótulos, não resultados em tempo real. Este valor de energia exclui a fronteira de arrefecimento do centro de dados. Esta base de referência é uma implementação de referência, não o serviço atual. Estas frases impedem que uma medição útil se transforme numa promessa enganadora. Também facilitam o desacordo. Um leitor pode contestar a fronteira em vez de discutir se o número parece impressionante.

Equipas diferentes podem escolher deliberadamente denominadores diferentes. Uma equipa de plataforma pode preocupar-se com o trabalho por joule. Um responsável de serviço pode preocupar-se com decisões concluídas por hora de pessoal. Uma autoridade pública pode preocupar-se com resultados corretos e explicáveis para uma população definida e com o tempo de resposta. Não são verdades concorrentes se cada uma for nomeada. Os problemas começam quando se permite que o denominador mais fácil represente a missão. O núcleo mais rápido não faz automaticamente o melhor serviço, tal como o maior conjunto de testes não faz automaticamente o mais relevante.

Antes de reutilizar uma referência, pergunte o que mudou: a carga de trabalho, o responsável, a consequência ou o horizonte temporal. Se algum deles mudou, repita a interpretação mesmo que o número subjacente não tenha mudado. A medição não é uma relíquia para transportar entre salas. É uma relação que tem de ser renovada quando a sala muda.

Um resultado deve saber quando expirar

Os resultados têm uma vida útil. Uma referência ligada a uma versão de modelo, a uma captura de fonte ou a uma configuração de hardware torna-se histórica quando essas condições mudam. Isso não torna o resultado antigo falso. Muda a pergunta a que ele pode responder. O relatório deve indicar que evento torna a afirmação desatualizada: um novo modelo, um compilador alterado, uma nova distribuição de dados, uma regra de rótulos revista, uma substituição de hardware, uma alteração de política ou um sinal de deriva observado. Uma regra de expiração é uma pequena peça de memória institucional.

Sem uma regra de expiração, os números acumulam-se como casacos numa cadeira. Cada um continua tecnicamente lá, e ninguém sabe qual pertence ao dia de hoje. Um registo de resultados pode manter o histórico completo, assinalando a comparação atual, a definição substituída e o motivo para voltar a executar. O ato de voltar a executar passa a ser manutenção corrente, em vez de uma resposta a uma crise. Isto é especialmente importante para serviços públicos, onde um resultado pode sobreviver à equipa que o produziu.

A expiração também protege o progresso honesto. Se uma nova carga de trabalho revelar que uma referência anterior era demasiado restrita, a organização pode publicar a alteração, preservar o método antigo e explicar o novo limite. Não precisa de defender um número desatualizado nem de fingir que o número antigo nunca existiu. Uma referência que pode ser restringida, substituída e compreendida é mais útil do que uma que tenha de permanecer impressionante para sempre.

Fontes