Technische Samenvatting: Het verklaren van het risico van codewijzigingen met behulp van LLM-gebaseerde voorspellingsmodellen

Probleemstelling

In grootschalige softwareontwikkeling worden Just-in-Time (JIT) defectvoorspellingssystemen, zoals de Diff Risk Score (DRS), gebruikt om de waarschijnlijkheid te voorspellen dat een codewijziging (diff) een service-onderbreking veroorzaakt. Hoewel traditionele modellen zoals logistische regressie enige verklaarbaarheid bieden via feature-coëfficiënten, hebben ze moeite om de rijke tekstuele inhoud van codewijzigingen te benutten. Omgekeerd hebben Large Language Models (LLMs) een superieure nauwkeurigheid aangetoond in risicovoorspelling, maar opereren ze als "black boxes", waarbij ze slechts een risicoscore leveren zonder actiegerichte rechtvaardiging.

Dit gebrek aan verklaarbaarheid creëert aanzienlijke barrières voor adoptie: engineers kunnen niet gemakkelijk bepalen waarom een diff wordt gemarkeerd, wat leidt tot verminderd vertrouwen, scepsis en moeilijkheden bij het verfijnen van inspectie-inspanningen. Zonder duidelijke begeleiding worden risicovolle waarschuwingen vaak genegeerd, of worden engineers gedwongen om volledige diffs handmatig te scannen, wat de productiviteit in gevaar brengt. De kernuitdaging is om LLM-gebaseerde risicovoorspellingen actiegericht te maken door specifieke delen van een codewijziging te identificeren die het meest bijdragen aan het voorspelde risico, zonder hallucinaties of excessieve latentie te introduceren.

Methodologie

De auteurs stellen een pragmatische aanpak voor voor verklaarbaarheid die gebruikmaakt van de interne attention-mechanismen van een LLM tijdens de standaard inferentie. De methodologie omvat drie primaire stadia:

1. LLM-gebaseerde Risicovoorspelling:

   • Een vooraf getraind LLM (specifiek Llama3-70B, instructie-gefine-tuned op historische diffs) wordt gebruikt om te classificeren of een diff een onderbreking kan veroorzaken.
   • Het model ontvangt een prompt met de inhoud van de diff en krijgt de instructie om een single-token respons (0 of 1) te genereren.
   • De risicoscore wordt afgeleid van de logits van deze output-token.

2. Extractie en Aggregatie van Attention:

   • Tijdens de inferentie genereert het model een attention-tensor die de correlatie tussen de output-token en de input-tokens vertegenwoordigt.
   • Deze attention-gewichten worden gepoold over attention heads om een token-niveau belang-vector te creëren.
   • De auteurs geven expliciet aan dat zij niet beweren dat er een causale trouw bestaat tussen attention en redenering; in plaats daarvan dient attention als een praktisch proxy-signaal om relevante code-regio's te highlighten.

3. Hiërarchische Token-groepering en Mapping:

   • Om token-niveau gewichten interpreteerbaar te maken voor ontwikkelaars, mapt het systeem deze terug naar standaard code review-eenheden: Lines (regels), Hunks (aaneengesloten blokken wijzigingen) en Files (bestanden).
   • Een vier-niveau hiërarchie wordt geconstrueerd:
     • Token Reconstitutie: Subword-tokens (bijv. van SentencePiece of Tiktoken) worden samengevoegd tot whitespace-gescheiden tokens.
     • Structuurherstel: Newline-tokens en unified-diff headers (@@ ... @@) worden gebruikt om de file- en hunk-structuur te reconstruen.
     • Score Aggregatie: Attention-scores worden bottom-up geaggregeerd. Voor leaf-tokens worden scores gemiddeld. Voor interior nodes (regels, hunks, bestanden) worden specifieke aggregatiefuncties toegepast. Met name op het niveau van de hunk wordt een top-$k$ sum gebruikt om geconcentreerde signalen te vangen terwijl de invloed van grote hunks wordt begrensd.
   • Pruning (Snoeien): Om ruis te verminderen, worden token-scores binnen testbestanden (geïdentificeerd via regex-patronen) geneutraliseerd, aangezien wijzigingen in tests zelden de werkelijke oorzaak zijn van onderbrekingen.

4. Output:

   • Het systeem presenteert de top-$K$ hoogst scorende eenheden (bijv. de top-2 hunks) aan de ontwikkelaar binnen de code review UI als een "review budget", om de aandacht te richten op de meest verdachte regio's.

Belangrijkste Bijdragen

