L'ultimo articolo sull'argomento "come uso l'AI" lo avevo scritto il 23 Febbraio e nel frattempo ho condotto un'intensa attività di sperimentazione.
E siccome sono una persona intellettualmente onesta, oggi sono in grado di mettere in discussione alcune delle affermazioni che avevo fatto.
Ma andiamo con ordine, perchè le cose da dire sono tante.
Per prima cosa, partiamo da un principio generale: l'AI non è magia, se gli dai in pasto spazzatura ti restituirà spazzatura amplificata e se non sai fare le domande giuste non puoi pretendere di avere le risposte giuste.
Questo è il primo motivo per il quale l'AI non può sostituire un umano che sa come utilizzarla.
Quindi la prima domanda che devi farti è: in quale parte del mio processo lavorativo posso integrare l'AI in modo UTILE?
Eh si... perchè dopo 3 anni di hype ora anche i fuffa-guru alzano bandiera bianca e ammettono che l'AI non entrerà ovunque, in qualsiasi processo lavorativo, in qualsiasi contesto, a tutti i livelli, e non arriveranno la cavallette e non pioverà fuoco dal cielo se non adotterai l'AI.
Più pragmaticamnte, devi valutare SE e DOVE l'AI può portarti dei vantaggi, quanto ti costa acquisire questo vantaggio (la "Token ansiety" ha travolto anche aziende molto strutturate), quale può essere il ROI (Return of Investment) EFFETTIVO.
Perchè "a chiacchiere e gazzosa" siamo tutti esperti ma poi quando i conti non tornano il risveglio può essere brusco.
Ed è esattamente quello che ho fatto io. E ora ve lo racconto.
IL MIO PROCESSO LAVORATIVO
Volendo semplificare all'osso, il mio processo lavorativo può essere schematizzato secondo un diagramma in 5 fasi
In realtà, è un molto più complesso, ma per i nostri scopi questo schema è sufficiente.
PLANNING
Deriva dalle attività d'ingegneria del software condotte nella società in cui lavoro. Rispetto a tali attività vengono fissate priorità, tempi di realizzazione, scadenze di produzione. Ed io devo adeguare concordemente la pianificazione della necessaria documentazione di prodotto.
DATA COLLECTION
E' una delle attività più critiche. Tradizionalmente, si affrontava questa fase attraverso delle interviste semi-strutturate con i Subject Matter Experts (SMEs). Al risultato delle interviste si aggiungevano le bozze disponibili di qualsiasi tipo di documento, sviluppato da chiunque in azienda, o le evidenze rintracciabili nel Data Base, o da qualsiasi altra sorgente.
Alla fine tutte le informazioni confluivano in una prima bozza che veniva sottoposta agli SMEs per una prima verifica.
Il processo iterava dalle 2 alle 4 volte (anche in base alla complessità del topic) e consumava non solo il tempo del Tech Writer ma anche quello degli SMEs.
Questa fase mi è apparsa fin da subito molto adatta per assorbire un processo di analisi basato sull'AI.
In particolare, lavorando per una società che sviluppa software, mi è sembrato opportuno provare ad estrarre i dati che mi servivano DIRETTAMENTE dal codice: quindi non più dal racconto degli SMEs ma direttamente dal codice che viene reralizzato dagli SMEs.
In un articolo scritto il 6 Febbraio elencavo una serie di cose che l'AI NON POTEVA FARE.
Negli esperimenti che ho fatto sulla raccolta dei dati direttamente a partire dal codice, mi sono reso conto che questa affermazione va in parte corretta: alcune cose LE PUO' FARE, poi rimane in discussione la qualità del risultato e su questo farò degli esempi precisi nel prossimo articolo. Ma il miglioramento dei modelli negli ultimi 4 mesi ha reso possibile cose che all'inizio dell'anno presentavano una qualità non accettabile. Ora invece si può ottenere qualcosa di utile.
Dove sta il nucleo del mio obiettivo? Quello che ottenevo in 5 o 6 giorni di analisi di documenti grezzi e conversazioni con gli esperti del topic era una prima bozza che andava comunque verificata prima di andare oltre. Ora le informazioni le ottengo in meno di 10 minuti e la prima bozza la chiudo in una giornata.
E' SEMPRE UNA BOZZA da verificare, ma ho risparmiato 4 o 5 giorni. Ma non ho risparmiato solo IL MIO TEMPO ma anche quello degli SMEs.
WRITING
Con buona pace dei fuffa-guru, questa è ancora un'attività umana. In questo articolo non entro nei dettagli, sarebbe una lunga conversazione. Se siete interessati, contattatemi in privato. E' chiaro che io non pubblico quello che mi restituisce l'AI senza verificarlo, magari riorganizzando la struttura delle informazioni secondo i criteri che ritengo opportuni, verificando la concordanaza della terminologia rispetto alla documentazione già pubblicata, etc.
Se volete far scrivere e pubblicare la documentazione di prodotto IN AUTOMATICO dalla AI, tanti auguri: non sono il vostro uomo.
REVIEW & QUALITY CHECKS
Questo è stato il primo campo da gioco in cui ho sperimentato, come accennavo il 23 Febbraio.
Ad oggi dispongo di un framework flessibile e configurabile che mi consente di valutare la qualità di QUALSIASI TIPO di contenuto: da un singolo documento (in qualsiasi formato ispezionabile), ad un Online Help o una Knowledge Base.
Sono in grado di esprimere un indice di qualità per ogni singolo criterio utilizzato (N criteri liberamente configurabili) e un indice di qualità composito che tiene conto dei livelli di qualità dei singoli criteri.
Ecco un esempio di un particolare criterio:
Per ogni criterio si produce un report che evidenzia il risultato, la severità associata alla situazione, una proposta per migliorare il livello di qualità e l'evidenza del file (il report può elencare anche TUTTI i file coinvolti, per la leggibilità di questo esempio ho indicato un file fittizio), nonchè il livello di qualità registrato (in questo caso 82 su 100).
Come vedete da questo esempio, si potrebbe demandare all'AI la messa in atto della soluzione proposta: "Split long sentences and normalize punctuation for US English".
Quindi ripetere il check e vedere se l'indice di qualità è migliorato.
Questo può andar bene se parliamo di una issue di severità minor, che si limita a migliorare la punteggiatura e spezzare le frasi troppo lunghe.
Ma io preferisco ancora procedere con una verifica personale.
Il vantaggio di questo framework è che posso analizzare 500-600 pagine di documentazione verificando in parallelo N criteri e ottengo il risultato in pochi minuti. Questo non mi esime dalla fatica delle verifica e della riscrittura, ma mi guida nell'intervenire prima su quelle aree dove l'indice di qualità è basso.
Ma questo framework è così potente, nella sua semplicità, che potrebbe essere utlizzato per capire, ad esempio, se la documentazione di prodotto di una macchina industriale rispetta le regole del nuovo Regolamento Macchine.
"Hey aspetta un attimo... tu sei un espertro di documentazione del software... che ne sai di Regolamento Macchine?"
Non c'è trucco e non c'è inganno: tutto dipende dal contesto di dominio che si fornisce all'AI e dalla conoscenza di dominio di colui che formula i criteri da verificare.
Questo è il secondo motivo per cui l'AI non può sostituire un umano: la conoscenza di dominio che serve sia a configurare il framework, sia a verificare le risposte fornite dall'AI.
E TUTTO QUESTO QUANTO MI COSTA?
E questa è un'altra conversazione. In questi ultimi mesi sono arrivate agli onori della cronaca decine di aziende che hanno bruciato in 3 mesi il budget di token di un anno. Su questo argomento non ho ricette. Ogni azienda deve fare le sue valutazioni. E deve capire dove sta il ROI. Io ho ottenuto tutto questo senza bruciare il denaro dell'azienda, perchè sapevo esattamente cosa volevo ottenere e sono stato in grado di scrivere un set di file markdown che imponevano all'AI paletti molto precisi. Non ho avuto bisogno di fare vibe coding, non ho dovuto fare 200 iterazioni "a caso", perchè sapevo tutto PRIMA. Ma tutto questo forse funziona solo per me e per il mio use case. Non saprei dire.
Peraltro, sto ancora limando e sperimentando.
Ma già ora lo stumento è abbastanza buono e veloce.
"E le allucinazioni?"
Quelle ci sono e ci saranno sempre. Quanto più disegni delle regole ben fatte e precise, tanto più puoi sperare che le allucinazioni diminuiscano, mai che possano essere eliminate.
Anche per questo la verifica FINALE prima della pubblicazione DEVE ESSERE DI UN UMANO.
PUBLISHING
E' la fase finale del mio lavoro. Per tutto quanto già detto, e per altri motivi tecnici che non sto qui ad illustrare, qui l'AI non entra, anche perchè comunque il livello di automazione dei processi di publishing è già molto elevato, efficace e testato.
Ecco un bell'esempio di dove si può fare a meno dell'AI.
Perchè sprecare token quando si dispone di processi già standardizzati, deterministici, automatici, testati da molti anni e affidabili?
Per il resto, al prossimo articolo.
Nessun commento:
Posta un commento