AI聊天机器人授权开发指南

本文概述了通过强大授权方法保护AI聊天机器人的关键技术。通过使用Pinecone、Supabase和Microsoft Copilot等工具，介绍了元数据过滤、行级安全和基于身份的访问控制等技术，旨在保护敏感数据的同时优化AI驱动的工作流程。

AI聊天机器人正在彻底改变组织与数据交互的方式，带来个性化客户支持、改进的内部知识管理和高效业务流程自动化等好处。然而，随着能力的增强，需要强大的授权机制来防止对敏感数据的未授权访问。随着聊天机器人变得更加智能和强大，强大的授权对于保护用户和组织变得至关重要。

这是一个面向开发者的基础指南，介绍可用于为AI聊天机器人添加强大且精细授权的不同技术和提供商。以Pinecone、Supabase和Microsoft Copilot为参考，我们将深入探讨元数据过滤、行级安全（RLS）和基于身份的访问控制等实际技术。我们还将介绍OAuth/OIDC、JWT声明和基于令牌的授权如何保护AI驱动的交互。

最后，我们将讨论如何结合这些方法帮助创建符合组织需求的安全且可扩展的AI聊天机器人。

Pinecone：AI聊天机器人的元数据过滤

Pinecone是一个为AI应用设计的向量数据库，通过元数据过滤简化授权。这种方法允许用元数据（如用户角色或部门）标记向量，并在搜索操作期间进行过滤。在AI聊天机器人场景中特别有效，可以确保只有授权用户才能基于预定义的元数据规则访问特定数据。

理解向量相似性搜索

在向量相似性搜索中，我们构建数据的向量表示（如图像、文本或配方），将其存储在索引（向量的专用数据库）中，然后使用另一个查询向量搜索该索引。

这与谷歌搜索引擎的原理相同，它识别您的搜索查询如何与页面的向量表示对齐。类似地，Netflix、Amazon和Spotify等平台依赖向量相似性搜索，通过比较用户偏好并识别群体内的相似行为来推荐节目、产品或音乐。

然而，在保护这些数据时，实施授权过滤器至关重要，以便根据用户的角色、部门或其他特定上下文元数据限制搜索结果。

元数据过滤简介

元数据过滤通过为每个向量添加额外上下文（如用户角色、部门或时间戳）来为搜索过程添加授权层。例如，表示文档的向量可能包含如下元数据：

• 用户角色（例如，只有"经理"可以访问某些文档）
• 部门（例如，只有"工程"部门可访问的数据）
• 日期（例如，将数据限制为最近一年的文档）

这种过滤确保用户只检索他们有权查看的结果。

元数据过滤的挑战：预过滤与后过滤

图：向量数据库中的预过滤与后过滤（来源：Pinecone.io）

应用元数据过滤时，通常使用两种传统方法：预过滤和后过滤。

• 预过滤在搜索前应用元数据过滤器，将数据集限制为相关向量。虽然这确保只考虑授权向量，但它破坏了近似最近邻（ANN）搜索算法的效率，导致速度较慢的暴力搜索。
• 相比之下，后过滤先执行搜索，然后应用过滤器。这避免了预过滤带来的减速，但如果顶部匹配项都不满足过滤条件，则可能返回不相关的结果。例如，如果没有顶部向量通过元数据过滤器，您可能会检索到较少或没有结果。

为了解决这些问题，Pinecone引入了单阶段过滤。这种方法合并了向量和元数据索引，实现了速度和准确性。通过在一个单阶段过滤过程中实施访问控制，Pinecone在实时搜索中优化了性能和安全性。

应用元数据过滤进行授权：代码示例

现在，让我们探讨如何在实际AI聊天机器人用例中在Pinecone中实现元数据过滤。此示例演示如何插入带有元数据的向量，然后使用元数据过滤器查询索引以确保授权访问。

import pinecone

# 初始化Pinecone
pinecone.init(api_key="your_api_key", environment="us-west1-gcp")

# 创建索引
index_name = "example-index"

if index_name not already created:
    pinecone.create_index(index_name, dimension=128, metric="cosine")

# 连接到索引
index = pinecone.Index(index_name)

# 插入带有元数据的向量
vector = [0.1, 0.2, 0.3, ..., 0.128]  # 示例向量
metadata = {
    "user_id": "user123",
    "role": "admin",
    "department": "finance"
}

