落地实践｜ 92% 的准确率！如何用 DB-GPT 打造企业级的知识库问答系统

搭建一个高效的知识库问答系统，远不止是扔一堆文档给大模型那么简单。从文档预处理、向量化召回，到Prompt设计和LLM选型，每个环节的细微偏差，叠加起来就是准确率从92%跌到50%以下的差距。下面这套方法论，来自真实场景的多次踩坑与调优，希望能给正在落地的团队一些参考。

PART 1
CVP STACK

什么是CVP STACK？

CVP这个缩写，拆开来看其实很直观：

• C
  代表以ChatGPT为代表的大语言模型。目前通用模型里表现最好的是GPT-4，但它的价格是ChatGPT-3.5的20倍。本地部署方面，百川智能的Baichuan2-13B-Chat效果不错。实践下来，如果知识库不涉及隐私数据，直接调用ChatGPT-3.5性价比最高；若涉及隐私，用DB-GPT本地部署Baichuan2-13B-Chat做推理，效果同样令人满意。

• V
  是Vector Database（向量数据库）的缩写。它跟传统数据库完全不同——专门用来存储和管理向量数据，通过把向量映射到高维空间并构建索引结构，来支撑高效的相似度查询。

• P
  即Prompt。这里说的Prompt不单单指提示词，而是提示工程与产品交互的广义概念。常见的Prompt包括zero-shot（不举例子）、one-shot（举一个例子）和few-shot（举少量例子，如5、10、15个）。经验表明，few-shot的效果通常明显优于前两者。

为什么要选择CVP STACK？

企业借助LLM提升生产力，是当前大模型落地的重要方向。目前围绕这个方向的探索大致分为两大流派：

主张把垂域内容、私域内容塞进数据集，微调甚至重训LLM，期望模型具备端到端能力——也就是单模型架构。
则引入向量数据库作为LLM的外部记忆体，采用通用LLM集成领域知识库的方案来提供服务，也就是CVP架构。

相比单模型架构，CVP架构在可扩展性、实时性和成本三个维度都更具优势。

• 传统流派需要把垂域、私域内容更新到模型参数里，每次更新都得微调LLM。这不仅要消耗大量计算资源，还得由专业人员操刀，结果却常常不稳定——花上数周微调出的模型可能还不如初始版本，甚至出现负优化。这个过程被形象地称为“炼丹”。

• 新兴流派引入向量库作为LLM的外部记忆体，专门存储垂域和私域知识。知识更新只需把实时内容添加到向量库中即可，完全不需要微调LLM。

• 在我们AI问答助手产品的落地实践中发现，即便CVP架构依赖本地部署的Baichuan2-13B-Chat，其问答效果也能显著优于GPT-4的单模型架构。当然，这套架构的核心在于垂域、私域知识库的构建——

  知识库的质量
  直接决定了CVP架构的问答效果。

PART 2
AI 工作助手的工作原理

AI问答助手的完整流程如下：

文档预处理 → 文档切割 → Embedding存储到向量数据库 → 用户提问 → 将问题用同样引擎做Embedding → 问题向量化 → 到知识库所在向量数据库中进行相似匹配 → 召回得分最高的k个Chunks → 将用户原始提问文本、用户的prompt、这k个Chunks三者输入本地大模型（LLM） → 返回给用户问题的回答。

理解了整体流程，接下来拆解每个核心环节，方便后续做体系化调优。

文档预处理

文档在上传知识库之前，需要做预处理工作。处理准则是：能系统化的步骤就要系统化；不能系统化的步骤，则按照SOP人工处理后，确保达到入库标准。不满足标准的文档坚决不允许入库，这样才能保证知识库的整体质量。

文档预处理阶段需要重点考虑以下几个方面：

•

：构建知识库时发现，有的文档中英文混杂，比如同一行左边是中文简体、右边是英文，这种情况需要删除英文，只保留中文简体；中文繁体则需要转为简体；英文文档也要转为中文简体。这样做的原因是，不同Embedding引擎对中英文、繁简体的支持程度不同，如果文档不做处理，引擎会把中英文切到同一个chunk里，向量化之后一半可能是乱码，一半是没有价值的数据。

•

：测试结果显示，.docx格式的效果优于.pdf格式，因此推荐使用.docx格式，需要将.pdf格式转换为.docx。

•

