锐Owl 雷达 · 2026-10-27：省下来的成本，记在另一栏

覆盖 2026-10-26 18:00 → 2026-10-27 18:00（北京时间）。

本期五条都在追同一件事：每一次「更省」，账单都记在另一栏上。 OpenAI 把单价砍了一半，跑完同一张智能榜却多吐 60% 的 token，首 token 等到 78 秒；百度把长文档的 KV 缓存从 47GB 压到 1.77GB，代价是模型不再保留全局文档结构，标题层级这类「整本书的骨架」它看不见；skill 从人工编写的 56.4% 被自动进化推到 60.7%，多出来的 4.3 个点靠的是一个被冻结的模型和一套自己出的题；looped transformer 把串行深度折成并行，延迟降 46%，省下的是时间不是算力；研究 agent 最擅长的则是把互相矛盾的证据磨平成一句更硬的结论——它省掉的，正是证据的锯齿。所谓效率，从来不是把某一栏的数字做小，而是说清楚这一栏的数字是从哪一栏挪过来的。

① GPT-6.1 Terra 单价砍半、每任务 $0.40，但首 token 78 秒、跑同一张榜多吐 60% 的 token（OpenAI 2026-10-26 发布）

便宜是真的，便宜在哪一栏需要自己算。 OpenAI 于 2026-10-26 放出 GPT-6.1 Terra，定位「快速、高效、电脑操作」，标准 API 价格 $1 / 百万输入、$0.05 / 百万缓存输入、$5 / 百万输出，官方称比 GPT-5.6 Terra 与 GPT-6.1 Sol 低 50%。官方成绩单：Agents' Last Exam（专业软件实操，如把建筑图纸做成 3D 模型）medium 档比 GPT-5.6 Terra 高 15 个百分点，单任务成本约后者 1/3，并以 GPT-6 Astra 十分之一的每 token 价格追平其表现；max 档 token 效率超 Claude Opus 5.5 3 倍以上、单价为其 1/4，单任务成本约 1/9，完成任务比 Astra 与 Sol 快 3 倍以上。事实性错误率从 GPT-5.6 Terra 低推理档的 53.6% 降到 16.7%（−36.9pp），max 档再降到 4.3%；Terminal-Bench 4.0 max 档解出 50.3%，GPT-5.6 Terra 公布值是 21.5%。文档页给的是硬参数：1,050,000 上下文 / 最大输入 922,000 / 最大输出 128,000，知识截止 2026-06-01；输入超过 272K token 的请求整单按 2× 输入、1.5× 输出计价，缓存写入 $1.25（30 分钟）/ $2.50（12 小时）。第三方口径补上官方没说的两栏：Artificial Analysis 上 智能指数 48 分（同类中位 28）、输出 90.9 tokens/s（中位 88.2）、每任务 $0.40，跑完智能指数一共输出 1.3 亿 token（中位 8,100 万），但首 token 延迟 77.96 秒（同类中位 3.81 秒）。

认知价值：① 「单价减半」和「成本减半」不是同一句话。 单价砍半，但同一张榜它多吐了约 60% 的 token（1.3 亿 vs 中位 8,100 万），两条账抵掉一部分之后，真正可比的是 $0.40 / 任务这个数。选型时拿 per-task 成本横比，别拿每百万 token 单价横比——这是 10-26 期 Kimi 那条给过的同一条教训，一周内被两家验证两次。② 「一折价格拿到 Astra 级」这句话掉了两个限定词：「每 token 价格」和「medium 推理档」。转述时限定词先掉，结论就变成「全面追平」，这是我们自己写稿最容易犯的错。③ 成绩单上唯一难看的一行是 TTFT 78 秒。 它不推翻任何 benchmark，但直接决定这类模型能干什么：批量离线（读发票、填表单、跑评测）无所谓，交互式场景（边聊边改、agent 连续操作屏幕）基本不可用。指标要按场景选，不按榜单选。 ④ 1M 上下文有一个隐藏价目表： 输入超 272K，整单按 2× 输入 / 1.5× 输出计，长文档塞满窗口的成本不是线性的。⑤ 边界：benchmark 全为厂商自测（官方页明确「we measured」），AA 是第三方但采样有限；媒体流传的 283 tokens/s 与 AA 实测 90.9 tokens/s 差三倍，口径未对齐前不引用。

