S'applique à :
SQL Server 2025 (17.x) Azure SQL DatabaseAzure SQL Managed InstanceBase de données SQL dans Microsoft Fabric
Cet article contient des questions fréquemment posées sur les vecteurs et les incorporations dans le moteur de base de données SQL.
Pour les échantillons et les exemples, consultez le référentiel SQL AI Samples.
Puis-je créer une solution de génération augmentée de récupération (RAG) complètement dans T-SQL ?
Oui, vous pouvez créer une solution de Retrieval-Augmented Generation (RAG) reposant sur les fonctionnalités natives du moteur de base de données SQL. Vous pouvez utiliser T-SQL pour implémenter la logique de récupération et de traitement des données nécessaires, tout en intégrant également des services IA externes pour l’aspect de génération. Les vecteurs peuvent être stockés en mode natif dans le moteur SQL et les connexions aux machines virtuelles LLM qui fournissent des fonctionnalités de compréhension du langage naturel sont possibles via sp_invoke_external_rest_endpoint.
Pourquoi créer une solution RAG complètement dans T-SQL ?
Si vous souhaitez améliorer une application existante sans avoir à la réécrire pour prendre en charge les fonctionnalités d’IA, utilisez les fonctionnalités intégrées du moteur SQL pour implémenter des fonctionnalités IA directement dans vos requêtes de base de données. Vous devez uniquement mettre à jour votre code T-SQL pour incorporer des fonctionnalités IA, plutôt que d’apporter des modifications approfondies à votre architecture d’application.
Existe-t-il des exemples de bout en bout utilisant Azure SQL ou Fabric SQL pour RAG ?
Vous trouverez des exemples de bout en bout pour RAG à l’aide d’Azure SQL et fabric SQL ici :
Puis-je utiliser RAG sur des données structurées, telles que des colonnes et des lignes ?
Si vous avez besoin d’utiliser des données structurées, vous pouvez toujours tirer parti de RAG en le combinant avec d’autres techniques, telles que l’utilisation d’incorporations pour représenter vos données structurées d’une manière qui peut être comprise par le modèle IA. Cela vous permet d’effectuer des tâches de récupération et de génération sur des données structurées tout en bénéficiant des fonctionnalités de RAG.
Pourquoi l’envoi d’un schéma complet et complexe à un LLM entraîne-t-il une génération SQL médiocre et comment puis-je le corriger ?
Si vous avez un schéma de base de données complexe et volumineux, avec des centaines de tables et de vues, il est préférable d’utiliser une approche multi-agent pour réduire le bruit et permettre aux modèles IA de se concentrer sur des zones spécifiques du schéma. Une description complète ainsi qu’un exemple de bout en bout de travail est disponible ici :
Puis-je me connecter à Azure OpenAI à l’aide de Managed Identity ?
Oui, vous pouvez vous connecter à Azure OpenAI à l’aide d’Une identité managée. Cela vous permet d’authentifier et d’accéder en toute sécurité au service Azure OpenAI sans avoir à gérer les informations d’identification directement. Pour en savoir plus, consultez :
Mes données sont-elles utilisées par Microsoft pour les modèles d’apprentissage ?
Non. Les données ne sont pas utilisées par Microsoft pour les modèles d’entraînement. Pour plus d’informations, consultez la documentation sur l’IA responsable.
Quelles données le service Azure OpenAI traite-t-il ?
Pour plus d’informations sur la façon dont les données fournies par vous pour Azure Modèles directs dans Microsoft Foundry sont traitées, consultez Données, confidentialité et sécurité pour Azure OpenAI Service. Un « modèle direct Azure » est un modèle IA désigné et déployé en tant que « modèle direct Azure » dans Foundry, et inclut Azure modèles OpenAI.
Comment puis-je protéger mes données contre l’accès non autorisé à l’agent IA ?
Azure SQL et SQL Server offrent une prise en charge étendue de la sécurité d’accès affinée :
- Prise en main des autorisations du moteur de base de données : contrôler l’accès aux objets de base de données à un niveau granulaire à l’aide d’autorisations.
- Utilisez des procédures stockées qui effectuent des opérations spécifiquement autorisées dans les garde-fous. N’accordez des autorisations EXECUTE à un agent que lorsque cela est nécessaire, au lieu de lui accorder un accès direct aux tables sous-jacentes. De cette façon, les agents interagissent de façon déterministe avec la base de données à l’aide d’instructions T-SQL préécrites.
- Sécurité au niveau des lignes (RLS) : contrôler l’accès aux lignes d’une table en fonction des caractéristiques de l’utilisateur qui exécute une requête. Vous pouvez voir RLS en action dans cette vidéo.
- Masquage dynamique des données : limitez l’exposition des données sensibles en les masquant aux utilisateurs non privilégiés.
- Always Encrypted : protégez les données sensibles en les chiffrant au repos et en transit, ce qui garantit que seuls les utilisateurs autorisés peuvent accéder aux données non chiffrées.
Pour plus d’informations sur l’audit dans le Moteur de base de données SQL, consultez :