Superando o RL com reflexão: GEPA e Optimize Anything — Lakshya A. Agrawal, GEPA

Autoria: AI Engineer · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Beating RL With Reflection: GEPA and Optimize Anything — Lakshya A. Agrawal, GEPA · Canal: AI Engineer · 20:41 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Engenharia de prompts e contexto, Modelos de IA

Resumo

Lakshya A. Agrawal apresenta a otimização reflexiva como alternativa eficiente em dados ao reinforcement learning: em vez de aprender apenas com recompensas numéricas e atualizar pesos, o método analisa traces e feedback textual para melhorar prompts. GEPA usa reflexão e uma seleção de candidatos baseada em fronteira de Pareto, e é apresentado com resultados em tarefas como matemática, programação e resolução de issues em repositórios. A abordagem é ampliada em Optimize Anything, uma API para otimizar qualquer artefato textual que possa ser avaliado, incluindo código, agent harnesses e skills. A palestra também aborda a criação de evals a partir de traces de produção e a possibilidade de combinar a otimização de prompts com atualizações de pesos.

Pontos-chave

Muitos cenários de aplicação têm poucos dados disponíveis ou rollouts caros, o que torna a eficiência amostral um gargalo.
A otimização reflexiva analisa o trace completo de um rollout e aproveita feedback textual, em vez de depender apenas de uma recompensa escalar.
Uma alteração em linguagem natural no prompt pode produzir mudanças de comportamento maiores do que pequenas atualizações sucessivas de pesos.
GEPA combina reflexão com seleção de candidatos baseada em fronteira de Pareto para evitar ficar presa a uma solução local.
Optimize Anything aplica a mesma lógica a qualquer artefato textual que possa ser avaliado, como código, agent harnesses e políticas de escalonamento.
A palestra apresenta exemplos de melhoria de desempenho em tarefas de programação, matemática, geração 3D e resolução de issues.
Skills otimizadas em um agente podem ser reutilizadas com outros modelos e reduzir o tempo de execução de tarefas em repositórios.
Traces de produção anotados por humanos podem servir para otimizar o prompt de um LLM as a judge e, em seguida, melhorar o agente.
O palestrante defende que modelos mais capazes também podem se beneficiar de instruções mais precisas sobre a tarefa.

Capítulos

Início	Capítulo	Resumo
00:12	O gargalo da eficiência amostral	A palestra apresenta os limites de dados e custo do reinforcement learning e propõe aproveitar o feedback textual dos traces.
04:34	GEPA e otimização de prompts	GEPA é comparado ao GRPO e demonstrado em tarefas de perguntas e respostas, matemática e programação de hardware.
08:22	Reflexão e seleção de candidatos	O método analisa feedback, propõe prompts melhores e mantém uma fronteira de Pareto para evitar estagnação em ótimos locais.
12:42	Optimize Anything em aplicações práticas	A API é aplicada à geração 3D, à construção de agentes e à otimização de skills para repositórios.
16:32	Modos de otimização e resultados	O palestrante descreve modos de uso, resultados em diferentes domínios e a otimização de evals a partir de traces de produção.
20:11	Aprendizado contínuo e encerramento	A apresentação menciona pesquisas sobre co-otimização de pesos e prompts e conclui com orientações para começar a usar a abordagem.

Citações

Podemos aproveitar essas outras informações extremamente ricas? — 02:58

Uma única atualização em linguagem natural pode provocar uma grande mudança de comportamento. — 03:29

Se você consegue expressar algo como texto e avaliá-lo, o GEPA pode otimizá-lo. — 10:34

Não tenha receio de otimizar no espaço textual: muitos problemas podem ser formulados como otimização. — 20:41

Conceitos e entidades

GEPA (conceito): Método de otimização reflexiva que melhora prompts por meio de feedback textual e seleção de candidatos baseada em fronteira de Pareto.
Optimize Anything (ferramenta): API apresentada para otimizar artefatos textuais avaliáveis, como código, agent harnesses e políticas.
Otimização reflexiva (conceito): Abordagem que analisa traces e feedback de execuções para propor melhorias em texto, como prompts.
Fronteira de Pareto (conceito): Estratégia de seleção que mantém candidatos com vantagens em diferentes exemplos, em vez de guardar apenas o melhor resultado agregado.
Lakshya A. Agrawal (pessoa): Apresentador da palestra sobre GEPA e Optimize Anything.
AMD (empresa): Empresa cujo acelerador NPU XDNA2 é usado como exemplo de tarefa com pouca informação disponível.
GPT-4.1 (modelo): Modelo citado na comparação de desempenho com GPT-4.1 mini em uma tarefa de matemática.
GPT-4.1 mini (modelo): Modelo cuja performance em uma tarefa de matemática foi melhorada por otimização de prompt.
GSkill (ferramenta): Recurso mencionado para otimizar skills voltadas à resolução de issues em um repositório.
OpenAI (empresa): Empresa citada como autora de uma publicação sobre a criação de sistemas de IA que se aprimoram.

Tradução completa (pt-BR)

