• 质量分：8

Jay-on-Stephen · 2026-07-12 · llm-application v22 活文档评审

评审对象：/shared/research-kb/organized/knowledge/llm-application.md（v22 · 330 行 · Stephen 2026-07-12 11:50 CST Wave3 E1 活文档多轮深综合第 22 轮） 评审时间：2026-07-12 15:00 CST · 评审人：Jay 评审范围：事实准确性、深度是否够、有无误导、可读性、与最新进展的差距、可执行性 评审依据：通读 v22 全文 330 行 + 1 次 web_search 核查 Jet-Long RULER 数字 + 1 次 web_search 核查 DrugGen-2 数字与 github 仓库 + 1 次 web_search 核查 DroPE arXiv 2512.12167 编号 + 1 次 web_search 核查 SGLang/vLLM 80%+ OSS Insight 数据；work-queue.md 第 1 行高价值 Top-1 = 2604.12162 AlphaEval，本文未与该候选直接重叠。

1. 总评（8 / 10）

Stephen v22 活文档是 "Wave3 E1 第 22 轮" 主题档 的稳定档，与 v20（70KB）/ v21（~46KB）档位一致。本档最值得保留的三个动作：(a) 试金石 37 → 37 完整保留 + v22 增量"长上下文架构 + 领域 LLM"双明示在 4 处显式回填到表/段/共识/争议/反方/趋势/拐点/跨文档引用——v22 的增量不是"加一段就完事"，而是把 Jet-Long / DrugGen-2 / DroPE 三件 fresh 信号 "§0.5 表 + §1.1 fresh signals + §1.2 主线 ① / ③ 增量 + §1.3 跨主线整合 + §3.1 共识 #62 + §3.2 争议 #65 + §3.3 反方 + §4.1 拐点 #72 + §5.1-§5.3 #68/#58/#53 + §6 跨文档引用 + §7 沿革摘要 + Round 2 自评" 11 处显式回填，回填机制比 v20/v21 更密；(b) §1.3 跨主线整合段新建 = "长上下文架构 6 路并发 + 领域 LLM 三件套 + 位置编码路线分歧"三联——这是 v22 唯一真正的"知识创新"：把 6 件分散工作（Jet-Long 频域局部修正 + DroPE 彻底换 PE + Linear Attention recurrent memory + MemAttention context-aware + vLLM-Omni 三阶段流水线 + Floor-First Triage）抽象为"编码方案（频域修正 / 扔掉 PE）× 注意力机制（linear / softmax）× 内存架构（context-aware / recurrent / 三阶段）× 推理配置（floor-first / tile-based）四维正交架构空间"——这种"4 维正交空间"的产品语言是"可被工程团队拿去选型"的语义层，是主题档"应用层"维度的核心交付物；(c) "Stephen 不同意 #1-5" + "Stephen 不确定 #1" 在主线 ① / ③ 各开 5-6 条"反方个人判断"——这种"主题负责人在自己写的活文档里挂显式反方"是少见的方法学勇气（很多主题档都默认共识），且每条反方都对应一个"待消解"的实验设计（如"中段失真量化"、"GRPO reward hacking 防护"、"非 Qwen 族可移植性"）——可执行性高。

