Nel primo articolo di questa serie, abbiamo esplorato il design e la user experience di “Chiedilo a me”. Ora, è il momento di aprire il cofano e mostrare il “come”: le scelte, le sfide e l’architettura che fanno funzionare un assistente virtuale per la Pubblica Amministrazione.
Condurre un progetto RAG (Retrieval-Augmented Generation) da un prototipo sperimentale a un servizio pubblico integrato nel portale me.toscana.it non è un semplice esercizio tecnico. Rappresenta una sfida di “public design” che richiede un’adozione “consapevole” dell’intelligenza artificiale, come promosso da Designers Italia.
Sono almeno tre le sfide non negoziabili:

Sicurezza e Privacy: come si gestisce un servizio destinato a cittadini autenticati (tramite SPID, CIE, CNS) e come si garantisce la conformità al GDPR?
Affidabilità: le risposte devono provenire solo da fonti ufficiali. Errori o informazioni inventate (l’effetto allucinazione), tollerabili in contesti commerciali, sarebbero invece inaccettabili per un servizio pubblico e ne comprometterebbero la credibilità e la fiducia dei cittadini.
Pragmatismo e Sostenibilità: la soluzione deve essere efficace, facile da gestire nel tempo e sostenibile, soprattutto per quanto riguarda i costi delle infrastrutture e l’uso dei token dei modelli LLM.

La richiesta della Regione Toscana poteva essere soddisfatta attraverso un’architettura RAG “onesta” e pragmatica. Da parte nostra non abbiamo implementato l’architettura più complessa possibile, ma quella più adatta e robusta per il contesto specifico della PA.

Come stack tecnologico fondamentale, sono state operate tre scelte strategiche:

L’adozione del framework open-source Cheshire Cat, selezionato per la sua flessibilità e, come si vedrà, per la sua capacità di estensione tramite plugin.
L’utilizzo di Qdrant come database vettoriale, che agisce come memoria vettoriale predefinita per Cheshire Cat e offre un eccellente equilibrio tra velocità di ricerca e utilizzo efficiente della memoria.
I modelli di Azure OpenAI, specificamente gpt-4.1-mini per la generazione e text-embedding-3-large per gli embedding. Questa scelta non è stata dettata solo dalle performance, ma dalle sue stringenti garanzie contrattuali.

Optando per il tipo di distribuzione EU Data Zone di Azure OpenAI, viene assicurato che l’hosting e l’elaborazione dei dati avvengano esclusivamente entro i confini europei (in linea con l’EU Data Boundary). A questo si aggiunge la “Zero Training Policy”, che garantisce contrattualmente che i dati dei cittadini non vengano mai utilizzati per addestrare i modelli sottostanti.

2. L’architettura: un equilibrio tra flessibilità e sicurezza

L’architettura del sistema è costruita su due pilastri: un modello di autenticazione delegata per la sicurezza dell’utente e un modello di hosting ibrido per la sovranità del dato.

Integrazione, non gestione dell’identità

Un punto chiave da chiarire immediatamente riguarda la gestione dell’identità. “Chiedilo a me” è un componente React embedded, integrato all’interno del portale me.toscana.it. Non gestisce direttamente l’autenticazione, che è demandata al sistema ARPA di Regione Toscana.

L’architettura implementa un pattern di “Delegated Authentication” (Autenticazione Delegata). In questo modello, il portale me.toscana.it (tramite ARPA) agisce come asserting party: si assume la piena responsabilità di gestire la complessità dell’autenticazione federata (via SPID, CIE o CNS) e di verificare l’identità del cittadino.

Una volta che l’utente è autenticato, il portale “passa” al componente React (il relying party) un token di autenticazione. Il chatbot opera quindi in un contesto già autenticato, ricevendo un’identità verificata senza mai dover gestire le credenziali. Questa architettura crea un confine di responsabilità netto e robusto, che isola il componente conversazionale dalla complessità della gestione dell’identità digitale, seguendo le best practice per l’integrazione di componenti sicuri.

