LLM Code Smells: A Taxonomy and Detection Approach
Dit artikel presenteert een verfijnde taxonomie van negen LLM-codegeuren en introduceert SpecDetect4LLM, een statische analyse-tool die hoge precisie en recall aantoont bij het detecteren van deze integratieproblemen in 73,5% van de 692 geanalyseerde open-sourceprojecten.
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 of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer
Stel je voor dat je een huis bouwt, maar in plaats van een menselijke architect in te huren, huur je een super slimme, ongelooflijk snelle, maar licht onvoorspelbare robot in om je te helpen bij het ontwerpen van kamers en het kiezen van meubels. Deze robot is een Groot Taalmodel (LLM). Het is verbazingwekkend, maar als je geen duidelijke instructies geeft of zijn werk niet controleert, kan hij een deur bouwen waar een raam zou moeten zijn, of materialen gebruiken die in de regen uit elkaar vallen.
Dit artikel gaat over de "slechte gewoonten" (of "codegeuren") die ontstaan wanneer menselijke ontwikkelaars proberen deze robots binnen hun software in te zetten. De onderzoekers ontdekten dat, net zoals een rommelige keuken kan leiden tot verbrand eten, rommelige code bij communicatie met een AI kan leiden tot software die crasht, te veel geld kost of verkeerde antwoorden geeft.
Hier is een overzicht van hun bevindingen met eenvoudige analogieën:
1. Het Probleem: "De Slechte Gewoonten van de Robot"
De onderzoekers identificeerden 9 specifieke slechte gewoonten die ontwikkelaars maken bij het praten met deze AI-robots. Ze groepeerden ze in drie categorieën, net als het sorteren van gereedschap in een gereedschapskist:
De "Structurele" Gewoonten (Hoe je de vraag stelt):
- Analogie: Stel je voor dat je een chef vraagt: "Maak me het avondeten", zonder te vertellen of je vegetarisch wilt, pittig, of dat je een notenallergie hebt.
- De Geur: Geen Systeembericht. Ontwikkelaars vergeten vaak de AI een "functieomschrijving" te geven (een systeembericht) waarin staat wie het zou moeten zijn (bijvoorbeeld: "Je bent een behulpzame wiskundeleraar"). Zonder dit gedraagt de robot zich als een generieke chatty bot in plaats van als een specialist.
- De Geur: Anonieme Oproepen. Stel je voor dat je een restaurant belt maar je naam niet geeft. Als het eten slecht is, weet het restaurant niet wie ze moeten terugbellen. Ontwikkelaars vergeten vaak een "gebruikers-ID" aan de AI-aanvraag te koppelen, waardoor het onmogelijk wordt om later te traceren wie het probleem heeft veroorzaakt.
De "Data"-Gewoonten (Wat je verstuurt en terugkrijgt):
- Analogie: Vragen aan een robot om je post te sorteren, maar hem een gigantisch, ongeopend doos vol ongewenste reclamepost sturen in plaats van alleen de brieven.
- De Geur: Geen Gestructureerde Output. Je vraagt de AI om een lijst met ingrediënten in een specifiek formaat (zoals een JSON-lijst), maar je dwingt het niet om dat formaat te volgen. Het kan je een alinea tekst geven in plaats daarvan. Je software probeert die alinea vervolgens als een lijst te lezen en crasht.
- De Geur: Raw Vision Payload. Als je de AI vraagt om naar een foto van een bug in je code te kijken, is het zonde om de hele 4K-screenshot van je monitor te sturen. Het is alsof je een hele bibliotheek per post stuurt om iets te vragen over één boek. Je moet de afbeelding eerst bijsnijden tot alleen de bug.
De "Protocol"-Gewoonten (De regels van het spel):
- Analogie: Een auto rijden zonder een snelheidslimiet in te stellen of te controleren welk model auto je rijdt, ervan uitgaande dat het altijd hetzelfde zal zijn.
- De Geur: Geen Modelversie-Vastlegging. Je zegt tegen de robot: "Gebruik het 'GPT-4'-model." Maar het bedrijf kan "GPT-4" morgen updaten tot een geheel andere robot. Je code breekt omdat de robot zijn persoonlijkheid heeft veranderd. Je moet het vastleggen op een specifieke versie (zoals "GPT-4 van november 2024").
- De Geur: Onbegrensde Max-metrieken. Je vraagt de robot om een verhaal te schrijven, maar je zegt niet dat het moet stoppen na 500 woorden. Het kan eeuwig doorgaan met schrijven, al je geld en tijd opvretend.
- De Geur: Temperatuur Niet ingesteld. Dit regelt hoe "creatief" of "willekeurig" de robot is. Als je dit niet instelt, gebruikt de robot een standaardinstelling die morgen kan veranderen, waardoor je software op verschillende dagen anders gedraagt.
2. De Oplossing: De "Snuffelhond" (SpecDetect4LLM)
De onderzoekers bouwden een tool genaamd SpecDetect4LLM. Denk hierbij aan een snuffelhond die door je code loopt.
- Het voert de code niet uit; het kijkt alleen naar de instructies (de "statische analyse").
- Het snuffelt rond om te zien of je een van die 9 slechte gewoonten hebt gemaakt.
- Als het een slechte gewoonte vindt, blaft het (markeert het) zodat de ontwikkelaar het kan oplossen voordat de software live gaat.
3. De Resultaten: Hoe goed is de hond?
De onderzoekers testten deze snuffelhond op 692 verschillende softwareprojecten (ruim 171.000 bestanden met code). Hier is wat ze vonden:
Hoe vaak komen deze slechte gewoonten voor?
- 73,5% van de projecten had ten minste één van deze slechte gewoonten. Het is alsof je een huis binnenloopt en ontdekt dat 3 van de 4 een lekkende kraan hebben. Het komt zeer vaak voor.
- De meest voorkomende slechte gewoonte was het niet vastleggen van de modelversie (een generieke naam gebruiken in plaats van een specifieke).
Hoe goed is de snuffelhond in het vinden ervan?
- Precisie (Nauwkeurigheid): Wanneer de hond blaft, heeft hij 91,3% van de tijd gelijk. Hij schreeuwt zelden wolf.
- Recall (Volledigheid): De hond vindt ongeveer 71,8% van de werkelijke slechte gewoonten. Hij mist er enkele, maar vangt de meerderheid.
4. Waarom is dit belangrijk?
Het artikel betoogt dat hoewel deze slechte gewoonten niet altijd direct leiden tot het crashen van de software, ze zijn als roest op een auto.
- Ze maken de auto moeilijker te repareren later (Onderhoudbaarheid).
- Ze maken de auto trager of duurder in brandstof (Prestaties).
- Ze maken de auto onvoorspelbaar op regenachtige dagen (Betrouwbaarheid).
- Ze maken de auto onveilig als de wegcondities veranderen (Robuustheid).
Samenvatting
De onderzoekers creëerden een "menu" van 9 veelgemaakte fouten die ontwikkelaars maken bij het gebruik van AI, bouwden een tool om deze fouten automatisch te vinden, en bewezen dat deze fouten overal in de softwarewereld voorkomen. Hun tool is zeer goed in het opsporen ervan, waardoor ontwikkelaars software kunnen bouwen die veiliger, goedkoper en betrouwbaarder is wanneer het AI gebruikt.
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.