8a4a777be7
后端新增员工行为画像算法模块，支持标签规则引擎和评分计算， 完善员工模型、银行信息、序列化和导入逻辑，优化报销审批流 和工作流常量，增强 Hermes 同步和知识同步能力，前端新增费 用画像详情弹窗、雷达图和风险卡片组件，完善登录页和工作台 样式，优化文档中心和归档中心交互，补充单元测试。
674 lines
31 KiB
Markdown
674 lines
31 KiB
Markdown
# 员工业务行为画像功能概念文档
|
||
|
||
## 1. 功能一句话
|
||
|
||
员工业务行为画像通过确定性算法把费用申请、流程质量、AI 协作和审批行为沉淀为可追溯的画像快照，并在审批详情、Hermes 数字员工巡检和运营看板中提供可解释的审核依据。
|
||
|
||
## 2. 背景与问题
|
||
|
||
预算费用规划推荐模型需要解释“为什么某个申请应该被重点审核”。仅看当前单据金额不够，因为同样的金额在不同员工、部门、岗位、城市和费用类型下含义不同。
|
||
|
||
当前讨论中已经明确几个问题：
|
||
|
||
- 出差天数、出差金额、业务招待频次和招待标准需要和申请人挂钩，否则审核者看不到长期费用节奏。
|
||
- 用户操作时长、AI 使用次数、Token 消耗、审核时长、退单次数等指标也有价值，但它们性质不同，不能混成一个“坏人分”。
|
||
- 审批详情需要一个直观入口展示画像，例如“风险审核画像”卡片，但卡片必须展示证据、口径和建议，避免给员工贴不可解释标签。
|
||
- Hermes 已有数字员工和调度入口，画像检测应该接入现有 Hermes 任务体系，而不是另写一套调度器。
|
||
|
||
代码现状可作为第一版基础：
|
||
|
||
- `AgentRun`、`AgentToolCall`、`SemanticParseLog` 已记录 Agent 运行、工具调用耗时和语义解析日志。
|
||
- `ExpenseClaim`、`ExpenseClaimItem` 已承载费用申请和明细。
|
||
- `HermesTaskConfig`、`HermesTaskExecutionLog` 已承载 Hermes 任务配置和执行日志。
|
||
- 现有 Hermes 调度器会轮询启用任务，并按 `task_type` 分发到具体服务。
|
||
- 当前前端 Hermes 设置仅暴露 `global_risk_scan` 和 `weekly_expense_report` 两类任务，画像任务需要补齐配置入口。
|
||
|
||
## 3. 目标与非目标
|
||
|
||
### 3.1 目标
|
||
|
||
- 建立员工维度的多层画像：费用支出画像、流程质量画像、AI 协作画像、审批行为画像。
|
||
- 建立可审计的快照存储，不把动态画像直接写进员工主表。
|
||
- 形成可解释的量化公式，支持 30 / 90 / 180 天窗口。
|
||
- 接入 Hermes 数字员工任务，定期生成画像快照和汇总日志。
|
||
- 在审批详情中展示“风险审核画像”卡片，默认突出费用支出和流程质量。
|
||
- 保留指标来源、同组基准、计算窗口、任务日志和算法版本，便于复核。
|
||
- 明确 Token 统计口径：真实值、估算值和不可用值必须区分。
|
||
|
||
### 3.2 非目标
|
||
|
||
- 不用画像自动处罚员工，也不自动降低费用标准或缩短出差天数。
|
||
- 不把 AI 使用次数、Token 消耗直接当作费用风险。
|
||
- 不做全员每日全量画像快照，避免频率过高和无意义存储。
|
||
- 不重写 Hermes 调度器；如频率能力不足，优先增强现有 Hermes 调度体系。
|
||
- 不用 LLM 直接判定风险等级；LLM 仅可用于解释、摘要和报告生成。
|
||
|
||
## 4. 用户与场景
|
||
|
||
### 4.1 费用审核者
|
||
|
||
在费用申请详情页查看“风险审核画像”卡片。审核者需要知道：
|
||
|
||
- 申请人近期是否频繁申请大额出差或招待。
|
||
- 当前申请是否显著高于同组基准或个人历史。
|
||
- 申请人的材料质量是否经常导致退单、补充材料或复核。
|
||
- 系统建议是“重点复核”“建议补充说明”还是“建议升级审批”。
|
||
|
||
### 4.2 财务和预算管理员
|
||
|
||
在运营看板或 Hermes 报告中查看部门、项目、费用类型下的画像趋势。管理员需要识别：
|
||
|
||
- 哪些部门或项目存在持续预算占用压力。
|
||
- 哪些费用类型的人均标准偏离明显。
|
||
- 哪些流程环节反复出现退单或材料缺失。
|
||
|
||
### 4.3 AI 运营人员
|
||
|
||
观察 AI 调用、Token 消耗、建议采纳率和覆盖率。AI 运营人员需要知道：
|
||
|
||
- 哪些入口消耗高但采纳率低。
|
||
- 哪些业务流程高度依赖 AI。
|
||
- 哪些模型调用需要限额、优化或替换。
|
||
|
||
### 4.4 Hermes 数字员工
|
||
|
||
Hermes 作为调度入口，负责在设定周期内触发画像计算、写入快照、记录执行日志，并输出可读摘要。
|
||
|
||
## 5. 功能能力
|
||
|
||
### 5.1 输入
|
||
|
||
- 费用申请：申请人、部门、岗位、费用类型、申请金额、审批金额、出差天数、招待客户、业务地点、项目编号。
|
||
- 费用明细：明细金额、票据金额、费用类型、发生日期、供应商或客户线索。
|
||
- 审批流转：提交时间、审核开始时间、审核完成时间、退单、调减、复核、审批意见。
|
||
- Agent 数据：Agent 运行记录、工具调用次数、工具耗时、语义解析、AI 建议、AI 建议采纳或覆盖。
|
||
- Token 数据：输入 Token、输出 Token、总 Token、估算 Token、不可用状态。
|
||
- Hermes 数据：任务配置、任务执行日志、报告或风险巡检结果。
|
||
- 组织基准：部门、岗位、职级、城市等级、项目类型、费用类型和预算池。
|
||
|
||
### 5.2 输出
|
||
|
||
- 员工画像快照：每个员工、每个窗口、每个画像类型一条或多条快照。
|
||
- 最新画像查询：给审批详情、运营看板和 Hermes 报告读取。
|
||
- 画像证据：指标值、同组基准、贡献项、命中原因、数据质量标记。
|
||
- 画像标签：把复杂指标转成可读标签，例如“费用之王”“长差达人”“材料补丁户”“急速审核员”，每个标签必须有触发公式、置信度和证据。
|
||
- 行为雷达图：把费用、差旅招待、流程质量、AI 协作和审批行为压缩成 6 到 8 个维度，用于分析者快速理解员工行为结构。
|
||
- 审核建议：复核天数、复核金额、补充材料、升级审批、关注预算占用等建议。
|
||
- Hermes 执行摘要：本次计算人数、生成快照数、高关注人数、失败原因。
|
||
|
||
### 5.3 审批详情卡片
|
||
|
||
审批详情中建议新增卡片：`风险审核画像`。
|
||
|
||
卡片默认展示：
|
||
|
||
- 总览：画像等级、计算时间、窗口期、同组基准口径。
|
||
- 特征标签：展示 3 到 6 个置信度最高、与当前场景相关的标签；风险型标签优先，但必须保留证据入口。
|
||
- 雷达图：展示行为维度得分，帮助审核者一眼判断该员工是“费用强度高”“材料质量弱”还是“审批节奏快”。
|
||
- 费用支出：频次、金额占用、同组偏离、历史调减、当前单据偏离。
|
||
- 流程质量：退单、附件缺失、发票不一致、补充材料、重提耗时。
|
||
- 当前单据建议：是否建议复核出差天数、招待人均金额、业务必要性或预算占用。
|
||
- 证据展开：展示贡献最高的 3 到 5 个指标和原始口径。
|
||
|
||
审批详情默认不突出 AI 协作画像和审批人行为画像。AI 指标主要服务运营治理，审批人画像只在管理员或流程治理场景展示。
|
||
|
||
### 5.4 权限和边界
|
||
|
||
- 普通审核者只能看到与当前单据审核有关的申请人费用画像和流程质量画像。
|
||
- 财务管理员可查看部门、项目和费用类型维度的汇总趋势。
|
||
- AI 运营人员可查看 AI 协作画像，但不把它用于单据费用风险裁决。
|
||
- 审批行为画像只面向管理员和流程治理角色展示。
|
||
- 所有画像结论必须展示数据窗口和计算时间，避免被误读为永久标签。
|
||
|
||
## 6. 方案设计
|
||
|
||
### 6.1 数据模型
|
||
|
||
第一版建议新增通用快照表：
|
||
|
||
```text
|
||
employee_behavior_profile_snapshots
|
||
```
|
||
|
||
核心字段：
|
||
|
||
```text
|
||
id
|
||
subject_type applicant / approver / employee
|
||
subject_id employee_id 或 user_id
|
||
subject_name
|
||
department_id
|
||
department_name
|
||
position
|
||
grade
|
||
|
||
profile_type expense / process_quality / ai_usage / approval
|
||
window_days 30 / 90 / 180
|
||
expense_type_scope overall / travel / entertainment / ...
|
||
peer_group_key
|
||
peer_group_fallback_level
|
||
|
||
profile_score 0-100
|
||
profile_level normal / watch / review / escalation
|
||
metrics_json 原始指标、分位数、样本量、Token 口径
|
||
basis_codes_json 贡献项和解释编码
|
||
profile_tags_json 标签、触发分、置信度、证据和展示优先级
|
||
radar_json 雷达图维度、维度分、维度等级和主导标签
|
||
source_task_type employee_behavior_profile_scan
|
||
source_task_log_id HermesTaskExecutionLog.id
|
||
algorithm_version
|
||
calculated_at
|
||
created_at
|
||
```
|
||
|
||
不建议把画像直接写入员工主表，例如 `employee.profile_score = 80`。画像是动态计算结果，需要保留算法版本、窗口期和历史依据。
|
||
|
||
### 6.2 后端服务
|
||
|
||
建议拆成三个职责：
|
||
|
||
- 数据抽取服务：从费用、审批、Agent、Hermes 记录中抽取指标。
|
||
- 算法服务：在 `server/src/app/algorithem` 下维护评分公式、等级判定和解释贡献项。
|
||
- 应用服务：负责员工集合筛选、快照写入、最新画像查询和 Hermes 执行结果汇总。
|
||
|
||
候选模块：
|
||
|
||
```text
|
||
server/src/app/algorithem/employee_behavior_profile.py
|
||
server/src/app/services/employee_behavior_profile_service.py
|
||
server/src/app/services/hermes_employee_profile_scanner.py
|
||
server/src/app/models/employee_behavior_profile.py
|
||
```
|
||
|
||
### 6.3 Hermes 接入
|
||
|
||
新增任务类型：
|
||
|
||
```text
|
||
employee_behavior_profile_scan
|
||
```
|
||
|
||
接入原则：
|
||
|
||
- 复用现有 `HermesTaskConfig` 和 `HermesTaskExecutionLog`。
|
||
- 在现有 `HermesScheduler._execute_task()` 中增加任务分发。
|
||
- 在 `start_hermes_daemon.py` 中初始化画像任务配置。
|
||
- 在 `hermesEmployeeSettingsModel.js` 中补充任务展示和默认开关。
|
||
- 不创建第二个后台调度器。
|
||
|
||
频率建议：
|
||
|
||
- 第一版不做全员每日全量。
|
||
- 推荐每周一次全量画像，工作日对存在待审单据的员工做轻量增量。
|
||
- 如果现有 Hermes 调度只支持近似每日触发，应先把画像任务默认关闭或仅启用轻量扫描；后续在现有调度器内补齐 frequency / weekday / time 判断。
|
||
|
||
### 6.4 API 契约
|
||
|
||
审批详情读取最新画像：
|
||
|
||
```text
|
||
GET /api/v1/employee-profiles/{employee_id}/latest
|
||
```
|
||
|
||
建议查询参数：
|
||
|
||
```text
|
||
scene=approval
|
||
claim_id=<claim_id>
|
||
window_days=90
|
||
expense_type_scope=travel|entertainment|overall
|
||
```
|
||
|
||
响应结构建议：
|
||
|
||
```json
|
||
{
|
||
"employee_id": "EMP001",
|
||
"window_days": 90,
|
||
"calculated_at": "2026-05-28T10:30:00+08:00",
|
||
"peer_group": {
|
||
"key": "FINANCE|M2|travel|tier1",
|
||
"fallback_level": 1,
|
||
"sample_size": 42
|
||
},
|
||
"profiles": [
|
||
{
|
||
"profile_type": "expense",
|
||
"score": 72,
|
||
"level": "review",
|
||
"top_contributors": [
|
||
{
|
||
"code": "peer_deviation_high",
|
||
"label": "差旅日均费用高于同组 P90",
|
||
"value": 1.18,
|
||
"unit": "ratio"
|
||
}
|
||
]
|
||
}
|
||
],
|
||
"profile_tags": [
|
||
{
|
||
"code": "expense_king",
|
||
"label": "费用之王",
|
||
"display_label": "费用集中度高",
|
||
"category": "expense",
|
||
"polarity": "risk",
|
||
"score": 86,
|
||
"confidence": 0.82,
|
||
"reason": "近90天费用总额达到同组P90，且部门费用占比为34%",
|
||
"metrics": {
|
||
"amount_total": 128000,
|
||
"peer_amount_p90": 76000,
|
||
"amount_share": 0.34
|
||
}
|
||
}
|
||
],
|
||
"radar": {
|
||
"dimensions": [
|
||
{
|
||
"code": "expense_intensity",
|
||
"label": "费用强度",
|
||
"score": 78,
|
||
"level": "review",
|
||
"top_tags": ["expense_king", "large_amount_deviation"]
|
||
}
|
||
]
|
||
},
|
||
"review_suggestions": [
|
||
{
|
||
"type": "review_travel_days",
|
||
"severity": "medium",
|
||
"message": "建议复核出差天数和业务必要性"
|
||
}
|
||
]
|
||
}
|
||
```
|
||
|
||
### 6.5 前端展示
|
||
|
||
审批详情页新增 `风险审核画像` 卡片，建议分成三层：
|
||
|
||
- 顶部摘要：等级、窗口期、同组基准、更新时间。
|
||
- 中部指标：费用支出和流程质量两个分组。
|
||
- 底部建议：系统建议和证据展开。
|
||
|
||
文案边界：
|
||
|
||
- 使用“关注”“复核”“建议”而不是“惩罚”“违规”“头号人物”。
|
||
- 展示“该结论来自 90 天窗口和同组对比”，避免变成员工永久标签。
|
||
- AI 协作强度只作为运营指标，不在费用审批默认卡片中强调。
|
||
|
||
## 7. 算法与公式
|
||
|
||
### 7.1 通用归一化
|
||
|
||
对越大越需要关注的指标，使用同组分位数归一化：
|
||
|
||
$$
|
||
score(x) = clip\left(100 \times \frac{x - P_{50}}{P_{90} - P_{50}}, 0, 100\right)
|
||
$$
|
||
|
||
其中：
|
||
|
||
- \(x\)：员工在窗口期内的指标值。
|
||
- \(P_{50}\)：同组中位数。
|
||
- \(P_{90}\)：同组 90 分位数。
|
||
- \(clip(v, 0, 100)\)：把结果限制在 0 到 100。
|
||
|
||
当同组样本不足时，按以下顺序降级：
|
||
|
||
```text
|
||
部门 + 岗位 + 费用类型
|
||
→ 部门 + 费用类型
|
||
→ 岗位 + 费用类型
|
||
→ 公司 + 费用类型
|
||
```
|
||
|
||
降级层级必须写入 `peer_group_fallback_level`。
|
||
|
||
### 7.2 费用支出画像
|
||
|
||
$$
|
||
expense\_profile\_score =
|
||
0.20F + 0.25B + 0.25D + 0.15H + 0.15C
|
||
$$
|
||
|
||
变量定义：
|
||
|
||
- \(F\)：费用申请频次分，包含出差、招待等申请次数。
|
||
- \(B\)：预算占用分，包含个人费用占部门或项目预算比例。
|
||
- \(D\)：同组偏离分，包含金额、天数、人均招待金额等分位数偏离。
|
||
- \(H\)：历史调减和复核分，包含历史调减、退回、复核次数。
|
||
- \(C\)：当前单据偏离分，衡量当前申请相对个人历史和同组基准的偏离。
|
||
|
||
### 7.3 流程质量画像
|
||
|
||
$$
|
||
process\_quality\_score =
|
||
0.25R + 0.20A + 0.20I + 0.15T + 0.20M
|
||
$$
|
||
|
||
变量定义：
|
||
|
||
- \(R\)：退单次数分。
|
||
- \(A\)：附件缺失分。
|
||
- \(I\)：发票金额或票据一致性问题分。
|
||
- \(T\)：退回后重新提交耗时分。
|
||
- \(M\)：业务上下文缺失分，包含事由、地点、项目编号、客户信息等。
|
||
|
||
### 7.4 AI 协作画像
|
||
|
||
AI 协作画像命名为强度分，不命名为风险分。
|
||
|
||
$$
|
||
ai\_usage\_intensity\_score =
|
||
0.25N + 0.25K + 0.20G + 0.20O + 0.10E
|
||
$$
|
||
|
||
变量定义：
|
||
|
||
- \(N\)：AI 调用次数分。
|
||
- \(K\)：Token 或估算成本分。
|
||
- \(G\)：AI 辅助生成申请比例分。
|
||
- \(O\)：AI 建议被人工覆盖分。
|
||
- \(E\)：AI 调用失败或低置信度分。
|
||
|
||
Token 口径必须进入 `metrics_json`：
|
||
|
||
```text
|
||
exact_token_count 真实记录
|
||
estimated_token_count 按文本长度估算
|
||
unavailable 当前入口不可用
|
||
```
|
||
|
||
### 7.5 审批行为画像
|
||
|
||
审批行为画像用于流程治理，不用于评价申请人的费用合理性。
|
||
|
||
$$
|
||
approval\_behavior\_score =
|
||
0.20L + 0.20S + 0.20P + 0.20Q + 0.20V
|
||
$$
|
||
|
||
变量定义：
|
||
|
||
- \(L\)：平均审核时长分。
|
||
- \(S\)：SLA 超时分。
|
||
- \(P\)：直接通过率异常分。
|
||
- \(Q\)：高风险单据通过率分。
|
||
- \(V\)：系统建议被覆盖分。
|
||
|
||
### 7.6 审批优先级分
|
||
|
||
审批详情只使用费用支出和流程质量形成优先级，不引入 AI 协作强度。
|
||
|
||
$$
|
||
review\_priority\_score =
|
||
clip(0.70 \times expense\_profile\_score +
|
||
0.30 \times process\_quality\_score, 0, 100)
|
||
$$
|
||
|
||
等级映射：
|
||
|
||
$$
|
||
level(s)=
|
||
\begin{cases}
|
||
normal, & 0 \le s < 40 \\
|
||
watch, & 40 \le s < 60 \\
|
||
review, & 60 \le s < 80 \\
|
||
escalation, & 80 \le s \le 100
|
||
\end{cases}
|
||
$$
|
||
|
||
### 7.7 审核建议公式
|
||
|
||
系统建议只能作为复核提示，不自动改写申请单。
|
||
|
||
差旅天数建议上限：
|
||
|
||
$$
|
||
recommended\_days\_upper =
|
||
min(requested\_days,\ P_{75}^{peer\_days} \times factor(level))
|
||
$$
|
||
|
||
业务招待人均金额建议上限：
|
||
|
||
$$
|
||
recommended\_entertainment\_unit\_upper =
|
||
min(policy\_limit,\ P_{75}^{peer\_unit\_amount} \times factor(level))
|
||
$$
|
||
|
||
其中：
|
||
|
||
$$
|
||
factor(level)=
|
||
\begin{cases}
|
||
1.20, & normal \\
|
||
1.10, & watch \\
|
||
1.00, & review \\
|
||
0.90, & escalation
|
||
\end{cases}
|
||
$$
|
||
|
||
如果当前申请本身有充分业务依据，审核者可以覆盖系统建议。覆盖原因应进入后续流程治理指标。
|
||
|
||
### 7.8 目标员工集合
|
||
|
||
第一版不计算全员。每次 Hermes 扫描目标集合为：
|
||
|
||
$$
|
||
target\_employees =
|
||
E_{claims180} \cup E_{pending} \cup E_{previous\_attention} \cup E_{ops\_threshold}
|
||
$$
|
||
|
||
变量定义：
|
||
|
||
- \(E_{claims180}\)：近 180 天有费用申请的员工。
|
||
- \(E_{pending}\)：当前有待审费用申请的员工。
|
||
- \(E_{previous\_attention}\)：上一期画像等级为 watch、review 或 escalation 的员工。
|
||
- \(E_{ops\_threshold}\)：AI 使用或审批行为达到运营关注阈值的员工。
|
||
|
||
### 7.9 用户画像标签体系
|
||
|
||
标签用于把复杂指标转成直观特征。标签不是永久评价，也不是处罚依据；它只表示员工在某个时间窗口、某个同组基准下呈现出的行为特征。
|
||
|
||
前端可以展示两层文案：
|
||
|
||
- `label`：内部或分析侧标签，例如“费用之王”“急速审核员”。
|
||
- `display_label`：审批详情默认展示文案，例如“费用集中度高”“快速审核型”。
|
||
|
||
标签输出结构建议：
|
||
|
||
```json
|
||
{
|
||
"code": "expense_king",
|
||
"label": "费用之王",
|
||
"display_label": "费用集中度高",
|
||
"category": "expense",
|
||
"polarity": "risk",
|
||
"score": 86,
|
||
"confidence": 0.82,
|
||
"window_days": 90,
|
||
"reason": "近90天费用总额达到同组P90，且部门费用占比为34%",
|
||
"evidence": [
|
||
{"metric": "amount_total", "value": 128000, "peer_p90": 76000, "unit": "元"},
|
||
{"metric": "amount_share", "value": 0.34, "threshold": 0.30, "unit": "比例"}
|
||
],
|
||
"radar_dimensions": ["expense_intensity"]
|
||
}
|
||
```
|
||
|
||
#### 7.9.1 通用标签打分
|
||
|
||
标签触发后仍然需要计算强度和置信度，避免一个边界值把员工直接贴成强标签。
|
||
|
||
$$
|
||
tag\_score =
|
||
clip(100 \times (0.55S + 0.25C + 0.20R), 0, 100)
|
||
$$
|
||
|
||
$$
|
||
confidence =
|
||
clip(DQ \times (0.65S + 0.20SR + 0.15C), 0, 1)
|
||
$$
|
||
|
||
变量定义：
|
||
|
||
- \(S\)：指标强度，表示当前指标超过阈值或同组分位数的程度。
|
||
- \(C\)：持续性，30 / 90 / 180 天三个窗口中命中的窗口比例。
|
||
- \(R\)：近期性，最近一次命中距今天数越近分越高。
|
||
- \(DQ\)：数据质量，字段完整、样本充足、无估算时更高。
|
||
- \(SR\)：样本可靠性，同组样本量越大越可靠。
|
||
|
||
标签展示阈值：
|
||
|
||
$$
|
||
active(tag)=
|
||
\begin{cases}
|
||
true, & tag\_score \ge 60 \land confidence \ge 0.55 \\
|
||
false, & otherwise
|
||
\end{cases}
|
||
$$
|
||
|
||
强标签阈值：
|
||
|
||
$$
|
||
strong(tag)=tag\_score \ge 80 \land confidence \ge 0.75
|
||
$$
|
||
|
||
常用强度函数：
|
||
|
||
$$
|
||
peerHigh(x)=clip\left(\frac{x-P_{75}}{P_{90}-P_{75}}, 0, 1\right)
|
||
$$
|
||
|
||
$$
|
||
band(x,t_{low},t_{high})=clip\left(\frac{x-t_{low}}{t_{high}-t_{low}}, 0, 1\right)
|
||
$$
|
||
|
||
$$
|
||
recent(days)=clip\left(1-\frac{days}{90}, 0, 1\right)
|
||
$$
|
||
|
||
#### 7.9.2 第一版候选标签清单
|
||
|
||
以下标签均需要写入触发依据、窗口期、同组样本量和 fallback 层级。审批详情默认只展示与当前单据相关的前 3 到 6 个标签；运营看板可展示完整标签。
|
||
|
||
| 类别 | code / 标签 | 默认展示文案 | 量化触发条件 | 雷达维度 |
|
||
| --- | --- | --- | --- | --- |
|
||
| 费用支出 | `expense_king` / 费用之王 | 费用集中度高 | \(amount\_total_{90} \ge P90(amount\_total)\) 且 \(amount\_share_{90} \ge 0.30\)。强度 \(S=max(peerHigh(amount\_total), band(amount\_share,0.15,0.45))\)。 | 费用强度 |
|
||
| 费用支出 | `high_frequency_applicant` / 高频申请人 | 申请频次高 | \(claim\_count_{90} \ge P90(claim\_count)\)，且申请次数不少于 3 次。强度 \(S=peerHigh(claim\_count)\)。 | 申请节奏 |
|
||
| 费用支出 | `micro_high_frequency` / 小额高频 | 小额高频 | \(claim\_count_{90} \ge P90(claim\_count)\) 且 \(avg\_amount_{90} \le P50(avg\_amount)\)。 | 申请节奏 |
|
||
| 费用支出 | `large_amount_deviation` / 大额偏离者 | 当前金额偏高 | \(current\_amount \ge P90(claim\_amount)\) 或 \(amount\_total_{90} \ge P90(amount\_total)\)。 | 费用强度 |
|
||
| 费用支出 | `budget_sprint` / 预算冲刺型 | 近期费用集中 | \(amount_{30}/amount_{90} \ge 0.55\) 且 \(amount_{30} \ge P75(amount_{30})\)。 | 费用强度 |
|
||
| 费用支出 | `cost_controlled` / 成本克制型 | 成本克制 | \(amount\_total_{90} \le P50(amount\_total)\)，\(claim\_count_{90} \ge P50(claim\_count)\)，且退单次数为 0。该标签为正向标签。 | 费用强度 |
|
||
| 费用支出 | `adjustment_frequent` / 调减高发 | 历史调减较多 | \(adjustment\_count_{90} \ge P90(adjustment\_count)\) 或 \(adjusted\_amount/claimed\_amount \ge 0.20\)。 | 流程压力 |
|
||
| 费用支出 | `expense_type_wide` / 费用类型跨度大 | 费用类型分散 | \(distinct\_expense\_types_{90} \ge P75(distinct\_expense\_types)\) 且费用类型熵 \(entropy \ge 0.60\)。 | 申请节奏 |
|
||
| 差旅招待 | `long_trip_master` / 长差达人 | 出差天数偏长 | \(current\_travel\_days \ge 1.5 \times P75(peer\_days)\) 或 \(travel\_days_{90} \ge P90(travel\_days)\)。 | 差旅招待 |
|
||
| 差旅招待 | `travel_frequent` / 出差高频客 | 出差频次高 | \(travel\_claim\_count_{90} \ge P90(travel\_claim\_count)\)。 | 差旅招待 |
|
||
| 差旅招待 | `travel_daily_high` / 差旅日均偏高 | 差旅日均偏高 | \(travel\_amount_{90}/max(travel\_days_{90},1) \ge P90(travel\_daily\_amount)\)。 | 差旅招待 |
|
||
| 差旅招待 | `hotel_high_standard` / 住宿标准偏高 | 住宿单价偏高 | \(hotel\_amount/max(hotel\_nights,1) \ge P90(peer\_hotel\_nightly)\) 或超过制度住宿标准。 | 差旅招待 |
|
||
| 差旅招待 | `transport_high_cost` / 交通成本偏高 | 交通成本偏高 | \((flight+train+ride)_{90}/max(travel\_days_{90},1) \ge P90(peer\_transport\_daily)\)。 | 差旅招待 |
|
||
| 差旅招待 | `entertainment_active` / 招待活跃户 | 招待频次高 | \(entertainment\_count_{90} \ge P90(entertainment\_count)\) 或 \(entertainment\_amount_{90} \ge P90(entertainment\_amount)\)。 | 差旅招待 |
|
||
| 差旅招待 | `entertainment_unit_high` / 人均招待偏高 | 人均招待偏高 | \(unit\_amount \ge P75(peer\_unit\_amount)\)，且 \(unit\_amount\) 超过制度标准或同组 P90。 | 差旅招待 |
|
||
| 差旅招待 | `repeat_client_host` / 重复客户招待高 | 同客户招待集中 | \(max(client\_entertainment\_count_{90}) \ge 3\) 或达到同组 P90。客户无法结构化时降级为“客户线索不足”。 | 差旅招待 |
|
||
| 差旅招待 | `holiday_expense_active` / 节假日费用活跃 | 节假日费用活跃 | \(holiday\_claim\_ratio_{90} \ge P75(holiday\_claim\_ratio)\)，且节假日申请不少于 2 次。 | 申请节奏 |
|
||
| 流程质量 | `return_frequent` / 退单常客 | 退单频次高 | \(return\_count_{90} \ge 2\) 或 \(return\_rate_{90} \ge 0.30\)，且达到同组 P75。 | 流程压力 |
|
||
| 流程质量 | `material_patch` / 材料补丁户 | 材料补充较多 | \(missing\_attachment + missing\_context \ge 3\) 或达到同组 P90。 | 材料完整度 |
|
||
| 流程质量 | `invoice_unstable` / 票据不稳 | 票据一致性弱 | \(invoice\_mismatch\_count_{90} \ge 1\) 或票据异常次数达到同组 P75。 | 材料完整度 |
|
||
| 流程质量 | `reason_thin` / 事由空心化 | 事由说明偏弱 | 空事由、模板化事由或少于最小字数的事由占比 \(\ge 0.40\)。 | 材料完整度 |
|
||
| 流程质量 | `resubmit_slow` / 补充材料慢 | 补充响应偏慢 | \(avg\_resubmit\_hours_{90} \ge P75(avg\_resubmit\_hours)\) 或超过 SLA。 | 流程压力 |
|
||
| 流程质量 | `repeat_issue` / 重复问题未改善 | 同类问题反复 | 同一问题编码在 90 天内出现 \(\ge 2\) 次，且 30 天内仍出现。 | 流程压力 |
|
||
| 流程质量 | `clean_first_pass` / 材料清爽 | 一次通过质量好 | \(first\_pass\_rate_{90} \ge 0.90\)，附件缺失为 0，票据不一致为 0。该标签为正向标签。 | 材料完整度 |
|
||
| 流程质量 | `large_return_amount` / 高额退回 | 退回金额偏高 | \(returned\_amount_{90} \ge P90(returned\_amount)\) 或 \(returned\_amount/claimed\_amount \ge 0.20\)。 | 流程压力 |
|
||
| AI 协作 | `ai_heavy` / AI 重度用户 | AI 使用频繁 | \(ai\_run\_count_{90} \ge P90(ai\_run\_count)\)。 | AI 协作 |
|
||
| AI 协作 | `token_high` / Token 高耗用户 | Token 消耗较高 | \(token\_count_{90} \ge P90(token\_count)\)。估算 Token 必须标记 `estimated`，不得当作真实成本。 | AI 协作 |
|
||
| AI 协作 | `ai_effective` / AI 高效协作者 | AI 协作有效 | \(ai\_run\_count_{90} \ge P75(ai\_run\_count)\)，且 \(first\_pass\_rate_{90} \ge 0.85\)，流程质量分低于 40。该标签为正向标签。 | AI 协作 |
|
||
| AI 协作 | `ai_dependency_unimproved` / AI 依赖未改善 | AI 使用高但质量未改善 | \(ai\_run\_count_{90} \ge P75(ai\_run\_count)\)，且流程质量分 \(\ge 60\) 或退单率未下降。 | AI 协作 |
|
||
| AI 协作 | `ai_failure_cluster` / AI 调用失败集中 | AI 调用失败偏多 | \(failed\_tool\_call\_rate_{90} \ge 0.20\) 或失败次数达到同组 P90。 | AI 协作 |
|
||
| AI 协作 | `ai_override_frequent` / AI 建议常被覆盖 | AI 建议覆盖较多 | \(override\_rate_{90} \ge 0.40\) 或覆盖次数达到同组 P75。无结构化覆盖字段时不触发。 | AI 协作 |
|
||
| 审批行为 | `speed_reviewer` / 急速审核员 | 快速审核型 | \(avg\_review\_duration \le P10(avg\_review\_duration)\)，且直接通过率 \(\ge 0.90\)。该标签为行为型，不默认视为风险。 | 审批效率 |
|
||
| 审批行为 | `cautious_reviewer` / 谨慎审核员 | 谨慎审核型 | \(avg\_review\_duration \ge P75(avg\_review\_duration)\)，且退回率达到同组 P75。 | 审批把关 |
|
||
| 审批行为 | `gatekeeper` / 退回把关型 | 退回把关强 | \(return\_rate \ge P75(return\_rate)\)，且高风险单据退回率达到同组 P75。 | 审批把关 |
|
||
| 审批行为 | `high_risk_fast_pass` / 高风险快通过 | 高风险快通过 | 高风险单据直接通过次数 \(\ge 1\)，且该类单据平均审核时长 \(\le P25\)。 | 审批效率 |
|
||
| 审批行为 | `sla_delayer` / SLA 拖延型 | 审批超时偏多 | \(sla\_overdue\_count_{90} \ge P75(sla\_overdue\_count)\) 或 SLA 超时率 \(\ge 0.25\)。 | 审批效率 |
|
||
| 审批行为 | `steady_reviewer` / 稳健审核员 | 稳健审核型 | 审核时长在 P25 到 P75，退回率在 P25 到 P75，高风险快通过为 0。该标签为正向标签。 | 审批把关 |
|
||
|
||
### 7.10 行为雷达图
|
||
|
||
雷达图用于表达“行为结构”，不是单一风险分。第一版建议 8 个维度，每个维度 0 到 100 分。
|
||
|
||
$$
|
||
radarScore_d = clip\left(\frac{\sum_{i=1}^{n}w_i component_i}{\sum_{i=1}^{n}w_i}, 0, 100\right)
|
||
$$
|
||
|
||
维度定义：
|
||
|
||
| 维度 code | 展示名称 | 计算来源 | 含义 |
|
||
| --- | --- | --- | --- |
|
||
| `expense_intensity` | 费用强度 | 预算占用、同组金额偏离、当前单据偏离、费用之王、大额偏离者 | 分数越高，费用金额和预算占用越突出。 |
|
||
| `application_rhythm` | 申请节奏 | 申请频次、小额高频、费用类型跨度、近期费用集中 | 分数越高，申请节奏越密集或集中。 |
|
||
| `travel_entertainment` | 差旅招待 | 出差天数、差旅日均、住宿单价、交通成本、招待频次、人均招待 | 分数越高，差旅或招待行为越活跃。 |
|
||
| `material_completeness` | 材料完整度压力 | 附件缺失、票据不一致、事由空心化、重复问题 | 分数越高，材料质量越需要关注。 |
|
||
| `process_pressure` | 流程压力 | 退单、调减、高额退回、补充材料耗时 | 分数越高，流程返工和沟通成本越高。 |
|
||
| `ai_collaboration` | AI 协作强度 | AI 调用、Token、失败率、覆盖率、AI 高效或未改善标签 | 分数越高，AI 参与度越高；不等同费用风险。 |
|
||
| `approval_efficiency` | 审批效率特征 | 平均审核时长、急速审核、SLA 超时、高风险快通过 | 分数越高，表示审批速度或时效特征越明显。 |
|
||
| `approval_control` | 审批把关特征 | 退回率、高风险退回率、谨慎审核、稳健审核 | 分数越高，表示审批把关或复核行为越明显。 |
|
||
|
||
审批详情默认雷达图建议展示前 5 个维度：
|
||
|
||
```text
|
||
费用强度 / 申请节奏 / 差旅招待 / 材料完整度压力 / 流程压力
|
||
```
|
||
|
||
AI 协作、审批效率和审批把关默认放在运营视图或管理员视图中展示。审批详情如需展示，必须明确标注“不参与费用风险裁决”。
|
||
|
||
## 8. 测试方案
|
||
|
||
- 单元测试：覆盖归一化、同组降级、四类画像评分、等级映射、审核建议生成。
|
||
- 标签算法测试：覆盖 36 个候选标签的触发、未触发、强标签、置信度和数据质量降级。
|
||
- 雷达图测试：覆盖 8 个雷达维度的维度分、等级映射和 top tags 关联。
|
||
- 数据服务测试：覆盖费用、审批、Agent、Hermes 数据缺失时的降级逻辑。
|
||
- API 测试：覆盖审批场景读取最新画像、权限过滤、无画像时的空态。
|
||
- Hermes 测试：覆盖任务配置初始化、任务分发、执行日志成功和失败状态。
|
||
- 前端测试：覆盖“风险审核画像”卡片的正常态、空态、标签展示、雷达图展示、证据展开和权限隐藏。
|
||
- 回归测试：确保 AI 协作强度不进入审批优先级分。
|
||
- 手工验证：用包含差旅、招待、退单、AI 调用的样例员工验证卡片展示是否可解释。
|
||
|
||
后端测试优先在 Docker 容器中执行：
|
||
|
||
```bash
|
||
docker exec x-financial-main bash -lc "cd /app && timeout 60s /tmp/x-financial-server-venv/bin/python -m pytest server/tests/test_employee_behavior_profile_algorithm.py -q"
|
||
```
|
||
|
||
## 9. 指标与验收
|
||
|
||
- 能为目标员工生成 30 / 90 / 180 天窗口画像快照。
|
||
- 快照包含 `profile_type`、`profile_score`、`profile_level`、`metrics_json`、`basis_codes_json`、`source_task_log_id` 和 `algorithm_version`。
|
||
- 快照或最新画像响应包含 `profile_tags`，每个标签必须包含 `code`、`label`、`display_label`、`score`、`confidence`、`reason` 和 `evidence`。
|
||
- 最新画像响应包含 `radar.dimensions`，每个维度必须包含 `code`、`label`、`score`、`level` 和 `top_tags`。
|
||
- 每个标签都有实际量化触发条件，不能只靠文字描述或 LLM 判断。
|
||
- 审批详情默认展示不超过 6 个标签，优先展示与当前单据相关且置信度最高的标签。
|
||
- 雷达图默认展示费用审核相关维度，AI 和审批人行为维度不参与申请人费用风险裁决。
|
||
- 同一输入和同一算法版本下，评分结果可重复。
|
||
- 同组样本不足时有明确 fallback 记录。
|
||
- Token 统计明确区分真实、估算和不可用，不把估算值包装成真实计费数据。
|
||
- 审批详情卡片只默认展示申请人费用画像和流程质量画像。
|
||
- AI 协作强度不进入 `review_priority_score`。
|
||
- Hermes 任务执行后能写入执行日志、结果摘要和失败堆栈。
|
||
- 后端定向单元测试在 60 秒内通过。
|
||
- 前端构建或相关测试通过，且卡片在无画像时有稳定空态。
|
||
|
||
## 10. 风险与开放问题
|
||
|
||
- Token 采集可能并不完整，需要先确认各 AI 入口是否真实记录 Token。
|
||
- 审批开始时间、完成时间、退单原因、补充材料事件可能还不够结构化。
|
||
- 当前 Hermes 调度器对频率的执行能力需要核对；如只支持近似每日触发，需要在现有调度器内增强。
|
||
- 同组样本量不足时，分位数容易失真，需要展示样本量和 fallback 层级。
|
||
- 审批详情中的画像语言要克制，避免把治理建议变成员工标签。
|
||
- 标签名称需要区分内部分析文案和前端默认展示文案，避免“费用之王”等趣味标签在审批场景造成压迫感。
|
||
- 雷达图维度不能混淆“行为强度”和“风险结论”；AI 使用强度、审批速度特征必须单独解释。
|
||
- 正向标签和风险标签需要同时存在，否则画像容易变成单向负面评价。
|
||
- 画像快照可能增长较快，需要后续定义保留周期和归档策略。
|
||
- 业务招待中的客户、用户或项目标识需要数据标准化，否则重复招待次数难以准确统计。
|