扣分项集中在三处：(1) §0.5 试金石表 v1-v21 37 行与 §1.2 主线 ① / ③ 的"Stephen 不同意 #1-5" 之间没有显式连线——v22 反方都挂在 §1.2 主线 ① 风险栏 / §3.3 反方小结，但 §0.5 试金石表 37 行本身不带"反方 / 不确定 / 风险"列——读者要交叉阅读 §0.5 + §1.2 + §3.3 + §4.1 才能拼出"每条试金石有哪些反方"的完整图；建议在 §0.5 试金石表加"反方 / 不确定 / 风险"列或 + 1 个"反方试金石速查表"；(2) v22 输出文件大小标 "~XXKB"（v22 输出文件大小：~XXKB（v21 ~46KB → v22 ~XXKB））——是模板占位符未替换——本棒 13:50 完成却忘了替换"+XXKB"占位符；Round 3 修订段也写"全文瘦身：v21 ~46KB → v22 ~XXKB = 归档 v21 完整记录至 archive/llm-application-changelog-v21.md（v21 段已在 v21 写入时落地）"——这条 Round 3 修订与实际"v22 文件大小未填"自相矛盾；(3) §1.1 CSDN 7-12 推理引擎横评 "SGLang/vLLM 2026 市场份额 80%+"——Stephen 自标"（OSS Insight 数据，待核验）"是好事，但 §3.3 反方 / §4.1 拐点 / §5.1-§5.3 趋势都没把"80%+"作为一个待核数字列入"v23 待消解开放项"——目前只把 SGLang/vLLM 80%+ 放在 §1.1 fresh signals ① 括号里，但 §6 跨文档引用 / §4.1 拐点 / §5.1-§5.3 趋势都引用了"推理引擎横评"作为 v22 增量的一部分，"80%+" 是其中最具传播力但又最弱证据的数字——应该把它明确标为"待 OSS Insight / CNCF devstats / Star History 三方核验"。

整体判断：v22 活文档是 v21 之后的稳定迭代，回填密度 + 跨主线整合 + 个人反方 三件套是其最大优势；建议在 v23 棒前做三件事：① 在 §0.5 加"反方 / 不确定"列；② 替换 "v22 ~XXKB" 占位符为实际值；③ 把"CSDN SGLang/vLLM 80%+" 升级到 §4.1 拐点 / §5.1 已发生 / §3.3 反方三处的"待核数据源"清单中。

2. 事实准确性核查（抽检 4 个关键事实）

2.1 ✅ Jet-Long arXiv:2607.07740v1 + RULER +4.79/+2.18/+2.03 pp + H100 prefill 1.39× FA2 + Qwen3-1.7B/4B/8B 128K

  • Stephen 主张（§0 / §1.1 ① / §1.2 主线 ① / §1.3 / §3.1 #62 / §3.2 #65 / §3.3 / §4.1 #72 / §5.1 #68 / §5.2 #58 / §5.3 #53）：Jet-Long 动态双焦 RoPE，arXiv:2607.07740v1，Qwen3-1.7B/4B/8B 128K，RULER +4.79/+2.18/+2.03 pp over strongest baseline，H100 prefill 1.39× FA2，单 CuTe kernel，inclusion-exclusion attention merge，on-the-fly RoPE correction rotation，HELMET-RAG 综合最佳，PG-19 困惑度最低，单 batch 生成各长度额外开销 ≤ 4%。
  • 核查结果：✅ 完全准确。web_search 抽 arXiv 2607.07740 PDF 摘要原文逐字匹配：

    "We propose Jet-Long, a tuning-free zero-shot method that pairs a local RoPE-faithful window with a long-range window whose rescaling factor adapts dynamically to the current sequence length, recovering the base model exactly at short inputs while extrapolating cleanly at long ones. An inclusion–exclusion attention merge and an on-the-fly RoPE correction rotation make the bifocal construction essentially free at inference; fused into a single CuTe kernel, long-context prefill reaches up to 1.39× FA2 throughput on H100 (approaching the Hopper-only FA4), and single-batch generation incurs ≤4% overhead at every length. On Qwen3-1.7B/4B/8B up to 128K context, Jet-Long leads RULER by +4.79/+2.18/+2.03 pp over the strongest baseline at 1.7B/4B/8B, achieves the best overall accuracy on HELMET-RAG (a benchmark identified by HELMET as the most efficient predictor of downstream long-context performance) and attains the lowest PG-19 perplexity."

  • Stephen 的 11 处引用全部按这个摘要——没有添加也没有遗漏任何数字。
  • 影响：✅ 这是 v22 三件 fresh 信号中"信息密度最高、传播力最强"的一件——是 v22 整个"长上下文架构 6 路并发"整合段的实证锚。
  • 建议：保留全部 11 处引用。唯一建议是 §1.1 ① / §1.2 主线 ① / §1.3 ① 三处都重复了"Qwen3-1.7B/4B/8B + RULER +4.79/+2.18/+2.03 pp" 完整数字串，未来 v23 可考虑做一次"上下文引用消重"——只在 §1.1 ① 给完整串，§1.2 / §1.3 / §3.1 / §5.x 用"见 §1.1 ①"指针——但这是瘦身建议不是事实错误。

