模型真假怎么验：指纹、知识截止与分布检测

你从某个渠道拿到一个号称是某旗舰模型的接口，用起来感觉不太对：答得太顺、知识太旧、风格也不像。这时候光靠「感觉像不像」没法下结论，得有可复现的测法。这篇不推荐你换哪家，只讲怎么测、怎么判、测出来的异常怎么往下走：三种验真手段各自适合什么场景、会在哪里误判，以及一套能直接照着跑的组合流程。

你从某个渠道拿到一个号称是某旗舰模型的接口，用起来感觉不太对：答得太顺、知识太旧、风格也不像。这时候光靠「感觉像不像」没法下结论，得有可复现的测法。验真这件事最怕的就是「我记得它以前不是这么答的」——记忆不是基准，可重复的对照才是。

这篇不推荐你换哪家，只讲怎么测、怎么判、测出来的异常怎么往下走：三种验真手段各自适合什么场景、会在哪里误判，以及一套能直接照着跑的组合流程。先把一个前提说清：验真的目标不是给出「它是不是原版」的终极答案，而是找出「它与宣称不符」的具体证据，并判断这个不符是否影响你的实际任务。

为什么「感觉不对」不能当证据

同一个模型在不同渠道可能有不同的系统提示词、温度默认值和上下文处理方式，风格差异不必然等于换了模型。渠道方为了让回答更「好用」，加一段前置指令、做一层输出清洗，都会让最终呈现出来的语气和格式变样。你把这种变样当成换模型的证据，方向就偏了。

版本迭代也会让官方自身的输出风格漂移。你脑子里的「标准答案」可能只是某个旧版本的印象，拿旧印象去否定新表现，属于自己给自己设套。另外单次问答受随机性影响大，没固定问集和固定参数的对比都不具备可重复性。所以验真第一步不是找证据，而是把变量固定下来：同一套题、同一组参数、多轮重复。

• 固定问集：把题目写死，别每次即兴出题，否则两次结果没法比
• 固定参数：温度、最大长度、是否开工具调用，尽量与对照渠道对齐
• 固定时间窗：两类调用尽量在一个短时间段内完成，避开服务波动期
• 固定记录：原始请求与原始回复都留档，只存结论等于没存
• 先说清不适用：如果待测渠道跑的是自己的业务逻辑，行为差异的解释权不在你手里

行为指纹：用固定问集做对照

行为指纹的思路是把模型当成一个「行为系统」来观察：不追求单题答对，而是看它在特定类型的请求上暴露的处理习惯。同一份问集分别打给对照渠道和待测渠道，参数尽量对齐，每道题重复几轮看稳定性。看的是模式而不是对错——它在哪类问题上系统性地给出不同处理方式，比单题答错更有信息量。

问集要覆盖几个容易暴露差异的维度，而不是随机抽题。下面这张对照表可以当作问集骨架，每类准备几道，重复跑几轮记录稳定程度。在线实测入口见站内 /tools/verify，探针设计思路见 /tools/verify#probes。

不适用的情况要提前说：待测渠道套了自己的系统提示词或做了输出后处理，指纹会被整体改写，这时候结论只能降级为「行为被改过」，而不是「换了模型」。这两件事的严重程度和后续处理完全不同，别混为一谈。

知识边界探测：找它的知识截止在哪

知识边界探测是沿时间轴设计一组问题，从较早时期往较晚时期递进，看从哪个区间开始出现系统性的不知道或含糊带过。关键在「系统性」：单道题不会不能说明边界，连续一段时间区间内都表现出一致的缺失，才更接近真实边界。

1. 搭时间轴题库沿时间轴分段出题，每段多准备几种问法，覆盖不同话题领域，避免只测一个领域造成的偏差。
2. 固定问法交叉提问同一时间点用直接问、侧面问、要求列举等多种措辞各问一遍，排除因为提问方式导致的假性「不知道」。
3. 区分「不知道」和「编」它明确说不知道，接近真实边界信号；它不知道却编出细节，是幻觉问题，不能直接当成边界证据。
4. 记录区间而不是结论写成「从某区间开始出现系统性缺失」，别写成「截止于某时间」，官方也可能在更新中调整边界。

把「知识截止」和「幻觉」分开看很重要：不知道却编，说明它在硬撑；明确说不知道，才更接近真实的边界信号。两者区别站内有专门讲幻觉的页面，值得对照着读。

• 联网检索会突破训练时的知识边界，此时探测结果不能用来判断底座版本
• 工具调用、检索增强同理，能力来自外部数据而不是模型本身
• 官方常在更新中调整截止点，单次结果只能代表当时
• 模型被明确要求不要透露能力边界时，探测会系统性失真
• 知识边界测的是能力档位，不是真伪，两者结论要分开表述

