被刷屏的LLM、RAG是什么？本文上半部循序渐进地解释了RAG的前世今生。
数禾科技基于RAG打造企业知识库的经验在中间部分不要错过。
你是否也面对AI应用的生产挑战？在文章下半部分一起交流模型服务中心（ModelHub）的研发、调研、开发和应用干货。

#01

1.1. 让人右滑退出的概念解释

“RAG，即检索增强生成（Retrieval-Augmented Generation），是一种优化大型语言模型（LLM）输出的方法。它让LLM在生成文本之前，能够从外部知识库中检索相关信息，并结合这些信息生成更准确、更全面的回答。”

以上来自Gemini大模型的回答

“优化大型语言模型（LLM）输出的方法”：

1. 什么是大语言模型（LLM）？

2. 为什么要优化LLM输出？

“它让LLM在生成文本之前，能够从外部知识库中检索相关信息，”：

1. 什么是外部知识库？

2. 相关信息是什么意思，和谁相关？

3. 检索，怎么检索？

“并结合这些信息生成更准确、更全面的回答。”：

1. 怎么结合信息？

2. 怎么就更准确、更全面了呢？

下面内容会解释这些问题。

如果你已经了解RAG，想看RAG生产应用实践，可以跳转#03 RAG这件小事。

如果你已有过RAG生产应用实践，ModelHub部分可以跳转#04 从RAG到ModelHub。

#02

2.1. 什么是LLM（Large Language Model）

随着ChatGPT发布，LLM（Large Language Model, 即大语言模型）一词频繁出现。以下是在ChatGPT发布当月至今，某搜索引擎“LLM”关键词搜索趋势：

2.2. LLM可以干许多白领的工作

2.3. 你说AI将会取代我，我不信

2.4. 你看，AI炒得那么火，不还是个笨蛋嘛！

2.5.图解RAG

2.6.企业知识库

#03

3.1.算法：It works on my machine – AI应用上云

3.2.前端：你这功能缺失得厉害 – 关键接口

3.3.运维：没见过消耗资源这么高的应用

#04

从图11的架构图中可见，一个RAG服务，至少需要三个模型：语义文本分割模型（text-splitter）、嵌入模型（embedding）、大语言模型（LLM）。RAG的实现可以有不同的层次，这超出本篇的范围。这里只以图11-企业知识库服务架构展示的RAG方案为例介绍ModelHub。

• 其中语义文本分割模型模型，我们采用modelscope平台上的nlp_bert_document-segmentation_chinese-base文本分割模型。

• 其中嵌入模型，我们采用huggingface上的BAAI/bge-base-zh模型。

• 大语言模型使用了通义千问的API服务。

这里需要文本分割模型和嵌入模型不像大语言模型有公共API提供，需要自行解决调用问题。

在初次实现RAG服务时，我们通过本地模型文件加载，推理的方式使用。从上文可以看出来，这种使用方式有以下几种痛点：

1. 代码费时：加载本地模型文件，就需要配置模型文件地址。这对修改模型调试需要修改代码增加了复杂度。而开发时的文件地址，和部署生产环境的文件地址又有不同，这又增加了服务代码和构建部署代码的复杂度。

2. 部署费力：在云上部署服务，AI应用的单个模型文件都是几百MB到GB不等，将模型文件放到代码中，再构建部署是不合适的。这就需要额外的挂载存储资源的配置工作。

3. 资源浪费（CPU、Memory）：模型占用资源较多，但是每个模型使用量不同。

4. 无法复用：其它AI应用无法复用模型的使用经验。上述的问题，在其它AI应用上，会继续重复问题。

我们可以通过将模型推理功能和RAG拆分开来，将模型推理功能服务化，通过APIs使用模型推理，将模型推理服务集中管理，即模型服务中心应用（ModelHub）。

一个典型的AI应用开发兼顾模型服务开发的流程如下图所示：

图16: ModelHub应用的用户故事

为了更好地理解这个流程，我们以一个开发者希望使用某个模型来构建一个应用程序为例。

对于AI应用开发人员，工作流程如下：

1. 选择模型：开发者首先在ModelHub上选择一个适合其需求的模型。每个模型都有一个唯一的ID，方便开发者进行标识和调用。

2. 如果模型不在ModelHub上，则进入在ModelHub部署模型的流程。如果存在，则进入下一步。

3. 使用模型：通过ModelHub的SDK，可以调用ModelHub上部署的模型服务，推理得到模型调用结果。

4. 开发应用：开发者使用模型功能开发自己的应用程序。在这个过程中，应用程序会调用之前部署的API服务，从而实现模型的预测功能。

对于部署模型服务人员（可以和AI应用开发人员是同一人），工作流程如下：

