Aplicações baseadas em modelos de linguagem raramente falham só porque o prompt foi mal escrito. Em produção, os problemas mais difíceis costumam estar no que acompanha a pergunta: histórico da conversa, dados do usuário, documentos corporativos, data e hora, permissões, resultados de ferramentas e limites de custo. É nesse ponto que engenharia de contexto deixa de ser um rótulo e passa a orientar decisões de arquitetura.

Em uma apresentação no QCon AI, Ricardo Ferreira descreveu a construção de uma habilidade para Alexa apoiada por um LLM, memória em Redis e componentes do ecossistema Java. O relato mostra por que ampliar a janela de contexto ou trocar por um modelo maior não resolve, por si só, continuidade conversacional, recuperação de conhecimento e objetividade nas respostas.

Contexto como fluxo de arquitetura

O caso apresentado combinou memória de curto e longo prazo, busca vetorial, filtros por usuário, reescrita de consultas, reranking, sumarização e cache semântico para tornar a operação mais consistente. A conclusão prática não depende tanto das bibliotecas usadas: contexto é um recurso finito, mutável, caro e sujeito a falhas de qualidade.

Para equipes que projetam assistentes, agentes e interfaces de linguagem natural, o prompt é apenas uma etapa de uma cadeia maior. Antes da chamada ao modelo, a aplicação precisa selecionar, transformar, validar e observar as informações que vão compor o contexto.

A implementação relatada por Ricardo Ferreira

Ferreira relatou a implementação de uma skill chamada My Jarvis, integrada a dispositivos Alexa. A arquitetura utiliza uma função AWS Lambda como backend, LangChain4j para orquestração em Java, modelos da OpenAI e uma camada de memória construída sobre Redis, incluindo o projeto open source Redis Agent Memory Server.

O caso tinha uma restrição concreta: as interações da Alexa precisavam retornar dentro de oito segundos. Isso muda o desenho do sistema. Não basta gerar uma resposta plausível; é necessário recuperar dados, eventualmente acionar ferramentas, montar o contexto, invocar modelos e responder dentro de um orçamento rígido de latência.

Ao evoluir a solução, Ferreira relatou o uso dos seguintes mecanismos:

  • ferramentas para informar data e hora atuais ao modelo;
  • memória de sessão para preservar interações recentes;
  • memória de longo prazo recuperada por busca semântica;
  • separação de usuários com metadados e pós-filtragem dos resultados vetoriais;
  • bases de conhecimento separadas das memórias pessoais;
  • transformação de consultas para resolver referências como “ele” ou “onde ele mora”;
  • few-shot prompting para reduzir respostas excessivamente amplas;
  • reranking para priorizar trechos mais relevantes entre os resultados recuperados;
  • janela de tokens e sumarização para conter o crescimento do histórico;
  • cache semântico para evitar chamadas repetidas ao LLM.

O histórico de mensagens sem limite elevava o custo de forma não linear. A mitigação relatada foi resumir o conteúdo relevante à medida que o contexto se aproximava do limite de tokens, em vez de simplesmente descartar as mensagens mais antigas.

O impacto no desenho de sistemas

Na minha leitura, uma aplicação de IA generativa madura precisa de um pipeline de contexto, não de um único prompt extenso. Esse pipeline define quais informações entram na chamada, em que ordem, com qual prioridade, para qual usuário e sob quais regras de atualização.

Modelos de linguagem são stateless do ponto de vista da chamada de API: cada requisição precisa carregar tudo o que o modelo deve considerar. A memória, portanto, não fica “dentro” do modelo. A aplicação a constrói e a injeta seletivamente na requisição atual.

Histórico de sessão e memória persistente atendem a problemas distintos

O histórico recente ajuda a manter o fio da conversa. Ele é útil para referências locais, como interpretar “ele” depois que uma pessoa foi mencionada na frase anterior. Manter toda a sessão indefinidamente, porém, é caro e frágil: aumenta o número de tokens, acumula saídas de ferramentas e inclui dados antigos que podem não ter relação com a pergunta atual.

A memória de longo prazo atende a outra necessidade. Ela registra fatos, preferências, eventos ou informações persistentes e permite recuperá-los depois por similaridade semântica. Uma preferência como “o usuário prefere respostas em português” tem natureza diferente de uma troca temporária sobre uma tarefa em andamento.

Colocar tudo na mesma estrutura tende a produzir dois efeitos: custo maior e recuperação menos precisa. A separação entre memória de sessão, memória persistente e base de conhecimento, apresentada no caso, é uma decisão arquitetural sólida independentemente do banco vetorial ou framework adotado.

Busca vetorial encontra candidatos, não a resposta definitiva

Um erro recorrente em implementações de RAG é tratar o resultado de uma busca vetorial como resposta pronta. A busca por embeddings encontra conteúdos semanticamente próximos; não garante que o trecho seja o mais importante, o mais atual, o mais autorizado ou o mais específico.

No exemplo, uma pergunta sobre cor favorita também recuperou informação sobre linguagem de programação favorita. Isso é esperado quando palavras e conceitos semelhantes aparecem no conjunto recuperado. O modelo respondeu além do necessário porque as duas informações faziam parte do contexto enviado.

O reranking preenche essa lacuna. Depois de recuperar um conjunto inicial de candidatos, um segundo modelo ou algoritmo atribui uma pontuação mais precisa à relação entre pergunta e conteúdo. Com isso, o sistema pode reduzir o contexto final e aumentar a relevância dos itens enviados ao LLM principal.

Calibração de reranking, filtros e sumarização

O relato traz um ponto operacional importante: limiares de relevância não são universais. A pontuação de 0,80 em um reranker pode se comportar de maneira muito diferente em outro modelo, idioma, domínio ou depois de uma mudança no método de embeddings.

Da mesma forma, filtros de tenant, usuário, departamento ou classificação de acesso não devem ser vistos como refinamento opcional. Em aplicações multiusuário, eles compõem o isolamento de dados. Recuperar um documento semanticamente relevante, mas pertencente a outra pessoa ou organização, é uma falha de segurança e privacidade, não apenas uma resposta de baixa qualidade.

Sumarização controla tokens, mas transforma o histórico

A sumarização é mais criteriosa do que cortar cegamente mensagens antigas. Ela preserva fatos, decisões, preferências e compromissos, removendo detalhes redundantes. Ao mesmo tempo, transforma o contexto original em uma interpretação produzida por outro modelo.

Por isso, resumos podem omitir nuances, consolidar afirmações que deveriam permanecer separadas ou manter dados que perderam validade. Em sistemas com implicações legais, financeiras, médicas ou de segurança, o resumo não deve substituir o registro original auditável. Ele deve ser um artefato de otimização, vinculado à sua fonte, versão e momento de geração.

Limites do que o relato permite afirmar

A apresentação descreve um caso prático útil, mas não traz uma avaliação comparativa controlada entre estratégias, modelos ou fornecedores. Não há métricas publicadas de precisão, taxa de alucinação, latência por estágio, taxa de acerto de cache ou qualidade do reranking antes e depois da adoção das técnicas.

Também não é possível estender os custos citados a outros produtos ou workloads. O custo de uma aplicação com IA depende do modelo, do tamanho dos prompts, do volume de chamadas, do idioma, da frequência de ferramentas, da taxa de cache, da política de retenção e do preço vigente de cada provedor.

Outro limite é que uma arquitetura para assistente doméstico não se transfere automaticamente para ambientes corporativos. Um sistema empresarial pode exigir controle de acesso baseado em atributos, trilha de auditoria, retenção regulatória, criptografia por tenant, avaliação de respostas e mecanismos de aprovação humana.

Decisões práticas para equipes que operam IA generativa

