Skip to content

wanghai-tech / hikoon-ACR

Go to a project
Toggle navigation
Toggle navigation pinning
Switch branch/tag
research-delivery-roadmap.md 8 KB

Research Delivery / 当前研究交付与 Roadmap

目标：把当前已经验证过的研究成果、下一阶段待办、以及可执行 checklist 固化成一份可直接唤起的交付文档。

1. 当前交付了什么

当前已经形成两条可复用主线：

  1. song-centric + 4 表 PostgreSQL 主链
  2. selected20（20 首歌）文件级小样本实战评测主线

一句话总结：

数据库宿主链已经打通，20 首专题评测基线也已经建立；下一阶段不是重新争论总方案，而是在当前基线上做 challenger 扩展与 hard-case 改善。

2. 当前研究成果摘要

2.1 主数据 / 宿主链成果

当前默认物理模型：

media_entity -> audio_object -> feature_fact -> set_membership

当前默认逻辑语义：

song -> asset -> window -> fingerprint / embedding

已真实验证：

  • live PostgreSQL schema 可建表
  • 真实目录 -> manifest -> import 可跑通
  • windows[].features[] 可直接导入 feature_fact
  • exact lane 已接 chromaprint_matcher
  • semantic lane 已接 mert-v1-95m
  • 当前主链在 live PostgreSQL 上已有 fresh evidence

2.2 selected20（20 首歌）专题成果

专题数据目录：

  • /root/hikoon_song_files/output/selected_20_songs/downloads

当前专题方案：

  • exact：chromaprint_matcher
  • semantic：mert-v1-95m
  • fused：0.6 * exact + 0.4 * semantic

当前 fresh 结果：

lane count top1 top3
exact 123 0.6016 0.8130
semantic 123 0.4715 0.6016
fused 123 0.6341 0.8537

分类型结论：

query_type count 当前判断
type_1 21 已打满，当前不是主要矛盾
type_7 41 主要短板之一，混淆明显
type_12 23 当前表现很好，semantic 单 lane 已打满
type_16 38 另一主要短板，仍需重点优化

一句话判断：

当前融合结果优于单独 semantic，也略优于单独 exact；实战瓶颈主要在 type_7 / type_16。

3. 当前 blocker

3.1 语义 challenger blocker

MuQ 当前还没接入成功。

已确认事实：

  • 候选：OpenMuQ/MuQ-large-msd-iter
  • muq 包已安装
  • 当前 host 上 import muq 仍被 RuntimeError: operator torchvision::nms does not exist 阻塞

所以当前 blocker 不是“还没想到做什么”，而是：

MERT baseline 已可用，但 MuQ challenger 受 torchvision 兼容问题阻塞。

3.2 效果 blocker

从 selected20 看，当前真正的效果短板不是：

  • type_1
  • type_12

而是：

  • type_7
  • type_16

这意味着下一阶段不能只盯 overall，必须盯 hard-case 的分类型提升。

4. 后续 Roadmap（建议版）

当前进度快照（2026-06-04）

Phase 状态 当前判断
Phase A：冻结当前基线 进行中 主链与 selected20 基线都已形成，fresh 重跑一致性也已确认
Phase B：接入 MuQ challenger 未开始 仍被 torchvision::nms runtime blocker 卡住
Phase C：selected20 回归闸门 进行中 已有脚本、JSON、Markdown 摘要，但还未完全制度化成固定门禁
Phase D：专题策略回灌在线主链 未开始 还没有把 selected20 的 hard-case 分析映射回 PostgreSQL 查询侧
Phase E：更大规模评测与工程化 未开始 当前仍以 selected20 为核心小样本基线

Phase A：冻结当前基线

目标：

  • 守住当前 song-centric 4 表主链
  • 守住 selected20 小样本回归基线

完成标准：

  • run_songcentric_directory_pipeline_live.py 继续稳定可跑
  • selected20_songid_eval_report.json 继续作为对照基线

Phase B：接入 MuQ challenger

目标：

  • 在不破坏现有 MERT baseline 的前提下，加一条 MuQ semantic challenger lane

完成标准：

  • import muq / from muq import MuQ 可成功
  • runner/评测脚本能产出 MuQ embedding
  • PostgreSQL 或文件级评测里能看到独立 MuQ 指标

