AI-RAG · Percorso 4: Costruire e gestire
Enterprise RAG Engineering
Una demo RAG è un pomeriggio, un sistema RAG con autorizzazioni e qualità misurabile è engineering. Qui Lei costruisce il secondo.
- Durata
- 3 giorni
- Gruppo
- da 4 a 12 persone
- Formato
- Inhouse · Edizione aperta · Nel lab
- Lingua
- Tedesco o inglese
- Preavviso
- da 4 settimane
- Prezzo
- 23.700 € forfettario, IVA esclusa
Erogazione a partire da quattro partecipanti effettivamente iscritti. La data viene confermata per iscritto dopo aver concordato contenuti, prerequisiti e disponibilità.
Per chi è questo track
Sviluppatori, data engineer e architetti che costruiscono o hanno la responsabilità di un sistema RAG per l’uso aziendale. Anche per team che vogliono dare a un prototipo esistente un fondamento solido.
Per chi no
Non per partecipanti senza pratica di programmazione, per l’ingresso concettuale su fonti e autorizzazioni il punto di partenza giusto è AI-DATA. Chi cerca soprattutto la misurazione della qualità in esercizio trova il posto migliore in AI-EVAL.
Situazione di partenza
Il primo prototipo RAG da tutorial funziona alla demo e fallisce sui documenti reali: le tabelle si sgretolano nel chunking, la ricerca non trova i sinonimi, tutti vedono ogni documento e nessuno sa dire se la versione 2 risponde meglio della versione 1. Tra tutorial e produzione c’è esattamente l’engineering che questo track trasmette.
Questo esiste dopo il track
- Un prototipo RAG funzionante sull’ambiente Lab, costruito dal proprio team, con una decisione architetturale tracciabile per ogni componente
- Una pipeline di ingestion con strategie di chunking documentate per testo continuo, tabelle e documenti strutturati
- Retrieval ibrido da ricerca vettoriale e full text con reranking, nel confronto misurato diretto con la ricerca vettoriale naive
- Un set di valutazione con 30-50 coppie domanda-risposta e un primo livello di qualità misurato come baseline
- Un modello di autorizzazioni implementato con document-level security e un documento dei limiti che mette nero su bianco, con onestà, ciò che il prototipo non sa fare
Prerequisiti
Solide competenze di programmazione in Python, comprensione di base di API e database. L’esperienza con gli embedding aiuta, ma non è una condizione.
Preparazione prima del track
Riceverà in anticipo l’accesso all’ambiente Lab con un setup check di 30 minuti e un catalogo di domande: 10 domande reali a cui il Suo futuro sistema dovrà rispondere, con i tipi di documento in cui si trovano le risposte. Queste domande diventeranno parte del Suo set di valutazione.
Contenuto della fornitura
- 3 giornate di formazione con Dino Bordonaro, a scelta inhouse o nel Lab
- Ambiente personale per ogni partecipante sul nostro Enterprise Lab per la durata del training più 14 giorni di coda
- Repository di codice completo con implementazione di riferimento, stati degli esercizi e soluzioni campione
- Modelli per set di valutazione, modello di autorizzazioni e documentazione dei limiti
- Certificati di partecipazione e documentazione formativa per il Suo archivio di compliance
- Sessione remota di 90 minuti 4 settimane dopo il training per le domande dalla propria implementazione
Agenda
Giorno 1
Perché il RAG da tutorial fallisce sui Suoi documenti
Verifica dal vivo nel Lab: un RAG naive contro tipi di documento reali con tabelle, scansioni e versioni. Ogni errore viene attribuito a un componente, da qui nasce la lista di costruzione dei tre giorni.
Ingestion: dai documenti a unità utilizzabili
Hands-on: parser per PDF, Office e HTML, gestione di tabelle e intestazioni, estrazione dei metadati. Ognuno costruisce la pipeline contro un set di documenti preparato con trappole note.
Il chunking è una decisione, non un default
Esercizio con confronto misurato: finestre fisse, chunking strutturale e semantico contro lo stesso catalogo di domande. Quando regge quale strategia e come si documenta la decisione.
Mettere in esercizio embedding e indice
Modelli di embedding a confronto, dimensioni, lingue, costi. Costruzione dell’indice vettoriale nel proprio ambiente Lab, prime query contro il proprio corpus.
Risultato della giornata: la pipeline gira
Ogni persona mostra: set di documenti ingestito, chunk ispezionati, indice interrogabile. Il criterio di verifica è una decisione di chunking documentata con motivazione, non solo codice che gira.
Giorno 2
I limiti della pura ricerca vettoriale
Esercizio di misura sul proprio indice: numeri di prodotto, nomi propri e abbreviazioni su cui la ricerca semantica passa oltre. La lista degli errori motiva l’approccio ibrido.
Costruire il retrieval ibrido
Hands-on: ricerca full text accanto all’indice vettoriale, fusione degli score e pesatura. Ognuno misura l’effetto sul proprio catalogo di domande invece di crederci sulla parola.
Reranking: precisione sugli ultimi metri
Integrazione di un reranker nella propria pipeline, misurazione di latenza e costi inclusa. Decisione sul valore misurato: quando il passo aggiuntivo conviene e quando no?
Nasce il set di valutazione
Dai cataloghi di domande portati nasce un set di valutazione strutturato con risposte attese e riferimenti alle fonti. Un run automatizzato contro la propria pipeline fornisce la prima baseline.
Risultato della giornata: qualità misurata invece di sensazioni
Ogni persona presenta numeri: tasso di successo e qualità delle risposte per ricerca naive, ibrida e ibrida con reranking a confronto. La tabella delle misure è il risultato verificabile della giornata.
Giorno 3
Autorizzazioni: la domanda che ferma i progetti
Dimostrazione nel Lab: un RAG senza verifica delle autorizzazioni risponde a domande sugli stipendi da un documento HR. Poi le architetture per la document-level security: ereditarietà delle ACL, filtro al momento della query, passaggio della trusted identity.
Implementare la document-level security
Hands-on: metadati di autorizzazione nell’indice, filtro di sicurezza nello strato di retrieval, test con due ruoli utente sullo stesso corpus. Verifica: il ruolo bloccato non riceve né risposta né citazione.
Qualità delle risposte: grounding, citazioni e il non lo so
Prompting dello strato di generazione: risposte con citazione della fonte, comportamento in assenza di contesto, gestione di documenti contraddittori. Un run di misura contro il set di valutazione mostra l’effetto di ogni modifica.
Documento dei limiti e passaggio all’esercizio
Ogni team scrive la documentazione onesta dei limiti: a quali tipi di domande il prototipo risponde in modo affidabile, a quali no, cosa manca fino alla produzione? Sguardo a observability e release gate come ponte verso AI-EVAL.
Risultato della giornata: il prototipo in review
Review finale per ogni persona: query dal vivo con due ruoli, risultato di valutazione, documento dei limiti. Il gruppo verifica con una checklist: gira, misura, protegge, e c’è scritto onestamente cosa manca?
Esercitazioni e quota lab
Almeno il 60 per cento del tempo è lavoro nel codice sul proprio ambiente nell’Enterprise Lab: costruire la pipeline, riempire gli indici, misurare il retrieval, testare i filtri di sicurezza. Ogni decisione architetturale viene verificata sul proprio valore misurato.
Piattaforme
Si costruisce sul nostro ambiente Lab con componenti open source e modelli eseguiti in locale, non vengono usati dati dei clienti. I pattern sono trasferibili su ambienti target Azure, on-prem e ibridi, i servizi di piattaforma nella versione di volta in volta disponibile. Il Sovereign Assistant serve da riferimento di un RAG on-prem produttivo.
Prova di transfer
La review finale del Giorno 3 documenta per ogni persona il prototipo funzionante, i risultati di valutazione e il documento dei limiti contro una checklist fissa. Partecipazione e risultati vengono documentati in modo tracciabile e verificabile in sede di audit.
Artefatti che porta con sé
- Prototipo RAG proprio con ingestion, retrieval ibrido e reranking, esportabile dall’ambiente Lab
- Repository di codice con implementazione di riferimento e soluzioni campione da riutilizzare
- Set di valutazione con 30-50 coppie domanda-risposta e baseline misurata
- Modello di autorizzazioni implementato con filtro di sicurezza documentato
- Documento dei limiti come base decisionale onesta per il percorso verso la produzione
Estensioni opzionali
- Evaluation, Observability e Guardrails (AI-EVAL) per il percorso dal prototipo a un sistema gestibile in esercizio
- LLMOps per ambienti connessi, separati e Air-Gap (AI-OPS) per l’esercizio sovrano
- Sovereign Assistant come percorso di prodotto, se preferisce un RAG on-prem gestito invece dell’autocostruzione
Delimitazione
Il track costruisce un prototipo con il Suo team e trasmette le decisioni di engineering che ci stanno dietro. Non è un’introduzione di prodotto né un progetto di implementazione nel Suo ambiente di produzione, per questo parliamo di un progetto o del Sovereign Assistant.
Domande frequenti
Abbiamo già costruito un prototipo con un framework. Cosa impariamo ancora?
La differenza sta tra girare e reggere: retrieval ibrido con confronto misurato, decisione sul reranking in base ai numeri, document-level security e un set di valutazione come baseline. Esattamente le parti che mancano nei tutorial dei framework e che più avanti fermano i progetti.
Ci serve un ambiente GPU proprio o accessi cloud?
No. Ogni persona lavora su un ambiente dedicato nel nostro Enterprise Lab con 2.516 core CPU e 24 TB di RAM, inclusi 14 giorni di coda. Per il trasferimento nel Suo ambiente target porta con sé codice e decisioni architetturali.
Quanto costa la partecipazione se vogliamo mandare solo 2 sviluppatori?
Il track si svolge come edizione inhouse a 23.700 € IVA esclusa con 4 fino a 12 partecipanti, con cataloghi di domande e tipi di documento della Sua organizzazione. Con meno di 4 sviluppatori propri ha senso combinare con il team dati o piattaforma, proprio il RAG vive di questa miscela.