meowの覚え書き

write to think, create to understand

【WIP】言語技術(対話、意見文、議論、論理的思考、批判的思考)に関する気付きメモ

言語技術

言語技術(Language Arts)のトレーニングをして1年半が過ぎる。
トレーニングには、三森ゆりか先生のご著書、『大学生・社会人のための言語技術トレーニング』の内容をベースに勉強している。

大学生・社会人のための言語技術トレーニング

大学生・社会人のための言語技術トレーニング

書籍では不明点もあったので、先生の主催する社会人向けの言語技術講座に全ての回を受講した。 それでも言語技術運用能力が身についたとは思えない。辛うじて、日常やインターネットで見聞きする議論が議論の体を成していないことがわかった程度。 言語技術を自在に操り、無意識でも情報をインプット→思考→アウトプットできるように、最低あと5年くらいは腰を据えて勉強していきたい。
このページでは、言語技術の勉強の過程で気づいたことをメモする。

  • 言語技術とは(私の見解)
    • 自分の意見を論理的に考えたり、相手の意見を論理的に正しく導けているかをジャッジする能力。
      • 私の印象では、前者を論理的思考、後者を批判的1思考と世間で呼ばれている気がする。
  • 言語技術教育
    • 言語技術を身につけさせるための教育
  • そもそもなぜ言語技術は必要か
    • 私の見解では、対話を通して他人(自分とは異なる価値観を持つ者)に自分の意見を伝わらせるため。
      • ここで「対話を通して」を強調しているのは、相手へ意見を伝わらせる手段は脅迫、金など他にもあるため。
      • また、ここで意見という言葉を強調しているのは、事実(誰でも正しいと思ってくれる情報)と区別しておきたいから。相手に事実を伝える(例えば、「今、12時です」「私の名前は山田太郎です」)ならば、相手はその情報を正しいものとして受け入れるだろう。しかし、議論の余地のある事象に対しては、相手は基本的に受け入れてくれない(例えば、「学校は私服で通学できるようにすべきだ」)。したがって、相手が納得するように、自分の意見の根拠を提示しながら、伝える必要がある。
    • 「意見を伝える必要があるのか」という議論ももちろん考えられる。私の所感では、他人との社会的なコミュニケーションが避けられないならば、自分の意見を伝える必要があると思っている。

言語技術教育で習うスキル

他人との議論・コミュニケーション

  • 質問応答

情報のインプット(聞く、読む、観察する)

  • 事実 or 意見 を分類する癖
    • 自分の意見を支えるために根拠を用意するが、その根拠には客観的に正しくないと説得力に欠ける。なので、根拠となる情報を集める際には、それが事実といえるか、他人の1意見なのかは分類しておく必要がある。
    • また
    • なお、三森先生曰く、事実も意見の一種という立場を取る人もいるので、先生の言語技術講座では、事実は10人中8，9人が正しいと認識している事象に対してのことを指すとしていた。
      • 例.「日本は細長い国である」は事実。

情報に対する思考

  • 空間配列(Spatial Order)
    • 事象を構成する要素を「全体→細部」という順番で整理すること。

その他

  • 日本と国外の言語技術教育の学習開始タイミングに関して
    • 日本では、大学の研究室配属後や社会人になってようやく研修などで論理的思考・批判的思考を習い始める気がする。
    • 一方で、それ以外の国では、母国語の授業で、小学1年生からカリキュラムとして扱っていると本に書いてある。
    • 日本語の言語技術を身につけるタイミングが遅いことに対して、三森先生が講座で「言語技術は算数のようなもの。日本ではいきなり、論理的思考を学ばせるが、これは算数も知らない学生に微分方程式を学ばせるようなもの」というようなことを仰っていた記憶がある。

  1. よく言われることだが、批判は、他人を言葉で人格攻撃する意味ではない。相手の意見の不足している点を指摘することで、相手の説を補強するという寧ろ建設的な役割を果たす。↩

【WIP】機械学習システム開発プロジェクトで直面する課題の列挙

MLOps

機械学習を搭載したシステム(MLシステム)やプロダクトの開発は、保守・運用フェーズが(PoCや開発フェーズに比べて)辛いです。その辛さを軽減しよう、すなわち、保守・運用をしやすいようにMLシステム開発をしようとする試みは、MLOpsと呼ばれています。
現行(2019年)で、MLOpsにベストプラクティスは存在していません。そのため、MLシステム開発に携わるエンジニアは日々同業者と勉強会で、自分がMLシステムを開発するにあたって、どういう課題があって、どう解決しようとしてるかを議論し、ナレッジを貯めています。
私もご多分に漏れず、MLシステムの保守・運用に苦しんでいるうちの一人です。 ただ、今一度我が身を振り返ってみると、何が苦しいのかを言語化していませんでした。そこで、この記事では、課題を文字に起こすことで思考を整理したいと思います1。

