會議摘要用哪個 LLM 最好？鎖定模型的工具為什麼輸（粵語多語言適用）

如果你看過一份 AI 生成的會議摘要、心想「這個完全捉錯重點」或「這個發明了沒有人真正承諾過的行動項」，那你就撞到了 LLM 契合問題。不同模型在摘要會議上有可量度的不同強項——長上下文處理、多語言覆蓋、文筆、跟指令、每次摘要成本。在其中一個維度最強的模型，很少在全部都最強。

大部分會議轉錄工具——Otter、Fireflies、Fathom、Descript、Plaud、NotebookLM——選一個模型（或一個它們不披露的層級內的模型）就鎖定你。當廠商選的那個不適合你的會議類型，你的摘要就受影響，而你除了轉工具之外沒有辦法補救。

本文是關於怎樣思考這個選擇，並誠實申報：我經營 Subanana。Subanana 讓用戶選擇哪個 LLM 寫他們的摘要——是我們產品內唯一一個模型選擇是用戶可見決定的功能。這個論點不論你是否使用 Subanana 都適用：重點是理解這些維度，然後就任何工具的做法對照評估。

一句總結

沒有單一 LLM 是「會議摘要最好」。 合適的模型取決於你的會議是什麼、你需要什麼輸出。
長會議（90 分鐘以上）獎勵長上下文模型。 上下文窗口容量在不同家族之間差異很大。
高節奏會議獎勵速度優化的中層模型。 抽取行動項與乾淨的結構化輸出比推理深度更重要。
多語言會議獎勵多模型做法多於任何單一「多語言」模型。非英文或粵英夾雜內容的最佳摘要 LLM，很少與純英文那個一樣。
高風險溝通獎勵有文筆的高階旗艦。 邊際成本小；輸出差別有意義。
例行內部會議獎勵預算層模型。 在一個 15 分鐘團隊同步丟一個旗艦下去，是浪費它的推理深度。

對大部分用戶的實際答案是：預設用中層模型，在真正重要的會議切到高階，不要為具體版本號碼煩惱。 層級結構穩定；每個層級內的具體前沿模型每隔幾個月就變。

真正有差異的維度

LLM 在會議摘要工作上有意義地不同的五條軸：

上下文窗口。 模型一次過可以容納多少轉錄稿？30 分鐘會議對大部分模型都舒適；一個 3 小時董事會就把長上下文旗艦與其餘區分開。
跟指令。 當你要求「決定、行動項、跟進，按這個次序」，模型有沒有乾淨地交出那個結構，還是自由發揮？跟指令強的模型產出你不需要重塑就可以放入下游工作流程的摘要。
抗幻覺。 模型會不會捏造沒有真正同意過的行動項？高階推理模型傾向更保守；預算層模型在壓力下會鬆散地意譯。
多語言處理。 主要用英文訓練的模型，產出的非英文與粵英夾雜內容摘要明顯更差。這個差距比廠商通常承認的更大。
每次摘要成本 + 延遲。 旗艦層模型可以是中層模型的 5–10 倍成本，而輸出你可能看不出分別。延遲差異類似。

留意這份清單缺了什麼：一個總體「智能」分數。公開 LLM benchmark（MMLU、HumanEval 等）把模型在大部分不是會議摘要的總體任務上排名。一個在數學推理勝出的模型，不一定在由策略討論抽取決定上勝出。就這個特定用例來說，把總體 benchmark 當作噪音。

為什麼大部分會議工具不讓你選擇

看看主要會議工具怎樣處理 LLM 選擇：

Otter.ai——廠商選的 AI 做摘要；沒有用戶選擇底層 LLM
Fireflies.ai——廠商選的 AI 做摘要；沒有外露切換
Fathom——廠商選的 AI 做筆記；沒有用戶切換
Plaud——硬件裝置把錄音送到自己的 AI 摘要引擎；沒有模型選擇器
NotebookLM（Google）——鎖定在 Google 自己的模型生態
Descript——廠商選的內部模型選擇；沒有用戶選擇器

鎖定模式很普遍。每個廠商在「LLM」實際上是一個主流選擇時設計它們的產品，而重新架構成多模型系統並不簡單——不同 API、逐模型不同的提示工程、逐供應商不同的成本追蹤基建。大部分廠商決定模型選擇不值得做用戶可見差異化。Subanana 下了相反的注：模型選擇是一個值得在選擇器外露的用戶可見決定。

Subanana 的做法怎樣運作

Subanana 的會議摘要功能呈現一個三層選擇器：高階、進階、標準。每個層級內坐著來自不同家族的多個前沿模型。你選擇層級（或具體模型，如果你有偏好）；你的摘要就由那個模型寫。

層級結構穩定；每個層級內的具體模型持續輪替。新前沿模型就四個準則評估——智能、吞吐量、價格、上下文窗口——並在它在那層級勝過現任時加入。表現差的輪走。在用戶角度看，層級選擇器隨時間靜靜地改善，不需要他們追蹤個別模型推出。

三樣要點出：

