Aplica-se a:
SQL Server 2025 (17.x) Base de Dados SQL do AzureAzure SQL Managed InstanceSQL database in Microsoft Fabric
Este artigo contém perguntas frequentes sobre vetores e incorporações no Mecanismo de Banco de Dados SQL.
Para amostras e exemplos, visite o repositório SQL AI Samples.
Posso criar uma solução de geração aumentada de recuperação (RAG) completamente em T-SQL?
Sim, pode criar uma solução de geração aumentada por recuperação (RAG) baseada nas funcionalidades nativas do Motor de Base de Dados SQL. Você pode usar o T-SQL para implementar a lógica de recuperação e processamento de dados necessária, ao mesmo tempo em que se integra com serviços de IA externos para o aspeto de geração. Os vetores podem ser armazenados nativamente no mecanismo SQL e conexões com LLMs que fornecem recursos de compreensão de linguagem natural são possíveis via sp_invoke_external_rest_endpoint.
Por que eu criaria uma solução RAG completamente em T-SQL?
Se você quiser melhorar um aplicativo existente sem ter que rearquitetá-lo para dar suporte aos recursos de IA, use os recursos internos do mecanismo SQL para implementar funcionalidades de IA diretamente em suas consultas de banco de dados. Você só precisa atualizar seu código T-SQL para incorporar recursos de IA, em vez de fazer alterações extensas na arquitetura do aplicativo.
Existem exemplos de ponta a ponta usando o SQL do Azure ou o SQL de malha para RAG?
Claro, você pode encontrar exemplos de ponta a ponta para RAG usando o SQL do Azure e o Fabric SQL aqui:
Posso ter o RAG trabalhando em dados estruturados, como colunas e linhas?
Se você precisar trabalhar com dados estruturados, ainda poderá aproveitar o RAG combinando-o com outras técnicas, como o uso de incorporações para representar seus dados estruturados de uma forma que possa ser compreendida pelo modelo de IA. Isso permite que você execute tarefas de recuperação e geração em dados estruturados enquanto ainda se beneficia dos recursos do RAG.
Porque é que enviar um esquema completo e complexo para um LLM leva a uma má geração de SQL, e como posso corrigir isso?
Se tiver um esquema de base de dados complexo e grande, com centenas de tabelas e vistas, é melhor usar uma abordagem multi-agente para ajudar a reduzir o ruído e permitir que os modelos de IA se concentrem em áreas específicas do esquema. Uma descrição completa, juntamente com uma amostra de trabalho de ponta a ponta, está disponível aqui:
Posso me conectar ao Azure OpenAI usando a Identidade Gerenciada?
Sim, você pode se conectar ao Azure OpenAI usando a Identidade Gerenciada. Isso permite que você autentique e acesse com segurança o Serviço OpenAI do Azure sem precisar gerenciar credenciais diretamente. Para obter mais informações, consulte:
Meus dados são usados pela Microsoft para modelos de treinamento?
No. Os dados não são usados pela Microsoft para modelos de treinamento. Para mais informações, consulte a documentação Responsible AI.
Que dados o Serviço OpenAI do Azure processa?
Para detalhes sobre como os dados fornecidos por si aos Azure Direct Models no Microsoft Foundry são processados, consulte Dados, privacidade e segurança para o Azure OpenAI Service. Um "Azure Direct Model" é um modelo de IA designado e implementado como "Azure Direct Model" no Foundry, e inclui modelos Azure OpenAI.
Como posso proteger meus dados contra acesso não autorizado ao AI Agent?
O SQL do Azure e o SQL Server fornecem suporte extensivo para segurança de acesso refinada:
- Introdução às permissões do Mecanismo de Banco de Dados: controle o acesso a objetos de banco de dados em um nível granular usando permissões.
- Use procedimentos armazenados que executem apenas operações especificamente autorizadas dentro dos limites definidos. Conceder permissões EXECUTE a um agente apenas quando necessário, em vez de conceder acesso direto às tabelas subjacentes. Desta forma, os agentes interagem com a base de dados de forma determinística, usando instruções T-SQL pré-escritas.
- Segurança de Nível de Linha (RLS): Para controlar o acesso às linhas de uma tabela com base nas características do utilizador que executa uma consulta. Você pode ver a RLS em ação neste vídeo.
- Mascaramento dinâmico de dados: limite a exposição de dados confidenciais mascarando-os a usuários sem privilégios.
- Sempre criptografado: proteja dados confidenciais criptografando-os em repouso e em trânsito, garantindo que apenas usuários autorizados possam acessar os dados não criptografados.
Para mais informações sobre auditoria no SQL Database Engine, veja: