Utilizzo di LLM locali con Oracle Database: metodi e funzionalità
Cosa fare se non si desidera o non si può trasferire i propri dati a un'IA basata su cloud? La risposta è semplice: portare l'IA nel proprio data center, possibilmente al minor costo. Questo articolo si propone di illustrare alcune metodologie standard attuali per connettere i Large Language Models (LLM) a un Oracle Database. Verranno descritti anche alcuni Large Language Models specifici per determinati scopi e quali di queste metodologie sono ben compatibili con la versione 19c del database.
Alcuni mesi fa, è stata descritta brevemente una metodologia per connettere una Oracle Database 23ai Free Edition con un'IA locale per scopi di test e sviluppo. Se ben scelta e tenendo conto della forma di licenza, i Large Language Models sottostanti possono essere utilizzati anche in produzione, non solo per il test. L'ambiente descritto in quell'articolo serviva a rendere i documenti caricati ricercabili in modo che potessero fungere da base di conoscenza per l'IA e permettere di porre domande tramite un'interfaccia di chat. La metodologia all'epoca ampiamente enfatizzata, la “Retrieval Augmented Generation”, in breve RAG, offre ancora oggi la base per arricchire le IA con conoscenze locali e private da dati non strutturati e strutturati in tempo reale, senza dover creare un proprio Large Language Model con i propri dati al suo interno.
Nel frattempo, lo sviluppo dei Large Language Models è proseguito, e ora possono essere utilizzati localmente in modo più completo e complesso. I temi del Tools-Support, degli agenti e del Model-Context-Protocol (MCP), così come della Mixture-of-Experts e, molto importante, delle Context Window Sizes sempre più grandi supportate, sono entrati a far parte anche delle API e degli strumenti relativi a Oracle Database, motivo per cui si desidera descriverli brevemente.
Vorremmo scusarci in anticipo per l'eccezionale lunghezza di questo articolo del blog! Forse non leggerete l'intero contenuto, ma selezionerete prima i capitoli più interessanti per voi:
Caratteristiche attuali dei LLM, in particolare per l'uso locale
- Molto spazio, molta potenza di calcolo?
- Risparmiare spazio, aumentare le prestazioni
- Distribuire spazio e carico
- Mini-esperti veloci
- Pensatori veloci a cassetto
- Non parlare, ma agire – Formati di dati, strumenti, agenti e MCP
Funzionalità di Oracle Database che possono utilizzare i LLM locali
- SELECT AI / DBMS_CLOUD_AI (Database 19c e 26ai)
- UTL_HTTP (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
Che la festa abbia inizio, qui e ora:
Caratteristiche attuali dei LLM, in particolare per l'uso locale
Molto spazio, molta potenza di calcolo?
Se si desidera operare un Large Language Model (LLM) localmente o in prossimità dei propri server e database, la priorità è innanzitutto la richiesta di memoria, le prestazioni e una qualità dei risultati comunque accettabile. I Large Language Models operati in ambienti cloud sono solitamente onnipotenti, in grado di svolgere al meglio le loro ormai numerose capacità, motivo per cui richiedono una notevole quantità di memoria principale GPU e GPU potenti con molti core di calcolo. Tali LLM si basano solitamente su centinaia di miliardi di parametri (200B, 400B, 600B,...) e consumano attualmente fino a 400GB di costosa memoria GPU solo per il loro funzionamento – per istanza. A ciò si aggiungono numerose Context Windows, che sono aree di memoria per le richieste attualmente in corso degli utenti finali e degli agenti con la loro rispettiva cronologia delle chat e informazioni di contesto, che vengono inserite in prompt sempre più grandi tramite il meccanismo RAG. Questo, per l'uso locale non generico, non è assolutamente necessario in questa misura!
Risparmiare spazio, aumentare le prestazioni
Inizialmente, sono state sviluppate strategie per riorganizzare i Large Language Models in modo che occupassero meno spazio per il funzionamento su sistemi GPU meno potenti. Attraverso la Quantizzazione, la precisione dei parametri o vettori negli LLM viene ridotta, la velocità di elaborazione aumenta notevolmente e anche il fabbisogno di spazio si riduce significativamente. I risultati, tuttavia, non appaiono più così raffinati o intelligenti come prima, ma sono comunque nettamente migliori rispetto agli LLM con un numero di parametri corrispondentemente inferiore. Se originariamente i vettori o i parametri venivano rappresentati con la massima precisione possibile con numeri in virgola mobile a 64 bit, oggi vengono solitamente utilizzati e offerti per il download numeri decimali a 32 bit, 16 bit fino a 4 bit. Il LLM [gpt-oss](http://openai.com/index/introducing-gpt-oss/) rilasciato nell'estate del 2025, ad esempio, è stato sottoposto a un metodo di quantizzazione a 4.25 bit (circa) (MXFP4).
Distribuire spazio e carico
Gli attuali inference server, ovvero programmi che gestiscono, caricano ed eseguono gli LLM, sono in grado di distribuire grandi LLM su più dispositivi GPU locali. Questo purtroppo non porta un vantaggio in termini di prestazioni grazie alla parallelizzazione, ma riduce drasticamente lo svantaggio di dover trasferire un LLM troppo grande, pezzo per pezzo, dal disco alla memoria GPU. Il produttore di GPU nvidia offre per le sue grandi soluzioni una funzionalità nvlink compatibile con rete/infiniband/RDMA, per rendere, in un certo senso, le già grandi GPU ancora più grandi. Viceversa, è possibile caricare ed eseguire contemporaneamente più LLM più piccoli, oppure utilizzare più inference server, ciascuno con la propria GPU più piccola, coordinandoli tramite un Load Balancer. Per completezza, si menziona che Oracle Database supporta l'accesso a diversi inference server locali ([HuggingFace tgi](https://huggingface.co/docs/text-generation-inference/index), [vLLM/triton](https://docs.vllm.ai/en/latest/getting_started/installation/index.html), [ollama](https://ollama.com/)) sia direttamente sia tramite un'API REST compatibile con OpenAI, solitamente già presente.
Mini-esperti veloci
![Image 5: gemma3 l (URL mancante nel testo originale)
Il concetto di "Mini-esperti veloci" si riferisce a LLM più piccoli e specializzati, spesso ottimizzati per compiti specifici. Questi modelli possono essere addestrati su dataset ristretti e mirati, rendendoli estremamente efficienti per determinate funzioni. Un esempio potrebbe essere un modello LLM specializzato nell'analisi legale o nella traduzione tecnica, che, pur avendo un numero inferiore di parametri rispetto a un modello generico, eccelle nel suo dominio di competenza. Questa specializzazione permette non solo di ridurre il fabbisogno di risorse computazionali, ma anche di ottenere risposte più precise e contestualizzate per il compito specifico, un vantaggio significativo negli ambienti on-premise dove le risorse sono spesso limitate e la specificità del compito è alta. L'efficienza di questi modelli contribuisce a un'inferenza più rapida e a un utilizzo più economico delle risorse GPU disponibili.
Pensatori veloci a cassetto
I "Pensatori veloci a cassetto" sono comunemente noti come modelli **Mixture-of-Experts** (MoE). Questa architettura permette di combinare più modelli esperti, ciascuno specializzato in una parte diversa del problema o in un tipo specifico di input. Invece di avere un unico grande modello che cerca di padroneggiare tutti i compiti, un sistema MoE utilizza un "router" o "gate" che seleziona dinamicamente quali esperti attivare per un dato input. Questo approccio offre diversi vantaggi: consente di avere modelli con un numero molto elevato di parametri totali, ma con un costo computazionale per token significativamente inferiore, poiché solo un sottoinsieme di esperti viene attivato per ogni input. Ciò si traduce in una maggiore efficienza e velocità, specialmente quando si gestiscono tipi di dati diversificati o requisiti di output complessi. Per l'uso locale, i MoE possono offrire un equilibrio tra prestazioni elevate e gestione efficiente delle risorse, permettendo di distribuire il carico di lavoro in modo intelligente tra i vari "esperti" locali.
Non parlare, ma agire – Formati di dati, strumenti, agenti e MCP
La capacità dei LLM di "non parlare, ma agire" si manifesta attraverso il Tools-Support, gli agenti e il Model-Context-Protocol (MCP). Il Tools-Support permette ai LLM di interagire con strumenti esterni, come API, database o calcolatrici, per eseguire azioni specifiche o recuperare informazioni in tempo reale. Invece di generare solo testo, il LLM può decidere di utilizzare uno strumento per raggiungere un obiettivo. Gli agenti sono sistemi autonomi che utilizzano i LLM come motore di ragionamento per pianificare, eseguire e monitorare una serie di azioni. Essi possono iterare su un problema, utilizzando strumenti, ottenendo feedback e adattando la loro strategia. Il Model-Context-Protocol (MCP) è un protocollo che facilita la comunicazione standardizzata tra i LLM e i loro ambienti esterni, inclusi database e altri sistemi. Questo protocollo garantisce che i dati siano formattati correttamente e che le interazioni siano gestite in modo efficiente, migliorando l'affidabilità e la scalabilità dell'integrazione dei LLM. I formati di dati giocano un ruolo cruciale, assicurando che le informazioni siano comprese sia dai LLM che dagli strumenti esterni, permettendo un flusso di lavoro fluido e automatizzato, essenziale per applicazioni on-premise che richiedono alta integrità dei dati e azioni specifiche.
Funzionalità di Oracle Database che possono utilizzare i LLM locali
Oracle Database offre una suite di funzionalità robuste che facilitano l'integrazione e l'utilizzo dei Large Language Models (LLM) locali, sia per le versioni più consolidate che per quelle più recenti. Queste capacità consentono alle aziende di sfruttare appieno il potenziale dell'intelligenza artificiale all'interno della propria infrastruttura dati esistente, garantendo al contempo sicurezza e conformità.
SELECT AI / DBMS_CLOUD_AI (Database 19c e 26ai)
Le funzionalità SELECT AI e DBMS_CLOUD_AI rappresentano un'innovazione fondamentale per l'integrazione dei LLM in Oracle Database. Mentre DBMS_CLOUD_AI è specificamente progettato per interagire con servizi AI basati su cloud, la filosofia e i principi sottostanti possono essere adattati per l'uso con LLM locali. SELECT AI, in particolare nella versione 23ai (e si presume nelle future versioni 26ai), mira a semplificare l'interazione con i LLM direttamente dal database. Permette agli sviluppatori e agli analisti di incorporare facilmente le capacità dei LLM nelle loro query SQL, ad esempio per la generazione di testo, il riassunto o l'analisi semantica, senza dover spostare i dati all'esterno del database. Con Oracle Database 19c, anche se non offre SELECT AI nativamente, è possibile ottenere un'integrazione simile tramite API esterne e procedure PL/SQL.
UTL_HTTP (Database 19c e 26ai)
Il package UTL_HTTP è una funzionalità consolidata di Oracle Database che consente al database di effettuare chiamate HTTP e HTTPS a servizi esterni. Questa è una metodologia fondamentale per connettere LLM locali. Un LLM locale viene solitamente esposto tramite un'API REST, e UTL_HTTP permette al database di inviare richieste (ad esempio, prompt) a questa API e ricevere risposte. Questo approccio è estremamente flessibile e compatibile con Oracle Database 19c e 26ai, rendendolo una soluzione universale per l'integrazione. Gli sviluppatori possono scrivere procedure PL/SQL che utilizzano UTL_HTTP per interfacciarsi con qualsiasi inference server LLM locale che esponga un'API compatibile, inclusi quelli che imitano le API di OpenAI. Ciò garantisce che anche le installazioni più datate possano beneficiare delle capacità dei LLM locali.
Vector Store / Vector Search o DBMS_VECTOR / DBMS_VECTOR_CHAIN (Database 26ai)
Le funzionalità di Vector Store e Vector Search, insieme ai package DBMS_VECTOR e DBMS_VECTOR_CHAIN (previsti per Oracle Database 26ai), sono cruciali per l'implementazione efficiente della Retrieval Augmented Generation (RAG) con LLM locali. Questi strumenti consentono di memorizzare e interrogare vettori di embedding (rappresentazioni numeriche di testo o altri dati) direttamente all'interno del database. I vettori possono essere generati da LLM locali e poi indicizzati per una ricerca di similarità rapida ed efficiente. Quando un utente pone una domanda, il database può utilizzare la ricerca vettoriale per trovare rapidamente i documenti o i frammenti di dati più rilevanti nel proprio contesto, che vengono poi forniti al LLM per generare una risposta informata. Questo riduce la dipendenza da sistemi di vector database esterni e centralizza la gestione dei dati, migliorando le prestazioni e la sicurezza. Sebbene queste funzionalità siano pienamente realizzate in 26ai, alcune capacità di gestione vettoriale possono essere emulate o implementate in 19c con soluzioni personalizzate.
Application Express Runtime e Design Time (Database 19c e 26ai)
Oracle Application Express (APEX), sia in Runtime che in Design Time, offre un ambiente di sviluppo rapido per la creazione di applicazioni web basate su database. APEX è particolarmente utile per costruire interfacce utente per interagire con LLM locali. Le applicazioni APEX possono utilizzare le capacità di UTL_HTTP per chiamare API LLM locali o integrare direttamente le nuove funzionalità AI di Oracle Database. Questo permette agli sviluppatori di creare facilmente chatbot, assistenti virtuali o strumenti di analisi del testo che sfruttano i LLM, offrendo un'esperienza utente ricca e interattiva. L'ambiente di sviluppo low-code di APEX rende l'integrazione dei LLM accessibile anche a chi non ha una profonda conoscenza di programmazione, accelerando lo sviluppo di soluzioni AI on-premise in Oracle Database 19c e 26ai.
MCP Server per Oracle Database (Database 19c e 26ai)
Il MCP Server for Oracle Database è una componente specializzata che implementa il Model-Context-Protocol, facilitando una comunicazione standardizzata e ottimizzata tra Oracle Database e i Large Language Models locali. Questo server agisce come un intermediario intelligente, gestendo il formato dei dati, la sessione e la logica di contesto per le interazioni con i LLM. Funziona come un gateway che traduce le richieste del database in un formato comprensibile per il LLM e viceversa. Questo server è progettato per migliorare l'affidabilità, le prestazioni e la gestione del contesto nelle conversazioni con i LLM. La sua compatibilità con Oracle Database 19c e 26ai lo rende una soluzione versatile per garantire che le applicazioni basate su database possano interagire con i LLM in modo efficiente e conforme ai protocolli stabiliti, rendendo più agevole l'implementazione di funzionalità avanzate come gli agenti AI e il Tools-Support.
Riepilogo e prospettive
L'adozione di Large Language Models locali con Oracle Database rappresenta una soluzione strategica per le aziende che cercano di bilanciare le capacità dell'IA con le esigenze di sicurezza e controllo dei dati. Le metodologie discusse, dalla quantizzazione alla distribuzione del carico, fino all'utilizzo di modelli specializzati e architetture Mixture-of-Experts, offrono strade concrete per ottimizzare le prestazioni e ridurre i costi operativi dei LLM on-premise. Le funzionalità di Oracle Database, come SELECT AI, UTL_HTTP, Vector Store, APEX e il futuro MCP Server, forniscono gli strumenti necessari per un'integrazione profonda e versatile. L'evoluzione continua di queste tecnologie promette ulteriori miglioramenti in termini di efficienza, scalabilità e intelligenza contestuale, consolidando Oracle Database come una piattaforma robusta per lo sviluppo e l'implementazione di soluzioni AI avanzate direttamente nel proprio data center. Il futuro vedrà probabilmente una convergenza ancora maggiore tra database e AI, con un'enfasi crescente su agenti autonomi e capacità di ragionamento complesse integrate direttamente nel fabric del database.