目次


DevOps をコグニティブおよび人工知能システムに適応させる

Apply DevOps to the training process

Comments

コグニティブ・システムは、これを背後で支える強力なインテリジェンスを使用して新種のアプリケーションを構築する絶好の機会を提供しますが、このような新しいアプリケーションを開発するプロセスには新しい考え方が必要です。従来型のアプリケーション開発は DevOps の考え方によって強化されました。DevOps の考え方に従うと、運用上の考慮事項を、開発段階、実行、プロセスに取り入れざるを得なくなります。このチュートリアルでは、新しいコグニティブ・アプリケーション向けに DevOps の最良の部分を改良して適応させる「コグニティブ DevOps」プロセスの概要を説明します。具体的には、トレーニング・データ、モデル化、パフォーマンスの評価を含め、コグニティブ・システムのトレーニング・プロセスに DevOps を適用する方法を見ていきます。

コグニティブ・タスクのタイプ

基本的に、コグニティブ・システムまたは人工知能 (AI) システムはデータを基に理解、推論、学習するといった能力を提示します。さらに深いレベルでは、これらのシステムは各種のコグニティブ・タスクの組み合わせを活かして構築されます。コグニティブ・タスクが組み合わされることで、全体的なコグニティブ・アプリケーションの一部になるという仕組みです。コグニティブ・タスクには、以下のタイプがあります。

  • エンティティーの抽出
  • パッセージの取得
  • テキストの分類
  • トーンと感情の検出
  • 知識の抽出
  • 言語翻訳
  • 音声テキスト変換
  • コンピューター・ビジョン
図 1. コグニティブ・タスク
AI システムのコンポーネントと成分を示す図
AI システムのコンポーネントと成分を示す図

コグニティブ・システムの基礎となる技術の一部として、深層学習や自然言語処理などの機械学習 (ML) があります。上の図に示されているコンポーネントのひとつひとつが、コグニティブ・システムの 1 つ以上の能力 (理解、推論、学習、対話など) を実証することができます。これらのコグニティブ・システムが実用的な洞察と知識を引き出すために活用する、内部データやサード・パーティーからのデータ、購入したデータ、オープンソースのデータには、構造化データと非構造化データの両方が含まれます。

構造化データは簡単にデータベース内で編成して鑑別することができますが、非構造化データはそれとは異なり、従来は人間が理解しなければなりませんでした。非構造化データの例は多数ありますが、中でも代表的なものとしては、自然言語で作成されたドキュメント、録音、画像、さらにはソーシャル・メディアの投稿があります。このような (非構造化) データは、例えば調査レポート、ローンの書類、メモ、コール・センターの録音、製品レビューなど、企業内で日常的に扱うものです。

図 2. 企業内外に見られるさまざまなタイプの非構造化データ
AI システムで使用されるさまざまなタイプの非構造化データを示す図
AI システムで使用されるさまざまなタイプの非構造化データを示す図

コグニティブ・システムまたは AI システムをトレーニングするには、教師あり学習の手法を使用します。この手法では、1 人または多数の対象分野の専門家 (SME) によって作成された、ラベル付きグラウンド・トゥルースが用いられます。グラウンド・トゥルースとは、それぞれの学習アルゴリズムが適合または順応する「究極の判断基準」となるデータを表します。グラウンド・トゥルースを作成するプロセスは、コグニティブ・システムのトレーニングとテストの両方において極めて重要な意味を持ちます。また、グラウンド・トゥルースの作成プロセスの一環として、特徴エンジニアリング・ステップも並行して行われます。深層学習ベースの手法を採用する場合や、IBM Watson のプラットフォーム API を利用してトレーニングする場合は、グラウンド・トゥルースに基づいて特徴が自動的に選択されます。

モデルとシステムのトレーニングが完了してデプロイされても、それで仕事が終わったわけではありません。コグニティブ・システムを最新の状態に維持し、新しいデータの観測と相互作用による学習を続ける必要があります。それには、トレーニング・データをさらに追加するだけでなく、AI システムが使用するコードやモデルに変更を加えることになるはずです。また、機械学習で使用する新しい特徴を仮説として作成することになるでしょう。そのような仮説の中には良い結果になるものも、ならないものもあります。このプロセスは、試行錯誤が必要な反復型プロセスなのです。

機械学習

