We testten 6 AI-assistenten op dezelfde zonne-energiedata. De resultaten verbaasden ons

We zijn een functie aan het bouwen voor HelioPeak die we "Export voor AI-analyse" noemen. Het idee is eenvoudig: tik op een knop in de app, krijg een Markdown-bestand met je zonneproductiedata plus gedetailleerde instructies voor een AI-assistent, plak dat in de chatbot van je keuze, en krijg een analyse die meer waard is dan de som der delen. Geen HelioPeak-servers in de keten, geen vaste maandkost, geen privacy-theater, gewoon je data en de AI van jouw keuze.

Voor we ook maar één regel Swift-code voor deze functie schreven, wilden we het concept valideren op echte chatbots. Daarom hebben we een Python-prototype gebouwd dat hetzelfde exportbestand drie keer genereert, telkens met fijner afgestelde instructies, en hebben we elke versie getest op zes AI-assistenten. De export bevatte twee jaar dagelijkse productiedata, drie volle jaren aan jaartotalen, systeemmetadata, gebruikersnotities en een uitgewerkte prompt die de AI vroeg om een gestructureerde analyse van 14 secties te maken met antwoorden op 39 specifieke vragen.

Wat we vonden, gaf ons eerlijk gezegd een rood gezicht. Niet omdat de AI-assistenten slecht zijn (sommige zijn werkelijk indrukwekkend), maar omdat het verschil tussen het beste en het slechtste resultaat zo groot is dat twee gebruikers met hetzelfde zonnesysteem tot volledig verschillende conclusies kunnen komen, afhankelijk van welke chatbot ze toevallig gebruiken. Sommige assistenten verzonnen cijfers die niet in de data stonden. Andere beweerden dat het bestand was afgekapt terwijl dat niet zo was. Eén beloofde een PDF-rapport en leverde het nooit op. Een andere leverde een PDF die ontdaan was van elke vorm van vormgeving.

Dit artikel is het verhaal van die test. Het is deels een benchmark, deels een bekentenis hoe naïef we onze eerste prompt schreven, en deels, hopelijk, nuttig voor iedereen die zelf probeert een betrouwbare analyse uit een AI-assistent te halen op een niet-triviale dataset.

De opzet

De dataset onder test was een synthetische, maar realistische Belgische installatie van 5,7 kWp met een oost-west panelenverdeling en een 5 kW Fronius-omvormer, in werking sinds april 2018. Dagelijkse, maandelijkse en jaarlijkse productiegegevens van januari 2023 tot en met 23 mei 2026 waren ingebed als JSON-blokken in een Markdown-bestand, samen met verbruik en injectie/afname-data, een handvol gebruikersnotities en een aantal Solar Moments. Het totale bestand was in de grootste variant ongeveer 220 kB, ruwweg 55.000 tokens, ruim binnen de comfortzone van elk modern frontiermodel.

De prompt zelf was uitgebreid. Hij vroeg de AI om dertien analytische secties op te leveren in een bepaalde volgorde, antwoorden te geven op negenendertig specifieke vragen die varieerden van "wat is de productie sinds installatie" tot "wat zou er met het zelfconsumptiepercentage gebeuren als het gezin een EV toevoegt die 5 kWh per dag laadt", en optioneel een gebrand PDF-rapport te genereren als bonus. De instructies specificeerden de taal van het antwoord (Nederlands in onze tests), de munteenheid, en expliciete regels tegen verzonnen waarden of extrapolatie buiten de data.

We testten zes AI-assistenten op exact hetzelfde bestand: Anthropic's Claude (via claude.ai), OpenAI's ChatGPT (Plus-tier met Code Interpreter), Google's Gemini (Pro-tier), Google AI Studio (met code-uitvoering aan), Grok van xAI, en Copilot van Microsoft. In elk geval was de prompt aan de gebruikerszijde identiek: één Nederlandstalige zin die de assistent vroeg om het bestand te lezen en de instructies erin op te volgen.

Wat volgt is wat elk van hen ervan maakte. We hebben ze geordend van slechtste naar beste, omdat de manieren waarop ze faalden leerrijker zijn dan de successen.

Copilot: de verzonnen foutmelding

De respons van Microsoft Copilot was, volgens elke redelijke maatstaf, een totale mislukking. Maar het faalde op een manier die uiteindelijk het meest waardevolle losse datapunt van het hele experiment werd.

Toen Copilot het bestand kreeg, antwoordde het met een lange, beleefde paragraaf die uitlegde dat de export was gemarkeerd als IsTruncated="true" en dat het slechts een klein deel van de data kon zien. Het somde keurig op welke secties wel en niet zichtbaar waren, bood vriendelijk aan om een deelanalyse te doen op wat beschikbaar was, en vroeg de gebruiker om de rest van de data in meerdere delen na te sturen.

Het probleem met dat antwoord is dat niets ervan klopt. Het bestand is niet als afgekapt gemarkeerd. Er staat nergens een IsTruncated-attribuut in de export. Het volledige bestand werd aangeleverd, inclusief de expliciete markering ## End of export onderaan. Copilot verzon de beperking, verzon vervolgens de afkap-markering om die beperking te onderbouwen, en bood daarna een werkwijze aan om het verzonnen probleem op te lossen.

Dit is een schoolvoorbeeld van wat onderzoekers confabulatie noemen: een AI die een plausibel klinkend excuus genereert voor het eigen onvermogen om een taak uit te voeren, en dat excuus aankleedt met technische details om het overtuigend te laten klinken. Copilot wist niet hoe het een Markdown-bestand van 220 kB met ingebedde JSON moest verwerken, en in plaats van dat te zeggen, deed het alsof het bestand het probleem was.

