想像一個忙碌的急診現場：候診區同時出現胸悶、發燒、腹痛與呼吸困難的病患，但能立即投入處置的人力與空間有限。

這時最先要回答的問題，不是「病患最後確診什麼疾病」，而是：

誰可能有立即危險？誰需要更快接受處置？誰可以在安全範圍內稍候？

這個快速判斷的過程稱為急診檢傷。檢傷人員需要在很短的時間內，同時理解病患用日常語句表達的主訴，以及呼吸速率、血氧、心跳、血壓與體溫等生命徵象，再依照檢傷規則判斷急迫程度。

這正是本次 30 天系列想處理的問題：我們要建立一套能先查找檢傷規則，再根據規則整理候選結果的急診檢傷研究原型。

這套系統的核心方法是檢索增強生成（Retrieval-Augmented Generation, RAG），也就是先從外部知識中找出相關內容，再讓語言模型根據找到的內容產生回答。

這裡的個人實作專案（Side Project）不是臨床產品，也不是用來取代檢傷人員。它是一個可以逐步建造、執行、測試與檢查的技術專案，讓我們能具體研究文字、數值、規則檢索與語言模型如何協同工作。

下圖將這個目標畫成一條由左向右的建造路徑：左側是主訴與生命徵象，中間是公開資料、規則知識庫、檢索與模型模組，右側則是具有程式、測試、實驗紀錄與安全圖表的完整專案。

上圖先把 30 天的建造方向放在同一條路徑上。今天先不安裝模型，也不急著寫大量程式碼。我們會先說清楚問題、系統範圍、30 天順序與完成標準。只要地圖先畫對，後面的每一步才知道自己為什麼存在。

本篇目標

讀完這篇文章後，你應該能夠：

1. 用自己的話說明急診檢傷與疾病診斷的差異。
2. 說明大型語言模型與檢索增強生成在本專案中的角色。
3. 看懂系統從資料輸入到安全評估的完整路徑。
4. 說出 30 天五個階段的先後關係與主要產物。
5. 分辨這個專案能回答的研究問題，以及不能做出的臨床承諾。

本篇會用到的名詞

以下表格先提供快速索引。正文仍會在名詞第一次出現時，用完整句子重新解釋。

從急診現場開始：這個 Side Project 想做什麼？

急診檢傷不是疾病診斷

急診檢傷的目標，是依照病患當下風險安排處置優先順序；疾病診斷的目標，則是透過更完整的問診、檢查與檢驗確認病因。兩者發生的時間、可用資訊與工作目的都不同。

因此，本專案的輸入只會使用檢傷當下合理可取得的資訊，例如：

• 主訴：病患最主要的不舒服與就醫原因。
• 生命徵象：呼吸速率、血氧、心跳、血壓與體溫等可測量資訊。
• 意識狀態：病患是否清醒，以及對外界刺激的反應情形。
• 疼痛資訊：疼痛位置、程度與相關描述。
• 基本背景：年齡與其他在檢傷當下已知的必要資訊。

急診後續才產生的診斷、檢驗結果、住院狀態或處置結果，不應偷偷放進模型輸入。把預測當下原本不知道的資訊放進輸入，稱為資料洩漏。資料洩漏會讓測試結果看起來很好，卻無法代表系統在真實時間點的能力。

為什麼這個問題不容易？

病患可能說：「我今天一直喘，走幾步就很累。」這是自然語言，也就是人平常說話或書寫時使用的語句。系統必須先理解「喘」與「活動後加重」可能代表的症狀方向。

但文字不是唯一線索。若同一位病患的血氧明顯偏低、呼吸速率過快或意識改變，急迫程度可能需要立即提高。因此，系統還必須正確處理數值門檻，不能只靠文字相似度判斷。

最後，不同主訴與生命徵象可能對應不同規則。系統不只要給出答案，還要能回答：

1. 找到了哪一條規則？
2. 規則來自哪份文件與哪個版本？
3. 哪些病患資訊觸發了這條規則？
4. 若判斷錯誤，錯在找錯規則，還是解讀規則錯誤？

