Coloque cada fato no tipo certo de contexto

O problema

Uma equipe monta um agente de suporte que precisa saber a política de reembolso da empresa, o histórico completo do ticket atual e o status mais recente do pedido do cliente. Alguém decide simplificar: cola o manual de políticas inteiro, o histórico completo do ticket e todo o log de eventos do pedido em cada chamada, "pra garantir que o modelo tenha tudo que precisa". O contexto cresce, o custo por chamada sobe, e a taxa de acerto cai — porque o único parágrafo da política que realmente importa para aquele ticket está perdido no meio de dez páginas de texto genérico.

O erro não foi incluir informação demais. Foi tratar "onde um fato mora" como uma decisão única — jogar tudo no mesmo lugar — quando na verdade existem pelo menos quatro lugares diferentes para um fato viver, cada um certo para um tipo diferente de informação.

Quatro lugares, quatro perguntas

Para cada fato que uma aplicação precisa saber, três perguntas decidem onde ele deveria morar:

• Volatilidade: esse fato muda a cada chamada, ou é estável por dias/semanas?
• Volume: o fato cabe inteiro e é sempre necessário, ou é grande demais e só uma fração é relevante por vez?
• Escopo: o fato pertence só a esta troca de mensagens, a esta sessão inteira, ou precisa sobreviver entre sessões diferentes?

A partir dessas respostas, quatro destinos ficam claros:

1. Mensagem/prompt da chamada atual — para fatos de alta volatilidade e escopo estritamente local: o ticket que está sendo respondido agora, o texto que o usuário acabou de digitar.
2. Bloco de contexto estável (system prompt ou arquivo de projeto) — para fatos de baixa volatilidade que toda chamada precisa: um resumo curto da política, não o manual inteiro. Se o conteúdo muda toda hora, ele não pertence aqui.
3. Busca/RAG — para fatos de alto volume onde só uma fatia pequena é relevante por vez: a base de conhecimento completa, o histórico de milhares de tickets anteriores. A aplicação busca o trecho relevante e injeta só ele.
4. Memória persistente entre sessões — para fatos que precisam atravessar conversas diferentes: a preferência de idioma do cliente, o fato de que ele já abriu três tickets sobre o mesmo defeito.

O erro do cenário inicial foi tratar um fato de volume alto e volatilidade baixa (o manual de políticas) como se fosse um fato de escopo local — jogando o documento inteiro na mensagem em vez de indexá-lo e buscar só o trecho relevante.

Lost-in-the-middle não é resolvido com mais contexto

Modelos de linguagem tendem a prestar mais atenção ao início e ao fim de um bloco de contexto longo. Um fato crítico posicionado no meio de um texto extenso tem mais chance de ser subutilizado na resposta — mesmo que tecnicamente esteja "no contexto". Isso costuma ser mal diagnosticado como "o modelo não é bom o suficiente", quando na verdade é um problema de posicionamento e volume.

A mitigação certa não é aumentar a janela de contexto ou repetir o fato importante várias vezes esperando que "grude". É reduzir agressivamente o que é incluído — só o que é necessário para aquela chamada específica — e posicionar os fatos mais críticos perto das bordas: logo no início da instrução, ou imediatamente antes da pergunta final. Um sistema que busca um parágrafo específico da política e o coloca perto do final do prompt tende a ter desempenho melhor do que um que despeja o manual inteiro em algum lugar do meio.

Prompt caching depende de estabilidade byte a byte

Cachear o prefixo estável de um prompt — o system prompt, uma política fixa, exemplos que não mudam — reduz custo e latência em chamadas repetidas que compartilham esse prefixo. Mas o cache só é válido se o conteúdo cacheado for idêntico byte a byte entre chamadas.

Um erro comum e silencioso: alguém inclui um timestamp, um id de sessão gerado dinamicamente, ou qualquer valor que muda a cada chamada dentro do bloco que deveria ser cacheado. O cache invalida silenciosamente a cada chamada, sem erro visível — só o custo que não cai como esperado. A correção é simples uma vez identificada: separar o que é genuinamente estável (vai no bloco cacheável) do que muda a cada chamada (vai fora, na parte não cacheada da mensagem).

Onde a intuição erra

Três respostas que parecem seguras mas erram uma restrição real:

• "Colocar tudo no prompt garante que o modelo não vai errar por falta de informação." Ignora custo, latência e o efeito lost-in-the-middle — mais contexto nem sempre significa mais acerto.
• "RAG resolve qualquer problema de conhecimento grande." RAG introduz sua própria fonte de erro: se a busca trouxer o trecho errado, o modelo recebe um contexto relevante-parecendo-relevante mas factualmente inútil, e não tem como saber que a busca falhou.
• "Cache é só uma otimização de custo, não afeta corretude." Na prática, decidir errado o que fica dentro do bloco cacheado pode fazer a aplicação servir contexto desatualizado sem perceber, porque o cache "funcionou" tecnicamente — só que com o conteúdo errado.

Coloque em prática

No laboratório desta lição você vai implementar uma função que recebe uma lista de fatos com seus metadados de volatilidade, volume e escopo, e decide para cada um o destino correto entre os quatro descritos aqui — e um conjunto de testes que confirma que a decisão bate com o framework antes de você seguir para a próxima lição.