跳转到内容
logo logo 知识库

质朴发言：从 GPTs 聊到 Agent、LLMOps 以及开源的新机会｜Z 沙龙第 1 期

原文链接：https://mp.weixin.qq.com/s/h6LkRp3xpFfAA3ml6l3olA

来源：质朴发言

发文时间：2023.11.17

上周 OpenAI 举办了 DevDay，并公布了 GPTs 等系列新动作。作为当前大模型领域最头部的玩家，OpenAI 的大动作，总能引起圈内热议。

围绕 GPTs 以及由此搅动的大模型产业格局，尤其是应用层创业的生存与发展，我们开展了研究跟进，准备好了认知，不能埋头苦干，决定在周六找朋友们小聚一下。

本文不代表智谱认同文中任何观点。为鼓励自由发言，我们也暂时不披露参与者个人信息，不做流水账，抛开敏感信息，分类整理如下。后面继续办，一起来聊！🌊

🏆

以下为本文目录，建议结合要点进行针对性阅读。

一、Agent

  1. 什么是 Agent？具备什么能力？
    1. 观点一：狭义的 Agent，由 OpenAI 定义
    2. 观点二：广义的 Agent，具有基础智能、角色管理、技能调用、复杂思维、及未来更多的可扩展性
  2. Agent 在 B 端的落地到底情况如何？
    1. 观点一：设想与现实之间的gap有多大？人和大模型长期共存
    2. 观点二：在 Autonomy Agent 或 multi-agent 成熟之前，大模型应从“对外业务”和“简单功能”切入To B服务
    3. 观点三：大模型要做专家知识，还是通用知识？
    4. 观点四：人机边界识别，工程落地能力，基座模型能力，并驾齐驱，同样重要
  3. 未来可能有机会的方向

二、在 DevDay 之后，国产大模型和 OpenAI 之间的差距是扩大了还是缩小了？

三、AI LLMOps及开源社区

  1. OpenAI 对 AI Ops 的态度如何？
    1. 观点一：中间件挡住了 Open AI 的数据飞轮，注定会被吞没，开源中间件是在帮助 OpenAI 打磨产品
  2. 那么，什么形态的 AI Ops 会/不会挡住 OpenAI 数据飞轮？
    1. 观点一：哪些 AI Ops 会挡住 OpenAI 数据飞轮
    2. 观点二：哪些 AI Ops 不会挡住 OpenAI 数据飞轮
  3. AI Ops 公司们应该怎样调整入场姿势？
    1. 观点：OpenAI 进行“绑架”，自然会有反向要求解绑的需求
  4. Agent 框架的 2 种设计思路：功能导向和行业应用导向
    1. 观点一：Agent 功能导向，更适合以大模型厂商为主导的闭源模型
    2. 观点二：行业应用场景导向，更适合开源模式

四、开源和闭源商业模式之争

观点：OpenAI 选择闭源模式为时尚早

#一、关于 Agent

1、什么是 Agent？具备什么能力？

观点一：狭义的 Agent，由 OpenAI 定义

“Agent”一词虽然早在马文·明斯基、Russell 和 Norvig 等知名学者的著作中出现，但在大模型时代，OpenAI 重新定义了这一概念。Lilian Weng 在其个人博客中对 Agent 的主要功能进行了详细描述，提供了一个更为精确的定义。她指出，狭义上的 Agent 具备技能调用（Tool use）、记忆（Memory）和规划（Planning）能力。

推荐阅读：Marvin Minsky 的两本著作：《心智社会》和《情感机器》。Lilian Weng 文章：https://lilianweng.github.io/posts/2023-06-23-agent

观点二：广义的 Agent，具有基础智能、角色管理、技能调用、复杂思维、及未来更多的可扩展性

广义的 Agent 可以在 Lilian Weng 提出的 Agent 的基础上进行扩展，具有基础智能、角色管理、技能调用、复杂思维，及未来五感集成能力：

  • Agent 的基础能力，包括常识推理、逻辑性等，来源于大模型提供的基础智能。所以我们对 Agent 这一层能力的设计，本质上都是对模型的优化。如果要改进 Agent 在这一方面的能力，通常需要更换或优化底层模型。
  • Agent 的角色扮演、情感理解和身份相关能力，与其记忆和拟人化角色设定的 Prompt 工程紧密相关。这部分称为“角色管理”，涉及到如何让 Agent 理解并扮演特定的角色或身份。
  • Agent 的技能调用能力，如编程、查询、绘图等，依赖于 Agent 之上的插件。OpenAI 的“Function calling”机制是一个经典的实现方 式，允许 Agent 调用外部的功能和资源。
  • Agent 的复杂思维能力，在基础智能之上，大模型通过人们构建的思维链、思维树等方式，学会更高层的思维方式。这种方法教会模型特定的模式或思维方式，从而提高其处理复杂问题的能力。

