# 國科會大專生計畫草案 - 基於RAG的災難情境模擬系統
—— 結合 Agentic RAG 與情感運算的 On-Device 防災應用

## 1. 栽要

本計畫旨在 ~~開發 or 研究~~ 一款基於邊緣運算 (Edge AI) 的災難響應行動應用程式。
- 提高災前知識準備效率
- 針對災難發生時網路中斷及使用者心理恐慌兩大問題，此系統整合 Agentic RAG (檢索增強生成代理) 與 情感運算 (Affective Computing) 技術。系統能在離線環境下，透過 SLM (小型語言模型) 提供客製化的生存指導，並具備「生存核心」與「心理急救」雙模式切換機制。研究將探討模型量化、多模態感知及可解釋性 AI (XAI) 在行動裝置上的實踐與效能優化。
研究方法?
預想的研究結果?

## 2. 研究動機與背景
### 2.1 現況問題分析
- 高度依賴網路的脆弱性： 現有防災 App (如 Google Maps, Line 回報) 多需聯網。一旦基地台損毀，App 即失去功能。
- 資訊過載 (Information Overload)： 災難時資訊混亂，使用者難以從海量地圖標點中判斷「當下」該往哪裡逃。
- 缺乏情境感知與心理支持： 傳統 App 僅提供通用資訊 (如：地震要躲桌下)，無法針對具體情境 (如：腿部骨折、瓦礫堆受困) 提供建議，且忽略了災難當下的「恐慌」與「凍結反應 (Freeze Response)」。

### 2.2 現有防災app功能改進
功能類別|典型功能|本計畫改進點
---|---|---
即時示警 | PWS、颱風路徑、土石流警戒 | 結合本地推論，不只依賴即時 Server 推播
情資地圖 | 避難所位置、AED 位置、降雨量 | 動態路徑規劃：只找「有資源」且「路徑安全」的避難所
教育與指引 | 靜態圖文教學 (CPR 圖片) | Agent 引導：透過對話式互動，一步步引導急救操作
離線輔助 | 離線地圖下載、防災存摺 | Edge RAG：離線檢索醫療/生存 SOP，而非僅是地圖

## 3. 研究目標
本計畫旨在解決 「斷網環境下的個人化生存指引」 問題，並設定以下層次目標：
- 建構離線邊緣智能系統 (Infrastructure)： 在手機端部署量化後的 SLM (如 Gemma 2B/Phi-3)，實現斷網環境下的自然語言理解。
- 開發多模態感知與認知模組 (Perception & Cognition)： 利用鏡頭辨識災情/物資，利用麥克風偵測情緒，並據此動態切換 App 運作模式。
- 實作可解釋性推理 (XAI & KA-RAG)： 透過知識圖譜增強 RAG，讓 AI 的建議具備「來源歸因」，提升使用者在危急時刻的信任度。

## 4. 系統架構與方法 (System Architecture & Methodology)
本系統採用三層式架構設計：

### 4.1 感知層 (Perception Layer) - Multimodal RAG + Affective Computing
- 功能： 作為 AI 的眼睛與耳朵。
- 平時預防 (Pre-disaster)：
利用鏡頭掃描居家環境，分析家具擺放風險 (如：櫃子是否擋住門)。
- 災時應變 (Post-disaster)：
- 視覺辨識： 使用輕量化模型 (如 MobileNet/EfficientNet) 辨識環境 (火災、倒塌) 與物資 (水瓶數量)。
- 聽覺情緒偵測： 使用 Audio Classifier 偵測環境音 (尖叫、哭聲、急促呼吸)，判斷使用者焦慮等級 (Panic Score)。

### 4.2 認知層 (Cognition Layer) - Agentic RAG + SLM
- 核心大腦： 負責決策與生成指令。
- 模式動態切換 (Mode Switching)： 根據 Panic Score 自動切換 System Prompt。
- Mode A (生存核心 - Emergency Mode)：
- 觸發條件： 判斷環境危急或使用者冷靜。
- 行為： 指令簡短明確 (祈使句)，專注於生存 SOP (止血、逃生路徑)。
- Mode B (心理急救 - Counseling Mode)：
- 觸發條件： 環境相對安全但使用者極度焦慮/哭泣。
- 行為： 語氣溫柔，啟動心理急救 (PFA) 流程，引導深呼吸，安撫情緒。
- 智慧配給管家 (AI Rationing Agent)：
- 輸入：掃描到的物資 (水、食物) + 受困人數。
- 運算：結合人體代謝數據，計算最佳生存配給 (如：每人每 4 小時 50cc 水)。

### 4.3 基礎層 (Infrastructure Layer) - Trustworthy Edge Intelligence
- 隱私與可靠性： 所有數據 (影像、語音、位置) 均在本地處理，不需上傳雲端。
- 技術實踐：
- 記憶體優化： 使用 EcoVector (概念版)。以 Disk-based (sqlite-vec) 儲存大量向量資料，RAM 僅載入「災難類別中心向量」進行粗篩，解決手機記憶體不足問題。
- 模型推論： 整合 MediaPipe (處理視覺/音訊特徵) 與 ExecuTorch/TFLite (執行 LLM 推論)。
- 智慧電力管理 (Smart Energy Governor)： 電量低於 20% 時，強制切換 OLED 黑底模式，並縮減 LLM 的 Context Window 以降低功耗。

## 5. 關鍵技術與實作路徑 (Technical Implementation)
### 5.1 硬體與框架選型
- 目標裝置： Android 平台 (考慮大專生開發資源與 NDK 支援性)。
- 推論框架：
- MediaPipe: 用於快速部署 Object Detection (物資/環境) 與 Audio Classification (情緒)。
- LlmInference API (TFLite) / ExecuTorch: 用於執行量化後的 Gemma 2B (Int4) 或 Llama-3 (4-bit)。
- 開發語言： Kotlin (App 邏輯) + C++ (NDK 底層效能優化)。

