Andrej Karpathy: lezioni di deep learning per portare l'AI nei prodotti

Perché il deep learning spesso sembra difficile da usare nei prodotti reali

Una demo di deep learning può sembrare magia. Un modello scrive un paragrafo pulito, riconosce un oggetto o risponde a una domanda complessa. Poi provi a trasformare quella demo in un pulsante che le persone premono ogni giorno, e le cose si complicano. Lo stesso prompt si comporta diversamente, gli edge case si accumulano e il momento “wow” diventa un ticket di supporto.

Questa distanza è il motivo per cui il lavoro di Andrej Karpathy ha fatto presa sui costruttori. Ha promosso una mentalità in cui le reti neurali non sono artefatti misteriosi: sono sistemi che progetti, testi e mantieni. I modelli non sono inutili. È che i prodotti richiedono coerenza.

Quando i team dicono di volere un’AI “pratica”, di solito intendono quattro cose:

• Ripetibile: si comporta in modo prevedibile su input comuni, non solo su demo curate.
• Misurabile: puoi definire “buono” con un numero, non con una sensazione.
• Manutenibile: puoi aggiornare dati, prompt o modelli senza rompere tutto.
• Operativo: puoi monitorare fallimenti, costo, latenza e qualità dopo il rilascio.

I team faticano perché il deep learning è probabilistico e sensibile al contesto, mentre i prodotti sono giudicati sull’affidabilità. Una chatbot che risponde bene all'80% delle domande può comunque sembrare rotta se il restante 20% risponde con confidenza, sbagliando e difficile da rilevare.

Prendi un assistente di “risposta automatica” per il supporto clienti. Funziona bene su pochi ticket selezionati. In produzione, i clienti scrivono in slang, allegano screenshot, mescolano lingue o chiedono su casi di policy. Ora servono protezioni, chiare modalità di rifiuto e un modo per misurare se la bozza ha davvero aiutato un agente.

Lavoro iniziale: trattare le reti neurali come ingegneria, non magia

Molti hanno scoperto Karpathy attraverso esempi pratici, non matematica astratta. Anche i progetti iniziali facevano un punto semplice: le reti neurali diventano utili quando le tratti come software che puoi testare, rompere e riparare.

Invece di fermarsi a “il modello funziona”, l’attenzione si sposta sul farlo funzionare su dati disordinati e reali. Questo include pipeline di dati, run di training che falliscono per motivi banali e risultati che cambiano modificando una piccola cosa. In quel mondo, il deep learning smette di suonare mistico e inizia a sembrare ingegneria.

Un approccio alla Karpathy è meno fatto di trucchi segreti e più di abitudini:

• Parti da una baseline che puoi battere, anche se è semplice.
• Scegli una metrica che definisca “meglio” vs “peggio”.
• Cambia una cosa alla volta così sai cosa ha causato il risultato.
• Ispeziona gli errori e gli esempi, non solo il punteggio finale.

Questa base è importante perché l’AI di prodotto è principalmente lo stesso gioco, solo con più responsabilità. Se non costruisci l’artigianato iniziale (input chiari, output chiari, run ripetibili), rilasciare una funzionalità AI diventa un tiro al buio.

Rendere le reti neurali comprensibili per gli ingegneri che le mantengono

Una parte importante dell’impatto di Karpathy è stata trattare le reti neurali come qualcosa su cui puoi ragionare. Spiegazioni chiare trasformano il lavoro da “fede” a ingegneria.

Questo conta per i team perché chi spedisce il primo prototipo spesso non è chi lo mantiene. Se non puoi spiegare cosa fa un modello, probabilmente non puoi debuggarlo e di certo non puoi supportarlo in produzione.

Spiegalo come se dovessi mantenerlo

Forza la chiarezza presto. Prima di costruire la funzionalità, scrivi cosa vede il modello, cosa produce e come capire se sta migliorando. La maggior parte dei progetti AI fallisce sulle basi, non sulla matematica.

Una breve checklist che ripaga dopo:

• Qual è l’esatto input e output (formato, limiti, redazioni)?
• Quale baseline devi battere (regole, ricerca, template o un modello più piccolo)?
• Cosa significa “buono” (un numero, una rubrica o entrambi)?
• Quali fallimenti sono inaccettabili (sicurezza, privacy, tono del brand)?
• Chi revisiona i risultati e con quale frequenza?

La riproducibilità fa parte della spiegazione

