Применимо к:
SQL Server 2025 (17.x) База данных Azure SQLУправляемый экземпляр Azure SQLБаза данных SQL в Microsoft Fabric
В этой статье содержатся часто задаваемые вопросы о векторах и внедрениях в ядро СУБД SQL.
Для примеров и образцов посетите репозиторий SQL AI Samples.
Можно ли целиком реализовать решение с генерацией, дополненной поиском (RAG), исключительно на T-SQL?
Да, вы можете создать решение RAG (с дополненной поиском генерацией) на базе встроенных возможностей ядра SQL ядро СУБД. Вы можете использовать T-SQL для реализации необходимой логики извлечения и обработки данных, а также интеграции с внешними службами ИИ для аспекта создания. Векторы могут храниться непосредственно в SQL-движке, а подключение к LLM, которые обеспечивают возможности понимания естественного языка, возможно через sp_invoke_external_rest_endpoint.
Почему я создаю решение RAG полностью в T-SQL?
Если вы хотите улучшить существующее приложение без необходимости перепроектировать его для поддержки возможностей искусственного интеллекта, используйте встроенные функции ядра SQL для реализации функций ИИ непосредственно в запросах базы данных. Вам нужно только обновить код T-SQL, чтобы включить функции ИИ, а не вносить значительные изменения в архитектуру приложения.
Существуют ли комплексные примеры с помощью SQL Azure или Fabric SQL для RAG?
Конечно, вы можете найти комплексные примеры для RAG с помощью SQL Azure и Fabric SQL здесь:
Можно ли использовать RAG для структурированных данных, таких как столбцы и строки?
Если вам нужно работать с структурированными данными, вы по-прежнему можете использовать RAG, объединяя его с другими методами, например с помощью внедрения для представления структурированных данных таким образом, чтобы их можно было понять моделью ИИ. Это позволяет выполнять задачи извлечения и создания структурированных данных при использовании возможностей RAG.
Почему отправка полной и сложной схемы в LLM приводит к некачественной генерации SQL, и как это исправить?
Если у вас есть сложная и крупная схема базы данных с сотнями таблиц и представлений, лучше использовать многоагентный подход, чтобы снизить шум и позволить моделям ИИ сосредоточиться на конкретных областях схемы. Полное описание, а также рабочий сквозной пример доступны здесь:
Можно ли подключиться к Azure OpenAI с помощью управляемого удостоверения?
Да, вы можете подключиться к Azure OpenAI с помощью управляемого удостоверения. Это позволяет безопасно проходить проверку подлинности и получать доступ к службе Azure OpenAI без необходимости управлять учетными данными напрямую. Дополнительные сведения можно найти здесь
Используются ли мои данные корпорацией Майкрософт для обучения моделей?
No. Данные не используются корпорацией Майкрософт для обучения моделей. Дополнительные сведения см. в документации по ответственному ИИ.
Какие данные обрабатывает служба Azure OpenAI?
Дополнительные сведения о том, как обрабатываются данные, которые вы предоставляете Azure Direct Models в Microsoft Foundry, см. в разделе Данные, конфиденциальность и безопасность для Служба Azure OpenAI. «Модель Azure Direct» — это модель ИИ, обозначенная и развернутая в Foundry как «модель Azure Direct», включая модели Azure OpenAI.
Как защитить данные от несанкционированного доступа агента ИИ?
Azure SQL и SQL Server обеспечивают расширенную поддержку тонкой настройки безопасности доступа.
- Приступая к работе с разрешениями ядра СУБД: управление доступом к объектам базы данных на детальном уровне с помощью разрешений.
- Используйте хранимые процедуры, выполняющие только специально разрешённые операции в рамках установленных ограничений. Предоставьте разрешения EXECUTE агенту только по мере необходимости, вместо предоставления прямого доступа к базовым таблицам. Таким образом, агенты взаимодействуют с базой данных детерминированным образом с помощью предварительно написанных инструкций T-SQL.
- Безопасность на уровне строк (RLS): управление доступом к строкам таблицы в зависимости от характеристик пользователя, выполняющего запрос. В этом видео вы можете увидеть RLS в действии.
- Динамическое маскирование данных: ограничение доступа к конфиденциальным данным путем их маскирования для непривилегированных пользователей.
- Always Encrypted: защита конфиденциальных данных путем шифрования неактивных и передаваемых данных, обеспечивая доступ только авторизованных пользователей к незашифрованным данным.
Дополнительные сведения об аудите в компоненте SQL ядро СУБД см. в следующей статье: