揭開 AI 營養師背後的技術:DietMate 的多模態 AI 系統是如何運作的?

Key Takeaways

• DietMate 同時處理三種輸入：食物照片（影像）、血糖等生理數值（結構化）、病患自述（文字），三者合併才能給出有意義的營養建議
• 食物辨識目標準確率：單一食物 >90%、複雜餐點 >85%，支援 3,000 種以上台灣常見食物，辨識耗時 2–3 秒
• 四個 Agent 並非輪流「聊天」，而是各自專注在飲食分析、健康數值、建議生成、品質審核，最後合併輸出給營養師
• 人機協作不是口號：AI 建議送到營養師佇列後，審核時間從原本的 10–15 分鐘縮短至 2–3 分鐘，但簽核權始終在人手上
• 所有病患資料本地儲存，符合個資法與 GDPR；AI 決策過程留有完整稽核軌跡

這個系統要解決什麼問題？

讓我們從一個實際情境開始：一位第二型糖尿病患者拍了一張便當照片傳給 DietMate，同時系統已知他今天早上的血糖是 178 mg/dL、腎絲球過濾率（eGFR）在輕度下降的邊緣。

這三件事合在一起，代表他這頓飯的白飯份量需要減少、醬汁的鈉含量需要評估、蛋白質攝取量還要對照腎功能另行計算。任何一個維度單獨看都只是局部資訊；把影像辨識、生理數值、個案背景三者整合，才能給出對這個人有意義的建議。

這就是 DietMate 技術架構的出發點：不是「讓 AI 看懂食物」，而是「讓 AI 在正確的脈絡下判讀食物」。

三個核心技術問題，各自怎麼解

問題一：三種格式的輸入，如何同時處理？

病患資料天然是異質的。一張便當照片是非結構化影像、血糖數值是結構化表格、「我最近很容易餓」是自由文字。傳統單一模型難以同時對三種格式建立語意關聯。

DietMate 的做法是在 API Gateway 層就把輸入分流：

用戶介面（Web App / LINE Bot / 營養師後台）
        │
        ▼
  API Gateway（FastAPI + Cloudflare）
        │
   ┌────┴────┐
   │ 輸入路由 │
   └────┬────┘
   ┌────┼────────────┐
   ▼    ▼            ▼
影像  結構化數據   文字描述
辨識  整合模組    NLP 解析
   └────┬────────────┘
        ▼
   AI 處理引擎（多 Agent 協作）
        ▼
   數據儲存層（本地，不出境）

影像進影像辨識模組，血糖等生理數據進結構化整合模組，文字進語言模型的 NLP 解析。三條管道處理完成後，才交給 AI 處理引擎做合併分析。分流不是為了複雜化，而是讓每種模態用最適合它的方式預處理，避免雜訊互相干擾。

問題二：台灣食物的辨識準確率，怎麼做到的？

食物辨識是 DietMate 最容易被問到的技術點，也是最容易被誤解的一個。「AI 看食物照片」聽起來簡單，但食物辨識的難度遠比辨識人臉複雜——同一道菜在不同光線、角度、擺盤下外觀差異極大，份量估算更牽涉到三維空間的推算。

目前的目標指標：單一食物辨識率 >90%，複雜混合餐點 >85%，分析完成時間 2–3 秒。做到這個數字，需要幾個配合條件：

1. 在地化資料集

通用的國際食物資料集對台灣食物覆蓋率嚴重不足。魯肉飯、麻油雞、鹽水雞、蚵仔煎——這些食物不只是分類問題，連烹調方式不同（乾煎 vs. 水炒）都會影響油脂含量的估算。DietMate 建立並持續維護台灣本地食物資料庫，目前涵蓋超過 3,000 種台灣常見食物與料理方式，這是外部通用模型無法提供的。

2. 訓練資料的台灣飲食偏差修正

模型不只要認識「這是什麼」，還要正確估算「份量有多少」。份量估算透過視覺特徵（食物與容器的比例、食物堆疊層數）進行推算，這部分的誤差控制目標是 ±10% 以內。

3. 處理流程

上傳照片（JPG/PNG，最大 5MB）
  ↓
預處理：調整解析度、標準化色彩空間、增強對比度
  ↓
食物辨識：CNN 架構識別所有食物項目（支援多食物同框）
  ↓
份量估算：視覺特徵推算份量
  ↓
查詢本地食物資料庫 → 計算營養成分
  ↓
輸出：每道食物的熱量、蛋白質、碳水、脂肪、鈉等主要營養素

辨識結果不是最終輸出，而是交給下一層的多 Agent 系統進行進一步的脈絡分析。

問題三：如何避免 AI 的單一視角盲點？

這是 DietMate 架構中最費工設計的部分：用四個專門化 Agent，模擬不同專業角色的協作討論，而不是讓單一模型包辦所有判斷。

