大模型API被模型映射降级？用指纹探针做验收与日常自检

1. 从一次回答风格突变说起我为什么盯上了接口里的模型去年下半年我在一个多人协作的小项目里负责接口对接部分。当时为了省掉企业资质申请和外币结算的麻烦团队选了一家第三方接口中转服务商充值之后拿到一个 key文档上写的是全量支持目标旗舰模型 T1 及其全部参数。价格不算便宜折算下来比我们自己走原厂批量采购只低了大概两成但胜在开票方便、结算走本币、账单能直接对上一个总账财务那边省了不少事。前两周一切正常。第三周开始我写代码的时候习惯性地让模型帮我补一段边界条件判断它给出的答案开始变得短、平、快——话少了废话也少了但错得也多了。同样的提示词之前能一次给出带异常分支的完整函数现在只给出主干异常处理直接写个pass。我一开始以为是自己的提示词改坏了翻回去对比历史记录提示词一个字没动。真正让我警觉的是另一件事我让接口解释一段冷门的语言特性它给的答案在结论上是对的但举的例子是三个版本之前就已经废弃的写法而且措辞特别像某个开源小模型的输出风格。我把同一段提示词丢给我自己本地跑的一个小参数模型两边的回答在句式结构上高度相似连首先/其次/最后这种分点习惯都一模一样。那一刻我心里咯噔一下我付的是旗舰模型的单价拿到的可能是一个被映射过去的廉价替代品。这篇文章我想把这些天摸出来的东西完整讲一遍。映射模型这个说法在圈子里流传有一阵了但真正动手去验证的人不多多数人只会凭感觉说最近好像变笨了。我会把怎么判断、拿什么判断、判断出来之后怎么办这三件事掰开讲清楚包括我自己踩过的误判坑。适合正在用第三方模型接口做产品、做内容流水线、做内部工具的人看也适合只是想搞清楚自己那笔钱花得值不值的同学。提示本文讨论的是商业服务中的标称与实际不符问题所有检测手段都建立在你自己有合法 key、有正常调用额度的前提上属于正常的采购验收范畴。1.1 那三个不对劲的细节后来被我做成了固定检查项复盘的时候我把当时察觉到的异常归纳成三条现在这三条已经变成我每次接新服务商的必查项。第一条是输出长度分布的漂移。同一个提示词、同样把最大输出长度放到 2000旗舰模型的输出长度分布是右偏的长尾能拖到一千多 token而小模型往往在三四百 token 就自己收尾了。这个指标特别灵敏因为它几乎不受提示词措辞影响。第二条是对我不知道的处理方式。强模型在遇到超出知识范围的问题时通常会说明信息边界并给出可行的替代路径弱模型更倾向于硬编一个看起来合理的答案。我在测试里塞了几个故意构造的不存在的事实两个模型的表现差别非常明显。第三条是多轮对话中的指令遵循衰减速度。我在第一轮给了一条格式约束比如每个回答必须以一句话结论开头然后连续追问五轮。旗舰模型到第五轮还能守住映射过去的小模型到第三轮就开始忘了。这三条单独看都不足以定案但三条同时出现基本就可以怀疑了。1.2 映射模型这个词指的到底是哪一类操作很多人以为映射就是用 A 模型的接口假装成 B 模型其实具体形态比这复杂得多。我接触到的情况大致能分几层最粗暴的一层是纯替换。请求里写的是 T1路由层直接把模型名改写成某个开源小模型或者蒸馏版本返回的时候把响应体里的model字段再改回 T1。这种最容易被抓因为能力差距是断崖式的。第二层是版本降级。你买的是最新版实际给的是半年前的老版本或者是量化压缩过的版本。这种最恶心因为能力只下降一点点你在日常使用中几乎感觉不到只有在复杂推理或者长上下文任务上才会露馅。第三层是动态路由。请求进来之后先做一次轻量分类简单问题走小模型复杂问题走大模型。这种最难识破因为你随手试几次都会得到不错的结果只有做批量统计才会发现能力分布是双峰的。第四层是参数蚕食。模型确实是那个模型但把你的max_tokens悄悄截断把你的temperature强制拉低把系统提示词里的一部分内容吃掉。严格说不算换模型但同样是你花钱买了个残缺品。我遇到的那家事后判断大概率是第二层叠加了第四层。2. 拆开成本账映射模型是怎么被塞进你的请求链路的要理解为什么有人干这事得先算一笔账。旗舰模型 T1 的输出价格和某个同代小模型的价格差距通常在一个数量级左右如果换成更早一代的蒸馏模型差距能拉到二十倍以上。这意味着什么意味着只要有一半的请求被悄悄替换掉服务商的毛利就能翻倍而你在账单上看不出任何异常——因为账单上的 token 数是真实的只是单价对应的东西不是你以为的那个。我不想把这写成一篇揭露黑幕的文章因为绝大多数中转服务商是老老实实做转发的赚的是结算差价和运维成本。但确实存在一批人把信息不对称当成了主要利润来源。你要做的不是愤怒是具备识别能力。2.1 一条请求从你手里到模型之间要经过几道手很多人对链路的想象是我一发模型就答。实际链路至少有这么几环你的客户端发出 HTTPS 请求进到服务商的网关网关做鉴权、限流、计费预扣然后进路由层路由层根据模型名、负载、用户等级决定打到哪个上游上游返回之后网关做一次响应包装统一字段格式补上 usage 统计最后回给你。关键就在于路由层。这一层是完全黑盒的你看不到任何日志。它可以做的事情包括但不限于改写模型名、切换供应商、在多个上游之间做加权分流、按请求内容做复杂度判断、按时间段切换白天给你好的凌晨给你差的、按用户累计消费切换新用户给好的用久了给差的。我见过最讲究的一种做法是按用户维度做灰度前 10 万 token 给你真货让你建立起这家的东西不错的印象之后逐步降低真货比例。因为人的使用习惯是前期密集测试、后期无脑调用的等你不再测的时候正好是它开始省成本的时候。2.2 四种偷梁换柱形态对应的可观测特征不同的替换手法留下的痕迹是不一样的。我把能观测到的信号整理成了下面这张表实测时按这个思路去找线索效率会高很多。替换形态最明显的可观测信号容易误判的地方纯替换为小模型输出长度分布整体左移复杂推理题正确率断崖式下跌提示词写得不好时真模型也会短答版本降级/量化长上下文召回率下降代码生成的边界处理缺失网络超时重试会打断长任务看起来像能力下降动态路由能力分布呈双峰简单题几乎全对难题几乎全错样本量太小时看不出来会被当成随机波动参数蚕食实际输出 token 数长期贴着某个上限温度参数无效有些真模型本身就对 seed 不敏感这张表最有价值的一列其实是第三列。我自己就在版本降级这一行上误判过一次当时我拿一段三千行的日志做根因分析接口给的答案很浅我一口咬定是模型被换了。后来发现是我自己的请求超时设得太短连接被中断后客户端自动重试了一次第二次请求的上下文里只带了部分内容。这种乌龙不查清楚很容易冤枉人。注意任何单点异常都不能作为结论。模型能力本身就有方差一个提示词答不好太正常了。要下结论至少需要同一类探针重复二十次以上的一致偏离。2.3 为什么看响应里的 model 字段完全没用新手最容易犯的错是去看返回 JSON 里那个model字段发现写的是 T1 就放心了。这个字段是网关自己填的想填什么填什么。同理usage里的 prompt_tokens 和 completion_tokens 也是网关算的它可以随便给你一个数。能稍微保留一点参考价值的是token 计数的内部一致性。同一个网关用同一个分词器输入文本和它报出来的 prompt_tokens 之间应该有一个相对固定的比例关系。如果你发现同一个中文句子在不同时段报出来的 token 数不一样说明背后至少换过一次分词器而不同模型的 tokenizer 是不同的。这是个很隐蔽但挺好用的辅助信号。再补充一个首 token 延迟和总时长的比值。不同规模的模型在推理速度上有系统性差异小模型的首 token 延迟通常明显更低。如果你在同一网络条件下测到某段时间的首 token 延迟系统性下降了三成而输出质量也在下降这两个信号叠加起来就很有说服力了。当然这个信号受服务商负载影响极大只能作为佐证不能单独用。3. 自己动手做模型指纹一套不依赖服务商自证的探测方案我不喜欢感觉变笨了这种判断方式因为它没法拿出去跟人交涉。你总不能跟客服说我觉得你们换模型了。你需要的是可复现、可量化、别人拿去跑能跑出同样结果的东西。这一节我把自己攒的一套探针方案完整写出来。这套东西不复杂核心思路就一句话找那些强模型和弱模型表现差异极大、而提示词措辞影响极小的任务然后看你的接口在这些任务上的表现落在哪个区间。3.1 探针题的挑选原则什么样的题目才有区分度我试过几十道题最后留下的不到二十道。筛选标准有四条缺一不可。第一条是答案唯一且可机器判定。凡是需要人工评判好坏的主观题一律不要因为那引入了你自己的偏见。要的是这个数是 17这种硬答案。第二条是跨模型方差大、同模型方差小。也就是说同一个模型重复问二十次答案应该基本一致把温度设成 0而不同规模模型之间的正确率差异要足够悬殊。我通常要求这道题在旗舰模型上正确率高于 90%在小模型上低于 30%这样单次测试就有很强的判别力。第三条是不依赖训练数据记忆。纯知识题不好因为可能刚好命中了某个模型的训练集。要用那种必须现场推理的题比如多步约束满足、嵌套括号匹配、长链算术。第四条是长度可控。探针题的输入最好控制在 300 token 以内这样跑一百次也不心疼钱而且能排除长上下文带来的干扰变量。按这四条筛下来能用的题其实不多但够用了。3.2 五类高区分度探针以及我用的判定阈值我最终固定下来的是五类每类三道题一共十五道。跑一轮大概花掉不到两万 token成本可以忽略。第一类是嵌套约束。给一段包含七八条相互制约条件的描述问满足全部条件的方案有几个。这类题对模型的工作记忆要求很高小模型经常在第三条约束上就开始丢条件。我的判定标准是正确率低于 60% 就进观察名单。第二类是长文本定位。在一段八千字左右的材料里埋一个关键数字然后问一个必须用到这个数字的问题。同时我要测两个位置数字放在开头附近和放在结尾附近。强模型在两个位置上的召回率差异通常小于 10%弱模型能差出 40% 以上。这个位置衰减差是我认为最有价值的单一指标。第三类是格式强约束。要求输出严格的 JSON且字段顺序、嵌套层级、字段类型全部指定死。强模型一次成型率很高弱模型经常多带解释性文字或者漏字段。判定阈值取一次成型率低于 70%。第四类是自我一致性测试。同一个问题用三种不同的表述方式问三遍温度设 0看答案是否一致。强模型在语义等价的问题上给出的答案应该高度一致弱模型会因为表述变化而给出不同结论。这个指标能有效识别参数蚕食型的替换。第五类是否定指令。明确告诉它不要提到某某概念不要使用某某句式然后看它是否遵守。弱模型对否定指令的遵循度明显更差这一点在做产品时也是实打实的影响。3.3 采样次数、对照组和统计口径这三件事决定结论可信度我这套方案里最容易被人忽略的是对照组。你必须同时测两个东西一个是你怀疑有问题的接口另一个是你信得过的参照接口原厂直连、或者另一家口碑好的服务商、或者本地部署的开源模型。没有对照组你测出来的数字没有意义因为你不知道正常是什么样。采样次数上我的经验是每道题至少跑 10 次整个探针集跑三轮三轮分布在不同时段比如早中晚各一次。这样能顺带发现按时段切换的情况。三次结果之间的标准差如果很大本身就是个红灯。统计口径上我只看三个数整体正确率、题与题之间的正确率方差、同一题多次采样的答案离散度。第一个数看能力水平第二个数看是否存在动态路由如果简单题全对难题全错题间方差会异常大第三个数看输出的一致性。下面这段是我实际在用的探测脚本骨架去掉了一些业务相关的封装你可以直接改成自己的。import time, json, statistics, requests BASE https://example-gateway.invalid/v1/chat HEADERS { Authorization: Bearer YOUR_KEY, Content-Type: application/json, } def ask(prompt, modelt1, temperature0.0, max_tokens800, seed42): payload { model: model, messages: [{role: user, content: prompt}], temperature: temperature, top_p: 1.0, max_tokens: max_tokens, seed: seed, } t0 time.time() r requests.post(BASE, headersHEADERS, jsonpayload, timeout180) dt time.time() - t0 data r.json() choice data[choices][0] return { text: choice[message][content], latency: round(dt, 3), completion_tokens: data.get(usage, {}).get(completion_tokens), reported_model: data.get(model), } def run_probe(probes, rounds10): stats {} for name, prompt, checker in probes: results [] for _ in range(rounds): out ask(prompt) results.append({ ok: checker(out[text]), len: len(out[text]), tokens: out[completion_tokens], latency: out[latency], }) time.sleep(0.8) stats[name] { accuracy: sum(r[ok] for r in results) / rounds, len_mean: round(statistics.mean(r[len] for r in results), 1), len_stdev: round(statistics.pstdev(r[len] for r in results), 1), tok_mean: round(statistics.mean(r[tokens] or 0 for r in results), 1), lat_mean: round(statistics.mean(r[latency] for r in results), 3), } return stats这个脚本的价值不在于它多复杂而在于它把我感觉变成了三个可比的数字。你拿同一份脚本去跑两个接口把结果并排放谁在撒谎一目了然。提示seed参数不是所有上游都支持如果发现传了 seed 之后结果依然高度随机这本身也是一个信号说明网关没把这个参数透传下去。4. 实测记录同一批提示词在两套接口上的分歧点讲完方法我把实测过程和数据摊开。这一段是我写这篇文章最主要的原因——网上讲映射模型的内容大多是转述别人的说法很少有人把自己测到的数拿出来。我的测试对象有三个一个是自己申请的直连接口记为 REF作为基准一个是我实际在用的那家服务商记为 S1还有一个是后来朋友推荐的另一家记为 S2。测试时段选在工作日的上午、下午、深夜各一轮每轮跑完整探针集。4.1 长上下文召回的位置衰减最能说明问题的一个指标我构造了一份大约九千字的技术材料在开头、中段、结尾分别埋了三个不同的数字然后问三个必须用到这些数字的问题。温度设 0每轮每问跑 10 次。结果很说明问题。REF 的三个位置召回率分别是 100%、100%、93%也就是说整体召回很好只在最末端有一点衰减。S1 的三个位置召回率是 97%、76%、52%位置衰减极其明显——这个曲线形状非常像上下文窗口被压缩过的模型或者被截断了部分输入的调用。这里有个坑我得提醒位置衰减必须先排除输入被截断的可能。我最初测出来 S1 的结尾召回率只有 40% 出头当时怀疑是彻底截断了一半内容。后来加了一个校验——在提示词末尾要求模型复述最后一行——发现它能复述出来说明输入是完整的只是注意力分布有问题。这个区别很重要输入被截断是技术故障注意力衰减是模型能力问题两者的处理方式完全不同。为了进一步确认我又做了一个反向实验把关键信息同时放在开头和结尾然后问这两处提到的数字是否一致。如果输入完整、模型能力足够它应该能正确比较如果输入被截断它根本看不到后面的。S1 在这个测试上正确率 88%REF 是 100%。88% 这个数说明信息是能看到的只是提取不精确。4.2 结构化输出与指令遵循衰减曲线长得完全不一样格式约束这类测试的结果更有意思。我要求模型输出一个特定结构的 JSON包含六个字段其中两个是嵌套对象并且明确规定不要输出任何 JSON 之外的内容。REF 的一轮成型率是 96%S1 是 71%S2 是 92%。但如果只看这个数你可能会得出S1 能力弱一些的结论实际上问题远比这严重——因为我又测了多轮场景。我设计了一个五轮对话第一轮就给出格式约束后面每一轮都追问一个相关问题全程不重复约束。REF 到第五轮还有 90% 的格式保持率S1 到第三轮就掉到 45%第五轮只剩 20%。这个衰减速度不是能力弱一点能解释的更像是系统提示词或者对话历史没有被完整传递。后面这一点后来被另一个测试印证了我在最开始的系统提示里塞了一条编号规则所有列表项必须从编号 100 开始然后在第五轮让它列三样东西。REF 正确输出了 100、101、102S1 输出的是 1、2、3。这条规则在第五轮完全丢失了。我把这个发现整理成了一个指令保持率指标定义是在 N 轮对话后首轮给出的非显式约束仍然被遵守的比例。这个指标对识别上下文被裁剪型的问题特别有效而且几乎不受探针题难度影响非常好用。4.3 数据汇总以及我是怎么排掉那些误判的三轮跑完我把核心数据汇总成一张表。为了避免文章变成数据堆砌我只保留最有判别力的四行。指标REF基准S1在用的S2备选判定嵌套约束正确率94%58%91%S1 明显异常长文本末位召回率93%52%90%S1 明显异常五轮后指令保持率90%20%86%S1 严重异常输出长度中位数token412168395S1 明显异常四个指标全部指向同一个方向而且三轮结果之间的波动都不大S1 的三个时段数据差异在 8 个百分点以内这排除了偶发故障的解释。但我也确实排掉了两个误判。第一个是首 token 延迟我最初看到 S1 的首 token 延迟比 REF 低 40%认定它是小模型后来发现纯粹是因为 S1 的服务器物理位置更近网络往返时间短。这个信号在跨服务商比较时基本不能用。第二个是输出 token 统计S1 报的 completion_tokens 比我自己用分词器数出来的少了大约 15%。我一度以为它在偷计费。后来确认是分词器版本不同导致的这在正常范围内。真正有问题的是它报的 token 数在不同时段不一致这个才是硬伤。还有一点值得说我把同样一批探针题拿去问我自己本地部署的一个中等参数模型结果它的表现介于 REF 和 S1 之间嵌套约束 76%末位召回 71%。这个结果的意义在于它说明 S1 的表现在能力层面是可以用小模型解释的不需要引入服务器故障这类复杂假设。5. 服务商话术与合同条款里那些容易忽略的措辞数据出来之后我跟对方沟通过一轮这个过程本身也很有信息量。我把自己遇到的几种典型回应记下来供你参考——不是让你去吵架是让你提前知道会遇到什么。5.1 五种常见回应以及它们背后的逻辑漏洞第一种是我们用的是官方同款模型绝对没有替换。这句话本身可能是真的但它回避了版本问题。同一个模型的不同版本在能力上可以差出很多你说同款我认但你没说版本号。第二种是模型能力会随时间波动这是正常的。这句话在技术上站得住脚但波动的合理范围是有限的。如果一个指标在三轮测试里都掉到基准的一半以下那不叫波动那叫系统性差异。第三种是您可能是网络不稳定导致的。这句话其实是最好反驳的——我的探针题全部是短输入、可重试、有完整响应体的网络问题会导致请求失败不会导致模型答得浅。而且我用的是同一个客户端、同一个时段、同一个网络环境测多组其他服务商没有这个问题。第四种是我们做了智能路由优化会根据问题复杂度分配资源。这句话是在给动态路由找说法。如果真做了这个应该在文档里明说并且给出可关闭的选项。偷偷做本质上就是降级。第五种是可以给您退款。这反而说明问题因为正规服务商的第一反应通常是我们查一下日志。我把这五种回应整理成一句话的判断标准愿意提供上游调用日志、愿意写明版本号、愿意让你按探针结果验收的才值得继续合作。这三件事任何一件做不到就别谈技术了。5.2 验收条款该怎么写几个真正能保护自己的约定我现在签这类服务合同时会坚持三条写进去之后对方的态度会立刻变得诚实很多。第一条是版本声明义务。要求服务商在接入文档里明确写出当前对应的上游模型版本标识并且任何版本变更必须提前书面通知。这一条看起来简单但它把版本降级这条路堵死了因为你有了对比基准。第二条是验收测试权。约定甲方有权在任意时段用约定的探针集进行测试测试结果低于约定阈值的按比例退还当期费用或者终止合作。阈值怎么定我建议直接写在合同附件里比如十五道探针题的整体正确率不低于 85%五轮指令保持率不低于 80%。把主观问题变成客观条款。第三条是用量明细可回溯。要求提供按天、按模型、按耗时分布的明细账单而不只是一个总数。如果对方只能给你一个总数说明它的计费系统根本不区分模型那映射这件事从技术上就是默认允许的。提示这三条对方如果含糊其辞不用纠缠直接换下一家。做正经生意的服务商对这些条款没有心理负担因为他们本来就没打算换模型。还有一个实操上的小建议别用月付先用按量付费跑到验证通过再谈长期。我见过太多人上来就充值一年发现问题之后退款极其困难。按量付费虽然单价高一点但让你保留随时走人的权利这个权利值那个差价。6. 把检测变成日常一套低成本的长效自检机制靠人工测试是撑不了多久的——我第一轮测试做完之后心想以后每两周跑一次。结果第三个礼拜就忘了第五个礼拜想起来的时候那家服务商已经把模型换回去又换回来了我根本无从验证。所以最后还是得靠自动化。我现在的做法是在 CI 里挂一个每日任务跑一个精简版探针集把结果画成趋势图。成本每天不到一千 token但能在问题出现的第二天就发现。6.1 一个每天只花一千 token 的精简探针精简化之后我只保留三样东西一道嵌套约束题、一道末位召回题、一次五轮指令保持测试。前两个各跑 3 次第三个跑 1 次总共调用次数不到 15 次。判定逻辑我写得很朴素把最近 7 天的正确率做滑动平均如果今天的结果比 7 天均值低了 20 个百分点以上就触发告警。用滑动平均是为了过滤掉单日波动我一开始用绝对值低于阈值就告警结果因为题目本身难度问题天天误报跑了一周就不想看了。告警触发之后不要急着下结论先做两件事一是把探针跑满完整版十五道题三轮二是检查当天的输出长度分布有没有整体左移。两个信号都出现基本可以定案只有一个就再观察两天。还有一个细节我得说一下趋势图比单次结果重要得多。能力是缓慢变化的你每天看一个绝对值可能毫无感觉但把 30 天的数据连起来看从某一天开始台阶式下降这种形状会非常刺眼。我自己就是靠这张图发现对方是在某个周二下午开始动手的——因为那一天之后所有指标都平移了一档而之前的 20 天一直很平整。6.2 出现哪些信号时必须立刻复检别拖我给自己定了五条红线任何一条触发就立刻停下来查。第一条输出长度中位数连续三天比历史基线低 25% 以上。这条最容易观测也最灵敏。第二条五轮指令保持率跌破 60%。这条一旦触发说明上下文处理链路上出了问题不管是模型换了还是裁剪了历史都是硬伤。第三条同一请求在温度 0 下重复三次得到三个明显不同的答案。说明参数没有被透传或者背后有多个上游在轮询。第四条账单上的 input token 与实际输入长度的比值出现跳变。说明分词器换了而换分词器往往意味着换模型。第五条首 token 延迟和总时长的比值出现台阶式变化。注意是台阶式不是波动波动是正常的台阶式变化意味着背后的硬件或者模型规模变了。这五条里我实际用下来最可靠的是第一条和第二条剩下三条作为辅助。第一条几乎零成本第二条约等于零成本两个加起来就能覆盖大部分情况。6.3 真要换服务商时我的迁移清单最后说一下切换这件事。我把模型从 S1 迁走的时候踩了几个坑写在这供参考。第一个坑是参数兼容性。S1 支持一些非标准参数迁到新服务商之后这些参数被静默忽略了不报错但行为变了。所以迁移之后必须重新跑一遍完整探针集不能只看接口通了就完事。第二个坑是并发限制。老服务商的限流很宽松新家的限流阈值低得多迁过去的当天下午我的批处理任务就全挂在了 429 上。迁移前一定要问清楚 RPM 和 TPM 的具体数值并且实测一遍。第三个坑是错误码语义不一致。同样是 400一家表示参数错误另一家可能是表示额度不足。这个只能靠实测把你业务里可能出现的边界情况都打一遍。第四个坑是输出格式的细微差异。比如 JSON 里null和空字符串的处理、多余空格的保留、流式输出里data:前缀的格式。这些在你业务代码里可能都有隐含依赖迁移之后要跑一轮端到端回归。我现在的迁移流程是四步先跑完整探针集确认能力水平再跑一遍并发压测确认限流阈值然后跑端到端业务回归确认格式兼容最后灰度 10% 流量观察一天。这套流程走下来大概两天比出问题之后再回滚省事得多。我个人在实际操作中的体会是这类问题真正难的不是发现,而是持续发现。一次测试做的再漂亮也挡不住三个月后的悄悄变化。所以与其花力气设计多么精巧的探针不如把最简单的两三个指标做成每日自动跑的看板让它替你盯着。这点成本比起你基于一个降级模型做出来的产品决策所付出的代价实在微不足道。