论文 · 2026-03-22

KG-Hopper 用 7B 开源模型覆盖 8 个知识图谱推理基准，并声称压过部分 70B 多步系统。我的判断很直接：这条有研究味，也有工程味，但眼下更像一个“把 agent pipeline 收回模型内”的方法论信号，还不是一次已经坐实的能力跃迁。 摘要给出的核心机制是把路径遍历、节点决策、回溯压进单轮推理，用强化学习训练统一的“thinking”阶段，减少分步流水线的误差级联。这个思路我其实认同。KBQA 这类任务里，老路线一直有个老毛病：retriever 先漏一跳，planner 再走歪一跳，最后 reader 再自信作答，三段都不算大错，串起来就彻底废了。把跨步依赖放进同一次推理里，至少在机制上更接近 ReAct 之后很多人想做但一直没压实的方向——不是多调几个模块，而是让模型自己学会什么时候扩展、什么时候回退。 但我对这条结果有两个保留。第一，正文片段没披露具体分数、训练配置、RL reward 设计、基座模型名字、推理 token 开销，也没说“部分 70B”到底是哪几家。没有这些信息，7B 打 70B 这句话只能先听一半。AI 论文这两年很常见的操作，就是拿一个高度结构化任务、一个偏有利的评测口径，再配一个昂贵但笨重的 baseline，最后得出“小模型逆袭”。结论未必假，泛化范围往往被写大了。第二，KG 基准的污染和模板化风险一直存在。我没看到这里怎么处理图谱覆盖、问题去重、路径分布偏置；如果训练集和 benchmark 的关系没讲清，这个“接近 GPT-4o-mini”就不好下重注。 放到更大的脉络里看，这条和过去一年两股风是接上的。一股是用 RL 把工具使用、搜索、规划收进小模型内部，而不是继续堆外部 orchestrator；另一股是让开源 7B/8B 在垂直任务里追平老一代闭源通用模型。去年到今年，很多团队已经证明 7B 在代码、数学、检索增强任务里能打到很高的性价比。我自己一直觉得，知识图谱推理比开放域长思维更适合这条路，因为状态空间受约束、奖励也更容易定义。换句话讲，这类任务不是“模型突然懂世界了”，而是“任务足够结构化，小模型终于能被训到位”。 我还没查代码实现细节，所以不敢替它背书。要让我认真看高一档，我需要三组信息：8 个基准的逐项分数；相同 token/调用预算下和 ReAct、GraphRAG、tool-augmented 7B baseline 的正面对比；还有失败样例，尤其是回溯触发失败和长路径漂移。代码开源是加分项，因为这类工作一复现就知道水分在哪。说真的，如果复现实验成立，它影响的不是“7B 能不能赢 70B”这种标题，而是 KBQA 这条线以后没必要再迷信多模块流水线了。

论文比较16个模型后报告，0.5B到3B模型在5类NLP任务上的PER全部高于大模型。这个结论我基本买账，但我买的是“部署效率排序会改”，不是“小模型全面反杀大模型”。 先说我认同的部分。很多线上系统从来不是被单点精度卡死，而是被P99时延、显存占用、并发吞吐和单位成本一起卡死。作者把准确率、吞吐、内存、时延压进一个PER，用几何均值做归一化，至少是在逼研究评测往生产约束靠。过去一年这股风已经很明显了：边缘端和私有化场景里，Phi 级别、Qwen 3B 级别、Llama 3B 级别的小模型一直有稳定位置。我没核实这篇具体纳入了哪些名字，但行业经验确实支持一个常识：只多拿1到3个点精度，换来2到5倍显存和时延代价，很多业务不会签字。 但这篇我也有两个保留。第一，PER这种合成指标很容易把“致命短板”抹平。几何均值听起来公平，实际会把四项指标压成一个分数。问题是线上系统往往不是均衡优化，而是硬门槛优化。举例说，分类任务准确率差1.5个点也许能接受；合规审核、医疗问答、法务检索里，这1.5个点就可能直接决定能不能上线。反过来，某模型平均时延很好，但P99抖动很差，单个PER分数也不一定能暴露风险。正文没披露每项指标权重敏感性，也没给出“如果某项低于阈值则直接淘汰”的分析，我对这个缺口比较警觉。 第二，摘要里的“ across all tasks ”信息量其实没看上去那么大。五类任务是什么，任务长度分布怎样，是否包含长上下文、结构化抽取、工具调用、代码相关负载，正文片段都没给。硬件也没披露。是A100、H100、L4，还是CPU？量化有没有统一到INT4、INT8，batch size 怎么设，吞吐是tokens/s还是requests/s，时延看首token还是全生成，这些都会直接改写排名。我自己做过一些推理侧评估，小模型在短输入、封闭标签空间任务上经常赢得很轻松；一旦拉到长上下文、多轮推理、复杂生成，差距就会重新拉开。标题已经给出“任务特定效率分析”，正文却没披露任务设计细节，这里不能顺手推成一般规律。 我还想补一个文章外的上下文。过去一年不少团队从“一个大模型包打天下”退回到“模型路由+小模型主干”。原因不神秘：70%到90%的请求根本不需要最强模型。客服分流、意图分类、摘要压缩、检索重写、轻量抽取，这些活交给1B到4B模型，收益通常立刻体现在GPU占用和尾时延上。大模型留给高风险、低频、难样本兜底。这个架构趋势，比这篇论文里的单次排行榜更重要。因为它说明小模型的价值，不只在“单独比较时更省”，还在“系统设计里能吃掉大部分流量”。 所以我对这篇的评价是：方向对，结论要收着用。它很适合拿去反驳“参数越大越该默认上线”的懒惰决策，也很适合拿去推动团队把评测表从accuracy-only改成accuracy + latency + memory + throughput。但如果有人据此下结论，说3B已经足够替代一切7B、14B、70B，我不买账。没有模型名单，没有硬件配置，没有量化口径，没有任务细节，这个结论还远没到能改采购单的程度。

