Blog

O que é engenharia de contexto?

10 min de leitura

A resposta curta

Engenharia de contexto é decidir que informação o modelo enxerga numa dada requisição, como ela é organizada, e o que fica de fora. Engenharia de prompt é sobre como você pergunta. Engenharia de contexto é sobre o que você entrega.

O termo apareceu porque os times perceberam que o gargalo tinha mudado de lugar. Depois que o prompt está competente, a diferença entre um sistema que funciona e um que não funciona é quase inteiramente se o material certo estava na frente do modelo no momento em que ele respondeu.

Por que o termo apareceu

No começo, o modelo era a restrição e frase esperta produzia ganho real. Conforme os modelos melhoraram, isso deixou de ser onde estava a alavanca. Instrução melhor não compensa documento ausente.

Ao mesmo tempo, os sistemas ficaram mais complicados. Uma requisição em produção hoje monta instrução de sistema, trechos recuperados, histórico de conversa, atributos do usuário, definição de ferramenta e resultado de chamadas anteriores. Alguém precisa decidir o que entra.

Essa decisão é engenharia, não redação. Tem orçamento, tem trade-off, tem modo de falha, e pertence à revisão de código.

A janela de contexto é orçamento, não recipiente

Janela grande incentivou um vício: colocar tudo dentro e deixar o modelo se virar. Isso falha de três formas ao mesmo tempo.

Custa dinheiro em toda requisição, e prompt longo em volume domina a conta. Custa latência, porque mais entrada significa resposta mais lenta. E custa acurácia, porque material relevante compete com ruído, e a atenção do modelo é finita mesmo quando a janela não é.

Trate como orçamento que você gasta de propósito. Cada token adicionado deveria conquistar seu lugar melhorando uma classe específica de resposta.

As quatro fontes

Instrução. Quem é o sistema, o que faz, o que nunca faz. Em geral estática, e a parte em que os times investem demais.

Conhecimento recuperado. Os trechos puxados para aquela pergunta específica. Normalmente o maior valor por token e o mais difícil de acertar.

Estado. Histórico de conversa, o que o usuário já disse, o que já foi tentado. Cresce sem limite se ninguém gerenciar.

Capacidade. Definição de ferramenta e resultado de chamadas já feitas. Fácil de subestimar, porque dez descrições de ferramenta podem ser maiores que a pergunta em si.

Recuperação é engenharia de contexto

A maior parte do que chamam de problema de RAG é problema de contexto com outro nome. O modelo não falhou em raciocinar. Ele raciocinou corretamente sobre o material errado, que é o que acontece quando a recuperação devolve algo plausível em vez de algo relevante.

É por isso que recuperação e geração precisam ser avaliadas em separado, divisão que cobrimos em RAG e bancos vetoriais. Se o trecho certo nunca chega, nenhum trabalho de prompt conserta a resposta.

A implicação prática é que melhorar contexto normalmente significa melhorar o que é selecionado, não escrever mais instrução sobre como usar.

Ordem e posição importam

Onde uma coisa fica no contexto muda quanto ela influencia a resposta. Material no começo e no fim tende a pesar mais que material enterrado no meio, e o efeito fica mais forte conforme a entrada cresce.

Então coloque a instrução que não pode ser ignorada nas bordas, não no centro de uma parede de texto recuperado. Coloque o trecho mais relevante primeiro em vez de confiar que o modelo vai ranquear dez deles.

Isso é sem glamour e é mensurável. Reordenar o mesmo conteúdo, sem mudar mais nada, move a acurácia num conjunto de referência com frequência suficiente para valer um teste explícito.

Compactação, resumo e memória

Qualquer conversa de comprimento real uma hora excede o que você quer enviar. Você tem três opções e cada uma perde algo.

Truncar e você perde o começo, que muitas vezes é onde o requisito real foi enunciado. Resumir e você perde detalhe, e o próprio resumo pode alucinar. Recuperar seletivamente do histórico e você perde continuidade quando a seleção erra.

Não existe resposta limpa. O que funciona na prática é proteger explicitamente um conjunto pequeno de fatos, aqueles que precisam sobreviver a toda compactação, e tratar o resto como recuperável. Decida quais são esses fatos de propósito, em vez de descobrir a resposta durante um incidente.

Como saber se o contexto está funcionando

Meça recuperação separada de geração. Para recuperação, verifique se o material correto apareceu no que foi montado. Para geração, verifique se a resposta é sustentada pelo que de fato foi entregue. Os métodos estão em evals de LLM.

Depois instrumente o próprio orçamento. Registre quantos tokens cada fonte consumiu em cada requisição. Os times costumam se surpreender ao descobrir que definição de ferramenta ou histórico de conversa está comendo a maior parte da janela, enquanto os trechos recuperados, a parte que carrega a resposta, ficam com uma fração.

Sem esses números, ajustar contexto é adivinhação, e também esconde para onde vai o dinheiro. Cobrimos o lado do custo em quanto custa.

Onde os times desperdiçam

Quatro padrões, em ordem de frequência. Instrução de sistema enorme que repete a mesma regra de cinco formas. Histórico completo de conversa quando os dois últimos turnos bastariam. Dez definições de ferramenta quando a requisição só poderia precisar de duas. E trecho recuperado grande demais, com uma página sobre doze assuntos entrando por causa de um parágrafo.

A correção em todos os casos é a mesma: ser deliberado sobre o que merece lugar. Essa disciplina é boa parte do motivo de algumas features de IA aguentarem tráfego real e outras só funcionarem na demo, e é central em como construímos IA em produção, ponta a ponta.

Se sua feature de IA funciona nas perguntas simples e desmonta nas reais, o problema costuma ser contexto, não modelo. Trinta minutos e você sai sabendo onde está vazando.

Agendar call Ou mande os detalhes por escrito
Voltar para o blog