为什么要先建测试集这个系列要做一件事：横向对比六个开源 RAG 方案（LightRAG、GraphRAG、HippoRAG、HyperGraphRAG、RAG-Anything、gbrain），给出选型建议。但"横向对比"有一个前提：同一套问题，同一套评分标准。如果每篇文章都用自己的文档、自己出的题，结果没有可比性——你测 LightRAG 用的是 API 文档，测 GraphRAG 用的是论文，这不叫对比，叫各显神通。所以在跑第一个方案之前，先把测试集建好。这篇文章记录这件事的完整过程。为什么不直接用 BEIR第一个直觉是去找现成的标准数据集。RAG 评测领域最常引用的是BEIR——一个包含 18 个子集的检索基准，覆盖问答、事实核查、医疗文献等。但 BEIR 有一个根本性问题：它是学术检索任务，和企业知识库的实际使用场景有明显的分布差距。维度BEIR企业知识库文档类型学术论文、维基百科API 文档、操作手册、技术规范问题类型事实核查、论文检索“怎么配置”、“为什么报错”、“哪个方案更合适”拒答能力无（假设答案一定存在）必须：文档没有的内容不能瞎编语言全英文中英混合用 BEIR 测企业 RAG，就像用高考题去测岗位面试能力——题型对不上，分数没有参考价值。正确的做法：用与目标场景同分布的文档，合成专属测试集。文档来源的选择测试集要能代表"企业技术文档"这个类别。选了两套开源项目的官方文档：LightRAG 官方文档（13 个 Markdown）：API 服务配置、Docker 部署、多站点部署文件处理流程、分块策略、解析器开发Milvus 配置、离线部署、角色 LLM 配置graphrag 官方文档（17 个 Markdown）：架构设计、默认数据流、输入输出格式索引配置、查询方式、提示词调优CLI 使用、可视化工具这两套文档的特点恰好是企业技术文档的典型形态：有操作步骤、有配置示例、有跨文档的依赖关系。而且 LightRAG 和 graphrag 本身就是后续要测的方案，用它们的文档做测试集，既自洽又有实战代表性。共 30 个有效文档（过滤了内容少于 200 字符的占位文件）。三类问题的设计逻辑测试集需要覆盖三种典型的失败模式：类型一：单跳事实查询（50%，50题）答案直接在某一个文档里，不需要跨文档推理。测的是：检索的基础召回能力——给定问题，能不能找到包含答案的文档片段？真实样例：Q: What are the two main categories of configuration settings in the LightRAG Docker Deployment? A: Server Configuration and LLM Configuration src