论文 · 2026-03-31

FGR-ColBERT 在 MS MARCO 上拿到 64.5 的 token-level F1，延迟只比原版 ColBERT 多 1.12 倍。我的判断很直接：这篇东西的价值，不在“110M 打过 27B”这种标题，而在它把细粒度证据对齐从后处理搬回了检索函数。对做 RAG 的人，这比又一个 reranker 小涨点数更实用，因为它碰的是系统结构，不只是 benchmark 分数。 ColBERT 这条线本来就适合做这种事。它靠 late interaction 保留 token 级匹配，比 DPR 这类单向量检索器更容易承接“哪些 token 真相关”这类监督。我一直觉得，过去一年很多团队把检索做差了，不是因为 embedding 不够强，而是把证据抽取外包给了第二个大模型：先召回，再重排，再让 LLM 找 span。这样做当然能提效果，但延迟、成本、级联失败率都会上去。现在这篇 paper 给了一个更像产品工程的答案：先用大模型蒸馏 supervision，再让小检索器学会在第一步就吐出更细的相关性信号。这和去年一批“小模型吃大模型偏好数据”的思路是一致的，只是它落在 retrieval，而不是聊天模型。 我对 64.5 对 62.8 这个对比会保留一点警觉。标题给了 Gemma 2 27B 的 token-level F1，但正文摘录没披露评测 protocol、prompt 形式、证据标注口径，也没说 Gemma 2 是直接生成 span、抽取 token，还是经某种后处理对齐。少了这些条件，“245 倍更小还更强”只能先当方向性信号，不能直接当部署结论。MS MARCO 也有它的局限：它是经典检索集，分布相对干净，跟企业知识库、长文档、多跳问答、表格混排差得很远。我自己更想看的是 LoTTE、BEIR，或者真实 FAQ + policy corpus 上的表现。文章目前没给。 还有一个现实问题：token-level F1 提升，未必自动转成端到端问答收益。很多 RAG pipeline 的瓶颈不在“有没有找到正确 token”，而在 chunk 切分、文档去重、权限过滤、引用格式、生成模型是否肯老实引用。也就是说，FGR-ColBERT 比较像把 retriever 从“找文档”往“找证据”推了一步，这一步很对，但离生产里的 citation-grade grounding 还差系统工程。说真的，我愿意把它看成对 ColBERT 路线的一次很像样的加固，而不是“LLM reranker 可以退休了”。如果后续全文能给出 teacher 模型、蒸馏损失、跨数据集泛化和吞吐细节，这篇会更站得住。

论文用 3754 个样本测试 4 个模型先预测拒答，再在新上下文作答，Claude Sonnet 4.5 准确率到 95.7%。我对这条的第一判断是：它测到的更像“拒答机制的可读性”，不是很多人会顺手理解成的“安全边界理解力”。两者差很远。一个模型能提前说出自己会不会拒答，说明它内部对拒答触发条件有稳定表征；这不自动说明它对伤害、合法性、语境细节有更深理解。 这点从论文自己给的数据就能看出来。作者用 d' 量自省敏感度，4 个模型落在 2.4 到 3.5，数值不低；可一到 safety boundary，敏感度就明显下滑，武器请求最难预测。这个结果很关键。因为部署里最贵的错误，从来不是“明显违法内容被拦住了”，而是边界样本：双用途生化、武器部件、红队化改写、医学与伤害场景混杂。这些地方模型如果只是读到了“我大概率会拒答”，那只是把 policy surface 暴露出来，不是把 policy reasoning 做扎实了。 我一直觉得，行业里容易把这类结果讲得太满。Anthropic 这两年在 constitutional 与 refusal consistency 上确实做得比很多同行稳，Sonnet 4.5 比 Sonnet 4 从 93.0% 提到 95.7%，说明新一代在这件事上有代际改进。OpenAI 这边 GPT-5.2 只有 88.9%，而且文中直接说 behavior 更波动。Meta 的 Llama 3.1 405B 到了 80.0%，问题不只是准确率低，还是 refusal bias 强、校准差。这个对开源部署很现实：你未必缺一个“会拒答”的模型，你更常缺一个“知道自己何时会误拒、误放”的模型。校准差的系统最难接进生产，因为阈值怎么设都会亏一边。 这里有个文章外的背景，我觉得需要补上。过去一年不少团队在做 self-evaluation、uncertainty estimation、LLM-as-a-judge，结论经常类似：模型对“输出质量”自评不稳定，但对“格式约束、工具是否可用、简单 policy 是否触发”这类窄任务，自评会好很多。我没逐篇去核实这篇引用链，但大方向很一致。所以这篇结果不算反常，反而说明拒答已经越来越像一个显式子系统，或者至少像一层能被上层表征读取的 gating。你可以把它类比成分类器能读出自己 decision boundary 的局部信号，而不是哲学意义上的自知。 我对“高置信度样本可到 98.3%，因此可做安全路由”这句结论有点保留。第一，正文没披露高置信样本覆盖率。如果只覆盖 40% 请求，98.3% 就很难直接转成业务价值；如果覆盖 90%，那意义完全不同。第二，fresh context 的实验设定比真实产品干净。线上用户会连续追问、改写、贴上下文、夹带工具调用结果，拒答阈值常被多轮状态拖动。单轮里能自知，不等于多轮 agent 里还能自知。第三，论文只说 weapons 最难，但没给更细的错误拆分；我还没看到 false allow 和 false refuse 在各主题上的占比，这决定了路由系统到底该接人工复核，还是接更强 policy model。 尽管我有这些保留，这篇还是有实操价值。它给安全工程一个很朴素的方向：先别把“模型自省”想成玄学能力，先把它当成可用信号。若一个模型像 Sonnet 4.5 这样校准相对稳，你可以把 refusal self-prediction 当成前置特征，配合 topic classifier、user history、tool risk score 做分流。高置信拒答就直接拦；低置信样本送更贵模型或人工；高置信放行也别裸放，先限定工具权限。这个设计比单靠最终回答分类，通常便宜一拍，因为你在生成前就能决定是否值得继续烧 token。 还有一层更深的含义。模型若能稳定预测自己会不会拒答，说明安全训练留下的痕迹已经深入到可报告层。对模型供应商这是好消息，因为可监控；对红队也是好消息，因为可探测。攻击者可以反过来 probing 哪类表述最接近边界，再做改写搜索。所以“模型会自知拒答”不只是 safety feature，也是在泄露 policy geometry。供应商若把这类信号产品化，我会很在意它是否限流、是否加噪、是否只在 server-side 用，不然它会变成越狱调参器。 所以我对这篇的总体判断是：结果不错，但别上升成“模型理解自己的伦理边界”。它更扎实地说明了一件工程事实——前沿闭源模型的拒答行为正在变得更一致、更可校准，也更容易被系统拿来做路由。离“可靠安全判断”还差一截，差的正是论文里表现最弱的那块：边界样本。

