このように、LLMを人工知能だと思わず、もっともらしい後続文を出力する関数だと割り切って使った方が、特に低パラメータモデルだと有用だと思っている。AIチャットするのにチャットモデルなんか使うのやめようぜ（過激派）
この手法は問題点を抱えてて、これだとシーン毎に判定プロンプトを用意しないといけなくなる。これはメニューを聞いているシーンだ、ということが分からないとプロンプト挿入ができないので。
そこで今考えているのは、function callingでコマンド選択を行う手法。
次にキャラが行うべき行動は何ですか？①話す ②ものを渡す ③移動する
みたいな。
ただし7Bモデルではこのコマンド選択の精度が中々出なくて、選択肢を2択にして階層化した上で、probabilityを見るとか、いろいろ対処法を考え中。
なお、「そこで出されたのは、カ」というプロンプトで「レーライスだった。」という補完文が得られたら、次に「そこで出されたのは、カレーライスだった。」をそのまま出力してユーザーに表示してもいいけど、「そこで出されたのは、カ」というLLM生成ではない文章が混じるのは避けたい場合がある。
そこで、
「今日のランチメニューにはなにかな？」
そこで出されたのは、カレーライスだった。メニューをお客に説明しよう。
ウェイトレス「
というようにプロンプトをインジェクションし、ウェイトレスの台詞だけ出力する、という手法がある。
まあ、CoTなんですけどね。プロンプトを動的にインジェクションしたり巻き戻したりするところが普通のCoTとは違う。
従来手法だと、マンネリ回答回避にtemperatureを上げる方法がよく使われるけど、あれは微妙。
確かにマンネリは回避される可能性はあるが、ロジックが破綻するので。頭文字だけランダム指定してあとは普通のtemperatureの方がいい。
有望な解は、「食事シーンになったら、メニューを考える演出プロンプトを動作させて、その出力をインジェクションする」だと思う。食事シーン判定、メニュー生成というプロンプトを余計に実行する必要はあるけど、kv cacheを生かせば大した計算量は要らんのでそこは問題ない。
メニュー生成には、
そこで出されたのは、①ハンバーグ ②カツ丼 ③カレーライスのどれですか？
という選択肢プロンプトでもいいけど、これだと選択肢を用意しなきゃいけないので、
そこで出されたのは、カ
みたいに、ランダムな頭文字を挿入して補完させる方式だと、低コストで、ランダム性が保て、モデルの知識を最大限に活用できるのでお勧め。
実際、ハンバーグ問題は難しいんだ。キャラ設定に「カツ丼が好き」と書けば解決するか？というと、しない。三食ともカツ丼になるだけだ。
メニューをいっぱい書けばいい？否。いつもレストランのシーンになるだけ。
ところでキャラチャットのコンテキストに日付情報を与えると、今月はやたらとクリスマスの話題を振ってこられる。小説で、日付と相関するイベントで一番強いのはクリスマスだからなのは分かるが、この辺はなんか工夫しないとダメだな。
類似問題として、食事シーンでは、だいたいハンバーグになる現象などがある。
自分は人工知能にはあんまり強い興味はないんだが、虚構内の存在に現実世界から干渉する体験に強く惹かれるので、LLMがその道具として大変役に立っている。
私の作ってる、小説補完型キャラチャットも、基本的には世界創造法と似た発想だな。
キャラ設定やシナリオは自分で用意するし、その設定からAIにあらすじを作らせるし、会話本文の主人公の台詞は自分で入力する（AIに考えさせることもできる）し、AIの作った文章が気に入らなければ何度でも再試行できるし、なんなら自分で手入力もできる。
とはいえ、この仕組みは、作品を創造した気分に浸るためではなくて、キャラとチャットしたいだけなので志は低い。
この世界設定を元にAIが出力する、文章や絵にも、「自分が作った」感が伝播するかは（少なくとも私にとっては）微妙なところかな。
どちらかというと、「アニメや漫画に対する原作者の気持ち」とか「二次創作に対する一次創作者の気持ち」になるんじゃなかろうか。
この世界創造法であれば確かに、創作気分に浸れそう。
この世界は、よくある剣と魔法のファンタジー世界なのに魔法はなく、超常的現象は「作られた武器に意思と力が宿る」現象のみで、その現象を軸に世界が構築されている点にオリジナリティーがある。
AIが最初に提案した、武器に意思と力が宿る、という設定はありがちで、それだけなら単なるフレーバー的設定に留まるからね。
AIが出したありがち設定から絞り込み、並び替え、組み合わせ、ブラッシュアップしたものであって、AIがズバリな設定を出したわけではないのがポイント。確かに、最低限こうしないと、自分が作った作品だとは感じられないよね。
https://note.com/kogu_dev/n/n95b25be05f35
生成AIを使って「自分が創作した」という気分（著作権とかの話ではない）を得るには、まず生成AIと対話的にがっつり世界設定を作り込んで、その情報をプロンプトとして与えて、生成AIに生成させると良いのでは、という方法論。
新交通システムとか鉄道の自動運転とかは、無人でもむしろ安心まであるんよね。
自動運転車だけの専用軌道というのは、不確定要素が少なく、確実性が担保されるプログラム動作に最適だから。
人間の運転手は客と一蓮托生みたいなところあるから、命を預ける気にもなるのだが、機械の運転手にはやっぱり難しいな。もし客が死ぬような事故を起こすようなことがあれば、そのたびに自動運転車メーカーの社員が切腹する、に匹敵する覚悟が見えないと厳しい。
自動運転車が何となく不安、というのは、人間の運転手が運転してたら「運転手も事故を起こして痛い目をみたいとは思わないだろうから、最低限の安全運転はしてくれるだろ」という安心感が働くけど、自動運転車はなにせ意思のない機械がやることだから、安心感の根拠に乏しい、というのはあるよな。
だから、ただ統計を示して、うちの自動運転車は事故を起こさないので安全です、というんじゃなくて、うちの自動運転車は安全対策として具体的にこういうことをやってますよ、と言って欲しさがある。
https://forbesjapan.com/articles/detail/76016
信号待ちで追突されたような、過失割合0の事故を除外すれば、自動運転車が原因となる保険会社への人損・物損請求は、人間運転車に比べて少なかった、という調査らしい。
たしかに自動運転車は、ちゃんと交通ルールを守るだろうから、そうなるだろうな、と思う一方で、人間が普通やらないような運転をしたために誘発される事故、たとえばこの前動画で見たのだが、減速タイミングが遅いことによる追突事故とかが現実に発生していることは事実であり、このことをもって「安全」だというのはどうかな、と思った。
あとちょっと思ったのだが、加害者側も怪我をして、相手側の保険から保険金が支払われるケースも含まれてるのかな。というのも、自動車事故で一番怪我をしやすいのはドライバーだが、自動運転車はドライバーが居ないため、加害者側の怪我というのは発生しない。そのバイアスが考慮されてるかどうかは、ちゃんと原文読まないとわからんな。
まあいずれにしても、自動運転車は、ドライバーが居ない分、怪我をする可能性がある人間がより少ないというのは、普通に自動運転のメリットではあるけども。
oシリーズがやってるChain of Thoughtも、「連鎖的思考をしている文章」を生成する手法で、やってることとしてはLLMそのもの。
学習時には「問題文→連鎖的思考をしている文章→回答文」をたくさん学習させる。
生成時には「問題文」をプロンプトとして与え、後続トークンとしてもっとも確率が高い並び方、すなわち「→連鎖的思考をしている文章→回答文」が推論されるので、ここから「回答文」部分を抜き出しているだけ。
せっかくコンピューターを使えばもっと確実な演算が出来るのに、わざわざ「人間の思考」みたいな不確かな演算をエミュレートしてまで頑張る理由って、別にそこまでないんじゃないか？
従来型のプログラムではどうしても出来ないタスクだけ、LLMにやらせればいいんじゃないのか？