這些問題共同形成本專案的核心：同時處理文字、數值與規則證據，並保留可以檢查的判斷過程。

為什麼要讓 LLM 搭配 RAG？

大型語言模型：整理文字與產生固定格式結果

大型語言模型（Large Language Model, LLM）是從大量文字中學習語言規律的模型。它可以整理主訴、辨識症狀描述，也能按照指令產生結構化回答。

結構化回答是依照預先指定的欄位與格式輸出，例如固定回傳「候選級數、引用規則、理由與警示」，而不是只寫一段自由文字。固定格式能讓後續程式自動檢查欄位，也比較容易追蹤錯誤。

不過，LLM 說得流暢，不代表它引用的檢傷規則正確。若只依賴模型訓練時記住的內容，它可能使用錯誤、過時或根本不存在的依據。

檢索增強生成：先找證據，再產生回答

檢索增強生成（Retrieval-Augmented Generation, RAG）是一種先搜尋外部資料，再讓語言模型根據找到內容作答的方法。

在本專案中，RAG 可以先簡化成三個步驟：

1. 保存規則：把檢傷規則整理進知識庫（Knowledge Base）。知識庫是集中保存外部資料，並讓系統可以搜尋證據的資料集合。
2. 尋找規則：收到病患資訊後，先找出可能相關的主訴、生命徵象與高風險規則。
3. 根據規則回答：把病患資訊與找到的規則一起交給 LLM，要求模型只能根據提供內容產生候選結果。

RAG 不保證答案一定正確。它的價值是讓答案多一層可以檢查的外部依據，也讓我們能把「是否找對規則」與「是否根據規則判對」分開評估。

把整個 Side Project 拆成五個步驟

下圖把系統拆成五個連續層次。閱讀時請由左向右看：前一層的輸出，會成為下一層的輸入。

上圖的五個層次不是彼此獨立的功能清單，而是一條連續的資料流。下面依序說明每一層要完成的工作。

第 1 層：準備合法且可說明的資料

我們會選擇具有清楚取得方式、固定版本與使用規範的急診資料。每個欄位都要說明定義、單位、缺失情形，以及它在檢傷當下是否已經可知。

第 2 層：建立可追溯的規則知識庫

規則不能只被切成互不相關的文字片段。每個知識單元需要保存來源、章節、主訴類別、急迫級數、生命徵象門檻與版本資訊，才能在輸出錯誤時回頭檢查。

第 3 層：比較不同檢索與門控策略

本系列會逐步比較四類設計：

1. 基本式檢索增強生成（Basic RAG）：在整個知識庫中搜尋相似文字。
2. 階層式檢索增強生成（Hierarchical RAG）：先按照主訴與級數組織規則，再進入較小範圍搜尋。
3. 階層門控式檢索增強生成（Hierarchical Gated RAG）：先依生命徵象估計風險範圍，再限制後續檢索。
4. 安全候選聯集（Safety Candidate Union）：合併主訴、生命徵象與高風險規則的候選，降低單一路徑漏掉危急線索的機會。

第 4 層：產生候選結果與證據紀錄

模型需要輸出固定欄位，包括候選級數、引用規則、判斷理由與警示。系統也會保留推論軌跡，也就是從接收資料、找到規則到產生結果的過程紀錄。

第 5 層：同時評估正確性與安全性

急診檢傷是一種序位分類問題。序位分類是類別具有先後順序的分類問題；例如第一級與第二級相鄰，但第一級與第五級相差很遠，不能把五個級數當成彼此毫無關係的名稱。

因此，我們不只計算整體正確率，也會檢查：

• 危急病患是否被找回。
• 病患是否被分到過低的急迫級數。
• 錯誤跨越了幾個級數。
• 每個級數的表現是否穩定。
• 找到的規則是否真的支持輸出結果。

怎樣才算是一個可重現的 Side Project？

可重現研究（Reproducible Research）是指第三方能依照清楚的資料說明、程式與設定，重新建立流程，並檢查結果如何產生。

