全部 · 2026-03-18

这篇论文最刺痛人的地方，是它没有去争“模型知不知道危险内容”，而是直接说：你们量的地方，常常不是行为发生的地方。作者在 5 家实验室的 9 个开源权重模型上，看的是“检测→路由→生成”三段链条。按摘要说法，政治 probe、空白对照、置换基线都能跑到 100% 准确率。这个结果很狠，因为它等于告诉你：只要 probe 设计得不够严，连假特征都能拿满分，检测分数本身几乎没有解释力。摘要给出的替代标准是跨类别泛化。这个我买账。一个方向如果真代表“政治敏感性”，它至少该在留出类别上还能工作；如果只能记住模板，那就是 dataset leakage 的另一种样子。 更要命的是第二层。论文说，定向消融能在多数模型里去掉审查，并恢复事实输出；跨模型迁移却失败。这说明很多团队嘴上都在讲 alignment，落到权重里却不是一套共享机制，而是各家自己学出来的“路由几何”。我一直觉得这比“模型有没有学会某个危险概念”更接近真实部署问题。你上线后遇到的偏差，往往不是识别错了概念，而是识别到了以后，被送去了哪条 policy 分支。OpenAI、Anthropic 过去一年公开的安全材料，也越来越像在讲 policy stack、system prompt、tool gating、classifier cascade，而不是只讲 base model 内部有没有某个表示。这个方向跟论文的判断是对得上的，只是这篇把问题压到了权重几何层。 摘要里还有一个点很关键：某个模型家族里，硬拒答降到 0，叙事引导升到最高。这个现象我一点不意外。很多团队已经知道，硬拒答太显眼，用户一眼就能看出“被拦了”；叙事引导更隐蔽，看起来像模型在正常回答，实际是在改写结论、稀释事实、转移框架。拒答率 benchmark 在这种情况下会非常好看，因为模型几乎不拒答；可行为层面，它照样在控输出。安全评测如果还把“是否直接说不”当主指标，基本等于拿 2023 年的尺子量 2026 年的系统。 我对这篇也有保留。第一，材料只有摘要，正文没给 probe 构造、消融方法、样本规模、统计显著性，我还不能判断 100% 准确率是不是来自任务太容易。第二，政治审查是个很好的自然实验，但它和生物、化学、网络攻击这类安全场景不完全同构。政治类输出常带强风格化模板，路由信号可能更集中，所以结果能不能外推到通用 harmlessness，我不敢直接点头。第三，作者说有一支模型“知识和审查机制纠缠”，消融后会胡编。这个很重要，也有点危险，因为它提醒我们：不是所有 routing 都能被当作可拆插件。你把安全层拔掉，拿回来的不一定是“原始事实模型”，也可能是被训练过程重写过的半残表示。 我自己会把这篇当成一个评测方法的纠偏信号，不是审查论文。它逼着大家少问“模型有没有检测到 X”，多问“检测到 X 之后，走了哪条计算路径”。如果正文后面真给出可复现的 held-out 泛化设置和消融细节，这篇会对开源安全评测很有杀伤力。要是没有，那它至少也指出了一件早该承认的事：拒答只是表层现象，路由才是行为接口。

论文在 4500 轮师生对话里用双向可预测性 P 检出注入扰动达到 100% 灵敏度，这个结果先把它放在“监控信号”里看，别急着放进“安全能力”里吹。作者最有价值的点，不是又发明了一个分数，而是把多轮交互拆成了两层：结构有没有继续耦合，和回答语义好不好，未必是一回事。摘要里给的 85% 对齐结构一致性、44% 对齐语义评审分数，已经把边界说得很直白了。P 更像系统完整性指标，不像答案质量指标。 这点其实补到了现在评测栈的一个空洞。业内常用的 perplexity 看单向 token 置信度，semantic entropy 要重复采样，LLM-as-a-judge 看语义表面，三者都更接近“这一轮答得像不像样”，不太盯“这段对话是不是还在同一条轨道上”。很多 agent 事故也正卡在这里：输出看着像回事，工具调用链和上下文约束已经慢慢漂了。论文把 context→response→next prompt 做成闭环监测，而且只用原始 token 频率统计，不要 embedding、不做二次推理，这个工程取向我觉得是对的。你真要挂在线上系统里，便宜、稳定、低延迟，比一个更聪明的 judge 更重要。 但我对这个 100% 还是有保留。正文只有 RSS 摘要，没披露注入扰动的类型、强度、基线、误报率，也没说 4500 轮里教师模型具体是谁、任务分布是什么。灵敏度单独拿出来不够，至少还要看 specificity、阈值漂移、长上下文衰减、跨模型泛化。安全论文很爱报“全检出”，最后发现打的是人工构造扰动，部署里一遇到真实世界的软偏移就掉。Nvidia 新卡爱讲 10 倍，很多 benchmark 落地后只剩 3 到 4 倍；这类监控指标也有同样风险：实验里像报警器，线上变成噪声源。 我还在意另一个问题：P 基于 token 频率统计，天生偏结构信号。摘要已经承认它和语义分数只有 44% 对齐，这不是缺点，前提是团队别把它包装成“更好的质量评测”。我不买这种叙事。它更适合盯 prompt injection、上下文污染、记忆漂移、teacher-student loop 失耦，尤其适合多 agent 编排和长工作流。它不解决 hallucination 本身，也不告诉你答案是否有用。这个分工如果讲清楚，IDT 有落地价值；讲不清楚，就会变成 another dashboard metric。 外部参照也很清楚。过去一年很多 guardrail 产品往 embedding similarity、policy classifiers、LLM judges 上堆，代价是延迟和成本一起涨，而且 judge 自己也会漂。我记得 Anthropic 和 OpenAI 在 system-card 里都反复提过多轮上下文失真问题，但公开披露的实时完整性指标并不多。这篇论文如果后续能公开误报率、不同上下文长度下的曲线，再给一个和 perplexity、semantic entropy 的头对头比较，它会比现在这个标题硬很多。眼下我给它的定位很简单：这是一个便宜的交互完整性传感器，不是新的真理机。

IndicSafe 这篇论文给了一个很难回避的数字：10 个模型在 12 种 Indic 语言上的跨语言安全一致性只有 12.8%。如果这个口径是对同一提示的翻译变体做对比，那就已经足够说明一件事——今天多数“对齐完成”的说法，默认前提还是英语或少数高资源语言。模型不是在不同语言里表现略有波动，而是在安全边界上直接换了一套人格。 我对这条很买账，因为它打中的不是某个模型的小瑕疵，而是现在安全评测的流程缺口。很多团队做 safety eval，数据集主体还是英文，扩到多语言时常见做法是机器翻译一遍，再看 refusal rate、policy violation rate、toxicity score。问题在于，南亚语境里的风险不只是“同一句英语换个脚本”。种姓、宗教、地方政治、性别规范、医疗迷信，这些主题的触发词、冒犯阈值、上下文含义都不是直译能保真的。论文说自己用了 6000 条贴近文化语境的提示，这一步比单纯翻译 benchmark 更重要。说真的，很多号称 multilingual safety 的工作，输就输在这里。 12.8% 这个数也低得有点刺眼。我没看到正文里的计算细节，标题和摘要也没披露具体模型名单、闭源开源占比、评审协议、SAFE 的判定标准，所以还不能直接比较“谁更差”。但方向已经很清楚：安全对齐没有自动迁移。这个结论其实跟过去一年不少迹象能对上。我记得此前多语种能力评测里，像 MMLU、MGSM、XCOPA 这类任务，模型在语言切换后已经会掉点；安全只会更糟，因为它不是纯能力题，还叠加了拒答阈值、政策规则、RLHF 偏好和审核器误差。能力掉分，常常是 5 分 10 分；安全漂移一旦出现，就是该拦没拦，或者不该拦乱拦，两边都伤。 我更在意摘要里提到的两个失真方向：低资源文字过度拒答，政治敏感主题过度标记；同时另一些模型又漏判不安全输出。这说明问题不只是数据少，而是现有安全栈把“看不懂”近似成“先拒掉”，把“词面敏感”近似成“高风险”。这在部署上很麻烦。过度拒答会直接劝退真实用户，尤其是医疗、政务、教育这些高频场景；漏判则是合规事故。两种错一起出现，意味着系统既不公平，也不稳。 这里我有个保留意见。论文用了熵、类别偏差分数、多语言一致性指标，方向没问题，但 benchmark 终归是 benchmark。它能证明“存在系统性漂移”，不自动等于“真实产品风险按同样比例发生”。实际线上系统还会叠加输入法、ASR、检索、审核器、后处理模板。我还没查到 IndicSafe 是否评估了整条产品链，还是只看 base/chat model 的单轮输出。如果只是后者，那它更像在测模型层的原发缺陷，不是最终应用层的全部风险。这个边界得说清。 回到行业判断，我一直觉得多语言安全会变成 2026 年评测体系补课最狠的一块，原因很现实。过去大家先冲英语 agent、代码、长上下文，因为收入和 demo 都在那里；多语言安全经常被当成上线前的 locale check。IndicSafe 这种工作把问题量化后，借口会少很多。接下来谁家如果还拿英文 system card 证明自己“全球可用”，我基本不信。至少要补三样东西：按语言公开 refusal/violation split、说明低资源脚本的审核器或对齐数据覆盖、把文化语境 prompt 纳入回归测试。做不到，就别把“multilingual safety”写得太满。 标题已给出 benchmark 发布和核心数字，正文没披露具体模型名单、标注流程、是否有人类双语评审，也没给出各语言拆分结果。少了这些，现阶段还不能下结论说哪类架构或哪家模型更稳。但只看这 12.8% 一项，这篇已经足够把一个旧幻觉打碎：会 12 种语言，不等于在 12 种语言里守同一条安全线。