论文声称模型内部编码了 3 个情境隐私参数，还把它们做到了线性可分和功能独立。我的判断很直接：这条如果成立，打脸的不是“LLM 不理解隐私”这类粗说法，打脸的是另一种更常见的偷懒叙事——只要模型表征里有规范，行为上迟早会跟上。这里作者给出的恰好是反例：表征在，执行不在。 这个结论跟过去一年不少可解释性结果是接上的。我们已经见过 toxicity、refusal、persona、语言切换这类属性能在激活空间里被 probe 出来，甚至能被 steering 一把拉动。问题一直不是“有没有这个方向”，而是“这个方向能不能穿透解码、RLHF、系统提示、工具调用和长上下文干扰，稳定变成行为”。这篇 paper 把同样的问题搬到 contextual privacy 上，我觉得是有价值的，因为隐私比一般 safety 标签更结构化：信息类型、接收者、传输原则，本来就不是一个单标签分类任务。 我比较买账的一点，是作者没有把隐私当成一个总开关，而是拆成 3 个 CI 维度去 steer。这个设计比 monolithic steering 更像工程方案。你把“该不该说”拆成“什么信息、对谁说、在什么传输条件下说”，控制面会清楚很多。OpenAI、Anthropic 这几年在 policy 层也一直是这么长出来的：不是一个“安全”分数包打天下，而是场景、对象、意图、工具权限分层判定。回到模型内部，这篇文章等于在说，表示空间里也许本来就长成了这种结构。 但我对摘要里的强结论还是有保留。第一，正文没披露 probe 的基线、层位、模型规模、AUC 或 accuracy，也没说 steering 的副作用有多大。少了这些数字，“更有效、更可预测”只能先当方向判断，不能当结论。第二，线性可分不等于模型在真实推理时优先使用这组特征。可解释性社区这几年最容易被误读的一点就在这：你能读出一个概念，不代表模型在做决定时靠它。第三，我还没看到 adversarial 设定。隐私泄露往往出在多跳诱导、角色扮演、工具回填、检索拼接，不是单轮问答里一句“不该说”这么简单。如果作者只测干净 prompt，这个结果离部署还差一截。 还有一个更硬的外部背景。企业里现在上 RAG、agent、客服自动化，隐私泄露很多时候不是 base model 价值观崩了，而是 retrieval scope、memory、权限边界、日志留存出了问题。模型内部就算有完整 CI 表征，也挡不住系统把不该给它的东西先喂进上下文。所以这篇 paper 我会把它看成“model-side control”的证据，不会把它误读成“privacy alignment 快解决了”。 我自己最想看的是两组补充实验。第一组，给出不同模型家族上的定量对比，像 Llama、Qwen、Claude-class 开源代理模型，看看这个 3 维结构是不是普遍存在，还是只在某些 instruction-tuned 模型里明显。第二组，测 steering 后的效用折损：拒答率升多少，任务完成率掉多少，长上下文和工具调用下还能不能稳。如果这些数据站得住，这条就不只是“又一个 probe 论文”，而是能进 privacy guardrail 工具链的东西。现在只有摘要信息，我愿意给方向高分，结论先保守。

