🤖 machine learning

Merge-Bench: Resolve Merge Conflicts with Large Language Models

Este artículo presenta Merge-Bench, un conjunto de datos a gran escala de conflictos de fusión del mundo real, y LLMergeJ, un modelo específico de Java entrenado con Optimización de Políticas Relativas por Grupos que supera a varios modelos comerciales de LLM, aunque incluso los mejores modelos resuelven actualmente menos del 60% de los conflictos en 11 lenguajes de programación.

Autores originales: Benedikt Schesch, Michael D. Ernst

Publicado 2026-05-26

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Benedikt Schesch, Michael D. Ernst

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 que estás trabajando en un proyecto grupal donde dos amigos editan el mismo documento al mismo tiempo. El Amigo A cambia un párrafo, y el Amigo B cambia exactamente el mismo párrafo. Cuando intentas combinar su trabajo, la computadora se confunde y grita: "¡No sé qué versión conservar!". Esto se llama un conflicto de fusión.

Por lo general, un humano debe intervenir, leer ambas versiones, averiguar lo que los amigos realmente pretendían hacer y arreglar manualmente el desastre. Esto toma tiempo y puede llevar a errores.

Este artículo presenta una nueva forma de enseñar a las computadoras a arreglar estos desastres automáticamente utilizando IA "inteligente" (Modelos de Lenguaje Grandes). Aquí está el desglose de su trabajo en términos sencillos:

1. El Problema: La computadora está a ciegas

Las herramientas tradicionales son como un robot que solo mira las letras. Si el Amigo A escribió "gato" y el Amigo B escribió "perro", el robot solo ve un choque. No entiende que quizás estaban hablando de mascotas, o que quizás uno fue un error tipográfico. Necesita que un humano explique la intención.

2. La Solución: Un nuevo campo de entrenamiento (Merge-Bench)

Para enseñar a una IA a resolver estos conflictos, necesitas una biblioteca masiva de ejemplos que muestren "Aquí estaba el desastre, y aquí es cómo un experto humano lo arregló".

La Vieja Forma: Otros investigadores intentaron crear estas bibliotecas a mano o ejecutando pruebas. Esto era lento, costoso y, a veces, la IA "hacía trampa" memorizando las respuestas de las pruebas en lugar de aprender a arreglar el código.
La Nueva Forma (Merge-Bench): Los autores construyeron una biblioteca gigante y automatizada llamada Merge-Bench. Recopilaron 7,938 conflictos reales de 1,439 proyectos de código públicos diferentes en GitHub.
- La Analogía: Imagina a un profesor que no necesita calificar cada tarea a mano. En su lugar, tiene una máquina que automáticamente captura 8,000 ejemplos del mundo real de estudiantes cometiendo errores y las respuestas correctas escritas por el profesor. Como la máquina hace todo el trabajo, pueden tener una biblioteca enorme que nunca se agota.

3. El Estudiante: LLMergeJ

Los autores entrenaron un modelo de IA específico llamado LLMergeJ (la "J" significa Java, el lenguaje de programación en el que se centraron).

Cómo lo enseñaron: En lugar de solo mostrarle al modelo la respuesta (como un profesor estándar), utilizaron un método llamado Aprendizaje por Refuerzo.
- La Analogía: Piensa en entrenar a un perro. Si el perro adivina el truco correcto, recibe una golosina. Si adivina mal, no recibe nada. Si se niega a adivinar y simplemente dice "No sé" (preservando el conflicto), recibe una migaja.
- La IA intentó miles de veces. Cuando descubrió la forma correcta de combinar el código, recibió una gran recompensa. Con el tiempo, aprendió no solo cómo se veía la respuesta, sino cómo pensar sobre el problema para llegar a ella.

4. Los Resultados: Perro pequeño, trucos grandes

Probaron su modelo de 14 mil millones de parámetros (que es relativamente pequeño para los estándares de la IA) contra los modelos comerciales de IA más grandes y costosos disponibles (como Gemini, Claude y Grok).

La Sorpresa: Su modelo pequeño y entrenado específicamente lo hizo mejor que casi todos los modelos comerciales gigantes. Resolvió correctamente aproximadamente el 59% de los conflictos (después de ignorar diferencias menores de formato).
La Comparación: El mejor modelo comercial (Gemini 2.5 Pro) fue ligeramente mejor, pero el modelo de los autores superó a los demás por un margen significativo.
La Lección: Un modelo pequeño entrenado específicamente en cómo resolver conflictos de fusión utilizando recompensas es mejor que un modelo gigante de propósito general al que simplemente se le pidió hacerlo una vez.

5. Por qué esto importa

Sin hacer trampa: Su método de prueba no depende de ejecutar pruebas de código (que la IA a veces puede engañar). Compara el código directamente con lo que el desarrollador humano realmente hizo.
Escalable: Como no necesitaron que humanos etiquetaran los datos, pudieron hacer el conjunto de entrenamiento tan grande como quisieran.
Independiente del lenguaje: Aunque solo entrenaron el modelo en Java, probaron los grandes modelos comerciales en 11 lenguajes diferentes (C, Python, Rust, etc.). Descubrieron que el comportamiento de la IA fue similar en todos los lenguajes, lo que sugiere que su método podría funcionar para cualquier lenguaje de programación.

Resumen

