NIST AI风险管理框架生产级RAG实战

By Lakshman Pandey | August 2026

我交付了一个生产级 RAG（检索增强生成）系统，服务于英国艺术和文化领域的客户。本文记录了该系统如何实现 NIST AI 风险管理框架的各项控制，包含真实的决策过程、权衡取舍和可量化的成果。

专为低风险检索增强场景设计

所有决策均记录在 ADR（架构决策记录）中

每次查询成本 $0.003-0.005，基础设施月费 $25

EU 数据驻留（符合 GDPR）

Eval 框架防止质量下降

前端：Streamlit Cloud

向量数据库：Supabase pgvector（EU-West-2）

Embedding 模型：Voyage AI（1024 维）

LLM：Claude Haiku 4.5（直接调用 REST API）

可观测性：Langfuse

集成方式：MCP server（对接 Claude Desktop）

以检索为核心（本身不生成内容）

不进行模型训练或微调

部署前可进行人工审核

不涉及安全关键决策

NIST AI RMF 实现

NIST 框架有四个核心功能：GOVERN（治理）、MAP（映射）、MEASURE（测量）、MANAGE（管理）。以下是生产系统对每一项的实现方式。

1. GOVERN：建立治理结构

要求：为 AI 风险管理定义角色、责任和决策权限。

决策权限：单一架构师 + 客户利益相关者审批循环。

数据治理（ADR-001）：

决定：使用 EU 区域（伦敦）的 Supabase pgvector

原因：英国公共部门文化客户要求数据驻留在英国/EU 以符合 GDPR

风险：对 Supabase 的供应商依赖

缓解措施：Eval 框架 + ADR 确保可逆性

开发者：Lakshman（我）——系统架构、数据管道、部署

客户：英国公共部门利益相关者 ——审批治理策略、验证输出质量

运营：未来（待定）——监控、告警响应

策略：所有用户数据留在 EU。对 Claude/Voyage 的 API 调用均为瞬态（不存储在美国）。

测量：Langfuse 审计追踪记录每个查询的来源和去向。

2. MAP：识别 AI 风险

要求：识别 AI 系统在特定上下文、设计和使用场景下的风险。

风险评级：总体 = 低风险

以检索为核心（非生成式主导）

小规模、受控语料库（108 篇文档）

利益相关者有限（内部 + 客户团队）

不涉及实时安全关键决策

3. MEASURE：建立指标与监控

要求：定义指标以评估 AI 系统在整个生命周期中的性能和风险。

Eval 框架（第二阶段）：

基于 Ragas 构建了包含 18 个黄金问题的评估套件：

• Faithfulness（忠实度）：检测幻觉（答案与源文档一致）
• Context Precision（上下文精确度）：确保检索到的片段确实相关
• Context Recall（上下文召回率）：确保没有遗漏好的片段
• Answer Relevancy（答案相关度）：确保答案匹配问题

可观测性（第三阶段）：

Langfuse 集成追踪每条生产环境查询：

{
  "trace_name": "rag_query",
  "input": "What are the current content guidelines?",
  "output": "Based on sources [1][2]...",
  "input_tokens": 450,
  "output_tokens": 85,
  "cost_usd": 0.0031,
  "latency_ms": 1250
}

每次查询成本：$0.0005（embedding）+ $0.003（生成）= $0.0031

延迟目标：< 2 秒（目前约 1.2 秒）

4. MANAGE：实施风险缓解

要求：通过保障措施、监控和响应机制管理已识别风险。

提示工程：系统提示词强制"仅根据来源作答"约束

错误处理：try-catch 块防止崩溃；错误记录到 Langfuse

速率限制：（未来）每个会话最大查询数/小时

成本上限：（未来）每个客户月度支出硬上限

# phase3-deployment/app.py, lines 52-58
response = requests.post(
    "https://api.anthropic.com/v1/messages",
    json={
        "model": "claude-haiku-4-5-20251001",
        "messages": [{
            "role": "user",
            "content": (
                'Answer using ONLY the sources below. '
                f'If answer not in sources, say so.\n\n{context}\n\nQ: {question}'
            )
        }]
    }
)

未来保障措施（第四阶段）：

• 敏感查询的人工介入审批门禁
• 提示缓存以降低 25-50% 成本
• Microsoft Presidio 用于 PII（个人身份信息）脱敏
• CI/CD 回归门禁（部署前必须通过评估套件）