現時点での課題リスト

  1. ML部隊とOps部隊の役割分担がアンバランス
    • ML部隊がPoCをやって、いい精度が出るモデルができ次第、Ops側にモデルやコードを渡してスキルトランスファーが完了ということがあります。渡されたコードに説明はなく、readmeにモデル学習のさせ方だけが書いてあったりします。
    • そうなると、MLシステムのMLモデル周りでなにか不具合が見つかった時、コードのデバッグをするのは運用側になります。
      • 保守対象のMLのコードというのは、アカデミアのリポジトリを引っ張ってきていることが多いため、コード品質はお世辞にも良いとは言えないことが多いです2。そのため、保守が大変になりがちです。
      • すると、ML側よりも、そのコードを理解する必要がでてきます。そうなると、MLモデルの選定はML側なのに、面倒を見るのはOps側というアンバランスさが発生します。
  2. 「MLシステムの運用・保守は辛い」という認識がされていない。
    1. 良い精度 ≠ 良いシステム
      • 上のこととも関連しますが、モデルの精度を高めることで、保守性が悪化することもあります。手法をSotAなMLモデルに差し替えれば精度はあがるものの保守にコストが取られて旨味がないこともありえます。
      • 研究(PoC)のコードを、製品ver.に流用しようとするのはくれぐれもやめた方がいいと思います。
    2. 人事評価でOpsが不当に低い
      • ML側とOps側で、どう評価を換算するかが整備されていないことが根本的な要因だと思います。
  3. MLモデルの推論結果の(主に顧客への)説明責任が難しい。
    1. 信頼度(事後確率)が正解・不正解と相関がない
      • 信頼度が低くても推論結果があっていることもあれば、信頼度が99%でも推論結果が間違っていることがあります。
    2. 「説明可能なAI」自体がおかしな可視化結果を出す
      • DNNは基本的にブラックボックスですが、CAMやattentionなどの構造を取ると、推論の判断理由(どのような特徴を以て、答えを導いたか)を可視化することができます。
      • しかし、これも完全に使えるわけではなく、人間の直感に反するような結果がでることもあります。
      • そうすると、エンドユーザにそのような結果になった理由を聞かれた時に困ってしまいます。

まだまだ出てきそうなので、随時更新したいと思います。

  1. そしてあわよくば、実務でMLエンジニアをされている人達が集う勉強会の懇親会で、議題にあげることも考えています。↩

  2. そもそも、研究者は自分のコードが他人のプロダクションに載せられることを想定してはいないと思うので、それが普通だと思います。↩

【論文メモ】PoCキャンバスを用いた仮説検証プロセスの管理手法

MLOps

機械学習(ML)モデルは確率的に振る舞う以上、MLシステム開発は不確実性が伴います。
そのため、MLシステム開発においては、不確実性を減らすためにソフトウェア開発に着手する前にPoCを行います。すなわち、不確実性に対して、こうなるだろうという仮説を予め立てた上で、それが合っているかを実験します。 この論文では、機械学習のPoCを行う上での道具(シート)を提案しています。

論文の基本情報

機械学習システム開発の不確実性

MLシステムと従来のソフトウェア開発の違う点は、PoCが求められること。それは、不確実性が伴うため。次のような不確実性が存在する。

MLシステムprjの不確実性、ソフトウェアの構造の不確実性

プロジェクト上での3つの不確実性 1. PoCの実現性に関する不確実性 - PoCですら事前に予測不可能なことが多い(工数やリソース)。そのため、Pre-PoCを行うこともある。 2. ソフトウェアにおけるモデルの不確実性 - 確率的な振る舞いをするモデルがどのようにユーザに価値を提供するかがわからない。同じ精度90%という値でも、迷惑メールの分類性能と自動運転の性能では精度の持つ価値が違う。 3. 運用における学習の不確実性 - 運用中に妥当な学習をし続けられるかわからない。

ソフトウェアの構造とその不確実性 1. モジュールがモデルの不確実性を扱うことが可能か - モデルの不安定な挙動を、モジュール内でリカバリすることができるか。 2. ソフトウェアがモデルの不確実性を吸収することが可能か - モデルの不安定な挙動に対し、サービスという観点でリカバリすることができるか。例えば、MLで天気を予測するサービスがあったとして、推論器が異常値を出した場合は、別の天気予報の情報を提供するモードに切り替える、ようなことを考えているかなど。 3. ユーザや環境からの情報をデータとして追加による不確実性を扱うことが可能か

機械学習システム開発における開発プロセスが満たすべき要件

前段で上げた不確実性がある中で、各粒度においてどういう要件を満たす必要があるか。

MLシステムprjの3つの不確実性に関する要件 1. PoCの実現性に関する不確実性 - 精度向上により顧客価値を提供できるか - PoCの成功/失敗条件の規定 - 非ML手法との比較 1. ソフトウェアにおけるモデルの不確実性 - ソフトウェアにおいて、どのような不確実性が許容できるのかを把握する - ユーザにどのような価値を届けるのかを見据え、その価値を提供するために欠けている情報を機械学習で補えるという仮説を立て、その仮説をPoCとして検証する 1. 運用における学習の不確実性 - 新しく学習したモデルが、そのソフトウェアにとって最低限の水準を満たしていることを保証する仕組み - 製品自身に新しい学習モデルを評価する仕組み - ユーザ自身に判断を仰ぐといった設計が適している場合もある

