基于知识库和 LLM 的问答系统经验分享

最近一直在做检索增强和问答系统的内容。今天给大家分享一些关于LLM和知识库相结合的技巧和使用场景，提供一些信息增量。江湖经验，欢迎有相关经验和感兴趣的伙伴一起交流学习。

一、问答系统简介

问答系统（Question Answer system，简称 QA system），其核心就是用简要的自然文本回答用户提出的问题。
QA 的难度主要在于回答这个问题所依赖的信息在长文档中的分布情况，具体可以大致分为下面三种情况：
（L1）相关信息可以出现在不超过一个固定上下文长度（512）限制的 block 以内
（L2）相关信息出现在多个 block 里，出现的总数不超过 5-10 个,最好是能在大模型支持的有效长度内。
（L3）需要考虑多个片段，并综合结合上下文信息甚至全部内容才能得到结果

受限于数据集的大小和规模以及问题的难度，目前主要研究偏向于 L1 和 L2 。由于高质量的中文数据集整理会耗费很大的人力、物力、现在 QA 问题的数据集，文档长度普遍偏低，而且规模较小和实际应用相差甚远。当然，现在借助大模型的能力，能比较好的整合和回答 L1 类问题，L2 类问题也有比较不错的结果，但对于 L3 类问题，如果所涉及到的片段长度过长，还是无法做到有效的回答。

二、基于LLM的问答系统架构

目前比较常见的开源 LLM 的问答系统都会遵循下图这种结构去进行设计，整个流程用文字表述如下：加载文件 -> 读取文本 -> 文本分割 -> 文本向量化 -> 问句向量化 -> 在文本向量中匹配出与问句向量最相似的 top k个 -> 匹配出的文本作为上下文和问题一起添加到 prompt中 -> 提交给 LLM生成回答。

LangChain+ChatGLM 框架示意图

参照之前，我们将之前的 QA 问题的过程进行细化，梳理出更详细的解决方案：

1）将长文档以某种方式切分为若干 block，每个 block 大小一般会小于向量模型能处理的最大上下文。切分方式可以简单也可以是一个复杂的策略。比如，相邻的 block 之间可以保留重复的内容，用来降低简单切分方式造成的信息损失，并进一步补充 block 的上下文信息。

2）将每个 block 映射为一个vector。对于每个问题，也通过相同的方式与 block 进行相关性匹配，或者其他方式进行匹配。选择最相关的 1个 或者多个 block，加上问题，组合为 prompt 输入给 LLM，让其进行回答。

对于L2的问题，所需的 block 数量比较多，再加上提示词模板，很容易超过 LLM 的长度，因此需要进行信息的压缩和回溯。具体一个可选方案就是：

1）每一个 block 和提问的问题进行组合输入给 LLM，然后返回相关信息。

2）将多个相关信息进行汇总和筛选，总结，将相关性较高的内容作为新的 context 输入给 LLM 进行回答。

三、问题分析与解决方案

根据上述的方案设计，我们会很容易发现几个问题。虽然L1 类问题解决比较容易，但是 L2 类问题涉及到了信息的压缩和整合，如果多次调用 LLM，则代价很大，而且时间开销不低。

整个向量检索到最后 LLM 生成的整体链路很长。需要对文本切分，然后向量化之后存储到向量数据库中。然后需要进行 KNN 检索最相似的 K 个文本片段，拼接成提示词去调用 LLM。这几个步骤都有可能出现问题，导致带来连锁反应，使得最后结果的可信度满足不了客户效果。

从整体流程梳理，细节的问题主要集中在下面几点：
1）文本切分，切分策略需要按数据集进行适配和微调，没有低成本、高质量的方案
2）向量模型的语义表达能力问题，长文本的召回率和相关性一般
3）作为基座的 LLM，能力不够，天花板太低

针对出现的问题，提供几个可能的解决方案和优化措施，经过我们实验，能在一定程度上缓解这些问题。

一）文本切分