Il pensiero chiaro si manifesta in esperimenti disciplinati: uno script che puoi rilanciare, dataset di valutazione fissi, prompt versionati e metriche loggate. Le baseline ti mantengono onesto e rendono il progresso visibile.

Dai prototipi alla produzione: cosa cambia quando si rilascia

Un prototipo dimostra che un'idea può funzionare. Una funzionalità rilasciata dimostra che funziona per persone reali, in condizioni disordinate, ogni giorno. Questo divario è dove molti progetti AI si arenano.

Una demo di ricerca può essere lenta, costosa e fragile, purché dimostri capacità. In produzione le priorità si capovolgono. Il sistema deve essere prevedibile, osservabile e sicuro anche quando gli input sono strani, gli utenti impazienti e il traffico aumenta.

I vincoli di cui ti preoccupi all’improvviso

In produzione la latenza è una caratteristica. Se il modello impiega 8 secondi, gli utenti abbandonano o ripremono il pulsante, e paghi per ogni retry. Anche il costo diventa una decisione di prodotto, perché una piccola modifica al prompt può raddoppiare la fattura.

Il monitoraggio è non negoziabile. Devi sapere non solo che il servizio è up, ma che gli output restano entro una qualità accettabile nel tempo. Shift nei dati, comportamenti utenti nuovi e cambi upstream possono degradare le performance senza generare errori.

I controlli di sicurezza e policy passano da “bello da avere” a obbligatori. Devi gestire richieste dannose, dati privati e edge case in modo coerente e testabile.

I team tipicamente finiscono per rispondere alle stesse domande:

• Qual è il tempo di risposta massimo accettabile e il costo per richiesta?
• Qual è il fallback quando il modello fallisce o va in timeout?
• Quali metriche definiscono la qualità e quali soglie generano allarmi?
• Come prevenire output non sicuri o non conformi?
• Come rollbackare rapidamente se la qualità cala?

Serve più di abilità sul modello

Un prototipo può essere costruito da una persona. Lo shipping di solito richiede che il product definisca il successo, che i dati validino input e set di valutazione, che l’infrastruttura lo esegua in modo affidabile e che la QA testi i modelli di fallimento.

“Funziona sulla mia macchina” non è un criterio di rilascio. Un rilascio significa che funziona per gli utenti sotto carico, con logging, guardrail e un modo per misurare se aiuta o danneggia.

La cultura ingegneristica: assunzioni, baseline e iterazione

L’influenza di Karpathy è culturale, non solo tecnica. Ha trattato le reti neurali come qualcosa che si può costruire, testare e migliorare con la stessa disciplina applicata a qualsiasi sistema ingegneristico.

Si parte scrivendo le assunzioni prima di scrivere codice. Se non riesci a dire cosa deve essere vero perché la funzione funzioni, non sarai in grado di debuggarla dopo. Esempi:

• “Gli utenti accetteranno una risposta suggerita se è corretta e corrisponde al loro tono.”
• “È richiesta una latenza sotto gli 800 ms o le persone smettono di usarla.”

Sono affermazioni testabili.

Le baseline vengono dopo. Una baseline è la cosa più semplice che potrebbe funzionare ed è il tuo controllo di realtà. Può essere regole, un template di ricerca o anche “non fare nulla” con una buona UI. Baseline solide ti proteggono dal passare settimane su un modello elegante che non batte qualcosa di semplice.

L’instrumentation rende possibile iterare. Se guardi solo le demo, navighi a vista. Per molte funzionalità AI, un piccolo set di numeri ti dice già se stai migliorando:

• Adozione (chi la prova e continua a usarla)
• Qualità (tasso di accettazione, modifiche prima dell’invio, pollice su/giù)
• Velocità (latenza e tempo al primo output utile)
• Costo (token, compute, tempo di revisione umana)
• Sicurezza (violazioni di policy, fughe di dati sensibili, tentativi di jailbreak)

Poi itera in cicli ristretti. Cambia una cosa, confrontala con la baseline e tieni un registro semplice di cosa hai provato e cosa ha mosso. Se il progresso è reale, si vede in un grafico.

Passo dopo passo: un workflow semplice per rilasciare una funzionalità AI

Lo shipping dell'AI funziona meglio quando lo tratti come ingegneria: obiettivi chiari, una baseline e loop di feedback rapidi.