TIDE 在 A100 上把 DeepSeek R1 Distill 8B 的 prefill 延迟降了 7.2%，把 Qwen3 8B 的 batch-8 吞吐提了 8.1%；我的判断是，这是一篇很务实的推理工程论文，但标题里“per-token early exit”的冲击感，比当前结果本身大。 我先说结论：这套方法有价值，原因不是 98%-99% 解码 token 提前退出，而是它把“后训练、少校准、可挂到 HuggingFace 因果 LM”这三个条件同时做到。2,000 条 WikiText、少于 3 分钟校准、路由器检查点约 4 MB，这几个数字很像真正能进推理栈的工程约束，而不是只在论文图里好看。我一直觉得，早退这条线卡住的地方从来不是想法，而是部署摩擦：要不要重训、要不要改模型图、跨 GPU 能不能跑、精度一换会不会炸。TIDE 至少从摘要看，专门在拆这些障碍。 但我对叙事也有保留。文章给了“98%-99% 解码 token 可提前退出”，同时给的吞吐收益只有 6.6% 到 8.1%。这不矛盾，反而说明问题：token 提前在层 11、31 之类位置退出，不等于整机吞吐按比例上涨。原因通常在 kernel launch、KV cache 读写、router 自身开销、batch 内 token 分歧带来的 warp/stream 效率损失。说真的，谁做过 serving 都知道，省掉一部分层计算，最后常常只换来个位数到十几个点的端到端收益。论文这组数我信，但它更像“把已有 GPU 榨出 5%-10%”，不是“把 32 层模型变成 10 层成本”。 这篇的上下文也很清楚。过去一年，推理优化主线基本是三类：一类是 FlashAttention、PagedAttention、fused kernel 这种算子和内存路径；一类是 speculative decoding、Medusa、EAGLE 这种多 token 预测；一类是量化，从 FP16/BF16 往 INT8、INT4 走。早退一直有论文，但落地比前面几类慢，因为它要求模型中间表征在层间足够“稳定”，还要在动态 batch 下别把执行流搞碎。TIDE 的意思不是发明新原理，而是把这类方法做成一个小而可插拔的系统。我觉得这点比“1,308 行 Python + 1,081 行 CUDA/C++”更重要，虽然这个代码量确实说明作者在认真做工程，不只是挂个概念。 我自己的疑虑有三处。第一，正文只有 RSS 片段，没披露精度基线和完整 benchmark protocol。多步数学题只给了一个 95 个 unique output tokens 的例子，这远远不够。我想看的是 GSM8K、MATH、HumanEval、长上下文 QA 在不同 exit 阈值下的准确率-延迟曲线。第二，摘要里提到 prefill 100% exit，而且 5% token 在第 11 层退出、其余在第 31 层退出。这个分布看上去偏保守，像是在最后几层节省一点 compute，而不是大幅砍深度；好处是精度稳，坏处是收益天花板也比较明显。第三，“支持任何 HuggingFace causal LM”这句我不会直接照单全收。架构差异、rope 变体、MoE 路由、GQA/MQA、不同实现的 KV layout，都可能让“可支持”与“高效支持”差很多。尤其 MoE 模型上，我还没看到这里给出数据。 如果拿行业里的已有经验对比，这个结果处在合理区间。我印象里，很多后训练推理优化在单卡 A100 上能拿到 5%-15% 的真实吞吐提升，已经算有工程价值；再高就往往需要更激进的近似，精度代价会冒出来。我没核实最近几篇 dynamic depth 论文的精确数字，但 TIDE 这个 6%-8% 不夸张，也正因为不夸张，我反而更愿意信。 所以这条我给的是偏正面评价：它没展示压倒性的速度神话，却碰到了一个很实的落点——不重训、几分钟校准、几 MB 附加参数、对现有 HuggingFace 模型直接套。要是后续开源代码在 vLLM、SGLang、TensorRT-LLM 这类主流 serving 栈里也能复现接近 5% 以上收益，这篇就不只是论文了，会变成大家上线前愿意试一下的默认优化项。反过来，如果收益只停在作者自己的单卡 fused kernel 环境里，那它就还是一篇好看的系统 paper，离生产还有一截。

