# X-Financial 预算费用规划推荐模型方案

X-Financial Model Proposal

# 预算费用规划推荐模型方案

这个模型不只是给审批页打一个分，而是把“预算是否够、费用是否合理、是否影响预算节奏、下一步该怎么处理”整理成可解释、可审计、可持续迭代的推荐结果。

规则模型优先 硬约束可审计 LLM 只做解释层 审批反馈可回流
模型主目标 帮预算管理者快速判断是否可承接
Recommend
第一版边界 不替代人工审批，不让 LLM 直接做硬判断
Guarded
核心口径 扣除当前申请已预占，避免重复计算
Traceable
迭代方向 规则评分 + 历史基准 + 解释生成
V1 → V3

## 方案结论

建议把模型定位为“预算审批辅助决策引擎”，输出结构化推荐和解释依据，而不是单纯的页面分数。

Executive Summary
推荐动作
4 类
建议通过、谨慎通过、需要复核、不建议直接通过。
核心评分
100 分
预算安全优先，费用必要性与信息完整度共同影响。
硬性约束
3 条
超预算、强阻断控制、预算池无法匹配必须显式处理。
上线策略
分阶段
先确定性规则，再接入历史基准和解释层。
推荐采用的产品口径： 分数不是结论本身，结论应由“推荐动作 + 风险等级 + 触发依据 + 可执行建议”共同表达。
需要避免的方向： 不要让 LLM 直接判断是否通过，也不要只用一个综合分覆盖预算、业务必要性、历史异常等不同原因。

## 业务闭环

模型要服务完整预算链路：预算池建立、申请预占、审批推荐、报销核销、结果反馈。

Business Loop
1 预算计划建立 按部门、项目、科目、成本中心形成预算池和预警线。
2 费用申请预占 申请提交后先占用预算，避免后续审批期间额度被重复使用。
3 预算审批推荐 预算管理者看到风险等级、计算依据、建议动作和补充要求。
4 报销与核销 申请通过后生成报销草稿，实际报销后转为已核销金额。
5 结果反馈回流 记录审批采纳、驳回原因、实际报销差异，反哺后续规则。

## 模型架构

采用“上下文构建 → 特征计算 → 硬约束判定 → 综合评分 → 推荐解释 → 反馈沉淀”的分层结构。

Model Layers

### 上下文层

统一组装申请单、预算池、历史费用、项目计划和审批身份，形成模型输入快照。

- 复用 `build_claim_budget_context()` 的预算上下文。
- 补充申请事由、地点、费用类型、项目编号、附件摘要。
- 保留计算时刻的预算快照，方便事后审计。

### 特征层

把业务数据转换成可解释特征，而不是直接把原始字段丢给模型。

- 预算容量：审批前可用、审批后使用率、超预算金额。
- 单笔影响：本次金额占预算比例、是否突破预算节奏。
- 必要性证据：事由、项目、地点、附件、业务场景是否完整。
- 历史基准：同部门、同项目、同费用类型的历史均值和波动。

### 决策层

先执行硬规则，再计算综合分，确保强管控场景不会被其他维度“平均掉”。

- 硬规则：超预算、预算池阻断、预算无法匹配、关键字段缺失。
- 综合评分：预算安全、费用影响、规划匹配、历史异常、信息完整。
- 分档输出：recommended、caution、review、block、reference。

### 解释层

第一版直接用模板解释；后续允许 LLM 改写语气，但不能改写分数、等级和硬性结论。

- 解释必须引用结构化依据，不允许凭空补充原因。
- 建议要能变成审批动作，例如补充材料、拆分费用、调整预算。
- 所有展示文案保留对应的 `basis_code`，方便追踪。

## 数据与特征

模型输入需要覆盖“预算是否够”和“费用是否该花”两条线，避免只看额度、不看业务必要性。

Feature Design

### 预算上下文

- `budget_applicable`：是否纳入预算管控。
- `matched`：是否匹配到预算池。
- `total_amount`、`reserved_amount`、`consumed_amount`。
- `current_reserved_amount`：当前申请已预占金额。
- `warning_threshold`、`control_action`。

### 申请单主数据

- 申请金额、费用类型、申请事由。
- 业务地点、项目编号、成本中心。
- 直属领导意见、附件摘要。
- 申请时间、期望发生时间、是否紧急。