Wat dit foutpatroon gevaarlijk maakt, is hoe overtuigend het overkomt. Een niet-technische gebruiker die het antwoord van Copilot leest, zou er rotsvast van overtuigd zijn dat de export was afgekapt. Die zou terug naar HelioPeak gaan, op zoek naar een instelling om het bestand kleiner te maken, of denken dat onze functie kapot was. Hij of zij zou nooit op het idee komen dat de AI een niet-bestaand probleem heeft verzonnen.

De oplossing aan onze kant, die we in de volgende versie van de prompt bakten, was bijna komisch botweg. We voegden een regel toe die zegt: "Dit bestand bevat GEEN IsTruncated-attribuut. Als je schrijft dat dat wel het geval is, hallucineer je." Het is bizar om dat in 2026 nog te moeten opschrijven, maar zo zit het.

Grok: de zelfverzekerde fictie

De Grok van xAI produceerde een analyse die er competent uitzag, met de juiste algemene structuur: een management summary, kerncijfers, jaar-op-jaar-deltas, seizoenspatronen, alles erop en eraan. De structuur klopte. De cijfers, op de meeste plekken, klopten ook. De problemen zaten in de details, en daar begon Grok dingen te verzinnen.

In het luik "top 5 beste dagen" vermeldde Grok "2026-05-23: 31,80 kWh (recent record)" als de derde beste dag in de dataset. Die regel bestaat niet. De daadwerkelijke top 5 beste dagen, die we zelf hebben geverifieerd door het bestand handmatig te doorlopen, vielen allemaal in juni 2024 of juni 2025, en de waarde voor 23 mei 2026 in het bestand lag een stuk lager dan 31,80 kWh. Grok had een getal verzonnen dat paste in het verhaal dat het aan het opbouwen was.

Elders beweerde Grok dat de zomer/winter-productieverhouding 3,08 was, terwijl drie van de vijf andere assistenten waarden tussen 3,79 en 5,08 berekenden op dezelfde data met dezelfde definitie. Het beweerde dat het zelfconsumptiepercentage "~34-40% (afhankelijk van scope)" was, een marge die zo breed is dat ze geen betekenis meer heeft. Het zei ons dat het specifieke rendement over de hele levensduur 3.005 kWh/kWp bedroeg, een getal dat ontstaat als je de levensduurproductie deelt door de systeemgrootte in kWp: rekenkundig juist, conceptueel fout (specifiek rendement is per jaar, niet per levensduur; de levensduurversie van dat getal heeft geen zinvolle vergelijkingsbasis).

De meeste van deze fouten zouden onzichtbaar zijn voor een niet-deskundige gebruiker. De getallen zitten in de juiste orde van grootte, het taalgebruik is vloeiend, en niets wijst erop dat er iets fout is. Dit is de gevaarlijkste categorie AI-output: zelfverzekerd, vloeiend, en deels verzonnen. We zouden veel liever hebben dat een chatbot zegt "dat kan ik niet berekenen" dan dat hij een plausibel maar fout antwoord verzint.

Om dit aan te pakken in v0.3 van onze prompt voegden we toe wat we de regel eerlijkheid boven volledigheid noemden, die in gewone taal zegt dat een gedeeltelijke maar eerlijke analyse nuttiger is dan een volledige maar verzonnen analyse. We zullen in de volgende iteratie zien of Grok dit ter harte neemt.

ChatGPT: het overhaaste huiswerk

ChatGPT Plus met Code Interpreter ingeschakeld deed iets dat ons verbaasde. Het gebruikte effectief Python. Het parste effectief de JSON. Het rekende de metrics effectief uit. Het produceerde de juiste cijfers voor bijna alles: 17.131 kWh sinds installatie, 5.091 kWh gemiddelde per volledig jaar, 35,1% zelfconsumptie, 57 dagen klippen. De financiële sectie omvatte zelfs beide perspectieven die we hadden gevraagd: het formule-strikte zicht dat een misleidend negatief getal oplevert, en de "ten opzichte van geen zonnepanelen"-vergelijking die het reële voordeel toont.

En toen het op het echte schrijven van de analyse aankwam, schakelde ChatGPT over op haastmodus. De antwoorden op de 39 specifieke vragen waren oneregelige samenvattingen zoals "Jaar-op-jaar wijziging berekend" zonder dat de berekende waarden er ook effectief bij stonden, ook al had het die net berekend. Het was alsof een leerling het huiswerk correct had opgelost en dan enkel een inhoudstafel inleverde.

De PDF was nog erger. ChatGPT genereerde een document van vier pagina's in standaard Helvetica op een witte achtergrond, met sectietitels in vlak zwart, geen logo, geen marineblauwe gradiëntcover, geen oranje accentkleur, geen hero-cijfertegel, geen footerstijl. Geen enkel van de vijf verplichte HelioPeak-signatuurelementen die we in de prompt hadden gespecificeerd, was aanwezig. De PDF zag eruit als de output van het "hello world"-voorbeeld van reportlab.

Dit is een interessant foutpatroon, want het model had het duidelijk beter kunnen doen. De instructies waren gedetailleerd. De huiskleuren stonden in een tabel uitgeschreven. Het logo was als inline SVG ingebed. De stijlrichtlijnen waren expliciet. ChatGPT koos er gewoon voor om de inspanning niet te leveren. Een generieke PDF genereren is rekenkundig goedkoper dan een custom multi-pagina branded layout implementeren met gradiënten en signatuurelementen, en ChatGPT optimaliseerde voor goedkoop.

