AI 产品工程笔记：13 场实战分享浓缩成 20 分钟（中文导读）

一、这份笔记的总主张：改进有先后顺序

Hamel 在开篇给出了一张「改进顺序地图」：最低垂的果实是优化检索与上下文；然后改进系统与 harness；把 post-training（微调自己的模型）留到最后，等其他手段都用完再考虑。这个顺序和藏书 a16「这很难评测是产品坏味道」、a19「评的是模型+Harness 的协作」一脉相承：大多数时候分数低不是模型不行，是供给它的上下文、工具与评测环境不行。

二、Evals 线：四篇新机制

1. 错误分析可以半自动化（Shreya Shankar）

最常见的错误是没看任何数据就先写 Rubric。错误分析是 evals 中最耗人力的环节（要逐条读 trace、标注），Shreya 开源的 Error Discovery skill 把这个过程半自动化：人在本地评审 app 里标注，AI agent 同步更新「失败模式分类法」，并用主动学习（active learning）根据你已标注的内容挑选下一条最该看的样本。失败模式分类法从人工评审中「长」出来，而不是让 LLM 凭空编一个。

2. 模型级联：分类任务成本砍掉一大半（Shreya Shankar）

很多 LLM 工作负载本质是分类任务，全扔给最大模型太贵。BARGAIN 方法：用约 500 条大模型标注的样本，逐个测试小模型置信度阈值，选出「仍能达到目标准确率的最便宜阈值」，把小模型自信的样本路由给小模型、没把握的升级给大模型。注意：这里的目标准确率是与大模型答案的一致率，不是与人工标签的一致率——级联的目的是「模仿大模型」，不是「超越它」。论文报告在 8 个数据集上比同类方法多降最多 86% 成本；后续 Task Cascades 论文（改写为简单替代问题、只读相关段落、搜索最优级联序列）再平均降 48.5%。

3. Evals 上线案例：两个真实踩坑（Lucas / Nova Escola）

巴西教育非营利平台（约 100 万月活、20 万教师）的教案助手案例，两个教训值得背下来：

• 先做错误分析再写 Rubric：他先写了 Rubric，结果大多数标准从未在真实失败中出现过，团队白标了一大批数据；
• 不是所有失败模式都值得建 eval：助手偶尔输出两个学习目标而非一个——改一行 prompt 就解决了，为这种问题建评估器是浪费。

另一个警钟：两名标注员的一致率低于随机水平——说明「什么叫好」根本没定义清楚，团队拉着教学专家重写 Rubric 后重新标注。上线后他每天对 2% 生产流量跑 eval 套件抓回归。

4. 先把 eval 修对，再谈微调（Prime Intellect）

微调应该是提升 eval 分数的最后手段。动手前先按顺序检查：① 读 trace 搞清到底什么在失败；② 修 eval 和环境本身；③ 改进检索、上下文与 harness。第②条有震撼实例：Terminal-Bench 2 上光把任务超时×5，分数就从 46.3% 涨到 60.97%——你以为在测模型，其实在测你的评测环境。其他高频坑：强迫 temperature=0（模型按 1 训练时会影响可复现性）、max token 截断推理、沙箱 CPU/内存不足、臃肿 harness、缺任务专属技能。post-training 只在两个条件同时成立时才考虑：答案能被自动验证，且当前分数在 0 到 100 之间（有上升空间）。

三、Context / Systems 线里和评测相关的

• Evals For Data Agents：一个还原真实混乱数仓环境的 data-agent benchmark，思路可平移到自有数据 Agent 的评测；
• How to Improve Search Agents：搜索 Agent 的 eval 策略与效率分析工具（哪些轮次在空转）；
• The case for agent sandboxes：为什么该给 Agent 配沙箱、怎么为开发效率设计——与第 4 篇的「环境坑」互为表里。

四、与你收藏其他文章的关系

五、适合谁 · 怎么用

适合已经读完精读主线、想把 evals 从「会做」推进到「做得省、做得快」的读者。建议用法：先读本导读确定哪篇对症，再点进对应子笔记看细节（每篇 5 分钟以内）；「错误分析自动化」和「先修 eval 再谈微调」两篇优先级最高。无硬先修；若先读过 en01（错误分析总纲）与 a16，会更清楚这些新机制补的是哪块拼图。

以下为原文全文 · 中文翻译

上方为本站原创导读，下方为 Hamel 原文索引页的完整中文翻译（宝玉翻译管线，normal 模式）。原文本身是 13 篇子笔记的索引；13 篇子笔记的中文全文翻译续接在目录之后。

