Utilizzare LLM locali con Oracle Database

In un'era digitale sempre più dipendente dall'intelligenza artificiale, la gestione e la sicurezza dei dati rappresentano una preoccupazione centrale per molte organizzazioni. Il dilemma è chiaro: come sfruttare la potenza dei large language models (LLM) senza compromettere la privacy e la sovranità dei propri dati, evitando il trasferimento a sistemi AI basati su cloud? La risposta, sempre più adottata, risiede nell'integrare l'intelligenza artificiale direttamente nel proprio data center, minimizzando i costi e massimizzando il controllo. Questo approccio non solo risponde alle stringenti esigenze di conformità e sicurezza, ma apre anche nuove opportunità per personalizzare l'AI in base a specifici contesti aziendali.

Il presente articolo si propone di esplorare le metodologie standard attuali per la connessione di LLM con un database Oracle, ponendo particolare enfasi sulle soluzioni compatibili con la versione 19c e la futura 26ai. Saranno inoltre descritti alcuni modelli di linguaggio di grandi dimensioni con scopi speciali e come le diverse tecniche si allineano con l'ambiente Oracle.

Qualche mese fa, è stato delineato come connettere un Oracle Database 23ai Free Edition con un'AI locale per scopi di test e sviluppo. Con un'attenta selezione e considerazione del tipo di licenza, i large language models sottostanti possono essere utilizzati in modo produttivo, non solo per il collaudo. L'ambiente descritto in quell'articolo serviva a rendere ricercabili i documenti caricati, in modo che potessero fungere da base di conoscenza per l'AI ed essere interrogati tramite un'interfaccia di chat. Il metodo noto come "generazione aumentata dal recupero", o RAG in breve, all'epoca ampiamente enfatizzato, fornisce ancora la base per arricchire l'AI con conoscenza locale e privata da dati non strutturati e strutturati al volo, senza dover creare il proprio large language model con i propri dati al suo interno. Questo approccio è fondamentale per le aziende che desiderano mantenere i propri dati sensibili all'interno della propria infrastruttura, pur beneficiando delle capacità avanzate di ragionamento e generazione del linguaggio degli LLM.

Nel frattempo, lo sviluppo dei large language models è progredito notevolmente, e ora possono essere utilizzati localmente in modo più completo e complesso. Temi come il supporto agli strumenti (tool support), gli agenti e il Model Context Protocol (MCP), così come la miscela di esperti (mixture of experts) e, molto significativamente, le sempre maggiori dimensioni delle finestre di contesto (context window sizes) supportate, hanno trovato la loro strada nelle API e negli strumenti che circondano l'Oracle Database. Questo significa che le organizzazioni hanno ora a disposizione un ventaglio più ampio di opzioni per implementare LLM on-premise, consentendo interazioni più sofisticate, una gestione contestuale più profonda e la capacità di integrare le capacità degli LLM con i processi aziendali esistenti in modi innovativi. Queste evoluzioni sono cruciali per l'adozione diffusa e produttiva dell'AI nei contesti aziendali.

Chiedo scusa in anticipo per l'eccezionale lunghezza di questo post! Forse non lo leggerete per intero, ma selezionerete prima i capitoli che più vi interessano:

Funzionalità attuali degli LLM, in particolare per l'uso locale

• Molto spazio, molta potenza di calcolo?
• Risparmiare spazio, aumentare le prestazioni
• Distribuire lo spazio e bilanciare il carico di lavoro
• Mini-Esperti veloci
• Pensatori veloci per categoria
• Non parlare, agisci e basta – formati di dati, strumenti, agenti e MCP

Funzionalità di un database Oracle che possono utilizzare un LLM locale (in modo supportato)

• SELECT AI / DBMS_CLOUD_AI (Database 19c e 26ai)
• UTL_HTTP e JSON_OBJECT_T (Database 19c e 26ai)
• Vector Store / Vector Search o DBMS_VECTOR / DBMS_VECTOR_CHAIN (Database 26ai)
• Application Express Runtime e Design Time (Database 19c e 26ai)
• MCP Server per Oracle Database (Database 19c e 26ai)

Riepilogo e prospettive

Alcuni link interessanti

Ora e qui, che il banchetto abbia inizio:

Funzionalità attuali degli LLM, in particolare per l'uso locale

Molto spazio, molta potenza di calcolo?

