“语义缓存层”（1）—— 问答对适合直接丢知识库吗？-优快云博客

最近给一个大规模代码仓库构建了一个问答智能体，知识库的范围包括大概18个子仓库，数据大概包括三类：

历史问答对（后面我会把它们叫做QA），来自开源共建答疑群，大约50条；
开发文档，主要是设计文档，包括各个板块，加起来大约七八十个doc文档；
开源代码仓库，二十多个.md文档，还有源代码；

整个过程非常简单。用户提出一个问题，语言模型进行意图识别，提取出相关的搜索关键词，然后用混合检索搜索到最匹配的5个文档切片，整合到最终的提示中，输入到Deepseek-3.2生成答案。

一、数据处理

对于开发文档来说，直接把文档切片然后丢进知识库的效果很出奇的好，按照小标题把它们切成小片，然后转成向量，检索最相关的部分，最后让模型生成答案。对于一个RAG系统来说，数据量其实也不算很大，我的Deepseek-3.2几乎很少在关于开发文档的回答犯错。

不过像是QA和源代码这种东西，把它们一股脑丢到知识库里就会比较为难了。从群聊里整理的QA对：

有答也有问：“答”的部分塞进知识库没有什么问题，但是“问”的部分看起来在意图识别步骤处理更好；
彼此独立：按照RAG“一个语义上独立的段落分一块”的原则来分，似乎应该扔几十个分块（chunk）进去，但是召回文档数一般是3~10。单独召回一个小分块看起来知识量不多，很浪费召回文档数；
简洁干练：问的短，回的也短。很多重复的问题只要找到那个历史记录，用户的问题就能被马上解决。

源代码的处理会更复杂，我们在以后会详细讨论。

在MVP阶段我考虑了这个问题，不过还是决定先不作复杂处理，而是直接把它们一股脑扔进markdown里，和剩下的文档一起索引，先实现功能闭环，后续再作优化。

二、初版内部测试

链路跑通之后，内部测试结果居然很不错，在内部的问答基准测试（也是约50条问-答测试，由我手工标注对/错）中能够有78%的准确率。

我研究了智能体的回答，其中有两个问题让我非常不满意。

1. 回答简单高频的问题消耗太多

测试集里有这样一个简单的问题：

“部署一个这样的系统需要多少计算资源？”

在我最初的流程里，这样的问题依然会沿着整个RAG链路走。搜索整个文档库，返回多个片段，然后让Deepseek-3.2进行长达20秒的深度思考，然后给出一个滴（you）水（chou）不（you）漏（chang）的回答。

用户需要花费一分钟打字、看到输出，需要花费额外的时间看完整篇滴水不漏的800字回答，还要提炼出哪些是他关心的东西。但是其实他们不需要报告，只是想要几个数字。

而我的系统要为一个简单的问题花费16k tokens，召回5份文档，其中最有用的不超过20个字，也就是多少核多少内存，需要主备部署还是集群部署。

2. 模型被放在一起的QA对误导

有一个很有趣的错误，它的问题是这样的：

“平板上的数据是从哪里获取的？”

我们答疑群的历史QA里回答过控制中心的平板，也回答过手持的平板。虽然都是“平板”，但是它们的业务含义是完全不同的，模型找到了我的QA文档，然后把这些“平板”混为一谈。这些信息误导了模型作出了错误回答。

原则上来说，我应该按照业务语义把这两个“平板”分开。也许我会有两个或者更多markdown文档，它们是使得这些问题互不干扰的最佳分割。

不过我在想的是，既然每个问题之间可能会相互干扰，那么最好的办法可能还是让他们独自成为一个文档分块，然后单独检索回来。至于分割，也许后面再说，我现在最关心的其实是怎么把混在一起的那个QA文档拆出来。

三、总结

到目前为止都只是上下文工程（Context Engineering）的考量，并非是RAG本身。和普通的文档不同，问答对包含用户意图和验证后答案的知识形式值得更特殊的对待。在下一篇文章里，我会介绍一下我在探索业界对于这些知识的处理，总结这些发现，最后我们会讨论这些东西是如何发展成一个专门的“语义缓存层”的。