Un’architettura ibrida per la sovranità del dato

È stata operata una scelta strategica di separare fisicamente l’hosting dei componenti in base al loro profilo di rischio e alla necessità di controllo.
Il “Cervello” (LLM): Hosting su Azure EU
I modelli di intelligenza artificiale (gpt-4.1-mini, text-embedding-3-large) sono ospitati su infrastruttura Azure in una region europea (es. Germania, Svezia).
Questa scelta è buona per la compliance GDPR e offre due garanzie contrattuali inamovibili:

EU Data Boundary: Microsoft si impegna contrattualmente a memorizzare ed elaborare tutti i dati dei clienti (inclusi i prompt e le completions) esclusivamente all’interno dei confini geografici dell’Unione Europea.
Zero Training Policy: la documentazione ufficiale di Azure OpenAI è esplicita: i dati dei clienti (prompt, output, embedding) NON sono disponibili per OpenAI o altri fornitori terzi, NON vengono usati per addestrare o migliorare i modelli base e tali modelli sono stateless (non memorizzano le interazioni)

Questo approccio permette di utilizzare modelli state-of-the-art “inscatolati” in un ambiente sicuro che gestisce i dati transitori dei cittadini (le loro domande) con il massimo livello di conformità.

Il “Core” (Applicazione): Hosting su Infrastruttura controllata

Il framework applicativo open-source Cheshire Cat e il database vettoriale Qdrant girano invece su un’infrastruttura controllata (Hetzner), un provider cloud europeo localizzato in Germania.
Questa scelta rappresenta una fase di deployment pragmatica che ci ha permesso di accelerare lo sviluppo e il time-to-market in un ambiente conforme al GDPR. Rappresenta un passo intermedio verso la piena sovranità del dato: come indicato nella nostra roadmap, si sta già lavorando per migrare questi componenti direttamente sull’infrastruttura regionale del Sistema Cloud Toscana (SCT), che consoliderà la governance e il controllo locale.

3. Anatomia di una risposta: un RAG semplice è un RAG robusto

L’affidabilità del chatbot si fonda su una pipeline RAG volutamente semplice ma robusta, che privilegia il controllo sulla complessità.

Fase 1: L’ingestione (le fonti)

Il primo e più importante “guardrail” del sistema è il grounding. La conoscenza del bot è limitata esclusivamente a un corpus di dati curato e proveniente da fonti ufficiali:

Bandi e guide da giovanisi.it e regione.toscana.it.
Offerte di lavoro da ARTI.
Lista dei servizi digitali da open.toscana.it.
I contenuti del sito di competenze digitali di Regione Toscana.

Script automatici estraggono e aggiornano questi contenuti. I documenti vengono poi frammentati (chunking), trasformati in vettori numerici tramite il modello text-embedding-3-large e memorizzati nel database vettoriale Qdrant. Questo processo crea la “verità” incontestabile del bot, la base fondamentale del RAG.

La memoria tripartita di Cheshire Cat

Il processo di ingestione non è monolitico. Sfruttiamo la specifica architettura di memoria di Cheshire Cat, che suddivide la conoscenza in tre collection distinte su Qdrant:

Declarative Memory: è la “biblioteca” del bot. Qui finiscono i documenti ufficiali (bandi, guide, etc…) dopo il chunking e la vettorizzazione. È la fonte primaria per il RAG.
Episodic Memory: è la memoria della conversazione. Contiene un estratto di ciò che l’utente ha detto in passato e permette al bot di comprendere domande successive (follow-up) e mantenere il contesto, conferendo “memoria” all’interazione.
Procedural Memory: contiene la conoscenza su “come fare le cose”, ovvero i “Tools” (funzioni Python) che il bot può decidere di eseguire.
Questa memoria non è solo una capacità teorica, ma è già impiegata per alcuni “Tools” semplici, integrati tramite plugin. Un esempio pratico è la ricerca dei Punti Digitali Facili (PDF). Se un utente chiede: “Qual è il Punto Digitale Facile più vicino a Pisa?”, Cheshire Cat riconosce l’intento e attiva il tool dedicato. Questo plugin esegue una chiamata API specifica al servizio regionale per recuperare l’informazione. La risposta dell’API (ad esempio, l’indirizzo del PDF più vicino) viene quindi passata contestualmente all’LLM insieme alle eventuali fonti recuperate dalla Declarative Memory, permettendo al modello di generare una risposta precisa e aggiornata.

