面向 LLM 安全的 AI Guardrails
TrustyAI Guardrails Orchestrator 会在 LLM 输入和输出上运行检测器,以过滤或标记内容。它基于开源的 FMS-Guardrails 项目。TrustyAI Operator 提供了 GuardrailsOrchestrator CRD,用于部署和管理它。
本文仅介绍 AutoConfig 部署以及 内置的 regex 检测器。
目录
前提条件使用 AutoConfig 部署资源状态内置 regex 检测器Gateway ConfigMap 结构Service 端口和 API 参考端口和 角色认证(已启用 auth)请求路径参考API 使用和示例独立检测 (/api/v1/text/contents)Orchestrator API:按请求选择 detector (/api/v2/chat/completions-detection)Gateway API:预设 pipeline (/all/v1/chat/completions)前提条件
- 已安装 TrustyAI Operator(参见 Install TrustyAI)。
- 在目标 namespace 中已将 LLM 作为 InferenceService 部署。
使用 AutoConfig 部署
使用 AutoConfig 时,operator 会根据 namespace 中的资源生成 orchestrator 和 gateway 配置;对于基础设置,无需手动创建 ConfigMap。
创建一个带有 autoConfig、并启用内置检测器和 gateway 的 GuardrailsOrchestrator 自定义资源:
inferenceServiceToGuardrail:要进行 guardrail 的 InferenceService(LLM)名称;必须与同一 namespace 中已部署的模型匹配。enableBuiltInDetectors:当为true时,会添加一个内置 regex 检测器 sidecar。enableGuardrailsGateway:当为true时,gateway 会暴露预设路由(例如/all/v1/chat/completions)。
资源状态
该资源具有一个 status 子资源。status.phase 可以是 Progressing、Ready 或 Error。使用 AutoConfig 时,status.autoConfigState 会保存生成的 ConfigMap 名称(generatedConfigMap、generatedGatewayConfigMap)、检测到的服务以及 message。只有在 status.phase == Ready 且对应的 Deployment 处于就绪状态后,才应发送流量。
operator 会创建一个 orchestrator ConfigMap 和一个名为 <orchestrator-name>-gateway-auto-config 的 gateway ConfigMap。内置检测器会以 built-in-detector 的名称注册。
内置 regex 检测器
内置检测器提供基于 regex 的算法。支持的算法包括:
默认的 gateway 配置使用一个占位 regex($^)。要启用某个特定算法(例如 email),请 patch 该 ConfigMap,并将 detector_params.regex 设置为算法名称(例如 - email)。
Gateway ConfigMap 结构
ConfigMap 名称:<orchestrator-name>-gateway-auto-config。示例:
将 built-in-detector 下的 regex 改为所需算法(例如 - email)。更新后,等待 Deployment 就绪。
Service 端口和 API 参考
Guardrails Orchestrator 通过名为 <orchestrator-name>-service 的 Service 暴露。端口号取决于是否启用认证(在 GuardrailsOrchestrator 上添加注解 security.opendatahub.io/enable-auth: "true")。
端口和 角色
启用认证时,gateway 和 built-in-detector 端口都需要 Bearer token。
认证(已启用 auth)
发送到 gateway 或 built-in-detector 端口的请求必须包含:
Authorization: Bearer <token>
该 token 必须是有效的 Kubernetes ServiceAccount token(或集群 auth proxy 接受的其他 token),且其主体对该服务具有访问权限(例如 services/proxy)。未授权请求会返回 401/403。
如何获取 token
在与 Guardrails Orchestrator 相同的 namespace 中创建一个 ServiceAccount、一个 Role(对 services/proxy 具有 get、create 权限)以及一个 RoleBinding;然后为该 ServiceAccount 创建 token:
也可以设置 token 的有效期,例如 --duration=8760h 表示一年。最后一条命令会输出 token;将其作为 Authorization: Bearer <token> 的 header 值。
集群内的客户端可以使用投影的 ServiceAccount token volume 作为 Bearer token。
请求路径参考
其他 gateway 路由(例如 /<preset-name>/v1/chat/completions)在 gateway ConfigMap 的 routes 中定义。
API 使用和示例
独立检测 (/api/v1/text/contents)
在不调用 LLM 的情况下,对文本运行内置 regex 检测器。使用 built-in-detector 端口(8080 或 8480)。请求体:contents(字符串列表)、detector_params(例如 regex: ["email"])。
使用 Service 地址(集群内:<orchestrator-name>-service.<your-namespace>.svc.cluster.local;集群外:如果已暴露,则使用 Ingress host)以及 built-in-detector 端口(参见 端口和 角色)。
Response: 数组(每个 contents 条目对应一项),其中包含检测对象数组。每个对象具有 start、end、text、detection(例如 EmailAddress)、detection_type(例如 pii)以及 score。
Response 示例(独立检测,检测到 email)
Orchestrator API:按请求选择 detector (/api/v2/chat/completions-detection)
当调用方必须为每个请求选择运行哪些 detector 时,请使用 orchestrator 端口(8032 或 8432)。请求体:model、messages,以及可选的 detectors(例如带有 detector 参数的 input / output)。
示例:在输入和输出上运行带有 regex email 的内置检测器:
当检测器在输入中发现匹配项(例如 email)时,响应会包含 detections 和 warnings,并且 choices 为空:
Response 示例(输入触发检测)
响应结构与 gateway chat 一致:choices、detections、warnings。如果是普通 chat completion 且不进行检测,则省略 detectors。
Gateway API:预设 pipeline (/all/v1/chat/completions)
使用 gateway 端口(8090 或 8490)进行 chat,并使用固定的 detector pipeline(在 gateway ConfigMap 中定义)。请求体:model、messages(OpenAI-style)。如果需要按请求选择 detector,请改用 orchestrator API。
使用 Service 地址和 gateway 端口(参见 端口和 角色)。
当输入/输出通过时: detections 和 warnings 为 null,choices 中包含模型回复:
Response 示例(输入/输出通过)
当输入触发检测时(例如 PII): detections 和 warnings 会被设置,choices 为空: