めもめも

このブログに記載の内容は個人の見解であり、必ずしも所属組織の立場、戦略、意見を代表するものではありません。

IT専門用語の日本手話(JSL)表現に関するメモ

speakerdeck.com

先日、社内で、一般人向けレベルの内容で、30分程度の「機械学習入門」のレクチャーを行いました。上記資料のタイトルにあるように、日本手話(JSL)でプレゼンしました。(オーディエンスは、エンジニア・非エンジニア含めたJSL話者7名。ろう者にも参加してもらいました。)

JSLを用いた理由はさておいて、発表後のディスカッションの際に、IT関係の専門用語の手話表現に関して、いろいろ興味深い会話があったので、記憶をいくつかダンプアウトしておきます。(特に内容の整理はしていません。)

なお、以下に出てくる用語は、基本的には、対応する日本語単語がプレゼン資料上にあるので、初出の際は、投影スライド上の日本語単語の指差しを加えています。また、私自身は、日本語が第一言語で、IT関連の事は、だいたい日本語か英語で考えているので、以下の内容は、IT関連の日本語/英語をJSLに翻訳する技術、という視点で捉えて書いています。

※注意事項:ここで議論している手話表現は、公式のものではなく、また、公式の表現を決めようと意図するものでもありません。他の手話話者とディスカッションした内容を参考としてご紹介するものです。ディスカッションには、ろう者、および、コーダの方にも参加していただきました。

「関数」の表現

今回のプレゼンでは、プログラミング言語ではなく、数学用語としての「関数」として出てきました。なので、私は、「皆さん昔、数学で勉強したと思います」と数学の用語であることをほのめかした(?)後に、「かんすう」と指文字を示して、「関係/数」と表しました。その後は、すべて「関係/数」で統一。

一方、エンジニアのオーディエンスからは、「自分なら「機能」を使う」とのご意見。英語で言うと Function で、プログラミング言語の場合は、日本語話者でも「ファンクション」と言うことはあるので、確かに専門家にはそちらの方がストレートかも知れません。とは言え、今回の一般人向けのプレゼンであれば「関係/数」の方が分かりやすいのでは、というのは、非エンジニアオーディエンスからのコメントでした。

「ディープラーニング(深層学習)」の表現

日本語でプレゼンするときは(個人的に「深層学習」という大仰な和訳が好きでないので)「ディープラーニング」で通していますが、今回は、「でぃーぷらーにんぐ」と指文字で示した後、「日本語で言うなら、「深い/学習」ですね。」と言って、あとは「深い/学習」で統一。

ここは、表現方法については、特にコメントありませんでしたが、「しんそうがくしゅう」の口形を付けてもよいのでは、というご意見がありました。(私は、個人的に、日本語の口形を付けるのが苦手で、実はこれに限らずよく指摘されるのですが・・・)

ちなみに、「Deep Mind」という会社があるのですが、これは「深い/考え」で表現すると、エンジニアのオーディエンスに教えてもらいました。(なるほど。)

「構造化データ・非構造化データ」の表現

発表中は、「こうぞうか(指文字)/データ」でやっていたのですが、発表後に「構造/データ」「非/構造/データ」でよいのでは、とのご意見。ここは、私の勉強不足でこの表現が「構造」という意味で使えることを知りませんでした。ご指摘ありがとうございます。(言い訳をすると、この表現は、建築/アーキテクチャーが本来の意味で、データベースエンジニアの方は分かるように、「構造化データ」と言った場合の「構造」とはちょっとニュアンスが違うんですよね・・・。どちらかと言うと「組織(仕組み)」の方が近い?? なので、データベース用語としての「構造」にピタッとあう表現が思いつかずに指文字にしていました。)

「ニューラルネットワーク」の表現

(いくつか議論はあったのですが)結論から言うと、「神経/ネットワーク」でOK。

関数の「入力」「出力」の表現

発表中は、「入る/数」「出る/数」を使いました。非エンジニアの方から、出力については、「現れる/数」(「現れる」は「表す」の手のひらを自分に向けたやつ)の方が、計算結果が(自分に)得られるというニュアンスが伝わって良いのでは、というご意見がありました。一方、今回は、ニューラルネットワークの中で、複数の関数が連続して入出力を受け渡していくという文脈なので、私の表現でニュアンスが伝わると言うコメントもありました。

もしかしたら、非エンジニア向けには、「数学としての関数を復習する」ページでは、「現れる/数」を使っておいて、その後、ニューラルネットワークを説明する部分で、「出る/数」に表現を移行するというテクニックがあれば、ベストだったのかも知れません。

(補足)この記事をアップした後、社内の人からコメントいただいて改めて考えたところ、ニューラルネットワークで計算が進む様子は、/入る 計算 現れる/ (掴んで移動する CL) /入る 計算 現れる/ (掴んで移動する CL) という水平方向の繰り返しでいけるんじゃないかという気がしてきました。

「パラメーター」の表現

うまい表現が見つからなかったので、初出の際に「「ぱらめーたー(指文字)」というのは、記号「θ(空書)」で表します」と言って、あとは、「θ(空書)」で統一。

「変数」の意味では「変わる/数」、いわゆる(ハイパーパラメーター的な意味での)パラメーターでは「調整/数」というご意見もいただきました。今回の文脈だと、「調整/数」でいけるかもしれません。

「アルゴリズム」の表現

発表中は、指文字で統一。ディスカッションの際に、初出は「指文字+口形」で、2回目以降は、「あるご(指文字)+あるごりずむ(口形)」という短縮バージョンでもよいかも、というコメントをいただきました。

おまけ

今回の発表にはないのですが、某弊社内では、TensorFlow の表現はこちらです。(わかる人にはわかるやつw)