1. Dichiara il problema utente in una frase. Scrivilo come un reclamo che potresti sentire da una persona reale: “Gli agenti di supporto impiegano troppo tempo a scrivere risposte a domande comuni.” Se non puoi dirlo in una frase, la funzionalità è probabilmente troppo grande.

2. Scegli un risultato misurabile. Prendi un numero che puoi tracciare settimanalmente. Scelte buone includono tempo risparmiato per attività, tasso di accettazione della prima bozza, riduzione delle modifiche o tasso di deflessione dei ticket. Decidi cosa significa “abbastanza buono” prima di costruire.

3. Definisci la baseline che devi battere. Confronta con un template semplice, un approccio basato su regole o “solo umano”. Se l'AI non batte la baseline sulla tua metrica scelta, non rilasciare.

4. Progetta un piccolo test con dati rappresentativi. Raccogli esempi che corrispondono alla realtà, inclusi i casi sporchi. Tieni un piccolo set di valutazione che non “alleni mentalmente” rileggendolo ogni giorno. Scrivi cosa conta come pass e cosa come fallimento.

5. Rilascia dietro un flag, raccogli feedback e iterare. Inizia con un piccolo gruppo interno o una piccola percentuale di utenti. Logga input, output e se ha aiutato. Risolvi prima la modalità di fallimento principale, poi riesegui lo stesso test per vedere il progresso reale.

Un pattern pratico per strumenti di redazione: misura “secondi per inviare” e “percentuale di bozze usate con modifiche minime”.

Assunzioni chiare e output misurabili (cosa scrivere)

Molti fallimenti di funzionalità AI non sono fallimenti del modello. Sono “non ci siamo mai messi d'accordo su cosa significhi successo”. Se vuoi che il deep learning sembri pratico, scrivi le assunzioni e le misure prima di scrivere altri prompt o addestrare altri modelli.

Inizia con assunzioni che possono rompere la tua funzionalità in uso reale. Quelle comuni riguardano dati e persone: il testo di input è in una lingua, gli utenti chiedono una sola intenzione per volta, la UI fornisce contesto sufficiente, gli edge case sono rari e i pattern di ieri saranno ancora veri il mese prossimo (drift). Scrivi anche cosa non gestirai ancora, come sarcasmo, consulenza legale o documenti lunghi.

Trasforma ogni assunzione in qualcosa che puoi testare. Un formato utile è: “Dato X, il sistema deve fare Y, e lo possiamo verificare con Z.” Mantienilo concreto.

Cinque cose da scrivere su una pagina:

• Input: cosa vede il modello (campi, limiti, redazioni) e cosa significa “abbastanza pulito”
• Contratto di output: cosa deve restituire (formato, tono, azioni consentite)
• Valutazione offline: un piccolo set etichettato con regole di punteggio (pass/fail più una metrica)
• Metrica online: cosa fanno gli utenti (tasso di accettazione, modifiche, tempo risparmiato, ticket riaperti)
• Guardrail: quando rifiutare, chiedere chiarimenti o ricorrere a un flusso più semplice

Tieni offline e online separati di proposito. Le metriche offline ti dicono se il sistema ha imparato il compito. Le metriche online dicono se la funzionalità aiuta le persone. Un modello può andare bene offline e comunque infastidire gli utenti perché è lento, troppo sicuro di sé o sbaglia nei casi importanti.

Definisci “abbastanza buono” come soglie e conseguenze. Esempio: “Offline: almeno l'85% corretto sul set di valutazione; Online: 30% delle bozze accettate con modifiche minime.” Se non raggiungi una soglia, decidi in anticipo cosa succede: tienilo dietro un toggle, riduci rollout, instrada i casi a bassa confidenza a un template o metti in pausa per raccogliere più dati.

Errori comuni quando i team aggiungono AI a un prodotto

I team spesso trattano una funzionalità AI come una normale modifica UI: la rilasciano, vedono cosa succede e regolano dopo. Questo fallisce rapidamente perché il comportamento del modello cambia con i prompt, il drift e piccoli aggiustamenti di configurazione. Il risultato è molto sforzo senza prova chiara che abbia aiutato.

Una regola pratica è semplice: se non sai nominare la baseline e la misurazione, non stai ancora rilasciando.

I modi di fallimento più comuni:

