💬 NLP

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

El artículo presenta el sistema del equipo "Archaeology" para la Tarea 13 de SemEval-2026, que aprovecha modelos de código preentrenados ajustados finamente y estrategias especializadas como la validación cruzada dejando fuera un idioma y el empaquetado de tokens tipo sándwich para lograr un rendimiento de primer nivel en la detección de código generado por IA y la atribución de su origen.

Autores originales: Jany-Gabriel Ispas, Sergiu Nisioi

Publicado 2026-05-05

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Jany-Gabriel Ispas, Sergiu Nisioi

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina una agencia de detectives digitales llamada Arqueología. Su trabajo no es excavar cerámica antigua, sino tamizar montones de código informático para responder a dos grandes preguntas:

¿Quién escribió esto? ¿Fue un programador humano o un robot (IA)?
¿Qué robot lo escribió? Si fue un robot, ¿qué modelo de IA específico lo creó?

Este equipo participó en una competencia de alto riesgo llamada SemEval-2026 Tarea 13 para demostrar sus habilidades. Así es como lo hicieron, explicado de forma sencilla.

El Reto: Un Misterio de Dos Partes

La competencia tenía dos acertijos distintos, cada uno requiriendo una estrategia de detective diferente.

Acertijo A: La Prueba "Humano vs. Robot" (Clasificación Binaria)

El Objetivo: Observar un fragmento de código y decir "Humano" o "IA".
La Trampa: El equipo se entrenó principalmente con código en Python (el 91% de sus datos de práctica), pero la prueba final incluyó idiomas que nunca habían visto antes, como JavaScript, Go y C#. Es como enseñar a un chef a cocinar solo comida italiana y luego pedirle que identifique si un plato es casero o fabricado en serie cuando en realidad es un curry tailandés.
La Pista: El código de la IA tiende a ser más largo y uniforme, mientras que el código humano es más corto y caótico. Sin embargo, esta regla cambia según el idioma (por ejemplo, en C++, los humanos en realidad escriben código más largo que la IA).

Acertijo B: La Prueba "¿Qué Robot?" (Atribución Multiclase)

El Objetivo: Si el código fue generado por IA, identificar exactamente cuál de los 11 modelos de IA diferentes lo escribió.
La Trampa: Los datos estaban desequilibrados de forma salvaje. Una categoría (código escrito por humanos) constituía el 88% de los datos, mientras que algunos modelos de IA específicos tenían menos de 2.000 ejemplos. Es como intentar encontrar una aguja en un pajar, donde el pajar es 99% paja y las agujas son de diferentes colores, pero solo tienes una aguja roja y un millón de azules.
La Pista: Los diferentes modelos de IA tienen estilos de "escritura" sutiles, pero estos estilos son difíciles de detectar en código largo y complejo.

El Arsenal del Detective

El equipo no solo adivinó; utilizaron cuatro "super-ojos" diferentes (modelos de IA preentrenados) y les dio técnicas de entrenamiento especiales para cada acertijo.

Para el Acertijo A (Humano vs. Robot)