Los autores construyeron un gimnasio masivo y automatizado (Merge-Bench) para entrenar a un atleta de IA específico (LLMergeJ) para resolver conflictos de código. Mediante el uso de un sistema de entrenamiento basado en recompensas, enseñaron a una IA relativamente pequeña a superar a los modelos de IA más grandes y costosos en esta tarea específica, demostrando que el entrenamiento especializado supera al tamaño general cuando se trata de arreglar desastres de software.

), 0 en caso contrario.
* $R_{format}$ : 1 si la salida utiliza un formato Markdown correcto, 0 en caso contrario.
* $R_{resolution}$ : 1.0 para una coincidencia textual exacta, 0.5 para una coincidencia de código fuente normalizada, 0.1 para preservar el conflicto (sin resolución) y 0 para fusiones incorrectas.

Ventaja sobre SFT: A diferencia del Ajuste Fino Supervisado (SFT), que solo puede aprender de las salidas finales, GRPO optimiza el proceso de razonamiento y maneja la imprevisibilidad de la verdad fundamental (donde múltiples soluciones sintácticamente diferentes pueden ser válidas) mediante el uso de ventajas relativas al grupo. Esto evita que el modelo se sobreajuste a patrones sintácticos específicos.

Contribuciones Clave

Merge-Bench: Una referencia a gran escala y escalable, resistente a la manipulación de recompensas y que requiere cero anotación manual.
Evaluación sin Ejecución de Pruebas: Una metodología que evita la ejecución de pruebas, permitiendo un entrenamiento y una evaluación escalables sin las vulnerabilidades de las recompensas basadas en suites de pruebas.
SWE-RL sin Filtro Humano: Una tarea de aprendizaje por refuerzo para la ingeniería de software que utiliza datos a escala de internet sin filtrado humano ni ajustes manuales.
LLMergeJ: El primer modelo entrenado con RL en línea para la resolución de conflictos de fusión, demostrando que un modelo de 14 mil millones de parámetros puede superar a modelos comerciales significativamente más grandes.

Resultados

Rendimiento en Java

En el subconjunto de Java de Merge-Bench (806 conflictos):

LLMergeJ (14B) logró un 48.8% de coincidencia textual exacta y un 58.9% de coincidencia de código fuente normalizada.
Comparación: LLMergeJ superó a tres grandes modelos de lenguaje comerciales (Claude Opus 4, o3 Pro y Grok 4) y a una línea base SFT de Qwen3-14B. Solo quedó por detrás de Gemini 2.5 Pro (62.5% de coincidencia normalizada).
Línea Base SFT: Incluso cuando la línea base SFT se entrenó con los mismos datos y con hiperparámetros optimizados específicamente para el conjunto de pruebas, solo logró un 36.6% de coincidencia exacta y un 44.7% de coincidencia normalizada, destacando la superioridad del enfoque GRPO para esta tarea.
Análisis Conductual:
- Resolutores Agresivos (LLMergeJ, Gemini 2.5 Pro, o3 Pro): Alta confianza, resolviendo entre el 51% y el 62% de los conflictos, con tasas bajas de preservación de conflictos (3–21%).
- Resolutores Conservadores (Grok 4, Llama 4 Maverick): Altas tasas de preservación de conflictos (40–86%), lo que indica incertidumbre.
- Modelos con Dificultad de Formato: Algunos modelos (por ejemplo, QwQ 32B, R1 1.5B) no lograron seguir las instrucciones de formato Markdown, lo que condujo a salidas inválidas.

Rendimiento Translingüístico

Los autores evaluaron seis modelos comerciales de última generación en 11 idiomas (C, C++, C#, Go, Java, JavaScript, PHP, Python, Ruby, Rust, TypeScript).

Dificultad del Idioma: Se encontró que C es el más difícil de fusionar, mientras que Java, PHP y Python son los más fáciles.
Estabilidad: El rendimiento de los modelos de lenguaje comerciales fue mayormente estable a través de los idiomas.
Generalización: Los patrones conductuales (por ejemplo, qué modelos son agresivos frente a conservadores) se mantuvieron consistentes entre los idiomas, lo que sugiere que las técnicas pueden generalizarse, aunque LLMergeJ en sí mismo solo fue entrenado en Java.

Significado y Afirmaciones

El artículo afirma que LLMergeJ demuestra que los modelos pequeños y especializados entrenados con aprendizaje por refuerzo pueden lograr un rendimiento competitivo o superior en comparación con los modelos comerciales masivos para tareas específicas de ingeniería de software. El trabajo destaca que:

El Aprendizaje por Refuerzo (GRPO) es superior al SFT para conflictos de fusión porque optimiza el razonamiento y maneja la ambigüedad de múltiples soluciones válidas sin degradar el rendimiento.
La Escalabilidad es alcanzable sin anotación humana, abordando un cuello de botella en las referencias actuales de SWE como SWE-Bench.
Eficiencia de Parámetros: Un modelo de 14 mil millones de parámetros puede rivalizar con modelos que tienen órdenes de magnitud más parámetros cuando se entrena con la metodología y los datos correctos.

Los autores mantienen una postura modesta, reconociendo limitaciones como la posibilidad de errores en la verdad fundamental, la posibilidad de filtración de datos en conjuntos de entrenamiento comerciales y el hecho de que el entrenamiento se limitó a Java. Señalan que las restricciones de tamaño del conjunto de datos pueden excluir los problemas de fusión más complejos, lo que podría llevar a una sobreestimación del rendimiento en todos los conflictos del mundo real.