Antes de levar uma prova de conceito para produção, arquitetos e líderes técnicos podem tornar a engenharia de contexto uma sequência explícita de decisões.

  1. Mapear as classes de contexto, distinguindo instruções do sistema, dados da sessão, memória persistente, documentos corporativos, resultados de ferramentas e dados temporais.
  2. Definir proprietários e tempo de vida: para cada informação, registrar origem, usuário ou tenant, data de criação, validade, política de atualização e tempo de retenção.
  3. Aplicar autorização antes da recuperação: filtros de acesso devem restringir a consulta antes que o conteúdo entre no prompt ou seja exibido ao usuário.
  4. Usar recuperação em duas etapas: recuperar mais candidatos inicialmente e reduzir o conjunto com reranking, regras de negócio, atualidade e nível de confiança.
  5. Limitar tokens por orçamento, com tetos distintos para instruções, histórico, documentos recuperados, saída do modelo e chamadas auxiliares.
  6. Sumarizar com rastreabilidade: manter referência para as mensagens originais que fundamentaram cada resumo e prever reprocessamento quando regras ou modelos mudarem.
  7. Instrumentar o cache semântico, medindo hits, misses, respostas incorretas reaproveitadas e diferenças entre similaridade calculada e intenção real do usuário.
  8. Construir uma suíte de avaliação com perguntas ambíguas, referências pronominais, mudanças temporais, dados de múltiplos usuários e consultas com documentos parecidos.

Fluxo de contexto em um assistente interno

Em um cenário hipotético de assistente interno, o fluxo pode começar com autenticação e resolução de identidade. Depois, a aplicação classifica a intenção, reescreve referências dependentes da conversa, consulta fontes permitidas, aplica filtros de acesso e atualidade, executa reranking e monta um pacote de contexto dentro de um orçamento de tokens.

Após a resposta, o sistema pode registrar telemetria, avaliar se houve chamada de ferramenta, decidir se algum fato merece promoção para memória persistente e verificar se pergunta e resposta podem alimentar o cache semântico. Esse desenho evidencia que o LLM é um componente essencial, mas não é o sistema inteiro.

Riscos operacionais além da qualidade da resposta

O risco mais evidente é o vazamento de contexto entre usuários. A pós-filtragem mencionada na apresentação pode funcionar conforme a tecnologia de recuperação, mas exige validação cuidadosa: conteúdos não autorizados não podem chegar à etapa de geração nem aparecer em logs, métricas ou caches compartilhados.

Há também o risco de context rot, expressão usada para a degradação da utilidade do contexto à medida que ele cresce. Mais informação não significa necessariamente uma resposta melhor. Contexto em excesso pode distrair o modelo, introduzir contradições e diluir instruções importantes.

  • Cache semântico pode devolver conteúdo desatualizado ou semanticamente parecido, mas incorreto para a intenção atual.
  • Rerankers podem favorecer textos com maior sobreposição lexical e deixar de lado documentos mais recentes ou normativamente superiores.
  • Chamadas auxiliares a LLMs para resumo, roteamento e transformação de consulta aumentam custo, latência e pontos de falha.
  • Ferramentas expostas ao agente exigem contratos estritos, validação de parâmetros, idempotência e limites de execução.
  • Memórias persistentes podem registrar preferências ou fatos errados sem mecanismos de correção, expiração e revisão.

A recomendação não é evitar essas técnicas, mas tratá-las como componentes de produção: versionados, monitorados, testados e sujeitos a rollback. Sem observabilidade, uma cadeia de contexto é difícil de depurar, porque a resposta final não mostra quais dados foram recuperados, descartados, resumidos ou reutilizados do cache.

Contexto não é acúmulo de mensagens

O valor central do caso está em desfazer uma expectativa comum: a de que um modelo mais novo, uma janela maior ou um prompt mais extenso resolverão os problemas de uma aplicação conversacional. Essas escolhas podem melhorar partes do resultado, mas não substituem decisões sobre memória, recuperação, segurança, custo e latência.

Considero que a engenharia de contexto deve aparecer cedo na arquitetura, ao lado de APIs, bancos de dados, observabilidade e controle de acesso. A equipe precisa saber quais dados o modelo recebe, por que os recebe, quanto custam, de onde vieram e quando deixam de ser confiáveis.

Com esse desenho explícito, o comportamento do sistema tende a ser mais previsível. Em IA aplicada a produtos reais, essa previsibilidade costuma valer mais do que uma resposta ocasionalmente brilhante produzida por um contexto mal governado.