• Pragmatisch Highlight-signaal: Het paper introduceert een methode om LLM attention-gewichten om te zetten in actiegerichte code-highlights (regels, hunks, bestanden) zonder aanvullende modeltraining te vereisen of potentieel hallucinerende natuurlijke taalverklaringen te generen.
• Hiërarchisch Aggregatieframework: Een nieuw pipeline dat subword-tokens reconstrueert en attention-scores recursief aggregeert over file-, hunk- en regel-granulariteiten, rekening houdend met verschillende tokenizer-gedragingen.
• Industriële Validatie: De aanpak wordt geëvalueerd in een grootschalige industriële context (FAANGCompany) met behulp van een handmatig gecureerde Outage Root Cause (O-RC) dataset, waar domeinexperts de specifieke regels identificeerden die verantwoordelijk waren voor echte onderbrekingen.
• Schaalbaarheid: Omdat attention wordt berekend als een bijproduct van de standaard inferentie, voegt de methode minimale latentie toe en is deze haalbaar voor workflows met een hoge doorvoer tijdens code reviews.

Experimentele Resultaten

De studie evalueerde de effectiviteit van de highlighting-methode met behulp van de O-RC dataset, waarbij de Coverage (het percentage diffs waarin de gehighlighte eenheden de werkelijke root-cause regels bevatten) en de Average Review Percent (ARP) (het percentage van de totale gewijzigde regels dat een ontwikkelaar moet reviewen) werden gemeten.

• Granulariteit-afwegingen:
  • Regelniveau (Line-level): Het highlighten van de top-30 regels bereikte 53,85% coverage, maar vereiste het reviewen van 22,8% van de diff.
  • Bestandsniveau (File-level): Het highlighten van de top-3 bestanden bereikte 92,30% coverage, maar vereiste het reviewen van 78,61% van de diff, wat vaak te grofmazig is voor actiegerichte debugging.
  • Hunk-niveau: Het highlighten van de top-2 hunks bereikte 53,85% coverage terwijl ontwikkelaars gemiddeld slechts 26,28% van de gewijzigde regels hoefden te reviewen.
• Optimale Configuratie: De auteurs concluderen dat hunk-level highlighting (top-2) de beste balans biedt tussen coverage en ontwikkelaarinspanning. Het sluit aan bij hoe engineers diffs natuurlijk reviewen (het inspecteren van hunks) en voorkomt de overhead van context-switching door verspreide regel-highlights of de excessieve hoeveelheid file-level highlights.
• Gebruikersfeedback: Vroege kwalitatieve feedback van 55 gebruikers (48 negatief, 7 positief) wees op specifieke foutmodi, zoals het highlighten van testbestanden (ondanks filtering) en boilerplate code, of directionele ambiguïteit waarbij attention eerder een laag risico dan een hoog risico zou kunnen aangeven.

Betekenis en Claims

Het paper positioneert dit werk als een voorlopige studie gericht op het overbruggen van de kloof tussen hoog-nauwkeurige LLM-voorspellingen en de noodzaak voor vertrouwen en actiegerichtheid bij engineers.

• Actiegerichtheid: De primaire claim is dat geaggregeerde attention een laag-latente, schaalbare signaal biedt dat inspectie beperkt tot een klein aantal code-regio's, waardoor JIT-defectvoorspellingen actiegericht zijn voor professionele engineers.
• Verbetering ten opzichte van Baseline: De aanpak verbetert meetbaar de huidige productie-baseline van "geen highlighting", waarbij engineers een risicoscore ontvangen zonder context.
• Vertrouwen en Adoptie: Door een visuele gids te bieden over waar te kijken, beoogt de methode het vertrouwen in het DRS-model te vergroten en engineers te helpen de risico's van hun wijzigingen te mitigeren.
• Bescheidenheid: De auteurs erkennen expliciet beperkingen, waaronder het potentieel dat attention-gewichten worden beïnvloed door de prompt-structuur in plaats van semantiek, de onvolledigheid van de test-file filtering, en het feit dat de studie een momentopname is. Zij beweren niet dat attention gelijk staat aan causaal redeneren, maar dat het dient als een nuttige heuristiek voor het prioriteren van menselijke reviews.

Het werk toont aan dat in een omgeving met hoge inzet en op grote schaal, eenvoudige, op attention gebaseerde highlighting effectief kan zijn om complexe LLM-gebaseerde risicomodellen te ondersteunen, wat een bredere inzet ervan in industriële settings mogelijk maakt.