Dentro un Transformer: attention, MLP e residual stream spiegati per chi integra LLM in produzione
GPT-4 ha ~1.800 miliardi di parametri; il modello legge il prompt in quattro componenti: embedding lookup, multi-head self-attention, MLP, unembedding+softmax. L'attention fa parlare i token fra loro, l'MLP inietta fatti, il residual stream è un nastro che trasporta i vettori ricorsivamente per decine di transformer block. Capire questo rende prevedibili allucinazioni, dipendenza dal prompt, sensibilità all'ordine. Continua a leggere
Ultima modifica:
Ho integrato quattro gestionali italiani diversi con applicazioni Laravel: ognuno aveva una API SOAP degli anni 2000 con documentazione parziale e comportamenti non documentati. Vi racconto il pattern adapter che uso per isolare l'integrazione dal codice applicativo e come gestire le incongruenze dei dati tra sistemi. 
Un'applicazione Laravel con la logica di business nei controller e le chiamate al database direttamente nei Model è impossibile da testare correttamente. Ho refactorizzato un gestionale HR verso l'architettura esagonale: il dominio ora è testabile senza database, e cambiare da MySQL a PostgreSQL ha richiesto un solo adapter. 
Ogni codebase PHP legacy che eredo ha la stessa peste: costanti integer o stringhe magiche per rappresentare stati di business. ORDINE_STATO_1, ORDINE_STATO_2. Con PHP 8 Enums, ho modernizzato un sistema ordini trasformando 40 costanti sparse in enum tipizzati con metodi di dominio. Il codice è diventato leggibile. 
La dependency injection è il pattern che più di ogni altro determina la testabilità del codice PHP. Vi mostro i pattern avanzati che uso in progetti complessi: constructor promotion di PHP 8, binding a interfaccia, lazy proxy per servizi costosi e come scrivere test che non dipendono dall'implementazione concreta. 
DDD viene spesso presentato come una soluzione per tutti i problemi architetturali, ma in pratica richiede una comprensione profonda del dominio di business. Vi racconto come l'ho applicato a un'applicazione assicurativa PHP, quali parti del pattern hanno funzionato e quali ho abbandonato come over-engineering. 
Un gestionale ordini con 14 side effect per ogni conferma d'ordine: email, aggiornamento magazzino, contabilità, notifiche. Tutto in un controller. Ho refactorizzato verso event-driven: un evento OrderConfirmed, undici handler indipendenti, deployment graduale. Il codice è passato da ingestibile a modificabile.