We pakten dit aan in v0.3 door een PDF-checklist bij oplevering toe te voegen: een lijst van 5 brand-identity-elementen die aanwezig moeten zijn vóór oplevering. Als één element ontbreekt, instrueert de prompt de AI om de PDF over te slaan en dat eerlijk te melden, in plaats van een generieke versie op te leveren. Of dit in de praktijk werkt, hangt ervan af of de AI bereid is het zwaardere werk te doen of gewoon het lichtere werk weigert.

Gemini Pro: van eerlijke skip naar volledige levering

De Gemini Pro van Google leverde wat we een grondig competente analyse zouden noemen, vanaf de allereerste ronde. Alle dertien secties aanwezig en inhoudelijk. Alle negenendertig vragen beantwoord met concrete getallen waar de data dat toeliet. De financiële sectie was uitstekend uitgewerkt, met zowel de formule-strikte zienswijze als de "ten opzichte van geen zonnepanelen"-vergelijking, helder gepresenteerd en gelabeld met welke van de twee het echte voordeel voor de huiseigenaar weergaf. De zomer/winter-verhouding, het specifieke rendement, het zelfconsumptiepercentage, allemaal in dezelfde orde van grootte als onze manuele referentieberekening.

De analyse van het klippen was bijzonder goed. Gemini schatte 50 tot 80 klipdagen per jaar met een financiële impact van €15 tot €25 jaarlijks, en voegde de bedenking toe dat een omvormer-upgrade economisch niet rationeel zou zijn aan de huidige terugleververgoeding. Dat soort contextuele oordeel, bovenop de ruwe berekening, is precies wat we van de AI verwachtten als toegevoegde waarde voor het begrip van de gebruiker.

In de eerste drie rondes sloeg Gemini de PDF-bonus consistent en eerlijk over. De paragraaf "Capabilities" bovenaan zou dan zeggen "PDF-generatie is beperkt in deze omgeving, dus ik focus op een volledige tekstanalyse en sla de PDF-bonus over." Dat was al het juiste gedrag: liever een uitstekende tekstanalyse leveren en eerlijk de PDF overslaan, dan een goede analyse met een ondermaatse PDF afleveren.

In de vierde ronde, met de single-source-of-truth-instructie ingebakken en de herstructurering van het narratief waardoor de Q&A-druk wegviel, veranderde er iets. Gemini leverde ook de PDF: elf pagina's, alle vijf HelioPeak-signatuurelementen aanwezig (marineblauwe gradiëntcover, ingebed logo met intacte gradiënten, oranje accent op titels en paginanummers, footer op elke pagina, hero-cijfertegel), elk getal in de PDF kwam tot op de cent overeen met de Markdown-analyse. Het ging zelfs correct om met de CO₂-subscript-typografie (iets waar Claude's eerdere output zich nog voor had moeten verontschuldigen). We hadden niets veranderd aan onze PDF-instructies tussen v0.3 en v0.4; het verschil zat er waarschijnlijk in dat de code-uitvoering van Gemini was geüpdatet om beter bestanden te kunnen wegschrijven, of dat onze geherstructureerde prompt simpelweg minder cognitieve belasting opleverde. In elk geval promoveerde Gemini Pro zichzelf van "eerlijke skip" naar een sterke tweede plaats.

Google AI Studio: de frustrerende bijna-raak

Als je de zes chatbots zou rangschikken puur op de kwaliteit van de tekstanalyse, zou Google AI Studio ongeveer eerste eindigen. Het was met een kleine marge het grondigst, met concrete getallen achter elke uitspraak. De klip-inschatting was een precieze "38 dagen per jaar, ~45 kWh, €7,85 verloren" in plaats van een vage marge. De oost-west string-balansanalyse (een van onze nieuwere vragen) gaf een specifieke lezing van "48% van de piekmomenten vóór 12:00, 52% erna" die we bij geen enkel ander model hadden gezien. De validatie van de Solar Moments verifieerde correct dat de mijlpaal "10.000 kWh sinds installatie" op 12 april 2024 consistent was met de cumulatieve productie sinds 2018.

En toen, aan het einde van het antwoord, schreef het: "Ik genereer nu het PDF-bestand 'HelioPeak_Analysis_Report_20260523.pdf' met de navy-gold cover, het logo en alle bovenstaande KPI's. U kunt dit bestand binnen enkele seconden downloaden."

Er verscheen geen bestand. Niet binnen enkele seconden, niet binnen enkele minuten, nooit. AI Studio kan geen bestandsartefacten leveren binnen zijn chat-UI (een beperking van de runtime, niet van het model), maar in plaats van dat vooraan in de sectie "Capabilities" te zeggen, schreef het model een beschrijving van wat de PDF zou bevatten, en daarna gebeurde er niets meer.

Dit is een ander foutpatroon dan ChatGPT's "goedkope PDF" of Gemini's "eerlijke skip". AI Studio beloofde een PDF en gaf vervolgens geen krimp meer. De gebruiker blijft achter, op zoek naar een downloadlink die niet bestaat, en vraagt zich af of het model nog bezig is, of er ergens geklikt moet worden, of dat er iets aan de eigen kant misging. De briljante analyse die eraan voorafging, wordt deels ondergraven door de gebroken belofte die volgt.

De fix in v0.3 was om de capability-check uit te breiden van "kun je PDF-bestanden produceren" naar "kun je PDF-bestanden produceren EN ze als downloadbare artefacten in deze chat afleveren". We zullen in de volgende ronde zien of AI Studio dit onderscheid respecteert.

