Depois que o modelo de código aberto é restrito, a primeira coisa a falhar é o julgamento de regressão.

Uma vez que as restrições externas recaem sobre um modelo de código aberto, a primeira coisa que quebra muitas vezes não é “ainda pode ser baixado?” mas “os resultados desta vez podem ser vistos junto com a última vez?” O nome do modelo ainda está lá e a interface ainda pode ser conectada. O que realmente se torna difícil é que a linha de julgamento começa a oscilar: o mesmo conjunto de palavras de alerta, o mesmo lote de amostras e o mesmo fluxo de trabalho, os resultados não são mais a mesma distribuição de comportamento.

Isso parece simples no papel, mas na prática se torna muito chato. O formato de saída anteriormente aceitável de repente tem um pouco mais de explicação, a sequência de chamada de função anteriormente estável começa a mudar, há uma camada adicional de prompts de política em algumas áreas ou a mesma solicitação obtém comprimentos de contexto diferentes em entradas diferentes. Cada um deles por si só não é um acidente, mas em conjunto confundirá o julgamento do retorno.

O que quebrou primeiro foi o calibre comparativo.

Muitas equipes se concentrarão primeiro nas pontuações de benchmark, mas as pontuações são adequadas apenas para indicar as capacidades aproximadas e não para explicar “se o comportamento atual ainda pode ser seguido pelo processo antigo”. O verdadeiro lugar para ficar online não é que o modelo seja executado sozinho, mas que funcione em conjunto com o analisador, chamada de ferramenta, novas tentativas, armazenamento em cache, auditoria e roteamento. Enquanto um dos links mudar de calibre, a pontuação perderá seu significado de referência.

A situação mais típica é que nenhum problema pode ser visto no conjunto de avaliação, mas a cadeia começa a cair online. As amostras de teste são suficientemente limpas e o modelo responde muito bem às perguntas. No entanto, uma vez recebida a entrada real, uma pequena quantidade de desvio de campo pode influenciar as etapas automatizadas subsequentes. O resultado parece “o modelo ainda pode ser usado”, mas na verdade significa “o método de comparação falhou”.

A linha de base deve ser salva de acordo com o fluxo de trabalho

Para suprimir tais mudanças, não dependemos da execução de mais rodadas de listas, mas sim de transformar a linha de base em um fluxo de trabalho reproduzível. A entrada deve ter uma versão, a saída deve ter um esquema, a resposta da ferramenta deve ser reproduzível e as amostras com falha devem reter o contexto original. Só assim, depois de mudar para outros modelos, outras regiões e outras estratégias, podemos saber se o desvio está no próprio modelo ou nos links dianteiro e traseiro.

Esse tipo de linha de base tem mais medo de armazenar apenas uma pontuação e uma conclusão. As pontuações serão usadas para confortar as pessoas, as conclusões serão usadas para escrever relatórios, mas faltam os detalhes verdadeiramente úteis. Depois que as restrições forem reforçadas posteriormente, a equipe só poderá reabastecer as amostras, recarregar o calibre e recarregar os limites anormais, o que equivale a dividir o trabalho de comparação que poderia ter sido concluído de uma só vez em várias rodadas de retrabalho.

O custo real da migração é restabelecer a confiança

Após a restrição do modelo, a ação de migração parece mudar para um item disponível, mas na verdade está restabelecendo a confiança de que “este processo é relativamente estável”. A confiança não é construída por uma ligação bem-sucedida, mas por um conjunto de resultados de comparação que podem ser verificados repetidamente. Sem este conjunto de resultados, só seria executável temporariamente se mudássemos para o passado; com este conjunto de resultados, estaria dentro da faixa controlável se mudássemos para o passado.

É por isso que algumas equipes completaram a reposição na superfície, mas internamente ainda precisam esperar muito antes de ousar aumentar sua capacidade. O que está realmente bloqueado não é a acção de acesso, mas sim algo que ninguém se atreve a responder: se os limites mais importantes do antigo processo ainda se mantêm verdadeiros no novo modelo. Enquanto esta questão não for respondida com clareza, qualquer afirmação de que “a migração foi concluída” será apenas uma declaração encenada.

Somente as peças adequadas para o teste valem a pena reconstruir

Nem todos os cenários são dignos de tornar a cadeia de regressão tão pesada. Conversas ad hoc, geração leve e resumos únicos têm limites frouxos e a construção excessiva é uma perda de tempo. Mas assim que o modelo começa a participar da geração de código, extração de informações, decisões de roteamento e execução de ferramentas, o julgamento de regressão não é mais um acessório, mas uma parte do fluxo de trabalho.

As restrições externas podem ampliar esta diferença. Se pode continuar a ser usado geralmente é apenas a camada mais superficial; o que realmente determina se a equipe pode ser estável é se existe um método estável para comparar os novos resultados com a antiga linha de base. Uma vez estabelecida a comparação, a migração é apenas um problema de engenharia; uma vez que a comparação falhe, todos os julgamentos subsequentes começarão a vacilar.