1. 将选择的模型，或训练的模型，部署到ModelHub上成为模型服务。

2. 在AI平台上（一般是JupyterHub/JupyterLab）使用的模型加载、推理代码，整理成ModelHub格式的模型预测脚本。

3. 将模型文件和预测脚本按ModelHub的方式，发布到ModelHub平台上。发布成功后，就可以根据对应的ID和ModelHub SDK调用该模型执行推理得到结果。

通过是否使用ModelHub的各项对比，可以评估研发ModelHub的价值：

在对比直接使用模型和通过ModelHub使用模型的优缺点后，我们可以更清晰地看到ModelHub带来的好处和可能的挑战。

首先，通过ModelHub使用模型的学习成本相对于直接使用模型会稍微提高一些。原因是用户不仅需要理解模型本身，还需要理解ModelHub的使用方式和流程。然而，一旦掌握了ModelHub的使用，这种投入将会带来长远的回报。

其次，直接使用模型的代码难度相对较低，因为用户只需要关注如何加载和使用模型。但是，通过ModelHub使用模型，用户需要额外掌握如何将模型上传到ModelHub，以及如何通过ModelHub的API进行调用。然而，这也意味着用户可以通过ModelHub提供的API，更方便地在不同的项目中复用模型和代码。

部署难度方面，ModelHub显著优于直接使用模型。直接使用模型需要解决模型文件的存储和加载问题，而ModelHub为用户提供了一个中心化的解决方案，简化了部署的复杂性。

在资源利用方面，ModelHub也比直接使用模型更高效。因为ModelHub可以根据需要配置模型服务资源，避免了直接使用模型可能存在的资源浪费问题。

然后，ModelHub的另一个显著优点是支持模型和代码的复用。这意味着一旦一个模型被上传并配置到ModelHub，其他AI应用可以轻松地复用这个模型，无需再次进行模型加载和配置。这极大地提高了模型的使用效率和便利性。

最后，ModelHub提供了方便的模型对比实验功能。用户可以轻松地在ModelHub中上传和测试不同的模型，然后通过比较它们的性能来选择最合适的模型。而在没有ModelHub的情况下，进行模型对比实验会更加麻烦。

总的来说，尽管通过ModelHub使用模型的学习成本和代码难度略高于直接使用模型，但ModelHub的便利性、资源效率、以及对模型和代码复用的支持，使其成为一个非常值得投资的工具。

ModelHub爆珠果酱在我脑海爆开

根据调研的模型服务和预期的模型服务中心用户故事，模型服务中心的系统可以设计成客户端（SDK）、应用UI、APIs、后台管理UI、服务管理、部署模型服务、模型文件存储等七个组件，如下图所示：

图17: ModelHub架构图

上述组件是综合前面调研的设计。在实际的实施过程中，是可以根据开发阶段先只实现其中部分组件。后台管理部分完全是可选的。ModelHub UI部分是提供用户使用，可以通过UI上传模型文件、模型推理脚本，实现自动化部署模型服务，这部分也是可选。而模型存储组件可以通过固定的挂载存储方式解决。

一天找开源项目，一天部署开源项目，问题就这样解决了？我们做了如下调研分析：

1. Replicate

Replicate是一个闭源商业大模型服务供应商，Replicate提供了用户友好的接口（SDK），是一个理想的模型服务中心方案。但是Replicate只是提供了生成式AI模型[8]的支持，不能满足需求。

2.HuggingFace inference endpoints

Inference Endpoints提供了一种安全的生产解决方案，可以轻松地将Hub中的任何Transformers、Sentence Transformers和扩散器模型部署到由Hugging Face管理的专用和自动扩展的基础设施上[9]。但是不支持modelscope上的模型，这使AI应用对模型的使用有限制。不能完全满足需要。

3. Sagemaker
SageMaker通过完全托管的基础设施、工具和工作流程为任何用例构建、训练和部署机器学习（ML）模型。SageMaker 提供对数百个预训练模型的访问权限，包括公开的基础模型，您只需点击几下即可部署这些模型[10]。
我们没有使用SageMaker的经验，它应该可以满足部署模型服务的需求，但是使用SageMaker需要引入一套不同的技术栈，在这个需求上不合适。

4. Ollama
ollama是大模型的容器化本地执行方案，一开始并不支持Embedding模型，在后来版本支持。且只局限于提供大模型服务和几个有数的Embedding模型。不能满足需求。