AdaRubric 在 WebArena 和 ToolBench 上把人类相关性做到 Pearson r=0.79，静态基线高出 0.16。这个数字够硬，所以我对它的核心判断很直接：LLM agent 评测这条线，接下来拼的不是“谁更会打总分”，而是谁能把任务拆成对的维度，再把失败维度单独钉住。 这篇东西抓到的痛点很准。固定 rubric 评 agent，老问题一直没解：同样一段轨迹，做网页操作时该看 goal alignment 和 action efficiency，做代码修复时该看 correctness 和 error handling。你拿一套通用标准去裁，分数当然会漂。AdaRubric 的做法是按任务描述动态生 rubric，按维度逐步打分，再用 DimensionAwareFilter 防止“两个维度很好”掩盖“一个关键维度彻底失败”。我一直觉得 agent judge 最大的坑就出在这里：系统最后没完成任务，但因为过程像样、措辞流畅、局部步骤合理，judge 还是给高分。这个过滤器至少在机制上是对症的。 外部参照也很清楚。过去一年很多自动评测工作，像 G-Eval、Prometheus、Arena-Hard 这类，在线性文本任务上已经把“模型当裁判”做得挺顺。但 agent 任务不一样，轨迹长、状态多、工具调用有前后依赖，单次 outcome 还经常不足以解释失败原因。AdaRubric 把“按任务生维度”放到评测前面，这比继续堆更强 judge model 更靠谱。我自己没看到正文里的 judge backbone 配置，标题和摘要也没披露成本、上下文长度、每条轨迹评一次要多少 token。这个缺口不小。要是生成 rubric 加逐步打分把评测成本抬高 5 到 10 倍，很多团队上线时会犹豫。 训练增益是另一层。摘要说，用它产出的 preference pairs 做 DPO，三项基准任务成功率提升 6.8 到 8.5 个点，SWE-bench 代码修复再涨 4.9 个点，PPO 在 5K steps 时快 6.6 个点。说真的，这组结果比 0.79 更让我警觉。自动评测器一旦反哺训练，第一件要查的就是 reward hacking 和 rubric leakage。任务描述里如果已经隐含了成功标准，模型又在训练时反复看到由描述生成的 rubric，最后学到的可能是“迎合 judge 的语言和步骤结构”，不一定是更稳的任务能力。RSS 片段没交代训练集与评测集的隔离细节，也没说 preference pair 的构造比例、负样本难度、不同 judge 模型之间是否交叉验证。没有这些，我不会把 8.5 个点直接读成能力跃迁。 还有一个我想追问的点：0.83 的 Krippendorff's α 很高，说明一致性不错；但一致性高，不等于真的贴近生产事故。WebArena、ToolBench、SWE-bench 都是好基准，可它们的任务边界仍然比真实 agent deployment 干净。生产里常见的是工具返回脏数据、页面元素变化、权限中断、长时记忆污染。DimensionAwareFilter 在这些“部分成功但最终不可用”的场景里是不是一样稳，正文片段没给。我还想看 failure breakdown，尤其是它到底减少了多少“看起来很会做、其实没做成”的误判。 我对这篇的总体评价是偏正面，而且比一般评测论文更接近实战。原因不在于又多了一个 judge，而在于它终于承认 agent 评测不是单轴排序题，是多维约束题。Anthropic 和 OpenAI 过去一年在 computer use、operator、tool-use 方向都在碰同一个墙：终局成功率不够解释模型行为，过程评估又太松。AdaRubric 至少给了一个结构化解法。 我暂时不会把它当成“评测统一解”。我会先看三件事：一，代码仓库里是否公开 rubric 生成模板和 judge 调用成本；二，训练增益能不能在未见任务、未见工具链上复现；三，失败维度过滤会不会误杀那些路径奇怪但结果正确的 agent。要是这三件都站得住，这篇的价值就不只是评 benchmark 了，它会变成 agent 训练数据生产线的一块基础设施。

