## 一、 摘要
### CARE: Clinical Assistance & Resource Engine──具高齡友善與高可靠性之適地性健康醫療資訊 AI 助手D
隨著行動醫療（mHealth）與生成式人工智慧（Generative AI）技術的快速發展，民眾透過即時通訊平台取得健康與醫療資訊已成為常態。然而，現有數位醫療服務多以文字介面為主，對高齡者與本土語言使用者而言，仍存在操作門檻高、資訊理解困難及數位排除等問題；同時，生成式 AI 在醫療應用中亦面臨資訊正確性不足與「幻覺（hallucination）」風險，對使用者決策可能造成潛在影響。
本研究提出一套名為 CARE（Clinical Assistance & Resource Engine）之適地性健康醫療資訊 AI 助手，以高齡友善設計、資料準確性保障與 AI 科技整合為核心目標，建構一個結合即時通訊平台（LINE）、語音互動與檢索增強生成（Retrieval-Augmented Generation, RAG）技術之智慧醫療輔助系統。系統在介面設計上，透過卡片化互動訊息（Flex Message）、高對比與大尺寸按鈕之 Rich Menu，以及 LIFF 輕量化前端，降低高齡使用者之操作負擔；在互動模式上，進一步整合台語語音辨識（ASR）與語音合成（TTS）技術，支援以本土語言進行自然語音諮詢，以提升可近用性與使用意願。
在資料可靠性方面，CARE 系統採用 RAG 架構，結合政府機構與官方醫療單位之公開資料，建立具可追溯來源之醫療知識庫，並於生成回應前進行事實查核，以降低生成式 AI 產生錯誤醫療資訊之風險。同時，系統設計明確區分可驗證與不可驗證內容，於回應中提供風險標示與透明揭露，確保使用者不將 AI 回覆誤認為專業醫療診斷。
此外，本研究亦整合地理定位服務（Location-Based Services, LBS）與政府開放資料，提供符合使用者所在地之醫療院所搜尋與掛號指引，實現線上諮詢與線下實體醫療資源之銜接。透過模組化系統架構與多模型協作設計，CARE 不僅提升高齡族群取得正確醫療資訊之便利性，亦為生成式 AI 於醫療輔助情境中的安全應用與信任機制提供一具體實作範例。
## 二、 研究動機與研究問題
在當前數位醫療（mHealth）普及的環境下，民眾已習慣透過行動通訊軟體獲取健康資訊。特別是在台灣，LINE已成為民眾日常依賴度極高的通訊平台[1]，許多醫療機構與新創公司（如翔評互動[2]、叡揚資訊[3]等）紛紛開發基於 LINE 的聊天機器人，提供掛號預約、進度查詢及健康教育等便民服務。
然而，根據文獻回顧，現有的健康諮詢工具多以文字互動為主要通訊模式[4][5]。雖然 AI 聊天機器人展現了提升醫病關係與營運效率的潛力，但針對特定族群，尤其是高齡者（Mature users）及習慣使用本土語言（如台語）的使用者，目前的系統仍缺乏足夠的優化設計[6]。研究顯示，50 歲以上及教育程度較低的使用者，其數位語音助理的使用經驗普遍較少，顯示出明顯的數位落差 [4][5] 。基於以上調查，本研究還觀察到現有數位醫療環境中，仍存在以下尚未解決的關鍵問題：
* #### 醫療資訊混雜與生成式 AI 的「幻覺」風險：
社群平台上影音與文字形式的健康謠言頻傳，使用者難以辨識內容真偽。儘管生成式 AI（如 ChatGPT）能處理複雜查詢，但現有系統仍存在回應不自然、無法記住對話脈絡或產生錯誤資訊（Hallucination）的品質疑慮，這在醫學應用上可能導致錯誤的診斷或治療建議，且使用者容易對 AI 抱有過度自信 [8]。此外，許多醫療聊天機器人在面對敏感或危機狀況時，常表現出理解力不足，且無法保證理解病人的情緒與價值觀 [9]。
* #### 高齡族群的語言障礙與數位排除：
台灣高齡族群偏好以台語進行口語溝通，但現有系統多側重文字，缺乏精準的台語語音辨識（ASR）與合成（TTS）技術。這導致許多不擅長操作智慧手機或閱讀長篇文字的長輩，在獲取正確醫療資訊時面臨極高門檻。
* #### 醫療資源破碎化與整合度不足：
使用者在尋求醫療協助時，常需在多個 App 之間切換以尋找診所或比對掛號資訊，缺乏「一站式」的醫療整合服務。現有系統往往無法有效串聯線上諮詢與線下實體醫療（OMO），導致患者流程產生資訊斷點。
基於上述動機，本研究擬轉化為以下具體的技術研發與學術議題：
* #### 高可靠性的生成式 AI 闢謠機制：
如何透過檢索增強生成（RAG）技術結合專業醫療事實查核庫，以降低大型語言模型（LLM）的幻覺現象？並探討如何針對文字與影音等多模態內容，建立精準的醫療資訊真偽判斷框架？
* #### 多語言與多模態的無障礙互動：
如何整合 TAIDE Gemma 3 等在地化語言模型，實現精準的台語語音諮詢服務？並研究將影音內容自動轉化為可分析逐字稿的演算法，以優化高齡者的互動體驗？
* #### 適地性醫療服務 (LBS) 的智慧推薦系統：
如何在保護用戶隱私 的前提下，運用 GPS 定位與政府開放資料 API（如健保特約院所資料庫），設計出能自動篩選並推薦最符合使用者需求（如診所距離、醫師專長、即時診量）的智慧推薦機制？同時，系統設計需符合國內對 AI 應用之核心原則，落實透明性與可解釋性，確保醫療輔助工具的適當揭露。
* #### 家庭共同照護的健康鏈結機制：
如何設計安全的「家庭帳號連結」功能，使照護者能在尊重被照護者隱私的前提下，掌握長輩的健康查詢紀錄與約診狀態，進而達成預防醫療與遠距照護的協同效果。
## 三、 文獻回顧與探討
#### 遠距醫療與隱私保護
學者 Lei 與 Chuang［7］提出一種基於生物識別之三因子驗證與金鑰協議（authentication and key agreement, AKA），以確保使用者在多伺服器環境中的匿名性與不可追蹤性（untraceability）。該方法結合橢圓曲線密碼學（elliptic curve cryptography, ECC）中之橢圓曲線計算式 Diffie–Hellman（Elliptic Curve Computational Diffie–Hellman, ECCDH）問題、雜湊函數假設，以及模糊提取器（Fuzzy Extractor）機制，以處理生物特徵資料中的雜訊並生成高強度金鑰，從而有效抵禦冒充攻擊與重放攻擊等常見威脅。
儘管上述研究主要針對多伺服器架構進行設計，其所提出之三因子驗證概念（使用者所知、所持有與所固有）仍具高度參考價值。本系統於「家庭帳號連結」功能之設計中，即可借鑑該三因子識別機制，以提升使用者隱私保護與整體資訊安全性。
#### 生成式 AI 於醫療應用之潛力、風險與信任機制
大型語言模型（Large Language Models, LLMs）作為生成式人工智慧之核心技術，近年來已逐步展現其在醫療領域中的應用潛力。蔡甫昌與周昱辰[8]指出，LLMs 可作為臨床輔助工具，協助將醫病互動內容轉換為結構化且標準化之電子健康紀錄（Electronic Health Records, EHR），有效降低醫護人員在文書處理上的負擔。此外，在患者衛教與醫療溝通方面，生成式 AI 能將複雜的醫療法規、診療說明或手術同意書轉化為較易理解之自然語言，有助於提升病人之知情同意（Informed Consent）程度。針對高齡者或復健族群，相關研究亦顯示，AI 可依據個人資料提供客製化之健康建議與復健指引，具備縮減醫療資訊落差之潛在價值。
然而，生成式 AI 在醫療場景中的應用亦伴隨顯著風險，其中最受關注者為「幻覺（Hallucination）」問題，即模型可能基於機率推論生成看似合理、實際上卻不正確之醫療資訊。文獻 [8] 指出，由於生成式模型本質上缺乏對真實世界與醫療責任之理解，若未經適當查核即直接向使用者提供建議，可能對病人健康與醫療決策造成嚴重影響。此外，數據偏見（Data Bias）亦為重要倫理挑戰之一，若模型訓練資料未涵蓋多元族群或語言情境，生成結果可能對特定族群（如高齡者或方言使用者）產生系統性偏差，進而影響醫療公平性。
基於上述風險，如何建立可驗證且具可信度之生成式醫療 AI 系統，已成為當前研究的重要課題。近年研究指出，針對醫療應用場景，傳統自然語言處理評估指標（如 ROUGE、BLEU）已不足以反映生成內容之事實正確性與臨床適切性。Tanasa,Oprea and Bâra 提出[12]「LLM-as-a-Judge」之評估架構，透過性能較高之語言模型對生成結果進行多維度評估，包含相關性（Relevance）、落實度（Grounding）與完整性（Completeness），以更全面地檢驗生成內容之品質。
特別是在檢索增強生成（Retrieval-Augmented Generation, RAG）架構下，落實度（Grounding）被視為判斷系統是否產生幻覺之關鍵指標。文獻[12]中提到，可透過餘弦相似度（Cosine Similarity）計算生成文本與原始查核資料（如官方醫療指引或政府資料庫）之向量距離，以驗證系統回應是否確實依據可靠來源生成。此外，考量醫療諮詢情境中使用者可能承受之心理壓力，相關研究亦建議結合情感分析（Sentiment Analysis），以評估回應內容在同理心與倫理適切性上的表現。
此外，針對AI在中文語境下的表現
#### (4)rag準確度提升
文獻[13]提出一種結合混合檢索模型以提升醫療領域準確度的方法。該研究同時採用傳統關鍵字搜尋與 RAG（Retrieval-Augmented Generation）之語意搜尋方法，並降低大語言模型的幻覺（hallucination）的問題。文獻中進一步引入小的LLM（Qwen1.5-4B-Chat）應用在 HyDE（Hypothetical Document Embeddings） 技術，先用相對小快速的LLM對使用者查詢（query）進行初步生成回應，作為假想文件，再以該假想文件進行向量化，提升查詢向量與文件向量之間的語意相關性。透過此混合式檢索架構，可有效提升檢索結果的準確度，進而改善整體醫療資訊判斷表現。
此外，該文獻指出目前中文醫療闢謠資料相對不足，因此研究中透過爬蟲技術大量蒐集健康網站上的內容，以及使用者對健康相關網站所提出的問題，並在資料清洗後，利用LLM(GPT-3.5)自動生成對應的謠言說明、闢謠內容與正確醫學回答，建立結構化的中文健康謠言資料集（文獻提及為中文最大醫療相關資料集112萬筆），作為後續模型訓練與評估的重要基礎。
在醫療大型語言模型的訓練，文獻採用**監督式微調（Supervised Fine-Tuning, SFT）**方法，並未從零開始訓練模型，而是已中文LLM（qwen1.5-14B-Chat）為基礎進行微調，訓練過程用LLM（GPT-4）作為教師模型（teacher model）針對部分健康問題生成謠言判斷及回應分析，作為SFT的標準答案，引導其於醫療資訊及謠言判斷邏輯與回應。其訓練資料除前述所建立之中文健康謠言資料集外，並另外串接多個開源中文醫療問答資料集，以提升醫療闢謠的準確度。
## 四、 研究方法及步驟
本研究將依循軟體工程流程與方法進行需求分析、架構與介面設計、系統實作、單元測試、系統功能與效能測試。
### 1. 需求擷取與分析
本研究根據上述之研究動機分析，在分析既有健康及醫療資源軟體之優缺點後，我們擬定了此應用系統的使用者需求，底下列出較核心的功能需求。
#### A. 即時通訊互動與使用者管理（Messaging-based Interaction & User Management）
A-1. 即時通訊平台互動介面：
使用者可透過主流即時通訊平台（如 LINE）加入系統並開始互動，無需額外安裝專屬應用程式或進行複雜設定。
A-2. 多輪對話式引導機制：
系統支援多輪對話流程，能逐步引導使用者提供必要之健康相關或定位資訊，以提升資料蒐集的正確性與完整性。
A-3. 使用者偏好與介面設定：
透過輕量化前端介面（如 LIFF），管理使用者基本資料、慣用語言（如台語、國語或外籍移工母語）及回應呈現方式。
#### B. 智慧醫療建議與健康諮詢 (Medical & Health Consultation)
B-1. 需求意圖判斷： 系統能自動辨識使用者是「尋求醫療協助（急需就醫）」或「詢問一般健康問題（知識查詢）」。
B-2. 內容真偽性驗證： 對於一般健康問題，系統需判定文字內容是否具備可驗證性，並回傳查核結果。
B-3. 初步醫療建議： 針對醫療協助需求，系統提供非診斷性的初步解決建議。
B-4. AI 透明性標示： 針對不可驗證之內容，系統需明確標示為 AI 生成，以確保資訊安全與透明性。
#### C. 醫療資源定位與實體協助 (Medical Resources & Physical Assistance)
C-1. 鄰近醫療院所搜尋： 整合 GPS 定位與政府開放資料，自動搜尋使用者周邊的醫院、診所或藥局資源。
C-2. 掛號資訊指引： 提供搜尋結果之詳細資訊、線上掛號連結或診所聯絡資訊。
#### D. 多媒體影音辨識與分析 (Multimedia Analysis)
D-1. 影音格式適應與解析： 支援使用者轉發之影片或音訊內容，系統能判斷其格式是否可讀取,。
D-2. 影音轉逐字稿處理： 透過 ASR (語音轉文字) 技術將影片內容轉為逐字稿，並送入事實查核流程。
D-3. 圖片提取文字資訊： 透過 OCR (光學字元辨識) 技術提取圖片中的文字資訊，並送入事實查核流程。
D-4. 文件格式處理及提取： 透過各種文件轉檔及讀取技術提取各種常見文件類型(如pdf、docx等)所包含之文字資訊並結合D-3的OCR技術提取圖片中所含資訊
#### E. 高齡友善語音支援 (Senior-Friendly & Multilingual Support)
E-1. 台語語音互動 (TTS)： 針對不擅閱讀文字的長者，將 AI 回應內容以台語語音讀出。
E-2. 語言切換機制： 支援台語、國語及多國語言（如針對外籍照護者），確保不同族群皆能獲取準確資訊。
#### F. 家庭照護連結與管理 (Family Care & Management)
F-1. 家庭健康狀態共享： 家人或照護者可互相查看彼此的諮詢紀錄與健康狀態。
F-2. 照護介入功能： 當偵測到異常健康詢問或高風險狀況時，及時通知家庭成員。
### 2. 系統架構設計
根據上述需求分析與操作概念，本研究進一步進行 CARE 系統之整體設計。為使系統架構能更清楚呈現，本研究採用 C4 Model 作為系統描述方法（如圖 1），並繪製整體系統架構圖以輔助說明（如圖 2）。在系統設計上，本研究將使用者介面劃分為兩個核心部分（見圖 2 Frontend）：
* LINE 官方帳號： 透過 LINE Messaging API 建立互動窗口，負責接收使用者輸入（含文字、語音、影音）並回傳對話訊息。使用者可直接於 LINE 客戶端透過對話框或 Rich Menu 快速啟動醫療諮詢或健康查核服務。
* LIFF (LINE Front-end Framework) 前端框架： 開發輕量化 Web 應用，整合 LINE 帳號授權以實現一鍵登入，並提供使用者個人資料管理與醫療服務（如掛號輔助）之設定介面。
考量到開發生態的成熟度與系統擴充性，本研究選用 Node.js (Express) 建構 BFF (Backend for Frontend) 子系統(見圖2 Backend for Frontend)。此層級作為 LINE 平台與核心後端間的轉接層，專注於 Webhook 事件轉接、LIFF 請求適配及回應格式化（如 Flex Message 轉換），透過將前端呈現與商業邏輯解耦合（Decoupling），確保後續功能的彈性擴充。
為充分發揮 AI 與生成式模型 生態系的技術優勢，核心後端選用 Python FastAPI 框架開發(見圖2 Backend)。此層級為系統的中樞，負責執行「對話管理」、「事實查核」、「語音處理協調」以及醫院資源管理」等關鍵商業邏輯。
此外，為了因應快速進步的AI時代，本研究將複雜的 AI 計算與異步工作流獨立為外部系統(見圖2 External Service)處理，方便未來迭代更新的AI模型與工作流(Workflow)：
* 台語 AI 模型系統： 基於 TAIDE Gemma 3 建立專屬服務，提供精準的台語 LLM 文字生成、ASR（語音轉文字）與 TTS（文字轉語音）能力，以滿足高齡使用者的溝通需求。
* MCP (Model Context Protocol) Server： 採用新穎的 MCP 框架執行 RAG (檢索增強生成) 工作流，整合醫療知識庫，並異步處理影音分析與 OCR (光學字元辨識) 等高運算負荷之任務。
▲圖1 Container Diagram
▲圖2 CARE整體系統架構圖
---
### 3. 使用者介面設計
#### A 動態互動式訊息（Flex Messages）生成機制
在 LINE 平台所提供的 Flex Messages 設計中，可透過卡片化版面呈現多項互動元素，並於其中配置按鈕供使用者操作。使用者點擊按鈕後，系統將自動傳送預先定義之關鍵字或事件訊號至後端機器人，藉此觸發對應之系統功能與流程（如圖 3-1、圖 3-2）。
本研究利用此特性設計掛號相關互動流程，將複雜的輸入行為轉化為直覺式點選操作，以降低使用門檻並提升互動效率，特別適用於不熟悉文字輸入之高齡使用者。
▲ 圖 3 Flex Message 掛號流程示意
---
#### B 高齡友善之 Rich Menu 動態配置設計
LINE 應用程式提供 Rich Menu 快速選單功能，可於聊天介面底部呈現固定操作選項（如圖 4）。本研究依據高齡使用者之操作習慣與需求，設計高對比色彩、大尺寸按鈕及清楚圖示之 Rich Menu 介面，以提升可讀性與辨識度。
此外，系統可依據使用情境動態調整 Rich Menu 內容，使使用者在不同服務階段下，皆能快速存取最常用之功能，進一步減少操作負擔並提升整體使用體驗。
▲ 圖 4 Rich Menu 功能示意
---
#### C LIFF（LINE Front-end Framework）應用整合設計
為補足聊天介面於複雜資訊呈現上的限制，本研究整合 LINE Front-end Framework（LIFF）技術，於 LINE 應用程式內嵌網頁式互動介面，使使用者無需離開 LINE 即可完成進階操作。
LIFF 頁面可依使用裝置自動適配不同版型，確保於行動裝置與桌上型電腦上皆能提供一致且良好的操作體驗。圖 5 與圖 6 分別展示手機版與電腦版之 LIFF 介面設計。
▲ 圖 5 手機版 LIFF 頁面
▲ 圖 6 電腦版 LIFF 頁面
---
### 4. 核心技術設計
#### A 適地性資源搜尋與資料整合 (LBS & Data Integration)
為提升醫療資訊服務之即時性與實用性，本研究整合地理資訊服務（Location-Based Services, LBS）與多來源醫療資料，實現以使用者所在地為核心的適地性醫療資源搜尋與資訊整合機制。系統將依據使用者授權取得之定位資訊（如 GPS 座標或行政區），結合政府開放資料與醫療機構公開資訊，提供符合實際需求之醫療院所建議與服務指引。
* 健康資訊與闢謠資料整合：
本研究優先採用具官方可信度之資料來源作為事實查核依據，包括衛生福利部（MOHW）、疾病管制署（CDC）及食品藥物管理署（TFDA）等政府單位之公開資料。
* 醫院資源定位與篩選機制：
在醫療院所推薦方面，系統將依據使用者所在位置，計算使用者與周邊醫療院所間之地理距離，距離計算可參考google map使用的dijkstra[11]演算法，並結合醫院屬性資料（如科別、門診時段、是否仍在看診）進行多條件篩選。此篩選機制確保所回傳之醫療院所為「目前可提供服務」且「符合使用者需求」之合法醫療機構，避免提供過期或不具實用性的資訊。
```mermaid
---
title:
---
flowchart TD
start([詢問使用者是否開啟GPS])
start -- 是 --> GPSgetLocation[透過GPS取得使用者位置]
start -- 否 --> CantSearch[無法搜尋附近資源]
GPSgetLocation --> GPSOkOrNot{GPS定位是否成功}
GPSOkOrNot -- 是 --> SearchOpenData[尋找政府開放資料中的醫療院所]
GPSOkOrNot -- 否 --> TryLocate[嘗試重新定位]
TryLocate --> GPSOkOrNot
SearchOpenData --> hasLegalDataOrNot{是否有合法的資料}
hasLegalDataOrNot -- 是 --> calcAndSort[計算距離並排序]
hasLegalDataOrNot -- 否 --> NoResource[告訴使用者附近查無醫療院所]
calcAndSort --> ReturnInfoAndAsk([回傳資訊並詢問使用者是否需要實體協助])
```
* 掛號與聯絡資訊指引：
系統於確認合適之醫療院所後，將從自建資料庫或外部 API 擷取該院所之官方掛號連結、聯絡電話及相關注意事項，並透過 LINE Flex Message 格式或是LIFF回傳至前端介面。此方式可在維持良好使用者體驗的同時，降低高齡使用者於資訊查找與掛號流程中的操作負擔。
```mermaid
---
title:
---
flowchart TD
selectHospital([確認合適醫療院所]) --> fetchContactInfo[擷取掛號連結、聯絡電話與注意事項]
fetchContactInfo --> checkData{是否取得有效資料}
checkData -- 是 --> returnData[回傳掛號與聯絡資訊]
checkData -- 否 --> notifyUser[告知使用者查無資料]
returnData --> chooseDelivery{傳送方式選擇}
chooseDelivery -- LINE Flex Message --> displayFrontEnd[前端介面顯示掛號與聯絡資訊]
chooseDelivery -- LIFF --> displayFrontEnd
displayFrontEnd --> userAction[使用者查閱與操作掛號]
```
#### B 多模態內容處理與分析技術 (Multimodal Content Processing)
考量使用者可能透過文字、語音、圖片或影音等多元形式輸入資訊，本研究設計一套多模態內容處理流程，以統一方式將非結構化資料轉換為可分析之結構化文本，作為後續事實查核與醫療判斷之依據。
* 影音轉逐字稿流程：
當系統接收到使用者上傳之音訊或影片檔案時，將先進行格式驗證與音軌提取，並導入支援台語及多語系之語音辨識模型（ASR）進行語音轉文字處理。轉換完成後，系統會產生逐字稿文本，作為後續語意分析與資訊擷取的主要輸入來源。
* 影像文字擷取（OCR）：
對於圖片類型輸入（如藥袋、藥單或醫療文件），系統將使用 PaddleOCR 進行光學字元辨識（Optical Character Recognition, OCR），將影像內容轉換為可處理之文字資料。PaddleOCR 具備良好中文辨識能力，且易於部署於 Python 環境，符合本研究系統架構需求。
* 文字正規化與個資過濾（PII Filtering）：
為降低誤判風險並確保使用者隱私，系統於文字整合階段將執行正規化與降噪處理，並透過個人可識別資訊（Personally Identifiable Information, PII）過濾機制，自動遮蔽姓名、身分證字號、電話等敏感資訊，避免將不必要之個資送入大型語言模型進行推論。
* 命名實體識別（Named Entity Recognition, NER）：
在資訊擷取階段，本研究導入自然語言處理之命名實體識別技術，針對文本中的醫學相關實體（如藥品名稱、症狀、疾病、醫療院所名稱）進行精準標註。此機制可將使用者輸入轉換為結構化查詢條件，提升後續醫療資料檢索與事實查核之準確性，避免僅依賴模糊關鍵字比對所造成的錯誤推論。
```mermaid
---
title:
---
flowchart TD
Start([接收使用者上傳內容]) --> CheckType{判斷媒體類型}
%% 影音處理路徑
CheckType -- 影片/音訊 --> ExtractAudio[提取音軌]
ExtractAudio --> FormatCheck_AV{格式檢查<br/>mp4, wav, mp3}
FormatCheck_AV -- 格式錯誤 --> ErrorMsg[回傳不支援格式訊息]
FormatCheck_AV -- 格式正確 --> ASR_Model[導入台語/多語系 ASR 模型<br/>Speech-to-Text]
ASR_Model --> GenTranscript[生成逐字稿]
%% 圖片處理路徑
CheckType -- 圖片 --> FormatCheck_Img{格式檢查<br/>jpg, png}
FormatCheck_Img -- 格式錯誤 --> ErrorMsg
FormatCheck_Img -- 格式正確 --> OCR_Model[導入 OCR 光學字元辨識<br/>Image-to-Text]
OCR_Model --> ExtractText[提取圖片內文字]
%% 整合與預處理
GenTranscript --> MergeText[文字正規化與PII個資過濾]
ExtractText --> MergeText
MergeText --> Output([輸出結構化文本<br/>至 RAG 事實查核模組])
style Start fill:#f9f,stroke:#333,stroke-width:2px
style Output fill:#bbf,stroke:#333,stroke-width:2px
style ASR_Model fill:#dfd,stroke:#333
style OCR_Model fill:#dfd,stroke:#333
```
#### C 高可靠性事實查核與 RAG 技術 (Fact-checking & RAG Mechanism)
為降低生成式 AI 在醫療場域中可能產生的不實或誤導性資訊風險，本研究將事實查核機制視為核心設計重點，並結合檢索增強生成（RAG）架構，確保系統回應內容具備可驗證性與來源依據。
* 醫療知識庫與向量資料庫建置：
本研究將官方醫療文件、健康指引與闢謠資料進行文本切分與向量化處理，並儲存於向量資料庫中。透過語意相似度搜尋，系統能在生成回覆前，快速檢索與使用者問題最相關之可信資料片段。
* RAG 工作流程設計：
當使用者提出健康相關問題時，系統將先透過 NER(命名實體識別) 與語意分析建立查詢向量，並自醫療知識庫中檢索相關內容，再將檢索結果與使用者原始問題一併送入大型語言模型進行生成。此流程可有效限制模型回應範圍，使其基於已驗證之資料進行回答，而非單純依賴模型內部參數記憶。
```mermaid
flowchart TD
start([使用者提出健康相關問題]) --> NER[命名實體識別<br/>標註藥品/症狀/疾病]
NER --> Semantic[語意分析]
Semantic --> Vector[建立查詢向量]
Vector --> Retrieval{自醫療知識庫檢索<br/>語意相似度搜尋}
DB[(醫療知識庫)]
DB -.->|提供已驗證資料| Retrieval
Retrieval --> Combine[整合檢索結果與原始問題]
Combine --> LLM[送入大型語言模型]
LLM --> Verify{事實查核}
Verify --> Output([生成基於驗證資料之回答<br/>具可追溯來源])
```
* 真偽性判斷與風險標示機制：
針對無法於資料庫中找到對應佐證之內容，系統將自動降低回應確定性，並於前端標示「尚無足夠可靠來源驗證」或「AI 生成內容，僅供參考」等警語，以避免使用者誤將生成結果視為專業醫療建議。
* MCP（Model Context Protocol）之應用：
本研究透過 MCP Server 管理多模型與多工作流之上下文傳遞，將 RAG 查詢、影音分析、OCR 與語音處理等高運算任務進行模組化與非同步處理。此設計不僅提升系統整體效能，亦利於未來替換或升級 AI 模型，而不影響核心後端架構。相關健康資訊將透過n8n自動化工作流進行資料清洗與標準化處理，並儲存於結構化資料庫(如PostgreSQL)與向量資料庫中(如milvus)，作為後續 RAG（Retrieval-Augmented Generation）查詢與比對之基礎。透過此機制，系統得以針對使用者提出的健康疑問或網路傳言，提供具可追溯來源之澄清與說明。
```mermaid
flowchart TD
start([接收使用者上傳內容])
start --> AsyncDispatch{任務類型判斷}
AsyncDispatch -->|文字| RAGQuery[RAG 查詢模組]
AsyncDispatch -->|影像| OCR[OCR 文字辨識]
AsyncDispatch -->|影音| MediaAnalysis[影音分析]
AsyncDispatch -->|語音| SpeechProcess[語音處理]
subgraph n8nworkflow[n8n 自動化工作流]
RAGQuery --> n8n[資料清洗與標準化]
OCR --> n8n
MediaAnalysis --> n8n
SpeechProcess --> n8n
n8n --> StructDB[(結構化資料庫)]
n8n --> VectorDB[(向量資料庫)]
StructDB --> RAGEngine[RAG 檢索與比對]
VectorDB --> RAGEngine
RAGEngine --> TraceableAnswer[產生具可追溯來源之回應]
TraceableAnswer --> UserResponse([回傳闢謠結果與說明])
end
```
#### D 在地化台語語音互動技術 (Localized Speech Technology)
本研究透過整合語音辨識（Automatic Speech Recognition, ASR）、文字轉語音（Text-to-Speech, TTS）以及大型語言模型（Large Language Model, LLM）等技術，實現符合在地需求之本土語言語音互動系統（如圖所示）。
使用者透過前端介面輸入台語語音後，語音資料將傳送至後端進行處理。首先，系統透過台語 ASR 將語音轉換為台語逐字稿，接著由具備台語處理能力之 AI 模型進行語言轉換，將台語逐字稿轉換為後端可處理之語言（目前預設為中文），並將結果傳遞至核心後端系統進行後續分析與處理。
核心後端結合檢索增強生成（Retrieval-Augmented Generation, RAG）與規則引擎，負責執行醫療相關邏輯判斷與內容查核，確保回應內容之正確性與安全性。當後端產生最終回應文字後，系統將依據使用者的語言習慣與個人設定，決定是否以台語進行回覆。
若選擇台語回應，系統會先透過台語 AI 模型將中文回應轉換為台語逐字稿，並特別針對高齡使用者進行語言友善化處理，最後再由台語 TTS 將逐字稿轉換為台語語音，並透過通訊平台回傳給使用者，完成整體語音互動流程。
在技術選型方面，本研究目前規劃使用 Breeze ASR 25 作為台語語音辨識模型，該模型已針對臺灣華語以及華語與英語混用情境進行最佳化，具備良好辨識效能。大型語言模型則選用 Gemma 3 TAIDE 12B，其為 TAIDE 計畫所開發、符合臺灣語言與文化特性的生成式對話模型，亦為目前 TAIDE 最新模型之一，適合用於台語文字理解與轉換任務。
```mermaid
flowchart TD
A(高齡使用者<br/>台語語音輸入) --> B[台語 ASR]
B --> C[台語 AI<br/>台語逐字稿 → 中文逐字稿<br/>僅語言轉換]
C --> D[核心 Backend<br/>RAG / 規則引擎<br/>醫療邏輯與查核]
D --> E[安全且已查核之<br/>回應文字]
E --> F[台語 AI<br/>中文回應 → 台語逐字稿<br/>長輩友善語言生成]
F --> G[台語 TTS]
G --> H([LINE 回傳<br/>台語語音回覆])
```
### 5.軟體測試與部署
為確保本研究所建構之醫療輔助 AI 系統於開發與部署過程中具備穩定性、可驗證性與可回溯性，本研究導入持續整合與持續部署（Continuous Integration / Continuous Deployment, CI/CD）機制。
有別於傳統僅針對程式碼建置與部署之 CI/CD 流程，本研究進一步將 AI 行為驗證與知識庫更新納入自動化驗證範圍，建構一套以風險控管為核心之分層式 CI/CD 架構。
#### 分層式 CI 設計
本研究之 CI 流程區分為三個相互獨立且可單獨失敗之驗證層級，分別為程式碼整合驗證、AI 行為驗證與知識庫驗證。
1. 程式碼整合驗證（Code CI）
於程式碼提交階段，系統自動執行程式碼靜態分析、單元測試與API測試，以確保基本功能與介面一致性，避免低階錯誤進入後續部署流程。
2. AI 行為驗證（AI Behavior CI）
針對大型語言模型於醫療輔助情境中可能產生之行為漂移與幻覺風險，本研究設計 AI 行為驗證流程，透過預先定義之黃金問答集（Golden QA Set），於每次模型、提示詞或推論邏輯更新時進行回歸測試，以檢驗回應是否符合預期行為範圍。
3. 知識庫驗證（Knowledge CI）
本研究將知識庫更新視為高風險變更之一環，於知識文件匯入向量資料庫前，先行執行文件結構、來源標註與嵌入向量品質之驗證，避免不合規資料直接影響系統推論結果。
```mermaid
flowchart TD
A[變更發生<br/>Code / Prompt / Knowledge] --> B[版本控制<br/>Git Repository]
B --> C1[Code CI<br/>Lint / Unit Test / API Test]
B --> C2[AI Behavior CI<br/>Golden QA Set<br/>Hallucination Check]
B --> C3[Knowledge CI<br/>Document / Metadata / Embedding Check]
C1 --> D{是否通過?}
C2 --> D
C3 --> D
D -- 否 --> E[拒絕合併<br/>回饋修正]
D -- 是 --> F[部署至 Staging 環境]
F --> G[人工審核<br/>Human-in-the-loop]
G -- 未通過 --> E
G -- 通過 --> H[部署至 Production 環境]
H --> I[系統監控與<br/>可回滾機制]
```
## 五、 預期結果
#### 1. 預期學習結果
* 軟體工程流程實踐： 實際執行需求分析、系統架構設計（C4 Model）、實作及測試等軟體開發流程，並落實 Scrum 敏捷開發與迭代發展最小可行產品（MVP）。
* 後端與 API 開發技術： 學習使用 FastAPI (Python) 構建核心業務邏輯、使用 Node.js (Express) 開發 Backend for Frontend (BFF) 轉換層，並掌握 RESTful API 設計原則。
* 前端與行動框架應用： 學習 React/Vue.js 結合 LINE Front-end Framework (LIFF) 技術，打造跨平台且低門檻的使用者互動介面。
* 生成式 AI 與多模態處理技術： 學習如何整合 TAIDE Gemma 3 模型進行台語語意生成，並運用 MCP (Model Context Protocol) 框架實現 RAG (檢索增強生成) 工作流，以處理醫療知識檢索與影音/影像分析。
* 雲端維運與資料庫管理： 熟悉 MongoDB 文件型資料庫、Redis 快取機制，並學習使用 Docker 容器化技術進行系統部署與環境管理。
#### 2. 預期系統結果
* 建立高可靠性的健康資訊助理： 打造一個整合 LINE 介面的智慧助理，提供幻覺率低的 AI 醫療建議與闢謠功能，確保健康資訊的可信度。
* 落實高齡者友善之語音服務： 透過台語 ASR (語音轉文字) 與 TTS (文字轉語音) 技術，消除數位落差，讓不擅閱讀文字的長輩能以台語進行就醫諮詢。
* 醫療資源整合與實體協助： 系統能結合 GPS 定位提供附近醫療院所資訊，並輔助查詢掛號資訊，實現從線上諮詢到實體就醫的資源對接。
* 家庭健康連結機制： 建立家庭連結功能，讓照護者能即時掌握家人的健康詢問紀錄與狀態，提升遠端照護效率。
## 六、 需要指導教授指導內容
1. 資料收集：學習資料與文獻收集、分析與整理之方法。
2. AI 系統架構與技術分析： 指導如何設計 Agentic System 的決策邏輯，特別是針對醫療領域 RAG 工作流的準確性優化，以及台語 AI 模型在特殊語境下的提示工程（Prompt Engineering）設計。
3. 軟體工程研究方法： 指導如何運用服務導向架構（SOA）與 C4 模式進行細部設計，確保系統在處理大量多媒體（影片、語音）時的效能與擴展性。
4. 系統測試、部署與倫理： 指導如何設計不同的測試案例，以驗證事實查核功能的精準度，以確保本系統之可用性與可靠度；針對 AI 生成內容的社會責任與醫療倫理風險（AI Transparency）提供專業指引，並學習如何運用持續整合/部署以及容器技術，進行系統自動化建置與發佈。
## 七、 參考文獻
[1] 一天開LINE幾次？台灣人使用行為報告公開：近半數中重度, Available from: https://today.line.me/tw/v3/article/YaXEez8
[2] 探討智慧醫療新創提供 LINE 聊天機器人服務之 關鍵因素：以某數位新創公司為例, Available from: http://tdr.lib.ntu.edu.tw/jspui/handle/123456789/94833
[3] 快速建置行動醫療助理機器人 結合對話機器人& LINE 問診 部立臺北醫院用iota C.ai 創高效, Available from: https://www.gss.com.tw/eis/257-eis105/3178-eis105-09
[4] 財團法人網路資訊中心 2023 年台灣網路報告 pp.107-121
[5] 財團法人網路資訊中心 2024 年台灣網路報告 pp.89-115
[6] 財團法人網路資訊中心 2025 年台灣網路報告 pp.261-262
[7] Lei and Chang(2019) "Privacy Protection for Telecare Medicine Information Systems with Multiple Servers Using a Biometric-based Authenticated Key Agreement Scheme" ,Available from:https://ieeexplore.ieee.org/document/8930560
[8] 蔡甫昌, 周昱辰, "大型語言模型醫學應用之倫理挑戰與監理," 台灣醫學, vol. 29, no. 1, pp. 75-85, 2025.
from:https://www.fma.org.tw/fweb/doc/mgz/29-1/fma29-1-11.pdf
[9] 蔡甫昌, 周昱辰, "大型語言模型醫學應用之倫理挑戰與監理," 台灣醫學, vol. 29, no. 1, pp. 76, 2025.
from:https://www.fma.org.tw/fweb/doc/mgz/29-1/fma29-1-11.pdf
[10] 金融監督管理委員會, "金融業運用人工智慧(AI)之核心原則及政策," 2023.
from:https://www.fsc.gov.tw/websitedowndoc?file=chfsc/202408231741530.pdf&filedisplay=%E9%99%84%E4%BB%B6_%E9%87%91%E8%9E%8D%E6%A5%AD%E9%81%8B%E7%94%A8AI%E6%8C%87%E5%BC%95.pdf
[11] Lanning, D. R., Harrell, G. K., & Wang, J. (2014). Dijkstra's algorithm and Google maps.[Abstract],ACMSE '14: Proceedings of the 2014 ACM Southeast Conference
Article 30,1–3.https://doi.org/10.1145/2638404.2638494
[12]https://www.mdpi.com/2079-9292/15/2/334
[13]HRDE: Retrieval-Augmented Large Language Models for Chinese
Health Rumor Detection and Explainability
Sign in with Wallet
Connect another wallet