本機語者分離技術：我們如何打造 100% 私密的會議筆記工具

本機語者分離是指在會議錄音中標記「誰在何時說話」的處理過程，全程在使用者的裝置上執行，不會將任何音訊、嵌入向量或逐字稿傳送至任何外部伺服器。 會議逐字稿有個「誰說了什麼」的問題。Zoom 給你的是一整面文字牆。多數 AI 筆記工具——Otter.ai、Fireflies、Read、Granola——的解法是把你的會議音訊上傳到它們的伺服器，在那裡執行語者模型，再把標記好的片段傳回來。你的聲音，以及同事們的聲音，最終都成了別人資料庫裡的向量。我們不想這樣，我們的使用者也不想。OpenWhispr 是建立在相反假設上的開源會議筆記工具：音訊絕不離開您的裝置，語者聲紋存放在您磁碟上的本機 SQLite 檔案中，除非您明確選擇上傳，否則會議的任何內容都不會被上傳。本文是這項承諾中語者分離面向的技術剖析——它是什麼、我們選了哪些模型、它們如何協同運作，以及每一個位元組的資料在每個步驟究竟存放在何處。

最後更新：2026 年 4 月 15 日。實作細節參照於 2026 年 4 月 14 日併入 OpenWhispr 桌面應用程式的語者分離功能。以下每項技術主張均出自第一手參考資料，或可直接在開源儲存庫中檢視。

• 語者分離回答的是「誰在何時說話」。 它會對照 NIST Rich Transcription 等社群基準與 pyannote.audio 參考流程進行評估。 NIST RT 評估 · pyannote.audio 論文（Bredin 等人，2020）
• 我們使用 pyannote-segmentation-3.0 以及來自 3D-Speaker 專案的 CAM++。 兩者皆為開源、皆可移植為 ONNX，且皆直接從 sherpa-onnx 模型發行版下載。 pyannote-segmentation-3.0 模型卡 · CAM++ / 3D-Speaker 論文（Wang 等人，2023）
• 所有推論皆透過 sherpa-onnx 執行，這是一個原生 ONNX 二進位檔——不需 Python 執行環境、不需 PyTorch、不需 GPU。 我們在建置時將該二進位檔及其相依套件版本鎖定。 sherpa-onnx 於 GitHub · sherpa-onnx 發行版
• 聲紋是 512 維的 float32 向量，以本機 SQLite BLOB 形式儲存， 每位語者約 2KB。它們絕不離開裝置。 SQLite 資料型別文件 · ONNX Runtime
• 在語者分離過程中，不會有任何音訊、嵌入向量或逐字稿被傳出裝置之外。 整個功能唯一的網路活動，是首次啟動時的一次性模型下載，您可以親自在開源儲存庫中檢視。 OpenWhispr 隱私權政策 · OpenWhispr 於 GitHub

語者分離是指在錄音中標記「誰在何時說話」的處理過程——而非他們說了什麼。 轉錄回答「說了什麼」；語者分離回答「是誰說的」。兩者相輔相成：一個好的會議筆記工具兩者都需要，而要讓它們協同運作，比單獨處理任何一項都更困難。

語者分離之所以真的很難，有幾個頑固的原因。同一通話中可能有兩個聲音重疊。背景雜訊會滲入其中。短句（「對」、「好」）幾乎不帶任何語者資訊。新的語者可能在會議進行到一半時才出現。而且與轉錄不同，語者分離必須做出全域性的判斷——它無法在不與第二段比對的情況下，獨自標記第七段。正是這種全域脈絡，使得多數商業解決方案選擇在伺服器端對完整錄音進行語者分離，再把標記好的逐字稿傳回。

光有轉錄是不夠的。一場十人會議、四十五分鐘的交叉討論，若呈現為一整面毫無區隔的文字牆，根本無法閱讀。會議筆記——人們真正想要的實際成果——需要語者歸屬，因為待辦事項、決策與承諾全都繫於特定的人。「Alice 會在週五前完成這次遷移」是一條筆記。「會在週五前完成這次遷移」則是雜訊。