领域：industry-model ｜ 去向：feeds（喂养「单价 vs 每任务成本」方法论：与 10-26 期② Kimi K3.1 Pro 的 $2.11/任务 同框，一周内两个厂商给出同一类反例）｜ 等级：🟡

来源：🟢 一手已核（2026-10-27 直读官方发布页与 API 文档）https://openai.com/index/introducing-gpt-6-1-terra/ 《Introducing GPT-6.1 Terra》（原文含：标准价「50% lower than those of GPT-5.6 Terra and GPT-6.1 Sol」、「$1 per million input tokens, $0.05 per million cached input tokens, and $5 per million output tokens」；Agents' Last Exam medium「15 percentage points higher than GPT-5.6 Terra at about one-third the cost」「on par with GPT-6 Astra at only one-tenth its price per token」；max 档「over three times as token efficient as Claude Opus 5.5, and one-fourth its price per token, resulting in a ~9x lower cost per task」「over three times faster than both GPT-6 Astra and GPT-6.1 Sol」；事实性错误率 53.6%→16.7%、max 档 4.3%；Terminal-Bench 4.0 50.3% vs 公布值 21.5%）https://developers.openai.com/api/docs/models/gpt-6.1-terra （1,050,000 上下文 / 最大输入 922,000 / 最大输出 128,000 / 知识截止 Jun 01, 2026；「Prompts with more than 272K input tokens are priced at 2x input and cache rates and 1.5x output for the full request」；cache write $1.25/30min、$2.50/12h；Batch 与 Flex 再低 50%）｜🟡 第三方聚合（2026-10-27 直读）https://artificialanalysis.ai/models/gpt-6-1-terra （Intelligence 48、Speed 90.9 tok/s、$0.40 per task、输出 130M tokens（中位 81M）、TTFT 77.96s（中位 3.81s）、cache discount 95%、1M 上下文、「released on October 26, 2026」）｜🟡 媒体口径 https://www.qbitai.com/2026/10/505719.html 量子位《GPT-6.1 Terra首批网友实测来了！》2026-10-27 16:27（网友 Leo 测得 283 tokens/s、Sonnet 5.5=56 / Opus 5.5=58 分；DesignArena 复刻贝伦塔成本 $0.047 vs $0.077、token 多 48%——均为网友自测，本刊只取「成本更低但 token 更多」这个方向）

② 文心 Unlimited OCR 2 把百页文档的 KV 缓存从 47GB 压到 1.77GB，代价是不再保留全局结构（百度 2026-10-27 开源）

它解决的是「翻书翻到后面越来越慢」，不是「看不懂书」。 百度 ERNIE 团队于 2026-10-27 发布并开源 Unlimited OCR 2（技术报告随模型卡发布，PDF 直接可读），接上 6 月那一代的 R-SWA，这次把解码注意力整体换成 SR-SWA（稀疏参考滑动窗口注意力）：先用 Page Gate 把参考范围从整本书收到相关几页，再用 Token Sieve 在页内按相关度取固定数量的信息块（例如 512 个 token），配合固定大小的 Local Window——每一步需要看的信息量被框死，单步解码延迟不随文档变长而增加。显存那头靠 Unlimited-Horizon Decoding：按页分块、相邻两块重叠一页当书签，复用这块重叠页的视觉 KV、保留上一段输出的文本缓存，其余页面缓存及时释放。技术报告表 4 的账：单序列（B=1）峰值 KV 47.00 GB → 1.77 GB（−96.2%），16 路并发吞吐 360 → 1,315 TPS（3.65×）；百页尺度单步解码相对 Full Attention 7.0×、相对上一代 R-SWA 5.6×。质量上 MPDocBench 84.59（上一代 61.89，Qwen3.8-Max 78.30）、自建 MarathonDocBench 77.06（100–300 页，第二名 Kimi-K3 33.74）、单页 OmniDocBench v1.6 94.02%。模型 3B-A0.5B、MIT 许可；训练用了 25×8 台 H800、200 万页多页 + 1,000 万页单页，伪标签来自 MinerU2.5-Pro 与 PaddleOCR-VL-1.6。仓库生态可核：GitHub 28,865★ / 3,061 fork / MIT，HF 上一代 30 天下载 305.8 万 / 4,910 likes，二代仓 10-26 建、123 likes。