00:12 Olá, pessoal. Meu nome é Lakshya Agrawal e hoje vou apresentar, em nome de um esforço muito amplo, o problema da otimização reflexiva, ou seja, como podemos melhorar prompts, agents e modelos por conta própria a partir de feedback textual. A pergunta que nos fazemos é: como podemos ensinar a IA a realizar novas tarefas? A maneira padrão tem sido fazer atualizações de pesos com gradiente descendente, seja durante o pré-treinamento, o fine-tuning supervisionado ou o aprendizado por reforço. Isso se mostrou

00:43 extremamente eficaz, mas exige um número enorme de exemplos: trilhões de tokens para o pré-treinamento, dezenas de milhares de exemplos rotulados para o fine-tuning supervisionado ou centenas de milhares de rollouts para o aprendizado por reforço em domínios como matemática, programação etc. No entanto, a maioria das equipes não dispõe de tantos dados ou recursos computacionais. Na verdade, os problemas que estamos tentando resolver com IA agora têm como gargalo a eficiência de amostras. O que queremos dizer com isso? Duas coisas. Em primeiro lugar, há

01:18 poucos recursos de conhecimento específico do domínio disponíveis, o que significa que não há dados suficientes para executar algoritmos offline como SFT. Em segundo lugar, os domínios nos quais estamos tentando aplicar IA estão cada vez mais sujeitos a rollouts caros: o pipeline de workflow com LLM ou os rollouts agentic podem ser muito lentos ou caros por si só, ou a métrica da tarefa pode ser muito lenta ou cara de calcular. Estamos vendo agents trabalharem por horas a fio, e aplicar a eles um algoritmo de aprendizado online exigiria

01:52 centenas de milhares de rollouts, o que não seria viável. Por isso, vemos um uso cada vez maior de agents em aplicações de produtos do mundo real, nas quais eles usam ferramentas que também podem levar muito tempo para executar, agravando ainda mais o problema da ineficiência de amostras. O paradigma dominante atualmente é o aprendizado por reforço com recompensas verificadas: dado um modelo e uma tarefa, fazemos qualquer número de rollouts em paralelo e recebemos recompensas no final. Por fim, um algoritmo como o GRPO pega essas recompensas e as converte em

02:24 gradientes que são aplicados de volta ao modelo. No entanto, como podemos ver, havia muita informação em cada um desses rollouts, mas aprendemos apenas uma pontuação O(1) e a propagamos por meio do gradiente descendente. Podemos ver cadeias de pensamento, as chamadas de ferramentas feitas ao ambiente, as respostas do ambiente a essas chamadas, que poderiam conter mensagens de erro com valor diagnóstico, e aprendemos quase nada com tudo isso. Então, a pergunta que fazemos é: será que podemos aproveitar

02:58 essa outra informação extremamente rica? Nossa ideia é fazer otimização reflexiva no espaço textual, em que, em vez de usar apenas o sinal de recompensa zero ou um, podemos fazer um modelo de linguagem ou um agent analisar o registro de todo o rollout e refletir sobre o que funcionou e o que não funcionou. Essa reflexão poderia usar todas as saídas intermediárias e até fazer outras chamadas de ferramentas, como buscar informações na base de conhecimento da sua empresa

03:29 ou em algum livro-texto de referência, e assim por diante. Essa é a primeira ideia-chave; a segunda é que, em vez de atualizar apenas os pesos com pequenos deltas, podemos atualizar um prompt, em que uma única alteração em linguagem natural pode provocar uma grande mudança de comportamento. Vamos usar um exemplo simples. Imagine que a tarefa seja escrever um sistema de resumo de texto e que o prompt desse sistema diga: “gere um resumo de uma linha”. Se eu simplesmente alterar esse prompt para dizer “gere um resumo de 10 linhas”, todos podemos concordar que o comportamento do sistema mudaria

04:03 bastante com essa alteração de uma só palavra. E fazer essa alteração é rápido; podemos refletir sobre nosso próprio comportamento e identificar o que precisa mudar. Para obter uma atualização de comportamento semelhante no nosso sistema de IA, precisaríamos fazer milhares de atualizações de gradiente minúsculas, uma após a outra. Com essa ideia-chave, propusemos o GEPA, uma técnica de otimização reflexiva de prompts para agents. Ela usa um ciclo evolutivo junto com um novo método de seleção de candidatos baseado na fronteira de Pareto,

04:34 ao qual voltarei mais adiante. É semelhante a fazer aprendizado por reforço no espaço textual: em vez de apenas receber uma pontuação de recompensa, obtemos a pontuação junto com feedback textual, que pode ser muito específico do domínio e nos permite aprender tudo sobre ele. Vamos comparar o GEPA com o GRPO, uma das principais técnicas de RL. No eixo x, temos o número de etapas de treinamento, também proporcional ao número de amostras de dados analisadas; no eixo y, temos o desempenho no domínio para o qual

05:07 estamos treinando. O que podemos ver é que, com apenas uma rodada de reflexão e usando só três pontos de dados, o GEPA já consegue obter ganhos de desempenho duas vezes maiores que os do GRPO após 25 mil rollouts. Continuar executando o GEPA por mais algumas etapas aumenta ainda mais essa diferença, em mais 2 vezes. Quero observar aqui que o modelo Qwen 38B está se otimizando por conta própria. Não há nenhum professor especialista externo envolvido.

