⚡ electrical engineering

A Benchmark on LLM-Based Power Flow Computation: Do More Structured Prompts Help?

Dit artikel presenteert een benchmark die aantoont dat, hoewel Gemini 2.5 Pro andere modellen overtreft bij LLM-gebaseerde Gauss-Seidel-stroomstroomberekeningen, geen enkele configuratie de voor directe numerieke oplossing vereiste betrouwbaarheid bereikt, en dat tegenstrijdig genoeg meer gestructureerde prompts de nauwkeurigheid kunnen verminderen in vergelijking met eenvoudige narratieve formaten.

Oorspronkelijke auteurs: Tingwei Chen, Kaiyang Huang, Kai Sun

Gepubliceerd 2026-05-19

📖 5 min leestijd🧠 Diepgaand

CC BY 4.0

Oorspronkelijke auteurs: Tingwei Chen, Kaiyang Huang, Kai Sun

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 drie verschillende AI-"studenten" hebt (laten we ze Gemini, Claude en GPT-3.5 noemen) en je wilt zien of ze kunnen fungeren als een rekenmachine voor een elektriciteitsnet. Specifiek vraag je hen om een klassiek, stap-voor-stap wiskundig probleem op te lossen genaamd "Power Flow" (vermogensflow), dat ingenieurs gebruiken om ervoor te zorgen dat elektriciteit veilig door een netwerk van draden stroomt.

De onderzoekers hebben een gecontroleerd experiment opgezet om twee dingen te onderzoeken:

Kunnen deze AI-studenten de wiskunde daadwerkelijk uitvoeren?
Verandert de manier waarop je de vraag stelt (de "prompt") hoe goed ze presteren?

Hier is de uiteenzetting van hun bevindingen met behulp van eenvoudige analogieën:

De Opzet: Een Driestrooksweg

De onderzoekers creëerden een klein, vereenvoudigd elektriciteitsnet met slechts drie "steden" (bussen) die verbonden zijn via wegen (transmissielijnen). Ze genereerden 50 verschillende verkeersscenario's (willekeurige belastingen en wegomstandigheden) en vroegen de AI om precies te berekenen hoeveel elektriciteit de hoofdstroombron (de "slack bus") moet genereren om alles draaiende te houden.

Ze testten de AI met vier verschillende manieren om de vraag te stellen:

Het Verhaal: Een eenvoudige alinea die het probleem beschrijft (zoals een vraag in een leerboek).
Het Verhaal + Voorbeeld: Dezelfde verhaal, maar met een opgelost voorbeeld uit een leerboek direct ervoor.
De Checklist: Een genummerde lijst met stappen om te volgen, waarbij de AI wordt gevraagd om haar werk te tonen.
Het Kalkulier: Een stijf, machineleesbaar formaat (JSON) met een strikte eis om elke stap van de berekening te tonen.

De Resultaten: Wie Geslaagd en Wie Gefaald?

1. De "Overdenker" (Gemini 2.5 Pro)

De Verrassing: Je zou denken dat het geven van een stijf kalkulier aan een AI en het vragen om elke enkele stap te tonen, haar nauwkeuriger zou maken. Het deed het tegenovergestelde.
De Analogie: Stel je voor dat je een briljante wiskundestudent vraagt een probleem op te lossen. Als je gewoon zegt: "Hier is het probleem, geef me het antwoord", krijgen ze het 54% van de tijd goed. Maar als je ze een complex formulier geeft en zegt: "Vul elk vak in en toon je werk regel voor regel", raken ze in de war, compliceren ze het onnodig en verdrievoudigen hun fouten.
Uitspraak: Gemini is de slimste van de drie, maar is zeer gevoelig voor hoe je met haar praat. Eenvoud is beter; complexe instructies schaden haar prestaties juist.

2. De "Steady Eddie" (Claude Sonnet 4.5)

Het Gedrag: Claude gaf niet veel om de manier waarop de vraag werd gesteld. Of het nu een verhaal, een checklist of een kalkulier was, het kreeg het antwoord ongeveer 38% van de tijd goed, ongeacht wat.
De Analogie: Denk aan Claude als een student die een specifieke manier van studeren heeft. Het veranderen van het testformaat helpt hen niet, maar het schaadt hen ook niet. Ze blijven gewoon in dezelfde "gemiddelde" zone.
Uitspraak: Het toevoegen van een uitgewerkt voorbeeld (hen een opgelost probleem laten zien) hielp Claude iets, maar het was nog steeds niet goed genoeg om een betrouwbare rekenmachine te zijn.

3. De "Strijdende Student" (GPT-3.5 Turbo)

Het Gedrag: Dit model faalde bijna elke keer, ongeacht hoe de vraag werd gesteld.
De Analogie: Stel je voor dat je een student vraagt die het materiaal nog niet heeft geleerd, een calculusprobleem op te lossen. Of je hen nu een hint, een leerboek of een rekenmachine geeft, ze krijgen het nog steeds 90% tot 96% van de tijd fout.
Uitspraak: Het is op dit moment simpelweg niet in staat tot dit specifieke type complexe, meervoudige wiskunde.

