01 · 管理摘要
核心判断：合并可去除一次历史上下文输入及部分通用规则，但高风险话题具备动态配置、多标签命中、排除边界和高危安全识别等特点。独立 Prompt 在调优、故障隔离和质量追踪上更可控。由于历史仅固定10条，合并带来的真实成本收益必须通过 Gemini 使用量数据和统一评测验证，不能用“2次变1次”推算节省50%。
02 · 业务范围与假设
| 要素 | 现状 / 范围 | 评估影响 |
|---|---|---|
| 模型 | gemini-3.8-flash（由业务方提供的调用标识） | 具体模型能力、Thinking、价格、缓存支持需以实际 API/账单为准 |
| 请求输入 | 最新客户消息1条 + 过去10条历史消息 | 双请求会重复发送这一部分输入；总长度取决于消息实际内容 |
| 历史角色 | customer 与 agent 混合 | 客服消息可解释语境，不可直接作为客户风险证据 |
| 情绪识别 | 0–3级；包含轻微情绪与特定业务升级信号 | 并非纯情感分类；退款/质量故障可触发1级 |
| 高风险识别 | 12个预设话题 + 商家自定义；多话题、priority、排除条件 | 必须动态传入本次启用的 active_topics |
| 业务决策 | 商家情绪阈值 + 高风险启用状态 | 转人工规则建议由后端执行，不让模型直接决定 |
注：模型 ID 按用户提供的系统配置记录，本报告未独立验证该模型标识的官方产品状态或计费价格；所有性能与成本推演均需以实际调用数据复核。
03 · 技术架构对比
方案 B · 分开 Prompt + 并行 推荐基线
当前客户消息 + 最近10条混合消息
Gemini 请求 ①
Gemini 请求 ②
+ active_topics
→ 继续 AI / 转人工
特点：两个请求可独立模型参数、超时、重试、发布和回滚；上下文逻辑在服务端统一维护，但输入 Token 仍分别计量。
方案 C · 合并 Prompt + 单调用 实验候选
+ active_topics
Gemini 请求 ①
同一次调用执行两套独立判定
→ 后端转人工规则
特点：复用上下文与共同约束；但单次输出、复杂指令、不同任务的回归及失效边界需重点验证。
方案 A（两次串行调用）除非存在必须依赖先后结果的理由，否则不建议作为默认方案。
04 · 12个评估维度
| 维度 | 分开并行（B） | 合并调用（C） | 倾向 |
|---|---|---|---|
| 1. API 请求数量 | 2次/客户消息 | 1次/客户消息 | 合并 |
| 2. 输入 Token | 最新消息及历史重复传入 | 上下文只传一次，公共规则可压缩 | 合并 |
| 3. 输出/思考 Token | 两项任务分别生成 | 联合任务可能增加思考消耗 | 实测 |
| 4. 实际费用 | 重复输入，但可分别观察缓存 | 有降本潜力，不保证同等比例降费 | 实测 |
| 5. P95 延迟 | 接近较慢请求+汇总开销 | 一项更复杂的请求，不一定更快 | 实测 |
| 6. 情绪分级质量 | 反讽、0–3级边界独立调优 | 须防业务风险标签影响情绪等级 | 分开可控 |
| 7. 风险话题召回 | 聚焦逐话题触发、排除条件 | 需验证联合任务下多标签漏判 | 分开可控 |
| 8. 多标签与优先级 | 只为高风险任务服务 | 与情绪判断共享一次输出预算 | 分开可控 |
| 9. 自定义话题扩展 | 仅影响风险请求长度 | 使统一 Prompt 更复杂 | 分开 |
| 10. 维护与回归 | 可独立上线、回滚和归因 | 公共约束减少，但每次变更需双任务回归 | 分开 |
| 11. 稳定性与降级 | 一项失败时另一项可能仍可用 | 一次失败可能同时失去两项结果 | 分开 |
| 12. 转人工逻辑 | 后端统一决策 | 后端统一决策 | 持平 |
“分开可控”表示工程上的独立性优势，并不意味着其实际模型准确率必然高于合并；须通过人工标注数据检验。
05 · Token 与成本测算
E=情绪 Prompt Token；R=风险 Prompt Token；M=合并 Prompt Token；H=最新消息与10条历史 Token；T=启用话题规则 Token。
合并输入 ≈ M + H + T
输入节省 ≈ E + R − M + H
示例：假设 Token 预算（非真实监控数据）
| 输入组成 | 分开并行 | 合并调用 |
|---|---|---|
| 情绪 System Prompt | 3,500 | — |
| 风险 System Prompt | 2,800 | — |
| 合并 System Prompt | — | 5,300 |
| 客户消息及10条历史 | 2,000 | 1,000 |
| 启用话题配置 | 2,500 | 2,500 |
| 合计输入 Token | 10,800 | 8,800 |
需要在生产请求日志中记录：promptTokenCount、candidatesTokenCount、thoughtsTokenCount、cachedContentTokenCount、模型标识、请求耗时与账单费用（实际字段依 API 版本确认）。
06 · 识别质量与关键业务边界
| 客户原话（示例） | 情绪等级（现有规则） | 高风险话题 | 测试重点 |
|---|---|---|---|
| I want a refund. | 1 | 无 | 普通退款申请不得自动命中 A3 |
| Your instructions are useless. | 2 | 无 | 明确批评不等于配置话题命中 |
| You deliberately lied to me about this product. | 3 | B5 | 诚信指控在两个任务中分别成立 |
| Someone accessed my account without permission. | 0（无其他负面表态） | A2 | 风险事件不自动增加情绪等级 |
| This product burned my hand. | 1（无其他升级表态） | D2 | 安全事件可在情绪不强时命中 |
| I will report you to the regulator. | 3 | B1 | 正式举报意图独立识别 |
| It's finally resolved, thank you. | 0 | 无（无新风险时） | 不继续沿用历史最高级与旧话题 |
分开方案的主要优势
- 情绪与高风险分别回归，方便精准定位错误。
- A1/A2、B1/B5、C1/C3 等易混话题可专项优化。
- 自定义话题变更不会影响情绪请求的 Prompt 长度。
合并方案必须重点验证
- 同一语义证据不能直接推导另一任务结果。
- 多话题同时命中时不能只返回主话题。
- 3级组合触发条件不能被压缩成宽泛关键词。
- D1/D2/D3 安全风险不得因联合任务而漏判。
07 · 最新消息 + 10条混合历史的上下文策略
推荐结构：current_message + conversation_history[最多10] + risk_context[可选]。无论分开或合并，都应共用这一上下文构建规范。
08 · A/B 验证方案与决策门槛
| 实验组 | 调用架构 | 目的 |
|---|---|---|
| A 组 | 原版双 Prompt 并行 | 建立现状基线 |
| B 组 | 独立 Prompt 精简 + 并行 | 先验证低风险降本 |
| C 组 | 统一 Prompt 单请求 | 量化合并收益和质量变化 |
建议至少500条人工标注会话作为初始离线评测集，包含中性、轻度负面、反讽、明确抱怨、3级升级、12类风险、动态自定义话题、多标签、历史承接、已解决风险、多语言及高危安全案例。安全类须额外构建专项集，不能仅依赖500条综合样本。
| 指标 | 建议验收方式 |
|---|---|
| 情绪分类质量 | 各等级 Precision/Recall、Macro F1；可暂以相比 B 组下降≤1个百分点作为讨论起点 |
| 风险识别质量 | 每话题 Precision/Recall、Micro/Macro F1、完整多标签命中率 |
| 安全风险 | D1/D2/D3 专项召回；已知严重样本不得新增漏判 |
| 业务动作 | 不同商家阈值下转人工漏转率、误转率 |
| 成本 | 实际每条消息费用；建议合并达到 ≥15% 净降费再考虑切换（产品建议阈值） |
| 性能 | P50/P95/P99，超时、重试、吞吐、限流 |
| 可用性 | JSON 结构合法率、类型校验率、任务级失败率；建议结构有效率目标≥99.9% |
所有门槛均为初始评审建议，不是模型厂商承诺；需要由业务方最终确认风险容忍度及具体上线门槛。
09 · 实施路线图与最终决策
建议后端决策表达式
risk_trigger = high_risk_enabled AND (matched_topics.length > 0)
transfer_to_human = emotion_trigger OR risk_trigger
生产环境需补充：模型失败的兜底策略、人工接待可用性、会话状态幂等控制、安全话题特别处理与审计日志。
对当前业务而言，「高风险识别不漏判、情绪误触发可控、规则变更独立」比仅减少一次请求更重要。但若 C 组在关键质量指标保持稳定的前提下显著降低实际费用或延迟，则可以推进合并上线。
10 · 文档依据与说明
- 业务输入：本次讨论中提供的客户情绪识别 System/User Prompt、高风险话题识别 System Prompt、12个预设话题规则、自定义话题规则生成 Prompt、商家灵敏度配置。
- 工程参考：Google Gemini API · Token counting；Google Gemini API · Context caching；Google Gemini API · Structured outputs。
- 本报告中的 Token 示例、验收阈值、预期准确率变化均为分析假设或建议，不代表线上实测结果。