05:39 E o que o GEPA aprende? Diferentemente de alguns otimizadores de prompts anteriores, que usavam peculiaridades dos modelos, como “minha avó vai ficar muito brava se você não gerar um bom prompt”, o GEPA apresenta uma especificação do problema bastante detalhada, que inclui como interpretar a entrada. Qual é o propósito e o contexto desta parte específica do pipeline? Quais são algumas observações e lições importantes dos dados? O prompt que vemos aqui é para o segundo salto de um sistema de respostas a perguntas com múltiplos saltos, no qual, dada uma

06:13 pergunta, precisamos recuperar alguns documentos que possam respondê-la. Analisamos esses documentos, fazemos um resumo e, por fim, respondemos à pergunta. Aqui, vemos que o GEPA descobriu que os documentos do primeiro salto geralmente abordam uma entidade ou aspecto, e que o segundo salto deve recuperar documentos relacionados a ele. Observamos que, sempre que um novo modelo é lançado, as equipes de engenharia humana passam semanas ajustando manualmente uma palavra aqui e outra ali, tentando descobrir a especificação do problema.

06:45 Agora, todo esse processo é totalmente automatizado com o GEPA, que leva de cerca de meia hora a uma hora para executar, dependendo dos seus pipelines. Também podemos aplicar o GEPA a modelos proprietários líderes. Por exemplo, conseguimos otimizar o desempenho do GPT-4.1 mini para superar o GPT-4.1 em uma tarefa de matemática, e podemos ver o tipo de destilação de informações que o GEPA realizou no próprio espaço de prompts. Voltando ao problema da eficiência de amostras, a AMD

07:19 desenvolveu um novo acelerador de hardware chamado NPU XDNA2, que usava uma API completamente nova para programação, sobre a qual havia quase zero informação disponível na internet. Por causa disso, os principais modelos da época, como o GPT-4, falhavam miseravelmente nessa tarefa. Pegamos um agent existente, que estava obtendo 4,25% nessa tarefa, e aplicamos o GEPA sem fazer nenhuma outra alteração no próprio agent. Obtivemos este prompt e elevamos o

07:49 desempenho em 7 vezes, para 30,52%. Isso mostra que pode haver muitas informações específicas do domínio que, se forem incluídas nos prompts dos seus sistemas de IA, podem fazer os modelos terem um desempenho muito melhor, e o GEPA pode ajudar a descobri-las de forma totalmente automática. Quero destacar a frase “evite incluir ADF.h”. O interessante é que a AMD realmente distribui uma biblioteca chamada ADF.h para programar NPUs, mas ela não funcionava com a geração mais recente de hardware com a qual estávamos trabalhando, e o GEPA conseguiu

08:22 descobrir isso em apenas uma etapa. Como funciona? É um algoritmo extremamente simples, que simplesmente recebe seu pipeline de IA, escrito em qualquer framework agentic, ou até mesmo chamadas brutas de LLM que você possa ter. Ele executa seus sistemas em alguns exemplos e coleta feedback específico do domínio. Observa todas as informações contidas no seu ambiente. Em segundo lugar, executa uma reflexão com um LLM ou agent que lê o feedback e propõe um prompt melhor. Por fim, e o mais importante, mantém um conjunto de Pareto, no qual guarda cada candidato

08:56 que vence em até mesmo um único exemplo de treinamento, e não apenas o que tem a maior pontuação. A pergunta é: por que manter um conjunto de Pareto? E continuaram nos fazendo muito esta pergunta: será que o GEPA é realmente melhor do que executar o modelo em um loop? Então fomos testar, e o que acontece é que um loop mantém apenas o melhor resultado e fica preso em um ótimo local. À esquerda, vocês veem uma árvore de busca gerada usando um LLM em um loop, começando com um prompt inicial no canto superior esquerdo, em que pedimos ao LLM para melhorar o prompt. Ele melhorou o

09:30 prompt e gerou um prompt que nos levou ao nó do meio. No entanto, esse prompt ficou preso em um ótimo local e, quando pedimos novamente ao LLM que tentasse melhorá-lo, ele propôs algo que, na verdade, não era melhor. Então, ele voltou e tentou melhorar o prompt outra vez, continuou fazendo isso e esgotou todo o orçamento de busca. Por outro lado, com a estratégia de seleção de candidatos baseada em Pareto do GEPA, à direita, vemos que o processo de busca é muito mais equilibrado e acaba convergindo para uma pontuação bem maior. Em quatro benchmarks, vimos que mais da metade dos ganhos observados

10:03 com o GEPA se deve, de fato, a isso, e ele obtém quase o dobro dos ganhos de desempenho que teríamos simplesmente executando o modelo em um loop. O GEPA pode ter um desempenho muito bom em benchmarks variados. Aqui vemos resultados em perguntas e respostas, seguimento de instruções, verificação de afirmações e matemática, áreas para as quais todas as principais empresas de modelos de fronteira já estão otimizando bastante seus modelos. Ainda assim, conseguimos obter um ganho de 10% apenas otimizando o prompt. Até aqui, vimos o GEPA otimizando apenas prompts, mas