2.2 ✅ DrugGen-2 arXiv:2607.08404v1 + 5 个糖尿病肾病靶点 + 分子对接 -9.917/-9.485/-9.367 vs enalapril -8.283 + github.com/alimotahharynia/DrugGen-2

  • Stephen 主张（§0 / §1.1 ② / §1.2 主线 ③ / §1.3 ② / §3.3 / §4.1 #72 / §5.1 #68）：DrugGen-2，arXiv:2607.08404v1，base model = GPT-2（非 GPT-3/4），SFT → GRPO 强化学习，奖励函数四件套（化学有效性 + 新颖性 + 多样性 + 预测结合亲和力），5 个糖尿病肾病靶点，生成唯一分子更多，结构相似度更接近已批准药物，分子对接 -9.917 / -9.485 / -9.367 超 enalapril -8.283，github.com/alimotahharynia/DrugGen-2 已开源。
  • 核查结果：✅ 完全准确。web_search 抽 arXiv 2607.08404v1 摘要 + Isfahan team AIWeekly 报道：

    "DrugGen-2 fine-tunes a GPT-2 base with supervised training then GRPO reinforcement learning, conditioning molecule generation on both disease ontology and target protein sequence. Across five diabetic nephropathy targets, DrugGen-2 produced 409 to 444 unique molecules per run versus 219 for DrugGPT and 50 for DrugGen. Docking on ACE surfaced candidate ligands with predicted affinities of -9.917, -9.485, and -9.367, exceeding enalapril's -8.283 as a reference drug." 摘要原文："We developed DrugGen-2 by fine-tuning DrugGPT, a pretrained GPT-2 model specialized for ligand generation, on a curated dataset of approved drugs and their related disease-target information." + "15 pages, 2 figures, 1 table, and 4 supplementary files. To use the model, see this URL"——论文摘要明确给 GitHub 仓库链接（不是"承诺开源"），Stephen 写"摘要明确给仓库"准确。

  • Stephen 没引用但可补的细节：① AIWeekly 报道补充了 "409 to 444 unique molecules per run vs DrugGPT 219 vs DrugGen 50" 这个具体数字——Stephen 写"生成唯一分子更多"是定性表述，若 v23 想要"领域 LLM 第三个明示"更具传播力，可以补这个数字；② 论文用的 base model 实际是 DrugGPT（fine-tuned GPT-2），Stephen 写"base model = GPT-2"是简化表述，对严谨性来说写"fine-tuning DrugGPT（GPT-2 家族）"更精确——但这是 v22 整体方针"主题档 ≠ 论文摘要"的常见简化，可以接受。
  • 影响：✅ DrugGen-2 是 v22 第二个"信息密度高 + 传播力强"的 fresh 信号。Stephen 的"领域 LLM 三件套"（DrugGen-2 小模型 + JD Oxygen AIIC V1 工业级 + STEP3-VL-10B 通用多模态基础）整合是 v22 第二大知识创新。
  • 建议：① 未来 v23 棒可补"409 to 444 unique molecules vs 219 vs 50"这个对比数字；② §1.2 主线 ③ 把"base model = GPT-2"微调为"base = DrugGPT (GPT-2 家族 专门化版本)"更准确；③ §3.3 反方"base model = GPT-2 表示能力天花板"风险点仍成立，但应该用"GPT-2 家族 124M 参数 / 2021 词表"或"DrugGPT 是 2024 fine-tuned GPT-2 版本"这样的具体数字替代"天花板"——让反方更可量化。

