「自然言語処理」プロジェクトを円滑に進めるためのポイント

タスクと目的を明確にする

データ分析のプロジェクト全般に言えることですが、分析の目的を明確にすることは最も重要です。自然言語処理の場合、下記のような種類のタスクが存在します。

• 文書分類：事前に定義したカテゴリに文書を分類するタスクです。メールのスパム判定や口コミの感情分析など、さまざまな用途に使われています。
• 情報抽出：商品名などの固有表現認識、固有表現の曖昧性解消、固有表現同士の関係抽出、ゼロ代名詞などの照応解析といったタスクの総称です。
• トピック抽出：大量の文書から潜在的なトピックを抽出するタスクです。文書のクラスタリングや、類似コンテンツのレコメンドなどに使われます。
• 文章校正：文章中の誤字・脱字・衍字などの入力誤りを修正するタスクです。記事の校正業務や、検索クエリの修正などに使われています。
• 文章要約：長い文章の要約を作成するタスクです。文章中から重要な箇所を抜き出す抽出型要約と、新しい要約文を作り出す生成型要約に分けられます。
• 情報検索：ユーザーのクエリに関連する文書を検索するタスクです。一般的な検索エンジンだけでなく、社内文書の検索システムなどにも利用できます。
• チャットボット：対話システムを構築するタスクです。FAQやチケット予約などのタスク指向型が一般的ですが、自由な会話ができる雑談型も注目されています。

自社で保有しているテキストデータを活用したい場合、どの業務にどのタスクが適用できるかを検討します。大量の商品レビューにカテゴリやタグを自動で付与したければ、文書分類やトピック抽出を適用することが考えられますし、SNSの投稿から自社の製品やサービスに言及している表現を抽出したければ、固有表現認識を使える可能性があります。

ビジネス活用の観点では、単にタスクを選択するだけでなく、業務上の利用目的をセットで決めることが肝要です。商品レビューの分類タスクであれば、顧客からの要望のカテゴリに応じた担当部署への転送、タグ検索によるユーザーの利便性向上、トピックの件数に基づくインシデントの早期発見と対処、などの用途が挙げられます。

適切なアプローチを選択する

プロジェクトの目的を明確にしたら、タスクを解くための具体的なアプローチを考えます。BERTなどのTransformerをベースにしたモデルは、現在の自然言語処理分野における大きなトレンドです。しかしながら、Transformerをはじめとする深層学習モデルをビジネスで用いるのは容易ではありません。

深層学習モデルは、従来の機械学習モデルと比べて表現力が豊かな反面、学習に多くのデータを必要とします。大量のテキストデータやラベルを収集するためには多大な労力を必要としますし、GPUを用いた並列計算やモデルの継続的な運用にもコストがかかります。時には、モデルの解釈性が低いことや、推論時のレイテンシなども問題になるでしょう。

このような状況では、深層学習以外のアプローチから始めることも視野に入れるべきです。ルールベースや正規表現、辞書ベースなどのヒューリスティクスは、単純ながら実用的なアプローチです。文書分類ならナイーブベイズ、固有表現認識ならCRFのように古典的な機械学習モデルでも十分な可能性はありますし、ルールベースと機械学習を組み合わせた複合的なアプローチも効果的です。Google Cloud Natural LanguageやAmazon Comprehendのように、クラウドの自然言語処理サービスを利用する手もあります。

何よりも重要なのは、シンプルなアプローチを素早く試行することで、問題に対する理解が深まり、評価指標や速度の面でベースラインが得られるということです。ベースラインを基に課題を洗い出し、プロジェクトの関係者から早期のフィードバックを得ることで、効率的な改善のサイクルを回すことができます。最初から複雑なアプローチを試すことは、問題の理解と改善のサイクルを遅らせ、プロジェクトの成功確率を下げる要因となります。

運用の条件として高い予測精度が要求される場合、十分な量のデータセットを用意することが可能であれば、深層学習によるアプローチが有効です。深層学習以外のアプローチを選択した場合でも、データの蓄積に伴い、後から深層学習に移行するための計画を立てることができます。以降では、Transformerを用いることを念頭において話を進めます。

モデルの性能はデータセットで決まる

「Garbage in, Garbage out」という言葉があります。どんなに高性能なモデルを用いたとしても、使われているデータや特徴量の品質が悪ければ、出てくる分析結果の品質も悪くなるということです。人間がラベル付けしたデータをモデルに学習させるとき、モデルが人間の基準を超えることはありません。また、学習データに含まれないパターンをモデルが認識することもできません。高品質かつ多様性のあるデータセットを用意することは、モデルの予測精度を向上させるために不可欠なのです。

テキストや画像などのデータに対し、正解ラベルを付与する作業はアノテーションと呼ばれます。文書分類であれば、文書を1件ずつ読みながら該当するカテゴリを選択し、物体検出であれば、画像を1枚ずつ見ながら検出対象を枠で囲むといった作業です。アノテーションはしばしばドメイン知識を必要とするため、社内のエキスパートに頼めるのが理想ですが、通常業務の傍らで大量のアノテーションをやってもらうのは現実的ではありません。

解決策の一つは、アノテーションのサービスを提供する企業に依頼することです。大手からベンチャーまで多くの企業がアノテーションを手がけており、対応範囲や料金プランも異なるため、複数の企業を比較しながら検討するのがよいでしょう。弊社でも多くのプロジェクトでアノテーションを依頼した実績があり、お客様との間に立って作業の品質を管理することもあります。単純なタスクであれば、クラウドソーシングを活用する方法もあります。