• Lanciare senza una baseline non-AI, così il miglioramento non è dimostrabile.
• Inseguire qualità ignorando latenza e costo (un +3% non vale 5x più lento).
• Affidarsi a feedback vaghi (“gli utenti lo apprezzano”) invece che a instrumentazione.
• Sintonizzare su un test piccolo o selezionato che non rispecchia il traffico reale.
• Non avere un piano di rollback quando un prompt o un aggiornamento del modello produce output strani.

Un esempio concreto: aggiungi AI per redigere risposte di supporto. Se tracci solo i pollici su potresti perdere che gli agenti impiegano più tempo a rivedere le bozze, o che le risposte sono accurate ma troppo lunghe. Misure migliori sono “percentuale inviate con modifiche minime” e “mediana del tempo per invio”.

Checklist rapida prima del rilascio

Tratta il giorno del rilascio come un handoff ingegneristico, non come una demo. Dovresti saper spiegare, in parole semplici, cosa fa la funzionalità, come sai che funziona e cosa farai quando si romperà.

Prima di spedire, assicurati di avere:

• Una frase che spiega il problema e utenti target chiari.
• Una baseline misurata (anche semplice).
• Una metrica online primaria legata al valore utente, più log che catturano input, output e outcome.
• Una revisione di sicurezza: modalità probabili di fallimento, chi viene danneggiato e cosa fa la UI (avvisa, blocca, chiede conferma).
• Un piano di rollback con un owner: cosa scatena il rollback e cosa controlli nella prima ora.

Tieni anche un set di valutazione offline che assomigli al traffico reale, includa edge case e resti stabile abbastanza da poter confrontare le settimane. Quando cambi prompt, modelli o pulizia dei dati, riesegui lo stesso set e vedi cosa è cambiato.

Scenario di esempio: rilasciare una funzionalità di redazione per il supporto

Un team di supporto vuole un assistente che rediga risposte all'interno della vista del ticket. L'agente non invia i messaggi automaticamente. Il sistema suggerisce una bozza, evidenzia i fatti chiave usati e chiede all'agente di rivedere e modificare prima dell'invio. Questa singola scelta mantiene basso il rischio mentre impari.

Inizia decidendo cosa significa “migliore” in numeri. Scegli outcome che puoi misurare dal primo giorno usando i log esistenti:

• Tempo medio di gestione (da aperto a risolto)
• Tasso di modifica (quanto gli agenti cambiano le bozze prima dell'invio)
• Tasso di escalation (ticket inviati a livelli superiori)
• Tasso di riapertura (ticket riaperti entro 7 giorni)
• Punteggio di soddisfazione cliente (se già lo tracci)

Prima di introdurre un modello, imposta una baseline noiosa ma reale: template salvati più uno strato semplice di regole (rileva rimborso vs spedizione vs reset password e precompila il template migliore). Se l'AI non batte quella baseline, non è pronta.

Esegui un piccolo pilot. Rendilo opt-in per pochi agenti, limitato a una categoria di ticket (es. stato ordine). Aggiungi feedback rapido su ogni bozza: “utile” o “non utile”, più una breve motivazione. Cattura cosa l'agente ha modificato, non solo se ha cliccato un pulsante.

Definisci i criteri di rilascio in anticipo per non indovinare dopo. Per esempio: il tempo di gestione migliora del 10% senza aumentare escalation o riaperture e gli agenti accettano bozze con modifiche minime almeno nel 30% dei casi.

Decidi anche cosa scatena il rollback: un picco di escalation, un calo della soddisfazione o errori ripetuti di policy.

Prossimi passi: applica queste lezioni al tuo prossimo rilascio AI

Scegli un'idea AI che puoi spedire in 2–4 settimane. Tienila abbastanza piccola da poterla misurare, debuggarla e rollbackare senza drammi. L'obiettivo non è dimostrare che il modello è intelligente; è rendere il risultato utente ripetutamente migliore di quello che hai già.

Trasforma l'idea in una pagina: cosa fa la funzionalità, cosa non fa e come saprai che funziona. Includi una baseline e la metrica esatta che traccerai.

Se vuoi andare veloce sull'implementazione, Koder.ai (koder.ai) è pensato per creare app web, server e mobile tramite un'interfaccia chat, con funzionalità come snapshot/rollback ed esportazione del codice sorgente quando ti serve un controllo più profondo.

L'abitudine da mantenere è semplice: ogni cambiamento AI dovrebbe avere un'assunzione scritta e un output misurabile. È così che il deep learning smette di sembrare magia e diventa lavoro che puoi consegnare.