← Todos os insights

Guia de arquiteturaRecorte: Brasil4 min de leitura

O modelo mais barato é aquele cujos erros você consegue capturar. Como precificar IA por onde os erros caem

Três formas de cortar custo de inferência: especializar um modelo pequeno, servir pesos abertos melhor e concluir tarefas de agente em menos etapas. Nenhuma precifica os erros. Um framework para isso.

Ouça este artigo · 5 min

Narração completa do artigo, gerada por IA.

Uma rede de pesca verde vista de perto, no duotone da La Madre, ao lado das palavras Onde o erro cai
Foto: rawpixel (CC0)

“Qual modelo é o mais barato para este workflow?” não tem resposta até alguém dizer onde os erros do modelo vão cair.

Nos últimos dias surgiram três bons exemplos de como baixar o custo de rodar IA. A Microsoft treinou um modelo aberto pequeno com 17 documentos e elevou o F1 de extração de 0.44 para 0.81, a um preço por token de cerca de um trigésimo da referência de fronteira mais barata. O Google mostrou que os mesmos pesos do Beam podem servir várias vezes mais tráfego com roteamento ciente de cache. A DeepSeek afirma que sua atualização conclui tarefas de agente com menos etapas e saídas mais curtas. As três são alavancas reais. Nenhuma delas diz quanto custa uma resposta errada, e, para a maioria dos workloads enterprise, esse é o maior número da conta.

O termo que falta na maioria dos business cases

Já defendemos precificar a inferência por tarefa concluída, não por token. Isso é necessário e não suficiente, porque “concluída” esconde uma distinção: concluída corretamente, concluída errada e capturada, concluída errada e não capturada.

Uma unidade mais completa é o custo por saída aceita: o que você paga pela inferência, mais o que você paga para verificar, mais o que os erros que escapam custam a você, dividido pelas saídas que você realmente usa. O modelo pequeno ajustado no teste da Microsoft e as referências de fronteira diferem em cerca de 29 vezes no preço de entrada e em aproximadamente oito vezes na taxa de erro. Qual deles é mais barato depende do preço do terceiro termo, e esse preço é definido por onde, no seu processo, um erro é capturado.

Onde um erro é capturado define seu preço

Capturado por códigoNunca capturado

  1. Checagem determinísticaSchema, totais, dados mestre: frações de centavo
  2. Revisor no workflowMinutos de uma pessoa que ia olhar de qualquer forma
  3. Sistema a jusante ou clienteRetrabalho, notas de crédito, um caso de suporte
  4. Auditor ou reguladorAchados, programas de remediação, pedidos de evidência
  5. NinguémDecisões tomadas com dados errados
Framework da La Madre. As posições são ilustrativas; cada organização deve colocar seus próprios workflows nele.

Cinco regras para precificar um workload

1. Precifique o erro que escapa antes de comparar tokens. Para cada workflow, anote quanto custa uma saída errada se ela chega à próxima etapa, e quem paga: um revisor, um cliente, um time de compliance. Se ninguém consegue nomear o número, a escolha do modelo ainda não está pronta para ser feita.

2. Compre verificação antes de capacidade onde as checagens são baratas. Um modelo com F1 de 0.81 e validade de JSON quase perfeita é uma resposta final ruim e uma boa primeira passada, se checagens determinísticas capturam a maioria de seus erros: totais que precisam fechar, IDs que precisam existir, datas que precisam ser interpretadas. Os agentes de vendas da AWS mostram o mesmo padrão em produção: checagens determinísticas para toda resposta conhecida, juízes de modelo só para o resto. A verificação move os erros para a esquerda do espectro, onde eles são baratos.

3. Gaste tokens de fronteira onde os erros escapam longe. Saídas que vão direto para clientes, contrapartes ou reguladores ficam à direita do espectro. Ali, um preço por token mais alto costuma ser o controle mais barato que você pode comprar. Roteie por consequência, não por tipo de tarefa.

4. Meça a taxa de saída aceita, não o benchmark. Benchmarks medem um modelo no harness de outra pessoa. O que você paga é a fatia de saídas que seu processo aceita sem correção, medida nos seus documentos, nas suas ferramentas e no seu setup de serving, que, como as receitas do Beam mostram, pode mudar a economia tanto quanto o modelo.

5. Reprecifique quando qualquer coisa mudar. Um novo modelo atrás de um alias, uma nova precisão, um novo prompt ou uma nova fonte de dados move a taxa de erro. O preço por saída aceita é uma medição com data, não uma propriedade de um fornecedor.

Em trabalho regulado, o lado direito do espectro é mais longo

Para um banco ou uma farmacêutica, a ponta direita do espectro inclui achados, programas de remediação e, no pior caso, decisões tomadas com dados errados de um jeito que ninguém detectou. Isso muda a aritmética mais do que qualquer preço por token consegue. Também muda o que conta como verificação: uma checagem documentada e versionada que produz evidência vale mais do que o olhar não registrado de um revisor. Isso é consistente com o que chamamos de capacidade de verificação, o novo gargalo.

Nossa visão, e é uma visão, não um fato medido: a maioria dos estouros de custo de IA enterprise que são atribuídos a preços de modelo vai se revelar, quando examinada, como custos de verificação e de erro que nunca foram precificados. Os times que controlam o gasto com IA não serão os que têm o modelo mais barato. Serão os que sabem, para cada workflow, onde seus erros caem e quanto custa capturá-los.

Tem um caso de uso de IA parado entre o protótipo e a produção?

Conte o que você quer colocar no ar. Respondemos com próximos passos honestos.

Converse sobre um caso de uso