Operar um sistema baseado em um modelo de linguagem de grande porte não termina quando ele é disponibilizado ou quando sua precisão inicial é aprimorada. O sistema pode continuar totalmente disponível enquanto aprova silenciosamente decisões erradas, consome o orçamento rapidamente ou muda, durante falhas, para um modelo cuja qualidade não foi testada. Por isso, a quinta parte da série Running LLM systems in production concentra-se na operação diária, como a camada que torna o sistema observável, controlável, interrompível e capaz de se recuperar.
Monitore a decisão, não apenas o serviço
Métricas de serviço tradicionais, como taxa de solicitações, erros, latência e uso do processador, não revelam se o agente está tomando boas decisões. A fonte propõe acrescentar uma camada de monitoramento específica para decisões, incluindo volume de decisões, proporção de execução automatizada, distribuição da confiança composta, tempo de cada nó, casos de bloqueio dos controles de segurança, consumo de tokens e custo, taxa de intervenção humana e resultados de avaliações ocultas em amostras do tráfego de produção.
A fonte define quatro famílias de sinais: decisão, segurança, custo e desempenho, e qualidade. Se não for possível medir tudo, a prioridade deve ser a proporção de execução automatizada, os bloqueios dos controles de segurança, o custo total dos modelos e a taxa de substituição das decisões do sistema por humanos.
A fonte também recomenda dividir os registros em três camadas: dados operacionais de alto volume, metadados da decisão dentro dos limites de confiança e dados brutos ou estruturados sujeitos a criptografia e controle rigoroso. Cada decisão deve carregar um identificador estável, decision_id, que conecte métricas, registros, traces e o registro de auditoria, permitindo investigar uma decisão específica do início ao fim.
Faça com que o custo seja mensurável e limitado
As chamadas aos modelos não devem ser distribuídas por diferentes partes da base de código, pois isso dificulta atribuir e controlar os custos. Em vez disso, a fonte propõe um único gateway pelo qual passem todas as chamadas, responsável por calcular tokens e custos por locatário, capacidade e modelo, além de aplicar limites de taxa e orçamento.
As ferramentas de redução de custos vêm na seguinte ordem: não chamar o modelo quando uma regra determinística for suficiente, agrupar itens em uma única chamada, armazenar temporariamente resultados determinísticos em cache, escolher um modelo menor para tarefas simples e, depois, reduzir o contexto e as instruções desnecessárias. Também é necessário calcular os tokens estimados antes da chamada, em vez de contar cada solicitação como uma única unidade, além de estabelecer um teto geral para a plataforma e limites para tentativas de repetição e loops ilimitados de ferramentas.
Roteamento, fallback e chave de desligamento
Na prática, não existe um único modelo para todas as tarefas. Tarefas de baixo risco e alto volume podem ser encaminhadas para um modelo menor, enquanto casos ambíguos ou sensíveis podem ser atribuídos a um modelo mais capaz. Também é possível usar uma família diferente para o modelo de julgamento, para que os modelos não compartilhem os mesmos pontos fracos. Cada modelo presente no caminho de roteamento ou fallback deve ser avaliado, pois a mudança para um modelo alternativo pode alterar a qualidade.
Durante uma interrupção do provedor, deve-se usar uma cadeia de fallback definida, com um único prazo total, um intervalo de proteção que impeça chamadas a um provedor conhecido por estar indisponível e chaves de idempotência para evitar que a decisão seja processada duas vezes caso a chamada expire depois de ter sido efetivamente bem-sucedida. Quando a alternativa não for aceitável, a decisão deve ser encaminhada a uma pessoa, em vez de ocultar a degradação.
Quanto à chave de desligamento, a fonte propõe que ela funcione como um estado operacional compartilhado, que pode ser geral ou específico para um locatário ou uma capacidade. Os estados incluem: operação normal, HUMAN_ONLY, para interromper a execução automatizada mantendo as sugestões para as pessoas, e HALTED, para interromper totalmente a tomada de decisões. Se não for possível acessar a chave, o comportamento seguro é mudar para o modo de revisão humana, e não continuar na operação normal.
A arquitetura que impede o caos
A fonte relaciona a operabilidade a uma arquitetura hexagonal que separa a lógica de domínio dos pacotes dos provedores de modelos por meio de uma interface e de portas de adaptação. Dessa forma, é possível trocar o provedor sem reescrever a lógica de negócios e testar o domínio usando um modelo simulado sem rede ou custo.
A arquitetura básica inclui serviços de agentes sem estado, um gateway de modelos, um armazenamento de auditoria somente de acréscimo, uma memória compartilhada para limites e para a chave de desligamento, um armazenamento de segredos e armazenamento de objetos para entradas e dados sensíveis. A fonte também enfatiza uma identidade independente para cada serviço, o menor nível possível de privilégios e a verificação da correspondência entre a identidade do locatário e a solicitação a cada salto, especialmente ao usar concessões de autorização de curta duração para tarefas adiadas.
Por que esta notícia é importante?
O valor prático aqui não está em adicionar um novo componente, mas em reunir os pontos críticos de controle em uma única porta: o gateway que torna possível trocar o modelo é o mesmo que mede os custos, aplica limites, gerencia o roteamento e o fallback e aciona a interrupção. O sucesso dessa abordagem continua condicionado ao teste efetivo de cenários de falha, como a interrupção do provedor do modelo, a ativação da chave de desligamento, uma carga repentina e a reinicialização de um nó durante uma decisão em andamento. Sem esses testes, os mecanismos de recuperação permanecem suposições não comprovadas.