Como testar comparação de versões de software por modelos de IA

Para testar comparação de versões de software por uma IA, informe primeiro o esquema de versionamento e prepare um gabarito com casos que confundem números decimais, ordenação textual e regras de pré-lançamento. Em SemVer, 1.10.0 vem depois de 1.9.0: cada componente numérico é comparado separadamente. Isso não permite aplicar as mesmas regras a qualquer nome de produto.

Uma avaliação útil também verifica quando o assistente pede documentação. SemVer, o padrão de empacotamento Python e códigos comerciais de fornecedores têm convenções diferentes. A resposta correta deve indicar a regra aplicada, preservar o texto original e distinguir precedência, igualdade textual, compatibilidade e decisão de atualização.

Resumo rápido

• Declare o esquema antes de pedir a comparação.
• Não converta versões em números decimais nem ordene apenas como texto.
• Inclua pré-lançamentos, metadados, entradas inválidas e casos sem regra informada.
• Valide o gabarito com a documentação e um comparador apropriado.
• Maior precedência não comprova segurança nem compatibilidade operacional.

Defina qual pergunta está sendo avaliada

“Qual versão é maior?” parece simples, mas pode esconder tarefas distintas. Você pode querer ordenar identificadores pela precedência, descobrir qual publicação é mais recente, escolher uma versão permitida por uma dependência ou decidir se a atualização funciona no seu sistema. Essas perguntas não são equivalentes.

Comece o teste com uma instrução explícita: “Compare a precedência das versões abaixo segundo SemVer 2.0.0. Responda A maior, B maior, mesma precedência ou entrada inválida. Explique a regra decisiva em uma frase”. Ao restringir a tarefa, fica possível construir um gabarito objetivo.

Para outro grupo, use a especificação de versões do ecossistema Python. Em um terceiro, entregue apenas nomes comerciais fictícios e espere que o modelo peça o esquema ou a documentação. Essa separação impede que um bom desempenho com três números seja interpretado como habilidade geral para qualquer software.

Registre também a diferença entre identificar e recomendar. Um pacote com maior precedência pode ser experimental, incompatível com seu ambiente ou fora da faixa exigida por outra dependência. O teste básico de comparação não autoriza o assistente a mandar instalar a versão vencedora. Avalie recomendações de atualização em uma etapa própria, com requisitos adicionais.

SemVer: casos concretos para o gabarito

A especificação SemVer usa três componentes numéricos principais e define regras para pré-lançamentos e metadados de construção. A tabela abaixo aplica essas regras a identificadores sintéticos. Não se refere a lançamentos de produtos reais nem estabelece quais pacotes os adotam.

Transforme cada linha em uma pergunta separada antes de apresentar uma tabela completa ao modelo. Depois inverta a ordem das entradas e confira se o resultado também se inverte. Para metadados, a resposta deve preservar a igualdade de precedência sem afirmar que as duas strings ou os dois artefatos são idênticos.

Quando o assistente encontra uma entrada inválida, observe se ele a corrige silenciosamente. Um sistema pode ter uma política explícita de normalização, mas essa política precisa fazer parte do contrato do teste. Em modo estrito, comparar uma versão inventada a partir da entrada é uma falha, mesmo que o resultado pareça razoável.

Python e identificadores de fornecedores exigem regras próprias

A especificação de versões do empacotamento Python cobre elementos que não devem ser tratados como simples SemVer. Para um conjunto inicial de comparação, use os pares sintéticos 1.0.dev1 e 1.0a1, 1.0rc1 e 1.0, 1.0 e 1.0.post1. Os resultados esperados são, respectivamente, dev antes de alpha, candidato antes da versão final e final antes do pós-lançamento.

Acrescente 1.0 e 1.0.0: nesse esquema, os segmentos de lançamento são comparados com preenchimento por zeros, produzindo igualdade na comparação. Isso contrasta com a validação estrita de uma entrada SemVer incompleta. O rótulo do esquema deve estar em cada caso, e não apenas em uma nota distante.

Inclua também 1!1.0 e 2.0 no grupo Python. A versão com época 1 tem maior precedência que a versão sem época explícita, cuja época é zero. Não remova o trecho anterior à exclamação durante a limpeza dos dados. Para validar esses exemplos, utilize a classe Version da biblioteca packaging em um ambiente de teste.

Em produtos com nomes como “Edição 2026”, “R2” ou códigos internos, a pergunta pode não ter resposta determinada pelo texto. Um fornecedor pode usar calendário, sequência de construção ou nomenclatura comercial. Sem documentação, o gabarito deve aceitar “não há informação suficiente para estabelecer a ordem”, em vez de premiar um palpite.

Escolha alguns casos deliberadamente indeterminados. Por exemplo, compare “Sistema Alfa 9” com “Sistema Beta 12”: os nomes identificam produtos distintos, e os números não demonstram precedência entre eles. Esse grupo avalia a capacidade de reconhecer o limite da tarefa, que uma lista apenas com SemVer não mede.

Como executar e pontuar uma avaliação reproduzível

Prepare um arquivo com identificador do caso, esquema, versão A, versão B, resultado esperado e referência da regra. Mantenha a resposta esperada separada do prompt apresentado à IA. Revise o arquivo antes da execução; um gabarito errado transforma uma resposta correta em suposta falha do modelo.

Para Python, uma conferência mínima pode usar o código abaixo, depois de disponibilizar a biblioteca packaging no ambiente. O exemplo demonstra uma comparação específica. Não converta isso em comparador universal para qualquer aplicação.

from packaging.version import Version