Fase 2: Il flusso di risposta

Quando un utente invia un messaggio, il flusso di risposta (la pipeline “retrieve-then-read”) è lineare e controllato:

Query: l’utente invia un messaggio tramite il componente React tramite connessione websocket.
Embedding: la domanda viene vettorializzata dallo stesso modello usato per i documenti.
Retrieval: viene eseguita una ricerca semantica su Qdrant per trovare i “chunk” di testo (dalla Declarative Memory) e i frammenti di conversazione passata (dalla Episodic Memory) più rilevanti per la domanda.
Prompting: viene costruito un prompt per gpt-4.1-mini che include la domanda originale dell’utente e i chunk di testo recuperati.

Il system prompt come “guardrail” principale

Qui risiede la vera sfida di un servizio pubblico. Da un lato, il bot deve usare tutta la potenza di un LLM di frontiera (come gpt-4.1-mini) per essere conversazionale, comprendere il contesto e avere una competenza linguistica elevata. Dall’altro, deve essere affidabile e sostenibile.
Il System Prompt è il nostro “guardrail” principale per bilanciare queste esigenze. È progettato meticolosamente non per limitare la sua capacità linguistica, ma per indirizzarla. Le istruzioni chiave ordinano all’LLM di:

Presentarsi correttamente come “chiedilo a me”.
Basare primariamente le sue risposte sui documenti forniti (i “chunk” recuperati dalla Declarative Memory), specialmente per domande fattuali.
Citare sempre le fonti utilizzate per la risposta, garantendo trasparenza e verificabilità da parte dell’utente.
Usare la sua conoscenza generale e capacità conversazionale (attingendo anche dalla Episodic Memory) per gestire il dialogo, ma rifiutare gentilmente di rispondere a domande fuori contesto (es. “Non ho informazioni su questo argomento”).

Questa strategia ci permette di contenere i costi (evitando che il bot produca risposte lunghe su questioni non pertinenti) e garantire l’affidabilità, senza sacrificare la fluidità dell’esperienza utente. Il bot è grounded, ma non limitato.

4. Le Sfide: perché “non fare” è una scelta di design

Molti approcci RAG accademici o commerciali includono pipeline complesse per migliorare marginalmente l’accuratezza. Sono state analizzate tecniche avanzate, ma si è consapevolmente scelto di non implementarle. Questa decisione “controcorrente” è un pilastro del design pragmatico del sistema.

Le pipeline RAG complesse spesso includono passaggi aggiuntivi come:

Pre-retrieval (Query Expansion): l’uso dell’LLM (o di altri metodi) per espandere o riformulare la query dell’utente prima della ricerca vettoriale.
Post-retrieval (Re-ranking): l’uso di un secondo modello (spesso un cross-encoder SBERT) per riordinare i risultati recuperati da Qdrant, cercando di mettere al primo posto il risultato più rilevante.

La Scelta Pragmatica: Ottimizzazione costi e latenza

Abbiamo analizzato soprattutto tecniche avanzate come il re-ranking, che la ricerca dimostra essere efficaci nel migliorare la precisione di recupero in scenari complessi. Tuttavia, queste tecniche introducono un inevitabile trade-off tra accuratezza, latenza e costi. Per un servizio pubblico destinato a un’ampia utenza, l’aumento del consumo di token e della latenza per-query, necessari per un re-ranker, è stato ritenuto un costo insostenibile nella fase attuale.

