質問の仕方って大事だよねという話
お久しぶりです。先生方、友人のおかげで無事大学院を卒業することになりました。ありがとうございました。
記念になにか書いておくかと思ったのですが、NAIST関連のことは別の人がたくさん書きそうなので、今回はなんとなくためになりそうなことを書き残しておきます。
ということで、「質問するときには環境についての情報や何をやったかをちゃんと書こう」という話をします。
質問の仕方を知ってると、色々なことを教えてもらいやすくなる
実は去年の研究室内M1向けチュートリアルで書こうと思っていたことです。特に技術的な疑問の場合、質問の内容・書き方ひとつで答える側も負担が減ります、教わる側もすぐに教えてもらえます。つまりWIN-WIN──ということを言っておけばよかったなと思う次第なわけです。
ここでは、例としてpytorchで何らかのエラーが出たときの質問を想定してみます。まずは駄目な方。
pytorchを使っているのですが、gpuを使えません。どうすればいいのでしょうか。
......はい。極端過ぎる例ですが、ここで回答者の頭の中にはいくつもの疑問が思い浮かぶと思います。「OSは？」「pytorchのバージョンは？」「CUDAのバージョンは？」エトセトラエトセトラ。当然聞き返せば質問者から答えは返ってくるけど、この逐次的なやり取りはとても面倒なんですね。
なので、質問の仕方を変えてみましょう。
問題：pytorchからgpuを使えなくて困っています。
環境：CUDA version: 〇〇、Pytorch version*：〇〇
状況：ターミナルのpython対話環境からtorch.get_device_name()をした際に、指しているはずのgpuの名前が表示されません。動かしたコードは以下のとおりです。
......hogehoge
こうして書いてもらえると、回答者も状況がある程度分かるし、かなり回答しやすくなるし無駄なやり取りも減って嬉しいよねってわけです。
「じゃあ、実際にどんなことを書いたらいいんですか？」って話ですが、
こんな感じにまとめてくれてる親切な人がネットにはいます。
ただこれだと丸投げなので、自分的書いてあること嬉しいリストを以下に列挙しておきます。
- わかりやすいタイトル
- 起きている問題（できるだけ詳しく！）
- 動作環境（プログラミング言語やライブラリのバージョン情報、ドライバのバージョン情報やOS、notebookなのかそうでないのか、仮想環境は何を使っているのいるのか等）
- 実際に動かしたコード
- 自分で調べたことややったこと
全部書いたら長すぎるって話かもしれないですが、その辺はうまくスレッドを活用するなりしてください。
情報があればあるほど、回答者は嬉しいものです。
以上、「質問の仕方って大事だよねという話」でした。新入生だと意外とっできてない（自分ができてるとは言ってない）ことが多いので、このあたりを踏まえて快適な研究ライフを過ごして貰えれば幸いです。
LINE bot対話システム主観評価実験をした時の失敗備忘録
みなさま百億年ぶりです．やみんちゅです．今回は研究で対話システムのLINE bot上で完結する評価実験を行なったのですが，かなりの失敗を記録してしまったので，後続が同じ轍を踏まないよう備忘録も兼ねてここに記しておきます．なお，この記事では技術的な話には触れません（LINE bot関連の記事ならネット上に腐るほどあるしね）．あくまで実験設定とか準備とかはここに気を付けよう，という話です．多分LINE bot利用だけでなく，非対面で対話から評価までを完結させるタイプの実験を行う話全般に言えるものになると思います．
時間の見積もりを舐めてはいけない
表題の通りですが，本当に舐めてはいけません．音声対話に比べて，人によってタイピング速度や一つの発話の長さが非常にばらけてくるため，想像するよりもこの見積もりは困難です．実験前，自分で試した際は30分で実験が終了したため多く見積もって45分，せいぜい一時間で終わるだろうと私は考えていました．しかし実際には一時間ぎりぎり（というかオーバーした方も......ｹﾞﾌﾝｹﾞﾌﾝ）かかる例が大半という結構な惨事になったのです．この辺りは実験前の謝金設定とかにも関わってくるので，できれば小規模に予備実験を複数人にしてもらって見積もるか，できなければマージンをかなり多めに取ることをお勧めします．
主観評価は後から修正可能なツールでやろう（Google formとか）
ここはどの程度の頻度で評価する必要があるのか，何を評価するのかによるので何を使うかは難しいところな気がします．今回の場合，対話終了ごとに主観評価を行う必要があったため，システムとの対話に続いてチャットツール上でテキストとして評価値を送信してもらったのですが，修正に不便という声をいただき確かにその通りだと思ったので，まぁGoogle formとか使っとくのが無難と思います．後は，本当にその評価はそこでやる必要があるのか，とかを考えて，まとめてやれそうなものはまとめてやるようにする，など評価のタイミング整理とかも多分必要．
即応性の高い連絡手段を用意しておく
これは失敗というより，やっててよかったという話．今回，直前の思いつきで実験参加者連絡用のLINE Groupを作成したのですが，システムが死ぬほどとちったので正直めちゃくちゃ助かりました．メールだとどうしてもレスポンスに時間かかるし，他の参加者へもまとめて状況共有ができるので作ってよかったと思っています．特に対話システムの主観評価実験はデモを動かしながらやることになるし，こういうのは対面でやるより重要になってくると思います．
実験の初めは，少ない実験参加者からやる
計算資源の制限がある場合，基本的には時間スロットごとに人数を決めて実験をやることになると思います．大体はじめはトラブルが起こりやすいので，解決しやすいように最初の方のスロットは人数少なめにしておいた方がいいです．そうじゃないとトラブルを捌き切れなくなります．
まぁ，一人でやってる時はいけても多人数になるとダメ，というのは実験に限らず往々にしてある（そして必ずトラブルは起こる）と思うので，ちゃんと備えて準備しときましょう，というのが今回の実験で一番得られたものです（実験結果は...?）．
多分色々忘れているので，思い出したらまた追記します．
Introduction method for argumentative dialog using paired question-answering interchange about personality
どんなもの？
議論型対話システムにおいて，ユーザーとシステムがお互いに知り合うような初期談話を挿入することにより，議論型対話をスムーズに行う手法を提案する．
技術や手法のキモはどこ?
議論の前に人格に関する質問と回答の組からなるQAを数ターン，議論の前に行うことでユーザーの議論への関心と積極性を高める．
どうやって有効だと検証した?
アンケート方式（各問7段階）の主観評価 QAとargument部分でそれぞれ異なるアンケート（発話の自然性や親しみやすさなど vs システムの意見を理解できたか，システムが自分の意見を理解できていたかなど）
議論はある?
質問選択の方法や質問への回答に含む情報の数など，QAセッションでのシステムの振る舞いについて改善点あり
次に読むべき論文は?
自己開示や感情表現がユーザーとシステムのコミュニケーションに与える影響について述べられた論文？ Computer-Mediated Communication Effects on Disclosure, Impressions, and Interpersonal Evaluations: Getting to Know One Another a Bit at a Time
collections.Counterクラスを使ったスコアの保存
お久しぶりです．やみんちゅです．前回記事の更新を放置して久しいですが，それはそれとして，言語モデルから出力された複数の生成文候補とそれぞれの生成確率をあとでリランキングしやすい形で保存するのにcollections.Counterクラスが便利だと知ったので，備忘録として書いておきたいと思います．
そもそもpythonのcollections.Counterクラスって何だっけ
詳細な解説はこちら
に譲りますが，例えばリスト内の各要素の個数を調べたいときに
import collections l = [1, 1, 2, 2, 3, 3, 3] collections.Counter(l)
このようにリストを渡してcollections.Counterクラスをインスタンスすると，
Counter({1: 2, 2: 2, 3: 3})
辞書形式（ここが大事）で各要素をkeyとしてそれぞれの個数がvalueに格納されます．
Counterを辞書として操作する
本題ですが，ここで大事なのは
- Counterの扱い方は辞書とほぼ一緒
- valueには整数値以外も入れられる
という2点です． そこで試しに下のように空のcollections.Counterクラスを生成し，後からkeyと対応するfloat値の追加を行ってみます．
import collections c = collections.Counter() c['a'] = 1.05 print(c)
すると結果は
Counter({'a': 1.05})
となって，しっかり辞書と同じように扱えて，floatも扱えることがわかりましたね． valueがどんな値を受け付けるのか詳細には調べていないのですが，pytorchのtensorもvalueに入力することができたので，値を比較できるものなら何でも入れられるかと思います（多分）．
Counterクラスを使うと何が嬉しいの？
個人的に嬉しいのは，most_common()関数を使って，簡単にvalueの値順に要素を並べたリストを得られることです．
試しに下のようにコードを書いてみます．
import collections l = [1, 1, 2, 2, 3, 3, 3] c = collections.Counter(l) c.most_common()
すると，下のように(key, value)のタプルがvalueが大きい順に格納されたリストが返ってきます．
# result [(3, 3), (1, 2), (2, 2)]
またmost_common()関数の引数に整数値nを渡すことで，上位n個までの値を取ってくる，という動作も実現できます．
まとめ
collections.Counterクラスを利用して生成候補と生成確率を保存しておくことと辞書形式と同じ操作ができるので，後から別のスコアを加算してmost_common()で並び替える，という実装が簡単に実現できますよ，というのが結論です．もし必要に迫られたら，皆さんもぜひ使ってみてください．
ReactとAmazon Mechanical Turkによる実践アノテーションツール（番外編）
こんにちは．やみんちゅです．
前回Amazon Mechanical Turkのテンプレートで対応できない際に，外部サイトでアノテーションツールを動かしてMturkから誘導する，というような話をしました．実はこの時に（先の話のネタバレになりますが）AWS SDK経由でAPIを叩いてMturkに仕事を投げることになります．ここではそれに関連した小話を二つします．
本当にAPIを叩く方がいいのか？他の方法はないのか？
そもそもなんですが，外部サイトでアノテーションを行うような方法を本当にAmazonが用意していないのか？という疑問がありそうですが，実はあります．テンプレートも用意されています．この辺りの話は下のリンクでMturk公式が回答している通り，Survey Linkテンプレートを使用することでAWS SDKを使うだのというめんどくさい話は全てスルーできるのです．
だというのに，なぜこのブログではわざわざ面倒臭い方法をとっているかというと，そこにはアカウント管理の問題が絡んできます．MturkではAWSアカウントではなく米国Amazonのアカウントが必要になるのですが，MturkではAWSとは違いゲストユーザを設定することができません（ここ勘違いしていたら誰か教えてください）．作業者は支払い情報もろもろを閲覧できるルートユーザでMturkにログインし，作業する必要があります．その点，APIを経由する場合はMturkのアカウント周りは一切触らず，管理者はAWS側でAPIキーだけを作業者に渡せばよく，特に研究室なんかで学生にHITの作成をさせたい場合とかに，機密情報に触らせずに作業させられるので管理上好都合というわけです．
API経由で作成したHITsは，Mturkのサイト上で管理ができない
API経由で作成した場合，提出情報の確認やHITsの終了といった重要な管理が，実はMturkのサイト上にある管理ツールで行えないという致命的な弱点があります（普通にMturk上でテンプレートから作成した場合には大丈夫）．なら管理ツールを内製するか，といってもコストが高いのまぁ無理なわけですが，人間大体同じことを考えているので実はAPI経由で作成したHITsの管理ツールを既に作ってくれている方がいます．
使い方は見て慣れれば大体なんとかなります（READMEもあるし）．大抵の管理機能はこれで補完できます．
というわけで，チュートリアル用のリポジトリ作成が全然間に合っていないので小話でなんとか場を繋ごうという回なのでした．しかし2番目の管理の話は普通に三四日ぐらい詰まっていたところなので，これからMturkに立ち向かう人たちの一助になれば幸いです．
ReactとAmazon Mechanical Turkによる実践アノテーションツール（概要編）
お久しぶりです，やみんちゅです．
最近，研究室でAmazon Mechanical Turk（以下Mturk）とReact製Webアプリケーションによるアノテーションツールの作成を行ないました．しかしMTurk自体が日本ではあまりメジャーどころではない（？）のと，そもそも外部サイトに誘導してのアノテーションというトンチキなことをやっている人も少なく，ドキュメントがなくて何度も落とし穴にハマりました．なので，そのような被害者をこれ以上生み出さないよう，今回の作業で得た知見を共有していきたいと思います．
今回の記事(概要編)で分かること
- 今回の記事(概要編)で分かること
- Amazon Mechanical Turkとは？
- Mturkの良いところ
- Mturkだけで完結できるアノテーションは？
- Mturkだけで完結できないアノテーションを行う方法と必要な道具
- まとめ
Handsontable紹介-javascript向け表計算ライブラリ
Handsontableというライブラリをご存知でしょうか。
Handsnotableはweb上の画面でExcelライクなスプレッドシート機能を実装できるjavascriptライブラリです。公式ホームページは以下から。
公式の記述通り、ReactとVue向けのラッパーが提供されてます。10k単位の行数にも耐えてくれるし、ほとんど脳死でReduxとも連携できる上に、公式ドキュメントも非常に豊富(まぁ豊富過ぎるのも困り物なんだけど)、カスタマイズ性もかなり高いという、個人的には使い勝手の良いライブラリだと思います。
しかし最新版の利用は商用利用の場合、有料ライセンスが必須となっています（非商用及び評価版は無料）。予算の関係諸々で無料でMITライセンスで使いたい！という商用開発ユーザは旧バージョンのver6.2.2の無料版を使う必要性が出てきて、この辺りにバグや機能の追加実装などの非常につまづく要素が転がっているわけです。ライセンス買えよ、と言われたら、まぁそうなんですけどね…
自分はReactしか触ったことがないので、以下はReact向けの話になります。
React向けラッパーは以下のgithubのページから。
ver6.2.2の本体とラッパーのインストールは
npm install handsontable@6.2.2 @handsontable/react@2.1.0
基本的な使い方については以下の記事で事足ります。
ただ、有料機能を無料版の範囲で実装しようとすると一工夫必要になるので、その辺りの話について今後更新して行こうかと思います。
それでは、Handsontableで楽しいスプレッドシートライフを！
...某侍のページ並みに内容がないですわね
