CAPA: o benchmark que mede se o assistente de código aprende com você — ou repete a mesma pergunta

Todo desenvolvedor que usa um assistente de código tem um jeito próprio de pedir as coisas — uma convenção de nomes preferida, uma forma habitual de estruturar um endpoint, um jargão interno da empresa que o assistente não conhece de fábrica. O problema é que, hoje, a maioria dos assistentes trata cada sessão como se fosse a primeira vez que fala com você. A mesma ambiguidade que você já resolveu ontem volta a gerar uma pergunta de esclarecimento hoje.

O CAPA (Cross-Session Personalized Ambiguity Adaptation) é um benchmark desenhado especificamente para medir essa lacuna: dado o histórico de sessões já resolvidas de um usuário, um assistente consegue identificar o padrão de ambiguidade recorrente e resolver uma nova tarefa parecida sem precisar perguntar de novo?

Como o benchmark simula a ambiguidade real

Em vez de coletar ambiguidade "no mundo real" — difícil de padronizar e comparar entre modelos —, os autores construíram um pipeline de três estágios que injeta seis mecanismos específicos de ambiguidade pessoal em tarefas de código originalmente não ambíguas e executáveis. Os seis mecanismos incluem coisas como polissemia cognitiva de domínio (um termo que significa algo diferente dependendo do contexto do usuário), desalinhamento estrutural de lógica, omissão habitual de contexto e restrições implícitas não especificadas.

O resultado é um conjunto de 600 sessões de código, organizadas em 60 células balanceadas — 10 perfis de usuário cruzados com 6 pares de mecanismos de ambiguidade —, divididas em 300 sessões de histórico e 300 de avaliação. As tarefas variam em dificuldade: 97 simples, 89 médias e 114 complexas.

O achado que menos se esperava

A parte mais interessante do estudo não é que histórico ajuda — isso era esperado. É que ele ajuda mesmo quando os dados específicos do usuário são embaralhados. Os pesquisadores testaram uma condição em que o histórico de sessões passadas era misturado entre usuários diferentes antes de ser mostrado ao modelo, removendo a informação pessoal real, mas mantendo o padrão de ambiguidade. Mesmo assim, os modelos ganharam até 10,67 pontos percentuais de taxa de sucesso.

Isso sugere que boa parte do ganho vem de os modelos aprenderem padrões genéricos de como ambiguidade se resolve — não necessariamente de memorizar fatos específicos sobre um usuário individual. O histórico pareado corretamente (do usuário real) ainda soma um ganho adicional de 2 a 12 pontos percentuais no sucesso de primeira tentativa, mas a maior parte do valor já está no padrão, não na identidade.

Uma técnica simples que fecha parte da lacuna

Os autores também propõem e testam o history gating, uma técnica sem parâmetros adicionais — ou seja, não exige treinar nada de novo, apenas uma forma de filtrar e priorizar qual parte do histórico é mostrada ao modelo antes de responder. Aplicada ao GLM-5.2, ela melhorou o sucesso de primeira tentativa em 13,33 pontos percentuais, mantendo a taxa de sucesso geral estável. É uma intervenção barata comparada a re-treinar um modelo, e o tipo de técnica que produtos de assistente de código já em produção poderiam adotar sem esperar a próxima geração de modelo.

O que isso revela sobre a corrida entre modelos abertos e fechados

Um padrão fica visível na tabela de resultados: os modelos de ponta fechados (Claude Opus 4.8, GPT-5.5) e o principal modelo aberto chinês (GLM-5.2) formam um grupo claramente à frente, enquanto modelos compactos — mesmo populares, como Llama-3.3-70B — ficam para trás tanto na taxa de sucesso base quanto na capacidade de se beneficiar do histórico. Isso é relevante porque personalização entre sessões não é apenas uma questão de "ter mais contexto disponível" — é uma questão de o modelo conseguir extrair um padrão útil de um contexto ruidoso, uma habilidade que parece escalar com capacidade geral do modelo mais do que se esperaria.

O limite do benchmark

O CAPA mede um cenário controlado: ambiguidades injetadas artificialmente segundo seis mecanismos predefinidos, não o caos real de como um desenvolvedor de fato varia seus pedidos ao longo de meses de uso. É uma simplificação necessária para tornar o experimento comparável entre 12 modelos diferentes, mas significa que os números — por mais precisos que sejam — descrevem o comportamento dos modelos numa versão estilizada do problema, não necessariamente a experiência de personalização que um usuário sentiria num produto real ao longo do tempo.

Perguntas Frequentes

O que significa "sucesso de primeira tentativa" (FT-ES) no benchmark?

É a taxa de vezes em que o modelo resolve a tarefa corretamente já na primeira resposta, sem precisar de nenhuma rodada adicional de esclarecimento ou correção. É uma medida mais rigorosa que a "taxa de sucesso" geral, que permite múltiplas tentativas até o modelo acertar.

O que é o "history gating" proposto no paper?

É uma técnica de filtragem que decide qual parte do histórico de sessões anteriores do usuário é relevante o suficiente para ser mostrada ao modelo antes de responder a uma nova tarefa, sem exigir treinamento adicional. A ideia é reduzir ruído — mostrar só o histórico que ajuda, não tudo que existe.

Por que embaralhar o histórico entre usuários diferentes ainda ajudou os modelos?

Porque parte do ganho de ter histórico vem de reconhecer o tipo de ambiguidade em jogo — por exemplo, "este termo tem um significado específico nesse domínio" — e não necessariamente de saber quem é o usuário. Um padrão de ambiguidade de outro usuário, desde que do mesmo tipo, ainda ensina o modelo a reconhecer a categoria do problema.

Esse benchmark está disponível publicamente para outros pesquisadores testarem seus modelos?

O paper foi publicado no arXiv como trabalho acadêmico com metodologia detalhada, o padrão usual para esse tipo de publicação incluir a disponibilização do conjunto de dados e do código de avaliação — mas a confirmação de acesso público ao conjunto completo de 600 sessões deve ser verificada diretamente na publicação original antes de qualquer uso em avaliação própria.