OpenWhispr 的語者分離流程有四個階段：語音活動偵測、切分、語者嵌入與分群——之後再加上一個合併步驟，將語者片段與逐字稿對齊。 每個階段都是獨立的 ONNX 模型或原生二進位檔。不需 Python 執行環境、不需 PyTorch、不需 CUDA。這些模型在磁碟上的總佔用空間約為 45MB。

音訊擷取從第一天起就是雙串流的。麥克風在定義上就是「您」，因此我們從不耗費運算資源去為您自己的聲音做語者分離——每一段麥克風片段都依來源標記為「您」，而非靠聲音比對。系統音訊（通話中的其他所有人）才是唯一真正需要語者切分的對象，這一來就立即省下一半的工作量。

音訊一旦擷取完成，四個階段便依序執行。VAD 會濾掉靜音，讓昂貴的嵌入階段不會把運算週期浪費在空白音框上。切分會把連續語音切成單一語者的片段。嵌入模型把每個片段轉換成 512 維的聲紋。聚合式分群會把看起來相似的聲紋歸為一群，產出最終的語者 ID 集合。最後一道處理依時間戳記重疊，把這些 ID 合併回逐字稿，使每個字都標上語者。

整套流程都在從應用程式衍生出的單一子處理程序中執行——沒有伺服器、沒有監聽埠、不對 Electron 以外的任何東西進行 IPC。您可以閱讀開源儲存庫中的 src/helpers/diarization.js 來確認這一點。

語音活動偵測（VAD）是在昂貴階段執行之前，把語音與靜音分開的廉價過濾器。 對靜音執行語者嵌入模型既浪費 CPU，又會產出無用的向量。VAD 正是讓流程其餘部分得以保持快速的關鍵。

我們使用 Silero VAD：一個 2MB 的 ONNX 模型，採 MIT 授權，實質上是開源業界的預設選擇。Silero 會回傳目前這個 32 毫秒視窗含有語音的逐音框機率。在現代 CPU 上，其成本微乎其微——每 32 毫秒音框約 0.1 毫秒，大約只佔單核心的千分之三。

即時流程會在通話期間對系統音訊持續執行 Silero。我們實際出貨採用的門檻，是針對真實會議音訊調校的，而非乾淨的基準測試：

• 視窗大小： 512 取樣（16kHz 下為 32ms）
• 語音門檻： 0.15——刻意設得積極，以免漏掉音量小或距離遠的語者
• 靜音門檻： 0.08
• 片段結束條件： 連續 16 個靜音視窗（約 512ms）後
• 嵌入所需最小片段： 0.8 秒
• 即時辨識頻率： 在累積 ≥1.6 秒語音後，每 1 秒一次

切分會把連續語音切成各自只含一位語者的片段，同時偵測語者轉換點與重疊區段。 這是決定語者邊界落在何處的階段。它之後的一切，都假設那些邊界是正確的。

我們使用 pyannote-segmentation-3.0，這是 pyannote.audio 團隊該模型的現行版本，由 sherpa-onnx 專案匯出為 ONNX。Pyannote 是事實上的學術基準：pyannote.audio 流程在 AMI 與 CALLHOME 等標準基準上，能達到 12–15% 區間的語者分離錯誤率——這正是商業雲端供應商愛引用的數字。

為何特別選 ONNX 版本？因為在 Electron 應用程式裡塞進 PyTorch 根本行不通——光是執行環境就約 1.5GB，而且實質上需要 GPU 才能跑得快。ONNX 匯出版只是一個 6.6MB 的單一檔案，透過 ONNX Runtime在 CPU 上執行。同樣的模型，重量卻只是其中極小的一部分。

我們透過 sherpa-onnx 的離線語者分離二進位檔搭配少數幾個旗標來呼叫它。最小時長的設定取自 pyannote 論文建議的預設值：短促的語音爆發會被併入相鄰的靜音，而短暫的靜音不會打斷連續的語者片段。輸出是一串以起訖時間配對、標上暫定語者 ID 的清單（ speaker_0, speaker_1等等）。