従来、コンピューターのプログラミングは、そのコンピューターが従うべき一連のステップを明示的にコード化するという方法で行われてきました。例えば、「A > 0 である場合、X を実行する」といった具合にステップをコード化します。このように特定のタスクを実行するステップの論理的セットは、アルゴリズムと呼ばれます。ほとんどのソフトウェアは、この方法で作成されてきました。

ステップのセットをコード化するという方法は、ある職務を遂行するために従うべき手順を人間に教えることに似ています。例えば、人間にカードを配る方法を教えるには、一組のカードの一番上から 1 枚ずつカードを取り、すべてのカードを配り終えるまで左から時計回りの順で配っていくように指示します。人間には言葉による指示を出すことによって、このようなステップを教えることができます。けれどもコンピューターの場合は、実行すべきステップをコード化するためにプログラミング言語を使用する必要があります。プログラミング言語は徐々に水準を高め、簡単に使えるようになってきています。それでも、プログラミング言語を実装するにはソフトウェア開発に熟練した人間が必要であるという状況は変わっていません。

コンピューターにタスクを実行する方法を教えるもう 1 つの手法は、機械学習を使用することです。ML が問題の解決に取り組む方法は、一連のステップを使用するのではなく、一連のサンプル (グラウンド・トゥルース) を使用して、特定のタスクを実行するようにコンピューターをトレーニングするというものです。この過程は、人間が動物の見分けかたを習得する方法に似ています。幼い子供に犬の写真を何枚か見せると、子供はすぐに犬を見分けるようになります。それと同じように、一連のサンプルを使用して、犬を見分けるようにコンピューターをトレーニングすることができます。

従来型のプログラミングと同様に、機械学習は歴史的にコンピューター・サイエンティストとデータ・サイエンティストの領域となっています。ML のいくつかの部分に関しては引き続きコンピューター・サイエンティストに任せるのが最善ですが、最近では機械学習の特定分野でのユーザー・インターフェースの進歩により、コンピューター・サイエンティストに代わって SME がシステムをトレーニングできるようになっています。そのようなユーザー・インターフェースの一例が、(言語構成体に詳しい) SME とがん専門医向けに設計された Watson Knowledge Studio です。ML を使用することで、Watson Knowledge Studio では SME とがん専門医がソフトウェア・エンジニアと協力してコグニティブ・システムを構築できるようになっています。

コグニティブ・アプリケーションの開発に伴う最も重要な側面は、トレーニング・データの可用性です。コグニティブ・システムをトレーニングするために必要となるトレーニング・データの量を決定する要因はいくつかありますが、そのうち最も重要な要因としては、データの変動性、目的とする精度レベルの 2 つが挙げられます。トレーニング・データを作成するのに最もふさわしい立場にいるのは、その特定の主題を最も知り尽くしている SME です。

トレーニングのライフサイクル

AI システムのトレーニングのライフサイクルを理解するために、具体的なプロセスとして CRISP-DM (Cross-Industry Standard Process for Data Mining) を見ていきます。CRISP-DM は標準化された手法であり、コグニティブ・システムを駆動および編成する各種のモデルを作成するために導入できます。CRISP-DM のライフサイクル・モデル (以下の図) は 6 つのフェーズからなります。図中では、フェーズ間の最も重要かつ一般的な依存関係を矢印で示しています。フェーズの順番は厳格に決まっているわけではありません。トレーニングの意味合いとステップは、AI タスクまたはワークロードのタイプによって異なりますが、基本的なところに変わりはなく、フェーズ全体は同じです。

図 3. CRISP-DM のライフサイクル・モデル
CRISP-DM のライフサイクル・モデルを示す図
CRISP-DM のライフサイクル・モデルを示す図

別の一般的な見方としては、このプロセスは以下の図のように表すこともできます。以下の図に示されているプロセスでは、フィードバックのモニタリングと収集という追加のステップがサイクルに含まれています。この 2 つの重要なステップは、システムを使用して徐々に改善を加えていく際に役立ちます。

図 4. ステップが追加された CRISP-DM のライフサイクル・モデル
ステップが追加された CRISP-DM のライフサイクル・モデルを示す図
ステップが追加された CRISP-DM のライフサイクル・モデルを示す図

トレーニング・データ