在未来，Agent 还会具备更多的可扩展的空间。就 Observation 而言，Agent 可以从通过文本输入来观察来理解世界到听觉和视觉的集成；就 Action 而言，Agent 在具身智能的应用场景下，对各种器械进行驱动和操作。

总而言之，Agent 是以核心智能模型来驱动的，一个可以具备能力从思考开始，最终做到完整输出的智能性结构。Agent 的发展很符合第一性原理，从最先的 Prompt，后面有人在写完的 Prompt 后面加通用的规划器。

再到 COT 和 TOT，其实也是 Agent。再后面 AutoGPT 火了之后，一些公司如面壁出了双循环的 Agent，其实是在 AutoGPT 基础上的演化，包括“斯坦福智能体小镇”。这些都证明 Agent 更像是大模型的超级版。

2、Agent 在 B 端的落地到底情况如何？

观点一：设想与现实之间的 Gap 有多大？人和大模型长期共存

目前已成熟的方式

  • RAG + 知识问答 + 语音条，目前是比较容易获得订单的方式。
  • 主要场景时替代掉传统客服或者对内做培训的知识库。
  • 可以开发点击鼠标等动作的 RPA ，搭配 RAG 的系统，方便现场 demo 演示。

路径设想

  • 如果用 AutoGen 搭一个框架，多个 GPT 可以共同发挥作用。这是最笨但最符合第一性原理的方案。
  • 或者当模型能力进化到一定程度，Agent 的能力不再趋同，可以单一模型实现从理解需求到落地

实现难点

  • 包括 GPT-4 在哪的很多测试，并不具备 planning 的能力，只能 plan 模型学过的知识库里的东西。
  • 比如在金融行业场景中，模型没有学过诸如“供求关系分析”“一致预期”“投资逻辑”等文本，因此根本无法做到这样的 planning，包括 action。

我们发现，面对更深层次的用户需求：就需要一个产品经理，将问题一层层拆开，拆分成每个分析师独立的观点是什么和汇总的综合观点是什么。所以未来很长时间是人与 GPT 同时存在的状态，并非 GPT-4/GPT-5 可以独立全部解决。人类的产品经理扮演很重要的角色，可能是类似过去 SaaS 的流程规划过程。

比如模拟今天沙龙的一个对话场景：三个 GPT 同时使用，一个主控制意图，一个是要把对方引导到某种推荐的概念，第三个是回答问题。GPT-4 做的都不是很好，只有把人类的规划引入进去后，第一次跑通后再用 GPT 进行执行。所以落地的主要 Gap 是培养一个理解需求并且懂得大模型的产品经理的一年时间。

观点二：在 Autonomy Agent 或 Multi-Agent 成熟之前，大模型应从“对外业务”和“简单功能”切入 ToB 服务

  • B端能落地的业务都是普通人能通过一小段时间和成本以及一些输入就能习得的。对应到企业场景，可能是：财报，供应链管理等。业务对外的信息管理，可能最先作为大模型服务的辐射范围（如产品入库记录，物料管理，合同管理）
  • 供应商有限数量时，尚且可以轻松进行流程梳理。但当面临一些供应链复杂的巨头/独角兽公司业务的时候，不太可能用 GPT 解决。
  • 目前可能还没有到解决 Autonomy Agent 或 Multi-Agent 能力问题的时候，因为我们 Agent 实现的单次请求及回复的“原子颗粒”都还没有达到一个很好的状态。
    • 把私有领域知识训练在一个私有的模型里面或直接去训练一个小模型解决这个问题（这种解决问题的语料也可能不存在）
    • 构建请求链：把问题拆解细分到 Agent 能解决的问题。
    • Multi-agent 的协同前提条件是多样化，如果没有解决这个问题，相当于多个 Agent 在同自己对话，就会出现价值观与角色趋同问题。
    • Autonomy 问题，预训练的通识性模型无法解决，通常要解决这个问题有两种思路：
      • 把私有领域知识训练在一个私有的模型里面或直接去训练一个小模型解决这个问题（这种解决问题的语料也可能不存在）
      • 构建请求链：把问题拆解细分到 Agent 能解决的问题。

