ACR 系统蓝图 / Architecture Blueprint

更新：2026-06-04 目标：把当前 ACR 原型、未来 SOTA 演进路径、以及不同角色的关注点统一到一份可读的系统蓝图里。

一页结论

当前仓库已经验证了一个可运行的混合识别原型：

• Chromaprint / fingerprint：负责 exact / near-duplicate 快速召回
• ECAPA-style embedding：负责当前语义向量召回 baseline
• melody-aware rerank：负责弱旋律补强

但未来面向 版权保护 + 100w 音频 / 30w 歌曲 的目标，系统应演进为：

1. 数据规范稳定：canonical_song -> work -> recording -> recording_asset -> audio_window
2. 底座模型可替换：model_registry -> feature_set_registry -> embedding/index
3. 检索链分层：exact lane + semantic lane + version/cover lane + aggregation
4. 服务与运维分离：离线建库、在线召回、审核归一、监控治理分别有清晰职责

---

1. 总体系统图

flowchart TD
    A[Audio Sources\n官方母带 / 平台音频 / 抓取音频 / UGC / 录音] --> B[Asset Normalization]
    B --> C[Canonical Data Model\nSong / Work / Recording / Asset / Window]

    C --> D1[Exact Lane\nChromaprint / Neural AFP]
    C --> D2[Semantic Lane\nFoundation Encoder]
    C --> D3[Version/Cover Lane\nPhase-2+]

    D1 --> E[Candidate Aggregation]
    D2 --> E
    D3 --> E

    E --> F[Canonical Song Decision]
    F --> G[Service / Review / Audit]

---

2. 当前实现 vs 目标实现

维度	当前实现	目标实现
底座向量模型	ECAPA-style baseline	MERT / MuQ 等 foundation encoder 为主
检索结构	chromaprint + embedding + melody	exact + semantic + version/cover + rerank
数据主键	以 song_id 为核心	canonical_song / work / recording / asset / window 分层
存储形态	原型式 pgvector schema + 文件产物	PostgreSQL 主数据 + 可替换向量/索引层
服务目标	验证闭环	版权保护 / 归属判断 / 工业化运维

---

2.1 为什么现在会显得“层很多”

因为当前蓝图同时覆盖了 3 个维度：

1. 业务归属：song/work/recording
2. 音频实体：asset/window
3. 检索计算：feature/index/candidate/decision

把这三类问题放在一张总图中，会看起来像一条很长的链。 但在工程上，它们其实是不同职责：

• 业务归属层回答：最后该归谁
• 音频实体层回答：命中的是哪段音频
• 检索计算层回答：这段音频是怎么被召回出来的

---

2.2 当前最小可用架构可以收敛到什么程度

如果当前阶段只追求：

快速稳定地把 query 命中到正确 song_id

那 Phase-1 完全可以按下面这套最小骨架推进：

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

保留原因：

• window 不能删：它是 offset/evidence/多段投票的最小单元
• feature_set_registry / feature_fact 不能删：否则未来换 MERT/MuQ 会把 schema 写死
• asset 不能删：同一个 song 下会有多个真实音频文件

可以延后：

• recording
• work
• 更重的 retrieval_index_registry
• 更细的全链路审计表

因此推荐口径不是“把所有层都砍掉”，而是：

Phase-1 先上 song-centric 最小可用层；未来版本归属/cover/work 治理再继续加层。

---

3. 角色视图

3.1 产品 / 架构角色

关注：

• 版权保护是否能最终定位到 canonical_song_id
• recording 与 work 的区别是否明确
• 当前阶段是否坚持“先冻结规范、后迭代模型”
• 各团队之间接口是否清晰

最该读：

• 本文
• sota-evolution-guide.md
• postgresql-data-model.md

---

3.2 开发角色（后端 / 检索 / 数据）

关注：

• 如何把音频导入统一实体模型
• 如何切窗、建 feature_set、挂索引
• 如何从 query 走到候选，再归一到 canonical_song_id
• 如何支持未来切换 model_name / model_version / feature_set

最该读：

• 本文
• postgresql-data-model.md

---

3.3 运维 / 平台角色

关注：

• 离线任务：抽特征、建索引、重建索引
• 在线服务：召回、聚合、缓存、可观测性
• 存储分层：对象存储、PostgreSQL、索引后端
• 版本化：encoder 变更如何灰度、回滚、双写/双索引

最该读：

• 本文
• postgresql-data-model.md
• phase1-worker-contract.md

---

3.4 模型底座 / 研究角色

关注：

• Phase-1 先不用微调时，选哪个开源 encoder
• 如何定义 feature_set：窗长、hop、pooling、layer selection
• 未来如何从 encoder-only 升级到 version/cover lane
• 如何让新模型接入而不破坏数据层

最该读：

• sota-evolution-guide.md
• production-encoder-freeze-and-embedding-strategy.md
• postgresql-data-model.md

---

4. 离线 / 在线职责拆分

flowchart LR
    A[Offline\n数据治理/切窗/特征抽取/建索引] --> B[Registered Artifacts\nfeature_set / index / metadata]
    B --> C[Online\nquery encode / retrieve / aggregate / decide]

离线职责

• 资产标准化
• 元数据归一
• 切窗
• 模型特征抽取
• fingerprint / embedding 建索引
• 回填 PostgreSQL 元数据

在线职责

• 接收 query
• query 切块 / 编码
• exact / semantic / version lane 召回
• recording/work/song 聚合
• 输出 canonical_song_id + 证据

---

5. 为什么必须把角色拆开

因为这个项目已经不是单一模型脚本，而是：

1. 数据治理系统：谁的音频、属于哪个 recording/work/song
2. 检索系统：如何从 query 找到候选
3. 判定系统：最终输出哪一个 canonical_song_id
4. 服务系统：如何对外提供 API 与可观测性
5. 演进系统：底座模型会变，但数据规范不能跟着乱变

---

6. 当前阶段建议

当前最重要的不是继续改训练，而是：

1. 先把 PostgreSQL 数据规范稳定下来
2. 先把 model_registry / feature_set_registry 结构打稳
3. Phase-1 用开源 encoder 直接做 semantic lane baseline
4. 保留当前 ECAPA 作为历史 baseline / 对照组

当前系统中的保留项

• Chromaprint：保留
• ECAPA baseline：保留为对照组
• melody rerank：保留为补充 lane，不再作为主演进方向

当前系统中的升级项

• semantic lane 主 encoder -> foundation model
• pgvector 原型 schema -> 可扩展 PostgreSQL 数据模型
• 扁平 song_id -> canonical/work/recording/recording_asset/audio_window

---

7. 与代码的映射

代码/文档	当前角色
acr-engine/src/engines/chromaprint_matcher.py	exact lane 原型
acr-engine/src/engines/ecapa_embedder.py	current embedding lane baseline
acr-engine/src/engines/hybrid_engine.py	current aggregation prototype
acr-engine/sql/pgvector_schema.sql	早期 pgvector prototype
acr-engine/sql/acr_pg_schema_v2.sql	推荐的 PostgreSQL V2 schema
postgresql-data-model.md	V2 schema 设计说明

---

8. 阅读建议

如果你是：

• 架构负责人：下一篇看 sota-evolution-guide.md
• 数据/后端负责人：下一篇看 postgresql-data-model.md
• 模型负责人：先看 sota-evolution-guide.md 再看 production-encoder-freeze-and-embedding-strategy.md