AI 产品工程笔记

来自 13 场关于评测（evals）、上下文（context）与系统（systems）分享的笔记。—— Hamel Husain

过去三年，我的工作一直围绕评测展开。评测是改进 AI 产品的地基，但地基之外还有很多旋钮可以调，每个旋钮的取舍各不相同。

最低垂的果实是优化检索与上下文。这一步做完之后，再改进你的系统与 harness。最后，等其他手段都用尽之后，才考虑 post-training（后训练）自己的模型。

我主持了一个「AI 产品工程」系列来探讨这些议题。我把全部 13 场分享按主题整理成了笔记，并附上了原始材料的链接。提醒一句：我尽量提炼了每场分享的精华，所以有些笔记很短（9.5 小时的分享，压成了大约 20 分钟的阅读量）。

笔记目录

这些笔记里几乎每一项改进都始于好的评测。如果你想和一群人一起动手把评测做出来，AI Evals 课程有上手练习和答疑时间。

13 篇子笔记 · 中文全文翻译

按目录顺序排列；目录表中的标题均可点击直达对应译文。演讲视频与配套链接保留在译文内。

数据 Agent 的评测（Evals for Data Agents）

Shreya Shankar 的分享 · 2026-07-15 · 英文原文

在真实任务上检验数据分析 Agent。

数据 Agent 回答的是「哪个用户群的流失率最高？」这类本该由数据分析师回答的业务问题。尽管这类问题占据了知识工作的很大一块，针对它们的好基准却很稀缺。

Shreya Shankar 的分享介绍了 Data Agent Benchmark（DAB）。作者们还原了真实数仓的混乱：每个任务的数据分散在至少两个数据库系统中，join 键不一致、键值埋在自由文本里、schema 含糊甚至定义不清。（原文此处有 DAB 与相关基准在四项属性上的对比表，见英文原文。）

这个通用基准回答的问题与产品评测不同，但如果你在做数据 Agent，它的失败分析很有用。

出人意料的是，数据 Agent 失败最多的地方不是选错数据，而是计划与实现本身就错了。研究发现，Agent 常常先写一个计划，然后即使数据已经推翻了计划，也照旧执行。调试自己的数据 Agent 时，这些失败模式值得记在心里。

该基准是开放的，排行榜接受提交。团队会随着新模型发布持续刷新，值得长期关注。

↑ 返回笔记目录

用模型级联削减分类成本（Cut Classification Costs With a Model Cascade）

Shreya Shankar 的分享 · 2026-07-30 · 英文原文

用经过测算的模型级联砍成本，同时不牺牲目标准确率。

很多 LLM 工作负载本质是分类任务——这个问题比生成式 AI 老得多。LLM 太好用了，以至于人们动不动就把最大的模型怼上去。但分类一旦上了规模，成本就很可观。

Shreya 的最后一场分享讲的是 BARGAIN：一种把分类工作转移给小模型、同时满足你自选目标准确率的方法。它用小模型给每个标签输出的概率来为每条记录做路由。你先抽约 500 条记录，用大模型标注；然后把每个出现过的置信度都当作候选路由阈值逐一测试，选出「仍能达到目标准确率的最便宜阈值」。同一份样本还能告诉你：小模型的 logits 与大模型标签的相关性是否强到足以支撑这个玩法。

重要提醒：这里的目标准确率衡量的是与大模型答案的一致率，不是与人工标签的一致率——这项技术是「模仿大模型」，而「与人工标签对齐」是另一件事。

BARGAIN 论文报告：在 8 个数据集上，比同类方法多降最多 86% 的成本。

后续论文 Task Cascades 加了更多优化，比如：

• 把 prompt 改写成便宜模型也能回答的更简单的替代问题；
• 只读每篇文档中最相关的片段，而不是全文；
• 在候选级联方案中搜索，找到满足目标准确率的最便宜序列。

这些优化在 BARGAIN 式级联之上再平均降本 48.5%。完整演讲视频在这里。

↑ 返回笔记目录

自动化错误分析（Automating Error Analysis）

Shreya Shankar 的分享 · 2026-06-24 · 英文原文

从人工评审中长出错误分类法，而不是让 LLM 凭空编一个。

在做任何评测之前，先对日志做数据分析、搞清楚到底有哪些错误在发生，这很重要。一个常见错误是：还没看任何数据，就先把 Rubric 写好了。

