PythonAI算法
基于知识库和 LLM 的问答系统实践与优化经验
本文探讨了基于检索增强生成（RAG）的问答系统架构，分析了文本切分、向量模型选择及基座大模型配置中的关键问题。针对长文档信息分布不均、语义召回率低及上下文长度限制等挑战，提出了滑动窗口切分、混合检索策略及多阶段评估方案。通过对比不同向量模型效果与微调参数建议，结合 LangChain 框架实现了从文档加载到回答生成的完整链路，为构建高可用知识库问答系统提供了技术参考与实践路径。
本文探讨了基于检索增强生成（RAG）的问答系统架构，分析了文本切分、向量模型选择及基座大模型配置中的关键问题。针对长文档信息分布不均、语义召回率低及上下文长度限制等挑战，提出了滑动窗口切分、混合检索策略及多阶段评估方案。通过对比不同向量模型效果与微调参数建议，结合 LangChain 框架实现了从文档加载到回答生成的完整链路，为构建高可用知识库问答系统提供了技术参考与实践路径。
问答系统（Question Answering System，简称 QA System），其核心是用简要的自然文本回答用户提出的问题。QA 的难度主要在于回答这个问题所依赖的信息在长文档中的分布情况，具体可以大致分为下面三种情况：
受限于数据集的大小和规模以及问题的难度，目前主要研究偏向于 L1 和 L2。由于高质量的中文数据集整理会耗费很大的人力、物力，现在 QA 问题的数据集文档长度普遍偏低，而且规模较小，与实际应用相差甚远。当然，借助大模型的能力，能比较好的整合和回答 L1 类问题，L2 类问题也有比较不错的结果，但对于 L3 类问题，如果所涉及到的片段长度过长，还是无法做到有效的回答。
目前比较常见的开源 LLM 的问答系统都会遵循下图这种结构去进行设计，整个流程用文字表述如下：加载文件 -> 读取文本 -> 文本分割 -> 文本向量化 -> 问句向量化 -> 在文本向量中匹配出与问句向量最相似的 top k 个 -> 匹配出的文本作为上下文和问题一起添加到 prompt 中 -> 提交给 LLM 生成回答。
LangChain+ChatGLM 框架示意图：
参照之前，我们将之前的 QA 问题的过程进行细化，梳理出更详细的解决方案：
对于 L2 的问题，所需的 block 数量比较多，再加上提示词模板，很容易超过 LLM 的长度，因此需要进行信息的压缩和回溯。具体一个可选方案就是：
根据上述的方案设计，我们会很容易发现几个问题。虽然 L1 类问题解决比较容易，但是 L2 类问题涉及到了信息的压缩和整合，如果多次调用 LLM，则代价很大，而且时间开销不低。
整个向量检索到最后 LLM 生成的整体链路很长。需要对文本切分，然后向量化之后存储到向量数据库中。然后需要进行 KNN 检索最相似的 K 个文本片段，拼接成提示词去调用 LLM。这几个步骤都有可能出现问题，导致带来连锁反应，使得最后结果的可信度满足不了客户效果。
从整体流程梳理，细节的问题主要集中在下面几点：
针对出现的问题，提供几个可能的解决方案和优化措施，经过我们实验，能在一定程度上缓解这些问题。
目前对文本切片的方案，主要有两种，一种就是基于策略规则，另外一种是基于算法模型。同时，文本切分的策略也和向量模型息息相关，建议同时考虑向量模型的建模能力去设定切分的方案。例如，BERT 模型能处理的最大文本长度为 512，但切分时并不一定按照 512 去切分。
基于策略规则，主要有几种不同的策略可以供选择：
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 结构进行改进，会使向量模型支持更长的上下文，简单来说会有下面几种不同的方式，在具体任务上的表现也需要视情况而定。
目前主流的中文向量模型有 m3e、bge、text2vec 等，从实际使用效果来看，可以优先选择 bge，由于整个链路的性能瓶颈，主要在 LLM 一侧，向量模型耗时可以忽略不计。bge-v1.5 的效果没有原来的版本高，不建议使用。
如果有自己的数据集，建议按照官方说明，微调 bge。相关实验参数建议自己根据实际进行修改，难负例的挖掘十分重要，数量控制在 2-8 个为宜；batch size 尽可能的越大越好，微调的 epoch 不建议过大，1-2 个 epoch 为宜。
如果，直接用 bge 召回效果不太满意，可以考虑后续用 BM25 算法去进一步优化召回的得分。BM25 实现简单，可以作为 baseline，后续有能力再接入排序模型也是很好的选择。
LLM 是基石，选择一个质量较高的模型是关键。从成本和使用效果两个方面来分析，如果不考虑成本因素，首选 GPT4，其次 GPT3.5。根据我们实际测试的几个大模型的效果，和 GPT3.5 还是有所差距。
考虑有本地部署的需求，我们使用了 ChatGLM 和 baichuan，实测下来两者效果差不太多。6B 参数量级的模型差强人意，去微调模型或者是优化提示词能带来的提升比较有限，有能力的最好部署参数量更大的模型（大于等于 13B）。
目前去评价整体的 QA 系统是有相关测试数据集可以评价的，但是对于 LLM 生成的回答用机器的方法去评价会有遗漏的地方，还是需要人工介入更好。建议整体上对效果的评价分三步走，第一步选出最好的向量模型，第二步选择一个最优的基座 LLM 模型，第三步优化提示词。
第一步，对于向量模型的效果，可以使用专门用于检索的数据去评价，也可以自己制作相关的数据集去评选出最优的向量模型。
第二步，使用相同的问题和检索的上下文构建提示词，分别对不同的 LLM 模型输出的结果进行盲审，评选出最优的 LLM 模型。
第三步，使用向量模型召回的 context 和人工筛选出的 context 去利用 LLM 生成回答，并对回答的结果进行验证，定位效果瓶颈。如果人工筛选的 context 结果明显好于向量模型的，则瓶颈在向量召回上，应该去优化向量模型。如果人工筛选的 context 和向量召回的 context 效果差距不大，则瓶颈在 LLM，应该去使用更好的 LLM 或者尝试优化提示词。
在实际项目中，除了理论分析，还需要关注工程化的稳定性与可维护性。以下是几个关键实施建议：
以下是一个基于 LangChain 和 Chroma 向量库的基础 RAG 实现流程示例，展示了如何完成文档加载、切分、向量化及检索问答的核心逻辑。
from langchain.document_loaders import DirectoryLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain.embeddings import HuggingFaceEmbeddings
from langchain.vectorstores import Chroma
from langchain.chains import RetrievalQA
from langchain.llms import HuggingFacePipeline
# 1. 加载文档
loader = DirectoryLoader('./data', glob="**/*.txt")
docs = loader.load()
# 2. 文本切分
splitter = RecursiveCharacterTextSplitter(
chunk_size=512,
chunk_overlap=50,
length_function=len
)
chunks = splitter.split_documents(docs)
# 3. 初始化嵌入模型与向量库
embeddings = HuggingFaceEmbeddings(model_name="BAAI/bge-base-zh-v1.5")
vectorstore = Chroma.from_documents(documents=chunks, embedding=embeddings)
# 4. 初始化 LLM (此处以本地部署为例)
llm = HuggingFacePipeline.from_model_id(
model_id="THUDM/chatglm3-6b",
task="text-generation",
pipeline_kwargs={"max_new_tokens": 512}
)
# 5. 构建检索问答链
qa_chain = RetrievalQA.from_chain_type(
llm=llm,
chain_type="stuff",
retriever=vectorstore.as_retriever(search_kwargs={"k": 5})
)
# 6. 执行问答
query = "什么是 RAG 技术？"
result = qa_chain({"query": query})
print(result["result"])
该示例涵盖了从数据准备到最终推理的完整闭环。在实际生产中，需根据硬件资源调整 batch size 和并发数，并结合上述优化策略持续迭代模型效果。
微信公众号「极客日志」，在微信中扫描左侧二维码关注。展示文案：极客日志 zeeklog
使用加密算法（如AES、TripleDES、Rabbit或RC4）加密和解密文本明文。 在线工具，加密/解密文本在线工具，online
生成新的随机RSA私钥和公钥pem证书。 在线工具，RSA密钥对生成器在线工具，online
基于 Mermaid.js 实时预览流程图、时序图等图表，支持源码编辑与即时渲染。 在线工具，Mermaid 预览与可视化编辑在线工具，online
解析常见 curl 参数并生成 fetch、axios、PHP curl 或 Python requests 示例代码。 在线工具，curl 转代码在线工具，online
将字符串编码和解码为其 Base64 格式表示形式即可。 在线工具，Base64 字符串编码/解码在线工具，online
将字符串、文件或图像转换为其 Base64 表示形式。 在线工具，Base64 文件转换器在线工具，online