一、测试背景

在单样本测试阶段，我已经初步比较了传统 RAG 和 GraphRAG 在部分问题上的表现。

但是，单样本测试存在很强的偶然性。某个问题中 GraphRAG 表现更好，并不能说明 GraphRAG 整体更优。某个问题中传统 RAG 表现更好，也不能直接否定 GraphRAG 的价值。

因此，需要构建一个相对系统化的测试集，通过批量测试来比较不同 RAG 方法的整体效果。本阶段的目标就是从人工观察走向量化评估，为后续优化检索策略提供依据。

二、测试集构建思路

本项目面向的是 408 考研问答场景，因此测试集需要尽量覆盖计算机组成原理、操作系统、数据结构、计算机网络等多个科目。同时，问题类型也不能只包含简单定义题，还应该包括比较题、推理题和综合分析题。

最终测试集主要分为两类。

第一类是选择题。选择题具有明确标准答案，适合用于客观准确率评估。模型只需要从 A、B、C、D 中选择一个选项，脚本可以直接判断结果是否正确。

第二类是主观问答题。主观题更接近真实用户使用场景，例如“为什么”“如何理解”“二者有什么区别”这类问题。它们无法简单通过字符串匹配判断好坏，因此需要引入大模型作为裁判进行辅助评估。

测试集来源上，一部分参考了开源 408 RAG 项目中的 questions_400.json，另一部分则结合已有知识库内容，通过大模型生成。生成后的问题按照类型进行划分，包括 Factoid、Comparison、Reasoning 等，以便观察不同检索方式在不同问题类型上的表现。

三、评估对象

为了更全面地比较检索效果，我在评估脚本中设计了三种模式。

第一种是 naive 模式，也就是传统向量 RAG。它从 ChromaDB 中召回与问题最相似的文本片段，再将这些片段作为上下文交给大模型回答。

第二种是 graph 模式，也就是 GraphRAG。它通过 LightRAG 读取已经构建好的知识图谱，并使用 hybrid 检索方式召回与问题相关的实体、关系和文本内容。

第三种是 hybrid 模式，也就是混合检索。它同时调用传统向量检索和 GraphRAG 检索，将两部分结果共同提供给大模型。这样做的目的是尝试结合两者优势：传统 RAG 提供更直接的原文片段，GraphRAG 提供更结构化的知识关系。

四、选择题评估方法

选择题评估相对直接。

在评估脚本中，每道题会被拼接成完整问题，包括题干和四个选项。然后系统会根据当前模式进行检索，并将检索结果与题目一起交给大模型。

为了便于自动判断，Prompt 中会明确要求模型只输出 A/B/C/D 中的一个字母，不能输出解释、标点或额外文本。得到模型回答后，脚本使用正则表达式提取最终选项，并与标准答案进行比较。

最终指标是准确率，即：

“回答正确的题目数量 / 测试题目总数”。

同时，脚本还会按照科目或类别统计准确率，方便观察不同知识模块上的表现差异。例如某种检索方式可能在数据结构题目上表现较好，但在组成原理题目上表现一般。

五、主观题评估方法

主观问答题无法只用准确率衡量。因为同一个问题可能有多种合理表达方式，即使模型回答和标准答案文字不同，也可能是正确的。因此，我采用了两种主观题评估方式。

第一种是 LLM-as-Judge 绝对评分。

对于每个问题，评估脚本会将问题、标准答案、检索上下文和模型实际回答一起交给裁判模型。裁判模型从以下几个维度进行评分：

上下文相关性：检索出的资料是否与问题相关。

忠实度：回答是否忠实于检索资料，是否存在明显幻觉。

正确性：回答是否符合标准答案和计算机专业知识。

此外，脚本还会计算 ROUGE-L 分数，作为文本重合度的辅助指标。不过对于主观问答来说，ROUGE-L 只能作为参考，因为高质量回答不一定和标准答案有很高的字面重合。

第二种是成对比较。

对于同一道主观题，系统分别使用 naive、graph、hybrid 三种模式生成回答。然后将三个回答同时交给裁判模型，让它选择其中最符合标准答案、逻辑最严密、事实最准确的一个。

六、阶段性结论

通过构建测试集和评估脚本，RAG 效果验证从单个样本观察进入了批量评估阶段。

此外，测试集评估也为后续优化提供了依据。后面可以继续扩大测试集规模，细分不同科目的表现，优化实体抽取 Prompt，并改进图谱检索结果的筛选方式，使 GraphRAG 在真正适合它的场景中发挥更稳定的效果。