X-Financial/document/development/自我进化学习闭环/CONCEPT.md

# X-Financial 自我进化学习闭环方案

更新日期：2026-06-23

## 功能一句话

把 X-Financial 从“规则 + 图谱 + Agent 的智能费控系统”升级为“可持续学习的费控智能体平台”：先通过反馈、回放和影子运行让分析能力变强，再把稳定结论沉淀为可审核、可测试、可回滚的规则、参数和知识资产。

## 背景与问题

当前系统已经具备费用申请、报销、审批、规则中心、知识库、小财管家、数字员工、风险观察、员工画像和财务行为图谱。现有能力已经不是单一算法，而是由多类算法共同形成判断：

- 规则引擎负责执行已上线的制度口径和风险 DSL。
- 风控图谱负责识别重复票据、拆单、高频、跨部门聚集、同组偏离等风险信号。
- 员工画像和申请人画像负责建立同组基线、流程质量和历史行为特征。
- 知识库负责制度检索、引用和政策解释。
- Agent 编排负责意图识别、流程确认、工具调用和可视化交互。

但如果这些模块只各自运行，系统仍然只是“更自动化的费控工具”。要变成自我进化系统，必须解决几个核心问题：

- 每次命中风险后，系统是否知道人工最终确认、驳回、误报还是漏报。
- 新规则、新阈值、新权重上线前，是否能用历史样本回放验证。
- 系统是否能从反复出现的人工反馈中形成候选规则或候选参数。
- 知识库制度变更后，是否能定位受影响的规则、流程和问答。
- Agent 回答错误或流程误判后，是否能沉淀为可复盘样本，而不是只改一处文案。

因此，自我进化不是让大模型直接改生产代码或发布规则，而是建立一条受控学习链路：

```text
运行数据
  -> 人工反馈 / 审批结果 / 用户纠错
  -> 标签样本与回放集
  -> 分析能力校准
  -> 候选规则 / 候选参数 / 候选知识修订
  -> 影子运行与历史回放
  -> 人审发布
  -> 上线后持续监控
```

## 核心判断

学习闭环同时让两类能力变强，但顺序不同。

第一层是分析变强。

分析变强指系统越来越知道：

- 哪些风险信号真的值得阻断。
- 哪些风险只适合提醒或补充说明。
- 哪些规则在某些部门、费用类型、职级或场景下误报率高。
- 哪些历史相似单据最终被退回、确认或通过。
- 哪些同组基线更适合当前单据，而不是简单使用全局均值。

这一层优先影响风险分、置信度、推荐动作、抽检策略、自动化模式和解释质量。

第二层是规则变强。

规则变强指当某类分析结论被足够多的反馈和回放证明稳定后，再沉淀为正式规则、规则修订、例外条件或阈值配置。规则变强必须经过测试和审核，不能由模型直接上线。

推荐顺序是：

```text
分析先学习
  -> 形成候选结论
  -> 回放证明有效
  -> 人审沉淀为规则或参数
  -> 规则上线后继续接受反馈
```

这样可以避免系统过早把偶然反馈固化为生产规则。

## 目标与非目标

### 目标

- 建立统一的学习闭环总纲，串联风险观察、规则反馈、Agent 反馈、审批结果、回放评测和规则中心。
- 明确“分析进化”和“规则进化”的边界。
- 让风险分、置信度、推荐动作、抽检策略和自动化模式具备反馈校准依据。
- 让候选规则、候选参数和候选知识修订进入待审核流程，而不是自动生效。
- 通过历史回放、影子运行和灰度发布降低自我进化风险。
- 为后续实现算法评估中心、反馈样本池和候选规则工厂提供架构依据。

### 非目标

- 不让大模型直接修改生产规则、生产数据或核心代码。
- 不让系统绕过财务、风控或管理员审核自动发布规则。
- 不把员工画像作为惩罚标签；画像只服务于风险解释、排序和复核辅助。
- 不把所有学习结果都固化为规则；低置信反馈只进入分析校准和样本池。
- 不在第一阶段引入复杂机器学习训练平台，优先把样本、标签、回放和门控做稳。