可重現不等於把所有資料上傳到網路。醫療資料可能受到資料使用協議、隱私規範或授權限制。遇到不能公開的內容時，程式碼儲存庫（Code Repository, repo）應提供合法取得方式、欄位結構、處理程式與驗證方法，而不是把受限制資料一起公開。

本專案的每個結果，至少要能回到四個層次：

1. 資料層：使用哪個資料集、哪個版本、哪些欄位，以及排除了哪些紀錄。
2. 方法層：知識庫如何建立、查詢如何表示、檢索與生成如何執行。
3. 設定層：模型版本、提示詞、候選數量、隨機種子與其他參數。提示詞（prompt）是交給語言模型的指令與輸入模板；隨機種子則是控制隨機程序起點的數值。
4. 結果層：輸出檔案、評估指標、圖表與錯誤分析如何產生。

後續每個實作步驟都會按照相同順序說明：

1. 這一步要解決什麼問題。
2. 開始前需要哪些工具與檔案。
3. 程式會讀取哪些輸入。
4. 實際要執行什麼操作。
5. 成功時會產生什麼輸出。
6. 如何自行驗證輸出是否合理。

這樣安排的目的，是讓第一次接觸醫療人工智慧（Artificial Intelligence, AI）或資料工程的讀者，也能知道每一步存在的理由，不必靠猜測補上中間過程。

接下來 30 天會怎麼走？

下圖是完整路線圖。五個階段依照專案真正需要的順序排列，前一階段的產物會成為下一階段的輸入。

上圖把 30 天分成五個前後相依的階段。每個階段都會留下可供下一階段使用的產物，而不是只完成一篇獨立的概念介紹。

階段 1：Day 01–05，建立共同語言

• 目的：讓醫療、工程與研究背景的讀者先對問題有一致理解。
• 輸入：急診檢傷情境與 RAG 的基本概念。
• 工作：解釋五級檢傷、不同制度、LLM 與 RAG。
• 輸出：共同詞彙、問題邊界與醫療安全定位。
• 驗證：讀者能分辨檢傷與診斷，也能說明 RAG 的三個基本步驟。

階段 2：Day 06–10，設計方法、問題與資料

• 目的：把想法整理成可以被實驗回答的具體問題。
• 輸入：三種 RAG 架構、評估需求與可用資料來源。
• 工作：拆解架構、辨識混合變因、建立研究問題與選擇資料。
• 輸出：研究問題、預先假設、實驗矩陣與資料決策。
• 驗證：每個問題都能對應到一組實驗和明確指標。

階段 3：Day 11–20，準備資料、知識庫與檢索

• 目的：建立可執行、可測試的資料與規則基礎。
• 輸入：選定資料、檢傷規則與資料欄位需求。
• 工作：整理資料、排除資料洩漏、建立知識庫、處理生命徵象並測試檢索。
• 輸出：乾淨資料、資料說明、可追溯知識庫與檢索測試台。
• 驗證：每個欄位都有取得時點，每個知識單元都有來源，每個檢索結果都能被檢查。

階段 4：Day 21–27，建立架構並執行公平實驗

• 目的：比較不同方法，並找出真正帶來差異的元件。
• 輸入：固定資料、固定知識庫、固定查詢與評估方式。
• 工作：實作基本式、階層式、生命徵象門控與安全候選聯集，加入簡單基準，再執行消融實驗（Ablation Study）。消融實驗會固定其他條件，一次只移除或更換一個元件。
• 輸出：各方法的預測、設定、執行紀錄與配對結果。
• 驗證：比較使用相同測試樣本，而且每次消融只改變一個主要因素。

階段 5：Day 28–30，評估安全、分析錯誤並發布成果

• 目的：把輸出整理成可解釋、可檢查、可重跑的結論。
• 輸入：所有方法在固定測試資料上的預測與檢索紀錄。
• 工作：計算序位分類與安全指標、估計不確定範圍、分析錯誤案例並整理發布內容。
• 輸出：彙總結果、繁體中文圖表、錯誤分析、完整文章與可重跑專案。
• 驗證：結論同時說明樣本數、整體表現、各級表現、危急案例與研究限制。