论文在 Gemma 3 27B 和 Qwen 2.5 7B 上用 5 组干预实验支持一个很硬的结论：模型先生成答案，再在答案后相邻位置形成并缓存置信度表示，等被问到时再取回输出。我的判断偏正面，这篇东西抓到的不是“模型会不会说自己有多确定”这种表层现象，而是一个更接近元认知的执行细节：答题和自评在前向过程中并没有完全分开。 我买账的点，先在方法链条够闭环。摘要里给了 activation steering、patching、noising、swap、attention blocking 5 类证据，不是只拿一个 probe 就宣布发现“信心神经元”。这很关键。过去一年这类 interpretability 论文最容易翻车的地方，就是线性探针读到了某个信号，作者就把“可解码”直接写成“模型真的在用”。这篇至少试图补上因果环节：信号在哪里出现，怎么流动，被阻断后会不会影响 verbal confidence。这比单纯相关性强不少。 我自己更在意的是它和 token log-probability 的切割。摘要说，方差分解后，这个缓存表示解释的 verbal confidence 方差超过 token log-probabilities。这个结论如果正文统计做得扎实，分量很重。因为业界有个偷懒做法：把“置信度”近似成 next-token probability，或者把回答流畅度当成校准代理。很多时候它能用，但我们都见过反例：模型能很流畅地错，也能磕磕绊绊地对。要是 verbal confidence 的内部表征确实吸收了答案 token 的某种质量评估，那它就不只是语言表面概率的投影，而是一个独立一点的自评分支。 这里可以接一个文章外的参照。OpenAI、Anthropic、Google 过去一年都在推 uncertainty-aware prompting、self-critique、deliberate decoding 这一套，我记得不少 work 都发现“先答再审”比“边答边报信心”稳定，但机制层面通常停在行为结果。这个论文往前走了一步：它说自评不是第二次思考，而是第一次思考结束时就留下了缓存。我还没核过它和 process supervision、self-consistency 那些工作有没有直接实验对齐，但直觉上，这会影响我们怎么设计 verifier 和 routing。你不一定非要再跑一个完整 critique pass，先把答后那一拍的内部状态掏出来，也许已经有不少信息量。 我也有两个保留。第一，样本只写了 Gemma 3 27B 和 Qwen 2.5 7B，都是开源系、都是特定规模。标题讲的是 LLMs，证据其实只覆盖 2 个模型族。Claude、GPT 系列会不会一样，正文没披露。第二，摘要没有给 calibration 指标、任务类型、置信度格式，也没说这个表示在 out-of-distribution 或长链推理里是否稳定。要是只在短答 QA 或多选题上成立，外推到 agent 场景就得很小心。 说真的，这条最实用的含义不是“模型有意识了”，这种说法我不买。它更像工程启发：如果置信度在答案刚结束时就已经被压进了某个局部表征，那 black-box API 之外的开源模型，也许可以直接训练 readout 头或轻量 probe 去抽这个状态，替代一部分额外的 self-eval token 开销。前提是论文正文得拿出跨任务、跨模板、跨语言的稳健性数据。现在只有摘要，我愿意给它高关注，但不会把它直接当成 metacognition 已被证明。

