Files

caoxiaozhu 92444e7eae feat: 扩展风险规则体系、审批动态路由与预算中心列表化改造

- 新增 25+ 条风险规则（预算/报销/申请/通用类），完善风险规则模拟与反馈发布机制
- 引入费用审批动态路由、平台风险分级、预审与风险阶段管理
- 预算中心列表化改造，优化票据夹仪表盘与数字员工工作看板
- 新增 Hermes 风险线索收集器、Agent 链路追踪中心
- 扩展数字员工能力库（18 个领域 Skill）与交通费用自动预估
- 完善报销申请快速预览、权限控制与前端测试覆盖

2026-06-01 17:07:14 +08:00

37 KiB

Raw Blame History

数字员工财务行为图谱风险算法方案

更新日期：2026-05-29

1. 功能一句话

以数字员工为后台分析入口，持续把财务业务数据转成行为画像、制度语义和风险观察，再通过图谱证据链、单据详情和风险看板提供可解释的风险判断。

规则中心、审批和报销主流程仍由外层智能体流程负责调度；数字员工只消费事实、规则命中和反馈结果，生成后台分析、报告、知识库材料和待复核线索。

2. 背景与问题

X-Financial 已经具备费用申请、报销、审批、规则中心、知识制度归集、Agent 运行记录和数字员工任务入口。当前系统的风险能力主要来自规则命中、人工审核和局部页面展示，后续如果只继续增加单点技能，会出现几个问题：

风险判断缺少统一载体，不同页面、规则和数字员工各自输出，难以汇总为算法资产。
知识制度、员工画像、票据、审批链和历史反馈之间没有形成稳定关联。
单据详情能看到风险描述，但很难直观看到“为什么异常”和“和谁相比异常”。
分析看板如果只从散表拼统计图，会成为展示型页面，不能反映算法效果。
数字员工如果只做定时任务，会变成调度工具，不能形成核心壁垒。

本方案把核心能力定义为“财务行为图谱风险引擎”。它不是单一模型，而是一套闭环：事件沉淀、实体建图、画像基线、风险推理、人工反馈、待复核线索归集。

3. 核心判断

数字员工可以做后台数据分析、画像分析和风险分析，但壁垒不在“多几个技能”，而在：

公司制度的结构化能力。
报销、预算、票据、审批、供应商、员工和部门之间的业务图谱。
员工、部门、供应商和费用类型的长期行为基线。
审批结果、退回原因、人工复核结论和误报反馈。
可解释的风险观察模型和持续反馈闭环。

最终目标是让系统回答六个问题：

谁异常。
哪个业务环节异常。
和什么基线相比异常。
关联哪条制度或规则。
历史相似情况怎么处理。
当前应该怎么处置。

3.1 不可复制壁垒设计

别人可以复制页面、规则名称、图谱展示甚至部分算法论文，但很难复制 X-Financial 长期沉淀的业务语义、过程数据、人工反馈和证据闭环。系统壁垒必须设计在这些不可外购、不可快速补齐的资产上。

第一层壁垒：专有财务语义本体。

公司制度条款
  -> 费用类型本体
  -> 风险信号本体
  -> 审批场景本体
  -> 预算科目本体
  -> 票据与附件要求本体

该本体不是通用词典，而是由公司制度、历史审批、费用类型、预算口径、组织结构和管理员修订持续训练出来。外部系统即使知道字段名，也缺少本体版本、别名映射、风险信号口径和制度条款绑定关系。

第二层壁垒：对象中心财务事件日志。

申请 -> 预算占用 -> 票据上传 -> 审批 -> 退回 -> 修改 -> 付款 -> 归档 -> 复盘

每个事件同时绑定员工、部门、费用类型、供应商、审批人、票据、制度条款和 AgentRun。长期积累后，系统知道“正常流程是什么”“异常流程如何出现”“哪些异常最终被确认”，这是单纯规则库无法复制的。

第三层壁垒：风险观察反馈池。

每条 RiskObservation 都沉淀：

风险信号
证据路径
本体解析
规则命中
画像偏离
图谱异常
人工处理结果
误报/确认反馈
算法版本

这会形成自有训练集、评测集和规则执行校准样本。竞品能复制算法框架，但复制不了这些被真实审批和财务人员校准过的样本。

第四层壁垒：人机共审行为数据。

系统不仅记录“AI 判断什么”，还记录“人如何处理 AI 的判断”：

采纳
驳回
改写
退回
补件
升级审批
标记误报
归集待复核线索

