Si applica a:
SQL Server 2025 (17.x) Database SQL di AzureIstanza gestita di SQL di AzureDatabase SQL in Microsoft Fabric
Questo articolo contiene domande frequenti sui vettori e sugli incorporamenti nel motore di database SQL.
Per campioni ed esempi, visitare il repository SQL AI Samples.
È possibile creare una soluzione di generazione aumentata dal recupero (RAG) interamente in T-SQL?
Sì, è possibile creare una soluzione di Retrieval-Augmented Generation (RAG) basata sulla funzionalità nativa nel motore di database SQL. È possibile usare T-SQL per implementare la logica necessaria per il recupero e l'elaborazione dei dati, integrando al tempo stesso con i servizi di intelligenza artificiale esterni per l'aspetto della generazione. I vettori possono essere archiviati in modo nativo nel motore SQL e le connessioni alle macchine virtuali che forniscono funzionalità di comprensione del linguaggio naturale sono possibili tramite sp_invoke_external_rest_endpoint.
Perché creare una soluzione RAG completamente in T-SQL?
Se si vuole migliorare un'applicazione esistente senza dover riprogettarla per supportare le funzionalità di intelligenza artificiale, usare le funzionalità predefinite del motore SQL per implementare le funzionalità di intelligenza artificiale direttamente all'interno delle query di database. È sufficiente aggiornare il codice T-SQL per incorporare le funzionalità di intelligenza artificiale, anziché apportare modifiche estese all'architettura dell'applicazione.
Sono disponibili esempi end-to-end che usano SQL di Azure o SQL fabric per RAG?
Certo, puoi trovare qui esempi end-to-end per RAG che usano Azure SQL e Fabric SQL:
È possibile usare RAG per dati strutturati, ad esempio colonne e righe?
Se è necessario lavorare con dati strutturati, è comunque possibile sfruttare rag combinandolo con altre tecniche, ad esempio usando incorporamenti per rappresentare i dati strutturati in modo che possa essere compreso dal modello di intelligenza artificiale. In questo modo è possibile eseguire attività di recupero e generazione su dati strutturati, sfruttando al tempo stesso le funzionalità di RAG.
Perché l'invio di uno schema completo e complesso a un LLM comporta una generazione SQL scarsa e come è possibile risolverlo?
Se si dispone di uno schema di database complesso e di grandi dimensioni, con centinaia di tabelle e viste, è preferibile usare un approccio multi-agente per ridurre il disturbo e consentire ai modelli di intelligenza artificiale di concentrarsi su aree specifiche dello schema. Una descrizione completa insieme a un esempio end-to-end funzionante è disponibile qui:
È possibile connettersi ad Azure OpenAI usando l'identità gestita?
Sì, è possibile connettersi ad Azure OpenAI usando l'identità gestita. In questo modo è possibile autenticare e accedere in modo sicuro al servizio Azure OpenAI senza dover gestire direttamente le credenziali. Per ulteriori informazioni consulta:
I dati vengono usati da Microsoft per i modelli di training?
No. I dati non vengono usati da Microsoft per i modelli di training. Per altre informazioni, vedere la documentazione sull'intelligenza artificiale responsabile.
Quali dati vengono elaborati dal servizio Azure OpenAI?
Per informazioni dettagliate su come vengono elaborati i dati forniti dall'utente per Azure modelli diretti in Microsoft Foundry, vedere Dati, privacy e sicurezza per Servizio Azure OpenAI. Un "modello diretto Azure" è un modello di intelligenza artificiale designato e distribuito come "modello diretto Azure" in Foundry e include Azure modelli OpenAI.
Come è possibile proteggere i dati dall'accesso non autorizzato dell'agente di intelligenza artificiale?
Azure SQL e SQL Server offrono un supporto completo per la sicurezza degli accessi con granularità fine:
- Introduzione alle autorizzazioni del motore di database: controllare l'accesso agli oggetti di database a un livello granulare usando le autorizzazioni.
- Utilizzare procedure memorizzate che eseguono solo operazioni espressamente autorizzate entro limiti prestabiliti. Concedere autorizzazioni EXECUTE a un agente solo in base alle esigenze, anziché concedere l'accesso diretto alle tabelle sottostanti. In questo modo, gli agenti interagiscono con il database in modo deterministico, usando istruzioni T-SQL pre-scritte.
- Row-Level Security (RLS): controllare l'accesso alle righe di una tabella in base alle caratteristiche dell'utente che esegue una query. Puoi vedere RLS in azione in questo video.
- Maschera dati dinamica: limitare l'esposizione dei dati sensibili mascherandoli agli utenti senza privilegi.
- Always Encrypted: proteggere i dati sensibili crittografandoli inattivi e in transito, assicurandosi che solo gli utenti autorizzati possano accedere ai dati non crittografati.
Per altre informazioni sul controllo nel motore di database SQL, vedere: