🤖 AI

Empirical Computation: Prompting versus Programming

Questo documento di visione propone la "computazione empirica" come un nuovo paradigma in cui i Large Language Models risolvono problemi computazionali tramite il prompting piuttosto che attraverso la programmazione tradizionale, sostenendo che le loro capacità e i loro limiti unici richiedano alla comunità dell'ingegneria del software di sviluppare nuove teorie fondamentali e tecniche per analizzare la correttezza e i confini fondamentali.

Autori originali: Eric Tang, Jing Liu, Marcel Böhme

Pubblicato 2026-07-08

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Eric Tang, Jing Liu, Marcel Böhme

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di avere due modi per portare a termine un lavoro: la Programmazione e il Prompting.

Il vecchio modo: La Programmazione (L'Architetto Rigido)

Pensa alla programmazione tradizionale come all'assunzione di un architetto rigoroso che segue le regole alla lettera. Gli fornisci un progetto con misurazioni esatte, materiali specifici e un piano passo dopo passo.

Come funziona: Dici al computer esattamente come risolvere un problema, come ordinare una lista di numeri. Dici: "Usa questo algoritmo specifico (Merge Sort), prendi questi input e segui queste regole".
Il Risultato: Se l'architetto commette un errore, puoi trovare l'esatto mattone difettoso nel progetto, correggerlo e sapere con certezza che l'edificio starà in piedi la prossima volta.
Il Limite: Il tempo necessario per costruire dipende dalla complessità della matematica. Ordinare una lista enorme di numeri richiede un tempo prevedibile basato sulla dimensione della lista (specificamente, $O(n \log n)$ ).

Il nuovo modo: Il Prompting (L'Artista Intuitivo)

Ora, immagina di assumere un artista brillante e intuitivo. Non gli dai un progetto. Gli dici solo: "Ehi, ecco un mucchio disordinato di numeri, potresti ordinarli per me?".

Come funziona: Usi il linguaggio naturale (un "prompt") per descrivere il problema. Il "computer" (un Large Language Model o LLM) non segue un insieme rigido di regole. Invece, indovina la risposta più probabile basandosi su tutto ciò che ha mai letto su Internet. È come uno chef che assaggia una zuppa e ne indovina gli ingredienti invece di seguire una ricetta.
Il Risultato: La risposta arriva velocemente, ma è una congettura, non una garanzia. È la risposta "più probabile", non quella "provata corretta".

Cosa ha scoperto il documento: La sorpresa "Empirica"

Gli autori di questo documento hanno condotto esperimenti per vedere quanto bene questo "Artista Intuitivo" si comporti su classici problemi matematici come l'ordinamento di numeri o la ricerca di elementi in una lista. Ecco cosa hanno scoperto:

1. Il tempo non funziona allo stesso modo

Programmazione: Se raddoppi il numero di elementi da ordinare, il tempo necessario aumenta in un modo specifico e matematico.
Prompting: Il tempo impiegato dall'LLM per ordinare i numeri aumenta linearmente (semplicemente come una linea retta) man mano che la lista diventa più grande. Perché? Non perché la matematica sia più difficile, ma perché l'LLM deve leggere e scrivere più parole (token) per gestire la lista più lunga. È come leggere un libro più lungo; richiede più tempo per leggere le parole, non perché la storia sia più complessa.

2. L'accuratezza cala all'aumentare delle dimensioni

Programmazione: Un programma corretto è corretto al 100% ogni volta.
Prompting: L'LLM è bravo in compiti piccoli, ma si confonde man mano che la lista cresce.
- Per una lista di 50 numeri, l'LLM ha avuto ragione circa il 90% delle volte.
- Per una lista di 150 numeri, ha avuto ragione solo il 58% delle volte circa.
- Se gli chiedi di trovare un pattern specifico in una stringa breve, potrebbe fallire quasi immediatamente se la stringa si allunga leggermente.
- La modalità "Pensiero": Quando all'LLM è permesso "pensare" (ragionare passo dopo passo) prima di rispondere, rimane molto accurato, ma richiede molto più tempo.

3. Il gioco del linguaggio

Programmazione: Non importa se scrivi il codice in inglese o in tedesco; il computer legge i simboli allo stesso modo.
Prompting: L'LLM è influenzato da ciò che ha letto su Internet.
- Se chiedi all'LLM di ordinare numeri scritti come parole inglesi ("one, two, three"), fa un ottimo lavoro.
- Se chiedi all'LLM di ordinare numeri scritti in tedesco ("eins, zwei, drei"), fallisce quasi completamente.
- Perché? L'LLM ha visto milioni di esempi in inglese su Internet, ma molti meno in tedesco. È come chiedere a uno chef di cucinare un piatto che non ha mai visto prima; potrebbe indovinare la ricetta in modo errato.

4. Il problema del "Mattone Difettoso"

Programmazione: Se un programma fallisce, puoi trovare il bug, correggere il codice e il problema è risolto per sempre.
Prompting: Se l'LLM dà una risposta errata, non puoi facilmente trovare "il bug". Non puoi indicare una specifica riga di codice da correggere. Potresti provare a cambiare il tuo prompt o a chiedergli di "pensare più intensamente", ma non c'è garanzia che funzionerà la prossima volta. È come cercare di riparare un sogno cambiando l'umore del sognatore.

La grande conclusione

Il documento sostiene che stiamo entrando in una nuova era chiamata "Computazione Empirica".

Nel vecchio mondo, ci fidavamo dei computer perché seguivano regole rigide (framework Razionalista). In questo nuovo mondo, ci fidiamo dei computer perché fanno "congetture istruite" basate sui dati (framework Empirico).

Gli autori invitano gli ingegneri del software a smettere di analizzare questi sistemi di IA come i programmi della vecchia scuola. Abbiamo bisogno di nuovi strumenti per misurare, testare e comprendere come funzionano queste "macchine da ipotesi", perché le vecchie regole della matematica e della logica non si applicano più pienamente a loro. Dobbiamo capire come fidarci di un risultato che è "probabilmente corretto" piuttosto che di uno che è "sicuramente corretto".

Sintesi Tecnica: Computazione Empirica: Prompting versus Programmazione

Definizione del Problema

Il documento identifica un cambio di paradigma nella risoluzione di problemi computazionali: il passaggio dalla programmazione (specificare algoritmi e strutture dati precisi) al prompting (fornire descrizioni informali in linguaggio naturale a Large Language Models o agenti). Mentre la computazione tradizionale si basa su procedure deterministiche con correttezza verificabile e limiti di complessità ben definiti (ad esempio, $O(n \log n)$ per l'ordinamento), la "computazione empirica" si basa sul campionamento di output da una distribuzione di probabilità.

Il problema centrale è che le capacità e i limiti di questa nuova forma di computazione non possono essere compresi all'interno del classico framework razionalista dell'informatica. Nello specifico:

Mancanza di Determinismo: Gli output non sono generati proceduralmente ma sono il risultato "empiricamente più probabile", il che li rende suscettibili a allucinazioni ed errori che non possono essere localizzati o riparati tramite il tradizionale debugging.
Ambiguità nell'Input: A differenza della programmazione, che richiede contratti formali (tipi, formati), il prompting accetta input informali dove l'interpretazione dipende dal contesto e dalla distribuzione di addestramento del modello.
Complessità Incerte: Il comportamento del runtime appare scollato dalla classica complessità computazionale, correlandosi invece alla tokenizzazione e al comportamento di inferenza del modello.
Gap di Verifica: Le tecniche esistenti di ingegneria del software (SE) (analisi statica, verifica formale) sono inadeguate per analizzare sistemi in cui non esiste un programma esplicito da verificare.

Metodologia

Gli autori hanno condotto esperimenti preliminari per caratterizzare l'efficienza e la correttezza della computazione empirica attraverso cinque classici problemi computazionali:

Sorting (Ordinamento): Ordine crescente di numeri casuali.
Searching (Ricerca): Trovare un indice in liste ordinate e non ordinate.
Longest Palindromic Substring (Sottostringa Palindroma più Lunga): Trovare la sequenza palindroma più lunga in una stringa.
Subset Sum Problem (SSP - Problema della Somma di Sottoinsiemi): Trovare un sottoinsieme di numeri la cui somma sia uguale a un valore target.

Configurazione Sperimentale:

Modello: Gli esperimenti hanno utilizzato il modello open-weights gemma-4-26b-a4b eseguito localmente su un MacBook Pro (M5 Pro, 48GB RAM) per eliminare la latenza di rete.
Configurazioni: Sono state testate tre modalità:
- Default: Temperatura = 1.0.
- Deterministic (Deterministica): Temperatura = 0.0.
- Thinking (Ragionamento): Modalità di ragionamento abilitata.
Metriche:
- Efficienza: Tempo per la soluzione e tempo per la prima soluzione corretta.
- Correttezza: Proporzione di tentativi che restituiscono la risposta matematicamente corretta.
Variabili: Dimensione dell'input ( $n$ ), precisione del numero, e rappresentazione linguistica (cifre vs parole in varie lingue: inglese, tedesco, coreano, giapponese, ecc.).
Verità Fondamentale (Ground Truth): Per problemi non banali (Substring, SSP), semplici programmi Python hanno generato le risposte corrette per la validazione.

Risultati Chiave

1. Efficienza vs Complessità Classica

Contrariamente alla teoria classica, il runtime della computazione empirica non segue strettamente la complessità algoritmica del problema (ad esempio, $O(n)$ vs $O(n \log n)$ ).

Scalabilità Lineare: Per l'ordinamento, la ricerca e l'SSP, il tempo per la soluzione è aumentato linearmente con la dimensione dell'input ( $O(n)$ ) in tutte le modalità. Gli autori attribuiscono ciò all'aumento lineare dei token di input/output piuttosto che alla logica computazionale.
Dipendenza dai Token: Il tempo impiegato per incrementare un numero è stato paragonabile alla predizione di testo in chiaro da un hash SHA-512, suggerendo che il runtime sia guidato dalla tokenizzazione e dalle meccaniche di inferenza piuttosto che dalla difficoltà del problema.
Costo della Modalità "Thinking": Abilitare il "ragionamento" ha aumentato significativamente il runtime (ad esempio, fino a 275s per ordinare 150 elementi) ma ha mantenuto un'alta correttezza.

2. Correttezza e Dimensione dell'Input

Sensibilità alla Dimensione: Nelle modalità Default e Deterministic, la correttezza è degradata rapidamente all'aumentare della dimensione dell'input.
- Per l'ordinamento di 50 interi, la correttezza è scesa a circa il 50% (probabilità di lancio della moneta).
- Per l'ordinamento di 150 interi, la correttezza è scesa a circa il 58% (nonostante l'aumento lineare del tempo).
- Per il problema della Subset Sum, la correttezza si è avvicinata allo zero per liste di lunghezza 10.
- Per il problema della Substring, la correttezza è scesa quasi a zero per stringhe di lunghezza 5.
Resilienza della Modalità "Thinking": Quando le capacità di ragionamento sono state abilitate, la correttezza è rimasta alta (>90%) anche per input più grandi, sebbene entro i limiti di token/tempo.

3. Impatto della Rappresentazione in Linguaggio Naturale

Lo studio ha investigato come la lingua utilizzata per rappresentare i numeri influenzi la correttezza.

Bias della Rappresentazione dei Dati: La correttezza dipende fortemente dalla rappresentazione della lingua nei dati di addestramento del modello.
Alta vs Bassa Rappresentazione: Ordinare numeri scritti in inglese (ben rappresentato) ha prodotto una correttezza >95% per la dimensione 20. Al contrario, ordinare numeri scritti in tedesco (poco rappresentato) ha prodotto una correttezza <1% per la stessa dimensione.
Conclusione: La computazione empirica non è agnostica rispetto alla lingua; è influenzata dalle lingue e dai formati prevalenti nel corpus di addestramento.

4. Caratteristiche degli Errori

A differenza dei programmi tradizionali dove i guasti possono essere localizzati in specifiche righe di codice, gli errori nella computazione empirica sono non deterministici. L'LLM potrebbe:

Aggiungere numeri non presenti nell'input.
Rimuovere numeri presenti nell'input.
Duplicare numeri.
Non riuscire a ordinare l'intera lista.
Troncare input di grandi dimensioni.

Contributi Chiave

Definizione di Computazione Empirica: Il documento introduce formalmente la "computazione empirica" come un campo distinto in cui le soluzioni vengono generate tramite prompting e campionamento anziché tramite esecuzione procedurale.
Caratterizzazione Empirica: Fornisce la prima misurazione sistematica di efficienza e correttezza per gli LLM che risolvono classici problemi algoritmici, rivelando che il runtime correla con la tokenizzazione piuttosto che con la complessità algoritmica.
Identificazione dei Limiti: Lo studio dimostra che, senza modalità di ragionamento, la computazione empirica non scala in modo affidabile con la dimensione dell'input ed è altamente sensibile alla rappresentazione linguistica degli input.
Appello per Nuove Fondamenta di SE: Gli autori sostengono che la comunità dell'ingegneria del software debba sviluppare nuovi strumenti per l' "analisi di programmi empirici" (ragionamento statistico, controfattuale o causale) per analizzare, stimare e prevedere la correttezza di questi sistemi.

Significato e Visione

Il documento sostiene che la comunità dell'ingegneria del software non può fare affidamento sui classici framework razionalisti o sugli strumenti esistenti di analisi dei programmi per garantire l'affidabilità della computazione guidata dall'IA. Poiché gli LLM e gli agenti stanno diventando integrali nella risoluzione di problemi computazionali, il campo deve evolversi per affrontare:

Come analizzare la correttezza in assenza di un programma formale.
Come definire e testare i limiti della computazione empirica.
Come migliorare la correttezza per specifici casi di problemi senza introdurre regressioni.

Gli autori inquadrano questo come un ambito di ricerca tempestivo e ricco, esortando allo sviluppo di tecniche di "analisi dei programmi empirici" per colmare il divario tra la natura probabilistica degli LLM e le rigorose richieste dell'ingegneria del software. Il documento non pretende di risolvere questi problemi, ma mira a stabilire il campo e a evidenziare l'urgente necessità di nuove basi teoriche e pratiche.