封面图：RAG 低置信度决策系统根据证据质量、风险等级和用户意图选择回答、追问、拒答或转人工

系列：生产级 LLM 应用方法论 08
日期：2026-06-22
适合读者：正在建设企业知识库问答、客服助手、内部合规助手、研究助理或高风险 Agent 的工程师、产品负责人和技术负责人。

摘要

第七篇讲了混合检索与重排：如何把关键词检索、向量检索、融合排序和 reranker 组合成一个可评测的排序闭环。

但即使检索链路做得不错，RAG 仍然会遇到一个更关键的问题：什么时候不应该直接回答？

很多系统把“拒答”当成 prompt 里的最后一句话：

如果不知道，请说不知道。

这句话有用，但远远不够。生产系统真正需要的是一个低置信度决策层。它要读取检索结果、证据支持度、证据冲突、权限、版本、风险等级、用户意图完整度和工具状态，然后在四个动作之间做选择：

answer      证据足够，直接回答
clarify     信息缺失，先追问
abstain     证据不足或不允许回答，明确拒答
handoff     高风险或需要人工判断，转人工/转流程

这篇文章给出一套可落地的低置信度与拒答策略：置信度信号怎么定义、证据不足和证据冲突怎么区分、追问要问什么、拒答怎么写、哪些场景必须转人工、如何用结构化输出承载决策、怎样评测“少错答”和“不过度拒答”的平衡。

目录

1. 目标不是少拒答，而是少错答

很多团队上线 RAG 后，会把“拒答率”当成负指标：拒答越少越好。

这很危险。

如果系统在证据不足时仍然回答，用户看到的是一个流畅但不可靠的答案。短期看拒答率下降，长期看信任会被消耗。客服系统会带来错误承诺，合规系统会给出错误解释，研究助理会把不存在的结论写进报告，内部 Agent 可能触发错误操作。

生产 RAG 的目标不是“永远给出答案”，而是：

在证据足够时回答；
在信息缺失时追问；
在证据不足或不允许时拒答；
在高风险或需要判断时转人工。

这四个动作都应该被视为成功路径。拒答不是失败，错误回答才是失败。追问不是拖延，它是在补齐必要条件。转人工不是能力不足，它是风险边界的一部分。

1.1 一个典型事故

用户问：

企业客户提前取消年付套餐，是否可以退还剩余月份费用？

知识库里有三条证据：

证据 A：个人用户可以在取消后按剩余自然月退还未使用费用。
证据 B：企业客户合同以主协议为准，退款条款可能在补充协议中单独约定。
证据 C：2025 版企业客户政策已废止，2026 版政策未明确说明提前取消退款规则。

如果系统回答：

可以，企业客户提前取消后可按剩余月份退款。

这就是把个人用户规则误用到企业客户。看似有证据，实则证据不支持结论。

更合适的动作是：

我不能仅凭当前知识库确认企业客户提前取消年付套餐是否可退款。现有资料显示企业客户退款以主协议或补充协议为准，而当前检索结果没有找到该客户协议中的退款条款。请提供合同编号或协议条款；如果这是正式客户承诺，建议转财务/法务确认。

这个回答没有炫技，但它可信。

2. 四种动作：回答、追问、拒答、转人工

RAG 的低置信度层可以先把输出动作限定为四类。

动作 适用情况 用户体验目标
answer 证据充分、无关键冲突、风险可控 给出简洁回答，并引用证据
clarify 缺少必要条件，补一个信息就能判断 问一个最小必要问题
abstain 知识库没有足够证据，或系统不允许回答 明确边界，不编造
handoff 高风险、需人工审批、需访问外部系统或判断责任 把问题交给正确流程

这四类动作应该是系统契约，而不是自然语言风格。

推荐在生成最终用户回复之前，先生成一个内部决策对象：

{
  "action": "clarify",
  "confidence": 0.58,
  "risk_level": "medium",
  "evidence_status": "partial",
  "missing_information": ["customer_type", "contract_version"],
  "reason": "The retrieved policy distinguishes personal and enterprise customers, but the user did not specify the contract type.",
  "allowed_to_answer": true
}

只有当 action=answer 时，系统才进入正常答案生成。其他动作进入不同的回复模板或工作流。

3. 低置信度不是一个分数，而是一组信号

