背景介绍
最近一段时间搭建了一套完整的私有大模型知识库,目前完整的服务已经完成测试部署上线。基本之前的实践过程,从工程角度整理技术方案以及中间碰到的一些问题,方便后续对这个方向有需求的研发同学们。
为什么做离线私有化部署
在大模型火热起来之后,很多企业都有尝试相关服务。但是实际会碰到大模型不了解公司个性化的情况,无法针对公司情况给出个性化回答。因此就出现了针对大模型的知识库,通过提供公司内部的背景知识提升大模型个性化回答的能力。
但是这个方案马上就碰到一个问题,大量公司的内部信息被泄露。因此大部分公司会选择使用私有化部署的模型,这样就解决了信息泄露问题,这就是私有化部署的企业知识库。
部分企业数据更加敏感,基础数据的服务需要离线在内部运行,因此需要搭建离线的私有化部署的企业知识库。通过这一套服务,将企业内部散落的各种类型的文档知识组织起来,从而更好地为企业提供服务。
技术方案
目前大模型知识库的构建一般是使用检索增强生成 (RAG) 的技术方案,RAG 首先会检索与问题相关的文档,之后会将检索到的信息提供给大模型(LLM),LLM 使用它们来生成更准确、更相关的响应。RAG 有两个核心组件:
- 检索组件:负责从外部知识库中检索与用户查询相关的信息。
- 生成组件:负责生成最终响应。生成组件通常是 LLM,例如 GPT-3 或 ChatGLM 等;
RAG 的常规流程如下所示:
上面的流程图中,第 1~14 步对应于信息的检索,而第 15 步对应于响应的生成。可以看到 RAG 最核心的是信息检索。下面主要关注 RAG 的检索流程。
RAG 的信息检索主要包含两个步骤:
- 向量数据库的构建,对应于上面的 1~7 步,通过对原始的文件信息进行预处理,方便后续快速检索;
- 用户查询流程,对应于上面的 8~15 步,通过用户查询获取匹配的信息,通过构造生成合适的 prompt,提供给大模型得到最终的结果;
向量数据库的构建
向量数据库的构建主要包含下面的步骤:
- 本地文件的加载,实际中文件的类型可能比较多样化,需要根据文件类型选择对应的加载器。文件加载需要去除无关的信息,从而保证后续的高效处理;
- 文件切分,单个文件的内容可能会过大,考虑到大模型实际可用的输入有限,一般会对加载的原始文件执行切分,得到对应的文件块;
- 文件块向量化,为了方便后续根据用户查询匹配对应的文件块,因此会进行文件块的向量化,这样就根据查询数据的向量与文件块的向量之间的差异确定匹配的文件块;
- 向量库的构建,基于向量化后的文件块构建向量数据库,后续就可以在向量数据库中进行查询;
用户检索流程
用户检索的流程主要包含下面的核心步骤:
- 向量化查询语句,从向量数据库中获取匹配的文件块;
- 将匹配的文件块与用户的查询语句合并构造为完整的 prompt;
- 基于 prompt 发起 LLM 查询,获得 LLM 响应;
上面的流程包含 RAG 的核心流程,如果希望提升 RAG 的效果,需要对流程中的特定环境进行优化。
方案落地
为了实现完整的 RAG 框架,常规的方案是基于 langchain 开发,langchain 提供了不同格式的文件处理的封装,而且可以快速切换不同的 LLM 从而迭代调优 RAG 系统的效果。
但是实际中我选择了对 langchain 进行了二次封装的 Langchain-Chatchat,完整看完 Langchain-Chatchat 的实现后,感觉此项目相对完善,适合作为开箱即用的 RAG 服务。
更友好的是,Langchain-Chatchat 提供了在线大模型 API 的接入,因此可以在没有强大 GPU 服务器的个人笔记本上运行起来,方便快速测试,当部署至性能更强大的 GPU 服务器上,可以通过