De Grote Les: "Meer Instructies" ≠ "B betere Resultaten"

De belangrijkste bevinding van dit paper is een waarschuwing voor iedereen die AI probeert te gebruiken voor wiskunde of engineering: Het geven van meer gedetailleerde instructies, gestructureerde data, of het vragen om "haar werk te tonen", garandeert geen betere nauwkeurigheid.

Sterker nog, voor het slimste geteste model maakte het complexer maken van de prompt het slechter. Het is alsof je een GPS vertelt "de route opnieuw te berekenen met een specifiek algoritme" terwijl het gewoon "Rij daar naartoe" had moeten zeggen. De extra regels verwarren het systeem.

De Eindconclusie: Nog Niet Klaar voor de Grote Scherm

De onderzoekers concludeerden dat geen enkele van deze AI-modellen klaar is om een echte engineeringrekenmachine te vervangen.

Zelfs het beste resultaat (Gemini met een eenvoudige prompt) kreeg het antwoord slechts ongeveer de helft van de tijd goed binnen een foutmarge van 5%.
In de echte wereld, als je een elektriciteitsnet beheert, kan een fout van 5% betekenen dat er een stroomuitval of een brand ontstaat. Je hebt 100% precisie nodig.

Samenvatting: Deze AI-modellen zijn geweldig om uit te leggen wat vermogensflow is of om ingenieurs te helpen bij het brainstormen van ideeën, maar ze zijn niet klaar om de daadwerkelijke rekenmachines te zijn die het net aansturen. Als je hen vraagt de wiskunde te doen, heb je nog steeds een mens (of een traditioneel computerprogramma) nodig om de cijfers te controleren.

Technische Samenvatting: Een Benchmark voor LLM-gebaseerde Berekening van Vermogensstroom