ソフトウェアの構造とその不確実性に関する要件 1. モジュールがモデルの不確実性を扱うことが可能 - 自動テストが有効であること。モデルが想定外の結果を導き出した場合でも、モジュールとしては、想定された挙動を保証することができる。 1. ソフトウェアがモデルの不確実性を吸収することが可能 1. モジュールレベルで不確実性が考慮されていれば、そのモジュールの振る舞いをソフトウェアレベルでどうすればよいか決めればよい。 2. ユーザや環境からの情報をデータとして追加による不確実性を扱うことが可能 1. PoCフェーズであればエンジニアがデータ処理をすることができるが、運用に入って取得したデータにおいては、恣意的に欠損値を埋めたりすることができないため、そのようなデータの加工についても十分に検証する必要がある。

仮説指向ソフトウェア開発プロセス(HOP)

筆者は、ソフトウェア開発プロセスとして、仮説指向ソフトウェア開発プロセスを提唱している。HOPは3つのフェーズから成る。

f:id:meow_memow:20190929224014p:plain

  1. PoCフェーズ。
    1. 2種類のPoCを反復的に実施。
      1. モデル仮説の検証PoC: データがあった時、期待するMLモデルを構築することができるという仮説を検証する。いわゆる機械学習のPoC。
      2. 価値仮説の検証PoC: MLモデルがユーザに価値を提供でき、ユーザもその価値を認めてくれるという仮説を検証
    2. 手順(上図)としては、価値仮説の上にモデル仮説が複数載っている状態)
      1. 価値仮説を策定
      2. 価値仮説の前提となるモデル仮説を策定
      3. 価値仮説を検証
      4. モデル仮説を検証
      5. 手順4の結果をもとに振り返り。4つの選択肢。
        1. 新しいモデル仮説を策定し、手順4へ
        2. 新しい価値仮説を策定し、手順2へ
        3. PoCフェーズの終了
        4. プロジェクトの終了
  2. プロダクトフェーズ
    1. モデル構築とプロダクト開発をスクラムで進める
    2. 以下のことに考慮
      1. ユーザにとって価値のないモデル構築のための要件も、ユーザストーリーとして扱う
      2. 運用フェーズのための、モデルの妥当性の検証手法を確立する
      3. MLモデルの性質に応じた自動テストを記述する
      4. "done"の定義に、モデルの異常系のテストケースを追加する
  3. 運用フェーズ
    1. プロダクトを横断できるような画一的な手順はない
    2. 考慮すべき点を列挙すると、
      1. 運用で取得したデータで学習するかを決める
        1. 学習する場合は、その妥当性をどう検証するか確定し、妥当でない場合のアクションも決めておく
      2. 運用中のソフトウェアのアップデートの介入方法について決めておく。

PoCキャンバス

f:id:meow_memow:20190929224050p:plain

HOPにおける最初のPoCフェーズの要素を整理する手法(上図)を提案。

10つの領域がある。この数字の順に埋めていくのが簡単とのこと。モデル仮説として、Difficulty(PoCにおいて何が難しいか)をもとに、Performance(MLのスコープ)を決めて、MLに必要なDataとAlgorithmを決める。その一方で、価値仮説として、想定するCustomerと、その人がかかえているProblemを明確にして、達成したときのValueは何かを考える。モデル仮説と価値仮説がきめられたならば、その2つをつなぐ、Accountability、Maintainability、Costを整理し、prjとして成立しうるかを検証する。

  1. Difficulty
    • 顧客価値の実現を機械学習によって達成しようとする上で困難になる要因。
  2. Performance
    • MLモデルが満たすべき予測精度、計算時間。ここに載せた値が実現できない場合は、3.Data,4.Algorithm、1.Difficultyの変更が検討される。達成が前提なのでSLAとみなせばよさそう。また、MLモデルが満たさなくてよい要件なども補記する。
  3. Data
    • MLモデルの構築、評価データの取得経路、データクレンジング、特徴量選択手法
  4. Algorithm
  5. Customer
    • 価値を提供する想定対象。
  6. Problem
    • 5のCustomerが抱えているであろう課題。
  7. Value
    • 価値仮設の概要
  8. Accountability
    • MLモデルの説明可能性
  9. Maintainability
    • MLモデルの保守性
  10. Cost
    • 価値仮設として、prjの期間、費用

すべてを最初に埋めることはできないかもしれないが、その場合は将来的に仮説がこける可能性があることを認識しておく。

なお、提案されたことに対する評価実験は論文にない。

所感

PoCの段階で9.Maintainabilityが考えられていることはいいことだと思いました。保守性を考えずにPoCを行うと、製品化した際に保守性が壊滅的になっていると考えるからです。
PoCフェーズが説明の中心でしたが、プロダクトフェーズ、運用フェーズを進める上での仮説検証指針のようなものがこれからでたらいいな、と思いました。