Wiki
Longev AI 如何學習：規則、數據與預測驗證
Longev AI 的核心是建立在房客個人基準線之上的可解釋臨床規則，平台在此基礎上累積«干預 → 反應»數據對，並公開衡量自身的預測誤差。
Updated 2026-08-28 · Sample procedures Luxury Spa & Medical Wellness Hotel Prezident
Contents
- 重點摘要
- 採用規則而非黑盒子——原因何在
- 以個人基準線取代大眾常模
- 引擎架構分層
- PMS 所沒有的兩組資料集
- 預測驗證：以誤差代替承諾
- 發展藍圖
- 常見問題
- 資料來源
- 相關主題
重點摘要
- 本頁面向的對象。 技術審核人員、醫師與投資人——所有詢問«這是機器學習還是固定規則？»的人。答案坦誠透明，且可在入口網站中親自驗證。
- 核心是規則，這是有意為之的選擇。 每項建議均源自明確命名的閾值，並能以一句話解釋清楚；收費理療項目僅限醫師調整。在醫療流程中，沒有人會為黑盒子簽名負責。
- 個人化取決於自身基準線。 異常標記並非對照«大眾常模»判定，而是與房客本人入住期間的平均值比較：靜息心率 62 毫無意義，除非你知道他整週的數值都是 54。
- 兩組數據集。 決策日誌——«房客數據 → 醫師處置»；結果日誌——«昨日理療與負荷 → 手錶今晨測得數據»。兩者在架構上均為匿名，並可匯出為 JSONL 行格式。
- 預測受到審核。 平台透過三種模型預測明天的靜息心率、HRV、Body Battery 與睡眠分數，並以表格形式列出每種模型的平均誤差——展示真實數據，而非空泛承諾。
- 邊界與定位。 Wellness & Lifestyle Intelligence 屬於生活方式支援系統，並非醫療器材；最終決定權始終在於醫師。更新於 2026 年 8 月 25 日。
採用規則而非黑盒子——原因何在
Longev AI 採用確定性引擎架構：在相同閾值下，相同的夜晚數據必然生成相同的報告清單。這並非平台羞於承認的限制，而是基於三大原因的工程決策。
第一是醫師簽名。晨間清單需經醫師簽署，上面的每一行都必須能回答«為什麼»：«靜息心率 68，高於您的平均值 61——建議替換高強度理療»。無法用具體數據解釋的建議，引擎絕不輸出。
第二是監管框架。若系統依據不透明的模型擅自變更醫療處方，就會偏向醫療器材並落入《歐盟人工智慧法案》（EU AI Act）的高風險系統範疇。平台刻意保持生活方式支援的定位：提出建議、給予解釋並等待醫師確認（法律框架）。
第三是冷啟動問題。沒有數據的可訓練模型比規則更不可靠：在昨天才加入的飯店中，模型根本無從學習。規則從第一位房客入住起即可運作——而平台從第一個早晨便開始累積模型所需的數據，詳見下文。
以個人基準線取代大眾常模
引擎中幾乎所有閾值都是將房客與其自身進行比較。基準線是房客本次入住期間的自身平均值：抵達當天的不完整數據不會計入；在測量天數不足 2 天之前，個人基準線標記完全不會觸發——僅與單一夜晚比較就如同擲硬幣，不能當作結論輸出。醫師可將此保護門檻提高至最多 5 天。
心率變異度（HRV——心跳間隔的不規則程度）還有第二個真實數據來源：Garmin 內建的 Firstbeat 演算法經過約 3 週學習所建立的房客個人區間。當比我們兩天基準線更了解房客的手錶判定為«低於區間»時，準備程度組件就絕不會顯示為綠色——手錶的判斷優先於我們的計算，且僅朝嚴格方向生效。
每日準備程度也是由這些數據匯總而成——數值介於 0 到 100 之間，類似於 Oura 智慧戒指的 Readiness 或 WHOOP 手環的 Recovery，但基於 Garmin 數據並依照飯店醫師設定的規則計算：Body Battery 佔 30 分，HRV 與睡眠各佔 25 分，靜息心率與昨日負荷各佔 10 分。缺少數據的組件不會以«群體平均值»敷衍替代——該組件直接剔除，其餘權重重新歸一化；當具備數據的權重不足一半時，系統將完全不給出判定區間。
醫師晨間清單：準備程度 49 分（滿分 100）及各項細項拆解——每一行都載有其具體數值、基準線及背後原因×引擎架構分層
PMS 所沒有的兩組資料集
飯店管理系統（PMS）可以串接 Garmin Health API 來接收脈搏與睡眠資料。但它缺少構成訓練資料集的兩個關鍵要素：醫師的處方以及飲食記錄。因此，平台累積了兩組資料集，而這兩組資料只存在於生物特徵、處方與營養共處於同一閉環的環境中。
- 決策日誌——«房客數值 → 醫師採取的處置»。儀表板中的每項臨床操作都會與該時刻房客的匿名快照一同記錄：年齡、性別、入住天數、夜間數值、個人平均值與標記。目前它已能作為提示功能運作：醫師能看到飯店過去在出現類似數值時採取了哪些措施。
- 成效日誌——«干預 → 反應»。每個有測量數據的早晨，平台會自動記錄一組配對資料：前一天的理療項目與負荷（包括 20:00 後的晚餐與飲泉療程杯數），對照手錶在早晨採集的數據——靜止脈搏與相對於個人基準的 HRV、睡眠、Body Battery、準備程度及標記。
- 匿名性與清除。 資料列中不包含姓名與出生日期；若撤回健康資料同意書，該房客的配對資料也會隨之刪除——這讓資料集更加真實透明，而非有所缺損。資料可從管理後台以 JSONL 格式逐行匯出。
- 觀察結果，而非因果關係。 儀表板會根據累積的配對資料顯示«有該因素／無該因素»的平均值：前一天的熱療、高強度理療、負荷超出基準 50%、深夜晚餐等。只有在雙方各有至少 5 組配對資料時才會顯示比較，且會標註為觀察結果：單一早晨的狀態背後有太多成因，不能單純將平均值的差異歸為因果關係。
預測驗證：以誤差代替承諾
面對«平台越來越精準»這句話，稽核人員完全有權要求以數據證明。為此，管理後台提供了預測驗證功能：平台會根據所有累積的歷史資料，回溯預測每個早晨的數據——靜止脈搏、HRV、Body Battery 與睡眠分數——並計算平均絕對誤差（MAE）：評估預測平均偏離了多少單位。
這項計算採用前向步進（walk-forward）方式——也就是«僅向前推進»：某個早晨的預測嚴格僅根據該日之前的資料建立，連負荷係數也只會依據截至當時已發生的配對資料進行學習。從設計架構上，就徹底杜絕了窺探未來或湊出答案的可能。
這張表格特意呈現了真實甚至不討喜的一面：在歷史資料量較少時，簡單的«同昨日»往往表現得比修正模型更好——這是正常的客觀結果，而非系統異常。未來模型的標準也正是由這張表格所確立：只有當模型在飯店的實際資料上能穩定超越基準模型時，才會被正式採用，而不是因為聽起來很厲害。
發展藍圖
- 目前階段。 基於個人基準數據建立規則；決策日誌與結果日誌自動累積增長；按一下按鈕即可測量預測誤差。
- 下一階段。 基於結果日誌建立預測模型——前提是累積了足夠的配對數據，能穩定超越上表的基準線。在此之前，展示介面上絕不使用任何誇大的«智慧»字眼。
- 始終如一。 自動開立處方僅作為草稿由醫師簽署確認：晨間便條目前正是如此運作，未來基於決策日誌的處方建議功能也將維持這一模式。
常見問題
- 這是機器學習還是固定規則？ 核心是基於房客個人基準數據且可解釋的規則。系統中已具備可學習的元素——例如預測中的負荷係數以及決策日誌中的相似案例搜尋——而完整的模型將在結果日誌成熟時導入，其品質目前已透過誤差表進行評估。
- 為什麼不用神經網絡？ 因為處方單是由醫師簽署，可解釋性是一項臨床硬性要求，而非個人偏好；同時歐盟人工智慧法案（EU AI Act）對不透明的健康建議監管遠比對明確規則嚴格；此外，缺乏足夠數據的模型表現不如規則，而平台目前仍在累積數據。
- 一般的飯店管理系統（PMS）為何無法做到這點？ Garmin Health API 可以提供生物特徵數據，但無法提供醫師處方與飲食記錄。«介入因素 → 反應»的數據對只有在所有三項數據流整合在同一個閉環系統中才能建立——而這筆數據集完全保留在飯店手中。
- 在哪裡可以查看這些內容？ 在控制台中：«設定» → «助理»——包含兩種日誌的卡片、影響因素觀察、預測檢查按鈕以及 JSONL 匯出功能（管理員畫面）。
- 平台是否宣稱具有因果關係？ 沒有。«有該因素 / 無該因素»的平均值均標註為觀察數據；因果推論需要單一飯店無法具備的龐大樣本量與嚴格研究設計——我們在頁面上坦誠說明這一點。
資料來源
相關主題
← All articles