很多系统只用一个检索分数作为置信度。例如 reranker score 大于 0.8 就回答，小于 0.5 就拒答。

这个做法太粗。

低置信度至少来自六类信号。

3.1 检索信号

信号 含义
top_score 最高候选分数
score_margin 第一名和第二名差距
recall_count 过阈值候选数量
direct_support_count 被 reranker 判为直接支持的证据数
query_rewrite_drift 改写 query 是否偏离原问题
source_diversity 是否多个来源都支持同一结论

OpenAI Retrieval 文档中提到，score_threshold 可以限制返回更相关的 chunk，但阈值提高也可能排除有用内容。这个提醒很重要：阈值不是越高越好，必须结合召回率、错答率和拒答率一起调。

3.2 证据信号

信号 含义
support_type direct、partial、background、conflicting、irrelevant
citation_coverage 答案关键结论是否都有引用
missing_conditions 是否缺少适用条件
version_status active、deprecated、draft、unknown
freshness 是否超过有效期
locator_quality 引用是否能定位到页码、章节、span

证据不是“相关文本”。证据必须能支持一个具体结论。

3.3 用户意图信号

信号 含义
intent_type 事实、规则、流程、建议、操作、创作
required_slots 判断所需条件是否齐全
ambiguity 用户问题是否有多种解释
user_role 用户身份是否影响答案
time_scope 是否需要明确时间范围

例如“能不能退款？”这个问题必须知道订单类型、用户类型、支付渠道、政策版本、是否超过期限。缺一个关键条件，就应该追问或给条件化答案。

3.4 风险信号

风险 示例
法务风险 合同义务、赔偿、合规解释
财务风险 退款金额、税务处理、发票冲红
医疗风险 诊断、用药、检验解释
安全风险 危险操作、权限绕过
隐私风险 个人数据、客户信息、内部资料
操作风险 会触发真实系统状态变化

同样的证据质量，在不同风险等级下应该有不同动作。低风险 FAQ 可以给保守答案；高风险合规问题即使有部分证据，也可能需要转人工。

3.5 工具状态信号

信号 含义
retrieval_status 检索是否成功
index_freshness 索引是否刚同步
tool_timeout 工具是否超时
permission_check 权限检查是否成功
source_availability 原文是否可打开

工具失败不能伪装成知识不存在。检索超时、索引未同步、权限服务失败，应当明确降级，而不是让模型自由发挥。

3.6 答案一致性信号

信号 含义
self_check_passed 答案是否能逐句映射到证据
claim_count 答案里有多少独立声明
unsupported_claim_count 多少声明没有证据
conflict_count 多少证据互相冲突
policy_violation 是否触发内部规则

最终答案生成后，还要做一次证据对齐检查。很多错答不是检索失败，而是模型在生成阶段多说了一句没有证据的话。

4. Evidence Confidence 与 Answer Confidence

建议把置信度拆成两层：

Evidence Confidence：检索到的证据是否足够支持问题？
Answer Confidence：生成出来的答案是否忠实于证据？

这两个分数不能混在一起。

4.1 Evidence Confidence

Evidence confidence 关注检索和证据本身。

可以考虑：

  • 是否有直接支持证据；
  • 直接证据数量；
  • 证据是否来自 active 版本；
  • 是否存在冲突证据；
  • 是否缺少关键条件；
  • 引用定位是否可核查；
  • 证据是否覆盖所有子问题；
  • 检索工具是否成功。

4.2 Answer Confidence

Answer confidence 关注生成结果。

可以考虑：

  • 答案每个关键声明是否有证据；
  • 是否把 partial 证据写成确定结论；
  • 是否忽略了适用条件；
  • 是否把旧版本写成当前规则；
  • 是否在引用之外补充了事实；
  • 是否遵守拒答/转人工策略；
  • 是否把不确定性表达清楚。

很多团队只做第一层，导致检索证据明明是 partial，答案却写成 direct。真正上线时，两层都要做。

5. 决策矩阵：从信号到动作

下面是一张实用的动作矩阵。

