株式会社diveは、医療現場向け音声書き起こしAI「Luminous」のオンプレミス版を開発しています。
オンプレミス版Luminousは、ローカルLLMを用いることで、クラウド利用に制約のある医療機関や高いセキュリティ要件を持つ病院市場に向けたソリューションとして開発を進めているものです。
特に、大学病院、地域中核病院、公立病院、大規模医療法人などの施設では、医師のカルテ記載負担が大きい一方で、クラウドサービス導入時に情報システム部門、個人情報保護委員会、院内審査などの確認ハードルが高くなる傾向があります。
クラウド版では「音声や診療情報がどこを通るのか」「外部AIに送るのか」「ログはどう残るのか」といった点が導入検討の論点になりやすく、稟議が進みにくいケースがあります。オンプレミス版では、院内サーバまたは院内アプライアンス内で処理し、外部クラウドへ診療音声を送信しない構成として説明できるため、高いセキュリティ要件を持つ医療機関でも導入検討を進めやすくなります。
第127回日本耳鼻咽喉科頭頸部外科学会総会の一般口演「第1群 テクノロジー」において、加納 滋先生（加納耳鼻咽喉科医院）による演題「クラウドを用いずにLLMと小規模GPUによる診療会話から要約やSOAP形式での出力に関する検討」のビデオ映像による講演が行われました。
本講演は、当社が開発を進めているオンプレミス版Luminousを実際に用いた検討として行われたものです。加納先生には、日々の診療現場に根ざした視点から、クラウドを用いない環境で診療会話の要約やSOAP形式での出力を行う可能性と課題を丁寧に検討いただきました。当社は、医療現場の実務と安全性の双方に向き合う先生の取り組みに深く敬意を表するとともに、いただいた知見を今後の開発に活かしてまいります。
株式会社diveは今後も、医療現場の運用やセキュリティ要件に合わせて、Luminousのさらなる機能拡充と導入形態の拡大に取り組んでまいります。
第127回日本耳鼻咽喉科頭頸部外科学会総会 講演動画
講演書き起こし
前回、我々は大規模言語モデルを用いたアプリを作成し、通常の会話内容からSOAP形式での表示に関する報告を行いました。
しかしながら、インターネットへの常時接続が必要なため、セキュリティの問題やオンプレミスの電子カルテには対応が難しいという問題が残りました。そこで今回は、インターネットに接続しないで、院内環境のみでの運用に関して検討することにしました。
最初にGPUの性能に関しまして、データセンター級でない現実的な構成として、Windows PC、Macintosh、iPadなどを対象としました。GPUのタイプとメモリはこのようになっています。
LLMのモデルはLlama 3.1 8Bを用い、単一ストリーム、コンテキスト8K、出力512トークンの条件で、公式仕様なども参考に推定しました。
最初にTTFT、Time to First Tokenです。単位は秒です。プロンプト送信から最初のトークンが返るまでの時間で、小さいほど良い指標です。短文では短く、長文では長くなります。値は主に小さな準備時間、入力トークン数、プリフィルスループットで決まります。青色の棒は推定中央値、黄色の誤差バーは実操作による上下幅を表します。NVIDIA RTX A6000は最短の応答を示しました。
プリフィルスループットの単位はprompt tokens per secondです。入力を処理する区間の速度で、大きいほど良い指標であり、長文要約やRAGの所要時間、そしてTTFTに効きます。RTX A6000が高い性能を示します。
デコードスループットの単位はtokens per secondで、1トークンずつ書き出す段階の速さです。RTX A6000は70から110 tokens per secondと高い性能を示します。その他のモデルでも数十トークン毎秒の速度が出せることが確認できました。
次に、Mac Studio M3 Ultraを基準とした相対性能について検討してみました。7Bから13Bサイズでは、RTX A6000はCUDAの最適化で2から3倍と高速で、Mac mini、iPadでは約5分の1の性能でした。iPad単体で8Bを常用するには、発熱とメモリの余裕が小さいと考えられました。
70Bでは、A6000のVRAM不足によるCPU RAMへのオフロードが発生し、減速しました。Mac miniは15秒、iPadは対応できませんでした。120BではA6000はVRAMに収まらず、さらに減速しました。この規模ではMac Studioが有利でした。
次に、診療会話から要約およびSOAP形式での出力に関する検討を行いました。会話内容は生成AIを用いて個人情報のないテキストを作成し、これを音声データに変換しました。その音声データから文字起こしを行い、得られたテキストだけを根拠に、LLMに上限300字の要約をさせました。
今回はLLMの異なるサイズとして、OSS 120B、MedGem 27B、MedLlama 8Bを使用し、SOAPをJSON形式で返させました。評価指標は、医療文書らしさ、幻覚の混入リスク、フォーマット遵守としました。
最初に、生成AIの作成した仮想会話です。約2分間、総文字数は800字です。「こんにちは。本日はどのような症状でいらっしゃいましたか」「2、3日前から喉が痛くて、声も少しかすれてきたので受診しました」「喉の痛みは飲み込む時が一番つらいですか。それとも何もしていなくても痛みますか」「飲み込む時が一番痛いですけど、じっとしていても……」
MedGem 27Bによる要約などです。実務的にも違和感なく読める結果と考えられました。滲出性中耳炎という言葉も、要約からObjective、Assessmentに正しく伝わっています。
MedLlama 8Bでは要約の大筋は合っていますが、専門用語の保持が十分でなく、その影響がSOAPにも残っています。これはどのLLMでも発生しうる問題点であり、今後の課題と考えています。
まとめです。データセンター級でないGPUについて比較を行いました。8B級LLMの4ビット量子化モデルでも実務的な要約が得られ、文書品質の観点から下書き用途に向きますが、専門用語の保持、幻覚の混入などに関しては、医師による最終確認が必要と考えられました。