### 增强特征

- 同类费用历史均值与分位数。
- 部门剩余预算消耗速度。
- 项目里程碑与预算计划匹配度。
- 申请人近期预算占用频次。

预算容量 单笔影响 预算节奏 业务必要性 历史异常 信息完整度 审批反馈

## 计算口径

申请提交时已经发生预算预占，所以审批分析必须扣除当前申请已预占金额，避免重复计算。

Calculation

    已使用基数 = 已预占金额 + 已核销金额 - 当前申请已预占金额
    审批前可用预算 = 预算总额度 - 已使用基数
    审批后占用 = 已使用基数 + 本次申请金额
    此次费用占预算 = 本次申请金额 / 预算总额度
    审批后使用率 = 审批后占用 / 预算总额度
    超预算金额 = max(本次申请金额 - 审批前可用预算, 0)

关键原则 如果当前申请在提交阶段已经进入 `reserved_amount`，审批页就不能再把它当成新增占用直接叠加。否则预算管理者看到的风险会被放大，尤其是大额申请会明显失真。

## 评分推荐

建议采用“硬规则优先 + 加权评分”的组合。硬规则决定是否必须复核或阻断，评分用于排序和解释风险程度。

Decision Strategy

### 建议权重

- 预算安全：40 分，覆盖可用额度、审批后使用率、超预算金额。
- 单笔影响：18 分，判断本次费用对预算池的冲击。
- 规划匹配：16 分，比较项目计划、预算周期和费用发生时间。
- 历史基准：14 分，识别同类费用异常偏高或频繁占用。
- 信息完整：12 分，衡量事由、项目、地点、附件是否足够。

recommended
85-100
预算充足、信息完整、费用影响可承接，建议通过。
caution
70-84
预算可承接但影响较明显，建议谨慎通过并关注后续节奏。
review
50-69
存在信息缺口、历史异常或接近预警线，需要复核。
block
0-49
超预算或触发强管控动作，不建议直接通过。
硬规则示例： `control_action = block` 且超预算时，直接进入 `block`；预算池未匹配时输出 `reference`，不能伪装成低风险。
推荐动作要具体： 不只写“需关注”，而要给出“补充业务必要性、拆分费用、调整预算池、发起预算调剂”等可执行动作。

## 申请人费用画像公式

画像只用于调整复核强度和审核建议，不能直接把申请人定义为“异常人员”。核心是用同组基准解释个人费用节奏是否偏离。

Applicant Profile

    申请人画像风险分 =
      高频申请分 * 20%
    + 高金额占用分 * 25%
    + 同组偏离分 * 25%
    + 历史调减退回分 * 15%
    + 本次申请偏离分 * 15%

    等级：
    0-39   正常
    40-59  需关注
    60-79  重点复核
    80-100 强复核 / 升级审批

同组基准口径 同组不按全公司粗暴比较，而应按 `部门 + 岗位 + 费用类型 + 城市等级 + 项目类型 + 近 90/180 天` 聚合。销售、项目经理和研发不能混在一个基准池里比较。

### 出差天数建议

    同类基准天数 = peer_group.travel_days_p75
    天数偏离率 = 本次出差天数 / 同类基准天数
    建议天数 = min(
      本次出差天数,
      同类基准天数 + 业务缓冲天数
    )

当偏离率超过 1.5 时，建议补充行程安排或压缩天数；超过 2.0 时进入重点复核。

### 出差费用建议

    本次日均费用 = 本次申请金额 / 本次出差天数
    日均费用偏离率 =
      本次日均费用 / 同城市同职级日均基准
    建议金额上限 =
      建议天数 * 日均基准 * 容忍系数

容忍系数第一版建议使用 1.15 到 1.20，避免模型因为小幅波动给出过硬建议。

### 招待费用建议

    人均招待金额 = 本次招待金额 / 参与人数
    人均偏离率 = 人均招待金额 / 招待标准上限
    同客户招待频率 = 近 90 天同客户招待次数
    个人招待分位 = 个人近 90 天招待金额在同组分位

人均偏离率超过 1.2 时建议调低标准；同客户 90 天内多次招待时要求补充客户推进阶段。