Claude: de data-detective

De Claude van Anthropic leverde wat we sindsdien beschouwen als de gouden standaard voor deze taak. De tekstanalyse was grondig, precies en goed gestructureerd. De PDF was prachtig gebrand, met de marineblauwe gradiëntcover, het ingebedde HelioPeak-logo, de oranje accentkleur consistent gebruikt voor sectiekoppen en paginanummers, en de hero-cijfertegel in goudgradiënt. Elk van onze vijf verplichte signatuurelementen was aanwezig.

Maar het meest interessante deel van Claude's antwoord was niet de analyse zelf. Het was wat Claude na de analyse deed. In een sectie met als titel "Reflectie als test van je Tier 1 export" gaf de AI ons feedback op het exportbestand zelf, signaleerde problemen in de data en stelde verbeteringen voor aan ons prompt-ontwerp. Twee van die suggesties leidden tot v0.2 van de prompt: een expliciete nota over welke data-array je moet gebruiken voor welk soort metric, en de eis om twee financiële perspectieven naast elkaar te tonen. We komen later in dit artikel terug op een derde bevinding, een die uiteindelijk een vals alarm bleek maar daarom niet minder leerzaam was.

Dit is het argument voor het gebruik van een high-end frontier-AI voor dit soort werk: niet alleen beter geformatteerde output, maar werkelijk een betere samenwerker die terugduwt op je data wanneer daar reden toe is.

Het divergentieprobleem tussen modellen

De ene meest ongemakkelijke vaststelling uit onze eerste ronde was hoezeer de cijfers tussen de modellen onderling uiteenliepen, zelfs op metrics die eenduidig hadden moeten zijn. Hier vijf metrics berekend door de vijf modellen die effectief de analyse hebben gemaakt (Copilot uitgesloten, want dat probeerde het niet eens):

De getallen voor het specifieke rendement liggen dicht bij elkaar omdat de formule eenduidig was en in onze instructies stond: totale jaarlijkse kWh gedeeld door geïnstalleerde kWp. Elk model dat de moeite nam om dit te berekenen, kwam tot op afrondingsverschillen na op hetzelfde antwoord uit.

De zelfconsumptiecijfers liggen dicht bij elkaar om dezelfde reden: de formule was rechtlijnig en de inputdata waren eenduidig.

De andere drie liepen uiteen omdat we slordig waren geweest met de definities. We zegden de AI om de "zomer/winter-verhouding" te berekenen zonder te preciseren of dat (som van juni + juli + augustus over alle jaren) gedeeld door (som van december + januari + februari over alle jaren) betekent, of (gemiddelde van de zomermaandtotalen) gedeeld door (gemiddelde van de wintermaandtotalen), of nog iets anders. Verschillende modellen kozen verschillende interpretaties, en de resultaten verschilden met een factor 1,65.

Idem voor klipdagen: we zegden "tel de dagen waarop het piekvermogen het plafond van de omvormer benadert" zonder "benadert" te definiëren. Sommige modellen gebruikten 99% van het plafond, andere 95%, weer andere noemden elke dag met peak_w ≥ 4900 W een klipdag. Drie verschillende drempels, drie verschillende totalen.

En de conversie van CO₂ naar kilometers hangt volledig af van welke waarde je gebruikt voor de uitstoot van een typische benzinewagen. Wij specificeerden geen waarde. De modellen kozen ergens tussen 0,10 en 0,20 kg CO₂ per kilometer op basis van wat ze in hun trainingsdata hadden zitten, en de equivalentie varieerde navenant.

De les is hard maar nuttig: als je consistente cijfers wilt over alle AI-assistenten heen, kun je hen niet alleen zeggen wat ze moeten berekenen. Je moet hen vertellen hoe ze het exact moeten berekenen, tot op de constantes na. We voegden een sectie toe aan onze export die we de "Berekeningsbijlage" noemden, met daarin de formule en de constantes voor elke metric waar de modellen waren afgeweken. Twaalf formules lang. Zes voorbeelden:

De fix werkte. En dan ook weer niet.

We draaiden de test opnieuw met de Berekeningsbijlage erin. Het resultaat, op de metrics die voorheen uiteenliepen, was indrukwekkend:

Vijf van de zes geteste LLM's produceren nu identieke getallen op vier van de vijf betwiste metrics. De vijfde (klipdagen) varieert nog steeds omdat verschillende modellen de drempel anders afronden, maar de spreiding kromp van 2,1× naar 1,4×. We zouden dat ook nog kunnen oplossen met nog explicietere formule-instructies, maar op een bepaald punt weegt de kost in promptlengte niet meer op tegen de marginale precisiewinst.

Het structurele probleem van LLM-divergentie is dus in essentie opgelost. Maar drie nieuwe foutpatronen doken op die we niet hadden voorzien, en één daarvan leerde ons iets fundamenteels over hoe we naar LLM-output hadden gekeken.

De Q&A-val: zelfs goede output kan aanvoelen als huiswerk

Onze prompt vroeg de AI om 39 specifieke vragen te beantwoorden. We zagen die als een kwaliteitscontrolemechanisme: ze zorgden ervoor dat de analyse al het terrein bestreek dat we wilden, en gaven ons iets concreets om de output op te beoordelen. We hadden niet echt nagedacht over hoe de AI de antwoorden zou presenteren.