条件 推荐动作 示例
有 direct evidence，无冲突，风险低/中 answer 政策 FAQ、流程说明
有 direct evidence，但风险高 answer with caveat 或 handoff 合同、财务、医疗
只有 partial evidence，缺少关键 slot clarify 缺订单类型、时间、版本
只有 background evidence abstain 或 clarify 找到背景材料但没有规则
evidence conflicting abstain 或 handoff 两个 active 文档冲突
evidence deprecated abstain，提示版本问题 只命中过期政策
retrieval failed abstain with system limitation 检索服务超时
permission unknown abstain 权限服务失败
user asks for action requiring approval handoff 退款、删除数据、改合同
safety/compliance policy triggered abstain 或 handoff 不允许生成的请求

可以把矩阵变成显式 policy，而不是藏在 prompt 里。

5.1 一个简化决策树

1. 请求是否允许处理？
   no  -> abstain
2. 权限和工具状态是否正常？
   no  -> abstain or retry
3. 是否缺少必要条件？
   yes -> clarify
4. 是否有直接证据支持？
   no  -> abstain
5. 是否存在关键冲突？
   yes -> handoff or abstain
6. 风险是否高到需要人工判断？
   yes -> handoff
7. 否则 answer

注意顺序。不要先问模型“你有多确定”，再去查权限。权限、政策、安全边界应该先判断。

6. 什么时候应该追问

追问适用于“补一个或少数信息就能回答”的情况。

6.1 追问的好场景

场景 为什么追问
缺少用户类型 个人和企业规则不同
缺少产品线 不同产品政策不同
缺少时间范围 政策版本按日期变化
缺少地区 法规或运营规则不同
缺少订单状态 待支付、已发货、已完成不同
缺少目标 用户问“怎么处理”，但没有说目标

例如：

用户：这个订单可以退款吗？
系统：我需要确认两个信息才能判断：这是个人订单还是企业合同订单？订单当前是未发货、已发货还是已完成？

6.2 追问要少而准

追问最常见的问题是一次问太多。

坏例子：

请提供订单号、用户类型、支付方式、订单状态、购买时间、所在地区、合同版本、产品线和退款原因。

好例子：

请先确认订单类型：这是个人订单还是企业合同订单？这会决定适用哪套退款规则。

追问的目标不是收集所有信息，而是获取当前决策最关键的缺口。

6.3 可以给条件化回答，但要标清边界

有些时候，追问之前可以先给条件化框架：

如果这是个人订单，当前政策通常按剩余未使用月份计算退款；如果这是企业合同订单，需要以主协议或补充协议为准。请确认订单类型，我再给你对应规则。

这种回答比直接拒答更有帮助，也比无条件回答更安全。

7. 什么时候应该拒答

拒答适用于“当前系统不应回答或无法可靠回答”的情况。

7.1 证据不足

如果检索结果没有直接证据，系统应该明确说：

我没有在当前知识库中找到能支持这个结论的资料。

不要写：

根据常识，可能是……

RAG 系统的价值在于基于证据回答。没有证据时，常识猜测应该被明确降级。

7.2 证据冲突

如果两个 active 来源冲突，不要擅自选择一个。

我找到了两条互相冲突的现行资料：A 文档说企业客户需按主协议处理，B 文档说可按剩余月份退款。当前无法判断哪条优先级更高，建议由财务或法务确认。

这里的关键是暴露冲突，而不是把冲突藏起来。

7.3 版本不确定

只命中过期文档时，不能把它当成当前规则。

我只找到了 2025 版已废止政策，没有找到当前有效版本。不能据此确认现在的处理规则。

7.4 权限不足或隐私风险

用户无权访问材料时，拒答不应泄漏材料存在与内容。

我无法访问或确认你有权限查看相关资料，因此不能回答这个问题。

不要说：

有一份内部法务备忘录提到了这个条款，但你无权查看。

7.5 安全或合规不允许

这类拒答不是低置信度，而是明确不允许。语气要简洁，不要提供绕过路径。

8. 什么时候应该转人工

转人工适用于“系统可以发现问题，但不应该独自完成判断或承诺”的情况。

8.1 高风险业务承诺

例如：

  • 是否承诺客户退款；
  • 是否解除合同责任；
  • 是否给出法律解释；
  • 是否对医疗检查作诊断；
  • 是否批准高额补偿；
  • 是否修改用户权限；
  • 是否删除或导出敏感数据。

这些场景即使有证据，也可能需要人工审批。

8.2 证据冲突但业务必须继续

