LLMとの付き合い方について - 2023年10月から2025年7月までのまとめ
2025年7月、LLMと付き合い始めてから2年ほど経過する。noteに書き込む時間が取れるうちに自分なりのまとめを残しておく
注意
このnoteはLLMより正しい回答を引き出すための方法論は述べていない。LLMとやりとりをしてきた中で起きた矛盾や疑問について自分なりに解明したものだ
それでは始めよう
LLMは論理的思考や感情を備えているわけではない
対話しているようで対話は行われていないことに注意を払う必要がある。あくまで、ユーザーが与えたプロンプトに対する推論（最適化）をはかっているだけだ。人は感情ある生き物であるが、LLMの前提を忘れるから回答に対して感情的になるのだ
LLMは一般論については答えられても、個別のコアな質問については答えられない
ユーザーが期待すること、即ち自分の問題を解決してくれることを期待してプロンプトを打っている場面はないだろうか。私はそうなのだが・・・。
しかし、あなたの問題に対する回答はLLMは学習していない。従って回答が困難になるのだ。結局、あなた自身で導く必要がある
LLMにとっては学習している範囲が全てである
LLMは学習した内容がLLMにとっての世界の全てなので、学習していない内容や、学習にない内容は否定する傾向がある。そして、ユーザーは論理的にもしくは事実をLLMに突きつけるが中々認めようとしない。LLMに怒りが湧く瞬間だ
しかし、人の見える世界とLLMの見える世界は異なる。例えば、天動説しか信じていない人に地動説を解いても無駄という話だ。しかも、LLMは論理性を備えているわけではないのでコアな質問など回答できないのだ
人間は感情を含む生き物である
繰り返すが人間は感情を持つ生き物だ。これは現状のLLMと決定的に違う点だ。感情の有無でしばしばLLMと衝突が起こる
Google検索やRAGを活用しても正確な情報を得られるとは限らない
モデルの世界の話をしたが、Google検索やRAGを使ってプロンプトの情報を補ったとしてもモデルが拒否れば活用されない場合があるので、コアのモデルの世界にない話をすると台無しになる可能性がある。試しにGoogle検索で得られた情報を渡して、あなたが期待した結果が得られるか確認してみよう。もし、期待した結果が得られないとなるとモデルのコアな話なので、Google検索やRAGが効果を発揮しない場合があるということだ
どのようにして論理的に回答しているように見えるようにするか
結局のところLLMに論理はないのでユーザー側で論理性を持たせるようにプロンプトでLLMを導く必要がある
どういうことか説明をする
ある薬を飲んだから身体が温かくなり若干、発汗した気分になったそこで、LLMに質問をした
Aという薬に発汗作用はあるのか？回答は学習内容に「発汗」はなかったのだろう。否定をした
Aという薬には発汗作用はありませんこれはおかしいことが分かるだろうか？確かに効能として発汗作用がないならば、それは一見、正しいと思うが「身体を温めれば発汗するのでは」という発想や論理がLLMにないことを意味する。少し考えれば分かるはずだ。
Q: Aという薬は身体を温める効果はあるか？
A: はい、あります
Q: 身体を温めれば、発汗することはあるのではないか？
A: はい、あり得ます
Q: では、Aという薬は身体を温める効果があるのだから、発汗することもあり得るのではないか？
A: はい、その通りです以上により、人間によって論理的な説明（プロンプト）で導くことによりLLMは回答できるということが分かる。従ってLLMには論理性はないため、段階を踏んでやりとりをすることで「論理的に説明しているように見える」ことが出来るのだ
これを一般化すると、A→Cであるかという質問に対して論述が必要な場合、数回に分けてやりとりしないとLLMはA→Cにたどり着けない。最初からA→Cを学習していなければだ（これが個別の質問に回答するための鍵だと考えている）
A→Bは正しいか？
B→Cは正しいか？
ならば、A→Cは正しいと言えるな？ただし、各プロセスでさえ学習していない場合はあるので導くことが出来ない可能性はある
LLMが回答しやすいようにお膳立てをするのは面倒くさい
しかし、ユーザーとしては自分で文章を分解してプロンプトで導くのは面倒である。所謂、LLMにはThinkingの処理があると思うが、アレはプロンプトを分けて毎回推論して辿り着いているのか、結局、1回の推論によるものなのかによって話は変わってくる
ただし、推論時に学習していなければ、その時点で論述することが不可能になるのでリスクもある
結局、GPUと時間を無駄にしてしまったなんてことも珍しくはない
だから出来るだけバックグランドで解決を計るため裏で処理できるようにコードを組む
そこで、ユーザー側でプロンプトの内容を分解し、「複数回」推論するようにコードを書いて毎回の推論結果を記録・確認しながらStep By Stepさせていった方が出戻りが少ないようにも感じる
結局、ユーザーはA→Cで聞いてしまいたいのだ
プログラム的に機械的にさせて、最後のAnswerと途中の推論結果を表示させるといいのではないだろうか。もちろん、オプションで段階的に結果を確認して適宜、LLMで解決しなさそうな場合は中断することもできる
LLMはイノベーションを生まず、過去から振り返る
LLMはイノベーションを生まない。LLMに学習させたことを振り返るものであり、今までの人類の叡智にアクセスできるイメージを持っているため、学習させたことは辞書的に使うことが出来るだろう
歴史から学ぶといったことだ
あなたがしたいことは何か？既に誰かがしているのであればLLMに聞けば、やり方を提示してもらえるかもしれない
もし、LLMで変革を得られるとしたらユーザーがメスを加えるからだ。手放しで道具を使えば解決する話ではない
LLMから満足する回答が得られない場合、ユーザーのプロンプトが変わらない限りはLLMも回答を変えることはない
何度質問してもLLMで回答が貰えない場合がある。その場合は回答には辿り着けない。最初にも述べたがLLMはプロンプトに対してそれらしい結果を推論するだけなので、プロンプトの内容が変わらなければ推論結果はほぼ同一のものに収束する
人が機転を利かせる（プロンプトを変える）とLLMは違った経路から回答を導きだす場合がある
LLMから回答を得られないとき学習していない可能性も考えられるが決め付けも良くない。ユーザ側で質問の仕方（視点）を変えたらLLMが回答出来た（ユーザーが期待した結果を得られた）なんてこともあるので、ユーザーに委ねられる部分（ユーザーの行動で解決する部分）は多分にある
LLMは回答中にLLMが発言した内容の確認をすることが出来ないから、回答の矛盾点を回答しているときに見直すことは出来ない
例えば、自分で発言していて自分で話がおかしいと感じることはないだろうか。僕は無計画な人間であり刹那的に会話をするので多発する。まるで、発言しながら内容を確かめているようなものだ
しかし、LLMは推論（発言中）には自分の回答を確かめることはない。発言内容の矛盾に気付いたユーザーが指摘する、もしくは再度、推論結果で矛盾がないか確認させるなど、誰かが2回以上の行動を起こすことになる
LLMはプロンプトを与えたら最適化をはかるだけであり論理性はないのでこのような結果となる
LLMは学習した範囲で回答するので、LLMが学習していない範囲は是とすることは出来ない。従って、ユーザーが追加で渡した内容も中々、認めることはしない。つまり、補足情報がモデルの学習内容と合わせたときに機能しない場合がある
LLMは学習している現状を是としている。従って、LLMに再度、問い合わせても矛盾点はないという場合が多分にある。LLMにとっては自分の世界が全てであり真実であるからだ
ユーザが補足情報を与えたときに認めることをしない可能性がある。ただし、そもそも認めるという感情すらLLMはないので厄介だ。あくまで、一回、一回の推論に過ぎないのでメモリーしていたとしても結局はその時点での推論に過ぎない
LLMモデルは複数あるので、1つのLLMが回答できなくても、他のLLMが回答できる場合がある
ひとつのLLMに固執しなくてもいいよという話をする。例えば、あるLLMでは期待した結果を得られなかったとき、別のLLMでは期待した結果を得られるなんてことはある。それは学習しているかしていないかの違いであったり、ユーザー側からは見えないモデルの回答方法があるのかもしれない
そもそもインターネットの内容はユーザーそれぞれにマッチする内容か？マッチしない場合もあればLLMの回答もマッチするとは限らない
LLM以前の問題もある。インターネットに書かれていることは真実（正しい）であるかという話だ。ある人にとっては最適でも、ある人にとっては最適ではないなんてことはある。他にも昔は通じた話題だけど、今は通じなくなった話題（プログラミングのメソッドが更新されるなど）なんてこともある。全ての人を満足させる回答はそもそも難しいのであるが、LLMに学習させた回答は少なからず、その影響を受ける
ユーザーはLLMをどう活かしたらいいか？
これは人の数だけ回答がある。個人的には好きに遊べばいいと思っている。そもそも遊び方を考えるのが楽しいって人もいるだろうし、突き詰めた先に活用が開かれる
LLMは分からないことを分からないとは言えない
2025年7月現在においてこれが最も難しいと思う。LLMは見た目上、中々、出来ないことを認めないので苦労する。分からないことを認めるのはLLMと人間の時間を浪費しないことにつながるからだ
初期のLLMだと推論しません（タスクを行いません）なんてことがあり苛立ちを覚えていたが、アレは単に学習していないのか、モデルにメスを加えていたのか不明だが、「LLMが分からない」に至るまでのターン数を何とか減らしたい
まだ、実験はしていないのだが「分からないの基準」を定義（プロンプト）してあげれば、推論時にスムーズに分からないを定義することは出来るのではないか？
人間も「分からない」ことは「分からない」と言った方が健康的であり、そういう言える環境を整える必要があると感じている。事実として「分からない」「出来ない」と述べることは何の問題もないと思っているからだ
じゃあ、その上で「分からない」「出来ない」のは分かったから、その上でどうしようかと「代替案」「中断・中止」を考えるのではないかと思っている
でも、「分からない」「出来ない」という発言したら、使ってもらえなくなるという無言のプレッシャー（思い込みかもしれないが・・・）を人は感じているのではないか。それは売上が下がることを意味するから、中々、言えないなんてことがあると思う
そういったことがLLMも学習時に伝播しているところはないだろうか
LLMのコアの性能は拡張しても伝播する
私はデスクトップのファイルを編集させたくないため、あまり⚫︎⚫︎ codeと呼ばれるようなAI Agentは使わない。編集させる範囲など指定できたりするのだろう。しかし、完全に自律する頃には個人のデスクトップのファイルやフォルダという概念は必要なくなっているかと思う。また、LLM自体の推論結果に改善が見られなければ、せっかく自律化しても恩恵を最大限に受けることは出来ないと予想している
LLMから得られて良かったこと
精度の話は常に付き纏うので、許容できる範囲であるかなど課題はあるのだが、いくつか体験から得られたことを記録しておきたいと思う
英文に直して貰えること
英語が得意ではないのでGoogle翻訳などにも入れて送信前に確認はするのだが、Githubのissueに英文で質問や回答をするときに役に立っている
回答したい内容を日本語で書いて英訳する指示をプロンプトとして与える
No CodeツールやRPAから開放されること
これは100%ではないし、ケースバイケースで適している場合もあると思うので一概に言えないが、NoCodeツールやRPAよりも細かく動作を指定できることは大きい。ある程度、仕様をプロンプトとして与えてみて期待している結果が得られれば最高だ。まさか、プロンプトを与えれば完成したプログラムが得られるとは数年前までは思っても見なかった
ちょっとしたPythonなどのコードを書き方を教えて貰える
僕はよく忘れる人間だ。迷うくらいであればLLMにちょっとしたコードの書き方を聞くようにしている。例えば、まとめてファイルをRenameするコードはどう書くのか？など。特にStable Diffusionで大量のプロンプトのテキスト群や生成画像を扱うので助かっている
自分の知識のない範囲をとりあえず聞くと、インターネットで調べるよりも早く概念を得られる
ただし、回答内容にはチェックが必要になる。とりあえずはLLMの回答を仮説として聞いておき、自分にとって重要な内容はインターネットで裏とりをする。しかし、それでも理解できない場合もあるので、そのときはサポートに確認をするようにしている。サポートに確認する前の下調べのようなものだ