1. Escreva a pergunta antes de preparar as variantes
Uma comparação útil responde a uma decisão precisa: aumentar o comprimento máximo evita respostas cortadas? Um nível de detalhe preserva os contornos necessários? Um grupo maior termina sem erro? Escolha uma pergunta e um único parâmetro. "Encontrar as melhores configurações" é amplo demais para uma primeira sessão.
Chame A de referência e B de variante. Anote o valor exato modificado. Mudar ao mesmo tempo o modelo, as dimensões e o número de passadas pode produzir um resultado diferente, sem revelar qual modificação o explica. Guarde esses testes para comparações separadas.
2. Fixe um pequeno corpus e as regras de julgamento
Reúna as mesmas entradas para A e B. Uma dúzia de casos pode bastar para uma primeira decisão limitada se incluir as dificuldades do projeto: texto fino em uma imagem, documento longo, dado ausente ou formato incomum. Esse número é uma escolha prática, não uma garantia estatística. Evite incluir apenas os exemplos que já davam certo.
Para cada entrada, escreva antes do teste as condições de sucesso. Distinga uma preferência de apresentação de um defeito bloqueador. Em um assistente de documentos, uma resposta mais agradável pode continuar sendo recusada se inventar uma regra. Para um visual de produto, uma cor atraente não compensa o desaparecimento de um elemento importante.
Defina também o número mínimo de casos aceitos, os defeitos proibidos e o tempo máximo de controle. Esses limiares próprios do projeto devem permanecer idênticos quando você examina os resultados.
| O que fixar | Exemplo de nota | Por que isso importa |
|---|---|---|
| Entradas | caso-01 a caso-12, mesmos arquivos e mesmas formulações | Comparar as mesmas dificuldades |
| Critério de qualidade | Resposta verificável no documento e sem invenção | Evitar que uma saída fluida esconda um erro |
| Falha crítica | Regra ausente apresentada como certa | Recusar um defeito mesmo se o total parecer melhor |
| Variável | A: 128; B: 256 novos tokens no máximo | Atribuir a diferença a uma mudança identificada |
3. Mantenha a mesma sessão e as mesmas dependências
Mantenha o modelo, sua versão, as extensões, o mecanismo de cálculo e os demais parâmetros. Use o mesmo ambiente e a mesma GPU, sem iniciar outro processamento entre as duas variantes. Anote o que você não consegue controlar: atividade concorrente visível, mudança de versão imposta ou carregamento diferente. Uma comparação afetada por essas mudanças exige mais cautela.
Se a ferramenta usa uma semente aleatória e permite fixá-la, mantenha o valor para cada par de execuções. Isso facilita uma comparação, mas não garante uma saída idêntica em todo lugar. O PyTorch indica que a reprodutibilidade completa não é garantida entre versões ou plataformas, mesmo com uma semente idêntica.
Crie duas pastas, A e B, com a mesma lista de identificadores. Guarde as saídas brutas antes de qualquer correção manual. Um ajuste posterior deve aparecer como uma operação adicional, com seu tempo de trabalho, e não ser atribuído ao ajuste que produziu o arquivo inicial.
4. Faça uma execução de controle e depois compare os pares
Verifique primeiro se uma entrada simples chega até o arquivo ou a resposta recuperados. Essa execução controla o método. Sinalize separadamente um primeiro carregamento ou uma preparação específica: não compare a inicialização completa de A com uma execução B cujos elementos já estão todos carregados.
Execute os mesmos casos para A e B. Alterne a ordem se a ferramenta permitir, depois repita alguns pares decisivos na ordem inversa. Verifique se um resultado isolado ou uma vantagem de ordem não comanda toda a conclusão.
Registre também os erros e as saídas recusadas. Se B falhar em uma entrada grande, não a retire da tabela para melhorar sua média. Corrija eventualmente a causa em um teste B2 distinto. Assim você mantém uma comparação legível em vez de uma pasta onde a variante muda ao longo das dificuldades.
5. Separe o resultado aceito e o tempo observado
Examine primeiro a qualidade no tamanho ou na ferramenta de uso. Se possível, oculte temporariamente os nomes A e B no momento do julgamento. Uma pessoa pode simplesmente consultar as saídas em ordem embaralhada e depois restabelecer sua correspondência. Mantenha os critérios anunciados e um motivo curto para cada recusa.
Para o tempo, escolha uma definição única: por exemplo, do lançamento até a saída completa gravada. Separe em seguida o controle humano e as correções. Um cronômetro em torno de uma chamada GPU nem sempre é uma medida do cálculo concluído: com PyTorch/CUDA, as operações podem ser assíncronas. Use o método de medição documentado pela ferramenta se quiser isolar o cálculo.
Se as repetições se sobrepõem ou se a cronometragem continua aproximada, anote «diferença de duração não conclusiva». Uma pequena variação em uma única execução não justifica um percentual de ganho apresentado como certo.
Exemplo: 128 ou 256 novos tokens para um assistente documental
Uma pequena equipe quer respostas completas sobre doze perguntas fixas. Ela mantém o mesmo modelo, os mesmos documentos, a mesma instrução e a mesma GPU. Apenas o limite de resposta muda: A permite 128 novos tokens, B permite 256. No Transformers, max_new_tokens limita a geração sem contar os tokens do texto de entrada. Um token não é uma palavra: o limite não define um número exato de frases.
Antes do teste, a equipe fixa uma regra ilustrativa: pelo menos dez respostas aceitas de doze e nenhuma regra inventada. A tabela abaixo é um cenário fictício de leitura dos resultados. Ela não descreve um assistente medido e não prevê o efeito desses valores no seu modelo.
A atingiu o mínimo, B obteve mais respostas aceitas mas mantém um defeito crítico. A decisão é manter A para esse escopo, com revisão das respostas, e investigar a causa do defeito de B antes de outra comparação. O comprimento maior não é prova de qualidade nem a causa certa da invenção.
A equipe repete as perguntas que diferenciam A e B e duas perguntas já bem-sucedidas. Se o defeito aparecer também com A, ela suspende o veredito: o corpus inicial não havia sido suficiente para estabelecer a estabilidade. Ela mantém o registro das duas execuções em vez de guardar apenas a mais favorável.
| Critério do cenário | A: 128 tokens no máximo | B: 256 tokens no máximo |
|---|---|---|
| Respostas aceitas | 10 de 12 | 11 de 12 |
| Defeitos críticos | 0 | 1 regra inventada |
| Duração | A observar na sessão real | A observar com o mesmo método |
| Respeito à regra anunciada | Sim, neste cenário limitado | Não, apesar do melhor total |
Evite conclusões que seu teste não permite
Não escolha B só porque uma de suas saídas é espetacular enquanto as outras se degradam. Não mude o corpus no meio do caminho, não conte duas retomadas como duas entradas diferentes e não apague um fracasso do denominador. Doze entradas apresentadas continuam sendo doze casos a explicar, mesmo que alguns não tenham produzido nenhum arquivo.
O ajuste escolhido vale para as entradas, versões e critérios examinados. Ele pode não servir mais para um documento dez vezes mais longo ou para imagens diferentes. Adicione casos representativos aos poucos. Essa progressão amplia o controle; ela não transforma um pequeno teste em certificação do sistema.
Mantenha uma decisão curta e a próxima verificação
Seu dossiê final contém o corpus, as duas configurações, as saídas, os veredictos por identificador e algumas linhas de conclusão. Indique o ajuste escolhido, o motivo e o limite: “A mantido nessas doze perguntas; duas respostas ainda precisam ser revistas; documentos longos adicionais não estão cobertos”. Outra pessoa deve conseguir entender a escolha sem assistir à sessão.
Mantenha A como testemunha para o próximo diagnóstico. Se nenhuma variante atender aos critérios, não retenha nenhuma para a entrega; formule uma nova hipótese. Reserve tempo para copiar e conferir antes de iniciar essa continuação. Um teste concluído com um limite claro já traz uma decisão; ele não obriga a continuar até encontrar um vencedor.