论文用 SNEAK 测了一个很少被单独拎出来的能力：模型在给定秘密词后，能否同时让盟友读懂、又不让对手猜中；文摘给出的硬结果是，人类最高分可到已测模型的 4 倍。 我对这条的判断很直接：这不是“小众博弈任务”，这是多代理系统迟早会撞上的基本功。一个 agent 只要开始帮人谈判、做采购、跑安全响应、协调多个工具，就会碰到信息分层。哪些信息该给内部工具，哪些只能给特定协作者，哪些给了会让旁观者反推出敏感状态，这些都不是传统 benchmark 里的“答对题”能覆盖的。SWE-bench、MMLU、GPQA 这类分数再高，也不能自动外推到选择性传递信息。这个外推，行业里一直做得太顺手了。 我觉得 SNEAK 的价值，在于它把能力拆成了 utility 和 leakage 两个方向。这个拆法比笼统说“安全”更实用。很多模型在公开评测里显得会协作，原因是任务默认所有参与方共享上下文；一旦信息不对称，模型常会犯两个相反错误：要么提示太弱，盟友接不住；要么提示太直，旁观者一眼看穿。文摘没披露具体模型名单、分数分布、候选词规模，也没说 ally 和 chameleon 用的是规则器、分类器，还是另一个 LLM 评委，所以我还不能判断这个 benchmark 的噪声有多大。 我自己有个保留意见：这类任务很容易被“评测器偏好”绑架。若 chameleon 本身就是某个强模型，它猜得出的，不等于真实攻击者都猜得出；反过来，若 ally 太弱，又会把本来有效的隐晦表达判成失败。去年不少 agent benchmark 就吃过这个亏，换个 judge model，排名能明显变。我还没看到论文正文里的鲁棒性设计，像多评委一致性、人类复核比例、候选集大小变化后的稳定性，这些都很关键。 但方向我买账。过去一年大家把多代理讨论得很热，焦点多放在规划、工具调用、长上下文和角色分工。说真的，选择性沟通才更接近真实组织。人类能领先 4 倍，不像是 prompt 小修小补能补上的差距，更像模型还缺一层“按对象建模对方知识状态”的机制。要补这个洞，光靠 RLHF 我不太信，训练里大概要显式加入 epistemic reasoning、受限信道博弈，或者带对手建模的 self-play。标题已经给出 benchmark 方向，正文没披露这些训练启发有没有展开。

论文给出的硬数字是：在 τ²-verified Airlines 基准里，涉及状态变更的工具调用轨迹中，8%–17% 出现 latent failure，终态正确，但必需策略检查被跳过。这个比例不低。你把它放进任何真实业务流里看，都会觉得刺眼：如果一个订票、退款、改签 agent 每 100 次有 8 到 17 次靠“运气好”走对结果，那它不是稳，只是暂时没出事故。 我对这篇的判断很直接：它补的不是一个 safety 小角落，而是 agent 评测的主漏洞。过去一年不少 agent benchmark 还是把 task success、final state match、甚至 user-rated success 当主指标。WebArena 这类环境偏网页操作，τ-bench 一类偏工具工作流，大家都爱报成功率，因为好量化，也好讲故事。问题是业务系统不是电子游戏。只看终态，你只能发现“做错了”；你看不到“这次碰巧做对，但决策依据不够”。Near-Miss 把这层翻出来，价值就在这里。 这件事其实和过程监督那条线是同一个方向。OpenAI 早先做数学过程监督，核心直觉就是 final answer 对，不代表推理过程可靠。Agent 场景里，这个问题更严重，因为它会改数据库、发邮件、下工单、改订单。错一道数学题，损失是 benchmark 分数；跳过一个 eligibility check 再去执行 mutating tool，损失是审计风险。论文把“过程错但结果对”形式化成指标，我觉得很对路。 我也有保留。正文只有 RSS 摘要，没有披露样本量、policy 复杂度分层、不同模型的具体区间，也没说 8%–17% 是按 trajectory 计还是按 mutating episode 计。没有这些，暂时还不能比较 Claude、GPT、Qwen、Llama 谁更稳。还有一个更硬的问题：ToolGuard 先把自然语言 policy 编成 guard code，Near-Miss 的上限就被这层 formalization 限住了。policy 写漏了，或 guard code 过宽，检出的 near-miss 就会失真。换句话说，这篇先证明“终态评测不够”，还没证明“他们这套就是通用答案”。 我还想追问一件事：这些 near-miss 是模型能力不足，还是训练目标带偏？如果 agent 被 RL 或系统 prompt 强推“尽快完成任务”，它天然会压缩检查步骤。这个现象我在不少内部 agent demo 里都见过，模型很会补全 happy path，不爱走那些拖慢速度的确认环节。只要评分函数偏成功率，latent failure 就会被奖励。这个锅不该全甩给模型。 所以这篇的分量，不在它新造了一个术语，而在它逼团队改 eval 和 logging。做生产 agent 的人，至少该把三样东西单独记账：终态正确率、策略检查覆盖率、带状态变更操作的依据充分性。摘要里没给实现成本，我自己也还没跑过 ToolGuard，但方向是对的。你不把“为何调用这个工具”记录成可审计对象，后面所有安全承诺都偏虚。