5. LiteLLM
LiteLLM可以通过类似反向代理的方式，将许多的大模型供应商的服务都统一成部署LiteLLM地址的OpenAI兼容（OpenAI Compatible）的API[11]。
LiteLLM在大模型服务上提供了完美的解决方案，它可以自行创建API KEY，统计每个KEY的调用量、tokens使用花费，多个大模型部署负载均衡，大模型输入输出日志，还有后台管理UI等等功能。
LiteLLM也提供了Embedding模型、文生图、STT、TTS等API，但都是通过类似反向代理的方式，调用这些实际部署的服务，而不是提供部署模型的方案。且不支持其它种类的模型服务。
所以在LiteLLM提供的模型服务管理功能和统一API有很好的参考意义，但不能直接使用解决需求。

从上面调研的数个产品可知，业界没有一个开箱即用的ModelHub，那么需要自行设计并实现一个ModelHub产品。

5.3.1. 部署模型服务

部署模型服务可有以下几个主要选择：

1. 存储挂载+BetterCDS[12]

2. 单体单机部署/单体多机部署/单体K8s部署

3. 微服务+K8s部署

其中BetterCDS是数禾自研的一站式DevOps平台[12]。它有自己的一套上线服务流程，在本文的需求场景并不适用，但是未来可以探讨立项基于BetterCDS开发一个ModelHub产品。

单体ModelHub应用，在软件实施上是较容易的，但是拓展性（Scaling）较差，长期迭代很容易遇到困难。其中显而易见的是各个AI模型的Python包依赖冲突难题。

微服务+K8s部署的方案，其中微服务可简化为各个模型应用隔离，且与ModelHub服务隔离。ModelHub服务的独立，且通过ModelHub部署提供服务的多个模型服务各自独立为微服务。这通过架构方式而非软件方式直接解决了AI模型的Python包依赖冲突问题。

增删模型服务的拓展、一个模型提供服务容量的拓展，都是可以通过微服务的独立部署解决。

直接采用K8s部署应用服务，在容错性（Failovers）、副本（Replication）等方面，直接使用K8s提供的原生特性，可以省去重复造轮子的拙劣工作。

K8s之外的部署方案选择、对比，超出了本文范围，不再展开。

5.3.2. APIs组件

ModelHub产品必须提供一个有规则的APIs方案，不然与每个模型服务手动部署、配置也没有差别。

APIs可分成调用模型服务推理的API、ModelHub应用服务的API。这里探讨模型服务推理的API设计：

1. 服务地址
   因为前文探讨的部署方式，每个模型服务各自部署，所以每个模型服务地址自然不同。根据前文的用户故事(User Story)设计，每个模型服务自然需要对应ModelHub的模型服务ID，模型服务地址的确定便可以通过该ID确定。
   因为选定K8s技术部署模型服务，通过应用LoadBalancer类型的Service资源，访问模型服务地址，即实现负载均衡。
   模型服务在K8s部署时，将K8s服务名称直接设为ModelHub的模型服务ID，那么无需额外实现索引功能，直接利用K8s客户端，即可通过ModelHub的模型服务ID查询模型服务地址。

2. 路由
   对于AI应用使用的模型，在前文提供的结构设计图中，我们可以做出一些分类。其中大模型服务的路由（router or endpoints），业界已有约定俗成的写法，即”/completions”、”/chat/completions”。而embedding模型，亦有”/embeddings”。这些有约定俗成写法的模型，大多在许多AI框架中也有封装。所以这类模型服务的路由，可以通过服务代码、客户端SDK固定下来，以便提供各种AI框架的客制化封装。
   其它比如文本分割模型，则可以用户自行定义。

3. 协议
   在机器学习社区有多个框架实现了将模型封装成服务应用的功能，它们通常既实现了服务端代码的封装，也实现了客户端封装，既实现了HTTP协议，也可以通过配置以gRPC协议提供模型服务。所以这里无需对比选择，两者都实现的情况，只需要按情况配置使用即可。

5.3.3. 其它考虑

缓存、消息队列等，对于ModelHub产品不是必须实现的功能或组件。

数据库、认证与鉴权等，根据ModelHub的使用范围和本文实现版本，相关功能不需实现或未来版本再实现。

把大象放进冰箱需要几步：三步实现ModelHub

我们不准备从零编写每一行代码实现ModelHub，在机器学习社区有多个框架实现了将模型封装成服务应用的功能，这部分功能对于ModelHub的封装模型推理、部署推理服务实现是有帮助。不过大多数框架是MLOps框架，或做机器学习模型训练的框架，且一并实现了模型推理服务、部署的功能。在模型推理服务和部署这部分支持的相对完善、符合需求的框架，我们选择了Jina[13]。

对于ModelHub上的模型服务，我们约定一个固定的挂载路径，和一个固定的对象存储服务地址。这样使用的模型都上传到这个对象存储服务地址，在模型推理程序中，使用这个挂载地址和模型名称加载模型。

一个嵌入模型服务的模型加载代码示例如下：

图20: 开发ModelHub上的嵌入模型服务的加载模型代码