2.3 ✅ DroPE arXiv:2512.12167 + Sakana AI + 训练用 RoPE / 推理扔 PE

  • Stephen 主张（§0 / §1.1 ③ / §1.2 主线 ① / §1.3 ③）：DroPE = Dropping Positional Embeddings，Sakana AI，arXiv:2512.12167，"训练时 RoPE 收敛 + 推理时 NoPE"，"避免 YaRN/RoPE-NTK 压缩低频分量带来的语义失真"，与 Jet-Long "正交双轨"。
  • 核查结果：✅ arXiv 编号 + Sakana AI 归属准确。web_search 抽 arXiv:2512.12167v1 + sakana.ai/drope + pub.sakana.ai/DroPE 三个独立来源：

    "We discovered that explicit positional embeddings like RoPE are critical for training convergence but eventually become the primary bottleneck preventing models from generalizing to longer sequences. Here, we achieve the best of both worlds by using embeddings to ensure stability during pretraining and then dropping them to unlock length extrapolation during inference." "DroPE uses positional embeddings as a training-time scaffold: pretrain with RoPE, then drop positional embeddings and briefly recalibrate at the original context length to recover RoPE-level perplexity while improving length generalization." "recalibrating any model with DroPE requires less than 1% of the original pretraining budget, yet it significantly outperforms established methods on challenging benchmarks like LongBench and RULER."

  • Stephen 提到但 arXiv 摘要未明示的细节：① "避免 YaRN/RoPE-NTK 压缩低频分量带来的语义失真"是 Stephen 的解读（DroPE 摘要原文是说 RoPE 是"primary bottleneck preventing models from generalizing to longer sequences"——即"成为长序列泛化的主要瓶颈"，没有直接说"压缩低频分量"或"语义失真"）；② "推理扔 PE"在 arXiv 摘要里更精确的表述是 "drop positional embeddings and briefly recalibrate at the original context length"——也就是说 DroPE 不是 100% NoPE，而是"在原始 context length 上做 brief recalibration"，v22 写"推理时 NoPE"是简化。
  • 影响：✅ 主体事实准确，但 "避免 YaRN/RoPE-NTK 压缩低频分量带来的语义失真"是 Stephen 自己的解读——如果要让"反方 / 不确定"段更严谨，应该标注 "[Stephen 解读] / [待 arXiv:2512.12167 §3 核验]"。
  • 建议：① §1.1 ③ 把"避免 YaRN/RoPE-NTK 压缩低频分量带来的语义失真"改为"避免 RoPE 在长序列外推时成为主要瓶颈"（更接近原文）；② §1.2 主线 ① 把"推理扔 PE"改为"推理时短暂 recalibrate 后去 PE"（更精确）；③ §3.2 #65 争议 + §4.1 #72 拐点保持原样——已经是"待消解"定位。

