Desenvolvedor reduz para 0,34 rublos o custo mediano de um turno em jogo com LLM

Em um RPG de texto, uma única resposta do modelo precisa fazer várias coisas ao mesmo tempo: continuar a cena, resolver as ações do jogador, atualizar ferimentos e relacionamentos, preservar a memória dos personagens e preparar o turno seguinte. Se apenas dois campos divergirem, a história começa a desmoronar. Um golpe acerta na descrição, mas erra no cálculo. Um personagem descobre um segredo embora não estivesse presente na conversa. Um companheiro vai embora e, no campo seguinte, continua por perto.

O criador do jogo de Telegram AniWorlds deparou-se exatamente com esse problema de engenharia. Em vez de uma cadeia de agentes, ele usa uma única solicitação e recebe um JSON com 38 campos. A principal conclusão prática é surpreendentemente simples: a ordem dos campos em uma resposta estruturada afeta a consistência do resultado.

Primeiro a decisão, depois a narrativa

O modelo gera o JSON sequencialmente. Um campo posterior pode levar em conta o que já foi escrito, mas não consegue voltar e reescrever um campo anterior. Por isso, uma decisão oculta — por exemplo, se um golpe acertou — deve vir antes da descrição literária do combate.

Quando a ordem era inversa, o narrador podia primeiro descrever vividamente um golpe certeiro e depois registrar um erro no campo do resultado. As instruções no prompt de sistema não eliminavam a contradição de forma confiável. A reorganização dos campos removeu a própria origem do erro: primeiro o modelo registra o desfecho e depois descreve suas consequências.

O segundo princípio é que cada decisão deve existir em um único lugar. Se o comportamento de um companheiro for determinado simultaneamente pela regra de transição entre locais e por uma regra separada para companheiros, as respostas começam a divergir. No AniWorlds, a decisão foi transferida para um único campo, e as demais partes do esquema apenas usam seu resultado.

O que não deve ser confiado ao narrador

O criador deixou a aleatoriedade e a aritmética exata a cargo do servidor. Para cada participante do combate, o código lança dois dados d6, aplica o atributo correspondente e envia ao modelo os números prontos. O modelo não decide quem teve sorte: ele calcula o resultado com base nos dados fornecidos e o transforma em uma cena.

O custo das habilidades, a energia e os tempos de recarga funcionam da mesma maneira. O servidor informa antecipadamente quanto recurso resta e quais ações estão indisponíveis. Isso reduz o risco de o narrador esquecer um gasto anterior ou alterar arbitrariamente as regras em favor de um episódio mais dramático.

Há também um limite de conhecimento separado. Depois do desfecho, o modelo registra exatamente o que os personagens viram e ouviram. A memória deles é atualizada apenas a partir desse campo, e não da mensagem completa do jogador. A solução ainda não é perfeita: em parte dos testes, os personagens continuam recebendo informações desnecessárias. O criador reconhece honestamente que a melhoria ainda não foi comprovada.

O custo do contexto e o custo dos erros

A entrada completa ocupa de 45 a 53 mil tokens. As regras e a descrição do mundo quase não mudam, por isso ficam no início da solicitação e entram no cache do provedor. No turno 71, o custo mediano de uma solicitação foi de 0,34 rublos, e a média foi de 0,57 rublos. Sem acerto no cache, um turno custava aproximadamente 1,25 rublos.

A causa dos caros erros de cache revelou-se prosaica: os identificadores dos grupos eram recriados a cada turno. Até mesmo um único caractere alterado quebrava a correspondência do prefixo. Depois que identificadores permanentes foram fixados, o cache tornou-se mais estável. Essa é uma lição útil para qualquer produto com LLM: o cache não depende de semelhança semântica, mas de os dados de entrada permanecerem idênticos byte por byte.

O criador verifica as alterações em séries de 10 solicitações idênticas e registra a taxa de erros. O critério de aceitação é obter 10 respostas em 10 sem o defeito selecionado. Isso não comprova confiabilidade absoluta, mas impede que o problema seja declarado resolvido após um único exemplo bem-sucedido. Antes do lançamento, as regras também são revisadas por duas sessões limpas do modelo; depois, a alteração passa por 20 turnos reais.

A conclusão prática vai além dos jogos. Em sistemas com saída estruturada, coloque primeiro os fatos e as decisões e, em seguida, o texto que depende deles. Mantenha os cálculos determinísticos no código. Atribua uma única fonte da verdade a cada decisão. Faça com que a parte estável do contexto permaneça idêntica byte por byte. E meça a qualidade em séries de execuções: um “pronto” dito com confiança pelo assistente ainda não significa que o erro desapareceu.