┌────────────────────────────────────────────┐
│           Multi-Agent 協作系統               │
├────────────────────────────────────────────┤
│                                            │
│  Agent 1：飲食分析                          │
│  ├─ 分析這頓餐點的巨量營養素組成            │
│  ├─ 識別營養不均衡（例：蛋白質偏低）        │
│  └─ 計算本日累計攝取比例                   │
│                                            │
│  Agent 2：健康數值整合                      │
│  ├─ 對照血糖、血壓、腎功能等生理數據        │
│  ├─ 評估本餐食物對當前生理狀態的影響        │
│  └─ 標記高風險營養問題（如：腎病患的磷鉀）  │
│                                            │
│  Agent 3：建議生成                          │
│  ├─ 根據 Agent 1+2 的分析生成具體建議       │
│  ├─ 考量台灣在地飲食文化與可取得的替代品    │
│  └─ 提供可執行的替代方案（而非空泛衛教）    │
│                                            │
│  Agent 4：品質審核                          │
│  ├─ 檢查三個 Agent 的建議是否邏輯一致       │
│  ├─ 確保符合醫療標準與法規                 │
│  └─ 過濾矛盾或潛在有害的建議              │
│                                            │
└────────────────┬───────────────────────────┘
                 ↓
         整合輸出：多 Agent 討論結果 + 結構化報告
                 ↓
         推送至營養師審核佇列

為什麼不用一個通用模型直接給建議？在 DietMate 開發初期，我們確實嘗試過單一 Agent 包辦的架構。問題很快就暴露了：面對「血糖偏高但同時有輕度腎功能下降」的患者，單一 Agent 容易在「控糖建議（增加蛋白質）」與「護腎建議（限制蛋白質）」之間來回矛盾，無法有效整合多個維度的衝突。

四 Agent 分工之後，Agent 1 先完整分析飲食，Agent 2 平行整合健康數值，Agent 3 拿到這兩份報告再生成建議，Agent 4 最後做一致性檢查。衝突在 Agent 4 被發現，而不是直接輸出給病患。

人機協作的實際流程

「AI 輔助而非取代」說起來容易，實作起來需要把這個原則轉化成具體的工作流設計。

1. AI 生成初步建議（約 5–10 秒）
   ↓
2. 自動推送至營養師審核佇列

3. 營養師開啟案件，看到：
   ├─ 食物辨識結果（含信心分數）
   ├─ 各 Agent 的分析過程（可展開查看推理步驟）
   ├─ 整合後的初步建議
   └─ 病患歷史紀錄與生理數值摘要

4. 營養師審核與處置：
   ├─ ✅ 確認正確 → 一鍵發送給病患
   ├─ ✏️ 需要調整 → 直接在介面修改後發送
   └─ ❌ 發現重大問題 → 退回重新分析，並留下標記供模型學習

5. 所有審核動作完整記錄，包含：
   ├─ 誰審核、何時審核
   ├─ 修改了什麼
   └─ 最終發送的版本

這個流程帶來的實際效果是：審核時間從原來的 10–15 分鐘降到 2–3 分鐘，但營養師的「最終簽核」這個步驟沒有被省掉。速度的提升來自 AI 把準備工作做完，而不是跳過判斷。

語言模型在架構中的角色

除了影像辨識和多 Agent 協作，DietMate 還整合了大型語言模型（LLM）負責三個具體任務：

自然語言理解：解析病患用口語說的「我最近很容易餓，飯後兩小時就想再吃東西」這類描述，判斷其中可能暗示的血糖波動模式或胃排空問題。

報告結構化：把 AI 分析結果轉成醫療機構可用的格式——不是 JSON 或程式碼，而是營養師後台能直接閱讀、帶有清晰結構的評估摘要，包含問題點、建議事項、追蹤指標。

對話式互動：當病患用 LINE Bot 詢問「我可以吃蛋黃嗎？」，LLM 根據該病患的個案脈絡（腎功能、膽固醇、用藥史）生成對應的回應，而不是給通用的衛教答案。

合規與資安的設計選擇

DietMate 在架構層面做了幾個選擇，不是技術最優化，但是在醫療場景下非這樣做不可：

「可解釋性」在這裡不只是技術名詞，而是法律必要條件。當一份建議被審核人員或主管機關詢問「AI 為什麼這樣建議？」，系統必須能回答，而不是說「模型就是這樣輸出的」。

從架構回到臨床現實

DietMate 的技術架構不是從工程角度往外推的——它是從「一位診所院長要怎麼對病患負責」這個問題往裡收的。多模態輸入是因為病患資料天然異質；多 Agent 是因為複雜病況需要交叉驗證；人機協作是因為 AI 的法律地位目前還不能獨立簽核醫療建議。

技術的選擇永遠服從臨床的需求，而不是反過來。

想了解 DietMate 如何整合進診所工作流？歡迎查看 DietMate 產品介紹，或直接聯絡我們討論你的場景。