Existe um reflexo compreensível quando se monta a primeira integração: mandar tudo. O ticket, o histórico do cliente, os últimos pedidos, a política inteira, o log do aplicativo. Se o modelo lê texto, quanto mais texto, melhor ele decide — parece.
A documentação oficial do jev-1.13 diz o contrário, com nome próprio. Ela
lista “state grande cheio de detalhe irrelevante” entre os nove modos de falha
declarados e usa a expressão context rot para o efeito: material sem relação
com a pergunta custa acurácia.
Os dois limites, que são diferentes
É fácil confundir duas coisas que aparecem juntas.
O limite de orçamento é uma barreira de API. A página de modelos declara 64 mil tokens por requisição, cobrindo o state mais todas as perguntas combinadas, e 32 mil para o state mais a pergunta mais longa. A documentação de primitivas dá uma referência prática: o orçamento de cerca de 32 mil tokens equivale a mais ou menos 150 mil caracteres de texto em inglês. Passar disso é erro; ficar abaixo é sucesso técnico.
O limite de qualidade não tem número publicado. É a degradação que começa bem antes do teto: a acurácia cai conforme o state cresce com conteúdo que a decisão não usa. O texto oficial explica o mecanismo em duas partes — o detalhe irrelevante age como distrator, e um state grande torna mais difícil descobrir qual parte da entrada produziu a resposta errada.
A segunda parte é a que morde no dia a dia. Um state enxuto que erra é depurável: você olha os três campos e entende. Um state de vinte mil palavras que erra é um mistério.
Por que o state é também o que você paga
Há uma segunda razão, econômica, para tratar o state com cuidado. O Jev cobra por token de entrada, e a saída é gratuita. Em qualquer chamada realista, o state domina a conta — a pergunta tem dezenas de tokens, o documento tem milhares.
Isso produz uma coincidência raríssima em engenharia: a decisão que melhora a acurácia é a mesma que reduz o custo. Cortar o campo que a pergunta não usa economiza dinheiro e melhora a resposta. A conta por decisão está em custo por decisão.
O que fazer antes de chamar
A orientação oficial é filtrar em código primeiro e mandar somente os campos de que a pergunta precisa. Na prática, isso vira uma lista curta de hábitos.
Recorte pela pergunta, não pelo registro. Se a pergunta é sobre a elegibilidade da política, mande a cláusula relevante, não o contrato inteiro. A receita oficial de classificação por confiança faz esse recorte de propósito: usa só a seção que descreve o negócio, e esse corte é parte da receita.
Nomeie as partes. A página de state recomenda objeto JSON para a maioria das requisições, porque cada parte fica com nome descritivo e as relações continuam claras. O ganho é duplo: o modelo tem onde se apoiar e a página de limites recomenda apontar as partes do state pelo nome dentro da instrução — isso reduz a indireção, outro modo de falha declarado. O formato está em state.
Use um Noul de relevância quando não puder filtrar antes. É a saída que a documentação oferece para o caso em que você não sabe, de antemão, o que é relevante: perguntar. O cookbook de classificar passagens de RAG é a versão trabalhada — cada passagem recuperada recebe uma pontuação e o código decide quais chegam ao modelo que responde.
Junte o que a decisão compara, e só isso. A página de state é clara sobre o critério: ponha informações relacionadas juntas quando a decisão exige comparar essas partes. Um pedido, uma política e a mensagem do cliente são um state só quando a pergunta é se o reembolso se aplica. Não são, se a pergunta é sobre o tom da mensagem.
O que não é context rot
Muitas perguntas na mesma chamada não são o problema. O mecanismo é outro: as perguntas são avaliadas em paralelo contra o mesmo state, e o padrão oficial de fan-out especulativo recomenda justamente agrupá-las. O que degrada é o state, não a lista.
State estruturado não é state grande. Um objeto JSON com dez campos relevantes é melhor que um parágrafo corrido com os mesmos dez fatos. A estrutura não é peso morto; ela ajuda o modelo a localizar.
Nem todo erro em state grande é context rot. Vale checar antes se a falha não é leitura literal, indireção ou instrução contraditória — os outros modos de falha listados em limites do Jev. Encurtar o state não conserta uma pergunta mal escrita.
Um teste que vale mais que a teoria
Pegue vinte casos em que você conhece a resposta certa. Rode duas vezes: uma com o state que você manda hoje, outra com o state recortado para os campos que a pergunta usa. Compare acerto, confiança média e tokens de entrada.
É um experimento de uma tarde, e ele responde de uma vez três perguntas: se o recorte melhora a acurácia, quanto ele economiza e se a confiança do modelo sobe junto. Para montar a primeira versão desse teste, veja primeiros passos.
Perguntas frequentes
O que é context rot no Jev?
É o nome que a própria documentação usa para a queda de acurácia quando o state cresce com conteúdo não relacionado à decisão. O texto oficial diz que o detalhe irrelevante age como distrator e que um state grande torna mais difícil saber qual parte da entrada produziu uma resposta errada.
Quais são os limites de tokens do jev-1.13?
A página de modelos declara 64 mil tokens por requisição, cobrindo o state mais todas as perguntas, e 32 mil para o state mais a pergunta mais longa. A documentação de primitivas dá a equivalência aproximada de 150 mil caracteres de texto em inglês para o orçamento de cerca de 32 mil tokens.
Se eu couber no limite, está tudo bem?
Não. O limite é uma barreira de API; o context rot é uma perda de qualidade que começa muito antes dele. Caber é condição necessária, não suficiente.
Como eu reduzo o state sem perder informação?
Filtrando em código antes de enviar, mandando só os campos que a pergunta usa. Quando não é possível filtrar antes, a orientação oficial é usar um Noul de relevância como primeiro passo, e o cookbook de passagens de RAG traz a versão trabalhada.
Mais perguntas na mesma chamada também causam context rot?
Não pelo mesmo mecanismo. As perguntas são avaliadas em paralelo contra o mesmo state, e o padrão oficial de fan-out recomenda agrupá-las. O que degrada é conteúdo irrelevante no state, não quantidade de perguntas.
Context rot é problema só do Jev?
Não, é um efeito conhecido em modelos que leem contexto longo. O que é específico aqui é a documentação declarar o efeito, dizer em que situação ele aparece e dar o remédio: filtrar antes, apontar as partes do state pelo nome e mandar só o que a pergunta precisa.