这个过程叫错误分析（error analysis）。它是评测中最耗人力的环节，因为你得逐条读 trace 并标注。

Error Discovery skill 消除了其中大量摩擦：你标注的同时，它同步更新失败模式分类法，并为每个新模式检查此前的记录；它用主动学习（active learning），根据你已标注的内容挑选下一条最该看的样本。

工作流是这样的（原文此处有流程图）：人工评审者在本地评审 app 里标注，AI agent 在一旁更新失败模式分类法并挑选下一批样本。

演讲视频是这个 skill 的完整上手演示。

↑ 返回笔记目录

案例：把评测搬进生产环境（Case Study: Putting Evals Into Production）

Lucas Machado Rocha 的分享 · 2026-07-09 · 英文原文

Lucas 用评测优化了 Nova Escola 的教案规划助手——Nova Escola 是巴西一家非营利教育平台，月活约 100 万、覆盖 20 万教师。他的分享覆盖了完整流程。他的团队犯过两个错误：

1. 先写 Rubric，后做错误分析。由于大多数标准从未在真实失败中出现过，团队花了很多时间标注根本用不上的数据。
2. 为一个「简单修复就能解决」的问题建了评测。助手有时该输出一个学习目标却输出两个——团队改了 prompt，问题就消失了。（「什么时候才值得为失败模式建自动评估器」这个权衡，Hamel 的 FAQ 里有专门讨论。）

标注过程还暴露了另一个问题：Lucas 用了两名标注员，结果两人一致率低于随机水平。团队这才意识到「什么叫好」定义得不够清楚，于是拉上教学专家重写 Rubric、重新标注。（原文此处有 Lucas 的评测电子表格截图。）

通过错误分析锁定失败模式后，Lucas 用 eval skills 把后续工作的一部分自动化了，包括编写裁判（judge）并用人工标签验证它们。

他的端到端示例视频展示了整个流程。他每天对 2% 的生产流量跑一整套评测，以此尽早抓住回归。

↑ 返回笔记目录

多向量检索入门（An Intro to Multivector Retrieval）

Marek Galovic 的分享 · 2026-07-09 · 英文原文

保住 token 级检索质量，同时让存储和延迟变得实用。

大多数检索系统把每篇文档压缩成单个向量，这会成为信息瓶颈。多向量检索避开这个瓶颈（但有代价）：查询和文档都按每个 token 存一个向量。查询的每个 token 与文档中最佳匹配的 token 配对，把这些 token 级分数求和，得到文档分数。这个打分算子叫 MaxSim。（Hamel 关于 late interaction 的笔记解释了为什么这条路值得一试。原文此处有 Marek 的直觉示意图：每个格子比较一个查询 token 和一个文档 token，阴影格是 MaxSim 求和的最佳匹配。）

但有个取舍：查询和文档的每个 token 都要存向量、做比较，计算和存储成本涨得很快。Marek 估算，MaxSim 的算术量约为单个点积的 2,000 倍，存储是 10 到 100 倍——这也是它长期只待在论文里的原因。

Marek 讨论了一组把成本降到可规模化的优化。最主要的是 SMVE：把每个 token 投影到一大组随机方向上，只保留最大的 8 个值；按文档求和后得到一个高度稀疏的向量，进入倒排索引。与查询没有共同条目的文档根本不打分，精确 MaxSim 只对幸存者运行。Marek 报告：在 10 亿篇文档规模下，p99 延迟低于 100 毫秒。

他的团队还发布了 Iso-ModernColBERT——GTE-ModernColBERT-v1 的修正版，其 embedding 几何特性与 SMVE 的随机投影兼容；在 bf16 精度下还快约 3 倍，排序质量几乎无损。

完整演讲视频在这里。

↑ 返回笔记目录

如何改进搜索 Agent（How to Improve Search Agents）

Nandan Thakur 的分享 · 2026-07-13 · 英文原文

既衡量答案质量，也衡量 Agent 搜索的效率。

Nandan Thakur 的分享讲了三个项目，做搜索 Agent 的话都用得上。

第一个是 ORBIT：一条合成数据流水线，可以为检索评测冷启动数据。传统合成数据方法直接从文档朴素地生成问题，生成的问题单次搜索就能答对。ORBIT 反过来了：它描述一个实体的属性但不点名，并校验每个问题是否难到需要多次搜索跳转才能答对。

