Model-Optimizer 评估实战：用 NEL 运行 AA-Omniscience 知识可靠性基准与 Omniscience Index 评分提取

AA-Omniscience（ns_omniscience）是 Artificial Analysis（AA）Index v2 套件中的知识/幻觉基准，由 Judge 模型对模型在冷门事实上的回答进行"答对 / 幻觉 / 弃答"三分类打分，核心产出是"准确率扣除幻觉"后的 Omniscience Index。本文基于 Model-Optimizer 仓库中 AA-Omniscience 任务配方，完整讲解该任务的参数语义、YAML 配置、环境变量注入与 MLflow 分数提取方法，并融入 NeMo Evaluator Launcher（NEL）的实际运行工作流，帮助你在一套可比配置下完成对量化前后模型的可靠性评估。

任务概述：衡量"知道多少，且不乱编"

AA-Omniscience 属于 evaluation skill 中的 judge-scored 类知识型基准，其设计目标是衡量模型在冷门、小众事实上的知识可靠性：模型不仅要答对，更要在不确定时主动弃答，而不是生成一个貌似合理的幻觉答案。这正是量化压缩场景下最值得关注的退化方向之一——在 量化感知基准推荐文档 中，AA-Omniscience 被标注为中等量化敏感性：激进的精度损失（如 NVFP4、INT4-AWQ）会侵蚀事实召回率、改变 omni-index 的平衡，因此它被列入量化 checkpoint 验证的默认 AA 套件。

与同套件的其他任务相比，它有几个鲜明特征：

• judge-scored：最终得分由固定的 Judge 模型（gcp/google/gemini-3-flash-preview）判定，而非规则匹配；
• 三分类语义：区分"正确回答"、"幻觉回答"与"弃答（abstention）"，因此 Omniscience Index 可以是负数——猜错被重罚，弃答反而得到奖励；
• 多次重复降方差：默认 num_repeats: 10，所有指标均以 pass_at_1_avg-of-N 聚合。

关键参数语义：三个决定可比性的"金旋钮"

1. ++parse_reasoning=False 是必选项

任务配方明确指出该参数是 golden knob（黄金旋钮）：omniscience 评分的是最终答案（final answer），而非推理轨迹（reasoning trace）。因此必须通过 extra.args 传入：

args: "++parse_reasoning=False"

若省略该参数，harness 会尝试解析并纳入模型的思维链内容参与评分，导致评分对象与基准设计不一致。这一设计与其他任务形成对比——例如 HLE 任务通过 hle_strict_judge: true 开启严格判卷，而 Omniscience 则是显式关闭推理轨迹解析，把注意力完全放在模型给出的最终答案上。

2. Judge 模型固定 + 端点从 .env 注入

任务配方在 YAML 片段中硬编码了 judge 的 model_id（gcp/google/gemini-3-flash-preview），这是一个需要保持跨 run 一致的约定：

• url（<INFERENCE_JUDGE_URL>）来自工作区根目录 .env 文件中的 INFERENCE_JUDGE_URL，指向 OpenAI 兼容推理服务的 /v1 base；
• api_key（INFERENCE_API_KEY）同样来自 .env，是唯一需要导出并由 harness 读取的密钥；
• 如果自己的端点提供等效模型，可以替换 model_id，但同一批可比 run（baseline 与 quantized）之间必须保持 judge 完全固定，否则分数差异无法归因于模型本身。

这一"url/密钥来自环境、model_id 写在配置"的模式在 env.example 中有完整说明：INFERENCE_JUDGE_URL 属于配置而非机密（无需 export），而 INFERENCE_API_KEY 是密钥，需要在 shell 中 source 后由 harness 读取。HLE、AA-LCR、Tau2-Bench 等 judge-scored 任务共享同一套 INFERENCE_API_KEY 与同一个 OpenAI 兼容 host。

3. num_repeats: 10 与量化对比约束

num_repeats: 10 是为降低方差而调校的重复次数。在 量化感知基准推荐文档 中明确提醒：做量化对比时不要调低重复/采样数，否则噪声会掩盖真实的精度回归。N 值同时决定了分数提取时的指标名（avg-of-N 中的 N）。

完整 YAML 任务片段

将以下片段放入 NEL 配置顶层 evaluation.tasks 列表中（基准配置模板见 example_eval.yaml）：

