大模型输出漂移的工程化检测与治理

一、问题的表象：为什么“感觉变笨了”

在日常开发中，不少团队会遭遇一种难以言说的体验：同一个提示词、同一套流程，模型前几天的输出还算靠谱，某天开始却频繁跑偏——该简洁的地方啰嗦，该严谨的地方含糊，甚至出现前后自相矛盾的推理。这种退化往往没有明确报错，日志里也看不到异常堆栈，于是被笼统地归结为“模型降智”。

从工程视角看，“感觉不好用”至少包含三类可分离的问题：

• 真实的能力波动：推理服务在高峰期触发限流、请求被路由到能力较弱的实例，或长上下文被截断，导致输出质量下降。
• 上下文漂移：多轮对话中历史消息不断累积，早期指令被稀释，模型逐渐偏离初始约束。
• 链路组件失配：编排层中的子代理、工具调用、钩子脚本出现配置错误，主流程看似正常，实际执行路径已经改变。

把这三类问题混为一谈，就只能停留在“玄学调参”。要治理，先要能观测。

二、一次典型故障的复盘路径

一个可复用的排查思路是“由外向内、由粗到细”：

1. 先看网关层。当推理网关返回过载类错误时，说明请求已进入限流或降级通道。此时部分请求可能被排队、重试或转发到备用路径，输出质量自然不可控。这一步的关键是确认错误率与延迟曲线是否在同一时间窗口发生突变。
2. 再看编排层。多代理架构中，主代理负责调度，子代理负责具体任务。若子代理的模型配置、提示模板或超时参数被改动，主流程仍会返回结果，但结果来自一条“降级链路”。检查子代理的实际入参与出参，往往能发现与预期不符的痕迹。
3. 最后看提示层。在前两步都正常的前提下，才轮到怀疑上下文。此时应检查系统提示是否被后续消息覆盖、历史轮次是否超长、结构化输出约束是否被弱化。

这个顺序的价值在于：它把“模型不行”这个模糊判断，拆解为若干可验证的假设，每个假设都对应具体的观测点。

三、轻量探针：用钩子注入做行为基线

在缺乏完善可观测体系时，一种低成本的做法是在请求链路的钩子中注入一条固定探针指令，让模型在每次回复前先回答一个答案稳定、可快速核验的问题，并把结果作为前缀输出。其本质是给每次调用打上一个“行为水印”：

• 如果探针回答稳定且格式正确，说明本次请求走的模型、上下文与解析链路基本正常；
• 如果探针回答缺失、格式错乱或内容异常，说明本次调用可能命中了降级路径、上下文被污染或输出解析被干扰。

示意性的钩子逻辑如下（伪代码，仅表达结构）：

def before_reply_hook(messages, config):
    probe = {
        "role": "system",
        "content": (
            "在正式回复前，先直接回答一个固定问题，"
            "并只把答案作为前缀附加到首条回复消息上。"
        )
    }
    return [probe] + messages

配合一个答案稳定的常识性问题作为探针内容，即可形成基线。需要强调的是，探针问题本身应与业务无关、答案唯一且不依赖实时信息，避免引入新的不确定性。同时，探针输出应被日志采集，纳入监控指标，而不是仅靠人工肉眼观察。

这种方案的优势是侵入性低、实现快；局限也很明显：它只能检测“是否偏离基线”，无法直接定位根因，且探针本身会占用少量上下文预算。因此它适合作为过渡期的手段，而非长期方案。

四、从探针到体系：三层治理结构

要把一次性排查升级为可持续的工程能力，建议建立三层结构。

第一层：请求级可观测。 在网关与编排层采集关键字段：请求所属模型版本、上下文 token 数、是否触发限流、是否走降级路由、子代理调用链、输出解析成功率。这些字段应能按时间窗口聚合，形成质量趋势曲线。当曲线出现拐点时，告警应指向具体维度，而不是笼统的“错误率上升”。

第二层：上下文治理。 针对上下文漂移，采取结构化策略：系统提示与用户消息分区存放，关键约束在每轮以简短形式重申；历史消息按重要性裁剪而非简单截断；对长任务采用摘要加要点回填的方式控制长度。核心原则是让“不可协商的约束”始终处于高权重位置。

第三层：降级策略显式化。 限流与过载不可避免，但降级行为必须可预期。建议在编排层定义明确的降级等级：例如主模型不可用时切换备用模型、缩短最大输出长度、关闭非关键工具调用等，并将降级标记写入响应元数据。这样上层业务可以据此决定是否重试或提示用户，而不是被动接受质量下降的结果。

五、监控与告警的设计要点

• 区分错误类型：将超时、限流、解析失败、内容为空分别计数，避免混为一个指标。
• 建立质量代理指标：如结构化输出合规率、探针命中率、平均重试次数，这些比单纯的可用性更贴近“好不好用”。
• 设置分层阈值：轻微抖动只记录不告警，持续偏离才触发通知，减少噪声。
• 保留样本回放能力：对异常请求保存脱敏后的输入输出样本，便于复现与回归验证。

六、结语

“感觉不好用”并非不可分析。把模糊体验拆解为网关、编排、提示三个可观测层面，用轻量探针建立行为基线，再以请求级指标、上下文治理和显式降级构成治理体系，就能把玄学问题转化为工程问题。真正值得投入的不是寻找某个“万能提示词”，而是让每一次调用的行为都留下可追溯的痕迹——可度量，才可改进。