# 员工业务行为画像模型方案

## 目标

员工业务行为画像用于把费用申请、审批流转、AI 协作和数字员工巡检中产生的行为数据沉淀为可解释的统计画像。

它不是给员工贴负面标签，也不是替代审批人做最终判断，而是为以下场景提供结构化依据：

- 费用审批详情页展示申请人近期费用节奏和材料质量。
- Hermes 数字员工定期巡检高频费用、异常预算占用和流程质量问题。
- 运营看板观察 AI 使用、Token 消耗、流程耗时和审核效率。
- 后续规则中心根据真实覆盖率和人工覆盖情况优化规则阈值。

## 设计原则

1. 不把不同性质的数据混成一个总分。
2. 费用风险、流程质量、AI 使用、审批行为必须分维度计算。
3. 画像结果必须能追溯到指标、窗口期、同组基准和计算时间。
4. Hermes 负责调度和沉淀快照，确定性算法负责计算，LLM 只可用于解释和报告。
5. 画像用于审批参考和运营治理，不直接作为惩罚或自动降标依据。

## 画像分层

```text
员工业务行为画像
├── 费用支出画像
├── 流程质量画像
├── AI 协作画像
└── 审批行为画像
```

### 费用支出画像

用于判断申请人的费用节奏是否显著高于同组基准。

核心指标：

- 近 30 / 90 / 180 天申请次数。
- 近 30 / 90 / 180 天申请金额。
- 差旅申请次数、出差天数、日均费用。
- 招待申请次数、人均招待金额、同客户重复招待次数。
- 个人费用占部门预算比例。
- 个人费用占项目预算比例。
- 同部门、同岗位、同费用类型分位数。
- 历史调减、退回、复核次数。

审批用途：

- 识别高频费用申请人。
- 提醒审核者复核出差天数和费用标准。
- 推荐补充业务必要性、拆分费用或升级审批。

### 流程质量画像

用于判断申请人提交材料和流程配合质量。

核心指标：

- 草稿到提交平均耗时。
- 退回到重新提交平均耗时。
- 退单次数。
- 补充材料次数。
- 附件缺失次数。
- 发票金额不一致次数。
- 申请事由缺失次数。
- 业务地点缺失次数。
- 项目编号缺失次数。
- 同一申请多次修改次数。

审批用途：

- 提示“近期材料质量偏低，需要重点核对附件和事由”。
- 对高频退单申请人提高材料完整性检查权重。
- 对低质量申请触发补充材料建议，而不是直接判定费用风险。

### AI 协作画像

用于观察员工和系统的 AI 协作行为，不直接判定费用风险。

核心指标：

- AI 调用次数。
- AI 辅助生成申请次数。
- AI 解析票据次数。
- AI 预审次数。
- 语义解析次数。
- 输入 Token。
- 输出 Token。
- 总 Token。
- 估算调用成本。
- AI 建议被采纳次数。
- AI 建议被人工覆盖次数。
- AI 生成后人工修改次数。

运营用途：

- 观察哪些流程高度依赖 AI。
- 识别高成本用户、部门或功能入口。
- 衡量 AI 建议采纳率和被覆盖率。
- 为模型配置、成本控制和产品优化提供依据。

审批边界：

AI 使用多不等于风险高。Token 消耗、AI 调用次数不应直接推高费用审批风险，只能作为运营和辅助说明。

### 审批行为画像

用于分析审批人的审核效率和审核风格。

核心指标：

- 平均审核时长。
- 中位审核时长。
- 超 SLA 次数。
- 直接通过率。
- 退回率。
- 调减率。
- 高风险单据通过率。
- 系统建议采纳率。
- 系统建议覆盖率。
- 审批意见完整度。
- 审批积压数量。

治理用途：

- 识别审批积压。
- 识别过度宽松或过度退回的审批模式。
- 评估规则建议是否被人工持续覆盖。
- 为流程优化和审批授权调整提供依据。

## 计算窗口

第一版建议支持三个窗口：

```text
30 天：识别近期异常波动
90 天：作为审批详情页默认画像
180 天：用于稳定趋势和年度预算节奏
```

