59.实战为RAG系统加入评估监控权限和审计

实战：为 RAG 系统加入评估、监控、权限和审计

码海寻道 · 大模型、智能体与 RAG 工程组件系列第 59 篇

一个能回答问题的 RAG Demo，距离企业上线还缺四层能力：质量评估、运行监控、权限控制和操作审计。本篇把它们放进同一条请求链路，形成可解释、可追踪、可回归的系统。

一、统一请求上下文

python 复制代码

class RequestContext(TypedDict):
    trace_id: str
    run_id: str
    user_id: str
    tenant_id: str
    roles: list[str]
    knowledge_base_ids: list[str]
    model_version: str

上下文在 API、RAG 服务、向量检索、工具调用和审计事件之间传递。客户端传来的租户和角色不能覆盖服务端上下文。

二、权限控制链路

text 复制代码

认证
  ↓
资源授权
  ↓
知识库范围
  ↓
PostgreSQL 过滤
  ↓
Milvus 过滤
  ↓
引用和下载二次校验

权限检查结果也要进入 Trace 的非敏感属性，便于排查"为什么没有召回"，但不要把完整权限列表暴露给普通用户。

三、质量评估事件

json 复制代码

{
  "run_id": "run-001",
  "retrieved_chunk_ids": ["doc-001:v3:chunk-08"],
  "answer_citation_ids": ["doc-001:v3:chunk-08"],
  "scores": {
    "recall_at_5": 1.0,
    "faithfulness": 0.9,
    "answer_relevance": 1.0
  },
  "evaluation_version": "eval-v2"
}

离线评测集和线上用户反馈都应关联模型、Prompt、切分和索引版本。

评测事件还应保存数据集版本、权限上下文摘要、检索候选 ID、最终引用 ID、指标结果和 trace_id。高风险样本单独统计，不能让总体平均分掩盖越权、敏感信息或错误拒答。

四、运行监控指标

text 复制代码

API：QPS、错误率、P95、活跃 SSE
RAG：空结果率、Top K、Reranker 延迟、引用命中率
模型：输入/输出 Token、TTFT、超时、429
任务：队列深度、失败率、重试率、最老任务
基础设施：CPU、内存、连接池、Milvus 查询延迟

指标使用低基数标签，详细问题通过 trace_id 进入日志和 Trace。

建议统一 request_id、trace_id、run_id 和 job_id 的关系，并在 API、Worker、向量检索、模型调用、审计事件之间传播。Prometheus 标签保持低基数，用户问题、文档 ID 和完整 Prompt 放到受控日志或 Trace 属性中并按策略脱敏。

五、审计什么？

需要审计的动作包括：

登录和权限变化；
创建、发布、撤回和删除文档；
知识库访问和导出；
Agent 工具调用；
数据库写操作；
管理员跨租户访问；
评估和配置版本发布。

json 复制代码

{
  "audit_id": "audit-001",
  "trace_id": "trace-001",
  "actor_id": "user-001",
  "tenant_id": "tenant-a",
  "action": "document.publish",
  "resource_id": "doc-001:v3",
  "result": "success",
  "created_at": "2026-08-12T10:00:00Z"
}

六、把观测和业务数据分开

PostgreSQL 保存业务事实和审计索引，Langfuse 或 Trace 后端保存模型调用细节，Prometheus 保存指标。不要把所有完整 Prompt 和原文重复写入每个系统。

七、异常响应和脱敏

python 复制代码

def safe_error(exc: Exception, trace_id: str) -> dict:
    logger.exception("rag_failure", extra={"trace_id": trace_id})
    return {
        "error": {
            "code": "RAG_REQUEST_FAILED",
            "message": "请求处理失败，请稍后重试",
            "trace_id": trace_id,
        }
    }

内部日志可以保留更多诊断信息，但必须有权限、保留周期和脱敏策略。

八、评估和发布门禁

模型、Prompt、切分器和索引参数变更时，CI 或发布流程应运行固定评测集：

text 复制代码

Recall@K 不低于基线
忠实度不低于阈值
越权测试全部通过
P95 延迟不超过预算
Token 成本处于配额内

不满足门禁时阻止发布，或只进入灰度环境。

九、审计日志的安全

审计记录应尽量追加写入，限制修改和删除权限，并记录操作者、租户、资源、动作、结果、原因、审批和时间。审计系统不可用时，对删除、导出、权限变更等高风险动作应拒绝或进入待处理状态；普通问答可以降级，但不能静默丢失关键安全事件。

防止普通业务账号修改或删除；
记录操作者、时间、资源和结果；
敏感字段脱敏；
支持按 Trace 和资源查询；
设置归档和保留周期；
高风险操作可以写入不可变存储。

结语

企业 RAG 的质量、稳定性和安全需要同一条可追踪链路支撑：请求有上下文，检索有指标，模型有成本，权限有边界，操作有审计，版本有评估门禁。

下一篇将总结一个可维护 AI 应用的特征，回答 Demo 如何走向生产系统。

参考资料

本文为"码海寻道"原创技术文章。审计、权限和评估门禁应结合行业合规与组织安全流程落地。