## 现有基础

### 风控图谱

`evaluate_financial_risk_graph()` 已经把单据、员工、部门、费用类型、地点、票据和本体解析合成风险图谱，并输出贡献分、证据、风险等级、置信度、采样策略和决策 trace。

当前贡献分包括：

- `S_rule`：规则信号。
- `S_anomaly`：同组金额异常。
- `S_graph`：图谱异常。
- `S_policy`：制度关联。
- `S_history`：历史反馈。

这说明系统已经具备“分析可解释”和“反馈可进入评分”的基础。

### 规则中心

风险规则已经支持自然语言生成 JSON 风险规则、DSL 校验、风险评分、样例测试、真实场景试运行、测试报告确认、审核发布、反馈记录和修订版本。

这说明系统已经具备“规则可生成、可测试、可审核、可发布”的基础。

### 风险观察反馈池

`RiskObservation` 和 `RiskObservationFeedback` 已经能记录风险观察、反馈状态、反馈历史、算法版本和证据数据。

这说明系统已经有学习闭环的核心样本载体。

### 回放评测雏形

`AlgorithmReplayCase` 和 `AlgorithmReplaySet` 已经定义了历史单据、本体版本、规则版本、算法版本和反馈标签的回放契约。

这说明系统已经具备把历史风险观察转为评测样本的基础。

### 数字员工

数字员工已有风险图谱巡检、员工画像扫描、反馈样本积累、算法回放评估等任务概念。

这说明后台定时分析能力可以成为学习闭环的执行入口。

## 学习对象分层

### L1. 交互与意图学习

学习对象：

- 用户是否选择了正确流程。
- 小财管家是否误判申请 / 报销。
- 直接提交、保存草稿、附件关联、关联申请单等动作是否被用户纠正。

可进化内容：

- 意图识别提示词。
- 澄清问题策略。
- 流程确认门控。
- 推荐动作排序。
- 前端快捷动作默认项。

禁止直接进化内容：

- 不根据单次对话自动修改规则中心。
- 不把用户一句话纠错直接变成生产规则。

### L2. 风险分析学习

学习对象：

- 风险观察是否被人工确认。
- 命中后是否被退回、补件、通过、忽略。
- 哪些风险信号误报率高。
- 哪些风险在相似场景下总是漏报。

可进化内容：

- 风险分权重。
- 置信度计算。
- 自动化模式门槛。
- 抽检和回放采样策略。
- 同组基线选择策略。
- 风险解释优先级。

禁止直接进化内容：

- 不让系统自动把高风险改成阻断。
- 不让模型直接替代人工确认违规。

### L3. 规则学习

学习对象：

- 多次确认的风险观察。
- 反复出现的漏判反馈。
- 规则测试中的真实场景命中差异。
- 制度变更引起的规则失配。

可进化内容：

- 候选规则。
- 规则修订草稿。
- 例外条件。
- 阈值建议。
- 规则适用范围。

必须经过：

- 样例测试。
- 真实场景试运行。
- 回放评测。
- 人工审核。
- 灰度或发布确认。

### L4. 知识学习

学习对象：

- 知识库问答命中错误。
- 制度引用缺口。
- 规则和制度条款不一致。
- 用户追问中反复出现的政策盲点。

可进化内容：

- 知识文档结构化摘要。
- 制度条款引用。
- 问答检索关键词。
- 规则与制度条款绑定。

禁止直接进化内容：

- 不让模型编造制度。
- 不让模型用未审核知识覆盖正式制度。

## 闭环架构

### 1. 事件采集层

统一采集以下事件：

- 风险观察生成。
- 规则命中和未命中。
- 审批通过、退回、驳回、补件。
- 风控人员反馈确认、误报、漏报、不清楚。
- 用户对 Agent 回答的低分反馈。
- 规则测试、试运行和发布结果。
- 知识库检索命中和无结果。

每个事件都应绑定：

