醫療 AI Agent 記憶機制（上）：在地化優先與合規挑戰

本文為系列文章之「上集」。續集請見：醫療 AI Agent 記憶機制（下）：強化思考鏈與工具調用策略

Key Takeaways

• 四種記憶類型各有盲點：Buffer 燒 Token、Summary 可能產生幻覺、Vector 仰賴 Embedding 品質、Graph 建置成本高——醫療場景需要混用而非單一選擇
• 台灣食物資料庫不是「加一個分類」的問題：麻油雞的熱量因薑的比例、米酒添加量而異，這種變異性不在國際資料集裡
• 資料不出境是法律硬限制，不是選項——這直接決定了哪些雲端 LLM 的記憶服務在台灣醫療場景完全不可用
• PICO-Graph RAG 比一般 RAG 更適合醫療的核心原因：醫學知識的關聯是圖狀的，不是線性的
• SLM as Judge 的存在理由：大型模型生成能力強，但在醫療法規合規判斷上不如專門調校過的小型模型可控

為什麼「記憶」是醫療 AI Agent 的核心問題

大部分人第一次使用 AI 對話工具，都不會意識到記憶的問題——因為在一般場景下，就算 AI 「忘了」上一輪說了什麼，頂多讓使用者重新說一次，成本很低。

醫療場景完全不同。一位糖尿病患者連續三個月的飲食紀錄，其中隱藏著血糖控制趨勢、飲食習慣的季節性變化、節日前後的飲食偏移、某次感冒後的食慾下降。這些資訊如果只活在「最近幾輪對話」裡，AI 給出的建議就是基於片段的。更嚴重的是：如果 AI 在壓縮記憶的過程中產生了幻覺（把「患者上週血糖偏高」誤記為「患者本月血糖控制良好」），後續的建議可能往錯誤的方向走。

在醫療場景，記憶機制的選擇不是效率問題，是安全問題。

四種記憶類型，用糖尿病患者的三個月紀錄來說明差異

讓我們用一個具體情境來看四種記憶類型的行為差異。

情境：65 歲男性糖尿病患者，連續三個月每週回報飲食日誌給 DietMate。第一個月血糖控制尚可（HbA1c 7.2%），第二個月農曆年期間大量進食年菜，血糖一度飆高（HbA1c 7.9%），第三個月逐步恢復控制（HbA1c 7.4%）。第三個月底，患者問：「我最近飲食比較注意了，可以放鬆一點嗎？」

Buffer Memory（短期記憶）

運作方式：把所有原始對話紀錄完整保留在記憶體，不做任何壓縮。

這個問題的行為：如果 Buffer 設定夠大，能看到三個月完整紀錄，理論上可以給出考量完整歷史的回應。但三個月的週回報，Token 量可能超過 10,000 以上，推論成本極高，且 LLM 的注意力在過長的上下文裡會開始衰減——中間那段農曆年的血糖飆高，可能因為位置太靠前而被「忽視」。

在醫療場景的問題：Token 成本高、長上下文注意力衰減、原始病患資料全部留在推論過程中（隱私風險）。適合需要完整細節的短期諮詢，不適合長期個案追蹤。

Summary Memory（摘要記憶）

運作方式：每隔一段時間，用 LLM 把歷史對話壓縮成摘要，後續只看摘要而非原始紀錄。

這個問題的行為：摘要可能寫成「患者三個月整體血糖控制趨勢改善，HbA1c 從 7.2 降至 7.4%」——但這個摘要遺漏了中間農曆年的血糖飆高事件（7.9%）。當患者問「可以放鬆一點嗎？」，基於這個摘要的 AI 可能回應「整體趨勢不錯，適度放鬆是可以的」，實際上忽略了患者在高熱量節慶食物面前的具體弱點。

在醫療場景的問題：這正是最危險的情境——AI 不是不知道，而是「知道了但摘要時丟掉了」。如果摘要由境外雲端 LLM 生成，更有資料外流問題。

Vector Memory（向量記憶）

運作方式：把知識切分成片段，轉成向量儲存，查詢時用語義相似度搜尋。

這個問題的行為：「患者問可以放鬆飲食嗎？」這個查詢，會在向量資料庫裡找到語義相關的片段——包括「農曆年期間血糖 7.9%」「高碳水攝取與血糖波動」「患者對節慶食物的偏好」。這些片段被組合後，AI 有機會給出更精準的個人化回應。

