Comprometer a arquitetura de uma empresa com um único modelo de linguagem significa assumir a dependência de algo cujo preço, capacidade e termos mudam várias vezes ao ano. Não se trata de desconfiar de nenhum fornecedor; trata-se de que o ritmo das mudanças de mercado faz com que qualquer decisão desse tipo se torne obsoleta antes mesmo de se pagar.
A maneira correta de tratar um modelo é como um componente substituível, assim como você trataria um banco de dados ou um provedor de e-mail transacional.
A discussão sobre autonomia total é frequentemente enquadrada como uma questão de maturidade tecnológica. Seria mais útil enquadrá-la como uma questão econômica: onde está a mão de obra cara e onde está o risco caro?.
O Stanford HAI documentou que o custo de inferência para um sistema com capacidades equivalentes ao GPT-3.5 diminuiu mais de 280 vezes entre novembro de 2022 e outubro de 2024, caindo de aproximadamente US$ 20 para US$ 0,07 por milhão de tokens. Essa magnitude de declínio é sem precedentes na infraestrutura tecnológica.
Existem três consequências práticas:
O que é caro hoje pode ser barato daqui a um ano. Casos de uso anteriormente descartados devido ao custo tornam-se viáveis novamente sem qualquer intervenção.
O melhor modelo hoje pode não ser o mesmo daqui a seis meses. A liderança mudou de mãos diversas vezes.
Os modelos estão sendo descontinuados. As versões têm um ciclo de vida, e aqueles que construíram seu software com base em uma versão específica acabam migrando por necessidade, não por conveniência.
Uma arquitetura que não permite aproveitar a primeira consequência ou absorver a terceira está permanentemente a pagar um preço excessivo.
Não significa usar vários modelos ao mesmo tempo ou construir uma camada de abstração complexa. Significa que Alterar o modelo de uma etapa específica é uma configuração e não um projeto.. Quatro condições:
Elemento | Onde ele deveria morar? | Consequências se você mora na área de cobertura do provedor. |
|---|---|---|
Lógica de fluxo | Na sua orquestração | Cada mudança de modelo é um redesenho. |
Instruções e orientações | Versionado em seu repositório | Eles não podem ser comparados ou auditados. |
Conjunto de avaliação | No seu sistema | É impossível saber se a mudança é para melhor ou para pior. |
Registro de execuções | Na sua infraestrutura | Você perde seu histórico de dados ao fazer alterações. |
A terceira linha é crucial. Sem um conjunto específico de estudos de caso com a resposta correta para o seu negócio, a pergunta "Este outro modelo seria melhor para nós?" não tem resposta objetiva. E quem não consegue comparar não consegue negociar nem decidir: só pode confiar.
As tabelas públicas de desempenho de modelos servem apenas como orientação, não para tomada de decisões. Elas medem capacidades gerais com base em testes padronizados; seu caso é específico e depende da sua terminologia, documentação, tolerância a erros e orçamento.
É comum que um modelo com classificação inferior em comparações gerais tenha um desempenho melhor em um caso específico, especialmente se for mais barato e o caso não exigir raciocínio complexo. Isso só pode ser descoberto testando com seus próprios casos específicos.
É por isso que o conjunto de avaliações é o ativo mais duradouro de um projeto de IA: ele sobrevive aos modelos, permite mudanças sem riscos desnecessários e transforma uma decisão baseada na fé em uma decisão orientada por dados. Nós o desenvolvemos em A IA não elimina o controle de qualidade, ela o torna ainda mais importante.
Seria desonesto apresentar a independência como gratuita. Ela tem um custo, e existem razões legítimas para a concentração:
A diferença entre concentrar-se por escolha e concentrar-se por acidente é que, no primeiro caso, a capacidade de optar por não participar é preservada: a lógica, os avisos, a avaliação e o registro permanecem sob seu controle. Concentrar o consumo é uma decisão de negócios reversível; externalizar a lógica não é.
Três etapas, nenhuma das quais requer a reconstrução do sistema:
Com esses três passos, da próxima vez que os preços mudarem ou surgir uma alternativa melhor, a decisão será comercial, não técnica. Que é exatamente como deveria ser.
Isso faz com que o registro da validação seja um requisito, e não uma boa prática. E isso tem uma implicação de design: o monitoramento que ocorre, mas não é registrado, não prova nada.
Antes da próxima renovação com um fornecedor de modelos, é aconselhável responder a esta pergunta: Quanto tempo levaríamos para avaliar uma alternativa e quanto tempo levaríamos para mudar, caso ela se mostrasse melhor?
Se a resposta for "dias para avaliar, semanas para alterar", a posição é sólida. Se a resposta for que os fluxos teriam que ser refeitos, a empresa não está escolhendo um fornecedor: está herdando um a cada ano.
Isso ocorre porque os preços, as capacidades e a disponibilidade mudam várias vezes ao ano. O Stanford HAI documentou que o custo de inferência para um sistema equivalente ao GPT-3.5 caiu mais de 280 vezes entre o final de 2022 e o final de 2024, e versões específicas são descontinuadas ao longo do tempo.
A substituição do modelo de uma etapa específica deve ser uma configuração, não um projeto. Isso exige que a lógica de fluxo, os prompts versionados, o conjunto de avaliação e o log de execução residam na infraestrutura da própria empresa, e não na do fornecedor.
Eles servem como guia, não como tomadores de decisão. Medem capacidades gerais com base em testes padronizados, enquanto cada caso depende de sua própria terminologia, documentos específicos, tolerância a erros e orçamento. Um modelo com classificação inferior pode ter um desempenho melhor em um caso específico.
Trata-se de uma coleção de estudos de caso reais com as respostas que a organização considera corretas. Ela sobrevive a mudanças no modelo de negócios, permite a comparação objetiva de alternativas e transforma a decisão de trocar de fornecedor em uma decisão baseada em dados, em vez de um ato de confiança.
Quando existem descontos relevantes por volume, requisitos de residência de dados que apenas esse fornecedor atende, integração nativa com a plataforma já em uso ou uma equipe pequena para a qual a manutenção de abstrações seria desproporcional, a chave é manter a capacidade de rescisão.
Em três etapas que não exigem retrabalho: extraia os prompts e instruções para seu próprio repositório e versione-os, construa um conjunto de avaliação com cinquenta ou cem casos reais e isole a chamada do modelo por trás de sua própria interface refinada.
Quanto tempo você levaria para trocar de modelo se o preço subisse amanhã? Criamos a camada de abstração, o conjunto de avaliação e o registro para que a decisão volte a estar em suas mãos. Vamos conversar → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