語者嵌入向量是一串固定長度的數字，它代表一個聲音的方式，就像雜湊值代表一個檔案一樣。 同一個聲音的兩段錄音會產生在向量空間中彼此相近的嵌入向量；不同的聲音則產生彼此相距甚遠的嵌入向量。「相近」是以餘弦相似度來衡量——一個介於 -1 與 1 之間的單一數值。這是流程中其餘一切運作的數學核心。

我們的嵌入模型是來自阿里巴巴達摩院 3D-Speaker 專案的 CAM++，在 VoxCeleb 語者驗證基準上訓練。我們實際出貨的檔案是 3dspeaker_speech_campplus_sv_en_voxceleb_16k.onnx，一個約 28MB 的 ONNX 匯出版，能為每個片段產出一個 512 維的 float32 向量。其論文為 arXiv:2303.00332（Wang 等人，2023）。

我們選擇 CAM++ 而非顯而易見的替代方案 ECAPA-TDNN，有三個具體的理由：參數量大約只有一半、在 VoxCeleb1-O 上有更低的等錯誤率，以及更快的 CPU 推論。NVIDIA NeMo 的 MSDD 模型沒有官方 ONNX 匯出版，且高度依賴 PyTorch。Picovoice Falcon 帶有商業的按席位授權。Apple 的 CoreML Speech 框架僅限 macOS。CAM++ 是唯一同時滿足我們各項條件的選擇——跨平台、ONNX、開源授權、CPU 高速。

為了餵給 CAM++，我們在 src/helpers/speakerEmbeddings.js中內建了自己的對數梅爾濾波器組特徵擷取器：80 個梅爾頻帶、25 毫秒視窗、10 毫秒跳距，皆為此類模型的標準參數。特徵會透過 onnxruntime-node流入 ONNX 模型，於 Electron 主處理程序中執行。另一端輸出的是一個 512 項的 Float32Array，我們將它以 2,048 位元組的 BLOB 寫入 SQLite。

比對步驟本身是最簡單不過的事：兩個向量之間的餘弦相似度。以下就是判定兩個會議片段是否為同一位語者的實際程式碼：

// src/helpers/speakerEmbeddings.js
cosineSimilarity(a, b) {
  let dot = 0, normA = 0, normB = 0;
  for (let i = 0; i < a.length; i++) {
    dot += a[i] * b[i];
    normA += a[i] * a[i];
    normB += b[i] * b[i];
  }
  const denom = Math.sqrt(normA) * Math.sqrt(normB);
  return denom === 0 ? 0 : dot / denom;
}

為每個片段做完嵌入後，你會得到 N 個向量。分群會把它們歸成 K 位語者——但困難之處在於，你通常事先並不知道 K 是多少。 一通業務電話可能有 2 位語者。一場全員大會可能有 8 位。固定 K 值的分群在兩端都會出問題。

我們使用餘弦相似度門檻為 0.5 的聚合式分群：一開始把每個片段各自當成一群，合併相似度最高的兩群，重複此步驟直到剩下的所有配對都沒有任何一對超過門檻為止。決定何時停止的，是門檻，而非目標數量。這能從兩位語者自然地延伸到十位，完全不需任何設定。

實際的呼叫位於 src/helpers/diarization.js。它是 sherpa-onnx 二進位檔搭配少數幾個 CLI 旗標的衍生：

// src/helpers/diarization.js
const args = [
  `--segmentation.pyannote-model=${segPath}`,
  `--embedding.model=${embPath}`,
  `--clustering.num-clusters=${numSpeakers}`,    // -1 = auto
  `--clustering.cluster-threshold=${threshold}`, // 0.5 default
  "--min-duration-on=0.2",
  "--min-duration-off=0.5",
  wavPath,
];

輸出為純文字：每個片段一行，格式為 start_sec -- end_sec speaker_NN。我們將它解析成一個物件陣列，接著走訪逐字稿，把每個逐字稿片段比對到時間重疊最多的語者分離片段。麥克風來源的片段一律標記為 you——來源永遠勝過聲音。

0.5 這個門檻不是猜的。我們是對照自己的評估框架（scripts/meeting-diarization-eval.js），在真實會議錄音上調校出來的。門檻太高會分群不足——一位語者被拆成兩位。門檻太低會分群過度——兩個相似的聲音被合併。0.5 是我們收斂出來的最佳平衡點。