10:34 o GEPA vai muito além dos prompts. Como prompts são apenas artefatos de texto que determinam o comportamento de sistemas de IA, o mesmo algoritmo pode melhorar qualquer coisa que possa ser expressa como um trecho de texto e receber uma pontuação. Por exemplo, todo o seu agent harness acaba sendo apenas um arquivo Python ou JavaScript, e podemos aplicar a ele todo o processo de otimização reflexiva e trabalhar com esse arquivo. Então, se você consegue escrever algo como texto e atribuir uma pontuação, o GEPA pode otimizar isso. Com essa ideia em mente, propomos o Optimize Anything, que

11:07 é uma API universal para otimizar qualquer parâmetro textual em qualquer domínio, como a otimização de código, quando, por exemplo, você quer otimizar o código de um kernel CUDA. A entrada é simplesmente esse código do kernel CUDA. Um avaliador examina o trecho de código, talvez o compile, faça o profiling e gere várias informações relacionadas, que chamamos de informações auxiliares acionáveis. Essas informações são então fornecidas a um LLM, que propõe um candidato melhor preservando esse conjunto de Pareto. E o processo se repete até convergir. O mesmo pode ser

11:41 aplicado à otimização numérica, em que os números podem ser serializados como texto; à otimização de harness, em que um harness inteiro pode ser serializado como texto; ou até à otimização de políticas de escalonamento na nuvem, em que a política de escalonamento ou o algoritmo heurístico pode ser expresso como um trecho de texto. O avaliador pode ser algo como o negativo do custo ou alguma função que meça precisão e eficiência, e as informações auxiliares acionáveis podem incluir rastros de jobs, violações de SLA e assim por diante. A API é muito simples de usar. Tudo o

12:12 que você precisa fazer é nos fornecer o conjunto de problemas que quer resolver, junto com uma função avaliadora ou de aptidão que retorne uma pontuação, além de quaisquer informações auxiliares específicas do domínio disponíveis. Se o seu domínio produzir feedback especializado, retorne-o. Se produzir mensagens de erro do compilador, mensagens do profiler ou mensagens de erro de tool calling, retorne-as. Se você tiver documentação escrita, retorne-a. Pode ser qualquer tipo de informação: é um dicionário muito flexível. Você pode retornar literalmente qualquer coisa. E tudo o que precisa fazer é chamar

12:42 o Optimize Anything com essa função de aptidão e o conjunto de problemas que você tem, e ele cuidará de tudo e fornecerá uma solução otimizada. Vamos ver algumas aplicações. Digamos que você tenha a tarefa de gerar um unicórnio em 3D. Este é todo o código que você escreveria — ou que seu agent pode escrever, já que vimos que o Optimize Anything é uma API muito fácil de usar para agents de ponta, como o Claude Code. Então, basta escrever este código, que diz para otimizar um programa Python que gere um unicórnio em 3D. E

13:14 o candidato é um script Python que produz uma renderização PNG, ou algo do tipo, e aqui está o resultado. À esquerda, vemos o Claude Opus 4.6. Se você lhe desse essa tarefa, isto é o que ele geraria. E, à direita, vemos o unicórnio que obtemos com o Optimize Anything. Isto é só por diversão. Mas digamos que você tenha a tarefa de escrever um agent para resolver uma tarefa específica. Em geral, as equipes passam muito, muito tempo ajustando seus agents, criando ferramentas para eles, escrevendo descrições de ferramentas, orquestrando cuidadosamente

13:47 o fluxo de controle e assim por diante. Aqui, começamos com um programa Python simples de quatro linhas, que apenas chamava o chain of thought de um modelo para resolver um problema de ARC-AGI. Em apenas 16 rodadas de reflexão, o GEPA, usando o Optimize Anything, conseguiu encontrar esse agent sofisticado de seis etapas, que elevou a precisão do Gemini Flash no ARC-AGI de 32,5% para 89,5%. E podemos ver que esse agent automaticamente, por conta própria, faz indução de hipóteses sobre regras e síntese de código

14:20 . Ele executa o código e rastreia sua execução, depura o código automaticamente, volta e propõe novas versões. Por fim, executa o código nas entradas de teste reais e retorna o resultado. Este é um exemplo executável. Vocês podem acessar este QR code e executar o exemplo agora mesmo. Aplicando a mesma abordagem de descoberta de agent harnesses ao MATH-500, conseguimos aumentar em 20% a precisão do GPT-4.1 Nano, simplesmente criando um agent de duas etapas e

14:54 mais uma vez, quero enfatizar que tudo o que fizemos foi pedir ao Optimize Anything que otimizasse um arquivo de agent. Ele descobriu automaticamente essa arquitetura sofisticada de agent, e não precisamos fazer nada além de especificar o objetivo e a tarefa. Por fim, todos nós usamos algum agent de programação, como Claude Code ou Codex, ou talvez o seu agent favorito. E as skills de agent se tornaram uma parte muito importante do ecossistema, em que quase todos os agents de programação entendem skills. Vamos

15:24 dizer que você quer otimizar skills para um repo específico. Este é o código que você escreve, que diz para aprender uma skill a partir da trajetória. Quando o agent de programação receber um problema semelhante, a skill deverá ser útil. Nós apenas fornecemos essa instrução em linguagem natural. Começamos com o Mini-SWE-agent usando GPT-5 mini, porque tínhamos um orçamento muito limitado, e conseguimos elevar seu desempenho de 24% para 93%. Foi um salto de quase 3 vezes na resolução de issues de um repo Go. Mas, ainda mais importante, as skills que otimizamos a baixo custo com um agent GPT-5 mini puderam ser