### 5.2 XAI 與 KA-RAG (Knowledge Graph RAG) 實踐
為了增加 AI 建議的可信度 (Trustworthiness)，本計畫將實作輕量級的 KA-RAG：
- 原理： 不在手機上動態生成圖，而是預先建立「災難推理路徑」的 Mermaid.js 語法庫。
- 應用： 當使用者問「為什麼要這樣做？」，系統檢索對應的邏輯圖並渲染顯示。
- 例： [傷口] --> [加壓] --> [止血] --> [存活]
- 來源歸因： 每一條建議均標註來源 (如：「依據：內政部消防署地震手冊 P.5」)，並支援點擊查閱原始離線文件。

## 6. 預期成果 (Expected Outcomes)
類別|預期指標/產出
---|---
量化指標|1. 離線環境下，針對常見災難問題 (急救/避難) 的回應時間 < 3秒。2. 語音/情緒辨識準確率 > 85%。3. 應用程式在低電量模式下，續航力較一般模式提升 20%。
具體產出|1. 一套可運作的 Android App 原型 (Prototype)。2. 災難場景專用的輕量化向量資料庫 (SQLite 格式)。3. 結案報告與技術文件 (含 GitHub 開源程式碼)。
社會價值|提供斷網環境下的數位韌性 (Digital Resilience)，降低災難初期的恐慌與錯誤決策，提升黃金時間生存率。
學習成長|掌握 Edge AI 模型部署、RAG 系統架構設計、Android NDK 開發及情感運算應用。

-----
=============
-----

## 題目發想
### 災前教學
- 可聯網 - LLM
- 缺了解當地文化教師，ai 需要能以不同文化、信仰與價值觀背景的口吻輸出內容。
- 不同文化也需要不同的應對機制。
- 在地化教材，使用不同語言。
- 結合地理資訊系統（Web GIS）
- 對話式 AI
- 系統可以引導使用者談論對災難的恐懼，並教授簡單的呼吸法或認知重構技巧。這在心理學上稱為「預防接種 (Inoculation)」
- 官方的防災清單通常是通用的，無法針對特定家庭狀況（如：家中有臥床長輩、寵物、或住在高樓層）提供具體建議
- 結論

    開發和實施針對不同文化的族群的 ai 教學與應對~~系統~~

### 災中
- 可能斷網 - SLM
1. 防災教育從「平時的知識」轉化為「戰時的生存工具」
- 快速從教材中檢索到急救步驟（如：「現在流血了該怎麼辦？」）
2. 心理對話功能，引導使用者進行情緒宣洩（Ventilation）或提供即時的安撫建議。

### 災後
- 可聯網 - LLM
- 心理健康與復原

## 結合離線 RAG 口袋知識庫的災難情境對話演練以提升防災韌性
- 應有的系統模組
- 如何提供對話情境?(如何判斷並面對災難，增進互助)
- 歷史事件總結 + 新聞推波
- 災難種類

- 實驗對照組?