El Ejercicio "Cambio de Idioma": Para prepararse para los idiomas sorpresa en la prueba, entrenaron a los modelos ocultando un idioma a la vez. Enseñaron al modelo a reconocer patrones sin depender de trucos específicos del idioma (como el uso de # para comentarios en Python).
El Entrenamiento "Limpieza y Máscara": Eliminaron los comentarios y reemplazaron los números con marcadores durante el entrenamiento. Esto obligó a los modelos a observar la lógica del código, no solo los adornos superficiales.
La Estrategia de "Fragmentación": Dado que el código de prueba a menudo era demasiado largo para leer de una sola vez, lo cortaron en trozos superpuestos (como leer un libro largo leyendo unas pocas páginas a la vez). Luego tomaron el promedio de estos trozos, ignorando las predicciones más extremas y "ruidosas", para tomar una decisión final.
La Calibración de "Casos Difíciles": Crearon una "prueba especial difícil" utilizando ejemplos que un programa informático simple había fallado. Ajustaron su umbral de decisión (la línea entre "Humano" y "IA") basándose en estos casos complicados para asegurar que no fueran engañados por los datos de prueba.

Para el Acertijo B (¿Qué Robot?)

La Técnica del "Sándwich": Dado que el código era demasiado largo para caber en la memoria del modelo, no simplemente cortaron el medio. En su lugar, mantuvieron la Cabeza (inicio) y la Cola (final) del código y los metieron juntos como un sándwich, con un marcador especial en el medio. Esto preservó el estilo al principio y al final, que es a menudo donde se esconde la "firma del robot".
El Peso de "Equidad": Debido de que algunos modelos de IA eran raros en los datos, el equipo le dijo al modelo: "¡No adivines solo el más común! Presta atención extra a los raros". Ajustaron el sistema de puntuación para que el modelo aprendiera a detectar los robots raros, no solo los populares.
La Votación de la "Sabiduría de la Multitud": Ejecutaron el mismo código a través del modelo varias veces con ligeras variaciones y dejaron que los modelos votaran por la respuesta. Esto redujo los errores y aumentó la confianza.

Los Resultados

El equipo de "Arqueología" lo hizo muy bien:

Acertijo A: Obtuvieron una puntuación de 0.737, colocándose 6º de 81 equipos. Su mejor herramienta fue CodeBERT, que parecía entender la "lógica" del código mejor que los demás.
Acertijo B: Obtuvieron una puntuación de 0.422, colocándose 7º de 34 equipos. Su mejor herramienta aquí fue UniXcoder, que se benefició de observar trozos de código más largos y de utilizar la estrategia de "votación".

La Gran Conclusión

El equipo descubrió que cómo se entrenó un modelo importa más que su tamaño.

Los modelos más pequeños (125 millones de parámetros) que fueron entrenados específicamente para entender la lógica del código funcionaron mejor para detectar la IA.
El modelo gigante (220 millones de parámetros) no ganó, lo que sugiere que para este trabajo específico, ser un "especialista" es mejor que ser un "generalista".

En resumen, el equipo demostró que con los trucos de entrenamiento adecuados —como cortar el código largo, ignorar el ruido superficial y votar por las respuestas— se puede construir un sistema sorprendentemente bueno para detectar código generado por IA, incluso cuando intenta disfrazarse en nuevos idiomas.

Resumen Técnico: Arqueología en SemEval-2026 Tarea 13

Declaración del Problema

El artículo aborda el desafío de detectar código fuente generado por IA, un problema crítico para la integridad académica, la seguridad de la cadena de suministro de software y la atribución de propiedad intelectual. Los autores participaron en la Tarea 13 de SemEval-2026, dividida en tres subtasas; su sistema, "Arqueología", se centró en las dos primeras:

Subtarea-A: Clasificación binaria para distinguir entre código escrito por humanos y código generado por IA.
Subtarea-B: Atribución multiclase para identificar la familia específica de Modelos de Lenguaje Grande (LLM) que generó un fragmento de código dado entre 11 clases (incluyendo código escrito por humanos y 10 modelos de IA distintos).

Ambas subtareas utilizan la puntuación F1 promediada macro como métrica de evaluación principal. Las tareas presentan desafíos distintos: la Subtarea-A requiere generalización a lenguajes de programación fuera de dominio (OOD) no vistos durante el entrenamiento, mientras que la Subtarea-B debe manejar distribuciones de clases extremadamente desequilibradas (una relación de 225:1 entre la clase más grande y la más pequeña) y secuencias de código largas.

Metodología

Línea Base

El equipo estableció una línea base utilizando características TF-IDF (n-gramas de caracteres desde bigramas hasta 5-gramas) combinadas con Regresión Logística. El código se truncó a los primeros 10,000 caracteres. Para la Subtarea-B, se aplicaron pesos de clase equilibrados para mitigar el desequilibrio de etiquetas. Esta línea base alcanzó puntuaciones F1 macro de 0.266 (Subtarea-A) y 0.255 (Subtarea-B), demostrando que los patrones léxicos superficiales por sí solos son insuficientes.

Modelos Pre-entrenados

El sistema central ajusta finamente cuatro modelos de código pre-entrenados:

CodeBERT: Solo codificador (RoBERTa-base, 125M parámetros), pre-entrenado con Modelado de Lenguaje enmascarado (MLM) y Detección de Tokens Reemplazados.
GraphCodeBERT: Solo codificador (RoBERTa-base), extendiendo CodeBERT con estructuras de grafos de flujo de datos.
UniXcoder: Solo codificador (RoBERTa-base), un modelo unificado que soporta comprensión y generación mediante objetivos multimodales cruzados.
CodeT5+: Codificador-decodificador (220M parámetros), pre-entrenado con desruido y modelado de lenguaje causal en código y pares de código-texto.

Estrategias para la Subtarea-A (Clasificación Binaria)

Para abordar el desafío de lenguajes OOD (entrenamiento en Python, C++, Java; prueba en lenguajes adicionales como JavaScript, Go, PHP), los autores emplearon:

Validación Cruzada Leave-One-Language-Out (LOLO): Los modelos se entrenaron en dos lenguajes y se validaron en el tercero para simular condiciones OOD. Los datos de entrenamiento se equilibraron muestreando un número igual de ejemplos por lenguaje y etiqueta.
Aumento de Código: Se aplicaron aumentos estocásticos para reducir la dependencia de características superficiales específicas del lenguaje, incluyendo eliminación de comentarios, enmascaramiento de literales y eliminación de encabezados. La normalización determinista eliminó las vallas de markdown y estandarizó los espacios en blanco.
Inferencia por Bloques: Dado que el código de prueba es más largo que el de entrenamiento, los fragmentos que excedían la ventana de contexto del modelo se dividieron en bloques superpuestos. Las probabilidades se agregaron utilizando una media recortada (eliminando valores mínimos/máximos) combinada con una media de los 2 mejores (promediando las dos probabilidades más altas) para equilibrar la robustez frente al ruido con la sensibilidad a señales fuertes.
Calibración de Umbrales: Se utilizó una calibración en dos etapas. Primero, se encontró un umbral óptimo en predicciones OOF. Segundo, se construyó un "conjunto de datos difícil" de 1,000 ejemplos mal clasificados (de una validación cruzada de Regresión Logística) para derivar un segundo umbral. El umbral de decisión final fue una mezcla de igual peso de estos dos, con umbrales adicionales por lenguaje aplicados donde fue posible la detección de lenguaje.

Estrategias para la Subtarea-B (Atribución Multiclase)

Para manejar el desequilibrio extremo de clases y las secuencias largas:

Empaquetado de Tokens de Sándwich: En lugar de truncar el código largo, la secuencia de entrada se construyó utilizando los primeros $h$ tokens (cabeza), un delimitador y los últimos $t$ tokens (cola). Durante el entrenamiento, la fracción de cabeza se muestreó aleatoriamente para actuar como aumento de datos; durante la inferencia, se fijó en 0.60.
Pérdida Equilibrada por Clase: Para contrarrestar el desequilibrio de 225:1, los autores utilizaron pesos de pérdida equilibrados por clase basados en el número efectivo de muestras ( $\beta = 0.9995$ ), asignando un peso mayor a las clases subrepresentadas sin el sobre-peso extremo de los métodos de frecuencia inversa.
Ensamblaje y Aumento en Tiempo de Prueba (TTA):
- UniXcoder: Entrenado con 3 semillas aleatorias y ejecutado con 3 fracciones de cabeza diferentes durante la inferencia (9 pasadas hacia adelante en total).
- CodeBERT/GraphCodeBERT: Semilla única con 3 fracciones de cabeza (3 pasadas).
- CodeT5+: Semilla única, fracción de cabeza fija, 1 época de entrenamiento debido al tamaño del modelo.

Resultados

El sistema alcanzó las siguientes puntuaciones F1 macro en el conjunto de prueba:

Subtarea-A: 0.737 (6º lugar de 81 equipos) utilizando CodeBERT.
Subtarea-B: 0.422 (7º lugar de 34 equipos) utilizando UniXcoder.

Observaciones Clave:

Todos los modelos ajustados finamente superaron significativamente la línea base TF-IDF.
Para la Subtarea-A, los modelos solo codificador enfocados en la comprensión de código (CodeBERT, GraphCodeBERT) superaron al CodeT5+ codificador-decodificador y al UniXcoder orientado a la generación.
Para la Subtarea-B, UniXcoder superó a los otros modelos, atribuido a su ventana de contexto más grande (1,024 tokens frente a 512), el ensamblaje de 3 semillas y el uso del token de modo <encoder-only>.
El análisis de errores reveló que los modelos tuvieron más dificultades con los lenguajes OOD en la Subtarea-A y con distinguir generadores de IA estilísticamente similares en la Subtarea-B (por ejemplo, la Clase 1 tuvo una F1 $\le$ 0.11 a pesar de tener suficientes datos de entrenamiento).

Significado y Contribuciones

El artículo reclama tres contribuciones técnicas principales:

Pipeline de Inferencia por Bloques: Un método para la clasificación binaria de código que utiliza agregación de media recortada para manejar fragmentos de código largos que exceden los límites de contexto del modelo.
Estrategia de Calibración de Umbrales: Un enfoque híbrido que combina umbrales OOF con umbrales derivados de un "conjunto de datos difícil" de ejemplos mal clasificados, refinado adicionalmente por calibración por lenguaje.
Empaquetado de Tokens de Sándwich: Una estrategia para la atribución multiclase que preserva la información del principio y el final de secuencias de código largas, combinada con aumento en tiempo de prueba y pérdida equilibrada por clase.

Los autores concluyen que la elección del objetivo de pre-entrenamiento es más crítica que el tamaño del modelo para estas tareas. Los modelos pre-entrenados para la comprensión de código (CodeBERT, GraphCodeBERT) destacaron en la detección binaria, mientras que el UniXcoder unificado, potenciado por ventanas de contexto más largas y ensamblaje, tuvo el mejor rendimiento en la atribución multiclase. El artículo señala que CodeT5+, a pesar de ser el modelo más grande (220 millones de parámetros), no alcanzó las puntuaciones más altas, lo que sugiere que el tamaño por sí solo no garantiza el rendimiento en este dominio.

Limitaciones

Los autores reconocen varias limitaciones:

El uso de modelos pre-entrenados relativamente pequeños (125M–220M parámetros) y ventanas de contexto limitadas (hasta 1,024 tokens).
La compensación en la inferencia por bloques entre cobertura y dilución de la señal.
La dependencia de un "conjunto de datos difícil" para la calibración de umbrales, que puede no estar siempre disponible en implementaciones del mundo real.
La falta de estudios de ablación extensos debido a restricciones computacionales, dejando la contribución aislada de componentes específicos (por ejemplo, aumentos específicos o métodos de agregación) sin cuantificar.