在醫療場景的優勢：不依賴完整上下文，能在大量歷史資料中找到語義相關的片段，適合知識型查詢。

限制：片段化儲存可能切斷脈絡（例如「血糖 7.9%」和「農曆年期間」這兩個片段可能在查詢時沒有同時被召回）。搜尋精準度高度依賴 Embedding 模型的品質——通用 Embedding 模型對台灣在地醫療術語的語義理解往往不足。

Graph Memory（圖譜記憶）

運作方式：把資料以實體與關係的方式組成知識圖譜。例如：患者 → 有（HbA1c 記錄）→ 第二個月 → 值（7.9%）→ 發生於（農曆年期間）→ 原因（年菜攝取量過高）。

這個問題的行為：查詢「患者是否適合放鬆飲食」時，圖譜能清楚呈現：整體趨勢改善，但存在一個明確的「節慶食物觸發因子」。AI 給出的回應會是：「您的整體血糖控制趨勢確實在改善，但我注意到農曆年期間有一次明顯波動。在有大量傳統食物的節慶前後，仍建議保持目前的飲食控制，平時可以適度彈性。」

在醫療場景的優勢：能保留跨時間點的因果關係，不只是「有什麼資料」，而是「這些資料之間是什麼關係」。對複雜的慢性病管理特別有價值。

限制：知識圖譜的建置需要定義實體類型和關係類型，初期投入成本高；圖譜的維護需要持續的資料工程工作。

在醫療場景的選擇策略

沒有一種記憶類型全面勝出。實際部署時，需要依問題類型混用：

台灣醫療 AI 在地化的三道真實障礙

第一道：資料不出境，切斷了大多數雲端記憶服務

這不是選擇題。台灣個資法與衛福部醫療資料相關規範，要求病患個人健康資訊不得儲存於境外伺服器。這表示：任何需要把病患資料傳送到境外雲端 API 進行 Summary Memory 壓縮、或是使用境外向量資料庫儲存病患資料向量的方案，都不符合法規。

實際影響：開發初期許多看起來很方便的記憶解決方案，直接被排除在選項外。整個系統的記憶機制必須建立在本地可運行的基礎上。

第二道：在地飲食知識的缺口，比想像的深

一個具體的例子說明問題的規模：「麻油雞」在國際食物資料庫裡幾乎找不到，即使找到了，熱量與脂肪含量的數據範圍也非常寬——因為薑的比例、米酒的添加量、是否加入冬粉或木耳，都會影響整道料理的營養成分。

這種變異性無法用「找一個通用值」解決。如果 AI 把一碗麻油雞的熱量估算成 250 kcal（乾式低油版）或 550 kcal（重油全材料版），給腎病患者的磷鉀估算誤差可以非常大。

這就是為什麼 DietMate 必須自建台灣本地食物資料庫，並對常見的烹調變型分別建立記錄，而不能沿用國際通用資料集。

第三道：醫療術語的語義嵌入，需要在地化

通用的 Embedding 模型，對「腎絲球過濾率」「血清肌酸酐」「腹膜透析」這些台灣臨床常用術語的語義向量，往往與它們在實際醫療脈絡中的關係不符。換言之，用通用 Embedding 建立的向量記憶，在查詢「CKD Stage 3 患者的蛋白質建議」時，可能召回的是不相關或過時的資訊。

解法是用醫療領域的語料對 Embedding 模型進行微調——這需要高品質的台灣醫療文本作為訓練資料，又繞回到資料不出境的問題。

PICO-Graph RAG：為什麼它比一般 RAG 更適合醫療

解釋這個問題，先得說清楚「一般 RAG 在醫療場景有什麼問題」。

一般 RAG 的運作方式：把問題轉成向量，在文件庫裡找最相似的段落，把段落組合後讓 LLM 生成回應。

在醫療場景的問題：

醫學知識的結構是網狀的，不是線性的。「糖尿病患者的蛋白質攝取建議」不是一個獨立的知識點，它與腎功能分期、年齡、肌肉量、蛋白尿嚴重程度、現行用藥都有關係。一般 RAG 找到的是「語義最相似的文字段落」，但不知道這個段落與患者的具體條件之間的關係是「適用」還是「有條件適用」還是「這個患者不適用」。

