Lo Stack AI che Usiamo in Produzione: Modelli e Pipeline

Il panorama del tooling AI all'inizio del 2026 è travolgente. Ogni settimana porta un nuovo framework, un nuovo modello, un nuovo vector database che afferma di essere il più veloce, e un nuovo layer di orchestrazione che promette di semplificare tutto. Per i leader ingegneristici che cercano di costruire sistemi AI di produzione, il rapporto rumore-segnale non è mai stato peggiore. Lo sappiamo perché lo stiamo navigando noi stessi -- spedendo prodotti alimentati da AI e sistemi agent per clienti in fintech, energia e governo mentre il terreno si muove sotto di noi ogni trimestre.

Questo articolo è il nostro tentativo di tagliare quel rumore. Stiamo condividendo i tool, modelli e decisioni architetturali specifici che compongono il nostro stack AI di produzione -- cosa usiamo, perché l'abbiamo scelto, e cosa abbiamo deliberatamente scelto di non usare. Questo non è un framework teorico o un grafico di confronto vendor. È lo stack che gira in produzione oggi, servendo utenti reali, gestendo edge case reali, e costando soldi reali. Lo condividiamo perché la trasparenza costruisce fiducia, e perché vorremmo che più team facessero lo stesso. Quando i vendor pubblicano benchmark, ottimizzano per la demo. Quando i practitioner condividono i loro stack, ottimizzano per l'onestà.

Il Layer dei Modelli: Scegliere i Tuoi LLM

Eseguiamo una strategia multi-modello -- non perché sia trendy, ma perché nessun singolo modello è la scelta giusta per ogni task in un sistema di produzione. Sbagliare la strategia del modello significa sovra-spendere per capacità che non ti servono o sotto-performare sulla qualità che gli utenti si aspettano.

Claude: Il Nostro Modello di Ragionamento Primario

Claude di Anthropic è il nostro modello primario per ragionamento complesso, analisi di contesto lungo e seguimento di istruzioni sfumate. Lo usiamo per decisioni di orchestrazione agent, analisi di documenti su contratti di 50-100 pagine, generazione e revisione codice, e qualsiasi task dove seguire prompt di sistema dettagliati precisamente conta più della velocità grezza. La capacità di extended thinking di Claude è particolarmente preziosa per sistemi agent -- quando un agent deve pianificare un workflow multi-step, la differenza di qualità rispetto ad altri modelli è misurabile. Ci affidiamo anche all'affidabilità dell'output strutturato di Claude. I sistemi di produzione non possono tollerare JSON malformato, e per settori regolamentati questa affidabilità è un requisito rigido.

GPT-4o e Modelli Open-Source

GPT-4o di OpenAI serve come nostro fallback e nostra scelta per task multimodali che coinvolgono analisi di immagini e pattern complessi di function calling. Lo manteniamo non come copertura contro vendor lock-in -- anche se questo è un beneficio -- ma perché certi task genuinamente performano meglio su di esso. Fingere che un modello vinca ovunque è ideologia, non ingegneria.

Per task cost-sensitive ad alto volume, deployiamo modelli open-source -- principalmente Llama 3 di Meta e Mistral. Questi gestiscono classificazione, estrazione entità e summarization semplice dove i costi dei modelli frontier sono ingiustificabili. Un task di classificazione che gira 50.000 volte al giorno costa circa $100 al mese su Llama 3 versus $3.000 su Claude. La differenza di qualità per classificazione binaria è trascurabile; la differenza di costo non lo è. Self-hostiamo usando vLLM per inference serving, dandoci controllo su latenza, availability e data residency.

Orchestrazione: Collegare Gli Agents Insieme

Il layer di orchestrazione è ciò che trasforma chiamate individuali al modello in workflow agent coerenti. Gestisce stato, instrada decisioni, gestisce chiamate tool e recupera da fallimenti. Fare bene questo layer è la differenza tra una demo che impressiona e un sistema che funziona alle 3 del mattino di sabato.

LangGraph per Workflow Agent

Usiamo LangGraph come nostro layer di orchestrazione primario. Modella workflow agent come grafi diretti dove i nodi rappresentano azioni e gli archi rappresentano transizioni condizionali. Il vantaggio chiave è il checkpointing -- LangGraph persiste lo stato completo dell'agent ad ogni nodo, abilitando replay di esecuzioni fallite dal punto esatto di fallimento, approvazione human-in-the-loop ad ogni step, e audit trail completi per compliance.

Orchestrazione Personalizzata per Percorsi Critici

