一、背景与目的：知识库建设不能再「凭感觉」了

过去半年我们花了许多工夫来建设企业内部研发知识库，除了智能体的搭建，在知识输入上，我们梳理导入了包含研发架构管理制度与规范、各类内部平台操作与引导的知识内容，但始终不好回答一个关键问题：

内部知识库到底建设得好不好？有没有真正协助到研发？

以前的评判方法超级粗糙：

• 看访问量？有人点了不代表有用
• 看采纳率？人工抽样能覆盖的问题太有限，而且采不采纳完全看抽样人主观判断
• 问一线同事？夸你两句你还当真了

最终只能靠「感觉」来判断效果，而这在一个科技团队内显然不那么「工程」与「科学」。

所以我们希望知识库的评估能够：

• 可量化（给出明确的分数）
• 可复现（能重复执行）
• 可对比（知道新知识有没有提升效果）

因此，我们构建了一套知识库评估框架，系统地评测量化我们的知识库与智能体回答能力。

二、指标体系：用三项核心算法量化知识库效果

要评价一个RAG知识库，业内已经有了比较成熟的评估框架，在探索中我们先选了三个核心指标：

1. Recall Score（检索召回率）

Recall Score 指标主要用来衡量系统是否检索到了正确的知识。构建知识库的第一步是检索，检索不准，后续生成就无从谈起。我们采用了余弦类似度（cosine similarity）来作衡量：

余弦类似性通过测量两个向量的夹角的余弦值来度量它们之间的类似性。两个向量有一样的指向时，余弦类似度的值为1；两个向量夹角为90°时，余弦类似度的值为0；两个向量指向完全相反的方向时，余弦类似度的值为-1。

其中emb代表文字经过向量模型后的向量值，retrieved是检索到的文档内容，ground_truth是我们写的基准答案，如果知识库能够正确检索出与真实答案语义一致的内容，RecallScore 就会更高。

2. Correctness（答案正确度）

Correctness 指标用来衡量模型回答是否正确。即便检索正常，模型仍可能出现表达偏差或理解不准。我们使用同样的余弦类似度，将模型回答与标准答案比较：

上一个RecallScore指标是用来衡量找得对不对，而Correctness是用来衡量如Qwen3、Deepseek等大模型是否正确利用了检索出来的材料做出回答。直观区别就是Correctness中的answer是经过了大模型后的输出答案。

有四个场景可以进一步加深理解：

• 场景 A：RecallScore低，Correctness高

反映的是检索错了，但模型乱答出了正确内容（就是蒙对）。要么是问题超级简单，要么是模型本身能力很强，这种情况说明知识库白建了，而且还会让我们误以为自己做得很好。

• 场景 B：RecallScore高，Correctness低

检索对了，但模型回答错了。这说明知识库建设没问题，问题出在模型生成阶段，可以思考换模型。

• 场景 C：RecallScore高，Correctness高

这就是我们想要的场景，知识库建设得好，模型回答得也好。

• 场景 D：RecallScore低，Correctness高

这说明知识库检索链路错误 ，导致模型没有拿到正确文档 ，并且模型也没办法推理出正确答案。好好回炉重建吧。

3. Groundedness（基于知识库程度）

Groundedness 指标用来衡量模型回答是否引用了知识库，而不是瞎编。简而言之就是用来衡量是否有「幻觉」，大模型是否自己加戏了。我们将模型回答与检索文档进行类似度匹配：

高Groundedness说明回答基于知识库，可信度高；低Groundedness说明有幻觉风险，需要调整。

仔细看就会发现，这三个指标就是对retrieved、answer、ground_truth这三个向量值C32求余弦，总结如下：

指标	衡量什么	反映什么
RecallScore	检索是否找到正确知识	RAG是否准确
Correctness	回答是否正确	大模型对问题理解与表达是否准确
Groundedness	回答是否基于知识	大模型是否有幻觉

三、系统建设：一套轻量可扩展的评估Pipeline

整个评测系统采用Python编写，在内网运行。总体架构沿用了知识系统自身的基础能力，因此超级轻量、易维护。（一句话就是，接口现成的，代码AI写的，vibe coding我谢谢你）

有四个核心模块：

1. retriever.py：向量检索

在向量模型上，用与内部知识库一致的bge-m3向量模型，确保评估一致性。

2. generator.py：调用 Dify 知识库问答接口

实际就是用Dify走一遍和真实用户一致的流程，都是标准接口。

3. evaluator.py：基于向量的三项指标计算

每个问题都会输出三项评分，算三个余弦值，代码就不贴了。

4. main.py：跑一遍完整测试集

也不赘述了。有需要可以去搂一眼：
https://github.com/dumbray/rag_eval

四、评估结果与优化方向

我们先梳理了20道内部研发平台的高频问题，作为第一版benchmark，实际跑下来的平均分：

• Recall Score：0.54
• Correctness：0.75
• Groundedness：0.59

整体表现只能说还行吧，提升空间还是很大的，而且这个分数跟人工抽样采纳率和用户的实际体验感受也差不多。

• 检索准确率（0.54）说明检索还需要增强
• 回答正确率（0.75）说明模型生成能力相对稳定，回答质量是可以了
• Groundedness （0.59）说明还是有少量幻觉存在的

未来我们计划从以下几方面持续演进：

1. 扩充基准问题集

当前20道题还属于「小样本」，未来会持续扩展：

• 问题数量起码要到100+
• 问题覆盖范围要扩展至平台、工具链、流程规范等全范围
• 从实际日志、问答群中收集真实问题

还有就是现有问题是人工写的，后续也可以让大模型自动从知识库中抽取问题扩充问题集

2. 扩展评估指标

目前是纯向量类似度，但未来可以思考：

• 引入 LLM-based 的一致性判断（如 GPT-Score）
• 引入 NLI（自然语言推理）判断回答是否“逻辑正确”
• 使用更适合评估的 Ranking 模型

（这些都是大模型跟我说的，有没有可行性之后再说吧）