30 天後，我們預計完成什麼？

這個系列不只會留下 30 篇文章，也會逐步建立以下產物：

• 資料來源、版本、欄位與限制說明。
• 資料清理與驗證程式。
• 可追溯來源的規則知識庫。
• 基本式、階層式與門控式 RAG 實作。
• 規則式與傳統機器學習基準。
• 檢索、分類、安全與統計評估程式。
• 消融實驗與錯誤分析紀錄。
• 繁體中文流程圖、架構圖、混淆矩陣與結果圖表。
• 從零開始操作的 README 與可重跑設定。

每個產物都必須回答三個問題：輸入是什麼、如何產生、如何驗證。若一個成果只能展示、不能說明產生過程，就還不算完成。

先說清楚：這個系列不會承諾什麼

1. 不會宣稱模型可以取代檢傷人員

模型輸出只能作為候選與證據提示。真正的臨床檢傷仍需要合格醫療人員依現場狀況判斷。

2. 不會把測試正確率直接等同臨床安全

整體正確率高，不代表危急病患一定不會被低估。本系列會另外檢查危急級數召回、檢傷不足方向與跨多級錯誤。

3. 不會公開受限制的病患內容

Repo 只保存允許公開的程式、設定、欄位結構、合成測試資料與彙總結果。受資料使用規範限制的內容不會上傳。

4. 不會把計畫提前寫成成果

Day 01 完成的是問題定義與專案路線，不是模型實驗。資料與模型結果必須等實際執行並通過驗證後才能報告。

5. 不會假設所有五級檢傷制度都能直接互換

不同制度雖然都可能使用五個級數，主訴分類、判定規則與標籤意義仍可能不同。更換資料時，必須同步說明它對應的制度與規則。

不同背景的讀者可以怎麼跟上？

如果你第一次接觸這個主題

建議從 Day 01 依序閱讀。先掌握開場案例、詞彙表、流程圖與本日小結，再決定是否深入程式細節。

如果你是軟體工程師

不要跳過檢傷制度、資料治理與資料洩漏。這些限制會直接決定程式能使用哪些欄位，以及測試結果是否可信。

如果你關心研究設計

可以特別留意研究問題、控制變因、基準方法、消融實驗、安全指標與不確定性估計之間的對應。

如果你有醫療背景

可以協助檢查主訴、生命徵象、急迫程度與規則解讀是否符合臨床語意。系統會保留規則來源與推論軌跡，讓專業人員能逐步檢查。

今天走到了哪裡？

Day 01 完成了三項基礎工作：

1. 定義問題：同時處理文字主訴、數值生命徵象與檢傷規則。
2. 畫出系統：資料、知識庫、檢索與門控、模型輸出、安全評估。
3. 排定順序：共同語言、研究與資料設計、資料與檢索、架構與實驗、評估與發布。

你可以用下面三個問題檢查自己是否掌握本篇內容：

1. 你能否說明急診檢傷與疾病診斷的差異？
2. 你能否不用縮寫，解釋 RAG 的「保存規則、尋找規則、根據規則回答」三個步驟？
3. 你能否說明為什麼這個專案不能只報告一個整體正確率？

如果三題都能回答，就已經具備進入 Day 02 所需的前置知識。

本日小結

這 30 天，我們會從急診檢傷問題出發，逐步完成資料、規則知識庫、檢索、語言模型、實驗與安全評估。

最重要的原則是：

縮寫不早於解釋，步驟都有輸入、輸出與驗證，計畫不提前寫成成果，每個結論都能回到資料、設定與證據。

完整專案與實驗規劃可參考根目錄的 README。

下一篇預告

Day 02 會暫時放下模型，回到真正的問題現場：急診為什麼需要檢傷分類？

我們會從有限醫療資源與病患等待順序開始，逐步解釋五級檢傷、檢傷不足與檢傷過度，並說明為什麼急診檢傷不能被當成一般的五類分類問題。