Sistema RAG o assistente AI: checklist di progetto

La maggior parte dei progetti di assistenti AI che deludono non fallisce per colpa del modello. Fallisce perché nessuno ha concordato a che cosa serve l'assistente, perché i contenuti di base erano incompleti o superati, perché ai permessi si è pensato solo alla fine o perché non c'era modo di capire se una modifica migliorasse o peggiorasse le cose. La scelta del modello conta, ma di solito è una delle decisioni più facili.

Questa checklist raccoglie le domande che affrontiamo prima di costruire un sistema di retrieval-augmented generation (RAG) o un assistente AI sui dati aziendali. Usatela per preparare un progetto interno, per dare il brief a un fornitore o per verificare se un'offerta che avete ricevuto copre l'essenziale. Non vi servono tutte le risposte il primo giorno, ma dovreste sapere quali sono ancora aperte.

1. Caso d'uso e criteri di successo#

Metteteli per iscritto prima che qualcuno apra un notebook o confronti dei modelli.

• Un solo compito principale. Indicate l'unico compito che l'assistente deve svolgere bene per primo, ad esempio rispondere alle domande di prodotto degli operatori del supporto o trovare clausole nei contratti con i fornitori. Altri casi d'uso possono seguire una volta misurato il primo; mescolarne diversi all'inizio rende confusi sia i requisiti sia la valutazione.
• Gli utenti e la loro situazione. Descrivete chi fa le domande, con quale frequenza, in quale lingua e su quale dispositivo, e che cosa fa con la risposta. Un esperto interno che controlla le fonti ha bisogno di qualcosa di diverso da un cliente che agisce direttamente in base alla risposta.
• Domande reali con risposte ideali. Raccogliete 20–50 domande reali da ticket, e-mail o log delle chat e fate scrivere a un esperto di dominio la risposta ideale, indicando la fonte da cui dovrebbe provenire. Questo insieme definisce che cosa significa «buono» e diventa il nucleo del vostro set di valutazione.
• Fuori perimetro e rifiuti. Elencate ciò che l'assistente non deve fare: dare consulenza legale, medica o finanziaria, rispondere oltre le proprie fonti, assumere impegni per conto dell'azienda. Decidete che cosa deve dire in questi casi e dove deve indirizzare l'utente.
• Baseline del processo attuale. Registrate come viene svolto oggi il compito, quanto tempo richiede, chi lo svolge e quanto costa. Senza una baseline, «l'assistente aiuta» è un'opinione e non un risultato.

2. Fonti di dati#

La qualità delle risposte ha come tetto la qualità e l'accessibilità dei contenuti che ci stanno dietro.

• Inventario delle fonti. Elencate ogni fonte che l'assistente dovrebbe usare: wiki, cartelle SharePoint o Google Drive, sistemi di ticketing, database, PDF, siti web. Per ciascuna annotate come vi si può accedere (API, export, crawling) e se tale accesso è consentito.
• Formati e qualità dei documenti. Verificate la presenza di PDF scansionati che richiedono OCR, tabelle complesse, moduli, slide e immagini che contengono informazioni essenziali. Tabelle e scansioni sono i punti in cui le pipeline ingenue perdono più informazioni, quindi campionatele presto.
• Responsabilità e aggiornamento. Indicate un responsabile per ogni fonte e registrate con quale frequenza cambia. Se nessuno è responsabile dei contenuti, nessuno correggerà le risposte sbagliate che ne derivano.
• Duplicati, versioni e lingue. Individuate copie superate, bozze e versioni parallele della stessa policy e decidete quale fa fede. Annotate le lingue sia dei documenti sia delle domande, perché il retrieval tra lingue diverse va testato esplicitamente.

3. Controllo degli accessi e privacy#

Chiarite questi punti prima che qualsiasi dato reale lasci i vostri sistemi.