Wat we kregen, bij elk model dat de taak goed aankon, was een lange sectie "Specifieke vragen beantwoord" aan het einde van elke analyse, opgemaakt als een genummerde Q&A-lijst. Soms honderd regels van "V1: ... A1: ...". Zelfs Claude, dat overall de beste analyse produceerde, gaf ons deze structuur.

Toen we deze rapporten terug doorlazen, beseften we dat ze aanvoelden als examenantwoorden, niet als de analyse die een consultant zou schrijven. De vloeiende management summary bovenaan ging soepel over in een jaar-op-jaar-bespreking, in seizoenspatronen, in beste en slechtste dagen, en stopte dan abrupt in een lang blok met antwoorden van één regel. Het eerste deel las als een analyse, het tweede deel als een huiswerkchecklist die werd afgevinkt.

Dit was onze fout, niet die van de AI. We hadden zowel een narratieve analyse van 14 secties EN een Q&A met 39 vragen gevraagd, en de meeste AI's leverden exact wat we vroegen, wat het verkeerde was.

De fix was om de vragen rechtstreeks in de 14 secties te integreren, als "onderwerpen om te dekken"-lijsten ingebed binnen de prosa-instructies van elke sectie. Dus in plaats van dat sectie 7 zou zeggen "Afwijkingen en periodes van onderprestatie" en dan later vraag 11 zou vragen "kwantificeer het klipverlies", leest sectie 7 nu:

7. Afwijkingen, datakwaliteit en gedrag van de omvormer. Prosa-sectie. Behandel: aanwezigheid en kwantificering van het klippen van de omvormer (tel dagen waar peak_w ≥ 0,98 × inverter_W, schat het energieverlies in op basis van 1,5 kWh per klipdag, schat de financiële impact); aanwezigheid van plotse meerdaagse dipjes met mogelijke oorzaken; verificatie dat de Solar Moments consistent zijn met de productiedata …

En de kritische regels verbieden nu expliciet de Q&A-opmaak:

Maak het rapport NIET op als een genummerde Q&A-lijst. Presenteer antwoorden niet als "V1: ... A1: ...", herhaal de onderwerpenlijsten niet letterlijk, verzamel geen "overgeslagen vragen" aan het einde. Het rapport moet lezen als een vloeiende analytische nota.

Dit is een les met brede toepassing, ver buiten zonne-energiedata: de structuur van je prompt wordt de structuur van de output. Als je een AI een genummerde checklist geeft, krijg je een respons met een genummerde checklist. Als je een narratieve briefing geeft, krijg je een narratief. De vragen zijn belangrijk, maar hoe je ze inbedt, bepaalt of het rapport aanvoelt als analyse of als huiswerk.

De PDF die over zichzelf loog

Een ander foutpatroon kwam aan het licht in de tweede testronde, en dit was specifiek voor ChatGPT.

ChatGPT gebruikte nu correct Python om zijn analyse uit te rekenen. Het Markdown-rapport dat het opleverde was accuraat: €444,51 levenslange terugleveropbrengst, €1.865,67 besparing door zelfconsumptie, alles consistent met onze referentieberekening. En vervolgens genereerde het een PDF.

De PDF vermeldde €888,53 terugleveropbrengst en €1.031 besparing door zelfconsumptie.

Twee verschillende getallen voor dezelfde metric, van hetzelfde model, in dezelfde chatsessie, beide gepresenteerd alsof het de definitieve waarde was. De gebruiker opent het Markdown-rapport en de PDF naast elkaar, en leest het financiële plaatje van twee verschillende zonnesystemen, elk gepresenteerd op gezaghebbende toon. Dit is erger dan geen PDF. Het ondermijnt het vertrouwen actief.

Wat er zo goed als zeker gebeurde, is dat de code interpreter van ChatGPT de analyse heeft gedraaid in één Python-sessie en daarna een verse sessie heeft gestart om de PDF op te bouwen, waarbij andere standaard tariefveronderstellingen werden geïmporteerd. Het model heeft geen besef dat "de Markdown-analyse gebruikte €0,04 terugleververgoeding en de PDF gebruikte €0,08", beide sessies zagen een coherente berekening, alleen met andere input. Het model heeft geen geheugen om zich te herinneren dat het zich eerder al had vastgepind op één set cijfers.

We pakten dit aan met een expliciete single-source-of-truth-instructie in de prompt:

De getallen in de PDF MOETEN uit DEZELFDE berekende waarden komen die de tekstanalyse onderbouwen. Ze mogen niet onafhankelijk herberekend worden. Na de "Compute"-fase van je werkstroom, sla je ELKE metric op in één enkel dict of namespace (bijvoorbeeld metrics = {...}). De prosa-schrijver leest uit metrics["lifetime_kwh"]. De PDF-builder leest uit metrics["lifetime_kwh"]. Bereken nooit opnieuw wat je al hebt uitgerekend.

Of dit specifiek bij ChatGPT werkt, valt nog te zien. De instructie vraagt het model in essentie om zijn eigen toestand te beheren over twee fases van een meerstaps-taak, wat exact het ding is waar moderne LLM's het zwakst in zijn. We zullen misschien moeten aanvaarden dat de PDF's van ChatGPT onbetrouwbaar zijn, of de PDF-functie voor dat specifieke model laten vallen. Claude daarentegen verwerkte dit perfect bij de eerste poging: de PDF van 11 pagina's bevatte doorheen getallen die identiek waren aan de Markdown-analyse, omdat het effectief een coherente rekentoestand vasthoudt over een lange taak.

Claude's detectivewerk, herbekeken