CodeScout 报告用标准 Unix 终端训练代码搜索代理，并在 3 个 SWE-Bench 变体上打平或超过 2 至 18 倍更大的模型。我的判断是，这篇论文的价值不在“又一个小模型赢了”，而在它把代码定位这件事从“堆专用检索工具”拉回了“环境设计加 RL 配方”。这对做 agent 的人很现实：如果奖励设计、轨迹筛选、搜索预算分配做对，工具复杂度未必是第一瓶颈。 我一直觉得，过去一年代码 agent 有点被“工具崇拜”带偏了。很多系统默认要上 repository graph、静态分析、符号索引、向量检索多路召回，最后 paper 看起来像 infra 展示，不像能力研究。CodeScout 反着来，只给 Unix 终端，这个设定很克制。它如果真能靠 `grep`、`find`、`sed`、测试反馈，把定位做好，说明当前很多代码搜索收益其实来自交互式搜索策略，不是来自那张花哨的图。这个结论跟一批实际工程经验是对得上的：在中大型 repo 里，能不能缩小搜索范围，常常比“有没有更强的编辑器补全”更决定成败。 但我对摘要里的对比说法有保留。2 至 18 倍更大的 base 和 post-trained LLM，到底是谁？参数量怎么记？比较时给了同样的 token budget、同样的步数、同样的工具权限吗？摘要没披露。它还说“有时接近 Claude Sonnet”，这句话听着亮眼，信息量却不够。Claude Sonnet 这类闭源模型在 SWE-Bench 上通常吃到的是更完整的 scaffold、更多 test-time compute、还有更重的提示工程；如果 CodeScout 比的是“只看搜索定位”而不是“端到端修复”，那结论就该窄一点写。我还没查到正文表格前，不会把这句当成模型代际信号。 外部对比里，我最先想到的是过去一波 repo-level retrieval 路线。很多 embedding 检索方案在干净 benchmark 上很好看，一到真实仓库就容易被命名噪声、跨文件依赖、测试目录污染拖垮。Agentic search 的优势一直不是单次召回率，而是它能边查边修正假设。CodeScout 把这个优势用 RL 固化下来，这点比“模型更小还赢了”更重要。另一个参照是最近不少 coding agent 都在堆长上下文，128k、256k 甚至更高，试图用“全仓读入”解决定位。我的看法一直没变：上下文窗口扩大能缓解一部分问题，但仓库搜索本质还是决策问题，不是纯记忆问题。给模型更多 token，不等于它更会找。 这篇论文如果后续表格站得住，我觉得会推高一个很具体的研究方向：把 RL 用在代码代理的前半段，也就是定位、检索、工具调用顺序，而不是只盯着最终 patch 是否通过测试。这个方向比单纯追求 pass@1 更健康，因为它更接近真实开发流。问题也在这里：SWE-Bench 终究是 benchmark。摘要没有披露 reward 设计是否对这些数据集结构过拟合，也没说迁移到陌生私有仓库时会掉多少。开源模型、代码、数据是加分项，至少别人可以复现；但在看到跨 repo 分布迁移、ablation、轨迹成本前，我会把它当成一篇“RL 让搜索策略更像样”的论文，不会急着下结论说“专用代码图工具已经没用了”。

