博文视点
进入AI 2.0时代，大模型技术将给产品设计与实现带来怎样的变化？基于这种变化，又催生了哪些新的产品形态？

趋势变迁

在移动互联网时代，一个移动App的功能特性及核心依赖其操作系统，但二者的关系不大，操作系统是关键约束，投入成本和App价值点都集中在App本身，如图1（a）所示。在大模型时代，大模型的核心能力受限，呈现出类似“卷心菜”的应用结构，App本身的形态价值逐渐萎缩、投入成本占比也急剧下降，如图1（b）所示。

图1 “卷心菜”的应用结构
这一现象引起了广大开发者的关注，应用开发从以建模为中心向以应用构建为中心转变。LangChain等应用开发框架获得了开发者前所未有的关注，甚至整个大模型应用开发的过程都围绕这些框架展开。
业内存在一种推断，未来的大模型应用都可以运行在以大模型为核心的操作系统上。图2所示为大模型操作系统结构，大模型相当于CPU，而大模型的上下文窗口相当于内存，向量数据库等存储相当于硬盘，浏览器相当于网络，音视频相当于I/O设备，计算器、代码解释器等相当于操作系统上的系统软件，可被调用。

图2大模型操作系统结构
大模型应用就是在此操作系统上构建的应用，大模型应用开发相较于传统的软件开发也有较大区别，如图3所示。

图3应用组织结构变迁
发生这种变化的核心原因在于传统的软件开发只与代码有关。对于一个传统的软件开发过程，只需要产品经理定义好需求，开发人员按照需求编码实现即可。确保App达到预期质量的方式也比较简单，就是严格全面的测试。另外，传统应用的特性不会随外界的变化而变化，它的逻辑都被固化在代码中，只要代码（包含环境）正确，应用就正常。因此，在DevOps时代，开发质量的核心就是保证开发代码到生产代码的一致性，相关技术也围绕这一目的展开，典型的例子就是Docker。
到了AI 1.0时代，AI应用已经从单纯的代码变成为代码、模型和数据。因此，一个AI应用是否达到预期质量，不仅与代码实现相关，更受到模型和数据的影响。另外，由于传统小模型本身的特性，其能力是单一稳定的，因此代码与模型的能力边界是相对清晰的。同时，由于概念和数据漂移需要高频训练，小模型无法实现一次训练多次使用的目标，因此在这一阶段除关注传统软件开发的问题外，还需要做到从模型训练到推理的正确性，消除其中的不一致，而这正是MLOps关注的重点。
现在，进入大模型应用时代，大模型具备几个核心特点，导致了开发范式的再度迭代。相较于传统的小模型，大模型最大的特点在于它具备一定的通用性，通过提示就可以完成不同的任务。同时，大模型的性能表现和训练微调成本使模型训练变成了一个低频动作，普通开发者无须自己训练模型，只需要不断地升级替换更强大的模型即可。这样就引发了一个问题：代码和模型的能力边界是不稳定的，大模型的每次更新都将是外围代码的灾难。操纵大模型实现某个功能成本极低，可能只是提示（自然语言）的调整，更重要的是，随着整个应用的闭环，一些固定策略代码的效果远不如不断自我完善的模型。但大模型有自身的问题，比如其输入输出的自然语言特征存在天然不精确的问题，导致系统不稳定。
可以看出，这一切的变化来自大模型独特的构建模式。通过提示，可以让大模型完成各种不同的任务。从传统的自然语言处理任务，如情感分析、对话系统，到大模型特有的逻辑推理，不一而足。正因如此，从DevOps、MLOps及LLMOps的边界关系可以看出，MLOps到LLMOps的应用开发方式转变，来自以数据为中心的模型训练推理的闭环构建，向以微调模型为中心的应用构建转变，如图4所示。

图4 DevOps、MLOps及LLMOps的边界关系
因此，当下LLMOps关注的重点不再是模型训练推理本身，更多的是如何更好地围绕模型构建应用。而在这个时候，处理好代码做什么、模型做什么的边界问题就变得尤为重要，将有限的精力投入正确的地方，以及充分理解大模型的特点，扬长避短，才能开发出一款优质的大模型应用。

产品形态