機械学習は、教師あり学習と教師なし学習の 2 つに分類できます。その違いは、モデルが学習して予測しなければならない正解を提供するかどうかという点です。教師あり ML では、トレーニング・データに正解 (「ラベル付き」データと呼ばれます) が含められます。トレーニング・データに正解が含まれていれば、アルゴリズムによって、その特定の正解を導くことになる入力の組み合わせを推測できます。最も広く使われている教師あり学習アルゴリズムには、サポート・ベクター・マシン、ランダム・フォレスト、線形回帰、ロジスティック回帰、単純ベイズ、ニューラル・ネットワーク (多層パーセプトロン) があります。

教師なし ML では、トレーニング・データにラベルは付けられないため、アルゴリズムは同様のデータのグループを判断することに限定されます。深層学習の場合でも、モデルをトレーニングするためにはラベル付きデータのセットが必要となりますが、特徴エンジニアリング・ステップはほとんど自動化されます。

強化学習の手法も広く使われるようになってきています。強化学習は、モデルまたはアルゴリズムがフィードバック・システムを通して学習するという手法です。自動走行車やドローンなどのロボット工学アプリケーションで広く使用されています。

トレーニング・データの例

演習として、さまざまな予測因子から住宅の販売価格を推測するシステムを見ていきましょう。ML で一連の入力値から出力を推測する必要がある場合は、一連の入力とラベル付き出力が必要になります。

サイズ (平方フィート) 寝室の数 浴室の数 エーカー数 販売価格
2000 3 2 0.3 250,000
1500 2 2 0.2 200,000
1600 2 1.5 1.2 280,000

入力列の数を 50 で乗算し、その積と同じ数の行をラベル付きトレーニング・データとして提供すればよさそうです。この例には 4 つの入力 (サイズ、寝室の数、浴室の数、エーカー数) があるので、堅牢なモデルにするには 200 行のトレーニング・データが必要になります。

次は、自然言語処理の演習を見ていきましょう。この演習では、特定のタイプのデータをプレーン・テキストから抽出します。トレーニング・データには、テキストからの複数の抜粋、抽出するデータのタイプ、そのデータの位置が含まれています。

テキストアノテーション
The quick brown fox jumped over the lazy dog. Animal[fox](16,19)
Animal[dog](41,44)
The cow jumped over the moon. Animal[cow](4,7)
Location[moon](24,28)
The dish ran away with the spoon. -

この場合の確かな経験則としては、タイプごとに 50 の肯定的なサンプルと 50 の否定的なサンプルをグラウンド・トゥルースとして提供します。抽出する必要があるすべてのパターンをモデルが学習できるよう、トレーニング・データには十分な変動性が必要です。また、収集して比較するグラウンド・トゥルースは、通常は 80:20 の割合でトレーニング・データとテスト・データに分けます (60:40、70:20:10 などの他の割合はいずれも一般的ではありません)。テスト・データとして使用するデータの割合を増やせば、分析モデルのパフォーマンス検証の信頼性が高くなります。トレーニング・データの量が少なすぎると、モデルが学習するためのデータが少ないことから、過少適合という結果になります (アルゴリズムが示すバリアンスは小さい一方、バイアスが大きい)。一方、トレーニング・データ・セットの割合がテスト・データ・セットを上回っていると、過剰適合という結果になります (アルゴリズムが示すバイアスは小さい一方、バリアンスが大きい)。過剰適合と過少適合のいずれにしても、新しいデータ・セットに対するモデルの予測能力とパフォーマンスの欠如という結果を導きます。したがって、コグニティブ・システムのトレーニングにおいては、代表的なグラウンド・トゥルースを選択することが極めて重要になります。

トレーニング手法の概要

わかりやすい例えとして、AI システムを大学の学生だと考えてください。大学の学生は対象分野について学習するために、最後のページに正解が載っている宿題に取り組みます。学生は、問題に取り組み、その正解を調べながら自習を進めることで、対象分野に対するメンタル・モデルを改善していきます。中間試験の前に、学生は模擬試験を受けて、自分の成績を評価します。模擬試験では宿題とは別の質問が出題されますが、これらの質問は概して同様のものです。最終的に、学生は中間試験を受けます。中間試験では、これまでに見たことのない質問が出題されます。この中間試験の成績は、学生が自分の知識をどれだけ上手く適用できるかを示す最良の標識になります。この例えでは、宿題で取り組む問題がトレーニング・データ・セットに相当し、模擬試験がテスト・データ・セットに、中間試験がブラインド・セットに相当します。

