- A discussão está migrando da "engenharia de prompt" para um estágio mais avançado: a "engenharia de contexto"
- Contexto não significa apenas a frase do prompt, mas todas as informações que um LLM pode ver antes de gerar uma resposta (instruções, histórico da conversa, memória de longo prazo, informações externas, ferramentas disponíveis etc.)
- O sucesso e o fracasso dos agentes agora dependem mais da qualidade do contexto do que do desempenho do modelo
- Agentes mais sofisticados integram vários contextos, como o calendário do usuário, e-mails anteriores e contatos, para gerar respostas mais próximas da resolução de problemas reais
- Engenharia de contexto é o processo de projetar sistemas dinâmicos adaptados à situação, fornecendo ao LLM as informações e ferramentas corretas no momento exato
O que é Context Engineering
- Recentemente, o termo "engenharia de contexto" está se espalhando rapidamente no campo da IA
- Se a tradicional "engenharia de prompt" se concentrava em projetar uma única pergunta ou instrução, a engenharia de contexto é uma abordagem mais ampla e mais poderosa
- Tobi Lutke a define como "a arte de fornecer todo o contexto para que o LLM consiga resolver a tarefa de forma confiável"
Principais elementos do contexto
- Em sistemas de agentes, o fato de funcionarem com sucesso ou não depende em grande parte de quais informações serão incluídas na memória de trabalho (working memory)
- A maioria das falhas dos agentes não vem do modelo, mas da falta de contexto adequado
Componentes do contexto
- Prompt/instruções de sistema: instruções básicas, exemplos e regras que definem o comportamento do modelo
- Prompt do usuário: pedido ou pergunta imediata do usuário
- Estado/histórico da conversa: fluxo da conversa até o momento e informações de contexto
- Memória de longo prazo: conversas anteriores em várias etapas, preferências do usuário, resumos de projetos passados e conjunto de informações que o modelo aprendeu a manter no longo prazo
- RAG (geração aumentada por recuperação): informações recentes e altamente relevantes trazidas de documentos externos, bancos de dados, APIs etc.
- Ferramentas disponíveis: definições de funções e ferramentas embutidas que o modelo pode chamar (ex.:
check_inventory, send_email etc.)
- Saída estruturada: definição do formato de resposta que o modelo deve seguir (ex.: JSON)
Por que o contexto é importante
- Na prática, o fator que torna possível criar agentes de IA eficazes não é código complexo nem a qualidade do modelo, mas o quanto de contexto apropriado você consegue fornecer
- Enquanto um agente simples, "de demonstração", recebe apenas a solicitação do usuário e devolve uma resposta básica, um agente "quase mágico" considera um contexto rico e gera respostas muito mais úteis e humanas
- Comparação
- Agente de baixa qualidade (demo): vê apenas a solicitação simples e gera respostas engessadas. Ex.) para um e-mail dizendo "Você tem tempo amanhã?", responde mecanicamente algo como "Amanhã posso. Que horário seria bom para você?"
- Agente de alta qualidade (quase mágico): pode usar tudo, desde o próprio calendário, histórico de e-mails anteriores, informações sobre a identidade da outra pessoa e opções de chamadas de ferramentas necessárias, para gerar respostas naturais e adaptadas à situação. Ex.) "Amanhã minha agenda está cheia, mas quinta de manhã está livre, então já enviei um convite de calendário. Se puder, me avise"
- Assim, o fator de sucesso não é o algoritmo nem o modelo em si, mas fornecer o contexto certo para a tarefa
- A maioria das falhas dos agentes de IA é resultado de falhas no design do contexto, não do modelo
A evolução da engenharia de prompt para a engenharia de contexto
- Se a engenharia de prompt foca na otimização de instruções em uma linha de texto, a engenharia de contexto abrange uma gama muito mais ampla de informações, ferramentas e design estrutural
- Engenharia de contexto é a "competência profissional de projetar e construir sistemas que fornecem ao LLM, de forma sistemática, as informações e ferramentas necessárias, no formato e no momento corretos, para que ele consiga cumprir a tarefa"
Características da engenharia de contexto
- Design do sistema completo: contexto não é apenas um template de prompt, mas o produto de todo o sistema que atua antes da chamada ao LLM
- Geração dinâmica: seleção e processamento, em tempo real, de várias informações como calendário, e-mail e busca na web, de acordo com a tarefa
- Fornecimento de informações e ferramentas no momento certo: o princípio "Garbage In, Garbage Out"; é importante garantir que o modelo não receba informações desnecessárias nem fique sem informações essenciais
- Importância da clareza do formato: ao carregar informações, é preciso resumir e estruturar em vez de apenas listar tudo de forma dispersa, e também transmitir com clareza como usar as ferramentas
Conclusão
- A essência do desenvolvimento de agentes de IA poderosos e confiáveis não está em um "prompt mágico" nem no modelo mais recente, mas na engenharia de contexto (projetar e fornecer o contexto)
- Isso vai além de um simples problema técnico: exige capacidade de projetar sistemas de ponta a ponta, alinhando necessidades de negócio e objetivos com informações, ferramentas e definições de saída estruturada
- O ponto central é fornecer as informações adequadas, no formato certo e no momento exato, para que o LLM consiga concluir a tarefa
Referências
2 comentários
Parece muito que só estão mudando o nome.
Comentários do Hacker News
Recentemente escrevi no meu blog sobre esse tema, veja meu texto - Context Engineering
Acho que os textos do Drew Breunig tratam esse assunto de forma realmente fantástica
O timing coincidiu com o período em que o meme de “context engineering” estava circulando, mas na verdade o trabalho não tem relação com esse meme
O texto How Long Contexts Fail - por que contextos longos falham explica de várias formas como contextos longos causam problemas e como surge o chamado “context rot”
O texto How to Fix Your Context - como consertar seu contexto dá nome a várias técnicas, como Tool Loadout, Context Quarantine, Context Pruning, Context Summarization e Context Offloading, e propõe formas de resolver o problema
Acho que vale muito a pena ler o post do Drew Breunig
Isso é realmente importante não só para criar seus próprios agentes, mas também para usar coding agents agora
Essas limitações e esses padrões de comportamento provavelmente vão continuar por um bom tempo
Estou curioso para ver quem vai desenvolver primeiro um Logic Core que automatize o engenheiro de contexto
Também acho que isso é uma “skill de um mês”
No fim, vai desaparecer em breve como tantas outras modas
Esses problemas são vistos pela pesquisa em LLMs como produtos dos LLMs atuais
Já existem pesquisas sobre como usar milhões de ferramentas ao mesmo tempo e manter contextos longos estáveis
No futuro, exceto em casos especiais que exijam conexão com outros provedores, provavelmente um único agente bastará na maioria dos casos
Quem estiver projetando sistemas de agentes do futuro com base nos LLMs atuais pode acabar como o LangChain
Do mesmo jeito que o LangChain feito para GPT-3 ficou obsoleto rapidamente com o GPT-3.5
Para quem já usou LLM ou entende como ele funciona, isso é bem óbvio
Também era evidente que “prompt engineering” como “skill” não duraria muito como ponto central
Basicamente, trata-se de dar entrada (contexto) e ação (saída) ao LLM, e isso exige muito trabalho de pipeline
Concordo com a conclusão de que “criar agentes de IA poderosos e confiáveis está se afastando da busca por prompts mágicos ou updates de modelo”
Faz sentido focar mais em “context engineering, isto é, fornecer a informação e as ferramentas certas no formato e no momento adequados”
Mas, se esse “formato adequado” e esse “momento adequado” não estão definidos de forma essencial, isso não continua sendo perseguir uma “solução mágica”?
Se “a informação adequada” for “a informação que faz o LLM produzir uma resposta suficientemente correta”, então isso não parece essencialmente diferente de prompt engineering
Com essas máquinas não determinísticas, no fim das contas não vejo muitas heurísticas confiáveis além de “testar prompts e ver o resultado”
No fim, é um pensamento mágico sem fim
Mesmo que agora mudem o nome de “prompt engineering” para “context engineering”, continua sendo mexer em várias coisas para encontrar algo que funcione num espaço incerto
Essencialmente, é overfitting
Prompt engineering no fim é isso
O problema é que “o formato adequado, no momento adequado” não está definido de forma essencial
A maior parte dos conselhos reais sobre “como usar bem IA” parte exatamente desse problema
No fim, parece tocar tambor e fazer ritual xamânico
Nos frameworks teóricos mais recentes, esse processo é dividido em duas etapas: exploração (Exploratory) e descoberta (Discovery)
A etapa de exploração pode ser vista como um tipo de dispositivo de dispersão de material no ar
Introduz-se em alta velocidade uma substância marcadora facilmente identificável, geralmente descrita com uma metáfora fecal
A etapa de descoberta é conceituada como a análise do padrão de dispersão
Resumindo as duas etapas: “tenta qualquer coisa” e depois “olha o resultado”
Agora que todo mundo percebeu que “prompt engineering” não era uma skill tão grandiosa, parece que a indústria de IA continua mudando o alvo
A nova skill, no fim, é “programação”
A mesma skill de antes
Para entender essas coisas, é preciso escrever programas você mesmo
Você entende cada vez mais ao escrever programas para treinar LLMs, rodar inferência e analisar o comportamento
No começo eu tinha teorias e expectativas sobre os resultados, mas depois de treinar LLMs de várias formas, cheguei a resultados e convicções totalmente diferentes
O processo de implementar as ferramentas faz toda a diferença
Eu também só tenho experiência intermediária em programação de machine learning, mas acho que ter construído pessoalmente um compilador de complexidade intermediária é o ponto-chave para obter bons resultados em sistemas complexos
Como você acha que o Karpathy aprendeu isso?
A resposta está no blog do Karpathy
É como aconselhar alguém a escrever um compilador para entender compiladores
Tecnicamente está certo, mas a maioria das pessoas não quer ir tão fundo
Essa discussão está ficando cada vez mais parecida com fóruns de jogos como WoW, onde gamers testam estratégias e discutem entre si numa linguagem coletiva estranha
As tais estratégias quase sempre são encontradas por tentativa e erro, e são discutidas numa linguagem que só faz sentido dentro daquele grupo
A programação também está se adaptando cada vez mais a uma era de gamificação
Power users vendem estratégias falsas para iniciantes ou para executivos excessivamente inclinados à mentalidade gamer
Na verdade, a mesma coisa já se repetia nos ciclos anteriores de hype de software corporativo
Desta vez, porém, essa “moda puxada por power users” penetrou profundamente até nas áreas de influência, controle e workflow que antes pertenciam aos desenvolvedores, ou seja, aos builders
O que muitos desenvolvedores sentem hoje provavelmente não é muito diferente do que QA, SRE e CS já sentiam quando alguém dizia “isso agora é a tendência!” e passava a impor tooling ou práticas
Conclusão:
“Criar agentes de IA poderosos e confiáveis não depende de prompts mágicos nem de updates de modelo, e sim de context engineering: fornecer a informação e as ferramentas corretas no formato e no momento certos para o caso de uso do negócio”
Na verdade, esse mesmo princípio também se aplica a humanos
Se você der a informação certa na hora certa, humanos também resolvem melhor
Eu não gosto dessa tendência de comparações superficiais entre machine learning e humanos
Não traz insight e quase nunca está realmente certa
No fim, trata-se de encontrar e apertar com eficiência os botões de objetivo dentro de um ambiente
Não é tão diferente da engenharia de software tradicional
Só que o resultado é mais não determinístico
Eu sempre peço sem parar para UX e PMs explicações sobre “mockups, requisitos, critérios de aceitação, exemplos de input/output e por que esse recurso é importante”
A menos que seja possível escanear o cérebro e extrair o que a pessoa quer, na prática é indispensável explicar direito o que se deseja
Isso não é algo em que dá para depender apenas de “feeling”
O importante não é mais contexto, e sim contexto melhor
(exemplo clássico: X-Y problem)
Mesmo dando um contexto excelente para os LLMs mais recentes, eles ainda falham
Nossa empresa já explora isso a fundo há mais de dois anos
O nível de fé cega na ideia de que “contexto é a resposta” é impressionante
A partir de certo ponto, acho mais rápido fazer o trabalho diretamente sem IA
Pelo menos isso deixa alguma lição útil, ao contrário de passar horas montando contexto para LLM
Fiquei curioso com exemplos em que o LLM falha mesmo com contexto suficiente
Seria bom compartilhar casos concretos
A busca por um prompt mágico nunca foi realmente “prompt engineering”
Em essência, sempre foi “context engineering”
Muitos autoproclamados especialistas em IA venderam isso como prompt engineering, mas na verdade não entendiam bem a essência
RAG (retrieval-augmented generation) não é um conceito que surgiu de repente este ano
Ferramentas que encapsulam know-how complexo como embeddings, vector DB, graph DB e afins estão ficando cada vez mais populares
Grandes plataformas também seguem melhorando essas ferramentas e oferecendo ecossistemas cada vez maiores
Parece que vivem criando novos conceitos para o mesmo problema e apenas trocando o nome
No fim, é repetir um ritual xamânico de bater tambor diante da fogueira e recitar encantamentos
Parecia invocar um demônio, recitando o encantamento certo com as palavras certas e torcendo para que obedecesse bem às minhas ordens
Dentro de mim havia um conflito entre o engenheiro que quer confiabilidade, repetibilidade e forte cobertura de testes, e a complexidade incontrolável do momento atual
Tenho muito respeito por quem faz demos em larga escala com esse tipo de sistema
Isso me lembra os tempos em que eu fazia demos de pesquisa sobre vulnerabilidades de segurança
Por melhor que você se prepare, o resultado pode desandar a qualquer momento ao vivo, e eu lembro de suar frio durante apresentações
É uma visão muito parecida com a minha experiência
Quando coloco contexto em um LLM, costumo usar a pergunta: “um humano conseguiria resolver isso só com esta informação?”
Quando eu construía um produto de text2SQL no passado, quando o modelo falhava até um analista de dados real dizia coisas como “ah, essa tabela é antiga; agora usamos esta outra”
No fim, isso significa que o LLM erra quando falta o contexto de que um “analista humano” precisaria
Se há algo faltando nesse tema, é justamente “evaluations”
Ainda me surpreende ver projetos de IA sem avaliações, ou tratando isso de forma frouxa
Avaliações são ainda mais importantes do que testes na engenharia tradicional
O conjunto de avaliação nem precisa ser grande; basta cobrir bem o domínio do problema
Sem isso, tudo não passa de “chute”
E eu também me faço bastante a pergunta “um humano conseguiria resolver isso só com esta informação?”
Já esperei que um LLM resolvesse problemas que nem humanos conseguiriam resolver
Regra clássica da programação tradicional
“Se você tentar permitir que programadores codifiquem em inglês, vai descobrir que, na prática, programadores também não sabem escrever direito em inglês”
É meio piada, mas tem um fundo de verdade
A maior parte da linguagem natural não é assim tão clara
Se você consegue expressar com extrema precisão o que quer em inglês, talvez já pudesse ter escrito isso diretamente numa linguagem para a máquina interpretar
Se você fizer uma pergunta de sim/não, há 50% de chance de receber uma resposta falsa
Essa é uma característica disso
Eu costumo fazer o modelo responder esse tipo de pergunta antes de começar de fato a tarefa
Por exemplo, se houver incerteza, instruo o modelo a perguntar primeiro e a solicitar exemplos de padrões de código já usados
Tento induzi-lo a usar templates existentes como exemplo
Quem finge ser cientista de dados não quer avaliações
Por isso quase não há avaliações fora de produtos realmente monetizados
Dizer que “o rei está nu” não dá dinheiro
Quando a aplicação é necessária no trabalho real, a etapa de avaliação entra obrigatoriamente