# 使用元数据更新插入向量
index.upsert(vectors=[("vector_id_1", vector, metadata)])

在此示例中，我们插入了一个带有相关元数据（如user_id、role和department）的向量，这些元数据稍后可用于实施访问控制。下一步涉及在查询索引时应用元数据过滤器，以根据用户的授权配置文件限制结果。

# 查询索引，基于元数据限制结果
query_vector = [0.15, 0.25, 0.35, ..., 0.128]

filter = {
    "user_id": "user123",  # 仅检索属于此用户的向量
    "role": {"$eq": "admin"}  # 可选：匹配角色
}

# 使用元数据过滤器执行查询
results = index.query(queries=[query_vector], filter=filter, top_k=5)

# 显示结果
for result in results["matches"]:
    print(result)

通过在查询期间应用元数据过滤器，我们确保只返回与用户元数据（例如用户ID和角色）匹配的向量，从而有效地实时实施授权。

实现复杂过滤器进行授权

元数据过滤还可以扩展到处理更复杂、多维的授权场景。例如，我们可以基于多个条件过滤结果，例如将搜索结果限制在特定部门和日期范围内的文档。

# 使用多个元数据条件查询
filter = {
    "department": {"$eq": "finance"},
    "date": {"$gte": "2023-01-01", "$lt": "2023-12-31"}
}

results = index.query(queries=[query_vector], filter=filter, top_k=5)

# 显示结果
for result in results["matches"]:
    print(result)

向量相似性搜索和元数据过滤的这种组合为细粒度授权创建了一个强大的框架。它通过基于角色、部门和时间框架等多个维度将搜索结果限制给授权用户，确保AI聊天机器人能够提供高性能和安全、上下文驱动的响应。

想了解更多关于元数据过滤的信息，并查看Descope和Pinecone的完整构建示例？请查看我们下面的博客：
为Pinecone RAG应用添加身份验证和访问控制

Supabase：向量数据的行级安全

图：使用Postgres和Supabase的RLS

元数据过滤非常适合基于类别或标签的广泛访问控制（例如，按部门或角色限制搜索结果）。但是，当需要严格控制谁可以查看、修改或检索特定记录时，它就不够了。

在依赖关系数据库的企业系统（如金融平台）中，访问通常需要强制执行到单个交易记录或客户数据行。Supabase行级安全（RLS）通过定义基于用户属性或使用外部数据包装器（FDW）的外部权限系统在行级别实施精细权限的策略来实现这一点。

虽然元数据过滤擅长管理对非关系型、基于向量的数据的访问——非常适合AI驱动的搜索或推荐系统——但Supabase RLS提供了精确的记录级控制，使其更适合需要严格权限和合规性的环境。

有关Supabase及其RLS功能的额外阅读，请查看我们下面的博客，演示如何使用Descope将SSO添加到Supabase。
使用Descope为Supabase添加SSO

为检索增强生成（RAG）实施RLS

在检索增强生成（RAG）系统中，如Pinecone中的向量相似性搜索，文档被分解为更小的部分以进行更精确的搜索和检索。

以下是如何在此用例中实施RLS：

-- 跟踪文档/页面/文件等
create table documents (
  id bigint primary key generated always as identity,
  name text not null,
  owner_id uuid not null references auth.users (id) default auth.uid(),
  created_at timestamp with time zone not null default now()
);

-- 为每个部分存储内容和嵌入向量
create table document_sections (
  id bigint primary key generated always as identity,
  document_id bigint not null references documents (id),
  content text not null,
  embedding vector(384)
);

在此设置中，每个文档都链接到一个确定访问权限的owner_id。通过启用RLS，我们可以将访问限制为仅文档的所有者：

-- 启用行级安全
alter table document_sections enable row level security;

-- 为选择操作设置RLS
create policy "Users can query their own document sections"
on document_sections for select to authenticated using (
  document_id in (
    select id from documents where (owner_id = (select auth.uid()))
  )
);

一旦启用RLS，对document_sections的每个查询将只返回当前认证用户拥有相关文档的行。即使在向量相似性搜索期间，这种访问控制也会被强制执行：

-- 基于匹配阈值执行内积相似性
select *
from document_sections
where document_sections.embedding <#> embedding < -match_threshold
order by document_sections.embedding <#> embedding;