Quando si desidera eseguire un large language model (LLM) localmente o in prossimità dei propri server e database, le considerazioni primarie riguardano i requisiti di archiviazione, le prestazioni e la qualità accettabile dei risultati. I large language models operati in ambienti cloud sono solitamente soluzioni "tuttofare" che svolgono le loro ormai numerose mansioni nel miglior modo possibile. Questo approccio universale comporta la necessità di una notevole quantità di memoria principale per GPU e di potenti GPU con molti core di calcolo. Tali LLM sono tipicamente basati su diverse centinaia di miliardi di parametri (200B, 400B, 600B, ecc.) e attualmente possono consumare fino a 400 GB di costosa memoria GPU per istanza solo per funzionare. A ciò si aggiungono numerose finestre di contesto, che sono aree di memoria per le query degli utenti finali e degli agenti attualmente in esecuzione con la loro rispettiva cronologia delle chat e informazioni contestuali. Queste vengono incorporate in prompt sempre più grandi tramite il meccanismo RAG, fornendo all'AI un contesto ricco per generare risposte pertinenti. Tuttavia, per un uso locale e non generico, questa scala di risorse non è assolutamente necessaria né conveniente. Le esigenze di un'applicazione specifica all'interno di un'azienda possono spesso essere soddisfatte con modelli molto più snelli e specializzati, riducendo drasticamente i requisiti hardware e i costi operativi.

Risparmiare spazio, aumentare le prestazioni

Inizialmente, sono state sviluppate strategie per riprogettare i large language models per l'operazione su sistemi GPU meno potenti, in modo da richiedere meno spazio. La tecnica principale qui è la quantizzazione. La quantizzazione riduce la precisione dei parametri o dei vettori all'interno degli LLM, il che aumenta notevolmente la velocità di elaborazione e riduce significativamente i requisiti di spazio. Mentre i risultati non sono più sofisticati o intelligenti come prima, rimangono comunque significativamente migliori rispetto a LLM con un numero di parametri intrinsecamente inferiore. Originariamente, vettori e parametri erano rappresentati con la massima precisione possibile utilizzando numeri in virgola mobile a 64 bit. Oggi, invece, sono comunemente utilizzati e offerti per il download numeri in virgola mobile a 32 bit, 16 bit e persino 4 bit. Questa compressione dei dati, pur introducendo una leggera perdita di informazione, è un compromesso accettabile per ottenere guadagni sostanziali in termini di efficienza e costi. Ad esempio, l'LLM gpt-oss rilasciato nell'estate del 2025 è stato sottoposto a un metodo di quantizzazione a 4.25 bit (circa) (MXFP4). Questa innovazione permette di rendere modelli complessi accessibili su hardware più modesto, democratizzando l'uso dell'AI avanzata e rendendola praticabile per implementazioni on-premise dove le risorse sono limitate o costose.

Distribuire lo spazio e bilanciare il carico di lavoro

  

Gli attuali server di inferenza, ovvero programmi che gestiscono, caricano ed eseguono LLM, sono in grado di distribuire large LLM su più dispositivi GPU locali. Sfortunatamente, questo non offre vantaggi in termini di prestazioni attraverso la parallelizzazione, ma riduce drasticamente lo svantaggio di dover passare gradualmente un LLM eccessivamente grande dal disco alla memoria GPU. La distribuzione consente di superare i limiti di memoria di una singola GPU, permettendo l'esecuzione di modelli che altrimenti sarebbero troppo grandi. Per le sue soluzioni di grandi dimensioni, il produttore di GPU Nvidia offre una funzionalità compatibile con rete/infiniband/RDMA chiamata nvlink per rendere, per così dire, le già grandi GPU ancora più grandi. Ciò facilita la comunicazione ad alta velocità tra più GPU, migliorando ulteriormente la capacità di gestire modelli di grandi dimensioni in un ambiente distribuito.

Al contrario, è anche possibile caricare ed operare contemporaneamente diversi LLM più piccoli, oppure utilizzare più server di inferenza, ciascuno con la propria GPU più piccola, coordinati tramite un bilanciatore di carico. Questa strategia è particolarmente utile in scenari in cui diverse applicazioni richiedono modelli diversi o quando si desidera distribuire il carico di lavoro su risorse computazionali più modeste ma in maggior numero. Per completezza, va menzionato che l'Oracle Database supporta l'accesso a vari server di inferenza locali, tra cui:

• HuggingFace tgi
• vLLM/triton
• ollama

L'accesso avviene direttamente o tramite un'API REST compatibile con OpenAI, che di solito è già disponibile. Questa compatibilità estesa semplifica notevolmente l'integrazione degli LLM nel più ampio ecosistema di Oracle, consentendo agli sviluppatori di sfruttare le loro competenze esistenti e gli strumenti familiari per costruire applicazioni AI robuste e scalabili.

Mini-Esperti veloci

La crescente complessità e specializzazione dei compiti di intelligenza artificiale hanno portato allo sviluppo di LLM più mirati, noti come "mini-esperti". Questi modelli, sebbene più piccoli in termini di parametri rispetto ai loro cugini "tuttofare", sono estremamente efficienti e performanti in domini specifici. Immaginiamo un mini-esperto addestrato esclusivamente per l'analisi finanziaria o per la redazione di documenti legali: la sua efficienza deriva dalla concentrazione su un set di dati e un vocabolario ristretti, consentendogli di fornire risposte più rapide e accurate in quel campo. L'integrazione di questi mini-esperti con un database Oracle permette alle aziende di costruire soluzioni AI altamente specializzate, riducendo i requisiti computazionali e migliorando la pertinenza delle risposte AI per specifiche esigenze aziendali. Questi modelli possono essere utilizzati in combinazione, con un sistema di routing che indirizza le query al mini-esperto più adatto, ottimizzando l'uso delle risorse e la qualità dell'output.

Pensatori veloci per categoria

I "pensatori veloci per categoria" si riferiscono a sistemi che possono rapidamente classificare le query o i dati in categorie predefinite per indirizzarli al modello o al processo più appropriato. Questo è strettamente legato al concetto di "mixture of experts" (MoE), dove un modello più grande è composto da diversi "esperti" più piccoli, ognuno specializzato in un particolare tipo di input o compito. Quando una query arriva, un "gateway" o "router" intelligente determina quale esperto è più adatto per gestirla. Questo approccio non solo migliora l'efficienza, poiché solo l'esperto pertinente viene attivato, ma anche la qualità delle risposte, dato che ogni esperto è altamente specializzato. Integrando tali sistemi con Oracle Database, le aziende possono sviluppare architetture AI che sono sia scalabili che incredibilmente efficienti, gestendo una vasta gamma di tipi di query e dati con precisione. Ad esempio, una richiesta di assistenza clienti potrebbe essere rapidamente categorizzata e instradata a un LLM esperto nella risoluzione di problemi tecnici, mentre una richiesta di marketing andrebbe a un altro.

Non parlare, agisci e basta – formati di dati, strumenti, agenti e MCP

L'evoluzione degli LLM va oltre la semplice generazione di testo; sta convergendo verso la capacità di "agire". Ciò implica l'integrazione di LLM con strumenti esterni e la capacità di comprendere e manipolare diversi formati di dati per eseguire compiti complessi. Gli "agenti" LLM sono programmi che possono autonomamente pianificare ed eseguire una serie di azioni, interagendo con altri sistemi o database per raggiungere un obiettivo. Questo richiede la capacità di utilizzare strumenti, come API di database, sistemi di gestione delle transazioni o servizi web esterni. Il Model Context Protocol (MCP) gioca un ruolo cruciale in questo contesto, fornendo un meccanismo standardizzato per gli LLM per comunicare con sistemi esterni, condividere contesti e invocare funzionalità. Immaginiamo un LLM che non solo risponde a una domanda sull'inventario, ma può anche avviare un ordine di riassortimento se i livelli sono bassi, interagendo direttamente con il sistema di gestione dell'inventario tramite un'API e MCP. Questa capacità di "agire" trasforma gli LLM da semplici generatori di testo a potenti motori di automazione e supporto decisionale, con Oracle Database che funge da repository centrale per i dati e le operazioni che questi agenti eseguono. La gestione di formati di dati diversi, come JSON, XML o tabelle relazionali, diventa fondamentale per l'interazione senza soluzione di continuità tra gli LLM e l'infrastruttura dati aziendale.

Funzionalità di un database Oracle che possono utilizzare un LLM locale (in modo supportato)

SELECT AI / DBMS_CLOUD_AI (Database 19c e 26ai)