这篇最硬的地方，是作者把一个常被拿来做“人格”“安全”“自知力”讨论的问题，压回到了更可测的层面：模型内部状态和外部话语不是一回事。318M 古典汉语模型在伪造历史事件上的困惑度跳升 2.39 倍，半伪造事件跳到 4.24 倍，p 值分别到 8.9e-11 和 1.1e-16；同一时间，表示不确定的文言标记在 OOD 问题里反而更少，3.5% 对 8.3%。这个结果如果站得住，很多人平时把“模型不说不知道”直接解读成“模型不知道”，就得收一收了。 我觉得这篇论文最有价值的，不是古典汉语这个题材本身，而是它把“风格先验”和“知识边界”拆开了。文言文本天然偏修辞，很多“未详”“不可考”之类表达，本来就不是按概率校准出来的，而是按文体习惯出现。作者把这个点又在英语、日语和 8 个 1.1 亿到 15.6 亿参数模型上复现，说明问题不局限于某一种语料怪癖。这个结论跟过去一年不少工作其实能接上：我们已经见过很多模型在 logprob、entropy、self-consistency 上能暴露“不稳”，但嘴上还是给出很完整的答案。只是大多数文章把它讲成 calibration 问题，这篇更直白，它说的是生成模型默认学到的是“像训练文本那样说话”，不是“把不知道这件事说出来”。 我对作者最后那句“需要 RLHF 一类显式训练信号”有点保留。方向未必错，但证据链还差一截。因为这篇 RSS 摘要里给出了现象，也给了跨语言复现，却没给出一个关键对照：监督微调、拒答模板、工具调用反馈、deliberation-style decoding，这几种机制各自能把 3.5% 拉到多少？如果没这个 ablation，你很难说问题专属于 RLHF。说实话，我更倾向把它先看成“目标函数缺项”而不是“必须 RLHF”。你用 vanilla LM 训练，优化的是下一个 token，不是 uncertainty disclosure；那它学不到校准式拒答，并不奇怪。很多 API 模型今天更爱说“我不确定”，本来也是 system prompt、preference tuning、safety policy 叠出来的，不是 base model 自发长出来的。 还有一个我想追问的点：作者把“困惑度升高”解释为“真实事实编码，不只是句法匹配”。这很有吸引力，但正文摘要还不够让我完全放心。n=92 每组不算小，统计显著也够强，可 semi-fabricated 事件为什么达到最高 4.24 倍，要看构造方式有没有泄漏“违和感”特征。比如人物名是真的、事件模板是假的，这种混搭本身就容易形成低频组合。模型抓到的是语义冲突，还是仅仅抓到共现断裂？标题和摘要没有披露更细的构造控制，我不想替作者补结论。 回到行业侧，这篇东西会刺到两类常见叙事。第一类是“模型会不会知道自己不知道”。按这组结果，base LM 至少不会自然长出一个稳定的外显自知机制。第二类是“让模型多看点数据就会更诚实”。我一直不太买这个说法。参数从 110M 到 1.56B、语言从英语到日语都复现同一分裂，说明规模和语种都不是主因。你不给奖励信号，不给拒答范式，不给检索或工具链，模型就继续优先完成一个流利答案。这个结论对 agent 设计比对哲学讨论更有用：别把“会算分布内外”误当成“会把边界讲清楚”。 所以我对这篇的判断是：现象很重要，解释还没封口。它很适合被拿去校正我们对“不确定性表达”的直觉，但还不够支持“RLHF 是唯一解”。我还没查到全文里有没有更完整的 ablation；如果没有，这篇更像是在给后续对齐研究立靶子，而不是已经把靶子打穿。