La soluzione ad alto ROI: Investire nel datastore

La nostra strategia è stata quella di investire il tempo di ingegneria in pipeline di ingestione che danno priorità alla qualità dei dati a monte.
Questa decisione è allineata con un filone emergente della ricerca RAG (ad es. Lyu et al., 2025, “Frustratingly Simple Retrieval” ), che ha dimostrato come una pipeline RAG minimale, se alimentata da un datastore di altissima qualità, possa eguagliare o superare le prestazioni di sistemi agentici complessi che operano su dati rumorosi. Il nostro investimento si concentra quindi sul “guardrail” più efficace ed economico: garantire che solo la “verità” incontestabile e pulita entri nel vector store.

5. Sicurezza e osservabilità: i pilastri della fiducia

Un servizio pubblico digitale non può esistere senza una sicurezza attiva e senza la capacità di imparare dai propri utenti.

Difesa attiva

Qui emerge il valore strategico della scelta open-source (Cheshire Cat). Una soluzione SaaS “black-box” non avrebbe concesso il livello di controllo necessario. Il framework Cheshire Cat è progettato per essere espandibile tramite plugin. Tra i vari, è stato sviluppato anche un plugin custom che utilizza gli “hook” del framework per intercettare e analizzare ogni messaggio dell’utente prima che questo raggiunga il database vettoriale o l’LLM. Questo plugin agisce come un “firewall” applicativo che implementa due livelli di difesa:

Rate Limiting: una best practice critica per qualsiasi applicazione LLM. Il plugin limita il numero di messaggi che un singolo utente può inviare in un dato intervallo di tempo (es. all’ora). Questo protegge il servizio da abusi (come attacchi DDoS) e previene un consumo incontrollato di token, contenendo i costi.
Rilevamento Jailbreak: questo plugin affronta direttamente una vulnerabilità: la Prompt Injection. Gli attacchi di “jailbreaking” tentano di indurre l’LLM a ignorare le sue istruzioni di sicurezza. Il plugin custom intercetta e blocca i pattern di attacco noti, impedendo che raggiungano il modello.

Evaluation (Il “Golden Dataset”)

Per garantire che le nostre scelte di design “pragmatiche” (come un RAG semplice) fossero solide dal punto di vista ingegneristico, abbiamo definito un’architettura basata su un rigoroso processo di valutazione, che precede e accompagna l’osservabilità sul campo. Il vero asset strategico di questa fase è stato lo sviluppo di un “golden dataset” di valutazione. Questo dataset non è stato creato da tecnici, ma da una nostra esperta di dominio (la curatrice editoriale del sito competenzedigitali.toscana.it), garantendo che le domande riflettessero i bisogni reali degli utenti e che le risposte attese fossero fattualmente corrette.
Questo dataset è la base per i nostri script di valutazione automatizzati.
Utilizzando framework come ragas, misuriamo metriche oggettive a ogni modifica del sistema (es. cambio del modello di embedding, modifica della strategia di chunking):

Context Precision e Context Recall: per assicurarci di recuperare solo i chunk giusti e tutti i chunk giusti.
Faithfulness e Response Relevancy: per misurare quanto la risposta generata sia fedele alle fonti e pertinente alla domanda.

Questo approccio ci permette di prendere decisioni data-driven e di dimostrare l’effettivo ROI di ogni intervento, trasformando il “pragmatismo” da filosofia a metodologia misurabile.
Siamo tuttavia consapevoli dei limiti e dei potenziali bias intrinseci delle metriche di valutazione LLM-based. Per questo motivo, la valutazione quantitativa automatizzata è sempre affiancata e validata dalla rigorosa revisione manuale del “golden dataset” e dall’analisi qualitativa del feedback degli utenti, garantendo una visione olistica e affidabile delle prestazioni del sistema.

Osservabilità (Imparare dagli Utenti)