Le funzionalità di SELECT AI e DBMS_CLOUD_AI rappresentano un ponte diretto tra l'Oracle Database e i servizi AI, inclusi gli LLM locali. SELECT AI consente agli utenti di invocare funzionalità di intelligenza artificiale direttamente tramite query SQL, semplificando l'integrazione dell'AI nell'analisi e nella manipolazione dei dati. Ad esempio, si potrebbe chiedere a un LLM di riassumere una colonna di testo o di categorizzare i dati, il tutto all'interno di una semplice istruzione SELECT. DBMS_CLOUD_AI estende questa capacità fornendo procedure e funzioni PL/SQL per interagire con servizi AI, sia nel cloud che on-premise. Sebbene il nome suggerisca il cloud, la sua architettura è progettata per essere flessibile, consentendo la configurazione per puntare a endpoint di LLM locali. Questo significa che gli sviluppatori possono sfruttare gli stessi costrutti di programmazione familiare per integrare LLM che risiedono all'interno del proprio data center, garantendo la sovranità dei dati. Queste funzionalità sono cruciali per Oracle Database 19c, una versione di supporto a lungo termine, e saranno ulteriormente potenziate nella prossima versione 26ai, sottolineando l'impegno di Oracle nell'integrazione dell'AI a livello di database.

UTL_HTTP e JSON_OBJECT_T (Database 19c e 26ai)

Per un'integrazione più generica e flessibile con gli LLM locali, l'Oracle Database offre strumenti robusti come il package UTL_HTTP e il tipo di dato JSON_OBJECT_T. UTL_HTTP consente al database di effettuare chiamate HTTP a servizi esterni, che è il meccanismo fondamentale per interagire con la maggior parte degli LLM che espongono un'API REST. Inviando richieste HTTP/HTTPS a un server di inferenza LLM locale, il database può inviare prompt e ricevere risposte. Le risposte degli LLM sono quasi universalmente in formato JSON. Qui entra in gioco il tipo di dato JSON_OBJECT_T, insieme alle funzioni SQL e PL/SQL per la gestione JSON. Queste funzionalità permettono al database di creare, analizzare e manipolare facilmente le strutture JSON, rendendo semplice la costruzione di payload di richiesta per l'LLM e l'estrazione delle informazioni pertinenti dalle risposte. L'utilizzo combinato di UTL_HTTP e delle funzionalità JSON fornisce un metodo potente e personalizzabile per integrare qualsiasi LLM che offra un'interfaccia RESTful, garantendo compatibilità con Oracle Database 19c e 26ai e offrendo agli sviluppatori la massima libertà di scelta.

Vector Store / Vector Search o DBMS_VECTOR / DBMS_VECTOR_CHAIN (Database 26ai)

L'introduzione di funzionalità di Vector Store e Vector Search, accessibili tramite DBMS_VECTOR e DBMS_VECTOR_CHAIN, rappresenta un passo significativo nell'integrazione profonda dell'AI all'interno di Oracle Database 26ai. Queste funzionalità sono progettate per gestire e interrogare embedding vettoriali, che sono rappresentazioni numeriche di dati (testo, immagini, audio) in uno spazio multidimensionale, catturando le loro relazioni semantiche. Gli LLM utilizzano estesamente gli embedding vettoriali per comprendere il significato e il contesto. Un Vector Store all'interno del database permette di memorizzare questi embedding e di eseguire ricerche di similarità (Vector Search) in modo efficiente. Questo è fondamentale per il meccanismo RAG: i documenti o le basi di conoscenza locali vengono trasformati in embedding e memorizzati nel Vector Store. Quando arriva una query, anch'essa viene convertita in un embedding, e il Vector Search trova i documenti più semanticamente simili nel database. Questi documenti recuperati vengono poi forniti all'LLM come contesto aggiuntivo. Le procedure DBMS_VECTOR facilitano la creazione e la gestione degli embedding, mentre DBMS_VECTOR_CHAIN potrebbe orchestrare sequenze di operazioni vettoriali. Queste nuove capacità rendono Oracle Database 26ai un vero e proprio "AI Database", in grado di supportare direttamente operazioni di AI complesse e di integrare gli LLM con una profondità e un'efficienza senza precedenti.

Application Express Runtime e Design Time (Database 19c e 26ai)

Oracle Application Express (APEX) è una piattaforma di sviluppo a basso codice che consente di creare rapidamente applicazioni web ricche di funzionalità direttamente nel database Oracle. L'integrazione degli LLM locali con APEX è possibile sia a runtime che a design time. A runtime, le applicazioni APEX possono invocare LLM locali tramite le API REST (utilizzando UTL_HTTP e JSON), o tramite le funzionalità native di AI del database (come SELECT AI o DBMS_CLOUD_AI/DBMS_VECTOR). Ciò consente agli sviluppatori di incorporare funzionalità di AI generativa, come riassunti automatici, traduzione, generazione di testo o chatbot, direttamente nelle loro applicazioni per gli utenti finali. Ad esempio, un campo di testo in un'applicazione APEX potrebbe utilizzare un LLM per suggerire il completamento o correggere la grammatica in tempo reale. A design time, gli stessi principi possono essere applicati per migliorare il processo di sviluppo stesso. Un LLM potrebbe assistere gli sviluppatori APEX nella generazione di codice, nella creazione di query SQL, o nel suggerire layout di pagina basati su descrizioni testuali. Questa stretta integrazione tra APEX e LLM locali in Oracle Database 19c e 26ai accelera lo sviluppo di applicazioni innovative, rendendo l'AI accessibile anche agli sviluppatori con competenze limitate in machine learning.

