说明本文讨论的是模型自身拒答行为的工程承接——拒答有哪些形态、怎么定来路、怎么度量、怎么接住属于模型行为承接话题不涉及具体模型版本与价格。AI 领域版本迭代极快凡涉及版本号、价格、可用性请以你阅读时的官方页面为准。文中代码为结构示意请按自己的技术栈调整后再上生产。一、拒答不是一种东西硬拒给的是一个明确的「不」硬拒是指模型明确表达不能协助。它的特征是句子短、语义否定明确、通常不带任何实质内容。对用户来说这是被直接拒绝对工程来说这反而是三种形态里最好处理的一种——它在字符串层面可判定调用返回一次状态码你能立刻知道这一步失败了。硬拒的代价是它不可协商。用户改一个标点、换一个问法拿到的还是同一句话。所以硬拒的正确处置不是再问一遍。软回避最容易被算进「答对了」软回避不说不帮它给一个含糊、泛化、绕开要点的回答。它最麻烦的地方在于形态上完全成功请求返回正常有内容没有报错长度也不短。但它进不了任何失败统计。典型特征有三个句子结构完整却缺少具体名词把具体问题抬升成一般性建议回答里出现了用户问句中的词但没有出现用户要的那个答案。这三种特征里第三条是最好用的判定线索。软回避往下游走的时候是静默的。它不会中断流程只会让结果变空。等到业务方发现最近输出质量在下降通常已经积了一批。带免责的回答内容给了责任留给你带免责的回答是给内容 加限定。前置说明、后置提醒、括号里的适用条件都属于这一类。它是三种里最接近可用的内容往往是对的限定往往也是必要的。风险在下游。如果解析环节只取正文、丢弃限定那么在满足某三个前提时成立会被读成成立。这个错误的成本往往比一次明明白白的硬拒高得多。形态表面表现判定难度用户感受下游影响硬拒明确表示不能协助低字段可判定被直接拒绝流程中断拿到空结果软回避有回答答非所问高形态上成功说了但没用静默进入下游污染结论带免责正文 大量限定中限定容易丢拿到东西但不放心限定条件丢失结论被误用三类里只有硬拒在指标上是干净的。如果你只用成功率看系统状态三种拒答里有两种不会被看见。二、先分清来路四条来路各自留下什么痕迹拒答有四个来源它们的可修改性完全不同。输入触发的规则长度、关键词、附件类型通常在请求进入模型之前就被拦下痕迹在入口日志里。应用侧外挂的校验层它拦在模型输出之后。这类拒答有一个特征——模型返回的原文和最终给用户的内容不一致因为中间被改写或替换过。系统提示里的约束这是你自己写进提示里的禁止项。它在提示文本里是可见的摘掉对应条款就能验证。模型自身的安全对齐这一层在模型内部改不动。它的判定依据是它的训练和对齐结果你只能通过换模型或换问法去对照观察。分清来路的必要性在于外层的规则改一行配置就能动模型侧的对齐你只能接受并设计承接。把模型侧的拒答当成提示问题去反复调提示是这类排查里最常见的时间浪费。判定顺序从最外层往内收判定要按从外到内走因为外层最便宜、验证成本最低。先看输入层规则同一个问题缩短长度、去掉附件再发一次还拒吗再看校验层模型原文和交付内容的差异是否出现在被拒这一步再看系统提示把提示里所有不要 / 禁止 / 仅限类条款临时摘掉还拒吗剩下的归到模型侧同一提示换一家厂商的旗舰模型问同样的话看是否同样被拒。顺序不能反。如果一上来就去改提示、换模型你会同时动三个变量最后拿到一个无法归因的结果。一次最小改动就能定位判定过程中最要紧的纪律是每一步只改一个变量。工程上落地的做法是给每次请求存一份指纹把输入长度、附件类型标志、系统提示版本、校验层版本一起打进去。拒答发生时拿当前指纹和上一次成功的指纹做差差在哪一项就先怀疑哪一项。⚠️ 代码待验证# 定位拒答来路按从外到内的顺序每个变体只改一个变量defprobe(variants):variants: 同一问题的多个改写逐条跑记录是否仍被拒report{}forname,reqinvariants.items():respcall(req)report[name]{blocked:resp.blocked,# 是否被拒form:resp.form,# hard / soft / caveatedguard_hit:resp.guard_hit,# 应用侧校验层是否有拦截记录echo_mismatch:resp.differs,# 模型原文与交付内容是否不同}returnreport# 变体按改动的层从外到内排列命中哪一层就从哪一层往下查VARIANTS{baseline:{},# 原样no_attachment:{drop_attachment:1},# 只去附件 → 查输入层规则shortened:{shrink:1},# 只缩长度 → 查输入层规则prompt_stripped:{drop_prompt_clause:1},# 只摘提示条款 → 查提示}这份探针的价值不在代码本身在于它把改一处、看一处变成了流程而不是靠猜。三、拒答与答错必须分开度量三类指标要并排看拒答和答错不是同一件事在指标上也不能合成一个数。至少要有三类拒答率判为拒答的次数 / 总请求数错答率有回答但内容错 / 有回答的总数无答案率既不是拒答、也没有给出可用答案软回避与限定到不可用的部分/ 总请求数三类的分母不一样这是必须分开的主要原因。把两个不同分母的数放一起算平均算出来的东西没有含义。指标分子分母单独看会漏掉什么拒答率判为拒答的请求总请求完全看不见软回避错答率有回答但内容错有回答的请求看不见拒答造成的空白无答案率无可用答案但未拒答总请求与软回避的边界靠标注确定一个「有效回答率」会把什么藏起来很多系统只统计一个有效回答率把三种失败压成一个数。它的问题不是不精确是方向相反的两次变化会互相抵消。举一个具体的例子安全对齐收紧之后模型在敏感问题上的乱答减少了错答率下降同时它在边界问题上的拒答增加了拒答率上升。这两股力量一叠加有效回答率可能看上去纹丝不动。但用户的体验是明显变差的——原来至少能拿到一个错答案现在直接拿不到东西。反过来也成立一次放宽会让拒答率下降同时把风险从看得见的拒绝搬进看不见的错答里。一个总数看不见这个搬运过程。埋点结构每条回答都要能回溯到分桶想把三类指标算准埋点必须在回答产生的那一刻就带上足够的信息。最少要这几项形态、来路、提示版本、校验层版本、重试次数。⚠️ 代码待验证{request_id:req_2f81,answer_form:soft_avoid,answer_used:false,refusal_source:unresolved,prompt_version:p-2026-09-14,guard_version:g-2026-08-02,retry_count:1,latency_ms:1840,input_flags:[long_doc,no_attachment]}两个字段值得单独说。answer_used记录的是下游到底有没有采用这个回答它靠业务侧回填但它是无答案率能不能算出来的前提。refusal_source允许是unresolved——来路判不出来时记成未定比硬塞一个错误分类强。四、接住它的四种设计改述重试只对特定形态有用改述重试的思路是换一个说法再问一次。它的适用范围比多数人想的窄只对硬拒有用。软回避再问一次通常还是软回避。只对来路是输入层规则或提示措辞的硬拒有用。措辞触发的拒绝换个等义表达确实可能不触发。对模型自身对齐触发的硬拒基本无效。同一件事的不同说法对齐层判的是意图不是字面。改述重试的代价是一次额外调用以及一个副作用它会稀释拒答率。如果一次请求内部重试了三次那么每次请求的拒答率会下降但每次模型调用的拒答率没变。所以在埋点里重试次数必须单独记否则指标会自己骗自己。换路径与降级换的是上下文不是模型换路径重试和改述的区别在于它不动问法动的是输入的组织方式。三种常见做法——把长文档拆成片段分别问、把附件转成纯文本再问、把多轮对话压成一轮再问。它针对的是输入触发规则这一类来路因为长度、附件类型、轮数都是规则能看见的东西。它的代价是需要重新装配一次上下文工程上要保证装配后的输入和原始输入在语义上等价。降级到规则指的是拒答之后不走模型走检索、模板或固定话术。它适合有结构化答案兜底的场景——比如查询类问题答案本来就在库里。它的代价是覆盖面窄而且回答会明显变死板用户能感觉出来。转人工与重试上限转人工是四种里代价最高的一种只在有明确业务价值、且前三种都接不住的时候用。它不适合高频低价值的问句因为排队会变成新的投诉来源。比选哪一种更重要的是上限。一个可用的配置是改述一次、换路径一次、降级一次走完仍然没有可用答案才转人工。⚠️ 代码待验证RETRY_BUDGET{rephrase:1,# 改述重试最多一次reroute:1,# 换路径重试最多一次fallback:1,# 降级到规则最多一次}defhandle_refusal(form:str,source:str,done:dict)-str:# 软回避与带免责的回答不进重试链路它们该走的是质量复核ifform!hard_refusal:returndeliver# 模型自身对齐触发的硬拒重试没有意义直接走升级路径ifsourcemodel_alignment:returnescalateforstep,limitinRETRY_BUDGET.items():ifdone.get(step,0)limit:done[step]done.get(step,0)1returnstepreturnhuman四种承接放一起看取舍是这样分布的承接动作触发条件代价不该用在哪改述重试硬拒来路是输入规则或提示措辞一次额外调用指标被稀释模型自身对齐触发的硬拒换路径重试输入触发规则附件 / 长度 / 轮数需要重新装配上下文输入本身就不合规降级到规则有结构化答案兜底的场景覆盖面窄回答变死板开放性问题转人工有明确业务价值且前三种接不住成本最高有等待高频低价值问句上限的作用不只是控成本它同时保证了一件事拒答率这个指标不会被无限重试拉平。没有上限的重试链路最后会让所有指标都变得不可读。五、过度拒答怎么治提示里给边界示例不给口号过度拒答的成因里最常见的一条是提示写得像口号。“请严格合规”注意安全这类句子对模型没有约束力因为它没有说明边界落在哪里。有效的写法是给成对的边界示例一条是这类可以答一条是这类不答最好再有一条是这种情况该先追问。示例要贴近真实业务问句而不是抽象的类别描述。抽象描述会让模型自己解释边界解释的结果通常偏向谨慎也就是拒得更多。条数要控制。示例太少覆盖不到边界太多会占用上下文并且互相冲突——两条示例如果在同一情形下给出相反的期望模型的输出会变得不稳定。⚠️ 代码待验证boundary_examples:-id:own_order_invoicesay:查询本人名下订单的开票状态expect:answer-id:other_user_ordersay:帮我查一下这个订单号的开票信息# 该订单不属于当前登录账号expect:refuse-id:ambiguous_time_rangesay:上个月的费用明细expect:clarify# 时间范围缺省先追问再答回归集要用真实业务问句判定是不是过度拒答这件事自己编的问句测不出来。原因很简单编的句子不会有真实用户的措辞习惯、错别字、省略和行业黑话而这些恰恰是触发误拒的主要来源。可用的回归集来源是线上抽样。抽出来之后做三件事去掉含个人信息的样本给每条标注期望行为该答 / 该拒 / 该追问按主题分桶保证每个桶里都有一定量。这份集子的标注成本是一次性的之后每次改动都能重复用。两个清单分开维护过度拒答的治理里一个实用的结构是把样本拆成两份清单并行维护。该拒清单不该拒清单样本来源线上被拒且业务确认该拒线上被拒但业务确认可以答期望标注refuseanswer 或 clarify主要指标该拒样本的拒答率不该拒样本的误拒率变更后的期望方向上升或持平下降两份清单必须同时看。只看不该拒那一份你会把所有拒答都当成问题去压只看该拒那一份你会把提示越写越紧最后把可用性压没。这两份清单也是第六章里三条禁忌能不能守住的前提。完整版资料清单本文用到的边界示例写法与回归集清单结构都整理在里面了扫码即可获取六、不该做的三件事拿拒答率当安全指标拒答率只度量一件事模型有没有说不。它度量不了该说不的有没有说。一个系统可以把拒答率做得很漂亮同时在一个该拒的样本上照答不误——因为那部分样本根本没有被拒。反过来把拒答率做低也很容易放宽一点就行代价是风险从可见的拒绝搬进了不可见的错答。真正要盯的是两个带标注的数该拒样本里拒了多少、不该拒样本里误拒了多少。这两个数只有在有期望标注的回归集上才算得出来这也是第五章那两份清单存在的理由。用提示去绕开安全层有一种做法是把安全层的判定当成提示没写好通过反复改措辞、加角色设定、拼接前缀去让本该被拒的内容通过。这条路不推荐本文也不给出任何具体做法。原因有三条都和工程无关、和风险有关第一它不改变模型侧的实际判定只是在你这一条请求上碰巧过了。同样的内容换一次采样、换一个时间再发结果可能就不一样不可复现。第二它把风险从模型层搬到了你的产品层。模型拒了责任边界是清楚的你绕过去交付了责任就在你这边。第三这种做法不可审计。提示里的角色设定和前缀拼接很难在评审里被看出来但它实际改变了系统的行为边界。业务确实需要某项被拒的能力时正路是走合规评审和模型侧配置调整而不是在提示里做文章。这条边界不能靠工程技巧去试探。把拒答一律当故障告警拒答里有一部分是设计意图。把每一次拒答都打成故障告警结果只有一个告警疲劳然后没人再看这个告警。分级是必须的。可行的分法是三档单次拒答只进样本、不告警同一来路的拒答比例在短时间内明显抬升才告警敏感场景下的拒答单独成一条告警链路因为它的容忍度本来就低。分档的依据不是严重程度的主观排序是这条告警出来之后有没有人能立刻做点什么。如果一个告警对应的动作只能是等它就不该是告警。七、观测与迭代拒答样本要有档拒答样本的存档不是把日志留下来就完了。日志里通常只有请求 ID 和响应体缺少判断形态和来路所需要的字段这些字段要在拒答发生的那一刻补齐。⚠️ 代码待验证{refusal_id:rf_00913,input_digest:sha256:...,model_output:……模型返回的原文……,delivered:……最终交付给用户的内容……,form:caveated,source:system_prompt,source_confidence:confirmed,regression_set:real_business_v3,ts:2026-10-13T09:12:0008:00}三个字段是关键。input_digest存摘要而不是明文既能去重、又能避开个人信息的存储问题。model_output和delivered必须分开存——两者不一致本身就是来路是校验层的强证据。source_confidence允许是unresolved来路判不出来时不要硬分类。按来路分桶看趋势拒答率的整体曲线几乎没有行动价值。它上升时你不知道该改提示、该改校验层、还是该接受模型侧的变化。分来路之后每条曲线的动作才明确。分桶的落地顺序是先标置信度高的也就是入口规则直接拦下的、校验层明确记录的、提示摘除后立刻分化的这三类剩下的进unresolved桶定期人工抽样回标。unresolved桶的占比本身就是一个指标——它长期偏高说明你的判定链路还不够用。时间维度上要看的是同来路的比例变化而不是绝对值。因为绝对值和流量结构有关换一批用户就能让它跳一次。回归集接进变更流程观察只能发现变化验证才能确认变化是不是预期内的。这两件事要靠同一份回归集接起来。触发回归的时机有三类系统提示有改动、模型有切换、校验层有调整。这三类改动都会直接改变拒答行为而它们又都不一定会体现在普通的功能测试里——功能测试看的是接口通不通不是该拒的拒没拒。⚠️ 代码待验证# 提示 / 模型 / 校验层发生变更前跑一遍回归集run_regression--setreal_business_v3\--reportmetrics\--splitshould_refuse,should_answer# 只盯两个数# should_refuse 段上的拒答率 —— 变低要查是不是放宽过度# should_answer 段上的误拒率 —— 变高要查是不是提示写紧了这两个数的变化方向是相反的。任何一次改动如果让其中一个变好、另一个变坏都不是一次干净的改动需要人工判断这个交换值不值。把这一步固化进变更流程比事后从线上反馈里倒推要便宜得多。完整版资料清单本文用到的拒答样本存档结构与分桶观测口径都整理在里面了扫码即可获取附表 A关键取舍一览本文涉及的所有工程判断集中在这里方便按需回看。取舍本文结论判断依据位置拒答要不要当成一种失败要但硬拒与软回避分开处理两者在下游的破坏方式不同第一章只用成功率看状态行不行不行软回避与带免责在成功率里是成功的第一章拒答来路的判定顺序从输入层往模型侧收外层最便宜、验证成本最低第二章定位时能不能同时改多个变量不能一次只改一个否则结果无法归因第二章拒答率与错答率能不能合并不能分母不同合并后方向相反的变化会抵消第三章无答案率怎么算靠answer_used回填没有这个字段就算不出来第三章来路判不出来时怎么标记unresolved不硬分类错误分类会污染分桶趋势第三章改述重试用在哪只用于输入规则或提示措辞触发的硬拒模型侧对齐判的是意图第四章重试要不要设上限要每类一次无上限会把拒答率拉平到不可读第四章软回避要不要进重试链路不要走质量复核再问一次通常还是软回避第四章边界怎么给模型给成对示例不给口号口号没有说明边界落在哪第五章回归集样本从哪来线上抽样不用自编问句自编句缺少真实措辞与省略第五章该拒与不该拒清单分开维护同时看只看一份必然把提示写偏第五章拒答率能不能当安全指标不能它只度量说不不度量该说不第六章提示绕过安全层不推荐走合规评审正路不可复现、责任转移、不可审计第六章拒答告警怎么设三档分级单次只进样本全量告警会导致告警疲劳第六章拒答存档存什么模型原文与交付内容分开存两者不一致是校验层拦截的证据第七章趋势怎么切按来路分桶看组内变化总体曲线没有行动价值第七章回归集什么时候跑提示 / 模型 / 校验层变更前这三类改动普通功能测试测不到第七章附表 B术语速查表术语含义硬拒模型明确表示不能协助形态上可判定软回避有回答但答非所问、绕开要点的拒答形态带免责的回答给出内容同时附加大量限定条件的应答无答案率未拒答但未给出可用答案的比例拒答率判为拒答的请求占总请求的比例错答率有回答但内容错误占全部有回答请求的比例来路拒答的实际触发来源分输入规则、校验层、系统提示、模型对齐四类输入触发规则在请求进入模型前按长度、关键词、附件类型等条件拦截的规则应用侧校验层拦在模型输出之后、对结果做筛选或改写的一层系统提示约束提示文本中显式写入的禁止类条款模型自身对齐由模型训练与对齐结果产生的拒答倾向应用侧不可直接修改请求指纹输入长度、附件标志、提示版本、校验层版本等字段的组合改述重试保持意图不变、改变表述后重发一次换路径重试改变输入组织方式拆片段、转纯文本、压轮次后重发降级到规则不走模型改用检索、模板或固定话术应答重试预算每个承接动作允许的最大执行次数该拒清单线上被拒且业务确认应拒的标注样本集合不该拒清单线上被拒但业务确认可答的标注样本集合误拒率在不该拒清单上被拒的比例来路分桶按拒答来源对样本分组统计的做法告警疲劳告警过多导致接收方不再响应的状态写在最后这篇用到的资料写这篇文章时我把几个模型的官方文档、参数表和实测记录都对了一遍顺手整理成几份配套的东西大模型学习路线图从 LLM 基础到 Agent 开发各阶段该学什么、用什么资料大模型全套教程按主题分好的视频与文档清单大模型实战好书24 本附每本适合的阶段资料是我自己整理的放在下面这个码上扫码即可获取添加时备注「大模型」优先通过。拿到之后建议先看学习路线图那一份先定位自己在哪个阶段再决定学什么比一上来就啃框架效率高得多。 
长河君 · 2026/10/14 2:24:37 · 阅读 1.2k 模型拒答之后：从「答不上来」到工程上怎么接
说明本文讨论的是模型自身拒答行为的工程承接——拒答有哪些形态、怎么定来路、怎么度量、怎么接住属于模型行为承接话题不涉及具体模型版本与价格。AI 领域版本迭代极快凡涉及版本号、价格、可用性请以你阅读时的官方页面为准。文中代码为结构示意请按自己的技术栈调整后再上生产。一、拒答不是一种东西硬拒给的是一个明确的「不」硬拒是指模型明确表达不能协助。它的特征是句子短、语义否定明确、通常不带任何实质内容。对用户来说这是被直接拒绝对工程来说这反而是三种形态里最好处理的一种——它在字符串层面可判定调用返回一次状态码你能立刻知道这一步失败了。硬拒的代价是它不可协商。用户改一个标点、换一个问法拿到的还是同一句话。所以硬拒的正确处置不是再问一遍。软回避最容易被算进「答对了」软回避不说不帮它给一个含糊、泛化、绕开要点的回答。它最麻烦的地方在于形态上完全成功请求返回正常有内容没有报错长度也不短。但它进不了任何失败统计。典型特征有三个句子结构完整却缺少具体名词把具体问题抬升成一般性建议回答里出现了用户问句中的词但没有出现用户要的那个答案。这三种特征里第三条是最好用的判定线索。软回避往下游走的时候是静默的。它不会中断流程只会让结果变空。等到业务方发现最近输出质量在下降通常已经积了一批。带免责的回答内容给了责任留给你带免责的回答是给内容 加限定。前置说明、后置提醒、括号里的适用条件都属于这一类。它是三种里最接近可用的内容往往是对的限定往往也是必要的。风险在下游。如果解析环节只取正文、丢弃限定那么在满足某三个前提时成立会被读成成立。这个错误的成本往往比一次明明白白的硬拒高得多。形态表面表现判定难度用户感受下游影响硬拒明确表示不能协助低字段可判定被直接拒绝流程中断拿到空结果软回避有回答答非所问高形态上成功说了但没用静默进入下游污染结论带免责正文 大量限定中限定容易丢拿到东西但不放心限定条件丢失结论被误用三类里只有硬拒在指标上是干净的。如果你只用成功率看系统状态三种拒答里有两种不会被看见。二、先分清来路四条来路各自留下什么痕迹拒答有四个来源它们的可修改性完全不同。输入触发的规则长度、关键词、附件类型通常在请求进入模型之前就被拦下痕迹在入口日志里。应用侧外挂的校验层它拦在模型输出之后。这类拒答有一个特征——模型返回的原文和最终给用户的内容不一致因为中间被改写或替换过。系统提示里的约束这是你自己写进提示里的禁止项。它在提示文本里是可见的摘掉对应条款就能验证。模型自身的安全对齐这一层在模型内部改不动。它的判定依据是它的训练和对齐结果你只能通过换模型或换问法去对照观察。分清来路的必要性在于外层的规则改一行配置就能动模型侧的对齐你只能接受并设计承接。把模型侧的拒答当成提示问题去反复调提示是这类排查里最常见的时间浪费。判定顺序从最外层往内收判定要按从外到内走因为外层最便宜、验证成本最低。先看输入层规则同一个问题缩短长度、去掉附件再发一次还拒吗再看校验层模型原文和交付内容的差异是否出现在被拒这一步再看系统提示把提示里所有不要 / 禁止 / 仅限类条款临时摘掉还拒吗剩下的归到模型侧同一提示换一家厂商的旗舰模型问同样的话看是否同样被拒。顺序不能反。如果一上来就去改提示、换模型你会同时动三个变量最后拿到一个无法归因的结果。一次最小改动就能定位判定过程中最要紧的纪律是每一步只改一个变量。工程上落地的做法是给每次请求存一份指纹把输入长度、附件类型标志、系统提示版本、校验层版本一起打进去。拒答发生时拿当前指纹和上一次成功的指纹做差差在哪一项就先怀疑哪一项。⚠️ 代码待验证# 定位拒答来路按从外到内的顺序每个变体只改一个变量defprobe(variants):variants: 同一问题的多个改写逐条跑记录是否仍被拒report{}forname,reqinvariants.items():respcall(req)report[name]{blocked:resp.blocked,# 是否被拒form:resp.form,# hard / soft / caveatedguard_hit:resp.guard_hit,# 应用侧校验层是否有拦截记录echo_mismatch:resp.differs,# 模型原文与交付内容是否不同}returnreport# 变体按改动的层从外到内排列命中哪一层就从哪一层往下查VARIANTS{baseline:{},# 原样no_attachment:{drop_attachment:1},# 只去附件 → 查输入层规则shortened:{shrink:1},# 只缩长度 → 查输入层规则prompt_stripped:{drop_prompt_clause:1},# 只摘提示条款 → 查提示}这份探针的价值不在代码本身在于它把改一处、看一处变成了流程而不是靠猜。三、拒答与答错必须分开度量三类指标要并排看拒答和答错不是同一件事在指标上也不能合成一个数。至少要有三类拒答率判为拒答的次数 / 总请求数错答率有回答但内容错 / 有回答的总数无答案率既不是拒答、也没有给出可用答案软回避与限定到不可用的部分/ 总请求数三类的分母不一样这是必须分开的主要原因。把两个不同分母的数放一起算平均算出来的东西没有含义。指标分子分母单独看会漏掉什么拒答率判为拒答的请求总请求完全看不见软回避错答率有回答但内容错有回答的请求看不见拒答造成的空白无答案率无可用答案但未拒答总请求与软回避的边界靠标注确定一个「有效回答率」会把什么藏起来很多系统只统计一个有效回答率把三种失败压成一个数。它的问题不是不精确是方向相反的两次变化会互相抵消。举一个具体的例子安全对齐收紧之后模型在敏感问题上的乱答减少了错答率下降同时它在边界问题上的拒答增加了拒答率上升。这两股力量一叠加有效回答率可能看上去纹丝不动。但用户的体验是明显变差的——原来至少能拿到一个错答案现在直接拿不到东西。反过来也成立一次放宽会让拒答率下降同时把风险从看得见的拒绝搬进看不见的错答里。一个总数看不见这个搬运过程。埋点结构每条回答都要能回溯到分桶想把三类指标算准埋点必须在回答产生的那一刻就带上足够的信息。最少要这几项形态、来路、提示版本、校验层版本、重试次数。⚠️ 代码待验证{request_id:req_2f81,answer_form:soft_avoid,answer_used:false,refusal_source:unresolved,prompt_version:p-2026-09-14,guard_version:g-2026-08-02,retry_count:1,latency_ms:1840,input_flags:[long_doc,no_attachment]}两个字段值得单独说。answer_used记录的是下游到底有没有采用这个回答它靠业务侧回填但它是无答案率能不能算出来的前提。refusal_source允许是unresolved——来路判不出来时记成未定比硬塞一个错误分类强。四、接住它的四种设计改述重试只对特定形态有用改述重试的思路是换一个说法再问一次。它的适用范围比多数人想的窄只对硬拒有用。软回避再问一次通常还是软回避。只对来路是输入层规则或提示措辞的硬拒有用。措辞触发的拒绝换个等义表达确实可能不触发。对模型自身对齐触发的硬拒基本无效。同一件事的不同说法对齐层判的是意图不是字面。改述重试的代价是一次额外调用以及一个副作用它会稀释拒答率。如果一次请求内部重试了三次那么每次请求的拒答率会下降但每次模型调用的拒答率没变。所以在埋点里重试次数必须单独记否则指标会自己骗自己。换路径与降级换的是上下文不是模型换路径重试和改述的区别在于它不动问法动的是输入的组织方式。三种常见做法——把长文档拆成片段分别问、把附件转成纯文本再问、把多轮对话压成一轮再问。它针对的是输入触发规则这一类来路因为长度、附件类型、轮数都是规则能看见的东西。它的代价是需要重新装配一次上下文工程上要保证装配后的输入和原始输入在语义上等价。降级到规则指的是拒答之后不走模型走检索、模板或固定话术。它适合有结构化答案兜底的场景——比如查询类问题答案本来就在库里。它的代价是覆盖面窄而且回答会明显变死板用户能感觉出来。转人工与重试上限转人工是四种里代价最高的一种只在有明确业务价值、且前三种都接不住的时候用。它不适合高频低价值的问句因为排队会变成新的投诉来源。比选哪一种更重要的是上限。一个可用的配置是改述一次、换路径一次、降级一次走完仍然没有可用答案才转人工。⚠️ 代码待验证RETRY_BUDGET{rephrase:1,# 改述重试最多一次reroute:1,# 换路径重试最多一次fallback:1,# 降级到规则最多一次}defhandle_refusal(form:str,source:str,done:dict)-str:# 软回避与带免责的回答不进重试链路它们该走的是质量复核ifform!hard_refusal:returndeliver# 模型自身对齐触发的硬拒重试没有意义直接走升级路径ifsourcemodel_alignment:returnescalateforstep,limitinRETRY_BUDGET.items():ifdone.get(step,0)limit:done[step]done.get(step,0)1returnstepreturnhuman四种承接放一起看取舍是这样分布的承接动作触发条件代价不该用在哪改述重试硬拒来路是输入规则或提示措辞一次额外调用指标被稀释模型自身对齐触发的硬拒换路径重试输入触发规则附件 / 长度 / 轮数需要重新装配上下文输入本身就不合规降级到规则有结构化答案兜底的场景覆盖面窄回答变死板开放性问题转人工有明确业务价值且前三种接不住成本最高有等待高频低价值问句上限的作用不只是控成本它同时保证了一件事拒答率这个指标不会被无限重试拉平。没有上限的重试链路最后会让所有指标都变得不可读。五、过度拒答怎么治提示里给边界示例不给口号过度拒答的成因里最常见的一条是提示写得像口号。“请严格合规”注意安全这类句子对模型没有约束力因为它没有说明边界落在哪里。有效的写法是给成对的边界示例一条是这类可以答一条是这类不答最好再有一条是这种情况该先追问。示例要贴近真实业务问句而不是抽象的类别描述。抽象描述会让模型自己解释边界解释的结果通常偏向谨慎也就是拒得更多。条数要控制。示例太少覆盖不到边界太多会占用上下文并且互相冲突——两条示例如果在同一情形下给出相反的期望模型的输出会变得不稳定。⚠️ 代码待验证boundary_examples:-id:own_order_invoicesay:查询本人名下订单的开票状态expect:answer-id:other_user_ordersay:帮我查一下这个订单号的开票信息# 该订单不属于当前登录账号expect:refuse-id:ambiguous_time_rangesay:上个月的费用明细expect:clarify# 时间范围缺省先追问再答回归集要用真实业务问句判定是不是过度拒答这件事自己编的问句测不出来。原因很简单编的句子不会有真实用户的措辞习惯、错别字、省略和行业黑话而这些恰恰是触发误拒的主要来源。可用的回归集来源是线上抽样。抽出来之后做三件事去掉含个人信息的样本给每条标注期望行为该答 / 该拒 / 该追问按主题分桶保证每个桶里都有一定量。这份集子的标注成本是一次性的之后每次改动都能重复用。两个清单分开维护过度拒答的治理里一个实用的结构是把样本拆成两份清单并行维护。该拒清单不该拒清单样本来源线上被拒且业务确认该拒线上被拒但业务确认可以答期望标注refuseanswer 或 clarify主要指标该拒样本的拒答率不该拒样本的误拒率变更后的期望方向上升或持平下降两份清单必须同时看。只看不该拒那一份你会把所有拒答都当成问题去压只看该拒那一份你会把提示越写越紧最后把可用性压没。这两份清单也是第六章里三条禁忌能不能守住的前提。完整版资料清单本文用到的边界示例写法与回归集清单结构都整理在里面了扫码即可获取六、不该做的三件事拿拒答率当安全指标拒答率只度量一件事模型有没有说不。它度量不了该说不的有没有说。一个系统可以把拒答率做得很漂亮同时在一个该拒的样本上照答不误——因为那部分样本根本没有被拒。反过来把拒答率做低也很容易放宽一点就行代价是风险从可见的拒绝搬进了不可见的错答。真正要盯的是两个带标注的数该拒样本里拒了多少、不该拒样本里误拒了多少。这两个数只有在有期望标注的回归集上才算得出来这也是第五章那两份清单存在的理由。用提示去绕开安全层有一种做法是把安全层的判定当成提示没写好通过反复改措辞、加角色设定、拼接前缀去让本该被拒的内容通过。这条路不推荐本文也不给出任何具体做法。原因有三条都和工程无关、和风险有关第一它不改变模型侧的实际判定只是在你这一条请求上碰巧过了。同样的内容换一次采样、换一个时间再发结果可能就不一样不可复现。第二它把风险从模型层搬到了你的产品层。模型拒了责任边界是清楚的你绕过去交付了责任就在你这边。第三这种做法不可审计。提示里的角色设定和前缀拼接很难在评审里被看出来但它实际改变了系统的行为边界。业务确实需要某项被拒的能力时正路是走合规评审和模型侧配置调整而不是在提示里做文章。这条边界不能靠工程技巧去试探。把拒答一律当故障告警拒答里有一部分是设计意图。把每一次拒答都打成故障告警结果只有一个告警疲劳然后没人再看这个告警。分级是必须的。可行的分法是三档单次拒答只进样本、不告警同一来路的拒答比例在短时间内明显抬升才告警敏感场景下的拒答单独成一条告警链路因为它的容忍度本来就低。分档的依据不是严重程度的主观排序是这条告警出来之后有没有人能立刻做点什么。如果一个告警对应的动作只能是等它就不该是告警。七、观测与迭代拒答样本要有档拒答样本的存档不是把日志留下来就完了。日志里通常只有请求 ID 和响应体缺少判断形态和来路所需要的字段这些字段要在拒答发生的那一刻补齐。⚠️ 代码待验证{refusal_id:rf_00913,input_digest:sha256:...,model_output:……模型返回的原文……,delivered:……最终交付给用户的内容……,form:caveated,source:system_prompt,source_confidence:confirmed,regression_set:real_business_v3,ts:2026-10-13T09:12:0008:00}三个字段是关键。input_digest存摘要而不是明文既能去重、又能避开个人信息的存储问题。model_output和delivered必须分开存——两者不一致本身就是来路是校验层的强证据。source_confidence允许是unresolved来路判不出来时不要硬分类。按来路分桶看趋势拒答率的整体曲线几乎没有行动价值。它上升时你不知道该改提示、该改校验层、还是该接受模型侧的变化。分来路之后每条曲线的动作才明确。分桶的落地顺序是先标置信度高的也就是入口规则直接拦下的、校验层明确记录的、提示摘除后立刻分化的这三类剩下的进unresolved桶定期人工抽样回标。unresolved桶的占比本身就是一个指标——它长期偏高说明你的判定链路还不够用。时间维度上要看的是同来路的比例变化而不是绝对值。因为绝对值和流量结构有关换一批用户就能让它跳一次。回归集接进变更流程观察只能发现变化验证才能确认变化是不是预期内的。这两件事要靠同一份回归集接起来。触发回归的时机有三类系统提示有改动、模型有切换、校验层有调整。这三类改动都会直接改变拒答行为而它们又都不一定会体现在普通的功能测试里——功能测试看的是接口通不通不是该拒的拒没拒。⚠️ 代码待验证# 提示 / 模型 / 校验层发生变更前跑一遍回归集run_regression--setreal_business_v3\--reportmetrics\--splitshould_refuse,should_answer# 只盯两个数# should_refuse 段上的拒答率 —— 变低要查是不是放宽过度# should_answer 段上的误拒率 —— 变高要查是不是提示写紧了这两个数的变化方向是相反的。任何一次改动如果让其中一个变好、另一个变坏都不是一次干净的改动需要人工判断这个交换值不值。把这一步固化进变更流程比事后从线上反馈里倒推要便宜得多。完整版资料清单本文用到的拒答样本存档结构与分桶观测口径都整理在里面了扫码即可获取附表 A关键取舍一览本文涉及的所有工程判断集中在这里方便按需回看。取舍本文结论判断依据位置拒答要不要当成一种失败要但硬拒与软回避分开处理两者在下游的破坏方式不同第一章只用成功率看状态行不行不行软回避与带免责在成功率里是成功的第一章拒答来路的判定顺序从输入层往模型侧收外层最便宜、验证成本最低第二章定位时能不能同时改多个变量不能一次只改一个否则结果无法归因第二章拒答率与错答率能不能合并不能分母不同合并后方向相反的变化会抵消第三章无答案率怎么算靠answer_used回填没有这个字段就算不出来第三章来路判不出来时怎么标记unresolved不硬分类错误分类会污染分桶趋势第三章改述重试用在哪只用于输入规则或提示措辞触发的硬拒模型侧对齐判的是意图第四章重试要不要设上限要每类一次无上限会把拒答率拉平到不可读第四章软回避要不要进重试链路不要走质量复核再问一次通常还是软回避第四章边界怎么给模型给成对示例不给口号口号没有说明边界落在哪第五章回归集样本从哪来线上抽样不用自编问句自编句缺少真实措辞与省略第五章该拒与不该拒清单分开维护同时看只看一份必然把提示写偏第五章拒答率能不能当安全指标不能它只度量说不不度量该说不第六章提示绕过安全层不推荐走合规评审正路不可复现、责任转移、不可审计第六章拒答告警怎么设三档分级单次只进样本全量告警会导致告警疲劳第六章拒答存档存什么模型原文与交付内容分开存两者不一致是校验层拦截的证据第七章趋势怎么切按来路分桶看组内变化总体曲线没有行动价值第七章回归集什么时候跑提示 / 模型 / 校验层变更前这三类改动普通功能测试测不到第七章附表 B术语速查表术语含义硬拒模型明确表示不能协助形态上可判定软回避有回答但答非所问、绕开要点的拒答形态带免责的回答给出内容同时附加大量限定条件的应答无答案率未拒答但未给出可用答案的比例拒答率判为拒答的请求占总请求的比例错答率有回答但内容错误占全部有回答请求的比例来路拒答的实际触发来源分输入规则、校验层、系统提示、模型对齐四类输入触发规则在请求进入模型前按长度、关键词、附件类型等条件拦截的规则应用侧校验层拦在模型输出之后、对结果做筛选或改写的一层系统提示约束提示文本中显式写入的禁止类条款模型自身对齐由模型训练与对齐结果产生的拒答倾向应用侧不可直接修改请求指纹输入长度、附件标志、提示版本、校验层版本等字段的组合改述重试保持意图不变、改变表述后重发一次换路径重试改变输入组织方式拆片段、转纯文本、压轮次后重发降级到规则不走模型改用检索、模板或固定话术应答重试预算每个承接动作允许的最大执行次数该拒清单线上被拒且业务确认应拒的标注样本集合不该拒清单线上被拒但业务确认可答的标注样本集合误拒率在不该拒清单上被拒的比例来路分桶按拒答来源对样本分组统计的做法告警疲劳告警过多导致接收方不再响应的状态写在最后这篇用到的资料写这篇文章时我把几个模型的官方文档、参数表和实测记录都对了一遍顺手整理成几份配套的东西大模型学习路线图从 LLM 基础到 Agent 开发各阶段该学什么、用什么资料大模型全套教程按主题分好的视频与文档清单大模型实战好书24 本附每本适合的阶段资料是我自己整理的放在下面这个码上扫码即可获取添加时备注「大模型」优先通过。拿到之后建议先看学习路线图那一份先定位自己在哪个阶段再决定学什么比一上来就啃框架效率高得多。