很多团队测长上下文只做一次「128k 大海捞针」，结论写一句「支持 128k」。真正上线后出问题的往往是中间段落，所以建议把评测做成随版本跑的回归项。

一套最小可跑的矩阵：
1) 长度档：8k / 32k / 64k / 128k（按实际 tokenizer 的 token 数对齐，不按字符数）。
2) 插入位置：0% / 25% / 50% / 75% / 100%。
3) 干扰类型：随机拼接、同主题改写两类分别统计，后者更接近真实文档检索场景。
4) 每格至少多个随机种子，报均值与区间；固定解码参数与提示模板。

工程落地要点：
- 样本生成脚本、语料快照、模板字符串都进版本库，运行清单里记录各自哈希。
- 除了对错，记录首 token 延迟、输出长度、是否夹带干扰内容，以及最长档的资源占用（显存/耗时）。
- 设一条回归基线：新版本任一格相对上一版下降超过阈值就阻断发布，并自动保存对应原始输出供人工复核。
- 区分「检索失败」与「推理失败」：同一题目在短上下文下也答不对，属于能力问题，不应归因到长度。

报告形态建议是一张热力图 + 每档的 p95 延迟，比单数字更容易推动优化。

结论：长上下文能力是二维甚至三维的分布，不是一条「最大长度」规格。把它做进 CI，升级模型时才有可比的基线。