让知识库变得可度量：RAG知识库评估方法实践

得分不低也不高，这说明前期的投入没有白费，但也告知我们不能再靠感觉走下去，得用数据说话。我们把这次评测当成一次“体检”：检查看看知识库和智能体在真刀真枪的场景里到底能不能派上用场，什么地方撑得住，什么地方得动手术。

先说具体怎么跑的。选了20道高频的研发平台问题做第一轮基准测试，每道题会输出三项分数，分别衡量检索命中、模型回答质量和回答的依据性。评测流程和真实用户体验尽量一致，在内网用Python把接口串起来，调用路径复刻用户用Dify问智能体的场景，检索和生成都用同一套向量模型——bge-m3，保证向量空间不打架。每次问答我们把retrieved、answer、ground_truth之间的向量类似度都算出来，量化成余弦类似度分数，方便后面做统计和排查。

为什么要分成三项来量化？这事儿像拆开一台机子看零部件。第一项看检索能不能把正确片段找出来，这是“有没有料”的问题。第二项看模型拿到这些材料后，输出的答案和标准答案有多接近，这能区分是检索没问题还是生成出问题。第三项看回答里有没有明显引用检索到的文档，用来判断答案是不是凭空捏的。把这三条链路分开看，能把症结点钉得更准，不至于把问题统统归咎到“感觉不好用”上。

现场结果是中等偏上。人工抽样的采纳率和用户体验感受跟这个分数差不多。具体表现会落在四种情况里：一种是检索没找到但模型正好蒙对了——这最危险，容易误导人说知识库做得好；还有检索到位但模型答错，这说明知识库有料但生成环节得改；再就是检索和生成都到位，这是最理想的状态；最后检索不到模型也答不上来，说明检索链路要重建。把这些情形拆开看，就能针对性地调整策略，而不是打个补丁式的修修补补。

做这套评估的背景也说清楚。过去半年团队把组织里的流程、平台指引、各类操作文档都往知识库塞，目标是让研发同事凭借知识库少问人、多自助。但以往评估常靠使用率、点赞数或者“感觉好不好”来判断，这在工程化管理里不够严谨。于是就想要一套可复现、可量化的评估框架，明确每一环节的表现，便于持续改善。

实现上也有一些细节。评测系统全程在内网跑，自动化脚本把重复流程标准化，节省人为操作。我们把检索-生成-比对的流程链条用代码串起来，有些样板代码是让AI先帮写一遍，节省了不少工时。每次跑完都会把三项余弦类似度记录下来，方便事后做分布分析、找出薄弱模块。目前的匹配方式还是纯向量类似度，这方法简单但不是万能，后面会思考把更多维度加进来，列如检索段落覆盖率、答案生成置信度、还有级联检索策略的引入，这些都需要一步步验证成本和效果。

接下来两条路要同时走。第一条，把问题库从目前的几十道扩到几百甚至上千道，样本规模上去了，评估结论才稳。第二条，往自动化方向走，让大模型从知识库里抽题、生成候选问题池，减少人工偏差。把题目和场景多样化了，才能发现系统在不同类型问题上是不是一视同仁，也能看到边界情况。

说到改善优先级，我觉得先把检索打磨好最划算。就像开车先检查发动机，发动机不给力，其他调教都白搭。检索命中率上去了，模型就有可靠的材料可用；如果检索不稳，就算换最牛的生成模型也可能答不上来。另一方面，生成端的策略也不能放松——需要做模型切换实验、prompt策略优化，还有答案置信度的阈值控制，避免模型“自作主张”。

现场做这事给人的感觉挺实际的。把问题拆开看，能明确下一步要干啥，这比以前凭工作经验判断好太多。下一步是把问题集扩大、把检索逻辑反复打磨、把生成环节的模型和prompt策略多试几轮，把这些流程建立成日常监控项。工作节奏会是先把低成本能做的改掉，再针对重灾区投入资源。这样一步步把可观测性和稳定性提高，不再靠单凭“感觉”判断系统是否达标。