有些问题不能只拒答，因为用户需要流程推进。系统应该转人工，并携带证据包。

{
  "handoff_to": "finance_ops",
  "reason": "conflicting_active_policy",
  "evidence": [
    {"source_id": "enterprise_refund_policy_2026", "claim": "enterprise refunds follow master agreement"},
    {"source_id": "billing_faq_2026", "claim": "annual plans may refund remaining months"}
  ],
  "user_question": "企业客户提前取消年付套餐是否可退费？"
}

人工接手时最讨厌从头看对话。系统应该把问题、候选证据、冲突点、用户缺失信息和已做判断打包过去。

8.3 HITL 不是兜底，而是产品流程

OpenAI 的应用开发资料也强调，guardrails 和 evals 是生产级可信系统的基础，高风险或低置信度输出应当引入 Human-in-the-Loop。这里的重点不是“让人工修模型”，而是让产品有明确责任边界。

9. 用结构化输出承载决策

低置信度策略不应该只靠模型生成一段自然语言。推荐先生成结构化决策，再由模板或受控生成器转成用户回复。

OpenAI Structured Outputs 文档强调，结构化输出可以帮助应用拿到符合 JSON Schema 的结果，并且安全拒答可以被程序化检测。这个能力很适合承载 RAG 的内部决策。

9.1 决策 schema

{
  "type": "object",
  "additionalProperties": false,
  "required": [
    "action",
    "confidence",
    "risk_level",
    "evidence_status",
    "missing_information",
    "conflicts",
    "answer_policy",
    "user_message"
  ],
  "properties": {
    "action": {
      "type": "string",
      "enum": ["answer", "clarify", "abstain", "handoff"]
    },
    "confidence": {
      "type": "number",
      "minimum": 0,
      "maximum": 1
    },
    "risk_level": {
      "type": "string",
      "enum": ["low", "medium", "high", "critical"]
    },
    "evidence_status": {
      "type": "string",
      "enum": ["direct", "partial", "background", "conflicting", "missing"]
    },
    "missing_information": {
      "type": "array",
      "items": {"type": "string"}
    },
    "conflicts": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["source_a", "source_b", "issue"],
        "properties": {
          "source_a": {"type": "string"},
          "source_b": {"type": "string"},
          "issue": {"type": "string"}
        }
      }
    },
    "answer_policy": {
      "type": "object",
      "required": ["can_answer", "must_cite", "must_handoff"],
      "properties": {
        "can_answer": {"type": "boolean"},
        "must_cite": {"type": "boolean"},
        "must_handoff": {"type": "boolean"}
      }
    },
    "user_message": {
      "type": "string"
    }
  }
}

9.2 为什么要结构化

结构化决策有几个好处：

  • 产品可以统计 action 分布；
  • 工程可以按 action 走不同流程；
  • 评测可以直接判断动作是否正确；
  • 高风险场景可以强制 handoff；
  • UI 可以展示追问或转人工状态；
  • 日志可以复盘每次拒答原因；
  • 不同模型版本可以做 A/B 对比。

自然语言答案是给用户看的，结构化决策是给系统看的。两者不要混在一起。

10. 一个最小低置信度策略引擎

下面是一个简化版策略引擎。真实系统里，分数来自检索器、reranker、证据校验器、风险分类器和权限服务。

from dataclasses import dataclass
from typing import List, Literal


Action = Literal["answer", "clarify", "abstain", "handoff"]
EvidenceStatus = Literal["direct", "partial", "background", "conflicting", "missing"]
RiskLevel = Literal["low", "medium", "high", "critical"]


@dataclass
class RagSignals:
    evidence_status: EvidenceStatus
    top_score: float
    direct_support_count: int
    conflict_count: int
    missing_slots: List[str]
    risk_level: RiskLevel
    retrieval_ok: bool
    permission_ok: bool
    active_version_only: bool
    unsupported_claim_count: int


@dataclass
class Decision:
    action: Action
    confidence: float
    reason: str
    missing_information: List[str]


