f9553a6a1a
- 删除已落地的 improvement-roadmap、superpowers 计划与 ui-mockups 参考稿，删除早期 work-log（2026-05-06~08） - 新增 2026-05-23 起的 work-log 与 attachment-association-background-job、reimbursement-draft-action-branching 等开发文档及用户文档 - docker-compose(.full).yml 微调服务配置
491 lines
16 KiB
Markdown
491 lines
16 KiB
Markdown
# 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 的自我进化应先让分析变强，再让规则变强。
|
||
|
||
分析变强是低风险、高收益的第一步：它通过反馈、回放和影子运行持续校准风险分、置信度、动作建议和解释质量。
|
||
|
||
规则变强是第二步：只有当分析结论经过足够样本验证后，才沉淀为正式规则、规则修订或参数版本，并通过测试、人审和灰度发布进入生产。
|
||
|
||
最终目标不是“系统自己随便改规则”，而是形成一条可审计、可回放、可控发布的学习链路，让系统越用越懂企业自己的财务控制口径。
|