审批详情页默认读取 `90 天` 画像。运营看板可以切换 30 / 90 / 180 天。

## 同组基准

费用支出画像必须和可比人群比较，不能全公司一刀切。

建议同组口径：

```text
peer_group =
  department_id
+ position
+ grade
+ expense_type_scope
+ city_tier
+ project_type
+ window_days
```

当某个同组样本量不足时，逐级回退：

```text
部门 + 岗位 + 费用类型
→ 部门 + 费用类型
→ 岗位 + 费用类型
→ 公司 + 费用类型
```

回退必须写入 `peer_group_fallback_level`，避免审核者误以为基准非常精确。

## 分值模型

### 不建议使用一个大总分

不要这样计算：

```text
综合风险分 = 费用金额 + Token 消耗 + 操作时长 + 审核时长 + 退单次数
```

原因：

- Token 高可能代表高频使用 AI，不代表费用风险。
- 审核时长是审批人的行为，不是申请人的费用风险。
- 退单次数可能代表材料质量问题，不一定代表费用不合理。
- 一个总分会掩盖到底是哪一类风险触发。

### 建议使用多维分

```text
employee_behavior_profile =
  expense_profile_score
  process_quality_score
  ai_usage_score
  approval_behavior_score
```

每个分值都有自己的等级：

```text
0-39   normal
40-59  watch
60-79  review
80-100 escalation
```

审批详情页只展示与当前场景相关的分值：

```text
费用申请审批：
  展示 expense_profile_score
  展示 process_quality_score
  隐藏或弱化 ai_usage_score
  不展示 approval_behavior_score

运营看板：
  展示四类分值和趋势
```

## 指标权重建议

### 费用支出画像分

```text
expense_profile_score =
  frequency_score * 20%
+ amount_occupancy_score * 25%
+ peer_deviation_score * 25%
+ adjustment_history_score * 15%
+ current_claim_deviation_score * 15%
```

### 流程质量画像分

```text
process_quality_score =
  return_count_score * 25%
+ missing_attachment_score * 20%
+ invoice_mismatch_score * 20%
+ resubmit_duration_score * 15%
+ missing_business_context_score * 20%
```

### AI 协作画像分

AI 协作分不命名为风险分，建议叫 `ai_usage_intensity_score`。

```text
ai_usage_intensity_score =
  ai_call_count_score * 25%
+ token_cost_score * 25%
+ ai_generated_claim_ratio_score * 20%
+ ai_suggestion_override_score * 20%
+ failed_ai_call_score * 10%
```

含义：

- 分数高代表 AI 使用强度高或成本高。
- 不代表员工费用风险高。
- 主要用于成本治理、流程优化和模型配置。

### 审批行为画像分

审批行为分不命名为风险分，建议叫 `approval_behavior_score`。

```text
approval_behavior_score =
  avg_review_duration_score * 20%
+ sla_overdue_score * 20%
+ direct_approve_ratio_score * 20%
+ high_risk_approve_score * 20%
+ system_advice_override_score * 20%
```

含义：

- 分数高代表审批行为需要运营关注。
- 不直接代表审批人存在问题。
- 必须结合审批量、单据复杂度和部门业务特性解释。

## 数据来源

### 费用与流程数据

主要来源：

- `expense_claims`
- `expense_claim_items`
- 审批流转记录
- 退回 / 调减 / 补充材料记录
- 预算池和预算交易记录

需要补齐或确认的数据：

- 审批开始时间。
- 审批完成时间。
- 退回原因结构化字段。
- 调减前后金额。
- 补充材料事件。
- 审批意见是否为空。

### AI 与工具调用数据

主要来源：

- `AgentRun`
- `AgentToolCall`
- `SemanticParseLog`
- `runtime_chat.py`
- `ontology.py`
- `user_agent.py`
- `ocr.py`

需要注意：

不是所有模型入口都已经完整持久化 Token。第一版必须区分：

```text
exact_token_count：真实记录的 Token
estimated_token_count：按文本长度估算
unavailable：当前不可用
```