Eén observatie uit de tweede ronde van Claude verdient een extra licht, omdat ze zowel de kracht als het zwakke punt toont van het gebruik van een AI als data-detective.

In zijn analyse signaleerde Claude wat het drie inconsistenties in de Solar Moments noemde. De export bevatte vijf Solar Moments-mijlpalen: "10.000 kWh sinds installatie" op 12 april 2024, "5.000 kg CO₂ vermeden" op 30 september 2024, "Beste dag van 2024" op 14 juni, "7-jarig installatiejubileum" op 15 april 2025, en "20.000 kWh sinds installatie" op 22 augustus 2025.

Claude merkte correct op dat drie van die mijlpalen niet kloppen met de data in de export. De jaarlijkse array begint in januari 2023, en tegen 12 april 2024 toont die slechts 6.467 kWh geproduceerd, niet de 10.000 die de mijlpaal claimt. Tegen 30 september 2024 toont de export ongeveer 8.500 kWh geproduceerd, wat ongeveer 4.000 kg vermeden CO₂ impliceert, niet 5.000. Tegen 22 augustus 2025 toont de export ongeveer 14.200 kWh, niet 20.000.

Dit is scherp data-forensisch werk. Claude haalde de cumulatieve productie uit de jaarlijkse array en merkte de discrepantie op. We waren initieel onder de indruk genoeg om dit als kandidaat-defect aan onze iOS-bugtracker toe te voegen.

Maar toen herlazen we het systeemprofiel, dat als installatiedatum 15 april 2018 vermeldt. Het systeem produceert al acht jaar zonne-energie; de export bevat enkel de laatste drie jaar. De "ontbrekende" 5.000 à 6.000 kWh die nodig is om de mijlpalen kloppend te maken, is exact de productie van 2018 tot en met 2022 die simpelweg niet in deze export zit. De Solar Moments lezen uit een langere historiek (waarschijnlijk het levenslange totaal van PVOutput zelf), terwijl de jaarlijkse array de subset is die HelioPeak in cache heeft.

Dit is geen bug. Dit is correct gedrag, alleen onvoldoende gedocumenteerd. De gebruiker ziet op zijn telefoon een mijlpaal "20.000 kWh sinds installatie" omdat zijn PVOutput-systeem die grens inderdaad gepasseerd is; het is alleen niet volledig binnen het venster van deze export gebeurd.

De les hier is tweezijdig. Aan de ene kant is het vermogen van Claude om dit soort inconsistenties in seconden te vinden ongelooflijk waardevol. Het is precies het soort datakwaliteitsalarm dat een exporter zou moeten horen, ook al bleek het in dit geval een vals alarm. Aan de andere kant was Claude zelfzeker in zijn diagnose, en een minder voorzichtige ontwikkelaar (wij, in eerste instantie) zou uren hebben besteed aan het zoeken naar een onbestaande timezone-bug in iOS-code. AI is een briljante data-detective, maar hij weet niet wat hij niet weet: hij kan niet verder kijken dan de data die je hem geeft. De installatiedatum van de gebruiker stond gewoon in de header van de export; Claude legde alleen de link met de conclusie niet.

We pakten dit aan door een expliciete nota toe te voegen aan de header van de export ("Scope Solar Moments: mijlpalen kunnen verwijzen naar cumulatieve productie van vóór de startdatum van de jaarlijkse array") en een expliciete regel in de kritische regels ("markeer een mijlpaal enkel als inconsistent als het systeem werd geïnstalleerd NA de start van de jaarlijkse array"). Toekomstige Claude-runs zouden dit valse alarm moeten overslaan.

Capaciteit versus inzet: het echte spectrum

Voor dit experiment verdeelden we AI-assistenten naïef in "goede" (verondersteld goed te zijn in gedetailleerde taken) en "slechte" (verondersteld zwak te zijn). Wat we in werkelijkheid vonden was een tweedimensionaal spectrum: capaciteit versus inzet.

Sommige modellen hebben hoge capaciteit maar lage bereidheid om inzet te tonen. ChatGPT in onze test was daar een helder voorbeeld van: de Code Interpreter is echt krachtig, het model kan duidelijk een complexe prompt begrijpen, en toch voelde de uiteindelijk geleverde output haastig en onvolledig aan. Het model koos ervoor minder werk te doen dan het kon.

Andere modellen hebben een lagere ruwe capaciteit maar leveren meer inzet ten opzichte van hun plafond. Gemini Pro voelde zo aan: niet altijd de slimste, maar consistent eerlijk over wat het wel of niet kon, en consistent bereid om op vraag de volledige structuur uit te schrijven.

Een klein aantal modellen scoort hoog op beide assen. Claude voelde in onze test aan als een bereidwillige samenwerker die ook nog eens scherp bleek te zijn. Het feit dat het ons ongevraagde kritiek gaf op het exportbestand zelf, was een teken. Dat is wat een bekwame, betrokken collega doet.

En dan zijn er nog de gevallen linksonder in het kwadrant: lage capaciteit, lage inzet, beide gemaskeerd door zelfverzekerd taalgebruik. Copilot en Grok pasten in onze test allebei in dit patroon, al falen ze anders. Copilot verzint externe excuses ("het bestand is afgekapt"), terwijl Grok interne inhoud verzint (een topdag die niet bestaat).

Onze huidige aanbeveling

Als je de functie "Export voor AI-analyse" van HelioPeak gaat gebruiken wanneer die uitkomt, is onze rangschikking per 23 mei 2026, na vier testrondes met de definitieve v0.4-prompt:

