1 億筆醫病對話的飛輪效應：Abridge 如何打造醫療 AI 的「無形空調」

本文整理自 Latent Space Podcast 2026 年 5 月播出的單集。

{{< youtube vUARtyOvh5U >}}

{{< spotify "episode/7sXRzbVyUHpKUe061mXG8w" >}}

{{< apple-podcast "tw/podcast/latent-space-the-ai-engineer-podcast/id1674008350?i=1000767833040" >}}

---

醫療 AI 的空調哲學

「我們希望產品像空調一樣。」這是 Abridge 產品副總裁 Janie Lee 在 Latent Space Podcast 上用的比喻。空調最成功的時候，就是你完全忘記它存在的時候。你不會每五分鐘抬頭看一眼空調在幹嘛，你只是感覺到房間溫度很舒適。如果空調每隔幾分鐘就發出嗶嗶聲問你「要不要調低兩度？」，你大概會想把它拆了。

這個比喻精準地捕捉了醫療 AI 產品設計中最核心的矛盾：你手上有非常有價值的資訊，但你不能隨便打斷使用者。醫師看診時只有 15 分鐘，面對的是一位正在描述自己病情的真實病人。這不是在辦公室回覆 Slack 訊息的場景。任何中斷都有代價，而且代價可能遠超過你提供的價值。

Abridge 的工程主管 Chai Asawa 把這個設計理念推得更遠。他說 Abridge 從創立的第一天起就是一個「環境智慧」（ambient intelligence）的產品。它不需要醫師主動操作，不需要點按鈕或切換介面。它只是安靜地在背景中監聽對話、分析內容、準備好在適當時機提供幫助。Asawa 認為，這其實是所有 AI 產品最終應該走向的形態，而 Abridge 只是因為醫療場景的特殊性，比其他人更早走到了這一步。

超過 90% 的警報被忽略

空調哲學不是憑空冒出來的。它是從一個血淋淋的教訓中學到的：醫療界已經有太多失敗的「主動通知」案例。

現有的臨床決策支援系統最大的問題就是警報疲勞（alert fatigue）。根據 Lee 引用的數據，醫療環境中超過 90% 的系統警報被直接忽略。醫師對彈窗通知已經產生了條件反射式的關閉動作，不管內容是什麼都先按掉再說。這不是因為醫師不負責任，而是因為絕大多數警報都是低品質的雜訊。「這兩種藥物可能有不良反應」，但其實那個風險在臨床上根本不重要，或者醫師已經考慮過了。

Asawa 從工程師的視角分析這個問題時，指出了兩個根本原因。第一是技術層面的：過去的警報系統缺乏足夠的上下文，它不知道這位病人的完整病史、不知道醫師已經考慮過哪些因素、不知道這次就診的具體目的。沒有上下文的警報就是雜訊。第二是時機層面的：就算內容是對的，在錯誤的時間點出現也等於白搭。醫師正在跟病人討論一個情緒敏感的話題時，螢幕突然跳出一個與當下無關的提醒，只會讓人更煩。

Abridge 的策略是從「反應式警報」轉向「主動式智慧」。具體來說，與其在看診過程中不斷彈出通知，不如在醫師走進診間之前就把準備工作做好。系統可以自動摘要這位病人最近幾次的就診紀錄，根據這次掛號的主訴，預先整理出醫師可能需要討論的議題。醫師拿著這份摘要走進診間，而不是走進去之後才被系統一件一件告知。

真正需要在看診過程中介入的時刻，是像事前授權這樣的場景：如果病人離開了再處理，就得等上好幾週。這種情況下，系統的介入不是干擾，而是在對的時間點提供了關鍵的決策支援。區別在於，介入的品質必須非常高，而且必須是可執行的具體建議，不是模糊的警告。

1 億筆對話就是 1 億條 Agent Trace

Abridge 目前累計處理的醫病對話已經接近一億筆。這個數字本身很驚人，但更值得注意的是 Asawa 對這些資料的詮釋方式。他不把它們叫做「訓練資料」或「語料庫」，而是叫做「agent trace」。

這個概念很有意思。在 AI Agent 的世界裡，trace 指的是一個 agent 執行任務時完整的操作紀錄，包括它接收到什麼輸入、做了什麼判斷、採取了什麼行動、得到了什麼結果。而醫病對話恰恰就是醫療場景中最核心的「trace」。醫師（agent）接收到病人的症狀描述（輸入），結合自己的醫學知識和過往經驗做出判斷（推理），然後給出診斷和治療方案（行動）。

這種資料在 Abridge 出現之前，從來沒有被大規模、系統性地記錄和分析過。醫師的臨床判斷過程，那些在腦海中快速運轉的推理鏈，傳統上只存在於醫師的經驗中，隨著退休或離職就消失了。現在 Abridge 把這些「隱性知識」變成了可以學習的資料。

這就是 Abridge 資料飛輪的核心邏輯。產品被使用得越多，收集到的對話就越多。對話越多，模型在特定專科、特定場景上的表現就越好。表現越好，更多醫療體系願意採用。更多採用又帶來更多對話。而且這個飛輪有一個天然的防禦性：這些資料是高度專有的、受嚴格隱私法規保護的，其他公司很難複製。

隱私問題當然是繞不過去的。Abridge 建立了自動去識別化（de-identification）的模型，能從臨床逐字稿中移除所有受保護的個人健康資訊（PHI）。去識別化是單向的，不可逆轉。清洗過的資料才能用於模型訓練和評估。Asawa 承認，這意味著在多個概率系統疊加的情況下，你得先對去識別化模型本身建立足夠的信心。但一旦建立了這個基礎，後續的資料利用就有了堅實的合規保障。

快思慢想：模型星座的實戰策略