サンプルでどれだけの量のトレーニング・データが必要になるかについては、このリンク先の記事「Why does machine learning require so much training data」を参照してください。トレーニング・データのキュレーションに長い時間がかかる理由に関するいくつかの見解については、このリンク先の記事「Machine learning is just the tip of the iceberg—5 dangers lurking below the surface」を参照してください。

自然言語処理システムをトレーニングする際の最初のプロセス

以下の図に、NLP ベースのシステムをトレーニングする際の最初のプロセスに含まれるステップを示し、図の下にこれらのステップをリストアップします。さらに具体的に言うと、この図に示されているステップは、前に説明したコグニティブまたは AI システムの 1 つの側面を表すエンティティー抽出モデルをトレーニングするために必要となるものです。

図 5. エンティティー抽出を対象とした NLP トレーニング・プロセス
NLP トレーニング・プロセスを示す図
NLP トレーニング・プロセスを示す図
  1. 型システムの設計。抽出する必要があるエンティティーと関係を定義して体系化します。これらの定義と体系化はビジネス目標に基づきます。また、業界標準が使用されることも、組織ごとのオントロジーが使用されることもあります。
  2. コーパスのインポート (前処理を含む)。このステップは、情報を抽出するために NLP によって処理する必要がある自然言語テキストの代表的なサンプルを収集してインポートすることを意味します。このステップには、ドキュメントを前処理してグラウンド・トゥルースとして使用できるようにするために必要なタスク (フォーマット変換やチャンク化など) も含まれます。
  3. 辞書の作成。このステップでは、同様の用語を集めた辞書を定義します。辞書は用語辞典と同じようなものです。例えば、データから通貨の概念を探り出すとしたら、通貨辞書を定義します。その辞書内に、通貨に関連する「ドル」、「セント」、「USD」などの用語を含めます。
  4. 事前アノテーション。このステップでは、事前定義した辞書とその他すべてのルールをコーパスに適用します。これにより、トレーニング・データのベースラインを作ります。
  5. 人間によるアノテーション。このステップでは、人間がコーパスに集められたドキュメントをレビューします。ドキュメントには辞書とルールに従って事前にアノテーションが付けられることから、ドキュメントにはすでにアノテーションが含まれています。レビューアーはそれらのアノテーションをレビューし、誤って付けられているものがあればそれを修正し、システムが見落としたアノテーションがあればそれを追加します。こうすることにより、システムが次のステップで正確なトレーニング・データを使用できるようになります。コンテキストに基づいてエンティティーをマークする条件を人間がシステムに教える手段にもなっています。複数のアノテーターが重複するドキュメントに一貫して同じアノテーションを付けるよう、データ競合のトレーニングを行わなければならない場合もあります。その場合、誰かがレビューアーの役割を務めて、アノテーター間の合意 (IAA) スコアを調べ、アノテーションが付けられたドキュメント内の競合を解決する必要があります。
  6. 機械学習モデルのトレーニング。このステップでは、該当するエンティティー、関係、属性を抽出可能な、機械学習ベースのアノテーション・モデルを実際にトレーニングします。このステップには正しい特徴一式を識別するというタスクが伴う場合があります。IBM Watson Knowledge Studio のようなツールを使用する場合は、自動的に特徴の選択が処理されます。このステップでは、トレーニングで使用するためのドキュメント一式を選択するだけでなく、それらのドキュメントのうち、トレーニング・データ、テスト・データ、ブラインド・データのそれぞれに使用する割合を明確にする必要もあります。さらに、機械学習アノテーターをトレーニングするために使用するドキュメントは、承認または裁定によってグラウンド・トゥルースとして認められたものだけに限ってください。
  7. ルール・モデルの識別と作成。このステップでは、コーパス内に出現するエンティティーにアノテーションを付ける際の決定論的ルールを定義します。これらのルールは少なくとも大抵の場合は正確でなければなりません。ただし、100 パーセント正確なルールにする必要はありません。その理由としては、NLP で 100 パーセントの精度が達成されることはないこと、ルールが当てはまらなければ、後のステップでトレーニング・データを調整する機会があることがあります。
  8. 分析のモデル化。このステップでは、トレーニング済みモデルのパフォーマンスをレビューして、アノテーターに調整を加えなければならないかどうかを判断します。これにより、有効なエンティティーに関する言及、関係に関する言及、および同一指示を、ドキュメントから検出するアノテーターの能力を強化します。また、メトリックをレビューして、システムの精度を判断します。重要なメトリックには、F 値と正解率の 2 つがあります (追って説明します)。通常は、再現率、適合率、FI 値からなる精度混同行列内に示された統計を分析し、その結果に基づいて機械学習アノテーターのパフォーマンスを改善するための措置を取ることになります。

分析の後も、このサイクルは続きます。次のステップは、分析の出力に応じて決定されます (例えば、型システムを修正すること、トレーニング・コーパスにデータを追加することなどが次のステップとなります)。

コグニティブ・システムでの継続的インテグレーション・プロセス

システムのトレーニングを長期的な見方でとらえると、トレーニングにはユーザーからのフィードバックが取り込まれます。この際ユーザーは、通常はカスタム・ユーザー・インターフェースを組み込んだパイロットまたは本番システムを実際に使用します。以下の図にフィードバックを取り込むためのステップを示し、その下に各ステップの概要を説明します。

図 6. トレーニングの継続的インテグレーション
トレーニングの継続的インテグレーションを示す図
トレーニングの継続的インテグレーションを示す図
  1. 初期状態のコーパスをアップロードします。
  2. SME が型システムを確立します。
  3. SME がコーパスにアノテーションを付けます (教師あり学習)。
  4. トレーニングを実施します。これにより、モデルのバージョン 1 が作成されます。
  5. このモデルをアプリケーションで使用します。これにより、アプリケーション UI に結果が表示されます。
  6. エンド・ユーザーがアプリケーション UI に表示された結果を見て、フィードバックを提供します。
  7. システムとのさまざまな対話について、多数のユーザーからフィードバックを集めて保管します。
  8. 特定のしきい値に達した時点で、システムにフィードバックを反映します。
    1. 必要に応じて、SME がフィードバックをレビューして修正またはアノテーションを追加することもできます。
    2. 初期のアノテーション付きコーパスとともに、フィードバックのバッチ・セットを使用してモデルを再度トレーニングします。
    3. これにより、モデルの次のバージョンが作成されます。
  9. 目的の精度レベルに達するまで、あるいは新しい変動性が取り込まれて、それに対してシステムをトレーニングする必要が生じた時点まで、ステップ 5 から 8 を繰り返します。

モデルの評価

AI システムは時間をかけて徐々にそのパフォーマンスを向上させていくものです。したがって、システムのパフォーマンスをどの程度まで向上させる必要があるかを明確にしておく必要があります。そのためには、その AI システムに適切な評価基準を選ばなければなりません。主な測定法には、正解率と F 値 (通常は F1) の 2 つがあります。

正解率は極めて単純な測定値です。簡単に言うと、正解の数を質問の数で除算した結果が正解率になります。例えば、システムに 10 個の質問をして、そのうちの 9 個の質問に対して正解が返ってきたとすると、システムの正解率は 90% ということになります。正解率をメトリックとして使用する利点は、誰でも理解できる単純な評価基準になることにあります。一方、正解率には高度な情報は含まれていないため、システムのパフォーマンスを詳細に理解することはできません。

F 値には、システムが正しい (または誤った) 予測を行った理由が分類されて反映されます。正しい予測と誤った予測は、それぞれ次の 2 つのカテゴリーに分類されます。

  • 真陽性: システムは正しい予測を行っている
  • 真陰性: システムは行うべきでない予測を行っていない
  • 偽陽性: システムは行うべきでない予測を行っている (第 1 種の過誤)
  • 偽陰性: システムは行うべき予測を行っていない (第 2 種の過誤)

F 値を計算するには、まず始めに適合率と再現率を計算します。適合率とは、システムが行った予測の正確さを意味し、偽陽性の率で定義されます。再現率とは、予測可能な値のうち、システムが予測した数を意味し、偽陰性の率によって決まります。F1 は最もよく使われている F 値であり、適合率と再現率の調和平均です。適合率と再現率には必然的なトレードオフの関係があり、寛大なモデルにすれば、通常は再現率が高くなりますが、適合率は低くなります。逆に、厳格なモデルにすると適合率は高くなる一方、それと引き換えに再現率が低くなります。