Per percorsi critici di produzione -- agents di elaborazione pagamenti, workflow security-sensitive -- usiamo state machine TypeScript personalizzate piuttosto che un framework. I framework aggiungono layer di astrazione, e i layer di astrazione aggiungono modalità di fallimento. Quando un workflow elabora transazioni finanziarie, ogni linea di codice di orchestrazione dovrebbe essere esplicita, testabile e libera da aggiornamenti di dipendenze di terze parti che potrebbero cambiare comportamento. È più codice di LangGraph, ma il trade-off vale dove l'affidabilità supera la velocità di sviluppo.

Vector Database ed Embeddings

Usiamo tre vector database per tre contesti di deployment. Pinecone è il nostro default per deployment cloud-native -- gestito, scalabile, con isolamento tenant basato su namespace. pgvector è la nostra scelta quando l'applicazione già gira su PostgreSQL, mantenendo vettori accanto a dati relazionali ed eliminando un database separato da operare. Weaviate è deployato per clienti on-premise -- agenzie governative e istituzioni finanziarie con data residency stretta -- girando containerizzato all'interno della loro infrastruttura con ricerca ibrida nativa.

Per gli embeddings, text-embedding-3-large di OpenAI è il nostro default per applicazioni in inglese. Per lavoro multilingue -- una porzione significativa dei nostri progetti attraverso America Latina ed Europa -- embed-multilingual-v3.0 di Cohere supera le alternative sul retrieval cross-language. Per deployment on-premise, usiamo modelli open-source come BGE-large ed E5-mistral, girando sulle stesse istanze GPU dei nostri LLM per mantenere l'intera pipeline self-contained.

Pipeline RAG: Dai Documenti alle Risposte

La qualità di un sistema RAG dipende molto di più dalla pipeline di retrieval che dal modello di generazione -- un modello frontier dato cattivo contesto produce cattive risposte con la stessa confidenza con cui produce buone risposte.

Chunking Consapevole del Tipo di Documento

Abbiamo abbandonato presto le strategie di chunking universali. Chunk di dimensione fissa con overlap funzionano per articoli e report ma fanno a pezzi contratti, specifiche e rendiconti finanziari. Il nostro approccio: i contratti legali sono chunkati per clausola, i doc tecnici per sezione, i report finanziari per tabella e narrativa separatamente. Manteniamo anche relazioni parent-child tra chunk così il sistema può tirare contesto circostante quando un frammento viene recuperato -- eliminando la modalità di fallimento RAG più comune di restituire un frammento rilevante che manca del contesto per interpretarlo correttamente.

Reranking e Ricerca Ibrida

Il reranking è costantemente il singolo più grande miglioramento di qualità nelle nostre pipeline RAG. Usiamo Cohere Rerank per deployment gestiti e modelli cross-encoder per setup on-premise. Aggiungere reranking a una pipeline di ricerca vettoriale baseline migliora l'accuratezza delle risposte del 15-25% attraverso i tipi di documento. Aggiunge 100-200ms di latenza, ma il miglioramento di qualità lo rende non-negoziabile.

Accoppiamo questo con ricerca ibrida -- combinando similarità vettoriale con keyword matching BM25 -- per ogni sistema di produzione. La ricerca vettoriale pura perde query exact-match per numeri di contratto, SKU prodotto e identificatori di regolazione. L'implementazione aggiunge complessità, ma perdere un documento ovviamente rilevante perché non è semanticamente vicino alla query è troppo dannoso da accettare.

Valutazione e Monitoraggio

Un sistema AI senza valutazione è una liability. Ogni sistema di produzione ottiene una suite di valutazione personalizzata: accuratezza di estrazione, completezza e tasso di allucinazione per elaborazione documenti; tasso di completamento task, rilevanza e aderenza al tono per agents conversazionali. I tool off-the-shelf ti danno metriche generiche. I framework personalizzati ti danno le metriche che effettivamente correlano con la soddisfazione utente.

Per dimensioni di qualità soggettive, usiamo un pattern LLM-as-judge -- Claude come modello giudice, scorando output su scala 1-5 con ragionamento obbligatorio per ogni punteggio. Non è una sostituzione per la valutazione umana ma un filtro scalabile che cattura regressioni e segnala casi borderline. Per applicazioni critiche in domini legali e finanziari, esperti di dominio rivedono un campione statistico di output settimanalmente, fornendo la ground truth per calibrare la valutazione automatizzata.

Per osservabilità, eseguiamo LangSmith catturando ogni chiamata LLM, invocazione tool e decisione agent come trace. Dashboard Grafana personalizzate tracciano ciò che conta alla leadership: costo al giorno per modello e cliente, percentili di latenza, tassi di completamento task e punteggi di qualità. Ogni dollaro di inferenza AI è attribuito a un cliente, progetto e caso d'uso specifico -- non come igiene finanziaria, ma per guidare decisioni di ottimizzazione.

