Vocabolario AI 2026: i concetti tecnici che un decisore IT deve distinguere davvero
Quando un vendor ti propone un progetto AI per la tua azienda, sa distinguere pretraining da fine-tuning? Sa perché Mixture of Experts cambia i costi di inferenza di un ordine di grandezza? Sa che un benchmark MMLU 5-shot non è comparabile con un 25-shot? Ho passato in rassegna i 28 concetti tecnici che nei contratti enterprise del 2026 vedono più confusione, con distinzioni rigorose per non farsi vendere fumo e per costruire domande operative ai fornitori. Continua a leggere
Ultima modifica:
Il primo giorno su un progetto legacy è sempre disorientante: migliaia di file, zero documentazione, tempo limitato. Ho costruito un agente AI con Claude API e tool use per automatizzare l'assessment iniziale: chunking intelligente, navigazione filesystem, generazione di report strutturato con priorità. Ti mostro l'architettura, i prompt che uso, la gestione del contesto lungo e il controllo dei costi. 
Un'applicazione AI consumer-facing richiede un SDK TypeScript robusto lato client: streaming SSE che gestisce reconnect su disconnessione rete, error recovery discriminando errori transitori da permanenti, cost tracking per mostrare il consumo utente, tipizzazione forte sugli output strutturati del backend. Ti mostro l'architettura dell'SDK che ho costruito come libreria interna: API pulita, zero dipendenze browser, supporto React/Vue/vanilla, pattern di ripresa sessione dopo navigazione. 
PHP e Node sono ottimi per la logica di dominio, ma come inference gateway per LLM sotto carico soffrono: event loop Node saturabile con chiamate lente, PHP-FPM worker-bound con decine di secondi di attesa per token streaming. Go risolve entrambi: concorrenza nativa con goroutine, latenza sub-10ms sui routing decision, gestione elegante di streaming SSE verso migliaia di client paralleli. Ti mostro l'architettura gateway Go che ho costruito come front-end unificato per modelli LLM eterogenei. 
Partire da 5% di copertura test su un codebase legacy è demoralizzante. Portarla al 70% in 3 mesi è realistico con LLM nell'anello di supporto - ma solo se il processo è strutturato. Ti mostro il workflow che ho testato: LLM genera characterization test sul comportamento esistente, sviluppatore verifica, itera. Con catalogo degli anti-pattern LLM tipici (test che passano sempre, assertion inutili) e come rilevarli. 
pgvector trasforma PostgreSQL in un vector database capace. Ma la scelta dell'indice e il tuning dei parametri fanno la differenza tra latenza di 50ms e 5 secondi. Ti mostro il confronto pratico sul dataset di benchmark che uso nel mio laboratorio: quando usare HNSW, quando IVFFlat, come dimensionare m/ef_construction, trade-off memoria vs speed, integrazione con Laravel per pipeline di embedding e ricerca semantica. 
La code review umana è collo di bottiglia in molti team piccoli. Gli LLM possono affiancare i reviewer senior, non sostituirli, a condizione che la pipeline sia ben progettata. Ti mostro l'integrazione GitHub Actions + Claude API che ho implementato: prompt strategy per ridurre falsi positivi, esclusione di file sensibili, combinazione con PHPStan per ridurre rumore, controllo dei costi per PR. 
Le chiamate LLM sono lente (5-30 secondi), costose (€ per token), soggette a errori transitori (rate limit, 529 overloaded). Farle sincrone nel ciclo HTTP è un anti-pattern garantito. La pipeline giusta passa da Horizon con job dedicati: retry con backoff esponenziale per errori transitori, cost tracking per job con alerting anomalie, timeout management che distingue tra retry-safe e fatal. Ti mostro l'architettura completa con codice reale che uso nella mia pipeline personale su Claude API. 
Il servizio assistenza di un cliente rispondeva alle stesse 50 domande 100 volte al settimana. Ho costruito un chatbot RAG su 200 documenti interni (manuale prodotto, FAQ, procedure): il sistema risponde correttamente al 78% delle domande senza escalation umana. Self-hosted su VPS, zero dati verso API esterne. 
Containerizzare un LLM self-hosted non è come containerizzare PHP-FPM. Serve nvidia-container-toolkit per passthrough GPU, gestione dei modelli come persistent volume, orchestrazione di modelli multipli (uno generalista, uno specializzato, un embedding model) con routing intelligente per caso d'uso. Ti mostro l'architettura Docker Compose che uso su VPS GPU: configurazione GPU passthrough, persistent cache, health check, monitoring dei VRAM consumption e risposta alle OOM.