这确保语义搜索尊重RLS策略，因此用户只能检索他们有权访问的文档部分。

使用外部数据包装器处理外部用户和文档数据

如果您的用户和文档数据驻留在外部数据库中，Supabase对外部数据包装器（FDW）的支持允许您连接到外部Postgres数据库，同时仍然应用RLS。如果您的现有系统在外部管理用户权限，这尤其有用。

以下是如何在处理外部数据源时实施RLS：

-- 为外部用户和文档创建外部表
create schema external;
create extension postgres_fdw with schema external;

create server foreign_server
  foreign data wrapper postgres_fdw
  options (host '<db-host>', port '<db-port>', dbname '<db-name>');

create user mapping for authenticated
  server foreign_server
  options (user 'postgres', password '<user-password>');

import foreign schema public limit to (users, documents)
  from server foreign_server into external;

一旦链接了外部数据，您可以应用RLS策略基于外部数据过滤文档部分：

create table document_sections (
  id bigint primary key generated always as identity,
  document_id bigint not null,
  content text not null,
  embedding vector(384)
);

-- 外部数据源的RLS
create policy "Users can query their own document sections"
on document_sections for select to authenticated using (
  document_id in (
    select id from external.documents where owner_id = current_setting('app.current_user_id')::bigint
  )
);

在此示例中，app.current_user_id会话变量在每个请求开始时设置。这确保Postgres基于外部系统的权限实施精细访问控制。

无论您是管理简单的用户-文档关系还是具有外部数据的更复杂系统，Supabase的RLS和FDW组合为在向量相似性搜索中实施授权提供了可扩展、灵活的解决方案。

这确保为用户提供强大的访问控制，同时在RAG系统或其他AI驱动应用中保持高性能。

行级安全（RLS）与元数据过滤

Pinecone元数据过滤和Supabase RLS都提供强大的授权机制，但它们适用于不同类型的数据和应用：

• Supabase RLS：适用于结构化、关系型数据，其中访问需要在行级别控制，特别是在需要为单个记录（例如在RAG设置中）提供精确权限的应用中。Supabase RLS提供严格的控制，并具有通过外部数据包装器（FDW）集成外部系统的灵活性。
• Pinecone元数据过滤：适用于搜索或推荐系统中的非关系型、基于向量的数据。它使用元数据提供动态、上下文驱动的过滤，允许AI驱动的应用在检索期间灵活高效地管理访问。

何时选择

• 如果您的应用专注于依赖快速、可扩展的向量数据搜索和元数据驱动访问控制的AI驱动搜索或推荐系统，请选择Pinecone。
• 如果您需要为结构化数据控制单个数据库行的访问，特别是在需要复杂权限的情况下，请选择Supabase。

特性	Pinecone	Supabase
授权模型	向量的元数据过滤	数据库行的行级安全（RLS）
范围	搜索和推荐系统的基于向量的过滤	单个行和文档的数据库级访问控制
效率	单阶段过滤，用于快速、大规模搜索	Postgres强制RLS，用于精细数据访问
复杂性	使用元数据标签简单实现	需要在Postgres中配置策略和规则
性能	针对具有快速搜索时间的大数据集进行了优化	如果应用复杂的RLS策略，对于大型数据集可能较慢
与外部系统集成	不适用	支持外部数据包装器（FDW）以集成外部数据库
理想用例	搜索和推荐系统，AI驱动的客户支持，处理非关系型或基于向量的数据的SaaS应用	具有结构化、关系型数据的SaaS平台；需要严格行级控制的企业应用（例如金融、医疗、合规严格的环境）

虽然两种方法各有优势，但都不能完全覆盖复杂的组织范围数据访问需求。对于更广泛、多层次的解决方案，Microsoft Purview提供了一个整合两种方法元素以跨多个系统和数据类型全面管理数据访问的示例。

Microsoft 365 Copilot和Purview：AI聊天机器人授权的真实示例

图：Microsoft 365 Copilot访问用户数据（来源：Microsoft）

Microsoft 365 Copilot和Purview提供了一个多层系统，用于管理数据访问，结合了元数据过滤、基于身份的访问控制和用法权利实施。这种方法与Microsoft Entra ID（前身为Azure AD）无缝集成，应用为内部和外部用户跨Microsoft服务配置的相同授权规则。

Microsoft Purview中的数据产品：为数据访问添加上下文