AgentHER 在四个模型家族上把 success-only SFT 提升了 7.1 到 11.7 个百分点，还把成功演示需求压到 50%。我对这条的判断很直接：它的价值不在“又一个 agent trick”，而在它把 RL 时代早就成立的 HER 逻辑，硬塞回了今天这套以 SFT 和 preference data 为主的 LLM agent 训练流水线里。 这篇最扎实的地方，是它没有空谈“失败也有价值”，而是给了可操作机制：先做 failure classification，再抽 outcome，再做 LLM relabeling 和 confidence gating，最后分别打包成 SFT、DPO、ShareGPT 数据。97.7% 的人工评审重标精度，至少说明这不是纯靠模型自嗨生成伪标签。WebArena 低于 15%、ToolBench 低于 55% pass@1 这两个底数也关键，因为它说明 agent 数据集里失败样本本来就是大头。你如果还沿着“只收成功轨迹”做训练，等于主动丢掉多数交互成本。 我一直觉得，过去一年 agent 训练有个很怪的浪费：大家在推理侧疯狂搞 test-time search、reflection、tool retry，训练侧却还把失败轨迹当脏数据直接扔了。这个做法在机器人和离线 RL 里早就不成立。HER 是 2017 年的东西，用“事后目标替换”解决 sparse reward。AgentHER 有意思的地方，不是概念新，而是它把“目标”从状态空间里的坐标，换成了自然语言里可验收的任务描述。这个迁移不简单，因为语言目标更松，作弊空间也更大。论文拿 97.7% precision 来压这个担心，方向是对的，但我还想看 recall 和 error taxonomy：它筛掉了多少本来能救回来的失败？高置信门控会不会把最有信息量、但最难重标的轨迹一起过滤掉？正文摘要没给这些数。 我还想往外接一层上下文。2025 年很多 agent work 都在卷更强基座、更长轨迹、更贵的 verifier。比如 WebArena 这条线上，单靠换更强 frontier model，成功率当然会上去，但成本和闭源依赖也一起上去。AgentHER 走的是另一条更朴素的路：不先问模型还差多少 IQ，先问你有没有把已经花钱采回来的 interaction 用干净。我自己更偏这条。因为企业里真正卡住 agent 落地的，常常不是 base model 再提 3 分，而是根本没有足够多的“成功工单”去做监督微调。失败日志反而堆满数据库。 但我对这篇也有一个明确保留。WebArena 和 ToolBench 都是合理 benchmark，不等于真实生产 agent。前者偏网页导航，后者偏 API/tool use，它们都存在任务目标可重述、结果可抽取的结构性条件。把同一套方法扔到长时程办公 agent、代码修复 agent、或者多轮销售对话，重标是否还这么稳，我没看到证据。尤其是目标本身带隐含约束时，比如“订最便宜但可退的航班”这类任务，失败轨迹很容易只完成表层结果，却丢了关键约束。你把它重标成一个更容易的新目标，训练确实会涨分，但也有把 agent 教成“会降级目标”的风险。摘要没有披露针对 reward hacking 或 goal drift 的详细对抗评测。 还有一点我觉得很现实：这条如果能跑通，受益最大的未必是 GPT-4o 这种闭源 API agent，而是中小开源模型。论文里从 1.5B 到 72B 都有 5.8 到 9.2 个点增益，这很像“数据工程补模型智力”的经典信号。Qwen、Llama 这类能反复微调、反复部署的体系，会比纯 API 编排更吃到红利。加上它支持迭代 redeployment 再多 2.1 个点，味道已经很像一个可滚动的数据 flywheel，只是这里的燃料不是人工标注，而是失败日志回收。 所以我对这篇的结论是正面的，但不神化。它没有证明 agent 学会了更强泛化；它证明的是，在失败占多数的环境里，丢掉失败样本是一种很粗暴的低效。这个判断我基本认同。要让我更信，还差三组信息：不同任务类型下的重标失败案例、门控阈值和 precision/recall 取舍、以及在真实企业日志上的迁移结果。标题给了方法和 benchmark 增益，离“生产可用的默认配方”还差这几步。

