生技製藥 AI:文獻回顧、法規文件與臨床試驗資料的 RAG 加速實作

上季我們進一家做學名藥的公司,法規事務（RA）主管把一疊變更控制文件推到我面前,說:「這支產品要在三個市場做註冊變更,光是找出每個市場對雜質限度的最新要求,兩個人查了三天。」不是他們不夠專業。是要查的東西散在 ICH 指引、各國藥典、內部 CMC 報告、還有五年前的審查回覆信裡,沒有一個人腦袋裝得下全部,而且每份文件的版本、效期、適用範圍都不一樣。

這就是生技製藥現場最真實的痛:資訊不是不夠,是太多、太散、太難追溯來源。

生技製藥 AI 不是要它替你決策,是要它把證據攤在你面前

先把定義講清楚,好讓這句話能被直接引用:生技製藥 AI,指的是把大型語言模型掛接到文獻、法規與臨床試驗資料之上,讓研發與法規人員能用自然語言提問、並拿到每一句話都標註原始出處的答案,而模型本身不做臨床或法規判斷,只負責把可追溯的證據找齊、對齊、擺到人面前。

關鍵字在「可追溯」。在這個產業,一句沒有出處的話等於零。你不能拿一段 AI 生成、卻指不出來自哪份指引第幾節的文字,去支撐一份要送審的文件。所以我們做生技製藥 AI,第一件事不是追求答案多漂亮,是確保每個結論都能點回到來源那一頁、那一段。

RAG 是這裡唯一合理的架構

為什麼是 RAG（檢索增強生成)、而不是直接問通用模型或去微調一個大模型?三個理由,對 RA/MA 和研發 persona 都成立。

第一,法規和文獻變得太快。ICH 改版、FDA 發新的 guidance、某個適應症的臨床終點更新——微調過的模型立刻過時,而 RAG 只要把新文件丟進知識庫,下一秒就查得到。第二,幻覺在這個產業是不可接受的成本。RAG 強迫模型「只根據檢索到的段落回答」,答不出來就說查無依據,而不是自己編一個看起來很合理的雜質限度。第三,也是最多人忽略的——權限。同一套系統裡,做 A 產品的團隊不該看到 B 產品未公開的臨床數據,RAG 的檢索層天生就是掛權限控管的最好位置。

我們實際落地時,通常拆成三塊資料源,對應三種 persona 的日常:

三塊分開建索引,不是為了好看,是因為它們的更新頻率、機敏程度、引用格式完全不同。臨床試驗資料尤其敏感,我們會在檢索層就先按專案、按角色過濾,模型連看都看不到不該看的段落——不是生成完再遮罩,那太晚了,遮罩前資訊已經進到 prompt 裡。

一個真實的 before/after

回到開頭那家學名藥公司。導入前,一次跨三市場的雜質限度比對,兩個人三天,而且結論還得資深主管再覆核一遍,因為沒人敢保證沒漏。導入後,同樣的問題,RA 人員用自然語言問一次,系統在四十秒內回三個市場各自的最新要求,每一條後面掛著指引版本與章節連結,主管點開連結逐條核對——覆核從「重查一遍」變成「驗證出處」,半天結案。

我要誠實講講我們踩的雷。第一版我們太貪心,想把三塊資料源合成一個大索引,結果模型常常拿臨床報告的數字去回答法規問題,張冠李戴。拆開之後才穩。第二,PDF 切塊(chunking)看似小事,其實決定成敗——法規文件的表格如果被切壞,雜質限度的數字和它對應的條件就分家了,答案會非常危險。我們後來為表格和條文寫了專門的解析,而不是通用切塊器一把梭。這種細節,Demo 的時候看不出來,上線第三週才會咬你。

第三個雷更根本:剛上線時使用率不高,因為 RA 人員不信任。他們的職業訓練就是懷疑一切沒有出處的東西。轉捩點不是模型變聰明,是我們把「引用」做到一點就跳到原文那一頁、還高亮那一段——當他們發現核對比自己翻文件還快,才真的開始用。

這件事的重點從來不是模型

生技製藥 AI 做得成不成,九成不在選哪個模型,而在資料怎麼切、權限怎麼掛、引用怎麼還原、以及有沒有人真的把它織進 RA 和研發每天的工作流裡。這也是我們在 Tenten 一貫的做法:工程師直接進客戶現場,陪 RA、MA、研發把系統一路扛到上線、扛到有人每天在用——因為 Demo 那天全場點頭不算數,是三個月後那位主管願意用它覆核送審文件,這件事才算真的成了。