PICO-Graph RAG 的不同之處：

PICO 框架（Patient 患者、Intervention 介入措施、Comparison 比較對象、Outcome 結果）是臨床研究方法論的標準結構。把知識圖譜用 PICO 框架組織，意味著每一個知識節點都帶有「這是針對什麼類型的患者、比較了什麼情況、得出什麼結果」的結構化標籤。

當一個患者問題進來，系統先把問題用 PICO 結構解析（這個患者的 P 是什麼、正在問的 I 是什麼），再在圖譜裡找到結構上匹配的知識節點，而不只是語義相似的文字。

舉例說明差異：

一般 RAG 的查詢結果：搜尋「糖尿病蛋白質攝取」，召回五段文字，包含一篇 2018 年的一般建議（0.8 g/kg/天）、一篇高蛋白飲食研究、一篇腎病患者限制蛋白質的研究。LLM 可能把這三篇混合，給出一個模糊的「0.6–0.8 g/kg/天，視情況而定」。

PICO-Graph RAG 的查詢結果：患者條件被解析為 P=CKD Stage 3 合併糖尿病 65 歲以上男性、I=蛋白質攝取量調整、C=一般建議、O=腎功能保護 vs 肌肉量維持。圖譜找到的節點是專門針對這個 P 類型的文獻，並且能識別出「高蛋白飲食研究」對這個 P 不適用（腎病患者），所以排除它。最終給出的是有明確 PICO 對應的建議，附帶文獻來源。

對非 ML 工程師來說，這個差別的直覺理解是：一般 RAG 是「找語義上看起來像的答案」，PICO-Graph RAG 是「找在結構上匹配這個病人情況的答案」。在醫療場景，後者的安全性要高得多。

SLM as Judge：為什麼是小型語言模型，不是大型模型

直覺上，應該用最強的模型做最後的審查。這個直覺在醫療合規場景是錯的。

大型語言模型（如 GPT-4o、Claude 3.7）的生成能力強，但在醫療法規合規判斷上有幾個問題：

1. 行為不完全可控：大型模型的回應受到訓練資料的廣泛影響，在特定的合規判斷上，行為不如專門調校過的模型穩定。
2. 無法本地部署：大型模型必須呼叫境外 API，又回到資料不出境的問題。
3. 難以客製化：針對台灣特定的醫療法規（《醫師法》《營養師法》個資法等）進行專門訓練，小型模型比大型模型容易且成本低。

SLM as Judge 的角色很明確：它不負責生成，只負責審查。它的評估清單是針對台灣醫療合規要求明確定義的：

• 回應內容是否超出衛教範疇（有沒有用「診斷」「應服用 X 藥物」等確診或開藥語言）
• 是否包含潛在誤導性數據
• 是否引用了可供查核的來源
• 是否包含適當的「請與醫師/營養師確認」聲明
• 是否符合現行台灣醫療法規的要求

這些判斷標準是確定的，不需要「強大的語言理解能力」，需要的是「穩定且可控的規則執行」。小型語言模型在本地部署、針對具體規則微調後，比大型模型更適合做這件事。

這個機制是 AI 建議在進入人類審核佇列前的最後一道自動化把關。它讓進入營養師視野的草稿，已經通過了基本的合規篩選，讓營養師可以把注意力放在真正需要臨床判斷的地方。

從記憶機制說回架構選擇

這篇文章討論的記憶機制，看起來像純技術決策，實際上每一個選擇都指向同一個問題：這個系統能不能在出事的時候被審計？

Buffer Memory 留有原始紀錄，可以事後還原。Graph Memory 保留因果關係，可以解釋為什麼這個節點被選中。PICO-Graph RAG 有結構化的文獻來源，可以指出建議依據的是哪篇研究。SLM as Judge 有完整的審查日誌，可以說明每條建議通過或被退回的原因。

這不只是工程設計，是醫療 AI 能被臨床機構信任的基礎條件。

下集將進入推理機制：CoT 思考鏈的四種模式、Tool Calling 的資安設計、以及四層 Agent 架構中一個問題如何流轉。請見：醫療 AI Agent 記憶機制（下）：強化思考鏈與工具調用策略