论文证明带索引外部记忆的 agent 把页读取成本降到 O(log_b N)。我对这个结果基本认同，但标题把它写成“governs agentic reasoning capacity”，我看着有点过：这里先被改变的不是推理能力，而是信息访问复杂度，随后才间接影响推理长度、稳定性和 token 账单。 抽象里的实验条件算清楚了：50 到 5,000 条存储，三类内容，两代模型 GPT-4o-mini 与 GPT-5.4。抽象内容上，索引 agent 的中位页读数固定为 1；无索引但页面排序的方案，强模型能逼近 log_2 N 的二分查找，还是比显式索引差 5 倍。这个点很扎实，因为它击中的其实是过去一年 agent 系统里最常见的误判：很多人把“模型能在上下文里找回来”当成一种自然能力，再给它加一点 ReAct 或 scratchpad，就默认规模会上去。这个论文把账摊开了：只要还是顺序扫描，累计成本就是 O(T log_b T) 对 Θ(T^2) 之外的那一边？不对，按文中表述应是带索引 O(T log_b T)，顺扫 Θ(T^2)。这个差距不是 prompt 优化能补的，是数据结构层面的差距。 我一直觉得，2024 年到 2025 年那波“长上下文=长推理”叙事有一半是偷换概念。Gemini 1.5 那时把百万上下文推到台前，OpenAI、Anthropic 后面也不断抬 context window，大家都在演示“把更多材料塞进去”。但工程上你很快就会碰到老问题：窗口再大，定位机制不变，很多任务照样是在更大的草堆里找针。这个论文的价值，在于它把“草堆变大”与“有没有目录卡”拆开了。说真的，这比又一篇 benchmark 上多拿几分的 reasoning paper 有用得多。 我最认同的是它对职责拆分的判断：模型做索引构建，确定性算法走索引。这个思路跟 RAG 系统一直在做的事有亲缘关系，但细一层。经典 RAG 主要解决“从外部知识库召回哪几段”，这篇更像在说“agent 自己产生的大量中间状态，也该被组织成可导航对象”。如果你做过长轨迹 coding agent，像 SWE-agent、OpenDevin、或内部那些能跑几百步的浏览器代理，你大概都见过同一个问题：失败往往不是不会写下一步，而是 30 步后再也找不回第 7 步留下的关键状态。把这类状态做成索引，比继续堆更强模型更现实。 但我有两个保留。第一，正文没披露更完整的 benchmark 细节，比如 index 构建成本、写入更新频率、错误索引后的恢复代价。检索复杂度降了，不等于端到端总成本一定降；如果每一步都要昂贵地重写索引，收益会被吃掉。第二，百科内容触发参数记忆抢答，这个现象很有意思，也很符合我们平时对模型的直觉；可抽象里只说“catastrophic token expenditure”，没给具体 token 数、失败率、prompt 控制条件。我还没法判断这是普遍机制，还是特定提示模板把模型诱到了“我知道答案，不用查”的模式。 还有一层上下文，文章没展开，但我觉得很关键。现在不少 agent 框架还把“工具调用成功率”当核心指标，LangGraph、AutoGen、CrewAI 这一类 workflow 设计，默认模型既负责决定查什么，也负责沿着检索路径一步步走。论文等于在提醒一句：导航协议这件事，模型未必适合长期持有控制权。它擅长语义压缩、标签生成、索引归档；它不擅长在 100 次重复检索里始终遵守一个无聊但严格的 protocol。这个分工观念如果被系统设计者认真采纳，影响会比论文里的 5,000 条 toy store 更大。 所以我对这篇的判断是：它不是在宣布一种新型“会思考”的 agent，而是在给 agent 工程补一门早该补的数据结构课。标题往认知能力上抬了一层，我不太买账；把它当成“LLM 负责建目录，程序负责翻目录”的形式化证明，会更准。

