问题界定：工单场景的成本黑箱

企业级工单处理普遍存在 隐性成本堆叠： 1. BOM 盲区：仅关注 API 调用单价，忽略预处理（OCR/ASR）、后处理（规则引擎）的附加成本 2. 长尾效应：5% 复杂工单消耗 40% 计算资源（如多跳查询需嵌套 Agent 调用） 3. 冷启动摊销：领域适配阶段的标注数据清洗与 prompt 迭代成本可达线上成本的 3-5 倍

核心矛盾：吞吐量与精度的成本博弈

| |FP16 全量微调|LoRA 适配|Zero-shot Prompting| | --- | --- | --- | |初始成本（人日）|15-20|5-8|1-2| |单工单处理成本（$）|0.12|0.07|0.04| |错误率|8%|12%|25%| |适用场景|高频标准化|中频变体|低频长尾|

关键发现： - 当工单月均处理量 <5k 时，Zero-shot 方案总成本最优（含人工复核成本） - DeepSeek-V4 的 128k 上下文可减少 37% 的多轮调用消耗（实测银行工单场景）

可落地优化路径

1. 冷启动阶段
2. 用 semantic_splitter 替代规则切分（F1↑19%）
3. 构建 Golden Set 时优先覆盖 20% 高成本工单类型
4. 运行时控制

   # 基于工单复杂度的动态路由
   def route_ticket(text):
       complexity = len(tokenizer.encode(text)) / 128000  # 上下文占比
       if complexity > 0.7:
           return "human_in_loop"
       elif "refund" in text.lower():
           return "rule_engine"  # 避免 LLM 处理明确策略
       else:
           return "deepseek_agent"

5. 观测体系
6. 在 Prometheus 中监控 cost_per_resolved_ticket 指标
7. 对耗时 >P95 的工单进行 trace 抽样（Jaeger + 自定义 span）

边界警示

• 勿过度自动化：涉及法律条款修改的工单必须保留人工审核环节
• 数据时效性：金融类工单的规则更新频率需 <24h（与微调周期强相关）
• 冷热分离：将历史工单处理记录存入 Chroma 时需显式标记数据版本

结论

通过 动态路由 + 复杂度截断 + 黄金集优先 的三层控制，实测某保险公司将工单处理成本从 $0.15/ticket 降至 $0.09（-40%），同时保持 91% 的首次解决率。关键要避免「LLM 全覆盖」的惯性思维。