Dentro Quantum Radar: cosa fa il codice, cosa fa l’intelligenza artificiale

Nel primo articolo ho raccontato perché ho costruito Quantum Radar: seguire nel tempo un piccolo gruppo di aziende appartenenti a un settore emergente, senza affidarmi soltanto alla memoria, a qualche foglio Excel o alla successione di notizie che ogni giorno il mercato mette davanti agli occhi.

A proposito del nome, devo una precisazione a un lettore che, commentando la prima puntata su LinkedIn, mi ha fatto notare come quantum radar indichi già una specifica linea di ricerca nel campo del rilevamento quantistico, accompagnata peraltro da un interessante dibattito critico sui risultati raggiunti e sulle prospettive applicative.

L’osservazione è pertinente e lo ringrazio per averla sollevata. Il mio Quantum Radar non utilizza tecnologie radar quantistiche: il termine radar è impiegato esclusivamente in senso metaforico, per descrivere uno strumento di osservazione del settore del calcolo quantistico. Chi fosse interessato all’argomento può approfondirlo attraverso il paper segnalato dal lettore .

Chiarito questo punto, torniamo alla nostra officina.

Una volta individuato il bisogno, nasceva una domanda forse ancora più interessante, che riguarda proprio il rapporto tra intelligenza artificiale e codice: quanto di questo lavoro doveva essere affidato davvero a un modello linguistico?

La risposta, almeno nel mio caso, è stata: molto meno di quanto si potrebbe immaginare.

Quando si parla di applicazioni basate sull’IA, si tende facilmente a pensare a un modello linguistico come al cuore dell’intero sistema, una sorta di motore centrale al quale affidare dati, domande, interpretazioni e risultati. In Quantum Radar ho preferito una strada diversa, distinguendo fin dall’inizio le attività che richiedevano comportamenti ripetibili da quelle nelle quali sarebbe stato necessario interpretare informazioni.

È una scelta che costringe a progettare l’applicazione partendo dalla natura del problema, anziché dal fascino dello strumento.

I prezzi devono essere numeri esatti, le date non possono essere approssimate e le variazioni percentuali devono essere calcolate sempre nello stesso modo. Se una regola è nota, il modo più affidabile per applicarla resta scriverla come regola; ricorrere a un modello linguistico, in questi casi, introdurrebbe soltanto un’incertezza inutile.

Quantum Radar è quindi costruito attorno a una divisione del lavoro piuttosto netta: le fonti esterne forniscono le informazioni, il codice le acquisisce e le organizza, il database conserva la storia, mentre il modello linguistico interviene quando occorre leggere, confrontare e sintetizzare. La decisione finale rimane alla persona che utilizza lo strumento.

È un criterio progettuale che approfondisco in Officina atomica: prima di scegliere un modello bisogna capire quali attività richiedano davvero interpretazione e quali possano essere affidate a software tradizionale, regole verificabili e supervisione umana. Quantum Radar è uno degli esperimenti con cui ho provato ad applicare concretamente questo metodo.

Dove il codice deve restare codice

Disponendo di un modello linguistico potente, la tentazione di affidargli anche operazioni risolvibili con poche righe di codice tradizionale è piuttosto naturale. Ma se devo confrontare due valori, verificare l’esistenza di un campo, applicare una soglia o interrogare un archivio, non ho bisogno di interpretazione, bensì di un comportamento ripetibile.

Il software convenzionale possiede un vantaggio enorme proprio in queste attività poco spettacolari: posso conoscere le regole con cui opera e verificare il risultato. In Quantum Radar, questa prevedibilità permette di distinguere ciò che deriva dai dati da ciò che nasce da una loro interpretazione, soprattutto quando i risultati di oggi devono poter essere confrontati con quelli di settimane o mesi precedenti.

Lo stesso principio vale per la memoria.

Un modello linguistico può produrre risposte convincenti, ma non dovrebbe diventare il deposito affidabile delle informazioni di un’applicazione. Per questo gli elementi acquisiti, gli eventi rilevanti e le valutazioni precedenti vengono conservati separatamente, in modo che il sistema possa recuperarli senza dover ricostruire ogni volta il passato attraverso una nuova generazione di testo.

Il modello può leggere quella memoria e utilizzarla per formulare un’interpretazione, ma non deve sostituirsi all’archivio da cui essa proviene. Diventa così possibile risalire alle informazioni originali e distinguere un fatto registrato da una sintesi prodotta successivamente.

Un sistema governabile, del resto, non è necessariamente quello che fa più cose, ma quello nel quale si riesce a capire chi ha fatto che cosa, con quali dati e secondo quali regole.

Il compito giusto per un modello linguistico

La situazione cambia quando entrano in gioco notizie, dichiarazioni societarie e documenti nei quali il significato non è riducibile a un numero o a una condizione verificabile.

Due comunicati possono riferirsi allo stesso argomento usando parole diverse; un annuncio apparentemente importante può non aggiungere nulla a ciò che era già noto, mentre un dettaglio poco appariscente potrebbe modificare la lettura di una traiettoria osservata da tempo.

