一个"售后助手"被问到"能不能开专用发票"，它答"这个问题我无法回答，请联系相关同事"。用户于是自己找了两轮，最后打了客服电话。而系统里其实有"专票申请流程"的文档——只是"检索没命中"，这个"回流"很常见：拒答被当成"模型能力问题"，而它常常是"检索没命中"——于是"改话术"改不到根上，用户还是得自己找。
于是"回流到了兜底话术"。
"拒答"是必要的安全阀，而它有一个常被忽略的后续：拒答之后"用户去哪"。如果答案是"请联系相关同事"，那这个拒答就只是"把问题退回给用户"。这个"退回"的成本被低估了：用户"再找两轮"的成本，远高于"系统多说一句入口"——而"退回"看起来"很安全"，于是没人改。
1. 三种"拒答"的质量
| 质量 | 表现 |
|---|---|
| 空洞 | "我无法回答"（无出路） |
| 有路径 | "请联系客服 400-xxx" |
| 有路径 + 有原因 | "资料中没有专票流程，可联系财务或看《开票指引》" |
第三项的"额外收益"是"可诊断"："资料中没有"这句话本身就是"知识缺口"的数据——而"我无法回答"什么都没说。
第三项"最有价值"：它同时给了"为什么没有"与"下一步"——于是用户"不必猜是不是系统坏了"。
2. "该拒答"的三种情形
| 情形 | 说明 |
|---|---|
| 资料里确实没有 | 无依据 |
| 资料冲突（两版政策） | 不能替用户选 |
| 超出能力边界（预测/保证） | 不能承诺 |
第二项最容易被"硬答"：模型会把"两版政策"折中成"一个看起来合理的答案"第二项的"危险"在"折中像分析"："一般 7 天内可退（部分情况除外）"读起来像"严谨"——而它既不是"7 天"也不是"拆封不退"。
——而它"既不是 A 也不是 B"。
"依据门槛"要写成"可判定"，否则拒答率会"凭心情":
// 三条"该拒答"的判定（都在代码里）
1 检索命中的 chunk 数为 0 → 拒答
2 命中的 chunk 与我方政策"版本冲突" → 列两种，不合并
3 命中数 ≥ 1 但"都不含问题的主语"（如问"专票"只命中"普票"）→ 拒答 + 出路
// 判据：三条都能"用程序算"，而不是"让模型自己觉得"
3. "转介"的三种设计
| 设计 | 效果 |
|---|---|
| 给"联系方式" | 最弱（用户还要自己描述问题） |
| 给"具体入口 + 关键词" | 中（"去'开票'页面找'专票申请'"） |
| 带"上下文转交"（工单预填） | 最强（用户不用重复描述） |
第三项的"实现"很轻：转人工的链接带一个 session_id，人工点开就能看到"用户问过什么、系统答了什么"——而"没有它"时，人工的第一句永远是"您能再说一遍吗"。
第三项是"体验的分水岭"：把"用户说过的话"一起交给人工——于是"用户不必再说一遍"，而"他说过什么"往往正是"人工需要的第一句话"。
// 一条"可执行"的拒答（四段）
1 结论：资料中没有"专票申请"的具体流程
2 原因：检索到的只有"普票"相关条款（附来源）
3 出路：可在"财务服务"页提交"专票申请"（需税号与开户行）
4 转交：如需人工，点这里（会把本次对话一起带上）
4. "拒答率"该怎么看
| 指标 | 读法 |
|---|---|
| 整体拒答率 | 太低=硬答，太高=能力差 |
| 拒答后"是否继续" | 走了=体验差 |
| 拒答后"转人工率" | 高=知识缺口 |
第三项是"最有指导性"的：拒答集中的主题，就是"该补文档"的清单第三项的"用法"是"每周看拒答 Top 10 的提问"：它们直接对应"文档缺口"或"检索缺口"——而"这两类"的修法完全不同（补文档 vs 加同义词）。
——而它比"满意度评分"更具体。
"转人工"的上下文要"最小但够用"，而不是"整段对话":
// 一个"够用"的转交包（四字段）
question: "能开专用发票吗"
answered: "资料中没有专票流程"（含命中的 2 条来源）
user: {id, 租户, 最近订单}（用于人工判断资格）
session: <id>（可回看完整对话）
// 判据：人工"不用再问用户"就能开始办
5. "拒答话术"的三种写法
| 写法 | 问题 |
|---|---|
| "我无法回答" | 切断对话 |
| "建议咨询专业人士" | 把问题推回用户 |
| "资料中没有 X；可做 Y；如果需要，我可以 Z" | 可执行 |
第三项的"边界"是"别写成三段推脱"："缺什么"要短、"能做什么"要具体、"能帮什么"要是"真的能做的"——否则"三句"只是"更长的推脱"。
第三项的结构是"缺什么 + 能做什么 + 我能帮什么"——三句，但"每一句都往前推一步"。
"明明有资料却拒答"要"先查检索"，而不是"先改话术":
// 三步定位（每次一条）
1 用"文档里的原词"搜：命中 → 检索没问题，问题在"查询表述"
2 用"用户的说法"搜：不命中 → 同义词/改写缺失
3 用"按 ID 查"：不在 → 文档没入库
// 判据：三步走完，才能判断"该改检索还是改话术"
6. 排错：五种"拒答问题"
| 现象 | 成因 | 处理方向 |
|---|---|---|
| 用户反复追问同一问题 | 拒答无出路 | 给入口 |
| 明明有资料却拒答 | 检索未命中 | 修检索/同义词 |
| 两版政策被"折中" | 未检测冲突 | 列两种 |
| 转人工后用户要重说 | 无上下文转交 | 带对话 |
| 拒答率忽高忽低 | 无统一判据 | 定"依据门槛" |
"拒答与推荐"要分清："我不能回答"与"我不建议你做"是两件事。
// 两种"拒绝"的措辞
1 能力边界：资料中没有 X → 给"去哪查/找谁"
2 不建议：这个操作有风险（如"绕过审核"）→ 不给"操作路径"，只说明"为什么不行"
// 判据：拒绝的是"信息缺失"还是"行为不当"
7. 边界：什么情况"不给出路"可以接受
| 场景 | 为什么 | 做法 |
|---|---|---|
| 明显违规请求 | 不应引导 | 直接拒绝 |
| 安全问题（涉密） | 不能指路 | 只说"这件事我不能展开" |
| 用户只是"随口问" | 不需要流程 | 简短拒答 |
| 已有"全局客服入口" | 用户知道去哪 | 可不重复 |
判断口径一句话："用户被拒之后，还知不知道下一步做什么"。最后一条与"度量"有关的边界：**"拒答后是否继续对话"**是最好的单指标——用户"继续追问"说明他还在努力，"直接离开"说明他放弃了；而"放弃"通常发生在"第一次拒答没有出路"时。
不知道（且他"确实需要办这件事"），拒答必须"带出路"；知道（页面到处是入口，或他本来只是好奇），简短拒答更好——因为"每条拒答都塞三个链接"会让回答变噪声。
最后一个"产品"建议：把"拒答"当成"一个功能"，而不是"一个失败"——它有文案、有入口、有指标、有 owner。因为"拒答"是"用户最需要帮助的那一刻"：如果那一刻只得到"我无法回答"，那前面所有"聪明地回答"都白费。而这个视角的转变，通常只需要"给拒答加一条出路"和"加一个统计"，成本一天。
而"那一刻"的体验，恰恰是"用户对系统信任的最后一道门"——它决定他下次还来不来问。
所以拒答的文案，值得和"首页文案"同等对待。
8. 自测
- 三种拒答质量的分界是什么？为什么"有原因"比"只给路径"更好？
- "两版政策"为什么最容易被"硬答"？硬答的结果是什么？
- "带上下文转交"为什么是体验的分水岭？
- "拒答后转人工率"为什么比"满意度"更有指导性？
- "缺什么 + 能做什么 + 我能帮什么"三句各解决什么？
- 判断"拒答是否要给出路"的那个问题是什么？