这些反馈会反向影响规则质量、抽审比例、自动化门控和数字员工能力考核。越使用越贴近企业自己的财务控制风格。

第五层壁垒：可回放评测资产。

每个风险版本都必须能离线回放：

同一批历史单据
同一本体版本
同一规则版本
同一算法版本
同一反馈标签

这样系统不是“调参数看感觉”，而是可以证明新算法是否降低误报、提高确认率、减少人工审核量。长期回放集会成为核心资产。

因此，本项目的算法壁垒不是某一个模型，而是：

专有本体
+ 对象中心事件日志
+ 风险观察反馈池
+ 人机共审行为数据
+ 可回放评测资产
+ 规则/图谱/画像/制度的版本化证据链

这些资产必须在产品和数据库设计阶段就开始沉淀，否则后续即使接入复杂模型，也只会是可复制的通用能力。

4. 目标与非目标

4.1 目标

建立统一的 RiskObservation 风险观察模型，承接规则中心、数字员工、单据审核和图谱分析结果。
建立财务行为图谱，关联员工、部门、供应商、票据、费用类型、单据、审批人、制度条款和风险规则。
建立员工、部门、供应商、费用类型画像，提供同类基线和异常偏离度。
在单据详情中展示风险证据链，解决单个风险解释问题。
在数字员工工作记录详情中展示本次分析结果和图谱构建结果，解决数字员工“做了什么”的解释问题。
在分析看板中增加风险看板，解决整体风险态势、算法效果和待处理风险管理问题。
把人工反馈、审批处理结果和误报标记写回风险闭环。

4.2 非目标

第一版不做独立“大图谱中心”，避免做成展示型页面。
不让大模型直接决定风险等级，大模型只参与语义抽取、解释生成和事实线索整理；不参与规则生成、改写或发布。
不用画像自动惩罚员工，不给员工永久贴标签。
不在员工技能详情中展示知识归集图谱；图谱结果只进入工作记录详情、单据风险详情或画像详情。
不让数字员工生成、改写或自动上线规则；规则变更只能由管理员在规则中心维护。

5. 用户与场景

5.1 审批人

入口：单据详情。

关注点：

当前单据为什么被标为风险。
和本人历史、同部门同级别、同费用类型相比是否异常。
命中了哪条制度或规则。
历史相似单据是通过、退回还是调整金额。
当前建议动作是什么。

5.2 财务与审计人员

入口：风险看板、风险详情、数字员工工作记录。

关注点：

哪些部门、费用类型、供应商、员工风险集中。
哪些风险重复出现。
哪些规则误报率高。
图谱发现了哪些异常关系。
哪些风险需要优先复核。

5.3 管理员

入口：数字员工、规则中心、系统设置。

关注点：

数字员工运行是否成功。
本次分析处理了多少数据、产出多少风险观察。
待复核风险线索是否有足够事实和证据。
是否需要调整技能、规则、制度知识或调度配置。

5.4 管理层

入口：分析看板中的风险看板。

关注点：

整体风险态势是否恶化。
涉及金额和高风险待处理量。
部门、费用类型和供应商风险分布。
风险处理效率和算法确认率。

6. 功能能力

6.1 数字员工能力分层

第一版建议保留四类核心数字员工：

制度整理员工：把公司财务制度整理成条款、适用范围、费用类型、触发条件和引用关系。
风险扫描员工：定期扫描新增单据、票据、供应商、审批链和画像偏离，生成风险观察。
画像更新员工：定期更新员工、部门、供应商、费用类型画像和同类基线。
风险线索归集员工：从申请、报销、规则命中和人工反馈中归集待复核线索，不生成规则。

6.2 图谱体现方式

图谱不应该默认展示成全量关系网。第一版按业务场景拆成四种可读形态：

单据详情：风险证据链。
风险详情：小范围关系穿透图。
工作记录详情：本次分析图谱和产出摘要。
风险看板：风险地图、分布、趋势和算法效果。

6.3 单据详情风险证据链

建议在现有风险说明或审核建议附近增加“风险证据链”区块：

员工张三
  -> 提交差旅报销 4,860 元
  -> 命中住宿费用异常
  -> 同部门同级别平均 680 元/晚，本单 1,260 元/晚
  -> 关联制度：差旅住宿标准第 3 条
  -> 历史相似单据 12 笔，其中 8 笔被退回
  -> 建议：补充说明或人工复核

显示内容：

风险结论。
证据链节点。
同类基线对比。
命中制度条款。
历史相似案例。
建议动作。