这篇论文最扎人的地方，不是它证明了模型有偏见，而是它把偏见放进了一个很多团队都爱装作“只是建议系统”的场景：婚恋匹配。作者用真实征婚资料，操控 5 档收入和 Brahmin、Kshatriya、Vaishya、Shudra、Dalit 五类身份，让 GPT、Gemini、Llama、Qwen、BharatGPT 五个模型家族去打“社会接受度、婚姻稳定性、文化兼容性”分。结果很直白：同种姓评分最高，平均可比跨种姓高 25%，跨种姓内部还沿传统种姓序列继续排序。这个数字已经够说明问题了。模型不是在“理解文化”，模型是在把训练语料里最稳、最旧、最不公平的婚配启发式复写出来。 我对这类结果一点也不意外。过去一年，大家已经看过太多同构案例：招聘里名字和学校变成阶层代理变量，信贷里邮编变成种族代理变量，医学问答里性别和族裔变成风险捷径。LLM 一旦被要求输出“稳定性”“兼容性”“社会接受度”这类软判断，它就会抓住语料里最容易压缩成统计规律的社会标签。种姓在南亚婚配语境里，本来就是高强度标签，所以模型顺手拿来当 shortcut，几乎是机制层面的必然，不是一次失手。说真的，很多产品团队嘴上说自己没把 caste 放进 feature，但只要提示词要求模型预测家庭接受、文化摩擦、婚后稳定，代理变量就会自己冒出来。 我比较想追问的是，25% 这个差值到底在什么提示模板、温度、评分 rubric 下出现。正文摘要只给了“up to 25%”和“10-point scale”，没披露各模型具体分布、方差、提示词版本，也没说是 API 闭源模型的哪一代，比如 GPT 到底是 GPT-4.1、GPT-5 还是别的版本，Gemini 是 2.0 还是 2.5，Qwen 是 Qwen3 还是更早。我还没查到论文全文里的附录，所以先不把这组结果外推到“所有模型同样严重”。但有一点已经够硬：只要五个家族都复现同方向排序，这就不是单厂商对齐失误，而是训练语料、偏好优化和任务设定一起把社会层级压回来了。 还有个地方我不太买一些常见说法：有人会把这种结果解释成“模型只是忠实反映现实”。这句话拿来给研究做描述还行，拿来给产品免责就不行。婚恋推荐不是搜索引擎照单全收，它会排序、打分、解释、过滤。只要系统给某类配对长期更低的“稳定性”或“社会接受度”分，用户就会被 nudged 到更保守的选择上。推荐系统研究早就反复证明，排序本身会改变偏好暴露和后续行为。这里危险的不是模型会说一句冒犯的话，而是它把歧视包装成看起来很理性的 compatibility score。 这篇论文还有一个行业层面的提醒：所谓“本地化”“文化适配”不是天然正向词。过去一年很多地区模型都在打这张牌，尤其在政府、金融、教育、婚恋这些高语境场景里，厂商爱强调自己更懂当地文化。问题是，当地文化里如果本来就含有可量化的等级秩序，本地化经常不是更公平，而是更会复现偏见。BharatGPT 被放进同一组里其实很关键。标题和摘要没有给出它是否比通用模型更偏，正文片段也没披露逐模型对比，所以现在不能下结论说本地模型更糟或更好。但这恰恰是最该补的数据：地域语料增强，到底是在提升语境理解，还是把历史歧视学得更熟。 我还想看作者有没有做一个很简单但很有杀伤力的对照：把“社会接受度”这类显性社会规范指标拿掉，只保留双方兴趣、教育、收入、地点等相对中性的匹配信息，偏差还剩多少。如果偏差大幅下降，说明问题主要出在任务 framing；如果偏差依旧顽固，说明模型已经把 caste 从别的文本线索里编码进潜变量了。摘要没给这部分，我不能替作者补。 对做产品的人，这篇研究的落点很实际。第一，别让模型直接输出单一的“婚姻稳定性总分”，这等于鼓励它用社会偏见压缩复杂关系。第二，凡是涉及家庭接受、文化适配、长期可靠性这类词，先做敏感属性审计，而且要测代理变量，不要只测显式 caste token。第三，解释层要拆开，告诉用户哪些判断来自地理、语言、教育，哪些维度系统根本不该自动推断。你如果非要把 LLM 放进婚恋、招聘、教育分流这类高风险场景，那就别再把“模型只是建议”当挡箭牌了。它给出的每一个分数，都会被当成一种社会许可。