- 业务对象：申请单、报销单、票据、员工、部门、规则。
- 版本信息：算法版本、规则版本、本体版本、知识版本。
- 执行上下文：run_id、conversation_id、task_id。
- 处理结果：人工动作、审批状态、反馈标签。

### 2. 标签与样本层

将原始事件转为标准标签：

- `confirmed`：风险被确认。
- `false_positive`：误报。
- `false_negative`：漏报。
- `unclear`：证据不足。
- `over_blocked`：阻断过度。
- `manual_override`：人工覆盖系统建议。
- `policy_changed`：制度变化导致旧判断失效。

同时形成三类样本池：

- 分析校准样本：用于调整风险分、置信度和推荐动作。
- 回放评测样本：用于新算法、新规则、新权重上线前验证。
- 规则候选样本：用于生成或修订规则草稿。

### 3. 离线评估层

定期对候选算法、候选规则、候选参数运行回放。

关键指标：

- 确认率：命中后被人工确认的比例。
- 误报率：命中后被标记误报的比例。
- 漏报率：人工发现风险但系统未命中的比例。
- 阻断准确率：阻断动作最终被确认合理的比例。
- 人工负担：进入人工复核的单据比例。
- 解释完整率：风险观察是否包含规则、证据、基线和相似案例。
- 数据质量通过率：字段完整性、票据 OCR、申请关联等基础数据质量。

### 4. 候选生成层

系统只能生成候选，不直接生效。

候选类型：

- 候选规则：来自反复确认的风险观察或漏判样本。
- 候选规则修订：来自误报较高的规则反馈。
- 候选参数：来自权重、阈值、置信度、自动化门槛的评估结果。
- 候选知识修订：来自制度引用缺口或知识问答低分反馈。

每个候选必须包含：

- 来源样本。
- 触发原因。
- 预期改善指标。
- 可能副作用。
- 回放结果。
- 推荐发布方式。

### 5. 发布门控层

发布顺序：

```text
候选
  -> 样例测试
  -> 历史回放
  -> 影子运行
  -> 人工审核
  -> 灰度启用
  -> 全量发布
  -> 上线后监控
```

影子运行期间，新规则或新参数只记录“如果启用会发生什么”，不影响真实审批。

灰度启用期间，只对指定部门、费用类型或测试公司生效。

全量发布后，必须持续监控误报、漏报、阻断和人工覆盖。

## 数据与版本要求

每条学习样本至少保留：

- `sample_id`
- `sample_type`
- `subject_type`
- `subject_id`
- `business_stage`
- `risk_signal`
- `rule_code`
- `algorithm_version`
- `rule_version`
- `ontology_version`
- `knowledge_version`
- `input_snapshot`
- `decision_trace`
- `expected_label`
- `actual_label`
- `feedback_source`
- `feedback_actor`
- `created_at`

每次算法或规则评估至少保留：

- `evaluation_id`
- `candidate_type`
- `candidate_version`
- `baseline_version`
- `replay_set_id`
- `sample_count`
- `metrics_before`
- `metrics_after`
- `regression_cases`
- `approval_status`

## 推荐实施路径

### 第一阶段：补齐评估地基

目标是让系统知道自己判断得好不好。

- 统一风险观察反馈标签。
- 把审批结果、退回原因、补件动作写入风险样本池。
- 将 Agent 低分反馈归因到意图识别、流程路由、知识问答、规则解释、附件处理等类别。
- 建立回放集生成任务，把风险观察和反馈状态转成评测样本。
- 在数字员工工作记录中展示反馈样本摘要和回放评估摘要。

### 第二阶段：分析进化

目标是先让判断更稳。

- 将风险图谱权重、置信度门槛、自动化模式门槛迁移到版本化配置。
- 基于反馈样本计算规则、风险信号、费用类型、部门维度的误报率和确认率。
- 对高误报规则降低默认动作等级，对高确认规则提高抽检优先级。
- 增强同组基线选择，优先使用部门、职级、费用类型、供应商等可解释维度。
- 引入影子参数评估，只记录差异，不直接影响生产。

### 第三阶段：规则进化

目标是把稳定结论沉淀为规则资产。