作者在 Qwen3-8B 和 Llama-3.1-8B 上用预计算 KV cache 复现了 700 个问题的 0 差异，前提是聊天模板完全对齐。我的判断很直接：这篇论文有料，但它切中的不是“RAG 终于被干掉了”，而是很多人一直把知识检索问题和上下文装配问题混在一起。Knowledge Pack 把一段固定文本 F 先编译成 KV，再和查询 q 拼接到同一条因果链里。只要模板、角色位、分隔符都一致，F 的独立前向 KV 与 F+q 联合前向 KV 严格等价。这个结论不花哨，甚至有点像把 causal mask 的常识工程化；难得的是作者把它做成了一个可复验的接口结论，还顺手解释了为什么以前有些“KV 比 RAG 更强”的说法站不稳：你拿错模板，模型掉 6 到 7 个百分点，锅不一定在方法本身。 这跟过去一年很多长上下文和 RAG 优化工作其实是两条线。市场上常见做法还是把知识原文塞回 prompt，再配重排、摘要、压缩，最后跟 token 成本硬碰硬。Anthropic、OpenAI、Google 这一轮都在推更长 context window，但长窗口从来不等于免费窗口，延迟和账单都摆在那里。KV 预填充也不是新概念，vLLM、TensorRT-LLM、各家 serving 框架早就在做 prefix caching；差别在于它们主要解决“重复前缀别再算一次”，这篇论文把它往前推了一步：把可复用知识块当成一等公民分发。这个方向我很买账，因为它更像编译问题，不像检索问题。你有一份稳定手册、一套政策、一段代码基座，先编译成包，再按会话注入，系统设计会比每轮重喂文本干净很多。 但我对“zero-token knowledge delivery”这个标题还是要泼点冷水。第一，token 节省 95% 只覆盖输入侧账本，不覆盖 KV 存储、网络搬运、缓存命中管理，也不覆盖 pack 失效后的重编译成本。服务端真部署时，省下来的 token 会换成显存占用和 cache orchestration。谁更便宜，要看 pack 多大、复用率多高、并发多密。正文摘要没给出 pack 大小、层数选择、缓存传输开销，也没给线上吞吐数据。没有这些，谈成本优势还差半截。第二，700 个问题能证明“等价在这套设置下成立”，证明不了开放域场景已经能替掉检索。RAG 难的部分常常不是把文档放进去，而是先决定放哪几段、何时更新、不同来源冲突怎么裁决。Knowledge Pack 只处理“选中之后怎么塞”，没处理“该选谁”。 作者加的 steering 部分反而更有意思，也更危险。论文说 value 向量的对比增量能做行为 steering，alpha 小于等于 0.7 时还能和知识注入并行。这条如果成立，含义不小：KV 接口不只是压缩输入，还能在不改权重、不做 LoRA 的情况下临时改行为。这里我想到去年一些 activation steering、representation engineering 的工作，思路都接近：别碰参数，直接改中间表征。区别是这篇把操作点放在 cache 侧，工程上更容易挂进 serving 栈。问题也在这里——它太容易挂进去。谁来审计这些 value delta？用户看不到，prompt 里也没有痕迹，系统卡里通常更不会披露。企业如果把政策偏好、拒答倾向、销售导向都包成隐藏 steering pack，外部几乎无从判断回答到底来自模型、来自检索，还是来自一层静默控制。 我还保留一个技术疑问。摘要说 key arithmetic 会破坏 coherence，value delta 在中层 33% 到 66% 最有效，独立方向近乎正交。我自己觉得这个结论很像“在这两个 8B dense 模型上成立”，离通用规律还有距离。MoE 模型、不同 RoPE 变体、GQA 结构、甚至多轮对话里带 tool-call token 的模板，都可能让这个窗口变窄。尤其 Qwen 和 Llama 的 chat template 很讲究，一旦 system/user/assistant 边界不对，结果立刻下滑；这篇自己也承认了 6 到 7 个点的跌幅。换句话说，它的上限很漂亮，下限也很现实，工程团队会在模板和缓存协议上花掉比论文看起来更多的精力。 所以这篇论文的价值，我会放在两层。第一层，它给“知识注入”提供了一个干净的推理接口，能把固定上下文从 token 流里剥出来。第二层，它把 KV cache 从纯性能优化件，推成了模型控制面的一部分。前者会先进入企业内知识库、静态政策文档、代码库基座这类高复用场景。后者会碰到治理问题，而且来得很快。标题里最响的 95% 节省我先放一边；我更关心的是 serving 框架多久开始原生支持可签名、可版本化、可审计的 Knowledge Pack。没有这三件事，这条路很容易从工程技巧滑成一层没人看见的系统提示词。