认知价值：① 「恒定延迟」和「恒定显存」是两个旋钮，得分开拧。 SR-SWA 管每步算多少（7.0×），分块解码管显存里驻留多少（47→1.77GB）；只动一个，另一个立刻成瓶颈——这是长上下文优化最通用的一课：算力账与驻留账分开记。② 96% 与 3.65× 不是同一条件下的数。 96.2% 是 B=1 单序列的峰值 KV，3.65× 是 B=16 并发的吞吐（1,315 TPS）；把两个数并排成「既省显存又提速」没错，但要写清 B 值，否则读者会以为是在同一张卡同一并发下测的。③ 省掉的注意力，正是理解结构的器官。 报告 limitation 自己写了：当前稀疏注意力不保留全局文档信息，标题层级这类文档级结构理解受限——一页页读得又快又准，但「这本书有几章、谁是谁的子节」它答不好。恒定成本换来的，是不再有全局视野。④ 长文档强者不必然单页通吃：单页 94.02% 与榜单最强的 TeleOCR 96.91% 仍有距离。⑤ 天花板可能来自老师：伪标签出自 MinerU2.5-Pro 与 PaddleOCR-VL-1.6 两个竞品，学生学到的是两位老师的输出分布；再叠上「自建 MarathonDocBench」，77.06 应读作「百页端到端可行」的存在性证明，不是排名。⑥ 工程细节可直接抄：块间重叠一页、只留边界页 KV，任何分块处理长输入的流水线都能用。

领域：ocr-doc ｜ 去向：feeds（喂养「长文档的真实成本」选题：与 10-26 期③ EdgeRock 并置——一条砍历史（KV 定容锚点），一条砍页面（分块+稀疏参考），两条都在夺「常驻内存」这个数）｜ 等级：🟡

来源：🟢 一手已核（2026-10-27 直读技术报告 PDF 与模型卡）https://hf-mirror.com/baidu/Unlimited-OCR-2/blob/main/Unlimited-OCR-2.pdf 《Unlimited OCR Works 2》（Baidu ERNIE Team；原文含：SR-SWA 把参考压到固定容量「e.g., 512 tokens」、「7.0× and 5.6× per-step speedups over Full Attention and R-SWA」；表 4「Standard Decoding 47.00 GB / 360 TPS」对「Unlimited-Horizon Decoding 1.77 GB / 1315 TPS」（B=1 与 B=16）；表 1 MPDocBench Overall 84.59、表 2 MarathonDocBench 77.06、表 3 OmniDocBench v1.6 94.02%（3B-A0.5B；TeleOCR 96.91）；训练 25 × 8 H800、2M multi-page and 10M single-page、伪标签来自 MinerU2.5-Pro / PaddleOCR-VL-v1.6；limitation 原文「does not preserve global document information, limiting its understanding of document-level structures such as heading hierarchies」）https://hf-mirror.com/baidu/Unlimited-OCR-2 （模型卡 ## Release：「[2026/10/27] We release Unlimited OCR 2」；license MIT；createdAt 2026-10-26 / lastModified 2026-10-27 / likes 123）｜🟢 一手已核（GitHub API，2026-10-27）https://github.com/baidu/Unlimited-OCR 28,865★ / 3,061 fork / MIT / created 2026-06-18 / pushed 2026-10-27｜🟢 一手已核（HF API，2026-10-27）上一代 baidu/Unlimited-OCR downloads 3,058,783 / likes 4,910｜🟡 媒体口径 https://www.qbitai.com/2026/10/505773.html 量子位《KV Cache被压成常数！OCR开源新王》2026-10-27 16:35（884 页《指环王》42 分 56 秒、每页约 2.9 秒、466 处跨页合并；「累计下载量超 1000 万」为媒体口径，HF 30 天口径为 305.8 万）

③ 把「经验」做成会自我进化的资产：自动优化的 skill 在 83 道题上 60.7%，人工编写的是 56.4%（两篇同日预印本，2026-10-26）