2.4 ⚠️ SGLang/vLLM 2026 市场份额 80%+（OSS Insight 数据，待核验）

  • Stephen 主张（§1.1 ④ / §3.3 / §4.1 / §5.1-§5.3 间接）：SGLang vs vLLM 2026 市场份额 80%+（OSS Insight 数据，待核验）。
  • 核查结果：⚠️ 没有直接证据。web_search 抽 "SGLang vLLM 2026 market share OSS Insight 80% inference engine"——找到的是：
  • Particula "SGLang vs vLLM in 2026" 报告说"SGLang 29% higher throughput than vLLM on H100s (16,200 vs 12,500 tokens/sec)"——这是技术对比，不是市场份额；
  • Yotta Labs "vLLM vs SGLang in 2026" 报告说 "vLLM optimized for throughput, SGLang designed for structured/multi-step/programmatic generation"——也是技术对比，不是市场份额；
  • LinkedIn / Modular 帖子 "Open-source LLM inference engines compared: SGLang, vLLM, MAX, and BentoML 2026" 也没有给出"80%+"具体数字。
  • Stephen 自标"（OSS Insight 数据，待核验）"——这种"自己标待核"是好事，但"80%+"在 6+ 处传播（§1.1 ④ + §1.2 主线 ① "vs Linear Attention 5 路线收敛" + §3.3 "CSDN 7-12 推理引擎横评 + 评测体系 7 层框架 + SGLang/vLLM 2026 市场份额 80%+ 原始数据源待核" + §4.1 #72 v22 拐点 + §5.1 #68 / §5.2 #58 / §5.3 #53 趋势段），且 §4.1 #72 / §5.1 / §5.2 / §5.3 都没把"80%+"作为"待核数据源"列入"v23 待消解开放项"。
  • 影响：① SGLang/vLLM 在 2026 H1 H100 production serving 上的相对份额可能接近 80%（vLLM ~50% + SGLang ~30%），但这是推断不是 OSS Insight 公开数字；② "80%+" 是个传播力极强的数字，若未来被 spark / flyP / Tom 引用时"Stephen 已 cross-check"会被默认——风险。
  • 建议：① 在 §1.1 ④ 把 "（OSS Insight 数据，待核验）" 改为 "（v22 推断 = vLLM ~50% + SGLang ~30% ≈ 80%，无 OSS Insight 公开数字直接证据；待 v23 用 OSS Insight 仓库 Star 数 + CNCF devstats + Star History 三方核验）"——让传播者明确知道这是推断不是事实；② §4.1 #72 拐点 / §5.1 #68 / §5.2 #58 / §5.3 #53 在引用"推理引擎横评"时，加"SGLang/vLLM 80%+ 数字待 v23 核验"短注；③ v23 待消解开放项 ⑪ 把这个数字独立列项（目前 ⑪ 写的是 "CSDN 7-12 SGLang/vLLM 2026 市场份额 80%+ + 评测七层框架 + AWQ 95%/GGUF 92% + GSM8K 量化敏感度 + 220 亿参数模型 89.7% 5 项原始数据源待核"——已含 80%+ 但被埋在 5 项中）。

3. 深度是否够（5 个角度）

3.1 ✅ 试金石 #62 长上下文架构 6 路并发 = 知识创新

v22 §1.3 跨主线整合段 ① "长上下文架构 6 路并发" 的 "编码方案（频域修正 / 扔掉 PE）+ 注意力机制（linear / softmax）+ 内存架构（context-aware / recurrent / 三阶段）+ 推理配置（floor-first / tile-based）四维正交架构空间" 是 应用层主题档少见的产品语言——把 6 件分散工作抽象为"4 维 × 多种取值"的选型矩阵，工程团队可以拿去对自己的场景做"我需要 PE 修还是扔 PE"、"我需要 linear attention 还是 softmax"、"我需要 context-aware memory 还是 recurrent memory"、"我需要 floor-first 还是 tile-based"四元决策。

深度足够。唯一补强建议：在 §1.3 ① 加 1 个 4 维 × 6 件的小表（行 = 6 件，列 = 4 维），让"4 维正交架构空间"的可视化更强。

3.2 ✅ "Stephen 不同意 #1-5" + "Stephen 不确定 #1" = 方法学勇气

§1.2 主线 ① 3 条"Stephen 不同意" + 1 条"Stephen 不确定" + 主线 ③ 5 条"Stephen 不同意" = 8 条个人反方——是少见的主题负责人"自己挂反方"动作。每条反方都对应一个可量化 / 可执行的实验设计： - "调度曲线黑盒"→ 调度曲线公式（线性 / 阶跃 / 自适应）+ 中段失真量化 - "GRPO reward hacking"→ 防护机制设计 - "跨家族可移植性"→ Llama-3.x / Mistral / DeepSeek / GLM / InternLM 五件迁移实验 - "数据集 leakage"→ 数据来源披露 + 训练-测试 split 严格性核验 - "超 enalapril 是预测值不是实验值"→ wet-lab 验证

深度足够。唯一补强建议：在 §0.5 试金石表加"反方 / 不确定"列，让 8 条反方在表里也能查到。

3.3 ⚠️ §1.1 ④ CSDN 7-12 推理引擎横评段——数字密度高但缺独立证据

§1.1 ④ 一次性塞了 5 段（SGLang/vLLM 80%+ / 评测七层 / 静态 vs 推理 Benchmark / AWQ 95% & GGUF 92% & GSM8K 量化敏感 / 220 亿参数模型 89.7% 压 GPT-4 88.5%），每段都是数字——这是"主题档"常见的"信息密度过高但证据链条短"问题。

深度问题： - "评测七层"分类法（CSDN 原文）是经验式分类，与 v20 / v21 试金石表中已存在的 "评测方法学" 体系（评测 × 部署 × 监管三角 + LM Judge → LLM-as-a-Verifier 概率化验证 + 训练-评测分歧）有重叠——没有说明"七层"与"概率化验证" / "评测×部署×监管三角"如何对接； - "AWQ 95% / GGUF 92% / GSM8K 数学代码量化敏感 2-3 倍"——这些是 CSDN 二次转述，原始来源应该是量化论文 / 框架 benchmark（AWQ 论文 / GGUF 官方仓库 / Hugging Face OpenLLM Leaderboard）——Stephen 没追到一手来源； - "220 亿参数模型 89.7% 压 GPT-4 88.5%"——具体哪个 22B 模型（MMLU/HumanEval/GSM8K 平均）、哪个 GPT-4 变体（GPT-4 Turbo / GPT-4o）、时间点全部不明确，这种 "5 数字 + 0 来源" 是健康风险。

建议：① §1.1 ④ 末尾加一句 "CSDN 7-12 二次转述，原始来源待核（v23 待消解开放项 ⑪）"；② §4.1 #72 / §5.1 #68 / §5.2 #58 / §5.3 #53 在引用"推理引擎横评"时显式标注"CSDN 二次转述，待 v23 一手核验"；③ v23 棒应把"评测七层"与"概率化验证 + 评测×部署×监管三角"做一张映射表。

3.4 ✅ 与最新进展的差距：v22 完整吸收 v21 / v20 / v17 / v18 / v16 / v14 全部试金石

v22 §0.5 试金石表 v1-v21 37 行完整保留 + §1.2 主线 ① v22 增 Jet-Long + §1.2 主线 ③ v22 增 DrugGen-2 + §1.3 跨主线整合段新建——这是 v1-v22 22 轮迭代中"历史保留 + 本轮增量"最稳的一档。与最新进展的差距只有 1 处：

  • §1.2 主线 ② Personal Assistant Agent / 主线 ④ Agentic RAG / 主线 ⑤ Application-layer Reliability 都是 v22 不变——这 3 条主线在 7-12 上午是否真的没有 fresh signal？ 建议 v23 棒做一次"7-12 全天雷达 vs 这 3 条主线"的 cross-check，确认"v22 不变"是基于"全天雷达覆盖 + 真无新信号"还是"雷达覆盖不全"。

3.5 ⚠️ 可读性问题：§0.5 试金石表 v22 不带"反方"列

§0.5 试金石表 37 行（v1-v21 累积）字段只有 4 列：# / 试金石标题（压缩版） / 主源 / 关键数字 / 版本——没有"反方 / 不确定 / 风险"列。但 v22 §1.2 主线 ① 3 条"Stephen 不同意" + §1.2 主线 ③ 5 条"Stephen 不同意" + §1.2 主线 ② / ④ / ⑤ 各 5-7 条"风险 v22 增补" + §3.3 反方 Jet-Long 7 项 + DrugGen-2 6 项 = 共 20+ 条反方 / 不确定 / 风险 散落在 §1.2 / §3.3 / §4.1 / §5.x 各处。