只做批次語者分離雖然準確，但在通話過程中完全看不見。只做即時雖然立即可見，卻容易出錯。OpenWhispr 兩者都跑：即時標籤在會議中即時出現，完整的批次處理則在事後加以精修。

即時路徑位於 src/helpers/liveSpeakerIdentifier.js。它以 16kHz 接取系統音訊串流，把每個 32 毫秒音框餵進 Silero VAD，並持續累積語音音框，直到某個片段結束（在約 512ms 的靜音之後），或達到即時辨識頻率（在累積 ≥1.6 秒後每 1 秒一次）。一旦觸發，它便擷取一個 CAM++ 嵌入向量，將其與記憶體中通話進行中嵌入向量及已儲存語者檔案的對應表比對，接著發出一個 IPC 事件—— meeting-speaker-identified——並附上最佳比對結果。React 端接收到後，便就地更新逐字稿氣泡。

一旦有人在使用者介面中手動設定了語者名稱，該指派便會被 鎖定。會後的批次處理不得覆寫它，即便它自己的分析結果有所不同也不行。這個鎖定行為位於 src/utils/transcriptSpeakerState.ts，而它很重要：最糟糕的使用者體驗，莫過於放任自動化處理悄悄覆寫使用者的更正。

錄音停止後，我們會對完整的 WAV 檔案執行完整的離線語者分離。批次處理擁有完整脈絡——它看到的是整場會議，而非只有最後 1.6 秒——因而能產出更乾淨的最終標記。批次結果會與即時標籤對齊、尊重每一道使用者鎖定，並以更準確的分群取代暫定的猜測。

一旦您在某場會議中將某位語者標記為「Alice」，OpenWhispr 便會在日後每場會議中自動為她標記——無需您做任何事，也不會讓她的聲紋離開您的裝置半步。

其機制很直接：每位語者的質心嵌入向量都會儲存在您本機的 SQLite 資料庫中。當日後通話出現新的嵌入向量時，我們會以餘弦相似度將其與每一個已儲存的檔案比對。相似度高於門檻的比對結果會自動指派名稱。這一切完全不觸及任何伺服器。支撐它的三張資料表都是單純的 SQLite：

