企业官网建设流程全解析

MEX 是一款把团队记忆放进代码仓库的开源工具，核心能力之一是用代码图（Code Graph）做自然语言检索。这篇文章拆解 MEX 的检索基准评测方法论：它如何用盲评、配对 Token 核算和确定性回退，证明图检索对比传统 Grep 文件搜索，能让 AI Agent 的 token 消耗直降 54%，且答案正确率不降反升。

为什么检索效果不能只看"测试全绿"

在做代码图检索（mex graph scope <自然语言问题>）的评测时，MEX 团队先直面了一个尴尬的现实：旧的评测全绿，不代表检索真的好用。

问题出在"考的"和"用的"不一致：

• 🎯 旧门禁任务大多用精确标识符（如runGraphScope），这类查询当然能命中；
• 但真实使用中，Agent 问的是"什么东西防止检索结果超过 token 预算"这类自然语言问题，往往查不到目标声明；
• 查不到就会反复换说法重试，token 和延迟直线上升；
• 最后 Agent 退回 Read/Grep 逐文件翻代码，图检索的存在意义被完全抵消。

这套评测原则完整记录在 EVAL_SYSTEM_PLAN.md，其中几条对任何想评测检索系统的团队都有参考价值：缺失的结果就是失败（不能从平均分里剔除）、比较相同工作量（要统计重试和回退的总消耗，而不只是第一次响应）、确定性检查守 CI，随机 Agent 实验支撑发布决策。

两层评测架构：确定性套件 + 无头盲评

MEX 把评测拆成两层，各管一件事（见 evaluate/README.md）：

确定性套件的每个任务都带精确的源码级标准答案：符号名、声明类型、仓库相对路径，甚至起止行号。准备阶段会主动拒绝过期行号、重复任务 ID、歧义声明。任务覆盖自然语言符号查询、改写（paraphrase）家族、多符号流程、负向查询，定义在 evaluate/compare/suites/mex-graph.json 这类套件文件中。

设计 Grep 基线：给对照组一个公平的起点

盲评对比的核心设计，是设三个"配对臂"（arms）：

1. Files 臂（对照）：Agent 只能用普通的 Read / Grep / Glob 翻仓库——这就是"一个会用文件搜索的 Agent 该达到的水平"；
2. main 臂：使用已发布main分支构建的图；
3. Candidate 臂：当前待验证版本，强制先执行一次mex graph scope，之后才允许读文件。

两个关键公平性细节：

• ⚖️臂顺序做平衡排列。24 个会话按任务与轮次打乱执行顺序，避免某个臂总在后跑、白吃前一个臂"预热"的提示词缓存；
• 🔒会话完全隔离。每个会话从全新中立临时目录开始，不继承任何对话状态，Bash 命令经白名单守卫，Agent 无法跨臂作弊。

值得一提的是，MEX 还保留了一条确定性的 Grep Top-3 基线（evaluate/lib/grep-baseline.mjs）：按关键词子串命中数给文件打分，取前 3 个文件的全文作为 token 分母——这是早期紧凑度基准的"诚实分母"，用于说明图检索返回的上下文远比"读 3 个最像的文件"精瘦。

盲评打分：先判答案，再揭身份

这是整套方法论里最有"盲测精神"的一环：

• 🧪 所有会话的答案先被匿名化，打上A001、A002… 这样的盲评编号，打乱顺序后对照源码判分；
• 判分依据是结构化的标准答案：Agent 必须给出实质性的答案文本（≥40 字符）、精确的源声明符号名、以及"路径+行号"的证据引用，规则定义在 evaluate/compare/lib/answer.mjs；
• 身份映射单独存放在blind-reveal.json，揭盲之前不允许任何人（包括判分流程）知道哪个答案来自哪个臂；
• 盲评文件带与运行绑定的一致性校验，过期的评审结果无法挂到新结果上——防止"旧判分、新数据"的张冠李戴。

盲评的实现细节在 evaluate/compare/lib/report.mjs 中，判分与揭盲是两个显式步骤。

Token 核算：只比较"同题配对"的消耗

两个 CLI（Claude / Codex）暴露的用量字段各不相同，MEX 的做法是：原始用量对象原样落盘，只把确定语义的字段映射成统一结构（未缓存输入、缓存写入、缓存读取、输出等），字段缺失就保留null，绝不把缺失当 0 来制造省钱假象。

对比信号采用同任务、同轮次的配对差值：

deltaNewTokens = newTokens(候选臂) - newTokens(Files 臂)

其中 New tokens = 未缓存输入 + 缓存写入 + 输出。报告同时给出分布、配对均值和确定性 bootstrap 95% 区间——这是评测文档里反复强调的"比较配对差值，而不是绝对会话总量"原则的直接落地。

结果：token 直降 54%，正确率不降反升

试点规模：12 个自然语言任务（6 个 Hono + 6 个 MEX 仓库问题），每臂各跑一遍，共 24 个 Claude Sonnet 会话，全部通过执行、权限、主体一致性与 token 核算检查。实测结果（完整数据见 evaluate/RESULTS.md）：

检索质量侧，12 个任务中 11 个在首次响应就命中了必需文件，必需源码区间返回 22/23，图证据覆盖率 12/12，而候选臂平均每个会话只用了1.0 次去重后的 scope 查询——没有"反复重试"的行为。12 个任务的配对中位数 new-token 降幅为 -47.0%。

确定性回退：不经过模型的硬指标

随机 Agent 实验只支撑发布决策，真正的 CI 门禁由确定性套件把守。两个独立回退套件的硬指标：

完整性门禁同样全部通过：两次重建产生相同的归一化图哈希，无抽取/存储丢失、重复身份、悬挂边或 FTS 漂移。效率门禁（evaluate/thresholds.json）则要求"图检索返回量 ≤ Grep Top-3 全文"且期望召回 ≥ 0.85——质量门禁永远先于效率门禁执行，防止"输出变短但没答对"被误读为胜利。

解读边界与复现方式

MEX 团队对 54% 这个数字的表述相当克制（见 RESULTS.md 的"Limits on interpretation"）：

• 每任务仅 1 轮重复、单一模型，单题效率仍有噪声；
• 试点未包含已发布main图实现这一臂（发布决策需三臂齐全）；
• TypeScript 用的是真实仓库src/compiler子树的稀疏检出，而非完整 monorepo；
• 结论是"该试点下 token 下降且正确率不降反升"，不是通用的省钱百分比。

复现确定性部分很简单：

npm ci npm run build npm run eval:test

无头对比则需本地已认证的模型 CLI，并消耗模型配额，命令与套件说明都在 evaluate/README.md 中。

小结

MEX 的检索基准评测方法论可以浓缩为四句话：用盲评消除判分偏见，用配对差值消除缓存偏差，用精确源码级标准答案消除模糊判分，用确定性门禁兜住 CI。54% 的 token 降幅只是这套方法论跑出来的一个试点结果——真正可复用的，是"先让评测可信，再谈指标提升"这个顺序。