def decide(signals: RagSignals) -> Decision:
    if not signals.permission_ok:
        return Decision(
            action="abstain",
            confidence=0.0,
            reason="Permission check failed or user lacks access.",
            missing_information=[],
        )

    if not signals.retrieval_ok:
        return Decision(
            action="abstain",
            confidence=0.1,
            reason="Retrieval failed, so absence of evidence cannot be trusted.",
            missing_information=[],
        )

    if signals.risk_level == "critical":
        return Decision(
            action="handoff",
            confidence=0.4,
            reason="Critical-risk request requires human review.",
            missing_information=signals.missing_slots,
        )

    if signals.missing_slots:
        return Decision(
            action="clarify",
            confidence=0.5,
            reason="Required information is missing.",
            missing_information=signals.missing_slots[:2],
        )

    if signals.conflict_count > 0 or signals.evidence_status == "conflicting":
        action: Action = "handoff" if signals.risk_level in ["high", "critical"] else "abstain"
        return Decision(
            action=action,
            confidence=0.35,
            reason="Retrieved evidence contains unresolved conflicts.",
            missing_information=[],
        )

    if not signals.active_version_only:
        return Decision(
            action="abstain",
            confidence=0.3,
            reason="Only deprecated or uncertain-version evidence was found.",
            missing_information=[],
        )

    if signals.evidence_status != "direct" or signals.direct_support_count == 0:
        return Decision(
            action="abstain",
            confidence=min(signals.top_score, 0.45),
            reason="No direct evidence supports the requested conclusion.",
            missing_information=[],
        )

    if signals.unsupported_claim_count > 0:
        return Decision(
            action="abstain",
            confidence=0.55,
            reason="Draft answer contains claims not supported by retrieved evidence.",
            missing_information=[],
        )

    if signals.risk_level == "high" and signals.direct_support_count < 2:
        return Decision(
            action="handoff",
            confidence=0.65,
            reason="High-risk answer needs stronger support or human approval.",
            missing_information=[],
        )

    return Decision(
        action="answer",
        confidence=max(signals.top_score, 0.75),
        reason="Direct active evidence supports the answer and no blocking risk was detected.",
        missing_information=[],
    )

这个策略引擎有几个特点：

  • 权限和工具状态先于模型置信度；
  • 缺 slot 时优先追问；
  • 证据冲突不强行选择；
  • 旧版本证据不会被当作现行规则；
  • 高风险问题需要更强证据或人工；
  • 生成后的 unsupported claims 会阻止答案输出。

真正上线时，可以把这些规则配置化，并按业务线设置不同阈值。

11. 回答、追问、拒答的文案模板

策略层决定动作，文案层决定用户体验。

11.1 answer 模板

适合证据充分时：

可以。根据《退款政策 2026-03》第 4.2 节，命中 E7782 的订单必须进入人工审核，不得自动退款。审核完成后，退款通常在 1-5 个工作日内退回原支付渠道。

要点：

  • 先回答结论；
  • 明确条件；
  • 引用来源；
  • 不扩展证据外内容。

11.2 clarify 模板

适合缺少必要条件时：

我需要先确认一个条件：这是个人订单还是企业合同订单？当前资料显示两类订单适用的退款规则不同。

要点：

  • 只问最关键缺口；
  • 说明为什么需要这个信息；
  • 不把用户推回复杂表单。

11.3 abstain 模板

适合证据不足时：

我不能根据当前知识库确认这个结论。检索结果只包含个人订单退款规则，没有找到企业合同订单提前取消时的退款条款。

要点：

  • 明确不能回答什么；
  • 说明原因；
  • 不编造替代答案；
  • 如可能，给出下一步。

11.4 handoff 模板

适合高风险或人工审批时：

这个问题涉及企业合同退款承诺，需要财务或法务确认。我已整理出相关资料：当前政策说明企业客户以主协议为准，但知识库没有找到该客户合同的具体退款条款。建议转财务运营处理。

要点：

  • 说明为什么转人工；
  • 带上已经找到的证据；
  • 不让用户重复提供信息；
  • 给出明确流转对象。

12. 如何评测拒答策略是否有效

低置信度策略必须评测，否则很容易走向两个极端：

  • 过度自信：错答少量但严重；
  • 过度保守：大量可答问题被拒答。

12.1 样本集设计

评测集至少包含这些桶：

样本桶 期望动作
证据充分的普通问题 answer
缺少关键条件的问题 clarify
知识库没有答案的问题 abstain
只有背景证据的问题 abstain
证据互相冲突的问题 abstain 或 handoff
只有旧版本证据的问题 abstain
高风险但有部分证据的问题 handoff
权限不足的问题 abstain
检索工具失败模拟 abstain with system limitation
用户恶意或不允许请求 abstain

