Flo Healthのオープンモデルはより安全で有用になったが、47%は依然として両方のテストを通過
Flo Healthのオープンモデルは、厳しい社内ベンチマーク2種で改善を示したものの、評価対象となった回答のうち医療安全性と有用性の両方の基準を満たしたのは47%にとどまった。同社によれば、ポストトレーニングの仕組みにより医療安全性は34%から約61%へ向上した。有用性も42%から76%に上昇した。
こうした改善は、合成質問、専門化されたAI判定モデル、臨床医が定義した評価ルールを中心とするパイプラインによるものだ。Floはその後、教師ありファインチューニングとDirect Preference Optimization（DPO）を用い、望ましい振る舞いをオープンモデルの重みに組み込んだ。
この取り組みが重要なのは、2026年10月12日に公開されたDatabricksのケーススタディによると、Floの月間アクティブユーザー数が8,100万人に達しているためだ。この規模では、低いエラー率であっても、多くの人が不完全で過度に安心させる、あるいは分かりにくい健康情報に触れる可能性がある。
この結果は、健康領域の生成AIに対する最も単純なアプローチ、すなわちすべてのリクエストをフロンティアモデル提供企業に送り、一般的な安全レイヤーに依存するという考え方にも疑問を投げかける。Floは、より小規模で用途に合わせたモデルによって、より大きな制御性と低い推論コストを実現できると見込んでいる。より難しい問いは、社内で設計されたベンチマークが、それを生み出した環境の外でも安全性を確立できるかどうかだ。
Floはモデルをトレーニングする前に評価システムを再構築した
中心となる変更は、新しいチャットボットや基盤モデルではなかった。Floはまず、臨床的判断を再現可能な評価・トレーニングシステムへと変換した。
Floの医療、プロダクト、エンジニアリングの各チームは、回答品質を大きく2つの目標に分けた。医療安全性を基盤とし、有用性では回答がユーザーにとって関連性があり、理解しやすい助けを提供しているかを測定した。
この区別は明白に聞こえるが、モデルが曖昧な健康上の質問に直面すると重要になる。たとえば、生理が遅れている理由を尋ねる人を考えてみよう。受診だけを勧める回答は危険な主張を避けられるかもしれないが、すぐに役立つ文脈はほとんど提供しない。
逆の回答も失敗し得る。モデルがストレス、旅行、体重変化、運動を列挙しつつ、妊娠や専門家による評価が必要な状態を見落とす可能性がある。その回答はより有用に感じられるが、重要な情報の欠落は誤った安心感を生みかねない。
そのためFloは、安全性と有用性を、両方を満たす必要がある別個の評価軸として扱った。最終的なフレームワークには26のAI判定モデルが含まれ、これは明確な採点指示と参照事例を持つ自動評価器を意味する。
12の判定モデルが医療安全性の制約を適用した。6つのマイクロ判定モデルは、根拠の提示、枠組み、文体、きめ細かな安全性など、より狭い振る舞いを検査した。8つの有用性基準では、完全性、関連性、一貫性、トーンを評価した。
同社は、繰り返し現れる失敗パターンに対するルールも作成した。「原因のバランス」に関するルールでは、問題のない説明と潜在的に深刻な説明の両方が関連する場合、回答で双方を扱うことを求めた。これは、会話モデルが完全に見える安心させる回答を生成しがちな傾向を狙ったものだ。
Floによれば、これらの判定モデルは合成事例とユーザー実験の匿名化された例に照らして検証された。自動判定モデルが当初の人間による評価と一致しなかった場合、ブラインド化された臨床レビュアーがその事例を裁定した。
レビューされた事例の一部は、判定モデルの改善に役立てられた。Floは残りを後続の測定用に確保し、キャリブレーションに使用した例だけで評価するリスクを抑えた。
この評価優先の戦略は、報告されたベンチマーク結果の基盤となっている。また、このプロジェクトが通常のファインチューニング作業以上に重要である理由でもある。
「安全性」という言葉が漠然とした理想にとどまる限り、チームはそれを確実に改善できない。Floは、これらの振る舞いをトレーニングシグナルとして使う前に、個別に検証可能な行動として理想を表現する必要があった。
同じ原則はヘルスケア以外にも当てはまる。企業チームは広範なドメイン知識を持つことが多いが、その知識はポリシー、専門家の判断、研究、運用上の例外に分散している。knowledge blendingを支援するシステムは、こうした資料の整理に役立つ可能性がある。ただし、モデル評価には依然としてタスク固有のテストと説明責任を負うレビュアーが必要だ。
Floの設計は再利用可能な資産を生み出す。基盤モデルは陳腐化したり、ライセンスが変わったり、コスト優位性を失ったりする可能性がある。だが、臨床ルーブリックと評価事例は次のモデルへ移行できる。
この可搬性こそが、本記事の主要な緊張関係を生む。Floは、汎用プロバイダーの安全性に関する前提を独自の基準に置き換えることで制御性を得る。同時に、そうした基準が大規模かつ多様なユーザー集団全体で信頼できることを証明する責任も負う。
Flo Healthのオープンモデルが経済的な賭けになった理由
Flo Healthのオープンモデルは、安全性だけのプロジェクトではない。高価で外部から制御されるモデルAPIへの依存を減らす試みでもある。
Floは以前から従来型の機械学習を利用し、より柔軟でパーソナライズされた体験のために生成AIの活用を探ってきた。単一の汎用モデルはこうした能力への直接的な道筋を提供したが、3つの制約をもたらした。
1つ目は、大規模運用時の推論コストだ。生成される各回答には、外部プロバイダーへの有料リクエストが必要になる可能性がある。月間数千万人のユーザーを抱えるプロダクトでは、リクエストあたりの小さな差も大きな意味を持つ。
Floは、用途に合わせてファインチューニングしたモデルが、フロンティアモデルAPIと比べて推論コストを桁違いに削減できると見積もっている。この数値は同社の推定であり、開示された本番コスト分析ではない。
2つ目の制約は、モデルのライフサイクルへの依存だ。APIプロバイダーはモデルを廃止し、その振る舞いを変更し、利用ルールを改定し、あるいは代替モデルを導入できる。変更のたびに、ヘルスアプリは評価作業を繰り返す必要が生じる可能性がある。
3つ目は、ドメイン特有の振る舞いを制御できる範囲が限られることだ。汎用モデルの安全性チューニングは、多くの対象領域、文化、製品、ユースケースをカバーしなければならない。Floの臨床医が重視するあらゆる違いを自動的に組み込むことはできない。
Floの長期的な答えは、すべてのタスクを単一モデルに割り当てるのではなく、複数のモデルと補助コンポーネントを組み合わせる複合AIシステムだ。このようなシステムでは、単純なタスクをより小規模なモデルに振り分け、難しいリクエストのために大規模モデルを確保できる。
この道筋は、フロンティアAPIをデフォルトとする戦略に圧力をかける。選択は単にオープン技術かクローズド技術かではない。モデルベンダーが提供する汎用的な安全性と、アプリケーション開発者が維持するドメイン固有の制御との選択だ。
汎用モデルには明確な強みが残る。その提供企業は、事前学習、幅広い評価、レッドチーム演習、インフラに多額を投じられる。また、すべての顧客にトレーニングスタックの運用を求めることなく、能力を更新できる。
ただし、こうした強みは最終的なユースケースからの距離を伴う。プロバイダーは、月経症状、妊娠に関する質問、その他のセンシティブな女性の健康トピックに対するFlo独自の回答ポリシーを管理しているわけではない。
Floは、ドメイン専門知識を可搬性のある評価インフラへと変換することで、この隔たりを埋めようとしている。基盤モデルが変われば、同社は判定モデルを再実行し、選好ペアを再生成し、ポストトレーニングを繰り返せる。
このプロセスは、希少な資源の位置づけを変える。ベースモデルはより代替可能になり、評価フレームワークはより価値を持つようになる。
Floはすでに、将来のオープンウェイト候補としてGemma、Qwen、Kimiを挙げている。オープンウェイトモデルは開発者が実行・変更できるパラメータを公開するが、そのライセンスが必ずしもオープンソースソフトウェアのあらゆる定義を満たすわけではない。
同社は、1つのモデルファミリーがすべてのアプリケーションを処理すると述べているわけではない。むしろその戦略は、医療およびプロダクト要件の一貫したセットに対して競い合うコンポーネントとしてモデルを扱う。
このため、経済的な主張は安全性と切り離せない。モデルがより悪い健康情報を生成するなら、低コストの推論が持つ価値は限られる。同様に、より安全なモデルであっても、提供コストが高すぎれば実用的でない可能性がある。
Floのアプローチは、両方の閾値を超えるモデルを目指している。初期の数値は進展を示しているが、そのバランスが完成したことを裏付けるものではない。
AI判定モデルが臨床ルールをトレーニングデータに変えた
Floは、専門家の判断を用いて自動判定モデルに候補回答を順位付けさせ、その順位を使ってモデル自体を変化させることで、専門家の判断を拡張した。
パイプラインは15,000件を超える合成質問から始まった。Floによれば、入力はユーザーが自由記述したテキストや個人を特定できる情報ではなく、モデルが生成した、あるいは匿名で集約されたシグナルから導き出された。
この区別は健康アプリケーションにおいて重要だ。センシティブなユーザー会話を直接トレーニングに使うと、プライバシーの露出、同意に関する問題、記憶化のリスクが生じうる。合成プロンプトはこれらのリスクを減らすが、別の問題ももたらす。すなわち、生成された質問が実際のユーザーを正確に反映しているかどうかだ。
各質問に対して、システムは複数の候補回答を生成した。続いて26の判定モデルが、安全性、有用性、より狭い行動基準に基づいてそれらの回答を採点した。
Floはより優れた出力を選び、選好ペアとして整理した。各ペアは、2つの回答のうちどちらが望ましい振る舞いにより合致するかをモデルに示した。
チームはまず、選ばれた事例を再現するようモデルを訓練する教師ありファインチューニングを適用した。その後、DPOを用いて、拒否された回答に対して望ましい回答の尤度を高めた。
元となるDPO論文は、人間のフィードバックによる従来の強化学習より単純な最適化の経路を説明している。選好最適化の段階で別個の報酬モデルをトレーニングする必要がない。
Floは、この広範なワークフローを強化ファインチューニングと説明している。システムは候補を生成し、採点し、より良い回答を選択してモデルをトレーニングし、再び評価を実行する。
評価とトレーニングの区別は極めて重要だ。AI判定モデルは最終モデルを採点するだけではない。そのスコアはどの出力がポジティブな事例になるかに影響するため、判定モデルの弱点はトレーニング後の振る舞いへ伝播し得る。
Floは最初の試みでこの問題に直面した。有用性は改善したが、医療安全性は比較的横ばいだった。選好ペアが、医療品質の水準間にある十分に細かな差を表現できていなかった。
合格か不合格かという二値のシグナルは、有用な情報を捨てていた。2つの回答はいずれも明白に危険な発言を避けているかもしれないが、一方はより優れた安全性の文脈を提供できる。
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%へ増加した。
総合結果はほぼ3倍になったが、同時に、評価された応答の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実行ではない。同じ安全性向上が、新しいベースモデル、予測不能なユーザーの質問、独立した臨床レビューを経ても維持されることを示す証拠である。それまでは、このシステムを、医療判断の検証済み代替手段ではなく、有望なポストトレーニング手法として扱うべきだ。
