5,759 文字
こんにちは、私はNinaと申します。Taurisのリサーチエンジニアをしています。本日はSと共に、臨床アプリケーションにおけるLLMの評価についての私たちの取り組みをご紹介します。7分間、医師が私たちのLLMを活用したアプリケーションTaurisを使用するたびに、彼らは医師としての本来の仕事に7分間を費やすことができます。
今日、これが非常に重要な理由は、医師の業務時間の最大60%がデータ入力、検査の記入、オーダー作成などのコンピュータ作業に費やされており、一般的な勤務時間中に4,000回ものクリックを要することがあるからです。そのため、53%の医師がバーンアウトを報告しており、コンピュータの使用がその主な原因の一つとなっているのは驚くことではありません。
では、Taurisの動作を見てみましょう。
「こんにちはS、今日はどうされましたか？」
「はい、この数日間本当に没頭していたんです。OpenAI DevDayのプレゼンテーションの準備をしていて、一晩中スライドを作っていました」
「ああ、どんな症状が出ていますか？」
「Canvaを開くたびに吐き気がして、Sam Altmanが発表中にヤジを飛ばしてくる悪夢を見るんです。ここ数日は本当に大変でした」
「ああ、それはかなりひどいですね。本当に没頭されているようなので、透析と解熱鎮痛薬を処方しましょう」
ここでTortusが私たちの診察内容を取り上げ、電子カルテに記録される診療記録を作成できることがわかります。では、この要約を見てみましょう。
見てわかるように、SalがOpenAIのプレゼンテーションでストレスを感じており、吐き気があり、ストレス状態であることがよく捉えられています。また、私が処方した「没頭」に対する透析とイブプロフェンについても言及されています。しかし、注目すべき点として、私はSalにパラセタモールを処方するとは一言も言っていません。これは臨床上のエラーであり、患者に影響を及ぼす可能性があります。
そのため、LLMを本番環境で使用する際は非常に慎重になる必要があります。シリコンバレーの典型的なマントラである「素早く動いて物事を壊す」は、必ずしも私たちには当てはまりません。なぜなら、素早く動いて物事を壊すことは、素早く動いて人を傷つけることにつながる可能性があるからです。
したがって、エンドユーザーであり、この分野の専門家である医師を中心に据えて、本番環境にプッシュするものの設計と評価を支援してもらうことが重要です。医師は通常、診察内容を入力として一連の文書を出力する複雑なワークフローのアイデアを出し、これらの要件を開発者に伝えます。開発者はこれらをコードで実装し、良い解決策に達するまで共に繰り返し作業を行います。
しかし、私たちには非常に厳しいコンプライアンス要件があります。当然ながら、アウトプットは臨床的に安全である必要があり、このため個人のプロセスは非常に遅く、労力を要します。プロセスを最も遅くしていたのは、開発者とのこの反復的なループでした。当時、医師を運転席に戻すためのすぐに使える解決策はありませんでした。
そこで私たちは、これらの複雑なワークフローをブロックと呼ばれる小さなステップに分解し、医師を運転席に戻すためのプラットフォームを作ることを決めました。
その方法を見てみましょう。私たちのアーキテクチャの中核には、LLMワークフローを構成する基本的なブロックがあります。私たちの主要な目標は、医師とエンジニアリングがこれらのワークフローを開発する際に同じ言語で話せるようにすることでした。
ブロックを設計する際、私たちはLLMの呼び出しを中心に据えました。入力を決定し、ほとんどの場合は医療記録となります。また出力も定めます。モデル、使用されたプロンプト、構造化された出力かどうかなどの追加のモデル設定も指定します。これが、LLMワークフローでブロックを作成する際に使用する一般的なインターフェースです。
重要な点は、医師同士がブロックを共有して再利用できるようにすることで、多くの作業を再利用する必要がないようにすることです。そのため、これらをデータベースに保存します。これらのパラメータをすべて取り込み、ハッシュを作成し、これがブロックIDを形成します。これはブロックの一意な表現であり、これらのパラメータのいずれかを変更すると新しいブロックIDが生成されますが、ブロックを他の医師と共有したい場合は、データベースから取得できます。
では、ブロックの骨格ができたところで、それらがどのように組み合わさるかを見てみましょう。医療記録から重要な事実を抽出する1つのブロックと、それらの事実を取り込んで紹介状を作成する別のブロックがあるとします。これら2つのブロックがどのように組み合わさるかを指定する方法が必要です。
最初は、単に「事実」という用語を使用して2つのブロックを接続すればよいと考えました。しかし、事実は非常に高レベルで、箇条書きの事実もあれば、段落で書かれた事実もあり、それが後々異なる出力につながる可能性があります。そのため、非常に明示的である必要があります。
そこで、次のブロックへの入力として、前のブロックのブロックIDを使用することにしました。そうすることで、前に何が来るのかを正確に知ることができ、IDが一致するとこれら2つのブロックを組み合わせることができることがわかります。
これでLLMワークフローができました。現在の事実から手紙のブロックを維持しながら、情報抽出ブロックを改良するとしましょう。例えば、OpenAIが新しい魅力的なモデルをリリースして使用したい場合、プロンプトを少し変更するかもしれません。これにより新しいブロックIDが生成され、古いブロックIDもまだ残っていますが、ブロックIDが一致しないため、ブロックはもう組み合わせることができません。
これは非常に冗長に見えるかもしれませんが、監査を受ける際には実際に良い立場に立つことができます。なぜなら、特定のワークフローの監査を受ける際に、途中で何が起きているのかを正確に知ることができるからです。
医師がこれらのブロックを作成できるようにUIを作成しました。これにより、長いJSONを編集することなく、関数呼び出しブロックを作成し、構造化された出力を生成できます。また、Firebaseからブロックをロードすることもできます。
ここにあるのは、EMISと呼ばれる電子カルテシステムで使用される形式で、医療記録から主要な問題を抽出するブロックです。医師はこのブロックをロードし、いくつかの記録を入力して出力がどうなるかを確認できます。ここで見られるように、これは構造化された出力で、問題の配列を出力します。
このワークフローに追加したい場合、UIからブロックを作成できます。ここでは、これらの問題を取り込んでSOAP形式のノートを出力する単純なLLMブロックを作成します。入力を指定する際、EMISの問題のブロックを入力として指定していることに注意することが重要です。
ブロックができたら、それをチェーンに追加して出力を生成できます。生成後、SOAPノートが正しい形式で出力されるはずです。また、途中の出力も表示されるため、途中で何が生成されているかを確認できます。
これが医師がブロックを改良し共有する主要な場所であり、満足したらこれらのブロックを実験として保存できます。実験とは何でしょうか？実験は、LLMワークフローを比較する方法です。
例えば、既存の記録から手紙へのワークフローは、記録を取り込んで紹介状を作成する1つのブロックで構成されているとします。このワークフローを改良して、まず重要な事実を抽出し、その後手紙を生成したいとします。実験を設計する際、生成されるデータポイントの数、各データポイントをレビューする医師の数、結果を比較するベースラインなど、いくつかの事項を指定します。このフレームワークが実験を形成し、この例ではこれがベースラインとなります。
生成パイプラインがどのように機能するか見てみましょう。指定した実験から始まり、診察内容のバンクから出力を生成します。これを医師に提供し、入力に含まれていない出力の部分である幻覚と、LLMのステップで見落とされた部分である欠落をラベル付けできるデータラベリングプラットフォームを設計しました。
Taurisでは、これを「halumi」と呼んでいます。はい、これは近々商標登録する予定です。誰かがこれを使用したい場合は、私たちのウェブサイトを参照してください。halumiを収集したら結果を分析します。通常の生活とは異なり、実験で生成されるhalumiの量を最小限に抑えたいと考えています。
実験のhalumiがベースラインよりも少ないことがわかった場合、実際には設計図に戻り、新しい実験を作成してそこから改良を重ねます。良好に見える場合は、製品に組み込むことができます。
ここで重要なのは、パイプラインのこの部分、つまりhalumiの人間によるラベル付けを収集する部分が実際に最も重要だということです。医師はLLMが自力では本当にできない重要な情報を持っています。2023年にはM EVの評価を試みましたが、十分な水準ではありませんでした。
そのため、この部分を重要視する必要がありました。医師が入力と出力を見てラベル付けするこのステップは非常に時間がかかることに注意することが重要です。私たちは医師に良い仕事をしてもらうためにインセンティブとして報酬を支払っています。そのため、利用可能なリソースを最大限に活用する必要があります。
リソースを最大限に活用するためにいくつかのことを行っています。まず、ブロックレベルで結果を保存します。中間出力を保存することに加えて、以前の実験を実際に再利用できます。例えば、非常に優れた情報抽出ブロックがあり、それを基に他の異なるワークフローを構築したい場合、その情報抽出ブロックのラベルを再度取得する必要はありません。
もう1つは、スマートサンプリングです。これは、実験とベースラインの間でランダムシードを共有し、新しいデータポイントをサンプリングする際に、実際にベースラインと同じ例を再利用することです。つまり、リンゴとリンゴを比較しているのです。
これにより実現できる重要な機能は、ラベル付けの労力を大幅に増やすことなく、時間とともに収集するデータポイントの数を増やすことができることです。例えば、ベースラインが25の例で、新しい実験で30を実行したい場合、同じ25をサンプリングし、追加の5つを取得します。そしてその追加の5つがラベル付けされます。
このプラットフォームを使用して製品の臨床的安全性を評価した結果を見てみましょう。Salが言及したように、幻覚と欠落があります。これらは、モデルが生成する元の記録に存在しない内容と、LLMによって見落とされた内容です。
また、重大なエラーと軽微なエラーという内部分類も行っています。重大なエラーは患者の臨床結果に影響を与えるものです。そのため、重大なエラーを最小限に抑えることに特に関心があります。
重大なエラーの例を少し示しましょう。上部のテキストは非常に小さいので説明しますが、これは医師が患者を診察している内容で、患者はインフルエンザのような症状があり、医師は患者に家で休んで水を飲み、イブプロフェンを服用するように推奨しています。
下部には、私たちのワークフローの1つでLLMによって生成された出力があり、赤で示されているのがLLMが犯したエラーです。この場合、LLMは広域スペクトル抗生物質の使用について話し合うべきだと述べましたが、これは医師が言っていないことです。そのため、これは患者に影響を与えるため、重大な幻覚として分類されます。
大まかに見ると、時間の経過とともに実験のグラフで、幻覚と欠落の量が減少していることがわかります。しかし、これは反復的なフレームワークであるため、必ずしも予想通りにはいきません。
ここでグラフの一点を強調しますと、重大な幻覚が大幅に増加したことがありました。これは、元のベースラインで記録から直接手紙を生成しようとしていたときに起こりました。アウトプットをより事実に即したものにするために、事実を抽出してからそれを使用して手紙を生成すべきだと考えました。
このプラットフォームにより、実験が実際にはより多くの重大な幻覚を引き起こしたことを非常に迅速に評価することができました。そのため、これを本番環境にプッシュすることはできないと直ちに判断し、したがって実際の臨床現場で患者に影響を与えることはありませんでした。
全体として、このフレームワークの使用はTortusで多くの時間を節約しました。当初、医師と共同で作業し、彼らが実行したいワークフローを設計する任務を負った2人の開発者がいました。医師が遊び場を通じて自分でワークフローを作成できるようになったため、これら2人の開発者は会社で必要とされる他の作業に取り組むことができました。
さらに、これは医師をより幸せにする効果がありました。なぜなら、彼らが運転席に戻り、自分の望むスピードでワークフローを設計し、関心のある実験を実行できるようになったからです。全体として、これは新しいプロンプト、新しいモデル、新しいアーキテクチャを本番環境に投入する時間を短縮する効果がありました。
加えて、ラベル付けされた出力のすべてが、LLMが生成した臨床文書の幻覚と欠落に関する最初の大規模データセットの1つとなりました。私たちはこれを使用してエラー検出を自動化し、製品をさらに安全にすることを計画しています。
これにより、本番環境でのライブモニタリングも可能になり、エラーが発生した際にユーザーに警告を出すことができ、文書を共有する際に注意を促すことができます。
ご清聴ありがとうございました。また後ほどお話しできることを楽しみにしています。
コメント