医療ドメインの自然言語処理に飛び込んで1年経って見えてきたこと
2021-06-23
医療スタートアップのUbieに入社して1年が経ちました。これまでの人生で一番短かったんじゃないかというくらいのスピードで月日が過ぎ去っていき、主体的に携わるプロジェクトも1.5周くらいしたところかなと思います。この記事では機械学習エンジニアの私が、医療というドメインの自然言語処理に携わるなかで考えたことを紹介したいと思います。
最近ではリーガルテックをはじめ、HR、ファイナンス、そして医療など、様々な領域で自然言語処理の活用が広がっています。そうした専門ドメインでの自然言語処理に携わる人も増えてきていると思いますので、その中の一例として何かしら参考になれば幸いです。
【目次】
- 医療という専門領域の知識は必要
- 分野が違っても手法は同じ、研究が扱う題材を知っておく
- 医療という特殊なデータ事情
- なぜ私はいま医療言語処理をやるのか？
- まとめ
医療という専門領域の知識は必要
機械学習で何を解くのかというタスク設計において、医療ドメインの知識は必要不可欠だと感じます。どういった問題やデータに対して、どういった入力/出力を設計し、どうプロダクトに適用するかを、機械学習エンジニアは常日頃考えているわけです。そのあらゆる状況において、医療ドメインの知識は活かされています。
実際に私が遭遇した例を、幾つか紹介しましょう。詳しくは書けませんが、ある病気の症状やその状態を文書中から抜き出すタスクに取り組むことになりました。病気の症状というと「38度の熱がある」とか「昨日から頭が痛い」とか「足首を捻挫した」など、そういったものを想定してください。あまりきっちりとしたタスク定義ができない問題だったのですが、どういう情報を取得できれば価値があるかという問題設定からタスクを検討し始めたなかで見つけたのが、医師が問診の現場で利用する「OPQRST法」というフレームワークでした。これはOnset, Palliative/Provocative, Quality/Quantity, Region/Radiation, Symptoms associated(Severity), Time courseの頭文字を取ったもので、Oはいつから発症したか、Pはどういう時に痛くなる/痛くなくなるかといったように、この枠組みで患者の症状(病歴)を聞くことが良いとされています。これを踏まえて、このタスクではOPQRSTの各項目に対して情報抽出を行うというアプローチを取るということにしました。病気の症状というのは一般の人も知っている概念なので、どうしてもその知識の範囲内だけで捉えてしまいがちですが、医師の目線での体系を使うことでよりタスク定義が明確になったと思います。
また、推論結果のプロダクトへの適用という意味では、既に存在するID体系やオントロジー、リソースといった外部の知識とどう対応付けるかが一つ重要になってきます。つまり、すでに体系立てられているものに寄せて開発したほうがいいよという話です。例えば、文書中から病気の名前を抽出しましょうというタスクがあったときに、その病名の文字列だけを取得できればいいというケースは稀でしょう。その病気の詳細情報を表示したり、インデックスとして利用して検索システムに利用したり、病気に対して何かを紐付けたりと、なんらかダウンストリームのタスクに利用しますが、その時に必要になるのが病気の概念を表したIDです。日本では現在ICD-10と呼ばれる国際疾病分類に従った管理がされており、様々なデータがICD-10準拠になっています。自然言語処理のコーパスにおいても、万病辞書の病気の分類にも採用されています。この他にも様々な医療の概念に対してIDが付与されたり、標準化規格が策定されています。目の前のデータの中だけで精度高く解ければそれでいいということもありますが、既存のID体系やオントロジーに乗っかる方が正確であったり外部知識との接続も容易になることが多く、将来的な汎用性や網羅性に繋がります。こうしたシステムで利用する目的の規格などは医師も知らない場合が多く、エンジニアサイドが主体的に調べて知識を深めていく必要があります。
このように、解くべき問題の背後にある理論や知識は、機械学習タスクを設計する上で重要です。といっても医師と同じような知識が必要というわけではなく、病気や治療に対するモノの捉え方を理解したり、体系化された情報をどう活用するかがポイントと言えます。
分野が違っても手法は同じ、研究が扱う題材を知っておく
専門ドメインでの自然言語処理と言っても、解くべきタスクのデータや性質が異なるだけで、手法としての自然言語処理は共通している場合が多いです。文中からの情報抽出であればCRFやRNN/LSTM、Transformerが使えますし、他にも検索や名寄せ、ポジネガ判定、文書の類似度算出など、広く研究される自然言語処理のタスクの技術をそのまま利用できます。使える道具は共通しているので、そこに関して知識があれば別ドメインに移ることはそう難しいものではありません。
ちなみに分野を俯瞰するという意味では、実際に解かれているタスクを見るのが一番の近道です。私の場合は、はじめにNAIST荒牧先生の「医療言語処理」を読み、あとは適宜タスクが見えてきたら個別にサーベイをして補完していくという流れで進めました。言語処理学会の年次大会の論文から医療に関するものを見つけてきて一通り目を通したり、あとはカンファレンス内で開かれる医療系のワークショップなどは分野に明るくない身としてはとても役に立ちました。
ちなみにUbie入社後ちょっとしてから書いた下記の記事は、一通り実験したあとに類似研究があることに気づいて慌てて言及した記憶があります。何をするにしてもサーベイはやっぱり大事です。
医療分野の大規模テキストデータで学習した分散表現から、疾患の類似度を求める - Out-of-the-box
医療という特殊なデータ事情
ここが医療言語処理の一番の特徴だと思いますが、とにかくデータが無いです。なさすぎて困っています。
無いというのは少し語弊がありますが、もうすこし正確に記述すると、パブリックにアクセスできるコーパスや言語資源に乏しく、病院をはじめ医療関係の企業や研究室といった組織に偏在しているという感じでしょうか。そして色々な自然言語処理のドメインにおいて、医療ほどデータを集めにくい分野は他にないんじゃないかと思います。その理由としては、以下の2つがあります。
- 電子カルテや診療記録といった治療行為に関する情報は個人情報の塊であり、容易にアクセスできず、かつ利用が強く制限されるということ
- 医師や看護師といったドメインエキスパートの労働力は高単価であること
つまり、元となるデータはないわ、作るのにコストがかかるわ、の二重苦なわけです。何かしようと思ってもそもそも機械学習のスタートラインに立てないというのが、毎度おなじみの光景になっています。なので、基本はデータを作るところから始めます。社内DBやウェブサイトなどから使えそうなデータがないか探したり、教師あり学習の場合はアノテーションも付与する必要があるので、こちらもクラウドソーシングや業務委託に依頼するといった形で準備する必要があります。distant supervisionのような半教師有りといった方向に持っていくこともできますが、評価データやベースラインが定まっていない開発初期に採用することはあまりないです。
そうしてデータを作る間にもまだまだやることはたくさんあります。プロダクト開発では、なるべく早い段階で動くモノがあると、依存する他のサービスを作りやすくなります。しかしデータ作成にはリードタイムがありますから、まずはルールベースや簡単なモデルから作り始めます。すると性能を評価をしたくなりますが、評価データもあったりなかったりで、モデルを評価するにも性能向上するにもデータ作成が律速になってしまいがちです。
一方で、医療ドメインでも集めやすいデータが存在するので、そちらを利用する場合はちょっと状況が異なります。例えばTwitterでユーザが発言する病気や症状のテキストであったり、企業の中であれば提供しているウェブサービスが利用される中で得られる各種情報。Googleの研究者らがユーザの検索履歴を元にインフルエンザの流行予測を試みた「Googleインフルトレンド」の話は有名ですね（ちなみに予測はのちに有効ではなかったと結論付けられています link）。他には論文のデータはpublishされているという理由で扱いやすく、英語圏ですと特にPubMedという生命科学に関する論文データベースから、大量の論文のアブストラクト取得することができます。また前節で言及したオントロジーなどの知識ベースも、うまく活用するとよい情報源となります。
このように医療というドメインの性質がデータ収集や利用に強く影響するなかで、なかなか機械学習という枠組みに乗りにくいのが実情です。
なぜ私はいま医療言語処理をやるのか？
最後に大事な話を一つ。なぜ私はいま医療言語処理に携わるのか？という、もっとも根本的な問いがあります。それは入社時と比べて、より明確になったと思います。
まず第一に社会的な意義。この1年は私にとってUbieの1年であったと同時に新型コロナウィルスの1年でもあったわけですが、医療や健康に対して特に考える機会が多かったと思います。一介の機械学習エンジニアの自分にできることはなんだろうと考えるなかで、医療に対して直接的な貢献はできなくても、医療ベンチャーの一員として手伝えることがあるだろうと改めて思い直しました。世間ではAIや人工知能といった流行で持て囃される業種ですが、真にユーザに価値を届けられる仕組みを作るのはとても大変なことです。そこに対して自然言語処理という領域で取り組むことで、少しでも医療に貢献できればと思っています。
そして第二の理由としては、医療言語処理のプレイヤーの少なさと将来性。特にプロダクト開発/エンジニアリングにおいてプレイヤーは少なく、手のつけられていない課題がたくさんあると思っています。もちろん医療というドメインはその性質上どうしても閉鎖的になりがちな分野で、実際には言語処理関係の仕事をされている方が多数いらっしゃるのは認識しています。そうした制約がある上で分野としての裾野を広げるためにも、共通した言語資源の整備やタスク特化の手法の開発、そして医療言語処理での成功事例の蓄積など、そこに好機を見出して挑戦していくのが楽しいフェーズだと思います。私はこうした知識の共有やアウトリーチ活動が好きなので、個人的な趣向とも一致しています。
まとめ
少し長くなってしまいましたが、この記事では私が医療言語処理という医療ドメインの世界に飛び込んだ中で感じたことを紹介しました。一言で言い表すと、制約だらけの未開の地で大変だけどそのぶん楽しいよ！という感じです。冒頭でも述べたように自然言語処理には医療に限らず色々なドメインが存在しており、医療とは違った形の難しさや挑戦があるのだと思います。そうした自然言語処理がより盛り上がっていくのが楽しみですし、医療言語処理に対しても少しでもそのお手伝いが出来ればと思っております。
さて、Ubieでは、こうした医療言語処理を使ったプロダクトを一緒に開発していく方を募集しております。ご興味がありましたら、ぜひ気軽にご連絡ください。お待ちしております！