手工 skill 已经很强了，自动化的净收益只有 4.3 个百分点——值不值得，取决于你怎么给人力计价。 两篇 10-26 提交的预印本在做同一件事的不同一半。第一篇 Skill$^{\infty}$（2610.35434，17 页）：让 meta agent 按一条 meta-skill 去优化任务 skill，再用同一套流程优化这条 meta-skill 本身——诊断执行轨迹、提候选、请独立评审、分配搜索预算，这几步都写在 meta-skill 里，因此可以被自己改写；两级 skill 都是标准包，通过原生 skill 发现机制加载。在 83 道 SkillsBench 任务上通过率 60.7%，人工编写 skill 是 56.4%，上一个方法 SkillEvolver 是 54.5%。第二篇 HSE（Hierarchical Skill Evolution）（2610.35616）解决的是「经验太贴仓库」：先从单条轨迹抽任务级证据，再在同仓库内聚合出仓库级 skill 候选，最后跨仓库归并出可迁移 skill；进化由一个外部 writer-evaluator 循环驱动，底层编码模型全程冻结。评测在 SWE-bench Verified 与 DeepSWE 上，用 GLM-5.2 分别配 Pi 与 Claude Code 两种 harness，再用 GPT-5.5 与 Opus 4.8 配 Pi；结论是只从 SWE-Gym 长出来的 10 条 skill，在所有评测设置上都带来提升；另有一组不用验证器反馈、只靠学到的 evaluator 评估候选、从目标基准轨迹继续进化 skill 库，也有额外增益。

认知价值：① 先记住基线：人工 skill 已经是 56.4%。 读到「自动进化 60.7%」很容易以为天降 60%，其实净收益 +4.3pp；自动化的价值不是更强，而是省掉迭代的人力——这条账我们自己做 skill 时同样要算。② 两级优化的真含义是「优化器本身也是 skill」。 只有把流程写进 skill，它才有机会被自己改写；这和我们的做法（经验证的技术积淀当场固化成 Skill）是同一条路，区别只是它把「验证」这一步也自动化了。③ 迁移性才是资产的判据。 HSE 那 10 条 skill 只从 SWE-Gym 的轨迹里长出来，却在换 benchmark、换模型（GLM-5.2 → GPT-5.5 / Opus 4.8）、换 harness（Pi / Claude Code）后全部有效——不跨环境的叫过拟合，跨环境的才叫资产。④ 「冻结模型」这个设定对我们特别对口：收益全部来自上下文组织，不含权重更新，等于证明「不训模型也能涨点」这条路有天花板但还远。⑤ 边界：83 题是自建 SkillsBench、非公开榜；HSE 只报「所有设置均提升」不报幅度；两篇都没量化 skill 库变大之后的检索成本与 token load——「经验越多越强」目前只在题目固定、库较小的条件下成立。

领域：agent-frameworks ｜ 去向：feeds（喂养「Skill 作为可评测资产」选题：与 10-26 期④「harness 不能脱离模型单独评」同线——harness 与 skill 都是可被单独优化的那一层上下文，本期把「谁在优化优化器」也补上了）｜ 等级：🟡

来源：🟡 预印本（2026-10-27 直读摘要页）https://arxiv.org/abs/2610.35434 《Skill$^{\infty}$: Recursive Self-Improvement for Agent Skill Optimization》Submitted on 26 Oct 2026，comments「17 pages, 5 figures」（原文含：meta agent「follows a meta-skill to optimize task skills and optimizes the meta-skill itself using the same procedure」；「skills at both levels are standard packages loaded through native skill discovery」；「On 83 SkillsBench tasks, Skill$^{\infty}$ reaches a pass rate of 60.7%, compared with 56.4% for human-curated skills and 54.5% for SkillEvolver」）｜🟡 预印本（2026-10-27 直读摘要页）https://arxiv.org/abs/2610.35616 《Hierarchical Skill Evolution for Coding Agent》Submitted on 26 Oct 2026（原文含：三级聚合「task-level evidence → repository-specific skill candidates → transferable skills across repositories」；「external writer-evaluator loop … keeping the underlying coding model frozen」；「SWE-bench Verified and DeepSWE, using GLM-5.2 across Pi and Claude Code harnesses and GPT-5.5 and Opus 4.8 with Pi」；「10 skills evolved solely from SWE-Gym improve coding performance across all evaluated settings」）

④ 循环深度加深不再按串行付钱：延迟降 46%、八任务均值从 53.41% 升到 56.38%（同一作者组 2026-10-26 两篇）

