为什么你的可穿戴设备需要收集数周的数据后才能真正发挥作用?
我还能清楚地记得第一次戴上Oura戒指,第二天早上查看自己的状态得分时的情景——那一刻,我觉得自己就像在查看考试成绩一样。 我看到得分大概是62分,顿时慌了神:难道是我生病了吗?还是压力太大了?又或者是睡眠姿势不对导致的? 但实际上,这些根本无关紧要,因为这款戒指根本不了解我的具体情况。它所掌握的关于我的信息仅仅是一晚上的数据而已。而我却把这些数据当成了绝对可靠的依据。 对于那些购买了智能手表或智能手环,却发现它们无法立刻了解自己的健康状况而感到失望的人来说,这款产品非常适合你们。事实上,在使用的第一周内,你们的可穿戴设备并没有出现故障,只是它还没有真正掌握你的健康数据而已。 目录 使用初期的
我还能清楚地记得第一次戴上Oura戒指,第二天早上查看自己的状态得分时的情景——那一刻,我觉得自己就像在查看考试成绩一样。
我看到得分大概是62分,顿时慌了神:难道是我生病了吗?还是压力太大了?又或者是睡眠姿势不对导致的?
但实际上,这些根本无关紧要,因为这款戒指根本不了解我的具体情况。它所掌握的关于我的信息仅仅是一晚上的数据而已。而我却把这些数据当成了绝对可靠的依据。
对于那些购买了智能手表或智能手环,却发现它们无法立刻了解自己的健康状况而感到失望的人来说,这款产品非常适合你们。事实上,在使用的第一周内,你们的可穿戴设备并没有出现故障,只是它还没有真正掌握你的健康数据而已。
目录
使用初期的数据基本上都毫无意义
无论是Oura、WHOOP、Ultrahuman还是Garmin,所有这些可穿戴设备都是基于这样一个假设来工作的:它们能够为你确定一个个人的“基准值”,也就是你的正常健康状态。这个基准值包括你在平常日子里的心率、心率变异性范围以及体温等数据。
问题在于,任何一项单独的数据都无法真正反映你的正常健康状况。这些数据只能显示你这一次测量的结果而已。对于你来说,45毫秒的心率变异性是偏低还是偏高呢?只有当设备再次检测到类似的数据时,它才能得出结论。
这就是为什么在使用新设备的第一周里,你看到的状态得分会显得有些随机的原因——这些数据实际上是在与你大致的平均值进行比较,甚至更糟糕的是,它们只是在猜测你的健康状况。
这里的“基准值”到底是什么意思
对于可穿戴设备来说,“基准值”并不是一个平均数,而是一个通过多天数据计算得出的动态范围,并且通常还会附带一个标准差区间。换句话说,你真正应该了解的是:“你的心率变异性通常在38到52之间,而今天的45毫秒完全属于正常范围内。”
正是这个范围才是我们所讨论的重点。如果没有这个范围,所有的数据也就没有任何意义了,因为根本没有什么可以与之进行比较的对象。
而且这不仅仅适用于心率变异性。你的静息心率、皮肤温度、呼吸频率,甚至夜间时的不安程度——所有这些指标都有自己的基准值,而这些基准值都是根据各自的特点,在不同的时间节点上独立计算得出的。
对于皮肤温度来说,所需的数据点数量最少,因为对绝大多数人而言,它的变化范围其实非常狭窄。而心率变异性则需要更多的数据点来作为参考,因为它会受到压力、酒精摄入量、运动强度、健康状况等多种因素的影响。
可穿戴设备是如何建立这些基准值的
在大多数消费级可穿戴设备中,都会使用一种指数加权移动平均算法,也就是EWMA,来逐渐建立起你的个人基准值。最近几晚收集的数据比早期收集的数据更重要,但也不会有任何数据被直接舍弃。
这种计算方法与传统的平均算法不同,它能够让你의基准值随着时间慢慢发生变化,从而真实反映你身体状况的变化——而不会因为某个异常夜晚的数据就破坏整个基准值的准确性。
例如,Oura公司明确表示,在计算皮肤温度时,他们会使用基于你近期数据得出的“滚动基准值”。因此,只有在你佩戴该设备一段时间后,那些显示温度变化的图表才会真正具有参考意义。WHOOP设备的运作方式也类似,它会先逐步建立心率变异性和静息心率的基准值,直到认为可以开始生成真正个性化的恢复状况评估结果为止。
其实这种计算方法背后的数学原理并不复杂,尽管听起来可能有些专业。任何一次新的测量数据都只会对基准值的形成产生微小的影响。一般来说,每天新数据所占的比例大概为10%,而剩下的90%则是由之前收集到的所有数据共同决定的。
这样一来,无论是某个糟糕的夜晚、一个良好的夜晚,还是由于传感器故障导致的异常数据,都不可能单独破坏已经建立起来的基准值。只有当多次测量的数据共同作用时,基准值才会发生变化。因此,建立这个基准值需要花费数周的时间,而不是几天——因为几天的数据根本无法改变之前积累下来的数据结果。
这就是整个机制的核心所在,但这也意味着,你最初得到的基准值其实只是一个初步的、不准确的估计值。
这种计算方法本质上就是所谓的“冷启动问题”——在推荐系统或其他需要利用历史数据才能产生有效结果的机器学习模型中,都会遇到这种情况。
在某些情况下,人们会故意将这一过程分为两个阶段来执行。在第一阶段,通常是在使用的最初两周内,你的评分会参照由数千名年龄或特征相似的用户的数据建立起来的通用模型来进行计算。当你的数据积累到一定数量后,系统会自动开始使用你自己的历史数据进行评估。这个转换过程是悄无声息发生的,人们只会发现自己的评分结果变得更加准确了。
为什么需要数周时间,而不是几天?
尽管有智能的权重计算系统,但也不可能在短短几天内收集到足够多样的数据。人的身体状态在三个晚上是无法发生所有正常变化的。因此,基线数据应该包括以下内容:
一个常规的工作日和一个睡眠质量较差的夜晚
一个休息日以及一个进行高强度锻炼的日子
日常状态与工作中压力较大的那一天
如果属于有月经周期的人群,最好能涵盖周期中的几个不同阶段,因为在这个过程中,心率变异性和体温会出现较大波动
这些数据显然不可能在72小时内收集齐全。因此,大多数可穿戴设备制造商都建议用户在实际使用前等待两到四周再解读检测结果。不过,这一点可能并不会在产品包装上被特别强调,因为“需要等一个月才能看到效果”这样的说法确实不太容易吸引消费者。
我就亲身经历过这种情况,尤其是在使用循环监测功能时。我的体温基线数据会根据我处于月经周期的哪一周而发生显著变化。如果算法仅依据卵泡期的数据进行计算,那么每个月的黄体期数据就会显示为“发烧”状态;但当收集到一两个完整的周期的数据后,这些偏差才会真正具有参考意义,而不会每隔三周就触发错误警报。
“冷启动问题”并非可穿戴设备所独有
推荐系统在面对新用户时也会遇到同样的问题。Netflix无法仅根据用户观看了一部电影就给出有意义的推荐;同样,可穿戴设备也无法仅凭一天的睡眠数据来提供有效的分析结果。
不过,这两种情况的解决方法其实非常相似。通常的做法是先依赖群体数据或一些通用设定,然后逐渐用个人数据来替代这些默认值,并且给予最近的行为更多的权重,因为人们的生活方式和身体状况会随时间发生变化。本质上,这就是同样的处理方式,只是表达方式不同而已。
因此,如果你正在开发与生物特征或行为数据相关的产品,那么从一开始就应当考虑到这一点,而不是在后期才去补充这些数据。当模型还几乎没有足够的数据作为参考时,应该向用户展示一个表示数据可靠性的指标,而不是一个看起来非常精确的数值。例如,无论是在第二天还是第六十天,得分为61都显得同样可信,尽管这两个分数之间存在差异,而且产生这种差异的原因也各不相同。在用户界面中如实反映这一差异,能够避免日后出现大量令人困惑的技术支持请求。
这对你来说意味着什么
如果你刚刚购买了一款新的可穿戴设备,这篇文章会对你有所帮助。以下是在第一个月里你应该如何使用它。
首先,在第一周内忽略你的每日检测数据。这些数据并非完全错误,只是它们所依据的信息实在太少。你可以把它们看作是一个不认识你的人对你的第一印象而已。
接下来,如果你的应用程序提供了这样的功能,那就记录下一些与你的生活相关的信息。可以添加诸如“饮酒”、“睡眠不足”、“旅行”、“生病”、“锻炼”等标签。算法越早了解关于你的各种信息,就越快能够掌握你的真实状况。
另外,至少需要等待两到三周才能评估这些结果的准确性。因为在这个时间段里,算法才会收集到足够多的信息,从而进行准确的分析,而不会只是凭猜测来得出结论。
如果你有记录月经周期的习惯,那么最好跟踪一两个完整的周期。否则,算法只能掌握你周期中的一部分信息,从而导致不准确的结果。这就是为什么有时候,在一个完全正常的周期中,人们仍会收到“黄体期准备不足”的提示的原因。
我仍然每天都会查看我的智能手环,但在最初的几周里,我并不会太把这些数据当回事。只有等到算法有足够的时间来了解我生活的方方面面,包括那些不顺利的时期之后,这些数据才会真正变得有用。在那个阶段之前,它并没有在欺骗你,只是还没有掌握足够的资料而已。
所以,下次当你使用全新的设备看到一些看似不合理甚至令人尴尬的结果时,请记住,它并不是在评判你。它只是掌握了非常有限的信息,正在尽力做出最好的分析。给它足够的时间,它会开始给出真实的数据,而不会只是凭猜测来预测结果。
相关文章
Flutter中的低功耗蓝牙技术:开发者手册
大多数Flutter教程都只涉及到网络调用和REST API。但一旦你需要与物理设备进行交互——比如心率监测器、智能灯泡、健身追踪器、工业传感器,或者你自己定制的硬件设备——你就不得不离开HTTP这个“舒适的环境”,转而使用蓝牙低功耗技术。 本指南会教你如何在Flutter中正确且全面地实现这些功能。 移动设备上的蓝牙功能其实相当复杂。Android和iOS之间的权限设置有所不同,即使是同一款Android系统的不同版本,权限要求也会存在差异。蓝牙连接的生命周期包含许多状态,服务与特征的数据模型也会让新手感到困惑,而字节级的数据编码方式几乎会让每个人在初次尝试时遇到麻烦。 flutter_bl
阅读全文
在React中处理高频实时数据:从环形缓冲区到离屏canvas技术
React在很多方面都表现得非常出色。但如果你曾经尝试过每秒向它传输数千个数据点,你就会很快意识到:React并不像一根能输送大量水流的消防水管,而更像是一根普通的花园浇水软管。 如果强迫它处理过多的数据,要么会导致“草坪被淹没”(即DOM结构变得混乱),要么会使得“管道爆裂”(也就是应用程序运行出现严重问题)。 还有另一个与上述观点相关的观察结果:你的笔记本电脑通常拥有8到16个CPU核心,而你的React应用程序几乎总是只使用其中的一个核心。主线程负责处理JavaScript代码、DOM操作、布局计算以及绘制工作;而其他核心则处于闲置状态,因为主线程实在难以维持每秒60帧的渲染速度。 这两
阅读全文
大规模产品实验:Airbnb、Netflix、Lyft和Uber是如何针对基于大语言模型的AI功能进行因果分析的
对于基于大语言模型的AI功能而言,因果推断已不再是理论上的概念。Airbnb、Netflix、Lyft和Uber都发布了详细的工程博客文章,详细说明了他们是如何衡量产品变更对用户行为的因果影响的。 他们所使用的技术方法(如差异分析法、回归不连续性分析以及双重稳健估计等)都是标准工具。 值得关注的是,这些团队是如何在大规模应用中运用这些技术的:在哪些情况下这些方法在实际操作中会失效,他们又是如何通过补充措施来确保估算结果的可靠性,以及他们是如何将这些数据与实际的产品决策联系起来的。 如果你正在开发基于大语言模型的功能,并且是根据用户点赞率和会话时长来做出产品决策的,那么这些文章一定会改变你对测量
阅读全文
人工智能评估工程:从零开始构建一款可用于生产环境的大型语言模型评估平台【完整使用手册】
一个令人印象深刻的演示与一个值得信赖的系统之间的差距,其实是通过各种评估来衡量的。 我想先讲一个目前正在数百个工程团队中发生的真实案例。 有一个团队为法律研究开发了一个RAG应用程序。他们用40个精心挑选的问题对该程序进行了测试,结果看起来很不错,于是便向合作方展示了这个系统。合作方对它印象深刻,随后便决定将其正式投入使用。 然而在系统投入生产三周后,一名法律助理发现其中一个答案错误地引用了某项法规。工程团队查看了相关数据,发现“准确性得分”为0.91,这个数值看起来是正常的;他们还检查了答案的相关性,结果也符合标准。 但他们忽略了一个重要的指标:即“上下文完整性”。这个指标用于判断系统是否检
阅读全文