Clarify the ACR evolution path and freeze a production-grade data model
Constraint: Phase-1 must support encoder-only open-source backbones without destabilizing future schema evolution Rejected: extending the old flat song_id + fixed-vector schema | would couple model swaps to schema rewrites and weaken copyright lineage Confidence: high Scope-risk: moderate Directive: treat canonical_song/work/recording/recording_asset/audio_window plus model/feature registries as the stable contract; evolve models and indexes around them Tested: git diff --check on changed files; Python content/structure sanity check; architect review APPROVED; README link coverage and DDL object presence verified Not-tested: live PostgreSQL apply not run because psql is unavailable in this environment
Showing
6 changed files
with
475 additions
and
81 deletions
acr-engine/sql/acr_pg_schema_v2.sql
0 → 100644
This diff is collapsed.
Click to expand it.
| 1 | ## 2026-06-04 | ||
| 2 | |||
| 3 | - 重构文档主阅读路径,新增按角色划分的文档入口:架构、开发、运维、模型底座。 | ||
| 4 | - 新增 [SOTA 演进方案说明](./sota-evolution-guide.md),明确 Phase-1 encoder-only 路线、MERT/MuQ 角色与后续 version/cover 演进。 | ||
| 5 | - 重写 [ACR 系统蓝图](./acr-architecture.md),补充角色视图、离线/在线职责分工与当前实现到目标实现的映射。 | ||
| 6 | - 新增 [PostgreSQL 数据模型与 DDL 设计说明](./postgresql-data-model.md),补充设计意图、解决的问题、流程图与实施顺序。 | ||
| 7 | - 新增 `acr-engine/sql/acr_pg_schema_v2.sql`,提供面向 `canonical_song/work/recording/asset/window + model_registry/feature_set_registry` 的推荐版 PostgreSQL DDL。 | ||
| 8 | - 根据 architect 复核意见补充:`recording_asset` 术语统一、reference set 版本化对象、候选枚举约束、以及关键 lineage trigger 设计。 | ||
| 9 | |||
| 1 | - 新增 `acr-engine/scripts/export_workspace_music20_embeddings_jsonl.py` 与 `acr-engine/scripts/evaluate_songid_pgvector_path.py`,补齐 song_id 级 pgvector 评测脚手架。 | 10 | - 新增 `acr-engine/scripts/export_workspace_music20_embeddings_jsonl.py` 与 `acr-engine/scripts/evaluate_songid_pgvector_path.py`,补齐 song_id 级 pgvector 评测脚手架。 |
| 2 | - 新增 `acr-engine/data/pgvector_eval/music20/` 评测产物,当前 `faiss-as-pgvector-standin` 结果:整体 `top1=0.9091`、`top3=0.9545`;其中 `query_type=1` 很强(`top1=1.0`),`query_type=7` 仍明显偏弱(`top1=0.0`,`top3=0.5`)。 | 11 | - 新增 `acr-engine/data/pgvector_eval/music20/` 评测产物,当前 `faiss-as-pgvector-standin` 结果:整体 `top1=0.9091`、`top3=0.9545`;其中 `query_type=1` 很强(`top1=1.0`),`query_type=7` 仍明显偏弱(`top1=0.0`,`top3=0.5`)。 |
| 3 | - 新增 `acr-engine/data/local_eval/voice_workspace20_type7_eval.json`,对当前 `workspace_music20` 语义做了 20 条 `type_7` 批量验证:`top1=0.0`、`top3=0.05`,说明业务 song_id 正确性仍明显不足。 | 12 | - 新增 `acr-engine/data/local_eval/voice_workspace20_type7_eval.json`,对当前 `workspace_music20` 语义做了 20 条 `type_7` 批量验证:`top1=0.0`、`top3=0.05`,说明业务 song_id 正确性仍明显不足。 | ... | ... |
| 1 | # ACR Docs Overview | 1 | # ACR Docs Overview |
| 2 | 2 | ||
| 3 | > 保留最新架构与最短落地入口。历史细节仍在仓库中,但默认阅读只保留下面 6 份主文档。 | 3 | > 面向“版权保护 / 听歌识曲 / 版本归属”的音乐 ACR 文档入口。默认先看主路径,历史细节文档作为补充材料保留。 |
| 4 | 4 | ||
| 5 | ## 最短阅读顺序 | 5 | ## 一页结论 |
| 6 | 6 | ||
| 7 | 1. [session-handoff.md](./session-handoff.md) | 7 | 当前项目已经从“原型是否能跑通”转向“**如何把 100w 音频 / 30w 歌曲做成可演进的版权检索系统**”。 |
| 8 | 2. [CHANGELOG.md](./CHANGELOG.md) | 8 | 默认阅读顺序不再按“训练脚本 -> demo”,而按: |
| 9 | |||
| 10 | 1. **系统蓝图**:当前系统是什么、未来要演进成什么 | ||
| 11 | 2. **SOTA 演进**:Phase-1 不微调底座时怎么做,后面如何升级 | ||
| 12 | 3. **PostgreSQL 数据模型**:资产、窗口、特征、索引、匹配结果如何落盘 | ||
| 13 | 4. **现有实现对照**:当前仓库代码和文档分别在哪 | ||
| 14 | |||
| 15 | --- | ||
| 16 | |||
| 17 | ## 主阅读路径(推荐) | ||
| 18 | |||
| 19 | ### 1. 管理 / 架构 / 跨团队负责人 | ||
| 20 | 1. [acr-architecture.md](./acr-architecture.md) | ||
| 21 | 2. [sota-evolution-guide.md](./sota-evolution-guide.md) | ||
| 22 | 3. [postgresql-data-model.md](./postgresql-data-model.md) | ||
| 23 | 4. [session-handoff.md](./session-handoff.md) | ||
| 24 | |||
| 25 | ### 2. 开发 / 数据 / 检索工程师 | ||
| 26 | 1. [postgresql-data-model.md](./postgresql-data-model.md) | ||
| 27 | 2. [training-data-and-pgvector-guide.md](./training-data-and-pgvector-guide.md) | ||
| 9 | 3. [acr-architecture.md](./acr-architecture.md) | 28 | 3. [acr-architecture.md](./acr-architecture.md) |
| 10 | 4. [dataset-spec.md](./dataset-spec.md) | 29 | 4. [runbook.md](./runbook.md) |
| 11 | 5. [training-data-and-pgvector-guide.md](./training-data-and-pgvector-guide.md) | 30 | |
| 12 | 6. [runbook.md](./runbook.md) | 31 | ### 3. 运维 / 平台 / 服务工程师 |
| 32 | 1. [acr-architecture.md](./acr-architecture.md) | ||
| 33 | 2. [postgresql-data-model.md](./postgresql-data-model.md) | ||
| 34 | 3. [service-api.md](./service-api.md) | ||
| 35 | 4. [runbook.md](./runbook.md) | ||
| 36 | |||
| 37 | ### 4. 模型 / 底座 / 研究工程师 | ||
| 38 | 1. [sota-research-2026.md](./sota-research-2026.md) | ||
| 39 | 2. [sota-evolution-guide.md](./sota-evolution-guide.md) | ||
| 40 | 3. [production-encoder-freeze-and-embedding-strategy.md](./production-encoder-freeze-and-embedding-strategy.md) | ||
| 41 | 4. [training-data-and-pgvector-guide.md](./training-data-and-pgvector-guide.md) | ||
| 42 | |||
| 43 | --- | ||
| 44 | |||
| 45 | ## 新的核心文档分工 | ||
| 46 | |||
| 47 | | 文档 | 作用 | 适合谁先读 | | ||
| 48 | |---|---|---| | ||
| 49 | | [acr-architecture.md](./acr-architecture.md) | 当前系统蓝图、角色分工、在线/离线链路 | 架构、开发、运维 | | ||
| 50 | | [sota-evolution-guide.md](./sota-evolution-guide.md) | SOTA 演进路径、Phase-1 encoder-only 方案、后续升级路线 | 架构、模型、检索 | | ||
| 51 | | [postgresql-data-model.md](./postgresql-data-model.md) | PostgreSQL 数据字典、DDL 设计意图、流程图、查询路径 | 数据、后端、检索、平台 | | ||
| 52 | | [training-data-and-pgvector-guide.md](./training-data-and-pgvector-guide.md) | 当前训练/manifest/pgvector 原型链说明 | 开发、数据 | | ||
| 53 | | [session-handoff.md](./session-handoff.md) | 最新状态与续跑上下文 | 新 session 接手人 | | ||
| 54 | |||
| 55 | --- | ||
| 56 | |||
| 57 | ## 当前实现与未来目标的关系 | ||
| 58 | |||
| 59 | ```mermaid | ||
| 60 | flowchart LR | ||
| 61 | A[当前实现\nChromaprint + ECAPA + Melody Rerank] --> B[Phase-1\nEncoder-only Foundation Backbone] | ||
| 62 | B --> C[Phase-2\nVersion/Cover Lane + Better Aggregation] | ||
| 63 | C --> D[Phase-3\nIndustrial Retrieval + Reranker + Governance] | ||
| 64 | ``` | ||
| 65 | |||
| 66 | - **当前实现** 已验证基础链路可运行。 | ||
| 67 | - **Phase-1** 目标是:不微调底座,直接上更强开源 encoder,并把 PostgreSQL 数据规范先落稳。 | ||
| 68 | - **Phase-2** 目标是:增强 version / cover / hard-case 归属能力。 | ||
| 69 | - **Phase-3** 目标是:多索引、多角色协作、数据治理、服务化上线。 | ||
| 70 | |||
| 71 | --- | ||
| 13 | 72 | ||
| 14 | ## 当前推荐只看这几类 | 73 | ## 现有实现入口 |
| 15 | 74 | ||
| 16 | ### 1. 项目架构 | 75 | ### 代码入口 |
| 17 | - [acr-architecture.md](./acr-architecture.md) | 76 | - `acr-engine/src/engines/chromaprint_matcher.py` |
| 18 | - [session-handoff.md](./session-handoff.md) | 77 | - `acr-engine/src/engines/ecapa_embedder.py` |
| 78 | - `acr-engine/src/engines/hybrid_engine.py` | ||
| 79 | - `acr-engine/src/service/app.py` | ||
| 80 | - `acr-engine/sql/pgvector_schema.sql`(原型版) | ||
| 81 | - `acr-engine/sql/acr_pg_schema_v2.sql`(本轮新增的推荐版) | ||
| 19 | 82 | ||
| 20 | ### 2. 数据与评测 | 83 | ### 历史/补充文档 |
| 21 | - [dataset-spec.md](./dataset-spec.md) | 84 | - [sota-research-2026.md](./sota-research-2026.md) |
| 22 | - [training-data-and-pgvector-guide.md](./training-data-and-pgvector-guide.md) | 85 | - [production-encoder-freeze-and-embedding-strategy.md](./production-encoder-freeze-and-embedding-strategy.md) |
| 23 | - [open-dataset-workflow.md](./open-dataset-workflow.md) | 86 | - [project-responsibility-map.md](./project-responsibility-map.md) |
| 87 | - [industrialization-roadmap.md](./industrialization-roadmap.md) | ||
| 24 | 88 | ||
| 25 | ### 3. 运行与服务 | 89 | --- |
| 26 | - [runbook.md](./runbook.md) | ||
| 27 | - [service-api.md](./service-api.md) | ||
| 28 | 90 | ||
| 29 | ### 4. 最新 hard-case 结论 | 91 | ## 如何理解当前文档体系 |
| 30 | - [acr-hard-case-analysis.md](../acr-engine/../docs/acr-hard-case-analysis.md) | ||
| 31 | 92 | ||
| 32 | ## 当前架构一句话 | 93 | - **主文档**:优先保证“读完就知道怎么推进” |
| 94 | - **历史文档**:保留实验上下文、旧方案与补充解释 | ||
| 95 | - **SQL 文件**:保证可以直接落地数据库原型 | ||
| 33 | 96 | ||
| 34 | - `/workspace`:样本与素材来源 | 97 | 如果你只读 3 份: |
| 35 | - `acr-engine/`:训练、索引、识别、服务主工程 | 98 | 1. [acr-architecture.md](./acr-architecture.md) |
| 36 | - 本地小样本验证:优先 **FAISS** | 99 | 2. [sota-evolution-guide.md](./sota-evolution-guide.md) |
| 37 | - 生产向量检索:统一 **pgvector** | 100 | 3. [postgresql-data-model.md](./postgresql-data-model.md) | ... | ... |
| 1 | # ACR 系统架构图 | 1 | # ACR 系统蓝图 / Architecture Blueprint |
| 2 | 2 | ||
| 3 | > 更新:2026-06-02 | 3 | > 更新:2026-06-04 |
| 4 | > 目标:把当前 ACR 原型、未来 SOTA 演进路径、以及不同角色的关注点统一到一份可读的系统蓝图里。 | ||
| 4 | 5 | ||
| 5 | ## 一页结论 | 6 | ## 一页结论 |
| 6 | 7 | ||
| 7 | - 识别链路已不是单一模型,而是 **指纹 + 向量 + melody-aware rerank** 的混合结构 | 8 | 当前仓库已经验证了一个可运行的混合识别原型: |
| 8 | - 数据与服务已经进入工业化演进阶段 | 9 | |
| 9 | - 当前主短板在:`humming_like` 与 `confused` 的 hard-case 精度 | 10 | - `Chromaprint / fingerprint`:负责 exact / near-duplicate 快速召回 |
| 11 | - `ECAPA-style embedding`:负责当前语义向量召回 baseline | ||
| 12 | - `melody-aware rerank`:负责弱旋律补强 | ||
| 13 | |||
| 14 | 但未来面向 **版权保护 + 100w 音频 / 30w 歌曲** 的目标,系统应演进为: | ||
| 15 | |||
| 16 | 1. **数据规范稳定**:`canonical_song -> work -> recording -> recording_asset -> audio_window` | ||
| 17 | 2. **底座模型可替换**:`model_registry -> feature_set_registry -> embedding/index` | ||
| 18 | 3. **检索链分层**:exact lane + semantic lane + version/cover lane + aggregation | ||
| 19 | 4. **服务与运维分离**:离线建库、在线召回、审核归一、监控治理分别有清晰职责 | ||
| 10 | 20 | ||
| 11 | --- | 21 | --- |
| 12 | 22 | ||
| 13 | ## 1. 总体架构图 | 23 | ## 1. 总体系统图 |
| 14 | 24 | ||
| 15 | ```mermaid | 25 | ```mermaid |
| 16 | flowchart LR | 26 | flowchart TD |
| 17 | Q[Query Audio] --> P[Preprocess] | 27 | A[Audio Sources\n官方母带 / 平台音频 / 抓取音频 / UGC / 录音] --> B[Asset Normalization] |
| 18 | P --> F1[Chromaprint Features] | 28 | B --> C[Canonical Data Model\nSong / Work / Recording / Asset / Window] |
| 19 | P --> F2[128-Mel Features] | ||
| 20 | P --> F3[Melody Signature] | ||
| 21 | |||
| 22 | F1 --> M1[Fingerprint Matcher] | ||
| 23 | F2 --> M2[ECAPA + BandSplit Embedder] | ||
| 24 | F3 --> M3[Melody Similarity] | ||
| 25 | 29 | ||
| 26 | C[Catalog References] --> I1[Fingerprint Index] | 30 | C --> D1[Exact Lane\nChromaprint / Neural AFP] |
| 27 | C --> I2[Embedding Window Index] | 31 | C --> D2[Semantic Lane\nFoundation Encoder] |
| 28 | C --> I3[Reference Melody Cache] | 32 | C --> D3[Version/Cover Lane\nPhase-2+] |
| 29 | 33 | ||
| 30 | M1 --> H[Hybrid Fusion] | 34 | D1 --> E[Candidate Aggregation] |
| 31 | M2 --> H | 35 | D2 --> E |
| 32 | M3 --> H | 36 | D3 --> E |
| 33 | 37 | ||
| 34 | H --> O[Top-K + Reject] | 38 | E --> F[Canonical Song Decision] |
| 39 | F --> G[Service / Review / Audit] | ||
| 35 | ``` | 40 | ``` |
| 36 | 41 | ||
| 37 | --- | 42 | --- |
| 38 | 43 | ||
| 39 | ## 2. 在线/离线分层图 | 44 | ## 2. 当前实现 vs 目标实现 |
| 45 | |||
| 46 | | 维度 | 当前实现 | 目标实现 | | ||
| 47 | |---|---|---| | ||
| 48 | | 底座向量模型 | ECAPA-style baseline | MERT / MuQ 等 foundation encoder 为主 | | ||
| 49 | | 检索结构 | chromaprint + embedding + melody | exact + semantic + version/cover + rerank | | ||
| 50 | | 数据主键 | 以 `song_id` 为核心 | `canonical_song / work / recording / asset / window` 分层 | | ||
| 51 | | 存储形态 | 原型式 pgvector schema + 文件产物 | PostgreSQL 主数据 + 可替换向量/索引层 | | ||
| 52 | | 服务目标 | 验证闭环 | 版权保护 / 归属判断 / 工业化运维 | | ||
| 53 | |||
| 54 | --- | ||
| 55 | |||
| 56 | ## 3. 角色视图 | ||
| 57 | |||
| 58 | ## 3.1 产品 / 架构角色 | ||
| 59 | |||
| 60 | 关注: | ||
| 61 | - 版权保护是否能最终定位到 `canonical_song_id` | ||
| 62 | - `recording` 与 `work` 的区别是否明确 | ||
| 63 | - 当前阶段是否坚持“先冻结规范、后迭代模型” | ||
| 64 | - 各团队之间接口是否清晰 | ||
| 65 | |||
| 66 | 最该读: | ||
| 67 | - 本文 | ||
| 68 | - [sota-evolution-guide.md](./sota-evolution-guide.md) | ||
| 69 | - [postgresql-data-model.md](./postgresql-data-model.md) | ||
| 70 | |||
| 71 | --- | ||
| 72 | |||
| 73 | ## 3.2 开发角色(后端 / 检索 / 数据) | ||
| 74 | |||
| 75 | 关注: | ||
| 76 | - 如何把音频导入统一实体模型 | ||
| 77 | - 如何切窗、建 feature_set、挂索引 | ||
| 78 | - 如何从 query 走到候选,再归一到 `canonical_song_id` | ||
| 79 | - 如何支持未来切换 `model_name / model_version / feature_set` | ||
| 80 | |||
| 81 | 最该读: | ||
| 82 | - 本文 | ||
| 83 | - [postgresql-data-model.md](./postgresql-data-model.md) | ||
| 84 | - [training-data-and-pgvector-guide.md](./training-data-and-pgvector-guide.md) | ||
| 85 | |||
| 86 | --- | ||
| 87 | |||
| 88 | ## 3.3 运维 / 平台角色 | ||
| 89 | |||
| 90 | 关注: | ||
| 91 | - 离线任务:抽特征、建索引、重建索引 | ||
| 92 | - 在线服务:召回、聚合、缓存、可观测性 | ||
| 93 | - 存储分层:对象存储、PostgreSQL、索引后端 | ||
| 94 | - 版本化:encoder 变更如何灰度、回滚、双写/双索引 | ||
| 95 | |||
| 96 | 最该读: | ||
| 97 | - 本文 | ||
| 98 | - [service-api.md](./service-api.md) | ||
| 99 | - [postgresql-data-model.md](./postgresql-data-model.md) | ||
| 100 | |||
| 101 | --- | ||
| 102 | |||
| 103 | ## 3.4 模型底座 / 研究角色 | ||
| 104 | |||
| 105 | 关注: | ||
| 106 | - Phase-1 先不用微调时,选哪个开源 encoder | ||
| 107 | - 如何定义 feature_set:窗长、hop、pooling、layer selection | ||
| 108 | - 未来如何从 encoder-only 升级到 version/cover lane | ||
| 109 | - 如何让新模型接入而不破坏数据层 | ||
| 110 | |||
| 111 | 最该读: | ||
| 112 | - [sota-evolution-guide.md](./sota-evolution-guide.md) | ||
| 113 | - [sota-research-2026.md](./sota-research-2026.md) | ||
| 114 | - [production-encoder-freeze-and-embedding-strategy.md](./production-encoder-freeze-and-embedding-strategy.md) | ||
| 115 | |||
| 116 | --- | ||
| 117 | |||
| 118 | ## 4. 离线 / 在线职责拆分 | ||
| 40 | 119 | ||
| 41 | ```mermaid | 120 | ```mermaid |
| 42 | flowchart TD | 121 | flowchart LR |
| 43 | A[Offline Pipeline] --> A1[Dataset Prep] | 122 | A[Offline\n数据治理/切窗/特征抽取/建索引] --> B[Registered Artifacts\nfeature_set / index / metadata] |
| 44 | A --> A2[Training] | 123 | B --> C[Online\nquery encode / retrieve / aggregate / decide] |
| 45 | A --> A3[Index Build] | ||
| 46 | A --> A4[Benchmark] | ||
| 47 | |||
| 48 | B[Online Service] --> B1[/health] | ||
| 49 | B --> B2[/recognize] | ||
| 50 | B --> B3[/index/build] | ||
| 51 | ``` | 124 | ``` |
| 52 | 125 | ||
| 126 | ### 离线职责 | ||
| 127 | - 资产标准化 | ||
| 128 | - 元数据归一 | ||
| 129 | - 切窗 | ||
| 130 | - 模型特征抽取 | ||
| 131 | - fingerprint / embedding 建索引 | ||
| 132 | - 回填 PostgreSQL 元数据 | ||
| 133 | |||
| 134 | ### 在线职责 | ||
| 135 | - 接收 query | ||
| 136 | - query 切块 / 编码 | ||
| 137 | - exact / semantic / version lane 召回 | ||
| 138 | - recording/work/song 聚合 | ||
| 139 | - 输出 `canonical_song_id` + 证据 | ||
| 140 | |||
| 53 | --- | 141 | --- |
| 54 | 142 | ||
| 55 | ## 3. 关键模块表 | 143 | ## 5. 为什么必须把角色拆开 |
| 56 | 144 | ||
| 57 | | 模块 | 输入 | 输出 | 作用 | | 145 | 因为这个项目已经不是单一模型脚本,而是: |
| 58 | |---|---|---|---| | 146 | |
| 59 | | Preprocess | wav | mel/chroma/f0 | 统一特征入口 | | 147 | 1. **数据治理系统**:谁的音频、属于哪个 recording/work/song |
| 60 | | Fingerprint Matcher | query audio | chroma candidates | 快速召回 | | 148 | 2. **检索系统**:如何从 query 找到候选 |
| 61 | | ECAPA Embedder | mel | embeddings | 语义向量检索 | | 149 | 3. **判定系统**:最终输出哪一个 `canonical_song_id` |
| 62 | | Melody Similarity | query/ref melody | melody score | 哼唱场景补强 | | 150 | 4. **服务系统**:如何对外提供 API 与可观测性 |
| 63 | | Hybrid Fusion | multi-scores | ranked candidates | 综合排序 | | 151 | 5. **演进系统**:底座模型会变,但数据规范不能跟着乱变 |
| 64 | | Service API | request | JSON result | 对外调用 | | ||
| 65 | 152 | ||
| 66 | --- | 153 | --- |
| 67 | 154 | ||
| 68 | ## 4. 当前设计重点 | 155 | ## 6. 当前阶段建议 |
| 156 | |||
| 157 | ### 当前最重要的不是继续改训练,而是: | ||
| 69 | 158 | ||
| 70 | ### 4.1 为什么是混合结构 | 159 | 1. 先把 PostgreSQL 数据规范稳定下来 |
| 71 | 纯指纹对哼唱弱,纯 embedding 对局部强匹配和解释性不足,因此使用混合结构更稳妥。 | 160 | 2. 先把 `model_registry / feature_set_registry` 结构打稳 |
| 161 | 3. Phase-1 用开源 encoder 直接做 semantic lane baseline | ||
| 162 | 4. 保留当前 ECAPA 作为历史 baseline / 对照组 | ||
| 72 | 163 | ||
| 73 | ### 4.2 为什么加入 melody-aware | 164 | ### 当前系统中的保留项 |
| 74 | 目前 hard-case 主要在哼唱/近旋律混淆,因此用 melody signature 做辅助排序。 | 165 | - `Chromaprint`:保留 |
| 166 | - `ECAPA baseline`:保留为对照组 | ||
| 167 | - `melody rerank`:保留为补充 lane,不再作为主演进方向 | ||
| 75 | 168 | ||
| 76 | ### 4.3 为什么要 window-level index | 169 | ### 当前系统中的升级项 |
| 77 | 整曲平均 embedding 会损失局部片段信息;window-level 更贴近 ACR 场景。 | 170 | - semantic lane 主 encoder -> foundation model |
| 171 | - pgvector 原型 schema -> 可扩展 PostgreSQL 数据模型 | ||
| 172 | - 扁平 song_id -> canonical/work/recording/recording_asset/audio_window | ||
| 78 | 173 | ||
| 79 | --- | 174 | --- |
| 80 | 175 | ||
| 81 | ## 5. 细节附录 | 176 | ## 7. 与代码的映射 |
| 82 | 177 | ||
| 83 | 代码映射: | 178 | | 代码/文档 | 当前角色 | |
| 84 | - `src/engines/chromaprint_matcher.py` | 179 | |---|---| |
| 85 | - `src/engines/ecapa_embedder.py` | 180 | | `acr-engine/src/engines/chromaprint_matcher.py` | exact lane 原型 | |
| 86 | - `src/engines/hybrid_engine.py` | 181 | | `acr-engine/src/engines/ecapa_embedder.py` | current embedding lane baseline | |
| 87 | - `src/service/app.py` | 182 | | `acr-engine/src/engines/hybrid_engine.py` | current aggregation prototype | |
| 183 | | `acr-engine/sql/pgvector_schema.sql` | 早期 pgvector prototype | | ||
| 184 | | `acr-engine/sql/acr_pg_schema_v2.sql` | 推荐的 PostgreSQL V2 schema | | ||
| 185 | | [postgresql-data-model.md](./postgresql-data-model.md) | V2 schema 设计说明 | | ||
| 186 | |||
| 187 | --- | ||
| 88 | 188 | ||
| 189 | ## 8. 阅读建议 | ||
| 89 | 190 | ||
| 90 | ## Sources | 191 | 如果你是: |
| 91 | - See `docs/references-and-sources.md` for the current source map. | 192 | - **架构负责人**:下一篇看 [sota-evolution-guide.md](./sota-evolution-guide.md) |
| 193 | - **数据/后端负责人**:下一篇看 [postgresql-data-model.md](./postgresql-data-model.md) | ||
| 194 | - **模型负责人**:先看 [sota-evolution-guide.md](./sota-evolution-guide.md) 再回到 [sota-research-2026.md](./sota-research-2026.md) | ... | ... |
docs/postgresql-data-model.md
0 → 100644
This diff is collapsed.
Click to expand it.
docs/sota-evolution-guide.md
0 → 100644
| 1 | # SOTA 演进方案说明 / SOTA Evolution Guide | ||
| 2 | |||
| 3 | > 更新:2026-06-04 | ||
| 4 | > 目标:给出一个“先不上微调、先用开源 encoder”的 Phase-1 路线,并明确后续如何演进到更强的版权保护 / 版本归属系统。 | ||
| 5 | |||
| 6 | ## 一页结论 | ||
| 7 | |||
| 8 | 如果当前约束是: | ||
| 9 | - 先不微调底座 | ||
| 10 | - 先要落数据规范 | ||
| 11 | - 先解决 100w 音频 / 30w 歌曲的检索与归属基础问题 | ||
| 12 | |||
| 13 | 那么最合理的 Phase-1 路线不是“重训一套新模型”,而是: | ||
| 14 | |||
| 15 | 1. **保留 exact lane**:Chromaprint / fingerprint | ||
| 16 | 2. **semantic lane 主底座**:MERT-v1-95M | ||
| 17 | 3. **semantic lane challenger**:MuQ | ||
| 18 | 4. **数据库先稳住**:`model_registry + feature_set_registry + audio_embedding + retrieval_index_registry` | ||
| 19 | 5. **结果先按层聚合**:window -> recording -> work -> canonical_song | ||
| 20 | |||
| 21 | --- | ||
| 22 | |||
| 23 | ## 1. 为什么当前要走 encoder-only Phase-1 | ||
| 24 | |||
| 25 | 因为你当前最紧迫的问题不是“模型精度极限”,而是: | ||
| 26 | |||
| 27 | - 曲库很大:100w 音频 / 30w 歌曲 | ||
| 28 | - 数据关系复杂:同曲可能有多录音、多版本、多来源资产 | ||
| 29 | - 如果数据规范不稳,未来任何模型升级都会反复返工 | ||
| 30 | |||
| 31 | 所以 Phase-1 目标应该是: | ||
| 32 | |||
| 33 | ```mermaid | ||
| 34 | flowchart LR | ||
| 35 | A[冻结数据规范] --> B[接入开源 encoder] | ||
| 36 | B --> C[建立 semantic baseline] | ||
| 37 | C --> D[做大规模索引与聚合验证] | ||
| 38 | D --> E[再决定是否进入微调 / version lane] | ||
| 39 | ``` | ||
| 40 | |||
| 41 | --- | ||
| 42 | |||
| 43 | ## 2. 推荐的阶段划分 | ||
| 44 | |||
| 45 | ## Phase-0:当前仓库阶段(已具备) | ||
| 46 | - `Chromaprint + ECAPA + melody rerank` | ||
| 47 | - 可跑通训练/建索引/评测/服务闭环 | ||
| 48 | - 适合作为 baseline,而不是最终生产底座 | ||
| 49 | |||
| 50 | ## Phase-1:Encoder-only foundation baseline(当前推荐) | ||
| 51 | - exact lane:Chromaprint | ||
| 52 | - semantic lane:MERT-v1-95M | ||
| 53 | - challenger:MuQ | ||
| 54 | - 不微调底座 | ||
| 55 | - 只做 feature extraction + index + aggregation | ||
| 56 | |||
| 57 | ## Phase-2:Version / Cover lane | ||
| 58 | - 在 Phase-1 数据模型稳定后 | ||
| 59 | - 引入 cover/version 专门分支 | ||
| 60 | - 强化 work-level 归属 | ||
| 61 | |||
| 62 | ## Phase-3:Industrial retrieval stack | ||
| 63 | - ANN + reranker | ||
| 64 | - online/offline artifact registry | ||
| 65 | - 监控、回放、审计、人工复核 | ||
| 66 | |||
| 67 | --- | ||
| 68 | |||
| 69 | ## 3. Phase-1 的推荐模型组合 | ||
| 70 | |||
| 71 | ## 3.1 Exact lane | ||
| 72 | ### 选型 | ||
| 73 | - Chromaprint / landmark hash | ||
| 74 | |||
| 75 | ### 作用 | ||
| 76 | - 原曲片段 | ||
| 77 | - 平台转码 | ||
| 78 | - near-duplicate | ||
| 79 | - 局部片段强匹配 | ||
| 80 | |||
| 81 | ### 为什么保留 | ||
| 82 | 版权保护不能只靠 semantic embedding。exact lane 在很多真实投诉/取证场景里仍然是最快且证据最强的第一条路径。 | ||
| 83 | |||
| 84 | --- | ||
| 85 | |||
| 86 | ## 3.2 Semantic lane 主模型:MERT-v1-95M | ||
| 87 | |||
| 88 | ### 推荐原因 | ||
| 89 | - 是 music SSL foundation model | ||
| 90 | - 已有公开论文与实现 | ||
| 91 | - 比自训小型 ECAPA 更符合音乐任务底座定位 | ||
| 92 | - Phase-1 直接做 frozen encoder 成本与风险都更低 | ||
| 93 | |||
| 94 | ### Phase-1 中的角色 | ||
| 95 | - 作为主 encoder 产出 window embedding | ||
| 96 | - 负责 noisy/BGM/一般跨域检索 baseline | ||
| 97 | - 后面可继续作为 teacher 或兼容旧索引版本 | ||
| 98 | |||
| 99 | ### 推荐 feature set | ||
| 100 | 1. `mert_v1_95m__window_5s_hop_2.5s__meanpool__l2` | ||
| 101 | 2. `mert_v1_95m__window_10s_hop_5s__meanpool__l2` | ||
| 102 | |||
| 103 | ### 为什么先做两套 | ||
| 104 | - `5s/2.5s`:更利于局部定位 | ||
| 105 | - `10s/5s`:更利于整体语义稳定 | ||
| 106 | |||
| 107 | --- | ||
| 108 | |||
| 109 | ## 3.3 Semantic lane Challenger:MuQ | ||
| 110 | |||
| 111 | ### 推荐原因 | ||
| 112 | - 更新、更接近下一代 music foundation model 路线 | ||
| 113 | - 值得作为 challenger baseline | ||
| 114 | - 即使不开微调,也有希望在部分 MIR 任务上优于较早底座 | ||
| 115 | |||
| 116 | ### 当前建议 | ||
| 117 | - Phase-1 先作为对照组,不立即替代 MERT | ||
| 118 | - 重点验证:向量分布稳定性、窗口级检索表现、内存/推理成本 | ||
| 119 | |||
| 120 | --- | ||
| 121 | |||
| 122 | ## 3.4 为什么 Phase-1 不直接以 CoverHunter 为主线 | ||
| 123 | |||
| 124 | 因为 CoverHunter 的优势在: | ||
| 125 | - cover song identification | ||
| 126 | - alignment / refined attention / coarse-to-fine 训练 | ||
| 127 | |||
| 128 | 而你当前约束是: | ||
| 129 | - 先不用微调 | ||
| 130 | - 先用开源 encoder | ||
| 131 | - 先把数据和检索规范落稳 | ||
| 132 | |||
| 133 | 所以它更适合作为 **Phase-2 的 version/cover lane 方向**,而不是 Phase-1 的主 baseline。 | ||
| 134 | |||
| 135 | --- | ||
| 136 | |||
| 137 | ## 4. 角色关注点 | ||
| 138 | |||
| 139 | ## 4.1 模型底座角色 | ||
| 140 | 重点关注: | ||
| 141 | - 哪些 encoder 已注册到 `model_registry` | ||
| 142 | - 每个 encoder 的 input SR、window、pooling、embedding dim | ||
| 143 | - 哪些 feature set 是线上候选,哪些只是实验候选 | ||
| 144 | |||
| 145 | ## 4.2 检索角色 | ||
| 146 | 重点关注: | ||
| 147 | - 指纹 lane 与 semantic lane 如何组合 | ||
| 148 | - `recording/work/song` 聚合规则 | ||
| 149 | - top-k 候选如何稳定输出 | ||
| 150 | |||
| 151 | ## 4.3 数据角色 | ||
| 152 | 重点关注: | ||
| 153 | - 资产去重 | ||
| 154 | - reference 资产选择 | ||
| 155 | - window manifest | ||
| 156 | - 是否支持全量重建特征与索引 | ||
| 157 | |||
| 158 | ## 4.4 运维 / 平台角色 | ||
| 159 | 重点关注: | ||
| 160 | - encoder 版本切换是否可灰度 | ||
| 161 | - 索引重建是否可并行 | ||
| 162 | - 热/冷索引、历史索引是否可回滚 | ||
| 163 | |||
| 164 | --- | ||
| 165 | |||
| 166 | ## 5. Phase-1 的实施顺序 | ||
| 167 | |||
| 168 | ```mermaid | ||
| 169 | flowchart TD | ||
| 170 | A[冻结 PostgreSQL 数据规范] --> B[导入 canonical/work/recording/asset/window] | ||
| 171 | B --> C[注册 model_registry / feature_set_registry] | ||
| 172 | C --> D[抽取 MERT 特征] | ||
| 173 | C --> E[抽取 MuQ 特征] | ||
| 174 | D --> F[构建 semantic index] | ||
| 175 | E --> F | ||
| 176 | F --> G[与 fingerprint lane 做聚合] | ||
| 177 | G --> H[输出 canonical_song_id / work_id / recording_id] | ||
| 178 | ``` | ||
| 179 | |||
| 180 | --- | ||
| 181 | |||
| 182 | ## 6. 每阶段解决的问题 | ||
| 183 | |||
| 184 | | 阶段 | 解决的问题 | 暂不解决的问题 | | ||
| 185 | |---|---|---| | ||
| 186 | | Phase-1 | 数据规范、开源底座 baseline、索引可重建、song/work/recording 聚合 | 底座微调、cover 专项训练、melody tower | | ||
| 187 | | Phase-2 | version/cover 归属、work-level recall | 更复杂跨模态 humming | | ||
| 188 | | Phase-3 | 工业化服务、回放、监控、人工审核闭环 | 极致 research SOTA | | ||
| 189 | |||
| 190 | --- | ||
| 191 | |||
| 192 | ## 7. 与当前仓库的关系 | ||
| 193 | |||
| 194 | ### 当前保留 | ||
| 195 | - `ECAPA baseline`:保留做对照,不作为长期主底座 | ||
| 196 | - `Chromaprint`:保留,且在版权保护场景里非常重要 | ||
| 197 | - `melody rerank`:保留为辅助 lane | ||
| 198 | |||
| 199 | ### 当前新增 | ||
| 200 | - `model_registry` | ||
| 201 | - `feature_set_registry` | ||
| 202 | - foundation encoder 特征抽取与注册 | ||
| 203 | - 更清晰的 `canonical_song / work / recording` 数据结构 | ||
| 204 | |||
| 205 | --- | ||
| 206 | |||
| 207 | ## 8. 当前推荐结论 | ||
| 208 | |||
| 209 | 如果今天就要给 Phase-1 定方案,我建议: | ||
| 210 | |||
| 211 | 1. **先不改训练主线,不删 ECAPA** | ||
| 212 | 2. **新增 MERT-v1-95M semantic lane** | ||
| 213 | 3. **新增 MuQ challenger lane** | ||
| 214 | 4. **只把 `is_reference=true` 的主参考窗口先做成热索引** | ||
| 215 | 5. **先把 PostgreSQL 设计当成主交付** | ||
| 216 | |||
| 217 | 换句话说: | ||
| 218 | |||
| 219 | > Phase-1 的核心不是“哪一个模型最终赢”,而是“数据规范 + 模型注册 + 特征注册 + 索引注册”这套长期结构先稳定下来。 |
-
Please register or sign in to post a comment