### RAG
[一文读懂：大模型RAG（检索增强生成）含高级方法](https://zhuanlan.zhihu.com/p/675509396)

#### 資料準備階段 (Data Preparation / Offline Pipeline)
1. 資料提取 (Data Extraction)
將各種格式的檔案（如 PDF、Markdown、Word、HTML）轉化為純文字。
2. 文本分割 (Text Splitting / Chunking)
將長篇大論切割成較小的「塊」（Chunks）。
3. 向量化 (Embedding)
利用 Embedding Model 將文字塊轉換成高維度的數值向量（Vector）。
5. 資料入庫 (Vector Storage)
將生成的向量連同原始文字（Metadata）存入向量資料庫（如 Milvus, Pinecone, FAISS）。

#### 應用階段 (Application / Online Inference)
1. 使用者提問與向量化
2. 資料檢索 (Retrieval / Recall)
3. 注入 Prompt (Augmentation)
4. LLM 生成答案 (Generation)

### 架構
#### 知識庫建置以及動態更新

graph TD
    %% 樣式定義
    classDef static fill:#e3f2fd,stroke:#1565c0,stroke-width:2px;
    classDef dynamic fill:#fff3e0,stroke:#ef6c00,stroke-width:2px;
    classDef gatekeeper fill:#ffebee,stroke:#c62828,stroke-width:2px;

    %% 靜態建置路徑
    subgraph Static_Ingestion [1.靜態基礎建置 - 離線手冊]
        direction TB
        S1(原始防災手冊 PDF/SOP) --> S2[RAPTOR 遞迴摘要處理]
        S2 --> S3[Embedding 向量化]
        S3 --> VDB[(離線向量資料庫)]
    end
    class Static_Ingestion static;

    %% 動態更新路徑
    subgraph Dynamic_Update [2.動態更新路徑 - 每日推播]
        direction TB
        D1[每日網路搜尋/爬蟲] --> D2{動態內容過濾器<br/>The Gatekeeper}
        
        %% 判斷邏輯
        D2 -->|不通過| D3[僅執行一次性推播<br/>不儲存]
        D2 -->|通過| D4[知識精煉與結構化]
        
        D4 --> S3
    end
    class Dynamic_Update dynamic;
    class D2 gatekeeper;

    %% 使用者互動
    subgraph User_Interaction [3.使用者選擇演練]
        direction LR
        U1[推播通知] --> U2{使用者點擊演練?}
        U2 -->|是| U3[載入當日情境 + 輔助知識]
        U3 -->|啟動| Agent[Agentic RAG 演練代理]
    end

    %% 連接
    VDB -.-> U3
    D3 -.-> U1
    D4 -.-> U1

如何判斷「推播內容」是否需要存入資料庫？
在資工領域，這稱為 「資料減量與精煉策略 (Data Pruning & Refinement)」。我建議你採用以下三個維度作為判斷標準：

A. 語意相似度檢索 (Semantic Redundancy Check)
作法： 將新資訊進行 Embedding 後，與現有資料庫進行相似度比對。
判斷： * 如果相似度 > 0.9（代表資料庫已有類似教學），則 不存入。
如果出現新關鍵字（如：某種新型化學災害、特定的斷層活動更新），則 存入。

B. 資訊的「生命週期」 (Information Volatility)
作法： 區分「時效性資訊」與「長效性知識」。
時效性 (不存入)： 「今天下午兩點某路段淹水」、「目前降雨量」。這些過幾天就失效了。
長效性 (存入)： 「針對最新暴雨等級的避難 SOP 修改」、「新發現的斷層帶避難熱點」。

C. 針對個人化需求 (User-Centric Filtering)
作法： 比對 User Profile。
如果推播內容是關於「山區土石流」，但使用者住在「大都會中心」，則僅推播而不存入資料庫，避免干擾未來的檢索。

「知識庫動態增量策略 (Dynamic Incremental Update Strategy)」：
為解決口袋化裝置儲存空間限制與 RAG 檢索效能之平衡，本研究設計一 「雙軌知識處理模型」：
- 靜態軌 (Static Path)：針對權威性防災手冊進行一次性 RAPTOR 樹狀索引建置，確保基礎核心知識的完整性。
- 動態軌 (Dynamic Path)：每日擷取之防災資訊須經過 「知識門戶代理 (Knowledge Gatekeeper Agent)」 評估。該代理程式透過 相似度閾值過濾 (Similarity Threshold Filtering) 判斷新資訊之增量價值。
- 知識結構化：具備儲存價值之資訊將經由 SLM 進行 摘要與標籤化 (Abstractive Tagging)，轉化為結構化 JSON 片段後再執行 Embedding，以確保在離線檢索時能以最小空間代價獲得最高關聯度。

實作一個 「自動化清理機制」：
- 設定資料庫容量上限（例如 500MB）。
- 當空間不足時，自動刪除 「檢索頻率最低 (Least Frequently Used, LFU)」 或 「時效過期」 的動態資訊。這展現了你對系統資源管理（System Resource Management）的深度思考。

#### 檢索核心引擎（Retrieval Engine）
- 系統不再是被動回答，而是主動設計「災難情境」考驗使用者，並根據使用者的反應進行評估與指導。

graph TD
    %% 樣式定義
    classDef personal fill:#fce4ec,stroke:#880e4f,stroke-width:2px,color:black;
    classDef storage fill:#e1f5fe,stroke:#01579b,stroke-width:2px,color:black;
    classDef agentCore fill:#fff3e0,stroke:#ef6c00,stroke-width:2px,color:black;
    classDef optimization fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px,color:black;
    classDef stateLoop fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px,stroke-dasharray: 5 5,color:black;

    %% A. 離線知識與個人化存儲層 (Offline Storage)
    subgraph Offline_Storage [離線數據中心]
        direction TB
        DB_R[(1.RAPTOR 層級向量資料庫<br/>災難手冊/SOP)]
        DB_U[(2.個人化資訊庫<br/>住處/病史/家人)]
        DB_S[(3.事件狀態快取<br/>State Store)]
    end
    class DB_U personal;
    class Offline_Storage storage;

    %% B. 動態輸入與情境解析
    subgraph Input_Processing [動態輸入與解析]
        I1(使用者輸入: 現實災情或演練回答) --> I2[Context 整合器]
        DB_S -.->|讀取當前進度| I2
        DB_U -.->|提取使用者背景| I2
    end

    %% C. 優化檢索流程 (Optimization RAG)
    subgraph RAG_Engine [檢索優化核心]
        direction TB
        R1[Query 重寫/擴充<br/>整合個人化變數] --> R2[初次檢索: Top-50]
        DB_R -.-> R2
        R2 --> R3[後檢索重排序: Reranker]
        R3 --> R4[精選 Top-5 關鍵片段]
    end
    class RAG_Engine optimization;

    %% D. 代理式決策大腦 (Agentic Core)
    subgraph Agentic_Core [代理式演練/應變核心]
        direction TB
        A1{模式識別代理} -->|真實應變| A2[行動指揮模組]
        A1 -->|情境演練| A3[演練推進器]
        
        R4 --> A1
        A2 --> A4[任務生成與評估]
        A3 --> A4
    end
    class Agentic_Core agentCore;

    %% E. 輸出與狀態推進循環 (Progression Loop)
    subgraph Progression_Loop [狀態推進循環]
        A4 --> SLM[SLM 生成回覆/指導]
        SLM --> Output[最終回饋與救命指令]
        Output --> P1[狀態更新代理]
        P1 -->|更新演練關卡或災情階段| DB_S
        P1 -->|引導使用者執行下一步| I1
    end
    class Progression_Loop stateLoop;

    %% 備註說明
    note[註：個人資訊僅存放於本地，確保隱私]

graph TD
    %% 樣式定義 (保持不變)
    classDef personal fill:#fce4ec,stroke:#880e4f,stroke-width:2px,color:black;
    classDef storage fill:#e1f5fe,stroke:#01579b,stroke-width:2px,color:black;
    classDef memory fill:#fff9c4,stroke:#fbc02d,stroke-width:2px,stroke-dasharray: 5 5,color:black;
    classDef optimization fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px,color:black;
    classDef core fill:#fff3e0,stroke:#ef6c00,stroke-width:2px,color:black;

    %% A. 硬體分層
    subgraph Hardware_Layer [行動裝置硬體分層]
        subgraph Disk_Storage [Flash Storage / ROM 低速大容量]
            DB_R[(1.RAPTOR 層級向量庫<br/>災難手冊/SOP)]
            DB_Experts[(MoE 專家權重<br/>特定災害模組)]
            DB_Log[歷史對話存檔]
        end
        
        subgraph RAM_Memory [DRAM 高速小容量]
            DB_U[(2.個人化資訊快取)]
            DB_S[(3.事件狀態 State)]
            Draft_Model[Draft Model<br/>駐留小模型]
            Active_Expert[動態載入的<br/>專家權重]
        end
    end

    %% B. 動態輸入與情境解析
    subgraph Input_Processing [動態輸入與解析]
        I1(使用者輸入) --> I2[Context 整合器]
        DB_S -.-> I2
        DB_U -.-> I2
    end

    %% C. 優化檢索與動態載入
    subgraph Retrieval_System [I/O 優化檢索]
        R1[Query 重寫] --> R2[索引查找]
        R2 -.->|On-demand Loading| DB_R
        R2 --> R3[Top-K 檢索結果]
    end

    %% D. 推測解碼生成核心
    subgraph Inference_Engine [EdgeLLM 推論引擎]
        Task_Mgr{任務管理器} --> Speculative_Decoding
        
        subgraph Speculative_Decoding [推測解碼迴圈]
            SD1[Draft Model 生成草稿] 
            SD2[Main SLM 驗證/修正]
            SD1 -->|快速預測| SD2
            Draft_Model -.-> SD1
            DB_Experts -.->|I/O Swapping| Active_Expert
            Active_Expert -.-> SD2
        end
    end

    %% 連接關係
    I2 --> R1
    R3 --> Task_Mgr
    SD2 --> Output[最終回饋/指令]
    Output -->|更新狀態| DB_S
    Output -->|背景存檔| DB_Log

    %% 備註節點
    Note1[EdgeMoE技術: 僅將當前災難專家權重載入RAM]
    Note2[EdgeLLM技術: 大小模型協同 降低延遲]

    %% 應用樣式
    style Disk_Storage fill:#e1f5fe,stroke:#01579b,stroke-width:2px
    style RAM_Memory fill:#fff9c4,stroke:#fbc02d,stroke-width:2px,stroke-dasharray: 5 5
    style Inference_Engine fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px
    
    class DB_R,DB_Experts,DB_Log storage;
    class DB_U,DB_S,Draft_Model,Active_Expert memory;
    class Task_Mgr,SD1,SD2 core;
    class Note1,Note2 optimization;

1. 個人化資訊的「隱形注入」
技術實作： 在 Query 重寫/擴充 階段，系統會自動查詢 DB_U。

範例邏輯： * 使用者輸入：「我現在被煙困住了」。

系統重寫為：「[使用者住高樓層] [家中有幼童] [已知逃生口受阻] 尋找高樓層防煙與幼童保護策略」。

2. 狀態推進 (Progression) 的閉環設計
演練推進： 當使用者完成一個動作（如：躲到桌子下），狀態更新代理 會將 DB_S 的狀態從 Stage_1_Cover 更新為 Stage_2_Evacuate，並驅動 演練推進器 產出下一個情境（如：地震停了，請檢查瓦斯）。

真實環境推進： 系統會追蹤災情演變。若使用者回報「火勢變大」，系統會在狀態庫標記威脅等級提升，並連動 行動指揮模組 給予更緊急的撤離路徑。

#### 情境推理 mealy mechine

stateDiagram
    direction TB

    [*] --> Idle
    
    Idle --> Context_Analysis : 啟動程式/載入個人資訊
    
    Context_Analysis --> In_Drill : 模式選擇=演練/初始化情境
    Context_Analysis --> Emergency_Response : 模式選擇=真實/啟動應變邏輯
    
    state In_Drill {
        [*] --> Task_Active
        Task_Active --> Task_Active : 輸入回答/RAG評估與推進
        Task_Active --> Drill_Success : 任務完成/生成評分報告
    }
    
    state Emergency_Response {
        [*] --> High_Alert
        High_Alert --> High_Alert : 災情更新/動態避難引導
        High_Alert --> Safe_Status : 到達安全區/後續建議
    }

    In_Drill --> Emergency_Response : 偵測真實威脅/強制模式切換
    
    Drill_Success --> Idle : 結束演練/儲存紀錄
    Safe_Status --> Idle : 離線存檔/系統待機

本系統採用 Mealy Machine 邏輯設計核心代理程式，確保輸出指令不僅取決於當下的災難資訊（Input），更深度整合了預先存儲於本地端的個人背景資訊與目前的事件進度（Current State）。這種設計能有效避免離線模型（SLM）在複雜情境下產生邏輯斷層，確保防災指導的連貫性與精準度。

#### agentic RAG 建議

🔬 研究方法：進階代理式 RAG 演練系統實作
本計畫之核心目標在於建構一個具備「主動引導」與「即時評估」能力的離線防災演練系統。不同於傳統被動式檢索問答，本研究採用 代理式架構 (Agentic Architecture)，將系統拆解為多個協作代理（Agents），以實現動態情境對話。

1. 演練狀態管理器 (Scenario State Manager)
系統將維護一個動態的「演練狀態機」，負責記錄目前演練的進度、使用者已完成的避難動作以及剩餘的模擬變數。

情境觸發邏輯：根據離線知識庫中的災難階段（如：震時、震後初期、搜救階段），主動生成具備緊迫感的情境描述。

變數管理：動態調整環境參數（如：通訊中斷、建築受損、火警發生），測試使用者在多變環境下的應變韌性。

2. 多重代理評估架構 (Multi-agent Evaluation System)
為確保演練的專業性與安全性，本研究設計了雙層評估機制：

分析代理 (Analysis Agent)：負責將使用者的自然語言回覆進行語義拆解，轉化為具體的避難行動指標。

評估代理 (Critic Agent)：對比「離線口袋知識庫」中的標準作業程序（SOP），判斷使用者的回答是否符合防災邏輯。若出現致命錯誤（如：火災時搭電梯），系統將立即切換至優先指導模式。

3. RAG 導向的即時修正迴圈 (RAG-driven Feedback Loop)
當使用者在演練中表現不佳時，系統不會直接給予答案，而是透過以下流程進行引導：

動態檢索優化：利用 Query Expansion 將使用者的錯誤回覆轉化為檢索關鍵字。

引導式反饋生成：從 RAPTOR 層級索引中提取核心原則，由 LLM 生成提示性（Hint-based）的指引，誘導使用者思考正確的避難路徑，從而強化其「防災韌性」。

4. 離線裝置優化技術 (On-device Optimization)
考量到災難現場的極端環境，本階段將實作以下技術以保證效能：

4-bit 量化與推論加速：利用 llama.cpp 框架對 Llama-3 或同級別模型進行量化，確保在行動裝置 CPU 上仍能維持低延遲的對話品質。

離線向量索引：使用 FAISS 輕量化版本，實現毫秒級的本地文檔檢索。

#### 模組
架構層次說明：
- 知識獲取層 (Knowledge Acquisition)： 抓取歷史災害紀錄與即時新聞，轉化為結構化的 Markdown 或 JSON。
- 離線索引層 (Offline Indexing)： 使用 Embedding 模型將資料向量化，存儲於手機端的小型向量資料庫。
- 推論與生成層 (Inference Engine)： 結合 RAG 檢索出的 Context 進行生成。
- 評估模組 (Evaluation Module)：

演練情境示意圖:
- 推播導入： 系統模擬突發新聞（如：震度 5 強地震），或是使用者選擇一個感興趣的歷史災難。
- 角色對話： AI 扮演指揮官或受困者，詢問「你現在第一步要做什麼？」之類的問題，後續根據對話以及。
- 即時引導： RAG 從口袋知識庫提取正確的避難知識，指引使用者。
- 心理強化： 結合 GSE 量表題目，引導使用者確認自己的決策，提升效能感。

### "Pocket GPT: A Lightweight Generative AI-Based Real-Time Language Learning Platform for Enhanced Multilingual Proficiency" (2026)
它解決了在低資源設備（如手機）上**運行即時、具備同理心**的 AI 對話系統的難題
- 低資源消耗、強大的上下文理解
- 1.4. Techniques used to develop P-GPT
- Pocket GPT 的其中一個主要優勢，是使用一個帶遮罩的卷積神經網絡（CNN）層，並結合一個稱為 LeBERT 的輕量化 BERT 模型
- LeBERT 負責深層的語意分析，而 Masked CNN 層則進一步提升了處理效率與辨識準確率，確保系統能在行動裝置上實現**即時（Real-time）**的回饋。
- 此外，使用具遮罩的 CNN 層可透過讓系統聚焦於對提供語言學習有用回饋至關重要的特定文本片段，從而提升情境知識。
- 利用這些有效技術，該應用程式提供了一個積極的學習環境，將傳統的師生互動與高效的現代技術相結合。允許在所有相容性較差的裝置上使用人工智慧工具，旨在讓語言學習更加便捷，並激發用戶的參與度、積極性和自信心。
- 3.1.1. Hardware implementation
- 此應用程式將依賴無線網路連線進行雲端運算。不過，它仍會在網路連線受限的地區提供離線功能，並保證使用者能夠持續存取其各項功能。
- 3.2 Sources to construct the P-GPT app
- OpenAI GPT 系列和 RedPajama-INCITE-Chat-3B-v1 模型構成核心平台；兩者都以其高效的記憶體使用和對行動平台的靈活性而聞名。量化技術（例如先前討論過的 4 位元整數模型量化技術）有助於減少記憶體備份所需的運算量，並使裝置在 4GB 記憶體下也能運作良好。彈性大型語言模型 (ELMS) 的優勢在於它們可以調整行動裝置資源，並提高即時處理能力。Native mobile integration是透過使用 Android NDK 進行底層處理來實現的。
- 開放詞彙語意分割旨在根據一系列類別（即使是訓練過程中未遇到的類別）對照片影像中的物件進行標註和分離。擴散模型是一種生成模型，它透過不斷改進隨機噪聲，使其產生合理的結果，從而處理如何產生資料（例如圖像和動畫）。傳統的訊息傳遞架構僅針對鄰域聚合，並且傾向於考慮同質性，這會降低在異質圖上的效能。互動模型旨在實現人機之間的即時通信，例如為機器建議提供視覺或語音解釋。定義對話中人們的情緒狀態（例如快樂、悲傷、憤怒和中性）的任務也需要用到。
- 3.3 software implementation(LeBERT procedures)
- BERT 模型在與使用者進行對話互動時會產生高維向量，但無法收集情緒資訊。整合情緒詞典(sentiment lexicons)和 N-gram 表明，輕量級的 LeBERT 模型支持降低向量維度，這也有助於改進行動端實現模型。為了增強所提出的 P-GPT 中的語言訓練交互，LeBERT 模型有效地結合了 N-gram(文字預處理，切割句子)、情感詞典(辨識那些section中包含情緒字眼)和傳統的 BERT 能力。這有助於快速理解文本或交互，這在語言學習環境中至關重要。

互動流程是透過一個「感應-決策-生成」的迴路完成的，具體步驟如下：
1. 語意解析 (LeBERT 階段)： 系統接收使用者（學習者）的輸入後，先由 LeBERT 進行意圖識別與槽位填充（Slot Filling）。它會判斷使用者是在「提問」、「練習對話」還是「請求糾錯」。
2. 情境動態檢索 (RAG 觸發)： 這是流程中最重要的轉折點。系統會根據 LeBERT 提取的關鍵字，去檢索資料庫中的教學規範或語法知識。
3. 生成對策 (Generative Core)： 輕量化的生成模型（如論文提到的 GPT 變體）結合了使用者的輸入以及 RAG 檢索到的「正確範例」，產出具備教學意義的對話。
4. 即時過濾與修整 (Masked CNN)： 最終生成的文本會經過一個 Masked CNN 層，檢查是否有語法錯誤或不符合該語言等級（如 A1-C2）的生澀詞彙，確保輸出內容適合學習者。
- 似乎只有文字輸入

---

- 技術：量化（Quantization）後的輕量級模型（如 Llama-3-8B-Instruct 的 4-bit 版本或 Google Gemma）。

## 論文檢索
{%preview https://webii.lib.fcu.edu.tw/libnews/post/13629 %}
[sci-hub](https://pismin.com/)
[webofscience](https://web.lib.fcu.edu.tw/library/resources/guides/wos_scie.html)

[chrome 內建 AI 挑戰賽](https://developer.chrome.com/blog/ai-challenge-winners-2025?hl=zh-tw)

## 創意與技術選型
- 基礎層 (Infrastructure Layer) - Trustworthy Edge Intelligence
強調斷網可用性 (Reliability) 與 隱私保護 (Privacy)，因為災難時網路不穩，且心理數據不應外洩。

- edge intelligence，讓 ai 模型可以離線運作
- SLM (Small Language Models)
- "Quantization" (量化)
- 硬體存取 NDK、SDK 存取 npu
- 邊緣計算框架（如 TensorFlow Lite 或 OpenVINO）?
- 2025-Empowering large language models to edge intelligence A survey of edge efficient LLMs and techniques.
- 可解釋性 (Explainability, XAI) 在邊緣端的挑戰與研究
- [《A Survey on Trustworthy Edge Intelligence: From Security and Reliability to Transparency and Sustainability》](https://arxiv.org/html/2310.17944v2)(IEEE Communications Surveys & Tutorials, 2024/2025)： 這是目前最全面的綜述，定義了可信任邊緣智能的五大維度：安全性、隱私、可靠性、可解釋性與可持續性。它詳細列出了目前 100 多篇相關論文的分類。
- 應用在感情運算上[Exploring Interpretability in Deep Learning for Affective Computing: A Comprehensive Review](https://dl.acm.org/doi/10.1145/3723005)
- 多模態 RAG (Multimodal RAG)
- 應用於確認災難應對指導的恰當
- 應用於情感運算(effective computing)[EmoVerse: Exploring Multimodal Large Language Models for Sentiment and Emotion Understanding](https://arxiv.org/html/2412.08049v3)
- 結合 XAI 的 Agentic RAG
- 用於提供災難準備輔導以及認知、心理輔導?
- 2025 年 11 月發表的 [KA-RAG: Integrating Knowledge Graphs and Agentic RAG](https://www.mdpi.com/2076-3417/15/23/12547) 展示了： 當使用者問「為什麼？」時，系統不僅給出文字，還能畫出推理路徑圖（例如：A 實體與 B 實體在圖譜中的關係），這被證明在教育領域能提升 30% 的學習效率。
- [Explainable AI for Audio and Visual Affective Computing: A Scoping Review](https://ieeexplore.ieee.org/document/10766406)

- System Prompting
- Human-Centered Computing (HCC)

### 手機端 Edge AI 實作：作業系統與硬體差異
#### 作業系統層級差異 (OS Level)
特性 | Android | iOS
--- | --- | ---
|部署框架 | TensorFlow Lite (TFLite) (最主流), PyTorch Mobile (急追), MediaPipe (適合圖形/多媒體)。 | Core ML (Apple 專用，最佳化極好)。通常需將 PyTorch/TF 模型轉換為 .mlpackage。
|硬體抽象層 | NNAPI (Neural Networks API)：Google 試圖統一不同晶片的介面，但碎片化嚴重。現在趨勢是廠商直接提供 SDK (如 Samsung ENNSDK)。 | Core ML：自動調度 CPU, GPU (Metal), 和 NPU (Apple Neural Engine)，開發者不需手動管理底層。
|系統級模型 | AICore / Gemini Nano：Pixel 和部分旗艦機（如 Samsung S24）內建，App 可透過 API 呼叫系統常駐的 SLM，省記憶體但靈活性較低。 | Apple Intelligence：整合於系統層，第三方 App 存取權限目前較為封閉，通常仍需自帶模型。

#### 硬體層級差異 (Hardware Level)
- Qualcomm Snapdragon (Android):
- 核心是 Hexagon DSP/NPU。
- 使用 SNPE (Snapdragon Neural Processing Engine) 或 QNN SDK 進行量化（Quantization）與部署。
- 差異點： 對 INT8 量化支援極佳，但在浮點運算（FP16/FP32）上效率不如 INT8。
- MediaTek Dimensity (Android):
- 核心是 APU (AI Processing Unit)。
- 使用 NeuroPilot SDK。
- 差異點： 在中低階機種的普及率高，但開發者文檔相對較少。
- Apple Silicon (iOS):
- 核心是 Apple Neural Engine (ANE)。
- 差異點： 封閉但極度高效。Core ML 會自動將支援的運算層（Layers）丟給 ANE，不支援的丟給 GPU。ANE 偏好特定的 Tensor 格式（如 channel-last），對 Transformer 架構的支援在近年才大幅改善。

撰寫研究計畫時，除了抄襲這種千萬不能犯的錯之外，
還有三大常見地雷要注意：

❶ 方向過於發散

主題太廣，讓教授看不出你的研究重點。
✅ 解法：聚焦在一個具體問題，鎖定核心議題。

 ❷ 可行性不足

構想很創新，但資源或時間不符實際，會被質疑「做不到」。
✅ 解法：評估方法與資源，列出清晰步驟與進度表。

 ❸ 缺乏個人特色

計畫寫得太模板化，教授看過就忘。
✅ 解法：加入自己的背景、興趣或經歷，展現獨特視角。

 ⭐ 如何讓研究計畫更有亮點

1️⃣ 展現契合度：讓計畫貼合教授研究方向。
2️⃣ 主題具體化：標題明確，教授一眼就懂。
3️⃣ 引用文獻：引用學術期刊，展現你的研究基礎。
4️⃣ 強調價值：同時凸顯學術意義與實務應用。

## 預想問題
現今的 edge ai 可能沒辦法處理複雜問題，針對防災方面的問題，可以將大問題切分成簡單問題

## 研究方法與步驟

## 參考資料
{%preview https://apkpure.com/%E5%A1%8A%E9%99%B6%E5%95%8A-%E3%80%8C%E8%87%BA%E7%81%A3%E9%81%BF%E9%9B%A3%E6%89%80%E6%90%9C%E5%B0%8B%E3%80%8D/tw.evacuation.places %}
{%preview https://www.books.com.tw/products/0011009401 %}
{%preview https://prepare.mnd.gov.tw/ %}
{%preview https://hackmd.io/YrvSlJwyQSy6w77s2coQ1w?view %}
{%preview https://huggingface.co/ %}
[Explainable AI — 可解釋人工智慧](https://medium.com/%E5%AD%B8%E4%BB%A5%E5%BB%A3%E6%89%8D/explainable-ai-%E5%8F%AF%E8%A7%A3%E9%87%8B%E4%BA%BA%E5%B7%A5%E6%99%BA%E6%85%A7-caf3215fae50)

---
## 研究目標與方向範例
- 研究目標

開發專案 - 實際問題解決與應用
這個系統能解決什麼現有技術無法處理的問題
針對 [特定情境] 下的 [具體問題]，利用 [關鍵技術]，達成 [量化指標或質性改善]。」

具體性： 不要只說「改善交通」，要說「縮短尖峰時段救護車在特定路口的等待時間」。
必要性： 為什麼現在的方法不好？（例如：現有演算法運算量太大，無法在手機端即時執行）。
分層設定： 建議設定 2-3 個子目標，由淺入深。

- 研究方法

1. 技術架構（Technical Framework）： 繪製系統架構圖，說明各個模組（例如資料擷取層、核心演算法層、輸出介面層）如何互動。

2. 資料處理策略： 說明資料來源（Open Data、實驗收集或模擬生成）。如果是應用型，資料的品質與標註方法通常是研究的難點。

3. 核心演算法/模型設計： 不要只寫「使用 CNN」，要寫「預計調整 CNN 的哪幾層結構，以適應低解析度的影像特徵」。

4. 驗證與評估方法： 這是「研究」與「作業」的分水嶺。你需要設計實驗來驗證有效性，例如：
    對照組（Baseline）： 與現有的成熟技術進行比較。
    消融實驗（Ablation Study）： 證明你加入的某個新功能確實起到了作用。

- 預期結果
`
預期成果必須與研究目標呼應，通常分為「技術指標」與「應用價值」。`

| 類別 |內容描述 |範例
| --- | --- | ---
量化指標| 實驗數據的具體表現 |「模型準確率預期達到 90% 以上，且推論時間小於 100ms。」
具體產出| 實體化的成果 |「開發出一套原型系統（Prototype）、撰寫 1 篇學術論文。」
社會/應用價值 |解決問題後的實質幫助| 「降低災害發生時的通報延遲，提升搜救效率。」
學習成長| 對申請人（學生）的影響| 「掌握深度學習框架與分散式系統的整合能力。」

1. 邊緣智慧與行動 LLM 的部署挑戰 隨著大型語言模型 (LLM) 在自然語言處理任務中展現卓越性能，將其從雲端遷移至邊緣裝置（如智慧型手機）已成為實現「邊緣通用智慧 (Edge General Intelligence, EGI)」的關鍵趨勢。Chen et al. (2025) 指出，這種遷移不僅能解決雲端推論的高延遲與頻寬消耗問題，更能確保敏感數據（如個人健康資訊、位置）在本地端處理，從而大幅提升隱私安全性。然而，行動裝置受限於記憶體容量、計算能力與電池續航，這使得直接部署大規模參數模型面臨嚴峻挑戰。Wang et al. (2025) 的調查研究強調，為了解決這些資源限制，當前的研究主要集中在開發小型語言模型 (SLMs)、模型壓縮技術（如量化、剪枝）以及推論優化策略上。此外，Dantas et al. (2025) 回顧了最先進的模型壓縮技術，指出透過知識蒸餾 (Knowledge Distillation) 與神經架構搜索 (NAS)，可以在維持模型性能的同時顯著降低硬體需求，這為離線 RAG 系統在手機上的運行提供了基礎可行性。

2. 離線推論加速與記憶體優化技術 為了在有限的硬體資源下實現流暢的離線對話體驗，推論加速技術至關重要。Xu et al. (2025) 提出了「EdgeLLM」系統，該系統利用投機解碼 (Speculative Decoding) 技術，透過一個駐留在記憶體中的小型草稿模型 (Draft model) 快速生成 token，再由大模型進行驗證，這種方法能有效解決記憶體頻寬瓶頸，大幅提升生成速度。針對記憶體管理問題，Yi et al. (2025) 開發了「EdgeMoE」引擎，專為混合專家模型 (Mixture-of-Experts, MoE) 設計。該技術將不常使用的專家權重儲存在存儲設備中，僅在需要時加載至記憶體，這種基於稀疏性 (Sparsity) 的運算模式與 RAG 的檢索邏輯高度契合，能以極低的記憶體佔用運行大規模模型。

%%{init: {
  'theme': 'base',
  'themeVariables': {
    'fontSize': '20px',
    'fontFamily': 'Arial, "Microsoft JhengHei"',
    'primaryColor': '#ffffff',
    'edgeLabelBackground':'#ffffff',
    'tertiaryColor': '#f9f9f9'
  }
}}%%
graph TD
    %% 階段一：準備與篩選
    subgraph Phase1 [準備與篩選階段]
        E[招募受測者]
        E --> F1[實驗組: Edge RAG App]
        E --> F2[對照組: 靜態 PDF 手冊]
        
        subgraph ExpGroup [實驗組核心邏輯]
            F1 --> F1_3[即時回饋與評比系統]
        end
        
        subgraph ConGroup [對照組邏輯]
            F2 --> F2_1[自主閱讀官方防災教材]
        end
    end

    %% 階段三：高壓測試與評估
    subgraph Phase3 [壓力測試與後測 T2]
        F1_3 & F2_1 --> G[模擬高壓環境測試]
        G[模擬高壓環境測試] --> G3[執行複合式生存任務演練]
    end

    %% 階段四：數據分析
    subgraph Phase4 [數據採集與成效分析]
        G3 --> H[數據採集指標]
    end

    %% 套用樣式
    class D1 highLight;
    class E stress;
    class E1,E2 danger;
    class A,B,D2,F,G standard;
    class Phase1,Phase2,Phase3,Phase4 groupStyle;

graph TB
    subgraph User_Interface [應用層：使用者交互介面]
        A1[災前演練模式 - Drill Mode]
        A2[災時指引模式 - Emergency Mode]
    end

    subgraph Edge_Intelligence_Engine [運算層：邊緣推論引擎]
        direction TB
        B1[自適應檢索器 Adaptive RAG]
        
        subgraph Inference_Optimization [推論優化技術]
            B2[EdgeMoE 動態專家載入]
            B3[Speculative Decoding 推測解碼]
        end
        
        B4[Edge-SLM 核心模型]
    end

    subgraph Foundation_Layer [基礎層：本地數據與知識庫]
        C1[(本地向量資料庫 Vector DB)]
        C2[(防災士教導手冊 / 法規)]
        C3[(隱私敏感數據: GPS, 健康紀錄)]
    end

    %% 數據流向
    C2 -->|嵌入化 Embedding| C1
    C1 <-->|語義檢索| B1
    C3 -->|內容增強| B1
    
    B1 --> B4
    B2 -.->|記憶體優化| B4
    B3 -.->|加速推論| B4
    
    B4 -->|生成虛擬情境| A1
    B4 -->|提供 SOP 指引| A2

    %% 標註邊界
    style Foundation_Layer fill:#f9f,stroke:#333,stroke-width:2px
    style Edge_Intelligence_Engine fill:#bbf,stroke:#333,stroke-width:2px
    style User_Interface fill:#bfb,stroke:#333,stroke-width:2px

graph LR
    %% 全域樣式定義
    classDef academic fill:#ffffff,stroke:#000000,stroke-width:1.5px,color:#000000,font-family:serif;

    %% 定義節點 (長方形內容)
    CE["<b>具體體驗 (CE)</b><br/>參與高擬真虛擬情境演練<br/>(SLM 生成之災害對話場景)"] 
    RO["<b>反思觀察 (RO)</b><br/>系統評比與教學反饋<br/>(針對使用者應變進行分析)"]
    AC["<b>抽象概念化 (AC)</b><br/>內化防災知識與韌性思維<br/>(結合 RAG 知識庫之建議)"]
    AE["<b>主動實驗 (AE)</b><br/>將技能應用於災時指引<br/>(提升實際災害反應能力)"]

    %% 建立橫向循環
    CE --> RO
    RO --> AC
    AC --> AE
    
    %% 回饋線 (讓循環閉合)
    AE -.->|"循環迭代與經驗遷移"| CE

    %% 應用樣式
    class CE,RO,AC,AE academic;

    %% 加上外框標註
    subgraph "防災 Edge Intelligence：基於 ELC 之學習路徑圖"
        direction LR
        CE
        RO
        AC
        AE
    end

gantt
    title 研究進度規畫表
    dateFormat  YYYY-MM-DD
    axisFormat  %Y/%m
    
    section 研究流程
    確認研究問題           :active, a1, 2025-12-21, 2026-02-11
    資料收集與整理       :a2, 2026-02-12, 2026-04-28
    系統分析               :a3, 2026-04-29, 2026-07-30
    裝置開發               :a4, 2026-07-31, 2027-01-20
    進行實驗               :a5, 2027-01-21, 2027-02-19
    整理實驗結果資料       :a6, 2027-02-20, 2027-02-27
    撰寫結果報告           :a7, 2027-02-28, 2027-03-15