图：Microsoft Purview访问控制治理（来源：Microsoft）

Microsoft Purview的一个关键特性是使用数据产品，这些是围绕业务用例组织的相关数据资产（如表、文件和报告）的集合。这些数据产品简化了数据发现和访问，确保治理策略得到一致应用。

数据映射提供了数据如何在组织中流动的全面视图。它们通过跟踪数据产品的组织、所有权和治理，确保敏感数据得到正确标记和管理。例如，标记为"机密"的财务报告可以限制给财务员工，而外部审计员可能基于预配置规则具有有限访问权限。

与Entra ID集成：无缝授权

Microsoft Entra ID在所有Microsoft服务中实施现有的授权策略。这种集成确保角色、权限和组成员资格在SharePoint、Power BI和Microsoft 365 Copilot等服务中得到自动尊重。

• 统一授权：在Entra ID中配置的员工角色和权限决定了用户可以交互的数据，确保Copilot遵守相同的规则。
• 外部用户访问：Entra ID简化了外部合作伙伴或供应商的访问控制，允许安全协作，同时尊重应用于内部用户的相同敏感标签和权限。
• 自动化敏感标签：通过利用敏感标签，Purview自动在所有数据产品中实施加密和用法权利，确保安全数据处理，无论是由Copilot查看、提取还是总结。
• Microsoft生态系统的一致性：治理和授权策略在所有Microsoft服务中保持一致，提供跨工具（如SharePoint、Power BI和Exchange Online）的无缝保护。

Purview和Copilot的好处

Copilot、Purview和Entra ID的集成提供了跨组织可扩展、安全和自动实施的数据访问策略。无论对于内部还是外部用户，这种设置在部署新服务（如AI聊天机器人）时消除了手动配置访问控制的需要，提供了一个简化的、企业级的数据治理解决方案。

为您的AI聊天机器人选择正确的授权策略

选择适当的授权方法对于在AI聊天机器人中平衡安全性、性能和可用性至关重要：

• Pinecone元数据过滤：最适合基于向量的数据和AI驱动的搜索或个性化内容交付。它提供基于上下文的控制，非常适合非关系型数据。
• Supabase行级安全（RLS）：提供对单个数据库记录的精细控制，使其完美适用于用户需要在关系型数据库中进行特定行级访问的SaaS应用。
• Microsoft Enterprise Copilot：适用于需要跨多种数据类型和系统进行基于身份的访问的企业级应用。它提供了一个结构化的、面向业务的数据治理方法。

结合身份验证和授权解决方案

选择正确的授权策略只是解决方案的一半。集成强大的身份验证系统对于安全无缝的AI聊天机器人同样重要。

使用像Descope这样的OIDC兼容身份验证提供商简化了与第三方服务的集成，同时通过基于JWT的令牌管理用户、角色和访问控制。这确保令牌可以实施上述的精细授权策略。

以下是结合AI授权与现代身份验证系统的好处：

• 无缝集成：OIDC合规性使用标准身份验证协议简化了与外部系统的连接。
• 动态访问控制：来自Descope或Supabase Auth等服务的JWT令牌允许实时管理角色和权限，确保灵活和安全的访问控制。
• 可扩展性：灵活授权模型（RLS或元数据过滤）与强大身份验证服务的结合使您的聊天机器人能够安全扩展，管理大量用户而不牺牲安全性。

要了解更多关于Descope在AI应用中的能力，请访问此页面或查看我们下面关于使用Descope为Next.js AI聊天应用添加身份验证的博客。
DocsGPT：使用Next.js和OpenAI构建带身份验证的AI聊天

结论

AI聊天机器人和AI代理正在改变行业，但通过强大授权保护数据至关重要。无论您采用元数据过滤、行级安全、基于身份的访问控制还是它们的混合组合，每种方法都为聊天机器人安全提供了独特的好处。

通过集成一个OIDC兼容的身份验证解决方案，该解决方案使用基于JWT的令牌管理用户和角色，您可以构建一个可扩展且安全的聊天机器人系统。选择正确的工具组合确保效率和数据安全，使您的聊天机器人适合多样化的业务需求。

想与志同道合的开发者讨论身份验证和AI？加入Descope的开发社区AuthTown提问并保持联系。
更多精彩内容 请关注我的个人公众号 公众号（办公AI智能小助手）
公众号二维码