6.4 数字员工工作记录详情

工作记录详情展示数字员工本次任务结果，不展示员工技能定义。

建议展示：

本次扫描范围。
处理实体数量。
生成风险观察数量。
关键异常关系。
失败原因和跳过数据。
可点击的风险观察列表。
对知识制度整理类任务，展示知识制度记录图谱。

6.5 分析看板风险看板

风险看板放在分析看板中作为独立页签，定位是风险算法驾驶舱。

第一版模块：

风险总览：今日新增风险数、高风险待处理数、涉及金额、已确认风险数、误报数量。
风险分布：按部门、费用类型、风险类型、供应商、员工职级分布。
风险趋势：7 天 / 30 天风险走势、高风险占比、重复触发趋势、处理完成率。
异常排行：风险最多部门、偏离基线最大员工、高频异常供应商、高频触发规则。
算法效果：规则命中数、图谱异常命中数、人工确认率、误报率、待复核线索数。

风险看板必须从 RiskObservation 聚合，不直接从散表临时拼图表。

6.6 画像详情

画像详情作为第二阶段，不抢第一版主线。

可支持：

员工画像：费用结构、历史风险、同级对比、供应商关联、退回率。
部门画像：预算压力、费用结构、风险热力、审批效率。
供应商画像：关联员工、关联部门、重复票据、金额集中度。
费用类型画像：周期性、异常波动、制度命中频率。

7. 方案设计

7.1 总体架构

业务数据
  -> 财务事件层
  -> 实体图谱层
  -> 画像基线层
  -> 风险推理层
  -> RiskObservation 风险观察池
  -> 单据详情 / 工作记录详情 / 风险看板 / 规则候选
  -> 人工反馈
  -> 画像、规则、制度知识持续优化

7.2 事件层

统一沉淀业务事件，避免不同模块重复解释业务动作。

候选事件：

claim_created
claim_submitted
invoice_uploaded
approval_passed
approval_returned
amount_adjusted
budget_reserved
payment_completed
policy_document_ingested
risk_rule_triggered
digital_employee_run_completed
manual_feedback_submitted

7.3 实体图谱层

节点类型：

employee
department
position
vendor
invoice
expense_claim
expense_item
expense_type
approval_user
policy_clause
risk_rule
risk_observation
digital_employee_run

边类型：

belongs_to
submitted
contains_item
uses_invoice
paid_to_vendor
approved_by
matches_policy_clause
triggered_rule
similar_to
generated_by_run
confirmed_by_feedback

第一版不要求必须引入图数据库。可以先在关系型数据库中存储节点、边和 path_json，等查询复杂度上升后再接入专用图数据库。

7.4 本体与风险图谱桥接

本体层是风险图谱的语义骨架，不是图谱的替代品。图谱负责记录“谁和谁有关”，本体负责定义“这个关系在财务语义上是什么”。风险图谱中的节点、边、风险信号、规则匹配和看板聚合都必须引用本体标准化结果。

现有系统已有 /api/v1/ontology/parse、SemanticParseLog、scenario、intent、entities、risk_flags、missing_slots 等基础能力。风险图谱不应另建解析器，而应复用本体解析结果，并在必要时扩展本体词典和风险信号。

本体输出进入风险图谱的最小协议：

ontology_parse_id
ontology_version
domain
scenario
intent
entities
constraints
risk_signals
missing_slots
confidence

本体实体映射到图谱节点：

ontology entity            graph node
employee                   employee
department                 department
expense_type               expense_type
document_type              invoice / expense_claim / contract / payment_record
vendor                     vendor
policy_clause              policy_clause
risk_signal                risk_observation / risk_signal
budget_subject             budget_subject
project                    project
location                   location

图谱节点必须保留本体标准键：

node_type                  employee / claim / invoice / vendor / policy_clause / ...
ontology_type              expense_type / document_type / risk_signal / organization / ...
canonical_key              hotel / travel / duplicate_invoice / over_standard / ...
canonical_id               标准实体 ID，可为空但必须记录 canonical_key
source_object_type         expense_claim / invoice / policy_document / agent_run / ...
source_object_id
ontology_parse_id
ontology_version

图谱边必须来自白名单，不能让数字员工自由创造运行时边类型：