assert Version("1.10") > Version("1.9")
assert Version("1.0rc1") < Version("1.0")
assert Version("1.0") == Version("1.0.0")
assert Version("1!1.0") > Version("2.0")

Para SemVer, use uma implementação que declare suporte à especificação e configure seu modo estrito, se houver. Registre a versão da própria ferramenta comparadora e confira manualmente os casos de fronteira na especificação. Evite adotar um recurso de coerção que transforma entradas inválidas sem registrar a transformação.

Solicite uma saída estruturada com campos esquema, status, comparacao e justificativa_curta. Defina como representar “não comparável” e “entrada inválida” antes de rodar. A justificativa serve para localizar a regra usada; não é necessário pedir uma narrativa longa de raciocínio interno.

Pontue separadamente a validação da entrada, o resultado da comparação e a justificativa da regra. Acrescente um critério para recomendações indevidas: uma resposta pode acertar a ordem e ainda dizer “atualize em produção agora” sem ter recebido informações suficientes. Não dilua esse comportamento numa média geral de acertos.

Rode o mesmo conjunto ao mudar prompt, modelo ou ferramenta. Guarde respostas completas e configurações para investigar regressões. Os testes metamórficos ajudam a verificar propriedades como a inversão de pares, enquanto o guia de limites inclusivos e exclusivos complementa a avaliação de faixas permitidas.

Exemplo: suporte de uma integradora em Curitiba

Imagine uma integradora fictícia de Curitiba que recebe chamados com versões de conectores. A equipe usa IA para resumir o problema e indicar se a versão informada está abaixo de uma referência. O exemplo é ilustrativo e não representa um resultado medido de atendimento.

A empresa separa o catálogo em duas famílias. O Conector Loja usa SemVer por contrato interno. O pacote de análise Python usa a especificação do seu ecossistema. O formulário do chamado passa a exigir nome do componente, versão original e família de versionamento. Quando o cliente não sabe a versão, o assistente solicita o dado em vez de deduzi-lo pela data da mensagem.

No teste do Conector Loja, a versão recebida é 1.9.0 e a referência é 1.10.0. A IA deve marcar “abaixo da referência”. Em outro chamado, a versão é 1.10.0-rc.1: ela também fica abaixo da referência final segundo SemVer. O resumo deve manter o sufixo, porque removê-lo mudaria a comparação.

O chamado seguinte contém “Conector Loja R2”. Como esse formato não faz parte do contrato declarado, o fluxo encaminha a entrada para revisão. A equipe pode descobrir que o cliente citou um nome de instalador, mas isso exige consulta ao catálogo. O modelo não recebe pontos por converter R2 em 2.0.0 por conta própria.

Por fim, o relatório distingue “versão abaixo da referência” de “atualização aprovada”. A segunda conclusão depende de requisitos do ambiente e homologação. A equipe usa o checklist para conferir respostas de IA antes de enviar orientações ao cliente e mantém uma lista de casos que já produziram erro.

Erros comuns

• Tratar 1.10 como número decimal. Identificadores de versão não são medidas de uma grandeza contínua.
• Ordenar qualquer lista alfabeticamente. Essa abordagem não implementa as regras dos componentes numéricos.
• Aplicar SemVer a todo software. Verifique o contrato do componente e o formato admitido.
• Confundir mesma precedência com mesmo arquivo. Metadados distintos não comprovam igualdade de artefatos.
• Eliminar sufixos durante a limpeza. Guarde a entrada original e registre qualquer normalização autorizada.
• Declarar compatibilidade só pela ordem. Maior precedência não substitui a análise dos requisitos e notas de versão.

Outro erro é corrigir apenas o prompt depois de cada resposta ruim e testar novamente a mesma pergunta. Reserve casos inéditos e repita o conjunto anterior. Uma melhoria precisa sobreviver à troca dos números, à inversão dos pares e à presença de uma entrada inválida próxima de outra válida.

Perguntas frequentes

1.10 é sempre maior que 1.9?

Depende da tarefa e do esquema. Como números decimais, 1,10 é menor que 1,9. Como versões Python, 1.10 vem depois de 1.9. Em SemVer estrito, ambas as strings sem o terceiro componente são inválidas. O teste precisa dizer qual interpretação é válida.

Uma versão beta vem sempre antes de uma final?

Em SemVer, o pré-lançamento tem menor precedência que a versão normal com os mesmos componentes principais. Isso não permite afirmar que qualquer beta é menor que qualquer final. Por exemplo, 2.0.0-beta tem maior precedência que 1.9.0 pela comparação dos componentes principais.

Como comparar datas usadas como versões?

Declare o formato e a regra de comparação do fornecedor. Uma sequência que parece data pode ser um identificador comercial. Se o contrato definir ano, mês e revisão, teste esses campos segundo o contrato e inclua valores inválidos. Não adivinhe a convenção apenas pela aparência.

Posso usar a IA como único comparador?

Para decisões automatizadas com regras formais, prefira uma biblioteca apropriada no código e use a IA para explicar ou classificar o contexto. Ainda teste a integração: a versão pode ser extraída incorretamente de um chamado antes de chegar ao comparador.

Acertar todos esses casos comprova que o modelo é confiável?

Comprova apenas o desempenho no conjunto e na configuração registrados. Amplie os casos conforme os componentes usados pela empresa e mantenha exemplos de regressão. Validação de entradas, classificação e recomendação operacional continuam sendo responsabilidades distintas.

Fontes e leitura recomendada

• SemVer: especificação oficial 2.0.0
• Python Packaging: especificação de versões e comparações
• Packaging: documentação de Version e InvalidVersion
• PEP 440: proposta e contexto do padrão Python