Pyromind推大小模型协同架构 工业AI质检误报率降至8%

AI 下半场,不会只剩一个超级模型|对谈 Kevin Ding:Pyromind 创始人/CEO — 十字路口Crossing

十字路口Crossing

中心化超级大模型无法破解成本与隐私的不可能三角,AI ToB 的终局必然是基于 AutoRL 的分布式 Agent 蜂群。

AI-assisted summary of AI 下半场,不会只剩一个超级模型|对谈 Kevin Ding:Pyromind 创始人/CEO — original source. Check the original for full context.

Source published:

Detailed notes

## Background 本期节目由小宇宙播客频道《十字路口Crossing》于 2026 年 8 月 30 日发布,主持人为 Koji 杨远骋。节目围绕对谈 Pyromind 创始人兼 CEO Kevin Ding 展开,主要讨论了后训练即服务、AutoRL 自动化管道构建、工业与 B 端场景的落地应用,以及新推出的 PyroDash 大小模型协同架构。

## TL;DR 对谈探讨了为何 AI 终局将是 Agent 蜂群而非单一超级基础模型,并指出了单靠预训练和 Harness 难以突破的行业痛点。Pyromind 提出了从 RL as a Service 向 AutoRL 演进的路径,通过 Pyromind Studio 和 Ecomind 实现了数据回流与模型自我迭代(RSI)。同时,团队分享了在工业质检和工艺参数优化等场景下靠极高 ROI 落地企业 AI 的经验,并展示了兼顾成本、效率与隐私的 PyroDash 架构。

## Atmosphere & style 对话氛围专业且接地气,充满了一线创业者对 AI Infra 和工业落地细节的透彻思考。主持人与嘉宾的互动紧凑流畅,从技术架构的理性分析自然过渡到 B 端商业算账的真诚坦率,整体呈现出一种务实、求真且对 AI 下半场变革充满期待的专业研讨风格。

## Key takeaways - `00:00` Pyromind 的核心定位是通过 AutoRL(自动化强化学习闭环)实现递归自我改进(RSI),目前已在工程和商业化上初步验证了 PMF。 - `01:55` 预训练下半场的终局形态将是服务化的 Agent 蜂群(分布式生态),而非单一超级大模型,因为单一模型难以泛化真实世界无限且动态变化的复杂场景。 - `01:55` RSI(递归自我改进)成为刚需的原因在于,当企业并行成百上千个 Agent 时,人类无法手动进行维护和演进,Agent 必须具备在时间轴上自我迭代的能力。 - `05:21` 普通的 RL as a Service 只解决了训练基础设施(Infra)问题,而 AutoRL 将环境轨迹抓取、奖励(Reward)生成与模型重新部署串联,实现了真正的全自动化演进。 - `08:32` 最适合后训练落地的 B 端客户应具备三大特征:真实世界数据极其富集、具备天然且明确的评价标准(自带好坏标签),且改善场景能带来极高的经济回报(ROI)。 - `08:32` 后训练在工业制造场景效果显著,例如在可见光质检中,基于约 1 万张样本进行后训练,直接将误报率从传统的 23% 降至 8%。 - `10:16` 进入新场景初期,FDE(前瞻部署工程师)进场适配业务流程不可省略,但由于奖励机制在同类模态和场景下高度复用,FDE 的工作量可实现横向跨场景递减。 - `10:16` 通过将后训练与数据回流机制下沉为无状态的自动化管道,Pyromind 达成了极高人效,仅靠 2 名 FDE 即可支撑十余个大型 B 端客户的运转。 - `23:22` 接洽企业需求的三个否决标准:经济收益不可衡量(ROI 算不清)、偏离多模态与工业真实环境主线、以及不具备在产业链上下游横向复制的可能性。 - `23:22` 仅靠 Harness(如 Prompt 工程、工作流)无法改变基座模型底层参数,只有后训练才能在垂直领域突破天花板,并真正打破“成本、效率与隐私”的不可能三角。 - `27:03` 新架构 PyroDash 由 4B 端侧 Worker Model 与大基座模型协同工作,小模型负责对请求进行难度分类、本地处理简单问题并拦截敏感数据,复杂问题再路由至大模型。 - `27:03` 通过包含正确性和成本系数的奖励对 4B 小模型进行后训练(GRPO),PyroDash 架构能够在提升 10% 综合表现的同时,为客户节省约 20% 的算力与 Token 成本。 - `38:20` 由于工业生产环境的数据和参数每天都在发生微小变化,模型如果停止持续后训练就会导致性能衰退(掉点),这确保了 AutoRL 是一项持续性的管道服务而非一次性交付。 - `38:20` 与过去难以算账的中国 SaaS 不同,AI ToB 能够通过修改模型参数直接带来工业生产线上的良率或效率飞跃,拥有明确且巨大的 ROI 增量空间。 - `47:47` 当前 100B 以下(特别是 3.8B 到 7B)的小模型下载量占据绝对主流,进一步印证了多元化的真实需求不会被完全收拢到一个中心化超级模型中。

## Detailed walkthrough ### `00:00` 快问快答:团队背景与 PMF 初步跑通

主持人 Koji 介绍了本期嘉宾 Kevin Ding(丁一),他是 Pyromind 的创始人兼 CEO。Pyromind 专注于强化学习即服务(RL as a Service)与后训练即服务领域,成立不久即完成了由高瓴、百度风投、蓝驰创投以及 Atypical(Adebico)投资的天使轮融资。