Infrastruttura e il Pattern API Gateway

I servizi agent sono containerizzati con Docker su Kubernetes, auto-scaling basato su profondità coda piuttosto che utilizzo CPU -- perché i workload AI sono I/O-bound aspettando API di modello, non CPU-bound. Per inferenza self-hosted, vLLM gira su istanze GPU con dynamic batching, scaling a zero durante le ore off-peak. Un singolo API gateway gestisce autenticazione, rate limiting, retry logic, routing modello e cost tracking per ogni richiesta LLM in uscita. Questo gateway è il chokepoint attraverso cui fluisce tutta la spesa AI, rendendolo il posto naturale per imporre budget e raccogliere telemetria.

Cosa Abbiamo Scelto di Non Usare (e Perché)

I tool che rifiuti rivelano tanto sulla tua filosofia ingegneristica quanto i tool che adotti. Ecco le tecnologie notabili che abbiamo valutato e deliberatamente scartato.

• CrewAI -- Troppo opinionato sui pattern di interazione agent per la produzione. LangGraph fornisce le stesse capacità multi-agent con controllo esplicito su ogni transizione.
• Chroma -- Solido per prototipazione ma la maturità operativa per workload di produzione (connection pooling, HA, backup) non soddisfaceva i nostri standard. Rivisitiamo periodicamente.
• Haystack -- Astrazione pulita della pipeline ma ecosistema e supporto community significativamente più piccoli di LangChain/LangGraph.
• Modelli di ragionamento fine-tuned -- Risultati costantemente peggiori di modelli frontier ben-prompted, con alto burden di manutenzione. Facciamo fine-tune di modelli di embedding per retrieval domain-specific, dove il ROI è chiaro.
• AutoGen -- Hardening di produzione insufficiente. L'interazione agent basata su conversazione rendeva il debugging difficile, e nessun checkpointing persistente era un dealbreaker per workflow enterprise.

Come È Evoluto il Nostro Stack in 18 Mesi

A metà 2024, giravamo GPT-4 come nostro unico modello, raw LangChain chains per orchestrazione, Chroma per vector storage, e logging base. Il sistema funzionava per demo ma crollava sotto carico di produzione. Entro fine 2024, Claude 3.5 Sonnet aveva sostituito GPT-4 come nostro modello primario, Pinecone e pgvector avevano sostituito Chroma, e LangGraph aveva sostituito le LangChain chains -- migliorando immediatamente debugging e testing.

Attraverso il 2025, abbiamo aggiunto Cohere Rerank (il nostro più grande singolo miglioramento di qualità), costruito framework di valutazione personalizzati, deployato LangSmith, e introdotto il pattern API gateway. Nel 2026, il focus si è spostato sulla maturità: orchestrazione personalizzata per percorsi critici, loop di valutazione umana, modelli self-hosted per clienti data-sensitive, e pipeline LLM-as-judge. Lo stack è più complesso di 18 mesi fa, ma ogni componente guadagna il suo posto risolvendo un problema che abbiamo effettivamente avuto -- non un problema che abbiamo immaginato.

Principi Dietro le Nostre Scelte

• Usa il modello giusto per ogni task, non il modello migliore per ogni task. Il cascading dei modelli non è solo ottimizzazione dei costi -- è un principio architetturale.
• Possiedi il tuo percorso critico. I framework sono eccellenti per workflow non-critici, ma il codice production-critical dovrebbe essere esplicito e libero da cambiamenti di dipendenze upstream.
• Misura prima di ottimizzare. Ogni ottimizzazione che abbiamo fatto è stata guidata da gap di qualità misurati in produzione, non da preoccupazioni teoriche.
• La semplicità operativa si compone. Un tool leggermente meno capace che il tuo team può operare con confidenza batte un tool superiore che richiede expertise specializzata.
• La trasparenza è una feature. Quando i clienti chiedono quali modelli usiamo e come valutiamo la qualità, rispondiamo con specifiche.

Il nostro stack continuerà a evolversi -- il panorama del tooling AI si muove troppo velocemente perché qualsiasi architettura sia permanente. Ma i principi sono stabili: misura tutto, possiedi i tuoi percorsi critici, usa il tool giusto per ogni lavoro, e sii onesto su cosa funziona. Se stai costruendo sistemi AI di produzione e vuoi confrontare note, o se hai bisogno di un team che ha già navigato queste scelte, accoglieremmo la conversazione. Esplora i nostri servizi di AI e machine learning su /services/ai-development.