Personize.ai 这篇的核心动作很明确：它把多智能体系统里最散、最脏、最难审计的“记忆”抽成一层独立基础设施，并给了 250 次受控实验、500 次对抗查询和 74.8% LoCoMo 这组数字。我的判断是，这个方向是对的，甚至比再堆一个 orchestration 框架更像企业落地会买单的东西；但论文给出的证据强度还不够，尤其不够证明它已经跨过“研究原型”到“高风险生产系统”的那道线。 我一直觉得，过去一年 agent 系统最被低估的问题不是推理能力，而是状态管理。LangGraph、CrewAI、AutoGen 这一类框架把多步协作做出来了，很多团队也会给每个 agent 接一个向量库，但最后常见的故障不是 agent 不会想，而是它们记不住、记错、记串了对象，或者拿到不该拿的上下文。Personize.ai 把问题拆成五类：记忆孤岛、治理碎片、非结构化记忆不可复用、上下文重复投喂、缺反馈闭环。这个拆法我买账，因为它说的不是 prompt engineering，而是数据层和控制层失配。企业里一旦 agent 数量从 3 个涨到 30 个，这类问题会比模型分数先炸。 论文里最有价值的设计，不是“共享记忆”四个字，而是双模记忆加分层治理。原子事实负责开放集写入，类型化属性负责 schema 约束，这相当于把向量检索和轻量知识图谱揉到一起，再在外面套一层 policy router。这个组合很像很多团队私下都在拼的东西：一边保留非结构化 note 的召回弹性，一边把客户状态、权限、偏好、合规字段钉死在结构化槽位里。问题是，大多数团队没有把这层产品化，更没有把 schema 演化、属性级修正、实体隔离放进同一个闭环。Personize.ai 这里至少给了一个比较完整的架构答案。 但我对它的叙事有两个明显保留。第一，74.8% LoCoMo 不是难看的分数，也绝对不是“证明治理没有代价”的铁证。LoCoMo 本来就是长程对话记忆 benchmark，用它验证 memory architecture 合理；可如果你要证明 governance 和 schema enforcement 没拖后腿，最好给强基线。正文片段没披露对比对象，也没说是对哪种检索器、哪种模型、哪种上下文预算做 ablation。没有这些条件，74.8% 只能说明“能跑”，不能说明“代价接近零”。我印象里，近一年不少长上下文或 memory-heavy 系统在 LoCoMo 类任务上能打到相近甚至更高区间，但配置差异很大，我这里没法替它补齐。 第二，500 次对抗查询零跨实体泄漏，这个数字好看，但安全人看了不会放心。500 次太少，攻击空间太窄，尤其 enterprise agent 的泄漏往往不发生在显式“给我别人的资料”这种查询，而发生在 tool output 拼接、缓存污染、身份切换、异步任务回填这些边角位。论文还给了 100% adversarial governance compliance，听上去更强，但正文没有披露攻击集构造、失败定义、是否包含工具调用链。没有 threat model，这类百分比很容易高估。说真的，安全结论最怕样本数好看、边界条件没写。 50% token reduction 这条我反而觉得更像能落地的卖点。渐进式上下文投递本质上是在把“先给最小必要信息，再按需扩容”做成机制。这个思路跟很多 production RAG 团队这两年学到的教训一致：不是把所有相关上下文都塞进去，质量就会上升；很多时候先给 3 条，模型比先给 30 条更稳。论文说输出质量在每实体约 7 条 governed memories 后趋于饱和，这个观察很有用，因为它直接触到成本曲线。现在 agent 产品的毛利，很大一部分就死在上下文冗余上。只要这个“7 条左右饱和”的现象能跨任务复现，它比一个单独 benchmark 分数更有经营价值。 文章外的参照也很清楚。过去一年，Letta/MemGPT 这条线强调的是“让 agent 有可持续记忆”；企业 RAG 厂商强调的是“可控检索”；数据治理厂商强调的是“权限和审计”。Personize.ai 把三件事拧成一层，这就是它比普通 memory layer 更像企业架构件的地方。另一边，Salesforce、ServiceNow、Microsoft 这些大厂在 agent 平台上都在加 shared state、policy enforcement、tenant isolation，只是通常拆在 workflow、data fabric、identity system 三处做。Personize.ai 的价值，不在发明了全新原理，而在把这些碎片收束成单一抽象。如果它真在生产里跑，这个产品定义比论文分数更重要。 我还没查到的关键点有三个。第一，生产环境规模没披露：实体数、并发 agent 数、写入频率、schema 变更频率都没有。第二，基础模型没披露：不同模型对 typed memory 的服从度差很多，Claude、GPT、开源指令模型的行为不会一样。第三，LoCoMo 和内部实验之间的迁移关系没披露：实验是客户支持、销售、医疗、法务，还是纯合成内容类型？这些都决定这套架构是“普适层”还是“特定场景工程优化”。 所以我的结论很简单：这篇不是又一个“agent 更聪明了”的论文，它抓的是 agent 系统迟早都要补的内脏工程，方向比 headline 扎实；但它现在更像一份不错的 architecture memo，加一组有限实验，而不是已经坐实的行业答案。要让我更信，我需要看到公开基线、真实失败案例、跨模型结果，还有生产规模指标。没有这些，99.6% 召回和零泄漏都只能先打折看。