ちなみに、正解率は (TP+TN)/(TP+TN+FP+FN) として表現することもできます。F 値には、真陰性を考慮しないという利点もあります。真陰性は最もわかりやすく、最も関心度の低いケースです。エラーのタイプを分類する必要がある場合、またはデータに多くの真陰性が含まれる場合は、F 値を使用してください。例えば、10,000 文のうちの 1 文にしか出現しないようなまれな属性をソース・テキストから抽出する必要があるとします。アノテーターを作成せずに、すべての文を調べてそこに該当する属性が含まれていないと予測し続ければ、予測の正解率は 99.99% になります。F 値を使用すれば、この「何もしない」アノテーターの再現率は 0% になります。したがって、このアノテーターには価値がないことがわかります。

例 1

例として、自然言語での犬のインスタンスをマークするアノテーターの正解率と F1 を測定しましょう。

# 抽出された単語 結果
1 It was a bright sunny day. - 真陰性
2 The young dog found a bone. dog 真陽性
3 A young cat lay in the sun. cat 偽陽性
4 The puppy chased the cat. - 偽陰性
5 There was chaos everywhere. - 真陰性
6 A boy took the bone away. boy 偽陽性

この例では、適合率は 33% (行 2、3、6)、再現率は 50% (行 2 と 4)、F1 は 39.8、正解率は 50% (すべての行) となります。F1 による詳細な結果の内訳から、このモデルのどの部分を改善しなければならないかが、より明確にわかります。

例 2

次は、分類システムのパフォーマンスを測定しましょう。この仮定上のシステムは、画像を犬、猫、鳥のいずれかに関するものとして分類します。分類のパフォーマンスを測定する従来からの手段としては混同行列が使用されます。

犬 (実際) 猫 (実際) 鳥 (実際)
犬 (予測) 7 4 0
猫 (予測) 3 6 0
鳥 (予測) 0 0 10

この例では、30 点の画像を使用しました。それぞれの動物の画像は 10 点ずつありますが、システムは犬の画像が 11 点、猫の画像が 18 点、不明な画像が 1 点として分類しました。

各行の数値から、システムのクラスごとの適合率は、Precision(dog) = 7/(7+4+0) として評価できます。各列の数値からは、クラスごとの再現率を Recall(dog) = 7/(7+3+0) として評価できます。

混同行列から、システムがどのような間違いをしているか、新しいトレーニング・データが必要であるかどうかが明らかになります。恐らく驚くことではありませんが、このシステムは猫と犬とを混同している一方で、鳥については他の動物とまったく混同していません。したがって、猫の写真と犬の写真をさらに増やしてトレーニングする必要があります。NLP を重点に正解率を評価する詳細例については、このリンク先のブログ投稿「Cognitive system testing: Overall system accuracy testing」を参照してください。

公開、モニター、運用

AI システムはより多くのトレーニング・データに遭遇しながら、学習を重ねていきます。そのため、早い段階から頻繁にモデルをテストして、データから洞察が引き出されていることを確認することが重要となります。関連するトレーニング・データを追加しながら、定期的にシステムのパフォーマンスを評価してください。定期的に評価することによって、モデルのパフォーマンスが向上していなければ、それを判断できるようになります。パフォーマンスに向上が見られない場合、それはモデルを改良する必要性があることを意味するか、パフォーマンスの論理的限界に達していることを意味するかのどちらかです。また、モデルがその特定のパフォーマンスを見せている理由について理解を深めるために、従来の「F1、適合率、再現率」メトリックの枠を超えて、さらに深いレベルで他の主要な評価基準にもパフォーマンスをマッピングして評価することをお勧めします。例えば以下の評価基準が考えられます。

  • エンティティー・タイプごとの F1 スコア
  • エンティティーおよび関係ごとに使用されているグラウンド・トゥルース (トレーニングおよびテスト) サンプルの数
  • グラウンド・トゥルースに含まれる、ドキュメント・タイプごとのレコードの数 (モデルのトレーニングと評価に使用されるトレーニング・データとテスト・データの層別分布を理解するため)
  • 主要なエンティティー、関係、属性を抽出するまでの時間
  • サンプリング、処理、テストできる母集団のサイズ