submitted                  员工提交单据
belongs_to                 员工归属部门
contains_item              单据包含费用明细
uses_invoice               费用明细使用票据
paid_to_vendor             付款或票据关联供应商
approved_by                单据由某审批人审批
matches_policy_clause      单据或风险观察关联制度条款
triggered_risk_signal      单据触发本体风险信号
triggered_rule             单据命中规则
similar_to                 与历史对象相似
generated_by_run           由数字员工运行生成
confirmed_by_feedback      由人工反馈确认

风险信号必须本体化。不同文本说法要映射到同一标准风险信号，例如：

住宿超标 / 酒店超标 / 差旅住宿异常
  -> risk_signal = accommodation_standard_deviation
  -> scenario = travel_reimbursement
  -> expense_type = hotel

重复发票 / 发票重复 / 票据重复报销
  -> risk_signal = duplicate_invoice
  -> scenario = invoice_validation
  -> document_type = invoice

规则中心、图谱引擎和风险看板必须按同一套本体口径聚合：

规则中心：scenario + expense_type + risk_signal 决定规则适用范围
图谱引擎：canonical node + whitelisted edge 构造证据路径
风险观察：ontology fields + evidence path 输出可解释结论
风险看板：按 ontology scenario / expense_type / risk_signal 聚合
数字员工：只能产出本体可识别的事实、规则命中、待复核风险线索和证据引用

当本体置信度不足时，风险图谱必须降级：

confidence >= 0.85       可进入自动规则匹配和图谱证据构建
0.60 <= confidence < 0.85 进入人工复核或半自动模式
confidence < 0.60        只记录候选观察，不触发强拦截

7.5 统一风险观察模型

核心结构：

RiskObservation
- id
- subject_type              employee / department / vendor / claim / invoice / expense_type
- subject_id
- risk_type
- severity                  low / medium / high / critical
- score                     0-100
- status                    open / confirmed / false_positive / resolved / ignored
- evidence_items_json
- evidence_path_json
- related_policy_clauses_json
- related_entities_json
- comparable_baseline_json
- suggested_actions_json
- source_type               rule / graph / profile / policy / digital_employee
- source_id
- ontology_parse_id
- ontology_version
- domain
- scenario
- intent
- ontology_entities_json
- ontology_constraints_json
- risk_signals_json
- canonical_subject_key
- algorithm_version
- feedback_status
- created_at
- updated_at

7.6 API 契约建议

单据详情读取风险证据链：

GET /api/v1/risk-observations/by-claim/{claim_id}

风险观察详情：

GET /api/v1/risk-observations/{observation_id}

风险看板聚合：

GET /api/v1/risk-observations/analytics/summary

数字员工工作记录关联风险观察：

GET /api/v1/agent-runs/{run_id}/risk-observations

人工反馈：

POST /api/v1/risk-observations/{observation_id}/feedback

本体图谱映射调试接口建议只面向管理员：

GET /api/v1/risk-graph/ontology-mapping/{object_type}/{object_id}

返回当前对象关联的本体解析、标准实体、图谱节点、图谱边和降级原因，用于排查风险解释是否来自正确语义。

7.7 前端入口关系

分析看板
  -> 风险看板：整体态势和算法效果

单据详情
  -> 风险证据链：解释单个单据风险

数字员工
  -> 员工技能：配置技能和 Markdown 源文件
  -> 工作记录详情：展示本次任务结果和图谱结果

规则中心
  -> 风险规则详情：展示规则定义、条件、执行逻辑

画像详情
  -> 员工 / 部门 / 供应商长期画像

8. 算法与公式

8.1 风险总分

第一版使用可解释加权模型，不直接使用黑盒模型给最终分。


risk\_score =
clip(0.35S_{rule} + 0.25S_{anomaly} + 0.20S_{graph} + 0.15S_{policy} + 0.05S_{history}, 0, 100)

变量定义：

(S_{rule})：确定性规则命中分，来自规则中心或制度规则。
(S_{anomaly})：画像和同类基线偏离分。
(S_{graph})：图谱关系异常分，例如重复票据、供应商集中、审批链异常。
(S_{policy})：制度语义相关分，例如说明、票据和制度条款不一致。
(S_{history})：历史反馈分，例如相似案例退回率、确认风险率。

8.2 同类基线偏离

对金额、频次、天数、退回率等数值型指标，优先使用稳健统计：


deviation = \frac{x - median(peer)}{max(IQR(peer), \epsilon)}


S_{anomaly} = 100 \times sigmoid(k(deviation - \tau))

变量定义：

(x)：当前员工、部门、供应商或单据指标。
(peer)：同部门、同职级、同费用类型、同城市级别等同类样本。
(IQR)：四分位距。
(\epsilon)：防止分母为零的最小值。
(\tau)：异常阈值。
(k)：放大系数。