MCP Server per Oracle Database (Database 19c e 26ai)

Il MCP (Model Context Protocol) Server per Oracle Database rappresenta una componente cruciale per facilitare una comunicazione robusta e standardizzata tra l'Oracle Database e i large language models, in particolare in contesti locali. Come accennato in precedenza, MCP è un protocollo che permette agli LLM di interagire in modo più strutturato con sistemi esterni, comprendendo il contesto e orchestrando azioni. Un MCP Server dedicato per Oracle Database agirebbe come un middleware o un gateway specializzato, gestendo la complessità della comunicazione bidirezionale tra il database e uno o più LLM locali. Questo server potrebbe essere responsabile della traduzione delle query del database in prompt comprensibili per l'LLM, dell'interpretazione delle risposte dell'LLM e dell'esecuzione di azioni corrispondenti nel database (ad esempio, aggiornare tabelle, eseguire procedure). Potrebbe anche gestire il contesto della conversazione o della sessione, assicurando che l'LLM abbia sempre accesso alle informazioni rilevanti dallo stato del database e delle applicazioni. Questa architettura centralizzata semplifica l'integrazione, migliora la sicurezza e offre un punto di controllo unificato per la gestione delle interazioni AI, essendo pienamente compatibile con le versioni 19c e 26ai dell'Oracle Database e posizionando Oracle come un attore chiave nell'ecosistema dell'AI on-premise.

Riepilogo e prospettive

L'integrazione di large language models (LLM) locali con Oracle Database non è solo una possibilità tecnica, ma una necessità strategica per le organizzazioni che cercano di bilanciare innovazione AI con sicurezza dei dati e conformità. Le capacità illustrate, dall'ottimizzazione degli LLM per l'uso locale tramite quantizzazione e distribuzione del carico, alle robuste funzionalità di integrazione nel database Oracle come SELECT AI, UTL_HTTP con JSON, e le future funzionalità di Vector Search, dimostrano un percorso chiaro verso un'adozione dell'AI on-premise. Le innovazioni come il supporto agli strumenti, gli agenti e il Model Context Protocol stanno trasformando gli LLM da semplici generatori di testo a motori di automazione e decisione. Oracle Database, con le sue versioni 19c e la prossima 26ai, si posiziona come una piattaforma ideale per ospitare e orchestrare queste complesse architetture AI. L'attenzione alla sovranità dei dati, combinata con strumenti potenti per l'integrazione e lo sviluppo, consentirà alle aziende di sbloccare il pieno potenziale dell'intelligenza artificiale, mantenendo il controllo sui propri beni informativi più preziosi. Il futuro vede database non solo come repository di dati, ma come veri e propri centri nevralgici per l'intelligenza artificiale aziendale.

Alcuni link interessanti

Per approfondire gli argomenti trattati, si consiglia di consultare le seguenti risorse, alcune delle quali sono state fondamentali per la stesura di questo articolo:

• GenAI on-prem, free from Oracle: Un articolo precedente che delinea la connessione di un Oracle Database 23ai Free Edition con AI locale per test e sviluppo.
• gpt-oss: Informazioni sull'LLM gpt-oss rilasciato nell'estate del 2025 e il suo metodo di quantizzazione.
• HuggingFace tgi: Documentazione per Text Generation Inference di HuggingFace, uno dei server di inferenza supportati.
• vLLM/triton: Documentazione di vLLM, un altro server di inferenza ad alte prestazioni.
• ollama: Il sito ufficiale di Ollama, un framework per l'esecuzione di LLM localmente.
• Oracle Blogs - Current LLM features, especially for local use: Sezione del blog originale per approfondire le funzionalità degli LLM.
• Oracle Blogs - Features of an Oracle Database that can use a local LLM (in a supported way): Sezione del blog originale sulle funzionalità del database Oracle.
• Oracle Blogs - Summary and outlook: La sezione di riepilogo e prospettive del blog originale.