12.2 指标

指标 含义
Action Accuracy 动作是否选对
Unsafe Answer Rate 应拒答/转人工却回答的比例
Over-Abstain Rate 应回答却拒答的比例
Clarification Precision 追问是否问到关键缺口
Handoff Precision 转人工是否真的必要
Evidence Support Rate answer 中关键声明是否有证据
Conflict Detection Rate 冲突证据是否被识别
Version Safety Rate 旧版本是否被正确拦截
User Resolution Rate 用户最终是否解决问题

12.3 成本函数

不同错误的成本不同。

错误 成本
应拒答却回答 最高
应转人工却回答 最高
应追问却回答 高
应回答却拒答 中
应回答却追问 低中
应拒答却转人工 中

评测时不要只算平均准确率。一个医疗、法务或财务系统里，少量错误回答的成本可能远高于大量保守拒答。

13. 线上观测与事故复盘

每次 RAG 请求都应该记录低置信度决策信号。

推荐日志字段：

{
  "request_id": "req_20260622_001",
  "query": "企业客户提前取消年付套餐可以退款吗？",
  "action": "handoff",
  "confidence": 0.62,
  "risk_level": "high",
  "evidence_status": "partial",
  "top_score": 0.81,
  "direct_support_count": 0,
  "conflict_count": 0,
  "missing_slots": ["contract_id"],
  "retrieval_strategy": "hybrid_rrf_rerank_v3",
  "answer_policy_version": "confidence_policy_v2",
  "handoff_team": "finance_ops",
  "created_at": "2026-06-22T12:40:32+08:00"
}

线上复盘时要回答五个问题：

  1. 正确证据是否进入候选池？
  2. reranker 是否把正确证据排到前面？
  3. 决策层是否正确识别证据状态？
  4. 生成答案是否忠实于证据？
  5. 用户反馈是否说明动作选择不合适？

没有这些日志，团队只能靠猜。

14. 生产架构建议

低置信度层可以放在检索和生成之间，也可以在生成后再做一次校验。

User Query
  -> Input Guardrails
  -> Query Analyzer
  -> Retrieval and Reranking
  -> Evidence Classifier
  -> Risk Classifier
  -> Confidence Policy Engine
      -> answer  -> Grounded Generation -> Claim Check -> User
      -> clarify -> Clarification Template -> User
      -> abstain -> Refusal Template -> User
      -> handoff -> Handoff Package -> Human Workflow
  -> Logging and Evals

14.1 Evidence Classifier

把候选证据分成：

  • direct
  • partial
  • background
  • conflicting
  • irrelevant

这一步可以用 reranker、规则、LLM judge 或组合方式实现。

14.2 Risk Classifier

把请求按业务风险分级：

  • low：普通知识问答；
  • medium：影响用户操作但不产生承诺；
  • high：财务、法务、医疗、安全、隐私；
  • critical：可能产生不可逆操作或重大责任。

风险分类器不需要完美，但必须偏保守。

14.3 Confidence Policy Engine

这里不建议完全交给生成模型。策略引擎应该由规则、阈值和可审计配置组成。模型可以提供证据理解和分类，但最终动作最好由产品策略控制。

14.4 Claim Check

即使 action 是 answer，生成后也要检查答案中的关键声明是否被证据支持。可以把答案拆成 claims，再逐条验证：

[
  {
    "claim": "命中 E7782 后不得自动退款",
    "support": "supported",
    "citation": "refund_policy_2026_03#sec_4.2"
  },
  {
    "claim": "审核通常需要 1-5 个工作日",
    "support": "supported",
    "citation": "refund_policy_2026_03#sec_4.2"
  }
]

如果出现 unsupported claim，就重写答案或改为 abstain。

15. 常见误区

15.1 误区一：只靠一句 prompt 处理拒答

“不知道就说不知道”是必要但不充分。系统需要结构化信号、动作矩阵、阈值、日志和评测。

15.2 误区二：把低分等同于不能回答

低分可能是检索策略问题，也可能是 query 需要追问。不能简单用低分拒答。

15.3 误区三：把高分等同于可以回答

