论文导读
北京大学、百度、清华大学等机构提出H2S，让模型读长材料时先找出与问题有关的证据，再把证据压缩成一份短摘要后作答。在论文的长文本测试中，14B模型平均得分32.60，比受测的27B基线高10.17分；把输出预算从16K缩到4K时，仍保留97.1%的测试表现。它展示了一条更省输出、也更容易抓住重点的长文问答路径。
读得更长，不等于找得更准
把一本技术手册、一串客服记录或一整个代码仓库交给大模型，最难的往往不是把字装进窗口，而是把分散在各处的关键事实连起来。一个问题可能要同时查接口定义、实际实现与配置变化；若模型一边扫过大量无关段落一边长篇推理，容易漏掉真正决定答案的几句话。H2S针对的正是这种“资料都在，却找不准证据”的情况。
研究团队把工作拆成三步：先带着问题读原文，标出相关证据；再将这些证据整理成面向问题的摘要；最后依据摘要回答，并回到证据检查推理链。与“直接让模型在长文里想”相比，这相当于先做一份可追溯的材料摘录，再写结论。图中的示例从长文里找出食品名称、鱼名和属名之间的关联，最终得到答案，说明这里的“压缩”不是随意删字，而是保留回答问题所需的关系。
图：流程图展示长文、证据高亮、问题摘要与最终回答之间的传递关系。
用训练让模型学会找证据
团队构建了H2S-Dataset，包含来自11类基准的6647个样本，平均上下文长度约4.39万Token。训练目标不仅是答对题，也要求模型在长资料中挑出相关片段、形成有根据的摘要。论文还设计了过程奖励，分别关注证据选择和摘要构造，使模型不只在最后答案上拿分。对普通读者而言，可以把它理解成教模型先做好阅读笔记，再参加开卷考试。
这一步尤其重要：如果摘要漏掉关键条件，后面即使推理看起来流畅，也可能答错。论文中的注意力案例展示了模型如何把焦点集中到特定证据位置，而不是平均对待整篇材料。但这张图展示的是个案中的行为，不能把颜色分布直接当作所有题目的正确率证明。
图：案例热图标出模型处理问题时更关注的文本位置，用于观察证据聚焦行为。
14B为何能在这项测试中压过27B
研究者另设H2S-Bench评估长文本理解。在论文报告的设置下，H2S-14B平均得分32.60，比较对象Qwen3.8-27B为22.43，相差10.17分。这里的“干翻”只指这套测试与指定模型的比较，不表示14B模型在所有任务上都比任何27B模型强。标题里的75%也有明确口径：把允许生成的输出从16K Token缩到4K，预算减少四分之三；相应得分由33.56变为32.60，约保留97.1%。预算是上限，不应理解为每次实际账单都固定省75%。
数据来源覆盖多种任务，而不是只在一种问答格式上练习。下图展示训练资料按任务类型的构成；不同任务要求模型寻找的证据关系不一样，这有助于理解研究者为何强调“先高亮、再总结”的通用流程，而不是一套固定提示词。
图：论文训练数据按任务类别分布的示意，显示样本来自多种长文本任务。
下一步，是真正的长资料工作流
这项研究的直接启发是，面对长合同、研发文档或跨文件代码问题，可以把“找到依据”作为独立步骤，而不只要求模型一次性写出漂亮答案。若检索到的证据可供复查，使用者也更容易知道结论从哪里来。论文目前验证的是所报告的基准和预算设置；面向真实企业资料时，还要看来源变化、错误检索和跨文档冲突如何影响答案。研究的价值在于提供了一个可测量的方向：让推理先围绕证据收敛，再比较准确率与输出成本。
参考资料
https://arxiv.org/abs/2609.31382