目前对文本切片的方案，主要有两种，一种就是基于策略规则，另外一种是基于算法模型。同时，文本切分的策略也和向量模型息息相关，建议同时考虑向量模型的建模能力去设定切分的方案。例如，BERT 模型能处理的最大文本长度为 512，但切分时并不一定按照 512 去切分。

基于策略规则，主要有几种不同的策略可以供选择：

1. 截断 截取前 510 个或后 510 个或前 128 + 后 382
2. 分段 分段 k=L/510, 然后各段可以求平均、求 max
3. 滑动窗口 （Sliding window），即把文档分成有重叠的若干段，然后每一段都当作独立的文档送入BERT进行处理。最后再对于这些独立文档得到的结果进行整合

Sliding window 可以使用 LangChain 里的 RecursiveCharacterTextSplitter 或者 LangChain-Chatchat 实现的ChineseRecursiveTextSplitter 进行切分，对中文相比较友好一些。重叠的长度和窗口长度需要根据实际进行调整，没有特别明确的规则，可以根据文档的平均长度为参考基准。核心可以参考的几个指标有，响应时间、检索相关性以及产生幻觉的次数。

基于算法模型，主要是使用类似 BERT 结构的语义段落分割模型，能够较好的对段落进行切割，并获取尽量完整的上下文语义。需要微调，上手难度高，而且切分出的段落有可能大于向量模型所支持的长度，这样就还需要进行切分。

二）向量模型

向量模型核心是召回大量和查询的 query 相似的语义片段，如果想减少或者优化召回后的语义片段数量，还需要和排序模型相结合使用。现在常用的向量模型结构都比较类似，存在语义表示不足的问题。

目前，向量模型都会基于 BERT 作为基座模型再进行微调，而 BERT 最大长度仅支持到 512；超过 512 的时候，性能会急剧下降，再使用的意义不大，也制约了语义表示的质量。比较主流的向量模型，例如 text2vec 支持的长度仅为128；bge、m3e 等语义模型支持长度均为 512。

还需要注意的是，有的向量模型使用的数据集，文档长度都没有达到 512，这就意味着这种模型实际有效的文档长度并不是 512，因此做文本切分的时候还是需要根据实际情况进行确定。

向量模型的优化一般有两个思路，从适用性和实现难度上来讲，选择对文本进行切分的代价和成本都比较低，这种方法也是目前主流的 LLM+QA 系统常用的方案。第二种就是直接对向量模型进行改进，优化模型结构使得可以支持更大的上下文信息，以便生成更高质量的语义向量。

文本切分的策略可以参考第一小节，对文本切分之后的处理方式一般有两种，一种是将不同组块视为不同的向量，然后进行召回；另外一种是，将不同组块拼接为一个向量，可以取平均、取最值或者拼接向量。这两种方案在实现上难度比较接近，如果后续接入 LLM，一般会为了召回更相关的内容，用方式一的比较多。如果是做检索和排序任务，一般会检索整篇文章，方式二可能会更好一些。

直接对向量模型底层的 BERT 或者 Transformer 结构进行改进，会使向量模型支持更长的上下文，简单来说会有下面几种不同的方式，在具体任务上的表现也需要视情况而定。

1. 修改模型结构，比如Transformer-XL，魔改了 Transformer 的注意力机制，天然支持长文本序列。
2. 层次编码机制，由句子生成段落表示，然后由段落生成文章的表示。
3. 利用模型进行信息压缩和筛选，比如CogLTX。CogLTX 的关键步骤是将文本拆分成多个 block，然后识别关键的文本 block，在 CogLTX 中叫做 MemRecall。CogLTX 中有另一个 BERT 模型，叫做 judge，用来给 block 的相关性进行打分。

目前主流的中文向量模型有 m3e、bge、text2vec 等，从实际使用效果来看，可以优先选择 bge，由于整个链路的性能瓶颈，主要在 LLM 一侧，向量模型耗时可以忽略不计。bge-v1.5 的效果没有原来的版本高，不建议使用。

如果有自己的数据集，建议按照官方说明，微调 bge。相关实验参数建议自己根据实际进行修改，难负例的挖掘十分重要，数量控制在 2-8 个为宜；batch size 尽可能的越大越好，微调的 epoch 不建议过大，1-2个 epoch 为宜。