Un chatbot non è un prodotto “finito”, ma un servizio in continua evoluzione. Per questo, l’osservabilità è fondamentale.

Feedback: è stato integrato un sistema di feedback esplicito (es. “pollice su/giù”) per ogni singola risposta.

È fondamentale precisare che questo feedback non viene reimmesso automaticamente per correggere il sistema. Si tratta di una scelta di design consapevole: abbiamo osservato che il feedback negativo dell’utente è spesso soggettivo (legato a un’interpretazione personale o a un’aspettativa non soddisfatta) e non sempre a un errore fattuale.

Pertanto, ogni segnalazione negativa rappresenta un indicatore per una revisione manuale. Questi dati vengono raccolti e analizzati dal team per comprendere la natura del problema (una risposta errata, una fonte non pertinente, un’incomprensione). È questo processo di analisi umana che permette di correggere il sistema in modo mirato e sicuro, migliorando l’accuratezza nel tempo.

Tracciamento: Il pilastro dell’osservabilità è la registrazione di tutte le interazioni in modo anonimo e aggregato. Questo processo, definito “chatbot observability”, traccia metriche cruciali come le domande poste, le risposte fornite, le fonti usate, i tassi di errore e i feedback degli utenti.

Questo tracciamento non è solo uno strumento di debugging; è la fonte primaria di user research per un servizio digitale pubblico. Permette di rispondere a domande cruciali: “Cosa chiedono i cittadini che il bot non sa?”, “Quali documenti producono risposte errate?”, “Ci sono nuovi bisogni emergenti che le fonti attuali non coprono?”.

L’osservabilità è il motore del continuous improvement, che permette di adattare progressivamente il servizio ai bisogni reali dei cittadini.

Questa strategia di intensa osservabilità giustifica anche la scelta attuale di un modello di frontiera come gpt-4.1-mini. Trovandoci in una fase iniziale e non conoscendo ancora l’intero spettro delle esigenze degli utenti, un modello potente e versatile è necessario per garantire flessibilità.

6. Conclusione: Dall’Ingegneria Pragmatica all’Evoluzione Guidata dai Dati

L’architettura tecnica di “chiedilo a me” non è un esercizio di stile, ma l’atto di ingegneria pragmatica che abilita le promesse di design fatte nella Parte 1. La flessibilità del framework open-source Cheshire Cat, le garanzie di sicurezza contrattuale di Azure EU e un approccio “onesto” e semplificato alle sfide del RAG hanno permesso di tradurre la visione di design in un servizio reale, sicuro e pronto a evolvere.
Questa evoluzione è già in corso con la roadmap v2, che introdurrà capacità trasformative come l’ingestione dati semplificata, il potenziamento dei “Tools” agentici, la gestione multichat e il supporto multilingua.
Ma questa è solo la prima fase. Il vero motore dell’evoluzione futura è l’infrastruttura di osservabilità già in funzione. I dati di utilizzo e i feedback che stiamo collezionando rappresentano un asset strategico che ci consentirà di passare da un’analisi ipotetica a una empirica. Saranno le evidenze emerse dall’osservazione reale a guidare l’ottimizzazione data-driven e a motivare l’introduzione mirata di tecniche avanzate (come pre-retrieval, classificatori o re-ranking), inizialmente escluse per motivi di ROI.

Questo flusso di interazioni reali è, infine, la base per l’obiettivo finale già identificato: disporre del dataset necessario per il fine-tuning di un modello open-source , chiudendo il cerchio sulla sostenibilità e sulla sovranità del dato. Il percorso segna la maturazione pianificata del servizio: da un chatbot Q&A robusto a un vero assistente conversazionale agentico, capace di apprendere e migliorare non solo grazie alla nostra ingegneria, ma grazie ai bisogni reali dei cittadini.

A cura di Luca Baroncini , AI Specialist

L’Architettura Tecnica del Chatbot RAG di Regione Toscana