GPUベースの量子回路シミュレーターについて

TL;DR;

本物の量子デバイスが手に入らない場合でも、20〜30qubit 程度の量子回路であれば、GPUベースのシミュレーターで(現実的な計算速度で)量子計算を実行することができます。物理デバイスと異なり、外部ノイズの影響を受けないため、純粋にアルゴリズムの検証にフォーカスすることができます。(意図通りの結果が得られなかった際に、ハードウェアの問題かどうかを切り分ける必要がありません。)

必要なもの

Cirq : Google が開発中の量子デバイスで実行可能な量子回路を記述するための Python library
github.com

Qulacs : GPU ベースの高速な量子回路シミュレーター
github.com

cirq-qulacs : Cirq のバックエンドに Qulacs を用いて、Cirq で記述した量子回路を高速シミュレーションするためのパッケージ
github.com

参考情報

medium.com

「ITエンジニアのための強化学習理論入門」的な何かのアイデア

元ネタ
incompleteideas.net

ポイント
・学習の過程がステップバイステップで理解できる(目で見える)サンプルを示すことで、「なぜそれでうまく学習できるのか」を理解することを目標とする。
・アルゴリズムを愚直に実装したコードを示すことで、数式ではなく、コードを通してアルゴリズムを理解する。

Tabular method

Multi-arm bandit による導入

MDPの枠組みは一旦無視して、強化学習のポイントとなる「考え方」を理解する

・Exploitation - Exploration のバランスが必要。典型的には ε - greedy を利用する。
・環境から収集したデータを元に、行動の価値を見積もる価値関数を構成する。
・データ収取と並行して、価値関数を逐次更新する。
・逐次更新の方法は、一義的に決まるものではないが、「差分を一定の重みで加えて修正する」という考え方が基本。
・価値の初期値を高めにセットして、初期の Exploration を促進する話も入れる。(後々、SARSA, Q-Learning でも必要になるテクニックなので。)

github.com

MDPとDynamic Programmingによる厳密解

環境のモデルがあれば、(計算量を無視すれば)DP で価値関数の厳密解が得られる(強化学習は完全に解ける)事を理解する。

・MDPの枠組みを説明。簡単な例で、状態遷移のツリーが展開される様子を理解する。
・ある状態から、すべてのツリーを網羅的に辿って、それぞれの「確率×総報酬」の和で価値関数が計算される。
・価値関数は、ポリシーごとに決まる点に注意。複数のポリシーは、それぞれの価値関数を比較することで、どちらがより優れたポリシーかが決定される。
・Bellman 方程式に変形して、Iterative に価値関数を計算する手法を説明

github.com

・「なぜこれでうまくいか」をどう説明するか???ツリーの末端から上に向かって、順次、情報が更新される様子を図解???

ポリシーアップデート

・あるポリシーの価値関数を用いて、Greedy policy を構成すると、元のポリシーよりも優れたものが得られる。
・価値関数の計算と、それを用いた Greedy policy の再構成を繰り返すことで、ベストなポリシーが得られる。

github.com

Policy iteration と Value iteration

・価値関数の計算、Greedy policy の再計算、それぞれの計算量を考えて、現実的には、計算量を削減する工夫が必要になる点を理解。
・Policy iteration において、コーディング上の工夫をする。

github.com

・価値関数の収束を待たずに、Policy を随時更新する手法として、Value iteration を説明。

github.com

Monte Carlo Method

・環境モデルがない場合、実環境から収集した断片的なデータから学習する必要がある。
・多数のエピソードを収集して、それぞれのエピソードで得られた総報酬の平均値として、価値関数を見積もる。(ただし、その後で Greedy policy を構成する上では、Action - Value function を見積もった方がよい。)
・ポリシーを固定すると Exploration できないので、「価値関数を計算するべきポリシー」とは、異なるポリシーで収集したデータを活用する手法が必要。
・一般論としては、Importance Sampling で対応。
・「価値関数を計算するべきポリシー=Greedy policy」「データ収集用ポリシー=ε - greedy」という場合、エピソードの Tail からしか学習できないので、学習の効率が悪い点を説明。

github.com

TD Method

SARSA

・価値関数の見積もりをエピソードの総報酬で見積もるのではなく、DP と同じくステップごとに評価する。TD Error による補正を加えていく。
・MC より効率的に学習できることが経験的に分かる。
・online method として ε - greedy を用いて Policy のアップデートを行う手法が SARSA。ε - greedy に伴う不確定性が課題。

Q-Learning

・SARSA を offline 化したもの。よく考えると、ステップごとの評価であれば、Importance Sampling は不要で、TD Error を Greedy Policy に対する評価に置き換えるだけでOK
・一般論としては、SARSA より効率的。ただし、Cliff walk のように作為的に Q-Learning が不利になる例も作れる。
・offline メソッドなので、experience replay (Dyna-Q)や、exploration を促進する Behavior policy の導入(Dyna-Q+)などの工夫がやりやすい。
(TD(n) はコラム程度の言及にとどめる?)

Functional approximation

・状態数が増えると、Tabular 方式が破綻するので、Functional approx を行う。最近は、NN を利用するのが流行り。
・バッチで学習するために、offline メソッドが便利。
・「TD Error の二乗平均誤差」を誤差関数として、Backpropagation でバッチ学習する方法が考えられる。
・walk game の例で説明(環境がランダムなので、環境含めてステートにしないといけない。)
github.com

・Monte Carlo tree search のもっともシンプルな例として、1step だけ先読みする手法を実装。walk game の場合、壁に自ら激突するという単純ミスを防止できる。
・Functional approximation の場合、価値関数はどうしても不正確になるので、それを compensate するために、本番時に再度、シミュレーションでエピソードを収集して補正する、という考え方。