pgvector in produzione: indici HNSW, IVFFlat e tuning per applicazioni AI con dataset medi
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. Continua a leggere
Ultima modifica:
Ho simulato uno scenario ransomware per un cliente manifatturiero con 60 dipendenti: ho mappato tutti i sistemi critici, calcolato il costo orario del downtime e testato i backup. I risultati erano scomodi: 18 ore per ripristinare i sistemi principali, 40 ore per i secondari, backup di tre settimane fa. Ecco cosa abbiamo fatto. 
Un e-commerce torinese con 47.000 righe di PHP 5.6 procedurale, 340 chiamate mysql_connect(), un hosting che aveva annunciato la rimozione di PHP 5.6 entro 60 giorni, e un titolare che non poteva permettersi downtime. In quattro settimane l'ho migrato a PHP 8.4 senza riscrivere l'applicazione: ecco il metodo, gli strumenti, le breaking changes reali e le decisioni che hanno fatto la differenza. 
L'ecosistema AI è diventato un target di supply chain attack: modelli pubblicati su Hugging Face con backdoor, librerie Langchain/LlamaIndex con transitive dependencies non audit-abili, update automatici che introducono drift di comportamento. Ti mostro la strategia di hardening che applico: pinning dei modelli a digest SHA-256 (non tag), audit automatico delle dipendenze via Snyk/Dependabot, integrity checks su ogni deploy, separazione di ambienti con policy di network egress controllato. 
I worker Laravel Horizon di un cliente consumavano 500MB di RAM dopo 6 ore di esecuzione e venivano killati automaticamente. Il memory leak non era ovvio: un event listener registrato globalmente teneva riferimenti a ogni job processato. Vi mostro il processo di diagnosi con Blackfire e le strategie di correzione. 
Un portale di notizie Laravel con 50.000 utenti al giorno mandava in ginocchio il database MySQL ogni volta che arrivava un articolo virale. Ho implementato tre livelli di cache: in-process (array driver), Redis per i dati di business, Nginx proxy cache per le risposte HTTP. Il database ora riceve il 3% delle richieste originali. 
Dopo 18 mesi di utilizzo sistematico di LLM per codice PHP in produzione, ho una visione precisa dei limiti reali. L'AI eccelle nel boilerplate, nel refactoring locale, nella spiegazione del codice. Fallisce sistematicamente sul ragionamento architetturale, sulla coerenza a lungo termine e sulle interazioni di sistema complesse. 
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. 
Mettere un LLM in produzione senza monitoring è come deployare un'applicazione PHP senza log. Ho costruito un layer di observability per tre sistemi AI di clienti: cost tracking per richiesta, latenza p95, valutazione automatica della qualità delle risposte e alert su comportamenti anomali. Vi mostro gli strumenti open source che uso. 
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.