Skip to content

跨錄音語者連結:同一群人反覆出現的多份錄音,是目前每次用完就丟的最大證據來源 #181

Description

@kiki830621

Problem

每一份錄音都從零開始重新推斷「誰是誰」,推斷完就丟掉。

現況:轉錄一場會議 → 聲學分群 → (若有 enrollment)比對命名 → 輸出 SRT。下一場會議來時,整個過程重跑一次,完全不知道上一場已經見過這些人

但真實的使用情境幾乎都是同一群人反覆出現:定期會議(雙週/雙月/季)、研究團隊的組會、長期訪談的同一位受訪者、課程的同一批學生。一個會議系列跑一年,同一個人的聲音可能出現在六份錄音裡 —— 而這六份之間目前沒有任何連結

為什麼這是被浪費掉的最大一塊證據

單一場會議給你的是一個人的一份樣本,而且是在特定條件下錄的:那天他坐哪個位子、離麥多遠、感冒沒有、講話急不急。這份樣本的向量因此帶著大量與「他是誰」無關的變異。

六場會議給你的是六份樣本,來自六組不同的條件。這正是穩健語者模型需要的東西 —— 對條件取平均,留下跨條件不變的部分,那才是真正的個人特徵。

換句話說:目前系統手上其實有很好的資料,只是每次用完就扔。

而且這個累積是免費的 —— 不需要請任何人另外錄樣本,資料本來就會產生。

提議的機制

每份錄音內:分群(現況已有)
       ↓
跨錄音:把不同錄音的群連起來(同一個人在多場出現)
       ↓
人標一次:使用者在任一場標一個群 = 那個人
       ↓
標籤沿著連結傳播到所有錄音(含過去的、與未來的)

三個直接後果:

  • 冷啟動消失。 不必事前錄 enrollment 樣本。第一場會議先分群,之後任何時候標一次即可回溯生效。
  • 通道失配被結構性解決。 enrollment 不再是「某天某裝置錄的一段」,而是跨多場的中心,本身就涵蓋了條件變異。
  • 單邊判斷變成多路鑑別。 累積下來的是一整組人的向量;比對時是「這群最像誰」,錯誤指派會被別人的向量擋掉 —— 這正是 diarize 具名標籤 over-match:分群數低估 + 對混合體冠名,會把別人的發言記在註冊者頭上 #180 裡單一 enrollment 缺的東西。

出席名單是一個免費且獨立的約束

會議通常有出席名單。這給出兩個可交叉檢核的量:

這條不需要任何模型改動,只需要允許使用者提供一份與會者清單。

誠實邊界:這件事的失敗代價比單場更大

跨錄音連結比場內分群更難 —— 場內至少共享同一組通道特性,跨錄音連這個都沒有。

而錯誤的後果是放大的:一個錯誤連結會把錯的人名傳播到整個檔案庫,包含已經產出過的紀錄。單場的錯誤只汙染一份文件;跨場的錯誤會汙染全部,而且更難察覺 —— 因為「這個名字在每一場都出現」看起來反而像是可信的證據。

所以這個機制必須從一開始就帶著:

  1. 傳播要人確認,不是自動生效。連結本身可以自動算,但「把這個名字套到那五場」要有一個人按下去。
  2. 每個標籤要能追溯來源:它是人直接標的,還是從哪一場、經哪條連結傳過來的。
  3. 可撤銷:發現一個錯誤連結時,要能把沿著它傳播出去的所有標籤一起收回,而不是逐場去找。
  4. 寧可不連。 連結的門檻要比場內分群更保守 —— 漏連只是回到現狀,錯連是製造一個會自我強化的錯誤。

#179 / #180 的關係

三者處理同一個根本限制的三個切面 —— 單一遠場錄音對語者的可分辨度太低:

拿什麼補 補在哪個維度
#179 同一場的多支麥克風 空間(相對音量、到達時間差)
#180 具名比對的門檻與 surface 當下(別把混合體冠名、把分群數攤開)
本 issue 跨場次的多份錄音 時間(同一個人的多次獨立取樣)

三個可以獨立進行。但合起來看,方向是一致的:與其在單一份錄音裡把模型逼到極限,不如去拿那些本來就存在、卻一直被丟掉的額外觀測。

Impact

  • 定期會議這個主要使用情境,語者辨識的品質會隨使用次數自然變好,而不是每次都退回原點。
  • 使用者的投入從「每個人事前錄一段樣本」(幾乎沒人會做)降到「在某一場標一次」(順手就做了)。
  • 這是純加法:沒有累積的錄音時,行為與現況完全相同。

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions