解读

在国内真实业务场景里，大模型往往以“链式”方式工作：意图识别→检索→摘要→推理→答案生成。任何一步跑偏，后续全部作废，既浪费算力又可能触发合规风险。面试官问“监控中间置信度并提前终止”，核心想看三件事：

1. 你有没有量化置信度的指标，而不是拍脑袋；
2. 你能不能在链式框架里无侵入地插桩，不影响线上延迟；
3. 你能否结合国内监管要求（生成内容安全、个人信息脱敏）做熔断，而不是纯技术自嗨。

知识点

1. 置信度量化三板斧

   • 模型内置：softmax 最大概率、Beam Search 的 Score Gap、Top-p 累积概率。
   • 外挂判别：小尺寸 Uncertainty Estimation 模型（如 1.3B 的 ELECTRA 做二分类），输入当前步骤的隐状态，输出“可信/不可信”。
   • 任务相关：检索步骤用召回率@K与rerank 分数，推理步骤用答案一致性投票（Self-Consistency）。

2. 链式插桩机制

   • 基于 LangChain 的 Custom CallbackHandler，在每次 on_chain_end 时把置信度写进上下文；
   • 或者公司自研 DAG 引擎，在节点出边加条件网关，表达式里直接引用 ${step.confidence} < ${threshold}。

3. 提前终止策略

   • 硬熔断：置信度低于阈值立即抛 ConfidenceException，由上游重试或降级到兜底模板；
   • 软重路由：把低置信步骤输出 mask 掉，触发“安全小模型”生成保守回复，并记录审计日志；
   • 动态阈值：根据实时流量 QPS 与 GPU 利用率，通过 PD 控制器自动下调阈值，优先保业务成功率。

4. 合规与可观测

   • 所有置信度、熔断事件必须写入 Kafka 统一日志，字段包含 trace_id、step_name、confidence、threshold、uid_hash，方便网信办抽查；
   • 敏感词命中时，置信度直接归零，强制熔断，并回调内容安全审核平台做异步复核。

答案

“我会上报三步方案。
第一步，量化：对生成类步骤，用 Beam Search 的 (max_score − second_score)/max_score 作为归一化置信度；对检索类步骤，用 rerank 分数与召回空缺率加权。所有指标统一映射到 0～1。
第二步，插桩：在自研 LLM-OPs 引擎里给每个节点包一层 @confidence_wrapper，把上一步的隐状态送进 0.3B 的 uncertainty 小模型，推理仅 2 ms，CPU 执行不占用 GPU。
第三步，终止：配置双阈值——预警阈值 0.4、熔断阈值 0.2。低于 0.4 时把当前步骤输出标灰，继续跑但标记为“待审核”；低于 0.2 直接抛 ConfidenceException，由上游捕获后返回‘这个问题我暂时无法回答，已转人工’，同时写审计日志。整个链路通过 Prometheus 暴露 llm_chain_break_total 指标，配合 Grafana 做实时大盘，15 秒内可感知异常并自动电话告警值班经理。”

拓展思考

1. 如果业务允许“多轮澄清”，可把低置信节点转成反问用户而非直接熔断，提升转化率；此时需要维护一个澄清模板库，并监控澄清成功率作为新的置信度外部反馈。
2. 对千亿稀疏模型（MoE），置信度估计要额外考虑专家路由不均衡带来的噪声，可引入 Rényi entropy 替代普通 softmax entropy，减少伪高置信。
3. 国内金融、医疗场景要求可解释备案，可把置信度与《生成式 AI 服务管理暂行办法》第 8 条“显著标识”结合，在返回体里增加 confidence_score 字段，前端用黄底高亮提示用户“本条答案可信度 62%，仅供参考”，既满足监管又提升体验。