不能把估算值包装成真实计费数据。

## 存储设计

建议第一版使用通用画像快照表：

```text
employee_behavior_profile_snapshots
```

字段建议：

```text
id
subject_type                 applicant / approver / employee
subject_id                   employee_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
profile_level
metrics_json
basis_codes_json
source_task_type
source_task_log_id
calculated_at
created_at
```

### 为什么用快照表

不要把画像直接写入员工表：

```text
employee.profile_score = 80
```

原因：

- 员工表是主数据，画像是动态计算结果。
- 审批审计需要知道当时为什么是这个分。
- 算法规则调整后，历史依据不能被覆盖。
- 快照可以支持趋势分析。

### 是否每个员工都存

不建议全员每天存。

第一版只存：

- 近 90 / 180 天有费用申请记录的员工。
- 当前存在待审批申请的员工。
- 上一期画像等级为 `watch`、`review`、`escalation` 的员工。
- AI 使用或审批行为达到运营关注阈值的员工。

无行为员工不生成画像快照。

## Hermes 调度策略

不重新写调度器，复用 Hermes 现有 cron 调度体系。

建议新增任务类型：

```text
employee_behavior_profile_scan
```

任务职责：

```text
1. 识别本次需要刷新画像的员工集合。
2. 聚合费用、流程、AI、审批行为指标。
3. 调用各画像子算法。
4. 写入 employee_behavior_profile_snapshots。
5. 在 HermesTaskExecutionLog 写入执行摘要。
```

建议频率：

```text
事件触发：申请提交、审批完成、退回、调减、AI 任务完成后，刷新相关员工。
每日轻量：只扫描昨日新增行为和上一期高关注员工。
每周全量：刷新同组基准、分位数和活跃员工画像。
每月复盘：分析阈值、规则覆盖率和人工覆盖率。
```

## 审批详情展示

费用审批详情页建议展示：

```text
申请人费用画像
流程材料质量
本次申请实时偏离
```

不建议在普通审批详情页直接展示：

```text
Token 消耗
AI 调用成本
审批人行为分
```

这些更适合管理员运营看板。

示例展示：

```text
申请人费用画像
近 90 天 · 销售部 / 客户经理 / 差旅费
状态：重点复核

触发依据：
- 近 90 天差旅金额处于同组 P88。
- 本次出差天数为同类 P75 的 1.67 倍。
- 最近 180 天存在 3 次调减或退回记录。

审核建议：
- 建议确认本次 5 天行程是否可压缩至 4 天。
- 如确属关键客户推进，请补充客户拜访安排和预期产出。
```

## 运营看板展示

管理员或运营人员可以看到更完整的画像：

```text
员工画像总览
├── 费用支出关注榜
├── 流程质量待优化榜
├── AI 使用强度榜
├── Token 成本趋势
├── 审批效率与积压
└── 系统建议采纳率
```

运营看板要标明：

- 哪些指标是真实采集。
- 哪些指标是估算。
- 哪些指标当前不可用。

## 第一版落地边界

第一版建议先做：

1. 费用支出画像。
2. 流程质量画像。
3. AI 协作画像的数据口径定义。
4. 通用快照表。
5. Hermes 画像扫描任务。

暂不做：

- 自动处罚或自动降标。
- 将 AI Token 消耗纳入费用风险分。
- 用 LLM 直接判断员工是否异常。
- 全员每日全量画像。

## 后续演进

### 第二阶段

- 接入审批详情页“申请人费用画像”卡片。
- 接入 Hermes 数字员工日志。
- 支持画像快照趋势对比。
- 支持规则中心根据高频触发指标生成规则草稿。

### 第三阶段

- 引入更稳定的同组基准缓存。
- 引入审批建议采纳率。
- 对 AI 使用成本做部门和功能维度分摊。
- 将画像结果接入运营看板。

### 第四阶段

- 根据真实历史数据调整权重。
- 对高覆盖、高误报规则做自动复盘。
- 让 Hermes 输出月度费用治理建议，但仍不直接改线上规则。

