💬 NLP

Fine-Tuning Pre-Trained Code Models for AI-Generated Code Detection

O artigo apresenta o sistema da equipe "Archaeology" para a Tarefa 13 do SemEval-2026, que aproveita modelos de código pré-treinados ajustados finamente e estratégias especializadas, como validação cruzada leave-one-language-out e empacotamento de tokens sanduíche, para alcançar desempenho de alto nível na detecção de código gerado por IA e na atribuição de sua origem.

Autores originais: Jany-Gabriel Ispas, Sergiu Nisioi

Publicado 2026-05-05

📖 5 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Jany-Gabriel Ispas, Sergiu Nisioi

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 uma agência de detetives digitais chamada Arqueologia. Seu trabalho não é desenterrar cerâmicas antigas, mas sim vasculhar pilhas de código de computador para responder a duas grandes perguntas:

Quem escreveu isso? Foi um programador humano ou um robô (IA)?
Qual robô escreveu? Se foi um robô, qual modelo de IA específico o criou?

Esta equipe entrou em uma competição de alto risco chamada SemEval-2026 Task 13 para provar suas habilidades. Aqui está como eles se saíram, explicado de forma simples.

O Desafio: Um Mistério em Duas Partes

A competição tinha dois quebra-cabeças distintos, cada um exigindo uma estratégia de detetive diferente.

Quebra-Cabeça A: O Teste "Humano vs. Robô" (Classificação Binária)

O Objetivo: Olhar para um trecho de código e dizer "Humano" ou "IA".
A Armadilha: A equipe foi treinada principalmente com código em Python (91% de seus dados de prática), mas o teste final incluiu linguagens que eles nunca tinham visto antes, como JavaScript, Go e C#. É como ensinar um chef a cozinhar apenas comida italiana e, em seguida, pedir que ele identifique se um prato é caseiro ou de fábrica quando, na verdade, é um curry tailandês.
A Pista: O código de IA tende a ser mais longo e uniforme, enquanto o código humano é mais curto e caótico. No entanto, essa regra inverte dependendo da linguagem (por exemplo, em C++, os humanos na verdade escrevem código mais longo do que a IA).

Quebra-Cabeça B: O Teste "Qual Robô?" (Atribuição Multiclasse)

O Objetivo: Se o código for gerado por IA, identificar exatamente qual um dos 11 modelos de IA diferentes o escreveu.
A Armadilha: Os dados estavam extremamente desbalanceados. Uma categoria (código escrito por humanos) compunha 88% dos dados, enquanto alguns modelos de IA específicos tinham menos de 2.000 exemplos. É como tentar encontrar uma agulha em um palheiro, onde o palheiro é 99% palha e as agulhas são de cores diferentes, mas você tem apenas uma agulha vermelha e um milhão de azuis.
A Pista: Diferentes modelos de IA têm estilos de "caligrafia" sutis, mas esses estilos são difíceis de detectar em código longo e complexo.

A Caixa de Ferramentas do Detetive

A equipe não apenas chutou; eles usaram quatro "super-olhos" diferentes (modelos de IA pré-treinados) e deram a eles técnicas de treinamento especiais para cada quebra-cabeça.

Para o Quebra-Cabeça A (Humano vs. Robô)

