← Notas

O que uma sugestão técnica não traz junto

Toda recomendação de arquitetura embute um trade-off, e o trade-off só se resolve com números do sistema de quem recebe a sugestão — que quem sugere não tem.

Uma sugestão de arquitetura chega como afirmação e é, na verdade, uma hipótese sobre um sistema que quem sugere não mediu.

A orientação pública sobre construir com modelos é explícita quanto à natureza da escolha: "Agentic systems often trade latency and cost for better task performance, and you should consider when this tradeoff makes sense". A palavra que carrega o peso é when. Não existe resposta universal; existe uma resposta por sistema, que depende de onde o tempo e o dinheiro estão indo naquele sistema.

E os números que decidem isso são específicos e mensuráveis. A documentação de métricas de serving decompõe a latência que o usuário sente: "End-to-End Latency = Time to First Token + Total Generation Time". Uma sugestão de trocar o mecanismo de busca mexe numa fração da primeira parcela. Se a segunda parcela for a dominante, a sugestão está tecnicamente correta e praticamente irrelevante — as duas coisas ao mesmo tempo.

O que isso implica sobre como receber sugestões: elas são boas como hipótese e ruins como plano. A resposta madura a uma delas raramente é "vou fazer" ou "não vou fazer". É "vou medir a parcela que você está apontando" — que é mais barato que implementar e mais honesto que ignorar.