Resumo Técnico: Além da Recuperação: Um Benchmark Multitarefa e Modelo para Busca de Código

1. Declaração do Problema

As práticas atuais de avaliação de busca de código sofrem de quatro limitações críticas que impedem o desenvolvimento de sistemas robustos e prontos para produção:

1. Suporte de Reranking Ausente: Os benchmarks existentes avaliam apenas a recuperação de primeira etapa, ignorando a etapa de reranking essencial em pipelines de produção. Os praticantes são forçados a usar codificadores genéricos não treinados em código para reranking, potencialmente degradando a qualidade.
2. Contaminação de Dados e Overfitting: Benchmarks proeminentes como o CoIR dependem fortemente de conjuntos de dados (por exemplo, CodeSearchNet) que serviram como dados de pré-treinamento para muitos modelos de representação de código. Essa sobreposição entre treinamento e avaliação infla as métricas em até 100% e introduz vazamento entre conjuntos de dados.
3. Ruído de Rótulo e Correspondência Trivial: Conjuntos de dados anotados por humanos frequentemente contêm ruído significativo (por exemplo, ~51% de pares incompatíveis no CoSQA). Além disso, muitas tarefas reduzem-se a correspondência de strings (por exemplo, corresponder código à sua própria docstring) em vez de recuperação semântica genuína.
4. Estrutura de Relevância Degenerada: A maioria dos benchmarks atribui exatamente um documento relevante por consulta com pontuações binárias e sem negativos difíceis. Isso colapsa as métricas de classificação (nDCG, MRR) em sinais redundantes de acerto ou erro e falha em testar a capacidade do modelo de distinguir entre soluções corretas e distratores plausíveis, mas incorretos.

Além disso, os benchmarks existentes carecem de diversidade em linguagens de programação (frequentemente limitadas a Python e SQL) e falham em simular comportamentos reais de busca de desenvolvedores, como consultas curtas por palavras-chave.

2. Metodologia: O Benchmark COREB

Os autores introduzem o COREB (Benchmark de Recuperação e Reranking de Código Limitado por Contaminação e Multitarefa), construído através de um pipeline de cinco etapas projetado para abordar as falhas acima:

• Etapa 1: Origem das Sementes: Problemas são obtidos do LiveCodeBench (LCB), um benchmark continuamente atualizado que mitiga contaminação via filtragem temporal. O COREB é lançado em instantâneos temporizados (por exemplo, v202602, v202603) cobrindo janelas de concurso disjuntas.
• Etapa 2: Reescrita Contrafactual e Geração de Código: Para prevenir memorização, declarações de problemas e casos de teste passam por reescrita contrafactual (modificando entidades, contexto e nomes de variáveis enquanto preservam a lógica algorítmica). Dois LLMs de fronteira (Gemini 3 Flash, Claude Sonnet 4.5) geram candidatos de solução em cinco linguagens (Python, Java, C++, Go, Ruby).
• Etapa 3: Geração de Consultas: Consultas são geradas via LLMs e revisão humana, criando três tipos principais de tarefas:
  • Texto para Código (T2C): Descrições de problemas em linguagem natural para código.
  • Código para Código (C2C): Trechos de código para código semanticamente equivalente (multilíngue).
  • Código para Texto (C2T): Trechos de código para descrições de problemas.
  • Subtarefas incluem descrições canônicas/abreviadas, declarações completas de problemas e consultas curtas por palavras-chave no estilo "Busca".
• Etapa 4: Julgamentos de Relevância Graduada: Em vez de rótulos binários, o COREB usa um esquema de três níveis:
  • Relevância=2 (Verdadeiro Positivo): Soluções verificadas como corretas ou descrições originais de problemas.
  • Relevância=1 (Negativo Difícil): Itens do mesmo problema que são superficialmente plausíveis, mas incorretos (por exemplo, soluções de código falhas, descrições de ruído geradas por LLM).
  • Não Julgado (Negativo Fácil): Todos os outros itens do corpus.
  • As métricas são computadas com nível de relevância=2, significando que negativos difíceis contribuem com ganho zero para o nDCG, mas penalizam o modelo ao ocupar os primeiros ranks.