在开场的快问快答环节中,Kevin 透露自己是 1994 年出生(32岁),毕业于伦敦国王学院(King's College London),MBTI 测试结果为 INTJ(兼具 I 与 E 属性),摩羯座。创立 Pyromind 之前,他曾任职于阿里云,负责弹性 GPU 实例及训练 GPU 集群等 AI Infra(基础设施)相关工作。目前团队规模约 20 多人。

* **公司定位**:Pyromind 最终定位是 **AutoRL**,这是递归自我改进(RSI, Recursive Self-Improvement)在工程与产品层面的一种具象化实现路径。 * **商业进展**:公司已初步跑通 PMF(产品市场契合度),验证了通过 AutoRL 实现 RSI 的商业价值,且在横向扩展不同场景和客户时,Pyromind 自身的人工介入工作量正在逐步递减。

---

`01:55` 预训练下半场:为何终局是 Agent 蜂群而非单一超级模型?

讨论延伸至对 AI 下半场终局形态的判断。Kevin 回忆说,在 2025 年下半场,业界对 ASI(人工超级智能)的实现路径产生了两种分歧:一条是继续沿着预训练路线打造一个超级庞大、能包揽绝大多数场景的中心化大模型;另一条路线则是服务化、以 Agent 蜂群(Agent Function)的形式存在。

Kevin 坚定地选择并押注后者。他解释道,真实世界需要被 AI 解决的问题是无穷无尽且动态变化的。在 Transformer 现有的架构下,试图用有限参数的单一模型去泛化无限的复杂场景极其困难,因此 Agent 服务化的分布式生态是必定成立的。

* **RSI(递归自我改进)兴起的原因**:当用户或企业同时运行数十个甚至更多的 Agent 来处理日常业务时,人类不可能有精力手动去维护和演进每一个 Agent。 * **Agent 演进的核心条件**:Agent 被部署到具体场景后,必须具备在时间轴上“自我迭代”与“自我改进”的能力,才能持续满足业务预期,这也让 RSI 和后训练技术成为了刚需。

---

`05:21` 从 RL as a Service 到 AutoRL:如何补齐另一半拼图?

Kevin 分享了一个关于团队认知演进的有趣过程。最初创立 Pyromind 时,他们认为只要提供一个扁平的 RL as a Service 平台就已经足够;但随后发现,普通的 Service 只是把训练 Infra(基础设施)搞定了,依然需要客户自己的算法工程师去写奖励函数和推动 Agent 改进。

为了真正跑通 RSI 闭环,Pyromind 决定升级至 **AutoRL**,将奖励机制(Reward)的获取与生成也纳入产品范围,从而推出了两款核心产品:

* **Pyromind Studio**:面向开发者和算法工程的 Serverless 训练基础设施平台。它将训练依赖的物理节点抽象为逻辑节点,开发者只需配置训练参数与 DP-Size(数据并行度),系统会自动完成单卡到多机多卡的横向 K-Scaling 扩展。 * **Ecomind**:实现 AutoRL 自动化闭环的核心产品。它向客户透出代理 URL(Proxy),插入 Agent 后可自动抓取真实环境中的运行轨迹(Trajectory)。结合内部的奖励模型与奖励 Agent,自动化生成训练 Pipeline 并将优化后的模型重新部署。

以 GUI Agent 客户为例,第一期仅提供 Studio 时,客户仍需投入大量人力去分析需求和编写奖励;而在第二期接入 Ecomind 后,终端 Agent 收集到的真实用户反馈能自动转化为训练循环,实现了完全自动化的演进。

---

`08:32` 筛选最适合 AutoRL 的工业级客户与 ROI 算账

Pyromind 在挑选适合 AutoRL 落地场景时,确立了非常明确的客户画像标准。Kevin 指出,真实世界的数据(Real-world data)越富集、越处于基础模型能力之外,后训练带来的效果提升就越显著。

针对工业制造等硬核场景,Pyromind 筛选客户主要依据三个指标:

* **数据极其富集**:特别是经过工业 1.0/2.0 数字化改造的高端制造企业(例如英伟达上游供应链企业),多年积累了海量的生产线数据。 * **天然的明确评价标准**:工业生产对良品、废品以及工艺指标有极度明确的经济学定义,数据天然自带“好坏”标签,解决了数据标注的难题。 * **极高的 ROI(投资回报率)**:场景的改善能直接带来经济效益。

以实际案例来看,在工业质检(如可见光/结构光质检)领域,Pyromind 基于约 1 万张样本数据进行后训练,直接将误报率从传统的 23% 降至 8%;在工艺参数优化(如 PCB 电镀工艺)中,后训练模型能将老师傅的经验迁移并随着数据增量超越人工水平。

* **计费模型**:底层 Studio 采用类似传统云服务的资源消耗计费(Buy GPU/CPU/存储);上层 AutoRL 产品 Ecomind 采用额度(Quota)计费,根据客户场景的更新频率和数据消耗算力单元定价(类似 Quota Credit)。 * **客单价规模**:在 ROI 明确的大颗粒度 B 端场景下,单体客户的付费意愿通常在**百万到千万人民币**之间。

---

`10:16` FDE 驻场不可省,但如何做到横向跨场景递减?

针对企业 AI 落地中普遍存在的“定制化项目制(FDE,Forward Deployed Engineer,前瞻部署工程师)”难题,Kevin 坦诚表示,第一次切入新场景时,FDE 的工作是不可省略的。

在初次进场时,FDE 需要深入客户现场,梳理数据制式、评价基准,并将 Reward Agent / Reward Model 适配到具体业务流程中。但 Pyromind 并不走“卖人头”的技术咨询路线,而是致力于控制 FDE 工作的“宽度”:

* **工作量横向递减**:奖励机制最终会收拢到具体的模态上(如图像、多模态视觉、特定控制参数)。在相似模态和类似工业场景中,奖励结构和模型具备相当高的复用性。 * **极高的人效比**:通过将大量的后训练逻辑、数据回流机制下沉为无状态(Stateless)的 AutoRL 自动化管道,Pyromind 目前仅靠 **2 名 FDE 工程师** 就成功支撑了十几个大型 B 端客户的交付与运维。 * **边界划分**:Pyromind 明确与客户划清界限——管道是无状态的,客户只需提供数据集并接收更新后的模型,敏感数据留在客户侧,不把 A 客户的状态打包卖给 B 客户。

---

`23:22` 拒绝不合理的 B 端需求与应对“不可能三角”

在挑选 B 端项目时,Kevin 提出了三条严格的“接单与拒绝”标准:

1. **ROI 必须可衡量**:如果经济收益不可衡量(例如偏办公、发票、差旅等通用行政类 Agent),无法向客户证明价值,Pyromind 会直接拒绝。 2. **不偏离研发主线**:聚焦于多模态与工业真实环境场景,不做无意义的单模态泛化。 3. **具备跨企业扩展性**:需求必须在产业链上下游(如 PCB 电镀工艺、各种可见光质检)具备通用横向复制的可能性。

同时,企业 AI 落地时常陷入“成本、效率、隐私”的不可能三角。单纯依靠 Harness(如 Prompt 工程、工作流编排、Memory 等)虽然能提高流畅度,但无法修改模型底层参数,在遇到 PCB 板 EDA 设计图纸等深度垂直领域(Domain)时,基座模型因缺乏基准分布而无法突破天花板。况且,Harness 无法从根本上解决隐私隔离问题,只有靠后训练修改模型参数才能真正兼顾三者。

---

`27:03` 发布 PyroDash 架构:4B 小模型与大基座协同

为了破解企业 AI 的不可能三角,Pyromind 推出了开源工作 **PyroDash**——一个由 4B 尺寸的小端侧模型(Worker Model)、强基座模型(Base Model)以及协作引擎组成的架构。

``` [用户请求/轨迹] │ ▼ ┌───────────┐ 简单问题 (端侧解决,0 推理成本) │ 4B Worker ├─────────────────────────────────┐ │ Model │ │ └─────┬─────┘ ▼ │ 复杂/无法解决的问题 [最终输出结果] ▼ ▲ ┌───────────┐ │ │ Base ├─────────────────────────────────┘ │ Model │ (调用公域/开源/闭域超级大模型) └───────────┘ ```

* **架构设计与运行机制**:4B 模型可以直接部署在 Mac 等端侧设备上(推理成本降为零)。请求打过来时,4B 小模型先进行难易度分类与路由;若自身能解则直接在端侧处理,若解不了则路由回大基座模型。 * **后训练(GRPO)优化**:使用包含正确性奖励(Correctness)和带系数的成本奖励(Cost Reward)对 4B 小模型进行后训练。 * **实测效果**:在 Benchmark 上综合表现提升了约 10%,同时当 Lambda 参数适小时,能够直接为客户**节省约 20% 的算力与 Token 成本**。 * **解耦优势**:Worker Model 与 Base Model 完全解耦,Base Model 可以是任意开源或闭源模型,不依赖其梯度。 * **隐私屏障(私域隔离)**:利用 Worker Model 针对敏感 Token 进行 Masking 处理,作为公域 Base Model 的隐私防护层。

---

`38:20` 商业逻辑与云厂商竞争辩证

主持人问及,若模型通过后训练越训越好、导致后续训练需求减少,Pyromind 是否会赚得越来越少?

Kevin 澄清道,工业与实际生产环境(如工艺参数调整、质检)并非静态。上游客户订单、原料、产品线每天都在发生微小变化。模型如果不进行持续后训练,就会发生“掉点”(性能衰退)。因此,AutoRL 管道必须持续运行,以保证模型始终维持在高质量水平线上。

针对云厂商(拥有算力与基础设施)是否会吞噬 Pyromind 的疑虑,Kevin 认为:

* 云厂商的目标是做超级通用的大平台,产品形态沉重且难以做到足够敏捷和专用。 * 中国 SaaS 过去难做是因为算不清账;而 AI ToB 通过改变模型参数创造了极高的 ROI 增量空间,只要算清经济账,就能形成健康的商业模式。

---

`47:47` 小模型下载主流与需求多元化

对话最后,Kevin 引用了 Hugging Face 最近(2026年8月中旬)发布的报告数据:在真实的运行环境与社区下载中,100B 以上的大模型下载量极小,而 **100B 以下、特别是 3.8B 到 7B 左右的小模型占据了绝对的主流**(例如 Qwen/千问 3.8B/27B 等系列小模型表现极其反响热烈)。

这一现象有力地支撑了 Pyromind 推出 PyroDash 的底层逻辑:真实的需求世界是高度多元与分布式的,绝不可能所有问题都被归拢收缩到单一的中心化超级大模型里。

* **近期喜爱的 AI 产品**:Kimi(认为更新后非常强)、Coding Agent(如 Pi/Pi.ai)、DSH(DeepSeek Harness,增长极快)、Claude 等。 * **下一个里程碑(Milestone)**:希望 PyroDash 架构能够获得开源社区与工业真实生产场景最主流的认可,真正帮助企业解决落地过程中的死穴问题。

---

- **创业团队背景**:创始人 Kevin 94 年生,曾任职阿里云弹性 GPU Infra 团队;公司创立于 2025 年,天使轮获高瓴、百度风投、蓝驰创投、Atypical 投资,团队规模 20 余人。 - **核心产品双轨制**:Pyromind Studio(训练 Infra、Serverless、K-Scaling 弹性扩缩容)与 Ecomind(AutoRL 自动化管道、Proxy URL 自动化采集轨迹与迭代)。 - **实测性能数据**:工业质检场景成功将误报率从 23% 降至 8%(样本约 1 万张);PyroDash 架构在 Benchmark 提升 10% 效果的同时,降低了 20% 的成本。 - **高效交付架构**:仅依靠 2 名 FDE(前瞻部署工程师)成功支撑了十余家大型 B 端客户的 AutoRL 管道部署与运营。 - **开源工作成果**:PyroDash 开源架构主打 4B 端侧 Worker Model 与基座模型协同,内置正确性与成本/隐私奖励机制。

## Notable quotes > `05:21` RL as a Service 只是起点,不是终点。Service 只解决了一半问题;真正要让 Agent 在生产环境中持续改进,还需要把训练、奖励、反馈、部署和数据回流串成一条可以自动循环的管道——也就是 Pyromind 正在押注的 AutoRL。 — Kevin Ding

> `47:47` 需求世界是多元的,不是所有问题都应该被收拢到一个中心化大模型里解决。 — Kevin Ding

> `01:55` 当用户或企业同时运行数十个甚至更多的 Agent 来处理日常业务时,人类不可能有精力手动去维护和演进每一个 Agent。 — Kevin Ding

> `10:16` 企业 AI 怎样才能不是项目制咨询? — Koji

> `10:16` 把一次性交付沉淀成可以横向复制的 AutoRL 管道。 — Kevin Ding

> `08:32` 工业生产对良品、废品以及工艺指标有极度明确的经济学定义,数据天然自带“好坏”标签,解决了数据标注的难题。 — Kevin Ding

> `23:22` 如果经济收益不可衡量,无法向客户证明价值,Pyromind 会直接拒绝。 — Kevin Ding

> `26:29` 单靠 Harness 无法从根本上解决隐私隔离问题,只有靠后训练修改模型参数才能真正兼顾三者。 — Kevin Ding

> `38:20` 工业与实际生产环境并非静态。模型如果不进行持续后训练,就会发生“掉点”。 — Kevin Ding

> `40:58` 中国 SaaS 过去难做是因为算不清账;而 AI ToB 通过改变模型参数创造了极高的 ROI 增量空间。 — Kevin Ding

## Mentioned Kevin Ding(丁一), Koji(杨远骋), Pyromind, 十字路口Crossing, 高瓴, 百度风投, 蓝驰创投, Atypical(Adebico), 阿里云, 伦敦国王学院(King's College London), Pyromind Studio, Ecomind, PyroDash, 英伟达, Hugging Face, Kimi, Claude, Pi, DeepSeek

[Source](https://www.xiaoyuzhoufm.com/episode/6a90fc5e1352af56ff3d48af)

中文简报

Pyromind推大小模型协同架构,工业AI质检误报率降至8% 中心化超级大模型无法破解成本与隐私的不可能三角,AI ToB 的终局必然是基于 AutoRL 的分布式 Agent 蜂群。 对谈探讨了为何 AI 终局将是 Agent 蜂群而非单一超级基础模型,并指出了单靠预训练和 Harness 难以突破的行业痛点。Pyromind 提出了从 RL as a Service 向 AutoRL 演进的路径,通过 Pyromind Studio 和 Ecomind 实现了数据回流与模型自我迭代(RSI)。同时,团队分享了在工业质检和工艺参数优化等场景下靠极高 ROI 落地企业 AI 的经验,并展示了兼顾成本、效率与隐私的 PyroDash 架构。 Pyromind 创始人 Kevin Ding 指出,预训练下半场终局更倾向于分布式 Agent 蜂群而非单一超级模型,因其无法泛化无限且动态变化的真实世界复杂场景。 (1:55) 普通的 RL as a Service 仅解决了训练基础设施问题,Pyromind 押注 AutoRL 自动化闭环,将环境轨迹抓取、奖励生成与重新部署串联以实现递归自我改进(RSI)。 (5:21) 在工业落地中,后训练基于约 1 万张样本将可见光质检误报率从 23% 降至 8%,且借助无状态管道高复用性,仅用 2 名 FDE 便支撑了十余家大型 B 端客户。 (8:32) 针对企业成本与隐私难题,Pyromind 推出 PyroDash 大小模型协同架构,由端侧 4B 小模型主导路由与隐私隔离,实测在 Benchmark 提升 10% 效果并节省 20% 算力与 Token 成本。 (27:03)

Reading summary

Pyromind 创始人兼 CEO Kevin Ding 认为,真实业务场景的无限与动态性决定了 AI 终局不是单一超级中心化大模型,而是具备递归自我改进(RSI)能力的分布式 Agent 蜂群;通过 AutoRL 实现持续后训练,是打通工业落地商业价值的关键。 押注 Agent 蜂群与递归自我改进 (1:55) Kevin 指出,在 2025 年下半场关于人工超级智能(ASI)路径的分歧中,Pyromind 坚决看好分布式 Agent 蜂群。他认为 Transformer 有限参数的单模型无法完全覆盖并泛化真实世界动态无限的问题。当企业运行大量 Agent 时,人工手动维护并不现实,部署后的 Agent 必须具备沿时间轴自我迭代与演进的递归自我改进(RSI)能力,后训练技术因而成为刚需。 从 RL 平台演进至 AutoRL 双轨闭环 (5:21) 团队早期的 RL as a Service 平台仅解决了算力基础设施,但客户仍需投入算法工程师编写奖励函数。为形成完整闭环,Pyromind 转向 AutoRL 并构建了两款产品:底层 Pyromind Studio 提供 Serverless 训练基础设施与 K-Scaling 弹性扩缩容;上层 Ecomind 充当核心自动化产品,通过 Proxy 抓取终端运行轨迹,结合内置奖励模型自动化生成训练 Pipeline 并重新部署。以 GUI Agent 客户为例,二期接入 Ecomind 后即实现了用户反馈自动转化为训练循环。 工业级客户画像与非静态商业逻辑 (8:32) Pyromind 筛选落地场景要求具备数据富集、天然评价标准清晰和高 ROI 三项特征,主要切入数字化改造充分的高端制造供应链。在工业质检实测中,后训练将误报率从 23% 降至 8%;PCB 电镀工艺优化则可迁移并超越老师傅经验。商业模式上,底层 Studio 按资源消耗计费,上层 Ecomind 采用 Quota 额度计费,单体 B 端客户付费意愿达百万元至千万元人民币。针对后期训练量是否萎缩的疑虑,Kevin 解释生产线原料与订单每天都在微调,若中断持续后训练模型会发生“掉点”,因此 AutoRL 管道需要常态化运行。 控制交付边界与破除不可能三角 (10:16) 针对定制化交付的挑战,Kevin 强调首次切入场景时 FDE 驻场必不可少,但奖励机制收拢至图像或控制参数等具体模态后具备高复用性,目前仅依靠 2 名 FDE 便支撑了十余个大型客户。公司要求交付管道保持无状态且敏感数据留在客户侧,并拒绝行政类等 ROI 无法衡量的通用需求。为突破企业落地中的成本、效率与隐私“不可能三角”,Pyromind 开源了 PyroDash 架构:利用 4B 端侧 Worker 模型先做难易度路由与敏感 Token 屏蔽,简单任务端侧零成本推理,复杂任务调用大基座模型。基准测试显示该架构在性能提升 10% 的同时降低了 20% 的算力成本。 结合 Hugging Face 在 2026 年 8 月公布的 100B 以下小模型占下载绝对主流的行业数据,Kevin 认为真实需求展现出高度多元与分散的特征;Pyromind 的下阶段目标是推动 PyroDash 架构在开源社区与工业真实生产环境中成为主流方案。

Source quotes

[5:21] Kevin Ding: RL as a Service 只是起点,不是终点。Service 只解决了一半问题;真正要让 Agent 在生产环境中持续改进,还需要把训练、奖励、反馈、部署和数据回流串成一条可以自动循环的管道——也就是 Pyromind 正在押注的 AutoRL。 [47:47] Kevin Ding: 需求世界是多元的,不是所有问题都应该被收拢到一个中心化大模型里解决。 [1:55] Kevin Ding: 当用户或企业同时运行数十个甚至更多的 Agent 来处理日常业务时,人类不可能有精力手动去维护和演进每一个 Agent。 [10:16] Koji: 企业 AI 怎样才能不是项目制咨询? [10:16] Kevin Ding: 把一次性交付沉淀成可以横向复制的 AutoRL 管道。 [8:32] Kevin Ding: 工业生产对良品、废品以及工艺指标有极度明确的经济学定义,数据天然自带“好坏”标签,解决了数据标注的难题。 [23:22] Kevin Ding: 如果经济收益不可衡量,无法向客户证明价值,Pyromind 会直接拒绝。 [26:29] Kevin Ding: 单靠 Harness 无法从根本上解决隐私隔离问题,只有靠后训练修改模型参数才能真正兼顾三者。 [38:20] Kevin Ding: 工业与实际生产环境并非静态。模型如果不进行持续后训练,就会发生“掉点”。 [40:58] Kevin Ding: 中国 SaaS 过去难做是因为算不清账;而 AI ToB 通过改变模型参数创造了极高的 ROI 增量空间。

Original transcript

[0:00] 嗨,我是Koji,本周十足路口的嘉宾是PyroMind的创始人和CEO Kevin DeanPyroMind所在的赛道是非常热门的RL-assess service也就是强化学习及服务或者后训练及服务他们前不久刚完成了贴使轮融资投资机构包括高林、百度风投、蓝池等你好凯文欢迎来到十字路口大家好好我们还是从快案快答开始帮助大家尽快了解你请问凯文你的年龄我是94年的32岁请问你的求学经历伦敦国防学院Kens Carlsson的MBTI和星座如果是按测试结果来看是INTG但是我的感觉可能IE之间星座是摩羯那么一句话介绍一下PyroMind最终定位就是一个AutoRL它跟现在大家一直在讨论的RSI这个方向其实是相对于它是一个比较具象化的一个实现路径我们待会再讲开聊一下对然后咱们的融资情况呢我们是去年公司成立之后就做了一轮高岭白鹿风投还有蓝驰还有Adebico投的我们目前咱们团队的规模是我们现在有20多个人咱们现在收入和利润方面讲吗具体数值就先不share了但是现在我们我觉得比较振奋人心的一点我定义就是说他初步的跑通了PMF什么样的PMF跑通了两个方向一个方向就是证明我们提供out-of-rl正方式实现的RSI是有价值的这是第一点就是它的商业模型至少是成立的第二点呢就是说它的这种可困难性就是说在横向的这种场景和客户的这种复制上来说我们的工作量是逐步递减的明白咱们在创业之前做过些什么我之前其实有很多经历是放在PN Infra这里的因为我之前也是在阿里云然后在阿里云其实也做了弹性GPU实力包括训练GPU的这些集群当时咱们是看到了什么样的机会决定创业做Paramind其实当时我的想法是这样模型预训练这个事情到现在为止其实远远没有到终结的时候当时看到一个趋势就是到25年下半年也看到无论社区也好还是硅谷也好还是国内的技术权也好大家都在讨论AI可能要进入下半场下半场的说法就出现了两个方向一个方向就是认为我们继续沿着预训练走ASI到来的形式会是一个超级庞大的它能够解决绝大多数的场景里面的问题效果还足够好然后另一条路线或者是另一个讨论的方向就是它最终ASI的形态会是一个服务化的形态是一个agent function的形态因为我个人来说肯定偏向于后者我觉得这个更实际一点因为我们这个世界上需要去被AI解决的问题和场景它其实无论是从当下时间点看它就是已经是无穷无尽的了同时随着时间的推移会产生不断的新的场景出来而且这个场景本身它也不是静态的那在这个模式下我们尝试去用一种有限参数的这么一个模型去泛化掉无限的场景这个事情目前来看我觉得在至少在这个Transformer这个架构上实现还是蛮有挑战的到目前为止又过了一年多就是你有看到一些信号就是这个让你感觉你一开始的BET是越来越成立了吗是的因为就是首先这个理论我们看到的是第二条路必然是成立的就是我不能说正伪第一条路但是我能论证的就是说第二条这种服务化的路线它是一定成立的因为需求是一直在那里的然后需求一直也在增长的然后这一年我看到的一个变化就是说大家为什么现在去提RSI为什么在之前RSI其实没有热度没有那么高其实这就是服务化带来的一个结果是因为你去agent步的多了我们可以想象一下正常一个人日常带了几十个agent再去做一件事他是不可能有精力去维护这种演进的对吧RSIV需要就是因为其实agent的现在开始多起来了我们能这一个个的agent在嵌入到场景里面的时候我们对它最终的衡量方式是它得在一定的时间轴上表现都得符合我的预期这个实现的方法就是agent需要自我去迭代然后你agent本身需要有自我改进的能力才能做到这些事咱们一开始做Paramind的时候就想到了要用AutoRL去做RSI吗还是这个是在过程中慢慢浮现出来的实话说其实是过程中浮现出来的场景一方面我们自己本来就在看这个方向另一方面其实讲一个有意思的故事后训练这个事对我们自己影响也比较大因为你会发现以RL为代表的后训练技术它其实是拿到环境的反馈然后去更新拿到它是一个持续的过程其实对我们自己去研判方向我们团队也是这样子的 [5:00] 我们其实一开始在创立之初我们认为做到ROAS Service做到一个扁平的Service形态其实就已经差不多能满足这些agent的部署的一些要求了但是我们后来发现它依然是不够的因为Service它的面向的对象终归还是要有一个developer在那边去驱动agent去改进的对吧所以我们在这个阶段我们才去想其实Service值得一半的问题因为我们真正把RSI跑起来要解决两个问题一个是奖励的问题所以我们就开始规划说Auto RL要怎么跑起来同样的奖励就纳入了我们的scope可以用一个具体的客户的例子来讲一下我们只给他单独做RLSR Service和我们现在要给他做Auto RL具体的补物的内容有什么不同吗我觉得比较好的例子就是GUI Agent的一位客户因为他们下游有蛮多的消费的部署量的然后他会收上来很多这种用户这种特定的需求以及他自己的产品迭代一些需求进来我们一开始提供的这个RO Service呢是给了他一个Studio然后去把一个通用的一个Training Pipeline去给他固定下来但是呢他依然是要不断的去投入自己的这个算法工程师也好或者什么样的人也好去不断的去更新这个Agent本身我们只给他去把训练这件事情解决的很好因为就是你想嘛一个训练要去完整的解决完就是完成一版模型更新他其实除了这个需求册的一些分析就翻一张奖励然后训练 同时后端的Infra也要被解决 我们当时把Infra的问题全部给它解决掉了但是他依然没有摆脱掉说他依然会去投大量的人力去搞这个东西然后我们后来去就是到了第二期的时候我们去把这个GY方向的这种奖励做了做之后我们发现其实这个loop其实可以自动化的跑起来的因为就是只要他的这个末端部署的这些agent他能源源不断的收上来用户在真实环境下的一些反馈这个东西说过来之后我们就在想那为什么不让它能够自主的循环去跑起来所以我们在第二期就给它把Ecomind产品推过去了其实咱们现在提供的主要的产品有两个一个就是Paramind Studio然后另外一个叫Ecomind然后可不可以分别介绍一下他们俩是什么样的产品YouTube就是我们提供的解决训练Infra的一个serverless的service我们会在这个Studio上去实现大量的这种训练所依赖的逻辑节点因为开发者在去配这个节点的时候他是不需要去关心他在物理机上实现的他更多的只是配置了一个训练的参数然后逻辑节点他横向着K-Skilling的你可以去做这种单点的单卡的算力然后单台的到多台的这种都是可以在一个逻辑点上去扩展的然后扩展的工作是我们去做掉了然后对于训练开发者来说他只要去把训练的参数以及像DP-Size去配备好就可以了然后对于Ecomine的这种产品来讲所叙述的整个RSI的流程全部都包在这个ACOMINE的背后然后我们给用户透出的是什么呢是一个proxy就是一个代理的URL然后呢这个URL只要去插入到某一个agent里面其实它就可以去源源不断的去把agent在这种轨迹抓起来它就是一个相对来说比较整齐的一个数据集那这个数据集它去过这个讲庭结构然后去生成这样的一个training pipeline然后去训练拿到结果然后再部署回去对吧好产品去包起来了对OK那Paramite现在典型的这个客户画像是什么我们去做客户的选择的时候它其实需要的是真实世界的这些数据并且这真实世界的数据一要产生于生产场景第二个它最好是在模型能力之外对吧这个其实对模型的效果提升是最明显的然后我们去选择客户的时候就在思考哪里的real world data最负极对吧我们当下有一些比较重要的客户就是集中在工业领域的就是像这个英伟达的上游啊这些企业然后他们有个特性就是经过过往的这么几年的制造1.0 2.0的这些改造他们其实在企业内的数字化做的还是蛮好的同时经过了这么多年的生产又积累下来一批非常可观的数据这是一个指标然后第二个指标就是工业场景还有一个好处它除了数据复迹之外它自己对于自己的经济生产它是有定义的这样的话收上来的数据往往都有了一个相对明确的好坏的标签你标注这个问题也天然的就被他解掉了与此同时我们同样的毕竟还是一个商业行为我们要去衡量一下他的ROI然后这三个条件都满足情况下我们在产业链上的工业的客户他可能是一个比较好的画像工业客户是一类还有其他的比较典型的客户画像吗还有像agent或者是和巨生相关的对和巨生相关的对巨生相关的其实我们也会看当然当下来看巨生 [10:00] 是一个相对独立的这么一个板块因为我们目标还是去做后训练驱动的这种RSI当下偏软领域肯定会做的会更快一点因为巨身你还要需要去考虑硬件的一部分东西所以这个是一个更复杂的一个问题然后再咱们给企业去做RL不管是RLS Service还是我们做AutoRL的过程当中最花时间最花钱的是什么部分最花时间的实际上是的这个FDE的工作就是你看我们虽然说做RSI但是我们并不排斥就是完全FDE因为就是本身啊你去让这个把RSI渗透到某一个场景的时候这个FDE这个阶段是不可省的然后我们在初次进入的时候需要去把他们场景里面的这个数据知识还有它评价基准然后同时我们自己做的这套比如说奖励Ager Reward Agent或Reward Model去适配到这个场景上这个是比较花时间的但是好处呢你在这类型的行业其实在初次能挤动是需要做些工作的但是后面scaling起来它的工作就是递减的这个是我看到一个比较好的现象因为其实做奖励这个事情它最终还是会收拢到模态上就是它在相似模态上的话其实有相当一部分工作是可以服用的所以去年那一大批不管中国还是美国做RL as a service的公司现在大家都和咱们一样慢慢的开始都要去做autoRL在外面我觉得大家是有分化的因为首先对于下半场这种需求来说它是非常丰富且非常宽的比如说去年应该说我们同期去看了一些公司他们在做的事情比较出名的应该就是Apply Compute它其实到现在为止已经更往前走了一步它会去提供一个非常完整的这种服务的技术设施它去把agent serving这些东西全部都做了这个企业我去把企业内所有和agent和AI相关的东西我全部都做掉了这是一个路线然后还有一个路线是应该是近期比较出名的是那个trajectory它也是DevMind的人出来去搞的一家非常优秀的一个公司然后他们做的就和我们的理念会相似度相对会高一些他们就是单纯的去做这个二头二摇同时他们跟这个merker啊或者是clay或者是那个hervey啊他们也有一些这个合作然后他们的定义我觉得跟我们就会相对来说比较相似一点我们更期望做到的是Auto这个事情我们去把五状态的RSI的能力提供出去它是一个可以平台化的东西五状态的对因为这两个分支其实你能看到它的属性前者叫他Compute做的就相当于是我把企业里面所有的这场景我全部都爆掉了对吧它是一个更加宽并且更加重的一个方式然后后者它是一个scaling的方向不一样Apply Compute它是在一个企业内纵向去skilling然后对于Trader这个思想它是只把训练这一件事情做好然后横向去skilling我们更倾向用这种方式来做然后回到刚才状态的问题因为其实有状态无状态它最典型的例子是做环境因为其实大家做后训练环境是被高频提到的一个词然后我们对环境的理解呢就是呃他原本其实在coding领域环境是一个非常典型的东西因为你去把这个这个compiler去提供出来对吧他其实你每生成一个新的这个代码片段去compiler去跑一下他都能够拿到一个呃比较强的一个奖励信号他是否通过了对吧但是呢就是他的一个特性就是他跟你本身这个生产环境里面的这些信息他是不偶合的他是可以被抽离出来的对吧但是对于实际生产生产环境来说呢这样的环境就比较有限对吧你比如说是刚才举的那个例子就是像这个GValid Agent对吧你想去把他每个用户的一些自己的需求去做好的时候你是不能脱离他的这个用户上下文存在的如果你脱离了对吧他就缺乏了生产价值如果你跟用户上下文偶合在一起那他就是一个有状态的环境所以我们要去做的事情呢是在这个这么长的这个链路里面找到那个可以很像去Skilling的无状态的东西那这个东西呢感谢观看而是说它应该是一个auto-RL的这么一个管道这样的一个管道就是你给它去为数据然后它拿到数据之后通过reward agent及reward model去拿到reward signal然后去迭代一轮然后这种其实你本身的这个out-of-all的这个管道以及这个reward本身它其实就是一个无状态的它跟那个生产上下文其实是不合的这里我有点困惑因为它一旦是奖励信号它应该就是在真实的生产环境里面出现的奖励信号怎么能抽离出来你对于场景来讲它需要去做一层结构的因为奖励信号本身实际上是当模型去在场景里面去入落 [15:00] 一次对吧对应的reward model或者说reward agent它去给出一个这种优势就是advantage对吧就是你给出一个这种优势才能找到更新的方向这一种方法第二种方法就是它生产场景回流回来的数据它包含了一些人工的这种judgment这样子其实它也是一种奖励但是这两个信息就是它本身跟它的上下文其实已经结偶掉了它是包含在用户去回流过来的数据集里面的而不是包含在我的环境里面的也就是说特别是对于我们要去做一个很像可以skilling去卖给不同客户的产品来讲我不能去把A客户的状态打包进我的产品里把它再卖给B客户这样是不行的可以再稍微展开一下刚才咱们提到第一类的典型客户是工业工业的客户咱们在给他提供服务的时候我们具体帮他们做了什么工业其实我们现在偏软的主要看两个场景一个是和工艺相关的就是对于这种工艺改进的这种模型其实他去做post training还是比较甜品的一个地带然后第二个就是做这种质检的质检的其实它也是个典型多么太问题也是一个比较甜品的地带然后工艺领域它有个好处是无论是工艺还是质检其实它的数据复极程度是我们无法想象的就是非常非常复极而且是它对这个东西的结果是好还是坏都有明确的评价基准质检比较好理解工艺可以举一个更具体的例子吗工艺其实就类似于像电镀我们其实可以不用深入到它具体是怎么做的它其实就是说在生产线上有一批参数要配然后这批参数配好了之后它的产线后段就能拿到他想要的东西但是参数过配的不合适拿到就不是自己想要的东西然后现在的做法是还是老师傅在做这个事的对吧因为这个还是其实它就是个人驱动的一个事情然后你去做后训练对模型做后训练的目标是能够有效的和未来增量的生产数据去把人做这个事情的经验去迁移到模型里这样的话其实模型在去做这个事的时候无论就是说它在长期来看的这种品控的保护上就是品控做的水波动上还是说随着它增量数据略越多它可能会比人做的更好这个上面它其实模型现在是有能力去做到的咱们怎么收费呢我们现在就是有两层产品一层产品就是我们定义ROService的service层它就是Studio然后其实对于用户来讲它更多是资助式服务这里我去击费的方式就很简单了就是buy资源的这种击费方式buy token吗还是就是类似CPU存储GPU这样的因为这是在service层的service的计价其实大家也都比较归拢因为其实Cloud Service做了很多年了对吧然后对于上层的这种AutoL的产品这个场景价值来去记了然后他记的方式也是QDA我们会去根据他场景里面的这个更新的频率来去限制给他一个这个Ecomine的实力他的cota的限制在哪里对这样的话其实就是白效果因为我们对于Ecomine的AutoRL这样的产品我们是嵌入了我们提供的奖励价值的我们相当于除了把训练Service做好之外我们同样的用我们自己的奖励解构去给出了它胜确的一个更新方向所以对于客户来讲他其实什么都不用管他收到的是一个更新好的模型所以第一部分Service是等于训模型一次性的收入后者可能是更长期的收入其实前者也是长期的边界就是在于谁来维护RSI的管线如果是Studio的用户的话其实它这里面的管线是客户自己在做的包括reward function也是客户自己去写的我们只提供稳定的一个infra service但是对于Ecomine来讲因为我们自己介入了它实际场景里面的这些问题所以说我们会把它内化到我们的reward model上面我们来去维护这个事情像一个典型的用户他向你们付费大概是什么量级就能从他那收到或者赚到多少钱因为我们做的RSI这个形态它适配的光谱是很广的所以说对于大颗粒的企业来讲其实它付费还是蛮高的在ROI很明确的场景下其实单体客户付费基本上也是到百万到千万人民币的区间了但是因为本来RSI这个事情或者是auto-RL这个事情它能够改进的场景放大效应非常大的这种RI的场景同时他又会有一些比如说developer做coding的一些很小的场景小的场景的话其实对于用户来讲他的颗粒度可能就比较小我们去做这个为什么一直在强调很像就是本来auto-rl这个事情它就是应该无缝的渗透到所有类型的agent里面的至于说我们的这种大颗粒度的B端客户还是小颗粒度的这种PNC端ProC端的这种客户的付费它都是取决于这个agent本身的给它创造多少的效益出来 对 [20:00] 我们的这个ECOMED的这个计价就是一个单一的这种QOTA的计价我们其实也很容易去区分这个场景就是对于高价值场景来说其实它的这种生产loop里面积累的数据量也是相应的会大很多同时它要求也很高你要去做的这个训练轮次也很多所以说它对应的ECOMED的QOTA消耗就会是一个非常可观的数字然后对于一些比如说ProC这种很小的场景它可能要求没有那么高它只是说达到某一个BaseLine就可以了同时它在一个相对窄的DOMB里面没有那么多那它的QOTA消耗就会比较少刚说QOTA消耗的时候说的是Token消耗吗其实是我们定义的这种应该说一个资源单元就是我们去衡量本身ECOMIDE去做一轮RL在嵌入奖励价值下的一个单元所以它等于就是比如说Mindness的Credit还是类似于Credit对它跟Token其实不是特别的绑定它和什么绑定呢它就是我们去做一轮这样的一个其实我们自己会有一个成本账对吧就是你在做这种多莫泰的这种常年轨迹他做一轮我们大概成本是X然后同时我们嵌入了奖励价值之后我们会对Quota去定一个X网上去加一个百分比的这种形式你们的成本主要是Token成本还是是什么成本我们实际上是训练消耗的资源成本主要还是GPU CPU这样的资源对就是我们自己的内部的成本是这样现在企业主要找到你们他们会怎么表达他们的需求这就是涉及到需求侧了就是客户他能get到或者说最直接的方式就是你的结果是什么为什么我们去做像这种质检领域和公益领域这两个领域的这种结果是显而易见的然后对客户来讲他其实只问一个问题就是我需要付出什么然后我付出了这个之后我能拿到什么这个给他解释清楚就好了就是为什么我们会我们觉得RLService不够对吧因为我们如果说面向这项客户提供了一个Service他去自我自主去开发的这个肯定是不合理的我们提供Ecomind就是我们可以明确的告诉他就是在你历史的这些样本上然后我们去做Excellent的这样的训练就能拿到一个像一个指标然后其实像质检这个领域我们其实比较有效的可以把误报率从当下的23%直接降到8%能给他去这只是在大概1万张的样本上去做的然后这样子其实他的成本和收益就非常明确了那他一般会怎么理解你们的报价因为你其实自己创造了一个定价的体系看到他那他会对标什么来去理解这个价格其实客户对价格的理解更多的是在于这个事情在我的场景上的RI有多少以及我付出这个代价在我RI里面占比他要去判断这个东西值不值得搞其实对我们来讲总归因为我们的消耗其实主要还是店的消耗所以说总归下来这个账是双方都算得过来的因为我们选场景的时候也会去选放大效应比较好的场景就有一些场景企业内不是所有场景我们现在都要做的比如说有一些像偏办公的偏这种发票的或者说差旅的这种agents我们其实做起来就感觉会比较吃力因为它的ROI是不好衡量的在这里去说得通就有一些难度有没有什么类型的需求是总找你们但你们觉得就确实在这个时候就不做拒绝我觉得就是一个是这种RI不明确的就是我选场景有三个依据第一个依据就是RI必须是可衡量的然后如果是不可衡量的我不好定价第二个就是他不要偏离我们现在的研发主线我们现在其实去搞的是这种主要是动摩态的场景因为就是落地的话其实你不可能做单摩态然后第三个就是这个场景本身他在企业内的这种扩展和跨这种企业的扩展他得是有扩展性的的领域就是一个是工艺工艺它本身像比如说电镀这个工艺它在所有的这种PCB的这种行业里面它都是通用的然后质检就像可见光质检包括结构光质检这个其实在几乎所有的制造也都是通用的起来还是蛮和它其他环节节偶的它其实倒不能说结偶了因为它现在其实本来都是流水线它其实前后的都是息息相关的其实现在还有一个挺好玩的一个case就是它这些场景它整个这种生产流水线是很长的叫PQ Phase的这种控制整个去出一个报告就是Process and Quality这种控制他会去做一个更抽象的一个报告好处是什么它是可以被AI很好解决的一个单元我们去看是这么看这个问题的其实之前你看你在阿里云是做Infra然后现在开始感觉非常要深入到各个客户的业务的一线的现场就这个中间是一个什么样的过程就对你来说创业的这种体验经历我觉得跨度 [25:00] 没有那么大因为就是做infra本身就是一个需求导向的对吧Infra不可能闭门造车的对吧我们基本上都是以需求驱动的方式来去做的现在其实做客户也是一样的我们再去看到这个场景之后然后客户有明确的需求我们去提炼其中的共性然后找里面可以去SkillUp的点找到之后我们就把它做成一个产品对这个路径其实在Infra时代就是这个思维模式完全是相通的对就还是从需求出发对我们其实之前在20阶段商业的这种客户对我自己在想就是AI现在在落地的阶段或者说产生价值的阶段它需求其实是分层的就需求的这种接收度是分层的第一层就是这个东西是不是好用以及它效果是不是好对吧是不是好用这个事是不是简单这个事其实有很多方式可以实现比如说现在自动模型做的API就非常应用对吧API之外比如说DSH它做这个Deep Seek Harness对吧这个东西也很好用对吧好用解决了然后效果怎么解决效果就是你可以加大量的Hardens和技让模型行为对齐到你的需求上然后同时你也可以去做后训练你用训练的方式来提升模型能力来达到效果好用这其实是需求的第一层然后下沉到第二层他就会考虑第二个问题就是我做这个事情RI是不是合理我得有收益我做这事也没收益我就不会做了然后再就是说本身搞这个东西其实企业里面需求到第二层的时候它就会追求一个不可能三角了我既得成本好又得效率好未来还能不能满足我的隐私的需求它到了这一层的时候就会对需求要求就会很多了所以说我们选择去做RL我们为什么没有去做Harness我们没有去集中精力去做Harness我们选择RL以及把它做成RSI看到的是长期来看这种autom RL的形式的RSI它是可以正好把这两层需求都完美的承接掉的尤其是刚才提到的深层次需求里面的不可能三角这个东西实际上就是我们近期发的一个工作就是Pair Dash对吧给大家讲讲Pair Dash到底是什么对 因为Pair Dash我们做最初是源于我们自己的需求其实我们主要还是Web Coding也太贵了我们是做了一个协作式可以利引擎的然后这个引擎它会把一个4B size的模型和一个base model连在一起就是这种协助的引擎因为它在听接的对象是上下文的评级所以说它对base model是没有要求的你base model可以是任何一个base model可以是开源可以是B源因为我也不需要它的梯度但是我们训练的对象就是4B的模型我们选size有一个原因是它刚好在端侧就是Mac上可以跑起来所以说这就代表了你首先有一个推理成本是零的东西只是它问题就迁移到就是说它的效果不够好了对吧所以说要对它进行训练了然后训练大概就三个阶段了第一个阶段是要去给他做难以问题的分类第二阶段去做轮系统也就是说看到的结果是一个请求打过来小模型会先接接了之后他会去看这个问题到底是不是是不是一个他能解决的问题如果小模型能解他就直接端策就解决掉了如果他解不了他就会录由回这个base model然后第三个阶段的就是一个GRPO的过程这个GRPO过程就是我们开放的奖励结构就是一个正确性和一个成本当然成本奖励是带一个系数的训练了一段时间就发现一些比较有意思的结果它的base line表现会比纯的base model会有一些提升同时因为它做了分类之后它把简单问题自己解决掉了所以说它成本一定是这样的然后我们有一个数据就是在Benchmark表现提升大概10%然后用PairDash的架构的话其实当Lamda比较小的时候还可以省掉大概20%的成本当然就是这个架构我认为它潜力肯定不在于成本因为我们在去推广PairDash的时候它成本是一个非常好的一个突破口但是我们现在在构建的就是隐私问题隐私问题其实它就更具有这种弊端属性了就是它的企业里面的问题它总归还是可以分为公寓跟私欲的指的不是B端跟C端指的是这个问题有没有好的base model它现在机械模型不是所有问题都解得非常好的对吧公寓就是指这个问题机械模型本身的base line还不错这种情况下其实可以用我们的paradish这种方式去训一个这种walker model然后它只是训练对象不一样然后思域问题就简单就是你一个端端端的模型解掉就好了所以你觉得harness再怎么进化它仍然有它解决不了的地方harness其实是一个很好的很轻的一个方式就是说我们在思考的一个点怎么样能够通过一个不要去投入那么大的这个人力的同时去把那个不可能三角能够好好的解决掉这个其实就是一个后训练方法来去做的事情因为你想在这个成本速度和隐私这个三个维度上都去追求一个最有解的话你终归还是要挖掘一下模型的能力的你纯做harness可能能解决速度的问题但是呢隐私肯定解决不了的对吧所以harness不能够解决隐私的问题然后咱们可以解决这个 [30:00] 具体的隐私问题是怎么定义这个呀隐私这里其实就是公寓和私欲问题这个肯定是要分开看的对吧就公寓问题就是base model解的很好了然后呢对于企业来讲呢嗯他现在是有一些问题是不希望打到这个base model上有一些问题是可以的那隐私这个方式呢就是我们在公寓上去做这个work model这个work model你在训练他的时候可以去给他构造不同的奖励项我们现在发那个paradish就是开源那部分呢只提供了两个奖励项一个是正确性奖励一个是成本奖励再说的成本和表现这个东西先去cover掉了然后同时还有一个讲理像是可以去购造但是我们现在还没有去发出来的一个工作就是隐私讲理一下他对这种敏感的token需要有一定的masking能力你需要去挡一层然后用这个work model去把敏感信息挡掉去做一些处理然后再路由回base model所以当你说到隐私的时候就是说不想把任务丢到公寓去不想丢给基摩去不是所有的这种信息或者说上下文不是所有的信息都可以被丢给一个基模的但是Harness不也可以很简单路由一下如果本地部署一个开源模型玩到自己的服务器上我就把有隐私相关的问题也就是路由到自己的本地部署的模型所以它就是一个不可能三角你如果是用这种方式的话你怎么确保模型生成的结果是满足你的要求的你们不也有一样的问题吗所以说要训练这就是我们去搞模型训练的一个最终目标就是模型本身参数是需要去被修改的参数的方法来去搞这个事情的话它天花板其实是存疑的因为到了伸斗命之后有很多问题如果你不通过训练解决的话它是有可能是完全做不到的所以这个可以展开一下吗就是我们在一个需求场景上如果拿到了明确的这种就是它的这个场景里面的这些数据也好或者评价基准也好它其实是可以去翻译成一系列的这些奖励信号的我们可以教会模型怎么样去按照目标来完成这个任务但是模型要学会它它是不可能单单纯的通过Harness来学的对吧Harness它给提供的更多的是一些流畅性的东西或者 workflow或者skills或者memory对吧它都是在本质上来讲是在context上在做一些工作但是你如果说不去修改这个模型不去训练它它可能模型能够解决的这个问题就相对来说比较有限对而且这个还依赖于你本身部署的这个模型在预训练阶段它的样本分布EDA这个方向的就是在PCB版的电路图设计的一个EDA软件它是一个比较独立的这么一个斗命然后绝大多数的基础模型在预讯的阶段是不可能见过这样的样本的这样的样本其实哪怕是你拿一个很大size的一个base model去布置到本地去你要他解这个问题再怎么做harness他都很难达到一个非常理想的状态最终还是要对于模型参数本身还是要去做修改的我们去区分公寓和私欲问题的最重要的原因是也不是所有的场景都需要完整的预训练因为他当这个问题已经被BaseModel解过了比如说Coding类的问题你想在一个具体场景上再让他解的时候就没有必要再去从头预训练了对吧你去把Worker Model去把你特定的这些要求去训练就好了然后对于像刚才提到的这种很深的Domain他肯定需要一个Ant2Ant的Model来去做对所以Thinking Machine的Tinker和你们有哪些相同的不同其实是不大一样的因为就是Tinker提供的还是这种Laura API对吧就是我们现阶段其实不太会花太多精力去做Laura这个事因为就是怎么说就是Laura的训练它固然是非常有效的但是它有一个要求是第一它得跟机动模型要绑定起来你去在某一个机动模型上做的Laura其实在去跨机动模型迁移的时候会有一些工作你们ParaDash这个工作是解绑的完全解绑对因为就是训练方法来讲Worker Model跟那个Base Model之间就是Context的这种联系所以说它在训练阶段它就是一个完全独立的在服务一个客户的过程当中其实咱们刚才也提到FDE这个词其实我理解它就是需要人入场FDE只是一个比较好听的说法其实也是我们要自己派人过去沟通去服务去给他梳理他的各种东西你现在是怎么理解这个事情追求尽可能弱化FDE吗我倒没有说一定要弱化FDE因为我觉得在很长一段时间这个角色都是被需要的我追求的东西是就是FDE这个角色的宽度对吧其实我觉得现行主流的FDE它的定义宽度是很宽的它得进去去理解需求它得去做相应的这种适配然后去把交付做了然后交付的形态往往也是BaseModel加Harness对吧这是一个比较典型的这么一个FDE的行为然后我定义的FD其实我觉得他只要做前面段就好了就是把需求接回来然后我们把第一个场景的 [35:00] 在这个Otto Oil的这种产品上去做一次适配这样的话其实后半段就是交付的这个东西它更多的是交付的这么一个能够让把生产数据回流回来的能够不断提升模型表现的这么一个RSI的管道这样的话其实至少在我们时间角度来看FDE的工作量负载会相应的下降很多然后实际上我们现在去服务的也有十几个这样的B单的客户最终大概两个FDE去支撑他们的需求来的对但他比如说回来之后像用的AutoRL的这个部分你们要有其他的同事去承接吗我们需要的就是因为接回来的需求我们在第一次做一个场景的时候本身做奖励结构这块还是需要去做一次实配的那他是不是也叫某种意义的FDE呢就是泛化一点来定义的话我觉得不能算因为我们自己的角色分配是接回来这部分人他们其实是更加做基础和通用产品的这种角色就通用的这种板块的角色然后他们做的事情是在我们现行的这种奖励结构下去不断的去把其他场景去接入进来然后这个东西是一个他们主要做的是跨领域的问题然后对于FDE来讲他就是把一个个需求接回来就好了它其实是一个T字型的结构听起来咱们在非常的追求我们的这个business是要能够scale起来的一定是这样的不然的话你会变成一个就是这种比如说技术咨询服务这种全方位一体的公司然后不是说这样的公司没有存在的意义主要是说如果是用这种模式的话其实你选取客户的策略就应该选取最最最头部最最大的他一家你这一家客户就能够把你整个生命周期都cover住的对吧但是我的判断是说为什么一开始在讲的形态它其实本身就是一个分布式的市场所以说这个事你不能用中心化的思路去做它对吧如果是前者的话就是我做成那样子的话那就走Apply Compute那个路线了我们就用中心化的方式去做了这只是我们的一个观点就是其实在下半场的光谱里面它其实是非常广播的我觉得是容得下任何一个形态存在的对只是说我们选择的路径是更多的用这种奖励结构去把东北太这个场景的问题变得越来越通用因为随着你收的东西的场景越来越多其实它奖励本来是有一定复用性的有复用性就代表的可以用方法能力去解领域的一些新的问题这样的话其实我认为它是能够跑起来一个飞轮的这是我们内部的一个视角从外部视角来看对外的我们更多的定义产品的方式是需要去把我们的角色跟客户的角色以及双方的边界得划定清楚如果你划定不清楚的话你这个business就是一个非常模糊的一个东西然后我们划定的界限就是为什么要选择这种RL的这种方法Ultal URL这种方法就是它的界限就很清晰我跟客户之间传递的无非就是数据集然后回到一个更新的模型这样子其实你数据进来模型还给它我们这个管道是无状态的然后客户那里他看到的是我有我的数据拿到了我一个提升好的模型这个其实结果对大家来说都是可以接受的如果这个模型训得越来越好所以它后面需要的训练越来越少那我们是会赚的越多还是赚的越少它是分两层一层就是客户给我数据然后模型还给他这属于是应用模型这种模型如果说客户的场景它是静态的其实你可能做一次训练就够了他把这个问题都集结好就完事了但是绝大多数不是这样的绝大多数比如说我们做公益的和AVI的那种它上游来的这些需求天天都在变然后你要去做实际训练的一个原因是你需要维持应用模型的能力不要掉点如果你给一个静态的它不能去解决很多的这种变化那它就会出现掉点公益或者AVIAVI就质检对吧对对对对他们为什么会天天变呢我理解他们不是一个蛮固定的一个工作吗只是从流水线上理解是的但是实际上他的具体的case是千变万化的一直在变的因为就是我们想嘛就是这些客户接到的这些订单对吧他接到的订单需求肯定不是固定的对吧那这种一条线上的这种生产也是混杂的了解这种其实他一直在变的他不能做粗分类因为就是你做粗分类看起来他流水线是固定的你涉及到工艺和质检这种很深层的问题啊它有一点细微差别对它的结果影响都很大所以说这个场景只要是变化的就就需要用这种持续的方式来保证这应用模型始终维持在一定水平线之上你们现在去和客户交流的过程中他们应该就同时也会看其他的一些这个可能的能帮他们解决问题的提供商对吧不管是机模或者云厂商对你们遇到最多的这种就竞标的竞技对手是什么 [40:00] Yeah. 目前来说我觉得竞争还相对不是特别的多 因为我们做的domin 怎么讲呢 就它本身具备一定的壁垒 它不是一个非常开放的领域 所以我们在这些领域面临的竞争可能是一些传统的这种SARS服务商 他本来就在这个企业已经升更很多年了 那我们进去做的这个事呢 如果跟他们的业务没有冲突 那其实大家各自安好 如果有一些冲突 那可能就要谈一些这种合作的模式 And then, to do RSI, the competition is less than a few. At least in our field, it's like this. 当然其他领域就有很多了 指的具体是? 就是一些agent这种领域 比如说为什么要举那个水来水的意思 因为我觉得他是一个做的蛮成功的一个case 他就跟Harvey去合作 在法律领域其实就有很多这样的case 比如说我们去要去做类似的事情 那肯定就直面他的这个金针了吧 对啊 还是前面那个问题 我确定是不是已经回答了 就是这个SARS很难 那咱们也2B 为什么咱们就不难 当你把B段里面所有的事都做了 它就是一个很难的事 但是你看我选场景嘛 我有三条准则嘛 我就三条准则去抽象出来的 就是过滤下来之后的这个场景本身就相对来说前面比较整齐 然后再一个呢就是弊端的生意的最本质最本质的核心还是算账 对吧 你RI那个是一个很重要的点 所以SARS为什么算不清楚那个账你们为什么能算清楚 就或者你觉得你有可能可以算的比他们更清楚 呃 原因就是还是这里面引入了一个变量 就是你看那个AI时代去做这个弊端生意和Software这个时代去做这个 变量就是在模型本身上 因为现在模型还是很伟大的 对吧 它还是能解决很多问题的 只不过你要正确的去教它 对吧 然后我们做的事情就是在教模型 教会模型去把这个问题解掉 而不是说我给它提供一个这种软件式的这种固定的服务 因为这个的厚度是完全不一样的 同时它又能创造更具有RI空间的这么一个case 看待云厂商未来潜在的竞争威胁呢 因为就是他们其实好像也能做你们做的事对吧 或者说你们今天做的事最后就是在卖给客户的时候还是需要GPU CPU还是需要去找一个云厂商来配合你们部署 对那会不会慢慢的这个云厂商就是吞死掉 我觉得首先一点就是如果说这个领域大家做的多了对我来说是我很很开心的一个事情就是本来大家在RSI这个路线上都是会有自己的坚持和自己的探索的 其实它的业务是非常广的,它的目标也是非常多的,它跟模型议训练回程变成一样的结果,就是当你要做一个平台,这个平台目标是超级多的时候,你最后落起来的形态就不可能像我们这么的敏捷,以及这么的专用了。 你觉得今天的基模和多摩泰的基模,它们够用了吗?因为它们再继续进化,再有新的Sota,对咱们来说还能产生显著性的价值提升吗? 计划状态是够用也不够 就是够用呢 就是大家的宏观认知 感性认知嘛 都觉得计划很强 然后为什么说它够强又不够强呢 就是你一旦到一个生产环境里面去跑的时候 你会发现其实还要补足很多工作 他不是说这个模型API 怼到现场 然后他自己就跑起来了 他能把这个问题解的很好 所以就你们做的工作 对 我们做的工作就是这里面的很多很多的工作 我们也尝试就找到这种相对收敛的一个路径 因为其实你解决这个问题最直接的方法就是铺人嘛 对吧 你啥不好人去补嘛 对 但是这个方向 我只是觉得它不太那个 就是不太可扩展 所以说我们去扩展的方法 就是在初期用一定的人工 去把奖励网络构建起来 那其实你在去扩展的时候 就相对来说 它会是一个更好的形态 构建奖励网络 你们有一些什么样的方法论 或者窍门吗 其实它就是在模态上要统一 就是这是最重要的一个点 就是你跨模态之间去构建的话 是有难度的 是有很大的挑战 因为完全不一样 对 去在同一模态下去做总归还是有迁移性的 还有一个问题刚刚呃您提到的就是关于积动模型的演进 对吧 为什么我们 I think it's a long time to go to paradise. I think that all the AI teams are in the world, I think that all the people in the world are in the world. I think that all the people in the world are in the world. I think that all the people in the world are in the world's base. [45:00] 对吧这个其实是一个他俩这种问题他对这种后训练的依赖是没有变的为啥我们说是面向需求的就是你从需求侧才能拿到这种有效的这种场景级的奖励然后拿到场景级奖励你要去训一个work model还是训一个base model是不是由科夫来选的如果说未来出现一个客户说我就想把公寓问题做一个私有模型来解也可以这是他的选择我们只是从大的范围来看很少有人会选择这么搞我或许未来会有一家公司或者一个地域说我要做主权模型我就把扣你问题要重做一遍可以的我们面向需求需求才是我们的驱动员我们最后聊点轻松的创意到现在最有成就感的一件事情或者一个时刻大概是什么我其实觉得近期我跟我的CTO friend我们去讨论就是PyroDash架构的时候其实一开始我们的观点也是不一样的然后我觉得最有诚感一点就是我们打成共识那一刻吧你说服他还是他说服你啊不存在说服吧就是我们很开放的就是大家其实在论证这个事我们其实那部论证有很多嘛就是有的时候就是直接关小黑屋然后去论证论证这个事情包括巨神领域我们也论证过对吧就这种论证我觉得是非常受益的就是大家大家从不同的视角去看这个事情然后打成共识那一刻感觉很有成就对是的这其实就是为什么我很喜欢去跟大家一起去聊这个事情就是本身大家不同的视角进来自带奖励信号的然后你这种多目标的奖励信号下提炼出来这个结果它有可能就离真相很近了对这个时候觉得比较有成就感的你自己平时会用哪些AI产品啊最近啊我觉得就是Coning的多一点比如说PIPi这种Coning Agent就是一个极简的Agent这就是蛮好的包括DSHDSH还是很屌很屌的对吧这个已经是堪比历史上这个STARS增长是快的项目之一了应该十四五万了吧我们录播客这个时候才三天是的是的你喜欢有什么模型你现在的此刻有一些偏好吗我之前反正就在Cloud上面去搞搞然后近期的话就是KimiKimi有了就还是很强的然后前段时间就GM出来的时候也会去搞然后另外就是现在前文系列前文系列其实从我们从Huggy Face上那个数据来看他最近14号不是发了一个报告吗就是前文在实际的运行室里面下载量还是蛮高的也成为了一个用量比较大的一个模型了包括千万3.827B这个小模型我觉得它反向也非常好是的Hinebase那个报告其实还有一个数字挺有意思的他看到这种local类的模型下降量基本是100B以上的下降量是很小的基本100B以下占据了3.8的主流这说明什么问题说明就是说我们去搞Pairadish这个架构其实方向上我觉得和社区认知识也是相似的还会去下载这些小的模型去做所以说这就说明了这个需求世界它是多元的它不是所有需求都要归拢到一个大的base model上来统一的这样去解决掉的依然Hanford上依然有海量的小模型下载量就代表有大量的需求是需要用分布式这个形态去解决的所以我们在这个时间点去推这个paradise我觉得也是一个非常正确的一个时间点OK好那最后一个问题就是米歇最期待达成的下一个mildstone是什么我觉得下一个Milstone就是最重要的吧就是说PairDash能够获得社区最主流的一个认可就是这个形式因为认可的Milstone衡量基准可以去看看它在生产场景里面是不是真的解决了一些困境的问题不光是benchmark因为这毕竟是我们长期看的方向对因为中期和短期看的方向我们现在已经验证的还比较好了对了ok对好呀谢谢凯文好的感谢感谢ok好我们今天先到这里拜拜