Anthropic prompt caching workspace-level: ridurre il 95% dei costi API su un RAG aziendale
Dal 5 febbraio 2026 Anthropic offre prompt caching a livello di workspace, con cache hit al 10% del prezzo input standard. Ho migrato il mio chatbot RAG aziendale (system prompt da 3.800 token, 340 documenti retrieval context) e misurato un risparmio del 95% sulla parte prompt ricorrente. Ti racconto passo passo la migrazione, gli errori che ho fatto con la cache invalidation, e come stackare caching + batch per arrivare al minimo teorico. Continua a leggere
Ultima modifica:
Qdrant 1.15 porta asymmetric quantization in produzione: puoi comprimere i vettori a 1,5 bit (24x compressione) mantenendo scalar query alla risoluzione piena. Sul dataset da 180k embedding della mia sandbox, la RAM residente del vector DB è passata da 1,6 GB a 170 MB con recall@10 in calo di soli 0,8 punti. Tutorial completo: setup, configurazione Compose con binding, migrazione da uncompressed, benchmark. 
Se il RAG aziendale fatica a trovare i documenti giusti, il problema quasi mai è nell'LLM: è negli embedding. Modelli generalisti come ada-3 o multilingual-e5 ignorano sigle di settore, convenzioni interne, tecnicismi italiani. Tutorial su 180.000 paragrafi: da Word2Vec (Mikolov 2013) ai bi-encoder fine-tuned, valutazione recall@10 e nDCG, integrazione Qdrant e pgvector, costi, pattern di aggiornamento. 
Un chatbot RAG sulle procedure interne risponde correttamente al 75-85% delle domande frequenti senza escalation. Ma il self-hosted cambia tutto: nessun dato esce dall'azienda, compliance GDPR diretta, costi prevedibili. Ti mostro l'architettura completa: ingestione documentale, embedding con modelli locali, pgvector, Laravel per orchestrazione, frontend chat React, deployment su VPS Hetzner. 
Fine-tuning o RAG? La risposta dipende da 4 variabili: natura dei dati, frequenza di aggiornamento, budget, criticità della precisione. Ti mostro il framework decisionale che uso: RAG per knowledge base aggiornata frequentemente e controllo della fonte, fine-tuning per task specializzati ripetitivi e latenza critica. Con esempi dalla mia sandbox di prova dove ciascuna tecnica ha vinto. 
Un progetto legacy di 10+ anni ha migliaia di decisioni storiche invisibili: perché questa funzione si chiama così, perché quel campo accetta NULL, perché quel cron gira alle 3:27. Nella mia pipeline personale ho costruito un knowledge management AI-assisted che indicizza commit, issue, documentazione sparsa in embeddings e risponde a domande contestuali. Ti mostro l'architettura: ingestione multi-sorgente, memoria persistente cross-session, retrieval pesato per recency. 
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. 
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. 
Un RAG aziendale indicizza documenti interni e risponde alle domande. Se un attaccante inietta un documento nel corpus, può manipolare le risposte per tutti gli utenti. Ti racconto la metodologia di red team che applico: exfiltration di chunk sensibili, pivoting tra tenant multi-azienda, poisoning persistenti. Con tre proof-of-concept e il pattern di difesa applicativa. 
pgvector trasforma PostgreSQL in un database vettoriale senza infrastruttura aggiuntiva. Ho costruito un sistema di ricerca semantica per un catalogo prodotti da 50.000 articoli in Laravel: gli utenti cercano in linguaggio naturale, il sistema trova i prodotti pertinenti anche con terminologia diversa da quella del catalogo.