15:57 aplicadas ao Claude Sonnet mais recente. Isso foi feito alguns meses atrás, mas aplicamos as skills ao Claude Sonnet 4.5 e elevamos a precisão na resolução de issues para 100%. Mais importante ainda, reduzimos quase pela metade o tempo de execução, ou seja, o tempo para resolver issues. Reduzimos esse tempo à metade, o que também significa que ele usou menos tokens, porque as skills contêm informações sobre como o repo está organizado, como executar os casos de teste, onde determinada funcionalidade está implementada, quais sistemas de build o repo usa e assim por diante.

16:32 Este é um recurso chamado GSkill. Vocês podem encontrá-lo no repo do GEPA, e ele também é totalmente open source. O Optimize Anything é uma única interface que oferece três modos de otimização. Se você tiver apenas um problema — por exemplo, um único kernel de multiplicação de matrizes que queira otimizar —, pode usá-lo dessa forma. Se tiver qualquer quantidade de problemas relacionados — por exemplo, se quiser otimizar um kernel de multiplicação de matrizes junto com um kernel de produto escalar, sabendo que pode haver transferência de informações entre os dois —, pode usá-lo

17:02 o que chamamos de modo de busca multitarefa e, por fim, criar uma skill para quando você quiser otimizar um número definido de problemas, mas seu deploy puder apresentar muitos problemas novos. Por exemplo, no caso de otimização de matemática, como na otimização de prompts de matemática, treinamos com alguns exemplos, mas, quando fazemos o deploy, podemos receber um tipo de consulta totalmente novo. Então, nos importamos com o modo de generalização. Nesse caso, você pode fazer otimização de prompts, otimização da arquitetura de agents e assim por diante. Optimize Anything pode ser usado para

17:34 um amplo conjunto de domínios, incluindo otimização de políticas de escalonamento na nuvem, em que conseguimos reduzir os custos em quase 40% em comparação com heurísticas especializadas; escrever solvers personalizados para igualar e superar o Optuna até mesmo em otimização matemática de caixa-preta; criar skills para agents; otimização de prompts; e assim por diante. É tão fácil de usar que, apenas 20 horas após seu lançamento, pessoas da Snorkel já tinham melhorado alguns de seus benchmarks internos com ele e estavam publicando sobre isso no Twitter. Além disso, o GEPA também melhora o desempenho de modelos multimodais VLM. Aqui

18:06 conseguimos reduzir as taxas de erro de OCR dos principais modelos em quase 35%. E este é um relatório validado externamente. De forma semelhante, a Databricks conseguiu uma redução de custos de 90 vezes no desempenho de seus agents em produção. Aqui, conseguiram ajustar o GPT OSS 120B para superar o Claude Opus, custando 90 vezes menos. Mais importante ainda, a melhoria de desempenho que vocês veem em relação ao Claude Opus é, na verdade, maior do que a

18:36 que vocês veem nos modelos open source. Algumas pessoas me perguntaram: “Ah, à medida que os modelos melhorarem, a importância da otimização de prompts vai diminuir.” Defendo o contrário: à medida que os modelos melhoram, eles ficam melhores em seguir instruções, e quanto mais precisa for a instrução sobre a tarefa que você precisa dar a um modelo muito inteligente, melhor ele será em resolver sua tarefa. E é exatamente isso que vemos acontecer aqui: quanto melhor era a instrução, mais o Claude Opus avançava.

19:07 Algumas pessoas perguntam: “E se tivermos tarefas subjetivas que são muito difíceis de avaliar?” O GEPA pode aprender evals para sua tarefa a partir de rastros de produção. Para isso, você coleta vários rastros de produção do seu agent. Peça a uma pessoa para anotar apenas cerca de 50 dessas trajetórias, dando feedback bem detalhado: “Esta é uma resposta longa. Esta é uma resposta curta. Esta é uma boa resposta. Esta usa esta terminologia”, e assim por diante. Depois de obter essas anotações humanas, você pode usar o GEPA para otimizar um prompt de LLM as a judge. Então, pode usar esse prompt de LLM as a judge para voltar e otimizar seu

19:41 agent e fazer o deploy dele. Isso cria um ciclo virtuoso de dados em que você pode continuar melhorando o agent. Esse é um paradigma bem-sucedido que algumas das principais equipes em produção já estão usando. Então, a pergunta que recebemos é: será que podemos realmente usar essa otimização reflexiva para treinar modelos? Recentemente, publicamos um artigo chamado Learning Fast and Slow, em que propomos o aprendizado rápido e lento, no qual podemos otimizar em conjunto os pesos do modelo e os harnesses de prompts. Isso demonstra algumas propriedades muito desejáveis em um algoritmo de aprendizado contínuo.

20:11 Não tenho muito tempo para entrar nos detalhes, mas, por favor, consultem os artigos. Desde o lançamento, o GEPA tem sido usado em produção por estas empresas e também como metodologia principal nestes artigos. Aqui, os CEOs da Dropbox e da Shopify falam sobre o uso que fazem do GEPA, e a OpenAI também publicou um artigo no blog sobre como criar sistemas de IA que se aprimoram sozinhos com o GEPA. É muito fácil começar. Ele pode ser integrado a

