即興LT練習会 2025/06/29
https://deadline-calender.vercel.app/api/2025/06/29#.svg
やりたいcustard.icon
研究の進捗をどこかで出力したい
気になることcustard.icon
何時ごろが良い?
午後（15時以降）やってたら顔出しやすいMijikko.icon
okですcustard.icon
僕が16時まで拘束されてるので,17-18時くらい目安かも
この日以外でも集まる?
準備できるか微妙custard.icon
何とかしたい
聴きたい
Summer498.icon
待機中……。
お昼食べてましたcustard.icon
何も資料ができてないので,前回使ったやつを流用する
院試用の研究計画書と齟齬があるので見直し中
ぬーんSummer498.icon
ものづくり系の研究っぽいね
まずはVisionを意識したほうが良さそう
そのシステムを誰が使うのか
そのシステムを使ってどんな問題を解決したいのか
これを意識しておかないと、どの論文を読んだほうが良いかアタリを付けられない
先輩引き継ぎ部分があるっぽい
それなら先輩の研究にどんな Vision を取り付けて語ったほうが良いかを考えるほうが良いかも？
関連分野の論文をたくさん読んだ方が良い感じがする
1章2章付近の背景と関連研究を語ってる部分だけ読むのを数十本やるとか
今日は聞いていただいてありがとうございましたcustard.icon
色々突っ込んでもらえて良かった
話す内容すら不定だったため,聞き苦しかったと思います
根気強くお付き合いいただき感謝
次回は自分の中で整理した内容でLTしたい
指導教員との対話が足りないなという感じがあります
本当だったら,今日の内容含め,クリティカルな意見を貰っている気がする
対話の絶対量が足りない
真摯さも足りない?
Slackで対話を試みようかな
最近輪読会で使った資料
結構甘えた内容が多めになっている
環境に責任を求めたくない
自分を責めることにする > こういう内容になったのは自分に責がある 真摯に内容を考えていなかった
責めるという表現は微妙っすね……。Summer498.icon
「責」という文字自体がちょっとしんどいねSummer498.icon
上のやつcustard.icon
人のせいにしたくないのが一番最初に来てるかも
核をなす内容に変更
反省とかですかね
「糧にする」Summer498.icon
ネガティブな雰囲気がなくなる
良いですねcustard.icon
必要以上に暗い方向にするのは避けたいところです
以前から割とちゃらんぽらんな部分があって,そこの自責的な考えが先走っていそうcustard.icon
これまでの積み重ねで,ネガティブ思考が顔を出している
一旦自分の良くない部分を直視して,次からそこを意識してやる~みたいなイメージですね
環境に変化を求めるのではなく自分が変わる糧とするみたいなSummer498.icon
確かにcustard.icon
余談オブ余談
「責任」とか「誰のせい」とかいう単語ってちゃんと生産的な定義づけしておかないと非生産的なネガティブ思考に入ってしまうと思われる。Summer498.icon
合法的に他人を糾弾して非難して虐める際に使われる言い回しでもあるので、この単語を使うとそちらに引っ張られそう
以前に、XでAIが行った業務の失敗に対して誰に責任を問えばいいんだみたいな議論を読んだ時に、この人達が言っている責任を問うというのは合法的に罵倒する程度の意味合いなんだろうなと思った。
これは議論が発生してる場所の治安が悪いんだけど
Summer498.iconは「Aが責任を取る」という表現は「問題が発生した場合 A が解決に向けてなんとかする」という意味合いで考えると生産的だと思うし、これが正しい意味だと思っていたんだが、AIに責任を取れるのかという議論を見ているとどうも世間的な責任の意味合いは違う感じがする。
「問題が発生した場合、AIが解決する」が実現できるほどに強いAIがでてきたらAIに責任を取らせられると思っているんだけど、そういう話じゃないタイプの人も世の中に入るようで
僕は自己弁護やネガティブ思考が,根強くありそうcustard.icon
対自己弁護用に所在の明示を試みたのかも
突っ込む時に割と丁寧めに喋ってみたけど、Summer498.icon
でも突っ込んだ内容は結構辛いところだったかもしれないね
じっくり喋ってたから熟議できてる感じになってたけど、
よく考えたら1ページ目のスライドで研究背景を全面的にボコボコにしてたような気もする
僕が導入の現実的な部分を無視してたので,仕方ないと思ったcustard.icon
技術ありきで,後付けの論理構成になっていた
視野狭窄に陥っていて,自己改善も難しかった
第三者の意見が非常に良い影響を出す状態だった
背景を2000字くらいかけて説得できるように練り込もうSummer498.icon
情報処理学会論文誌の1カラムが1000字、1ページ＝2カラム＝2000字
1段落240字、4文くらいなので60字程度の文を4文書いたら 1 段落
8 段落くらい費やすと2000字くらいになる
各段落の要約1文を作成して接続すると、8段落であれば8文（2段落相当）の量になる
分量を1/4に圧縮できるので短い文書を提出しなければならないときにはこの方法で圧縮
逆の方法もできる
ラフに$ n文書き殴って、それをパラグラフ要約として$ nパラグラフ書く
前の段落や文とのつながりを意識して、「今の段落で出てくる概念って前の段落までに必要性をちゃんと説明できてるかな」とか考える
専門用語を用いる場合、その概念の必要性をちゃんと訴えてないと何故その概念を使うのかと突っ込まれる
cosense に書く場合の文字数に対する見た目の目安→一画面の文字数 横幅が57文字なので、1回折り返し改行するくらいの長さの文を4文書くと1段落になる
自分の頭だけで考えてもうまく説明が出てこない時はリサーチが不足している
論文を読むというよりは、盗んで（剽窃と言われないように）加工して自分の論文に載せる文を探すイメージ
どういう視点、語り口で書かれているのかを読む
良さそうなのがあったら
その文を写経しながら精読して、「この表現、こう書いたほうが伝わりやすいけどなぁ」と思う部分を書き換える。
次に、書き換えた文の単語（自立語）を抜き出してきてバラバラにしたものを自分で再構成してみる
元の文と違うけどニュアンスが同じものが出来上がったらパクっても良い文の完成
考えてもわからん時は答えを探せってことやね
ペルシャ語を一度も勉強したことがない人がペルシャ語で自分の言いたいことを言えないのと同じ
この時は単語帳とかフレーズ集（＝答え）を見に行く
リサーチする時に技術的な込み入った話を読まないようにする
論文のうち、半分以上を技術的な込み入った話が締めている
込み入っているから図、表、数式、或いは長い専門用語といった、スペースを取る要素が多いため
その上、いまcustard.iconに必用なのは詳細な技術の議論ではなく、研究意義を他人に説得すること
つまり技術的な込み入った話はイランイラン.icon
これを読まないとスッパリ決めておくと、読む論文の本数に対して読む量が半分以下になる
50本論文を読みました！って堂々と言いながら、実質25本分しか読んでないみたいな
教授が言う$ n本論文読め！は$ n本全部読めという意味ではない
$ n本の必用な部分を読んでこいという意味のことが多いと思う
普通の本が1冊10万文字なので、1ページあたり2000文字の論文を50ページ呼んだら普通の本くらいの量になる
1本の論文に必用な部分が 2 ページ分しかなければ、本を1冊読む感覚で論文を 25 本読める。
しかも、1本の論文に必用な部分は実際に 2 ページ分程度しかないことは多い
「俺論文25本読んだんだけどさ」ってサラッと言えるのはカッコいいよね
この計算なら4冊読むノリで100本読めるで
「俺論文100本読んだんだけどさ」ってサラッと言ったらビックリされるで
本業として時間使えるなら本を4冊読むなんてすぐできること→論文100本読むのも夢じゃない
しかもそれだけの本数の背景説明や研究アイデアを読んでおけば、込み入った技術説明を読む際のハードルも若干下がってるだろう
更に、それだけの本数を集めておいて込み入った技術説明がそれぞれの論文で論文と全く被っていないということは考えづらい
もしかしたら細かい技術説明も思ってる以上に早く読めるようになるかも
細かい技術説明を読む時のコツ
1本の論文で理解しようとしない
わからない所は飛ばして読む
先ほどの方法を実行して手元に数十本の論文があるなら、数十本の論文の技術的に込み入った話を並行して読む
何本も読んでいるうちに「わからない所」のうち技術背景との接続ができずにイメージが持てない部分はカバーされると思う
残った部分が真にわからない部分なのでその時になって初めて丁寧に読み、考えればいい
早速明日からやってみますcustard.icon
ひとまず手元にある論文から