Os riscos do modelo de código aberto recaem primeiro na camada de acesso

Nos últimos dias, tem havido uma discussão sobre se os modelos de código aberto ficarão presos às políticas restritivas dos Estados Unidos. A primeira coisa que muda na engenharia não são as capacidades do modelo, mas a acessibilidade padrão. O modelo ainda está lá, e os papéis também. O que realmente treme primeiro são o endereço pull, a fonte do espelho, a plataforma de hospedagem, os termos da licença e a disponibilidade regional. A primeira coisa que as pessoas que fazem trabalho de acesso frequentemente encontram não é “o modelo não é forte o suficiente”, mas “será que ainda podemos obtê-lo de forma estável hoje?”

A acessibilidade padrão piora primeiro

No passado, o problema mais irritante ao acessar o modelo era “o mesmo modelo poderia ser baixado ontem, mas de repente recebeu um 403 hoje”. Esse tipo de mudança parece uma pequena flutuação na cadeia de suprimentos, mas na verdade arrasta todo o link para um estado instável: o download do peso precisa ser repetido, a fonte da imagem precisa ser trocada, a soma de verificação precisa ser recalculada, a imagem de implantação precisa ser reembalada e o cache no CI também se tornará inválido. Superficialmente, apenas a etapa de obtenção do modelo se torna frágil, mas na verdade, a premissa de “usabilidade” é retirada do sistema.

O modelo de código aberto é frequentemente entendido como “depois que o código for de código aberto, ele não será mais controlado por terceiros”. Esta frase está apenas parcialmente correta. O código-fonte aberto não significa que seja acessível por padrão, e estar visível no warehouse não significa que o ambiente de produção possa ser lançado de forma estável. Quem está hospedando, em que região ele existe, se a licença foi alterada e se há alguma restrição na frequência de download. Uma vez que esses detalhes são bloqueados pela plataforma, políticas ou termos comerciais, o que a equipe vê não é “o modelo desaparece”, mas “coisas que estavam facilmente disponíveis começam a se tornar uma infraestrutura que precisa ser mantida”.

A interface do modelo será ampliada até o limite do sistema

No passado, quando eu escrevia todos os detalhes do roteamento do modelo, a coisa mais difícil de coletar não era que a pontuação estava dois ou três pontos abaixo, mas que a interface do modelo não era estável o suficiente. Depois que uma base for substituída, os hábitos de prompt, a estrutura de saída, o formato de chamada da ferramenta e o comportamento do contexto longo mudarão de acordo. O nome do modelo parece não ter mudado, mas o analisador, o conjunto de avaliação, o log de repetição e o tratamento de falhas no sistema precisam ser executados novamente. O que foi mais facilmente exposto naquele momento foi que o sistema confundiu “um certo modelo” com “uma certa habilidade”.

Esta é também a área mais negligenciada nas discussões relacionadas aos modelos de código aberto. O que é verdadeiramente valioso não é o nome em si, mas o conjunto de capacidades substituíveis que ele pode fornecer: conclusão, classificação, extração, diálogo, invocação de ferramentas, resumo longo de artigos e geração de código. Desde que a camada de acesso vincule estas capacidades a modelos específicos, quaisquer alterações subsequentes serão ampliadas em custos de migração. Por outro lado, se a camada de interface for primeiro condensada num contrato estável, a base pode ser substituída como uma dependência, e o risco será limitado apenas até certo ponto.

Roteamento e substituto são mais importantes que substantivos

Quer o modelo de código aberto seja “selado” ou não, o impacto no sistema final geralmente não é o nome do modelo, mas se há uma saída. Se uma equipe colocar todas as tarefas em um único modelo remoto, quaisquer restrições geográficas, restrições de acesso ou mudanças nas estratégias de negócios causarão diretamente a interrupção dos negócios. Pelo contrário, desde que modelos executáveis ​​localmente, fontes de hospedagem de backup, conjuntos de modelos de diferentes níveis de capacidade e conjuntos de avaliação reproduzíveis estejam todos presentes, as limitações externas aumentarão, na melhor das hipóteses, os custos de comutação e não tornarão imediatamente o sistema indisponível.

Portanto, ao fazer julgamentos no nível do modelo, é melhor não apenas perguntar “qual modelo é mais forte”, mas também perguntar “esta cadeia de capacidade pode ser substituída por uma base?” Os pesos podem ser mantidos em um armazém controlável? As dependências podem ser bloqueadas em versões fixas? O roteamento, o cache, a reprodução e a reversão podem ser transformados em um conjunto completo de ações? Essas questões estão mais próximas do limite real do que do nome do modelo. O risco de o modelo ser restringido não desaparecerá primeiro, mas a acessibilidade padrão mudará primeiro; e o que o sistema precisa manter nunca é um modelo, mas um conjunto de capacidades que podem ser fornecidas continuamente.