根据大模型特点，从技术实现和产品复杂度上来看，产品形态由简单到复杂可以分为对话机器人（ChatBot）、智能助手（Copilot）、智能体（Agent）和多智能体（MultiAgent）。
1.对话机器人
对话机器人是一种模拟与人类对话的人工智能系统，能够与用户进行自然语言交流。它们可以应用于客户服务、在线教育、娱乐互动等场景。高级的对话机器人还具备记忆能力，支持多轮对话，达到流畅的对话水平。例如，ChatGPT可以生成连贯的对话，回答用户的问题，甚至模拟特定角色进行对话。
2.智能助手
智能助手是一种能够为用户提供实时帮助和建议的应用，它基于大模型进行训练，可以理解用户的需求和意图，并提供相应的指导和建议。相较于对话机器人，智能助手具有调用工具的能力，能够根据用户任务指令调用不同的工具完成任务。智能助手可以应用于编程领域，为开发人员提供代码补全、错误修复和最佳实践等方面的支持。智能助手能够理解上下文，并生成准确和实用的建议，提高开发效率和质量。例如，Code Copilot——GitHub Copilot，它集成了GPT-4模型的能力来帮助开发者编写代码。智能助手可以根据开发者输入的部分代码或描述，自动补全代码片段，提高编程效率。智能助手适用于多种编程语言，能够理解代码上下文并提出合理的建议。
3.智能体
在人工智能领域，智能体是指能够感知环境，做出决策，并执行行动的实体。大模型可以作为智能体的核心，处理复杂的任务。相较于智能助手，智能体可根据某一确定性的目标自主分解计划任务并完成，如自动驾驶汽车中的决策系统、智能家居中的语音助手等。这些智能体能够理解用户的指令，执行相应的操作，并在必要时做出决策。
4.多智能体
多智能体由多个智能代理共同组成，这些代理可以相互通信和协作，共同完成任务。在大模型的辅助下，多智能体系统可以应用于更复杂的场景，如城市交通管理、机器人团队协作、在线游戏的NPC（非玩家角色）行为模拟等。相较于单一智能体，多智能体提供了环境支持指令体进行通信，每个智能体可以拥有自己的角色和目标，通过协调和沟通，实现整体的最优解。该方向也被认为是大模型应用的终极形态，通过它可以完成一个团队甚至一个组织的工作。
直观来看，大模型的能力边界越来越大，从回答单一问题，到辅助人类工作，再到独立工作，逐渐变得强大。而在应用领域层面，要让这样的产品落地，关键问题是如何影响模型，也就是改变模型原有的概率分布，使其能够更好地适应所在的行业，而手段就是灌入领域知识，并对齐行业任务指令，教会模型理解要做什么，进而学会如何做。这一点和一个员工进入一家新公司、一个新行业一样，员工首先要理解这家公司和这个行业的背景、知识和流程，才能执行任务，以及做正确的事情。

技术实现

1.对齐方法
预训练的大模型只具备续写能力，无法直接为人类完成具体的任务，比如翻译、总结等。从某种意义上讲，人类一直在寻找合适的手段让AI模型遵从用户指令，进而更好地服务人类，这一过程被称作对齐（Alignment）。往更高层次讲，大模型不仅应该遵从指令，还要符合人类偏好和人类价值观。可以想象，这一过程是非常具有挑战性的。对齐的方法随着模型能力的发展也在发展。通过提供必要的标记样本，告诉模型遇到什么样的问题应该采用什么样的方式回应，以便有针对性地对其进行训练，帮助它学会相应的任务。随着模型能力的不断提高，人类可以通过自然语言的方式操纵模型完成下游的各种任务，这一过程被称为上下文学习。更进一步地，我们希望大模型的输出更符合人类的偏好，于是引入了基于人类反馈的强化学习，让人类对大模型生成的答案进行偏好打分。随着大模型能力的不断提高，人类在某些方面已经不如AI模型，也无法评价模型输出内容的好坏。我们甚至无法避免AI不受人类控制，做出不符合人类价值观的事情。因此，OpenAI提出了“超级对齐”的概念，即使用较弱的模型来监督和管理更强的模型。
可以说，大模型应用开发是围绕“对齐”展开的，通过优化模型性能或者增强产品功能的方式，最终目标是满足用户的需求。在实际开发过程中，指令微调和上下文学习都能对模型产生影响，因此，我们将重点围绕这两项技术展开介绍。
如图5所示，通过改变模型本身（模型结构和权重），可以影响模型输出，即微调；通过影响模型的输入（提示），可以影响模型的输出，即上下文学习。

