大语言模型私有化部署和个性化调优的技术实践

简介

本文介绍如何在不依赖任何三方服务的情况下，私有化部署和使用大语言模型，以及如何以较低成本让大语言模型使用自己的数据来产生个性化输出。

本文偏技术向，读者需要具备一定技术背景，如有不懂之处，欢迎留言交流。

1、什么是大语言模型？

大语言模型（Large Language Model, LLM）是一种擅长自然语言处理的 AI 模型，它可以学习和理解自然语言的语法和语义，完成知识搜索、概括、翻译、创作等任务，并具备一定逻辑判断能力。根据上述天赋技能，可以看到 LLM 的应用场景相当广泛。比如它可以直接取代传统的翻译软件；可以帮你整理和归纳一段文字的重点；可以根据少量提示创作一个完整的故事；甚至可以为你分析体检报告。如果利用好 LLM 的语言处理优势，能够极大提升工作生产效率，让死气沉沉的文本焕发生机。

2、为什么要私有化部署？

当前 LLM 通常包含数十亿参数，需要通过大量的文本数据训练来优化这些参数，参数量越大，模型预测效果越好，所需要的算力也越高。

也就是说，训练 LLM 需要海量的数据，无论是制造或使用 LLM 都需要很大的算力。对消费级计算设备（如一般家用电脑）来说，虽然并不需要训练 LLM，但仅仅是安装和运行 LLM，目前都是一件很困难的事情。

原因一方面是 LLM 模型的文件体积很大，一个包含 60 亿参数的模型通常在 20GB 以上，这块赶上一个 3A 游戏的体量了，恐怕没人愿意在自己的电脑上安装一个 20GB 的聊天机器人；另一方面是加载和运行模型需要很高的硬件条件，比如内存至少需要在 16GB 以上，如果想要在移动设备上使用，就更困难了。

目前市面上大多数应用的背后其实都依赖三方服务，通过 API 调用三方服务提供的接口来访问部署在远端的 LLM。而 API 提供方坐拥数据和算力，消费者要享受流畅无限制的体验，自然需要付费使用。目前提供 API 的三方服务多为外国公司，如 OpenAI。

个人或国内企业如果通过 OpenAI 使用 ChatGPT，必然存在数据安全风险，任何通过 API 发往外部的数据都有可能被窃取或用于其他用途；同时，这样的方式也不利于国内企业发展和国家监管。如果不想被卡脖子，有两种选择：一种是自研 LLM，目前国内已有多家知名企业入局研发；另一种也是本文要介绍的，就是使用开源 LLM 并实现私有化部署，并在此基础上做一些定制化和产品建设，这更适合国内大量硬件或技术条件不佳的中小型公司使用。

3、技术路线

如上图，一句话描述就是将现有知识库（Knowledge base）和用户输入（User prompt）组合成一个具备上下文的模型输入（Context-aware prompt），送入 LLM（Language model）得到输出（Result）。

和市面上常见的套壳聊天框不同的是，用户输入（User prompt）是直接进入 LLM，这样模型输出的内容可能是相当泛化的，说人话就是不太接地气。而如果需要模型接地气地输出，则需要提供上下文（context），构造上下文是整个路线最为重要的环节。

3.1、知识库（Knowledge base）

Knowledge base 可以是一个现有知识库，比如产品说明书、用户手册等等，这些数据往往是领域特定知识，也是后面产生“个性化”的依据。

3.2、用户输入（User Prompt）

User prompt 就是用户的提问内容，与其让用户随意输入，不如适当做一些规则限制或引导，比如固定格式的提问，因为 prompt 对模型的输出结果影响较大。

3.3、带上下文的模型输入（Context-aware Prompt）

具体举一例：

请根据以下信息回答问题：
苹果是一种水果、香蕉是一种水果、白菜是一种蔬菜
问题是：水果有哪些？

其中「请根据以下信息回答问题：」和「问题是：」为固定内容，「水果有哪些？」是 user prompt，其余部分就是 context。

这里 context 的具体内容需要跟 user prompt 有关联性，可以理解成有一种查找算法从现有知识库中提取和用户提问相关的内容：

context = f(knowledge, user prompt)

3.4、Embedding 和向量数据库（Vector Database）

实现这种算法需要用到 Embedding 模型和向量数据库（Vector Database）。通过 Embedding 可以得到文本向量，通过向量数据库可以进行相似度搜索（Similarity Search）。

