Casi studio tecnici da pipeline reali in .NET: RAG su PostgreSQL/pgvector, assistenti vocali con orchestrazione agenti, reporting con Microsoft Agents AI, ML e backtest. Ogni scheda include stack, estratti di codice concettuali e fonti ufficiali (documentazione progetti open source).
Come usare questo indice
Le pagine collegate descrivono architetture ispirate a pipeline reali in .NET e PostgreSQL. Non sostituiscono una consulenza sul vostro caso: servono a qualificare una conversazione con Purple AI e a dare al vostro IT materiale verificabile prima di una call. Leggete almeno la sezione “In sintesi” e “Problema” di ciascun caso, poi approfondite lo stack se coincide con il vostro ecosistema.
Metodologia comune
Ogni caso elenca contesto, vincoli, decisioni di trade-off e limiti noti. Evitiamo claim non misurabili: quando citiamo pattern (embedding batch, SQL governato, orchestrazione agenti), indichiamo anche costi e rischi tipici. Se un argomento è trasversale — sicurezza, osservabilità, costi token — troverete ripetizioni volute tra le schede per chi legge solo una di esse.
Collegamenti interni
Dopo l’indice, passate ai servizi tecnici per capire cosa possiamo erogare come progetto. Le FAQ rispondono a domande che emergono spesso in fase commerciale. Il blog approfondisce temi come NL2SQL senza legarvi a un singolo caso.
Contesto normativo e tracciabilità
Nei corpus di testi ufficiali ogni versione di articolo può avere efficacia diversa nel tempo. La pipeline deve versionare documenti, conservare hash o timestamp di ingest e collegare ogni risposta utente alle fonti recuperate. Questo non sostituisce un giurista ma consente audit interni su cosa ha letto il sistema quando ha prodotto una sintesi.
Chunking e sovrapposizione
La segmentazione del testo influenza recall e precisione: chunk troppo grandi diluiscono il segnale semantico; troppo piccoli perdono contesto. Spesso si usa sovrapposizione controllata tra chunk adiacenti e metadati (numero articolo, rubrica, data di pubblicazione) per filtri SQL pre-vector.
Enrichment controllato
Gli worker di enrichment possono estrarre entità o riassunti con LLM. Va definito cosa resta persistito e cosa è volatile, per costi e privacy. Separare job di enrich da job di embed consente di ricalcolare vettori senza ripagare arricchimenti già validati.
Indici e prestazioni
Con volumi elevati, IVFFlat o HNSW su pgvector richiedono tuning di liste e parametri di costruzione. Monitorate tempi di build indice durante finestre di manutenzione. Query ibride (filtro relazionale + top-k vettoriale) devono usare piani verificati con dati realistici.
Orchestrazione agenti
Gli agenti possono scomporre domande complesse in sotto-query su sotto-corpus. Serve limite di passi, timeout e budget token per evitare loop costosi. I tool esposti agli agenti devono essere idempotenti dove possibile e loggati.
Allucinazioni e mitigazione
Anche con buon retrieval, il modello può sintetizzare oltre il testo recuperato. Tecniche includono citazioni obbligate, temperature basse, refusal templates e validazione post-gen su presenza di span nei chunk. Il business deve accettare che “non so” sia risposta legittima.
Costi operativi
Embed in batch ammortizzano chiamate rispetto a embed on-the-fly su ogni aggiornamento minore. Cache di query ripetute e deduplica documenti identici riducono storage. Confrontate costo storage vettoriale vs costo re-indicizzazione frequente.
Sicurezza e segregazione
Database dedicati o schema separati per ambienti dev/staging/prod. Ruoli PostgreSQL limitati ai soli comandi necessari per worker e API. Backup crittografati e test di restore periodici.
Test e qualità
Set di domande golden con risposta attesa e fonti attese. Regressioni dopo cambio modello embedding o LLM. Valutazione umana campionata su nuovi tipi di domanda prima di ampliare utenza.
Estensibilità
Nuove fonti documentali richiedono mapping schema e policy di aggiornamento. Prevedete adapter per formati (HTML, PDF testo, DOCX) e normalizzazione Unicode.
Handover
Documentate come rilanciare worker, come verificare lunghezza code, come invalidare cache semantica. Il cliente deve poter operare in emergenza anche senza il fornitore in videochiamata.
Multi-tenant e isolamento
Se più clienti condividono piattaforma, isolamento logico per schema o database è preferibile a semplice filtro applicativo. Ogni tenant ha quote storage e rate limit distinti per evitare effetto noisy neighbor su indici vettoriali.
Localizzazione contenuti
Documenti bilingui richiedono strategia di lingua nel retrieval: stesso embedding multilingue o modelli separati per lingua con routing esplicito nella domanda.
Disaster recovery
Backup PostgreSQL includono estensione pgvector. Testate restore in ambiente isolato e tempo di ricostruzione indici grandi. Pianificate finestra di manutenzione per rebuild dopo disaster.
Lettura per ruolo
Architect: concentratevi su diagrammi logici, scelta database, pattern di locking e osservabilità. Developer: snippet e link a README ufficiali. Product owner: sezioni problema/risultati e FAQ su limiti. Security: tracciabilità, segregazione, gestione segreti.
Ordine suggerito
Se siete nuovi al gruppo, leggete prima il caso RAG normativo per capire pipeline dati; poi voice se avete use case operativi; agenti e reporting per automazione su dati strutturati; ML solo se il vostro perimetro include forecasting o ricerca quantitativa interna.
Domande da portare in call
Chiedetevi: quali dati avete già strutturati? Chi è owner? Qual è il costo di un errore di risposta? Avete già policy su cloud e LLM? Le risposte guidano priorità meglio di una lista di buzzword.
Osservabilità e operatività
Metriche su latenza p50/p95, tasso errore, profondità code e costo stimato per richiesta dovrebbero essere visibili in dashboard dedicate prima che il business se ne accorga per telefono. Alert su soglie anomale devono avere runbook: chi guarda, cosa riavviare, quando escalation. Includete exporter compatibili con lo stack già usato dal cliente (Prometheus, Azure Monitor, altro).
Gestione segreti e rotazione
Chiavi API, stringhe di database e certificati restano in vault o variabili d’ambiente gestite, mai in repository. Pianificate rotazione periodica e procedure d’emergenza in caso di leak. Documentate quali servizi terzi ricevono quali segreti e con quali scope minimi.
Test di carico e caos controllato
Prima del go-live, simulare picchi di richieste e timeout di dipendenze esterne. Verificate degradazione controllata: code, circuit breaker, messaggi utente comprensibili. Il caos in produzione arriva da sé; meglio provarlo in staging.
Conformità e dati personali
Mappate flussi PII attraverso embedding, log e backup. Allineate retention a policy aziendale e GDPR. Se usate fornitori extra-UE, verificate SCC e trasferimenti. Il reparto legale del cliente deve ricevere diagramma semplificato dei flussi.
Documentazione e formazione handover
Consegnate architettura logica, istruzioni di deploy, checklist incident e contatti escalation. Una sessione di training registrata (se consentita) riduce dipendenza da singole persone. Aggiornate documentazione quando cambiate versione modello o schema DB.
Evolutività
Prevedete punti di estensione: nuovi template, nuovi corpus, nuovi tool per agenti. Evitate fork non mergeabili del codice core. Usate feature flag per abilitare gradualmente capacità a sottoinsiemi di utenti.
Collaborazione con il cliente
Coinvolgete early il team operations del cliente: conoscono finestre di deploy, blackout e vincoli di change management. Una roadmap condivisa evita sorprese quando il fornitore LLM annuncia deprecation o quando il cliente deve congelare rilasci per audit.
Chiusura e lesson learned
Dopo go-live, tenete retrospettiva su cosa ha funzionato in discovery e cosa no. Documentate debiti tecnici accettati e pianificate paydown. Questo materiale alimenta miglioramento continuo e proposte commerciali successive credibili.
Integrazione con toolchain esistente
CI/CD, code review e policy di branch del cliente vanno rispettate: consegnate pipeline coerenti con repository interni, evitando “isole” che solo il fornitore può buildare. Automatizzate test funzionali minimi su componenti AI così un refactor non rompe silenziosamente il retrieval o i template SQL.
Formazione e handover
Prevedete sessioni di handover con documentazione operativa: runbook, contatti escalation, metriche da monitorare e procedure di rollback. Così il team interno può gestire incidenti di routine senza dipendere dal fornitore per ogni piccolo aggiustamento.