Qwen3 VL 32B 用合成推理轨迹把 MMLongBenchDoc 做到 58.3 分，并超过 235B A22B 的 57.0 分。我的判断很直接：这篇 paper 的价值，不是又一次“小模型打大模型”，而是它把视觉长文档这条线里最贵、最慢、最难部署的那部分——显式推理输出——往参数里塞了一步。对做企业文档检索、合同审阅、研报问答的人，这比 benchmark 多 1 分更实在，因为部署成本经常先死在 token 和延迟上，不死在最后那道题。 文章给出的机制也算具体。它先做页面相关性打分，再抽文本证据，再按相关度重排，把这些过程写进 <think>；训练时再用 <cot> 控制 token 决定要不要走显式推理；最后用 low-strength model merging 把推理能力“内化”。这里有两个点我比较买账。第一，它不是泛泛地蒸馏一个长思维链，而是把长文档任务里最关键的检索顺序显式编码了。第二，它保留了开关，说明作者自己也知道显式推理在某些样本上还没法完全拿掉。很多“internalized reasoning”工作最大的问题，就是把训练期收益和推理期稳定性混成一件事，这篇至少从方法设计上没那么糊弄。 我会把它放到过去一年的一条更大趋势里看：大家都在想办法摆脱 test-time CoT 的账单。去年很多 reasoning 结果靠长输出堆出来，数学和代码里尤其明显。到多模态文档场景，这个账更离谱，因为前面已经有高分辨率页面编码、跨页检索、OCR 噪声，后面再吐几千 token 的思维链，线上系统基本很难扛。论文里给了一个很关键的数：Mistral Small 3.1 24B 的内化推理，平均输出 token 比显式推理少 12.4 倍。这个数字比 58.3 对 57.0 更有信号。原因很简单，长文档产品真要上线，单位 query 成本、P95 延迟、并发上限，往往比 benchmark 排名更决定生死。 但我对这条结果也有几处保留。第一，正文只有 RSS 摘要，我还没看到完整实验表，所以不知道 58.3 和 57.0 的统计稳定性怎样。是单次跑分，还是多 seed 平均，摘要没说。第二，MMLongBenchDoc 这种 benchmark 很吃检索排序和证据定位，如果合成轨迹正好把 benchmark 偏好教得很透，迁移到真实合同、扫描件、图表混排 PDF 上还能不能保住优势，摘要也没给。第三，所谓 low-strength model merging 我有点想追问：合并比例、层选择、对齐损失、灾难性遗忘，正文片段都没披露。这个步骤如果调得很细，复现门槛未必像“公开流水线”听上去那么低。 还有一个容易被标题带偏的地方：它超过 235B A22B，不等于 32B 已经全面强过更大模型。这里更像是“任务配方”赢了“通用底座尺寸”。过去一年这种事出现过不止一次。代码、数学、工具调用都见过，小模型只要把任务结构吃透，再拿合成数据和控制 token 压一遍，能在单项 benchmark 上越级。可一旦换任务分布，尺寸带来的鲁棒性常常又回来。我自己不会把这条解读成 scaling law 失效；我会把它解读成文档 VLM 这块还处在 recipe 红利期，远没到把训练范式榨干的时候。 外部参照也能说明这点。过去开源多模态长文档方案，很多核心优化都放在更长上下文、更强 OCR、页级检索、RAG 拼接，推理本身反而常被当成“有就加，没有也能跑”的可选项。这篇反过来把 reasoning 当主轴，而且不是让模型现场展开长链条，而是先教会一个文档任务专用的搜索顺序，再把顺序压缩进权重里。这个思路跟去年一些小模型 reasoning distillation 的方向是同一脉，但落到视觉长文档上，意义更大，因为文档问答天然就像“检索 + 证据编排 + 答案生成”的串联系统。你把中间那层顺序学稳，收益会比纯语言 QA 更直接。 我还有一点怀疑，针对的是 synthetic reasoning 这件事本身。摘要说它比从 Thinking 版本 traces 蒸馏高 3.8 分。这个结果很有意思，因为它暗示 teacher trace 不一定是最好监督，任务定制的合成轨迹反而更干净。可这也引出一个问题：合成器是不是已经把答案空间限制得太窄？如果生成轨迹主要依赖文本证据抽取与重排，那面对图表推断、版式跨栏、手写批注、表格单元格对齐这类视觉证据，方法会不会掉得很快？摘要没展开，我不想替作者补完。 即便有这些缺口，我还是觉得这条值得认真看。原因不是它又贡献了一个推理 tag，而是它给了一个很现实的工程方向：把文档多跳检索流程蒸馏成可控、可内化的中间表示，再用少输出甚至零显式思维链去换线上可用性。要是后续开源代码真能稳定复现，很多做 DocQA 的团队会照着改自己的训练栈，而不是继续盲目拉长 context。长上下文当然重要，但在文档任务里，先找到哪几页、按什么顺序看、抓哪几段证据，常常比把 500 页全塞进去更有效。这个判断，我是买账的。

论文用3B和7B模型完成长文档QA，并声称延迟比GPT-4o和DeepSeek-R1低2到4倍。我的判断很直接：这条价值不在“SLM接近LLM”，而在它把长文档问答拆成了一个更可训练的结构生成问题。小模型不是突然学会跨几十页材料做推理，它是先被教会了怎么抽记录、对齐单位、序列化输出，再在这个窄得多的轨道里做回答。 这点其实很符合过去一年的一个走向。很多团队嘴上讲reasoning，落地时都在做中间表示设计：表格、工具调用轨迹、程序、JSON schema、检索证据块。你把问题空间压到结构层，模型容量需求就会明显下降。我自己一直觉得，长文档QA最难的部分不是“想”，而是“找、对齐、归一化、别漏项”。LiteCoST的CoST模板就在解决这件事。文章给了机制，先让强LLM产出可审计的结构化思维链，再做SFT和GRPO。这个路径我买账，因为它避开了纯自由文本CoT最麻烦的两个坑：监督噪声大，训练后还难验证。 但我对“接近大模型质量”这句宣传有保留。正文没有给具体基准名、分数、上下文长度、延迟口径，也没说2到4倍延迟是在同等硬件、同等输出长度、同等检索设置下测的。这个缺口很关键。长文档QA的速度对比很容易被系统设计污染：你是单轮直接答，还是先抽结构再答；你有没有外部检索；输出是短答案还是完整表格；这些都会把延迟差放大。我看过不少类似论文，标题里的“更快”最后其实混着模型尺寸优势、prompt长度缩短、解码长度缩短三种因素。这里只靠摘要，我没法把功劳全部记在训练方法头上。 还有一个我会追问的点：教师模型是谁，教师错误怎么清洗。摘要只说“strong LLM”，没给型号。这个问题不小。过去一年从Self-Rewarding到RLAIF，再到各种合成数据管线，大家都碰到同一个现实：教师一旦在事实抽取上带偏，学生会把偏差学得更稳定。LiteCoST里“minimal structure、normalize、verify/refine”这套流程，听上去像是在给教师输出加护栏，这是好事；但验证器是规则、另一个模型、还是人工抽检，正文片段没披露。我还没查原文附录，如果附录里没有标清数据清洗比例和失败案例，这条证据链就不够硬。 外部参照也很清楚。2024到2025年，行业里一条主线是“用更小的模型吃掉更多受约束任务”。Phi、Qwen、Llama小尺寸变体都在走这条路：代码补全、表格理解、工具调用、受限格式生成，常常能靠蒸馏和任务结构化逼近更大模型。LiteCoST只是把这个思路推进到了长文档QA，而且挑了一个很现实的切口：企业文档问答通常不需要开放世界创造力，它需要证据整理和格式稳定。要是这篇论文的分数真能站住，受影响最大的不是OpenAI这种通用模型厂，而是那些还在卖“一个大模型包打天下”方案的应用层公司。因为客户一旦发现，7B配上结构模板和一套蒸馏流程就能过线，推理成本、部署时延、数据留在本地这三件事会立刻压过“最强模型”叙事。 我也得泼一点冷水。结构化思维链很适合表格、图、字段抽取这种任务，但它未必自然泛化到含大量歧义、跨段反事实、或者需要法律语境判断的文档QA。你把思考先压成固定schema，收益是稳定，代价是表达能力变窄。这个 trade-off 我自己是接受的，因为生产环境本来就更看重可审计性；但如果作者把它包装成通用reasoning提升，我不太买账。它更像把任务重新定义到了小模型擅长的区域。 所以这篇论文我会认真看代码，不会先看口号。要是GitHub里能看到训练数据构造脚本、奖励函数细节、失败样例和延迟测试设置，这条就很扎实。要是只有模板和几个案例，那它更像一篇把行业常识论文化的工作：方向对，工程价值高，学术上的跨越没标题写得那么大。

