传统 RAG 评估依赖人工标注的”标准答案”，但在 GraphRAG 时代，这套方法正在失去意义。
什么是 Gold Answer？
Gold Answer（黄金答案）是指人工标注的”标准正确答案”。在传统 NLP 和 RAG 系统评估中，我们通常这样做：
- 准备一批测试问题
- 人工写出每个问题的”正确答案”
- 让系统回答同样的问题
- 对比系统答案和 Gold Answer，计算 F1、BLEU、ROUGE 等分数
这套方法在搜索引擎和简单问答系统中运行了很多年。但在 GraphRAG 这类复杂系统中，Gold Answer 的价值正在急剧下降。
知识图谱持续演化，Gold Answer 跟不上
问题本质
GraphRAG 的核心是知识图谱。图谱不是静态的——每次文档更新、每次重新抽取实体关系，图谱都在变化。今天的”正确答案”，明天可能就过时了。
举个例子
假设你的公司有一份内部技术架构文档：
- 1 月版本：文档写着”订单服务使用 MySQL 数据库”
- 3 月版本：架构升级，改成了”订单服务使用 PostgreSQL + Redis 缓存”
你在 1 月标注的 Gold Answer 是：
Q: 订单服务用什么数据库？
A: MySQL
到了 3 月，GraphRAG 系统重新索引了新文档，正确回答了”PostgreSQL + Redis”。但如果你还拿 1 月的 Gold Answer 去评估，系统反而会被判”错误”。
更现实的场景
在企业内部，文档更新频率远比想象中高：
- API 文档每周都在改
- 组织架构每季度调整
- 技术选型每半年可能翻新一次
每次文档更新后，你都需要重新标注 Gold Answer。一个有 500 个测试问题的评估集，每次更新可能有 30% 的答案需要修改——这意味着每次要重新审核 150 个答案。
人工标注 Gold Answer 成本极高且不可靠
问题本质
GraphRAG 处理的问题往往是多跳推理、跨文档关联的复杂问题。对于这类问题，连人类专家都很难给出一个”唯一正确”的答案。
举个例子
假设问题是：
“张三负责的项目中，哪些使用了已经 EOL（End of Life）的技术栈？”
要回答这个问题，标注人员需要：
- 找到张三负责哪些项目（可能分散在 5 份文档中）
- 找到每个项目的技术栈（又是另外几份文档）
- 判断哪些技术栈已经 EOL（需要查外部信息）
- 综合以上信息给出答案
假设真实情况是张三负责 4 个项目，其中 3 个用了 EOL 技术栈。标注员经过 1 小时的文档翻阅，写出了 Gold Answer：
项目 A（Spring Boot 2.5）、项目 B（Log4j 1.x）、项目 C（Python 2.7）
但标注员漏掉了项目 D——因为张三对项目 D 的负责关系写在一份会议纪要里，而不是正式的项目分配表中。
现在来看评估结果：
| 系统 | 回答 | 对比 Gold Answer 的得分 |
|---|---|---|
| 普通 RAG | 找到了项目 A、B（漏了 C） | 召回率 2/3 = 0.67 |
| GraphRAG | 找到了项目 A、B、C、D（通过会议纪要中的关系推理找到了 D） | 召回率 3/3 = 1.0，但精确率 3/4 = 0.75（D 被判为”多余”） |
讽刺的是：GraphRAG 因为比 Gold Answer 还要正确，反而被扣了分。它通过图谱中的关系链（张三 → 参会 → 会议决议 → 负责项目 D）找到了标注员都遗漏的信息，但在评估框架里，这个”多出来的正确答案”被当成了错误。
最终 F1 分数：
– 普通 RAG：F1 = 0.80
– GraphRAG：F1 = 0.86
GraphRAG 明明找得更全、更准，分数优势却微乎其微——甚至在某些评估设置下（比如严格精确匹配），分数可能比普通 RAG 还低。Gold Answer 的天花板限制了对更优系统的识别能力。
成本账
标注一个复杂的 GraphRAG 测试问题，一个领域专家可能需要 30-60 分钟（需要翻阅多份文档、交叉验证）。如果你需要 200 个测试问题，那就是 100-200 小时的专家时间。而且这些答案的保质期可能只有几个月（参见论点一）。
GraphRAG 的答案形式天然多样
问题本质
传统 RAG 往往回答事实性问题（”X 是什么”），答案相对固定。但 GraphRAG 擅长的是关系推理和综合分析，这类问题的”正确答案”本身就有多种合理表达。
举个例子
问题：
“我们的微服务架构中，哪些服务之间存在循环依赖？”
GraphRAG 可能回答：
答案 A：服务 A → 服务 B → 服务 C → 服务 A 形成循环；服务 D 和服务 E 互相调用。
答案 B：存在两组循环依赖：(1) A-B-C 三角循环 (2) D-E 双向依赖。建议优先解耦 A-B-C 循环，因为涉及核心交易链路。
答案 C：检测到循环依赖路径：A→B→C→A。另外 D↔E 存在双向调用，但由于是异步消息，实际影响较小。
三个答案都是”正确”的，但侧重点不同。用任何一个作为 Gold Answer，都会不公平地惩罚其他同样正确的回答。
传统指标的失效
用 ROUGE 分数对比上面三个答案：
- 答案 A vs 答案 B：ROUGE-L 可能只有 0.3（措辞完全不同）
- 答案 A vs 答案 C：ROUGE-L 可能有 0.5（有部分重叠）
但从信息正确性来看，三个答案都应该得满分。Gold Answer + 文本相似度指标的组合，在这里完全失效了。
LLM-as-Judge 正在取代 Gold Answer
问题本质
既然 Gold Answer 有这么多问题，业界正在转向一种新的评估范式：用 LLM 作为评判者（LLM-as-Judge），直接评估答案的质量，而不是和”标准答案”做文本对比。
举个例子
传统方式：
系统答案: "PostgreSQL + Redis"
Gold Answer: "MySQL"
ROUGE 分数: 0.0 → 判定为错误 ❌
LLM-as-Judge 方式：
问题: "订单服务用什么数据库？"
系统答案: "PostgreSQL + Redis"
参考文档: [最新架构文档，明确写了 PostgreSQL + Redis]
LLM 评判: 答案与文档一致，信息准确，得分 5/5 ✅
LLM-as-Judge 的优势：
| 维度 | Gold Answer | LLM-as-Judge |
|---|---|---|
| 是否需要人工标注 | 需要大量人工 | 不需要 |
| 能否适应文档更新 | 需要重新标注 | 自动适应（参考最新文档） |
| 能否处理多种正确表达 | 不能 | 能（理解语义等价） |
| 评估成本 | 高（人工） | 低（API 调用） |
| 评估速度 | 慢（天/周） | 快（分钟） |
GraphRAG 的评估维度远超”答案正确性”
问题本质
Gold Answer 只能评估一个维度：答案内容是否正确。但 GraphRAG 系统的质量取决于很多其他因素，这些因素 Gold Answer 完全无法衡量。
举个例子
同一个问题，两个 GraphRAG 系统都给出了正确答案，但质量天差地别：
系统 A 的回答：
张三负责项目 X，使用了 Spring Boot 2.5（已 EOL）。
系统 B 的回答：
张三负责项目 X，使用了 Spring Boot 2.5（已于 2023 年 11 月停止维护）。此外，该项目还依赖 Log4j 1.x（2015 年 EOL，存在已知安全漏洞 CVE-2019-17571）。建议参考内部迁移指南 [链接] 进行升级。
两个答案对比 Gold Answer 可能得分相同，但系统 B 明显更有价值——它提供了更完整的信息、安全风险提示和行动建议。
真正重要的评估维度
对于 GraphRAG 系统，我们更应该关注：
- 图谱覆盖率：实体和关系是否被完整抽取？
- 推理路径可解释性：系统是通过哪些节点和边得出结论的？
- 信息完整度：是否遗漏了重要的关联信息？
- 时效性：引用的信息是否是最新的？
- 可操作性：答案是否给出了可执行的建议？
这些维度都不是 Gold Answer 能评估的。
那我们该怎么评估 GraphRAG？
既然 Gold Answer 不再是银弹，以下是更适合 GraphRAG 的评估策略：
- LLM-as-Judge + 评估维度拆分：让 LLM 从准确性、完整性、相关性等多个维度分别打分
- 基于源文档的事实核查：检查答案中的每个事实是否能在源文档中找到依据
- 图谱质量指标：直接评估知识图谱的实体覆盖率、关系准确率
- 端到端用户满意度：让真实用户评价答案是否解决了他们的问题
- 回归测试而非绝对评分：关注系统更新前后的质量变化，而非追求绝对分数
最后
Gold Answer 并非毫无价值——在简单事实问答、系统冷启动阶段，它仍然是有用的基线。但在 GraphRAG 这类复杂系统中，过度依赖 Gold Answer 会带来三个风险：
- 虚假的安全感：Gold Answer 评分高不代表系统真的好用
- 维护负担：持续更新 Gold Answer 的成本可能超过它带来的价值
- 评估盲区：Gold Answer 无法覆盖 GraphRAG 最重要的质量维度
与其花大量时间维护一套注定会过时的”标准答案”，不如把精力投入到更现代、更全面的评估体系中。GraphRAG 的评估，应该像 GraphRAG 本身一样——动态、多维、基于理解而非死记硬背。