💬 NLP

Beyond "What to Retrieve": Uncertainty in Retrieval-Augmented Code Generation

Este artigo apresenta o OpenCoder, um framework consciente de incerteza que estima e aproveita a incerteza específica da fonte para filtrar e classificar evidências de recuperação heterogêneas, melhorando assim a correção da geração de código em nível de repositório, ao mesmo tempo em que demonstra que seus benefícios dependem do backend de LLM específico e das interações de evidência.

Autores originais: Chandan Kumar Sah, Xiaoli Lian, Li Zhang

Publicado 2026-07-29

📖 6 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Chandan Kumar Sah, Xiaoli Lian, Li Zhang

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine que você está tentando construir um castelo de LEGO complexo, mas recebeu apenas um manual de instruções que cobre a porta da frente. Você conhece a porta, mas o castelo precisa de janelas, um telhado e um túnel secreto subterrâneo. Isso é a luta diária de uma Inteligência Artificial (IA) quando tenta escrever código de computador para projetos do mundo real. Embora a IA tenha se tornado incrivelmente boa em escrever pequenos trechos de código isolados, ela frequentemente se perde quando lhe pedem para construir algo que se encaixe em um "bairro" de software massivo e existente. Para resolver isso, os pesquisadores usam uma técnica chamada Geração Aumentada de Recuperação (RAG - Retrieval-Augmented Generation). Pense na RAG como dar à IA um mecanismo de busca superpoderoso: antes de escrever uma única linha de código, ela procura por projetos semelhantes, verifica as regras do bairro (as convenções específicas do projeto) e encontra as ferramentas certas (APIs) para usar.

No entanto, há uma pegadinha. Só porque o mecanismo de busca encontrou muita informação, não significa que essa informação seja útil. Às vezes, a IA encontra um trecho de código que parece semelhante, mas que na verdade quebra o projeto; outras vezes, ela encontra uma ferramenta que não se ajusta ao trabalho específico. A informação está lá, mas é ruidosa, conflitante ou simplesmente errada. A grande questão que os pesquisadores têm feito é: Como ensinamos a IA não apenas a encontrar a informação certa, mas a saber o quanto confiar nela? Se a IA não conseguir distinguir entre uma pista útil e uma pista falsa enganosa, ela construirá um castelo que desmorona no momento em que você tentar abrir a porta.

É aqui que entra um novo estudo de pesquisadores da Universidade de Beihang. Eles introduzem um sistema chamado OpenCoder, que atua como um gerente de projeto cético e ultraorganizado para a IA. Em vez de confiar cegamente em cada peça de informação que o mecanismo de busca encontra, o OpenCoder atribui uma "pontuação de dúvida" a cada pista individual. Ele pergunta: "Quão incertos estamos de que esta API é a correta?" ou "Qual a probabilidade de este código semelhante entrar em conflito com o nosso projeto?". Ao tratar a incerteza não como um erro, mas como um sinal útil, o OpenCoder filtra o ruído, classifica as pistas com base em quão confiáveis elas parecem e até sabe quando parar e corrigir seus próprios erros.

Os pesquisadores testaram este sistema pedindo à IA para escrever código para 32 tarefas diferentes do mundo real. Eles descobriram que, ao usar um modelo de IA poderoso chamado GPT, o OpenCoder aumentou significamente a taxa de sucesso do código final de 56,25% (com métodos de busca padrão) para 78,13%. No entanto, os pesquisadores descobriram uma nuance crucial: esse aumento de desempenho coincidiu com o desempenho de um grupo de controle que usou a busca padrão, mas adicionou uma etapa de "verificação e reparo". Isso sugere que, embora a filtragem de incerteza do OpenCoder tenha ajudado, o salto massivo no sucesso foi impulsionado principalmente pela capacidade do sistema de verificar e corrigir erros, e não apenas pela filtragem. O ingrediente secreto não foi apenas encontrar mais informações; foi a capacidade do sistema de dizer: "Esta peça específica de evidência parece instável, então vamos ignorá-la", e "Esta outra peça parece sólida, então vamos usá-la", tudo isso enquanto mantinha uma rede de segurança para capturar erros.

Contudo, a história não é um simples "a IA vence para sempre". Os pesquisadores foram cuidadosos ao notar que este sucesso depende fortemente de qual céreão de IA está fazendo o pensamento. Quando trocaram o GPT por um modelo diferente chamado Gemini, os resultados foram muito menos claros. As melhorias não foram estatisticamente significativas, sugerindo que o "radar de incerteza" do OpenCoder funciona de forma diferente dependendo da "personalidade" da IA. Além disso, o sistema encontrou um limite quando o projeto carecia de muita informação. Nesses casos de evidência incompleta, um sistema padrão com verificação e reparo superou o OpenCoder. Isso indica que, quando o mecanismo de busca não consegue encontrar as ferramentas necessárias para começar, o mecanismo de filtragem do OpenCoder pode, às vezes, suprimir os poucos fragmentos de evidência que estavam disponíveis, em vez de melhorar a decisão final.

