Flo Health 开放模型更安全、更实用，但仍仅有 47% 同时通过两项测试
Flo Health 的开放模型在两项严格的内部基准测试中有所提升，但接受评估的回答中，只有 47% 同时符合医疗安全性和实用性标准。这家女性健康公司表示，其后训练系统将医疗安全性从 34% 提升至约 61%，实用性则从 42% 提升至 76%。
这些提升来自一套围绕合成问题、专门的 AI 评判器和由临床医生定义的评估规则构建的流程。随后，Flo 使用监督微调和直接偏好优化（Direct Preference Optimization，DPO），将偏好的行为模式写入开放模型的权重中。
根据 Databricks 于 2026 年 10 月 12 日发布的一项案例研究，这项工作之所以重要，是因为 Flo 的月活跃用户达到 8100 万。在这一规模下，即使错误率很低，也可能让大量用户接触到不完整、过度宽慰或令人困惑的健康信息。
这一结果也对健康导向生成式 AI 最简单的做法提出了挑战：将每个请求都交给前沿模型供应商，并依赖其通用安全层。Flo 押注于更小型、定制化的模型能够提供更强控制力和更低推理成本。更困难的问题在于，内部设计的基准是否能够在其创建环境之外证明安全性。
Flo 在训练模型前重建了评估系统
核心变化并非新的聊天机器人或基础模型。Flo 首先将临床判断转化为一套可重复执行的评估和训练系统。
Flo 的医疗、产品和工程团队将回答质量划分为两个主要目标。医疗安全性构成基础，而实用性衡量回答是否能为用户提供相关且易于理解的帮助。
这一差异听起来显而易见，但当模型面对模糊的健康问题时，情况并不简单。例如，有人询问月经为什么推迟。仅建议就医的回答或许避免了危险表述，但几乎无法提供即时背景信息。
反过来，另一种回答同样可能失败。模型可能列出压力、旅行、体重变化或运动等原因，却忽略怀孕或需要专业评估的疾病。这类回答感觉更实用，但其遗漏可能造成虚假的安心感。
因此，Flo 将安全性和实用性视为必须同时通过的独立维度。其最终框架包含 26 个 AI 评判器，即具有明确评分说明和参考案例的自动化评估器。
其中 12 个评判器负责执行医疗安全约束。6 个微型评判器检视更细化的行为，例如依据性、表述框架、语气和精细化安全要求。8 项实用性标准则评估完整性、相关性、连贯性和语气。
该公司还为反复出现的失败模式制定了规则。其中一项“原因平衡”规则要求：当良性原因和潜在严重原因都与问题相关时，回答必须覆盖两者。这一规则旨在解决对话模型容易生成听起来完整、实则过度宽慰的回答的问题。
Flo 表示，它使用合成案例和来自用户实验的匿名示例验证了这些评判器。当自动评判器与初始人工评估存在分歧时，由不知情的临床审阅者裁定该案例。
部分审阅案例用于优化评判器，其余案例则留作后续测量，从而降低只在校准时使用的示例上进行评估的风险。
这种评估优先的策略是所报告基准结果的基础。它也解释了为何该项目的重要性超出一次常规微调练习。
如果“安全”这个词始终只是宽泛的愿景，团队就无法可靠地提升安全性。Flo 必须先将这一愿景表达为可单独测试的行为，才能将其用作训练信号。
同样的原则也适用于医疗保健之外的领域。企业团队往往拥有大量领域知识，但这些知识分散在政策、专家决策、研究和运营例外中。支持知识融合的系统可以帮助整理此类材料，不过模型评估仍需要任务特定的测试和可追责的审阅者。
Flo 的设计形成了一项可复用资产。基础模型可能过时、改变许可证，或失去成本优势；而临床量表和评估案例可以迁移到下一代模型。
这种可迁移性构成了本文的核心张力。Flo 通过以自身标准取代通用供应商的安全假设来获得控制力，同时也承担起证明这些标准能在庞大且多样化用户群体中保持可靠的责任。
为什么 Flo Health 开放模型成为一项经济层面的押注
Flo Health 的开放模型不仅是一个安全项目，也是在尝试降低对成本高昂、由外部控制的模型 API 的依赖。
Flo 此前使用传统机器学习，并开始探索生成式 AI，以提供更灵活、更个性化的体验。单一通用模型可以直接实现这些能力，但也带来了三项限制。
第一项是规模化推理成本。每一条生成的回答都可能需要向外部供应商发起付费请求。当产品服务数千万月活跃用户时，即使单次请求的成本差异不大，也会产生实质影响。
Flo 估计，与前沿模型 API 相比，定制微调模型可将推理成本降低一个数量级。这一数字是公司估算，而非已披露的生产成本分析。
第二项限制是对模型生命周期的依赖。API 供应商可以停用某个模型、改变其行为、修订使用规则，或推出替代模型。每次变化都可能迫使健康应用重复开展评估工作。
第三项是对领域行为的控制有限。通用模型的安全调优必须覆盖大量主题、文化、产品和使用场景，无法自动编码 Flo 临床医生认为重要的每一项细微区别。
Flo 的长期方案是复合 AI 系统，即结合多个模型和支持组件，而不是将所有任务交给单一模型。此类系统可以把简单任务路由至较小模型，并将较大模型留给复杂请求。
这一路线给默认的前沿 API 策略带来了压力。选择并不只是开放技术与封闭技术之间的取舍，而是由模型供应商提供的通用安全性，与由应用开发者维护的领域特定控制之间的选择。
通用模型仍具有明显优势。其供应商可以在预训练、广泛评估、红队演练和基础设施方面投入巨资，也能在不要求每位客户运营训练栈的情况下更新能力。
但这些优势也意味着与最终使用场景之间存在距离。供应商并不拥有 Flo 针对月经症状、怀孕问题或其他敏感女性健康议题的具体回答政策。
Flo 正试图通过将领域专业知识转化为可迁移的评估基础设施来缩小这一差距。如果底层模型发生变化，公司可以重新运行评判器、生成偏好对，并重复后训练流程。
这一过程改变了稀缺资源的归属。基础模型变得更容易替换，而评估框架变得更有价值。
Flo 已将 Gemma、Qwen 和 Kimi 列为潜在的未来开放权重候选模型。开放权重模型会公开参数，开发者可以运行和修改它们，但其许可证并不总能满足开源软件的所有定义。
该公司并未表示会由某一个模型家族处理所有应用。其策略是将模型视为组件，使其围绕一套一致的医疗和产品要求展开竞争。
这使得经济层面的主张与安全性密不可分。如果模型产生更差的健康信息，低成本推理的价值就很有限。同样，更安全的模型若服务成本过高，也可能难以落地。
Flo 的方法旨在寻找一款同时跨越这两道门槛的模型。早期数据表明有所进展，但尚不足以证明这种平衡已经完成。
AI 评判器将临床规则转化为训练数据
Flo 通过训练自动评判器对候选回答排序来扩展专家判断，并利用这些排序直接改变模型。
这套流程始于超过 15,000 个合成问题。Flo 表示，这些输入源自模型生成或匿名汇总的信号，而非用户撰写的自由文本或可识别信息。
这种区别在健康应用中尤为重要。直接使用敏感的用户对话进行训练，可能带来隐私暴露、同意授权和记忆化风险。合成提示可以降低这些风险，但也引入了另一个问题：生成的问题能否准确反映真实用户。
针对每一个问题，系统会生成多个候选回答。随后，26 个评判器从安全性、实用性和更细化的行为标准等方面对这些回答进行评分。
Flo 选出表现更好的输出，并将其组织为偏好对。每一对回答都向模型展示：两种回应中哪一种更符合预期行为。
团队首先采用监督微调，即训练模型复现选定示例。随后使用 DPO，这种方法会提高优选回答相对于被拒绝回答的生成概率。
最初的 DPO 论文描述了一条比传统基于人类反馈的强化学习更简单的优化路径。它避免了在偏好优化阶段训练单独的奖励模型。
Flo 将其更广泛的工作流程描述为强化微调。系统生成候选回答、进行评分、选出更优答案、训练模型，然后再次运行评估。
评估与训练之间的区别至关重要。AI 评判器不只是为最终模型打分，其评分还会影响哪些输出成为正向示例，因此评判器的任何弱点都可能传导至训练后的行为。
Flo 在第一次尝试中就遇到了这一问题。实用性有所提升，但医疗安全性相对停滞。偏好对未能对不同层次的医疗质量作出足够细致的区分。
二元的通过或失败信号丢弃了有用信息。两个回答都可能避免了明确不安全的表述，但其中一个可以提供更好的安全背景。
Flo 在二元门槛之后加入了分级安全评分。通过基础安全测试的回答，会根据其满足适用医疗标准的完整程度进行排序。
这一变化带来了更清晰的偏好对。模型不仅能够学习避免被禁止的回答，也能学习偏向覆盖更全面、具备更完善安全兜底的回答。
这是该项目最具启发性的技术结果。偏好优化无法修复模糊的奖励信号。如果评估系统将浅层谨慎与严谨的临床表述视为等同，模型就没有理由学习二者之间的差异。
临床医生仍负责定义和验证标准。他们不需要手动撰写或标注每一个训练对，因此其工作能够影响更多示例。
然而，自动化并未消除人工瓶颈。它只是将专家投入前移：从重复标注转向量表设计、疑难案例裁定和评估器校准。
这种再分配可以让领域微调更具可扩展性。但如果团队不再审查分歧或罕见案例，它也可能将错误掩盖在自动化评分背后。
因此，这一方法依赖于对裁判系统的持续维护。医学指南会变化，用户语言会演变，新的模型家族也会暴露不同的弱点。即使固定的裁判套件在最初验证中表现良好，仍可能逐渐过时。
Databricks AI Runtime 让这一循环得以重复
基础设施之所以重要，是因为 Flo 需要将生成、评分、训练和评估作为一个受控循环反复运行。
Flo 使用 PyTorch 和 Fully Sharded Data Parallel，在 32 块 NVIDIA H100 GPU 上进行训练。FSDP 将模型参数、梯度和优化器状态分布到多块 GPU 上，以支持更大规模的训练工作负载。
其技术栈结合了 Databricks AI Runtime、LLM Foundry、Compose-RL 和 MLflow。LLM Foundry 负责分布式训练，Compose-RL 提供偏好优化层，MLflow 则跟踪实验和检查点。
AI Runtime documentation 将其描述为面向深度学习工作负载的无服务器 GPU 环境。在 Flo 的项目中，这意味着工程师无需为每次实验配置新的集群，即可请求分布式计算资源。
其优势不仅在于能够使用 H100 加速器。Flo 将数据操作、实验跟踪、模型训练和评估保留在同一整体环境中。
这种安排减少了发现故障与测试修正方案之间的摩擦。团队可以调整评分准则、重新生成偏好数据、重新训练模型，并将结果与此前的检查点进行比较。
Flo 的首次安全性结果说明了迭代速度的重要性。最初的偏好设计改善了一个目标，却几乎没有改变另一个目标。团队需要再完成一次完整循环，以测试分级安全评分。
碎片化的技术栈会让这一循环更慢，也更难审计。训练数据可能在不同系统之间流转，而模型检查点、评分版本和评估报告则彼此脱节。
统一的工作流可以保留问题、候选回答、裁判评分、偏好对、训练运行和最终评估之间的关联。当模型生成不安全回答、调查人员需要了解原因时，这种可追溯性就变得重要。
这一设计也支持 Flo 测试更新的开放权重模型的计划。工程师可以替换基础模型，同时保留大部分生成、评分、训练和跟踪流程。
这种可移植性是将该管线称为资产的最有力理由。算力可以租用，基础模型也变化迅速；而一套经过验证、能将领域标准转化为模型行为的方法，可能具有更长久的价值。
不过，平台便利性并不能解决核心质量问题。更快的实验可以产生更多证据，但也可能导致针对不完整基准的快速优化。
这种风险类似于应试教学。模型可能非常擅长满足评估器可见的偏好，却未必能在意外问题上同样安全。
Flo 对留出案例和临床裁决的使用有助于缓解这一担忧。但公开案例研究并未披露足够细节，无法判断这些案例的覆盖范围有多广，或不同用户群体之间的表现如何变化。
因此，基础设施应被理解为治理流程的加速器，而不能取代治理流程本身。
47% 的综合得分意味着进展，而非证明
Flo 提升了两项公布指标，但剩余的失败率意味着这些结果不能构成广泛的安全保证。
原始模型在 Flo 的医疗安全基准上得分为 34%，实用性得分为 42%。只有 16% 的回答同时通过了这两个维度。
微调后，安全性得分达到约 61%。实用性升至 76%，综合得分则提高到 47%。
综合结果接近三倍增长，但这也意味着 53% 的评估回答未能同时满足两项标准。其中一些回答可能安全但缺乏帮助，另一些则可能有用，却遗漏了医学安全保障。
这种区别会影响部署决策。即使模型不适合提供不受限制的健康建议，仍可支持受约束的功能。产品控制措施可以限制主题、检索经批准的信息、要求澄清，或将敏感案例升级处理。
Flo 尚未在案例研究中公开基准规模、置信区间、子群体结果或失败严重程度，也未说明用于这些评分的原始开放模型。
缺少这些细节，外部研究人员无法判断是否由一小部分反复出现的案例推动了大部分改进。他们也无法将 Flo 的模型与前沿 API 或专业健康模型直接比较。
这 26 名裁判在临床医生参与下完成校准，但所得分数仍属于内部测量。独立复现将为这些主张提供更强支撑。
外部评估之所以重要，是因为合成问题可能不同于真实对话。用户会拼错症状名称、遗漏背景、转换话题、表达恐惧，或提出受文化假设影响的问题。
基准也可能低估罕见但严重的疾病。平均表现或许有所提升，但模型仍可能在潜在伤害最大的案例中失败。
世界卫生组织的health AI guidance将问责制、透明度和人的自主性与技术表现并列。即使 AI 功能提供的是信息而非诊断，这些原则仍然相关。
Flo 还必须面对自身的隐私历史。2021 年，美国联邦贸易委员会最终敲定了一项命令，解决了有关 Flo 在承诺保护隐私后仍与分析服务提供商共享敏感健康信息的指控。
FTC settlement record 涉及的是早期数据实践，而非新的训练管线。但它仍具有相关性，因为用户对健康应用的信任涵盖模型说了什么，以及系统如何处理敏感信息。
Flo 表示，其合成数据流程避免使用用户撰写的自由文本和可识别信息。该公司还提供 Anonymous Mode，并称其可以将健康数据与用户身份分离。
这些措施缓解了部分风险，但仍有若干问题尚待解决。聚合信号仍可能编码人口统计失衡；合成数据可能复现生成它的模型所带有的假设；自动化裁判可能奖励看似专业的自信措辞。
因此，“privacy-first”应被视为一种设计方向，而不是对该管线已完成的外部认证。同样，“safer”是比较基准中的结果，而非证明每一条生成回答在医学上都安全。
这些限制并不会抹去已有成果。它们只是厘清了这些数字能够支持什么结论。
Flo 已展示，其内部系统能够在自身评估集上，使开放模型更接近由临床医生定义的行为。它尚未证明该模型能够取代临床照护，或能安全回答每一个真实世界的健康问题。
三个信号将显示这一策略是否站得住脚
下一阶段应通过跨模型复现、真实世界监测和独立评估来判断，而不是又一次孤立的基准提升。
第一个信号是 Flo 是否能在 Gemma、Qwen 或 Kimi 上复现这一改进。该公司已将这些模型家族列为其管线的未来候选对象。
如果不同基础模型都能取得相近提升，将支持 Flo 关于评估与训练系统才是持久资产的主张。若换用另一模型后表现大幅下降，则意味着当前结果可能高度依赖于一款未披露的基础模型。
比较应保留同一套留出评估集，同时加入针对每个模型独特弱点设计的测试。否则，团队可能会选出最适合熟悉测试的模型。
第二个信号是生产环境监测。Flo 应报告已部署系统拒答、升级处理、检索经批准信息或收到负面质量反馈的频率。
汇总的基准得分无法揭示失败是否集中在怀孕、避孕、疼痛、更年期或紧急症状等领域。按类别报告将显示模型在哪些方面仍不可靠。
监测还应区分低价值回答与可能有害的回答。重复的回答与带来危险安慰感的回答，不应具有相同的运营权重。
第三个信号是独立验证。外部临床医生和安全研究人员应使用 Flo 的训练流程未生成或筛选的案例测试该系统。
独立审查人员可以探测分布偏移、人口统计差异、对抗性措辞、多语言使用以及罕见医疗情境。他们也可以评估自动化裁判是否偏好特定沟通风格，而非临床实质。
来自这三个信号的证据将强化 Flo Health 开放模型的论据。若未能公布更广泛的结果，当前主张仍将依赖于供应商撰写的案例研究和公司自行设计的测量方法。
对开发者而言，直接的教训不是复制 Flo 的具体技术栈，而是将评估设计视为产品的一部分，而非训练完成后才进行的一项测试。
对企业采购方而言，关键问题也在改变。模型采购应审视谁来定义可接受的行为、这些规则如何转化为测试，以及系统是否保留每次训练运行的证据。
知识工作者和健康应用用户应寻找更清晰的边界。值得信赖的产品应说明：何时生成式输出仅供参考，何时检索经过审查的材料，以及何时会引导用户寻求专业照护。
Flo 报告的提升使其方法值得关注。尚未解决的 53% 同样使审视变得必要。
下一次决定性的更新不会是一轮规模更大的 GPU 运行，而应是证明相同的安全性提升能够经受住新基础模型、不可预测的用户问题以及独立临床审查的检验。在此之前，读者应将该系统视为一种颇具前景的训练后方法，而非经过验证、可替代医学判断的方案。