：文件名控制在10字左右，使用简洁明了的词语或短语，避免使用无意义的数字、符号或缩写。

文档切割

：
标题命名应控制在5字左右，简洁明了，避免无意义的数字、符号或缩写。对于较大的文档，还需要对三级、四级标题进行打标和规整。

：合并段落的阈值默认是100个字——不满足100个字的段落会被合并到下一个段落。这个阈值需要根据文档切割的chunk_size大小来调整。chunk_size控制每个切割块的字符长度，DB-GPT支持调整这个参数以及文档切割方法，目前需要在代码中配置，默认使用的是zh_core_web_sm。

：为了防止大文档出现召回准确性问题，我们会标注每个chunk来自哪个文档的哪个段落，标注格式为“文档名+一级标题+二级标题”。这样做之后，召回准确性会有显著提升。

Embedding 阶段

评估Embedding阶段效果的标准，通常采用Top5和Top10的召回准确率。TopN召回准确率的计算公式是：TopN条chunk包含答案的问题数除以总问题数。

从实际应用经验来看，目前对于中文文档，

Embedding引擎效果最佳。

关于向量数据库的选型，基于实践经验整理出了一份参考建议，大家可以结合实际情况来选择。

召回TOP-K阶段

K值的选择：当文档内容足够丰富（文档数>10）时，可以调大K值；文档内容较少时，则要调小K值。具体数值需要根据实际使用场景不断测试。

这里必须格外注意：K乘以chunk_size的结果，不能超过LLM允许的最大输入tokens。假设用Baichuan-13B模型，其最大输入tokens小于4k，那么K和chunk_size的乘积就不能超过4k。

Prompt

知识库问答场景下的Prompt工程相对简单，不需要太多调整。不同知识库可以固化一个通用的Prompt即可。

LLM

对于中文知识库问答，目前表现最好的开源LLM是Baichuan2-13B-Chat。正如前面提到的，在CVP架构中，不需要太强的LLM就能取得很好的效果。以Baichuan2-13B-Chat作为本地LLM，在AI问答助手场景中，可以获得85%以上的准确率；在实际使用场景中，这一数字已经达到了

。

PART 3
知识库构建理论

最初构建AI问答知识库时，为了提高用户体验、减少用户在不同知识库之间切换的操作，我们把所有文档都放到了同一个知识库里——包括宏观政策、经济和行业调研分析的文档。但效果并不理想。分析badcase后发现，用户问宏观政策环境问题时，会召回到财报中讲述宏观政策环境对企业经营影响的内容；用户问某个企业经营状况时，又会召回到大量宏观政策经济的内容。知识互相交织，导致准确性大打折扣。

后来我们拆分成三个知识库，效果有了明显改善。但深入分析badcase后发现，用户对宏观政策库和经济库的问题，往往需要结合两者才能完美回答。而材料本身也确实如此——宏观政策中夹杂经济内容，经济材料中又涉及宏观政策。最终我们调整成两个库：宏观库和行业库。效果达到最优，问答准确率达到92%。

在这个过程中我们发现，知识库构建遇到的问题，答案基本都能在数仓建模中找到。上述案例对应的是数仓建模中“分主题域”的理论：域内高内聚、域间低耦合。推广到知识库的分库理论就是：

。也就是说，划分到同一个知识库的文档和知识，内容之间要有较强的相似度；而不同知识库之间，要尽量避免内容重叠或相似。

评分标准

效果展示

PART 4
未来的挑战和思路

超大文档集下，是否需要三级标题打标？打标内容过多会不会冲淡真实信息熵？

对于超大文档集，

，但打标质量必须特别关注：打标要言简意赅，尽可能精简。如果无法再精简，就需要相应地增大chunk_size的大小，确保打标部分占比不超过chunk的10%，防止打标内容覆盖掉真实信息。

文档中的表格和图片指标如何识别？

DB-GPT目前不识别文档中的图片，可以通过OCR方式将图片单独抽离出来处理。但测试结果显示，OCR识别还达不到落地应用的效果。因此要求：在图片旁添加必要的文字说明，特别是包含指标值的图片，需要人工将其解析成文字。

后续如何做推理框架升级、推理提速？

目前DB-GPT使用的是FastChat作为推理框架，推理速度和并发能力还有很大的提升空间。团队正在调研vLLM，希望能在Q4将其整合到DB-GPT工程中。