「多算」和「更慢」在 looped transformer 里本来是同一件事，这两篇在拆这个等号。 looped transformer 用重复套用同一个骨干来增加每 token 的计算量，参数不变、能力上升，但每一轮都依赖上一轮，深度一加延迟就跟着涨。LoopFold（2610.35556）把多个循环深度对同一个 token 前缀的计算折成并行批：一个轻量预测器先估出后面几轮需要的输入，让它们提前开工，再用一个校正器拿前几轮刚出的真结果回头修；全部组件只用最后的 next-token 预测损失联合训练。1.4B 模型、8 个 zero-shot 任务上，越深的 LoopFold 配置均值越高，53.41% → 56.38%，而 vanilla looped 与 PLT 在同一深度区间收益有限；相比九轮 vanilla，LoopFold 只用 5 个串行阶段加额外并行算力，解码延迟降 46%。同一批作者（Feichen Song、Boyi Zeng、He Li 等 10 人）同日的 StateLoop（2610.35544）补另一头：vanilla looped 每轮的输出直接当下一轮输入，跨轮信息全靠一个 hidden state 传，于是给每个 token 多加一个持久状态，用学出来的门控决定「保留多少旧状态、吸收多少新信息」，更新后再投回骨干输出；结果是 Pile 困惑度下降、8 个 zero-shot 任务均值提升，且相对 vanilla 的优势随训练深度增大。

认知价值：① 「猜一下先开工、拿到真结果再回填」这个结构值得单独记。 它把硬依赖改成软依赖：延迟高的部分先跑一个估计版本，正确的信息回来后再校正。任何串行流水线（多阶段生成、agent 串联工具调用）都能借这个思路，代价是要有便宜的预测器和能纠错的校正器。② StateLoop 修的是「深了就忘」。 收益随深度增长这一条很关键：说明它不是普遍涨点的小技巧，而是专治循环次数一多、跨轮信息被单个 hidden state 挤掉的问题。③ 46% 是「延迟」的 46%，不是「算力」的 46%。 它用 5 个串行阶段换掉了 9 个串行阶段，同时多花了并行算力——省的是墙上的时间，账单上的 GPU 小时可能更贵。排批跑的时候这两种「省」不能混。④ 两个数都不大（+3pp、困惑度小幅），这是机制论文的常态：它的价值是证明「串行深度可以摊平」，不是今天的 SOTA。⑤ 边界：只测 1.4B、8 个短 zero-shot 任务，没有长上下文、没有 agent 场景；PLT 之外的并行循环方案未纳入比较。

领域：inference-efficiency ｜ 去向：feeds（喂养「省的是哪一维」方法论：与本期②的「延迟/显存两个旋钮」、10-26 期③「恒定 KV 换掉远处细节」同框——三条都在问同一个问题：这一维省下来了，挪到哪一维去了）｜ 等级：🟡

来源：🟡 预印本（2026-10-27 直读摘要页）https://arxiv.org/abs/2610.35556 《LoopFold: Parallelizing Recurrent Depth in Looped Transformers》Submitted on 26 Oct 2026（原文含：「folds computation at multiple recurrent depths into parallel batches for the same token prefix」、轻量预测器「estimates inputs to later loops so they can start before earlier loops finish」＋corrector 用新结果精修、仅用 final next-token loss 联合训练；1.4B 模型 8 任务均值 53.41% → 56.38%；「Compared with a nine-loop vanilla model, LoopFold uses five sequential stages and additional parallel computation to reduce decoding latency by 46%」）｜🟡 预印本（2026-10-27 直读摘要页）https://arxiv.org/abs/2610.35544 《StateLoop: Persistent State for Looped Transformers》Submitted on 26 Oct 2026（原文含：「maintains one additional persistent state per token」、learned gate 控制保留/吸收比例；「reduces Pile perplexity and improves average accuracy across eight zero-shot tasks」；「Its perplexity advantage over Vanilla Looped grows with trained loop depth」）｜作者组一致（两篇作者均为 Feichen Song、Boyi Zeng、Yiqin Hao、Shixiang Song、He Li、Yizhou Yang、Zitong Wang、Yifan Liu、Ziwei He、Zhouhan Lin，据 arXiv 作者字段，2026-10-27 直读）

⑤ 研究 agent 最擅长的不是编造，是把矛盾磨平：最严重的系统有 22–35% 的结论属于「严重平滑」（NYU，arXiv 2610.35793，2026-10-26）

