AI Vibe Coding 25《数据与知识边界治理：RAG、记忆与上下文的安全设计》

当系统从“会用 AI”进入“依赖 AI”阶段后，最容易被低估的风险不是模型能力，而是数据边界。

典型问题：

RAG 把不该看的文档检索进来；
记忆层把临时会话信息长期保存；
上下文拼装把跨租户信息混在一起；
事后发现泄漏，却无法证明是哪个环节泄漏。

这章要解决的是：让 AI 的“看、记、用、忘”全部可治理。

学习目标

完成本章后，你将能够：

定义 RAG、记忆、上下文三层数据边界模型。
建立文档分级与检索权限联动机制。
控制会话记忆生命周期，实现可失效、可删除、可审计。
通过上下文装配策略避免跨租户与跨域语义污染。

一、先拆清三类数据通道

很多团队把所有信息都当“上下文”。这会让治理失焦。

应明确三条通道：

RAG Retrieval：从知识源检索外部信息。
Session Memory：会话中的短中期状态。
Runtime Context：本次任务拼装给模型的最终输入。

三条通道必须分别治理，不能混用。

二、知识分级：先给文档贴标签，再谈检索

如果知识源没有分级标签，RAG 权限控制几乎无法落地。

2.1 建议分级模型

P0-Public：公开资料，可全员检索。
P1-Internal：内部资料，需组织内身份。
P2-Restricted：受限资料，按角色与租户授权。
P3-Confidential：高敏资料，仅审批后临时可见。

2.2 文档元数据示例

doc_id: kb://finance/refund-policy-v5
classification: P2
owner_tenant: retail-cn
allowed_roles: ["policy_reviewer", "finance_agent"]
retention_days: 365

没有元数据，检索权限就是空谈。

三、RAG 检索边界：检索前鉴权，检索后净化

RAG 安全不只在“能不能查”，还在“查到后能不能直接用”。

3.1 检索前

强制携带 tenant_id、agent_role、task_purpose。
通过策略引擎做检索资格判定。

3.2 检索后

对结果做字段净化与脱敏。
对冲突文档做版本优选（最新且已生效）。
对低置信检索结果标注来源不确定性。

{
  "docId": "kb://finance/refund-policy-v5",
  "access": "allow",
  "sanitized": true,
  "confidence": 0.86,
  "policyRef": "POL-DATA-RAG-ALLOW-P2"
}

四、记忆治理：不是“记住越多越好”

记忆层常见误区是无限累积，导致两种风险：

敏感信息长期滞留；
过期语义污染当前决策。

4.1 记忆分层

Ephemeral Memory：单轮临时，任务结束即销毁。
Session Memory：会话级，TTL 到期失效。
Persistent Memory：长期记忆，必须白名单字段。

4.2 TTL 策略示例

memory_policy:
  ephemeral_ttl_minutes: 30
  session_ttl_hours: 24
  persistent_allowed_fields:
    - user_preference
    - project_glossary
  persistent_forbidden_fields:
    - id_card
    - bank_account
    - raw_contract_pdf

记忆应是“有价值的最小集合”，不是“全量备份”。

五、上下文装配：最小可用原则 + 来源可追溯

真正送进模型的 Runtime Context 必须遵循两条规则：

只装配当前任务必要信息。
每段上下文都能追溯来源和权限依据。

5.1 上下文块结构建议

{
  "chunkId": "ctx_001",
  "source": "kb://risk/approval-flow-v3",
  "tenantId": "retail-cn",
  "classification": "P1",
  "includedBy": "policy:POL-CTX-MINIMAL-01"
}

这能在事故时快速定位“哪段上下文把模型带偏”。

六、跨租户防污染：在装配层做最后一道闸门

即便前面都做了权限判定，仍建议在装配层再做一次边界验证。

6.1 关键校验

context.tenant_id == task.tenant_id
禁止混入非授权 tenant 的 chunk
禁止高分级数据降级输出

发现冲突直接阻断，不进入模型调用。

七、可遗忘机制：支持删除、撤回、法规响应

企业场景中，“被遗忘权”与“策略更新后失效”是刚需。

7.1 需要支持的动作

按用户删除记忆。
按租户批量失效知识索引。
按法规事件触发全链路清理。

7.2 删除审计

每次删除都应记录：

删除范围
触发原因
影响任务数
是否完成二次索引清理

八、观测与告警：把数据边界违规当 P0 处理

建议建立四类核心指标：

UnauthorizedRetrievalRate
CrossTenantContextBlockCount
SensitiveMemoryRetentionViolations
ContextSourceMissingRate

其中跨租户违规与敏感泄漏应直接触发 P0 告警。

九、Foundation 接口建议

public interface IRetrievalGuard
{
    RetrievalDecision Authorize(RetrievalRequest request);
}

public interface IMemoryPolicyEngine
{
    bool CanPersist(string fieldName, string classification);
    TimeSpan GetTtl(string memoryKind);
}

public interface IContextAssembler
{
    RuntimeContext Assemble(ContextRequest request);
}

public interface IForgettingService
{
    ForgetResult ForgetByUser(string tenantId, string userId);
    ForgetResult ForgetByPolicy(string policyEventId);
}

这四层分别对应“取、记、装、忘”，职责清晰且便于测试。

十、落地顺序（建议 3 周）

第 1 周：分级与鉴权

完成文档分级与检索鉴权接入。
建立检索后净化流程。

第 2 周：记忆与装配治理

上线记忆 TTL 与字段白名单。
统一上下文块元数据与装配校验。

第 3 周：可遗忘与审计

打通删除/失效机制。
接入边界违规告警与追踪面板。

常见坑

1) 只做检索权限，不做装配校验

前面安全，最后一步仍可能串线。

2) 记忆无 TTL

短期上下文会变成长期风险。

3) 上下文来源不可追溯

事故后无法定位责任链路。

4) 删除只删主存不删索引

看似删除，实际仍可被检索命中。

下一章进入《AI 协同平台收官：路线图、组织模型与长期演进机制》，把整条 Vibe Coding 路线沉淀为可持续的团队操作系统。