O Exercício "Troca de Linguagem": Para se preparar para as linguagens surpresa no teste, eles treinaram os modelos escondendo uma linguagem de cada vez. Eles ensinaram o modelo a reconhecer padrões sem depender de truques específicos de linguagem (como o uso de # para comentários no Python).
O Treino "Limpeza e Máscara": Eles removeram comentários e substituíram números por espaços reservados durante o treinamento. Isso forçou os modelos a olhar para a lógica do código, não apenas para as decorações superficiais.
A Estratégia "Fragmentação": Como o código de teste era frequentemente longo demais para ser lido de uma só vez, eles o cortaram em pedaços sobrepostos (como ler um livro longo lendo algumas páginas de cada vez). Em seguida, eles tiraram a média desses pedaços, ignorando as previsões mais extremas e "ruidosas", para tomar uma decisão final.
A Calibração "Casos Difíceis": Eles criaram um "teste especial difícil" usando exemplos que um programa de computador simples errou. Eles ajustaram seu limiar de decisão (a linha entre "Humano" e "IA") com base nesses casos complicados para garantir que não fossem enganados pelos dados de teste.

Para o Quebra-Cabeça B (Qual Robô?)

A Técnica "Sanduíche": Como o código era longo demais para caber na memória do modelo, eles não apenas cortaram o meio. Em vez disso, mantiveram a Cabeça (início) e a Cauda (fim) do código e os juntaram como um sanduíche, com um marcador especial no meio. Isso preservou o estilo no início e no fim, que é frequentemente onde a "assinatura do robô" se esconde.
O Peso "Justiça": Como alguns modelos de IA eram raros nos dados, a equipe disse ao modelo: "Não adivinhe apenas o mais comum! Preste atenção extra nos raros." Eles ajustaram o sistema de pontuação para que o modelo aprendesse a identificar os robôs raros, não apenas os populares.
O Voto "Sabedoria da Multidão": Eles executaram o mesmo código através do modelo várias vezes com pequenas variações e deixaram os modelos votarem na resposta. Isso reduziu erros e aumentou a confiança.

Os Resultados

A equipe "Arqueologia" se saiu muito bem:

Quebra-Cabeça A: Eles obtiveram uma pontuação de 0,737, ficando em 6º lugar entre 81 equipes. Sua melhor ferramenta foi o CodeBERT, que parecia entender a "lógica" do código melhor do que os outros.
Quebra-Cabeça B: Eles obtiveram uma pontuação de 0,422, ficando em 7º lugar entre 34 equipes. Sua melhor ferramenta aqui foi o UniXcoder, que se beneficiou de olhar para pedaços de código mais longos e usar a estratégia de "votação".

A Grande Conclusão

A equipe descobriu que como um modelo foi treinado importa mais do que o seu tamanho.

Os modelos menores (125 milhões de parâmetros) que foram treinados especificamente para entender a lógica do código se saíram melhor na detecção de IA.
O modelo gigante (220 milhões de parâmetros) não venceu, sugerindo que, para este trabalho específico, ser um "especialista" é melhor do que ser um "generalista".

Em resumo, a equipe provou que, com os truques de treinamento certos — como cortar código longo, ignorar ruídos superficiais e votar nas respostas — você pode construir um sistema que é surpreendentemente bom em pegar código gerado por IA, mesmo quando ele tenta se disfarçar em novas linguagens.

Resumo Técnico: Arqueologia na SemEval-2026 Tarefa 13

Declaração do Problema

O artigo aborda o desafio de detectar código-fonte gerado por IA, uma questão crítica para a integridade acadêmica, a segurança da cadeia de suprimentos de software e a atribuição de propriedade intelectual. Os autores participaram da Tarefa 13 da SemEval-2026, que é dividida em três subtarefas; seu sistema, "Arqueologia", concentrou-se nas duas primeiras:

Subtarefa-A: Classificação binária para distinguir entre código escrito por humanos e código gerado por IA.
Subtarefa-B: Atribuição multiclasse para identificar a família específica de Modelo de Linguagem de Grande Escala (LLM) que gerou um determinado trecho de código entre 11 classes (incluindo código escrito por humanos e 10 modelos de IA distintos).

Ambas as subtarefas utilizam a pontuação F1 macro-média como métrica de avaliação principal. As tarefas apresentam desafios distintos: a Subtarefa-A exige generalização para linguagens de programação fora do domínio (OOD) não vistas durante o treinamento, enquanto a Subtarefa-B deve lidar com distribuições de classe extremamente desbalanceadas (uma razão de 225:1 entre as classes maior e menor) e sequências longas de código.

Metodologia

Linha de Base

A equipe estabeleceu uma linha de base usando recursos TF-IDF (n-gramas de caracteres de bigramas a 5-gramas) combinados com Regressão Logística. O código foi truncado para os primeiros 10.000 caracteres. Para a Subtarefa-B, pesos de classe balanceados foram aplicados para mitigar o desequilíbrio de rótulos. Esta linha de base alcançou pontuações F1 macro de 0,266 (Subtarefa-A) e 0,255 (Subtarefa-B), demonstrando que padrões léxicos de superfície sozinhos são insuficientes.

Modelos Pré-treinados

O sistema central ajusta finamente quatro modelos de código pré-treinados:

CodeBERT: Apenas codificador (RoBERTa-base, 125M parâmetros), pré-treinado com Modelagem de Linguagem Mascaramento (MLM) e Detecção de Token Substituído.
GraphCodeBERT: Apenas codificador (RoBERTa-base), estendendo o CodeBERT com estruturas de gráfico de fluxo de dados.
UniXcoder: Apenas codificador (RoBERTa-base), um modelo unificado que suporta compreensão e geração via objetivos cross-modais.
CodeT5+: Codificador-decodificador (220M parâmetros), pré-treinado com modelagem de linguagem causal e desruído em código e pares código-texto.

Estratégias para a Subtarefa-A (Classificação Binária)

Para abordar o desafio de linguagens OOD (treinamento em Python, C++, Java; teste em linguagens adicionais como JavaScript, Go, PHP), os autores empregaram:

Validação Cruzada Leave-One-Language-Out (LOLO): Os modelos foram treinados em duas linguagens e validados na terceira para simular condições OOD. Os dados de treinamento foram balanceados amostrando números iguais de exemplos por linguagem e rótulo.
Aumento de Código: Aumentos estocásticos foram aplicados para reduzir a dependência de recursos de superfície específicos de linguagem, incluindo remoção de comentários, mascaramento de literais e descarte de cabeçalhos. A normalização determinística removeu cercas de markdown e padronizou espaços em branco.
Inferência em Blocos (Chunked): Como o código de teste é mais longo que o código de treinamento, trechos que excediam a janela de contexto do modelo foram divididos em blocos sobrepostos. As probabilidades foram agregadas usando uma média aparada (descartando valores mínimo/máximo) combinada com uma média top-2 (calculando a média das duas probabilidades mais altas) para equilibrar robustez contra ruído com sensibilidade a sinais fortes.
Calibração de Limiar: Uma calibração em dois estágios foi utilizada. Primeiro, um limiar ótimo foi encontrado em previsões OOF. Segundo, um "conjunto de dados difícil" de 1.000 exemplos mal classificados (de uma validação cruzada de Regressão Logística) foi construído para derivar um segundo limiar. O limiar de decisão final foi uma combinação de peso igual desses dois, com limiares adicionais por linguagem aplicados onde a detecção de linguagem foi possível.

Estratégias para a Subtarefa-B (Atribuição Multiclasse)

Para lidar com desequilíbrio extremo de classes e sequências longas:

Empacotamento de Tokens Sanduíche: Em vez de truncar código longo, a sequência de entrada foi construída usando os primeiros $h$ tokens (cabeça), um delimitador e os últimos $t$ tokens (cauda). Durante o treinamento, a fração da cabeça foi amostrada aleatoriamente para atuar como aumento de dados; durante a inferência, foi fixada em 0,60.
Função de Perda Balanceada por Classe: Para contrabalançar o desequilíbrio de 225:1, os autores usaram pesos de perda balanceados por classe baseados no número efetivo de amostras ( $\beta = 0,9995$ ), atribuindo maior peso a classes sub-representadas sem o aumento extremo de peso dos métodos de frequência inversa.
Ensemble e Aumento no Tempo de Teste (TTA):
- UniXcoder: Treinado com 3 sementes aleatórias e executado com 3 frações de cabeça diferentes durante a inferência (9 passagens forward no total).
- CodeBERT/GraphCodeBERT: Semente única com 3 frações de cabeça (3 passagens).
- CodeT5+: Semente única, fração de cabeça fixa, 1 época de treinamento devido ao tamanho do modelo.

Resultados

O sistema alcançou as seguintes pontuações F1 macro no conjunto de teste:

Subtarefa-A: 0,737 (6º lugar entre 81 equipes) usando CodeBERT.
Subtarefa-B: 0,422 (7º lugar entre 34 equipes) usando UniXcoder.

Observações Principais:

Todos os modelos ajustados finamente superaram significativamente a linha de base TF-IDF.
Para a Subtarefa-A, modelos apenas codificadores focados em compreensão de código (CodeBERT, GraphCodeBERT) superaram o CodeT5+ codificador-decodificador e o UniXcoder orientado à geração.
Para a Subtarefa-B, o UniXcoder superou os outros modelos, atribuído à sua janela de contexto maior (1.024 tokens vs. 512), ao ensemble de 3 sementes e ao uso do token de modo <encoder-only>.
A análise de erro revelou que os modelos lutaram mais com linguagens OOD na Subtarefa-A e com distinguir geradores de IA estilisticamente similares na Subtarefa-B (por exemplo, a Classe 1 teve um F1 $\le$ 0,11 apesar de ter dados de treinamento suficientes).

Significado e Contribuições

O artigo afirma três contribuições técnicas principais:

Pipeline de Inferência em Blocos: Um método para classificação binária de código usando agregação de média aparada para lidar com trechos longos de código que excedem os limites de contexto do modelo.
Estratégia de Calibração de Limiar: Uma abordagem híbrida que combina limiares OOF com limiares derivados de um "conjunto de dados difícil" de exemplos mal classificados, refinada adicionalmente por calibração por linguagem.
Empacotamento de Tokens Sanduíche: Uma estratégia para atribuição multiclasse que preserva informações do início e do fim de sequências longas de código, combinada com aumento no tempo de teste e função de perda balanceada por classe.

Os autores concluem que a escolha do objetivo de pré-treinamento é mais crítica do que o tamanho do modelo para essas tarefas. Modelos pré-treinados para compreensão de código (CodeBERT, GraphCodeBERT) se destacaram na detecção binária, enquanto o UniXcoder unificado, aprimorado por janelas de contexto mais longas e ensemble, teve o melhor desempenho na atribuição multiclasse. O artigo observa que o CodeT5+, apesar de ser o maior modelo (220 milhões de parâmetros), não alcançou as pontuações mais altas, sugerindo que o tamanho sozinho não garante desempenho neste domínio.

Limitações

Os autores reconhecem várias limitações:

O uso de modelos pré-treinados relativamente pequenos (125M–220M parâmetros) e janelas de contexto limitadas (até 1.024 tokens).
O trade-off na inferência em blocos entre cobertura e diluição de sinal.
A dependência de um "conjunto de dados difícil" para calibração de limiar, que pode não estar sempre disponível em implantações do mundo real.
A falta de estudos de ablação extensos devido a restrições computacionais, deixando a contribuição isolada de componentes específicos (por exemplo, aumentos específicos ou métodos de agregação) não quantificada.