观点三：大模型要做专家知识，还是通用知识？

  • 专家知识派：大模型 application 落地做隐性知识，甚至是过往没有明文方法论记载的，更多的是隐性的知识，比如如何思考投资决策，一个分析师如何草拟一份报告。解决这类 know-how 的 To B 企业，随着大模型功能的不断完善，未来会有越来越多的机会。
  • 通用知识派：以投资机构为例，对于一件事情的认知，本来就是构成其业务壁垒的一部分，所以信息不对称对于这些“专家知识”更重要。投资机构不会分享其由信息不对称造成的核心优势，电池制造商也不会公开其材料、组装和工艺流程等核心信息。B 端的数据敏感且难以获取，而仅靠公司内有限的私有数据又很难构建出多样性的 Agent。因此多样化的 Agent 很难实现，这也意味着，在金融、高端制造业等 B 端行业中，复杂的 Agent 系统的落地面临很大的挑战。

画外音：Agent 在 B 端落地的问题，本质上是 Agent 先代替哪一类工作的问题——是先代替培养成本高的高精尖的专家还是代替较为通用型的岗位，还是说把其当成实习生，需要 Mentor 和实习生一起干活？就目前来看，单一 Agent 无法很好地完成复杂的 B 端业务，这可能意味着目前 Agent 的落地需要在“通用的复杂任务”和“专业的简单任务”中做取舍。

观点四：人机边界识别，工程落地能力，基座模型能力，并驾齐驱，同样重要

  • Agent 开发过程中，任务拆分和划分人机边界同样重要。比如在工程中需要教会 GPT 用户的思想，在写论文的时候，如果与 GPT 同步了每一段要表达什么，甚至每一句话的核心观点，那样的呈现比只表达“要写一篇什么样的论文”精确得多。（通过 RAG 将知识串联起来，最终形成完整论文）
  • 大模型落地的工程能力和基座模型自身能力同样重要。很多企业要求性能从60分到90分，有很高技术门槛，要求微调等等。国内的大模型厂商很多缺乏这方面行业实践能力，将行业能力与自己的底座模型进行适配是一个工程学问题。当然，基座模型的性能本身同样重要。

3、未来可能有机会的方向：

  • 上一代AI 1.0 的四小龙更多不是平台而是解决方案，这次大模型趋势更像是搜索引擎：需要工程能力，科研能力，用户数据，及大规模资本投入。因此大模型赛道入门门槛高，不适合初创公司。
  • RPA 技术服务昂贵，GPT 对接 OA 和 ERP 软件的中间件，比如 GPT+SQL 的成本很低，目前在做的人也很多：大模型可以让 SaaS 及 RPA 更加低成本，更加 General，更加易得。
  • 大学生招聘等教育行业场景下，了解岗位介绍和定义、政府面向企业回答的政策咨询问题，这样更广泛定义下的机构化服务。需求迫切，且机会很多。
  • 类似 Zapier 可以连接各种各样工具，并实现客户业务协同的。或者在数据收集阶段，将客户业务数据用虚拟数据处理一遍。后面延续同样逻辑替换为客户自有数据的，这样满足客户保密性的应用。
  • “先摘容易摘的果子”，过往深耕某些垂直领域的知识图谱类和 SaaS 公司转型，将过去传统模型替换为大模型，更易实现。总体行业还在早期。

#二、DevDay 之后，国产大模型和 OpenAI 的差距进一步扩大了吗？

首先，我们观察到一个现象：开源社区对模型底层和算法层的影响有限，技术门槛和数据回流并不顺畅。在GitHub 上，最受欢迎的是偏向应用层的项目，例如 UI 项目。

从而，我们需要考虑大模型算法的生态，上层中间件的生态，以及在 OpenAI 发布会后对 AI Ops 的看法。

当我们抛出这个问题时，现场出现了戏剧性的众说纷纭：

支持“缩小”的一方：某 Agent 开源框架创始人提到，DevDay 发布的内容很早之前就被开发者复现了，是可预测的路径。从这个角度来讲，国产大模型和 OpenAI 之间的差距在缩小。

支持“扩大”的一方：某 VC 投资人认为，从模型能力的角度，OpenAI 选择公开的是数月之前的成果，始终保持着巨大的时间窗口优势；从生态搭建的角度，OpenAI 的动作远远领先于其他厂商，或将占据更多的用户时长、更丰富的数据、更多的应用开发者，进一步放大马太效应。

