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

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

更新日期：2026-06-23

功能一句话

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

背景与问题

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

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

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

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

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

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

核心判断

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

第一层是分析变强。

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

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

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

第二层是规则变强。

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

推荐顺序是：

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

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

目标与非目标

目标

• 建立统一的学习闭环总纲，串联风险观察、规则反馈、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. 发布门控层

发布顺序：

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

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

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

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

数据与版本要求

每条学习样本至少保留：

• 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 的自我进化应先让分析变强，再让规则变强。

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

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

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