# 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 的自我进化应先让分析变强，再让规则变强。 分析变强是低风险、高收益的第一步：它通过反馈、回放和影子运行持续校准风险分、置信度、动作建议和解释质量。 规则变强是第二步：只有当分析结论经过足够样本验证后，才沉淀为正式规则、规则修订或参数版本，并通过测试、人审和灰度发布进入生产。 最终目标不是“系统自己随便改规则”，而是形成一条可审计、可回放、可控发布的学习链路，让系统越用越懂企业自己的财务控制口径。