#三、AI Ops及开源社区

1、OpenAI 对 AI Ops 的态度如何？

观点一：中间件挡住了 Open AI 的数据飞轮，注定会被吞没，开源中间件是在帮助 OpenAI 打磨产品

目前中间件大多是开源社区在做。然而，中间件的开源不是一个自愿的选择，因为当其核心用户是开发者时，开发包的源代码需要开放让开发者理解，这是开发者能使用它的基本前提。

但是站在 OpenAI 的视角，开源社区明面上是在帮助 OpenAI 完善功能，其实是挡住了 OpenAI 的数据飞轮，而数据飞轮是目前 OpenAI 最看重的东西之一。

因此，为了强化这一优势，OpenAI 在 DevDay 之后实施了一系列策略，从以下两点可以窥见一二：

1）强制要求大型模型以 JSON 格式返回数据，并为 Call Functions 和 Code Interpreters 设计了不同的接口。这些措施的主要目的是为了区分各种应用场景，从而能够精准收集高质量数据，进而形成有效的数据飞轮。

2）一个带状态的 Assistant API，为我们展示了 OpenAI 的思考方向：为什么要再一次请求的时候必须做直接的响应？为什么不能在中间加入复杂的状态机做流转？我们推测 OpenAI 在模型层之上封装了两层框架，而这么做的目的可能是为了杜绝潜在的暴露可切换模型的底层设计框架——他们希望把模型层和框架尽可能的保留到一起，增加用户的切换成本，将用户绑定在 GPT 模型上，以形成数据飞轮。

同时，OpenAI 本身具备模型层最深度的 Know-how，因此，“开发框架+模型”一体化融合，将会是 OpenAI 在AI Ops 层日益清晰的方向。

2、什么形态的 AI Ops 会/不会挡住 OpenAI 数据飞轮？

观点一：哪些 AI Ops 会挡住 OpenAI 数据飞轮：

  • RAG：现在的 RAG 还相对原始，易用性有提升空间
  • 兼容性、易用性、效率等维度做得还不够极致的 Agent 框架，如 LangChain、llama_index 等

观点二：哪些 AI Ops 不会挡住 OpenAI 数据飞轮：

  • 提供一些小而重要的开发工具
  • 提供 OpenAI 看不上的数据（通用性不够强且持续变化的数据集，本质上是 ROI 低且蛋糕太小，所以 OpenAI 看不上）
  • 完全脱离于 OpenAI 体系，为 OpenAI、Anthropic 等闭源模型厂商的开源竞品提供服务，帮助这些竞品构建自己的数据飞轮。这类似于在操作系统领域，除了 Mac 和 Windows 这样的闭源系统之外，还为 Linux 这样的开源操作系统提供支持，满足不同用户群体和市场的需求

3、AI Ops 公司们应该怎样调整入场姿势？

观点：OpenAI 进行“绑架”，自然会有反向要求解绑的需求

中间件的生存空间很大程度上依赖于基座大模型最后的竞争格局。尽管 OpenAI 目前在提供模型服务上拥有主导地位，但市场仍然可能是分散的，因为数据是分散的，客户的需求是分散的。并且从地缘政治角度而言，大概率世界上会存在多个大模型。

那么，应用层与模型层解耦、无缝切换的需求就会在，中间件就变得尤其重要，因为它们可以帮助开发者无缝切换不同的模型服务，而不需要对每个模型都进行深入的研究和开发。同时，作为贴近开发者的中间件，其机会将存在于开源社区，因为中间件可以有话语权，告诉客户们应该用什么模型，中间件的角色从从贴近模型层变成贴近客户需求。

放在我们通往 Agent 实现之路来看，OpenAI 现在的趋势是希望够将所有模块变为一体，而开源社区希望把一体的东西揉碎，都变得可插拔，以形成多样化多能力的 Agent。目前情况下，多样化的 Agent 实现目前可以在两个不同的地方做区分，一是记忆管理系统上的差异，二是为多次请求设计的 COT。

4、Agent 框架的 2 种设计思路：功能导向和行业应用导向

观点一：Agent 功能导向，更适合以大模型厂商为主导的闭源模式

如果可插拔的模块是 Agent 的功能导向的，即：首先把 Agent 功能定义出来，然后再往基于这个往上去做，逐渐把 Agent “场景化”。

