VoxMem 不是跑分榜 / 它把音频记忆拆成可复现的测试流程

把 VoxMem 当成跑分榜来读，通常只能拿到一个总分和一个名次，但 VoxMem 真正有信息量的输出是「这个分数是怎么来的」：任务配置、音频样本清单、评估脚本三样一起给出。只要这套输入能固定，别人在你的机器上就能跑出可比较的结果，分数只是流程的副产物。是否值得投入复现，取决于你是否需要跨模型、跨版本、跨环境地定位音频记忆能力的差异；如果只想要一个横向排名，跑分榜其实已经够用。

VoxMem 的定位是评测流程，不是排行榜：分数只有在固定的任务配置、样本顺序和随机种子下才有意义。复现时建议先对齐配置文件与模型权重版本，再逐任务比对得分，差异优先从版本、依赖环境、权重来源三处排查。不要拿单次总分当作模型优劣的定论；需要留意，流程可复现并不等于结论可迁移，换数据集或换解码参数后要重新跑一次基线。

对比 VoxMem 与常见跑分榜的评测输出

跑分榜的输出结构通常是「一行名次 + 一个总分」，读者看不到样本怎么抽、提示词怎么写、错答怎么计分，也无法在本地重跑同样的输入。VoxMem 的输出更接近一份实验记录，除了分数之外还要交底：

跑分榜常见的输出：模型名、总分、名次，少数会附分类得分，但通常不含样本级明细。
VoxMem 给出的任务配置：每个任务用哪些参数、限制多少轮上下文、是否允许重复提问，都写在配置里。
VoxMem 给出的音频样本：样本清单和顺序固定，能在逐条结果里定位到具体是哪一段音频答错。
VoxMem 给出的评估脚本：判分逻辑可读，出现分歧时能直接看匹配规则，而不是猜榜单口径。

这个区别决定了两件事：一是同一个模型在不同配置下得分不可以直接横向比较，二是复现失败时你有排查的抓手——先查配置差异，再查环境差异。跑分榜给的是结论，VoxMem 给的是结论加实验条件。

按照 VoxMem 的配置文件固定随机种子和样本顺序

复现的第一步不是敲命令，而是把配置写死。下面是一份通用结构的配置示意，字段名需要按你实际使用的版本对齐；如果配置模板里没有同名项，先去看该版本自带的示例配置，不要凭猜新增字段。

run_name: audio_memory_baseline
seed: 1234                    # 固定采样、打乱与解码中的随机性
sample_order: manifest        # sorted | shuffled | manifest
audio_path: /data/voxmem/audio
manifest: /data/voxmem/manifest.jsonl
tasks:
  - recall_short
  - recall_long
  - order_sensitive
model:
  name: your-audio-llm
  weights: /models/your-audio-llm
  revision: v1
decode:
  temperature: 0.0
  max_new_tokens: 256
output_dir: ./runs/baseline
save_per_sample: true

三个字段要特别确认：seed 影响采样和打乱，sample_order 决定音频样本的遍历顺序，audio_path 必须指向与官方报告一致的那份样本目录。任何一个浮动，都会让逐条结果对不上，哪怕总分看起来接近。如果 temperature 不是 0，建议先按 0 跑一轮基线，再决定是否放开。

在本地运行 VoxMem 的完整评测流程

依赖建议装在独立虚拟环境里，避免与机器上已有的音频库、推理框架版本互相干扰。以下命令是骨架形式，模块入口以你拿到的版本为准。

python -m venv .venv
source .venv/bin/activate
pip install -r requirements.txt

# 一次性跑完
python -m voxmem.eval \
  `--config` configs/voxmem_baseline.yaml \
  `--output` ./runs/baseline \
  `--save-per-sample`

# 或者拆成三步，便于中断后继续
python -m voxmem.prepare `--config` configs/voxmem_baseline.yaml
python -m voxmem.run     `--config` configs/voxmem_baseline.yaml
python -m voxmem.report  `--run-dir` ./runs/baseline

依赖安装：安装完成后先 pip freeze > runs/env.txt 存一份依赖快照，后面定位差异时会用到。
模型加载：确认加载的是配置里写明的权重路径与 revision，加载日志里通常会打印参数量和路径，建议一并留存。
结果保存：保留逐样本文件、汇总文件和原始日志三份。只看汇总 json 会在后面排查时丢失线索。

验证这一步是否跑通，不看分数高低，而看产物是否齐全：运行目录里应该有配置副本、逐样本结果、汇总结果和日志。

将复现结果与官方报告对比，定位差异来源

对比不要只看总分，要按任务逐项比。下面是一个对比脚本骨架，只做数值和行为比对，不含任何判分逻辑：

import json

def load(path):
    with open(path, encoding='utf-8') as f:
        return json.load(f)

mine = load('runs/baseline/summary.json')
ref  = load('refs/official_report.json')

tasks = sorted(set(mine['scores']) | set(ref['scores']))
for task in tasks:
    a = mine['scores'].get(task)
    b = ref['scores'].get(task)
    if a is None or b is None:
        print(task, 'MISSING', 'mine=', a, 'ref=', b)
        continue
    print(task, 'mine=%.4f' % a, 'ref=%.4f' % b, 'delta=%+.4f' % (a - b))

# 逐样本对齐：先比样本 ID 集合，再看同一 ID 的判分是否一致
mine_ids = set(mine.get('per_sample', {}))
ref_ids  = set(ref.get('per_sample', {}))
print('only_in_mine:', sorted(mine_ids - ref_ids)[:10])
print('only_in_ref :', sorted(ref_ids - mine_ids)[:10])

拿到差异后，按下面顺序排查，通常比盯着总分更快：

版本差异：评估脚本版本、样本集版本、配置 schema 是否一致，配置字段被忽略是最常见的假复现。
环境差异：推理框架、音频解码库、GPU 驱动版本不同，可能改变重采样或精度路径。
模型权重差异：权重来源、revision、量化方式是否与官方报告一致，量化和非量化不要混着比。
顺序差异：样本顺序变了导致上下文状态不同，逐样本结果对不上但总分接近，属于这类问题。

如果逐样本结果完全一致而总分不同，那多半是判分或汇总环节的口径问题，回到评估脚本里核对即可。

用可复现流程做模型迭代的回归测试

把 VoxMem 当回归套件用，关键不是每次全量跑，而是固定一个可解释的子集。建议做法是：改动影响哪个模块，就重跑对应任务，再加一个固定小集做回归锚点。

必跑任务：短时回忆、长时回忆、顺序敏感各保留若干条，覆盖被改动路径最容易波及的场景。
触发条件：改模型权重、改解码参数、改音频前处理、升级评估脚本版本时，都要重跑一次锚点集。
记录指标：每任务得分、逐样本判分结果、失败样本 ID 列表、运行配置的哈希、模型权重 revision、依赖快照。
判定方式：先看逐样本结果是否变化，再看得分；只有得分下降但样本结果一致时，优先怀疑汇总口径。
留存方式：每次运行一个独立目录，用日期或 commit 标识命名，不覆盖上一轮结果，方便回溯。

这套流程不会让模型变好，它只保证你判断模型是否变好时，依据是同一套条件和同一批样本。需要提醒的是，锚点集长期不变容易过拟合，建议隔一段时间重新抽样扩充，并重新跑一遍基线做对齐。