Após a restrição do modelo de código aberto, a primeira coisa que precisa ser independente é a camada neutra do modelo.

Uma vez que um modelo de código aberto começa a ser restrito, a primeira coisa exposta muitas vezes não é a entrada de download, mas as suposições padrão no código. O nome do modelo foi alterado, mas a interface ainda está lá, mas o processo de negócios não está mais sincronizado com o comportamento antigo: formato de saída, sequência de chamada de função, tom de rejeição, comprimento do contexto, parâmetros de amostragem, qualquer um deles pode ser visualizado individualmente, mas empilhá-los irá arrastar o link inteiro.

Esse tipo de problema geralmente é difícil de ser considerado um problema arquitetônico. Durante a fase de desenvolvimento, vi apenas “pode ​​correr”. Depois de entrar online, descobri que a seleção do modelo já havia sido escrita na lógica de negócios. Alguns campos se adaptam apenas a um formato de retorno, algumas tentativas reconhecem apenas um método de rejeição e alguns substitutos de exceção adotam como padrão o modelo original para fornecer uma explicação mais longa. Uma vez impostas as restrições, todas essas pilhas escondidas foram expostas.

O comportamento padrão vinculará o modelo ao negócio

No estágio de acesso, o modelo é frequentemente considerado como adicionando um SDK, conectando uma API e adicionando uma palavra de prompt. Depois de conectado, a coisa mais difícil de limpar não é a chamada em si, mas as ramificações que cresceram em torno do comportamento padrão. Se a saída deve ser estritamente JSON, se a chamada da ferramenta deve ser tentada novamente após a falha, onde truncar a entrada muito longa e em qual camada colocar os prompts de controle de risco. Essas questões geralmente se enquadram no código comercial.

Depois que um modelo de código aberto é restrito ou removido das prateleiras, ou a imagem local e a versão upstream começam a se bifurcar, esses comportamentos padrão não são mais confiáveis. Superficialmente, trata-se apenas de alterar o modelo, mas por baixo é necessário alterar a análise, o monitoramento, a reversão e o teste ao mesmo tempo. O mais difícil não é escrever mais algumas linhas de adaptação, mas sim que o conjunto original de pressupostos não esteja explicitamente marcado do início ao fim.

O papel da camada neutra é espalhar as suposições implícitas

Camadas neutras em termos de modelo não são abstratas por uma questão de abstração. Sua função é muito simples: colocar palavras de prompt, verificação de esquema, roteamento, nova tentativa, downgrade, logs e avaliação em um só lugar, para que as diferenças do modelo passem primeiro pelo mesmo conjunto de limites. Dessa forma, mesmo que o modelo seja substituído por nuvem, código aberto, inferência local ou outros provedores, a empresa ainda verá um contrato unificado de entrada e saída.

Uma vez estabelecida esta camada, muitas coisas que inicialmente não estavam claras tornar-se-ão subitamente claras. Quais campos são valores obrigatórios, quais campos são apenas preferências de modelo, quais falhas podem ser repetidas, quais falhas devem ser revertidas, quais contextos serão truncados e quais indicadores podem realmente ser comparados, todos mudarão de “lembrados pela experiência” para “restritos por interfaces”. O impacto causado pelo modelo limitado não é mais inserido diretamente no código comercial, mas primeiro na camada neutra.

Nem todas as cenas são dignas desta camada

Algumas cenas não precisam que as camadas sejam tão espessas. Resumos únicos, geração temporária, experimentos internos e cadeias de ferramentas bloqueadas de modelo completamente único são suficientes para conectar o modelo nesses locais. Construir uma camada totalmente neutra para um processo de curta duração apenas irá sobrecarregar o custo antecipadamente.

Esta camada é necessária onde o modelo realmente participará do julgamento do negócio. Como extração, roteamento, execução de ferramentas, resposta de atendimento ao cliente, assistência de revisão e reescrita de lote. Nestes cenários, o modelo não é um brinquedo, mas sim uma parte do processo. Enquanto o modelo puder mudar, ou restrições externas puderem desestabilizar uma determinada entrada, a camada neutra não é uma decoração, mas uma parede que mantém a mudança dentro dos limites.

O que realmente força o modelo de código aberto a ser restringido não é a alternativa de um fornecedor específico, mas se a equipe trata as “diferenças de modelo” como cidadãos de primeira classe. Quanto mais cedo o comportamento padrão no código for espalhado, menos passivo ele será ao alterar os modelos posteriormente. O modelo pode mudar, mas os limites não podem seguir.