这种方案，尽管 API 调用简单，产品设计理念易于理解，开发风险低，但它做出来的框架是比较“薄”的，创业公司实际上在为 OpenAI 铺路，容易被 OpenAI 抄袭和超越。

例如，先做一个很基础的 Chat Agent，然后在这个 Chat Agent 基础上“搭积木”。例如，添加 critical thinking 实例使得这个 Agent 聚焦于 critical thinking；或者添加 planning 实例使得这个 Agent 聚焦于做计划。

优势：API 调用简单，产品设计理念易于理解，开发风险低。

劣势：框架比较“薄”，创业公司实际上在为 OpenAI 铺路，容易被 OpenAI 抄袭和超越。

观点二：行业应用场景导向，更适合开源模式

如果可插拔的模块是以行业应用场景导向的，其核心竞争力在于把不同行业的管理理念和 Agent 的记忆管理高度融合（比如情感陪伴的记忆管理和这个教育记忆管理的方案就会有很大差异）。

优势：API 调用简单，由于和特定行业 Know-how 结合很深，故较难被 OpenAI 抄袭，且对于一些小而美的行业，OpenAI 不会倾注资源去开发。

劣势：开发风险较高，需要很深刻的行业认知才能精准定位需求，否则难以找到 PMF。

#四、开源和闭源商业模式之争

观点：OpenAI 选择闭源模式可能为时尚早

一方面，OpenAI 在 DevDay 的战略举动引人注目，让人不禁联想起 2010 年附近的互联网。

逻辑：使用门槛高->用户增长乏力->降低用户门槛，例如做 GPTs Store（UGC），确实使用频次上升（提升对话轮数）

  • 数据飞轮：通过观察数据，了解市场需求，扩展模型的想象力，探索边界
  • 商业模式未定，但现阶段的想象力很重要；GPTs -> 小程序 -> Agents

但另一方面，OpenAI 的商业路径可行性仍任重而道远

OpenAI 大刀阔斧式地构建闭源生态的时间节点可能为时尚早，面临较大的商业风险，主要体现在以下方面：

  1. OpenAI 目前留给中间件开发者的空间太小了，这样激进地定义自己的闭源生态的行为可能操之过急，反而会倒逼开源生态的繁荣
  2. 此外，由于大模型的商业模式尚未得到验证，OpenAI 过早地闭源可能会主动放弃掉未来很大一部分蛋糕，最终丢掉相当大的市场给开源模式
  3. 移动互联网时代的商业模式并不能简单套用在大模型时代的公司，因此 GPTs Store 的商业模式待验证，仅仅是 OpenAI 在商业化上的一次尝试，远未形成行业范式

因此，顺势而为，我们相信 AI Ops 创业者仍有很大机会在开源模式中找到自己的生态位。🌊

文中专业词汇注释

  • Agent：参见文章第一部分
  • Prompt（提示词）：引导AI系统生成特定输出的一系列词语或指令。
  • DevDay：OpenAI 在当地时间 11 月 6 日举办的发布会
  • COT（Chain of Thoughts）：思维链，一种模拟人类逻辑和推理过程的推理框架，能够帮助大语言模型解决复杂的算术、常识及字符推理等任务。
  • TOT（Tree of Thoughts）：思维树，一种模拟人类逻辑和推理过程的推理框架，允许语言模型通过考虑多种不同的推理路径和自我评估选择来进行深思熟虑的决策，以及在必要时向前看或回溯以做出全局选择。
  • Autonomy Agent：理想状态下能够在没有外部干预的情况下自主作出决策和执行任务的AI系统。
  • Multi-Agent：多个AI代理共同工作，相互协作或竞争以完成复杂任务的系统。
  • UGC：用户生成内容，指用户创建并分享到网络平台上的内容，如社交媒体帖子、视频、博客等。
  • PMF：产品市场契合度，指产品成功满足市场需求的程度，是判断创业成功的关键指标。
  • RPA：机器人流程自动化，是使用软件机器人或AI来自动化重复的、基于规则的业务流程。
  • RAG：检索增强生成（Retrieval Augmented Generation），通过在生成响应之前从知识源检索相关信息来增强LLM的能力，适合需要查询数据库、文档或其他结构化/非结构化数据存储库的应用程序。
  • ERP：用于管理和整合公司的财务、供应链、运营、报告、制造以及人力资源活动的软件系统。
  • AI Ops：面向开发者的，构建和部署AI应用所需的基础结构和工具