Si possono certamente costruire filtri, classificatori e sistemi di regole sempre più sofisticati, ma arriva un momento in cui la complessità della soluzione tradizionale comincia a crescere più del beneficio. È in questo spazio che il modello linguistico diventa interessante, perché può mettere in relazione informazioni espresse in forme differenti, riconoscere somiglianze e possibili contraddizioni e restituire una sintesi comprensibile.

In Quantum Radar, però, non gli viene chiesto genericamente che cosa accadrà a una determinata azienda. Il suo lavoro si inserisce in un processo nel quale dati e contesto sono già stati raccolti e organizzati.

Può quindi contribuire a riconoscere quali elementi siano effettivamente nuovi, quali confermino una lettura precedente e quali meritino invece di rimetterla in discussione, senza che questa interpretazione si trasformi automaticamente in una decisione di investimento.

La qualità di una micro-app non dipende soltanto dalle capacità del modello utilizzato, ma anche dalla precisione con cui è stato definito il suo compito. Un modello molto potente, collocato al centro di un sistema mal progettato, può produrre risultati convincenti senza renderli necessariamente più affidabili; uno meno ambizioso, inserito in un processo ben delimitato, può invece offrire un contributo utile e soprattutto verificabile.

Il report non è una decisione

Quantum Radar produce periodicamente una rappresentazione organizzata di ciò che sta accadendo, mettendo in evidenza variazioni, eventi e informazioni che potrebbero meritare un approfondimento.

Questo, però, non lo trasforma in una macchina capace di suggerire automaticamente che cosa fare. Una notifica richiama l’attenzione, un report organizza le informazioni e un segnale indica qualcosa che il sistema considera meritevole di osservazione; il significato e le conseguenze di questi elementi rimangono da valutare.

La distinzione è importante anche dal punto di vista dell’interfaccia. Un’applicazione che produce risultati con regolarità e li presenta in modo ordinato può indurre l’utente ad attribuirle un’autorità superiore a quella che possiede realmente.

Per questo non basta progettare ciò che un sistema è capace di fare: occorre stabilire con altrettanta attenzione i limiti entro i quali deve operare.

Nel mio caso, Quantum Radar non deve diventare più sicuro di sé della persona che lo utilizza. Deve piuttosto aiutarla a fermarsi un momento e osservare meglio.

L’IA che costruisce e l’IA che lavora

C’è infine un aspetto che considero particolarmente interessante e che va oltre Quantum Radar.

Durante lo sviluppo, l’intelligenza artificiale ha avuto un ruolo molto ampio: mi ha aiutato a discutere i flussi, definire la struttura dell’applicazione, scrivere e correggere script, individuare errori e modificare rapidamente soluzioni che non funzionavano come previsto.

In questo senso, l’IA riduce sensibilmente la distanza tra un’idea e un prototipo funzionante, permettendo anche a chi non è uno sviluppatore professionista di partecipare in modo molto più diretto alla costruzione dei propri strumenti.

Una volta terminato lo sviluppo, però, il suo ruolo cambia. Il modello linguistico diventa soltanto uno dei componenti della micro-app, con compiti definiti e confini precisi: il fatto che sia stato determinante per costruire il sistema non significa affatto che debba governarlo.

Questa distinzione — tra l’IA che aiuta a costruire e quella che, eventualmente, resta dentro lo strumento costruito — è uno dei fili conduttori di Officina atomica, dove la affronto soprattutto come questione di metodo: come può chi conosce profondamente il proprio mestiere trasformare questa competenza in software, senza perdere il controllo del risultato?

È una trasformazione che non elimina il bisogno di competenze tecniche e progettazione rigorosa. Cambia, piuttosto, il rapporto tra chi comprende il problema e chi può contribuire a realizzare la soluzione.

L’IA può essere un ottimo strumento di officina senza dover diventare l’intera officina.

La parte più importante è il confine

Ripensando allo sviluppo di Quantum Radar, mi sembra che la scelta più importante non sia stata individuare il modello linguistico più adatto o selezionare una particolare fonte di dati, ma stabilire i confini tra componenti con responsabilità differenti.

Il dato deve rimanere distinguibile dall’interpretazione, la memoria deve essere conservata separatamente dalla generazione del testo e il risultato di un’elaborazione non deve acquisire automaticamente il valore di una decisione.

Il paradosso è che una buona applicazione di intelligenza artificiale può diventare migliore proprio quando si decide con precisione dove l’IA non deve entrare.

Quantum Radar non è dunque una macchina intelligente nel senso spettacolare del termine, ma un piccolo sistema nel quale tecnologie differenti collaborano senza perdere la propria identità. Una parte considerevole del lavoro è svolta da software tradizionale, mentre il modello linguistico interviene soltanto dove può aggiungere qualcosa che regole e calcoli non riescono a offrire.

È questo equilibrio, più della potenza di un singolo componente, che rende lo strumento comprensibile, correggibile e governabile.

Nella prossima puntata entreremo nel tema della memoria e vedremo perché, in un sistema di osservazione, ricordare correttamente ciò che pensavamo ieri può essere persino più importante che formulare una previsione su domani.