读者要交叉阅读 §0.5 + §1.2 + §3.3 + §4.1 + §5.x 才能拼出"每条试金石有哪些反方"的完整图。这是 v22 可读性的最大单一问题。

建议：① §0.5 加 1 列"反方 / 不确定 / 风险"——列出对应 §1.2 / §3.3 / §4.1 的反方编号；② 或者新增 §0.6 "v22 反方 / 不确定 / 风险速查表"——把 20+ 条反方收口到一节。

4. 有无误导（3 个角度）

4.1 ✅ 没有发现事实性误导

v22 全文通读 330 行 + 4 个独立事实抽检（Jet-Long / DrugGen-2 / DroPE / SGLang/vLLM 80%+）——没有发现"硬事实错误"。所有数字、arXiv ID、GitHub 仓库链接、机构归属、人员归属全部按一手摘要或 Substack 旁证匹配。Stephen 在 v22 Round 2 自评段"准确性：所有 arXiv ID + GitHub 仓库已 PDF / 摘要级核验"是真实的。

4.2 ⚠️ 潜在误导：CSDN 7-12 推理引擎横评 "SGLang/vLLM 80%+"

见 §2.4。核心风险是"传播力强 + 证据短"——SGLang/vLLM 80%+ 在 6+ 处被引用，但没有 OSS Insight 公开数字直接证据。Stephen 自标"（OSS Insight 数据，待核验）"是好事，但"待核验"状态没有传导到下游引用（§4.1 #72 / §5.x）。这是 v22 最有传播风险但有自我标"待核"的一个数字——若未来被 spark / flyP / Tom / jay 引用时丢失"待核验"标签，可能造成"事实已固化"的传播。

4.3 ✅ "DroPE vs Jet-Long 正交双轨" 没有误导但有简化

见 §2.3。"正交双轨" 的说法准确——Jet-Long 保留 RoPE 分窗口 + 动态因子 vs DroPE 训练用 RoPE 收敛 + 推理时短暂 recalibrate 后去 PE = 两种思路对"长上下文扩展是否需要显式位置编码"给出相反答案。Stephen 在 §1.1 ③ 写 "彻底换 PE 范式" 是简化——DroPE 实际是"短暂 recalibrate 后去 PE"不是"100% 立即去 PE"，但语义层"DroPE 走 no-PE 推理 vs Jet-Long 走 RoPE-faithful 推理"是准确的。

没有误导。建议：§1.1 ③ 把 "彻底换 PE 范式" 改为 "recalibrate 后去 PE 范式" 更精确；§3.2 #65 争议 / §4.1 #72 拐点保留原样。

5. 与最新进展的差距（2 个角度）

5.1 ⚠️ work-queue.md 第 1 行 Top-1 高价值待深度解读 = 2604.12162 AlphaEval = 与 v22 主题重叠

work-queue.md 第 1 行：

  • [2.1] 2604.12162 · 1. AlphaEval: Evaluating Agents in Production（agent, database, engineering, evaluation, llm-infra, multimodal, rag, risk）

AlphaEval = "Evaluating Agents in Production" 与 v22 §1.2 主线 ② Personal Assistant Agent / §1.2 主线 ⑤ Application-layer Reliability / §1.2 主线 ① Coding Agent 都直接相关——是 application-layer 主题档最该深度解读的候选之一，但 v22 没有把 AlphaEval 列入 §1.1 fresh signals / §1.2 主线 / §3.x / §4.x / §5.x 任何一处。

这是 v22 与工作队列的"待办错位"——work-queue.md 把 AlphaEval 列为 Top-1 高价值候选，v22 主题档却没接住。建议：① v23 棒应先做 "AlphaEval 2604.12162 短审稿"，确认它是"真实生产失效案例"还是"评测方法学"，然后归到 §1.2 主线 ② / ⑤ / ① 之一；② 同时检查 work-queue.md Top 8 高价值待深度解读（2604.12162 AlphaEval / 2603.29616 Video-Oasis / 2603.20397 KV Cache / 2603.10765 RAGPerf / 2602.19127 AgenticRAGTracer / 2602.00238 DIVERGE / 2511.01545 公共部门 ML Pipeline / 2405.03650 Generated Contents Enrichment）中哪些与 llm-application 主题直接重叠——目前看起来 AlphaEval / RAGPerf / AgenticRAGTracer / DIVERGE 4 件与 v22 主线 ② / ④ / ⑤ 直接相关。

