Abbiamo testato 6 assistenti IA sugli stessi dati solari. I risultati ci hanno sorpresi

Stiamo sviluppando per HelioPeak una funzionalità che chiamiamo «Export per analisi IA». L'idea è semplice: un tocco su un pulsante nell'app, si ottiene un file Markdown con i propri dati di produzione solare e istruzioni dettagliate per un assistente IA, lo si incolla nel chatbot che si preferisce e si riceve un'analisi che vale più della somma delle sue parti. Nessun server HelioPeak nel mezzo, nessun abbonamento ricorrente, niente teatro sulla privacy, solo i propri dati e l'IA scelta.

Prima di scrivere anche una sola riga di Swift per questa funzionalità, volevamo validare il concetto su chatbot reali. Abbiamo quindi costruito un prototipo Python che genera lo stesso file di export in tre varianti, con istruzioni via via più affinate, e abbiamo testato ogni versione su sei assistenti IA. L'export conteneva due anni di dati giornalieri di produzione, tre anni interi di totali annuali, metadati di sistema, note utente e un prompt elaborato che chiedeva all'IA di produrre un'analisi strutturata in 14 sezioni, con risposte a 39 domande specifiche.

Ciò che abbiamo trovato, sinceramente, ci ha fatto arrossire. Non perché gli assistenti IA siano scarsi (alcuni sono davvero notevoli), ma perché lo scarto tra la migliore e la peggiore risposta è tale che due utenti con lo stesso impianto fotovoltaico potrebbero arrivare a conclusioni del tutto diverse a seconda del chatbot che capita di usare. Alcuni assistenti hanno inventato numeri assenti dai dati. Altri hanno affermato che il file era troncato, mentre non lo era. Uno ha promesso un report PDF e non lo ha mai consegnato. Un altro ha consegnato un PDF privo di qualsiasi traccia di design.

Questo articolo è il racconto di quel test. È in parte un benchmark, in parte una confessione sull'ingenuità del nostro primo prompt e in parte, ci auguriamo, utile a chiunque cerchi di ottenere un'analisi affidabile da un assistente IA su un dataset non banale.

L'impostazione

Il dataset sotto test rappresentava un impianto belga sintetico ma realistico da 5,7 kWp, con suddivisione dei pannelli est-ovest e un inverter Fronius da 5 kW, in funzione da aprile 2018. I dati di produzione giornaliera, mensile e annuale dal gennaio 2023 al 23 maggio 2026 erano inseriti come blocchi JSON in un file Markdown, insieme a dati di consumo, prelievo e immissione in rete, alcune note utente e una manciata di Solar Moments. La dimensione complessiva del file raggiungeva circa 220 kB nella variante più grande, all'incirca 55.000 token, ampiamente entro la zona di comfort di qualsiasi modello frontiera moderno.

Il prompt stesso era corposo. Chiedeva all'IA di consegnare tredici sezioni analitiche in un ordine preciso, rispondere a trentanove domande specifiche che spaziavano da «qual è la produzione cumulativa dall'installazione» a «come cambierebbe la percentuale di autoconsumo se la famiglia aggiungesse un veicolo elettrico che carica 5 kWh al giorno», e in opzione produrre un report PDF brandizzato come bonus. Le istruzioni precisavano la lingua della risposta (italiano nei nostri test), la valuta e regole esplicite contro valori inventati o estrapolazioni oltre i dati.

Abbiamo testato sei assistenti IA su esattamente lo stesso file: Claude di Anthropic (via claude.ai), ChatGPT di OpenAI (livello Plus con Code Interpreter), Gemini di Google (livello Pro), Google AI Studio (con esecuzione di codice attiva), Grok di xAI, e Copilot di Microsoft. In ogni caso il prompt lato utente era identico: una sola frase in italiano che chiedeva all'assistente di leggere il file e seguire le istruzioni al suo interno.

Quello che segue è ciò che ciascuno ne ha fatto. Li abbiamo ordinati dal peggiore al migliore, perché i modi in cui hanno fallito sono più istruttivi dei successi.

Copilot: l'errore fabbricato

La risposta di Microsoft Copilot è stata, per qualunque criterio ragionevole, un fallimento totale. Ma è fallita in un modo che si è rivelato il singolo dato più prezioso dell'intero esperimento.

Quando Copilot ha ricevuto il file, ha risposto con un lungo paragrafo cortese che spiegava che l'export era marcato come IsTruncated="true" e che riusciva a vedere solo una piccola porzione dei dati. Elencava ordinatamente quali sezioni erano visibili e quali no, offriva gentilmente di realizzare un'analisi parziale su ciò che era disponibile, e chiedeva all'utente di inviare il resto dei dati in più parti.

Il problema con questa risposta è che niente di tutto ciò è vero. Il file non è marcato come troncato. Nell'export non esiste alcun attributo IsTruncated. Il file completo è stato consegnato, compreso il marcatore esplicito ## End of export in fondo. Copilot ha inventato la limitazione, ha poi inventato il marcatore di troncamento per sostenere quella limitazione, e infine ha proposto una soluzione per il problema inesistente.

È un caso da manuale di ciò che i ricercatori chiamano confabulazione: un'IA che genera una scusa plausibile per la propria incapacità di portare a termine un compito, vestendo quella scusa di dettagli tecnici per renderla convincente. Copilot non sapeva come elaborare un file Markdown da 220 kB con JSON incorporato, e invece di ammetterlo ha fatto come se il file fosse il problema.

