维基
Longev AI 如何学习：规则、数据与预测验证
Longev AI 的核心是建立在客人个人基线之上的可解释临床规则。平台在此基础上积累«干预→响应»数据对，并公开测量自身的预测误差。
Updated 2026-08-28 · Sample procedures Luxury Spa & Medical Wellness Hotel Prezident
Contents
- 简要概述
- 采用规则而非黑箱——以及背后的原因
- 以个人基线取代人群常模
- 引擎架构分层
- PMS系统所没有的两组数据集
- 预测检验：用误差说话，而非口头承诺
- 路线图
- 常见问题
- 来源
- 相关主题
简要概述
- 适用对象。 技术审查人员、医生和投资者——即所有想了解«这是机器学习还是固定规则？»的人。答案是坦诚的，并且可以直接在门户中核实。
- 核心是规则，这是我们的主动选择。 每条建议都源自明确的阈值，并能用一句话解释清楚；付费理疗项目只能由医生调整。在医疗闭环中，没有人会为黑箱签字确认。
- 个性化源于个人基线。 异常标记不是对照«人群常模»，而是对照客人本次入住期间的自身平均值：如果不了解某位客人整周的静息心率都是 54，那么 62 的静息心率就没有任何参考意义。
- 两套数据集。 决策日志——«客人的数据→医生的处理方案»；结局日志——«昨日的理疗与负荷→手表今晨记录的数据»。两者在架构设计上均完全匿名，并可导出为 JSONL 行。
- 预测受到严格检验。 平台使用三种模型预测明天的静息心率、HRV、Body Battery 和睡眠评分，并以表格形式清晰列出每种模型的平均误差，而非空洞的承诺。
- 边界说明。 Wellness & Lifestyle Intelligence 属于生活方式支持系统，并非医疗器械；最终决定权始终在医生手中。更新于 25.08.2026。
采用规则而非黑箱——以及背后的原因
Longev AI 是一个确定性引擎：在相同的阈值下，相同的夜晚数据必然生成相同的表格。这并不是平台羞于承认的局限，而是基于三个原因的工程决策。
第一是医生的签字确认。晨间清单需要签字，上面的每一行都必须能够回答«为什么»：«静息心率 68，而您的平均值为 61——建议调换高负荷理疗项目»。无法用具体数字解释的建议绝不会打印出来。
第二是监管合规框架。依靠不透明模型擅自更改医疗医嘱的系统，会逐步滑向医疗器械以及欧洲《人工智能法案》（EU AI Act）的高风险等级。本平台审慎地保持生活方式支持系统的定位：提出建议、给出解释并等待医生确认（合规框架）。
第三是冷启动问题。缺乏训练数据的模型比规则更不可靠：对于昨天刚接入的酒店，模型没有任何学习材料。规则从第一位客人入住起就能正常运行，而未来模型所需的数据也会从第一个早晨开始积累，详见下文。
以个人基线取代人群常模
引擎中的几乎每个阈值都是将客人与自身进行比较。基线是客人本次入住期间的平均值：不完整的到达日数据严格排除在外；而在测量天数少于 2 天前，个人基线标记根本不会触发——仅根据单晚数据做出的比较无异于掷硬币，不能作为结论输出。医生可以将这一保护期提高至最长 5 天。
心率变异性（HRV——心跳间歇的不规则程度）有第二个基准参考：客人自身的基线范围，由 Garmin 内置的 Firstbeat 算法历经约三周学习得出。当了解客人时间远长于我们两天基线的手表显示«低于基线范围»时，状态就绪度组件绝不会显示为绿色——手表的判定权重高于我们的算术计算，且仅在单向起效。
这些数据共同构成了当日的就绪度——一个 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