薬歴作成自動化の為のプロンプトエンジニアリング - 株式会社corte様
プロンプトエンジニアリング支援
本日は、弊社が支援させて頂いた株式会社corte様のユースケースについて紹介させて頂きます。
corte様は、音声認識AIと生成AIを活用した薬局向けの薬歴自動作成アプリを開発・運用されています。
薬歴作成業務というペイン
薬局では、薬剤師による患者様とのコミュニケーションから薬歴を作成し、調剤に至るまでの業務があります。
現在、厚生労働省の取り組みもあり、薬局全体にDXの波が訪れています。
そして、ITを積極的に活用することで、個々の患者様とのコミュニケーションを綿密に取る処方が推奨されています。
薬剤師が毎回患者様と異なる会話をすることで、多角的に患者様の容態を把握し、より正確な処方が出来るようになることが期待されています。
一般的に、薬剤の処方は医師による診察を経て処方されますが、医師による1回の診察では、病状の原因を見抜けない場合があります。
その結果、薬剤師と患者様との多様な会話の中から、医師の診察結果とは異なる病状を薬剤師が発見するケースがあったり、患者様とのコミュニケーションの中から、病状の原因を特定するケースがあります（詳しくは、既述のYouTube動画をご覧下さい）。
その為、真の病状の早期発見を促す為に、薬剤師と患者様との豊富なコミュニケーションを推奨され始めているという背景があります。
しかしながら、薬剤師による患者様とのコミュニケーションが優先事項となる一方で、薬歴記載といった業務に工数が割かれてしまい、薬剤師の工数を逼迫しているという現状がありました。
そこで、生成AIを使い、音声データから自動で薬歴を作成するアプリを開発することで、薬剤師の工数を削減し、患者様とのコミュニケーションに集中出来る環境を提供出来るのではないかと考えました。
支援内容 - SOAP形式での薬歴の要約
薬局では、患者様とのコミュニケーション内容を薬歴として記載する際に従うフォーマットがあります。それがSOAP形式です。
SはSubject（患者様による主観的報告）、OはObject（実際の事象）、AはAssumption（薬剤師による分析）、PはPlan（処方の計画）です。
このSOAP形式での薬歴を、音声認識AIと生成AIを併用して自動化することがcorte様のスコープです。
今回紹介するユースケースでは、Chat GPT 3.5turbo時点での支援内容を紹介します。
Chat GPT 4oになったことで、生成AIの要約精度は飛躍的に向上しましたが、3.5turboでは様々な制約がありました。
例えば、一回あたりのプロンプトでChat GPTからアウトプット出来るプロンプトの精度に制約がありました。
その為、Sに記載すべき内容がAに記載されていたり、Oの情報に不足があったり、音声認識AIで拾いきれなかった音声を補完する際に、ハルシネーションによって誤った医療用語が記載される事象が見受けられました。
そこで、弊社は支援の際に、「多段式プロンプト」を採用しました。
「多段式プロンプト」について
「多段式プロンプト」とは、ChatGPTを用いて複雑な処理を行う際に、タスクを小さなサブタスクに分割する手法です。
具体的には、各APIの呼び出し毎に1つのタスク、つまり1つのプロンプト（要約や内容確認など）のみ処理することで、複雑なタスクを段階的に処理し、最終的に所望の出力を得る為の手法です。
（推論と似たような処理を行うという点で、類似の思想にCoT（Chain of Thought）があります）
本件では、以下のようにSAOP要約の各パート毎に処理することで高い精度のSOAP要約を実現しました。
①Sの出力
スコープ：薬歴において最も重要な患者の主観的な報告は、精度高く最終アウトプットとして得る必要性があります。記載内容の抜け漏れやハルネーションを防ぐ為、Few-shotプロンプトを用いるとともに、出力のルールとフォーマットを記載しました。これにより実用に耐えるアウトプットを実現しました。
②Oの出力
スコープ：S(subjective)同様、O(objective)も高い精度が求められる為、Oのパートだけを独立して要約するプロンプトを用意しました。Oでは数値などを取り扱う関係上、より正確性を期すため出力のルールに関する記載を増やし、記載がないデータをハルネーションで補完してしまう可能性を低減しました。
③Aの出力
スコープ：A(Assessment)とP(Plan)はS,Oと比較して優先度が低いですが、会話データに該当する内容が含まれないこともあります。このためよりハルネーションを起こさないプロンプト（該当データがないときに出力しないようにする）を作成しました。
④Pの出力
Planという内容の特性上、Aと同等以上に会話データ内に含まれないことが多いため、こちらもハルネーションを起こさないようなプロンプトの設計を行いました。
これらのステップによって、単に1回のAPIの呼び出しでSOAP要約をするプロンプトと比べて、薬歴の自動記載の精度が飛躍的に向上しました。
また、音声データ時点では不正確な医療用語も、段階的な出力のステップを経ることで、精度高く正しい医療用語が記載されていることが確認出来ました。
特に、各項目を個別に要約し、それぞれの要件を満たすようなチューニングを行うことで、全体の精度向上に貢献したものと総括しています。
エンハンス開発の余地 - RAGの構築
本件には、まだエンハンス開発する余地が残っていました。
具体的には、地方の薬局で用いられる方言への対策や、病院やクリニックの薬歴作成にも対応する為に、各課題に特化したソリューションが必要でした。
そこで、RAG（Retrieval Augmented Generation）を構築することで、外付けのDBによって生成AIに検索機能を追加し、より多様なシチュエーションに応じたアウトプットを出せることが見込まれました。
現在では、生成AIのモデルのアップデートもさることながら、RAG周辺の技術の進展も目まぐるしく、日々生成AIの活用方法や課題が出てきている状況です。
最後に
弊社では、専門性の高い分野のお客様に対しても、数多くのLLM構築やプロンプトエンジニアリング、RAGの構築やfine-tuningを支援して参りました。
様々な企業様の試行錯誤もあり、生成AIのベストプラクティスも少しずつ見えてきました。
他方で、生成AIは提供しているプロバイダーですら把握し切れていない謎に包まれた側面も多く、試行錯誤が続いている状況です。
弊社では、実務実績ベースでのナレッジと、論文レベルでの最先端の研究成果も踏まえながら、お客様の生成AIの活用を支援致します。
生成AIを使って検証したいことや実装したいソリューションのアイデアがある際には、お気軽に弊社にお問い合わせ下さい。
Discussion