醫療知識系統該用 RAG 還是微調?臨床指引、藥品與院內規範的知識庫選型比較

去年底,一家區域教學醫院找上我們,想做一套「問了就能回答臨床指引」的系統。他們的資訊室很有想法,已經先試過把院內三年份的用藥規範、治療流程、衛福部公告丟進一個開源模型做微調,產出一個看起來很聰明的問答機器人。Demo 那天回答得頭頭是道。

問題是,兩週後藥事委員會更新了一條抗生素的建議劑量,那套系統照舊吐出舊答案,而且講得斬釘截鐵、連個出處都沒有。藥師當場臉就綠了。

這不是模型笨,是選型從一開始就選錯了。

醫療 RAG vs 微調:先講結論

一句話講完:在醫療知識系統裡,凡是牽涉到「會變、要查、要能追溯到原文」的知識,預設用 RAG(檢索增強生成);只有在「講話風格、格式、固定推理模式」需要調整時,才動用微調。醫療 RAG vs 微調不是二選一的對決,而是分工——RAG 管知識的新鮮度與可追溯,微調管模型的行為與口吻。

為什麼在臨床場景我們幾乎總是先押 RAG?因為醫療知識有三個特性跟微調天生犯沖:它更新頻繁(指引改版、藥品仿單修訂、院內規範季度調整)、它要求可追溯(醫師不會相信一個講不出出處的答案)、它禁不起幻覺(劑量講錯是會出人命的)。微調把知識「烘」進權重裡,這三件事它一件都做不好。

四個維度,一張表看懂差異

我們幫客戶做選型時,實際攤開來比的就是這四欄。醫療場景真正的痛點都在這裡。

看這張表,結論其實很直白:臨床指引、藥品資訊、院內規範這類「事實型、會改版、要負責」的知識,RAG 幾乎全面勝出。這也是為什麼我們遇到「vs 型」的選型糾結時,通常會先把客戶從「微調一個懂醫療的模型」這個念頭裡拉出來。

那微調到底什麼時候該用

別誤會,微調不是沒用,它只是被放錯位置。真正適合微調的,是模型的「行為」而不是「知識」。

比方說,你希望系統回答時固定用 SOAP 格式輸出、你要它學會醫院慣用的分診話術、你要它把病歷摘要壓成主治醫師習慣的句式——這些是風格與結構問題,微調很擅長。我們也看過用微調處理醫學專有名詞與縮寫消歧(同一個「MS」在不同科別意思天差地遠),效果不錯。但即使這些場景,底層的事實檢索還是交給 RAG,兩者疊在一起用。

一個實務判準:如果這條知識三個月後可能會改,別放進權重。如果醫師會問「這是根據哪一版指引」,你就一定需要 RAG 的引用能力。

落地時真正會踩的雷

選對 RAG 只是起點。我們在醫院現場踩過的雷,幾乎都不在模型,而在資料工程。

第一個是文件切分。臨床指引常有巢狀條件——「腎功能不全者劑量減半」如果跟主劑量被切到不同段落,檢索回來就是斷章取義,比不答還危險。第二個是版本治理。同一份用藥規範新舊版並存在知識庫裡,系統很可能同時檢索到兩版然後自相矛盾;我們的做法是給每份文件掛上生效日與失效日,檢索時強制過濾。第三個是「查不到要敢說不知道」。醫療系統寧可回「此問題未涵蓋於現行知識庫,請洽藥劑部」,也不能硬掰。這條護欄要寫死在提示與後處理裡,不能靠模型自律。

回到開頭那家醫院。我們把微調版本退役,改建 RAG 架構,替每份文件加上版本標記與出處回鏈,並設下「無來源不作答」的規則。上線兩個月後,藥師開始真的在早會前用它查交互作用——因為它會附上仿單頁碼,他點開就能核。

這就是我們一直在做的事:醫療 AI 不是把模型調得多聰明,而是讓每一個答案都查得到、追得到、也扛得住有人拿去做臨床決策。Demo 漂亮不算數,藥師願意在病人面前點開它,才算數。