ORBIT 还会验证每个问题：要求搜索 Agent 对照源文档确认每个论断；另有一个独立裁判仅凭这些文档复现答案。整条路线完全合成，因此对没有标注数据的人很有吸引力。ORBIT 流水线生成了 20,000 个经过验证的问题，没花一分钱在搜索 API 或付费 LLM 上——这个配方可以在你自己的语料上复用。

第二个是 Hawkeye：一个理解 Agent 轨迹的可视化分析界面（在审，暂无公开产物）。它把每次运行如何展开呈现出来，帮你抓搜索 Agent 的错误。他们的分析发现：成功的运行所需的搜索轮次远少于未解决的运行（原文此处有搜索轮次分布图）。这样的视图能帮你为自己的 Agent 找到合适的最大搜索轮次阈值。让你最喜欢的 coding agent 给你搭一个类似的，是个不错的主意。

他还介绍了 BrowseComp-Plus——OpenAI BrowseComp 的可复现版本。BrowseComp 是一个高难度事实查找基准：答案短、好校验，但要经过很多次搜索才能找到。这项工作的一个重要发现是：限制准确率的是检索器，而不是模型。把包含答案的文档直接给模型，它几乎能答对每一题。GPT-4.1 自己用 BM25 找文档时只得 14.6%，直接把文档递给它则是 93.5%。

↑ 返回笔记目录

如何选择并微调 embedding 模型（Choose and Fine-Tune an Embedding Model）

Radu Gheorghe 的分享 · 2026-07-29 · 英文原文

在你自己的数据上做基准、压缩和微调 embedding 模型。

Radu Gheorghe 讲了如何为检索挑选 embedding 模型。他从 MTEB 排行榜讲起，然后提醒：排行榜排的是质量，几乎不反映成本。他随后梳理了几个值得考虑的取舍，重要的有：

• 模型量化（权重精度）：CPU 上 INT8 模型比 FP32 快约 3 倍，同时保住大部分质量；GPU 上则用 FP16。
• 向量精度（输出向量怎么存）：FP32 转 binary 可省 32 倍存储；bfloat16 省一半且无可感知的质量损失。
• Matryoshka 模型（可截断的嵌入模型）：允许丢掉后面的维度而保住大部分质量，既省存储又加速搜索。
• 在你数据上的表现（排行榜看不到的）：一定要在自己的数据上测，因为在专业领域排名会重洗。常见差距在多语言支持和上下文长度。

当模型在你的领域还是不够用时，一个被忽视的优化是微调它。微调 embedder 比微调 LLM 容易得多，影响常常更大。Hamel 最喜欢的部分是 VespaEmbed——Radu 的开源微调工具：Apache 2.0 协议、零代码，从 Hugging Face 选基座模型、上传数据对、选损失函数、点训练，完事（原文此处有 VespaEmbed 新建任务的设置界面截图）。可以在这里直接试。

完整演讲视频，幻灯片。

↑ 返回笔记目录

如何选择 OCR 模型（How to Choose an OCR Model）

Joe Barrow 的分享 · 2026-07-10 · 英文原文

在有代表性的文档上比较 OCR 系统，观察它们怎么失败。

Joe Barrow 讲了如何挑选 OCR 模型。他给出一张双轴决策矩阵（原文有图）：你需要纯文本块还是完整文档结构；你要托管 API 还是自托管模型。

• AWS Textract、Google Cloud Vision 这类大厂云服务便宜，带词级边界框，每 1,000 页 0.60–1.50 美元；
• Reducto、Datalab、Extend 这类文档创业公司贵但功能全，每 1,000 页 5–20 美元；
• Tesseract、PaddleOCR 这类开源流水线便宜快，但能力面窄；
• LightOnOCR、Chandra、Docling 这类开源 VLM 需要 GPU，功能大致齐全。

Joe 的建议：只有约 5% 的团队应该自托管。以产品为导向的话，用 API 往往更划算。

即使用了 API，选哪个模型依然重要，因为 PDF 会以意想不到的方式干碎提取器。Joe 点名的几个：