O estudo também descobriu algo surpreendente sobre como diferentes tipos de informação trabalham juntas. Você poderia pensar que ter "código semelhante", "contexto do projeto" e "conhecimento de API" é sempre melhor do que ter apenas um. Mas os pesquisadores descobriram que não existe uma regra universal. Às vezes, adicionar "código semelhante" na verdade confundiu a IA, a menos que fosse acompanhado pelo "contexto do projeto" adequado. É como ter um mapa, uma bússola e um GPS: se você tiver apenas o GPS, pode se perder; se tiver o mapa e a bússola, mas não o GPS, pode ficar bem; mas se tiver todos os três e eles se contradizerem, você pode acabar andando em círculos. O valor de cada pista depende inteiramente de quais outras pistas estão presentes.

Para fazer isso funcionar, o OpenCoder utiliza uma dança de cinco etapas. Primeiro, ele constrói uma biblioteca de todas as regras e ferramentas do projeto. Segundo, ele decompõe a solicitação do usuário em pequenos passos. Terceiro, ele sai em busca de pistas, mas desta vez pontuando-as com base em quão "incertas" elas parecem. Quarto, ele gera o código, mas mantém um olho atento na "pontuação de incerteza" para evitar o uso de pistas instáveis. Por fim, e talvez o mais importante, ele atua como seu próprio inspetor de controle de qualidade. Ele executa o código através de uma série de testes. Se o código falhar, ele não apenas desiste; ele identifica o erro e tenta reparar o código com base nesse feedback de validação.

No fim, o artigo sugere que o futuro da codificação por IA não é apenas tornar a IA mais inteligente ou dar-lhe mais dados. É ensinar a IA a ser humilde e crítica. Ao tratar a incerteza como uma ferramenta para guiar decisões — filtrando dados ruins, verificando a saída e corrigindo erros sobre a marcha — sistemas como o OpenCoder podem construir softwares mais confiáveis. Mas, como alertam os pesquisadores, isso não é uma varinha mágica que funciona em todas as situações. Funciona melhor quando a IA tem informações boas o suficiente para trabalhar e quando o modelo de IA específico está ajustado para entender corretamente as "pontuações de dúvida". Por enquanto, o OpenCoder é um passo poderoso à frente, provando que, às vezes, saber o que você não sabe é a parte mais importante de resolver o quebra-cabeça.

Resumo Técnico: Além do "O Que Recuperar": Incerteza na Geração de Código com Recuperação Aumentada

Declaração do Problema

A geração de código em nível de repositório exige que Grandes Modelos de Linguagem (LLMs) sintetizem implementações que respeitem dependências entre arquivos, convenções de projeto e APIs privadas. Embora a Geração Aumentada por Recuperação (RAG) aborde a limitação do conhecimento paramétrico ao fornecer evidências externas do repositório, as abordagens existentes focam primariamente em otimizar o que informação recuperar (ex: código similar, contexto do repositório, conhecimento de API). Elas negligenciam amplamente a incerteza inerente associada a essa evidência.

A evidência recuperada é frequentemente heterogênea e não confiável: exemplos de códigos similares podem ser semanticamente relacionados, mas funcionalmente incompatíveis; o contexto do repositório pode conter dependências redundantes ou conflitantes; e o conhecimento de API pode estar incompleto ou incorretamente escopado. Os métodos atuais otimizam a relevância da recuperação sem modelar explicitamente como a incerteza nessas fontes afeta a geração, verificação e reparo subsequentes. Consequentemente, a combinação de evidências adicionais pode introduzir ruído e propagar erros de recuperação, levando a códigos executáveis que ainda contêm usos indevidos de API ou defeitos funcionais substanciais.

Metodologia: OpenCoder

Os autores introduzem o OpenCoder, um framework consciente da incerteza projetado para tratar a incerteza como um sinal de controle acionável, em vez de um escore de confiança post-hoc. O framework opera através de cinco fases:

Perfilamento de Conhecimento e Incerteza do Repositório: Constrói um índice contendo três fontes de evidência: APIs específicas do projeto ( $A$ ), código de contexto do repositório ( $X$ ) e exemplos de código semanticamente similares ( $S$ ).
Decomposição da Incerteza da Consulta: Decompõe a consulta do usuário em etapas de implementação e prevê a evidência necessária para cada etapa.
Recuperação Multifonte Consciente da Incerteza: Recupera candidatos de $A$ $A$ , $X$ $X$ e $S$ $S$ . Crucialmente, o OpenCoder atribui um escore de incerteza específico da fonte $u_m(e|q) \in [0,1]$ $u_{m} (e ∣ q) \in [0, 1]$ a cada item recuperado, onde valores mais altos indicam menor confiança na relevância, completude ou compatibilidade.
- A evidência é pontuada usando uma combinação de similaridade de cosseno ( $r_m$ ), peso de intenção da fonte prevista ( $w_m$ ) e incerteza: $\gamma_m(e|s) = r_m \cdot w_m \cdot \max\{0, 1 - \alpha u_m(e)\}$ .
- Evidências de baixa confiança são filtradas, e os itens restantes são deduplicados e ranqueados sob um orçamento de contexto compartilhado.
Geração de Código Guiada pela Incerteza: O LLM gera o código candidato condicionado à consulta, ao conjunto de evidências filtradas e ao traço de incerteza por fonte.
Verificação e Mitigação de Incerteza: Candidatos gerados passam por verificações estáticas e testes executáveis. O primeiro candidato que passa é selecionado. Se nenhum candidato bruto passar, o sistema identifica o candidato "modo" (do maior grupo de autoconsistência) e realiza até duas rodadas de reparo guiado por validação.