使用Jina框架实现服务：使用Jina提供的Executor类包装模型推理功能即可通过Jina提供AI服务。

如前文所言，对于嵌入模型服务，有”/embeddings”路由端点是业界约定俗成的。所以我们对此做了一定程度的封装，如此一个嵌入模型推理代码示例如下：

图21: 开发ModelHub上的嵌入模型服务的推理代码

根据前文的系统设计可知，其中”langchain-hf-embeddings-bge-base-zh”即是模型服务ID。在下文可以看到使用该ID客户端定位到模型服务地址。

使用K8s部署，需要先构建镜像，然后编K8s的YAML配置文件部署。

构建镜像

构建镜像的过程和一般服务应用构建镜像的过程无异。编写应用依赖、编写Dockerfile、构建和上传镜像即可。

K8s配置文件

参考Jina文档的云原生Kubernetes部署支持，结合前面几步，使用Jina框架提供的to_kubernetes_yaml方法，可以自动生成K8s配置文件。

其中使用ModelHub的ID作为生成配置文件中的服务资源名称。配置LoadBalancer类型的Service资源示例代码如下：

图22: 嵌入模型服务的K8s部署配置

这样ModelHub客户端可以使用ID通过K8s客户端查询服务地址，参见下文SDK客户端。

K8s部署

使用K8s的kubectl apply命令可以直接部署上述模型服务。通过将多个模型服务的配置文件生成在同一文件夹下的不同路径，模型服务的增删、更新，都可以使用相同的命令部署。该配置文件夹即ModelHub上的所有模型服务的部署集合。

图23: K8s部署ModelHub上的模型服务

SDK客户端

将模型服务部署之后，我们需要定位模型服务地址以调用服务。Client通过模型ID获取模型服务地址的代码示例如下：

图24: ModelHub客户端获取模型服务地址

Jina框架提供了Client类，其封装的功能对AI应用常用的embeddings和tensors数据嵌入AI应用服务特别有用。

参考Jina文档，使用图中获取的模型服务地址，和前文实现模型服务路由端点，即可实现Client访问前文实现的模型推理服务。

醋蘸饺子：大家都说好

在AI应用中，我们使用ModelHub的SDK，配置想要使用的模型服务ID，即可调用。在企业知识库服务的使用代码示例如下：

图25: RAG应用使用ModelHub上的嵌入模型服务

从图25中代码可以看出，AI应用不再依赖本地模型文件，这意味着部署AI应用不再需要挂载文件对象储存等步骤。对于模型的更换、新的AI应用开发上线，都简化了这个部署步骤。

因为AI应用不再使用本地模型执行推理，所以AI应用使用的资源和一般应用消耗资源无异。

图26: 使用ModelHub后的RAG应用CPU消耗

对比图15-RAG应用资源消耗，可以看到原本需要6C配置，现在下降使用不到1C。

图27: 使用ModelHub后的RAG应用Memory消耗

对比图15-RAG应用资源消耗，可以看到原本需要7G的配置，现在下降到一般使用不到1.5G。

从图25中代码可以看出，AI应用不再依赖本地模型文件，这对AI应用开发有如下好处：

1. 减少模型推理代码，因为推理代码在图21的模型服务中。

2. 对多种不同的模型做效果评估实验等，变得容易。

3. 更换更好效果的模型只需要修改模型服务ID即可。

总结

本文从RAG（Retrieval-Augmented Generation，即检索增强生成）定义开始，先通过介绍LLM（Large Language Model, 即大语言模型）是什么、有什么问题、解释了RAG技术如何解决LLM问题。然后展示了将RAG用做生产应用过程中的问题，揭示了RAG应用的产品细节，暴露出来其从实验室到生产应用遇到的挑战，进而引入ModelHub（模型服务中心）解决方案。介绍了模型服务中心产品的设计、调研、开发到应用全链路过程。ModelHub为AI时代到来即将产生的更多AI应用提供一套可拓展（Scaling）的解决方案。

本文重点介绍了客户端SDK、APIs、部署模型服务三个组件，对于ModelHub产品，还有数个组件是可以完善的。在未来或可以先实现用户UI使部署模型服务流程更简化。实现存储方案对模型文件的管理和使用也对现存问题有所解决。最后后台管理UI涉及的相关功能，可以进一步简化模型服务的监控，解决权限、计费管理等等问题。

目前我们是在企业内部使用ModelHub，可以省略众多组件、功能实现。根据图17-ModelHub架构图，有些组件又可以分阶段逐步实现，这为未来的产品迭代保留空间。

注意，本文的ModelHub应用在2024年上半年完成开发和上线。因为AI社区正在快速变化，所以本文的部分内容（比如对ModelHub应用的调研）可能已经过时，请自行甄别。