- name: nemo_skills.ns_omniscience
  container: nvcr.io/nvidia/eval-factory/nemo-skills:26.05.1
  env_vars:
    INFERENCE_API_KEY: host:INFERENCE_API_KEY
  nemo_evaluator_config:
    config:
      params:
        extra:
          num_repeats: 10
          args: "++parse_reasoning=False"
          judge:
            api_key: INFERENCE_API_KEY
            model_id: gcp/google/gemini-3-flash-preview   # use an equivalent on your own endpoint if needed
            url: <INFERENCE_JUDGE_URL>                     # from .env (/v1 base)

逐字段说明：

字段	值	作用
name	nemo_skills.ns_omniscience	nemo-skills harness 下的任务名，属于 ns_* 系列（需要 DUMMY_API_KEY 占位密钥，见下文）
container	nvcr.io/nvidia/eval-factory/nemo-skills:26.05.1	评估任务的 NGC 镜像，public 镜像可直接提交无需预检凭据
env_vars.INFERENCE_API_KEY	host:INFERENCE_API_KEY	从提交端 shell 环境读取密钥并注入容器，host: 前缀是 NEL 的强制约定
extra.num_repeats	10	每道题重复采样 10 次，pass_at_1_avg-of-N 聚合，N=10
extra.args	++parse_reasoning=False	评分只看最终答案，不看推理轨迹（必选）
extra.judge	见上	judge 端点与模型配置；仅 api_key 是需导出的密钥

关于 env_vars 的前缀语法：NEL 要求 env_vars 映射中每个值都带显式前缀——host:VAR（提交时从 shell 环境读取）、lit:value（字面量）、runtime:VAR（作业运行时读取）。裸值会硬报错 "Env var value '…' must have an explicit prefix."，详见 launcher-workflow.md 的 Step 5 说明。

运行前的环境准备：.env 与 nemo-skills 占位密钥

搭建 .env

judge-scored 任务要求在运行 nel 的工作区根目录维护一份 .env（不是 skill 目录下）：

# 模板位于 skill 目录，工作区 .env 需自行复制（不要污染 skill 目录）
[ -f .env ] || cp "$SKILL_DIR/recipes/env.example" .env
# 编辑 .env 填入你的密钥
set -a && source .env && set +a

Omniscience 任务需要的两个关键项（均来自 env.example）：

# Judge 推理端点密钥（必填，唯一需要导出的密钥）
INFERENCE_API_KEY=<your-key>
# Judge 推理端点 URL，OpenAI 兼容 /v1 base（配置，无需 export）
INFERENCE_JUDGE_URL=https://<your-inference-host>/v1

注意：HLE、AA-LCR、AA-Omniscience 这三个任务共享同一个 INFERENCE_JUDGE_URL 推理 host，model_id 各自硬编码在各自配方中。

DUMMY_API_KEY 的坑

ns_* 系列任务（含 ns_omniscience）在自部署模型场景下，harness 客户端硬性要求 api_key_name 指向的环境变量在评估容器内有值，否则报 ValueError: api_key_env_var=DUMMY_API_KEY but the value is not set。在 SLURM 上，shell 里的 export DUMMY_API_KEY=dummy 不会传播进容器——NEL 只注入 env_vars 中显式声明的变量。因此必须按 example_eval.yaml 的方式声明：

evaluation:
  env_vars:
    DUMMY_API_KEY: lit:dummy   # 注意 lit: 前缀
  nemo_evaluator_config:
    target:
      api_endpoint:
        api_key_name: DUMMY_API_KEY

（lit: 前缀只对本地/Docker 运行有帮助的场景另有说明，SLURM 下必须以 evaluation.env_vars 声明。）

从 MLflow 提取 Omniscience 评分

任务完成后，分数由 NEL 自动导出到 MLflow（前提是配置中启用了 execution.auto_export.destinations: [mlflow] 与 export.mlflow 块）。提取时遵循如下映射：

主指标：Omniscience Index（-100 到 100）

omniscience_pass_at_1_avg-of-N_judge_omni_index

这是 AA 的头条指标：在正确率基础上扣除幻觉惩罚，奖励"弃答"而非"乱猜"，因此可以为负。报告分数时以此为准。

配套指标

在同一个 pass_at_1_avg-of-N 聚合下，还需报告：

指标	MLflow key	取值区间	含义
Accuracy（准确率）	omniscience_pass_at_1_avg-of-N_judge_correct	0-100	答对问题的百分比
Non-hallucination rate（非幻觉率）	100 - omniscience_pass_at_1_avg-of-N_judge_omni_hallucination	0-100	judge_omni_hallucination 本身是幻觉率，非幻觉率 = 1 - hallucination

这里的 N 即重复次数（本任务为 10，因此实际键名为 ..._avg-of-10_...）。若重复次数未知，取可用的最高 avg-of-N。

这套命名规律与同套件其他任务一致：GPQA 是 gpqa_pass_at_1_avg-of-16_symbolic_correct，HLE 是 hle_pass_at_1_judge_correct（见 hle.md）。区别在于 Omniscience 额外带 judge_omni_index 与 judge_omni_hallucination 两个语义化后缀，直接反映其三分类设计。

端到端运行工作流：dry-run → canary → full

AA-Omniscience 走的是 0.2.6 版 nel launcher 的通用流程（详见 launcher-workflow.md），三阶段门禁：

# 1. 配置校验（解决 ??? 占位、Hydra 覆盖、env 变量、挂载、镜像问题）
nel run --config <path> --dry-run

# 2. 金丝雀：小样本验证 judge 认证/限流、容器、请求格式
nel run --config <path> -o ++evaluation.nemo_evaluator_config.config.params.limit_samples=10

# 3. 完整运行：移除 limit_samples，保持已验证的 parallelism
nel run --config <path>

针对 judge-scored 任务（Omniscience 属此类），launcher-workflow.md Step 5 有一条重要约束：judge.model_id / url 属于配置而非机密，应替换为 .env 中的字面量，不要输出 ${oc.env:...}（除非用 set -a 导出，否则会静默失败）；只有 api_key 保持为 env-var 名形式（如 INFERENCE_API_KEY），由 harness 读取。此外：

• 若 checkpoint 由 ModelOpt 量化产出并带 .experiment.json，建议把其中的 experiment_name / run_name / run_id / run_url 带入 export.mlflow，让评估 run 归组到量化它的 PTQ run 之下，便于事后按 tags.modelopt_run_id 检索；
• 保持 judge 在 baseline 与 quantized 两次运行中完全一致，是分数可比的前提；
• 与其他 judge-scored 任务（HLE、AA-LCR、Tau2）一样，建议单独金丝雀本类任务（judge 端点限流通常比自部署模型先到瓶颈），先保守设置 parallelism，待 judge 日志干净后再逐步上调。

在 AA 套件中的定位与量化评估建议

AA-Omniscience 是 量化感知基准推荐文档 中"AA / Artificial Analysis 套件（文本 LLM）"的成员之一，与 GPQA、HLE、LCR、SciCode、IFBench、Tau2-Bench Telecom 一起构成默认多任务配置。需要留意的使用规则：

• 用户提到 "AA" / "Artificial Analysis" 时，应把 recipes/tasks/aa/ 的任务合并为一个多任务配置，且不要混入 MMLU-Pro、AIME 2025、LiveCodeBench（它们属于独立 always-include 集合）；
• GDPVal 同为 AA 套件成员但本 skill 已不支持，生成的套件不含它，因此聚合结果与包含 GDPVal 的公开 AA Index 不可直接对比——应逐任务报告分数；
• 就量化敏感性而言，Omniscience 属于中等敏感（测量幻觉/弃答平衡，激进精度损失会侵蚀事实召回并移动 omni-index），低于 LCR/SciCode 的"非常高"，高于 IFBench 的"低"，可作为 FP4/INT4-AWQ 等激进格式回归检查的有力补充。

小结

AA-Omniscience 的评估要点可浓缩为三条：（1） ++parse_reasoning=False 必须带上，确保只评最终答案；（2） judge 的 model_id 固定、url 走 .env 的 INFERENCE_JUDGE_URL、只有 INFERENCE_API_KEY 是导出密钥，且同一可比 run 对之间 judge 不可更换；（3） 主指标是可为负的 ..._judge_omni_index（Omniscience Index），配套报告 Accuracy 与 Non-hallucination rate，全部基于 pass_at_1_avg-of-10 聚合。配合 NEL 的 dry-run → canary → full 门禁与 MLflow 自动导出，即可在量化模型验证流水线中获得稳定、可比的知识可靠性信号。