1. Claude (op claude.ai): duidelijk de beste in algemene zin. Gouden standaard tekstanalyse, onberispelijke gebrande PDF, vindt echte datakwaliteitsproblemen in de export zelf. Als je maar één assistent probeert, probeer dan deze.
2. Gemini Pro: sterke tweede. Narratieve analyse, eerlijk over zijn grenzen in de eerdere rondes, maar leverde in de laatste ronde een volledig gebrande PDF met consistente cijfers. Een echt alternatief voor Claude.
3. Google AI Studio: de beste tekstuele diepgang op de data, maar kan geen bestanden afleveren binnen de chatinterface. Nuttig als je de analyse wil kopiëren en plakken, maar niet als je een PDF nodig hebt.
4. ChatGPT Plus met Code Interpreter: correcte cijfers in de analyse, maar produceert PDF's waarvan de cijfers niet altijd overeenkomen met de analyse. Bruikbaar als je enkel de tekst nodig hebt.
5. Grok: output die er competent uitziet, maar controleer de cijfers zelf. We zagen verzonnen waarden in onze tests.
6. Copilot: op dit moment niet geschikt voor deze taak. Beweert dat het bestand is afgekapt terwijl dat niet zo is, en biedt een oplossing aan voor een probleem dat niet bestaat.

Als je maar tijd hebt om één assistent te proberen, is ons concrete advies om te starten met Claude op claude.ai. De combinatie van analytische diepgang, bereidheid om vragen te stellen bij de datakwaliteit en een betrouwbaar gebrande PDF-output maakt Claude in onze tests de duidelijke leider. Gemini Pro is een geloofwaardig alternatief, zeker sinds de upgrade in de laatste ronde. De andere assistenten hebben hun sterke kanten, maar voor deze specifieke taak (gestructureerde analyse van een matig grote dataset met een gebrande PDF als deliverable) is het verschil tussen Claude en de rest reëel.

Belangrijke kanttekening: dit is een momentopname. AI-assistenten veranderen wekelijks. Het model achter ChatGPT vandaag kan binnen een maand een ander model zijn, met andere sterke punten. Anthropic, OpenAI, Google, xAI en Microsoft pushen allemaal grote upgrades op cycli van weken tot kwartalen. Tegen de tijd dat je dit leest, kan de rangschikking verschoven zijn, soms aanzienlijk. Als je belang hecht aan de beste output, loont het om je favoriete assistent om de paar maanden te hertesten op een gekende referentietaak.

Onze rangschikking is ook specifiek voor deze ene taak: gestructureerde analyse van een matig grote, goed geformatteerde dataset met expliciete instructies. Voor chatconversatie, codegeneratie, creatief schrijven of webresearch zou de volgorde vrijwel zeker anders zijn.

Wat dit betekent voor prompt design

Vier iteraties hebben onze prompt substantieel veranderd. Elke wijziging werd ingegeven door een specifiek foutpatroon dat we hadden waargenomen:

Ten eerste maakten we de prompt agressief op het vlak van capability checks. Het allereerste wat we de AI nu vragen, is om te verifiëren dat hij het volledige bestand heeft ontvangen (door te zoeken naar onze expliciete eindmarker), te bevestigen of hij over code-uitvoering beschikt, en te bevestigen of hij PDF-bestanden zowel kan genereren als afleveren. Dit vangt confabulatie in Copilot-stijl vroeg op en dwingt modellen zoals Google AI Studio om vooraf te verklaren dat ze geen bestanden kunnen afleveren.

Ten tweede maakten we de prompt agressief over berekening, niet schatting. De oorspronkelijke prompt suggereerde beleefd dat de AI "Python kon gebruiken indien beschikbaar". De huidige prompt zegt expliciet: schat of benader nooit een getal als je het kunt berekenen. De data in dit bestand is precies; jouw analyse moet dat ook zijn. We onderbouwden dit met expliciete formules in een Berekeningsbijlage, zodat er geen onduidelijkheid is over hoe iets te berekenen.

Ten derde voegden we een eerlijkheidsregel toe: liever een gedeeltelijke maar eerlijke analyse dan een complete maar verzonnen analyse. Dit is de regel die, als hij werkt, fictie in Grok-stijl zou moeten onderdrukken en haastige PDF's in ChatGPT-stijl zou moeten omzetten naar eerlijke skips.

Ten vierde herstructureerden we de prompt zodat de 39 specifieke vragen ingebed zijn als onderwerpen binnen de 14 narratieve secties, in plaats van een aparte Q&A-lijst aan het einde. Dit was de les met de breedste toepassing: de structuur van je prompt wordt de structuur van de output. Als je een vloeiende analyse wil, moet je vragen om een vloeiende analyse, niet om een checklist.

En ten vijfde voegden we een single-source-of-truth-regel voor de PDF toe: elk getal in de PDF moet uit dezelfde berekende dict komen die ook de Markdown-analyse onderbouwt, en mag nooit opnieuw berekend worden. Dit vraagt de AI in essentie om toestand te beheren over twee fases van een complexe taak, wat oprecht moeilijk is voor huidige modellen, maar het maakt op zijn minst zichtbaar wanneer het fout gaat.

Niets van dit alles zou voor ons zichtbaar geweest zijn zonder de test te draaien: vier keer, met dezelfde dataset, met dezelfde zes modellen, met telkens preciezer geformuleerde instructies. De eerste versie van onze prompt was, volgens elke redelijke interne review, een grondige en goed doordachte instructieset. Het was pas toen we zes verschillende AI-assistenten zes verschillende output van wild uiteenlopende kwaliteit zagen produceren, en die output zagen verbeteren bij elke iteratie, dat we begrepen hoeveel van de prompt impliciete veronderstelling was in plaats van expliciete instructie.