20:41 qualquer framework, qualquer modelo, e não tem absolutamente nenhuma dependência obrigatória. Então, você pode fazer o deploy dele em qualquer tipo de ambiente. Não tenha medo de otimizar no setor de tecnologia: muitos problemas podem ser formulados como problemas de otimização. Portanto, forneça informações auxiliares acionáveis e exponha aos otimizadores o máximo possível de informações específicas do domínio; os otimizadores do futuro poderão trabalhar com elas. Então, por favor, confiram. Muito obrigado.

Transcrição original

[00:12] Hi everyone, my name is Lakshia Agraal and today I’ll be presenting on behalf of a very large effort uh the problem of reflective optimization or how can we self-improve prompts agents and models from textual feedback. The question we start with is how can we teach AI to perform new tasks. The standard way has been to perform weight updates with gradient descent either during pre-training, supervised fine-tuning or reinforcement learning. This has proven

[00:43] to be extremely effective, but it requires a huge number of examples. trillions of tokens for pre-training, tens of thousands of labeled examples for supervised fine-tuning or hundreds of thousands of rollouts for reinforcement learning in domains like math, coding, etc. However, most teams do not actually have that much data or compute and in fact the problems are that we are trying to tackle with AI now are bottlenecked by sample efficiency. What do we mean by that? Two things. First of all, there is

[01:18] low availability of domain specific knowledge resources which means there is not enough data to perform offline algorithms like SFT. Second, the domains that we are trying to apply AI increasingly are having expensive rollouts where either the LLM workflow pipeline or agentic rollouts are itself uh very slow or expensive to do or the task metric is very slow or expensive to execute. We are seeing that agents can now work for hours on end and if you were to apply an online learning algorithm to this uh it would require

[01:52] hundreds of thousands of rollouts and it would not be feasible. So we are seeing increasing use of agents for real world product uh applications where uh these invoke tools which can also be long running further exacerbating the sample inefficiency issue. The current dominant paradigm is reinforcement learning with verified rewards where given a model and a task, we perform any number of parallel rollouts and get rewards at the end. Finally, an algorithm like GRPO takes these rewards and converts it into

[02:24] gradients that are applied back to the model. However, as we can see, there was a lot of information in each of these rollouts, but we only learned an O of one score and propagated that via gradient descent. We can see that there is chains of thought, the tool calls made to the environment, the envir environment’s responses to those tool calls, which could potentially contain error messages which also provide diagnostic value and we learned almost nothing from all of that. So the question we ask is can we make use of

[02:58] this other extremely rich information. Our idea is to perform reflective optimization in text space where instead of only using the zero or one reward signal, we can have a language model or an agent look at the trace of the entire rollout and reflect on what worked in them, what did not work in them. And this reflection could potentially use all intermediate outputs and potentially even make other tool calls such as retrieval from your company’s knowledge

[03:29] base or some guide textbook and so on. So that’s the first key idea and the second is that instead of only updating weights with small deltas, we can instead update a prompt where a single natural language update can give a very large behavior change. Let’s take a simple example. Let’s say you’re tasked with writing a text summarization system and the prompt of that system says generate a oneline summary. If I just go and tweak that prompt to say generate a 10-line summary, we can all agree that the behavior of the system would change

[04:03] quite significantly with that just one word change. And making that one word change is quite quick and we can reflect on our own behavior and identify what needs to change. If we were to achieve a similar kind of behavior update from our AI system, we would have to have thousands of gradient very tiny gradient updates sequentially. So with that key idea, we proposed JPEA which is a reflective prompt optimization technique for agents. It uses an evolutionary loop along with a novel parto-based candidate selection

[04:34] which I will come to later. It is akin to doing reinforcement learning in text space where instead of just rewarding receiving a reward score we are actually obtaining score along with textual feedback which can be very domain specific and learn all about the domain from it. Let’s compare Japa with gRPO which is one of the leading RL techniques. On the x-axis we have the number of training steps uh also proportional to number of data samples seen and on the y-axis we have the performance on our domain that

[05:07] we are training for. And what we can see is that Japa in just one round of reflection using just three data points is already able to get twice the performance gains that gpo got after 25,000 rollouts. Continuing to run Japa for a few more steps further increases that gap itself by another 2x. I want to note here that the model Quen 38B is optimizing itself here. There is no external expert teacher involved whatsoever.

[05:39] And what does Japa learn? Unlike prior prompt optimizers somewhat which would uh uh use model idiosyncrasies like my grandmother will be really angry if you don’t generate a good prompt. Here Jpa is actually giving a very detailed problem specification which includes how to make sense of the input. What is the purpose and context of this particular pip part of the pipeline? What are some key observations and lessons from the data? So the prompt we are seeing here is for the second hop of a multihop question answering system where given a

[06:13] question we need to retrieve some documents that could potentially answer that question. Look at those documents summarize it and then finally answer the question. And here what we see is Japa has found out that first hop documents that often cover one entity or aspect and the second hop should actually be uh recovering documents that are related to it. We have seen that human engineering teams whenever a new model comes out spend weeks of their time manually tweaking one word here and there trying to discover the problem specification.