每条引用都真实存在，但结论比证据硬——这种失败以前没有名字，现在有了。 纽约大学 Tiasa Singha Roy、Manya Wadhwa、Greg Durrett 的预印本把 deep research 的典型失真命名为 smoothing（平滑）：模型把来源里互相矛盾、参差不齐的证据收束成一条叙事，于是「一句更利落的结论」取代了「一堆有条件的发现」。为此提出 SmoothScore 五步流水线：抽结论句 → 抽证据 → 归纳高层 aspects → 把证据分配到 aspects → 逐条打分（1–5，越高越平滑）。7 个系统 × 4 个数据集（ResearcherBench、ScholarQA-CS2 专家版、DeepResearch Bench II、ResearchRubrics；查询人工筛选以保证需要多文档综合）——系统包括 GPT Luna 5.6 / Sol 5.6 / Claude Sonnet 5 / Opus 5.5（均接 Websearch）、Gemini Deep Research、以及开源 DR Tulu 与 QUEST。结果：平均分 GPT Luna 1.66–1.95、Sol 1.82–1.93、Gemini 3.05–3.27，其余系统都落在 2.20–2.88；≥3（实质平滑）在每个系统、每个数据集上都存在，且至少 22% 的结论受影响；真正拉开差距的是 ≥4（严重平滑）——Gemini 22–35%，是其他闭源 agent 的 3–12 倍、Sol 的 13–26 倍，而 Luna/Sol 只有 1–4%，开源的 DR Tulu 与 QUEST 严重平滑比例同样偏高。人工验证：judge 与标注员 93% 的评分差距在 1 分以内，judge 判 ≥3 的结论里 62% 被标注员同样判 ≥3，两位标注员之间 κ=0.62。代码与数据已放出。

认知价值：① 这是「评测的评测」。 它不问答对没答对，只问结论比证据硬多少——正好补上 deep research 这类产品最容易被放过的那一格。② 失败模式的名字很重要：「幻觉」是可查的（引用不存在），「平滑」是不可查的（引用全对，只是把反面证据悄悄折进去了）。给它一个分数，才谈得上管。③ 分档比均分有用。 ≥3 到处都有（每个系统至少 22%），均分看起来都还行；只有 ≥4 这一档才能把系统区分开——评测指标设计上，「人人及格的那一段」不该占权重。④ 最反直觉的一格：闭源之间的差距比开源/闭源更大（Gemini 22–35% vs Luna/Sol 1–4%）。平滑更像是产品选择——要不要给用户一个利落的答案——而不是模型能力。⑤ 直接可用在我们自己身上：雷达与长文的常规动作就是多源合并，这套流程可以当发布前自检：把结论句抽出来，逐条问「支持它的证据里，有没有反方向的」。⑥ 边界：judge 是 LLM + 小样本人工验证（κ=0.62 属中等一致），查询人工挑选，4 个数据集偏英文研究型；分数是相对刻度，不能读成「错误率」。

领域：eval-evidence ｜ 去向：feeds（喂养「深度研究该怎么评」选题，并直接进本刊发布前自检清单：结论句 → 证据 → 有没有反方向证据，三步可执行）｜ 等级：🟡

来源：🟡 预印本（2026-10-27 直读 arXiv 全文 HTML 与摘要页，CC BY 4.0）https://arxiv.org/abs/2610.35793 《Quantifying Claim Smoothing by LLM Research Agents》arXiv:2610.35793v1 [cs.CL] 26 Oct 2026，作者 Tiasa Singha Roy、Manya Wadhwa、Greg Durrett（New York University）（原文含：smoothing 定义「discards the evidential 'jaggedness' of its corpus and asserts conclusions more decisive than the citations can support」；SmoothScore 五步；7 系统（GPT Luna 5.6 / Sol 5.6 / Claude Sonnet 5 / Opus 5.5 + Websearch、Gemini Deep Research、DR Tulu、QUEST）× 4 数据集（ResearcherBench、ScholarQA-CS2 Expert-Written、DeepResearch Bench II、ResearchRubrics）；「Mean SmoothScore ranges from 1.66–1.95 for Luna and 1.82–1.93 for Sol to 3.05–3.27 for Gemini, with every other system falling between 2.20 and 2.88」；「smoothing of ≥3 is present on every system and dataset, with at least 22% of claims affected」；「Gemini smooths severely on 22–35% of its claims, roughly 3–12 times the rate of other closed-source agents and 13-26× the rate of Sol」；Luna/Sol「only having 1-4% claims ≥4」；judge 与标注员「within one point on 93% of claims」、≥3 一致率 62%、标注员间 κ=0.62）https://github.com/tiasa2/SmoothScore （代码与数据）