-- src/helpers/database.js
CREATE TABLE speaker_profiles (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  display_name TEXT NOT NULL,
  email TEXT,
  embedding BLOB NOT NULL,          -- 512 float32s (~2KB)
  sample_count INTEGER DEFAULT 1,
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
  updated_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE speaker_mappings (
  note_id INTEGER NOT NULL,
  speaker_id TEXT NOT NULL,
  profile_id INTEGER,
  display_name TEXT NOT NULL,
  PRIMARY KEY (note_id, speaker_id),
  FOREIGN KEY (note_id) REFERENCES notes(id) ON DELETE CASCADE,
  FOREIGN KEY (profile_id) REFERENCES speaker_profiles(id) ON DELETE SET NULL
);

CREATE TABLE note_speaker_embeddings (
  note_id INTEGER NOT NULL,
  speaker_id TEXT NOT NULL,
  embedding BLOB NOT NULL,
  PRIMARY KEY (note_id, speaker_id),
  FOREIGN KEY (note_id) REFERENCES notes(id) ON DELETE CASCADE
);

比對採三層機制，以在信心程度與誤判之間取得平衡：

• 餘弦 ≥ 0.70： 自動確認。標籤立即出現，不會有任何提示。
• 0.55 ≤ 餘弦 < 0.70： 建議。使用者介面會顯示「這是 Alice 嗎？」並附上確認／略過控制項，等待您的輸入。
• 餘弦 < 0.55： 保持匿名。該片段維持為「語者 N」，直到您手動為其命名。

當您確認一筆比對時，已儲存的質心會以滑動平均的方式更新，而非直接覆寫。公式很簡單： new_avg = (stored_avg × sample_count + new_embedding) / (sample_count + 1)。這能處理聲音漂移——某個寒冷的早晨、換了支麥克風、一條品質不佳的線材——而不致破壞日後的比對。系統見過 Alice 聲音的樣本越多，她的檔案就越穩定。

新的檔案還會觸發 回溯重新標記。當您首次為某位語者命名時，一個背景工作會走訪每一場過往會議所儲存的嵌入向量，找出比對結果，並更新歷史逐字稿中先前未命名的語者。被使用者鎖定的對應永遠不會被觸碰。其結果是：為 Alice 命名一次，便能回溯地在她參與過的每一通先前通話中為她標記。

若已連接 Google Calendar 且會議有與會者，語者選擇器的使用者介面會以他們的名字與電子郵件預先填入。一鍵即可對應 語者 2 → alice@example.com並永久保存——與會者與語音檔案保持連結，因此即便跨裝置也會顯示正確的名字。

音訊絕不離開您的裝置。這不是一句行銷話術——它是程式碼的機械性質，而由於 OpenWhispr 是開源的，您可以親自驗證。 以下就是每一筆資料在每個步驟究竟經歷了什麼。

來自會議的原始 PCM 音訊會被寫入您作業系統暫存目錄中的一個檔案，交給本機衍生的 sherpa-onnx 二進位檔，並在語者分離完成時於一個 finally區塊中刪除。OpenWhispr 的語者分離流程中沒有任何一條程式路徑會開啟網路通訊端來上傳音訊。由於程式碼是開源的，您可以 grep src/helpers/diarization.js, src/helpers/liveSpeakerIdentifier.js、 src/helpers/speakerEmbeddings.js 與 fetch, axios找出 http 或

Electron 主處理程序與算繪處理程序之間的 IPC 使用內建的 contextBridge ——這是單一處理程序內核心層級的管道，而非網路通訊端。語者嵌入向量與語音檔案以 SQLite BLOB 形式，儲存在與您筆記相同的資料庫檔案中，並具有相同的作業系統層級檔案權限。

本機語者分離很好，但並非完美。以下是它真正會吃力的情況，以及我們對每一種情況的因應之道。

• 語者重疊。 兩個人同時說話，對單一標籤歸屬而言本質上就是有損的。Pyannote 3.0 會偵測到重疊區段，但每段一個 speaker_id 不足以表現「兩個人同時在說話」。我們會把那些片段標記為暫定，並讓您在使用者介面中加以更正。
• 冷啟動準確度。 與某位新同事的第一場會議只能仰賴通用的 VoxCeleb 訓練特徵。一旦您為他們標記過一次、檔案累積了幾個樣本後，後續的會議便會明顯更準確。
• 短句。 「對」、「好」、一聲快速的笑——任何短於約 0.8 秒的內容都無法產出可靠的嵌入向量。我們會把那些片段從嵌入階段剔除，改以從周遭脈絡進行標籤傳播作為後備。
• 遠場或低訊噪比音訊。 在吵雜房間裡用手機擴音的人，品質會優雅但明顯地下降。自動增益控制與 VAD 調校有幫助，但再高超的模型也無法完全克服糟糕的物理條件。
• 純 CPU 推論。 GPU 會更快，但我們刻意不要求使用它。實務上，現代 CPU 的吞吐量綽綽有餘：每個嵌入向量約 100 毫秒，而一場 45 分鐘的會議在 M1 Mac 上約需 30 秒的批次語者分離。

我們在開源儲存庫中公開了評估框架（ (scripts/meeting-diarization-eval.js) ），讓您可以親自在自己的錄音上衡量以上任何一項——而非我們精挑細選的展示片段。這比起行銷簡報裡一個光鮮亮麗的數字，感覺更為誠實。

我們需要一個跨平台、不依賴 Python、CPU 高速且開源的語者分離執行環境。Sherpa-ONNX 是唯一同時命中這四點的選擇。

我們的需求很具體。它必須能在 macOS（Intel 與 Apple Silicon 皆是）、Windows x64 與 Linux x64 上執行，且不需各自分立的程式路徑。它不能綁帶 PyTorch——光是執行環境就約 1.5GB，而且實質上需要 GPU 才能在互動式延遲下堪用。它不能要求 CUDA。而且授權必須足夠寬鬆，能放進一個商業但開源的桌面應用程式出貨。

以下是我們實際評估過的對象：

• pyannote.audio（Python）： 排除。在 Electron 應用程式裡綁帶 PyTorch 根本行不通。
• NVIDIA NeMo MSDD： 依賴 PyTorch、無官方 ONNX 匯出版、以 GPU 為核心。
• Picovoice Falcon： 商業的按活躍使用者授權，外加首次執行時需雲端啟用。
• Apple CoreML + Speech 框架： 僅限 macOS，無跨平台對等性。
• sherpa-onnx: Apache 2.0、原生 ONNX 二進位檔、約 35MB 的模型、衍生並讀取 stdout 的介面，由 k2-fsa 積極維護。同一套工具鏈也在其他已出貨產品中驅動正式環境的 ASR。

一個坦誠的但書：sherpa-onnx 的離線語者分離二進位檔相對較新。我們版本鎖定到 v1.12.23，並在每次提升鎖定版本之前，對每次更新執行完整的評估框架。對於這種如此關鍵的元件而言，這是正確的取捨。

有沒有不會把我的音訊上傳到雲端的私密會議筆記工具？

有。OpenWhispr 是一個免費、開源的會議筆記工具，您的音訊絕不離開您的裝置。轉錄以 OpenAI Whisper 或 NVIDIA Parakeet 在本機執行，語者分離以 pyannote 切分與 CAM++ 嵌入向量在本機執行，而聲紋則儲存在您自己機器上的本機 SQLite 檔案中——而非我們的伺服器上。

Otter.ai、Fireflies 或 Granola 能看到我的會議嗎？

能。以雲端為基礎的 AI 筆記工具會把您的會議音訊上傳到它們的伺服器，以便進行轉錄與語者分離。語者標籤、逐字稿與語音嵌入向量都在它們的基礎設施中運算，並儲存在它們的資料庫裡。如果您需要一個能把每一個位元組的音訊都留在您裝置上的替代方案，您需要的是像 OpenWhispr 這樣的本機優先工具。

什麼是語者分離？

語者分離是指在錄音中標記「誰在何時說話」的處理過程，有別於回答「說了什麼」的轉錄。一份經語者分離的逐字稿，會將每句話標上語者標籤——Alice、Bob、語者 3——而非一整面毫無區隔的文字牆。

本機語者分離真的有用嗎，還是相較於雲端只是降級？

有用。OpenWhispr 的流程——pyannote-segmentation-3.0 搭配來自 3D-Speaker 專案的 CAM++ 嵌入向量，透過 sherpa-onnx 執行——在標準基準上所達到的語者分離錯誤率，與商業雲端 API 處於同一水準。主要而坦誠的取捨在於語者重疊的處理，以及系統從未聽過的聲音的冷啟動準確度。

本機語者分離模型會用掉多少磁碟空間？

總計約 45MB：pyannote 切分（6.6MB）加上 CAM++ 語者嵌入模型（28MB）再加上 Silero VAD（2MB）。三者皆於首次啟動時下載一次，並快取於 ~/.cache/openwhispr/diarization-models/。之後它們便留在磁碟上，永不重新下載。

我需要 GPU 才能執行 OpenWhispr 的本機語者分離嗎？

不需要。一切都透過 ONNX Runtime 在 CPU 上執行。現代的 Apple Silicon 與近期的 x86 CPU 都能輕鬆勝任——實務上，一場 45 分鐘的會議在 M1 Mac 上約需 30 秒的批次語者分離，而即時語者標籤則在通話過程中一兩秒內就會出現。

OpenWhispr 真的是開源的嗎？

是的。語者分離程式碼、轉錄流程以及桌面應用程式的其餘部分，都在 GitHub 上開源。本文中的隱私主張可直接驗證：在語者分離輔助程式中 grep fetch、axios 或 http，您不會在語者分離路徑中找到任何網路呼叫。

當通話中兩個人互相搶話時會發生什麼事？

Pyannote 3.0 會明確偵測並標註重疊區段，但重疊期間的單一標籤歸屬本質上就是有損的。我們會把那些片段在逐字稿中標記為暫定，並讓您透過點按語者標籤來更正。您的手動更正會被鎖定，永遠不會被後續的自動化處理覆寫。