[06:45] This entire process is fully automated now with Japa which takes about half an hour to 1 hour to run depending on your uh pipelines. We can also apply Japa to leading proprietary models. Just for an example here we were able to optimize GPT 4.1 minis performance to outperform GPT 4.1 on a math task and we can see the kind of information distillation JPA has done in the prompt space itself. Coming back to the problem of sample efficiency, AMD

[07:19] developed a new hardware accelerator called NPU XDNA2 which had used a completely new API to program which had almost zero available information over on the internet and because of this uh the leading models at the time which was GPT4 was failing miserably to perform this task. We are able to take an existing agent which was getting 4.25% 25% on this task and apply Japa without any other change to the agent itself and we got this prompt and pushed this

[07:49] performance 7x to 30.52%. So what this is uh what this goes to say is there can be lots of domain specific information which if you include in your AI systems prompts the models could actually perform much better and JPA can help you fully automatically discover that. I want to highlight the sentence saying avoid including ADF.h H. Now the interesting thing is AMD actually ships a library called ADF.h for programming NPUs but that did not work with this latest uh generation of hardware that we were working with and Jeppo was able to

[08:22] discover that in just one step. So how does it work? It’s an extremely simple algorithm which simply takes your AI pipeline written in any agentic framework or even raw LLM calls that you may have. It simply runs your systems on a few examples and collects domain specific feedback. whatever information your environment contains is observed. Second, it runs reflection with an LLM or agent that reads the feedback and proposes a better prompt. Finally, and most importantly, it keeps a parto pool where it keeps every single candidate

[08:56] that wins on even one training example and not just the top scorer. The question is, but why keep a parto pool? And we kept getting asked this question a lot that is Jepper really better than running the model in a loop. So we went and tested it out and what happens is a loop keeps only the best and gets stuck in a local optima. So on the left hand side you see a search tree that was generated by using an LLM in a loop starting from a seed prompt at the top left where um we asked the LLM to improve the prompt. It improved the

[09:30] prompt and it generated a prompt that gave us the middle node. However, this prompt got stuck in a local optima and once again when we asked the LLM to try and improve it, it proposed something but that was not actually better. So, it went back and it again tried to improve it and it kept doing this and it exhausted all of the search budget. On the other hand, with Japa’s parto based candidate selection strategy on the right, we can see that it maintains a much more balanced search process eventually converging to a much higher score. Across four benchmarks, we saw that more than half of the gains seen

[10:03] with Japa actually account for this and it gets almost twice the performance gains that you would get with just applying the model in a loop. Japa can perform really well across diverse benchmarks. Here we see results on question answering, instruction following, claim verification as well as math which all the leading frontier model companies are already optimizing their models a lot for and we are still able to get plus 10% just by optimizing the prompt on it. So we have so far seen Japa only optimizing the prompts but

[10:34] Japa goes far beyond prompts. And because prompts are just text artifacts that determine AI system behavior, the same algorithm can improve anything that you can express as a piece of text and you can score. For example, your entire agent harness is eventually just a Python or a JavaScript file and we can apply the same kind of reflective optimization process to that entire file and we can work with it. So if you can write it as text and score it, JPA can optimize it. So with that insight in mind, we propose optimize anything which

[11:07] is a universal API for optimizing any text parameter given any domain like code optimization where let’s say you want to optimize the CUDA kernel code. The input is just that CUDA kernel code where an evaluator looks at this piece of code, maybe compiles it, profiles it, generates a bunch of related information that we call as actionable side information which is then provided to an LLM which proposes an better candidate maintaining this parto and it keeps the uh repeating this process um till we get convergence. The same thing can be

[11:41] applied to numeric optimization where your numbers can actually be serialized as text or harness optimization where an entire harness can be serialized as text or even cloud scheduling policy optimization where the scheduling policy or heristic algorithm can be expressed as a piece of text and the evaluator can be something like the negative of cost or some function measuring accuracy uh efficiency and the actionable side information can be something like job traces SLA violations and so on. The API is dead simple to use. All it

[12:12] requires is you give us the set of problems that you care to be solved along with an evaluator function or a fitness function that returns a score along with any available domain specific side information. If your domain produces expert feedback, return that. If your domain produces compiler error messages, profiler messages, tool call error messages, return that. If you have maybe a written up documentation, return that. any kind of it’s a very open-ended dictionary. You can return literally anything and all you do is you call

[12:42] optimize anything with this fitness function and the set of problems that you have and optimize anything will sort of take care of it um and give you a optimized solution. Let’s see some applications. Let’s say you were tasked with generating a 3D unicorn. This is all the code that you would write or your agent can now write it because we have seen that optimize anything is a very easy to use API for leading agents like plot code. So all you do is write this code which says optimize a Python program to generate a 3D unicorn. Um and

[13:14] the candidate is a Python script that produces a PNG rendering whatever and here is the result. On the left hand side we can see claude opus 4.6. If you gave it this task, this is what it generated. And on the right hand side, what what we the unicorn that we get with optimize anything. This just for fun. But let’s say you were tasked with writing an agent to solve a specific task. Typically teams spend lots and lots of time tweaking their agents, building tools for it, writing tool descriptions, uh carefully orchestrating