关键评估：

  • MuQ 单 lane 是否优于 MERT
  • MuQ + exact 的 fused 是否改善 type_7 / type_16

Phase C：以 selected20 作为回归闸门

目标：

  • 把 selected20 固化成每次 encoder / fusion 变更后的回归集

完成标准：

  • 每次变更后都能直接复跑 selected20
  • 报告中必须比较：
    • overall
    • per-type
    • 失败样例

Phase D：把小样本专题映射回在线主链

目标：

完成标准：

  • feature_fact 中能区分不同 semantic challenger
  • 可以对同一批 query 比较 exact / MERT / MuQ / fused

Phase E：进入更大规模评测与工程化

目标：

  • 从 selected20 扩展到更大的 reference / query 集
  • 明确生产级回归、巡检、落库与索引策略

完成标准：

  • 有更大评测集
  • 有固定报表结构
  • 有稳定的主链/专题双回归机制

5. Checklist（下一阶段执行清单）

5.1 基线保护 checklist

  • 4 表 song-centric schema 已作为当前默认口径
  • chromaprint_matcher 已接入 exact lane
  • mert-v1-95m 已接入 semantic baseline
  • selected20 已形成基线报告
  • selected20 fresh 重跑结果与当前基线一致
  • docs 已形成可唤起交付链路（root README / docs README / start-here / handoff / roadmap / selected20）
  • 把 selected20 失败样例沉淀成 hard-case 白名单

5.2 MuQ 接入 checklist

  • 审计 torch / torchvision / muq 兼容矩阵
  • 解决 torchvision::nms does not exist
  • 在本机成功 from muq import MuQ
  • 在评测脚本中增加 MuQ lane
  • 产出 MERT vs MuQ vs fused 对比报告

5.3 效果优化 checklist

  • 按 type_7 / type_16 汇总失败歌曲对
  • 统计最常见误判 top1 歌曲
  • 评估 fusion 权重是否仍应固定在 0.6 / 0.4
  • 尝试基于 hard-case 调整融合策略
  • 验证优化是否真正改善 type_7 / type_16

5.4 工程化 checklist

  • 让 selected20 评测成为固定入口命令
  • 报告输出统一到 json + markdown
  • 在 docs 里固定“怎么读结果 / 怎么继续”
  • 后续如果切 online path，保留该文件级评测作为快速回归集

6. 推荐下次启动顺序

  1. 先看 session-handoff.md
  2. 再看 selected20_songid_eval.md
  3. 再看本文件的 roadmap + checklist
  4. 决定是走：
    • MuQ 接入线
    • selected20 hard-case 优化线
    • PostgreSQL 在线回灌线

当前建议的下一步（按收益排序）

  1. 先做 hard-case 白名单
    • 把 type_7 / type_16 的失败样例整理成固定榜单
  2. 再做 MuQ runtime 解锁
    • 先解决 torchvision::nms，再做 challenger 对比
  3. 最后做主链回灌
    • 把 selected20 上确认有效的策略映射回 PostgreSQL 查询路径

7. 当前建议任务构想

任务包 A：MuQ 解锁

目标：

  • 打通 MuQ runtime

产出：

  • 环境兼容记录
  • 可运行 MuQ smoke
  • 可落盘 MuQ embedding

任务包 B：selected20 hard-case 分析

目标：

  • 只盯 type_7 / type_16

产出：

  • 失败歌曲对榜单
  • 常见误判榜单
  • 是否需要调整 fusion 的结论

任务包 C：回归制度化

目标：

  • 让 selected20 成为固定回归门禁

产出：

  • 固定命令
  • 固定报告路径
  • 固定结果解读模板

任务包 D：在线主链映射

目标：

  • 把有效的专题结论映射回 PostgreSQL 主链

产出：

  • 主链中的 challenger 标识
  • 可对比的落库数据
  • 在线/离线一致的评估视图

一句话交付结论

当前最值得保护的研究资产不是“某个临时实验数字”，而是 已经跑通的 4 表 song-centric 主链 + 已经成型的 selected20 小样本回归基线 + 明确的 MuQ / hard-case 后续路线图。