• Permessi riportati nel retrieval. Se gli utenti possono vedere solo determinati documenti, il retrieval deve filtrare in base ai permessi dell'utente che fa la richiesta, sincronizzati dai sistemi di origine. Le istruzioni nel prompt, o la fiducia nel fatto che il modello trattenga i contenuti, non sono controllo degli accessi.
• Dati personali e base giuridica. Individuate i dati personali presenti in documenti, domande e log e documentate la base giuridica e la finalità del trattamento ai sensi del GDPR. Coinvolgete il vostro responsabile della protezione dei dati all'inizio, non al momento del lancio.
• Contratto con il provider e residenza dei dati. Stipulate un accordo sul trattamento dei dati con ogni provider di modelli e di infrastruttura, esaminate i loro sub-responsabili e accertatevi che il trattamento possa restare in una regione UE, se lo richiedete. Fatevi confermare per iscritto che i vostri dati non vengono usati per addestrare i modelli del provider.
• Conservazione, logging e oscuramento. Decidete per quanto tempo vengono conservati prompt, passaggi recuperati e risposte, chi può leggerli e se i dati personali vengono oscurati prima del logging. I log servono per il debug e per la valutazione: l'obiettivo è una conservazione controllata, non l'assenza di log.

4. Progettazione del retrieval#

Nei sistemi RAG la maggior parte delle risposte sbagliate dipende dal retrieval più che dal modello; per un corpus piccolo e stabile, il contesto lungo con prompt caching può sostituire del tutto il retrieval (vedi RAG vs fine-tuning).

• Chunking lungo la struttura del documento. Suddividete i contenuti per titoli, sezioni, voci di elenco e confini delle tabelle anziché per un numero fisso di caratteri. Conservate con ogni chunk il percorso dei titoli, così che un passaggio abbia senso anche da solo.
• Metadati e filtri. Memorizzate con ogni chunk titolo, fonte, sezione, data, lingua, versione e gruppi di accesso. Sono i metadati a rendere possibili il filtro sui permessi, le regole «solo l'ultima versione» e citazioni utili.
• Ricerca ibrida e reranking. Combinate la ricerca per parole chiave, adatta a termini esatti come codici prodotto, numeri di articolo e nomi, con la ricerca vettoriale sugli embedding, adatta al significato, poi applicate il reranking ai candidati combinati. Testate ogni passaggio sulle vostre domande di esempio invece di dare per scontato che i valori predefiniti bastino.
• Citazioni obbligatorie. Esigete che l'assistente citi i passaggi che ha usato, con un link al documento di origine e alla sezione. Le citazioni permettono agli utenti di verificare le risposte e ai revisori di capire se una risposta sbagliata dipende da un cattivo retrieval o da una cattiva generazione.

5. Scelta del modello e del provider#

Scegliete il modello quando avete un set di valutazione, così la decisione poggia sui vostri dati e non su benchmark generici.

• Opzione di hosting. Confrontate un'API in hosting, gli stessi modelli o modelli simili in una regione cloud UE e un modello open-weight self-hosted sulla vostra infrastruttura. Ogni opzione sposta l'equilibrio tra qualità delle risposte, controllo sui dati, impegno operativo e costi.
• Latenza e costo per query. Misurate il tempo di risposta end-to-end e il costo per domanda risolta sulle vostre domande di esempio, inclusi retrieval, reranking e token di input e di output. Il prompt caching e modelli più piccoli per i passaggi semplici possono cambiare notevolmente queste cifre.
• Fallback e lock-in. Pianificate che cosa succede quando il provider non è raggiungibile o ritira un modello: un secondo provider, una modalità ridotta o un messaggio di errore chiaro. Mantenete prompt, set di valutazione e livello di retrieval indipendenti dal provider, così che il cambio sia una modifica di configurazione più un'esecuzione delle valutazioni, non una riscrittura.

6. Valutazione#

Se non potete misurare la qualità, non potete migliorarla né difendere la decisione di andare in produzione.