建议生成公式： `审核建议强度 = max(画像风险等级, 本次偏离等级, 硬规则等级)`。展示时必须说明是哪一类指标触发，而不是只给一个结论。
审核建议示例： “该申请人近 90 天费用占用处于同组 P88，本次出差天数为同类 P75 的 1.67 倍。建议将 5 天调整为 4 天，或补充客户拜访安排和项目阶段说明。”

## 输出协议

接口输出需要同时服务审批页展示、看板统计和后续审计，因此自然语言必须和结构化字段分开。

API Contract

    {
      "score": 82,
      "rating": "caution",
      "risk_level": "medium",
      "recommendation": "cautious_approve",
      "summary": "预算整体可承接，但本次费用对预算池已有明显影响。",
      "metrics": {
        "claim_amount": "12000.00",
        "total_amount": "50000.00",
        "available_before_approval": "38000.00",
        "claim_amount_ratio": "24.00",
        "after_usage_rate": "72.00",
        "over_budget_amount": "0.00"
      },
      "applicant_profile": {
        "profile_score": 66,
        "profile_level": "review",
        "peer_percentile": 88,
        "travel_days_ratio": "1.67",
        "daily_cost_ratio": "1.34",
        "suggested_days": 4,
        "suggested_amount_cap": "6800.00"
      },
      "evidence": [
        {
          "basis_code": "budget.after_usage_rate.warning_near",
          "text": "审批后预算使用率为 72.00%，接近预警区间。"
        }
      ],
      "suggested_actions": [
        {
          "action": "approve_with_note",
          "text": "可继续审批，但建议备注本次费用对应的项目阶段和后续预算节奏。"
        }
      ],
      "explainable_snapshot": {
        "budget_no": "BUD-TEST",
        "control_action": "warn",
        "warning_threshold": "80.00"
      }
    }

## 审批展示

预算管理者最需要看到的是“为什么是这个建议”和“如果要通过，还要补什么”。页面不应只展示一个分数。

Approval UX
顶部结论条 展示推荐动作、风险等级、综合分和一句话摘要，例如“谨慎通过：预算可承接，但审批后使用率接近预警线”。
关键指标 本次金额、预算总额、审批前可用、审批后使用率、超预算金额。
触发依据 逐条展示规则依据，保留 basis_code，方便定位到模型逻辑。
建议动作 通过、谨慎通过、补充材料、拆分费用、预算调剂、退回修改。
申请人费用画像 展示近 90 天频率、金额分位、天数偏离率和建议压缩区间，只作为审批参考。
审批反馈 记录预算管理者是否采纳建议，以及不采纳时的原因。

## 落地路线

先把确定性口径做稳，再逐步接入历史基准和解释层，避免第一版就变成难以审计的黑盒。

Implementation

### P0：口径对齐

确认预算预占、审批前可用、审批后占用的计算口径。

- 梳理预算上下文字段。
- 固化不重复计算规则。
- 定义输出协议。

### P1：规则评分

上线可审计的确定性模型，覆盖预算审批主流程。

- 实现特征计算。
- 实现硬规则和分档。
- 补齐单元测试。

### P2：历史基准

引入同类费用历史均值、部门消耗速度和预算节奏。

- 沉淀历史统计任务。
- 增加异常检测特征。
- 看板展示采纳率。

### P3：解释增强

在结构化依据上增加 LLM 文案层，提升可读性。

- LLM 不改分数和等级。
- 解释引用 basis_code。
- 增加人工反馈闭环。

## 验收清单

下面的清单会保存在当前浏览器本地，方便后续评审和开发跟踪。

Checklist
输出协议稳定 评分、等级、推荐动作、指标、依据、建议动作都有结构化字段。 预算预占不重复计算 测试覆盖当前申请已预占、未预占、部分预占三类场景。 硬规则不可被平均抵消 超预算和 block 控制动作必须进入高风险或阻断建议。 审批页展示可解释 预算管理者能看到风险原因、计算指标和可执行下一步。 申请人画像公式可审计 同组基准、偏离率、建议天数、建议金额上限都能追溯到结构化字段。 审批反馈可回流 记录采纳、覆盖、退回、预算调剂等结果，为后续模型迭代准备数据。 LLM 边界清晰 LLM 只改写解释文案，不参与硬性通过、阻断和预算额度计算。