企业内网RAG知识库评估实战：三大核心指标与Pipeline构建

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

过去半年，团队投入了大量精力构建企业内部研发知识库。除了搭建智能体，我们还系统梳理并导入了涵盖研发架构管理制度、规范以及各类内部平台操作指引的知识内容。然而，一个关键问题始终难以回答：

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

传统的评判方法相当粗糙：

• 看访问量？ 有人点击并不代表内容有用。
• 看采纳率？ 人工抽样覆盖的问题极为有限，且采纳与否完全取决于抽样人的主观判断。
• 问一线同事？ 得到的几句夸奖未必能反映真实效果。

最终，评估往往只能依赖“感觉”。这对于一个科技团队而言，显然不够“工程”与“科学”。

因此，我们希望知识库的评估能够做到：

• 可量化：给出明确的分数。
• 可复现：评估过程能够重复执行。
• 可对比：能够判断知识更新后效果是提升还是下降。

基于这些目标，我们构建了一套知识库评估框架，旨在系统、量化地评测我们的知识库与智能体的回答能力。如果你对如何系统化学习此类知识库与AI技术感兴趣，可以探索相关的技术社区和资源。

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

要评价一个RAG知识库，业界已有较为成熟的评估框架。在我们的探索中，我们首先选择了三个核心指标进行度量。

1. Recall Score（检索召回率）

Recall Score 指标主要用于衡量系统是否检索到了正确的相关知识。知识库应用的第一步是检索，如果检索不准，后续的答案生成就成了无源之水。

我们采用余弦相似度来进行衡量：

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

具体计算如下：
recall_score = cosine_similarity(emb(retrieved), emb(ground_truth))

其中 emb 代表文字经过向量模型编码后的向量值，retrieved 是系统检索到的文档内容，ground_truth 是我们预先设定的基准答案。如果知识库能够正确检索出与真实答案语义一致的内容，Recall Score 的分数就会更高。

2. Correctness（答案正确度）

Correctness 指标用于衡量模型最终生成的回答是否正确。即使检索环节正常，模型在理解和生成答案时仍可能出现偏差或错误。

我们同样使用余弦相似度，将模型的回答与标准答案进行比较：
correctness_score = cosine_similarity(emb(answer), emb(ground_truth))

RecallScore 衡量的是“找得对不对”，而 Correctness 衡量的是如Qwen、DeepSeek等大模型是否“用得对”，即是否正确利用了检索到的材料生成答案。直观区别在于，Correctness 中的 answer 是经过大模型处理后的最终输出。

我们可以通过四个典型场景来加深理解：

• 场景 A：RecallScore 低，Correctness 高
  这反映检索错了，但模型“蒙”出了正确答案。可能是问题过于简单，或模型本身能力过强。这种情况恰恰说明知识库没起作用，反而会误导我们以为效果很好。
• 场景 B：RecallScore 高，Correctness 低
  检索对了，但模型回答错了。这表明知识库建设本身没问题，问题出在模型生成阶段，可能需要考虑更换或优化模型。
• 场景 C：RecallScore 高，Correctness 高
  这是最理想的场景，说明知识库建设得好，模型回答得也准确。
• 场景 D：RecallScore 低，Correctness 低
  这表明从检索到生成的整个链路都有问题，需要回炉重造。

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

Groundedness 指标用于衡量模型的回答多大程度上基于知识库内容，而不是自行“编造”。简而言之，就是用来检测大模型是否产生了“幻觉”。

计算方法是将模型的回答与检索到的文档进行相似度匹配：
groundedness_score = cosine_similarity(emb(answer), emb(retrieved))

Groundedness 分数高，说明回答紧贴知识库内容，可信度高；分数低，则提示存在幻觉风险，需要调整。

仔细观察可以发现，这三个指标本质上就是对 retrieved（检索内容）、answer（模型回答）、ground_truth（标准答案）三者的向量进行两两之间的余弦相似度计算。总结如下：

指标	衡量什么	反映什么
RecallScore	检索是否找到了正确知识	RAG检索环节是否准确
Correctness	生成的回答是否正确	大模型对问题的理解与表达是否准确
Groundedness	回答是否基于知识库内容	大模型是否存在幻觉

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

整个评测系统采用Python编写，并在内网环境运行。其总体架构复用了知识系统自身的基础能力，因此非常轻量且易于维护。

系统主要由四个核心模块构成，具体的设计与架构实现可以参考相关的技术文档。

1. retriever.py：向量检索模块

在向量模型选择上，我们使用了与内部知识库一致的 bge-m3向量模型，确保评估过程与真实场景的一致性。

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

此模块模拟真实用户行为，通过调用Dify等知识库应用的标准问答接口，获取模型的回答。

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

针对每个问题，该模块会计算前述的Recall Score、Correctness和Groundedness三项评分。

4. main.py：驱动完整测试集运行

该模块负责组织测试流程，串联以上模块，完成对整个问题集的自动化评测。完整的项目代码可以参考：https://github.com/dumbray/rag_eval

四、评估结果与优化方向

我们首先梳理了20道关于内部研发平台的高频问题，作为第一版基准测试集。实际运行后的平均得分如下：

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

整体表现只能说中规中矩，有显著的提升空间。这个分数分布也与之前人工抽样的主观感受基本吻合。

• 检索准确率（0.54） 偏低，说明检索环节（如向量化、分块、检索策略）还需要加强。
• 回答正确率（0.75） 相对较好，说明所选大模型的生成能力比较稳定。
• 基于知识库程度（0.59） 表明模型回答中仍存在一定比例的幻觉内容。

基于首次评估的结果，我们计划从以下几个方向持续优化：

1. 扩充基准问题集

当前的20道题属于“小样本”，未来将持续扩展：

• 将问题数量扩充至100+。
• 将问题覆盖范围从单一平台扩展到工具链、流程规范等全研发领域。
• 从实际的用户操作日志、内部问答群中收集真实问题。
  此外，可以考虑让大模型自动从知识库中抽取潜在问题，以自动化方式扩充问题集。

2. 扩展评估指标

目前主要依赖向量相似度，未来可以引入更丰富的评估维度：

• 引入基于LLM的一致性判断（例如GPT-Score）。
• 引入自然语言推理模型来判断回答是否“逻辑正确”。
• 尝试使用更适合排序任务的Ranking模型进行更精细的评估。

五、总结

通过构建这套可量化的评估体系，我们将知识库的建设效果从主观的“感觉不错”，转变为了可度量、可追踪、可优化的工程实践。当然，这套体系刚刚开始运行，后续还有很长的路要走。知识库技术与评估方法本身也在快速发展，我们期待与广大开发者在云栈社区等平台交流，持续迭代，未来有新的实践成果再与大家分享。