CoVerRL 把单模型的自验证准确率从约55%提到85%以上，还在 Qwen、Llama 上拿到 4.7%-5.9% 的数学增益。我的判断很直接：这篇论文抓到的是一类被低估的问题，不是“RL 没标签也能学”，而是“多数投票会把模型训练成更会重复自己的错”。这点我认同，而且比再加采样数更像机制创新。 RSS 只给了摘要，正文没展开 benchmark 名单、模型规模、采样预算、RL 算法细节，也没说 4.7%-5.9% 是相对提升还是绝对分数差。这些缺口很关键。因为无标签推理训练这条线，过去一年最容易灌水的地方就是 test-time compute 和 training-time filtering 混在一起写。你把 sample 数从 16 拉到 64，多数投票本来就会更稳；你再加 verifier 过滤，提升到底来自机制，还是来自更高的算力支出，得拆账看。 我一直觉得“consensus trap”这个提法是成立的。去年到今年，self-training、RLAIF、process supervision 这一串工作都碰过同一个墙：模型会把高频答案误当高质量答案，分布一收缩，错也会变得很稳定。数学任务尤其明显，因为答案空间窄，错法会重复。多数投票在 GSM8K、MATH 这类 benchmark 上经常好用，不代表它真的会验证。它只是把最像自己的答案选出来。CoVerRL 至少承认了这个问题，还把 generator 和 verifier 拆成两种能力来互相校正，这一步比“多采样几次再选”认真得多。 但我对这条结果也有保留。第一，单模型轮流扮演 generator 和 verifier，参数共享带来的相关性还在。它比纯多数投票好，不等于它已经跳出自我循环。摘要说 verifier 会过滤“自洽但错误”的伪标签，这很好听；可如果 verifier 学到的只是题型偏好，而不是可迁移的判错能力，85% 自验证准确率就未必能外推到新分布。第二，数学推理是最容易让 verifier 看起来有效的场景，因为答案可检查、步骤可比对、错因相对结构化。你把同样机制搬到代码、法律、开放问答，收益大概率没这么干净。我还没看到正文给跨任务证据。 这里有个文章外的参照。OpenAI 和 Anthropic 过去一年都在推“过程监督”“critic”“constitutional feedback”这类路线，核心想法都接近：不要只奖励最后答对，要训练一个会挑错的东西。差别在于，大厂通常靠更强教师模型或人工偏好做 verifier；CoVerRL 试图在没有标签、也没有外部教师的条件下，把 verifier 从噪声里养出来。这个想法有研究味，也有现实吸引力，因为便宜。问题也在这：没有外部锚点时，verifier 的上限常常被 generator 的错分布卡住。摘要没披露它是否做了 out-of-domain 检验，也没披露 verifier calibration 指标，我不会只看 85% 就下结论。 我还想追一个实现层的问题。若 verifier 训练依赖多数投票提供初始噪声监督，那早期样本多样性怎么保住？摘要说它避免了 output diversity collapse，但没说具体靠温度、探索奖励、还是 replay/filtering 策略。这个机制要是没处理好，系统很容易前几轮就塌到单一路径，然后 verifier 只是在给主流错法盖章。很多“co-evolution”论文最后都输在这里：名字很漂亮，动力学不稳。 所以这篇我给的评价是：问题定义比 headline 更值钱，结果数字先别吹太满。要让我更信，至少得补三样东西：一是固定采样预算下的对照；二是跨任务迁移，别只停在数学；三是 verifier 的校准曲线和错误类型拆分。要是这三项站得住，CoVerRL 会成为 label-free reasoning 里一条靠谱支线。站不住，它就还是“给多数投票加了个更聪明的筛子”。