玄武VL-2B用约20亿参数拿到OpenCompass七项67.90分，并在七类审核任务做到94.38%召回。这个组合比单看榜单更有意思，因为它瞄准的不是“2B也能打大模型”这类老叙事，而是内容平台最难啃的那块：模型一旦为审核业务后训练，通用能力常常掉得很难看，OCR对抗和长尾噪声还会继续把误杀、漏杀一起抬高。 我对这条的第一判断是：这更像一份训练管线论文，不是一份纯模型论文。作者把InternViT-300M、MLP、Qwen3 1.7B拼成约2B预算，然后用预训练、中训练、后训练三段去压“业务对齐”和“通用保留”的冲突。这个方向我基本认同。过去一年里，很多多模态安全方案还是把审核当成后挂分类头，或者靠指令微调硬拉行为边界，短期有效，代价就是灾难性遗忘。玄武如果真像文中说的，把数据迭代和筛选机制放进主训练管线，那它解决的是工业问题，不只是论文问题。 但我对“通用能力保留”这句有保留。正文给了67.90 对 64.27，比较对象是 InternVL 3.5 2B；这个差值不小，说明在同量级开源底座里它确实做出了东西。问题是，OpenCompass七项到底覆盖哪些任务，视觉定位、图表、OCR、数学、视频有没有完整披露，RSS正文没写。没有任务构成和方差，你很难判断这3.63分是全面抬升，还是被一两类强相关题型拉起来。文章也没给训练数据规模、清洗比例、负样本构造方式、在线A/B 或人工复核成本，这些恰恰决定“工业级”三个字能不能成立。 审核部分的数据比通用部分更扎实一些。七项业务平均召回94.38%，对抗OCR违规文本加权召回82.82%，还压过 Gemini-2.5-Pro 的76.72%。这组数至少说明两件事。第一，2B 模型在窄域视觉语言安全上不一定输给更大闭源模型，前提是任务边界清楚、数据分布贴着业务。第二，OCR对抗仍然是内容生态里的硬骨头，谁能把花字、遮挡、谐音、低清截图这类样本吃下来，谁才配谈线上审核。我自己一直觉得，很多通用VLM在这块表现并不稳定，因为它们训练时追求的是宽覆盖，不是对违规规避手法的密集建模。 我还是要泼点冷水。召回高，不等于系统好用。审核系统至少还要看精确率、分层路由、人工复审负担、类别间不平衡下的阈值稳定性。94.38% 召回如果建立在明显更高的误报上，平台运营团队不一定会开心。正文没披露 precision、FPR、按语种拆分，也没说 Gemini-2.5-Pro 的对比提示词、输入分辨率、是否启用工具。没有这些条件，这个超越结论只能先收着看，不能直接拿去做采购判断。 再放一点文章外的上下文。2025年不少团队都在把小模型重新拉回台前，原因很现实：端侧部署、审核吞吐、延迟预算、GPU 成本都在逼大家放弃“一个超大模型包打天下”。我记得 InternVL 系列一直在推小尺寸多模态底座，Qwen-VL 线也证明了中文OCR和复杂视觉问答不必靠超大参数才能可用。玄武这篇顺着这个趋势再往前走了一步：它不是只证明“小模型也行”，而是试图证明“小模型经过正确的数据和后训练设计，能成为内容生态的专用底座”。这个命题我觉得比刷榜更实在。 我没法仅凭这段摘要就给它下“工业级已成立”的结论。标题给了很大的野心，正文没披露线上流量、错误案例、跨域迁移、持续学习代价。要让我更信，至少还得看到三样东西：一是精确率和误报成本；二是新型规避样本到来后，模型多久需要再训练一次；三是离开审核场景后，它在常见多模态任务上的掉点曲线。说真的，如果后两项也站得住，这类2B级审核底座会比很多大而全VLM更有商业生命力。

