「Doctor.ai」 Neo4jとAWSを活用したヘルスケア向け音声チャットボット #neo4j #AI
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
本ブログは 「Neo4j」 社の技術ブログで2022年1月18日に公開された「 Doctor.ai, a Voice Chatbot for Healthcare, Powered by Neo4j and AWS 」の日本語翻訳です。
いまヘルスケア業界ではビッグデータ、機械学習、クラウド、グラフデータベースによって変革がおきています。関連性の高い膨大な医療データが、クラウド上のグラフデータベースに蓄積され、機械学習によって処理されています。その結果、人間の体に対する理解が深まるのです。このような知識は、より良い予防医療、より正確な診断、そしてより効果的な治療につながります。
技術の進歩は、医療の民主化にもつながります。コストを下げ、医療行為をより効率的に普及させることで、低所得者でも恩恵を受けられるようになります。また、個人や公共の医療データを誰もが利用できるようになります。後者の点は見落とされがちです。エリック・トポルは著書『Deep Medicine』でこう述べています。
このような情報の非対称性は、総じて患者を不利な立場に置くことになります。自分の医療記録や検査結果はもちろん、データを理解するためのソフトウェア・ツールにもアクセスできないため、患者は医師に完全に依存している状態です。この場合、予防医療、診断、治療方法を決めるのは医師だけです。また、データへのアクセス制限で医師が困ることも多々あります。
まず、手書きのカルテや画像は、デジタル化されていないと医師間で容易に利用・転送できません。それは、事務作業や医療行為の無駄な重複につながります。また最新の医学研究の普及は非常に遅く、多くの医師はその恩恵を受けることができません。
この確信とDeep Medicineからのインスピレーションをもとに、Neo4jのエンジニア4名と私は、Singapore Healthcare AI Datathon and EXPO 2021でDoctor.aiを開発しました。グラフデータベース Neo4j と AWS を活用した音声バーチャルアシスタントです。このアシスタントは、大量の医療記録をグラフにマッピングし、GDS（Graph Data Science）ライブラリを使って治療法をレコメンドできます。
AWS Lexは、Doctor.ai の目であり、口であり、耳です。ユーザーからの音声や文字による入力を受け、Lambda を介してNeo4jグラフにクエリします。最後に、AWS Amplify上にReactのフロントエンドを置いて、簡単にやり取りできるようにしました。
図1：Doctor.ai のコンセプト
Doctor.ai はDatathonで作成したものに過ぎませんが、共有する価値のある技術的なハイライトを多く含んでいます。以前の記事では、Doctor.ai のすべてのセットアップ手順を紹介しました。今回は、チャットボットの内部構造について、より詳しくご紹介します。
Doctor.ai のスタンドインデータ、アーキテクチャ、および内部構造
Doctor.ai の開発には、eICUのデータベースを利用しました。2014～2015年、米国の139,000人以上のICU記録20万件を収集したものです。何十ものテーブルが入っています。また、元のデータベースとは別に、前処理されたデータベースeicu_crd_derivedが存在します。検査結果、診断、治療、人口統計情報、その他のメタデータをデータベースで見つけることができます。今回のDatathonでは、これらの情報を6つのテーブルからNeo4jに取り込みました（図2）。これらを組み合わせることで、各ICU滞在の全体像を把握することができます。
図2：Doctor.ai のNeo4jデータモデル
一方で、AWS上でのインフラ構築にも着手しました。AMIのデフォルト設定では制約が多すぎたため、AuraDBやNeo4jのパブリックAMIではなく、カスタマイズしたNeo4jをEC2インスタンスにインストールすることにしました。Lexは、Doctor.aiを支える自然言語理解エンジンです。Neo4jデータベースへのクエリは、ユーザーがDoctor.aiに質問を音声または文字入力で行います。ユーザーの意図を理解すると、LexはLambda関数を起動してNeo4jに対するクエリを実行します。クライアントにサービスを提供するため、Lucas Bassetti氏によるReact Simple ChatbotをベースにしたCI/CDのReactフロントエンドをAmplify上に置きました。（図3）。
図3：Doctor.aiのAWSアーキテクチャ
EC2とAmplifyのセットアップは比較的シンプルなものでした。コーディングのほとんどはLexとLambdaで行いました。Lex は AIの魔法で何気ない会話をすべて理解できるかのような誤解を与えるかもしれません。しかしLex は特化型チャットボットであり、あらかじめ定義されたいくつかのインテントを理解することができるだけで、その一つ一つをプログラマーが実装する必要があります。
それでは、インテント（intent、意図）、発話（utterance）、スロット（slot）の3つの概念について説明していきます。インテントとは、ユーザーがチャットボットに行ってほしいリクエストのことです。例えばユーザが、「ある特定の患者が何回ICUに入院したことがあるかを知りたい」とします。そのためには、ユーザーがチャットボットに言葉を発する必要があります。それが発話です。
例えば、「患者Aさんは何度ICUに入院しましたか？」や「患者AさんのICU入院回数を教えて。」などと発話することができます。 どちらも患者AさんのICU入院回数を求める発話です。この場合、患者の名前がスロットになります。スロットは、クエリを制約するために使うものです。スロットは、現在の発話または前の発話からの値を必要とします。スロットの値がまだ与えられていない場合、Doctor.aiが追加の質問をします。患者の名前がわかれば、Doctor.aiはICU入院回数の計算を試みます。
Lexでは、チャットボットの「Intents」ページでインテントを定義します（図4）。各インテントは主に、サンプル発話、スロット、リクエストを満たすアクションで構成されています。ユーザーがDoctor.aiに発話したり文字入力すると、Doctor.aiはユーザーのインテントを分類しようとします。分類が成功し、すべてのスロットが満たされた場合、Doctor.aiはリクエストを満たすアクションを実行します。最後に、ユーザーのインテントが明確でない場合の「フォールバック・インテント（fallback intent）」を定義する必要があります。
図4：Doctor.aiの「Intents」ページ
「ICU入院回数の取得（CountICUVisit）」のインテントを例として、インテントの設定方法を学んでいきましょう。このインテントは、患者が何回ICUに入院したのかを調べるものです。まず、8つのサンプル発話を定義しました。サンプル発話とは、ユーザーがこのインテントを実現するために、発話する可能性が高い文章のことです。Lexはこれらのサンプルを通して学習し、プロダクション環境で類似した発話を認識するようになります。ある特定の患者一人のICU入院回数を知りたいため、患者の名前をスロットに設定します。
図5：「ICU入院回数の取得（CountICUVisit）」インテント
また、人間同士の会話では、患者の名前を何度も言う必要はありません。名前が一度言及されれば、その後の会話でも、誰のことを言っているのかを双方が分かっているからです（図6）。それをLexで設定するには、「Contexts」を使います（図7）。Doctor.aiに患者のICU入院回数の取得を依頼する前に、「ProvideName（名前の提供）」や「CheckFirstICUVisit（ICU初入院日の確認）」などのインテントで患者の名前をすでに取得している場合が想定できます。ですので、「入力コンテキスト（Input contexts）」でその2つのコンテキストをオンにします。また、「名前」スロットの値を、この2つのコンテキストから得られることをLexに伝えました（図8）。「ICU入院回数の取得（CountICUVisit）」インテントが、その後の会話の入力コンテキストにもなりえるため、「名前」の値を「出力コンテキスト（Output context）」にも設定します（図7）。
図6：スロットの値はコンテキストから取得可能
図7：コンテキストの設定
図8：「名前」スロットの値はコンテキストから取得可能
Lexの設定が完了したら、「Fulfilment」でLambda関数を設定します。Lexはエイリアスを通してLambda関数と接続されています（図9）。
図9：LexのエイリアスにてLambda関数を設定
Lexは発話を受け取ると、「イベント（Event）」オブジェクトをLambda関数に送信します。これは、インテントの名前を含むJSONオブジェクトです。そして、Lambdaは対応する関数を呼び出し、適切なレスポンスを作成します。今回の例では、Lambdaが以下のCypherクエリをNeo4jに送信します。
Lambdaは、Neo4jによって返される結果を次のようなレスポンス発話にまとめます。
LambdaはこのレスポンスをLexに送り返し（図6）、この「コール＆レスポンス」サイクルが終了します。
他のインテントも同様に処理されます。「こんにちは（Hello）」や「名前の提供（ProvideName）」、「フォールバック（Fallback）」などはよりシンプルな処理で対応できます。最も難しかったのは、「治療法のレコメンド（RecommendTreatment）」のインテントの対応です。このインテントでは、医師がDoctor.aiに患者の治療法をレコメンドするよう依頼します。裏では、まず検査結果に基づいて患者間のコサイン類似度を計算しました。
そして、対象となる患者の治療法をレコメンドする際には、まず、同性で、年齢差が10歳未満で、類似度が0.9以上の患者を探します。その類似度の高い患者が同じ病気を患っていて、ある治療を受けているとします。もし対象患者がその治療を受けていない場合は、同治療をレコメンドします。
すべての準備が整った後、ボットを構築し、フロントエンドに接続しました。Reactベースのフロントエンドは、Lucas Bassetti氏によるReact Simple Chatbotをベースにしています。Lexとの通信には、AWSの認証情報やその他のデータを環境パラメータとして使用します。音声入力にはChromeブラウザを使用し、レスポンスの音声にはspeak-ttsパッケージを使用しました。
図10：治療法のレコメンド（Reactベースのフロントエンドにて）
最後に、自分でDoctor.aiを設定してみたい方は、「Doctor.ai, an AI-Powered Virtual Voice Assistant for Health Care」を参考にしてください。
結論
Googleのオープンドメインのチャットボット Meena とは異なり、Doctor.aiは、医療情報学に特化したチャットボットです。そのため、私たち開発者は、ヘルスケア関連の機能を充実させることに集中することができます。現在、Doctor.aiは基本的な機能を備えていますが、まだできることはたくさんあります。
例えば、検査結果が正常な範囲を逸脱している場合に警告を鳴らすことができます。また、Hetionetのようなナレッジグラフを活用することで、治療法のレコメンド機能の的確さを向上させることができるでしょう。医療記録とHetionetの両方がNeo4jに格納されているので、二つの統合を試みることもできます。そうすれば、グラフデータベースでしか処理できない複雑なクエリを実行できるようになるでしょう。
Doctor.aiの音声対話機能も改善が必要です。Chromeは私たちの発話を拾うことはできましたが、間違いが多すぎました。また、speak-ttsパッケージは、「ICU」などの略語周りの間違いが多く、意味不明な回答もありました。これに対し、Alan Voice AI Platformは、入力をその場で修正し、見事な精度を実現できています。そのため、Alanに乗り換えるというのも選択肢の一つになります。
また、現在のDoctor.aiは、AWSに依存しています。この依存関係は、将来的に諸刃の剣になりかねません。AWSは最大のクラウドプロバイダーであり、事業継続性に問題はないでしょう。一方、LexはあくまでSaaSであり、AWSによっていつでも変更、あるいは停止することが可能です。そのため、オープンソースへの切り替えを検討すべきです。しかし、言語AIの育成には資本が必要で、それを負担できるのは一握りの機関だけです。
Datathonのプロジェクトとして、Doctor.aiは、実際に機能する医療用チャットボットが作れることを実証しました。しかし、このようなチャットボットが国の医療システムの一部として使用されるのはいつ頃になるのでしょうか？これは技術的な問題だけでなく、政治的、倫理的な問題でもあります。しかし、患者や医師が個人的にこのバーチャルアシスタントを使い、自分のカルテを管理することは可能です。ですので、ボトムアップで採用していくことも可能です。
