[湘南日記] 生成AI (LLM) も人間も大差は無いように見える件
今回の日記は、「差」というものを定義しない限りは比較困難だけれども、なんだか感覚的には生成AIも人間もアウトプットは大差ないように見えるという話。特に先週は、そういった事案に2つほど遭遇したので考え込んでしまった。
VPNアップデート
在宅勤務の進んだ現在、大抵の会社はVPN… Virtual Private Networkなるソフトウェアを導入している。これをパソコンに組み込めば、インターネット経由でも “それなり” に会社ネットワークへ接続できる訳だ。
もちろんiPhoneやAndroidと同じく、iOSやWindowsなどのOS本体のみならず、VPNソフトウェアにアップデート作業が必要となることがある。
そのVPNアップデートだけれども、久しぶりの大型アップデートでプログラムサイズが大きかったせいか、トラブルに遭遇する人々が散見された。具体的には「アップデートの進捗率が表示されるけれども、ちっとも進まない」というヤツだ。
そいでもって会社の情報システム部門に対応方法を問い合わせているのに、僕のところにも相談が投げられて来たという訳だ。申し訳ないけれども、その非論理性に驚かされた。
まず事前にこういったことが通知されていないことが気に入らなかったらしいが、そもそもVPNアップデートというのは定期的に実行されている。それを事前に知ったからと言って、何も状況は変わらない。アップデート指示が表示されたら、おとなしくアップデートするしか選択肢はない。そして僕はトラブルが生じた時や機器手配/返却の雑用係であり、そういった情報の展開は担当していない。
それから進捗が上手く行かないと相談されても、既に専門部署に相談済みである。いくら僕が超優秀で親切で分析力が高い機器管理担当者(やさしさには”超”が付かないことは認めよう)とはいえ、やれることは専門部署と大差ない。結局のところは本人は気づいていないけれども、ストレスを発散しているに過ぎない。申し訳ないけれども非生産的なので、淡々と返事をするのに留めておいた。
結局そのトラブル？が解決したのは夕方近くになって自力解決したとのことだった。自宅のネットワークが無線接続だったので、有線接続に切り替えたら上手くいったとのこと。会社ネットワークに接続した時間帯は混み合っていて十分な帯域が割り当てられなかったとか、無線接続だと通信が劇遅だという事情などが考えられる。
が、会社の情報システム部門にしても僕にしても、神様じゃない。どうも神様と思われているようだが、実際に機器の稼働情報を得ない限り状況把握することは難しい。そして本人は「前回の経験に鑑みて試したら上手くいった」とのことだったが、基本的に前回情報は個人情報などもあるので記録しないという方針もある。
こういった事情を踏まえるとプロとしては現状利用可能であることを優先し、地道に状況確認を進めることになる。ユーザのお気に召さなくても、冒険して会社ネットワークへ接続できなくなっているような最悪シナリオを避けるように心掛ける。
と、いう訳で「あんたら大したことないじゃないの」と思われたかもしれないけれども、医者だとか保守部門というのは「そういった存在」なのである。今回の件で情報システム部門を責める気にはなれないし、今後も責める気はない。そもそも在宅勤務できる環境というのは、会社としては保証していない。情報システム部門などは、基本的に職場出社して仕事している者が大半だ。本人たちも在宅に憧れているけれども、会社側が職場出社を要請するから断る権利など存在しない。
さてそういった数多くの知識・理解・思考を欠いたユーザに対して、サポート部門はどのように対応すれば良いのだろうか。情報システム部門だって、人の子である。未熟なユーザからストレスをぶつけられたら、自分たちのメンタル悪化というトラブルを被ることになる。
で、最近検討が進んでいるのが、生成AI (LLM) の導入である。こういった事例を蓄積し、本人の過去履歴は本人パソコンに蓄積しておけば、その過去データを参照しながら生成AI (LLM) が分析することが可能になる。
僕には無用の長物であるが、こういったローカル生成AI (LLM) を搭載希望するユーザが出て来るかもしれない。このままPCのスペックが上がっていけば、まずはスマホから実装されることになりそうな気がする。
(今は僕が家族のスマホをメンテ実施し、ハンバーガーのモバイルオーダーは僕のスマホを利用している。僕がいなくなったら家族はスマホ・ライフを満喫できなくなる訳で、こういったユーザは多そうな気がする。そもそも叔父や従弟はスマホを利用しておらず、スマホ提供側としては潜在顧客として逃したくないだろう)
救いようのない者
それでは僕が失敗をしないかというと、全くそんなことはない。ミスや誤解が集まって構成された存在が、僕という者であるかもしれない。
ちなみにここ最近で最大の屈辱といえば、Windows上の仮想Linux環境(Ubuntu on WSL2)のリカバリ失敗である。今のところ、こちらに関しては再発防止策は見当たらない… 救いようがない、という状況である。
具体的に何があったかと言えば、ちょっといろいろとLinux環境に各種ソフトウェアを盛り過ぎたので、前回バックアップを取得した時の状態に戻ろうと考えたことが発端である。これは一度テストして、上手く行ったことがあったので自信満々だった。
あらかじめ “wsl –shutdown” で仮想マシンを終了させ、”wsl –export Ubntu-22.04 buckup-20230914.tar” でバックアップを取得しておいた。だからその環境へ戻ることは簡単だと思っていた。
- “wsl –shutdown” で仮想マシン終了
- “wsl –unregister Ubuntu-22.04” で既存環境を解放
- “wsl –import Ubuntu-22.04 buckup-20230914.tar” で過去環境を導入
ところがこの(3)のインポート作業が上手くいかない。どうもコマンドの使い方が適切でないようであり、wslコマンドのヘルプメニューが表示される。しかしそれに目を通しても、自分の何が宜しく無いのか全く分からない。
前回は上手くいったハズなのに、今回は全く上手くいかない。自分が何かを間違えているらしいが、その手掛かりは全く見当たらない。三時間ほどアレコレと試した後に、潔く初期化するということになった。
悔しい… いったい自分は何を間違えているのか… その理由は、翌日になって判明した。
ひょんなことで頭の中の “何か” がスパークしたけれども … いや、今ならば分かる。”D:\” という部分を見ている時に、自分の勘違いに気づいたのである。
いやね、そもそもこの “wsl –import” だけれども、バックアップ＆リカバリ用のコマンドではないのだ。思い出してみれば、僕はC:\ドライブにあったWSLデータをD:\ドライブへ移動させるために “wsl –import” を利用した。だから “wsl –import Ubuntu-22.04 WSLデータの設置場所 buckup-20230914.tar” とする必要があった訳だ。
うーん、こういった根本的な勘違いは、なかなか自分では気づくことが難しい。目玉焼きを入れて “月見バーガー” と呼ぶのは日本人には広く周知されて固定観念化しており、これを “ただの目玉焼きが入ったハンバーガー” と認識変更することは難しい。
生成AI (LLM) ではロミオとジュリエットのロミオをジェームズと変えるファインチューニングを試みた実験があるけれども、なかなか完璧に再トレーニングすることは難しいと判明している。つまり誤解や固定観念というのは、そうそう簡単には無くならないのである。
そしてこの件には続きがある。
実は本ブログ記事を書くまでは、さすがに生成AI (LLM) であっても、僕の溶けて消え去った三時間をゼロにすることは難しいと考えていた。
しかしここに来て、「単純に『wsl –import buckup-20230014.tarと叩くとヘルプメッセージが表示されます。私のwslコマンドの利用方法の何が間違っているのでしょうか。教えてください』と素直に叩いてみれば良かったんじゃないかと思い始めている。
うーむ、仮想Linux環境で生成AI (LLM) を使っていたので、GPT3.5あたりで質問すれば良かったのかもしれない。まだまだ僕も、十分に使いこなせているとは言えそうにない。
しめくくり
こうやってみると、人間と生成AI (LLM) というのは大した違いは存在しないのかもしれない。少なくともVPNアップデートで困った人は、僕よりも生成AI (LLM) の方が遥かに役立つかもしない。
別に過去履歴がなくても、正確に状況を生成AIに食わせることが出来れば、それなりに役立ちそうなアウトプットが出力されるだろう。そしてこのあたりの問診技法を生成AIにプログラミングすることが出来れば、人間はともかくパソコン診断はけっこうイケそうな気がする。
(生成AI (LLM)と表現しているのは、LLMは大規模言語モデル(Large Language Model)という実行エンジンに過ぎないけれども、生成AIは人間とのインターフェース部分まで実装した存在であるからだ)
こういったある意味で哲学的とも言えそうな考察をすることが出来るから、個人的には非常に楽しい。そんな訳で、会社でも生成AIやLLMに関する知見は必要という公式見解になっていることもあるし、しばらくはAI方面で楽しむ日々が続きそうだ。
それでは今回は、この辺で。ではまた。
————————–
記事作成：小野谷静