沒有廠商鎖定。 沒有承諾單一供應商。名冊橫跨多個主要模型家族。
UI 沒有「Preview」後綴。 Preview 標記的模型可能在幕後使用，但選擇器只顯示基本名稱——減少在路由層分辨 preview vs GA 的認知負擔。
某模型缺席不等於拒絕。 例如 Anthropic 的 Claude 目前不在 Subanana 菜單。那是就四個準則做滾動評估的結果——價格、存取限制、相對其他選擇的吞吐量——而非永久排除。隨著那些因素演變，菜單也演變。

至於每個層級內的當前具體版本名稱，請參考 Subanana app 內的模型選擇器——那個菜單是即時的真相來源，而非這篇 blog。

實用選擇指南

大部分用戶需要的框架很短：

何時選高階層：

會議真正重要（董事會、策略規劃、客戶升級、法律程序）
會議長（90 分鐘以上——上下文窗口容量成為差異點）
輸出給高層或客戶、不經大量人手編輯——文筆是承重

何時選進階層（大部分會議的預設）：

例行內部會議、銷售通話、客戶成功 check-in、專案同步
速度 + 乾淨結構化輸出比最大推理深度更重要
對你的用例來說，相對高階的邊際質素差別不值那個約 3–5 倍成本比

何時選標準層：

高量例行摘要（每用戶每日多場會議）
15 分鐘 check-in，任何結構化摘要都好過沒有摘要
你對成本敏感，而高階的推理深度會在那些內容浪費

至於多語言或粵英夾雜會議： 底層轉錄路由處理語音轉文字的語言步驟（Subanana 就每種源語言 benchmark STT 模型，在 80+ 種支援語言路由至評估最佳的那個）。至於摘要步驟，選擇器一樣適用——試高階或進階層，在你實際內容比較。沒有單一「多語言專家 LLM」在所有非英文內容都勝出；合適的選擇是實證，而非理論。對於要寫好中文摘要的香港團隊，可以選擇寫中文最好的那個模型。

何時生成兩次

對高風險摘要（董事會記錄、法律 readout、客戶升級報告），把同一份轉錄稿放入兩個不同模型可能值回雙倍成本。你不是跑 benchmark——你是對沖某個模型對你特定內容的盲點。選擇較好的輸出，或合併最強的部分。

這個今日是人手工作流程：觸發摘要、在選擇器切換 LLM、再觸發。對輸出會被細讀的會議值得；對例行內容是過頭。

常見問題

選擇 LLM 對大部分用戶是否太技術性？

Subanana 的 UX 呈現三層選擇器（高階 / 進階 / 標準），因此不想思考具體模型的用戶可以選擇層級，讓 Subanana 路由至那層級當前評估最佳的模型之一。在意具體模型的用戶可以按名選擇。兩種受眾都照顧到。

「最好」的 LLM 6 個月後會不會變？

幾乎肯定會。名冊持續演變。穩定的是層級結構——「前沿旗艦 vs 中層 vs 預算」即使每層內的具體模型輪替都仍然是有用的區分。把任何具體模型推薦當作一個快照，而非一個承諾。

為什麼 Claude 不在 Subanana 菜單？

Subanana 的名冊就四個準則策展：智能、吞吐量、價格、上下文窗口。Claude 在任何一日的存在或缺席是那個滾動評估的結果——而非永久拒絕。隨著價格、表現與存取因素演變，菜單也隨之演變。

為什麼不是每個會議工具都讓我選擇？

大部分工具在實際上只有一個主流模型選擇時建立——產品面圍繞單一模型設計。重新架構成多模型意味不同 API、逐模型提示工程與逐供應商成本追蹤。大部分廠商決定工程成本不值得用戶可見差異化。Subanana 下了相反的注。

有會議標準層真的好過高階嗎？

有——很多。例行狀態更新、輕鬆腦震盪、快速 check-in。在一個 15 分鐘團隊同步丟旗艦層推理下去，是浪費推理深度、又付著你用不到的容量費用。對例行內容，標準層產出在有用度上無法區分的摘要，成本只是零頭。

如果我轉工具，可以遷移摘要歷史嗎？

可以。摘要匯出做 DOCX、PDF、TXT 或 Markdown——標準格式，可攜至任何其他工具。不會乾淨地轉移的是逐摘要模型 metadata（哪個 LLM 在何時寫了哪份摘要）——那是 Subanana 專屬。大部分會議工具用類似標準格式匯出摘要，因此摘要匯出的遷移成本低。

Subanana 有公佈逐模型準確度 benchmark 嗎？

沒有公開逐模型 benchmark。逐模型表現按會議類型、音訊質素、語言混合與內容領域有重大差異——單一數字會誤導。本文一貫的建議是：在你自己的實際會議測試，模型對「你」內容的契合度才是決定價值的那樣。

方法說明

本文是關於怎樣思考模型選擇，而非 benchmark 報告。具體逐模型表現數字不在此公佈——模型表現按版本、按會議類型、按音訊條件而變，更新得比任何 blog 快照追得上更快。settle「哪個 LLM 對我的會議最好」的正路是在你實際內容測試。任何 Subanana 免費版帳號都直接支援那個測試。