• TeX 编译的 PDF 不含空格字符。TeX 按坐标放置字形，朴素的提取器会返回一长串零空格的字母。
• 双栏页面不携带阅读顺序。行级提取器会横着跨栏读，把打乱的文本喂给你的 LLM。Textract 这类云服务也会犯。
• 行级输出丢失语义结构。标题、表格、单元格边界全没了，下游检索因此丢掉上下文。
• 烂扫描件会让云 API 编造文本。有人观察到 Textract 在一张噪声扫描件上返回了一百次「the」。
• 空白页会让 VLM 幻觉出模板文本。一张空页可能返回一段页眉文字。
• VLM 的 markdown 输出没有词级边界框。如果你的产品需要在原 PDF 里高亮来源短语，光靠 VLM 输出可能不够。
• 模型许可证有隐藏的连环条款。Chandra 和 Surya 只对年收入 200 万美元以下且不与 Datalab 竞争的组织免费；GLM-OCR 是 MIT 协议，但依赖 Apache 协议的 Paddle 版面模型——两个许可证你都得继承。

想看看 PDF 能烂到什么程度，WTF PDF 是一个「能干碎大多数提取器」的文件画廊。

Joe 的流程很短：确定你的两个轴，抽 50–100 页有代表性的页面，让所有候选跑同一批页面，然后检查原始输出、比较失败模式，再做决定。

演讲视频；他的开放 OCR 模型研究也值得一读。

↑ 返回笔记目录

用「给 Agent 的脚注」引导 AI 写作（Steer AI Writing With Footnotes for Agents）

Bryan Bischof 与 Adam Conway 的分享 · 2026-07-23 · 英文原文

把上下文贴在它所解释的确切句子上，保住人的意图。

Bryan Bischof 和 Adam Conway 是 Theory Ventures 的 AI 工程师。这家投资机构的投资人会写详细的投资备忘录，每份备忘录都包含重要决策。当 Agent 改写这些文字时，这些决策有丢失的风险。

Subtext 是他们的解法：一种轻量格式，给每个句子附着元数据。句子文本原封不动，作者的澄清与待决问题存为元数据。它相当于「给 Agent 看的脚注」，让 Agent 不偏离原始材料。

人也能受益。Adam 的 demo 展示了一个原型聊天界面：每条消息旁边都浮现发送者关联的工单和通话 transcript（完整记录），读者不必自己去翻找上下文。

演讲视频；幻灯片和源码仓库都是公开的。

↑ 返回笔记目录

找到推理延迟藏在哪里（Find Where Inference Latency Lives）

Abi Aryan 的分享 · 2026-07-02 · 英文原文

先把 prefill 和 decode 分开，再优化——免得优化错了瓶颈。

Abi Aryan 的分享拆解了推理的两个阶段：prefill（读入输入）与 decode（逐个生成输出 token）。她的 Colab notebook 在同一个模型上跑三种请求形态，并排打印耗时。

decode 是顺序的：模型一次吐一个 token。prefill 并行处理整个输入，因此单 token 快一个数量级。三种常见推理形态：

• 长输入、短输出（RAG、分类、抽取）：最友好的形态。prefill 占大头，而 prefill 并行度高。
• 短输入、长输出（Agent 轨迹、代码生成、长文写作）：最差的形态，因为延迟由 decode 驱动。
• 短输入、短输出（对话轮次、单轮查询）：decode 仍占大头，而 prefill 喂不饱 GPU——25 个 token 太少，无法让它饱和。vLLM 这类推理引擎用连续批处理（continuous batching）把许多小请求打包进同一次前向传播。

Abi 的建议：如果输出占大头，先砍响应长度；然后考虑投机解码（speculative decoding）、更小的模型或更好的硬件。如果 prefill 占大头，就做请求批处理并缩短上下文。

这个 notebook 就是为折腾准备的。值得试的实验：

• batch size：用 batch 4 和 8 跑同样的形态，看单请求吞吐怎么提升、内存在哪里封顶；
• 推理引擎：把 Hugging Face pipeline 换成 llama.cpp 或 vLLM——这对 decode 速度影响最大；
• 量化：换成 int8 或 int4 模型，看权重内存缩下去、吞吐通常涨上来。

演讲视频，notebook 在这里。

↑ 返回笔记目录

开放权重模型怎么用（How to Use Open Models）

Zach Mueller 的分享 · 2026-07-24 · 英文原文

哪些开放模型擅长什么，以及它们所需硬件的显存账。

Zach 盘点了开放模型家族，并分享了日常使用的心得：

• Qwen：27B dense 模型是他日常 Agent 的首选——指个人助理类任务（查邮件、查网站、调 API），而非写代码。他自己拿它跑了几个月的后台 Agent。
• GLM 5.2：几乎是他的编程日常主力，一头不分心、不犯小错的劳模。
• DeepSeek V4 Flash：Claude Haiku 的直接替代品。
• Kimi：写作最爱，但全精度部署要一台 8×B200 节点，自己跑不现实。