當你每週處理數百萬筆對話，而且要在即時對話中提供決策支援，「用最貴的模型、燒最多的 token」這種策略就完全不現實了。Asawa 用「模型星座」來描述 Abridge 的技術架構：不同的模型負責不同的任務，根據複雜度和緊迫性動態調配。

這跟康納曼的「快思慢想」（Thinking, Fast and Slow）框架異曲同工。快速、便宜的小模型負責第一線的分類和篩選，快速判斷這個對話片段是否包含需要進一步分析的內容。只有在觸發特定條件時，才會把任務交給更大、更智慧的模型進行深度推理。這樣做不只是為了省錢，也是為了降低延遲。在即時對話的場景中，你不能讓系統花 30 秒思考，因為醫師和病人已經往下講了。

但 Asawa 也坦承，這些「巧妙的工程技巧」可能不是五年後的最佳解。AI 模型的能力邊界（Pareto frontier）一直在移動。今天需要用多個模型協作才能完成的任務，明天可能一個模型就能搞定。他的策略是：密切追蹤第三方模型提供商的發展方向，理解它們在哪些面向會變得更強（例如 agentic 能力、程式碼生成），然後把自有資源集中在那些第三方模型不太可能覆蓋的領域。

一個具體的例子是轉錄和語者分離（diarization）。這些是 Abridge 的核心場景，用自有資料後訓練出來的模型可以做得比通用模型更準確、更快、更便宜。但在通用的醫學知識推理上，讓第三方的大型模型持續進步反而對 Abridge 有利，因為消費者查詢中有大量是醫療相關的，模型提供商自然會在訓練中投入更多醫療資料。

三層個性化：從兩個空格到整個醫療體系

AI 生成的臨床筆記如果讀起來不像是這位醫師自己寫的，醫師就不會用。Asawa 把這個問題比喻為更廣義的「AI slop」（AI 垃圾內容）：缺乏上下文的 AI 輸出，就是 slop。但 Abridge 擁有豐富的上下文，所以有條件做到真正的個性化。

Lee 把個性化拆成三個層次。第一層是個人層面。每位醫師對筆記的格式都有非常具體的偏好：有人喜歡項目符號，有人堅持段落格式。有人要求簡潔，有人需要詳盡。甚至到了「我要求句子之間有兩個空格，否則我拒絕使用」的程度。Abridge 的回饋頻道裡充滿了這種高度個人化的要求，而且團隊必須認真對待，因為對醫師來說，病歷是他們工作的直接產物，代表他們的專業判斷和照護品質。

第二層是專科層面。心臟科的筆記和皮膚科的筆記長得完全不一樣，不只是內容不同，連結構、邏輯、需要記錄的重點都不同。一份「好的」心臟科筆記必須包含哪些元素？什麼樣的內容才能確保它符合計費標準？這些評估基準需要逐一建立，每個專科都是一套獨立的體系。Abridge 目前支援超過 50 個專科，每一個的評估集都是「辛苦掙來的」（hard-earned），Lee 這樣說。

第三層是醫療體系層面。大型醫療機構通常花了數年甚至數十年建立自己的臨床實務指引。它們想要的不是一套通用的 AI 建議，而是把自己的指引嵌入到 AI 的決策邏輯中。當一位醫師在看診時收到提示，這個提示應該反映的是這家醫院認為最佳的做法，而不是某個通用的醫學教科書建議。Lee 認為，當醫療體系願意把這些專有資料託付給 Abridge，就代表一種深度的信任關係，同時也是競爭對手很難複製的護城河。

這三層個性化的共同基礎，是 Abridge 從使用者編輯行為中持續學習的能力。每一次醫師修改 AI 產生的筆記，都是一筆訓練資料。把某個詞換掉、把某段移除、調整某個格式，這些編輯動作累積起來就形成了一個持續進化的個性化引擎。

從電子病歷到臨床智慧層

Abridge 跟電子病歷系統（EHR）的關係，是理解這家公司定位的關鍵。醫師每天大部分時間都泡在 EHR 裡，任何新工具如果不能深度整合進 EHR，就等於要求醫師多開一個視窗、多點幾下滑鼠。在一個每次就診只有 15 分鐘、醫師連上廁所的時間都得精打細算的環境裡，多出來的任何操作步驟都是被淘汰的理由。

所以 Abridge 投入了大量精力跟主要的 EHR 供應商建立合作關係，透過 API 實現資料的雙向流通。Lee 說得很直白：能不能做到深度互通，是醫療體系決定要不要用你的先決條件。這不是加分項，是入場券。

但 Abridge 的野心不止於此。Asawa 把 EHR 比喻為一個檔案系統，而 Abridge 則是在這個檔案系統之上建立的智慧層。EHR 擅長的是儲存和管理結構化的臨床資料，但它不擅長也不打算擁有的東西很多：保險公司的理賠政策分析、跨機構的臨床試驗配對、即時的臨床決策支援。Abridge 把自己定位在這個空間裡，作為連接醫療服務提供者、保險公司和藥廠的「臨床智慧層」。

這個定位的潛力在於，同一筆醫病對話可以同時服務多個利害關係人。醫師需要知道病歷是否完整。病人需要知道下一步該做什麼。保險公司需要確認治療是否符合給付標準。藥廠想知道某個藥物為什麼沒有被開立，或者哪些病人適合參加新的臨床試驗。目前這些需求各自依賴不同的系統和流程來處理。Abridge 的願景是用同一個平台、同一個對話資料來源，把所有這些需求整合在一起。

聽起來很宏大，但別忘了它的起點：一位心臟科醫師不想在睡衣裡寫病歷。有時候最好的技術願景，就是從最具體的痛點長出來的。