补充内容：在自然语言处理领域中，Embedding 通常指将单词或短语映射到低维向量空间中的表示。这种表示可以捕捉单词或短语的语义和语法信息，便于计算机进行自然语言处理任务，如文本分类、情感分析、机器翻译等。市面上有很多开源的 Embedding 模型可用，例如：Word2Vec、GloVe、BERT 等等。当然 OpenAI 提供的 Embedding API 背后也许就是基于这些开源模型的优化。

向量数据库可以对其存储的向量进行 CRUD 操作，而相似度搜索是这里最关键的部分。可以使用常见的 k-近邻算法（k-NN）来查找与给定向量最相似的向量，不过这件事通常由向量数据库完成，我们只需要默认使用或这根据需要选择最恰当的算法即可，不必自己实现一遍。

具体的方式如下图：

可以看到这里 User prompt 通过 Embedding API 被转换成了一组数字，这组数字就是文本向量。上面这个图其实还缺少对向量数据库的来源说明，向量数据库其实也由相同的 Embedding API 产生，即：

knowledge => Embedding API => vector database

文本向量进入向量数据库查询就得到了一组相关文档（Relevant documents），不过需要注意的是这里相关文档还不是 context，相关文档是 Embedding 模型的原始输入，可能还不能直接用作 context，需要做一些格式化或精简，来确保模型输入内容不会超限。

3.5、语言模型（Language model）

既然向量数据库已经能够给出相关文档了，那为啥还要塞给语言模型处理一遍呢？读者可以自己思考一下这个问题。

市面上的语言模型有太多，常见闭源的有 GPT-3、Bard、PanGu，开源的有 LLaMA、GLM、Moss 等等，都是可以拿来用的，不过使用成本各不相同。不过既然要私有化部署，那么最直接的方式是选择开源模型。

大多数开源模型都给出了运行方法，不过使用前依然需要仔细评估每个模型的要求和部署成本，比如有的模型不支持中文输出，有的模型对硬件的要求很高，有的模型依赖特别的环境等等。

4、其他技术路线

上述技术路线的成本相对较低（因为没有模型训练过程），可操作空间比较灵活，但对于需要深度定制模型的业务场景来说，Fine-tuning 可能是更好的选择。Fine-tuning 是一种对预训练模型进行微调来适应新任务或数据集的方法，模型训练的算力要求较高并且流程相对复杂，需要谨慎评估算力和技术成本。

5、项目实践

我采用上述技术路线，使用纯开源模型和技术，在本地实现和部署了一个用于搜索浏览器书签内容的 AI 助理，AI 可以从浏览器保存的历史书签中，以自然语言对话的形式找到你要想但忘记标题的网址。

项目代码：https://github.com/micooz/ai-bookmark
操作系统和硬件条件：macOS Ventura、64GB RAM、Apple M1
Framework：Langchain（TypeScript）
LLM：ChatGLM-6B
Embedding Model：text2vec-large-chinese
Vector Database：HNSWLib

使用效果：

6、注意事项和待解决的问题

总结几个需要注意的问题：

需要合理选择 LLM 和 Embedding Model，不同 LLM 和 Embedding 的性能截然不同。
为了方便实践验证，我选择了支持单文件存储的 HNSWLib 作为向量数据库，请不要在生产环境下使用，应该采用更可靠和专业的存储方案。

待解决的问题：

模型体积较大，一套下来 30GB 左右，还没办法为普通用户提供离线服务。
macOS 平台目前只能采用 Pytorch mps 加速方案，但即便如此，模型推导性能和资源占用情况依然很不理想，不太适合在没有专业 GPU 的设备上部署。

不过好在已经有人利用机器学习编译（Machine Learning Compilation，MLC）方案让模型能够在 iOS、Android、Web 浏览器上跑起来了：https://github.com/mlc-ai/mlc-llm

7、总结

本文介绍了大语言模型私有化部署和个性化调优的技术实践，采用开源大语言模型、Embedding 模型以及向量数据库的技术选型，实现了基于现有知识数据的个性化 AI 助理。期待后续挖掘出有更多有趣的 AI 应用场景，基于此方案可以让 AI 更加专注领域知识的处理。同时也期待有更多别出心裁的方案让大模型的使用成本进一步降低。