浅谈大模型时代的后台技术发展|社区征文
1、前言
随着互联网的快速发展，大数据、人工智能、大模型等技术的兴起，大模型时代已经到来，也让后台工程面临着新的挑战和机遇：
大模型时代下，AI 对后台的计算能力和存储能力提出了更强要求，以满足更高的性能和效率；
LLM（Large Language Model，大语言模型）重塑了日常工作与生活，要求服务提供方的私有化大模型业务具备可扩展性和可维护性；
LLM 落地也需要更高的数据安全性和隐私保护能力，这要求后台服务需要采用更强的加密和权限控制等安全机制；
……
下面我从一名后台开发工程师的角度，浅析一下在大模型时代下，后台工程技术将面临哪些变革、挑战和机遇。
2、后台工程化技术发展
2.1 成熟的后台架构技术
过去 20 年里，后台工程技术在应用领域，取得了非凡的进步，这里总结一下成熟且活跃的后台架构技术：
云计算：云计算技术的发展使得后台工程师能够更轻松地构建和管理大规模的分布式系统。通过云计算平台可以弹性地扩展和缩减服务器资源，提高系统的可靠性和可扩展性。业务上云一度成为互联网大厂的工程技术考核 KPI。
分布式系统：为了应对业务量剧增，并且提高系统的可靠性，各种分布式系统技术呼之欲出，比如：分布式数据库、分布式缓存和分布式消息队列等。
大数据处理：随着业务量剧增，业务数据量也呈指数级增长。通过分布式计算和存储技术，计算机能够高效地处理和分析大规模的数据集，从而给公司提供更准确的数据洞察和决策支持。
微服务架构：业务量剧增，带来了业务代码膨胀，也削弱了系统的可维护性，而微服务架构的兴起提出了解决方案：将复杂的应用程序拆分为多个小型的、独立运行的服务。此举可以提高系统的可维护性和可扩展性，并且使得不同团队可以独立开发和部署各自的服务。
容器化技术与自动化运维：容器化技术（如 Docker）的出现，让微服务架构如虎添翼，使得应用程序可以更加方便地打包、部署和管理应用程序；并在 K8S 等容器编排平台加持下，快速实现故障迁移、部署监控和水平扩展，提高了开发和运维效率，减少人工操作的错误和工作量。
DevOps 文化：DevOps 文化的兴起使得开发和运维团队更加紧密地合作，通过自动化和持续集成/持续交付实现快速部署和迭代。
2.2 曾经红极一时的“榜一技术”
这些技术亮点的出现和发展，极大地推动了互联网后台工程技术的进步和创新，为企业提供了更高效、可靠和安全的后台服务。
与此同时，也有一些技术亮点曾经红极一时，却因为政治因素或是实际落地的伦理问题，没有得到资本的青睐和大众认可，比如：低代码和无代码开发平台、区块链技术等。
2.3 风头正劲的 LLM
要问最近 2 年里，什么是最炙手可热的技术话题，无疑是由 ChatGPT 掀起的 LLM 产业革命（Large Language Model：大语言模型）。
大语言模型是一种基于深度学习和自然语言处理技术的语言模型，可以理解和生成自然语言文本，应用于各种领域，如对话生成、文本摘要、机器翻译、情感分析等。
用路奇的话讲，我们当前正处于一个新范式的拐点阶段；而在 2022 年到 2023 年，“模型”知识火遍社区，其中的代表便是 OpenAI 的技术创新。
2.4 大模型工程化
过去几年时间，我听到太多诸如“GPT 将会替代程序员”、“AI 终究替代人类”等热点话题和争论了，但从技术实践上讲，大模型其实也是后台工程架构的一次最佳实践。
我们除了思考“复杂且遥远的人类社会危机”，同时也应该脚踏实地：作为技术工程师的我们，应该如何赶上大模型应用落地的这股东风呢？
我想从云计算架构和底层技术、LLM 工程化技术，浅谈一下，在大模型时代下的后台工程化技术发展。
3、云计算架构
云计算架构是指在云环境中构建和部署应用程序的方式和方法，云计算技术架构图如下所示：
云计算架构主要包括了：云计算各个组件和服务，以及云计算组件之间的关系和交互方式；最终目标是实现高可用性、可扩展性、灵活性和安全性，说白了：像使用电一样使用 IT。
3.1 LLM 与云计算的关系
LLM 通常需要大量的计算资源和存储空间来进行训练和推理，各大厂研发的大模型落地产品（比如：百度的文心一言、阿里的通义千问、腾讯的混元 AI 等）都是通过公有云完成部署。
在对外口径上，国内大模型战场主打一个鼓吹卖点的商业混战；
但在对内口径上，开源节流和降本增效一直是企业主旋律；
往深处想，未来的国企政府是否需要引入一个大模型提升服务质量和效率，并出于敏感数据的安全性，将大模型进行私有化部署？所以，云计算架构部署将会直接影响大模型落地的可行性。
3.2 架构部署方案
云原生架构可以基于基础设施自建、IaaS、PaaS 或 SaaS 来构建和运行应用程序，如下图所示：
选择不同的部署架构，会影响应用程序的灵活性、定制性和管理复杂性，对大模型也是如此。
3.2.1 基础设施自建
基础设施自建是一种云原生的方式，它允许组织自己构建和管理云基础设施，如下图所示：
基础设施自建可以提供更高的灵活性和定制性，但也需要组织自己负责基础设施的运维和管理，企业自行购买服务器、搭建网络、多环境部署应用、多环境部署大模型框架等等，这也导致了成本飚高。
因此，除非是政府国企的大模型私有化部署场景，否则一般不推荐企业自建基础设施。
3.2.2 云计算分层
随着云计算商业模式越来越趋于成熟，云计算行业规模不断扩大，主流的云计算厂家所拥有的数百万台服务器的规模，他们决定将这部分资源变现，解决中小企业在自建基础设施的成本烦恼。而由于客户群多样性，云计算厂商得针对不同商业场景，去提供差异化的产品服务，这也决定了云计算需要更深层次的软硬件创新。
主流厂商是基于分层理念去提供云计算服务的，分层架构如下图所示：
3.2.2.1 IaaS、PaaS、SaaS
一般来说，公有云或者混合云厂商提供了 IaaS 和 PaaS，中小型企业负责开发垂类业务应用，并通过基于 IaaS 与 PaaS 基础设施，进行 SaaS 部署；而这种合作模式，很可能也是未来 LLM 产业链的分工合作。
3.3 云计算核心
云计算架构的核心是软硬件资源的虚拟化技术，如下图所示：
主要包括了硬件、软件、存储和网络四部分的虚拟化技术：
硬件资源虚拟化
硬件辅助虚拟化（2006s 附近， Intel-VT、AMD-V → 2014s 附近的 DPDK、SPDK）
软件系统虚拟化
大型机虚拟化（1960s 附近，Z/VM、KVM for Z Systems、LinuxONE 等）
小型机虚拟化（1980s 附近，IBM PowerVM、HP vPar/IVM 等）
x86 服务器虚拟化（2000s 附近，ESXi、Hyper-V、KVM、Xen 等）
容器虚拟化（2013s 附近，Docker 等）
存储虚拟化
本地存储：代表作是磁盘，单集群下，服务只能访问固定几个存储介质；
存储阵列：把服务器和存储剥离开来，容量可以做的比较大，通过交换机实现资源共享。
好处：用物理手段将存储介质归类为一个资源池
不足：交换机专用设备非常贵，且随着机器数量增多难以维护
分布式存储：上百万服务器时，没办法通过交换机很好的路由，利用软件手段来组合资源池，解决存储扩展性问题，成本下降。
软件定义存储：SDS（Software-Defined Storage），将存储的控制面和数据面分离。eg，容器的存储资源进行动态分配和管理，以满足不同容器的存储需求，实现对存储资源的灵活管理。更加灵活地满足不同规模的存储需求。
网络虚拟化
虚拟局域网（VLAN）/ 虚拟交换机（vSwitch）/ 虚拟路由器（vRouter）/虚拟防火墙（vFirewall）/ 虚拟专用网络（VPN）
软件定义网络（SDN）：SDN 技术将网络控制平面和数据平面进行分离，通过集中式的控制器对网络进行管理和控制，实现网络资源的灵活配置和管理。
……
4、大模型工程化实践
LLM 是一种基于机器学习的模型，它通过大量的文本数据进行训练，从而学习到语言的规律和模式，并能够生成具有语法和语义正确性的文本，因此 LLM 训练过程也必然涉及到机器学习中的模型构建、参数优化等技术。
4.1 MLOps
4.1.1 诞生原因
由于机器学习工具链不断丰富，SDLC（Software Development Life Cycle，软件开发生命周期）也补充了针对构建 ML 系统（机器学习）的一些新原则，所以产生了 MLOps 工程学科。
一旦在 LLM 领域花了足够多的时间，AI 研究员会意识到大模型本身的两点局限：
（1）它只有“脑子”没有“手臂”，无法在外部世界行动：**不论是搜索网页、调用 API 还是查找数据库，这些能力都无法被 OpenAI 的 API 提供；
（2）甚至它的“脑子”也不完美：**OpenAI 的训练数据截止至 2021 年，并且没有任何企业和个人的私有数据，这让模型只能根据自己的“记忆”回答问题，并且经常给出与事实相悖的答案。
解决办法就是：我们不仅仅要开发一个大模型，还要通过持续集成和反复训练，将源源不断的新知识告诉大模型，让大模型变得更加聪明，这就是 MLOps 的价值所在。
4.1.2 MLOps 概念
MLOps（Machine Learning Operations）是面向机器学习领域，为了提高机器学习落地效率的，涉及角色包括数据科学家和软件工程师。MLOps 的任务包括了：
定义场景
数据收集和整理
模型训练和部署
持续监控和更新
4.1.3 MLOps 架构图
基于数据+模型+代码，最终 MLOps 架构图如下所示：
可靠可追溯的标签化数据
数据收集和预处理：这个组件负责从各种数据源（如数据库、文件系统、API 等）中收集数据，并对其进行预处理和清洗，以便用于机器学习模型的训练和推理；
特征工程：这个组件负责将原始数据转换为可供机器学习模型使用的特征，包括特征选择、特征变换和特征构建等步骤。
可重复迭代训练的模型
模型训练：这个组件负责使用训练数据来训练机器学习模型。它可能包括选择合适的算法、调整模型参数和评估模型性能等步骤。
模型部署：这个组件负责将训练好的模型部署到生产环境中，以便进行实时的推理和预测。它可能包括将模型打包成可执行文件、配置模型服务器和监控模型性能等步骤。
模型监控和管理：这个组件负责监控部署的模型的性能和健康状况，并根据需要进行调整和更新。它可能包括监控模型的预测准确率、处理时间和资源使用情况等指标。
应用监控部署
**可重复且可靠的软件发布：**虽然模型输出可能是不确定的且难以重复，但将 ML 软件发布到生产中的过程是可靠且可重复的，并尽可能利用自动化；
**敏捷发布软件：**机器学习软件能够随时交付生产非常重要。即使组织不想一直交付软件，它也应该始终处于可发布状态。这使得何时发布它成为业务决策而不是技术决策。
4.1.4 DevOps 与 MLOps 的联系
4.1.4.1 相同点
DevOps 与 MLOps 的出现，都是为了提升效率。
DevOps 与 MLOps 的基本理念也是相同的，包括都是尽可能的自动化；对于提升实践的关键特点、关键做法也是相同的，其中系统的思考，尽快的反馈，持续的学习和改进，被称之为 DevOps 的 3 个方法论，在 MLOps 里面同样适用。
4.1.4.2 不同点
对于 DevOps 和 MLOps 来说，他们面向的对象、过程和触发方式是不一样的。
DevOps 的触发方式主要是代码的修改；而 MLOps 不仅仅是代码修改，当数据发生修改、Model Decay 模型性能发生衰退都会触发流水线；
MLOps 还包含构建/训练机器学习模型所需的额外数据和模型步骤，这意味着 MLOps 最终对工作流的每个组件都有一些细微差别。
4.2 LLMOps
最近有一个新概念非常火：LLMOps（LargeLanguageModelOperations），它 MLOps 在大模型领域的特殊应用，包括了在生产中管理和部署 LLM 的一组最佳实践、工具和技术。
LLMOps 架构图如下所示：
4.3 大模型上云
目前，我们已经可以得出两个结论：
（1）综合大模型的落地场景，最优解决方案依旧是云计算部署
举例子：大模型训练效率十分依赖 GPU 的算力。假设有一个芯片算力验证场景，需要实测比对多种芯片在仿真训练测试的场景，这会导致算力需求高峰，由平时的几十台服务器，短期内要上涨到几千台服务器，那么云原生的弹性伸缩就能很好去定制这类测试环境配置。
（2）LLM 工程化技术包括以下方面：
模型训练：LLM 模型的训练需要进行数据预处理、模型结构设计、优化算法选择等多个方面的工程化工作；
模型部署：LLM 模型部署需要将其部署到生产环境中，以便进行实时的自然语言处理任务。在这个过程中，需要考虑模型的性能、稳定性、可扩展性等方面的问题。通常采用容器化技术（如 Docker）来部署模型，同时也建议采用自动化部署工具（如 Jenkins）来实现自动化部署流程；
模型优化：LLM 模型的优化是一个持续不断的过程，需要通过对模型的参数进行调整、增加训练数据量等方式来提高模型的性能；
安全保障：LLM 模型在训练和使用过程中，需要保障其安全性和隐私性。为此，需要采用多种技术手段来保障模型的安全性，如数据脱敏、加密算法、防火墙等；
可视化展示：LLM 模型的结果通常需要以可视化的方式展示给用户，以便用户理解和使用。可视化展示包括结果的可视化展示、模型的运行状态监控等。
此外，而让 LLMOps 理论变得可行的，关键就在于两个重磅技术：LangChain 和向量数据库。
4.3.1 LangChain 框架
必须还得提一嘴LangChain，它是让 LLMOps 顺利实施的重要法宝。
LangChain 是一个强大的框架，旨在帮助开发人员使用语言模型构建端到端的应用程序，是一个用于构建基于大型语言模型（LLM）的应用程序的库，也是第一个被广泛接受的 LLM 应用开发框架。
它提供了一套工具、组件和接口，可以轻松管理与语言模型的交互，将多个组件链接在一起，并集成额外的资源，例如 API 和向量数据库。
组件 1：LLM（大语言模型）
LLM 是 LangChain 的基本组件。它实际上是围绕大型语言模型的封装，可以利用特定大型语言模型的功能和能力。
组件 2：Chains（链式调用）
LLM 是 LangChain 中的基本单元，因此可以根据特定任务来链式调用 LLM，而链式调用也可以很简单。比如，可能需要读取用户输入，然后用它构建提示信息，接着用该提示信息生成响应。
组件 3：提示（Prompts）
提示是任何自然语言处理应用程序的核心。即使在 ChatGPT 会话中，答案的帮助程度也取决于提示信息。为此，LangChain 提供了可以用来格式化输入和执行其他实用功能的提示模板。
组件 4：文档加载器和工具（Document Loaders and Utils）
LangChain 的文档加载器和工具模块方便连接到数据源和计算源。
组件 5：代理程序（Agents）
在某些任务中，调用的顺序通常不确定，下一步很可能取决于用户输入和先前步骤的响应。
对于这种类型的应用程序，LangChain 库提供了“代理程序”，可以根据沿途的输入采取动作，而不是固定的确定性顺序。
组件增强
对于 LangChain，还有很多工程化的事情可以去优化，因为 LangChain 的各个组件都可以增强：
比如 Document 如何切割；
比如向量数据库如何选型；
比如框架链路如何组装数据等；
……
4.3.2 向量数据库
4.3.2.1 大模型的记忆海绵
向量数据库因为 AI 大模型而火起来，而它也一直被认为是大模型的“海马体”或者“记忆海绵”，我们也将 VectorDB 称为大模型的黄金拍档，两者的整体关系架构图如下：
4.3.2.2 大模型存在的问题
目前的大模型都是预训练模型，对于训练截止日之后发生的事情一无所知，原因有二：
第一是大模型没有实时的数据
第二是基础模型缺乏私域数据或者企业数据
4.3.2.3 向量数据库作用
向量数据库可以通过存储最新信息或者企业数据有效弥补了这些不足，让大模型突破在时间和空间上的限制，加速大模型落地行业场景。同时，通过向量数据的本地存储，还能够协助解决目前企业界最担忧的大模型泄露隐私的问题。
4.3.2.4 向量数据库的技术理论
(1)向量
向量数据库是一种专门用于存储、 管理、查询、检索向量的数据库，简单理解就是在 AI 的世界中，处理的所有数据都是向量的形式。
比如，一只柯基就可以通过一个简单的三维向量去表示（毛发，鼻长，体积），最终在三维坐标下最终转化为[毛发-短，鼻长-长，性格-小]。
量化
这种用向量将事物转为向量坐标的过程，就叫量化
向量规律
向量坐标越是相近的点，他们的维度就越相似，越接近同个物种类型，就越难区分；
向量坐标越远，他们的维度差别越大，就越容易区分；
描述向量的维度越多，可以包含更多的信息，从而更准确地描述事物的特征和属性；
增加向量的维度和大模型的参数数量可以提高描述事物的准确性和表达能力；
(2)核心技术
向量数据库背后涉及众多的底层技术，向量数据库结构如下图所示：
其中主要包括：
向量索引技术
向量索引是向量数据库的核心技术之一，它通过构建高效的索引结构来实现快速的向量检索。常见的向量索引包括 FLAT、HNSW、IVF 等。
向量相似度计算技术
向量相似度计算是向量数据库的另一个核心技术，它用于度量向量之间的相似度。常见的向量相似度计算方法包括余弦相似度、欧几里得距离等。
Embedding 技术
利用 Embedding 技术将高维度的数据（例如文字、图片、 音频）映射到低维度空间，即把图片、音频和文字转化为向量来表示，将这些向量存储起来就构成向量数据库。
4.3.2.5 大模型落地案例
下面举 3 个例子说明落地 LLM 的场景案例，供大家参考：
（1）问答知识库老旧的问题
向量数据库可以用于存储和管理大规模的文本向量数据，原始的长文本内容可以通过文本分割转换成文本段，再由 Embedding 模型生成对应的向量并存储在向量数据库中，从而构建起外部知识库。
通过外挂一个向量数据库
当用户问到一个问题，软件系统先去向量数据库去搜索，搜到最新最近的解决办法
然后再将找到的数据，发给 LLM，重新组织语言结果并响应用户
（2）政府国企私有化部署大模型的场景
在使用 LLM 进行训练或预测时，可以从向量数据库中快速地加载和查询需要的文本向量数，这些数据可以作为大模型的外部知识输入，帮助大模型生成更加准确、包含更多私域知识的答案。
此外，这类专业敏感的知识，可以通过向量数据库的私有化部署得以持久化，让数据不出公司，实现数据安全。
（3）降本增效场景
向量数据库还可以使用一些特殊的算法和数据结构，例如向量索引和相似度计算等，来提高 LLM 的查询精度和效率。
ChatGPT 在执行过程中，产生很多任务和状态数据，每个任务都会去思考。如果把思考的过程记下来，那是否能省很多钱了？
5、大模型产业发展
5.1 大模型技术栈
陆奇老师发表过演讲：大模型带来的新范式，就提到过新范式产业正在高速形成，新范式技术堆栈见下图：
这次新范式的产业扩散，开发者堆栈技术发展和开发者生态的形成，是至关重要的，历史上的生态发展一直是“得开发者得天下”。开发者工具、界面、开发者生态，永远是“兵家必争之地”。而未来随着 LLMOps 行业的发展，产业将划分为两部分：模型开发与应用开发。
5.1.1 模型开发
模型开发有以下特点：
大模型本身的开发，目前开发体系已初步成型，但通常以大厂的大模型团队自主研发为主；
垂直和领域模型的开发，则围绕着轻量的模型开展，特点是：体量小、算力要求低，适用于端侧设备，如手机、智能音箱和未来的 LOT 设备上
开源模型开发，这对降低创新门槛，产业能健康发展有很重要的意义。
5.1.2 应用开发
关于快速形成的“开发的工具和工具链”：围绕着主流开发工具和工具链，由各中小厂商进行扩展开发能力；
关于开发对象，具体是开发的运行时和其他资源：
后台服务端：目前主要都是以 OpenAI 和 Azure 为先导；Amazon 也很快进入战场；
前端：目前是以 Web 端为主，比如 Vercel Chrome；但是移动端目前没有动静，在 iOS 上，苹果还没出台他们的产品方案，在 Anroid 上，谷歌目前忙于应付 Bing 的挑战；长期移动端和 IOT 端将有很多机会；
开发生态的关键资源，如课程、书籍等。
5.2 大模型普及
目前，大语言模型的用户，绝大部分都集中在云侧，而未来，每个用户都可能拥有自己的一个大模型，这个想法会让大模型在云边缘和端侧，都有机会出现新的商机和使用场景：
将大语言模型推广到用户端和边缘端，用户可以在本地使用大模型进行各种任务，而无需依赖云端的计算资源和网络连接。这将用户的隐私和数据安全性提高了，因为用户的数据不需要离开本地设备。
大模型的本地部署能提供更快的响应时间和更低的延迟，这对于需要实时交互和即时反馈的应用程序，如智能助手、语音识别和机器翻译等，可以大大提高用户体验。
大模型的本地部署还可以支持离线使用，用户可以在没有网络连接的情况下使用大模型进行各种任务，如离线文本生成、离线语音识别等。这对于一些偏远地区或网络不稳定的环境非常有用，减少对网络带宽的需求，提高系统的可靠性和稳定性。
5.3 大模型合规化
随着人工智能技术的不断发展，大语言模型在各个领域的应用越来越广泛，同时也引发了广泛的技术和社会问题。
社会问题
知识产权冲突、社会伦理争议、个人隐私安全等问题；
技术问题
非法网络数据爬虫更加有恃无恐，也引发了技术领域的思考：
开源合规问题
如果往深处去思考，当程序员利用 Copilot（GitHub 和 OpenAI 合作开发的 AI 代码补全工具）进行 AI 编程时，大模型工具产生的代码片段最终被商业软件所应用，如果跟代码开源协议产生了冲突，这个锅究竟是工具背呢，还是开发者背，抑或是商业软件公司担责？
5.3.1 合规管理法规
根据我国在 2023 年 07 月 13 日发布《生成式人工智能服务管理暂行办法》第四条规定：绿色、高效和安全成为大模型新的核心要素。
这意味着企业在开发和应用大模型时，需要注重以下方面：
绿色环保：是指 LLM 在开发和运行应符合环保要求，绿色的 LLM 应该是采用高效的算法和硬件架构，以减少能源消耗，并且在使用过程中尽量减少对环境的污染；
高效性能：是指 LLM 应该具备高效快速的计算能力和高度并行化的处理能力，开发者应优化算法和模型结构，提高计算资源的利用率；
安全保障：是指 LLM 在数据处理和模型应用过程中的安全性，大模型的开发和应用应具备安全性，并且能够抵御各种网络攻击和恶意行为，保护用户数据和隐私不受侵犯。
6、总结
以上是我从后台开发工程师，结合后台技术架构，对大模型技术栈的一点理解，另外也说说自己一些心得：
大模型短期内确实可以平替局部编程，但仍替代不了工程架构思维
在这个充满机遇和挑战的时代，要经常关注新兴技术发展，然后耐心学习，才可能适应时代的变化，迎接挑战。
参考文献
版权声明: 本文为 InfoQ 作者【后台技术汇】的原创文章。
原文链接:【http://xie.infoq.cn/article/41c059734fdc4d8898c6d7efa】。文章转载请联系作者。
因为向往，所以坚持。 2018-03-28 加入
🏆InfoQ首批签约作者 & 最佳内容创作者 & 首届引航计划参与者 🏆 微信公众号：后台技术汇 腾讯后台开发工程师
评论