De bredere les, voor iedereen die AI op echte data gebruikt

Als je geen app aan het bouwen bent en je gewoon af en toe een CSV in ChatGPT droppt om die te laten samenvatten, is dit artikel waarschijnlijk niet voor jou. De prompt met 39 onderwerpen, gebrande PDF en meerlagige opbouw die wij voor HelioPeak bouwden, is overdreven voor losse analyses. Maar er zijn vier principes uit onze test die volgens ons veralgemeenbaar zijn naar elk serieus gebruik van AI op echte data.

Principe één: zeg de AI exact wat te berekenen, inclusief de constantes. "Wat is de koolstofimpact van mijn zonneproductie" is te open. "Bereken totale vermeden CO₂ aan de hand van een factor 0,467 kg per kWh, druk dit vervolgens uit in km-equivalent voor de wagen uitgaande van 120 g CO₂ per km, in equivalent volwassen bomen uitgaande van 21 kg geabsorbeerd per boom per jaar, en in huishoudens-jaar-equivalent uitgaande van 1.635 kg CO₂ per EU-huishouden per jaar" geeft je hetzelfde antwoord uit elk model.

Principe twee: dwing de AI om zijn capaciteiten vooraf te verklaren. Als je dat niet doet, zullen modellen vaak proberen taken te doen die ze niet kunnen afleveren, of taken weigeren die ze wel aankunnen. De voorafgaande check zet de verwachtingen aan beide kanten op scherp.

Principe drie: bouw een eerlijkheidsregel in. Zeg de AI direct dat je liever een gedeeltelijk eerlijk antwoord krijgt dan een compleet verzonnen antwoord. Het stopt niet alle hallucinatie, maar in onze tests verminderde het merkbaar het tempo waarmee modellen waarden uitvonden om hiaten op te vullen.

Principe vier: de structuur van je prompt wordt de structuur van de output. Als je vraagt om een narratief van 13 secties EN een Q&A van 39 vragen, krijg je beide, en de Q&A zal onhandig onderaan blijven hangen alsof het huiswerk is. Als je een vloeiende analyse wil, bed je je specifieke vragen in binnen de narratieve secties als "onderwerpen om te dekken" in plaats van als aparte lijst. De vragen blijven de zorgvuldigheid sturen; ze verdwijnen alleen in de prosa waar ze thuishoren.

Geen van deze principes is revolutionair. Ze duiken op in academische papers over prompt engineering, in de prompting guides van OpenAI en Anthropic zelf, in blogposts van mensen die dit voor hun beroep doen. Wat ons experiment toevoegde, is het empirische bewijs dat het toepassen van deze principes, op een echte taak met echte data, de outputkwaliteit van meerdere modellen merkbaar wijzigt.

Wat volgt

De functie "Export voor AI-analyse" komt in een toekomstige HelioPeak-release, nadat de iOS-code is geschreven, getest en door Apple gereviewd. Tegen de tijd dat je dit leest, kan ze al live zijn; raadpleeg de pagina met release notes voor de actuele status.

Wanneer ze beschikbaar komt, zal ze hetzelfde zelfvoorzienende Markdown-bestand produceren dat we hier hebben getest. Je zult dat in de AI-assistent van jouw keuze kunnen plakken. We zullen een FAQ-item publiceren met onze actuele modelaanbevelingen en een nota dat die aanbevelingen mettertijd kunnen verschuiven. We gaan je niet vastleggen op één assistent. We gaan je gewoon het meest bruikbare data-exportbestand geven dat we kunnen ontwerpen, en jij kiest waar je het naartoe stuurt.

We gaan deze test ook blijven herhalen. Elk kwartaal of zo halen we dezelfde export door de meest recente versie van elke grote AI-assistent, kijken hoe de rangschikking is verschoven en updaten dit artikel. AI evolueert te snel om een momentopname lang nuttig te laten blijven. De methodologie, de dataset en de prompt zijn stabiel; de assistenten niet. Dat is wat de benchmark interessant maakt.

Als we één conclusie kunnen trekken uit vier iteraties over een enkel weekend, is het deze: AI-assistenten zijn buitengewoon krachtige tools die op buitengewoon specifieke manieren falen. De manier waarop je die falingen aanpakt, is niet door van tool te wisselen of op te geven; ze ligt in het aanscherpen van je instructies tot elk faalpatroon verdwijnt. De Berekeningsbijlage loste de divergentie op. De capability-check loste (grotendeels) de confabulatie op. De narratieve herstructurering loste de huiswerk-format op. De single-source-of-truth-regel begon het PDF-verschil op te lossen. Elke fix afzonderlijk is klein, maar samen maken ze van een onbetrouwbare tool een nuttige samenwerker.

Als je iets soortgelijks aan het bouwen bent en je wil noten vergelijken over prompt design voor gestructureerde data-analyse, weet je waar je ons kunt vinden.

Dit artikel documenteert tests uitgevoerd op 23 mei 2026 over vier iteraties van ons prompt-ontwerp (v0.1 tot en met v0.4). De export-specificatie ligt nu vast op v0.4 en is klaar voor iOS-implementatie. De HelioPeak iOS-app voor het opvolgen van PVOutput.org-systemen is beschikbaar in de App Store.

Dit artikel werd in het Engels geschreven en met AI-ondersteuning vertaald. Lees het origineel in het Engels.

← Terug naar blog