Ciò che rende pericoloso questo schema di errore è la sua forza persuasiva. Un utente non tecnico che legge la risposta di Copilot sarebbe assolutamente convinto che l'export fosse stato troncato. Tornerebbe in HelioPeak a cercare un'impostazione per ridurre la dimensione del file, o penserebbe che la nostra funzionalità sia rotta. Non gli verrebbe mai in mente che l'IA abbia inventato un problema dal nulla.

Il rimedio dal nostro lato, che abbiamo introdotto nella versione successiva del prompt, è quasi comicamente brutale. Abbiamo aggiunto una riga che dice: «Questo file NON contiene un attributo IsTruncated. Se scrivi che lo contiene, stai allucinando.» È strano doverlo ancora scrivere nel 2026, ma è così.

Grok: l'invenzione sicura di sé

Grok di xAI ha prodotto un'analisi che sembrava competente, con la giusta struttura generale: un riepilogo esecutivo, numeri chiave, scarti anno su anno, schemi stagionali, tutto al suo posto. La struttura era corretta. Anche i numeri, nella maggior parte dei casi, lo erano. I problemi stavano nei dettagli, ed è lì che Grok ha cominciato a inventare.

Nella sezione «top 5 giorni migliori», Grok ha indicato «2026-05-23: 31,80 kWh (record recente)» come terzo miglior giorno del dataset. Quella riga non esiste. I veri cinque giorni migliori, verificati da noi manualmente scorrendo il file, cadevano tutti in giugno 2024 o giugno 2025, e il valore del 23 maggio 2026 nel file era nettamente inferiore a 31,80 kWh. Grok aveva inventato un numero che si adattava al racconto che stava costruendo.