8.3 图谱异常分

第一版图谱异常分可以采用可解释信号累加：


S_{graph} = min(100, \sum_{i=1}^{n} w_i g_i)

候选信号：

重复票据：同一票据号、金额、供应商或影像指纹重复。
供应商集中：某员工或部门在窗口期内高度集中到少数供应商。
审批链异常：审批人和申请人关系异常、审批路径绕行或过短。
时间地点异常：业务地点、票据地点、行程地点不一致。
相似单据异常：与历史退回或调整金额单据高度相似。

8.4 人工反馈校准

人工反馈不直接覆盖算法，但会影响后续权重和待复核线索优先级：


confirmed\_rate = \frac{confirmed}{confirmed + false\_positive + ignored}


rule\_quality = 0.6 \times confirmed\_rate + 0.4 \times coverage

其中 coverage 表示该规则或风险类型在目标场景中的有效覆盖率。

9. 公开竞品资料借鉴

9.1 资料边界

本节只基于公开资料提炼可借鉴的算法模式，不假设能够获得用友费用或合思费控的内部算法实现。公开资料能证明的是产品能力、架构方向、典型场景和治理方法；工程实现仍需要结合 X-Financial 的本体、规则中心、数字员工、AgentRun 和业务数据重新设计。

参考资料：

9.2 用友费用可借鉴模式

公开资料中，用友费控的重点不是单点审核，而是“事前规划、事中控制、事后分析”的端到端费控链路。可借鉴点如下：

流程前置：在出差申请、商旅预订、报销、稽核、核算、结算、归档全流程内嵌管控，而不是只在报销提交后审核。
规则模板库：公开资料提到“超级差规”基于规则引擎，并预置大量差旅规则模板。X-Financial 应建设按本体场景绑定的规则模板族，而不是只存自由文本规则。
商旅比价与推荐：根据出行时间、目的地、企业标准和供应商价格推荐合规方案。X-Financial 可将其抽象为“候选行为合规推荐”，服务事前控制。
多服务连接：连接商旅、用车、餐饮、采购、电子发票等外部服务，交易数据自动同步。X-Financial 可把这些数据统一成图谱事件，而不是只做附件。
预算刚柔控制：预算规则支持事前、事中、刚性、柔性控制。X-Financial 的风险观察应记录 control_stage 和 control_mode，区分禁止、预警、复核、提示。
信用与抽审：公开架构中出现信用管理、指标管理、评价管理、抽审规则和抽审单据。X-Financial 可借鉴为“风险分层抽审”，不是所有单据都同等审核。

落地到 X-Financial，建议新增三个算法组件：

PolicyTemplateLibrary
  -> 按 ontology scenario / expense_type / risk_signal 绑定规则模板

PreControlRecommender
  -> 在申请和预订阶段给出合规选项、预算影响和风险提示

RiskSamplingPlanner
  -> 根据风险分、历史误报率、员工画像和规则质量决定抽审比例

9.3 合思费控可借鉴模式

公开资料中，合思更强调 AI 审核、人机共审、专属规则、跨材料校验和持续反馈。可借鉴点如下：

AI 数字员工治理：官网强调类似新员工管理的“培训、授权、监督、考核”。X-Financial 的数字员工也应该有能力边界、授权范围、低置信度转人工和运行质量考核。
结构化信息提取：公开资料强调从单据、发票、流水、合同、票据等材料提取结构化信息。X-Financial 应把 OCR、附件解析和本体实体统一进证据模型。
跨材料交叉验证：公开资料提到单据、发票、支付水单、事前申请事项的比对，以及单据、发票、流水一致性校验。X-Financial 应把它抽象为“多凭证一致性图谱”。
时空推理：公开资料提到结合时空推理还原真实轨迹。X-Financial 可在差旅、用车、住宿、餐饮场景中引入时间、地点、行程、票据地点一致性信号。
自然语言规则配置：公开资料提到财务可用日常语言编辑规则、制度导入导出、离线测试调优。X-Financial 应让制度整理员工产出规则候选，但上线必须走模板、测试和审核。
三种自动化模式：辅助审批、半自动、全自动。X-Financial 应将其产品化为风险自动化等级，而不是一开始追求全自动。
正负样本与对抗样本：公开资料提到正负向样本、反事实、噪声干扰、低置信度转人工。X-Financial 的反馈闭环应明确样本池和模型评测集。
结果可追溯：合思公开页面强调风险点、依据、建议、分级可溯和看板下钻。X-Financial 的 RiskObservation 必须保留证据、来源、算法版本和反馈状态。

