Van toepassing op:
SQL Server 2025 (17.x) Azure SQL DatabaseAzure SQL Managed InstanceSQL-database in Microsoft Fabric
Dit artikel bevat veelgestelde vragen over vectoren en insluitingen in de SQL Database Engine.
Ga naar de SQL AI Samples-repository voor voorbeelden.
Kan ik een oplossing voor retrieval-augmented generation (RAG) volledig in T-SQL bouwen?
Ja, u kunt een RAG-oplossing (Retrieval-Augmented Generation) maken op basis van systeemeigen functionaliteit in de SQL-Database Engine. U kunt T-SQL gebruiken om de benodigde logica voor het ophalen en verwerken van gegevens te implementeren, terwijl u ook integreert met externe AI-services voor het generatie-aspect. Vectoren kunnen systeemeigen worden opgeslagen in sql-engine en verbindingen met LLM's die mogelijkheden voor natuurlijke taalkennis bieden, zijn mogelijk via sp_invoke_external_rest_endpoint.
Waarom zou ik een RAG-oplossing volledig maken in T-SQL?
Als u een bestaande toepassing wilt verbeteren zonder deze opnieuw te ontwerpen om AI-mogelijkheden te ondersteunen, gebruikt u de ingebouwde FUNCTIES van de SQL Engine om AI-functies rechtstreeks in uw databasequery's te implementeren. U hoeft uw T-SQL-code alleen bij te werken om AI-functies op te nemen in plaats van uitgebreide wijzigingen aan te brengen in uw toepassingsarchitectuur.
Zijn er end-to-end-voorbeelden met behulp van Azure SQL of Fabric SQL voor RAG?
Natuurlijk vindt u hier end-to-end voorbeelden voor RAG met behulp van Azure SQL en Fabric SQL:
Kan ik RAG laten werken aan gestructureerde gegevens, zoals kolommen en rijen?
Als u met gestructureerde gegevens wilt werken, kunt u RAG nog steeds gebruiken door deze te combineren met andere technieken, zoals het gebruik van insluitingen om uw gestructureerde gegevens weer te geven op een manier die kan worden begrepen door het AI-model. Hiermee kunt u ophaal- en generatietaken uitvoeren op gestructureerde gegevens terwijl u nog steeds profiteert van de mogelijkheden van RAG.
Waarom leidt het verzenden van een volledig, complex schema naar een LLM tot slechte SQL-generatie en hoe kan ik dit oplossen?
Als u een complex en groot databaseschema hebt, met honderden tabellen en weergaven, is het beter om een benadering met meerdere agents te gebruiken om de ruis te verminderen en AI-modellen in staat te stellen zich te richten op specifieke gebieden van het schema. Hier vindt u een volledige beschrijving met een werkend end-to-end-voorbeeld:
Kan ik verbinding maken met Azure OpenAI met behulp van beheerde identiteit?
Ja, u kunt verbinding maken met Azure OpenAI met behulp van beheerde identiteit. Hiermee kunt u veilig verifiëren en toegang krijgen tot de Azure OpenAI-service zonder dat u referenties rechtstreeks hoeft te beheren. Voor meer informatie, zie:
Worden mijn gegevens gebruikt door Microsoft voor trainingsmodellen?
No. Gegevens worden niet door Microsoft gebruikt voor trainingsmodellen. Zie de documentatie voor Verantwoorde AI voor meer informatie.
Welke gegevens verwerkt de Azure OpenAI-service?
Zie Gegevens, privacy en beveiliging voor Azure OpenAI Service voor meer informatie over hoe gegevens die u hebt verstrekt aan Azure Directe modellen in Microsoft Foundry worden verwerkt. Een 'Azure Direct Model' is een AI-model dat is aangewezen en geïmplementeerd als een 'Azure Direct Model' in Foundry en Azure OpenAI-modellen bevat.
Hoe kan ik mijn gegevens beschermen tegen onbevoegde toegang tot AI-agent?
Azure SQL en SQL Server bieden uitgebreide ondersteuning voor verfijnde toegangsbeveiliging:
- Aan de slag met database-enginemachtigingen: beheer de toegang tot databaseobjecten op een gedetailleerd niveau met behulp van machtigingen.
- Gebruik stored procedures die alleen specifiek geautoriseerde bewerkingen uitvoeren binnen vastgestelde grenzen. Verleent EXECUTE-machtigingen aan een agent alleen als dat nodig is, in plaats van directe toegang te verlenen tot de onderliggende tabellen. Op deze manier communiceren agents deterministisch met de database met behulp van vooraf geschreven T-SQL-instructies.
- Row-Level Beveiliging (RLS):beheer de toegang tot rijen in een tabel op basis van de kenmerken van de gebruiker die een query uitvoert. U kunt RLS in actie zien in deze video.
- Dynamische gegevensmaskering: beperk de blootstelling van gevoelige gegevens door deze te maskeren voor niet-bevoegde gebruikers.
- Always Encrypted: Beveilig gevoelige gegevens door deze in rust en tijdens verzending te versleutelen, zodat alleen geautoriseerde gebruikers toegang hebben tot de niet-versleutelde gegevens.
Zie voor meer informatie over controle in de SQL-Database Engine: