https://x.com/SuguruKun_ai/status/1860474550737338585
この手法が必要となる理由（LLMは数えられない）も、有用である理由（出来ないタスクは外部に委譲）も分かるんだけど、ChatGPTが定額サブスクであることを利用した富豪的手法ではあるよね。
API利用なら、文章生成タスク全体をPythonとかのプログラムとして、作成部分はAPI実行、文字数カウントとリトライ制御は、（function callingではなく）そのまま関数実行するのが良いと思う。LLMに文字数カウント関数を毎回生成させたり、関数実行結果からリトライ必要性を判断させるのは無駄が多い。
開発者氏、こういうAI音声合成ソフトにどういうニーズがあってどういう使われ方をしているのか、誰よりも良く知っている筈だし、その問題点も嫌というほど理解している筈なのに、なんでボイスモデル共有サイトをやろう（協力しよう）と思ったのか不思議まであるんよ。
今回アップロードされたのは、故人の声優のボイスモデルだそうだが、これからは（伏せ字）アニメキャラとかVTuberとかのボイスモデルがどんどん上がるだろうし、どうやって規約で弾くのか、あるいは弾かないつもりなのか、注視していくかな。
下手を打つと声優やアニメやVTuberの版権元から怒られが発生するから、そこは管理が死ぬほど大変だろうけどうまいことやってほしいですね。というか、ボイスモデル共有サービスは、時勢を考えればやめといた方がやっぱりいいと思うなぁ…。
https://x.com/aivis_project/status/1859881048970351098
あー、利用規約や削除基準など定めないまま、HUBをサービスインしちゃったか（まあ知ってた）
A-BをA-Cに切り替えるコストは、KV cacheのsave & loadを駆使しても、そんなに安い処理では無いのも事実なので、なるべく数ターンに渡って会話相手を固定できるようにしといた方がいいかもしれない。
AがB、Cのどちらに話しかけるか、つまりA-B会話にするかA-C会話にするかの選択は、LLMに敢えて選択させるまでもないかな。
@ Bみたいなコマンドや、「おはようCさん」みたいな台詞からの文字列検索で自動決定で十分だろう。
複数人チャットの場合、A-B会話中に【A】が返ってきたら次の話者はユーザーになるし、【B】なら次ターンもA-Bの会話、【C】なら次ターンはA-Cの会話でA（ユーザー）発言を省略、となる。
「次の話者を選択する仕組み」も既に実装してある。
実装は単純で、
A「おはよう」
B「
というプロンプトが、
おはようございます」
A「そ
と補完された場合、【おはようございます】部分を推論結果として出力し、【A】部分を次の話者として記憶する。それだけ。
A-B、A-C、A-D…な会話プロンプトをローテーションさせることのメリットは他にもある。KVキャッシュのsave & loadが効く。ここにB-Cなどのプロンプトまで含めると、保持しておくべきKVキャッシュの数が増えて非効率だからね。
speaker1はA固定で、speaker2にB,C,D…がターン毎に差し替わる。
まあ、そういう作りになってないのは確かなので、大改造は必要だけど、根本的な会話モデルに手を入れなくて済む。
A-B、A-Cの会話を交互に（あるいはLLMによる選択に従って）実行し、チャットログを共有する、というのが良さそう。
A→B→Cという順で発話をさせたい場合、A-B→A-Cの順で会話を実行するが、2つ目の会話ではAの発言をスキップする、という風にすれば良いだろう。（発言スキップはできるようになってる）
また、BからCに話すときは、A-Bの会話中で、「BがA以外の相手に話しかける」イベントとして組み込めば良いな。あくまでチャットの中心はAなので、A以外に話すのはどちらかというと従の行為だから、こういう扱いで良さそう。
でも、会話は「自分」と「相手」の2人で行うものである、というモデル化は悪くないと思ってる。
LLMで実装する場合、会話参加人数分、個別の「主人公が相手と話す、という1人称小説を書いて下さい」というプロンプトを推論することで、登場キャラたちの人格が混ざりにくくなる効果があるので。
だからまあ、うまいこと、このモデルを多人数会話に拡張したいなあ。精度と効率を保ちつつ。
そもそも、chatはspeaker1（ユーザーとか主人公とかのrole）とspeaker2（speaker1の会話相手としてのrole）の会話で構成されていて、両者は等価な扱いをしてないんよね。
なので、A-B、A-Cは良いとして、B-Cの組み合わせってのがそもそもできない。BとCを等価に扱う仕組みになってないので。
キャラチャット、会話の最小単位は1対1で行われるものだ、という前提で作ってて、複数話者が参加する会話を実装する際には、1対1の会話の集合として定義するつもりだった。
しかし、例えば3人の話者ABC（Aは人間ユーザーでも良い）が参加するだけでも、A-B、B-C、C-Aの3つの組み合わせを要することになってめんどいな。
つまり、設計が良くなかったかもしれない。
YouTuberの製品レビュー案件、絶対に忖度が入るので、消費者的には良いことは何もないなあ、と思っていたが、意外とそうでもないという気がしてきた。
当該の案件動画は確かに直接は参考にはならないんだけど、「有名YouTuberがレビュー案件を受けがちなあの製品を、敢えて自腹購入して本音レビューする」というのがYouTuberのコンテンツとして成立し、そっちはかなり参考になる。（ステマは無いという前提は必要）
あと、あまり案件動画にならない、競合製品の方も取り上げられやすくなる効果がある。
n=5^(9^42)の精度の求め方。
ln((1+1/x)^x)をテイラー展開すると、
(1+1/x)^x≒e(1-1/2x)
という近似式が得られるので、これを利用する。
e*(-1/2x)にx=5^(9^42)を代入して得られるとても小さな数が誤差になるので、このlogを取れば誤差の桁数が分かるという寸法だ。
で、それが8368 澗桁だかになるみたい。
https://x.com/Science_Release/status/1859877878701424740
これよく見つけたな、と感心してたが、
e = lim n→∞ (1+1/n)^n
というネイピア数の定義に対して、1～9の数字を1つずつ使って、一番大きくなるnを2つ作ったということなのね。
e≒(1+0.2^(9^7*6))^(5^(3^84))の場合、
n=(1/0.2)^(9^7*6)=5^(9^42)
n=5^(3^84)=5^(9^42)
となる。
Linear Attentionでの学習は、通常のAttention（softmax関数利用）に比べると収束速度は緩やかだけど、その分O(n)の圧倒的速度でsteps数を稼いでカバーできるから問題ない、みたいな感じか。
https://qiita.com/Yosemat1/items/802a41588e8bffaca992
ふむふむ。O(n^2)をO(n)の計算で近似するというんじゃないんだな。O(n^2)な類似度算出計算を、O(n)な計算に分解する「逆カーネルトリック」なる手法を使うらしい。
ただし、Attention機構で使われるsoftmax関数を分解すると、無限大に発散する関数になってしまい適用できない。だったら逆に、分解先の関数をまず決めて、カーネルトリックにより導出される関数をsoftmax関数の代わりに使えばいいじゃない、という発想のようだ。
人類はほんといろんなことを考えるな。