如果，直接用 bge 召回效果不太满意，可以考虑后续用 BM25 算法去进一步优化召回的得分。 BM25 实现简单，可以作为 baseline，后续有能力再接入排序模型也是很好的选择。

三）基座LLM选择

LLM 是基石，选择一个质量较高的模型是关键。从成本和使用效果两个方面来分析，如果不考虑成本因素，首选GPT4，其次 GPT3.5。根据我们实际测试的几个大模型的效果，和 GPT3.5 还是有所差距。

考虑有本地部署的需求，我们使用了 ChatGLM 和 baichuan，实测下来两者效果差不太多。6B 参数量级的模型差强人意，去微调模型或者是优化提示词能带来的提升比较有限，有能力的最好部署参数量更大的模型（大于等于 13B）。

四）效果评价

目前去评价整体的 QA 系统是有相关测试数据集可以评价的，但是对于 LLM 生成的回答用机器的方法去评价会有遗漏的地方，还是需要人工介入更好。建议整体上对效果的评价分三步走，第一步选出最好的向量模型，第二步选择一个最优的基座 LLM 模型，第三步优化提示词。

第一步，对于向量模型的效果，可以使用专门用于检索的数据去评价，也可以自己制作相关的数据集去评选出最优的向量模型。

第二步，使用相同的问题和检索的上下文构建提示词，分别对不同的 LLM 模型输出的结果进行盲审，评选出最优的LLM 模型。

第三步，使用向量模型召回的 context 和人工筛选出的 context 去利用 LLM 生成回答，并对回答的结果进行验证，定位效果瓶颈。如果人工筛选的 context 结果明显好于向量模型的，则瓶颈在向量召回上，应该去优化向量模型。如果人工筛选的 context 和向量召回的 context 效果差距不大，则瓶颈在 LLM，应该去使用更好的 LLM 或者尝试优化提示词。

如何学习AI大模型？

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

第一阶段： 从大模型系统设计入手，讲解大模型的主要方法；

第二阶段： 在通过大模型提示词工程从Prompts角度入手更好发挥模型的作用；

第三阶段： 大模型平台应用开发借助阿里云PAI平台构建电商领域虚拟试衣系统；

第四阶段： 大模型知识库应用开发以LangChain框架为例，构建物流行业咨询智能问答系统；

第五阶段： 大模型微调开发借助以大健康、新零售、新媒体领域构建适合当前领域大模型；

第六阶段： 以SD多模态大模型为主，搭建了文生图小程序案例；

第七阶段： 以大模型平台应用与开发为主，通过星火大模型，文心大模型等成熟大模型构建大模型行业应用。

👉学会后的收获：👈
• 基于大模型全栈工程实现（前端、后端、产品经理、设计、数据分析等），通过这门课可获得不同能力；

• 能够利用大模型解决相关实际项目需求： 大数据时代，越来越多的企业和机构需要处理海量数据，利用大模型技术可以更好地处理这些数据，提高数据分析和决策的准确性。因此，掌握大模型应用开发技能，可以让程序员更好地应对实际项目需求；

• 基于大模型和企业数据AI应用开发，实现大模型理论、掌握GPU算力、硬件、LangChain开发框架和项目实战技能， 学会Fine-tuning垂直训练大模型（数据准备、数据蒸馏、大模型部署）一站式掌握；

• 能够完成时下热门大模型垂直领域模型训练能力，提高程序员的编码能力： 大模型应用开发需要掌握机器学习算法、深度学习框架等技术，这些技术的掌握可以提高程序员的编码能力和分析能力，让程序员更加熟练地编写高质量的代码。

1.AI大模型学习路线图
2.100套AI大模型商业化落地方案
3.100集大模型视频教程
4.200本大模型PDF书籍
5.LLM面试题合集
6.AI产品经理资源合集

👉获取方式：
😝有需要的小伙伴，可以保存图片到wx扫描二v码免费领取【保证100%免费】🆓