真实世界的权衡

ADR-001：Supabase vs 自托管 PostgreSQL

决策：云托管 Supabase pgvector（EU）

收益：托管备份、EU 数据驻留、零运维

成本：供应商锁定，如果 Supabase 变更则迁移成本中等

为何这个权衡胜出：

• 团队仅一人（无运维能力）
• 客户要求 EU 数据驻留
• EU 合规的长期价值 > 切换成本

ADR-002：Voyage AI vs Ollama

决策：云 API（Voyage）vs 本地（Ollama）

收益：云原生、1024 维（更高质量）、托管更新

成本：每次 embedding $0.0001，供应商依赖

为何这个权衡胜出：

• 可扩展至 10 个客户而无需基础设施变更
• 质量提升（1024 vs 768 维）可量化
• 每次查询成本不到一分钱

ADR-003：直接 REST 调用 vs Anthropic SDK

决策：手动 HTTP 调用（requests 库）vs SDK

收益：适用于 Python 3.14、依赖更少、显式控制

成本：无类型提示、手动错误处理

为何这个权衡胜出：

• Python 3.14 打破了 SDK（httpx/httpcore 不兼容）
• 直接 API 调用 = 面向未来
• 显式契约 = 更易于调试

对照 NIST 的衡量

GOVERN：✅ 文档化角色、EU 数据驻留、利益相关者审批

MAP：✅ 风险清单、低风险分类、已识别缓解措施

MEASURE：✅ Eval 框架（第二阶段）、Langfuse 追踪（第三阶段）、成本监控

MANAGE：⚠️ 基础错误处理、提示约束；未来计划：人工介入 + 支出上限

合规状态：符合 NIST 低风险场景要求。未来增强（第四阶段）将加强 MANAGE 功能。

数据驻留优先：对于英国公共部门客户，EU 托管是基本要求。先于其他因素选择了 Supabase。

数据驻留优先：对于英国公共部门客户，EU 托管是基本要求。先于其他因素选择了 Supabase。

一切皆需评估：第二阶段 eval 框架发现朴素关键词匹配不如向量搜索。测量 > 假设。

一切皆需评估：第二阶段 eval 框架发现朴素关键词匹配不如向量搜索。测量 > 假设。

直接 API > SDK 的稳定性：Python 3.14 让 4 个版本的 Anthropic SDK 失效。直接 HTTP 调用立即可用。

直接 API > SDK 的稳定性：Python 3.14 让 4 个版本的 Anthropic SDK 失效。直接 HTTP 调用立即可用。

成本透明建立信任：Langfuse 追踪使每次查询成本可见。客户对此很认可。

成本透明建立信任：Langfuse 追踪使每次查询成本可见。客户对此很认可。

记录决策，不只是代码：ADR 解释 WHY，不只是 HOW。对新成员入职和架构清晰度至关重要。

记录决策，不只是代码：ADR 解释 WHY，不只是 HOW。对新成员入职和架构清晰度至关重要。

下一阶段（第四阶段）

• 高风险查询的人工介入审批
• 提示缓存（节省 25-50% 成本）
• 摄入时 PII 脱敏（Microsoft Presidio）
• CI/CD 回归门禁（eval 必须通过）
• 使用 Voyage embeddings 重跑第二阶段 eval（证明质量持平）

关键 ADR 概览

• ADR-001：Supabase pgvector（EU 数据驻留）
• ADR-002：Voyage AI embeddings（生产级、云原生）
• ADR-003：直接 REST API（Python 3.14 稳定性）

系统构建阶段

• 第二阶段 Eval：Ragas 框架 + 18 个黄金问题
• 第三阶段系统：生产环境部署
• NIST AI RMF：https://www.nist.gov/itl/ai-risk-management-framework
• Supabase pgvector：https://supabase.com/docs/guides/database/extensions/pgvector
• Voyage AI：https://docs.voyageai.com/docs/embeddings
• Claude API：https://docs.anthropic.com/en/api/getting-started

Lakshman Pandey 是一位高级技术负责人，专注于内容密集型、受监管领域（英国公共部门、文化机构、教育）的 AI 解决方案架构。13 年以上全栈开发经验（Drupal、Python、Node.js）。目前构建在创新与治理要求之间取得平衡的 RAG 系统。

GitHub：code-lakshman/ai