落地到 X-Financial，建议新增四个算法组件：

MultiEvidenceReconciler
  -> 单据、发票、流水、合同、行程、申请之间的一致性校验

SpatioTemporalRiskEngine
  -> 时间、地点、行程、消费、开票之间的时空一致性检查

HumanInLoopAutomationGate
  -> 按置信度、风险等级、证据覆盖、历史误报率决定辅助/半自动/自动

RiskEvaluationDataset
  -> 正样本、负样本、反事实样本、噪声样本和历史误报样本

9.4 对当前方案的补强

结合公开资料，本方案需要补强五点：

从“事后风险识别”扩展为“事前申请、事中消费、事后审核”的分阶段风险控制。
从“规则命中”扩展为“本体模板 + 多凭证一致性 + 时空推理 + 行为画像”的组合判断。
从“统一风险分”扩展为“风险分 + 自动化等级 + 抽审策略”。
从“单次数字员工任务”扩展为“训练、授权、监督、考核”的数字员工治理。
从“人工反馈记录”扩展为“样本池、离线回放、规则质量、模型质量”的持续评测体系。

建议在 RiskObservation 增加字段：

control_stage              pre_application / booking / submission / approval / payment / archive
control_mode               block / warn / require_review / suggest / observe
automation_mode            assist / semi_auto / auto
confidence_score           0-1
evidence_coverage_count
sampling_strategy          full_review / risk_sampling / random_sampling / exempt
evaluation_case_id

自动化等级建议使用可审计门控：


automation =
\begin{cases}
auto, & confidence \ge \theta_{auto} \land severity \le medium \land evidence\_coverage \ge 2 \land false\_positive\_rate \le \alpha \\
semi\_auto, & confidence \ge \theta_{semi} \land evidence\_coverage \ge 1 \\
assist, & otherwise
\end{cases}

这个门控比“AI 直接通过/驳回”更适合企业费控，因为它把自动化建立在置信度、风险等级、证据覆盖和历史误报率之上。

9.5 可集成的外部算法技术栈

除友商公开能力外，还可以引入一组成熟的公开技术，形成更深的算法壁垒。核心原则是：先把技术映射到 X-Financial 的本体、图谱、风险观察和反馈闭环，不为了复杂而复杂。

参考资料：

9.5.1 对象中心过程挖掘

传统流程分析通常按单一 case 展开，例如一张报销单。但财务真实流程是多对象交织：申请、报销、票据、合同、付款、供应商、预算、审批人同时参与。OCEL 2.0 的对象中心事件日志适合承载这种复杂关系。

建议新增 FinancialObjectEventLog：

event_id
activity                 claim_submitted / invoice_uploaded / approval_returned / payment_completed
timestamp
actor_id
object_refs_json          claim / invoice / vendor / budget / payment / policy_clause
attributes_json
ontology_parse_id
source_run_id

可形成的风险能力：

流程偏离：实际审批路径和标准流程不一致。
返工循环：反复退回、补件、重提。
跳步审批：缺少关键节点或审批路径过短。
付款前异常：付款早于必要审批或票据校验。
供应商集中流程：同一供应商相关单据绕过常规节点。

对应算法组件：

ObjectCentricProcessMiner
  -> 从业务表和 AgentRun 构造对象中心事件日志

ConformanceRiskDetector
  -> 对比标准流程模型和实际事件路径，输出流程偏离风险

9.5.2 实体解析与主数据归一

风险图谱的质量取决于实体是否归一。供应商、商户、酒店、员工姓名、发票销售方、银行户名经常存在别名、错别字、简称和大小写差异。Fellegi-Sunter 记录链接、主动学习实体去重和人工确认机制都可以借鉴。

建议新增 EntityResolutionService：

entity_type              vendor / merchant / hotel / employee / bank_account
raw_name
canonical_key
canonical_id
match_score
match_method             exact / rule / probabilistic / embedding / human
evidence_json
review_status

可形成的风险能力：

同一供应商多名称拆分识别。
发票销售方和付款户名疑似同一主体识别。
酒店、商户、供应商别名归一。
员工、审批人、外部联系人身份消歧。

对应算法组件：

FinancialEntityResolver
  -> 字符串相似度 + 频率权重 + 业务字段校验 + 人工确认