输出分布特征：看风格与统计习惯

输出分布特征看的是统计层面的可观察项：回复长度分布、列表与标题的使用倾向、标点与换行习惯、自称与称呼方式、开场与收尾的固定套路。这些特征在温度调低、问题重复时更稳定，适合做批量比对；一次两次的差异说明不了什么。实用做法是把同一批回复拿去做两两比对，看差异是集中在个别题还是整体偏移。

这类手段最容易被人为抹平：对方加一层改写或摘要就能让风格大变，所以它更适合当旁证而不是主证。它能告诉你「这批回复的统计习惯整体偏移了」，但很难单独支撑「这就是另一个模型」。相关质量检测工具见站内 /tools/quality-check 与 /tools/quality-monitor。

判断标准可以简化成一句：差异集中在个别题目上，通常是随机性；差异表现为整体偏移，才值得往下查。但整体偏移也可能是渠道侧调了参数，不是换了模型，所以下一步必须回到行为指纹和知识边界去交叉验证。

组合流程：按什么顺序跑这三类检测

三类手段不是并列随便挑一个，而是有顺序的。顺序错了会把精力浪费在被污染的指标上。推荐按下面的步骤走，每一步都有明确的判断点，跑完能留下可复核的记录。

1. 固定变量统一参数、统一问集，尽量在同一时间段内完成两类渠道的调用。先用站内 /tools/speed-test 量一条延迟基线作为参照，把服务抖动和模型差异区分开。
2. 跑行为指纹先看有没有整体性的行为改写。如果发现系统性改写，后面两类的解释力都会下降，要先把这一层排除掉再往下。
3. 跑知识边界判断能力档位是否与宣称相符。重点看缺失是系统性的还是偶发的，把「不知道」和「编」分开记录。
4. 跑输出分布用分布特征做交叉验证。差异是集中在个别题还是整体偏移，这一步负责提供旁证。
5. 比对三类结论三类结论一致时可信度较高；互相矛盾时，优先相信行为指纹和知识边界，分布特征放最后。
6. 完整留档问集、原始回复、请求参数、时间点全部存下来。没有原始记录，下次检测等于从零开始。

每种手段的误判来源清单

验真做久了会发现，大部分「测出问题了」其实是测量本身出了问题。把误判来源列清楚，能省下大量误判后的无效排查。下面按手段分开列，最后是跨手段的共同误判源。

判断类结论都要写清适用范围：这套方法用于发现异常和不一致，不用来给模型能力下绝对排名。它能回答「这里有不一致，值得进一步核」，不能回答「它到底是第几名」。另外也别把某一次的服务抖动当成型号问题——先看延迟基线和错误率，再谈模型。

测出异常之后：处理顺序与边界

测出异常不等于可以直接定性。下面这套顺序的核心逻辑是：先排除测量误差，再判断影响范围，最后才做使用决策。跳步的下场通常是拿着一份被污染的记录去质问渠道，最后发现是自己参数配错了。

1. 先复测换时间段、换问法、换调用方式再跑一遍，排除单次抖动和参数配错。如果异常消失，九成是测量问题。
2. 再定位确认异常是集中在某一类请求、某个时间段，还是全量稳定出现。这决定了它是计费或限流问题，还是模型本身的问题。
3. 然后留证把问集、原始回复、请求参数、时间戳整理成一份可复核的记录。格式口径可以参考站内 /about 里说明的检测口径与数据来源。
4. 再对照公开信息到 /models 核对公开的模型资料，到 /providers 与 /official-api 核对宣称的厂商与规格，到 /rankings 看模型可信度排行做侧面参考。这几步都是核对，不是下结论。
5. 最后才做决定是继续用、限用途用，还是停用。判断依据是异常是否影响你的实际任务，而不是「它到底是不是原版」这个无法穷尽的问题。

这套流程给的是排查顺序，不构成对任何渠道的定性。真要定性，需要平台方提供可核验的信息，比如模型版本声明、调用链路说明、异常时段的服务状态记录。个人侧能做的，是把证据整理到「可以拿去问」的程度。

还有一点常被忽略：异常的影响是分任务的。一个用于批量文本分类的场景，风格偏移几乎不影响结果；一个依赖知识时效的问答场景，边界缺失就是致命问题。所以做决定前先回到自己的任务，问一句「这个异常会不会让我答错给客户的东西」。

验真不是找出它一定是假的，而是攒够「哪里和宣称不一致」的证据，再决定这个不一致要不要紧。