• Etapa 5: Formato do Conjunto de Dados: Distribuído como arquivos JSONL para consultas, corpora e julgamentos de relevância.

3. Contribuições Principais

1. Um Benchmark Limitado por Contaminação: O COREB é construído sobre problemas do LCB reescritos, garantindo que os modelos não possam depender de formas superficiais memorizadas. Ele cobre cinco linguagens de programação e três direções de recuperação.
2. Avaliação de Pipeline em Duas Etapas: Diferentemente de trabalhos anteriores, o COREB avalia tanto a etapa de recuperação quanto a de reranking, fornecendo um pipeline pronto para uso.
3. Relevância Graduada com Negativos Difíceis: O benchmark inclui explicitamente negativos difíceis (soluções falhas, descrições de ruído) para testar a capacidade discriminativa do modelo, indo além da avaliação binária de acerto ou erro.
4. COREB-RERANKER: Um reranker ajustado (baseado no Qwen3-Reranker-4B) treinado em um corpus misto incluindo COREB, CodeSearchNet, APPS e CosQA. É o primeiro modelo mostrado a obter ganhos consistentes em todas as três tarefas.

4. Resultados Experimentais

Os autores avaliaram 11 modelos de embedding e 5 rerankers nas três tarefas. As principais descobertas incluem:

• Assimetria de Tarefa: Nenhum modelo único domina as três tarefas. As classificações mudam significativamente dependendo da direção de recuperação (T2C, C2C, C2T).
• Especialização vs. Escala: O treinamento especializado em código importa mais do que a escala do modelo. Um modelo especializado em código de 0,5B (C2LLM-0.5B) supera codificadores gerais de 8B em mais de 12 pontos no geral. Modelos especializados em código mostram uma vantagem de ~2x na recuperação de Código para Código.
• O Colapso da "Consulta Curta": Todos os modelos colapsam para nDCG@10 próximo a zero em consultas curtas por palavras-chave (a sub-tarefa "Busca"), que estão mais próximas do comportamento real de desenvolvedores. Isso permanece uma lacuna não resolvida.
• Viés de Linguagem: O desempenho cai significativamente para linguagens de baixo recurso (Ruby, Go) em comparação com Python e Java, seguindo a distribuição dos dados de treinamento.
• Impacto do Reranking: Rerankers prontos para uso são altamente assimétricos em relação à tarefa; alguns degradam o desempenho em Código para Texto em mais de 20 pontos. Apenas o COREB-RERANKER ajustado obtém ganhos líquidos positivos em todas as três tarefas.
• Discriminação de Negativos Difíceis: Os modelos frequentemente classificam negativos difíceis (soluções falhas) acima de verdadeiros positivos. A "taxa de intrusão de negativo difícil" excede 55% para Texto para Código, um modo de falha invisível para benchmarks binários.

5. Significado e Alegações

O artigo afirma que o COREB aborda as falhas estruturais dos benchmarks existentes de busca de código por design. Seu significado reside em:

• Realismo: Ao usar relevância graduada e negativos difíceis, reflete melhor os desafios de sistemas de produção onde distinguir entre código correto e plausível, mas errado, é crítico.
• Resistência à Contaminação: A reescrita contrafactual e a filtragem temporal garantem que as pontuações do benchmark reflitam capacidades genuínas de codificação e recuperação, em vez de memorização.
• Completude do Pipeline: É o primeiro benchmark a fornecer um pipeline completo e avaliado em duas etapas (recuperação + reranking), demonstrando que rerankers genéricos são insuficientes e que o ajuste fino específico de domínio é necessário para ganhos consistentes.
• Valor Diagnóstico: O benchmark revela modos de falha específicos (por exemplo, colapso de consulta curta, viés de linguagem) que orientam futuras direções de pesquisa, como a necessidade de técnicas de expansão de consulta para consultas curtas.

Os autores concluem que, embora embeddings especializados em código sejam superiores a codificadores gerais, o campo deve abordar o problema da "consulta curta" e a falta de estratégias de reranking robustas para construir sistemas de busca de código verdadeiramente eficazes. Os dados e o COREB-RERANKER ajustado são lançados para facilitar esse progresso.