高分候选可能只是语义相似，不一定支持结论。还要看 direct support、冲突、版本、权限和风险。

15.4 误区四：拒答文案太含糊

坏拒答：

抱歉，我无法回答。

好拒答：

我不能根据当前知识库确认这个结论，因为检索结果没有找到企业合同提前取消的退款条款。

15.5 误区五：追问变成表单

追问应该问最小必要信息，不是把所有字段都扔给用户。

15.6 误区六：转人工不带上下文

没有证据包的转人工会增加人工成本。handoff 必须携带用户问题、系统判断、候选证据、缺失信息和冲突点。

15.7 误区七：只看拒答率

拒答率低可能是好事，也可能是系统在胡答。要同时看 unsafe answer rate、over-abstain rate、clarification precision 和 user resolution rate。

16. 落地路线图

第 1 周：定义动作和日志

  • 把输出动作固定为 answer、clarify、abstain、handoff；
  • 给每次请求记录 action、confidence、risk、evidence status；
  • 梳理高风险业务场景；
  • 定义第一版拒答和追问模板。

第 2 周：建立证据分类

  • 把检索候选分成 direct、partial、background、conflicting、irrelevant；
  • 接入版本和权限状态；
  • 记录 direct support count 和 conflict count；
  • 让最终答案必须引用 direct evidence。

第 3 周：实现策略引擎

  • 把决策矩阵写成可配置规则；
  • 缺 slot 时走 clarify；
  • 冲突、高风险、critical 请求走 handoff；
  • 检索失败、权限失败、旧版本证据走 abstain；
  • 给策略配置加版本号。

第 4 周：建立评测集

  • 人工构造每类动作样本；
  • 加入线上失败样本；
  • 评测 action accuracy、unsafe answer rate、over-abstain rate；
  • 按风险等级和 query 类型分桶。

第 5 周：接入人工流程

  • 设计 handoff package；
  • 对接工单、客服、法务或财务流程；
  • 记录人工最终处理结果；
  • 把人工改判样本回流评测集。

17. 发布前自检清单

动作契约

  • 系统明确支持 answer、clarify、abstain、handoff；
  • 每个动作都有触发条件；
  • 每个动作都有用户可理解的文案；
  • 动作选择写入结构化日志；
  • 策略版本可追踪和回滚。

证据

  • 候选证据有 direct/partial/background/conflicting/irrelevant 分类；
  • 答案关键声明必须有引用；
  • 旧版本证据不会被当成现行规则；
  • 证据冲突会阻止直接回答；
  • 检索失败不会被当成知识不存在。

追问

  • 缺少关键 slot 时优先追问；
  • 每次追问不超过 1-2 个关键问题；
  • 追问说明为什么需要该信息；
  • 能给条件化框架时不空泛拒答；
  • 追问后的上下文能继续使用。

拒答

  • 拒答说明具体边界；
  • 不泄漏用户无权知道的资料；
  • 不在拒答后提供未经证据支持的猜测；
  • 不把安全拒答和低置信度拒答混淆；
  • 拒答样本进入评测集。

转人工

  • 高风险和 critical 场景有 handoff 规则；
  • handoff package 包含证据、缺口和冲突点；
  • 用户不需要重复提供已知信息；
  • 人工处理结果能回写；
  • 人工改判会进入后续评测。

评测

  • 有 answer/clarify/abstain/handoff 四类 gold set；
  • 统计 unsafe answer rate；
  • 统计 over-abstain rate；
  • 按风险等级分桶；
  • 按 query 类型分桶；
  • 策略上线前有 A/B 或回放评测。

18. 总结

RAG 的可信度不只取决于检索和生成，还取决于系统是否知道自己的边界。

低置信度策略的核心不是让模型“谦虚一点”，而是建立一套可执行的决策层：把证据质量、缺失条件、冲突、权限、版本、工具状态和风险等级转成明确动作。能回答就回答，缺条件就追问，证据不足就拒答，高风险就转人工。

一个实用原则是：

不要让生成模型独自决定是否该回答。
让证据、风险和产品策略共同决定。

做到这一点，RAG 系统才不会只是在正确时显得聪明，而是在不确定时依然可靠。

下一篇可以继续写：RAG 的答案生成与上下文打包怎么做：如何把证据转成可靠回答。

参考资料