选模型之前，先估算它装不装得下你的硬件：权重(GB) = 参数量(B) × N × 0.5，其中 4-bit 时 N=1、8-bit 时 N=2、16-bit 时 N=4、32-bit 时 N=8。精确记账见 EleutherAI 的 transformer math 文章。

举例：27B 模型 4-bit 约需 13.5 GB，给激活值和 KV cache 留出余量后，一张 16 GB 卡装得下。

Zach 提醒：不要把私有代码发给 OpenRouter 这类第三方路由，因为请求可能落到数据隐私参差不齐的主机商那里。还要警惕在会话中途切换供应商的模型路由——缓存可能因此失效。如果用路由，用评测去实测它对延迟和成本的影响，而不是靠猜。

租 GPU 方面，Zach 更倾向单台顶级节点，而不是多节点 H100 集群：H100 只便宜 10–20%，多节点部署还会引入互联瓶颈。

↑ 返回笔记目录

别急着造 Agent，先造环境（Don't Build Agents, Build Environments）

Adam Azzam 的分享 · 2026-07-30 · 英文原文

给每个 Agent 一台快速、隔离的机器，而不是共用你的笔记本。

如果你在本地跑 coding agent，沙箱的必要性可能还不明显。当你的编码速度提上来、并行跑很多 Agent、或开始与他人协作时，它就变得重要了。沙箱隔离每个 Agent 运行的代码，出事时把爆炸半径控制在小范围。

CI/CD（很多人第一个想到的工具）并不合适：启动慢、生命周期短，而 Agent 可能为一个任务工作几小时甚至几天，还会改动自己环境的依赖。Agent 的代码也没经过评审，一个糟糕的改动可能搞挂机器或泄露环境里的凭据。

一旦批量跑 Agent，慢启动就成了瓶颈。Ramp 的解法是每 30 分钟烘焙一次预装妥当的机器镜像：Agent 启动时直接拿一台现成机器，跑个 git pull，不到一秒就开干。

另一条设计原则：把 Agent 与它调用的工具分开。工具崩了，不该拖垮 Agent。比如一个加载大 CSV 把内存跑爆的工具，不该杀死一条跑了很久的 Agent 轨迹。

Adam 目前在 Modal 工作——Hamel 最喜欢的云基础设施，它快到「代码其实在远程跑，感觉却像本地」。Modal 创建沙箱的 hello world：

import modal

app = modal.App.lookup("sandbox-hello-world", create_if_missing=True)
sb = modal.Sandbox.create(app=app)
process = sb.exec("echo", "hello")
print(process.stdout.read())
sb.terminate()

完整演讲视频，另可读 Modal 沙箱指南。

↑ 返回笔记目录

把评测结果变成更好的模型（Turn Eval Results Into a Better Model）

Will Brown 与 Florian Brand 的分享 · 2026-07-31 · 英文原文

Prime Intellect 的 Will 和 Florian 提醒：微调应该是提升评测分数的最后手段——因为很多时候不改模型也能提分。他们建议先按顺序过一遍：

1. 读 trace，搞清楚到底什么在失败；
2. 修评测和环境本身；
3. 改进检索、上下文与 harness。

第二条可能让人意外，但评测自身的小毛病可以很要命。他们给的例子：在 Terminal-Bench 2 上，光把任务超时乘以 5，分数就从 46.3% 涨到 60.97%。

他们还分享了搭建评测基础设施时的常见坑：

• 当心把 temperature 强设为 0——如果模型是按 temperature=1 采样训练的，这会影响基准上的可复现性；
• 检查 max token 上限或轮次上限是否过早截断了推理；
• 给沙箱足够的 CPU 和内存；
• 把臃肿的 harness 换成极简的，让模型直接跑 bash，而不是调用 bespoke（定制）工具；
• 在下「模型做不了这个任务」的结论之前，先把任务专属技能放进上下文。

只在两个条件同时成立时才考虑 post-training：正确答案能被自动验证；且模型在你的评测上得分高于 0、低于 100（还有上升空间）。

想试的话，Prime Intellect 的 verifiers 库用 Python 定义任务和奖励，他们的托管 RL 服务用一个短配置文件就能跑训练，也有现成的环境可以开箱即用。

完整演讲视频。最后一句话：post-training 需要一个奖励正确行为的评测——因为 RL 会利用一切不严谨之处。

↑ 返回笔记目录