もう一つの解決策は、外部のサービスに頼らずに自力でデータセットを構築することです。たとえば、社内のエキスパートに少量のデータをアノテーションしてもらい、そのデータを学習したモデルを使って、ラベル付けされていないデータを予測します。予測に自信のないデータは優先的にアノテーションし、学習データに追加して再学習します。このサイクルを繰り返すことで精度を高めるプロセスは「アクティブラーニング」と呼ばれ、通常のアノテーションよりも効率的な学習を可能にします。

BERTなどのTransformerモデルは、大量のラベルなしデータで事前学習されたモデルを、解きたいタスクに合わせて少数のラベル付きデータで転移学習するのが一般的です。一方、オープンソースのモデルはWikipediaなどの汎用的なテキストで事前学習されていることが多く、ドメインが大きく異なる場合は多くの正解データを必要とします。対処法としては、正解データを学習する前に、ラベル付けされていない大量のドメインテキストで事前学習を行う「ドメイン適応」が有効です。

アノテーションで失敗しないために

アノテーションを自社で行う場合でも、外部に委託する場合でも、アノテーターの間で認識を合わせて基準を統一することは極めて重要です。たとえ社内のエキスパートであっても、人によって細かい基準や暗黙知にギャップが存在することは少なくありません。文書分類であれば、各カテゴリの定義や具体例をできるだけ詳細に言語化し、ドキュメントなどで事前に共有するとよいでしょう。実際にアノテーションを始めてから、判断に迷うケースが見つかることも多いため、ドキュメントの内容は随時更新することを想定します。ただし、カテゴリの定義を変更したりするとアノテーション済みのデータに影響が出るため、対応可能な範囲の修正に留めて下さい。アノテーターによって品質に差があると思われる場合、カッパ係数などを用いてアノテーター間の一致度を測定することもできます。

Transformerの学習に必要となるアノテーションの件数ですが、これはドメインやタスクの難易度、予測精度の目標などに依存するため一概には言えません。参考までに弊社の事例をお話すると、数十のカテゴリに対する文書分類タスクであれば、最低限のパフォーマンスを発揮するために1カテゴリあたり最低でも100件は必要で、1カテゴリあたり1,000件程度あれば、Average Precisionと呼ばれる評価指標で90%前後の安定した精度を達成できることが分かりました。

繰り返しになりますが、条件次第ではこれよりも少ないデータで済むかもしれませんし、より多くのデータが必要になるかもしれません。重要なのは、いくらデータを増やしたところで「予測精度が100%に到達することはない」ということです。どれくらいの誤差なら許容できるか、許容範囲が狭い場合は、予測に自信のない一部のサンプルを人間がチェックする「ヒューマン・イン・ザ・ループ（Human-in-the-loop）」の運用を取り入れるなど、モデルの運用方針について社内の合意を得る必要があります。モデルが未熟でもとりあえず運用を始め、本番環境で得られるデータや現場からのフィードバックを反映することで、逐次的なモデルの改善を図ることも合理的な選択肢の一つと言えるでしょう。

プロジェクトの成否を分けるもの

上記で紹介した内容以外にも、自然言語処理プロジェクトを推進するためにはさまざまなことを考える必要があります。技術的な内容が多くなるため、本稿では詳細を割愛しますが、いくつかのポイントを紹介したいと思います。

モデルの性能に影響を与える要因は、データセットだけではありません。前処理、特徴量、モデルアーキテクチャ、ハイパーパラメータ、学習のテクニックなど多くの要因が存在します。これらのチューニングには専門的な知識や経験を必要とするため、自然言語処理や深層学習に詳しいデータサイエンティストなどをアサインすることが望ましいです。

タスクに応じた適切な評価指標を設定することも重要です。文書分類であれば、混同行列・再現率・適合率・F1スコアなどの定量的評価、予測を誤ったテキストの定性的評価、予測の判断根拠をLIMEやSHAPで可視化する解釈可能性の評価などを用います。さらにモデルの指標だけでなく、ビジネスの指標を評価することでステークホルダーを納得させる必要があります。冒頭の例で挙げた、顧客からの要望を分類して担当部署に転送するためのモデルを評価する場合、要望への対応に要する時間がどれだけ短縮されたか、要望が無関係の部署にどれだけ誤って転送されたか、といった指標が考えられます。

学習したモデルは、APIコールなどの形でシステムが予測結果を利用できるようにデプロイする必要があります。昨今では、Vertex AIやSageMakerのようなクラウドの機械学習プラットフォームを用いる事例も増えています。その他にも、スケーラビリティ、モデル更新の頻度、メトリクスの監視、アラートの仕組み、CI/CDなどの視点で、MLシステムに必要な機能を考えることになるでしょう。このような機械学習モデルを運用するための方法論は「MLOps」という分野で広く議論されています。MLシステムの開発や運用を行うメンバーには、エンジニアや機械学習エンジニアが適任と言えます。

プロジェクトを円滑に進めるためには、ステークホルダーの理解を得ることが不可欠です。経営層に対しては、ソリューションの導入で期待されることや、費用対効果などについて、正しく説明する必要があります。現場に対しては、オペレーションに与える影響の説明や、アノテーションの協力を依頼することも必要になるでしょう。

データサイエンティストやエンジニアを社内でアサインするのが難しい場合は、受託分析サービスなどを利用することが可能です。弊社でも、Transformerの専用モジュールや事前学習済みモデルを開発し、実際のプロジェクトに活用しています。Transformer以外の自然言語処理プロジェクトの事例もございますので、お気軽にお問い合わせ下さい。

最後になりますが、本稿が自然言語処理やTransformerのビジネス活用を促進するための一助となれば幸いです。

※DXについて詳しく知りたい方はこちらの記事をお読み下さい。
【関連】DX（デジタルトランスフォーメーション）とは？「DX＝IT活用」ではない。正しく理解したいDXの意義と推進のポイント