LaCulturaDelDato #207
Dati & algoritmi attraverso i nostri 5 sensi
For my English speaking friends, click here for the translated version
Ciao,
sono Stefano Gatti e questo è il duecentosettesimo numero della newsletter LaCulturaDelDato: dati & algoritmi attraverso i nostri 5 sensi. Le regole che ci siamo dati per questo viaggio le puoi trovare qui.
Ecco i cinque spunti del duecentosettesimo numero:
👃Investimenti in ambito dati e algoritmi. La regola del 9x di Gourville: perché non basta essere “un po’ meglio” (nemmeno con l’AI)
“Nel 2006, John Gourville ha pubblicato su Harvard Business Review un articolo intitolato “Eager Sellers and Stony Buyers“ che dovrebbe essere lettura obbligatoria per ogni founder nel mondo AI. Il suo risultato chiave: per convincere gli utenti a cambiare prodotto, la tua nuova soluzione deve essere nove volte migliore di quella che già usano.
Non due volte migliore. Non “dimostrabilmente superiore.” Nove volte.
Ecco perché. Gli utenti sopravvalutano ciò che già hanno di un fattore tre: la familiarità, la memoria muscolare, il senso di controllo. E le aziende sopravvalutano ciò che stanno offrendo di un fattore tre: perché l’hanno costruito loro, conoscono ogni funzionalità, ne vedono il potenziale. Tre per tre fa nove.
Questo genera quello che Gourville ha chiamato “un disallineamento di nove a uno, o 9x, tra ciò che gli innovatori pensano desiderino i consumatori e ciò che i consumatori vogliono davvero.” Le aziende AI si comportano come se il rilascio del loro prossimo modello facesse cambiare gli utenti. Annunciano miglioramenti nei benchmark come se dichiarassero vittoria. “Il nostro modello è il 12% migliore nei task di coding!” Bene. Ma è nove volte migliore? No? Allora resto dove sono.”
Questo è il cuore dell’approfondimento che ti consiglio di leggere perché racconta, al di là del fatto che il 9 sia davvero il fattore giusto da tenere in considerazione, una verità che spesso chi valuta start-up (e le start-up stesse) dimentica: conquistare un mercato esistente e i suoi clienti è molto più duro di quello che sembra. Non basta essere leggermente meglio, soprattutto se l’utente usa già un altro prodotto, ha un contratto in essere e, soprattutto, ha una buona esperienza di UX/UI. Ci dimentichiamo troppo spesso che gli utenti di un prodotto o servizio amano, almeno in larga maggioranza, la continuità d’uso e dell’esperienza, e valutano sempre di più il costo del cambiamento in termini di tempo. Ma il cuore (e il titolo) dell’articolo “UX Is Your Moat (And You’re Ignoring It)” mette giustamente al centro la user experience, che sta diventando, in modo forse troppo silenzioso, una delle barriere anche per i prodotti basati sull’AI. E questo è tanto più vero quanto la valutazione di un prodotto o servizio AI si sta spostando dalla sola efficacia del modello alla capacità anche di fornirgli il contesto migliore: cioè dati e informazioni.
Per fare un esempio concreto: le Skills, lanciate da Anthropic, o la facilità d’uso (e di caricamento dei documenti) di NotebookLM, sono esempi di come la UX stia diventando super importante anche per l’AI. E nell’articolo ci sono tanti altri casi del recente passato in cui questo è molto evidente.
E se vuoi, su questo tema, sentire il parere di un VC: Rex Woodbury, in questo post “In the Costco Era of Software, Design Is the Differentiator”, ribadisce e allarga il concetto a tutto il nuovo software.
🖐️Tecnologia (data engineering). Dal presente al futuro: DuckDB in SQL oggi, Lance/LanceDB per i lakehouse multimodali domani
Le architetture e le piattaforme dati all’interno delle organizzazioni si stanno ulteriormente complicando alla “faccia” di chi prevede che nel prossimo futuro anche i data-engineer saranno figure inutili 🙂. Infatti, oltre a dover riuscire a dismettere piattaforme legacy che continuano a gestire carichi importanti in produzione, si affiancano le piattaforme più recenti cloud-based e ora cominciano a nascere esigenze di piattaforme che supportano meglio, e in maniera più specifica, la nuova era agentica. E se qualcuno pensa che questa complessità possa essere gestita, essa stessa, da un agente, credo possa venire da Marte, non abbia vissuto un’ora in un’organizzazione complessa e non abbia mai scritto una riga di codice. A volte, dal vivo, ascolto un livello di banalizzazione su questi temi così alto che finisco per fare degli angry-incipit come questo ☹️ .
Gli approfondimenti che ti suggerisco oggi, se ti occupi di questi temi in azienda, sono molto utili e pratici: uno guarda al presente e uno al futuro, se vogliamo dirla così.
Partiamo ancorati al presente.
Se, come il sottoscritto, a volte finisci (per tradizione) a pensare in SQL, questo articolo sul sito del mitico database DuckDB ti mostra come fare preprocessing e feature engineering tutto in SQL, anche sfruttando alcune caratteristiche molto belle dell’SQL specifico di DuckDB. E il confronto, in termini di prestazioni, che viene fatto con la libreria scikit-learn è impressionante. E questo, oltre al fatto che il feature engineering su DuckDB ti può evitare spostamenti faticosi di dati.
Il secondo approfondimento guarda al futuro e arriva da Ben Lorica 罗瑞卡 e la sua bellissima newsletter GradientFlow. Lorica ci mostra che creare e manutenere un ambiente dati dove gli agenti possano essere efficaci non è esattamente la stessa cosa di un ambiente tradizionale.
Questo porta alla necessità di adottare sempre più lakehouse multimodali, con standard emergenti molto interessanti in termini di formato dati e di database multimodali. Lance e LanceDB in primis!
👂🏾Organizzazione e cultura dei dati e algoritmi nelle organizzazioni. Internet Archive si sta “accecando”: e noi stiamo perdendo la memoria del web 😬
Back to 85
A ottobre 2023 avevo ospitato nella newsletter Carola Frediani, e gli approfondimenti che ci aveva segnalato erano stati di gran lunga i più cliccati di quella puntata. È quindi tempo di fare un aggiornamento su quello che ci aveva segnalato e su quanto Carola, insieme al suo progetto collaborativo “Guerre di rete”, ha fatto nel frattempo.
Carola, in particolare, ci aveva segnalato come strumento per lei indispensabile Internet Archive, “che da anni fa un lavoro meritorio, utile e fondamentale per chi voglia tenere traccia di un panorama sempre più volatile e a rischio di mistificazioni.”
Purtroppo, anche a causa del tema dell’addestramento dell’AI, Internet Archive non se la sta passando molto bene. Infatti, per impedire alle intelligenze artificiali di addestrarsi gratuitamente sui propri contenuti, i grandi gruppi editoriali (come il New York Times e Condé Nast) hanno iniziato a bloccare i sistemi di salvataggio di Internet Archive, trattandolo non più come una biblioteca ma come una “falla” economica per lo scraping dei dati. Questa mossa difensiva sta rendendo l’archivio storico del web progressivamente cieco, creando enormi buchi nella memoria digitale proprio nel momento in cui l’informazione è più volatile. Il risultato è paradossale: per proteggere il copyright dall’AI, stiamo sacrificando l’unica copia di backup pubblica e universale della nostra storia recente.
“Pensano di creare un mondo in cui le aziende di AI non possano rubare le loro creazioni per addestrare i modelli; in realtà stanno creando un mondo in cui l’Internet Archive non può più catturare [la storia]...“ questa è la posizione dell’attivista Cory Doctorow raccontata in questo articolo su Pluralistic.
Per fortuna il progetto Guerre di rete se la sta passando decisamente meglio e continua ormai da un anno a sfornare articoli e approfondimenti di qualità. So che lo seguite in molti e che qualcuno di voi sta anche attivamente producendo contenuti validissimi. E non posso a questo punto non segnalarti “il manualetto di sicurezza digitale” pubblicato a fine gennaio proprio dal progetto Guerre di rete, come opera scritta a più mani dai più importanti animatori del progetto stesso. Come scritto nel post di lancio, “il manualetto è rivolto a due categorie (giornalisti e attivisti) essenziali per il funzionamento della democrazia e del dibattito pubblico, che troppe volte abbiamo visto essere target di attacchi informatici, sorveglianza, campagne d’odio e di molestie nel mondo, in Europa, in Italia.” Al di là del diminutivo con cui si presenta, l’opera è uno strumento utilissimo per tutti, dal taglio molto pratico. L’ho letto e l’ho trovato molto utile, soprattutto per spunti molto pratici a cui francamente non avevo mai pensato.
👀 Data Science. Tre letture sul Text-to-SQL: la bocciatura di Au, la riserva di ChatGPT, la mia scommessa sui metadati
Uno dei temi più dibattuti in quasi tutte le organizzazioni che lavorano tanto con i dati e hanno data expert è, in questo momento, l’efficacia degli LLM nel lavorare con SQL. Devo dire francamente che l’efficacia non può essere valutata in senso assoluto e da un’unica prospettiva: dipende da diverse variabili: complessità del database, ricchezza di metadati, complessità delle operazioni e, non ultimo, l’abilità e la conoscenza dell’SQL di chi usa queste soluzioni.
Senza questa premessa, il suggerimento di approfondimento su questo tema oggi sarebbe estremamente severo nel giudizio di efficacia. In realtà Randy Au, l’autore dell’articolo, è un grande esperto e utilizzatore del linguaggio e, per questo, il suo giudizio va letto da questa prospettiva. In sintesi, la sua opinione è che:
Text-to-SQL da zero è deludente: richiede così tanto contesto (schema, logica, metriche) che, se hai già tutte quelle informazioni, sei quasi arrivato a scrivere la query da solo.
Refactoring automatico di query complesse fallisce: per query più lunghe di 200 righe con logica articolata, gli LLM tendono a rompere la logica o a produrre output non equivalenti.
Esistono comunque quattro use case che funzionano bene:
Spiegare SQL esistente: ottimo per capire query complesse scritte da altri.
Traduzione tra dialetti SQL: risparmia tempo su sintassi specifiche.
Refactoring selettivo: funziona se isoli singole subquery invece dell’intera query.
Code completion utile: quando ha abbastanza contesto locale (es. file di lavoro con molte query precedenti).
Ho provato a dare l’articolo a ChatGPT 5.2 thinking e a chiedere un parere a lui che ti riporto:
“Per un profilo “SQL-first” come l’autore, è normale che l’LLM dia più valore come supporto cognitivo (spiegazione, traduzione dialetti, piccoli refactor locali) che come “autopilota”, perché i costi di trasferire contesto e vincoli superano spesso il costo di scrivere bene la query, e inoltre la correttezza che ti serve non è “sintattica” ma semantica e “di business”. La riserva è che la sua conclusione (“text-to-SQL è una follia”) vale per il text-to-SQL inteso come prompt ingenuo “scrivimi la query” senza un sistema intorno; appena metti attorno retrieval di schema e metriche, guardrail, esecuzione controllata e validazioni, il problema cambia natura e diventa più “ingegneria di prodotto” che magia linguistica, anche se resta difficile e pieno di edge case…. In pratica:
Funziona bene quando il dominio è ristretto, lo schema è ben documentato, e puoi recuperare automaticamente (o far scegliere) tabelle, join path e definizioni di metrica.
Si rompe quando la domanda è ambigua (“vendite” quale metrica?), quando ci sono più interpretazioni valide, o quando servono euristiche da “tribal knowledge” che non stanno nello schema.”
Personalmente (e riprendo la parola) penso che il tema centrale stia più nei metadati a disposizione (del database) che nella capacità di porre la domanda in termini di business. Quello che ho provato a fare con profitto, in alcuni casi, e che sia Au sia ChatGPT sembrano essersi dimenticati, è usare proprio gli LLM per creare metadati e contesto, al fine di avere strumenti Text-to-SQL (umani e artificiali) più efficienti.
Se hai un’opinione e hai fatto prove, sono molto curioso di sapere qual è la tua opinione e la tua esperienza!
👅Etica & regolamentazione & impatto sulla società. Agency is eating the world: o agisci, o subisci?
“Il mio intero modello del mondo è collassato in un singolo bit: agency, o nessuna agency. La transizione richiederà tempo, e sarà tutt’altro che indolore. Le istituzioni costruite attorno alle credenziali non se ne andranno velocemente. Il middle management combatterà per mantenere l’organico perché ci vorrà tempo per allontanarsi dall’idea che più persone che lavorano su un problema segnalano un problema più importante. Scuole e college impiegheranno un po’ ad adattare i loro metodi di insegnamento e contenuti. Solo la competizione di mercato dal basso verso l’alto forzerà il cambiamento.“
Questa conclusione, dell’approfondimento che ti consiglio oggi, è una di quelle frasi che non ti lasciano in pace perché mette un’etichetta relativamente semplice su un fenomeno complicato: stiamo entrando in un’epoca in cui il valore non sta solo in quello che sai, ma in quanto velocemente riesci a trasformarlo in realtà.
A scriverlo è Gian Segato, oggi in Anthropic e con un percorso che passa dall’imprenditoria (ha fondato Uniwhere, poi venduta) fino al lavoro in aziende “nel cuore” del software e dell’AI come Replit. Non è un ragionamento da osservatore esterno: è uno sguardo da dentro, da chi ha visto quanto velocemente strumenti e modelli stiano comprimendo tempi e barriere. Il punto, per Segato, è che l’AI sta rendendo molte competenze più “accessibili”: attività che prima richiedevano anni di mestiere oggi possono essere avviate da persone meno esperte, se hanno energia, iterazione e la capacità di sporcarsi le mani. Non vuol dire che gli specialisti spariranno; vuol dire che resteranno indispensabili soprattutto dove l’errore costa caro e serve altissima precisione. Ma in tantissimi altri ambiti, dove puoi testare, sbagliare, riprovare, vince chi ha agency: chi non aspetta il permesso, chi prende un obiettivo e lo porta avanti, chi usa gli strumenti come leve invece che come stampelle.
Ed è qui che la traduzione si inceppa. “Agency” in italiano non è “autonomia” e non è solo “iniziativa”. È una miscela di volontà d’azione, responsabilità, intraprendenza e capacità di attraversare ostacoli sociali e organizzativi. E fa ancora più sorridere (e riflettere) che nel tech chiamiamo “agenti” dei software che, per definizione, non hanno quella cosa lì: possono eseguire, ma non desiderano, non scelgono, non insistono. Il termine “agent” suona potente, ma spesso descrive strumenti che sono bravissimi… a fare ciò che gli viene chiesto.
📅 Nel Mio Calendario (passato, presente e futuro)
Sabato 7 marzo, a partire dalle 18:30, sarò ospite insieme a Donata Columbro all’evento organizzato a Rovereto dalla community digitale trentina Speck&Tech per festeggiare i suoi 10 anni di attività.
Il titolo del mio intervento sarà: “Il dato (e l’esperienza) come valore per costruire futuri preferibili”. Se vuoi esserci, l’evento è gratuito ma è necessario iscriversi qui:
Se hai ulteriori suggerimenti e riflessioni sui temi di questo numero o per migliorare questa newsletter scrivimi (st.gatti@gmail.com) o commenta su substack.
Se ti è piaciuta e non sei ancora iscritto lascia la tua mail qui sotto e aiutami a diffonderla!
Alla prossima!



Vissuto sulla mia pelle: Text-to-sql senza un semantic layer o informazioni di contesto da asset vari (ad es. Data contract) in contesti business non funziona. Non è un tema di mancanza di capacità dei modelli (figuriamoci) quanto dell'informazione latente che è vincolante per use case reali