それには、トレーニング・データをさらに追加するだけでなく、コードに変更を加えたり、AI システムの使用をモデル化したりすることになるはずです。また、ML で使用する新しい特徴を仮説として作成することになるでしょう。そのような仮説の中には良い結果になるものも、ならないものもあります。システムのあらゆる対話を追跡することで、有効な改訂バージョンとそうではない改訂バージョンをすぐに見分けられるようになります。

ソース管理では、AI システムに関連するすべての成果物を追跡する必要があります。これらの成果物にはコード、モデル、トレーニング・データ自体が含まれます。ソフトウェア開発者たちがよく知っているように、バージョン管理にはさまざまな長所があります。その 1 つは、バージョン管理によって、どの変更がいつシステムに導入されたのかを正確に把握できるようになることです。このようなバージョン管理の利点は、モデルとトレーニング・データにも適用されます。新しい仮説が構築されるにつれ、モデルは変化していきます。また、誤りが見つかって修正が加えられることで、トレーニング・データが変化していくこともあります (確かに、元のデータに含まれているエラーが多すぎたために AI システムがパフォーマンスを発揮できないでいるとわかる場合があります)。

以下に、一定の期間にわたり徐々にデータを追加しながら追跡した Watson Knowledge Studio モデルの精度を示します。12,000 ~ 20,000 語の単語が追加されたあたりで精度は頭打ちになっています。私たちはこの時点でモデルがトレーニング・データ・セットから学習できる変動性を十分に学習したこと、新しいトレーニング・データを追加してもモデルの改善は見込まれないことを把握しました。

図 7. Watson Knowledge Studio モデルの精度
Watson Knowledge Studio モデルの精度を示すグラフ
Watson Knowledge Studio モデルの精度を示すグラフ

継続的学習

モデル化結果の本格的なデプロイおよび統合においては、データのモデル化は常に進行中の継続的な作業になることがあります。例えば、高価値顧客の間での顧客維持率を伸ばすためのモデルをトレーニングしてデプロイしたとすると、維持率が特定のレベルに達した時点で、モデルの微調整が必要になってくるはずです。微調整の後、修正されたモデルを再利用すれば、維持率の増加は少ないとしても、価値のピラミッド上では有益なレベルで顧客を維持できます。

人は新しいシナリオや状況に遭遇すると、それに適応して学習します。実用に移されたコグニティブ・システムは継続的に学習し、新しい観測結果に遭遇しながら進化していかなければなりません。コグニティブ・システムが学習して適応することをしなければ、トレーニングされたモデルは本番環境にデプロイされた途端に劣化し始めます。したがって、コグニティブ・システム自体も劣化することになります。継続的に学習できるようにするためには、一連のツール、プロセス、インスツルメンテーション、ガバナンス・メカニズムが揃っていなければなりません。以下の図に、全体的な手法のうち、デプロイ・フェーズからフィードバックの収集フェーズまでの部分を拡大し、これらのフェーズでのアクティビティーを示します。システムに必要な学習内容を慎重に決定するガバナンス・プロセスを含め、これらのアクティビティーでは収集したフィードバックを使用して継続的に学習する必要があります。

図 8. 継続的学習のループ
継続的にフィードバックを収集してモデルを最新の状態に維持する方法を示す図
継続的にフィードバックを収集してモデルを最新の状態に維持する方法を示す図

まとめ

このチュートリアルでは、DevOps スタイルの考え方をコグニティブまたは人工知能システムに適用するいくつかの方法を概説しました。このチュートリアルはプロセス開発の出発点として役立ちますが、皆さんが構築する特定のコグニティブ・アプリケーションに応じて微調整を加える必要があります。覚えておくべき重要な点は、コグニティブ・システムを継続的に評価すること、そして開発プロセスではシステムのすべてのコンポーネントをファーストクラスの成果物として扱わなければならないことです。DevOps の考え方は、従来のアプリケーション開発に素晴らしい恩恵をもたらしました。コグニティブ・システムにも、コグニティブ・システムに応じた DevOps による同じ後押しが必要です!


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=DevOps, Cognitive computing
ArticleID=1060736
ArticleTitle=DevOps をコグニティブおよび人工知能システムに適応させる
publish-date=07122018