[

  {
    "title": "FORT-Searcher",
    "url": "/wiki/deep-search/fort-searcher/",
    "summary": "FORT 在构造期控制四类 shortcut，用轨迹签名校准可解但搜索重的任务；仅 SFT 的 FORT-Searcher 在同规模开源搜索 agent 中总体最优。",
    "lang": "zh-CN",
    "updated": "2026-08-04",
    "content": "Overview FORT（Framework of Shortcut-Resistant Training-Data Synthesis）把 实现难度分析 反转为构造期控制：在问题落成文之前，用内部证据图作工作区，调控选择性、分散度与依赖深度。FORT-Searcher 是仅在所得轨迹上做 supervised fine-tuning 的搜索 agent。 难度框架与 轨迹签名 见对应概念页；本页聚焦合成管线、训练设定与实证。 四阶段合成 1. Graph initialization 从 Wikidata 选长尾根实体：主题覆盖（去掉抽象概念）、实体冷门（偏好无英文维基页的稀有实体）、信息密度（轻量预搜索确认可解）。用预挖掘的 cycle 而非线性链做种子——线性种子容易把下游实体名逼进题面（exposed constants）；cycle 把根嵌进闭合局部结构，关系线索可不点名每个中间节点。cycle 写入 entity-to-cycle 倒排索引，去重节点集，并过滤 hub、冗余与大众协作结构。 2. Graph construction 在深度与节点预算下扩展，优先扩展最深未处理节点，以保留多步引用链成为串行依赖。Enricher 从 Wikidata、开放网页、结构化库、Google Scholar、Google Maps 等异构源采原子事实，刻意避免从同一证据项抽多条入选事实；并构造 derived facts（coincidence bridging、count aggregation、numerical relation、meta-fact extraction），使其难以在单条检索中原文出现。再做来源一致性与实体一致性检查。Expander 偏好 generic 事实而非代表性事实：过于特征的事实会让单线索过选择性，故保留「单独弱、组合才 identifying」的可靠事实。 3. Question formulation 选答案节点，剪冗余，保留联合 identifying、个体 generic 的线索；中间节点名改成泛指指称；剩余字面量做 exact-value fuzzing（类别泛化、范围放宽、元属性描述、算术编码、对比排除）。Fuzzing 不是为了暧昧或不可验证，gold answer 必须保留。 4. Adversarial refinement 强对抗 agent 在真实搜索设定下打草稿，按轨迹签名验收：答对、检索轮数够、答案出现够晚、且无证据前绑定。过快解开的草稿按路线级 shortcut 修（换 co-covered 证据、去过选择性事实、隐瞒/fuzz 暴露常量；若先验点名则换根或加强证据路径）。预算内解不出的草稿按过度模糊或欠指定修（收窄线索、去歧义、恢复约束）。 精炼两侧可见：易捷径草稿从 cost 33.9 / hit 12.4 到 82.7 / 31.4，prior-shortcut rate 从 17.0 到 12.0； initially 未解草稿精炼后可解，仍保留 cost 123.0 / hit 50.2。精炼是校准「可解但搜索重」，不是单纯加压。 训练与推理 基座：Qwen3-30B-A3B-Thinking-2507（MoE，推理约激活 3B/30B，256K 上下文）。仅 SFT：sequence packing、6 epochs、global batch 64、最大序列长度 262,144。 推理用 context-managed 协议：同一 rollout 内保留工具结果以复用证据；触达轮次上限仍无终答则清空交互史、从原问题重启。 主要证据 同规模开源 agent 中，FORT-Searcher 五基准总体平均 66.2，高于 MiroThinker-1.7-mini 的 64.6。BrowseComp 72.2，BrowseComp-ZH 75.0（所列开源含更大模型中最优），xbench-DeepSearch-2505 80.8，xbench-DeepSearch-2510 与同规模最优并列 57.2。例外是 Seal-0：46.0 vs MiroThinker-1.7-mini 的 48.2（该基准偏噪声/冲突证据下的搜索增强推理，而非长程证据发现）。 累计消融（2K 题）：完整管线求解准确率 29.0（更高=更易），去掉全部控制升到 81.6；cost 从 141.9 落到 43.7，hit time 从 46.5 前移到 11.8，prior-shortcut rate 从 11.4 到 22.3。该去除顺序下，去掉 fuzzing 对难度打击最大；因是累计而非逐组件，排序依赖顺序。轨迹对照与标注代理数字见 轨迹签名。 局限 训练仅 SFT；与 RL 结合留待后续。 Headline BrowseComp 很大一部分来自推理侧 context-management：关掉后 BrowseComp 从 72.2 到 55.9，BrowseComp-ZH 从 75.0 到 62.1，另三个基准变动小得多。与其他 agent 对比时应确认是否启用同类机制。 Prior-shortcut rate 与轨迹代理的保守性、固定求解器依赖，见轨迹签名页。 See Also 深度搜索概览 实现难度与 Shortcut 轨迹签名 Visual reading: FORT-Searcher"
  },

  {
    "title": "深度搜索问题地图",
    "url": "/wiki/deep-search/overview/",
    "summary": "深度搜索训练数据的核心问题是如何制造答案出现前的长证据前缀，而不是只把轨迹、hop 数或图结构做长。",
    "lang": "zh-CN",
    "updated": "2026-08-07",
    "content": "Overview 训练深度搜索智能体需要的不是「看起来很长」的任务，而是答案出现前的长证据前缀：求解器必须先收集足够证据，才有条件锁定答案。现有合成管线常靠加 hops、加图结构、加层级约束或加大证据分散来抬高表观难度，但结构复杂度不一定变成 agent 实际经历的长程证据获取——求解过程可能塌缩到更便宜的 identifying route。 当前主题以 FORT-Searcher 为起点。它还不是深度搜索训练的完整综述，而是一张问题地图：什么决定实现难度、shortcut 如何让任务变浅、轨迹里该看什么信号、以及构造期能怎样压住这些风险。 问题地图 什么才是“难” 深度搜索难度不由题面 hops 或证据图大小直接决定，而由最便宜的 identifying route 决定。求解器不必验证全部线索，只要某个 identifying subset 已能唯一锁定答案，任务就可能沿这条弱路径被解掉。详见 实现难度与 Shortcut。 为什么任务会变浅 Shortcut 是让题目以少于设计意图的证据获取被解掉的机制。当前已归纳四类：single-clue selectivity、evidence co-coverage、exposed constants、prior-knowledge binding。前三类压低结构下界，第四类来自模型侧先验绑定。详见 实现难度与 Shortcut。 怎样观察真实搜索负载 理论下界在开放网页搜索上难以全量计算，因此需要轨迹签名。Realized solving cost 看总查询数，answer hit time 看答案首次出现位置，prior-shortcut rate 看模型是否在证据前点名答案。真正有用的是长 pre-answer search，而不是长轨迹本身。详见 轨迹签名。 构造期如何压住风险 FORT 把上述诊断反过来用于数据合成：从图初始化、图扩展、问题表述到对抗精炼，持续压制过选择性线索、证据共覆盖、暴露常量和先验绑定。系统细节与训练结果见 FORT-Searcher。 共同主张 有用的深度搜索监督是「答案出现前的长前缀」，不是「总检索步数很长」。当前证据主要来自 FORT 一篇来源，因此本 topic 暂时把 FORT 作为系统证据锚点，而不把它写成领域全貌。待扩展问题包括：同类诊断在不同搜索后端和求解器上是否稳定、RL 是否能进一步利用这类数据、推理侧 context management 对 headline 分数的贡献占比有多大。 See Also 实现难度与 Shortcut 轨迹签名 FORT-Searcher"
  },

  {
    "title": "实现难度与 Shortcut",
    "url": "/wiki/deep-search/realized-difficulty/",
    "summary": "实现搜索难度由最便宜的 identifying route 决定；四类 shortcut 会把表观复杂任务塌成浅层检索或先验绑定。",
    "lang": "zh-CN",
    "updated": "2026-08-04",
    "content": "Overview 任务实例写成三元组：答案空间、问题表达的约束集、检索接口。问题良定，故完整约束集唯一确定 gold answer。关键观察是：求解器不必验证每条线索，只需为某个 identifying subset（已能把候选缩到唯一答案的约束子集）取得证据。因此实现难度由验证该子集的最便宜路线决定，而不是任务设计者设想的那条路线。 结构下界可写成所有 identifying subset 上的最小路线代价；无先验、不瞎猜的参考求解器的代价被该下界卡住。这是单边、weakest-link 性质：只要有一个 identifying subset 又浅又集中，整题就变简单，与底层证据图多大无关。极端情形下，若某 identifying subset 可用一条初始即可执行的查询验证，结构下界塌成单次检索。 决定下界的四个量 三个客观量控制下界与其上的缺口，第四个量依赖具体模型： Subset selectivity：只用部分线索后剩余候选池大小。它不直接下界路线长度，而是设定探索缺口；当小子集已足够 identifying，它决定哪些子集进入最小化。 Evidence dispersion：在忽略查询可执行性时，验证 gold 满足某线索子集所需的最少检索次数。若同一网页同时陈述两个本意事实，一步即可，计数降为 1。 Dependency depth：查询串行链中最长链的长度——后续查询需要的名字或中间事实只能由更早检索暴露。它纯来自查询可执行性。 Solver-side cost reduction：具体模型相对无先验参考求解器省下的代价，典型来自参数记忆认出目标。 固定 identifying subset 的路线代价至少是 evidence dispersion 与 dependency depth 的较大者；具体求解器的实现代价是无先验代价减去其 solver-side reduction。四个量把缺口归因到具名因子。 四类 Shortcut 风险 Shortcut 指任何让题目以少于设计意图的证据获取被解掉的机制。前三类作用于结构下界，第四类作用于模型侧减量。 Single-clue selectivity：一条或一小撮线索就把候选缩到一个或少数。即便子集并非严格 identifying，高选择性也会在有限检索结果里过早浮出答案。诊断例：四条独立线索本应汇聚到同一年，求解器只用「彩色电视」线索一查就把该年当作主候选，其余线索沦为事后验证。 Evidence co-coverage：单次检索的页面或 snippet 同时验证多条本意约束，把多步计划压成一步。诊断例：一条搜索结果 snippet 同时暴露答案实体及其行业、区域持股等答案侧事实。 Exposed constants：问题表面露出本应靠更早检索发现的精确名字、字符串、日期或数字，使下游查询从一开始就可执行，缩短串行依赖。诊断例：把目标人物的独特公开引语嵌进题面，模型几乎原样复用该短语，结果直接点名答案。关键是露出的字符串是目标的唯一属性，而非泛化中间线索。 Prior-knowledge binding：求解器在检索证据锚定之前就提交 gold answer。它不降低结构下界，故对无先验求解器仍需长证据路线的题，对已记住实体的模型仍可平凡。诊断例：模型在任何工具调用前就点名答案，之后才检索「证据」。 与主题其他页的关系 理论量难以在开放网页搜索上大规模精确计算（需枚举答案空间、所有 identifying subset 与合法路线），因此实现效果用 轨迹签名 诊断；FORT-Searcher 把这些风险反转为构造期控制。 See Also 深度搜索概览 轨迹签名 FORT-Searcher"
  },

  {
    "title": "轨迹签名",
    "url": "/wiki/deep-search/trajectory-signatures/",
    "summary": "用 solving cost、answer hit time 与 prior-shortcut rate 诊断实现难度；长轨迹不等于长答案前前缀，FORT 显著拉长 pre-answer search。",
    "lang": "zh-CN",
    "updated": "2026-08-04",
    "content": "Overview 实现难度框架 中的理论量在开放网页搜索上难以全量计算。FORT 一文因此在固定求解器与检索预算下，用三条可观测的轨迹签名诊断实现难度，并据此比较开源深度搜索数据与 FORT 合成数据。 三条签名 Realized solving cost：成功轨迹上的平均检索查询数。单独看证明力弱——长轨迹可能只是绕路。 Answer hit time：gold answer 或其规范化别名首次出现的步数，取检索观察与模型可见文本中较早者。更晚的 hit time 意味着更长的答案前搜索前缀，这是压住廉价 identifying route 后期望看到的行为。 Prior-shortcut rate：成功轨迹中，模型在任何检索锚定答案之前就提到答案的比例。作者称其为保守代理，只捕捉可见的 answer-before-evidence 行为。 真正有诊断价值的是 solving cost 与 answer hit time 的缺口：总步数很长但答案很早出现，说明监督并不「搜索重」。 开源数据 vs FORT 同一强 agent、同一预算下重评六个开源深度搜索数据集：表观轨迹长度 ≠ 搜索重监督。OpenSeeker 的 solving cost 为 84.7，但 answer hit time 仅 9.3，prior-shortcut rate 达 31.9。REDSearcher 在开源基线中签名最强（cost 92.1、hit time 18.7），答案仍远早于总成本。FORT 达到 cost 141.0、hit time 46.9，同时 prior-shortcut rate 为 11.0。 FORT 的额外代价并非来自更多 prior-bound 行为：hit time 显著后移，prior-shortcut rate 更低。 训练对照：长轨迹 ≠ 有用难度 四组各 12K 例、同一配方训练：把开源数据平均 solving cost 从 40.0 经 85.0 抬到 140.0，BrowseComp 仅从 47.1 到 49.5。把 cost 固定在 140.0 但换成 FORT 数据（hit time 47.0、prior-shortcut rate 11.4，对比开源侧 22.3 与 18.1），BrowseComp 到 52.9，BrowseComp-ZH 到 60.3。有用难度是长 pre-answer 前缀，不是长轨迹本身。 标注代理与局限 另对开源与 FORT 各 200 条成功 question–trajectory 做因子到可观测代理的映射：相对开源，FORT 把「自身证据只留下 1–2 个合理候选」的线索占比从 55.2 降到 40.2，归一化 evidence dispersion 从 78.7 升到 90.2，最贵答案前依赖链的检索代价从 3.1 升到 5.9，prior-bound 占比从 27.0 降到 16.0。 局限：prior-shortcut rate 只检测口头提前点名答案的模型；轨迹代理是实现效果而非理论量估计；签名依赖固定求解器与检索后端，换模型或搜索后端诊断会漂移。 See Also 深度搜索概览 实现难度与 Shortcut FORT-Searcher"
  },

  {
    "title": "Harness Engineering",
    "url": "/wiki/harness-evolution/harness-engineering/",
    "summary": "Harness engineering 把模型外部的 workflow、context、工具、文件系统记忆、评估与权限控制视为可演化的能力层。",
    "lang": "zh-CN",
    "updated": "2026-08-07",
    "content": "Overview Harness 是包裹 base model 的运行系统：决定模型如何计划、调用工具、读取和压缩 context、写入 artifact、保存历史、并用评估反馈推进下一步。相比早期 “LLM + memory + tools + planning + action” 的 agent 框架，harness engineering 更接近 runtime 和软件系统设计：它处理 workflow、permission controls、persistent state management 与 evaluation。 这使 harness 成为冻结模型能力增长的外部层。权重不变时，系统仍可以通过更好的上下文组织、更可靠的工具协议、更可恢复的文件系统记忆、更合适的 workflow 和更稳的评估门控提升长程任务表现。 三个基础设计模式 Weng 将近端 harness 设计概括为三个常见模式： Workflow automation：给模型一个可执行、可测试、可迭代的 loop，例如 plan → execute → observe/test → improve → execute again。重点不只是 prompt，而是让模型能分析自身轨迹和失败案例，并通过 agent runtime 继续推进。 File system as persistent memory：长程 rollout 中的 logs、code diffs、paper summaries、error traces 与 trajectories 会远超上下文窗口。把状态落到文件系统，让模型按需读取，比把全部历史塞进 context 更可恢复。 Sub-agent and backend jobs：主 agent 可以显式启动并监控并行子任务、后台实验或假设搜索；关键是让 parallelism inspectable，并把输出保存为文件、日志和状态记录，而不是只留在短暂 chat context。 这些模式解释了为什么 Skill Library 只是 harness evolution 的一层：技能文件、.memory.md、测试、脚本和资源都属于更大的 persistent state / tool protocol 设计空间。 优化对象层级 Harness optimization 的对象可以从浅到深排列： instruction prompts → structured context → workflow → harness code → optimizer code。 Meta Context Engineering 主要把 structured context 和 context-management mechanism 变成可演化对象；Meta-Harness 直接搜索 harness code，并让外部 coding agent 读取候选源码、分数和 traces；Self-Harness 则要求目标模型基于自身 held-in 失败提出 bounded harness edits，再用 held-in / held-out 非回归规则接受。 因此，harness engineering 的核心问题不是“哪条 prompt 更好”，而是能否把运行系统本身做成可观测、可评估、可修改的对象。 Self-Improvement 语境 Weng 把 harness engineering 放进 recursive self-improvement（RSI）的近端路径：现代系统短期内未必先让模型直接改写权重，而是让模型改善训练 pipeline 或 deployment system，再由更好的系统支持后续模型、研究或任务执行。 这一路线的含义是：外部 harness 可能先承担“认知机械”的一部分。手写 prompt trick 可能被更强模型内化，但目标、约束、上下文、工具和评估接口不会消失；它们会变成更稳定的系统边界。 评估、权限与长期目标 Harness evolution 的风险来自它优化的信号本身。若 reward 来自单元测试，agent 可能过拟合测试；若来自 judge model，可能学到 judge-specific reward hacking；若来自 benchmark，可能利用 benchmark artifacts。Weng 因此强调 evaluator 和 permission control 应尽量位于 harness-evolving loop 外部，并配合 held-out tests、trace audits 与关键节点的人类审查。 长期软件工程目标也难以用短期 sandbox reward 表达。Coding agent 可以完成当前任务，但标准 RLVR 风格训练通常捕捉不到 maintainability、ownership boundaries、migration cost、backwards compatibility 或未来 debugging burden。Harness evolution 若要服务真实工程环境，评估必须覆盖这些长期成本，而不只是 pass count。 See Also Harness Evolution 概览 Skill Library 技能生命周期 Meta Context Engineering Meta-Harness Self-Harness"
  },

  {
    "title": "Meta Context Engineering",
    "url": "/wiki/harness-evolution/meta-context-engineering/",
    "summary": "MCE 用双层优化共演化 CE skills 与 context artifacts：meta 层 agentic crossover，base 层以 files/code 做完全 agentic 上下文工程。",
    "lang": "zh-CN",
    "updated": "2026-08-07",
    "content": "Overview Meta Context Engineering（MCE）把 Context Engineering（CE）从「人工固定 harness + 预定 schema」改成可学习的 agentic 能力。它形式化为双层优化：外层演化规定「如何表示与学习 context」的 CE skill；内层在给定技能下优化 context artifact（files 与 code）。与本主题既有的任务技能库（Voyager / AutoSkill / MUSE 等）不同，MCE 的技能对象是 做 CE 的策略本身，而 ACE、GEPA 等静态 CE 管线被看作该设计空间里的单点。 代码仓库：ace-agent/ace。 双层问题与编排 Context 函数 $c$ 由静态组件 $\\rho$ 与动态算子 $F$（检索、筛选、格式化等）组成。MCE 引入技能 $s$，由 base-agent 执行得到 $c_s$，并求解： [s^{}=\\arg\\max_{s} J_{\\mathrm{val}}(c_{s}^{})\\quad\\text{s.t.}\\quad c_{s}^{*}=\\arg\\max_{c_{s}} J_{\\mathrm{train}}(c_{s};s).] 编排采用 history-informed $(1+1)$-ES：每轮 meta-agent 生成一个 offspring skill → base-agent 产出 context → 用验证集与当前最优比较并保留更优者；技能历史 $\\mathcal{H}$ 记录 $(s,c,J_{\\mathrm{train}},J_{\\mathrm{val}})$。meta / base 均使用通用工具集（Read / Write / Edit / Bash / Glob / Grep / TodoWrite），权限按角色与迭代限定。 Meta：Agentic Skill Evolution Agentic crossover 相对固定遗传重组：LLM agent 审议任务规格 $\\tau$、任意检查历史技能文件夹与执行评估，再合成新技能。技能在 workspace 中是文件夹，实践中可含：自然语言方法论、可执行脚本、结构化模板、验证协议、以及按 query 过滤/组装的动态检索算子。 作者观察：演化技能会调节自主性与粒度（刚性工作流 vs 全权委托）、按任务与模型容量调节 verbosity，并利用 train/val 信号监测过拟合、偏向泛化。 Base：Files/Code 上下文工件 Base-agent 在技能文件夹、上一轮最优 context、训练 rollouts 与可选 LLM/embedding 工具下执行 Engineer，把 context 写成目录中的静态知识与动态算子代码，而不预置 itemized list 等 schema。这与 ACE 的 generation–reflection–curation 固定管线形成对照：后者可被 MCE 重建，但不是唯一点。 实证要点 五域评测（FiNER、USPTO50k、Symptom2Disease、LawBench、Aegis2.0），主生成器 DeepSeek-V3.1（Aegis2.0 用 Qwen3-8B）。相对 base 的 Avg. Rel. Gain（Table 1）：offline MCE 89.1（ACE 70.7，GEPA 61.5）；online MCE 74.1（ACE 41.1）。相对 SOTA agentic CE 的相对改进为 5.6–53.8%（均值 16.9%）。相对 DeepSeek-V3.1 base，offline / online 平均相对提升分别为 89.1% / 74.1%，并分别高出 prior SOTA 18.4% / 33.0%（相对改进口径，见原文 Introduction）。 Method FiNER Acc.% USPTO50k Acc.% Symptom2Disease Acc.% LawBench Micro-F1 Aegis2.0 F1 Avg. Rel. Gain% Base 58.0 6.0 63.7 0.36 0.54 – ACE (offline) 71.0 18.0 79.2 0.65 0.68 70.7 MCE (offline) 75.0 20.0 89.2 0.70 0.80 89.1 ACE (online) 64.0 13.0 62.3 0.63 0.57 41.1 MCE (online) 68.0 20.0 76.4 0.66 0.63 74.1 适应性：有效 context 长度可随任务约在 1.5K–86K tokens（FiNER 最优约 1.5K / 20K；LawBench / USPTO50k 可达 44K / 86K）。FiNER 效率：约 1.5K tokens 时 MCE-S 73% vs ACE Step-20 的 65%；MCE-L 20K tokens 达 75%，高于 ACE 5 epoch 的 70%（约 79K tokens）。训练：FiNER 上 MCE 5 epoch 约 1.9 hours vs ACE 25.8 hours（约 $13.6\\times$）；达 95% train acc 约 450 rollouts vs ACE 峰值 94% 的 2169（约 $4.8\\times$ 更少）。强→弱迁移时，MCE 的 Avg. Rel. Drop 通常低于 ACE（如至 Qwen3-8B：Table 2 中 MCE 为 17.1，ACE 为 23.6）。 消融：online 的 MCE (w/o skills) Avg. Rel. Gain 为 Table 1 的 71.3，完整 MCE 为 74.1，说明技能演化有贡献但 base agentic CE 已很强。 局限与主题定位 作者自述：更利于领域知识与模式匹配；对已有强反思 harness 的推理密集型任务、以及超长复杂 trajectory 的细粒度 credit assignment 可能不占优。评测域是垂直 CE benchmark，不是 SkillsBench；与 Ratchet / MUSE 关于「LLM 自写任务技能」的争议互补，不宜直接对撞。 相对本主题：MCE 把「技能」抬到 学习算法 / harness 层，用验证信号做技能级选择，而不是任务技能库的 librarian（add/merge/retire）。表示上仍落在可执行文件夹技能，与 Skill Library 中 Agent Skills 传统一脉。 与 Meta-Harness 的对照 后续工作 Meta-Harness 在 GPT-OSS-120B 的在线文本分类协议下，把 MCE 与 ACE 一并作为手工 harness 基线：其 Table 2 报告 MCE 平均准确率 40.0（Ctx 28.5K）、ACE 40.9（50.8K）、所发现 harness 48.6（11.4K）。这是 另一基座与绝对准确率口径 下的比较，不能用来改写上文 DeepSeek-V3.1 的 Avg. Rel. Gain（offline 89.1 / online 74.1）。机制上：MCE 共演化 CE skill 与 context artifact；Meta-Harness 用 coding agent + 全历史 filesystem 直接搜索完整 harness 程序，并进一步评测数学检索与 TerminalBench-2。 从 Harness Engineering 的层级看，MCE 位于 structured context 与 context-management mechanism 之间：它已经超过静态 prompt / memory 设计，但还没有像 Meta-Harness 那样直接搜索完整 harness code。 See Also Harness Evolution 概览 Harness Engineering Meta-Harness Skill Library 技能生命周期 MUSE-Autoskill Skill Curation RL"
  },

  {
    "title": "Meta-Harness",
    "url": "/wiki/harness-evolution/meta-harness/",
    "summary": "Meta-Harness 用 coding agent 外环搜索 harness 代码，经 filesystem 访问历次源码、分数与执行轨迹，在分类、数学检索与 TerminalBench-2 上超过 ACE/MCE 与手工 harness。",
    "lang": "zh-CN",
    "updated": "2026-08-07",
    "content": "Overview Harness 是包裹冻结 LLM 的有状态程序：决定每一步存什么、取什么、给模型看什么。作者指出同一 benchmark 上仅改 harness 可造成约 $6\\times$ 性能差距；实践中 harness engineering 仍多靠人工改启发式。 Meta-Harness 是搜索 harness 的外环：proposer 是 coding agent（实验中为 Claude Code + Opus-4.6），反馈通道是不断增长的 filesystem——每个候选目录含源码、评估分数与执行轨迹（prompts、工具调用、模型输出、状态更新）。proposer 用 grep / cat 等按需读取，而不是把历史压成标量分或短摘要。外环刻意极简：维护种群与 Pareto 前沿，但不硬编码亲本选择；诊断与改写交给 agent。典型跑法约 20 轮、共评估约 60 个 harness。 在更大的 Harness Engineering 框架里，Meta-Harness 位于“workflow → harness code → optimizer code”这条深化线上：它不是优化单条 prompt，而是把运行模型的程序空间交给强 coding agent 搜索。 项目页与 TerminalBench-2 产物：meta-harness、artifact。 与 text optimizer / MCE 的差别 Table 1 对照 OPRO、TextGrad、AlphaEvolve、GEPA、Feedback Descent、TTT-Discover 等：其单次评估可用上下文多在约 0.002–0.026 MTok，而 Meta-Harness 设定下单次评估诊断可达约 10.0 MTok。主张是：harness 决策影响长程行为，压缩反馈会切断失败与早期设计选择之间的因果链。 相对 MCE：两者都在「元优化 CE / harness」线上，但机制不同。MCE 用双层优化共演化 CE skill 与 context artifact；Meta-Harness 直接在 完整 harness 程序空间 搜索，并把外环诊断信息暴露为可查询的全历史文件系统。ACE / MCE 在本文中是在线文本分类设定下的强手工基线，而非被重构的唯一设计点。 相对 Self-Harness：两者都把 harness 当成可修改对象，但优化者的位置相反。Meta-Harness 依赖外部 coding agent 读取历史源码、分数和 traces 后搜索候选 harness；Self-Harness 则要求被评估的同一固定模型依据自身 held-in 失败聚类提出 bounded edits，再用 held-in / held-out 非回归规则接受。前者强调全历史诊断接口和完整程序空间，后者强调减少对更强外部优化器的依赖。 在线文本分类 设定沿用 ACE / MCE 工作：LLM 逐条接收带标签样本、更新 memory，再在 held-out 上评测。基座为 GPT-OSS-120B；数据集为 USPTO-50k、Symptom2Disease（S2D）、LawBench。搜索初始化含 zero-shot、few-shot、ACE、MCE；20 轮、每轮 2 候选，共 40 个 harness。 Table 2 测试集（Avg Acc / Ctx↓，Ctx 为额外 context tokens，千）： Harness USPTO S2D Law Avg Acc Ctx ↓ MCE† 14.0 83.0 23.0 40.0 28.5 ACE† 16.0 77.8 29.0 40.9 50.8 Meta-Harness 14.0 86.8 45.0 48.6 11.4 相对 ACE 高出 7.7 points、相对 MCE 高出 8.6 points；context 约为 ACE 的 $1/4$ 量级（11.4K vs 50.8K）。† 实现来自 Ye et al.。这些是 本文化协议下的绝对平均准确率，与 MCE 原文在 DeepSeek-V3.1 上的 Avg. Rel. Gain 口径不同，不宜直接对撞。 相对 text optimizer（同 proposer 配置、同评估预算、仅用 search-set 选优）：Meta-Harness 以约 $0.1\\times$ 评估次数追平 OpenEvolve / TTT-Discover 的最终水平，最终再高出 10 点以上。Table 4（search-set）：Meta-Harness median 50.0 / best 56.7；OpenEvolve 39.1 / 43.3；TTT-Discover 34.1 / 45.6；GEPA 32.6 / 40.2。 Table 3 消融：Scores Only median 34.6 / best 41.3；Scores + Summary 34.9 / 38.7；Full（含 traces）50.0 / 56.7。作者据此认为 raw execution traces 是关键接口成分，摘要无法恢复诊断信号。 OOD 九数据集（Table 5）：Meta-Harness 平均 73.1（Ctx 7.3），ACE 70.2（Ctx 11.7）；在 6/9 数据集上最高。 检索增强数学推理 在 $\\geq$ 500,000 题语料上搜索 retrieval harness（40 轮、109 候选；search set 250 道 Olympiad 难度题）。选出的单一 harness 在 200 道未见过的 IMO 级题上，于五个 held-out 模型平均相对无检索高出 4.7 points（Table 6：No Retriever 34.1 → Meta-Harness 38.8），并略高于 BM25（37.5）。同一 harness 在搜索未见的模型上仍为正增益。 TerminalBench-2 在 89 题同一 benchmark 上做 discovery 式搜索与评测（作者说明为公开竞赛式 harness 迭代惯例，并用人工/正则检查任务特有串泄漏）。Table 7： 基座 Meta-Harness 对照要点 Claude Opus 4.6 76.4% 超 Terminus-KIRA 74.7；榜上仅 ForgeCode 81.8 更高 Claude Haiku 4.5 37.6% 超 Goose 35.5；该模型族报告结果中 #1 附录定性：TerminalBench-2 跑中 proposer 每轮中位读 82 个文件（约 41% 源码、40% traces）；早期把结构修复与 prompt 改写绑在一起导致回归后，能显式诊断 confound 并转向更安全的增量修改。 局限与主题定位 外环依赖强 coding agent；作者未系统比较多种 proposer。 TerminalBench-2 非严格 held-out 划分；应读作发现型基准优化，并依赖其过拟合检查叙述。 相对任务技能库路线（Voyager / MUSE / SkillOS / Ratchet），本文优化的是 任务侧 harness 程序（分类 memory、检索策略、agent 编排），不是 librarian 对 SKILL.md 库的 add/merge/retire。 相对 MCE：同属 CE/harness 元优化，但一个演化「如何做 CE 的 skill」，一个用全历史诊断搜索「整份 harness 代码」。 相对 Self-Harness：两者共享 TerminalBench-2 作为 harness 改进证据场景，但 Meta-Harness 是外部搜索器优化 harness，Self-Harness 是目标模型自我提出并验证 bounded harness edit。 See Also Harness Evolution 概览 Harness Engineering Meta Context Engineering Self-Harness Skill Library 技能生命周期"
  },

  {
    "title": "MUSE-Autoskill",
    "url": "/wiki/harness-evolution/muse-autoskill/",
    "summary": "ByteDance 的训练无关技能生命周期框架：运行时创建、skill-level memory、单测评估与跨 agent 迁移，在 SkillsBench / SkillLearnBench 上验证。",
    "lang": "zh-CN",
    "updated": "2026-08-07",
    "content": "Overview MUSE-Autoskill（Memory-Utilizing Skill Evolution）把技能当作可长期治理的资产，而不是一次性生成物。它在同一 agent 回路里覆盖五阶段生命周期——creation、memory、management、evaluation、refinement——并强调 skill-level memory、单测评估与跨 agent 可迁移的技能包。名称含 Autoskill，但与 ECNU 的 AutoSkill（对话轨迹抽象 SKILL.md）是不同系统。 五阶段生命周期 技能包遵循 Anthropic Agent Skills 目录约定（含 SKILL.md；可选 tests/ 与脚本）。主循环是 ReAct 式 Planning / Action / Observation，功能尽量外置为技能；内置能力包括 skill_create 与 web_search。 Creation：在运行时通过 skill_create 从成功轨迹蒸馏技能，消解「先离线造技能、再另场景用」的 creation–usage mismatch。 Memory：多层记忆——短期上下文、跨会话长期笔记，以及每技能旁路的 skill-level memory（.memory.md，加载时与 SKILL.md 一并浮现）。 Management：目录注入 system prompt（progressive disclosure）；维护含 refinement、合并近重复、裁剪持续失败或闲置条目。 Evaluation：代码型技能优先跑 tests/ unit tests，未通过则阻断注册；无测试时回退 sandbox / 轨迹反馈。 Refinement：失败触发 update_skill 补丁再检，形成 create → evaluate → register 回路。 配套基础设施还包括对话 DAG 上的两级自适应上下文压缩（单节点摘要 → 链段合并），以及可跨会话持久化的状态。 SkillsBench 与 SkillLearnBench 证据 四个 GPT-5.5 骨干 agent：Hermes、Codex、Claude Code、MUSE-Autoskill。SkillsBench 用 75-task × 5-run 严格分母；无可用自建技能的任务在自建设定下计 0。 设定 Hermes Codex Claude Code MUSE SkillsBench 无技能 37.24% 44.80% 42.43% 46.95% SkillsBench 人写技能 48.02% 57.58% 56.15% 59.67%（+12.72pp） SkillsBench 自建技能（all-75） – 47.52% 44.27% 53.42%（+6.47pp） SkillLearnBench 人写 / 自建 70.0% / – 68.0% / 40.0% 63.0% / 37.0% 72.0% / 48.0% 覆盖子集上，MUSE 自建技能准确率 85.24%，高于同子集人写 81.17%（覆盖 47/75，未覆盖 28 计 0）。作者将主瓶颈定为生成覆盖率，而非已生成技能质量。 跨 agent 迁移（技能注入 Hermes，不做任务特化修改）：MUSE 自建技能使 Hermes 达 51.90%（相对无技能 +14.66pp），高于 Hermes 人写技能 48.02%；同覆盖规模下 Codex 自建技能转入 Hermes 为 37.01%（几乎无效），Claude Code 自建为 45.97%。 局限（作者自述）：自建技能常由单条成功轨迹蒸馏并在同一任务复评，可能高估 within-task 增益；跨 agent 主要验证了 MUSE→Hermes；早期版本还讨论过更小任务子集带来的高估风险。 与主题内其他路线的关系 相对 AutoSkill 的对话抽取与 add/merge/discard，MUSE 更强调运行时创建、单测与 skill-level memory。相对 SkillOS 的可训练 curator，MUSE 为 training-free。相对 Ratchet 的 hygiene / retirement，MUSE 更偏完整创建—评估—迁移栈，而非最小 librarian 配方。 MUSE 与 Ratchet 对“LLM 自写技能是否有效”的解释不同：MUSE 把主瓶颈放在生成覆盖率与运行时评估闭环，Ratchet 则把重点放在 librarian / hygiene。完整争议见 自写技能有效性争议。 See Also Harness Evolution 概览 Skill Library 技能生命周期 自写技能有效性争议 Meta Context Engineering Skill Curation RL"
  },

  {
    "title": "Harness Evolution 概览",
    "url": "/wiki/harness-evolution/overview/",
    "summary": "Harness Evolution 关注冻结模型如何通过技能库、context、workflow、harness code 与评估闭环积累外部能力。",
    "lang": "zh-CN",
    "updated": "2026-08-07",
    "content": "Overview 冻结 LLM 的长期能力不一定来自更新权重，也可以来自围绕模型的外部系统：技能库、结构化 context、workflow、tool/runtime 协议、文件系统记忆、评估器、权限边界，以及能被搜索或自我修订的 harness code。Harness Evolution 关心的不是“又出现了哪个系统”，而是这些外部资产如何让同一个模型在更长任务、更复杂反馈和更多历史经验中变强。 当前 topic 的主骨架是问题地图；系统页只作为证据锚点。MUSE-Autoskill、MCE、Meta-Harness、Self-Harness 等页面保留，是因为它们会被多个问题反复引用，而不是因为每篇来源都应该变成系统页。Lilian Weng 的综述把这些线索整理成更大的 RSI 近端路径：先优化模型外部的运行系统，再让更强的运行系统支持更好的研究、训练或部署循环。 问题地图 技能资产长什么样 技能是 harness evolution 的一个资产层，而不是唯一对象。Voyager 把技能做成可执行代码；AutoSkill 把对话经验抽成 SKILL.md；MUSE-Autoskill 采用带 tests/、脚本和 .memory.md 的 Agent Skills 包；SkillOS 把外部 SkillRepo 交给 curator 维护。关键问题是：资产要保留多少程序性结构、多少自然语言规则，以及是否能被独立测试和迁移。详见 Skill Library。 库如何不漂坏 库增长本身会制造噪声、冲突、重复与过时条目。AutoSkill 给出 add / merge / discard 与版本化合并；MUSE 把创建、评估、更新、合并和裁剪放进同一运行时；Ratchet 把瓶颈明确为 librarian / hygiene，并强调 retirement、active cap 与 meta-skill authoring prior。详见 技能生命周期。 策展能否被学习 启发式 librarian 只能表达人的先验。SkillOS 把 executor 冻结，只训练 skill curator，并用 grouped task streams 与 composite rewards 从延迟反馈中学习长期策展策略。这个方向把「如何改库」本身变成可优化策略，而不是固定规则。详见 Skill Curation RL。 LLM 自写技能到底有没有用 这是本 topic 的主要争议。Ratchet 引用 SkillsBench 原文，把“LLM 自写技能无增益”解释为生命周期治理瓶颈；MUSE-Autoskill 在全生命周期 agent 中报告自建技能仍有正增益，并认为瓶颈更多在生成覆盖率。这个分歧不能靠单一分数裁决，必须保留协议、agent 栈、覆盖口径和技能治理差异。详见 自写技能有效性争议。 Harness 到底优化什么 Weng 把 harness optimization 的对象序列概括为 instruction prompts → structured context → workflow → harness code → optimizer code。MCE 演化 CE skill，Meta-Harness 用外部 coding agent 搜索任务侧 harness 程序，Self-Harness 让目标模型依据自身失败轨迹提出 bounded harness edits；三者都不是 task skill librarian，而是把“如何运行模型”本身变成可评估、可修改的对象。详见 Harness Engineering、Meta Context Engineering、Meta-Harness 与 Self-Harness。 评估与权限边界如何不被优化器破坏 自我改进 loop 优化的永远是给定信号。若信号来自单元测试、judge model 或公开 benchmark，系统可能学到 test overfitting、judge hacking 或 benchmark artifact。Harness evolution 因此不能只看 pass rate；评估器、trace audit、held-out tests、权限控制和 human review 需要在关键决策点留在可演化 loop 外部。 共同主张与边界 共同主张：能力增长可以发生在外部资产或外部 harness 上，而不必先更新权重。真正的分歧在于资产边界与反馈回路：技能是代码、Markdown、带测试的包，还是完整 harness；维护靠启发式、单测、RL curator、外部 coding agent 搜索，还是目标模型自提 harness edit；评估看任务成功、覆盖率、迁移性、搜索/上下文成本、held-out 非回归，还是长期可维护性。 本 topic 暂时把“外部能力演化”作为共同边界：任务技能库、context engineering 与 harness code search 都属于它；直接改模型权重、纯 self-play 训练或通用 continual learning 只在与 harness loop 联合优化时进入本 topic。 See Also Skill Library 技能生命周期 Skill Curation RL 自写技能有效性争议 MUSE-Autoskill Harness Engineering Meta Context Engineering Meta-Harness Self-Harness"
  },

  {
    "title": "自写技能有效性争议",
    "url": "/wiki/harness-evolution/self-authored-skills/",
    "summary": "Ratchet 将 SkillsBench 的 LLM 自写技能 null result 解释为 librarian 问题；MUSE-Autoskill 则显示全生命周期 agent 下自建技能仍有正增益。",
    "lang": "zh-CN",
    "updated": "2026-08-07",
    "content": "Overview “LLM 能不能自己写出有用技能”不是一个单一 yes/no 问题。Ratchet 和 MUSE-Autoskill 给出的结论看似冲突，实际比较的是不同系统栈、不同生命周期治理和不同计分口径下的自写技能。 本页把争议保留下来：Ratchet 侧强调 SkillsBench 的 null result 说明瓶颈在 librarian；MUSE-Autoskill 侧强调当创建、记忆、管理、评估与精炼放进同一运行时后，自建技能仍能带来正增益。 Ratchet 的解释 Ratchet 引用 SkillsBench 原结果：human-curated skills deliver +16.2pp，LLM-self-generated skills deliver +0.0pp。作者据此认为，问题不在“LLM 不会写技能”，而在技能库缺少生命周期治理：近重复失败标签未归一，弱技能不退役，活跃集合无上限，作者先验不稳定。 因此 Ratchet 的处方不是训练 curator，而是在冻结 LLM 单 agent 回路中加入 hygiene：pattern canonicalisation、outcome-driven retirement、bounded active-cap、meta-skill authoring prior。其主张是：自写技能若没有 librarian，会被噪声、重复和过时条目拖垮。 MUSE-Autoskill 的反例 MUSE-Autoskill 在四个 GPT-5.5-backed agent 的 SkillsBench common set 上重新评估技能创建与使用。MUSE 无技能准确率为 46.95%，人写技能为 59.67%，自建技能 all-task 口径为 53.42%。这说明自建技能仍低于人写技能，但不是零增益。 MUSE 进一步报告：在成功覆盖的子集上，自建技能为 85.24%，同子集人写技能为 81.17%。作者将主要瓶颈解释为生成覆盖率，而不是已生成技能完全无效。跨 agent 迁移中，MUSE 自建技能注入 Hermes 后达到 51.90%，高于 Hermes 人写技能的 48.02%。 如何并置这两个结论 两边不应被写成谁完全推翻谁： Ratchet 讨论的是朴素自写技能在 SkillsBench 原语境中的 null result，并把重点放在 librarian / hygiene。 MUSE 讨论的是带运行时创建、skill-level memory、单测评估、更新与裁剪的完整 agent，在严格 all-task 口径下仍有正增益，但覆盖失败仍被计入分母。 双方都承认技能质量和生命周期治理有关；差别在于 Ratchet 把治理视为首要瓶颈，MUSE 进一步把覆盖率、评估门控和跨 agent 迁移纳入系统。 因此本 topic 的中性表述应是：自写技能是否有效，取决于创建协议、覆盖率、评估门控与库治理；不能只用“LLM 自写 +0.0pp”或“覆盖子集超过人写”单独裁决。 See Also Harness Evolution 概览 技能生命周期 MUSE-Autoskill"
  },

  {
    "title": "Self-Harness",
    "url": "/wiki/harness-evolution/self-harness/",
    "summary": "Self-Harness 让固定模型依据自身失败轨迹提出 bounded harness edits，并用 held-in / held-out 非回归门控筛选可推广的 harness 改动。",
    "lang": "zh-CN",
    "updated": "2026-08-07",
    "content": "Overview Self-Harness 研究一个比 Meta-Harness 更内化的 harness 改进设定：固定模型不依赖人类工程师，也不依赖更强外部 agent，而是在当前 harness 下读取自己的执行失败证据，提出下一版 harness 的 bounded edit。模型权重、评估器与任务协议保持固定，只有围绕模型的非参数 scaffold 被修改。 这使它成为 Harness Engineering 中最接近 recursive self-improvement 的证据线之一：能力增长不只来自任务技能库或外部搜索器，也可能来自 agent 对自身执行协议的受控修订。 三阶段闭环 Self-Harness 的一次迭代包含三步： Weakness Mining：在 held-in 任务上运行当前 harness，收集执行轨迹与 verifier outcome。失败样本按 verifier-grounded failure signature 聚类，signature 同时记录终端 verifier cause、agent 行为的因果状态与可复用的 agent mechanism。这样做是为了避免把 timeout、missing artifact 等表层结果误当成同一种可修复机制。 Harness Proposal：同一个固定模型在 proposer 角色中读取 failure evidence bundle、当前 editable surfaces、已通过行为与历史失败编辑，生成多个 materially distinct、minimal 的 harness 修改。每个候选都必须绑定一个具体 failure mechanism 与可编辑 surface，而不是泛泛加长 prompt。 Proposal Validation：每个候选 harness 在 held-in 与 held-out split 上重新评测。接受规则要求至少一个 split 改进、另一个 split 不退化；若多个兼容候选通过，再合并进下一版 harness。被拒候选保留在日志中，不改变 active harness。 与 Meta-Harness 的关系 Self-Harness 与 Meta-Harness 都把 harness 当成可优化对象，但优化者位置不同： 维度 Meta-Harness Self-Harness Proposer 外部 coding agent，实验中使用 Claude Code + Opus-4.6 被评估的同一固定模型 反馈接口 filesystem 中的候选源码、分数与完整 traces 当前模型自身 held-in 失败聚类与 proposal history 搜索空间 完整 harness 程序空间，可局部编辑也可重写 declared editable surfaces 上的 bounded edits 接受逻辑 search-set / Pareto 前沿等外环选择 held-in / held-out 非回归规则 因此，Self-Harness 不是 Meta-Harness 的替代结论，而是补上另一个问题：如果没有更强外部优化器，目标 agent 能否把自己的失败机制转成可验证的 harness 改动。 Terminal-Bench-2.0 证据 实验使用 Terminal-Bench-2.0 的固定 64-case subset，排除不稳定外部网页资源与初始 harness 不支持的 multimodal 任务。三种模型 backend 保持模型、解码配置、预算、工具集、benchmark 环境与 evaluator 不变，仅允许修改 harness。 held-out pass rate 均提升： 模型 Initial Self-Harness MiniMax M2.5 40.5 61.9 Qwen3.5-35B-A3B 23.8 38.1 GLM-5 42.9 57.1 held-in 也同步提升：MiniMax M2.5 从 43.0 到 50.0，Qwen3.5-35B-A3B 从 15.1 到 36.0，GLM-5 从 47.7 到 57.0。论文据此强调，改动不是只修 held-in failure，而是在 held-out 上也保留了正收益。 模型特异的 harness 改动 Self-Harness 的定性分析显示，被接受的改动不是一条统一提示词： MiniMax M2.5 的 retained edits 主要处理 missing required artifacts、schema-invalid tool content 与 stalled tool-use loops，推动 agent 更早创建输出文件、谨慎处理结构化工具内容，并在长工具交互后重定向。 Qwen3.5-35B-A3B 的改动强调 dependency precheck、避免重复失败命令、打破无效探索循环，以及在工具错误后恢复 required artifacts。 GLM-5 的改动集中在 shell 会话间持久化环境设置，以及从长时间探索转向实现与测试。 共同模式是 artifact reliability：不同模型暴露出不同执行病理，但高价值 harness edit 往往能把失败轨迹里的机制性弱点转成可执行的运行约束。 局限 Self-Harness 仍是 bounded harness edits under fixed benchmarks，不是开放式递归自我改进。接受门主要基于 pass-rate non-regression；在高风险环境中，仅靠 held-in / held-out pass count 不足以证明安全性或鲁棒性。实验也依赖 verifier outcome 与 trace record 的质量，若评估器看不见关键失败机制，Weakness Mining 会缺少可靠证据。 Weng 的综述进一步强调：如果可演化程序能编辑自身运行环境，抽象边界会被打破；editable surface、permission control、security layer 和 evaluator 应设计在自我编辑 loop 外部，否则 reward hacking 与 verifier tampering 仍会成为核心风险。 See Also Harness Evolution 概览 Harness Engineering Meta-Harness Meta Context Engineering 技能生命周期"
  },

  {
    "title": "Skill Curation RL",
    "url": "/wiki/harness-evolution/skill-curation-rl/",
    "summary": "SkillOS 把冻结 executor 与可训练 curator 拆开，用 grouped task streams 与 composite rewards 从延迟反馈中学习长期技能策展策略。",
    "lang": "zh-CN",
    "updated": "2026-08-04",
    "content": "Overview 启发式技能操作与短视改编，很难从间接、延迟的执行反馈里学到长期策展策略。SkillOS 的处方是：不要端到端改写整个 agent，而是只训练 skill curator，让它维护外部 SkillRepo；agent executor 冻结，只负责按库检索与执行任务。 架构 Executor 𝜋L：冻结；给定任务与检索到的技能完成求解。 Curator 𝜋S：可训练（实现上以 Qwen3-8B 为基座，GRPO）；根据累积经验更新 SkillRepo（Markdown 技能文件）。 Grouped task streams：按技能相关依赖组流式任务——先出现的轨迹更新库，后出现的相关任务评估这些更新，从而给策展决策提供可学习信号。 Composite rewards：把下游 executor 的成效更准确地归因到策展动作，而不是只看即时一步。 推理训练数据从 DeepMath-103k 抽样 33,000 条；agentic 评测在 ALFWorld 与 WebShop，推理评测含 AIME24、AIME25、GPQA-Diamond。 主要证据 以 Qwen3-8B 为 curator 时： ALFWorld、Qwen3-8B executor：SkillOS 平均 SR 61.2，强记忆基线 ReasoningBank 为 55.7；相对 No Memory 的 47.9 提升更大，步数也更低（18.9 vs 基线更高步数档）。 同一 curator 可接到更强 executor：Gemini-2.5-Pro 在 ALFWorld 上从 66.4 到 80.2。 WebShop 与推理平均准确率同样抬升；例如 Qwen3-8B executor 上推理 Avg. Acc 到 73.8，Qwen3-32B executor 上到 79.7，Gemini-2.5-Pro executor 上到 88.6。 直接用 Gemini-2.5-Pro 当 curator（SkillOS-gemini）往往不如训练过的 8B curator，说明「更强生成 ≠ 更好策展」，需要与 executor 能力对齐的策展行为。 分析还报告：学到的 curator 技能使用更有针对性；SkillRepo 随时间形成更丰富结构与更高层 meta-skills。 在主题中的位置 相对 AutoSkill 的训练无关 merge 规则，以及 Ratchet 的固定 hygiene 配方，SkillOS 把「如何改库」本身当成策略学习问题。代价是需要可分组的任务流与可归因奖励；收益是 curator 可跨 executor / 域迁移，而不必为每个执行骨干重训整条 agent。 See Also Harness Evolution 概览 Skill Library 技能生命周期 MUSE-Autoskill（training-free 全生命周期对照）"
  },

  {
    "title": "Skill Library",
    "url": "/wiki/harness-evolution/skill-library/",
    "summary": "技能库是 harness evolution 的外部程序性记忆层；核心形态包括可执行代码、SKILL.md、SkillRepo 和带测试的 Agent Skills 包。",
    "lang": "zh-CN",
    "updated": "2026-08-07",
    "content": "Overview Skill library 把「做过一次的事」变成「以后还能调」的外部记忆。它不是原始对话回放，而是可检索、 ideally 可组合、可治理的程序性工件。在 Harness Engineering 语境下，skill library 是 persistent state / tool protocol 的一个资产层；核心问题是：技能应写成可执行代码、自然语言规范、Markdown 仓库，还是带测试和资源的 Agent Skills 包；这些表示如何影响检索、组合、评估和迁移。 MCE 与 Meta-Harness 使用相似的文件/代码资产，但它们的对象已经转向 CE skill 或完整 harness，属于本 topic 的边界问题，而非普通任务技能库形态。 Voyager：可执行代码技能 每个技能是通过 self-verification 的函数式程序。描述由 GPT-3.5 生成，embedding 作向量库 key，value 是程序本体。新任务时检索 top-5 相关技能，注入 GPT-4 代码生成上下文；复杂行为通过组合已有程序放大能力，并缓解 catastrophic forgetting。写入门槛高：环境反馈、解释器错误与 critic 式 self-verification 通过后才 commit。去掉 skill library 后后期探索趋于平台；完整系统相对基线约 3.3 倍独特物品、约 2.3 倍路程，并是唯一解锁 diamond 工具的方法。 AutoSkill：SKILL.md 工件 技能是可编辑、可版本化的 SKILL.md（Agent Skill 标准）：身份、标签、触发器、提示与约束。SkillBank 按 Users / Common 持久化并用向量索引。相对 Voyager，这里的技能多为自然语言行为规范与工作流，面向对话助手的个性化与制度性偏好，而不是 Minecraft 电机级程序。 SkillOS：Markdown SkillRepo SkillOS 沿用社区「技能即文件夹 / Markdown 指令」设定，把外部 SkillRepo 交给可训练 curator 维护；冻结 executor 只负责检索与执行。分析表明，学习后的库会发展出更丰富内部结构与更高层 meta-skills，策展本身比单纯换更强生成模型更关键。 MUSE-Autoskill：可测试的 Agent Skills 包 MUSE 采用 Anthropic Agent Skills 目录约定：SKILL.md 定义接口；可选 scripts/、resources/、tests/。执行时先读接口（progressive disclosure），再按需读资源或跑脚本；代码执行经 sandbox 工具隔离。每技能可附 .memory.md，跨任务追加失败模式、输入格式与性能备注，加载时与接口一并注入。注册前优先跑 unit tests；无测试则回退 sandbox / 轨迹检查。该表示同时服务本机复用与跨 agent 迁移实验（详见 MUSE-Autoskill）。 边界：CE skill 与 harness 程序 MCE 的技能也是 workspace 文件夹，但语义是 CE 策略：可含自然语言方法论、可执行脚本、结构化 context 模板、验证协议，以及按 query 过滤/组装的动态算子。Meta-Harness 的候选资产通常是任务侧 harness 程序及其执行痕迹。二者说明文件/代码资产可以被抬到更高层优化对象，但阅读时应与 task skill library 区分。 共同边界 上述表示都依赖检索或加载质量；库增长后噪声、冗余与过时条目会拖垮有效上下文。表示问题与治理问题应分开看：见生命周期、策展 RL，以及 MCE 用验证集做技能级选择、Meta-Harness 用全历史 traces 做程序搜索的对照。 See Also Harness Evolution 概览 Harness Engineering 技能生命周期 MUSE-Autoskill Meta Context Engineering Meta-Harness Skill Curation RL"
  },

  {
    "title": "技能生命周期",
    "url": "/wiki/harness-evolution/skill-lifecycle/",
    "summary": "技能库瓶颈常在 librarian 与评估：AutoSkill / Ratchet / MUSE 管任务技能；MCE、Meta-Harness 与 Self-Harness 则把生命周期问题抬到 harness 层。",
    "lang": "zh-CN",
    "updated": "2026-08-07",
    "content": "Overview 会写技能不等于库长期有用。技能库会遇到版本、冲突、重复、闲置和失效问题，因此需要 librarian：什么时候 add、merge、discard、retire，什么时候通过测试或任务反馈阻断注册。AutoSkill、Ratchet 与 MUSE-Autoskill分别给出不同生命周期处方。关于“LLM 自写技能是否有效”的冲突证据，单独见 自写技能有效性争议。 在更宽的 Harness Engineering 语境下，技能生命周期是外部能力演化的局部问题：同样的“生成候选 → 评估 → 保留 / 合并 / 回滚”结构，也会出现在 context function、workflow 和 harness code 的迭代中。 AutoSkill：add / merge / discard 在线路径做 hybrid 检索与 Top-K 注入；演化路径从交互抽候选技能，再经 management judge 在 add、merge、discard 中决策。merge 不是拼接，而是 versioned evolution：保留可复用约束、合并增量并 bump 版本。案例：professional_text_rewrite 到 0.1.34，说明高频生产力技能可反复精炼；低频技能可停在 0.1.0。SkillBank 统计（WildChat-1M，>8 turns，四子集 N=1858）显示库以编程与写作为中心，但仍覆盖多样沟通类技能。 AutoSkill 强调可检视与可编辑，但对「按任务贡献退役」与「硬容量上限」着墨有限；Ratchet 的对照表也将其标为缺少 outcome-driven retirement 与 bounded active-cap。 Ratchet：四类 hygiene 单 agent 回路里，冻结 LLM 同时写、取、管、退自然语言技能。四个候选机制： Pattern canonicalisation：近重复失败标签归一，避免同 bug 生两技能。 Outcome-driven retirement：按贡献分与证据门槛降级弱势技能。 Bounded active-cap：活跃槽有限，迫使竞争进入 Router shortlist。 Meta-skill authoring prior：约束 Synthesizer 风格，隐式去重。 技能多从 failure cluster 合成，偏 pitfall / 负向约束。MBPP+ hard-100（Claude Opus 4.7，100 rounds，3 seeds）上 Default 相对 round-0 的 0.258 基线，late-window rolling mean 到 0.584，gain +0.328，peak 0.658；无技能对照几乎不涨。SWE-bench Verified 上有 +0.22 peak lift。 消融要点：去掉 skill injection 增益消失；去掉 meta-skill 损伤大；harsh retirement 可掉到无技能地板以下；显式 canonicalisation / cover-guard 在此规模可被 meta-skill 吸收；更频繁 meta-skill refresh（A8）多花约 55% wall-time 换边际收益。Proposition 1：有限 cap 与 retirement threshold 一起保证期望表现不会无界掉到无技能地板之下。 MUSE-Autoskill：运行时生命周期与评估门控 MUSE 把五阶段（creation / memory / management / evaluation / refinement）放进同一 ReAct agent。关键差别是：skill_create 在执行回路内调用，代码型技能用 tests/ unit tests 门控注册，失败则 update_skill 再检；管理侧支持精炼、合并与裁剪。记忆上除短/长期层外，每技能有 .memory.md 积累跨任务经验。 SkillsBench 75-task（GPT-5.5）上，MUSE 人写技能 59.67%（相对无技能 +12.72pp），自建技能严格 all-75 为 53.42%（+6.47pp）；覆盖 47/75 时覆盖子集 85.24% vs 同子集人写 81.17%。跨 agent：MUSE 自建技能转入 Hermes 达 51.90%，高于 Hermes 人写 48.02%。作者将主瓶颈定为生成覆盖率。完整数字与争议语境见 MUSE-Autoskill。 对照 维度 AutoSkill Ratchet MUSE-Autoskill 技能来源 对话/轨迹偏好与工作流 失败簇合成 运行时成功轨迹蒸馏（skill_create） 维护动作 add / merge / discard + 版本 retirement + active-cap + meta prior 单测门控、update、merge、prune 训练 训练无关 plug-in 权重冻结，无 RL curator 训练无关；强调跨 agent 迁移实验 实证形态 SkillBank 统计与案例 MBPP+ / SWE-bench 定量增益与消融 SkillsBench / SkillLearnBench + Hermes 迁移 三者都承认库需要治理；AutoSkill 偏标准化工件与持续合并，Ratchet 偏结果驱动裁剪，MUSE 偏创建—评估闭环与可迁移技能包。 MCE：元层技能选择（对照） MCE 的「生命周期」发生在 CE skill 上：每轮 agentic crossover 生成 offspring，base 执行后写入 $\\mathcal{H}$，再按 $J_{\\mathrm{val}}$ 做 $(1+1)$-ES 式保留。meta-agent 可监测 train/val 并抑制过拟合，但没有 AutoSkill 式 merge/discard 目录，也没有 Ratchet 的 active-cap / retirement 配方。对象是 harness（如何学 context），不是任务技能库 librarian；评测在 FiNER 等 CE 域，不裁决 SkillsBench 争议。细节见 Meta Context Engineering。 Meta-Harness：候选 harness 种群（对照） Meta-Harness 也不做任务技能库的 add/merge/retire。它维护已评估 harness 的种群与 Pareto 前沿，把每次评估的代码、分数与 traces 追加进 filesystem；proposer 自行决定读哪些历史、做局部编辑还是重写。选择信号来自 search-set（及多目标时的 Pareto），外环本身几乎不写死亲本规则。对象是任务侧 harness 程序，评测覆盖分类、数学检索与 TerminalBench-2 discovery 设定。 Self-Harness：失败簇驱动的 harness 迭代（对照） Self-Harness 的生命周期对象同样不是任务技能，而是当前模型运行所依赖的 harness。它先从 held-in 失败轨迹中构造 verifier-grounded failure patterns，再让同一固定模型提出多个 minimal harness edits，最后用 held-in / held-out 非回归规则接受或拒绝候选；多个通过的候选可合并为下一版 harness。相对 Meta-Harness 的外部 coding-agent 搜索，这条路线把 proposer 内化到目标模型自身，但也更依赖 failure signature 与 verifier outcome 是否能暴露真实机制。 See Also Harness Evolution 概览 Harness Engineering Skill Library 自写技能有效性争议 MUSE-Autoskill Meta Context Engineering Meta-Harness Self-Harness Skill Curation RL"
  },

  {
    "title": "FP8 训练 Recipe",
    "url": "/wiki/llm-quantization/fp8-training/",
    "summary": "FP8 训练靠 TE/MCore recipe 在 GEMM 上用 E4M3/E5M2 或 MXFP8；显存与通信收益取决于 primary weights 与并行策略，不等于推理侧 FP8 PTQ。",
    "lang": "zh-CN",
    "updated": "2026-08-11",
    "content": "Overview 大规模预训练里的 FP8，首先是 训练期混合精度 recipe：把 linear 的 fprop / dgrad / wgrad GEMM 输入量化到 FP8，用 Tensor Core 加速；不是 GPTQ/AWQ 那种训后 INT4 权重量化，也不同于只把推理权重压到 FP8。 工具链上，Transformer Engine（TE）管 layer 内（量化、GEMM、多数 fusion、SDPA backend、TP overlap、CP 等）；Megatron-Core（MCore）管 layer 上（PP/EP/DP、建模、optimizer、checkpoint）。 FP8 格式与缩放 NVIDIA Ada/Hopper 起提供 FP8 Tensor Core。常见两种： E4M3：1 符号 + 4 指数 + 3 尾数；PyTorch 为 torch.float8_e4m3fn（fn 因 OCP E4M3 不保留 inf） E5M2：1 符号 + 5 指数 + 2 尾数；torch.float8_e5m2 宣称收益：FP8 Tensor Core 算力约为 BF16 的 2 倍；理想下 weight/activation 显存与通信量可减半——实际取决于是否去掉 BF16 副本、以及通信能否 FP8 化。 因范围与精度有限，训练必须有缩放：对 tensor 或 tile（sub-channel/group/block）取 amax，缩放到 FP8 可表示最大值。对比：BF16 训练通常不需要缩放；FP16 常用全局 loss scale。 OCP 另有 MXFP8：每 32 个 E4M3/E5M2 共享一个 E8M0 scale。 Recipe 三维 一个 FP8 recipe 至少含： 格式：纯 E4M3；或 Hybrid（activation/weight 用 E4M3，gradient 用 E5M2 → 前向 E4M3×E4M3，反向两个 E4M3×E5M2 GEMM） 粒度：至少 per-tensor；更细则定 tile 大小与 1D/2D 覆盖范围：实践上几乎只量化 linear（qkv、projection、fc1、fc2）；embedding、lm head、SDPA、main gradients、optimizer states 仍高精度。无 reduction 的通信（AllGather、AlltoAll）理论上可 FP8；有 reduction 的保持高精度。FP8 attention 尚无生产模型落地。 常用三种 Recipe 格式 粒度 定位 Per-tensor current scaling Hybrid 每 tensor 一个 scale TE Float8CurrentScaling；MCore --fp8-format hybrid --fp8-recipe tensorwise Blockwise（DeepSeek-V3-like） 纯 E4M3 act/grad 1×128，weight 128×128 当前最流行；TE Float8BlockScaling；CUDA 12.9+ MXFP8 纯 E4M3 + E8M0 均 1×32 Blackwell 主推；仅该代 Tensor Core 原生支持 Delayed scaling（用历史 amax buffer）可打破 amax 与量化依赖、少读 global memory，但 amax 非当前真值；作者实验称 >7B 即可观察到收敛问题，当下可直接忽略。Current / live scaling 对当前 tensor 统计 amax 再量化，多一次读；Nemotron-H-56B 用其证明可收敛。 计算流：加速三个 GEMM BF16 baseline：三个 GEMM 输入为 BF16；fprop/dgrad 输出 BF16，wgrad 输出常为 FP32（便于累加）。Tensor Core 内部累加是 FP32，输出精度只是最后 cast。 FP8 训练主要是把这三个 GEMM 的 input 量化到 FP8；output 一般仍是 BF16/FP32，不必再量化。 Hopper：FP8 GEMM 仅 TN layout → 常需 cast / cast_transpose；同一步内 weight 可在首个 micro-batch 量化后缓存复用；前向后通常只保存一份 colwise FP8 input 供反向，以减激活显存。 Blackwell：任意 layout 的 FP8 GEMM，常可省转置；若量化方向不同，仍可能需要 rowwise 与 colwise 两份数据。 Blockwise 在 Hopper 上实质需要两类 GEMM：128×128 @ 1×128（2D×1D）与 1×128 @ 1×128（1D×1D）。Blackwell 上可用 MXFP8 模拟 blockwise（如 1×128 拆成 4 个共享 scale 的 MXFP8）。MXFP8 若 weight 也是 1D，即使任意 layout 仍常要存 rowwise+colwise 两份；weight 改 2D（如 32×32）可避免。 显存：不会自动减半 默认路径从 BF16 weight 再量化出 FP8，训练中同时保留两者，常驻显存甚至高于纯 BF16。动机是 drop-in 替换与实现简单。 去掉 BF16、直接从 FP32 master weight 量化到 FP8（FP8 primary weights / 早期称 native FP8；MCore 参数名 --fp8-param-gather）才能把 weights/gradients/optimizer states 的常驻占用打平甚至略优。难点包括： FP8 对象需带 scale，且可能同时含 rowwise/colwise；TE 用继承 torch.Tensor 的 QuantizedTensor 与 Distributed Optimizer（ZeRO-1）兼容：master weight 被切到多个 DP rank 时，per-tensor 需 local amax → allreduce max → 量化 shard → FP8 AllGather 激活侧：各 recipe 通常只需存一份 colwise FP8 input，相对 BF16 可减半；MoE expert 激活因 top-k 膨胀，收益更明显。注意：SDPA 保存 BF16 output、projection 若再存 FP8 input，两者不再共享，可能变成约 1.5× 该处占用。开 TP（含 SP）时，要同时拿 FP8 AG 通信收益与 FP8 激活显存收益需额外处理。 作者举例：2048×80GB Hopper 训 DeepSeek-V3 时，FP8 能跑的并行配置下 BF16 会 OOM；BF16 若改并行则性能差很多。 通信：等价优先 原则：开/关 FP8 通信尽量数值等价；不做「量化→通信→反量化」换速度。 排除 CP/PP：attention 仍高精度；PP 通信量小且易 overlap，强行 FP8 常无损性与收益双输。 DP：在 primary weights 路径下，parameter AllGather 可 FP8，相对「BF16 AG 的 FP8 训练」无损。 TP AG：可先在 TP group 内 allreduce amax，再对 shard 量化并 FP8 AG，同时保留 colwise 供反向。 EP alltoall：DeepSeek-V3 / DeepEP 路径；前向「FP8 通信再 GEMM」与「BF16 通信再量化」可等价。反向常只传一份 rowwise，需昂贵的 dequant→另一方向 requant；Grace Blackwell 上作者因此未用 FP8 dispatch。且需 E8M0 / power-of-2 scale，使 double 与 single quantization 几乎等价。Activation 沿 token 1D 量化 才与按 token 发送吻合；per-tensor 或 activation 2D tile 几乎无法做等价 FP8 dispatch。 稳定主张 训练 FP8 的关键设计选择是：activation 沿 token 1D，weight 用 2D——利于通信与少存双份 weight。 Blockwise（DeepSeek-V3-like）是当下生产背书最多的 recipe；MXFP8 绑 Blackwell。 推理侧「模型存成 FP8」与训练侧「GEMM 输入 FP8 + master/BF16 权重策略」不要混为一谈。 训练侧 MXFP8（tile + E8M0）与推理侧 MXFP4（E2M1 + block-32）同属 microscaling 直觉，但场景与比特宽不同。 See Also 线性量化基础 PTQ 与 QAT MXFP4 推理量化 大模型量化问题地图"
  },

  {
    "title": "GPTQ 与 AWQ",
    "url": "/wiki/llm-quantization/gptq-awq/",
    "summary": "GPTQ 用 Hessian 做层内误差补偿，AWQ 保护高激活通道；两者都是面向 LLM 的校准式 INT4 权重量化，常见配方为 W4A16。",
    "lang": "zh-CN",
    "updated": "2026-08-11",
    "content": "Overview 朴素 Round-to-Nearest（RTN）把权重丢进最近的低比特桶，INT4 上常直接毁掉推理质量，因为权重重要性不均。LLM 实用 INT4 依赖更聪明的校准式 PTQ；两条主流哲学是 GPTQ 与 AWQ。 为什么不是随便 round 权重与激活相乘。若某权重连着持续尖峰激活，其舍入误差会被放大并跨层传播。RTN 对所有权重一视同仁，因此容易失败。 GPTQ：Hessian 补偿 GPTQ 逐层、按列量化，并问：量化某个权重引入误差后，如何调整同层剩余未量化权重来补偿？ 做法依赖对输出损失相对权重的 Hessian（曲率 / 敏感度）。校准前向得到层输入激活 $X$ 后，目标常写成最小化 $|XW - XW’|^2$，对应 $H = X^\\top X$。用途包括： 敏感度：对角元大的权重扰动更伤输出 误差补偿：用 $H^{-1}$ 估计量化掉某权重后其余权重应如何偏移 代价是压缩阶段需要更多显存来算 Hessian；收益是 INT4 下更稳。工具链上 AutoGPTQ 已归档，常见继任是 GPTQModel；vLLM 侧也可用 llm-compressor 的 GPTQ modifier。 AWQ：激活感知缩放 AWQ 观察：少数通道对应的激活幅度特别大，这些通道的量化误差会被放大。流程是： 用校准数据统计通道激活幅度 识别重要通道 量化前放大对应权重（提高有效精度），并相应缩小激活以保持数学等价 其余权重可更激进地量化 相对 GPTQ，AWQ 通常更轻、更快（InferLoop 称常约 2–3 倍量化速度），且在同等比特下常有更好精度保持。生产 INT4 GPU 推理里，AWQ 常被视为默认选项之一；AutoAWQ 归档后，官方推荐转向 llm-compressor 等统一工具。 W4A16 配方 llm-compressor 的常见 recipe： scheme=\"W4A16\"：权重 4-bit，激活保持 16-bit。激活随 prompt 变化且含 outlier，全量化（如 W8A8）更难；weight-only 用显存换质量。 targets=\"Linear\"：参数大头在线性层。 ignore=[\"lm_head\"]：词表投影对选词极敏感，掉精度易出乱码，通常留在 16-bit。 校准样本不必海量：文档示例用 256 条；过少统计不稳，过几百条后边际收益很小而耗时陡增。max_seq_length=4096 用来覆盖长上下文下的激活行为。InferLoop / GPTQModel 实践常用 128–1024 条，C4 一类通用语料；垂直场景可混入领域文本。group_size=128 是常见折中。 体积为什么不是严格 4× 理论 BF16→INT4 可缩约 75%。实测 Llama-3-8B 示例：BF16 15.30 GB → W4A16 5.45 GB，约减 64%。缺口来自未量化的 embedding、layer norm、lm_head。模型越大，线性层占比越高，压缩比越接近理论上限；小模型 vocab head 占比高时整体缩减更有限。 质量怎么验 生成对比只能看「像不像」。更硬的指标是 holdout perplexity。同一篇 blog 的滑动窗口结果：Base BF16 PPL 14.22，W4A16 14.85（+0.63，约 +4.4%），换约 64% 体积下降。InferLoop 在 Qwen2.5-7B-Instruct 上也给出类似量级：FP16 PPL 6.42，GPTQ INT4 6.58，AWQ INT4 6.51；MMLU 从 70.2% 掉到约 69.1–69.5%。 与其他格式的定位 方法 设备 角色 GPTQ GPU 优化式 INT4 PTQ AWQ GPU 激活感知 INT4 PTQ，服务端常用 GGUF CPU / 混合 llama.cpp 生态本地部署 FP8 Hopper+ 硬件原生，精度掉点通常更小 MXFP4 GPU（需专用 kernel） E2M1 + block-32 浮点权重路径；与校准式 INT4 不同 bitsandbytes GPU 即时量化，利于实验与 QLoRA，不如 AWQ kernel 利于生产吞吐 See Also PTQ 与 QAT 线性量化基础 MXFP4 推理量化 大模型量化问题地图"
  },

  {
    "title": "线性量化基础",
    "url": "/wiki/llm-quantization/linear-quantization/",
    "summary": "线性量化用 scale 与 zero-point 把浮点映射到低比特整数，粒度与对称性决定精度与算力折中。",
    "lang": "zh-CN",
    "updated": "2026-08-11",
    "content": "Overview 线性量化是后续 PTQ / QAT / GPTQ / AWQ 的共同底座：先选定浮点裁剪范围，再映射到目标整数网格，推理时按需要反量化或直接做整数算子。 映射公式 对浮点值 $x$，常用仿射量化： [q = \\mathrm{round}(x / S + Z),\\quad x \\approx S \\cdot (q - Z)] $S$（scale）：浮点范围与整数范围之比。 $Z$（zero-point）：浮点 0 对应的整数，保证零值可精确表示。 映射误差 $x - \\tilde{x}$ 即量化噪声。目标是用合适的方案、粒度与校准，把噪声对任务指标的影响压到可接受范围。 对称与非对称 方案 范围假设 参数 直观取舍 Symmetric 关于 0 对称，$Z=0$ 主要靠 $S$ 算子更简单；偏斜分布会浪费网格 Asymmetric / Affine 用真实 min–max 区间 $S$ 与 $Z$ 更贴分布；权重量化时算力开销更大 PyTorch 实践指出：非负激活更适合仿射；权重量化常偏好对称 per-channel，因为跨通道方差大时 per-tensor 表现差。 粒度 Per-tensor：整张量共用一组 $S,Z$，实现简单，分布不均时误差大。 Per-channel：每个输出通道一组参数，权重量化更常用。 Per-group / block：例如每 128 个权重一组，是 LLM INT4 的常见折中：比 per-tensor 细，比 per-channel 全量元数据更省。 训练期 FP8 把同一直觉推到 tile：DeepSeek-V3-like blockwise 常用 activation/gradient 的 1×128（沿 token 的 1D）与 weight 的 128×128（2D）；MXFP8 更细到 1×32 并共享 E8M0 scale。粒度不仅影响精度，还约束 TP/EP 通信能否做数值等价的 FP8 传输。详见 FP8 训练 Recipe。 推理侧 MXFP4 也是 block-32：元素为 E2M1（1 sign / 2 exp / 1 mantissa），每 32 元共享 scale 以恢复动态范围；matmul 必须感知该 scale，依赖专用 kernel。详见 MXFP4 推理量化。 InferLoop 给出经验数字：Qwen2.5-7B 约 72 亿参数时，FP16 参数约 14 GB，INT4（GPTQ）参数约 3.5 GB；实际推理显存还会加上 KV Cache 与激活。 INT4 packing 与 FP8 / MXFP4 INT4 只有 16 档。多数硬件不能原生存 4-bit，因此常把两个 INT4 pack 进一个 INT8 字节。即便没有原生 INT4 算力，带宽减半仍可加速 memory-bound 推理；但精度掉点通常大于 INT8，需要 GPTQ / AWQ 一类方法。 FP8 保留浮点结构（常见 E4M3 / E5M2），推理侧 A8W8 可同时压激活与权重；训练侧则是 TE/MCore recipe 把 linear GEMM 输入量化到 FP8（Hybrid 时 gradient 常用 E5M2）。高效执行依赖 Hopper/Blackwell 等硬件；无原生加速时收益有限。 MXFP4 则是 4-bit 浮点权重路径：用 E2M1 + block scale，而不是 INT4 整数网格；与校准式 GPTQ/AWQ 不是同一条流水线。 校准在基础层做什么 校准（calibration）是选定裁剪范围 $\\alpha$–$\\beta$ 并由此算 $S,Z$ 的过程。常见观察器包括 running min/max、滑动平均 min/max、直方图；也可用 KL / MSE / 分位数。不同 observer 给出的 qparams 不同，需要按任务实证。 See Also PTQ 与 QAT GPTQ 与 AWQ MXFP4 推理量化 FP8 训练 Recipe 大模型量化问题地图"
  },

  {
    "title": "MXFP4 推理量化",
    "url": "/wiki/llm-quantization/mxfp4/",
    "summary": "MXFP4 用 E2M1 四比特浮点加每 32 元一块的 block scale，让 gpt-oss 等模型以远低于 BF16 的显存跑推理，并依赖专用 Triton kernel。",
    "lang": "zh-CN",
    "updated": "2026-08-11",
    "content": "Overview MXFP4 是面向推理的 4-bit 浮点 + 块级缩放格式。相对 GPTQ/AWQ 的校准式 INT4，它更像「权重以 FP4 microscaling 原生交付」；相对训练侧 FP8/MXFP8 recipe，它解决的是能否把大模型塞进单卡并高效做带 scale 的 GEMM，不是预训练混合精度流水线。 本页证据主要来自 Hugging Face 对 gpt-oss 在 transformers 中的工程说明；精度掉点数字本源未给。 数值格式 MXFP4 元素布局为 E2M1：1 sign + 2 exponent + 1 mantissa。单独的 E2M1 档位很粗，靠 blockwise scaling 补动态范围： 向量按 32 个元素分块 每块存一个共享 scale，反量化时恢复量级 块内 4-bit 值相对该 scale 表示 因此 matmul / fusion 必须感知 block scale；没有专用 kernel 时，难以同时保住显存收益与可接受吞吐。 显存与模型实例 在 MXFP4 路径开启时，HF 给出的量级是： GPT-OSS 20B：大约 16 GB VRAM GPT-OSS 120B：大约 80 GB VRAM 不满足 MXFP4 运行条件时，transformers 默认落到更高精度路径（常用 bfloat16），显存大约是 MXFP4 的 约 4×。可用 Mxfp4Config(dequantize=True) 显式走反量化、吃满显存的对照路径。 transformers 路径 若配置里出现 'quant_method': 'mxfp4'，在支持的环境下会自动走 MXFP4 + Triton kernel。gpt-oss 示例里 modules_to_not_convert 包含： model.layers.*.self_attn model.layers.*.mlp.router model.embed_tokens lm_head 即 attention、router、embedding、lm head 保持更高精度；可量化主体主要是其余线性/专家权重。微调后也可直接以 MXFP4 格式存回 Hub。 运行依赖 安装 accelerate、kernels、triton>=3.4（PyTorch 2.8 已带 triton 3.4；2.7 需手动装） NVIDIA GPU compute capability ≥ 7.5 MXFP4 感知的 Triton kernel 由 Hub 上的 kernels-community/triton_kernels 等仓库自动拉取，不必再传 use_kernels=True。 与其它 Hub kernels 的冲突 Liger RMSNorm、MegaBlocks MoE 等需 use_kernels=True 的自定义 kernel 与 mxfp4 不兼容；启用后推理会落到 bfloat16。选路径时要在「MXFP4 省显存」与「其它自定义 MoE/RMSNorm kernel」之间自行 benchmark。 与相邻路线的边界 路线 典型形态 和 MXFP4 的差别 GPTQ / AWQ 校准式 INT4 权重量化（常 W4A16） 整数网格 + 校准/补偿；不是 E2M1 + block FP scale QLoRA / NF4 训练时冻结 4-bit 基座 目标是低显存微调，不是 MXFP4 推理交付格式 FP8 训练 TE/MCore 把 GEMM 输入打到 FP8 训练 recipe；MXFP8 的 1×32 scale 是同族「microscaling」直觉，但场景不同 稳定主张 MXFP4 的核心折中是：极低比特浮点 + 32-block scale，用元数据换动态范围。 工程上能否落地，取决于 感知 block scale 的 GEMM kernel，不只取决于权重文件是否 4-bit。 对 gpt-oss 一类模型，MXFP4 首先回答「单卡能不能装下」；吞吐还取决于 kernel 与是否误开不兼容的其它加速路径。 See Also 线性量化基础 GPTQ 与 AWQ FP8 训练 Recipe 大模型量化问题地图"
  },

  {
    "title": "大模型量化问题地图",
    "url": "/wiki/llm-quantization/overview/",
    "summary": "大模型量化的核心问题是如何在降精度省显存的同时控制量化噪声，以及何时用校准式 PTQ、何时回到 QAT 或 QLoRA 训练。",
    "lang": "zh-CN",
    "updated": "2026-08-11",
    "content": "Overview 大模型量化不是单一算法，而是一组互相耦合的选择：把哪些张量降到多少比特、用什么映射与粒度、误差在校准阶段还是训练阶段消化、以及最终服务场景是 GPU 推理、端侧部署、低显存微调，还是大规模预训练里的 FP8 混合精度。 本 topic 先回答六类问题：数值如何映射、PTQ 与 QAT 的流程边界、LLM 上主流 INT4 权重量化、后训练里的 QLoRA、训练期 FP8 recipe，以及推理侧 MXFP4 / microscaling FP4。 问题地图 精度怎么降下去 量化把浮点范围映射到更少的离散档位，引入 scale / zero-point，并在 per-tensor、per-channel、per-group 等粒度上折中精度与元数据开销。INT4 还常依赖 packing；FP8 则依赖新硬件；推理 MXFP4 则用 E2M1 + block-32 scale。详见 线性量化基础。 误差在什么时候消化 PTQ 在训完后用校准数据估参数或做层内补偿；QAT 在训练前向插入伪量化，用 STE 让模型适应量化噪声。生产推理多走 PTQ；低比特或精度敏感时才回到 QAT。详见 PTQ 与 QAT。 LLM INT4 为什么不只是四舍五入 朴素 RTN 在 INT4 上常崩。GPTQ 用 Hessian 做误差补偿；AWQ 保护高激活幅度通道。常见配方是 W4A16，并常跳过 lm_head。详见 GPTQ 与 AWQ。 后训练怎么和量化一起用 真正的 QAT 是 prepare → finetune → convert。更常见的低显存微调是 QLoRA：NF4 冻结基座 + 高精 LoRA adapter，不是经典 QAT。详见 LLM 上的 QAT 与 QLoRA。 大规模训练里的 FP8 怎么做 预训练 FP8 是 TE/MCore recipe：加速 linear 的三个 GEMM，并处理 Hopper/Blackwell layout、primary weights 与 TP/EP 通信。它与推理 FP8 PTQ 不是同一条流水线。详见 FP8 训练 Recipe。 推理侧 MXFP4 解决什么 当权重以 MXFP4（E2M1 + 每 32 元一块 scale）交付时，首要问题是单卡显存能否装下，以及 GEMM 是否有感知 block scale 的 kernel；它与校准式 INT4 PTQ、训练期 FP8/MXFP8 都不是同一条线。详见 MXFP4 推理量化。 共同主张 量化的主收益首先是显存与带宽，不一定等于算力加速；weight-only 场景尤其如此。 对多数 7B+ 服务端 INT4 推理，校准式 PTQ（尤其 AWQ / GPTQ）已够用。 QAT 在更低比特或端侧 8da4w 等设定上能显著回收精度，但训练成本更高。 QLoRA 解决的是「训练时塞得下基座」，与「导出可部署量化权重」不是同一条流水线。 FP8 训练的显存/通信收益取决于 recipe 与是否启用 FP8 primary weights，不能默认减半。 MXFP4 的落地取决于专用 kernel 与运行环境；不满足时可能 fallback 到约 4× 显存的 BF16 路径。 See Also 线性量化基础 PTQ 与 QAT GPTQ 与 AWQ LLM 上的 QAT QLoRA MXFP4 推理量化 FP8 训练 Recipe"
  },

  {
    "title": "PTQ 与 QAT",
    "url": "/wiki/llm-quantization/ptq-vs-qat/",
    "summary": "PTQ 在训后用校准或优化压精度；QAT 在训练中插入伪量化并用 STE 适应噪声，精度更高但成本更大。",
    "lang": "zh-CN",
    "updated": "2026-08-10",
    "content": "Overview 按误差消化时机，量化分成两条主路线：训练后量化（PTQ）与量化感知训练（QAT）。LLM 生产推理默认 PTQ；需要回收大幅精度损失时再上 QAT。 另有一条常被混谈的线：训练期 FP8 混合精度（TE/MCore recipe 加速 GEMM）。它既不是训后 INT4 PTQ，也不是经典 fake-quant QAT；见 FP8 训练 Recipe。 PTQ：训完再压 PTQ 在模型已训完后施加量化，通常不需要完整训练数据与反向传播。 动态 / weight-only 权重预先量化；激活在推理时按当前输入动态标定。实现简单，对 LSTM / Transformer 一类 memory-bound 模型友好；但层间反复 float↔int 转换有开销。 静态 PTQ 权重预先量化，激活范围用代表性数据预先校准并固定，推理时激活可保持量化精度。PyTorch 流程可概括为： fuse 可融合模块（如 Conv-BN-ReLU） 插入 Quant / DeQuant stub prepare：挂 observer calibrate：喂代表性数据（文档称约 100 个 mini-batch 量级常够用；随机数校准会得到坏 qparams） convert：换成真正量化模块 InferLoop 对 LLM PTQ 的操作版： 加载 FP16 模型 用校准集前向，收集权重 / 激活统计 计算 scale、zero-point（或更复杂的层内补偿） 写出低比特权重 保存并评测 优点：快、便宜。缺点：INT2 等极端位宽或小模型上掉点更大。 QAT：训练时假装已经被量化 QAT 在前向插入 fake quantization：先按低比特网格 round/clamp，再立刻反量化回浮点，从而把量化噪声写进 loss。权重仍以浮点存储与更新；反传通常用 Straight-Through Estimator（STE）穿过不可导的 round。 伪量化与真量化的差别可以写成： # PTQ / 真量化：cast 到低比特 x_q = (x / scale + zp).round().clamp(qmin, qmax).cast(int8) # QAT 伪量化：仍保持 float，只模拟数值 x_fq = (x / scale + zp).round().clamp(qmin, qmax) x_fq = (x_fq - zp) * scale 典型流程：插入伪量化 → 微调若干 epoch → convert 成与 PTQ 同结构的真实量化模型。 优点：尤其在低比特上精度通常优于纯 PTQ。缺点：需要训练数据与算力；开销可到数百 epoch（经典 DNN 文献语境），LLM 上则体现为更慢的 finetune。 怎么选 场景 更常见选择 7B+ 服务端 INT4 推理 PTQ（GPTQ / AWQ 等） 小模型、INT2/INT3、端侧精度敏感 考虑 QAT 只想低显存 SFT / 对齐 往往是 QLoRA，不是完整 QAT InferLoop 的实践判断：到 2025 年实践中 PTQ 仍是绝对主流；除非极端低比特或极高精度要求，否则先 PTQ。 See Also 线性量化基础 GPTQ 与 AWQ LLM 上的 QAT QLoRA FP8 训练 Recipe"
  },

  {
    "title": "LLM 上的 QAT",
    "url": "/wiki/llm-quantization/qat-for-llms/",
    "summary": "torchao / torchtune 的 LLM QAT 通过 prepare 插入伪量化、微调后再 convert，可在 8da4w 等设定上大幅回收相对 PTQ 的精度损失。",
    "lang": "zh-CN",
    "updated": "2026-08-10",
    "content": "Overview 面向 LLM 的 QAT 不是另起一套模型结构，而是在与目标 PTQ 相同的量化设定下，先用伪量化微调，再 convert 成可复用同一套 kernel 的量化模型。 prepare → train → convert torchao 流程两步： prepare：在 linear 层插入 fake quantize，前向模拟量化数值，但不做低比特 dtype cast。 convert：训练结束后把伪量化换成真实 quantize / dequantize，得到与对应 PTQ quantizer 同结构的模型。 实验中常用设定是 int8 per-token dynamic activations + int4 grouped per-channel weights（简称 8da4w），动机来自端侧 kernel 可用性与 LLM 量化研究中「per-token 激活 + per-group 权重」质量较好的经验。 与后训练的衔接方式 预训练全量数据往往不可及，因此实践是在 finetune 阶段做 QAT。PyTorch blog 在 C4（en）上对 Llama2-7B / Llama3-8B 跑 5000 steps：batch size 2，lr $2\\times10^{-5}$，Llama2 max seq 4096、Llama3 8192，FSDP + activation checkpointing；8da4w 权重 group size 256。 经验技巧：前 N 步关闭伪量化，让权重先稳定再引入量化噪声；实验统一用前 1000 steps 关闭。 能回收多少精度 相对同设定 PTQ： Llama3-8B 8da4w：hellaswag 归一化精度掉点可回收约 96%，相对未量化掉点可到 <1%；wikitext word / byte PPL 掉点分别回收约 68% / 65%。 Llama2-7B 8da4w：hellaswag 掉点回收约 62%；wikitext word / byte PPL 掉点约 58% / 57%。 落到 XNNPACK 后：QAT 相对 PTQ wikitext word perplexity 低 16.8%（23.316 → 19.403），模型体积同为 3.881 GB，端侧速度同量级。 低比特 weight-only 更残酷。Llama3-8B 2-bit 上纯 PTQ 的 wikitext word PPL 可爆到 603336；跳过最敏感的前 3 层与后 2 层后降到 6766；再叠加 QAT 可到约 30。跳过敏感层时，QAT 相对 PTQ 可回收 hellaswag 掉点约 53%，wikitext word / byte PPL 掉点约 99% / 89%。3-bit 上即便不跳层 QAT 也有效，跳层仍更好。 成本 伪量化遍布整网。Llama3-8B 约有 $(32 \\times 7) + 1 = 225$ 个 linear，每个至少有权重伪量化，还可能有激活伪量化。微基准：8da4w QAT finetune 约比普通 full finetune 慢 34%；开启 activation checkpointing 后每 GPU 显存约多 2.35 GB（中位峰值 67.501 → 69.850 GB；吞吐 546.314 → 359.637 tok/s）。 边界 QAT ≠ 真低比特训练；后者实际 cast 到低比特，既往成功多停在 8-bit，而 QAT 在更低比特仍有效。 当前 torchtune 集成以 full finetune 为主；与 LoRA / QLoRA 组合仍是展望项。 多数服务端 INT4 仍可先 PTQ；QAT 更适合端侧、低比特或 PTQ 掉点不可接受时。 See Also PTQ 与 QAT QLoRA GPTQ 与 AWQ"
  },

  {
    "title": "QLoRA",
    "url": "/wiki/llm-quantization/qlora/",
    "summary": "QLoRA 用 NF4 冻结基座、高精 LoRA adapter 与 Double Quantization / Paged Optimizer，把大模型微调塞进单卡，但不是经典 QAT。",
    "lang": "zh-CN",
    "updated": "2026-08-10",
    "content": "Overview QLoRA（Quantized LoRA）把基座存成 4-bit，只训练高精低秩 adapter。它回答的是「微调时如何塞得下」，不是「如何导出最优生产 INT4 权重」。 为什么需要混合精度 若整网用 4-bit 训练，极小梯度（如 $10^{-7}$ 量级）可能落在同一量化档，优化器失去有效更新。QLoRA 的折中： 基座权重：NF4 存储（省显存） LoRA adapter：16-bit 训练（保梯度） 量化常数：可用 Double Quantization 再压 优化器状态：Paged Optimizer 在显存尖峰时落到 CPU 目标能力表述：足以在单张 48GB GPU 上微调 70B 级模型；adapter 参数量通常不到全参的 1%。 NF4 NF4（4-bit NormalFloat）假设权重大致正态，把 $-1$ 到 $1$ 分成 16 个非均匀档，零点附近更密，尾部更疏。相对均匀 INT4，对集中在 0 附近的权重更省量化误差。 反量化可写为 $w = n(Q_1) \\times c_1$：$n(Q_1)$ 来自 LUT，$c_1$ 是 block 共享的 FP32 缩放。按每 block 32 个权重计，$c_1$ 均摊约 1 bit/param，叠加 4-bit 索引约 5 bit/param。 Block-wise 的意义：局部 outlier 不至于用一个全局 scale 毁掉整张量分辨率。 Double Quantization 把 $c_1$（FP32）再量化成 8-bit 的 $Q_2$，并引入第二级常数 $c_2$： [w = n(Q_1) \\times (Q_2 \\times c_2)] 从而再挤掉一级量化常数开销。 Paged Optimizer 训练中激活 / 优化器状态会造成 VRAM 尖峰。Paged Optimizer 把溢出页到 CPU RAM，避免 OOM，用带宽换稳定性。 与 PTQ / QAT 的关系 路线 基座 训练什么 典型产物 GPTQ / AWQ PTQ 校准后写死低比特 通常不再训 可部署量化权重 QAT 伪量化后 convert 全参或指定层 与 PTQ 同结构的更稳量化权重 QLoRA NF4 冻结 LoRA adapter adapter；推理可合并或保持 PEFT bitsandbytes 是 QLoRA 常见实现后端：load_in_4bit / NF4 即时量化利于实验与训练，但不像 AWQ 那样优先追求可分发的高速推理格式。 何时可以不用 显存充裕且追求最稳 adapter 质量时，BF16 LoRA 可能更简单。需要生产吞吐时，常在 BF16/FP8/AWQ 权重上部署，而不是直接把 QLoRA 训练时的 bnb 路径当最终 serving 格式。 See Also PTQ 与 QAT LLM 上的 QAT GPTQ 与 AWQ 大模型量化问题地图"
  },

  {
    "title": "On-Policy Distillation",
    "url": "/wiki/on-policy-distillation/overview/",
    "summary": "OPD 在学生自采样前缀上训练；teacher 信号支持集与 PG/GKD 梯度路径是两个正交轴，也可以按 teacher 熵混合两种路径。",
    "lang": "zh-CN",
    "updated": "2026-09-01",
    "content": "OPD 在优化什么 OPD 的轨迹来自学生当前策略 $\\pi_\\theta$。老师只在学生已经生成的前缀上给下一步的分布监督： [c_{t}=(x,y_{<t})] 和 SFT 的差别是数据从哪来：SFT 的序列是老师写的。和常见 outcome RL 的差别是监督有多密：那里整条轨迹只有一个对错标。 基本损失是 per-token reverse KL： [\\mathrm{KL}\\bigl(\\pi_\\theta \\Vert \\pi_{\\mathrm{teacher}}\\bigr) \\mathbb{E}{x\\sim\\pi\\theta} \\Bigl[ \\log\\pi_\\theta(x_{t+1}\\mid x_{1:t}) - \\log\\pi_{\\mathrm{teacher}}(x_{t+1}\\mid x_{1:t}) \\Bigr]] reverse KL reverse KL 是 mode-seeking：只在学生 rollout 里实际出现的前缀上，匹配老师下一步分布的众数。学生 support 里没有的 token 没有有效梯度，所以常见做法是先 SFT、再 OPD。折扣取 0，只看当前下一步。 PG-Style v.s. GKD-Style OPD 要用两个正交轴定位。第一个轴是每个学生前缀上 teacher 信号的支持集：只取 sampled token、取 top-k，或取 full-vocab。第二个轴是梯度路径：PG-Style 把 teacher 信号当作停止梯度的 advantage，经 sampled token 的 score function 更新；GKD-Style 把 rollout 当作固定 minibatch，直接对可微的局部分布距离反传。sampled-token / top-k / full-vocab 不等同于 PG / GKD。 PG-Style sampled-token 的逐 token advantage 是 [A_t=\\log\\pi_{\\mathrm{teacher}}(y_t\\mid c_t)-\\log\\pi_\\theta(y_t\\mid c_t).] 单个 $A_t$ 可以为正或为负：teacher 对 $y_t$ 的概率高于学生时为正，低于学生时为负。只有对 $y_t\\sim\\pi_\\theta(\\cdot\\mid c_t)$ 取期望，才有 [\\mathbb{E}[A_t] -\\mathrm{KL}\\bigl(\\pi_\\theta(\\cdot\\mid c_t)\\Vert \\pi_{\\mathrm{teacher}}(\\cdot\\mid c_t)\\bigr) \\le 0.] 因此「negative reverse KL」描述的是采样期望，不要求每个 token 的 advantage 都为负；advantage 本来就可以取正值或负值。 给定固定前缀、相同的局部 reverse KL，并令 $y_t$ 从学生分布采样时，PG sampled-token 是 direct distribution gradient 的 Monte Carlo score-function 估计。GKD 若在 top-k 或 full-vocab 上显式求和，会用更多 teacher 分布信息减少单 token 采样方差。两个轴仍然独立：PG 的 reward 可以使用更宽的支持集，GKD 也可以使用 sampled-token 的可微估计器。 PG-Style 只需要 teacher 对 sampled token 的 logprob，容易复用 PPO/GRPO 管线，也容易和 outcome reward 组合；代价是方差更高，通常更依赖 clip、baseline、mask 等稳定化。GKD-Style 更接近监督训练；现有材料支持它通常方差更小、训练更稳定，但不足以证明在同算力、同支持集、同 KL 方向下，最终 benchmark 必然更高。把 sampled-token PG 与 top-k 或 full-vocab GKD 直接比较时，性能差异同时包含梯度路径和 teacher 信号支持集的变化，不能全部归因于 loss 风格。 一种 PG-Style 实现会对同一 prompt 做组采样，但不启用组内 advantage normalization。它把 discount factor 设为 0，所以每个 token 只使用当前位置的信号，不是带完整 reward-to-go 的 sequence-level reverse-KL policy gradient。 RKL v.s. FKL KL 方向与监督支持集是两个正交轴。给定同一个学生前缀，reverse KL [\\mathrm{KL}(\\pi_\\theta\\Vert\\pi_{\\mathrm{teacher}})] 按 student 概率加权，主要惩罚 student 分配了概率、但 teacher 不认可的候选；它允许 student 只保留 teacher 的主要模式。forward KL [\\mathrm{KL}(\\pi_{\\mathrm{teacher}}\\Vert\\pi_\\theta)] 按 teacher 概率加权，主要惩罚 teacher 分配了概率、但 student 遗漏的候选；它要求 student 覆盖 teacher 支持的多个模式。 sampled-token RKL 从 $y_t\\sim\\pi_\\theta(\\cdot\\mid c_t)$ 取得单个 Monte Carlo 信号，成本低但方差高，而且没有采到的 teacher 合理候选不会在这一步得到监督。不存在直接对应的「student sampled-token FKL」：FKL 的期望按 teacher 概率加权，若只保留一个样本，需要从 teacher 采样；工程上更常见的是在 teacher top-k 或 full-vocab 上直接求和。top-k 与 full-vocab 都属于分布级监督，KL 方向可以相同；区别主要是 top-k 截断尾部并使用 $[B,T,K]$ 信号，而 full-vocab 保留整个词表并承担 $[B,T,V]$ 的存储与访存成本。 因此 EOPD 不是同一支持集上的纯 RKL / FKL 对照。它的 baseline 是 sampled-token clipped PG RKL，EOPD 在此基础上增加 entropy-gated teacher top-k direct FKL，同时改变了 KL 方向、支持集大小、梯度路径和 FKL 的位置选择。现有增益不能严格归因于 FKL 方向；干净比较还需要 teacher top-k direct RKL 对 teacher top-k direct FKL，以及 full-vocab direct RKL 对 full-vocab direct FKL 等控制。当前可靠结论只是：在 sampled-token PG RKL 上，对 teacher 高熵位置增加 top-k FKL，改善了该设定的多样性和 Pass@$k$。 FKL / RKL / JSD 的 logits 梯度 固定一个 student-generated prefix，记 teacher 分布为 $T$，student logits 为 $z$，$S=\\operatorname{softmax}(z)$。teacher 在以下推导中是固定监督信号，不参与求导。由 [\\frac{\\partial S_i}{\\partial z_j}=S_i(\\delta_{ij}-S_j)] 可得任意概率损失的通用换元。若 $g_i=\\partial L/\\partial S_i$，则 [\\frac{\\partial L}{\\partial z_j} S_j\\left(g_j-\\sum_i S_i g_i\\right).] 对 FKL，$L_{\\mathrm{FKL}}=\\mathrm{KL}(T\\Vert S)$，因此 [\\frac{\\partial L_{\\mathrm{FKL}}}{\\partial z_j}=S_j-T_j.] 当 teacher 对 token $j$ 分配非零概率、student 对它的概率接近零时，梯度仍趋近 $-T_j$。所以 FKL 能直接恢复 student 遗漏的 teacher 模式；在 student-generated prefix 上直接反传 soft-label FKL，可以理解为 on-policy soft-label SFT，也是 GKD-Style 的分布匹配。 对 RKL，$L_{\\mathrm{RKL}}=\\mathrm{KL}(S\\Vert T)$，其 logits 梯度是 [\\frac{\\partial L_{\\mathrm{RKL}}}{\\partial z_j} S_j\\left[ \\log\\frac{S_j}{T_j} - \\mathrm{KL}(S\\Vert T) \\right].] 当 $S_j\\to0$ 时，$S_j\\log S_j\\to0$，teacher-high / student-low token 的梯度也趋近零。这里不是 teacher 参数参与了求导，而是 student 概率既是 RKL 的加权分布，也是被优化对象。direct RKL 仍是 GKD-Style 分布损失，不等同于 RL；只有 sampled-token PG RKL 通过 student action、停止梯度的 advantage 和 importance ratio 更新时，优化路径才更接近 RL。 标准 JSD 令 $M=(T+S)/2$： [L_{\\mathrm{JSD}} \\frac{1}{2}\\mathrm{KL}(T\\Vert M) + \\frac{1}{2}\\mathrm{KL}(S\\Vert M).] 它对 student 概率的导数为 $\\frac{1}{2}\\log(S_i/M_i)$，所以 [\\frac{\\partial L_{\\mathrm{JSD}}}{\\partial z_j} \\frac{1}{2}S_j\\left[ \\log\\frac{S_j}{M_j} - \\mathrm{KL}(S\\Vert M) \\right].] JSD 同样在 $S_j\\to0$ 时给出趋零的 logits 梯度，因此不能像 FKL 一样强力恢复 student 遗漏的 teacher 模式。它的作用是损失有界，并且对支持集不匹配更温和，不是同时取得 FKL 和 RKL 的全部优点。 例如 $T=(0.5,0.5)$、$S=(0.99,0.01)$ 时，代入上式可见三种损失的两维 logits 梯度方向相同，但 FKL 的绝对值明显最大，RKL 小一个数量级，JSD 还要更小。这个例子说明的是梯度结构，不是经验结果。 loss coefficient 可以改变整体尺度，但不能改变低 student 概率模式的渐近梯度结构。若 teacher 与 student 已经接近，并且都在同一个 top-k 支持集内重归一化，三种损失的局部差异可能主要表现为尺度；此时支持集如何选择，以及采用 sampled-token PG 还是 direct backprop，可能比散度名称更重要。 K1 / K2 / K3 令 $y\\sim q=\\pi_\\theta$，$p$ 是 teacher 或 reference，$r=p(y)/q(y)$。目标 reverse KL 为 [\\mathrm{KL}(q\\Vert p)=\\mathbb{E}_{y\\sim q}[-\\log r].] K1、K2、K3 是 sampled-token 上三种不同的数值量： [K1=-\\log r,\\qquad K2=\\frac{1}{2}(\\log r)^2,\\qquad K3=r-1-\\log r.] K1 的数值期望严格等于目标 KL，但单样本可以为正或为负，方差通常较高，因而最自然地用于 PG-Style 的 sampled-token advantage。K2 始终非负且平滑，通常方差较低，但它对 KL 有偏；它只在 $p$ 与 $q$ 接近时是 KL 的局部二阶 surrogate，不是逐点近似 $-\\log r$。 K3 利用 $\\mathbb{E}_{q}[r-1]=0$ 作为 control variate，因此数值期望也严格等于目标 KL，并且逐样本非负。策略接近参考模型时，它通常比 K1 方差低；这不是普适保证，极端 probability ratio 仍可能造成高方差，计算 exp 时也可能需要 FP32 或 clamp。因为 $r=e^{\\log r}$，在 $\\log r\\approx0$ 时 Taylor 展开得到 $K3\\approx K2$，但两者不是同一个 estimator。原始 GRPO 的 KL 项是 K3，不是 K2。 这三种 estimator 早于 OPD。把 $p/q$ 换成 teacher/student ratio 只改变比较的模型，不构成新的估计理论；OPD 的实质差异仍是学生实时生成 prefix、teacher 在这些 prefix 上提供信号，以及信号通过 PG surrogate 还是 direct loss 回传。数值估计无偏也不等于优化梯度无偏：直接反传 estimator，或先 detach 再把它作为 PG reward，会形成不同的梯度估计器，不能仅凭 K1/K3 的数值无偏就无害互换。 拿到两组 sampled-token logprob 后，三者都只需对 $[B,T]$ 张量做逐元素运算：K1 是减法，K2 多一次平方，K3 多一次 exp 和加减；这些差异相对模型 forward/backward 可以忽略。主要成本来自额外的 teacher/reference forward，以及把信号从 sampled-token 的 $[B,T]$ 扩到 top-k 的 $[B,T,K]$ 或 full-vocab 的 $[B,T,V]$。K3 和 forward 用 K3、backward 用 K2 的 straight-through 变体会多一两个 $[B,T]$ 临时张量，但通常不是显存主项。 sampled-token v.s. GRPO 训练框架 sampled-token 本节比较的是 teacher 信号支持集及其框架成本，不是 PG/GKD 梯度路径。sampled-token 不是最早的 OPD 方案；在这种实现出现前，已经有工作用学生自生成轨迹做语言模型蒸馏。它更准确的定位是实现最简单、最接近现有 RL 训练管线的一档：每个位置只比较学生实际采到的那个 token 的 logprob。老师对这条轨迹做 compute_logprobs，取出已采 token 上的 teacher logprob，不需要词表上的完整分布。这是 reverse KL 的单样本估计，不是对两侧 logits 做 full-vocab 求和。 在已经具备学生 rollout、sampled-token student logprob、teacher sampled-token logprob、per-token advantage 和 importance-sampling 更新接口的 RL/GRPO 类框架里，训练骨架可以快速复用。老师提供的逐 token 信号是 [A_t=\\log\\pi_{\\mathrm{teacher}}(y_t\\mid c_t)-\\log\\pi_\\theta(y_t\\mid c_t)] 它是主监督，不是按组归一化的 sequence-level verifier advantage。已有实现明确展示的是：在带 KL 正则的 RL 脚本里把 regularizer 模型换成 teacher，再把 per-token advantage 设为负的 reverse KL，调用现成的 importance-sampling loss。这个结论不能直接扩成任意 GRPO trainer 都只需一两行修改；能否快速改出取决于上述逐 token 接口是否已经存在。 计算路径和原来的 KL 正则相同。角色不同：原来把学生约束在参考策略附近；这里这项是主监督，目标是 teacher。 top-k top-k 由谁选与 KL 方向是两个独立选择，但有一个自然起点： student top-k RKL 最符合原始 RKL：检查 student 当前主要概率质量是否得到 teacher 支持。 teacher top-k FKL 最符合原始 FKL：补齐 student 遗漏的 teacher 高概率候选。 teacher top-k RKL 已经不是 full-vocab RKL 的自然截断，而是一个局部 surrogate；它可以直接传递 teacher 认为重要的候选，而且 teacher server 通常天然返回 top-logprobs。 student top-k FKL 通常不理想，因为它可能完全看不到 teacher 有概率、student 已经遗漏的模式。 这不是硬规则。支持集由谁选择、师生是否在集合内重归一化，以及 top-k 外的概率质量如何处理，都是独立设计选择；它们会改变实际优化目标。 full-vocab 对整个词表做 KL。支持集变大，并不等于前面层反传变重。三者 backbone FLOPs 几乎一样。sampled-token 的 [\\partial\\log\\pi(y)/\\partial z] 和 full-vocab reverse KL 的 [\\partial\\mathrm{KL}/\\partial z] 都是 $V$ 维，再乘同一个 [W_{\\mathrm{lm}}] 前面层看到的上游梯度一直是 $[B,T,d]$。多出来的算术几乎只在最后一层附近对 $\\pi_T$ 做一次 $V$ 维计算，相对 LM head GEMM 约是 $1/d$。 真正增加的是显存和访存：要不要把完整 $V$ 维老师分布写到显存、按位置对齐后算 loss。可以不缓存完整 logits，只留 last-layer hidden，算 loss 时再乘 head。 sampled-token / top-k / full-vocab 训练上怎么选 没有统一配方。现有结论在「sampled-token 够不够」上不一致。 观点不一致。一种结论是：师生 top-k 高度重合、共享 token 已占绝大部分概率质量时，sampled-token 与 $k\\in{4,16,64}$ 的 top-k 下游接近；明显更差的是 Top-1，不是「只看一个按 $\\pi_\\theta$ 抽出的 token」。再加大 $k$ 收益很小。 另一种结论是：轨迹较长、前缀容易离开老师 support、tokenizer 或特殊 token 干扰单点比较时，sampled-token 监督偏斜、不稳定。改成 top-$K$ 截断 reverse KL，再加上 top-p rollout，梯度 norm 更低。其中不少增益来自 special-token mask，不完全是 estimator 本身。截断 reverse KL 是 surrogate，不等于 full-vocab。 可以先按设定选： 师生同族、学生轨迹已经在老师 support 里、top-k 重合高：默认 sampled-token。不要用 Top-1。 轨迹变长、agent、tokenizer 切分不一致或特殊 token 多：top-k 截断 KL + 集合内重归一化 + top-p rollout，必要时再 mask 特殊 token。$K$ 不用很大。 full-vocab：显存、通信和 kernel 都准备好、又在意方差时才值得。同一设定下三档还没有头对头比较。 EOPD 的熵门控混合 EOPD 把前述两个正交选择组合起来：外层始终使用 student rollout，并在固定学生前缀上同时使用 RKL 与 FKL。因此学生生成轨迹并不排斥在这些前缀上计算 FKL。 每个 token 都保留 sampled-token clipped RKL 的 PG-Style 项。只有 teacher 的 token-level entropy 满足 $H_T(c_t)>\\tau$ 时，才额外加入可直接反传的 teacher top-$k$ FKL： [\\mathcal{L}_t^{\\mathrm{EOPD}} \\mathcal{L}_t^{\\mathrm{OPD}} + \\mathbb{I}[H_T(c_t)>\\tau]\\mathcal{L}_t^{\\mathrm{FKL}}.] 因此低熵位置是纯 PG-Style；高熵位置是 PG-Style RKL 加 GKD-Style direct FKL。EOPD 整体是混合方法，不是纯 PG-Style。等价的批量实现可以先取得各位置的 teacher top-$k$，再把 $H_T(c_t)\\le\\tau$ 位置的 FKL mask 掉。 这里的 top-$k$ 明确来自 teacher。teacher 概率在这个集合内重归一化，student 则在同一批 teacher token IDs 上提供概率；该 FKL 公式没有再把 student 概率在集合内重归一化。主实验取 $k=16$。精确计算 teacher entropy 仍需要对 teacher full-vocab 分布做 reduction，但训练不必跨设备缓存或传输整个 $[B,T,V]$ 张量；只保留 top-$k$ 概率和 token IDs 时，额外存储约为 144 MiB。 门控依据是 teacher 在当前位置是否同时支持多个候选。低熵时，单个 student sampled token 提供的 RKL 信号更集中；高熵时，单点 RKL 的噪声更大，也容易只保留少数候选，额外 FKL 会同时提高 student 遗漏但 teacher 支持的候选，并降低 student 赋值过高的候选。它保护的是 teacher 表达的不确定性，不是原样保护 student 已有分布。 和 baseline 的差别也不是在同一支持集上做纯 FKL / RKL 对照：baseline 是 sampled-token clipped RKL PG，EOPD 是该项加 entropy-gated teacher top-$k$ direct FKL。收敛后约 15%–20% 的 token 触发 FKL。三组 Qwen3 主实验相对 baseline 的 Avg@8 提升分别为 $+1.16/+0.99/+1.80$，Pass@8 提升为 $+1.37/+2.39/+5.05$，收益更集中在多样性和 Pass@$k$。随机选择 20% 位置加入 FKL 更差；所有位置都加入 FKL 与熵门控大致相当，并非每个任务都落后于门控。 这些结果只来自一套数学任务与 Qwen 主设置，部分提升较小，主结果也缺少充分的多 seed 验证。它支持「在该设置中按 teacher 熵选择 direct FKL 位置有效」，不能推出 EOPD 在所有模型、任务或预算下都优于其他 OPD 配方。 Open Questions sampled-token 何时会不稳定：是师生 top-k overlap 起不来，还是 tokenizer / 特殊 token 把单点 KL 比较扭曲了。 同一设定下 full-vocab 是否稳定地优于 top-k。 Sources On-Policy Distillation 从OPD与反向KL的关系到OPD的两种形态以及路线之争 Revisiting On-Policy Distillation: Empirical Failure Modes and Simple Fixes Rethinking On-Policy Distillation of Large Language Models OPD深度解析：从数学推导到DeepSeek V4、SWIFT与verl实践 Entropy-Aware On-Policy Distillation of Language Models"
  },

  {
    "title": "通用智能测量",
    "url": "/wiki/test-time-training/measuring-general-intelligence/",
    "summary": "通用基准应控制先验与经验、测量 developer-aware generalization，并只假设人类 Core Knowledge；ARC 是这条契约的 2019 年测量物。",
    "lang": "zh-CN",
    "updated": "2026-08-17",
    "content": "Overview 技能获取效率 要变成可执行的反馈信号，基准必须让开发者无法用事先知道的任务、隐式先验或无限练习数据买分。Chollet 给出一组通用智能基准指南，并用 Abstraction and Reasoning Corpus（ARC）做第一次落地。原文：On the Measure of Intelligence。 Developer-aware generalization System-centric generalization 只问系统自己没见过的情境。把开发者算进系统之后，同一概念变成 developer-aware generalization：评价任务不能被测试系统或其开发者事先知道，否则测到的可能是工程师把解写进程序的智力。原文：Chollet 2019 I.3.2。 多任务榜若任务全部事先公开，仍不满足这条。CoinRun、Obstacle Tower 这类「新关卡」属于对已知分布的 local generalization，因为关卡生成器对开发者可见。 基准应控制的量 一篇通用基准至少应： 测量 broad abilities 与 developer-aware generalization，评价集不含事先已知任务 说明自己测的是 local、broad 还是 extreme generalization 控制训练时可获得的经验，避免用无限新数据买分 显式、穷尽地列出假设的先验 对人机公平：只假设人类具备的先验（例如 Core Knowledge），并只要求人类量级的练习时间或训练数据 原文：Chollet 2019 II.3。 Core Knowledge 先验 ARC 把先验钉在 Spelke 意义上的 Core Knowledge，并避免语言、真实物体图片和需练习才能获得的常识。四类是： Objectness： 按颜色连续或空间邻接解析物体，物体在噪声或遮挡下持续，接触可产生作用 Goal-directedness： 许多格子对可被理解为有意图过程的起止状态 Numbers and Counting： 计数、排序、比较数量；涉及的量大约小于 10 Basic Geometry and Topology： 线与矩形、对称、旋转平移、缩放、包含关系、投影与复制 原文：Chollet 2019 III.1.2。 ARC 作为测量物 ARC 同时被写成通用智能基准、程序合成基准和心理测量测验。训练集约 400 题，评价集约 600 题，其中公开评价 400、私有评价 200；训练与测试任务不相交。每题平均 3.3 个示范，测试例通常为 1 个。格子符号共 10 种，高宽在 1x1 与 30x30 之间。作答应从零构造输出格子；每道测试例允许 3 trials，反馈为对错；整题对全部测试例都对才算成功。分数是评价集上解出的任务比例。原文：Chollet 2019 III.1.1。 设计意图是：评价任务对开发者未知，经验被固定示范对卡住，先验被 Core Knowledge 穷尽。私有评价集用来在竞赛里强制 developer-aware generalization。人可以在无专门训练的情况下解其中多数题；2019 年的判断是，当时的机器学习（含 Deep Learning）无法有意义地逼近它。 本稿把 ARC 写成测量契约的证据，不建成系统页。网格规格、尝试次数和 400 / 600 划分会被后续竞赛协议改写。 已知弱点 Chollet 自己列出：泛化难度未量化、测验效度未建立、全集约 1,000 题且可能概念重叠、计分过于 0 / 1、交互不够、Core Knowledge 是否被正确捕捉仍开放。更贴近定义的格式会让应试者向例题生成器要新输入、提交假设并按所需反馈量计分。原文：Chollet 2019 III.2。 See Also 测试时训练问题地图 技能获取效率 测试时参数更新"
  },

  {
    "title": "测试时训练问题地图",
    "url": "/wiki/test-time-training/overview/",
    "summary": "本 topic 问的是：冻结后的任务技能为什么测不到智力，以及测试时改参数、加算力或做 ICL，各自对应技能获取效率的哪一段。",
    "lang": "zh-CN",
    "updated": "2026-08-17",
    "content": "Overview 冻结模型在已知任务上刷高分，测到的是已经结晶的技能，不是智力。Chollet 把智力写成 技能获取效率：在给定任务范围上，相对先验、经验和泛化难度，把信息转成新技能的速率。原文：On the Measure of Intelligence。 本 topic 的主骨架仍是这张测量地图。方法侧已经有一条可更新的机制：测试时用当前样本上的损失改权重。测试时加算力、ICL 与冻结后训练的对照仍等后续来源。 问题地图 测到的是技能还是获取效率 任务技能可以被无上限先验或无上限训练数据买到，同时掩盖系统自己的泛化力。公平比较要控制 scope、priors、experience、generalization difficulty。原文：Chollet 2019。 评价集对谁未知 只测系统没见过的样本，仍可能测到工程师写进程序里的智力。developer-aware generalization 要求任务对系统和开发者都未知。原文：Chollet 2019。 先验如何对人机公平 通用基准应显式穷尽先验，并只假设人类 Core Knowledge。ARC 是按这条契约做的测量物，不是又一个技能榜。原文：Chollet 2019。 测试时如何改权重 分布一旦在测试时才出现，冻结 $\\theta$ 就无法用当前 $x$ 里的提示。TTT 把无标签 $x$ 做成自监督问题，更新共享特征再预测。这解决的是已知任务上的分布偏移，不是评价集对开发者未知的新任务。原文：Sun et al. 2020。 共同主张 智力不是二进制属性，而是相对某个 scope 的谱：local / broad / extreme。原文：Chollet 2019。 技能是智力过程的结晶输出；要测的是把先验和经验转成新技能的效率。原文：Chollet 2019。 对人机公平的通用基准必须控制先验、经验，并测量 developer-aware generalization。原文：Chollet 2019。 测试时改 $\\theta$ 需要一个不依赖 $y$ 的损失；辅助任务与主任务的梯度需要正相关，否则更新会伤害主任务。原文：Sun et al. 2020。 开放接口 Chollet 已写出、但尚未展开的效率轴包括 skill program 的计算代价、训练时计算、时间、能量与风险。测试时加算力、ICL、熵最小式 TTA，以及把 TTT 接到有示范对的新任务上，留给后续来源。ARC 的竞赛协议与数据集修订同样留给 ARC Prize 报告。 边界 本 topic 不收录量化、不收录 On-Policy Distillation。冻结模型的外部资产演化属于 Harness Evolution：那边明确把直接改权重划出；这边问的是技能测量与后来会碰到的测试时适应。两边只做边界对照，不把同一篇来源倒进两个 topic。 See Also 技能获取效率 通用智能测量 测试时参数更新 Harness Evolution 概览"
  },

  {
    "title": "测试时参数更新",
    "url": "/wiki/test-time-training/parameter-update/",
    "summary": "TTT 把当前无标签测试样本做成自监督问题，先更新共享特征再预测；辅助任务与主任务的梯度需要正相关。",
    "lang": "zh-CN",
    "updated": "2026-08-17",
    "content": "Overview Sun 等人把 Test-Time Training（TTT）定义成：测试样本 $x$ 没有主任务标签 $y$，但仍给出关于测试分布的提示；让参数 $\\theta$ 依赖 $x$ 而不依赖 $y$。做法是把单张无标签图做成自监督问题，更新共享特征提取器，再用原来的主任务头预测。原文：Sun et al. 2020。 这条机制回答的是 local generalization 下的分布偏移，不是 ARC 那种对开发者未知的新任务。辅助损失的配方会变，但「用当前测试输入上的可计算损失改权重」会被后续来源反复更新。 决策边界可以依赖 $x$ 标准经验风险最小化在训练集 $P$ 上得到固定 $\\theta$。TTT 允许 $\\theta(x)$：先在 $x$ 上最小化辅助损失 $l_s(x)$，再在更新后的共享层上算主任务。网络做成 Y 形：共享底部 $\\theta_e$，主任务分支 $\\theta_m$，自监督分支 $\\theta_s$。训练时在 $P$ 上联合优化 $l_m+l_s$（joint training）；测试时只对 $\\theta_e$ 做辅助损失上的梯度步，$\\theta_m$ 保持训练结束时的值。原文：Sun et al. 2020 §2。 对照实验必须包含「训练时也用自监督、测试时冻住」的 joint training。Hendrycks 等人已表明训练时自监督能提高鲁棒性；TTT 的增量是测试时还要再走一步。 标准版与在线版 标准 TTT： 每张测试图从联合训练得到的 $\\theta$ 重新初始化，在该图的增强副本上走若干步，预测后丢掉 $\\theta_e^*$。 TTT-Online： 测试样本顺序到达且分布相同或平滑变化时，$x_t$ 的优化从 $\\theta(x_{t-1})$ 接着走，保留对已见测试分布的记忆。 本稿实验里的自监督任务是把图旋转 0 / 90 / 180 / 270 度并做四分类（Gidaris et al. 2018）。增强与训练时相同（随机裁剪与水平翻转），一个 batch 只含同一张图的增强副本。因此用 Group Normalization 而不是 Batch Normalization：单图小 batch 会让 BN 统计失真。原文：Sun et al. 2020 §2–3。 操作要点（只适用于这篇视觉设定，不是后续 LLM TTT 的默认超参）：测试时学习率取训练最后一轮的 0.001，weight decay 与 momentum 为 0；标准版每图 10 步，在线版每图 1 步。 何时会有帮助 凸模型上的充分条件是：主任务损失与自监督损失在共享特征上的梯度正相关。直观上，两个任务要在同一方向上犯错，决策边界也要相关。非凸的 ResNet 实验里，15 种腐蚀 × 5 个等级共 75 个测试集上，梯度内积与误差改进的线性相关系数为 0.93（标准版）和 0.89（在线版）。原文：Sun et al. 2020 §4。 辅助任务必须既良定义又非平凡。VID-Robust 里 airplane 几乎不涨：多数图两侧有黑边，旋转可被投机解掉；天空中的飞机人也难判断是否旋转。 证据（分布偏移，不是新任务） 相对「只做识别」和「joint training 但测试时冻住」： CIFAR-10 原测试集误差：识别 8.9%，joint training 8.1%，TTT 再降 0.2%。作者强调这与许多鲁棒方法用原分布性能换偏移鲁棒不同。 CIFAR-10-C level 5：标准版相对 joint training 总有改进；TTT-Online 常再改进超过 10%，三种噪声上超过 24%，pixelation 上 38%，且相对 joint training 的伤害不超过 0.2%。 即使无监督域适应方法 UDA-SS 能在训练时看到整个无标签测试集，TTT-Online 在 15 种腐蚀中的 13 种以及原分布上仍然更好。解释是 TTT-Online 只需适应当前测试分布，可以忘掉训练分布表征。 CIFAR-10.1（2000 张、对人几乎看不出差异的新测试集）：识别误差 17.4、joint training 16.7、TTT 15.9（表中单位为 %）。作者称这是当时第一个能把已有模型在该集上推高的方法；相对 joint training 的 0.8 个百分点相对原分布腰斩仍然很小。 原文：Sun et al. 2020 §3。 这些数字测的是已知任务、未知腐蚀或采集偏移，属于 Chollet 谱上的 local generalization。后续 ARC 式 TTT 会把同一「测试时改 $\\theta$」接到有示范对的监督损失上；Tent 会把损失换成熵、把可更新参数缩到 BN affine。那些对照等对应来源再写入。 See Also 测试时训练问题地图 技能获取效率 通用智能测量"
  },

  {
    "title": "技能获取效率",
    "url": "/wiki/test-time-training/skill-acquisition-efficiency/",
    "summary": "智力被定义为在给定任务范围上，相对先验、经验与泛化难度，把信息转成新技能的效率；任务技能本身可以被先验或数据买到。",
    "lang": "zh-CN",
    "updated": "2026-08-17",
    "content": "Overview Chollet 把历史上两种智力观拆开：结晶技能（在已知任务上达到目标）与获取新技能的能力。当代 AI 评价默认站在前一侧，用棋类、电子游戏等固定任务上的技能当智力。问题是技能高度受先验和经验调制。原文：On the Measure of Intelligence。 技能可以被买到 无上限先验（把解硬编码进程序）或无上限训练数据，都能在给定任务上抬高技能，而不增加系统处理未来不确定性的能力。两者都是在 prior/experience 平面上移动，与泛化轴正交。Deep Learning 在这篇里被放在 local-generalization 一端：概念上接近 locality-sensitive hashtable，要任意高技能就需要对输入–目标空间做稠密采样。原文：Chollet 2019 II.1。 因此，在开发者事先知道的任务上测技能，不能当作对 broad abilities 或 general intelligence 的测量。技能是智力过程的结晶输出，不是智力本身。 智力是技能获取效率 正式表述：一个系统的智力，是它在某组任务范围（scope）上的 skill-acquisition efficiency，并且必须相对 priors、experience 和 generalization difficulty 来读。示意贡献是 Expectation[skill · generalization / (priors + experience)] 再按任务价值加权、对 scope 取平均。白话版：智力是学习者把它的经验和先验，转成有价值、涉及不确定性与适应的新技能的速率。原文：Chollet 2019 II.2。 这一定义要求学习与适应。系统若一开始就能在评价情境上表现很好，则该任务的 developer-aware generalization difficulty 很低，智力分数也会低。 必须控制的四个量 Scope： 智力相对任务范围；两个系统只有在共享 scope、且先验可比时才能比。 Priors： 初始系统里与解相关的信息比例，不是系统体积。无关知识只付索引与检索开销。 Experience： 课程中相关且对系统而言新颖的信息；不惩罚噪声课程，也不把已经吸收后的重复步骤算进快学习者。 Generalization difficulty： 训练时最短最优解，要改多少才能成为评价时的充分解。最简单的训练时策略若已够用，则任务没有需要适应的不确定性。 人类既不是进化写死的专用程序集合，也不是空白石板。先天先验不是泛化的限制，而是其来源：No Free Lunch 要求从数据学习必须做假设。对人机公平比较，应把人类 Core Knowledge 当作参照先验。原文：Chollet 2019 II.1.3。 尚未展开的效率轴 II.2.2 还列出 skill program 的计算效率，以及训练时计算、时间、能量、风险。这些量是后续「测试时多算」与「测试时改参」的接口，本页不把它们写成已有方法比较。 See Also 测试时训练问题地图 通用智能测量 测试时参数更新"
  }

]