CanonicalEntityRegistry
  -> 维护财务图谱中的标准主体 ID

9.5.3 异构图与时序图学习

X-Financial 的图谱天然是异构图：员工、部门、供应商、票据、单据、制度条款和规则都不是同一种节点。metapath2vec、HAN、GraphSAGE、Temporal Graph Networks 等技术可以用于发现人工规则难以覆盖的结构风险。

第一版不建议直接上深度 GNN 作为主判定。建议先用可解释图特征，再把图嵌入作为候选信号：

metapath features:
employee -> claim -> vendor
employee -> claim -> invoice -> vendor
department -> employee -> claim -> vendor
claim -> expense_type -> policy_clause
approver -> claim -> employee -> department

temporal features:
最近 7 / 30 / 90 天边新增速度
供应商集中度变化
审批链长度变化
同类风险信号传播路径

对应算法组件：

HeterogeneousRiskGraphFeatureBuilder
  -> 构造元路径、中心性、团簇、邻域风险密度等可解释图特征

TemporalRiskGraphMonitor
  -> 监控关系在时间上的突增、消失、迁移和异常传播

9.5.4 多模型异常检测组合

单一异常检测模型不适合作为最终风控结论，但可以作为风险观察的候选信号。建议组合稳健统计、Isolation Forest、局部离群、时间序列突变和规则命中。

候选信号：

robust_z_score             同类分位偏离
isolation_score            多维行为孤立度
local_outlier_score        邻域异常
change_point_score         时间序列突变
seasonality_score          周期偏离

组合方式：


S_{anomaly\_ensemble} =
0.35S_{robust} + 0.20S_{isolation} + 0.15S_{local} + 0.20S_{change} + 0.10S_{seasonality}

该分数只作为 RiskObservation 的一类证据，不能单独触发强拦截。

9.5.5 决策建模与策略即代码

规则中心适合承载确定性规则，但复杂审批策略需要拆成“业务决策表 + 策略执行 + 审计日志”。DMN 和 Open Policy Agent 的思路可以借鉴。

建议拆分：

DecisionTable
  -> 业务可读决策表，例如不同职级、城市、费用类型的标准

PolicyRuntime
  -> 执行策略、权限、自动化门控、抽审策略

DecisionTrace
  -> 记录输入、命中行、输出、版本、解释

这样规则中心负责版本和发布，风险图谱引擎消费 DecisionTrace 作为证据。

9.5.6 可解释与不确定性控制

企业费控不能只输出分数，需要输出证据贡献、置信度、低置信度原因和人工复核建议。SHAP 类解释方法、置信区间、保守门控和人工反馈可以组合使用。

建议每条风险观察保存：

feature_contributions_json
confidence_score
uncertainty_reasons_json
required_human_review
explanation_template_key

门控原则：

强制度规则命中：优先使用规则解释。
多证据一致：允许进入半自动。
只有模型异常：只进入候选观察或抽审池。
低置信度本体解析：不触发强拦截。

9.5.7 因果分析与反事实建议

风险看板不应只回答“哪里风险多”，还要回答“哪些控制动作真的降低风险”。DoWhy 类因果推断框架可以用于后续分析，但第一版先做可回放的反事实建议。

示例：

如果补充酒店水单，当前风险分从 76 降到 48
如果选择协议酒店，住宿标准异常消失
如果审批链增加预算负责人复核，付款前风险等级降为中

对应组件：

CounterfactualRiskAdvisor
  -> 给出降低风险分的可执行补救动作

ControlEffectAnalyzer
  -> 评估某条规则、抽审策略或数字员工上线前后的风险变化

9.5.8 数据血缘与质量门禁

复杂风险算法的前提是数据可信。OpenLineage 和 Great Expectations 的思路可以用于记录数据来源、校验质量和阻止低质量数据进入强风控。

建议新增：

RiskDataLineage
  -> 记录风险观察使用了哪些表、文档、OCR、AgentRun、规则版本和本体版本

RiskDataQualityGate
  -> 校验金额、日期、供应商、费用类型、票据号、审批状态等字段完整性

质量门禁策略：

缺少关键金额或票据号：不生成强结论。
本体费用类型低置信度：只生成候选观察。
OCR 关键字段冲突：进入多凭证一致性复核。
来源数据过旧：风险观察标记为 stale。

10. 测试方案

10.1 后端测试

风险观察模型序列化测试。
单据风险观察查询接口测试。
风险看板聚合接口测试。
画像基线计算单元测试。
图谱路径构建单元测试。
人工反馈状态流转测试。
自动化门控模式测试。
多凭证一致性校验测试。
风险抽审策略测试。

