Perché il progetto è andato oltre la semplice automazione delle email
Il lavoro è nato da una esigenza pratica: leggere le email in arrivo, generare bozze di risposta e consentire agli utenti di revisionarle prima dell’invio. Tuttavia, l’obiettivo ingegneristico era più ampio. L’implementazione è stata concepita come un framework riutilizzabile in cui ingestione delle email, archiviazione dei messaggi, costruzione del prompt, invocazione del modello, revisione umana e osservabilità sono capacità separate, capaci di evolvere in modo indipendente.
Questa separazione è fondamentale. Un’automazione “una tantum” tende a codificare in modo statico formati di messaggio, prompt, ipotesi sul provider e comportamento dell’interfaccia in un unico flusso. Il nostro framework, invece, utilizza configurazioni basate su tabelle, archiviazione canonica dei messaggi, orchestrazione GenAI neutrale rispetto al provider e controlli amministrativi. In questo modo la stessa base può essere riutilizzata per nuove categorie di email, dipartimenti, fornitori di modello, dataset di addestramento e futuri flussi di lavoro assistiti dall’AI.
Principio di design: l’applicazione non delega al modello la gestione del flusso di lavoro. Il database e l’applicazione APEX mantengono identità, stato, permessi, cronologia dei messaggi, validazione, audit e azioni finali dell’utente. GenAI è impiegata solo come servizio di ragionamento e redazione controllato all’interno del perimetro aziendale.
Cosa coprirà la serie
Questo post introduce il problema architetturale: i flussi di lavoro email assistiti da AI sono utili solo quando sono ancorati a dati aziendali affidabili, validati sul server, osservabili e revisionabili da esseri umani. Una semplice chiamata al modello non è sufficiente per la produzione; occorre un framework.
Gli articoli successivi approfondiranno le singole capacità che rendono il framework riutilizzabile e gestibile:
- GenAI Email Oracle APEX Framework – Architecture Overview (questo post)
- GenAI Email Oracle APEX Framework – Outlook Integration
- GenAI Email Oracle APEX Framework – GenAI Orchestration
- GenAI Email Oracle APEX Framework – APEX Application Layer
- GenAI Email Oracle APEX Framework – Deployment Guide
Quali sono le potenzialità di GenAI
Generative AI è una classe di intelligenza artificiale progettata per produrre nuovi contenuti a partire da contesto e istruzioni. Nel nostro framework, viene usata per redigere risposte email combinando il messaggio più recente, il contesto della conversazione, esempi specifici di business e le istruzioni del modello.
GenAI è particolarmente efficace per compiti a forte contenuto linguistico, dove è necessario redigere, riassumere, riscrivere, classificare o adattare tono e formato. Non sostituisce il sistema di registrazione, le validazioni di business, i permessi o il giudizio finale umano. Per questo motivo, il framework utilizza GenAI come assistente di redazione all’interno di un flusso di lavoro controllato.
- Buon fit: redazione di risposte, sintesi di thread, estrazione di intenti, riformulazione di testo, verifica di sovrapposizioni negli esempi di addestramento e generazione di contenuti di prima bozza.
- Non adatto da solo: decidere destinatari fidati, aggirare approvazioni di flusso, sostituire la validazione del database o inviare comunicazioni esterne senza revisione.
L'architettura a cinque livelli
Il framework è organizzato in cinque strati principali, ognuno con una responsabilità ristretta, per mantenere il codice testabile, estensibile e più semplice da confezionare come capacità di piattaforma.
1. Ingestion
Connette a Outlook tramite Microsoft Graph, recupera le email non lette, le mette in una zona di staging e le segna come lette una volta elaborate.
2. Canonical Store
Persistisce metadati, contenuto del corpo, identificatori di conversazione, risposte generate e flag di elaborazione in tabelle relazionali.
3. Context Builder
Separa il messaggio più recente dalla cronologia, normalizza HTML e testo semplice e costruisce sezioni di prompt strutturate per il modello.
4. AI Gateway
Coordina le richieste a OCI GenAI chat e a OCI text‑embedding. Costruisce payload specifici per il provider, normalizza le risposte e genera vettori per domande di addestramento valide e query runtime tramite il servizio di embedding configurato. Recupera gli esempi più vicini dalla tabella GENAIMODELSDETAILVECTOR e registra separatamente l’uso di chat e vettori nelle tabelle GENAIUSAGETRACKING e GENAIVECTORUSAGETRACKING.
5. APEX Experience
Fornisce amministrazione, test, diagnostica, dashboard, revisione email, salvataggio e flussi di invio.
Il diagramma evidenzia come l’accesso alla casella di posta, la persistenza dei dati, il contesto del prompt, l’invocazione del modello, l’approvazione umana e l’osservabilità siano gestiti come preoccupazioni separate.
Impronta runtime minima: l’orchestrazione avviene interamente su Oracle Database, PL/SQL e APEX. L’applicazione effettua chiamate in uscita a Microsoft Graph per le operazioni di mailbox, a OCI Generative AI per le risposte di chat e al servizio di embedding configurato per i vettori. Non è necessario alcun server applicativo, worker host o proxy AI dedicato.
Modello dati centrale
Il framework è guidato dai dati: il comportamento di business è configurato in tabelle, non sparso nel codice UI. Le categorie di dati più importanti sono:
| Entità | Descrizione |
|---|---|
| Email staging | Area temporanea per le risposte di Microsoft Graph prima della normalizzazione. |
| Canonical email records | Fonte duratura di metadati, corpo, ID conversazione, stato di elaborazione e bozza di risposta. |
| Model headers | Informazioni su provider, versione, identificatore del modello e istruzioni generali. |
| Training examples | Esempi rappresentativi di messaggi in ingresso e risposte desiderate per guidare il modello. |
| Embedding vectors | Vettori per le domande di addestramento validi, memorizzati nella tabella GENAIMODELSDETAILVECTOR. Generati da MANAGEEMBEDDINGS tramite il servizio OCI configurato. |
| Usage tracking | Registra utilizzo del modello chat, contesto utente/sessione, conteggio token, dimensioni richieste/risposte, stato ed errori (GENAIUSAGETRACKING). |
| Vector Search usage tracking | Traccia attività di generazione vettori e ricerca (GENAIVECTORUSAGE_TRACKING), visualizzabili nella dashboard di utilizzo vettoriale. |
Contratti tecnici e pacchetti PL/SQL
Il cuore dell’orchestrazione risiede nei pacchetti PL/SQL MANAGEGENAI e MANAGEEMBEDDINGS. MANAGEGENAI si occupa di assemblare i prompt, inviare richieste di chat, normalizzare le risposte e registrare l’uso. MANAGEEMBEDDINGS chiama il servizio remoto OCI per generare vettori, li salva e li rende disponibili per le ricerche di similarità.
Durante il recupero dei vettori, MANAGEGENAI ottiene il vettore della query tramite MANAGEEMBEDDINGS, effettua una ricerca nella tabella GENAIMODELSDETAILVECTOR per trovare gli esempi Q&A più vicini e li inserisce nel prompt della chat. Questo meccanismo garantisce che il modello lavori con esempi di business pertinenti, migliorando coerenza e accuratezza.
Nota di scoping e dipendenze di sicurezza
Questa serie si concentra sull’architettura del framework, sui pacchetti database, sul layer APEX, sull’integrazione Microsoft Graph e sull’orchestrazione GenAI. Non tratta le modifiche di sicurezza e rete specifiche per l’ambiente di deployment, come regole di firewall, endpoint privati, proxy, TLS inspection o approvazioni di sicurezza. Tali controlli devono essere gestiti attraverso i processi standard di infrastruttura e sicurezza dell’organizzazione.
Le inferenze di chat e di embedding utilizzano impostazioni di regione separate. La regione del database è determinata dall’ambiente di deployment e non è impostata dall’esportazione APEX. Per i dettagli di default e scoperta del catalogo modelli, consultare la Deployment Guide.
Conclusioni e prossimi passi
Il GenAI Email Oracle APEX Framework dimostra come sia possibile costruire un sistema di automazione email basato su AI che rispetti i requisiti di governance, audit e controlli umani tipici di un contesto enterprise. La separazione in cinque layer, la gestione dei dati tramite tabelle configurabili e l’uso di pacchetti PL/SQL per l’orchestrazione garantiscono flessibilità, testabilità e facilità di estensione.
Nel prossimo articolo approfondiremo l’integrazione con Outlook tramite Microsoft Graph, illustrando come configurare le credenziali, gestire i token di accesso e sincronizzare le cartelle di posta con il layer di ingestione.