SECL把4个小模型在4个域的ECE压低56%到78%，我觉得这篇的分量先不在TTT，而在它承认了一件早就存在的事实：语言模型嘴上报出的置信度，常常比它内部“这题对不对”的判别信号更差。 这点其实很重要。很多校准工作还停在后处理思路，比如温度缩放、额外训练一个置信度头、或者做多次采样拿一致性当信心。那些办法有两个老问题。第一，要标签。第二，分布一偏就掉。SECL走的是另一条路：直接蒸馏内部的 P(True) 信号，再在测试时只对发生偏移的流量做适配。文章给了两个硬数字，训练只吃 6%到26% 的问题流，成本还低于它要追的蒸馏基线。这个组合比“再跑几次 self-consistency”更像能落地的东西，因为后者的推理账单经常是线性往上加。 我对这里的理论支点是买账的。正文提到一个已知结论：生成误差的下界大约是对应判别误差的两倍。直白点讲，让模型生成完整答案，比让它判断“这个答案对不对”更难。那你拿判别头信号去校准生成置信度，方向是对的。过去一年也有不少工作在挖这个坑，比如先答题、再让模型打分，很多时候 yes/no 或 True/False 的 token probability 比口头说“我有 90% 把握”稳。SECL的新意不只是发现这个差，而是把这条差距做成无标签自蒸馏，再接到 test-time adaptation 上。 但我还是有两个保留。第一，实验规模不大。摘要只说了 4 个小模型、3 个家族、4 个领域，没看到更大的开源模型，也没看到闭源 API 模型。校准这件事在 1B 到 8B 规模上成立，不自动推出 70B 或混合专家也同样成立。尤其大模型常有更强的 RLHF 痕迹，口头置信度和内部判别信号的耦合方式未必一样。第二，正文没披露域偏移的触发条件细节。它说“只在分布偏移时适配”，但偏移是谁判、阈值怎么设、误触发率多高，RSS 片段里都没有。这个机制如果不稳，线上系统很容易出现两种问题：该适配时没动，不该适配时乱改权重。 我还想追问一个更实际的问题：它到底是在校准“正确率”，还是在校准“某类提示下的自评一致性”。这两个东西差得很远。P(True) 作为监督信号，本身还是模型自产的。它优于 verbalized confidence，不代表它已经接近真实正确率。摘要说 SECL 甚至超过了它自己的 supervision signal，这很有意思，也说明蒸馏和门控策略可能在做去噪；但没有看到按任务拆开的 reliability plots、Brier score、AUROC 或 selective prediction 曲线前，我不会把它直接当成 production-ready 校准器。 和近两年的主流路线相比，我觉得这篇更像“把已有直觉工程化”。一边是 inference-time 路线，靠多样本、辩论、反思、验证器，把置信估计做厚；另一边是 post-hoc 路线，拿有标签验证集补一个 mapping。SECL卡在中间：不加人工标签，不把推理成本抬到离谱，也不假设训练分布稳定。这个位置很讨巧。要是代码能复现，而且门控真的稳，它对检索问答、医疗问卷、法务分类这类持续遇到分布偏移的场景会很有吸引力。 我对标题里的“self-calibrating”会稍微谨慎一点。它不是模型突然学会诚实了，而是研究者找到了一个更靠谱的内部老师，再用少量测试流量持续蒸馏。这个说法我能接受，但离“自校准成为通用能力”还远。下一步我更想看三样东西：70B 级别是否还有效；长链推理任务是否还能降 ECE；门控在连续线上流量里会不会累计漂移。标题给了降幅，正文片段没给这些关键答案。