[13:47] the control flow and so on. Here we started with a simple four-line Python program that was simply calling a model’s uh chain of thought to solve an RKGI problem. Within just 16 rounds of reflection, JEPA within optimize anything was able to find this sophisticated sixstep agent that took RKGI accuracy on RKGI uh that took RKGI accuracy of Gemini flash from 32.5% to 89.5%. And we can see that this agent is automatic like by itself doing rule

[14:20] hypothesis induction code synthesis. It executes and traces the code automatically debugs this code goes back and proposes new versions of that code. And finally it runs it on the actual test inputs and returns the output. This is a runnable example. You can go to this QR code and you can run this example right now. So um applying the same uh uh like approach of discovering agent harnesses to math 500 we are able to push its accuracy of GPT 4.1 nano by 20% by simply creating a two-step agent and

[14:54] again I want to emphasize that all we did is we asked optimize anything to optimize an agent file and it was automatically discovering the sophisticated agent architecture and we did not have to do anything other than specifying the objective and the task. Finally, every single one of us is using uh some coding agent like cloud code or codex or maybe your favorite agent and agent skills has become a very leading part of the ecosystem where almost all coding agents understand skills. Let’s

[15:24] say you want to optimize skills for your specific repository. This is the code that you write which says learn a skill from the trajectory. When the coding agent is presented with similar problem, the skill should be helpful. We just gave it this natural language behavior. And what we see is we started with minisu agent with GPT5 mini because we were very budget constrainted and we were able to take its performance from 24% to 93%. An almost 3x jump on go repository issue resolution but more importantly the skills that were

[15:57] optimized very cheaply on a GPT5 mini agent we are able to take that and apply to the latest claude sonnet. This was done of uh about a few months back but we applied it to clots onet 4.5 pushing its accuracy to 100% issue resolution while more importantly cutting down the execution time or issue resolution time by almost 50%. We cut it down into half which also means it spent less tokens because skills contain information about how the repository is organized, how to invoke the test cases, where a particular feature is implemented, um

[16:32] what are the build system used by this repository and so on. This is a a feature called GSkill. You can find it in the JPA repository and it’s fully open source as well. So, optimize anything is a single uh interface that provides three optimization modes. If you have just a single problem like there is a single matrix multiplication kernel that you want to optimize you can use it that way. If you have any number of related problems like you want to optimize a matrix multiplication kernel along with a dot product kernel and you know there might be some information transfer between these two you can use

[17:02] what we call as the multitask search mode and finally build a skill which is if you want to optimize on a set number of problems but your uh deployment can actually come up with many new problems. So like uh in case of math op like in case of math prompt optimization we are training on some examples but when we deploy it we can receive a completely new kind of query. So we care about generalization mode. So there you can do prompt optimization agent architecture optimization and so on. So optimize anything is can be used for

[17:34] a broad set of domains including cloud scheduling policy optimization where we were able to cut costs by almost 40% compared to expert huristics write custom solvers to match and exceed Optina even in blackbox mathematical optimization create agent skills prompt optimization and so on. It is so easy to use that within just 20 hours of releasing it, people at Snorkel had already improved some of their internal benchmarks with it and were tweeting about it. So, and Japa also improves multimodel VLM models performance. Here

[18:06] we are able to cut OCR error rates for leading models by almost 35%. And this is an externally validated report. Um, similar similarly, data bricks actually achieved 90x cost reduction in their deployed agents performance. uh uh performance and here they were able to tune GPT OSS 120B to outperform Claude Opus while being 90x cheaper. More importantly, the performance delta improvement that you see on top of Claude Opus is actually bigger than the

[18:36] one you see on open source models. Some people have asked me that oh as models get better the importance of prompt optimization will go down. I argue the opposite which is as models get better they will get better at instruction following and the more precise instruction about your task that you have to give to a very smart model the better that model will be at a uh solving your task and this is exactly what we see happening here the better the instruction was claopus actually jumped much uh higher

[19:07] some people have this question of uh what if we have subjective tasks which are very hard to evaluate jpa can actually learn evals for your task from production traces. The way to do that is you collect a bunch of production traces from your agent. Get a human to annotate just about 50 of those trajectories giving very detailed feedback. This is a long response. This is a short response. This is a good response. This uses this terminology, whatever. And once you get those human annotations, you can use JPA to optimize an LLM as a judge prompt. And you can use that LLM as a judge prompt then to go back and optimize your

[19:41] agent and deploy that agent. And this becomes a data flywheel where you can keep improving it. And this is a successful paradigm that uh some leading teams in production are already using. Then the question we get asked is like can we actually use this uh reflective optimization to train models and we recently had this paper called learning fast and slow where we propose fast slow learning where we can co-optimize model weights and prompt harnesses and this shows some very strong properties that one would want in a continual learning

[20:11] algorithm. Um I don’t have much time to go over details but please uh look at the uh papers and uh since uh since release Japa has been used in production by these companies as well as the main methodology in these papers and here the CEO of Dropbox and Shopify are talking about their use of Japa and OpenAI also wrote a blog post about how you can build self-improving AI systems with Japa. Um so it’s very simple to get started. It can plug into

[20:41] any framework, any model and it has absolutely zero hard dependencies. So you can deploy it any in any kind of setting. So um don’t be afraid to optimize in the tech space and many problems can be framed as optimization. So bring actionable side information and surface as much domain specific information as you can to optimizers and the optimizers of future will be able to work with them. So please go and check it out. Thank you very much.