LLM-based vs. Search-based Merge Conflict Resolution: An Empirical Study of Competing Paradigms

Deze empirische studie vergelijkt op LLM's gebaseerde en op zoek gebaseerde hulpmiddelen voor het oplossen van merge-conflicten en toont aan dat, hoewel LLM's uitblinken bij onevenwichtige inhoud, op zoek gebaseerde methoden superieure robuustheid en generalisatie bieden, wat uiteindelijk suggereert dat hybride systemen die beide paradigma's combineren noodzakelijk zijn voor optimale prestaties.

Oorspronkelijke auteurs: Heleno de Souza Campos Junior, Leonardo Gresta Paulino Murta

Gepubliceerd 2026-05-19✓ Author reviewed
📖 5 min leestijd🧠 Diepgaand

Oorspronkelijke auteurs: Heleno de Souza Campos Junior, Leonardo Gresta Paulino Murta

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat jij en een vriend tegelijkertijd hetzelfde document bewerken. Jullie maken allebei wijzigingen in dezelfde alinea, en wanneer je probeert jullie werk te combineren, gooit de computer zijn handen in de lucht en zegt: "Ik weet niet welke versie ik moet behouden!" Dit heet een samenvoegconflict.

Decennialang moesten ontwikkelaars deze conflicten handmatig oplossen, wat saai is en vatbaar voor fouten. Onlangs zijn twee nieuwe "slimme helpers" opgedoken om dit probleem automatisch op te lossen. Dit artikel is een rechtstreekse wedstrijd tussen deze twee helpers om te zien welke de beste is.

De twee kandidaten

Stel je voor dat de twee helpers zeer verschillende persoonlijkheden en vaardigheden hebben:

1. De "Super-lezer" (LLM-gebaseerde aanpak, vertegenwoordigd door MergeGen)

  • Hoe het werkt: Deze helper is als een briljante student die miljoenen boeken en code-documenten heeft gelezen. Hij "berekent" het antwoord niet echt; in plaats daarvan gebruikt hij zijn geheugen van hoe dingen er meestal uitzien om de beste oplossing te raden. Hij voorspelt het volgende woord of de volgende regel op basis van patronen die hij heeft geleerd.
  • De analogie: Het is als een chef-kok die duizenden soepen heeft geproefd. Als je hem een recept geeft met een ontbrekend ingrediënt, weegt hij de kruiden niet af; hij "weet" gewoon hoe de soep zou moeten smaken op basis van ervaring en voegt de juiste hoeveelheid toe.

2. De "Puzzeloplosser" (Zoekgebaseerde aanpak, vertegenwoordigd door SBCR)

  • Hoe het werkt: Deze helper is een methodische ingenieur. Hij weet niet wat code betekent; hij ziet alleen regels tekst. Hij behandelt het conflict als een gigantische legpuzzel. Hij probeert miljoenen verschillende combinaties van de bestaande regels, waarbij hij elke combinatie controleert om te zien welke mix het meest lijkt op de originele versies. Hij gebruikt een eenvoudige regel: "De beste oplossing is meestal een mix die enigszins op beide ouders lijkt."
  • De analogie: Het is als een detective die geen idee heeft wie de verdachte is, dus hij probeert elke mogelijke combinatie van alibi's en aanwijzingen totdat hij die vindt die perfect bij de feiten past. Hij raadt niet; hij test.

De wedstrijd: Wat gebeurde er?

De onderzoekers stelden deze twee tegen elkaar op met duizenden echte conflicten uit open-source projecten (zoals Java-, C#- en JavaScript-code). Hier is wat ze ontdekten:

1. De "Super-lezer" wint wanneer dingen rommelig zijn.
Wanneer de twee versies van de code zeer verschillend waren in grootte (bijvoorbeeld: één versie voegde een enorme alinea toe terwijl de andere één regel verwijderde), was de Super-lezer verbazingwekkend. Omdat hij zo veel data heeft geleerd, kon hij de context begrijpen en de juiste regels kiezen, zelfs als de balans vreemd was. Hij was ook veel sneller en loste conflicten op in een flits.

2. De "Puzzeloplosser" wint wanneer dingen gebalanceerd zijn.
Wanneer de twee versies vergelijkbaar waren in grootte en structuur, was de Puzzeloplosser de kampioen. Hij vond vaker dan de Super-lezer de perfecte mix van regels. Hij was ook betrouwbaarder wanneer de code vreemde symbolen bevatte, tekst in een niet-Engelse taal, of extreem lang was.

3. De "Super-lezer" heeft een paar slechte gewoonten.

  • Geheugenlekken: Soms bleef de Super-lezer "steken" op een specifiek voorbeeld dat hij eerder had gezien tijdens zijn training. Hij zou gewoon dat antwoord herhalen, zelfs als het verkeerd was voor de huidige situatie. Dit heet overfitting—hij heeft de toets uit zijn hoofd geleerd in plaats van de les te leren.
  • Korte aandachtsspanne: Als het codeblok te groot was, raakte de Super-lezer overweldigd en stopte halverwege met schrijven, waardoor het conflict half opgelost bleef.
  • Taalbarrière: Als de code opmerkingen bevatte in een taal waar het model niet op was getraind, raakte hij in de war.

4. De "Puzzeloplosser" is wat traag maar gestaag.
Het duurt langer om de puzzel op te lossen omdat hij veel combinaties moet testen. Echter, hij raakt nooit in de war door lange tekst of vreemde talen omdat hij alles als simpele tekst behandelt. Hij "onthoudt" niets, dus hij overfit niet.

De grote conclusie: Geen "zilveren kogel"

Het artikel concludeert dat geen enkele helper op zichzelf perfect is.

  • Als je de Super-lezer een klein, rommelig conflict geeft, is hij een genie.
  • Als je de Puzzeloplosser een groot, gebalanceerd of vreemd opgemaakt conflict geeft, is hij de betrouwbare werkpaard.

De oplossing?
De auteurs suggereren het bouwen van een hybride systeem—een "Verkeersregelaar" die eerst naar het conflict kijkt.

  • Als het conflict klein en rommelig is, stuurt de Verkeersregelaar het naar de Super-lezer.
  • Als het conflict groot, gebalanceerd is, of vreemde tekens bevat, stuurt de Verkeersregelaar het naar de Puzzeloplosser.

Door het juiste gereedschap het juiste werk te laten doen, kunnen we een systeem creëren dat zowel snel als nauwkeurig is, en ontwikkelaars redden van de hoofdpijn van handmatig samenvoegen.

Samenvatting in één zin

Dit artikel bewijst dat terwijl AI-"gokkers" snel zijn en goed in rommelige problemen, "zoekers" betrouwbaarder zijn voor complexe of vreemde problemen, en dat het beste toekomstige gereedschap een slimme combinatie van beide zal zijn.

Verdrinkt u in papers in uw vakgebied?

Ontvang dagelijkse digests van de nieuwste papers die bij uw onderzoekswoorden passen — met technische samenvattingen, in uw taal.

Probeer Digest →