图5 通过指令微调影响模型
1）微调
为了便于理解，可以将模型看作知识和能力经过压缩后的产物。经过微调的模型包含了学到的知识、逻辑，以及执行具体任务的能力。但是，由于模型比较重，训练和更新需要大量的时间和成本，导致出现模型的知识更新不够及时、变更困难、难以控制、能力扩展难度高等问题。
微调（Finetune）是一种常见的改变模型的方式，它是指在已经预训练好的大规模深度学习模型基础上，使用特定任务数据集进行进一步训练和调整的过程。通过微调，可以将预训练模型的知识和表征能力迁移到特定任务中，以提高模型在该任务上的性能和效果。微调通过调整模型的参数和学习策略，使其更加适应目标任务的需求，从而在特定领域或问题上获得更好的表现。这种方法可以节省训练时间和数据，通常比从头开始训练模型更有效。大模型的微调已经在自然语言处理、计算机视觉等领域得到了广泛应用，为各种任务带来显著的帮助。微调影响的是模型的权重。
2）上下文学习
提示可以看作知识和指令的混合体，类似于AI 1.0的判别模型。提示相当于特征输入，因此AI 2.0将特征工程晋级为提示工程。特征工程决定了模型的上限，从这个角度来看，提示的重要性可见一斑。提示可以给大模型不举示例直接表达需求（零样本），也可以给它一些示例（少样本）来解释需求，还可以一步步教它思考（思维链）以共同完成任务。此外，还可以给大模型一些上下文信息，帮助它理解问题和回顾历史。提示以其文本的特点，天然具有很好的灵活性和透明性，能够轻量级地完成一些看似神奇的工作。然而，受限于大模型的上下文窗口、性能和成本，提示的大小是有限的。此外，由于每次请求都需要携带大量信息来维持状态，因此提示在性能方面也存在一定的不足。
需要注意的是，上下文并不限于例子，还可以是提供给大模型参考的背景信息，或者状态信息。需要特别提出的是，常被提到的大模型记忆（Memory）也可以被视为一种上下文信息。实际上，大模型记忆就是将多轮会话信息作为提示的一部分提供给大模型，这样大模型就能够知道前面的内容，进而间接地拥有记忆功能。
下面是一个让大模型记住过去对话内容的例子。
The following is a friendly conversation between a human and an AI. The AI is talkative and provides lots of specific details from its context. If the AI does not know the answer to a question, it truthfully says it does not know.
Current conversation:
Human: What’s their issues?
AI: The customer is having trouble connecting to their Wi-Fi network. I’m helping them troubleshoot the issue and get them connected.
Human: Is it going well?
AI: Yes, it’s going well so far. We’ve already identified the problem and are now working on a solution.
Human: What’s the solution?
AI:
2.优劣势比较
1）优势
在实际的应用开发中，通常优先考虑采用开发和优化提示的方式来实现需求。因为相较于微调，上下文学习具有以下优势。
（1）更轻量。从模型的知识角度来看，一个模型的知识来自它的预训练和微调过程。然而，由于这两个过程的成本较高，很难实时进行，导致模型的知识会过时。例如，ChatGPT只知道2021年9月之前的事实。通过上下文学习，模型可以实时获取知识，成本几乎为零。另外，模型微调需要大量的标注数据，而标注问答对本身就是一项繁重的工作。相比之下，精心构造上下文示例要容易得多。
（2）更灵活。微调的方式是为每个任务训练一个模型，这就导致了它缺乏灵活性。虽然后来出现了类似适配器（adapter）的机制，对原有架构进行了改进，但总的来说，与简单修改提示相比，复杂度完全不在一个级别上。
（3）更可控。对于大模型而言，让其理解行业知识的方法之一是通过微调以问答对的方式注入知识。这种方法虽然可以改变模型的概率分布，提高零示例情况下的效果，但并不能直接约束模型是否使用这些知识，也很难进行精细的操作。另一种方式是将知识以上下文的形式放入提示中，让大模型仅基于提示中的上下文背景信息进行推理。从信息来源的角度来看，这种方式更加可控。
（4）更经济。微调的成本远高于推理的成本。此外，微调还有潜在的流程和技术要求，增加了使用的成本。
可以看出，上下文学习将成为未来训练大模型的首选方式。基于上下文学习，还衍生出了许多大模型应用的架构。可以说，提示是大模型的灵魂，一切应用都围绕着它来构建。然而，微调本身也具有价值和适用场景，它能够针对特定领域和专有任务进行专门的优化，在一些垂直领域能够显著提高模型的性能。而模型本身已经学习了任务的范式，无须受限于上下文窗口的长度，因此可以减少重复的标记，完成更多可能的任务。
2）劣势
虽然上下文学习有诸多优势，但它本身也存在一些劣势。一方面是结构性的问题，另一方面是发展阶段的问题。
（1）提示受到上下文窗口长度的约束
上下文学习受限于模型结构，它的计算复杂度为O(n2)，导致上下文窗口长度很难快速提高，对算力的消耗是巨大的。不过，当下这一问题在领域内有所突破，麻省理工学院、Meta AI和卡内基梅隆大学研究人员联手，开发了让语言模型能够处理无限长度流媒体输入的框架StreamingLLM。该框架的工作原理是识别并保存模型固有的“注意力池”（Attention Sinks），锚定其推理的初始Token。结合Token的滚动缓存，StreamingLLM的推理速度提高了22倍，而不需要牺牲任何准确性。
经研究团队实验证实，StreamingLLM能够让LLaMA 2、MPT、Falcon和Pythia可靠地处理多达400万个Token的文本。使用专为注意力下沉设计的Token进行预训练，可以进一步提高模型的流媒体运算性能。重要的是，StreamingLLM让语言模型预训练窗口大小与实际文本生成长度脱钩，为流媒体应用的语言模型部署提供了更多可能性。
（2）提示撰写存在技巧、撰写烦琐、输出不稳定
不同的提示，即使是表述上的细微差异，也会导致大模型的性能表现存在显著差异。因此，每次修改提示都需要精心地组织和验证，并且需要防止可能的非预期失败。随着大模型技术的发展，这类问题会逐步得到解决。但当下对用户及开发者来说仍是一个很大的挑战。如何能够更好地解决这类问题呢？对于普通用户，可以参考社区提供的提示模板及写作技巧，对于应用开发者，可以使用一些成熟的应用开发框架，如LangChain和LlamaIndex等。这些框架对提示进行了封装，开发者可以默认使用框架自带的优质提示。此外，社区也提供了一些可以稳定输出的框架，如Guidance和TypeChat等。
（3）上下文学习的安全和权限隔离
在当前的大模型技术水平下，安全性是阻碍大模型在真实场景中落地的重要问题。虽然提示是自然文本，非常容易构造，但基于提示驱动大模型的运作机理尚未被研究清楚，如何保证大模型不被不法分子利用和攻击成了一个难题。
目前，提示攻击是一个非常令模型服务者头疼的问题。如著名的“奶奶漏洞”，诱骗大模型给出汽油弹的制作方法。提示攻击通过精心设计的提示，欺骗大模型执行非预期的操作。提示攻击主要分为三种类型：提示注入、提示泄露和越狱。
提示注入。将恶意或非预期内容添加到提示中，以劫持语言模型的输出。提示泄露和越狱实际上是这种攻击的子集。
提示泄露。从大模型的响应中提取敏感信息或保密信息。
越狱。绕过安全和审查功能。
防御提示攻击有很多种可能的做法，如屏蔽和替换一些关键词，封装改写提示，如随机序列封装、三明治防御和XML封装防御等。业内也存在中间层框架来防止提示攻击，例如Rebuff，开发者可以直接使用。
由于大模型无法直接处理权限层面的问题，所以需要在外部加强权限粒度的管控，在检索增强生成应用里可以通过上下文的方式，将用户有权限的内容提供给大模型，而不需要大模型将其潜在的数据输出，以减少可能的敏感数据泄露。此外，需要在数据源层面进行硬隔离，并进行二次检查以解决数据权限访问的问题。

应用流程

构建大模型应用的基本流程与构建机器学习应用有很大的不同。在构建机器学习应用的过程中，核心在于如何以数据为中心构建训练和推理过程，每个场景都涉及完整的全过程。在构建大模型应用时，虽然也包含模型训练、微调等过程，但由于大模型具备很强的通用性，加之训练的复杂性和高昂的成本，因此通常不会从零训练大模型，而是采用开源的模型加上领域内具体的标注数据加以微调，或者在社区下载已微调好的模型，例如HuggingFace；或者选择更轻量级的方式，直接采用外部的模型服务接口，如ChatGPT、Claude等。值得一提的是，对于大模型应用开发者来讲，基于这些开放的云服务接口进行开发，能够大大地提升开发效率，避免被一些细枝末节的事情打扰。图6所示为机器学习应用和大模型应用的构建流程对比。


图6 机器学习应用和大模型应用的构建流程对比
本文节选自《探秘大模型应用开发》（李瀚，徐斌，著；电子工业出版社）。