O framework também emprega o Refinamento de API Orientado ao Alvo para remover APIs auto-recuperadas, redundantes ou incompatíveis com a intenção antes da geração.

Principais Contribuições

Formulação: O artigo formula a geração de código em nível de repositório como uma tomada de decisão sob incerteza sobre evidências heterogêneas, indo além do simples ranqueamento de relevância.
Framework: O OpenCoder é um sistema unificado que estima a incerteza específica da fonte e a operacionaliza através de filtragem de evidência, integração multifonte, geração, verificação e reparo.
Análise Fatorial: Através de uma análise fatorial completa do conhecimento de API, contexto do repositório e evidência de código similar, os autores demonstram que a utilidade da recuperação é dependente de interação. Não existe um ranqueamento aditivo universal de fontes; o valor de uma fonte específica depende da evidência acompanhante e do backend do LLM.
Avaliação Controlada: Os autores conduzem uma avaliação rigorosa e pareada nos backends GPT e Gemini em tarefas de nível de repositório executáveis, isolando o impacto do processamento consciente da incerteza da verificação e reparo downstream.

Resultados Experimentais

A avaliação utiliza um conjunto expandido de 32 tarefas RepoExec-inline pareadas e um teste de estresse em 10 tarefas ExecRepoBench de contexto parcial.

Desempenho do GPT: No conjunto de 32 tarefas RepoExec-inline, o OpenCoder melhorou a correção da saída selecionada de 56,25% (Baseline RAG) para 78,13% (um ganho de 21,88 pontos percentuais, nominal $p = .039$ ). No entanto, ele empatou com o controle RAG + Verify/Repair (que usa a mesma evidência, mas carece de filtragem consciente da incerteza), sugerindo que o ganho sobre o Baseline RAG é impulsionado principalmente pelo orçamento de verificação/reparo, e não apenas pela filtragem de incerteza.
Desempenho do Gemini: Para o Gemini, as diferenças entre OpenCoder, Baseline RAG e o controle não foram estatisticamente suportadas. O controle (RAG + Verify/Repair) apresentou o desempenho mais forte na maioria das métricas.
Efeitos de Interação: A análise fatorial (RQ1) revelou que nenhuma fonte de evidência individual teve um efeito marginal estatisticamente significativo no desempenho. Em vez disso, observaram-se interações entre fontes significativas (ex: o contexto do repositório e a evidência de código similar mostraram uma interação positiva para o GPT).
Recuperação de API: O refinamento orientado ao alvo melhorou substancialmente a recuperação do conjunto de APIs, aumentando o macro F1 de 43,4% para 64,8% para o GPT e para 59,1% para o Gemini.
Condições de Limite: No teste de estresse de contexto limitado ExecRepoBench, o controle RAG + Verify/Repair superou substancialmente o OpenCoder. Isso indica que, quando a evidência do repositório é incompleta, a filtragem consciente da incerteza pode suprimir alternativas úteis em vez de melhorar a decisão final.

Significância e Alegações

O artigo afirma que a incerteza é mais útil não como um estimador de confiança isolado, mas como um sinal de controle operacional acoplado à fusão de evidências, validação executável e reparo.

Dependência de Backend: Os benefícios do OpenCoder dependem do backend. Embora tenha melhorado significativamente a seleção de saída do GPT em relação ao RAG puro, não mostrou vantagens estatisticamente significativas sobre um controle de verificação e reparo, nem mostrou benefícios claros para o Gemini.
Completude da Evidência: A eficácia do framework depende da completude da evidência do repositório. Em cenários com evidência incompleta, o mecanismo de incerteza pode inadvertidamente filtrar informações necessárias.
Controle Acionável: A principal contribuição é a mudança de otimizar o que recuperar para modelar o quão confiável é a evidência recuperada, usando esse sinal para guiar a filtragem e a geração.

Os autores concluem que, embora o OpenCoder demonstre o potencial da integração consciente da incerteza, suas vantagens dependem do backend de LLM específico e da qualidade/completude da evidência do repositório recuperada. Eles enfatizam que o código gerado ainda requer revisão do desenvolvedor e testes específicos do projeto.