Altrove, Grok ha sostenuto che il rapporto estate/inverno della produzione fosse 3,08, mentre tre dei cinque altri assistenti hanno calcolato valori tra 3,79 e 5,08 sugli stessi dati con la stessa definizione. Ha annunciato una percentuale di autoconsumo «~34-40 % (a seconda dell'ambito)», una forbice così ampia da perdere significato. Ci ha detto che la resa specifica complessiva sulla vita utile era 3.005 kWh/kWp, numero che si ottiene dividendo la produzione di vita per la potenza in kWp: aritmetica corretta, concetto sbagliato (la resa specifica si misura per anno, non sulla vita utile; la versione «vita utile» di quel numero non ha un riferimento di confronto utile).

La maggior parte di questi errori sarebbe invisibile per un utente non esperto. Gli ordini di grandezza sono corretti, la lingua è fluente, e nulla segnala che qualcosa non quadra. È la categoria più pericolosa di output IA: sicura, fluente e in parte inventata. Preferiremmo di gran lunga che un chatbot dicesse «questo non lo posso calcolare» piuttosto che inventarsi una risposta plausibile ma sbagliata.

Per affrontare questo aspetto in v0.3 del nostro prompt, abbiamo aggiunto quella che chiamiamo la regola onestà prima della completezza, che in parole semplici dice che un'analisi parziale ma onesta è più utile di un'analisi completa ma inventata. Nell'iterazione successiva vedremo se Grok la prenderà a cuore.

ChatGPT: il compito fatto in fretta

ChatGPT Plus con Code Interpreter abilitato ha fatto una cosa che ci ha sorpresi. Ha effettivamente usato Python. Ha effettivamente parsato il JSON. Ha effettivamente calcolato le metriche. Ha prodotto i numeri corretti per quasi tutto: 17.131 kWh dall'installazione, 5.091 kWh di media per anno pieno, 35,1 % di autoconsumo, 57 giorni di clipping. La sezione finanziaria includeva persino entrambe le prospettive che avevamo richiesto: la visione strettamente formulare che produce un numero negativo fuorviante, e il confronto «rispetto a senza fotovoltaico» che mostra il beneficio reale.

E quando è arrivato il momento di scrivere davvero l'analisi, ChatGPT è passato in modalità affrettata. Le risposte alle 39 domande specifiche erano riassunti monoriga del tipo «Variazione anno su anno calcolata» senza i valori effettivamente calcolati, anche se li aveva appena calcolati. Era come se uno studente avesse risolto correttamente l'esercizio e consegnato solo l'indice.

Il PDF era persino peggio. ChatGPT ha generato un documento di quattro pagine in Helvetica standard su sfondo bianco, con titoli di sezione in nero piatto, senza logo, senza la copertina a gradiente blu navy, senza il colore d'accento arancione, senza il riquadro grande del numero in copertina, senza lo stile del piè di pagina. Nessuno dei cinque elementi di firma HelioPeak che avevamo specificato nel prompt era presente. Il PDF sembrava l'output «hello world» di reportlab.

È uno schema di errore interessante, perché il modello avrebbe chiaramente potuto fare meglio. Le istruzioni erano dettagliate. I colori del brand erano scritti in una tabella. Il logo era fornito come SVG inline. Le linee guida di stile erano esplicite. ChatGPT ha semplicemente scelto di non fare lo sforzo. Generare un PDF generico costa di meno, in termini computazionali, che implementare un layout su misura multipagina brandizzato con gradienti ed elementi di firma, e ChatGPT ha ottimizzato per il basso costo.

Abbiamo affrontato la cosa in v0.3 aggiungendo una checklist PDF alla consegna: una lista di cinque elementi di identità visiva che devono essere presenti prima della consegna. Se ne manca anche uno solo, il prompt istruisce l'IA a saltare il PDF segnalandolo onestamente, anziché consegnare una versione generica. Se funzionerà nella pratica dipende dalla disponibilità dell'IA a sostenere lo sforzo maggiore o a rifiutare semplicemente quello minore.

Gemini Pro: dal salto onesto alla consegna completa

Gemini Pro di Google ha consegnato fin dal primo round quella che definiremmo un'analisi rigorosamente competente. Tutte e tredici le sezioni presenti e sostanziali. Tutte e trentanove le domande con risposta numerica concreta dove i dati lo consentivano. La sezione finanziaria era ben curata, con la visione strettamente formulare e il confronto «rispetto a senza fotovoltaico» presentati con chiarezza e con l'etichetta che indicava quale dei due rappresentasse il beneficio reale del proprietario. Il rapporto estate/inverno, la resa specifica, la percentuale di autoconsumo, tutto nello stesso ordine di grandezza del nostro riferimento calcolato a mano.

L'analisi del clipping era particolarmente buona. Gemini ha stimato tra 50 e 80 giorni di clipping all'anno con un impatto finanziario di 15-25 € l'anno e ha aggiunto la considerazione che un upgrade dell'inverter non sarebbe stato economicamente razionale all'attuale tariffa di immissione. Questo tipo di giudizio contestuale, oltre al calcolo grezzo, è esattamente il valore aggiunto che ci aspettavamo dall'IA per la comprensione dell'utente.

Nei primi tre round, Gemini ha saltato il bonus PDF in modo coerente e onesto. Il paragrafo «Capabilities» in cima diceva «La generazione PDF è limitata in questo ambiente, quindi mi concentro su un'analisi testuale completa e salto il bonus PDF.» Era già il comportamento corretto: meglio consegnare un'eccellente analisi testuale e saltare onestamente il PDF, piuttosto che consegnare una buona analisi e un PDF mediocre.

Poi al quarto round, con l'istruzione single-source-of-truth in vigore e la ristrutturazione narrativa che aveva rimosso la pressione delle Q&R, qualcosa è cambiato. Gemini ha consegnato anche il PDF: undici pagine, tutti e cinque gli elementi di firma HelioPeak presenti (copertina a gradiente blu navy, logo incorporato con gradienti intatti, accento arancione su titoli e numeri di pagina, piè di pagina su ogni pagina, riquadro grande del numero), ogni numero del PDF corrispondeva al centesimo all'analisi Markdown. Ha persino gestito correttamente la tipografia del pedice CO₂ (cosa per cui un output precedente di Claude si era dovuto scusare). Non avevamo cambiato nulla nelle nostre istruzioni PDF tra v0.3 e v0.4; la differenza era probabilmente dovuta al fatto che il backend di esecuzione codice di Gemini era stato aggiornato per salvare meglio i file, o che il nostro prompt ristrutturato imponesse semplicemente meno carico cognitivo. In ogni caso, Gemini Pro è passato da «salto onesto» a un solido secondo posto.

Google AI Studio: il quasi-centro frustrante

Se si classificassero i sei chatbot esclusivamente sulla qualità dell'analisi testuale, Google AI Studio finirebbe primo o quasi. Era di pochissimo il più rigoroso, con numeri concreti dietro ogni affermazione. La sua stima del clipping era un preciso «38 giorni l'anno, ~45 kWh, 7,85 € persi» invece di una forbice vaga. L'analisi del bilanciamento delle stringhe est-ovest (una delle nostre domande più nuove) restituiva una lettura specifica di «48 % dei picchi prima delle 12:00, 52 % dopo», che non avevamo visto in nessun altro modello. La validazione dei Solar Moments verificava correttamente che il traguardo «10.000 kWh dall'installazione» del 12 aprile 2024 fosse coerente con la produzione cumulativa dal 2018.

E poi, alla fine della risposta, ha scritto: «Sto ora generando il file PDF 'HelioPeak_Analysis_Report_20260523.pdf' con la copertina navy-gold, il logo e tutti i KPI sopra. Potrai scaricare questo file tra pochi secondi.»

Nessun file è comparso. Non entro pochi secondi, non entro pochi minuti, mai. AI Studio non può consegnare artefatti di file all'interno della sua interfaccia di chat (limitazione del runtime, non del modello), ma invece di dirlo subito nella sezione «Capabilities», il modello ha scritto una descrizione di cosa avrebbe contenuto il PDF, e poi non è successo più nulla.

È uno schema di errore diverso dal «PDF economico» di ChatGPT o dal «salto onesto» di Gemini. AI Studio ha promesso un PDF e poi è andato in silenzio. L'utente resta lì, a cercare un link di download che non esiste, chiedendosi se il modello stia ancora lavorando, se debba cliccare da qualche parte, o se qualcosa sia andato storto dalla sua parte. La brillante analisi che precede viene parzialmente compromessa dalla promessa non mantenuta che segue.

Il rimedio in v0.3 è stato estendere la verifica delle capacità da «sai produrre file PDF» a «sai produrre file PDF E consegnarli come artefatti scaricabili in questa chat». Nel prossimo round vedremo se AI Studio rispetterà questa distinzione.

Claude: il detective dei dati

Claude di Anthropic ha consegnato quello che da allora consideriamo il riferimento per questo tipo di compito. L'analisi testuale era rigorosa, precisa e ben strutturata. Il PDF era splendidamente brandizzato, con la copertina a gradiente blu navy, il logo HelioPeak integrato, il colore d'accento arancione usato in modo coerente su titoli di sezione e numeri di pagina, e il riquadro grande del numero in gradiente dorato. Ognuno dei nostri cinque elementi di firma obbligatori era presente.

Ma la parte più interessante della risposta di Claude non era l'analisi in sé. Era ciò che Claude ha fatto dopo l'analisi. In una sezione intitolata «Riflessione come test del tuo export Tier 1», l'IA ci ha dato feedback sul file di export stesso, segnalando problemi nei dati e suggerendo miglioramenti alla progettazione del prompt. Due di quei suggerimenti hanno portato alla v0.2 del prompt: una nota esplicita su quale array di dati usare per quale tipo di metrica, e il requisito di mostrare due prospettive finanziarie affiancate. Torneremo più avanti in questo articolo su un terzo rilievo, che si è rivelato un falso positivo ma non meno istruttivo.

È l'argomento a favore dell'uso di un'IA frontiera di fascia alta per questo tipo di lavoro: non solo output meglio formattato, ma davvero un collaboratore migliore che ti contraddice sui tuoi dati quando ce n'è motivo.

Il problema della divergenza tra modelli

L'osservazione più scomoda del nostro primo round è stata quanto i numeri divergessero tra i modelli, anche su metriche che avrebbero dovuto essere univoche. Ecco cinque metriche calcolate dai cinque modelli che hanno effettivamente prodotto l'analisi (Copilot escluso, perché nemmeno ci ha provato):

I numeri della resa specifica sono vicini perché la formula era univoca ed esplicitata nelle nostre istruzioni: kWh annuali divisi per i kWp installati. Ogni modello che si è preso la briga di calcolarla è arrivato allo stesso risultato a meno di arrotondamenti.

I numeri di autoconsumo sono vicini per lo stesso motivo: formula lineare, dati di input univoci.

Gli altri tre sono divergiti perché siamo stati sciatti con le definizioni. Abbiamo chiesto all'IA di calcolare il «rapporto estate/inverno» senza precisare se significasse (somma di giugno + luglio + agosto su tutti gli anni) divisa per (somma di dicembre + gennaio + febbraio su tutti gli anni), oppure (media dei totali mensili estivi) divisa per (media dei totali mensili invernali), o qualcos'altro ancora. Modelli diversi hanno scelto interpretazioni diverse, e i risultati sono divergiti di un fattore 1,65.

Stesso discorso per i giorni di clipping: abbiamo detto «conta i giorni in cui la potenza di picco si avvicina al tetto dell'inverter» senza definire «si avvicina». Alcuni modelli hanno preso il 99 % del tetto, altri il 95 %, altri ancora hanno considerato giorno di clipping qualsiasi giorno con peak_w ≥ 4900 W. Tre soglie diverse, tre totali diversi.

E la conversione da CO₂ a chilometri dipende interamente dal valore usato per le emissioni di un'auto a benzina tipica. Noi non abbiamo specificato alcun valore. I modelli hanno scelto tra 0,10 e 0,20 kg CO₂ per chilometro in base a ciò che era nei loro dati di addestramento, e l'equivalenza è variata di conseguenza.

La lezione è dura ma utile: se si vogliono numeri coerenti su tutti gli assistenti IA, non si può dire loro solo cosa calcolare. Bisogna dire loro come calcolarlo esattamente, fino alle costanti. Abbiamo aggiunto al nostro export una sezione che chiamiamo «Appendice di calcolo», con la formula e le costanti per ogni metrica su cui i modelli erano divergiti. Dodici formule in totale. Sei esempi:

Il rimedio ha funzionato. E poi non più.

Abbiamo rilanciato il test con l'Appendice di calcolo. Il risultato, sulle metriche prima divergenti, era impressionante:

Cinque dei sei LLM testati producono ora numeri identici su quattro delle cinque metriche contese. La quinta (giorni di clipping) varia ancora perché i diversi modelli arrotondano la soglia in modo diverso, ma la dispersione è scesa da 2,1× a 1,4×. Potremmo risolvere anche questa con istruzioni di formula ancora più esplicite, ma a un certo punto il costo in lunghezza del prompt non compensa più il guadagno marginale di precisione.

Il problema strutturale della divergenza tra LLM è quindi, in essenza, risolto. Ma sono emersi tre nuovi schemi di errore che non avevamo previsto, e uno di essi ci ha insegnato qualcosa di fondamentale sul modo in cui guardavamo l'output di un LLM.

La trappola delle Q&R: anche un buon output può sembrare un compito

Il nostro prompt chiedeva all'IA di rispondere a 39 domande specifiche. Le consideravamo un meccanismo di controllo qualità: garantivano che l'analisi coprisse tutto il terreno desiderato e ci davano qualcosa di concreto su cui valutare l'output. Non avevamo davvero riflettuto su come l'IA avrebbe presentato le risposte.

Ciò che abbiamo ricevuto, per ogni modello capace di gestire bene il compito, era una lunga sezione «Domande specifiche con risposta» alla fine di ogni analisi, impaginata come elenco Q&R numerato. A volte cento righe di «D1: ... R1: ...». Persino Claude, che produceva la migliore analisi complessiva, ci ha consegnato questa struttura.

Rileggendo questi report, ci siamo resi conto che sembravano compiti d'esame, non l'analisi che scriverebbe un consulente. Il riepilogo esecutivo fluido in cima passava elegantemente alla discussione anno su anno, agli schemi stagionali, ai giorni migliori e peggiori, e poi si fermava bruscamente in un lungo blocco di risposte a una riga. La prima metà si leggeva come analisi, la seconda come una checklist di compito da spuntare.

Era colpa nostra, non dell'IA. Avevamo richiesto sia un'analisi narrativa in 14 sezioni SIA un Q&R in 39 domande, e la maggior parte delle IA ha consegnato esattamente ciò che avevamo chiesto, che era la cosa sbagliata.

Il rimedio è stato integrare le domande direttamente nelle 14 sezioni, come elenchi di «argomenti da coprire» annidati nelle istruzioni in prosa di ciascuna sezione. Così, anziché far dire alla sezione 7 «Anomalie e periodi di sottoperformance» e poi far chiedere più avanti alla domanda 11 «quantifica la perdita da clipping», la sezione 7 ora recita:

7. Anomalie, qualità dei dati e comportamento dell'inverter. Sezione in prosa. Trattare: presenza e quantificazione del clipping dell'inverter (conta i giorni con peak_w ≥ 0,98 × inverter_W, stima la perdita energetica su base 1,5 kWh per giorno di clipping, stima l'impatto finanziario); presenza di cali pluri-giornalieri improvvisi con possibili cause; verifica che i Solar Moments siano coerenti con i dati di produzione …

E le regole critiche ora vietano esplicitamente il formato Q&R:

NON formattare il report come elenco Q&R numerato. Non presentare le risposte come «D1: ... R1: ...», non ripetere letteralmente gli elenchi di argomenti, non raggruppare le «domande saltate» alla fine. Il report deve leggersi come una nota analitica fluida.

È una lezione largamente trasferibile, ben oltre i dati solari: la struttura del tuo prompt diventa la struttura dell'output. Se dai a un'IA una checklist numerata, ottieni una risposta con una checklist numerata. Se dai un briefing narrativo, ottieni un racconto. Le domande contano, ma il modo in cui le incorpori decide se il report sembra analisi o compito.

Il PDF che mentiva su sé stesso

Un altro schema di errore è emerso nel secondo round di test, e questo era specifico di ChatGPT.

ChatGPT ora usava correttamente Python per calcolare la sua analisi. Il report Markdown consegnato era esatto: 444,51 € di ricavo da immissione a vita, 1.865,67 € di risparmio da autoconsumo, tutto coerente con il nostro calcolo di riferimento. E poi ha generato un PDF.

Il PDF indicava 888,53 € di ricavo da immissione e 1.031 € di risparmio da autoconsumo.

Due numeri diversi per la stessa metrica, dallo stesso modello, nella stessa sessione di chat, entrambi presentati come definitivi. L'utente apre il report Markdown e il PDF affiancati e legge il quadro finanziario di due impianti diversi, ciascuno presentato in modo autorevole. È peggio di non avere alcun PDF. Distrugge attivamente la fiducia.

Ciò che quasi certamente è successo è che il code interpreter di ChatGPT ha eseguito l'analisi in una sessione Python e poi ha avviato una sessione nuova per costruire il PDF, importando ipotesi tariffarie predefinite diverse. Il modello non ha consapevolezza del fatto che «l'analisi Markdown ha usato 0,04 € di tariffa di immissione e il PDF ha usato 0,08 €», entrambe le sessioni hanno visto un calcolo coerente, solo con input diversi. Il modello non ha memoria che gli ricordi di essersi già impegnato in un set di numeri prima.

Abbiamo affrontato la cosa con un'istruzione single-source-of-truth esplicita nel prompt:

I numeri nel PDF DEVONO provenire dagli STESSI valori calcolati che sostengono l'analisi testuale. Non devono essere ricalcolati indipendentemente. Dopo la fase «Compute» del tuo workflow, salva OGNI metrica in un unico dict o namespace (per esempio metrics = {...}). Lo scrittore della prosa legge da metrics["lifetime_kwh"]. Il builder del PDF legge da metrics["lifetime_kwh"]. Non ricalcolare mai ciò che è già stato calcolato.

Se funzioni specificatamente con ChatGPT resta da vedere. L'istruzione chiede al modello, in sostanza, di gestire il proprio stato attraverso due fasi di un compito a più passi, che è esattamente il punto debole degli LLM moderni. Forse dovremo accettare che i PDF di ChatGPT siano inaffidabili, o rinunciare alla funzione PDF per quel modello specifico. Claude, al contrario, ha gestito la cosa perfettamente al primo tentativo: il PDF di 11 pagine conteneva numeri identici all'analisi Markdown da cima a fondo, perché mantiene effettivamente uno stato di calcolo coerente per tutta la durata di un compito lungo.

Il lavoro da detective di Claude, riveduto

Un'osservazione del secondo round di Claude merita una luce ulteriore, perché mostra sia il punto di forza sia il limite dell'uso di un'IA come detective dei dati.

Nella sua analisi, Claude ha segnalato quelle che ha definito tre incoerenze nei Solar Moments. L'export conteneva cinque traguardi Solar Moments: «10.000 kWh dall'installazione» il 12 aprile 2024, «5.000 kg di CO₂ evitati» il 30 settembre 2024, «Miglior giorno del 2024» il 14 giugno, «7° anniversario dell'installazione» il 15 aprile 2025, e «20.000 kWh dall'installazione» il 22 agosto 2025.

Claude ha correttamente notato che tre di questi traguardi non quadrano con i dati nell'export. L'array annuale comincia a gennaio 2023, e al 12 aprile 2024 mostra solo 6.467 kWh prodotti, non i 10.000 dichiarati dal traguardo. Al 30 settembre 2024, l'export mostra circa 8.500 kWh prodotti, il che implica circa 4.000 kg di CO₂ evitati, non 5.000. Al 22 agosto 2025, l'export mostra circa 14.200 kWh, non 20.000.

È lavoro forense sui dati di prim'ordine. Claude ha estratto la produzione cumulativa dall'array annuale e ha notato lo scarto. Eravamo abbastanza colpiti da aggiungerla come candidato difetto nel nostro tracker di bug iOS.

Ma poi abbiamo riletto il profilo di sistema, che indica come data di installazione il 15 aprile 2018. L'impianto produce energia solare da otto anni; l'export contiene solo gli ultimi tre. I 5.000-6.000 kWh «mancanti» necessari perché i traguardi tornino corrispondono esattamente alla produzione dal 2018 al 2022 inclusi, che semplicemente non è in questo export. I Solar Moments leggono da uno storico più lungo (probabilmente il totale di vita su PVOutput stesso), mentre l'array annuale è il sottoinsieme che HelioPeak tiene in cache.

Non è un bug. È comportamento corretto, solo insufficientemente documentato. L'utente vede sul telefono un traguardo «20.000 kWh dall'installazione» perché il suo sistema PVOutput ha effettivamente superato quella soglia; semplicemente, non è successo interamente all'interno della finestra temporale di questo export.

La lezione qui è a doppio taglio. Da un lato, la capacità di Claude di trovare questo tipo di incoerenza in pochi secondi è straordinariamente preziosa. È esattamente l'allarme di qualità dei dati che un esportatore dovrebbe sentire, anche se in questo caso si è rivelato un falso positivo. Dall'altro, Claude era sicuro della sua diagnosi, e uno sviluppatore meno prudente (noi, all'inizio) avrebbe passato ore a cercare un bug di fuso orario inesistente nel codice iOS. L'IA è un detective dei dati brillante, ma non sa cosa non sa: non riesce a vedere oltre i dati che le si danno. La data di installazione dell'utente era proprio nell'intestazione dell'export; Claude semplicemente non l'ha collegata alla conclusione.

Abbiamo affrontato la cosa aggiungendo una nota esplicita nell'intestazione dell'export («Ambito Solar Moments: i traguardi possono riferirsi a produzione cumulativa antecedente alla data di inizio dell'array annuale») e una regola esplicita nelle regole critiche («segnala un traguardo come incoerente solo se il sistema è stato installato DOPO l'inizio dell'array annuale»). Le future esecuzioni di Claude dovrebbero saltare questo falso positivo.

Capacità contro impegno: lo spettro vero

Per questo esperimento abbiamo ingenuamente diviso gli assistenti IA in «buoni» (presumibilmente forti nei compiti dettagliati) e «cattivi» (presumibilmente deboli). Ciò che abbiamo trovato in realtà è uno spettro a due dimensioni: capacità contro impegno.

Alcuni modelli hanno capacità alta ma scarsa disponibilità a impegnarsi. ChatGPT nel nostro test ne era un esempio chiaro: il Code Interpreter è davvero potente, il modello sa chiaramente comprendere un prompt complesso, eppure l'output finalmente consegnato sembrava affrettato e incompleto. Il modello ha scelto di fare meno lavoro di quanto potesse.

Altri modelli hanno capacità grezza più bassa ma erogano più impegno rispetto al loro tetto. Gemini Pro dava questa impressione: non sempre il più sveglio, ma costantemente onesto su ciò che poteva e non poteva fare, e costantemente disposto a srotolare la struttura completa su richiesta.

Un piccolo numero di modelli ottiene un punteggio alto su entrambi gli assi. Claude nel nostro test sembrava un collaboratore volenteroso che si rivelava anche acuto. Il fatto che ci abbia dato una critica non richiesta sul file di export stesso era un segnale. È ciò che fa un collega competente e coinvolto.

E poi ci sono i casi in basso a sinistra del quadrante: bassa capacità, basso impegno, entrambi mascherati da linguaggio sicuro. Copilot e Grok nel nostro test rientravano entrambi in questo schema, anche se falliscono in modo diverso. Copilot inventa scuse esterne («il file è troncato»), mentre Grok inventa contenuti interni (un giorno top che non esiste).

La nostra raccomandazione attuale

Se userai la funzione «Export per analisi IA» di HelioPeak quando uscirà, ecco la nostra classifica al 23 maggio 2026, dopo quattro round di test con il prompt definitivo v0.4:

1. Claude (su claude.ai): chiaramente il migliore in generale. Analisi testuale di riferimento, PDF brandizzato impeccabile, trova reali problemi di qualità dei dati nell'export stesso. Se provi un solo assistente, prova questo.
2. Gemini Pro: solido secondo. Analisi narrativa, onesto sui propri limiti nei round precedenti, ma ha consegnato un PDF interamente brandizzato con numeri coerenti nel round finale. Una vera alternativa a Claude.
3. Google AI Studio: la maggiore profondità testuale sui dati, ma non riesce a consegnare file all'interno dell'interfaccia di chat. Utile se vuoi copiare e incollare l'analisi, non se serve un PDF.
4. ChatGPT Plus con Code Interpreter: numeri corretti nell'analisi, ma produce PDF i cui numeri non sempre coincidono con l'analisi. Praticabile se serve solo il testo.
5. Grok: output dall'aspetto competente, ma verifica i numeri da solo. Abbiamo visto valori inventati nei nostri test.
6. Copilot: al momento non adatto a questo compito. Sostiene che il file sia troncato quando non lo è, e propone una soluzione a un problema inesistente.

Se hai tempo di provarne uno solo, il nostro consiglio concreto è iniziare con Claude su claude.ai. La combinazione di profondità analitica, disponibilità a sollevare dubbi sulla qualità dei dati e output PDF brandizzato affidabile rende Claude il leader netto nei nostri test. Gemini Pro è un'alternativa credibile, soprattutto dopo l'upgrade nell'ultimo round. Gli altri hanno i loro punti di forza, ma per questo compito specifico (analisi strutturata di un dataset di medie dimensioni con un deliverable PDF brandizzato), il divario tra Claude e il resto è reale.

Avvertenza importante: si tratta di un'istantanea. Gli assistenti IA cambiano ogni settimana. Il modello dietro ChatGPT oggi potrebbe essere un modello diverso tra un mese, con punti di forza diversi. Anthropic, OpenAI, Google, xAI e Microsoft pubblicano tutti grossi upgrade in cicli di settimane o trimestri. Quando leggerai questo, la classifica potrebbe essersi spostata, talvolta in modo notevole. Se tieni al miglior output, vale la pena ritestare il tuo assistente preferito ogni pochi mesi su un compito di riferimento noto.

La nostra classifica è anche specifica per questo unico compito: analisi strutturata di un dataset di medie dimensioni, ben formattato, con istruzioni esplicite. Per la conversazione, la generazione di codice, la scrittura creativa o la ricerca sul web, l'ordine sarebbe quasi sicuramente diverso.

Cosa significa per il design dei prompt

Quattro iterazioni hanno modificato sostanzialmente il nostro prompt. Ogni cambiamento era motivato da uno schema di errore specifico che avevamo osservato:

Primo, abbiamo reso il prompt aggressivo sul tema delle verifiche di capacità. La prima cosa che ora chiediamo all'IA è di verificare di aver ricevuto il file completo (cercando il nostro marcatore di fine esplicito), confermare se dispone dell'esecuzione di codice, e confermare se sa sia generare sia consegnare file PDF. Questo intercetta presto la confabulazione tipo Copilot e costringe modelli come Google AI Studio a dichiarare in anticipo che non possono consegnare file.

Secondo, abbiamo reso il prompt aggressivo sul calcolo, non sulla stima. Il prompt iniziale suggeriva educatamente che l'IA «potesse usare Python se disponibile». Il prompt attuale dice esplicitamente: non stimare né approssimare mai un numero se puoi calcolarlo. I dati di questo file sono precisi; la tua analisi deve esserlo altrettanto. Abbiamo sostenuto questo con formule esplicite in un'Appendice di calcolo, così non c'è alcuna ambiguità su come calcolare qualcosa.

Terzo, abbiamo aggiunto una regola di onestà: meglio un'analisi parziale ma onesta che un'analisi completa ma inventata. È la regola che, se funziona, dovrebbe soffocare le invenzioni stile Grok e trasformare i PDF affrettati stile ChatGPT in salti onesti.

Quarto, abbiamo ristrutturato il prompt in modo che le 39 domande specifiche siano incorporate come argomenti all'interno delle 14 sezioni narrative, invece di essere elencate separatamente come Q&R alla fine. Questa è stata la lezione più trasferibile: la struttura del tuo prompt diventa la struttura dell'output. Se vuoi un'analisi fluida, devi chiedere un'analisi fluida, non una checklist.

E quinto, abbiamo aggiunto una regola single-source-of-truth per il PDF: ogni numero del PDF deve provenire dallo stesso dict calcolato che sostiene l'analisi Markdown, e non dev'essere mai ricalcolato. Questo chiede all'IA, in sostanza, di gestire uno stato tra due fasi di un compito complesso, cosa sinceramente difficile per i modelli attuali, ma rende almeno visibile quando va storto.

Nulla di tutto questo ci sarebbe stato visibile senza condurre il test: quattro volte, sullo stesso dataset, con gli stessi sei modelli, con istruzioni via via più precise. La prima versione del nostro prompt era, secondo qualunque revisione interna ragionevole, un set di istruzioni rigoroso e ben pensato. È stato solo quando abbiamo visto sei diversi assistenti IA produrre sei output diversi di qualità ampiamente variabile, e poi visto quegli output migliorare a ogni iterazione, che abbiamo capito quanto del prompt fosse ipotesi implicita piuttosto che istruzione esplicita.

La lezione più ampia, per chiunque usi l'IA su dati reali

Se non stai costruendo un'app e ogni tanto ti limiti a buttare un CSV in ChatGPT per farlo riassumere, questo articolo probabilmente non è per te. Il prompt con 39 argomenti, PDF brandizzato e architettura multi-strato che abbiamo costruito per HelioPeak è sovradimensionato per analisi una tantum. Ma ci sono quattro principi nati dal nostro test che a nostro avviso sono generalizzabili a qualunque uso serio dell'IA su dati reali.

Principio uno: dì all'IA esattamente cosa calcolare, costanti incluse. «Qual è l'impatto carbonico della mia produzione solare» è troppo aperto. «Calcola la CO₂ totale evitata con un fattore di 0,467 kg per kWh, poi esprimila in equivalente km auto assumendo 120 g CO₂ per km, in equivalente alberi adulti assumendo 21 kg assorbiti per albero all'anno, e in equivalente famiglia-anno assumendo 1.635 kg CO₂ per famiglia UE all'anno» ti dà la stessa risposta da ogni modello.

Principio due: costringi l'IA a dichiarare le proprie capacità in anticipo. Se non lo fai, i modelli spesso tenteranno compiti che non possono consegnare, o rifiuteranno compiti che potrebbero gestire. La verifica preventiva chiarisce le aspettative su entrambi i lati.

Principio tre: incorpora una regola di onestà. Di' direttamente all'IA che preferisci una risposta parzialmente onesta a una completamente inventata. Non ferma tutte le allucinazioni, ma nei nostri test ha ridotto sensibilmente il ritmo con cui i modelli inventavano valori per riempire le lacune.

Principio quattro: la struttura del tuo prompt diventa la struttura dell'output. Se chiedi un racconto in 13 sezioni E un Q&R in 39 domande, otterrai entrambi, e il Q&R rimarrà goffamente in fondo come un compito. Se vuoi un'analisi fluida, incorpora le tue domande specifiche nelle sezioni narrative come «argomenti da coprire», non come elenco separato. Le domande continuano a guidare la cura; semplicemente scompaiono nella prosa, dove gli appartengono.

Nessuno di questi principi è rivoluzionario. Compaiono in articoli accademici sul prompt engineering, nelle guide al prompting di OpenAI e Anthropic stesse, nei post di chi lo fa per mestiere. Ciò che il nostro esperimento aggiunge è la prova empirica che applicare questi principi, su un compito reale con dati reali, modifica sensibilmente la qualità dell'output di più modelli.

Cosa viene dopo

La funzione «Export per analisi IA» arriverà in una futura versione di HelioPeak, dopo che il codice iOS sarà scritto, testato e approvato da Apple. Quando leggerai questo, potrebbe già essere online; consulta la pagina delle note di rilascio per lo stato corrente.

Quando sarà disponibile, produrrà lo stesso file Markdown autonomo che abbiamo testato qui. Lo potrai incollare nell'assistente IA che preferisci. Pubblicheremo una voce di FAQ con le nostre attuali raccomandazioni di modello e una nota che dice che tali raccomandazioni possono spostarsi nel tempo. Non ti vincoleremo a un singolo assistente. Ti forniremo semplicemente il file di export dati più utile che riusciamo a progettare, e tu deciderai dove inviarlo.

Continueremo anche a ripetere questo test. Circa ogni trimestre, faremo passare lo stesso export attraverso la versione più recente di ogni grande assistente IA, vedremo come si è spostata la classifica e aggiorneremo questo articolo. L'IA evolve troppo in fretta perché un'istantanea resti utile a lungo. La metodologia, il dataset e il prompt sono stabili; gli assistenti no. È ciò che rende il benchmark interessante.

Se possiamo trarre una sola conclusione da quattro iterazioni in un solo weekend, è questa: gli assistenti IA sono strumenti straordinariamente potenti che falliscono in modi straordinariamente specifici. Il modo per affrontare questi fallimenti non è cambiare strumento o arrendersi; sta nell'affinare le istruzioni finché ogni schema di errore non scompare. L'Appendice di calcolo ha risolto la divergenza. La verifica di capacità ha (in gran parte) risolto la confabulazione. La ristrutturazione narrativa ha risolto il formato compito. La regola single-source-of-truth ha cominciato a risolvere lo scarto del PDF. Ogni correzione singolarmente è piccola, ma insieme trasformano uno strumento inaffidabile in un collaboratore utile.

Se stai costruendo qualcosa di simile e ti va di confrontare appunti sul design dei prompt per l'analisi di dati strutturati, sai dove trovarci.

Questo articolo documenta i test condotti il 23 maggio 2026 su quattro iterazioni della progettazione del nostro prompt (da v0.1 a v0.4). La specifica di export è ora congelata a v0.4 e pronta per l'implementazione iOS. L'app HelioPeak per iOS, per il monitoraggio dei sistemi PVOutput.org, è disponibile sull'App Store.

Questo articolo è stato scritto in inglese e tradotto con l'aiuto dell'IA. Leggi l'originale in inglese.

← Torna al blog