APEX-EM 在冻结 Claude Sonnet 4.5、Opus 4.5 的条件下，把 KGQAGen-10k 准确率从 41.3% 拉到 89.6%。我对这篇的判断很直接：它抓住了 agent 体系过去一年最稳定的增益来源，不是再训一个更强 backbone，而是把执行痕迹做成可复用程序记忆。这个方向我一直觉得比“再加一层反思”更实在，因为反思常常只是在同一次 rollout 里兜圈子，结构化经验回放才像真的在积累能力。 论文里最像样的地方，不是“有记忆”三个字，而是它把失败轨迹也写进库里，还带结构化误差标注。很多 agent memory 工作只存成功样本，检索回来像 few-shot demo 扩容版。这样做有用，但上限不高，因为你只是在告诉模型“像这样做”。APEX-EM 多走了一步：它也告诉模型“这种计划图会怎么坏掉”。这跟 Reflexion、Voyager、甚至早期 ReAct trace logging 的差别很大。那些方法也会保留失败，但大多停在自然语言总结，少有把计划 DAG、迭代历史、工件和 verifier 信号一起编进可检索结构里。对代码、查询、工具调用这类任务，结构比表面文本重要，我基本认同这个设定。 分数上最扎眼的是两个点。KGQAGen-10k 提升 48.3 个点。BigCodeBench 从 53.9% 到 83.3%，比文中给的 MemRL 可比增益高 18.4 个点。这个幅度已经大到我会先怀疑评测设置，而不是先感叹方法通吃。文章摘要说它甚至超过了 oracle-retrieval upper bound 84.9%。这一下我有点愣住了。若 oracle 上界定义正确，系统结果高过上界，通常只有三种解释：上界口径偏窄、检索和生成耦合出了额外收益、或任务分布里存在近重复样本让结构签名匹配占了便宜。正文片段没披露检索库构造、时间切分、去重标准，也没给 leakage audit。我还没法替它下结论。 我更关心它为什么会在 HLE 上到 48.0%。Humanity’s Last Exam 这类题，大家过去一年都见过一个现象：纯靠更长上下文，收益很快钝化；靠更强工具链，收益不稳定；靠外部检索，常常被知识表面相似度拖后腿。APEX-EM 用 entity graph retrieval 把 25.2% 拉到 48.0%，至少说明一件事：这不是普通 RAG，那种“搜到相似文档再拼提示”在复杂推理上经常救不了场。它更像把过往任务压成可迁移的操作模板。这个思路跟程序员常说的“不是记答案，是记 debug 路径”很接近。 我还是有两个保留。第一，跨域迁移的叙事我只信一半。摘要说可以处理“没有词汇重叠但操作结构类似”的任务，这很诱人，但没给具体失败案例分布，也没说结构签名是人工设计多少、模型归纳多少。若签名工程成分太重，方法会更像 benchmark-tuned middleware，不是通用记忆层。第二，Task Verifier 的成本没披露。论文承认 rich judge feedback 对代码生成几乎没用，对结构化查询却值 10.3 个点。问题来了：这些 verifier 谁来写、谁来维护、每步要花多少 token 和工具调用？如果为了拿 10 个点，要引入一套脆弱 verifier 生态，工业可用性会打折。 回到行业语境，这篇更像在给“test-time scaling 的下一阶段”补拼图。2024 年大家先押长上下文。2025 年开始押 agent loops、tool use、self-refinement。现在越来越清楚，单次推理链再长，也不等于系统会变熟练。熟练来自经验压缩、经验检索、经验避坑。Adept、Cognition、还有一批做 coding agent 的团队，其实都在往这条线上靠，只是很多实现是产品黑箱，论文很少把负例记忆讲清楚。APEX-EM 把这个机制拆开了，这点有参考价值。 我对标题里的“non-parametric online learning”也想泼点冷水。严格说，它没有改权重，学到的是外部记忆和检索策略，不是模型参数里的能力增长。所以它更像 system-level learning，不是大家熟悉的 online optimization。这个命名没错，但容易让人误读成“无需训练也能持续学习”。实际前提很硬：任务可验证、轨迹可结构化、记忆库可维护。离开这三个条件，收益未必站得住。 所以这篇我会认真看复现，但不会先把 89.6% 当结论。我更想看三样补充：检索泄漏审计、verifier 成本表、去掉手工结构签名后的掉点。如果这三项还稳，APEX-EM 就不是一篇 memory paper，而是 agent stack 里该默认存在的那一层。