• Il set di valutazione prima dello sviluppo. Trasformate le domande reali della sezione 1 in un set di valutazione versionato, con risposte attese e fonti attese, ed estendetelo con casi difficili e casi limite. Costruitelo prima del primo prototipo, non dopo la prima demo.
• Qualità del retrieval e delle risposte. Misurate separatamente se sono stati recuperati i passaggi giusti e se la risposta è corretta, completa e fedele a quei passaggi. Controllate l'accuratezza delle citazioni: il passaggio citato deve davvero sostenere l'affermazione.
• Test di rifiuto e di prompt injection. Includete domande che l'assistente deve declinare e domande a cui le sue fonti non possono rispondere, e verificate che lo dica invece di tirare a indovinare. Aggiungete documenti e input che cercano di scavalcare le sue istruzioni o di estrarre dati di altri utenti, e accertatevi che falliscano.
• Test di regressione e revisione umana. Eseguite l'intero set di valutazione a ogni modifica di prompt, modelli, chunking o dati e confrontate i risultati con l'esecuzione precedente. La valutazione automatica affidata a un modello accelera il lavoro, ma un esperto di dominio dovrebbe controllare i risultati a campione con regolarità.

7. Integrazione e operatività#

L'assistente deve vivere da qualche parte, e dopo il lancio qualcuno deve gestirlo.

• Canale e accesso. Decidete dove vive l'assistente: un widget sul sito web, Slack o Microsoft Teams, uno strumento interno o un sistema di ticketing esistente. Usate il vostro SSO esistente, così identità e permessi arrivano dallo stesso punto di tutto il resto.
• Passaggio a una persona e feedback. Definite come l'utente raggiunge una persona quando l'assistente non può aiutarlo, con la conversazione che viene trasferita insieme alla richiesta. Aggiungete semplici pulsanti di feedback e fate confluire i feedback negativi nel set di valutazione.
• Modello dei costi e monitoraggio. Stimate il costo per query e per mese con l'utilizzo previsto e con quello di picco, e impostate alert sul budget. Monitorate latenza, tassi di errore, tassi di rifiuto e feedback degli utenti, con i log oscurati come concordato nella sezione 3.
• Reindicizzazione, responsabilità dei contenuti e incidenti. Automatizzate la reindicizzazione quando i documenti di origine cambiano, cancellazioni comprese, così l'assistente non cita mai contenuti ritirati. Indicate chi corregge i problemi nei contenuti e definite un processo per gli incidenti legati a risposte sbagliate, dannose o che divulgano dati, incluso il modo per spegnere rapidamente l'assistente.

8. Criteri go/no-go#

Concordate le regole di decisione prima che arrivino i risultati, così la decisione non viene presa sull'onda di una buona demo.

• Soglie concordate in anticipo. Mettete per iscritto i livelli minimi di correttezza delle risposte e di accuratezza delle citazioni sul set di valutazione, la latenza e il costo per query accettabili e la tolleranza zero per le risposte che oltrepassano i confini dei permessi. Confrontate i risultati con la baseline della sezione 1.
• Pilota a tempo con un'uscita chiara. Conducete un pilota con un piccolo gruppo di utenti reali per un periodo prefissato, con una persona designata che prende la decisione. Restringere il perimetro o fermarsi è un esito legittimo, e costa molto meno che scoprirlo dopo un rollout completo.

Come possiamo aiutarvi#

Se volete affrontare questa checklist insieme a noi, la strada più diretta è il nostro AI Proof-of-Value Sprint a perimetro fisso. In due settimane definiamo con voi il caso d'uso, costruiamo un prototipo RAG o ad agenti sui vostri dati, creiamo un set di valutazione, prepariamo un modello dei costi e consegniamo un report go/no-go da portare ai vostri decisori. I dettagli sono nella nostra pagina Prezzi e nei nostri servizi AI & automazione.

Prima che uno qualsiasi dei vostri documenti raggiunga un modello, concordiamo con voi come vengono gestiti i dati; potete leggere fin d'ora come gestiamo i dati dei clienti nei progetti AI. Se preferite partire da un ordine di grandezza, calcolate una stima gratuita e descrivete il caso d'uso che avete in mente.