- 从 confirmed 和 false_negative 样本中生成候选规则。
- 从 false_positive 样本中生成候选例外条件或适用范围收缩建议。
- 候选规则自动进入规则中心草稿，不自动发布。
- 草稿必须完成样例测试、真实场景试运行和测试报告确认。
- 已上线规则只能通过修订版本替换。

### 第四阶段：知识进化

目标是让制度、规则和问答保持一致。

- 对知识库无结果、低分反馈和制度引用缺口做聚类。
- 自动生成知识修订建议或制度引用补充建议。
- 标记受影响规则和问答范围。
- 由制度管理员确认后再更新知识库或规则引用。

### 第五阶段：灰度自进化

目标是在受控范围内逐步提高自动化程度。

- 为低风险、高置信、高证据完整度场景开放自动提醒或自动补件建议。
- 为高风险场景继续保持人工复核或阻断确认。
- 每个自动化动作都必须可解释、可撤回、可追踪。
- 自动化范围随反馈质量逐步扩大。

## 产品边界

自我进化系统里，人和系统的职责要明确。

系统负责：

- 发现模式。
- 聚合证据。
- 生成候选。
- 运行回放。
- 计算指标。
- 提醒风险。
- 记录全链路证据。

人负责：

- 确认制度口径。
- 审核规则发布。
- 判断复杂业务例外。
- 决定阻断、退回或放行。
- 对候选改进做最终确认。

大模型负责：

- 语义理解。
- 候选规则草稿。
- 解释生成。
- 知识摘要。
- 反馈归因辅助。

大模型不负责：

- 最终违规判定。
- 自动发布规则。
- 自动修改生产代码。
- 绕过审核执行高风险动作。

## 验收指标

第一阶段验收：

- 风险观察反馈、规则反馈、Agent 反馈能统一进入样本池。
- 回放集能按算法版本、规则版本、本体版本构建。
- 风险看板能展示确认率、误报率、反馈样本数和待回放样本数。

第二阶段验收：

- 风险分、置信度和自动化动作的调整都有反馈证据。
- 新参数可以影子运行并产生差异报告。
- 高误报规则能被识别并生成修订建议。

第三阶段验收：

- 系统能从反馈样本生成候选规则或候选修订。
- 候选规则能进入规则中心草稿。
- 候选规则必须通过测试报告确认后才允许发布。

第四阶段验收：

- 知识问答低分反馈能定位到知识缺口。
- 制度变更能提示受影响规则和问答范围。
- 知识修订必须保留来源和审核记录。

## 风险与防护

- 反馈噪音：单次反馈不能直接改规则或参数，必须聚合后进入候选。
- 误报固化：规则上线前必须跑历史回放和影子运行。
- 模型幻觉：所有制度、规则和风险结论必须绑定来源证据。
- 自动化越权：阻断、退回、发布规则等高风险动作必须人工确认。
- 数据漂移：长期监控样本量、字段缺失率、费用分布和 OCR 质量。
- 版本混乱：算法、规则、本体、知识和回放集必须带版本号。

## 与现有文档关系

- `document/development/hermes-risk-graph-algorithm/CONCEPT.md`：负责风险图谱算法和风险观察模型。
- `document/development/risk-rule-explainable-flow/CONCEPT.md`：负责风险规则 DSL、解释、测试和发布流程。
- `document/development/数字员工能力库扩展/CONCEPT.md`：负责数字员工技能边界和后台分析任务。
- 本文档负责把上述能力串成“自我进化学习闭环”的总体路线。

## 结论

X-Financial 的自我进化应先让分析变强，再让规则变强。

分析变强是低风险、高收益的第一步：它通过反馈、回放和影子运行持续校准风险分、置信度、动作建议和解释质量。

规则变强是第二步：只有当分析结论经过足够样本验证后，才沉淀为正式规则、规则修订或参数版本，并通过测试、人审和灰度发布进入生产。

最终目标不是“系统自己随便改规则”，而是形成一条可审计、可回放、可控发布的学习链路，让系统越用越懂企业自己的财务控制口径。