category
我们已经看到,希望使用Azure OpenAI服务结合自己的数据访问大型语言模型(LLM)的组织对此非常感兴趣。允许这些应用程序访问您组织的知识库,可以包含与对话相关的数据,从而创造更丰富、更有用的体验。然而,如果Generative AI应用程序不知道任何访问控制要求,这会带来新的问题。我们最近更新了AI Search OpenAI Demo,允许用户登录和访问控制,这使Generative AI应用程序能够根据每个用户定制响应。
Azure人工智能搜索的生成型人工智能应用程序中的访问控制
您如何将自己的数据与Generative AI相结合?
通常情况下,您只需询问ChatGPT的一般问题,即可获得良好的回复。然而,当您向ChatGPT询问有关您的组织的特定问题时,这种方法就会失效。当我问“我的Northwind Health Plus计划中包含的内容不符合标准”时,我得到的回答就不那么有用了,“对不起,我无法获得您的健康计划”。如果有办法将您组织的数据与ChatGPT结合在一起就好了!幸运的是,使用检索增强生成(RAG)方法可以实现这一点。
使用AI搜索
人工智能搜索是一个人工智能驱动的信息检索平台,允许您使用RAG方法将LLM与组织的数据相结合。使用Azure Open AI嵌入模型对组织知识库中的文档进行分块和嵌入。然后在AI搜索中将嵌入与文档文本一起编入索引。
AI搜索结合多种搜索方法来提高搜索结果。通过对文档文本进行关键字搜索,可以匹配文档中的特定术语。矢量搜索更进一步,可以找到与搜索查询语义相似的文档部分。使用称为互秩融合(RRF)的混合方法来组合来自两个步骤的搜索结果。最后,语义排名利用了微软必应的机器学习模型的力量,进一步改进了这些混合搜索结果。
安全的需要
并非您的知识库中的所有文档都是供组织外的公众使用的。销售报告、竞争研究或其他敏感文档甚至可能对您组织的所有成员都不可见。如果您创建了一个简单的应用程序,允许您与知识库中的所有数据聊天,那么您可能会无意中将文档暴露给错误的受众。
通常,任何访问控制解决方案都需要两个组件:
- 用于管理用户帐户及其权限的系统。
- 文档存储允许权限与文件或文件夹关联。
了解身份和访问管理
在我们深入了解解决方案的细节之前,对Azure中身份和访问管理的工作原理有一个大致的了解是很重要的。部署基于云的应用程序时,主要关注的问题之一是确保您的用户能够安全访问它。Microsoft Entra ID(前身为Azure Active Directory)是Azure的身份和访问管理解决方案,有助于您的组织安全访问外部和内部资源。以下是Microsoft Entra ID术语的简要概述:
- 租户–代表您的整个组织。所有Azure订阅都与租户具有信任关系。租户为订阅执行与身份和访问管理相关的操作。订阅只能信任单个租户,但多个订阅可能信任单个租户。
- 用户–表示与您的组织有关系的个人。此人可能是与您合作的其他组织的员工或客人。该用户的帐户信息可能存储在您的租户中,也可能来自Facebook等外部社交身份提供商。租户可以有许多用户。
- 身份验证–确认用户是他们所说的那个人。您的组织可能对身份验证有不同的策略要求,例如要求多因素身份验证或只允许从组织管理的设备进行身份验证。
- 授权–一旦用户通过身份验证,就授予他们做某事的权限。例如,管理员用户可能有能力向租户添加新用户,但普通用户没有此权限。身份验证和授权这两个术语经常互换使用,但它们实际上是不同的概念。
Microsoft Entra ID中的身份验证和授权是使用OAuth 2.0和Open ID Connect协议实现的。
- 应用程序–表示组织使用的应用程序。通过向租户注册应用程序,您可以将身份验证和授权委托给Microsoft Entra ID。租户可以有多个应用程序,但一个应用程序只能在一个租户中注册。
- 权限和同意–应用程序需要访问资源。例如,日历应用程序需要访问用户的日历来安排会议。像用户日历这样的资源通过基于权限的系统受到Microsoft Entra ID的保护。应用程序使用两种通用模型访问这些受保护的资源:
- 委派访问–用户登录应用程序并同意该应用程序,以便该应用程序可以代表他们访问受保护的资源。如果用户不同意,则不允许应用程序访问受保护的资源。
- 仅应用程序访问–应用程序在没有任何登录用户的情况下访问受保护的资源。此模型通常用于不需要用户交互的后台服务。租户管理员必须同意这些应用程序访问受保护的资源。
- 安全令牌–当用户对应用程序进行身份验证和登录时,他们将获得一个安全令牌。此安全令牌表示用户的身份以及他们同意授予应用程序访问受保护资源的权限。令牌以称为声明的键值对的形式包含有关用户的信息。令牌是加密安全的,在执行身份验证和授权相关任务时由Microsoft Entra ID验证。Microsoft Entra ID支持用户登录的各种身份验证流。
现在我们已经了解了身份和访问管理的基本知识,让我们看看如何增强Generative AI应用程序的安全性。
将人工智能搜索与Microsoft Entra ID集成
为了解释集成是如何工作的,我们将使用这个演示存储库,任何人都可以部署它,只要他们具备以下先决条件:
- Entra ID租户
- 具有以下任何角色的Azure帐户允许应用程序管理:
- 应用程序管理员
- 应用程序开发人员
- 云应用程序管理员
原始应用程序架构
在没有任何身份或访问管理的情况下,演示使用以下体系结构:
- 当部署演示应用程序时,样本数据被编入AI搜索索引。
- 用户与单页应用程序进行交互。他们可以与样本数据聊天,也可以就此提出问题。
- 单页应用程序对后端API服务器进行API调用。API服务器通过查询AI搜索来查找相关样本数据,并使用Azure OpenAI将结果上下文和查询相结合,从而实现RAG模式。
添加访问控制
当我们添加身份和访问管理时,演示架构会发生变化:
- 示例数据通过租户的示例组进行了扩充。
- 提供了示例脚本来创建这些组,并将具有访问控制的示例数据上传到data Lake Storage Gen2帐户。Data Lake Storage Gen2支持与Microsoft Entra ID集成,以实现对单个文件和文件夹的访问控制。
- 提供了示例脚本来更新AI搜索中的索引结构,以支持身份和访问管理。添加了额外的字符串集合字段,以便在文档内容旁边存储用户和组标识符。
- 如果AI搜索中的这些访问控制字段填充正确,任何可以存储Microsoft Entra ID用户或组标识符的数据源都可以与演示应用程序一起使用。
- 单页应用程序已注册并与Microsoft Entra ID集成,以支持用户身份验证。在应用程序界面中添加了登录和注销按钮。其他选项将添加到开发人员选项窗格中:
-
- “使用oid安全筛选器”。此选项切换租户中用户的标识符是否用于AI搜索中的安全过滤。
- “使用组安全筛选器”。此选项可切换用户在租户中所属的组是否用于AI搜索中的安全筛选。
- “ID令牌声明”。此表显示登录到单页应用程序后收到的ID令牌中的所有声明。
- 应用程序服务器已注册并与Microsoft Entra ID集成,以支持用户授权。
- RAG模式与API服务器中的Microsoft Entra ID集成在一起。从AI搜索中检索到的文档使用登录用户的身份或组成员身份进行过滤。启用安全筛选后,用户只能在示例知识库中使用他们可以访问的数据进行聊天。
让我们来了解一下演示是如何与Microsoft Entra ID集成的。
了解与Microsoft Entra ID的集成
设置演示的步骤记录在存储库中。以下是如何使用设置步骤与Microsoft Entra ID进行高级别集成:
- 在租户中创建一个新的Entra应用程序注册,代表后端API服务器。
- API服务器需要机密凭据才能向租户进行身份验证。
- API服务器使用on-behalf-of流从租户获取令牌,但仍需要权限才能执行此操作。API服务器应用程序公开了一个名为“access_as_user”的新权限,因此单页应用程序可以与其集成。
- 已登录用户的组使用可选的组声明添加到令牌中。但是,声明限制为200个组,以防止令牌过大。若要绕过此限制,API服务器需要委派的Microsoft。从Microsoft Graph读取用户组成员身份的读取权限。
- 在租户中创建另一个Entra应用程序注册,代表单页前端应用程序。
- 单页应用程序不需要任何凭据来向租户进行身份验证。
- 单页应用程序使用身份验证代码流来获取令牌。这需要注册重定向URI,以便租户能够在成功登录后将令牌通信回单页应用程序
- 单页应用程序必须向API服务器应用程序请求“access_as_user”权限,才能使代理流正常工作。
- 最后,单页应用程序必须注册为API服务器应用程序的“已知客户端应用程序”。这将对单页应用程序的同意与API服务器应用程序绑定在一起,从而避免了第二次同意对话框的需要。
- 下图说明了单页应用程序如何与API服务器交互并与Microsoft Entra ID集成:
- 使用授权信息在AI搜索中执行过滤。
- 用户的标识符从令牌声明中提取,并与用户的组成员身份相结合。
- API服务器向AI Search发送的查询中添加了包含授权信息的过滤器。
- 此筛选器使用特定的search.in语法,该语法可以在单个查询中支持数百甚至数千个组或用户标识符。
- 例如,要使用单个组标识符在groups字段上进行筛选,筛选器将为groups/any(g:search.in(g,'x'))
- 可以使用和或或运算符组合过滤器。例如,为了匹配访问控制字段中存在用户id或组id的文档,过滤器将是groups/any(g: search.in(g, 'x')) or users/any(g: search.in(g, 'y'))
下图演示了API服务器如何使用过滤器从AI搜索中检索与登录用户权限匹配的文档:
接下来的步骤
将Generative AI和访问控制相结合,可以解锁无数新的用例,增强安全性、合规性和生产力。我们邀请您通过部署我们的示例应用程序来探索这项尖端技术。
- 登录 发表评论
- 7 次浏览
最新内容
- 1 week ago
- 1 week ago
- 1 week ago
- 1 week ago
- 1 week ago
- 1 week 6 days ago
- 2 weeks ago
- 2 weeks 2 days ago
- 2 weeks 2 days ago
- 2 weeks 2 days ago