session-handoff.md
8.19 KB
Session Handoff / 持续开发交接文档
目标:让下次启动的新 session 在 3~10 分钟内 知道从哪里开始。
1. 下次启动先做什么
优先直接跑当前主线:
cd /workspace
/usr/local/miniconda3/bin/python acr-engine/scripts/run_songcentric_directory_pipeline_live.py \
--dsn 'postgres://d2:d2pass@127.0.0.1:5432/d2' \
--schema acr_songcentric_test \
--input-root acr-engine/data/songcentric_builder_smoke \
--output-dir acr-engine/data/pgvector_eval/music20
或:
acr-engine/scripts/start_songcentric_shortest_path.sh 'postgres://d2:d2pass@127.0.0.1:5432/d2'
当前 fresh evidence:
song_count = 2asset_count = 2window_count = 5matcher_fingerprint_count = 5fallback_fingerprint_count = 0semantic_runtime_available = truesemantic_runtime_missing = []semantic_runtime_ready_count = 5semantic_fallback_count = 0import_counts = media_entity:9 / audio_object:22 / feature_fact:34 / set_membership:9
2. 当前一句话状态
4 表 song-centric schema 已在 live PostgreSQL 上真实打通了“真实目录 -> 切片 -> exact/semantic feature enrichment -> import -> feature_fact”的宿主链。
下一步最应该做的是:
在不破坏这条宿主链的前提下,继续把 semantic lane 从当前 MERT baseline 扩展到 MuQ challenger。
3. 当前稳定结论
3.1 默认物理模型
media_entity -> audio_object -> feature_fact -> set_membership
3.2 默认逻辑语义
song -> asset -> window -> fingerprint / embedding
3.3 关键设计取舍
- 最终归属对象当前只要求稳定返回
song_id - 同一个
song下允许多个音频文件 -
window仍保留,因为它是切片/evidence/offset/召回最小单元 -
feature_fact统一承载fingerprint与embedding - Phase-1 不先训练/微调,先直接复用开源 encoder
4. 切片 / 模型 / feature 分别在哪张表
| 对象 | 表 | 关键字段 |
|---|---|---|
| song | media_entity |
entity_type='song' |
| asset | audio_object |
object_type='asset' |
| window | audio_object |
object_type='window', parent_object_id=<asset_id>
|
| model identity | feature_fact |
model_name, model_version, feature_set_name
|
| fingerprint payload | feature_fact |
feature_type='fingerprint', fingerprint_value
|
| embedding payload | feature_fact |
feature_type='embedding', embedding_uri/vector_table_name, embedding_dim
|
| set routing | set_membership |
set_type, set_name, member_type, member_id
|
5. 当前流程图
flowchart TD
A[song / media_entity] --> B[asset / audio_object]
B --> C[window / audio_object]
C --> D1[fingerprint / feature_fact]
C --> D2[embedding / feature_fact]
A --> E[set_membership]
B --> E
C --> E
D1 --> F[召回与归属到 song_id]
D2 --> F
6. 当前已经真实验证过什么
live PostgreSQL
- DSN:
postgres://d2:d2pass@127.0.0.1:5432/d2 - schema:
acr_songcentric_test
已验证链路
-
acr-engine/sql/acr_pg_schema_songcentric_v1.sql可真实建表 -
bootstrap_songcentric_phase1_live.py可重复 seed -
import_songcentric_manifest_live.py可幂等导入song/asset/window/membership - manifest 中
windows[].features[]已可直接落feature_fact - 真实目录 -> manifest -> import 已验证通过
- 真实目录 -> fingerprint enrichment -> import 已验证通过
- exact lane 已优先复用仓库内
ChromaprintMatcher - semantic lane 已真实接入
mert-v1-95mbaseline,当前 host 的 live 主链已不再停留在 placeholder 分支
7. 当前 host 的真实 blocker
-
torch / torchaudio / transformers已可导入 - 当前
semantic_runtime_available = true - 当前 semantic 已接上真实
mert-v1-95mbaseline
这说明当前主要 blocker 已从“依赖缺失”推进为:
runtime 已就绪,真实
MERTbaseline 已接入,下一步可继续接MuQ。
当前更具体的 MuQ 目标名可优先按下面口径尝试:
- Hugging Face / 代码线索:
OpenMuQ/MuQ-large-msd-iter - 官方加载入口:
from muq import MuQ+MuQ.from_pretrained("OpenMuQ/MuQ-large-msd-iter") - 当前 host 状态:
muq包已安装,但import muq被RuntimeError: operator torchvision::nms does not exist卡住 - 仓库现有 Phase-1 任务线索:
muq+large-msd-iter
8. 下次继续时先看哪些文件
关键代码:
acr-engine/sql/acr_pg_schema_songcentric_v1.sqlacr-engine/scripts/run_songcentric_directory_pipeline_live.pyacr-engine/scripts/build_songcentric_manifest_from_directory.pyacr-engine/scripts/enrich_songcentric_manifest_with_local_features.pyacr-engine/scripts/import_songcentric_manifest_live.pyacr-engine/scripts/start_songcentric_shortest_path.sh
9. 下一步优先顺序
- 保持当前 4 表 schema 不回退
- 给
enrich_songcentric_manifest_with_local_features.py接真实 semantic adapter - 保留 fallback 分支,不破坏当前 host 的可运行性
- 重新跑主链 runner,确认 semantic lane 有 fresh 证据
一句话 handoff
下次不要再从总方案争论开始,直接跑 song-centric runner;如果 exact 正常、semantic 仍 fallback,就继续补真实 semantic adapter 和依赖。
10. 数据关联与当前 live 落库事实
当前最重要的绑定关系只有 3 条:
-
feature_fact.object_id -> audio_object.object_id- feature 绑定到具体音频对象
- Phase-1 默认绑定
window,不是直接绑定 song
-
audio_object.parent_object_id -> audio_object.object_id-
window -> asset父子回溯链
-
-
feature_fact.song_id -> media_entity.entity_id- 用于快速做 song-level 聚合与最终返回
song_id
- 用于快速做 song-level 聚合与最终返回
可以用一句话理解:
audio_object说明“这段音频是谁”,feature_fact说明“这段音频被哪个模型编码成了什么特征”。
当前 live 主链已经真实落了什么
当前 live 新数据已经真实落到:
- exact:
chromaprint_matcher / phase1_local / chromaprint_matcher_5s - semantic baseline:
mert-v1-95m / hf-main / mert_5s_hop2.5_v1
当前 MuQ 状态:
- 目标模型:
OpenMuQ/MuQ-large-msd-iter - 当前 blocker:
import muq触发RuntimeError: operator torchvision::nms does not exist - 结论:MuQ 仍是下一阶段 challenger,不是当前 live 默认基线
一个可直接复核的 live 样例
当前可直接用 feature_id = 34 做人工复核:
feature_id = 34
feature_type = embedding
model_name = mert-v1-95m
model_version = hf-main
feature_set_name = mert_5s_hop2.5_v1
window_id = 22
window_range = 1000-6000 ms
asset_id = 20
asset_uri = /workspace/acr-engine/data/songcentric_builder_smoke/song_beta/artist_b/clip2.wav
song_id = 9
song_biz_key = song_beta
这条样例可以非常直观地证明:
- feature 不是直接挂 song,而是先挂到
window -
window通过parent_object_id回到asset - 最终通过
song_id回到song_beta
当前 manifest 形状(导入前)
{
"song": {"biz_key": "song_alpha", "title": "song alpha"},
"asset": {"storage_uri": ".../clip1.wav"},
"windows": [
{
"start_ms": 0,
"end_ms": 5000,
"features": [
{
"feature_type": "fingerprint",
"model_name": "chromaprint_matcher",
"feature_set_name": "chromaprint_matcher_5s"
},
{
"feature_type": "embedding",
"model_name": "mert-v1-95m",
"feature_set_name": "mert_5s_hop2.5_v1",
"embedding_dim": 768
}
]
}
]
}
下次 session 最直接的继续点
- 不要再验证 MERT 是否接上,已经接上
- 直接处理 MuQ 的
torchvision::nms兼容问题 - 接入
OpenMuQ/MuQ-large-msd-iterchallenger - 重跑主链 runner,确认每个 window 最终可同时看到:
chromaprint_matchermert-v1-95m-
muq-large-msd-iter(或最终统一后的model_name)