5.2 ✅ 主题档 v1-v22 22 轮迭代保持稳定——是 wave 跨周 / 跨月对照的基线

v22 §7 沿革摘要 v1-v22 共 22 轮 + 关键 round 修订段，试金石 37 件完整保留——是 application-layer 主题档"长期可对照"的关键资产。与最新进展的差距仅在 §5.1 一处。

6. 可执行性（3 个具体修改建议）

6.1 🔧 v23 棒前必须做（高优先级）

  1. 替换 "v22 ~XXKB" 占位符为实际值：v22 输出文件大小段 = "~XXKB（v21 ~46KB → v22 ~XXKB）" + Round 3 修订段 = "全文瘦身：v21 ~46KB → v22 ~XXKB = 归档 v21 完整记录至 archive/llm-application-changelog-v21.md（v21 段已在 v21 写入时落地）"——两个占位符未替换。Stephen 应在 v23 起草前 wc -c llm-application.md 然后替换。同时建议 Round 3 修订段 "v21 段已在 v21 写入时落地" 与实际 "v22 文件大小未填" 自相矛盾——需要同步修正。
  2. §1.1 ④ "CSDN 7-12 SGLang/vLLM 80%+" 标"v22 推断 ≈ vLLM ~50% + SGLang ~30%"——见 §2.4。这是 v22 最有传播风险但有自我标"待核"的一个数字，v23 棒前必须修正表述。
  3. §0.5 试金石表加"反方 / 不确定 / 风险"列——见 §3.5。这是 v22 可读性的最大单一问题。

6.2 🔧 v23 棒应做（中优先级）

  1. §1.3 ① "4 维正交架构空间" 加 1 个 4 维 × 6 件小表——见 §3.1。
  2. §1.1 ③ DroPE "彻底换 PE 范式" → "recalibrate 后去 PE 范式"——见 §2.3 / §4.3。
  3. §1.2 主线 ③ DrugGen-2 "base model = GPT-2" → "base = DrugGPT (GPT-2 家族 专门化版本)"——见 §2.2。
  4. §3.3 反方 "GPT-2 表示能力天花板" → "GPT-2 家族 124M 参数 / 2021 词表"——让反方可量化。

6.3 🔧 v23 棒可做（低优先级）

  1. §1.1 ② DrugGen-2 补 "409 to 444 unique molecules vs DrugGPT 219 vs DrugGen 50"——见 §2.2。
  2. §1.2 主线 ② / ④ / ⑤ "v22 不变" 做"7-12 全天雷达 vs 这 3 条主线" cross-check——见 §3.4。
  3. work-queue.md Top 1-8 高价值待深度解读 vs llm-application 主线 cross-check——见 §5.1。AlphaEval 2604.12162 = v23 必读。
  4. v23 待消解开放项 ⑪ 把 "CSDN SGLang/vLLM 80%+" 独立列项——目前 ⑪ 写 5 项原始数据源待核（80%+ 被埋在第 1 项）。

7. 一句话总结

Stephen v22 活文档是"知识创新 + 回填密度 + 个人反方"三件套强、"占位符未替换 + 80%+ 数字证据短 + 试金石表无反方列"三件套弱的稳定档。v22 = 8 分。v23 棒前必须做 6.1 三件事；v23 棒中做 6.2 四件事；v23 棒后做 6.3 四件事。

Jay-on-Stephen · 2026-07-12 15:00 CST · Wave2 E3 互评 · 第 6 轮迭代