Quando não usar um modelo de linguagem

Coloco modelos de linguagem em produção e gosto deles. É exatamente por isso que passo tanto tempo dizendo a times para não usar um. Um modelo é um componente: caro por chamada, lento comparado a uma função, não determinístico e errado em alguma porcentagem das vezes de formas que você não consegue prever por completo. Essas são propriedades boas para alguns trabalhos e desqualificantes para outros. A habilidade está em saber qual é qual antes de a feature ser construída, não depois do incidente.

A pergunta que faço primeiro

Antes de qualquer feature de IA, pergunto: isso pode ser computado? Se a resposta é um lookup, uma regra, um cálculo ou uma query sobre dados que você já tem, o modelo é a ferramenta errada, não porque não consegue, mas porque outra coisa faz isso perfeitamente, na hora, de graça e com stack trace quando falha. Um modelo que decide se um pedido tem frete grátis é um passivo. Uma função que decide isso é um fato. O modelo só merece o lugar onde o input é desestruturado, as regras são difusas ou a saída é linguagem.

Casos em que o modelo é a ferramenta errada

• Qualquer coisa com resposta correta que precisa estar exatamente certa toda vez: preços, totais, datas, limites legais, dosagens, IDs.
• Qualquer coisa num hot path com orçamento de latência apertado, onde algumas centenas de milissegundos são regressão.
• Qualquer coisa que roda num volume em que o custo por chamada domina, como classificar cada linha de log ou cada evento.
• Qualquer coisa em que não dá para construir um conjunto de evals porque ninguém consegue definir o que é uma saída boa.
• Qualquer coisa em que o usuário precisa confiar na resposta e não consegue conferir, a menos que haja um humano no loop.

O híbrido que costuma vencer

Os melhores designs que vi usam o modelo nas bordas e código no meio. O modelo transforma input bagunçado numa requisição estruturada: extrai os campos, classifica a intenção, normaliza a entidade. Código determinístico faz o trabalho de verdade: valida, calcula, consulta, decide. O modelo pode voltar no final para formular o resultado para uma pessoa. Isso mantém o não determinismo nos dois lugares onde ele é inofensivo, entender e formular, e fora do lugar onde é perigoso, a decisão. Também torna a feature testável, porque o meio é código comum com testes comuns.

O custo de estar errado

A decisão não é sobre se o modelo consegue fazer a tarefa. Modelos de fronteira conseguem quase tudo numa demo. É sobre o custo das vezes em que não vão conseguir. Um resumidor errado uma vez em cinquenta é um ótimo produto. Uma calculadora de dosagem errada uma vez em cinquenta é um processo judicial. A mesma taxa de erro, o mesmo modelo, veredictos opostos. Quando avalio uma proposta, peço a taxa de erro esperada e a consequência de um único erro, e multiplico. Se o produto não sobrevive a isso, o modelo não entra no caminho da decisão, não importa como foi a demo.

Um modelo é um componente

A mentalidade que facilita tudo isso é tratar o modelo como um banco de dados ou uma fila: uma peça de infraestrutura com características conhecidas, que você coloca onde essas características se encaixam. Ninguém põe uma fila de mensagens no meio de um checkout síncrono porque filas são empolgantes. Ninguém deveria pôr um modelo de linguagem no meio de uma regra determinística porque modelos são empolgantes. Coloque onde há linguagem, mantenha fora de onde há aritmética, e a maioria das decisões difíceis se resolve sozinha.