本文摘编自我在 2017 年 10 月 2 日准备的演讲稿《我们如何用大数据解决健康问题》。页面日期沿用源文件最后编辑日期：2019 年 5 月 12 日。这里记录的是当时的数据与产品设计实践。

在好啦早期，我们想解决一个具体问题：面对有不同情况的用户，能否利用他们提供的信息，给出更有针对性的健康服务？

从算法角度看，这是分类与推荐问题。但产品真正做起来，困难并不只在算法。我们还要知道该收集什么、怎样让用户准确表达、数据不足时怎么办，以及如何把分析结果重新放回产品。

从用户的问题定义目标

当时，我常用一句话描述我们的出发点：我们都独一无二，却又十分相同。

仅仅知道一个类别名称，不足以说明两个用户的情况相同。我们希望进一步比较症状、年龄、生活习惯等信息，寻找更接近的人群。

但分组本身不是终点。用户关心的是接下来怎么办。因此，我们在设计数据分析任务时，先明确希望观察的结果，再决定采集哪些信息、怎样分组，以及如何呈现结果。

这也影响了界面设计。产品不只展示一个分类名称，还需要把相关信息组织成用户能理解、能继续使用的内容。

数据质量从问卷开始

我们当时把大数据工作分成两个部分：采集和分析。

采集不是把所有能接到的数据都收进来。不同系统对同一信息可能有不同的定义、格式和记录方式。对接、清洗和转换本身就需要大量工作。

自我汇报数据也有自己的问题：用户是否理解问题？选项是否覆盖了他的情况？相似的回答是否真的表达相同的意思？

因此，一份问卷要经过几轮工作：

1. 医学团队阅读相关资料，梳理需要了解的信息，形成结构化问题。
2. 团队与领域专家讨论，继续打磨问题和选项。
3. 产品团队把专业术语改写成普通用户可以理解的语言，同时保留准确的含义。

我在这个环节常问：“我妈能看懂吗？”这里的“我妈”指的是没有专业背景的普通用户。如果答案是看不懂，就还要改。

这项工作有时比算法开发更花时间。但如果输入的问题本身含糊，后面的分析就很难补救。

用专家知识处理冷启动

数据产品刚上线时，通常没有足够的历史数据。即使总体数据增加，也可能遇到某一类用户样本很少的情况。

我们当时把两种分类方式分别称为 type0 和 type1：

内部名称	含义	当时的产品用途
type0	依据已有领域知识与专家整理的分类	在没有数据、数据较少或无法匹配时，提供基础服务
type1	依据所采集数据形成的更细分组	在数据支持的范围内，组织更有针对性的结果

这些是我们内部的产品术语，不是通用的医学分类名称。

我们不要求系统从第一天起就完全依赖数据模型。先把专家知识整理成可以交付的服务，再逐步引入数据分析，是当时处理冷启动的路径。

让分析结果回到产品

当时的工作流程是一个反复进行的循环：

1. 产品上线，先提供基于 type0 的服务。
2. 用户使用产品，提交信息与反馈。
3. 数据团队清洗数据，进行分组与建模。
4. 开发团队把相应结果接入产品，提供基于 type1 的服务。
5. 数据团队根据分析中发现的问题，向产品团队提出问卷改进建议。
6. 产品团队修改问卷，再继续采集和分析。

这里，问卷、数据、模型和界面不是各做各的。分析结果会改变我们下一轮提出的问题，问题的改进又会影响后续数据的质量。

业务团队也在这个流程中。产品需要进入真实的服务场景，才会持续有人使用，才能积累后续分析需要的信息。

群体数据与个人时间序列

原稿还区分了两类数据。

一类是群体数据：很多用户在不同时间提交的信息。它帮助我们观察人群差异，寻找相近的特征和分组。

另一类是个人时间序列：同一个人在连续时间点上的记录。它让我们有机会观察一个人自身的变化，而不只是把他放进某个群体。

这两类数据回答的问题不同。群体数据提供比较的背景，个人时间序列提供变化的过程。在产品设计中，需要分别考虑它们的采集方式和用途。

算法之外的落地工作

我在当时的演讲里提到，机器学习相关的工具和开源类库会逐渐成为基础设施。但工具更容易获得，并不意味着产品问题已经解决。

这段实践中，算法之外的大量工作，集中在几个具体环节：明确用户的问题、组织专家知识、设计能获得有效回答的问卷、处理数据不足的情况，以及把分析结果接回实际服务。

对我而言，这也是数据产品落地最值得记录的部分：模型要放进一套能够持续运行和改进的工作流程里，才有机会产生实际价值。