后端验证优先在 Docker 容器中执行：

docker exec x-financial-main sh -lc "cd /app && pytest <target> -q"

单元测试超时建议设置 60s，避免任务卡死。

10.2 前端测试

单据详情存在风险观察时展示证据链。
单据详情无风险观察时不占用主流程。
工作记录详情只展示本次任务相关图谱，不污染员工技能详情。
风险看板筛选、趋势、排行和卡片数据一致。
风险观察点击后能回到单据、规则或工作记录。

10.3 回归测试

规则中心风险规则详情不被图谱展示污染。
数字员工员工技能详情不显示知识归集图谱。
系统日志和数字员工工作记录边界保持清晰。
分析看板原有指标不受风险看板影响。

11. 指标与验收

11.1 业务验收

审批人能在单据详情看到风险结论、证据链、基线对比、制度条款和建议动作。
财务人员能在风险看板看到整体风险态势、分布、趋势、排行和算法效果。
管理员能在数字员工工作记录详情看到本次任务产出的风险观察和异常关系。
规则候选必须带证据、来源、置信度和人工审核状态。

11.2 技术验收

所有风险输出统一落到 RiskObservation 或兼容结构。
风险看板只读取风险观察聚合接口，不直接拼接业务散表。
风险观察详情接口返回结构化证据链。
每条风险观察保留算法版本、来源、时间和反馈状态。
关键接口有单元测试或接口测试覆盖。
自动化模式必须有门控原因，不允许只记录 AI 判断结果。
风险抽审策略必须可回放，保留当时的分数、阈值和样本策略。

11.3 算法验收

风险观察证据覆盖率不低于 95%。
高风险观察必须至少包含 2 类证据：规则、画像、图谱、制度、历史中的任意两类。
人工确认率、误报率、忽略率可统计。
同类基线样本不足时必须记录降级口径。
自动化放行单据的抽检误报/漏报结果可统计。
评测集必须包含正样本、负样本、反事实样本、噪声样本和历史误报样本。

12. 风险与开放问题

是否需要引入图数据库：第一版建议先用关系表和 JSON 路径，后续根据查询复杂度评估。
历史数据质量不足会影响画像基线，需要记录样本量和降级口径。
制度条款结构化质量会直接影响语义风险，需要把制度整理员工作为基础能力持续完善。
风险看板如果没有 RiskObservation 统一模型，会退化为普通统计页面。
图谱展示必须小范围、场景化，避免全量关系图降低可读性。
公开竞品资料只能提供产品能力和方法论参考，不能直接证明其内部算法实现；X-Financial 必须以自有数据和可审计实现为准。

37 KiB Raw Blame History Unescape Escape

数字员工财务行为图谱风险算法方案

1. 功能一句话

2. 背景与问题

3. 核心判断

3.1 不可复制壁垒设计

4. 目标与非目标

4.1 目标

4.2 非目标

5. 用户与场景

5.1 审批人

5.2 财务与审计人员

5.3 管理员

5.4 管理层

6. 功能能力

6.1 数字员工能力分层

6.2 图谱体现方式

6.3 单据详情风险证据链

6.4 数字员工工作记录详情

6.5 分析看板风险看板

6.6 画像详情

7. 方案设计

7.1 总体架构

7.2 事件层

7.3 实体图谱层

7.4 本体与风险图谱桥接

7.5 统一风险观察模型

7.6 API 契约建议

7.7 前端入口关系

8. 算法与公式

8.1 风险总分

8.2 同类基线偏离

8.3 图谱异常分

8.4 人工反馈校准

9. 公开竞品资料借鉴

9.1 资料边界

9.2 用友费用可借鉴模式

9.3 合思费控可借鉴模式

9.4 对当前方案的补强

9.5 可集成的外部算法技术栈

9.5.1 对象中心过程挖掘

9.5.2 实体解析与主数据归一

9.5.3 异构图与时序图学习

9.5.4 多模型异常检测组合

9.5.5 决策建模与策略即代码

9.5.6 可解释与不确定性控制

9.5.7 因果分析与反事实建议

9.5.8 数据血缘与质量门禁

10. 测试方案

10.1 后端测试

10.2 前端测试

10.3 回归测试

11. 指标与验收

11.1 业务验收

11.2 技术验收

11.3 算法验收

12. 风险与开放问题

37 KiB

Raw Blame History