Probleemstelling
Berekening van vermogensstroom is een fundamenteel element van netplanning, -bedrijf en stabiliteitsanalyse. Hoewel Large Language Models (LLM's) steeds vaker worden onderzocht als besluitvormingshulpmiddelen voor slimme netten – variërend van storingsdiagnose tot operatorvragen en -antwoorden – blijft hun vermogen om nauwkeurige numerieke algoritmen uit te voeren onbevestigd. Specifiek vereist de Gauss-Seidel-methode, een canoniek iteratief oplosmiddel dat in curriculum voor elektrotechniek wordt onderwezen, complexe rekenkundige bewerkingen, convergentie over meerdere doorlopen en zorgvuldige tracking van tussenliggende spanningsramingen. Dit artikel adresseert de lacune in het begrijpen of LLM's dergelijke klassieke iteratieve algoritmen betrouwbaar kunnen uitvoeren, en onderzoekt hoe prompt-engineeringstrategieën (zoals gestructureerde invoer, chain-of-thought en few-shot voorbeelden) de prestaties op deze taken beïnvloeden.

Methodologie
De auteurs ontwierpen een gecontroleerde benchmark die drie LLM's evalueerde via vier verschillende promptformaten, gebruikmakend van een AC-vermogensstroomsysteem met drie bussen.

Systeem en Oplossingsmethode: De testomgeving is een volledig verbonden systeem met drie bussen (één slack-bus, twee PQ-laadbussen) met gerandomiseerde takparameters ( $R, X$ ) en laadwaarden. De referentieoplossingen werden numeriek berekend met Python (NumPy) met dubbele precisie-rekenkunde. De Gauss-Seidel-methode werd geselecteerd boven Newton-Raphson om de moeilijkheidsgraad van iteratieve rekenkunde te isoleren van de complexiteit van matrixfactorisatie, zodat de benchmark het vermogen van het model test om een bekend algoritmisch procedé te volgen.
Geëvalueerde Modellen:
1. Gemini 2.5 Pro (Google DeepMind)
2. Claude Sonnet 4.5 (Anthropic)
3. GPT-3.5 Turbo (OpenAI) als baseline met lagere capaciteit.
Promptformaten: Vier formaten werden getest om representatieve complexiteit te variëren:
1. Narratief-eindantwoord: Natuurlijke taalbeschrijving van het probleem (handboekstijl) waarbij alleen het eindantwoord wordt gevraagd.
2. Narratief + Voorbeeld: Dezelfde narratieven plus een volledig uitgewerkt voorbeeld uit een handboek.
3. Procedurale tekst: Een genummerde, stap-voor-stap procedure met opsommingstekens voor gegevens, waarbij een iteratietabel en het eindantwoord worden vereist.
4. Gestructureerde JSON: Machine-leesbare JSON-invoer met de geschreven procedure, waarbij dezelfde iteratietabel en het eindantwoord worden vereist.
Evaluatie: De benchmark werd uitgevoerd op 50 testcases, met een onafhankelijke replicatie van 100 cases. De metrieken omvatten de gemiddelde absolute fout (MAE) in MW/MVar en het percentage gevallen dat binnen specifieke relatieve foutklassen valt (<1%, 1–5%, 5–10%, 10–20%, >20%). Falen (niet-parsbare uitvoer) werd geteld in de foutklasse >20% om de betrouwbaarheid van end-to-end weer te geven.

Belangrijkste Bijdragen

Ontwerp van de Benchmark: Het artikel presenteert de eerste gecontroleerde studie die systematisch promptformaten varieert voor een klassiek iteratief AC-vermogensstroomoplosser, waarbij het algoritme en het testnetwerk constant worden gehouden.
Analyse van Promptgevoeligheid: De studie toont aan dat de effecten van prompt-engineering sterk modelafhankelijk zijn. Voor het meest capabele model (Gemini 2.5 Pro) leidde het vergroten van de promptcomplexiteit (van narratief naar gestructureerde JSON met iteratietraces) tot een significante verslechtering van de prestaties, waarbij de MAE met een factor 3,1× toenam. Omgekeerd leidde het toevoegen van een uitgewerkt voorbeeld tot een verslechtering van de prestaties van Gemini, maar bood het een marginale winst voor Claude.
Grenzen aan Capaciteit: De auteurs stellen vast dat geen enkele geteste configuratie voldoende betrouwbaarheid bereikte voor direct gebruik als numerieke oplosser. GPT-3.5 Turbo faalde op ten minste 90% van de gevallen in alle formaten, terwijl zelfs de best presterende configuratie (Gemini met een eenvoudig narratief prompt) slechts 54% van de gevallen binnen een relatieve fout van 5% behaalde.

Resultaten

Gemini 2.5 Pro: Toonde de breedste gevoeligheid voor het promptformaat. Het eenvoudigste formaat (narratief-eindantwoord) leverde de beste resultaten op (MAE = 0,257 MW/MVar; 54% van de gevallen binnen 5% fout). Het meest complexe formaat (gestructureerde JSON) resulteerde in de slechtste prestaties (MAE = 0,789). Het toevoegen van een uitgewerkt voorbeeld verhoogde de fout met 73%.
Claude Sonnet 4.5: Toonde een bijna vlak profiel voor nauwkeurigheid over alle formaten, met ongeveer 38% van de gevallen binnen 5% fout, ongeacht de promptstructuur. Het formaat 'procedurale tekst' presteerde iets beter voor Claude dan voor Gemini, wat suggereert dat optimale prompting modelspecifiek is.
GPT-3.5 Turbo: Toonde bijna totale inefficëntie, waarbij 90–96% van de gevallen in alle formaten een relatieve fout van meer dan 20% vertoonde.
Actief versus Blind Vermogen: Er werd een consistente asymmetrie waargenomen waarbij de fouten in blind vermogen ( $Q_g$ ) de fouten in actief vermogen ( $P_g$ ) voor de meeste configuraties overtroffen, mogelijk vanwege een minder frequente representatie van het extraheren van het imaginaire deel in de trainingsdata.
Replicatie: De replicatie van 100 cases bevestigde de kwalitatieve volgorde (Gemini $\gg$ Claude > GPT-3.5) en het ontbreken van oplosser-nauwkeurigheid. De optimale vorm voor Gemini verschuift echter van narratief naar procedurale tekst in de grotere steekproef, wat wijst op gevoeligheid voor de moeilijkheidsgraad van het voorbeeld of variabiliteit in de steekproef.

Betekenis en Beweringen
Het artikel concludeert dat LLM's, hoewel veelbelovend voor hoogwaardige nettaken (uitleg, vragen en antwoorden), momenteel niet beschikken over de betrouwbaarheid die vereist is voor directe numerieke berekening van vermogensstroom. De bevindingen daagt de gebruikelijke aanname in prompt-engineering uit dat het verstrekken van explicietere, gestructureerde instructies altijd de rekenkundige nauwkeurigheid verbetert; in dit domein leverden eenvoudigere prompts superieure resultaten op voor het best presterende model.

De auteurs positioneren dit werk als een diagnostische baseline voor practitioners en onderzoekers. De belangrijkste implicatie is dat het inzetten van LLM's voor besluitvormingsondersteuning in slimme netten een zorgvuldige kalibratie van promptformaten vereist op basis van het specifieke model, aangezien "gedetailleerdere prompting" contraproductief kan zijn. Bovendien stelt de studie dat huidige LLM-configuraties niet als vervanging voor traditionele numerieke oplossers in productiemilieus moeten worden gebruikt, hoewel ze kunnen dienen als hulpmiddelen voor benaderend redeneren of educatieve doeleinden.

De Opzet: Een Driestrooksweg

De Resultaten: Wie Geslaagd en Wie Gefaald?

De Grote Les: "Meer Instructies" ≠ "B betere Resultaten"

De Eindconclusie: Nog Niet Klaar voor de Grote Scherm

Meer zoals dit