AutoResearch 与微调本体：把机构工作流变成自己的模型工厂
完整解析 Palantir 的 AutoResearch 与 Fine-Tuning Ontology，梳理数据集、SFT/DPO/GRPO、模型工厂及企业训练、评测和专用模型的 11 步流程。
企业真正需要的，可能不是再租一个更强的通用模型，而是拥有一套能把自身工作流持续变成训练信号的系统。Palantir 在这份 22 页报告中提出的核心命题是：把机构内部的数据、决策、动作和结果组织成可训练的 Episode，再让 AutoResearch 在数据集、训练技术、基础模型、算力预算和成本上限之间反复搜索，最终生成一个专门服务高价值工作流的自有模型。模型权重、数据版本、评测集、训练配方和实验结果都留在 Fine-Tuning Ontology 中，成为可部署、可分发的机构资产。
这套思路的重点并不只是“自动调参”。它试图把后训练从一次性项目变成一条闭环生产线：生产现场产生新数据，AutoResearch 读取既往研究、约束、实验、产物、评测和分数，设计下一轮训练；训练过程再把新的实验、事件、产物、评测和分数写回系统。每一次成功和失败都让下一轮搜索更有依据。
原报告明确说明，其中数据均为示意数据。本文会完整保留这些示例的结构和数字，用它们解释方法；但不会把这些未独立验证的产品指标当成公开基准结果。
1. AutoResearch 在自动化什么
报告给出的定义很直接：AutoResearch 为机构自动化 AI 后训练。借助 Fine-Tuning Ontology，它希望以更快、更低成本的方式持续生产模型，并让这些模型在机构最有价值的工作流上取得突出表现。
传统后训练通常由一支项目团队临时组织：收集数据、清洗样本、构造偏好数据、选择 SFT、DPO 或 GRPO、设定超参数、运行训练、人工看评测、根据直觉修改下一轮配方。AutoResearch 要把这套过程变成有状态、可追踪、可扩展的实验系统。
团队先完成四项输入：
- 从 Fine-Tuning Ontology 中选择相关语料；
- 定义要提升的目标能力；
- 给出成功标准；
- 设置可使用的模型、数据、算力和预算约束。
系统随后使用这些机构上下文设计并执行后训练循环：识别私有数据中的可学习模式，生成有针对性的合成训练样本，选择和配置后训练技术，再让每个候选模型接受既定目标下的评测。每一轮都会记录数据、方法、模型变化、评测结果、算力使用和成本。报告强调，这种记录让机构可以看见哪些增强真正带来了可测量的能力提升，哪些方向值得继续投入。
五步工作循环
- 识别目标工作流。选择一个高价值工作流及其中的具体任务，例如对机构设备做工程诊断、遍历机构自己的文档，或正确使用机构专有工具。
- 选择 Ontology 横截面。挑选包含训练信号的 Ontology 对象，例如维修工单、手册、故障记录或工具调用日志。
- 生成可测量的训练信号。把选中的数据转换为样例、标签、评测和合成训练任务，并确保任务反映真实目标工作流。
- 搜索后训练空间。在数据混合、合成样本、训练技术、模型参数和算力预算之间探索不同策略。
- 部署专用模型并迭代。沿着表现最好、成本最低的路径继续，淘汰无效方向，最终得到一个针对机构工作流优化的专用模型。
这里最关键的并不是“自动生成更多数据”，而是让每一步都产生结构化记录。AutoResearch 读取既往研究、约束、实验、产物、评测与分数；训练运行又写回实验、事件、产物、评测与分数。报告把这种读写循环视为复利资产的来源：模型不是一次性产物，机构和系统共同积累的上下文才是长期壁垒。
四项核心价值
| 价值 | 原报告主张 | 真正需要验证的东西 |
|---|---|---|
| 加速复利 | 压缩“形成想法、运行实验、测量结果、创造价值”的周期。每轮迭代建立在既往结果构成的 Ontology 上，随着新数据、新技术和新优先级持续改进。 | 搜索是否真的比熟练团队更快，且没有把错误评测或数据泄漏固化进后续实验。 |
| AI 模型所有权 | 模型围绕机构私有数据、目标和成功定义构建。机构保留对语料、模型、约束、评测标准与后训练过程的控制。 | 数据授权、权重许可、供应链依赖、退出机制与可移植性是否支持“所有权”这一说法。 |
| 专用性能 | 系统识别私有数据中的可学习模式，生成目标合成样本，并挑选能够提升表现的后训练技术，追求工作流上的异常优势，而不是泛化能力。 | 留出集是否真正隔离资产、地点、故障族和时间；专用提升能否迁移到生产分布。 |
| 受控成本 | 在模型、数据、算力和预算约束内运行。小型定向探针先排除弱方向，再用细粒度追踪把能力增益映射到成本结构。 | 成本是否覆盖数据构造、合成、评测、人工审核、推理与失败实验，而不只计算 GPU 小时。 |
报告对“专用性能”的措辞很重要：目标是 outlier capabilities，而不是 generalized competence。它承认最有价值的模型未必在所有任务上更强，而是能在决定机构收益的一组工作流上明显更好。
2. Fine-Tuning Ontology：训练资产本身也需要本体
Fine-Tuning Ontology 是训练全部基础对象的完整表示，核心包括三类：数据集、训练技术或配方，以及模型。最重要的对象是模型本身及其权重。报告认为，这套结构应由主权机构拥有，用于保护并积累机构能力，也可以按机构自己的意愿白标和分发。
在 Foundry 环境中调用 AutoResearch 时，系统会实例化一个 Fine-Tuning Ontology。这个数据结构保存训练所需的基础对象，并连接机构正在使用的实时 Ontology 资产。它不是一份静态数据目录，而是持续吸收生产信号的后训练状态层。
2.1 数据集资产
Ontology 把来自 ERP、MES、CRM 等系统的原始、割裂数据组织起来，帮助用户做决策。这些数据和相应决策又可以加工为专用训练集，存入 Fine-Tuning Ontology，并由机构拥有。机构可以用它们训练自有模型，也可以把它们作为数据资产在市场分发。
报告特别区分了静态事务数据和动态决策数据。组织在 ERP、MES、CRM、PLM、质量与维护系统中持有事务数据；这些数据在 Ontology 中被结构化、连接，用于改善决策。决策本身、动作以及动作是否成功的记录同样作为 Ontology 对象保存。事务数据与动态决策数据一起被加工为专用数据集，为具体工作流提供高训练信号。
一个合格的数据集资产被描述为具有谱系、版本、安全标记和访问控制。它既可以用于内部训练，也可以授权给其他机构。报告给出的数据资产流程是：
- 连接。把 ERP、MES、CRM、PLM、QMS 和维护系统接入 Foundry，保留每个来源的完整历史。
- 结构化。把记录映射为资产、工单、故障记录、维修工单等对象类型和链接，让跨系统上下文显式存在。
- 精选。选择 Ontology 横截面，记录动作结果，并用合成生成器放大可学习模式。
- 打包。发布带 schema、谱系、评测切分和安全标记的版本化训练集。
- 变现。用数据集训练自有模型，或把它作为白标数据资产授权出去。
图中的示例数据集名为“维修诊断”，版本 v3.2，约 124 万行，schema 为 Trace+Outcome，按 80/10/10 划分为训练、验证和留出，谱系覆盖 6 类对象，标记为受限。这个例子把训练数据的价值说得很清楚：真正有用的不只是原始工单，而是故障记录、维修动作、结果、成功或失败标签、成本以及跨对象关系共同构成的证据结构。
2.2 训练技术资产
Palantir 把后训练经验编码为训练技术资产。不同工作流和数据集适合不同技术；报告称 Palantir 在多次部署中形成了有观点的 tradecraft，知道哪些训练技术适合哪些类型的工作流。在 Fine-Tuning Ontology 中，这些经验被固化为经过测试的训练代码、推荐超参数和能识别理想训练配方的工具。
报告把问题与技术分成三类：
| 目标 | 典型问题 | 技术 | 训练信号 | 模型主要学到什么 |
|---|---|---|---|---|
| 模仿 Imitate | 必须精确完成复杂、多参数的工具调用，例如查询天气、读取文件、修复失败测试、转换 CSV、检查 SQL schema、确认并预订航班。 | SFT，Supervised Fine-Tuning | 人工精选的示范轨迹。 | 在每个 token 上做梯度更新，尽量复现精选轨迹。 |
| 对比 Contrast | 既需要正确行为，又需要减少不必要的拒绝，同时保留一组适当的防护边界。 | DPO，Direct Preference Optimization | 偏好对：chosen 与 rejected 行为。 | 靠近被选中的行为，远离接近正确但仍有缺陷的替代行为。 |
| 探索 Explore | 开放、多步问题，没有唯一正确轨迹。 | GRPO，Group Relative Policy Optimization | 由 judge model 打分的多条 rollout。 | 强化优于同组平均分的决策路径，发现示范中没有写出的策略。 |
报告列出的可编码技术库更广，包括 continued pretraining、full SFT、LoRA SFT、QLoRA、prompt tuning、distillation、rejection、ORPO、KTO、SIMPO、DPO、PPO、RLAIF 和 GRPO。每个从 AutoResearch 搜索树中产生的候选，都要以可运行训练代码交付，并附带超参数先验，例如 LoRA rank、学习率、epoch 数、DPO beta、GRPO group size，以及真实数据与合成数据的比例。
“已编码”包含三层：
- 训练代码：每种方法的经过测试实现，可以直接在 Fine-Tuning Ontology 的数据和算力上运行。
- 技术选择器：读取目标与成功标准，推荐单一方法或方法序列。
- 经验先验：从 Palantir 既往运行中提取初始超参数和剪枝规则，让 AutoResearch 更高效地探索。
2.3 模型资产与模型工厂
AutoResearch 在 Fine-Tuning Ontology 上运行，并结合算力，形成报告所称的“模型工厂”：为机构工作流生产定制的前沿模型，且模型由机构拥有。每个模型都在 Foundry 实例中注册完整谱系，包括数据混合、训练配方、成本和评测指标。被提升为生产版本后，模型继续从实际工作流吸收信号并改进；也可以分发或授权给其他组织，并以机构自己的品牌白标。
模型工厂的输入包括来自 Ontology 的训练集、SFT/DPO/GRPO 等可编码技术，以及 GPU 预算与成本上限。AutoResearch 围绕基础模型执行搜索、训练和评测，把候选写入带版本、分数和谱系的模型注册表。输出既可以部署到生产工作流和智能体，也可以出售、许可或托管出租。
模型版本、数据版本、配方、评测和成本一起注册，使模型从“某个团队训练出来的文件”变成可审计的组织资产。报告强调的“最佳单位成本增益”也很重要：一个分数略高但成本高得多的模型，未必应成为生产版本。
3. 一个完整的 11 步示例
报告用一个示意性的主轴过热报警工作流串起整个系统。目标不只是让模型回答“可能哪里坏了”，而是让它推荐一个能够被测量、执行和复核的维修动作。所有数字均为原报告的 notional data。
3.1 定义工作流
工作流是“为清除主轴过热报警推荐动作”。模型只做一个决策：根据故障上下文给出缓解建议。输入包括报警 E214、流量 5.1 L/min、温度 89°C；候选动作是更换冷却液过滤器。成功标准必须事先写清：流量恢复到 8 L/min 以上，温度在 30 分钟内降到 75°C 以下，并且 E214 不再复发。
这一步要求固定模型收到什么、必须返回什么，以及判断返回动作是否正确的一条规则。若成功标准含糊，后续数据标签、评测和模型晋升都会一起漂移。
3.2 在 Ontology 中表示 Episode
一个训练 Episode 不只是“问题与答案”。它是案例、用户或智能体执行的动作，以及随后被测量到的对象和结果。只有具备可测量结果的 Episode 才能用于训练。
示例以 CNC-042 为资产，把 E214 故障、更换冷却液过滤器、恢复至 10.2 L/min 和 72°C 组织成一个 Episode。静态事务数据包括 Machine、Part、Fault code manual、Procedure；动态数据包括人或智能体执行的维修动作；结果包括读数、负载测试、报警状态与是否复发。
这一步把“动作是否有效”变成可查询的对象关系。没有结果，模型只能学习流程文本；有结果，模型才有机会学习什么条件下哪种动作真正解决了问题。
3.3 把对象传给 AutoResearch
横截面是承载当前工作流信号的一组对象类型。示例横截面包含故障记录、工单、读数、规程和手册，共 41,200 个有可测量结果的 Episode。AutoResearch 读取哪些字段是输入、哪些是目标、哪些衡量成功。
系统同时接收算力位置，例如云、本地或第三方环境。数据在进入训练前还要检查四类问题：孤立对象、相互矛盾的记录、不完整记录和评测泄漏。报告图中将这些检查明确标为 Isolated、Contradictory、Incomplete、Leaked。
3.4 保留不可见的灯塔样例
所有训练开始前，先按 80/10/10 划分 Episode。示例从 41,200 个 Episode 中保留 4,100 个作为评测集，其中机器在训练集中不可见。切分同时沿资产、地点、故障族和时间进行，防止模型靠记住已经见过的案例拿高分。
“随机按行切分”通常是最危险的捷径之一。同一台机器、同一故障族、相邻时间段的记录很容易同时出现在训练和评测中，造成看似优秀、生产却失效的结果。报告明确要求评测样例在机器上未见，这一步直接决定了后续分数是否可信。
3.5 混合真实与合成 Episode
一个 mixture 是带权重的 Episode 选择，再加上为记录缺失场景生成的合成 Episode。每份 mixture 都有版本。
- Mix A：只使用成功案例。
- Mix B：同时使用成功和失败案例。
- Mix C：提高稀有故障权重，并加入合成案例。
示例 Mix C 由 45% 工单、15% 规程和 40% 合成数据构成。其中一个合成案例来自 CNC-208：在 34°C、5.4 L/min 条件下更换过滤器，然后恢复到 9.8 L/min、71°C。报告没有把合成样本当作凭空扩增文本，而是组合真实对象、工况和结果模式，以补足长尾场景。
3.6 组装训练配方
一个 recipe 由一个基础模型、一个 mixture、一种训练技术及其超参数构成。每份配方必须在运行前写入 Fine-Tuning Ontology，变成正式实验。
示例 recipe 是 base-c、Mix C、LoRA SFT、rank 32、3 个 epoch、学习率 2e-4。系统也会先对基础模型做无训练评测，再决定是否值得投入训练。这样同一轮实验既能比较“训练前后”，也能比较不同基础模型本身的起点。
3.7 评测每个候选
一次训练运行产生 checkpoint 和结果。结果必须包含候选模型在留出 Episode 上多个维度的分数，并与预先设定的阈值比较。示例关注四项指标：推荐动作是否正确、负载测试是否通过、故障是否复发，以及不安全建议比例。
| 候选 | 正确动作 | 负载测试通过 | 故障复发 | 不安全建议 |
|---|---|---|---|---|
| v1.0 · base-a · full SFT | 0.71 | 0.86 | 0.09 | 0.031 |
| v1.1 · base-c · full SFT | 0.83 | 0.92 | 0.05 | 0.014 |
| v2.0 · base-c · LoRA r32 | 0.88 | 0.94 | 0.04 | 0.008 |
| 阈值 | 0.90 | 0.97 | 0.02 | 0.010 |
注意，示例中最好的 v2.0 仍未达到所有阈值：正确动作 0.88 低于 0.90，负载测试 0.94 低于 0.97，复发率 0.04 高于 0.02；但它的不安全建议比例 0.008 已经优于 0.010。这正是多指标评测的意义。单个总分无法掩盖一个安全关键项的退化，也不能替代预先声明的阈值。
3.8 迭代到阈值
失败结果要能被解释成具体失败模式，并反向修改数据、合成材料、超参数或基础模型，再启动下一轮实验。
示例发现两个问题：高温环境故障只有 76% 正确，过度更换过滤器的比例达到 6%。下一轮因此提高高温 Episode 权重，生成 34°C 环境下过滤器退化的合成案例，把 LoRA rank 从 32 提到 64，多训练 2 个 epoch，并重新测试下一候选基础模型。此类反馈必须是结构化字段，而不是写在聊天记录里，系统才能持续搜索。
3.9 部署到生产
只有通过全部阈值的模型才能被提升。部署门还要规定哪些建议必须由人确认后才能执行。示例中新故障 E214 出现，流量为 5.2 L/min；模型给出建议，进入批准门，再由获准人员执行。
报告给出的批准规则是：动作属于安全关键，或模型置信度低时，必须人工批准。生产模型还应遵守三条行为约束：推荐动作、引用相关规程、在不确定时升级给人工。这里的“门”不是可选的 UI 提示，而是模型输出进入物理系统前的控制点。
3.10 从实时运营中学习
每个生产案例都会产生一个新 Episode，记录模型建议了什么、实际做了什么，以及之后的读数变化。被接受、被覆盖和失败的结果都要回流，其中 override 与 failure 往往包含最高训练信号。
示例中，被接受的结果是 10.1 L/min，负载测试通过；被覆盖的结果是工程师决定检查冷却液泵；失败结果是温度仍为 87°C，E214 继续存在。失败案例应回到第 3 步的对象输入与横截面选择，而不是只在表面上调一个概率。
3.11 拥有资产
到这一步，Fine-Tuning Ontology 同时保存模型及权重、训练数据、评测集以及每个实验和结果。它们成为机构资产。示例中的 diag-agent v2.0 包含：机构控制的权重、Mix C v3.2 数据集、4,900 个合成 Episode、4,100 个评测 Episode、base-c + LoRA r32 配方，以及 38 个带结果实验。
资产既可以部署到生产智能体和业务流程，也可以分发、出租、许可或白标。模型与数据的所有权结构、访问控制和商业许可决定了机构是否真的能把一次后训练投入转化为长期资产，而不是又一次项目交付。
4. 这套系统真正改变了什么
报告的真正重点不是某个训练算法，而是把后训练的对象边界扩大了。传统模型开发把资产理解为权重；Fine-Tuning Ontology 试图把数据谱系、决策记录、成功标准、评测留出集、失败实验和成本也纳入同一个可查询系统。权重只是最终产物之一。
第二个变化是“训练信号”从文档升级为有结果的行动。企业知识库通常保存说明书和问答，却不知道某条建议是否有效。ERP、MES、QMS 与维修系统本来记录了动作和后果，只是分散在不同对象中。Ontology 的价值在于把“建议、执行、结果、复发”连接起来，使模型能学习结果，而不只是模仿措辞。
第三个变化是评测前移。成功标准、不可见机器、故障族与时间隔离、预先阈值、人工批准门都在训练前定义。若这些条件缺失，AutoResearch 只会更快地优化一个不可信目标。
对机器人、具身智能和物理 AI 团队，这套结构也有直接参考价值。机器人日志通常同时包含任务指令、感知状态、动作轨迹、控制器事件、人工接管和安全异常；这些数据正好可以组织为 Episode。但物理系统还需要额外处理时序同步、传感器校准、仿真与现实差异、接触事件、安全约束和故障恢复。报告中的企业工单示例说明了资产结构，并不等于已经证明它能直接解决机器人基础模型的全部数据问题。
5. 边界与判断
这份报告是 Palantir 的产品观点，不是独立评测。它给出了清晰的方法结构，但没有公开对照实验、用户案例、成本明细、延迟、数据规模或失败率来证明 AutoResearch 相对于人工后训练团队的增益。文中的 0.88、0.94、38 次实验等数字全部是示意数据，不能作为采购或技术选型基准。
至少需要额外验证以下问题：
- 评测可信度：灯塔样例是否在真实生产中保持不可见，阈值是否由独立于训练团队的人设定，judge model 本身是否经过校准。
- 数据授权：工单、手册、操作员行为与客户数据能否合法用于训练、跨机构授权和白标分发。
- 安全与责任：安全关键动作的人工门如何防绕过，模型低置信度是否能可靠触发升级，覆盖与失败是否会被完整记录。
- 成本：数据清洗、人工标注、合成数据审核、评测、推理和失败实验是否全部纳入单位收益计算。
- 锁定与可移植性：模型权重、数据格式、训练配方和 Ontology 是否可导出，退出平台后能否继续训练和部署。
最合理的判断是：Fine-Tuning Ontology 提供了一个值得认真对待的架构方向，把后训练从“模型文件”提升为“可审计的生产资产”。AutoResearch 的自动化价值能否兑现，最终不取决于它能生成多少候选，而取决于每轮实验能否绑定正确目标、独立证据、真实成本和明确责任。
可以自动化的是搜索、训练与记录；不能自动化掉的是成功标准的定义、数据权利、安全阈值和最终责任。
原文来源：Palantir, AutoResearch and the Fine-Tuning Ontology, 2026。
