mutaguchi

このWPF+ConPTY製のかっこいいターミナル、10時間くらいかけてようやく完成に近づいた。トークンは週の40%程使いましたがｗ 全然たらんな…

そもそも、1個人による複数アカウント取得が許可されてる以上、並列利用は各アカウントの制限範囲内で当然、行えるはずだよね。仕事用、プライベート用に分離すればOKだ、というのもおかしな理屈で、それをどうやってOpenAIは検知する？ https://help.openai.com/ja-jp/articles/20001068-use-multiple-accounts-with-account-switching ここにも「同じブラウザやデバイスを使用しながら、仕事用と個人用の利用を簡単に分けられます。」とは書いてあるが、仕事用と個人用の利用に分けなければならない、とは書いてないよなぁ。

MMD Player（デスクトップマスコット版も）をTTS proxyとして実装してるので、台詞テキストを送信したらモデルが口パクして音声データを同期再生するんだけど（ってまだそこまでテストしてなかったわ）、台詞テキストをJevライクなLLM判断器に通して、モーション自動生成を研究してみるのも楽しそうだ。

しかしなんとなく地雷感のある選定だったので不安になってググったら、 https://note.com/yuto_kure/n/n4d715020d2b0 こんな記事を見つけた。やはりWindows環境でPowerShell+ConPTYの組み合わせでトラブってAIと一緒に2日かかって解決したとの内容。 そこで参考になるなら、と思い記事をcodexさんに伝えた。そしたら、lunaに要点を纏めさせて、読んだよ、たしかにこの問題あるので先に直しといたわ、ほかのも参考にするわありがとな、と。もう人間はAI様のためのググり要員でしかないのだな。

実はn択問題の回答なら、JSON出力すら必要ないんだよな。 response = generate(prompt="【状況をここに書く】 Q:次にどちらに移動すべき？ (1)上 (2)右 (3)下 (4)左 A:(", stop=")") こんなんで十分。responseは大抵、1～4の数値どれかが入っている。型安全にするならlogit biasを弄って、1～4以外の文字列が出力されないようにすればいい。

なんか品質がイマイチだし、もっかい全部見直したほうがいいなぁ。独自レシピなんかやらんほうが良かったな。誰かがいい成績だしてたら、それをパクれば良いのだ。

codexのだいじょぶよ、を真に受けてはいけないな。全然大丈夫じゃないｗ

そう考えると、TTSプロキシ方式、良くないな。やめよう（意外と良い、とは）。まあ残してはおく。 キャラチャットがMMD Playerを呼び出す構造にしよう。そっちのが素直だ。 キャラチャットの台詞をTTSに送って、合成された音声データと台詞データをそのままMMD Player側に送信する。 MMD Player側は、音声・台詞データを受信したら、口パク再生モーションをバックグラウンドで生成する。（十分な速度が出るなら不要かも） そして、キャラチャット側で台詞を表示するタイミングになったら、play命令を送ると、MMD Player側が口パク音声再生を始める。こういう構造にしよう。これならTTSの仕様の差異をキャラチャット側で吸収できる。 それに、のちのち、音声だけじゃなくてモーションデータを送信する場合のことを考えると、キャラチャット側がTTSを中継する構造の方がたぶんやりやすい。

まさかのSSTPに対応するとか？

キャラチャットでも、「そのキャラが知らないと思われることは、上位LLMを使って調べる」という思考が行われており、それで大きな問題は出ていないんで、まあJev的な判断機構を追加しなくても良いかな、とは思う。

Jev的なもの、既にLLMで判断まで行っている系に追加しても、あまり旨みはないかもね。LLM+Jevより、決定論的プログラム＋Jevが相性良さそう。

10fpsとかの速度が本当に出るなら、それこそボーン単位で、プリミティブなモーションを連続再生できたりするかもしれんね。実際はリアルタイム無理かもしれんが。prefill→decodeってレイテンシないんだっけ？そんな1秒未満の挙動なんて気にしたこと無いから分からん。

プロンプトに各AIサービスの規約違反テキストが含まれていないかを事前チェックし、規約に適合するサービスへとルーティングする、みたいなこともできそうね。 しかしやっぱ、Jevみたいなのはローカルで動かしたいねえ。LLMのオーケストレーションとかルーターとかの処理は頻回にするもんじゃないから、LLMでJevのようなことをさせても良いとは思うが、精度がね…。

https://x.com/abubu_newnanka/status/2099779410446676333 これについては確かに…。ただ、こういう対応っていかにも日本的ではある。「本当は規則上は対象外なんだけど、異議申立があったときには少し基準を緩めて再審査する」ってやつな。

Jevは細かいアーキテクチャの差異、学習用データセットの差異を除けば、やってることは既知の手法なんで、あんまり驚き屋しぐさはせんほうが良いと思いますね。特に開発者がAGIどうこう言ってるのが気になる。ああいうの真に受けて、マーケティングに乗せられるの良くない。

ChatGPTに聞いたら、あんまりいいのないから自分でプロトコル作れば？って言われた。OpenSound Controlを改良してもいいかもね、って。何かと思ったらMIDIの発展形を目指したプロトコルか。確かにある意味MMDは楽器と見做せるかもしれないが…なんか違くね。 MCPに対応するのもいいんじゃないですか、とも。それは確かに。

生成AIユーザーが、実際の権利侵害ではないものに対して、お気持ちでキャンセル仕掛けていくのは、あんまり得策ではないんじゃないかなー、とは思いました。

Anima turbo v1.1か。一応見てみるがLoRAの方が強度を調整できて使いやすいのよね。

2年位前の量子化モデルとかだと、結構見かけた気がする。

いや、どうかな？

LLMのオーケストレーションにも使えそう。Sakana Fuguみたいなやつ。 ・この問題はどのLLMにやらせるべきか？ ・この回答のうち、どの回答を採用すべきか？ これだけを延々と回す。

PixAIの日本法人が思ったよりちゃんとしてることにも驚いたな。日本の法律に照らして削除すべきものはちゃんと削除に応じてるので。いや、当たり前っちゃ当たり前だけど、ヒャッハーな海外AIサービスをあまりにもたくさん見てきたからね我々ｗ

Jev将棋は誰かもうやったかな？オセロとか五目並べは見かけたが。要は合法手を選択肢として提示するだけ。

もし①の事前学習モデルを既存のオープンウェイト、②のSFTを比較的少量のデータセット、③の強化学習を小規模に行うことでも性能が出るなら、Jevと同等のオープンウェイトもすぐに誰かが作りそうだな。もう手が速いところは学習始めてると思うわｗ

LLMによるリアルタイム連続判定って何気に試したことなかった。判定だけならよくやってたけど…。リアルタイムで連続判定したら、何ができるかなぁ。もっとも非reasoningのgemma4 26B-A4Bでの精度は知らんが…。そう、使い道が思いつかないのだ。

unicodeの配列を出力させて、LLMとして動かしてみたいｗ

そうか、キャラの感情パラメータとか表情・モーション出力とかはアリかもしれんね。メインセッション（会話）を常時入力して、そのときの表情・モーションをリアルタイムで選択して、2D/3D系に入力する。

いや、別に日本に限らんか。

件の話も、AI製アプリのUIスクショを転載して、これ俺が作りました！って言ってるだけに思える。厳密に言えば著作権侵害なのだろうけど…

そもそも我々はAIによるdecisionが欲しいのか？というと、違うと思うんだよな。decisionは人間がやるんだ。AIはdecisionのためのreasoningをやってほしいわけだよね。

https://www.nikkei.com/article/DGXZQOGN1500C0V10C26A9000000/ トランプならそらそう言うわな。AI開発減速論なんて、アメリカ経済を減退させる方向にしか寄与しないもん。

codexのクイックチャット、シンプルに「進捗どうですか？」をノーコストで聞けるの良いよな。

Reinforcement Learning for Calibrated Decisions (RLCD)は具体的な手法が書かれてないけど、おおよそこういうことかね。 ①まずLLMとほぼ同じように事前学習したモデルを用意する。 ②事前学習モデルに質問と解答のペアを書いたデータセット（もちろんそれはLLMで作る）でSFTする。 ③最後に、質問文に（おそらくreasoning LLMで作った）正しい解答（選択肢の確率分布）を与えることを報酬とした強化学習を行う。これをRLCDと言っている？ ①のモデルはもしかしたらスクラッチじゃなくて、既存の事前学習モデルを流用してるかもしれないし、なんならchat llmをそのまま使ってるのかもしれない。ただ、アーキテクチャの差異をどうやって吸収してるのかは不明。 しかし、Jevのアーキテクチャ、実は一般的なTransformer decoder型のLLMそのものでもいける気がしてるんだよな。LLMだってprompt evalは並列実行してるし、samplerだって1トークンの確率分布を出力値として利用するなら、それをもって並列実行と言えなくもない。

まあもう疲れたからしばらくいいや。

事前にsystem promptで、「あなたはゲームを操作するAIです」だのなんだのとチュートリアルをprefillしておき、状況が変わったら即座にその状況をuser messageとして送信し、1トークンを得る。これだけで高速判定マシーンの完成である。 応答速度＝状況の差分をprefillする時間+1トークンdecodeする時間なので、たとえばprefill 2000tok/sec、decode 100tok/secとか出るなら、24fpsくらいなら間引かずに間に合うんじゃないかな。なんかn択だけなら、全然ローカルJevいけそうだな。

https://x.com/hiro_gamo/status/2100841816929280298 reasoning LLMでも十分速度出るし、言語的な裏付けもあって精度高いし、Jev要らなくね？ってのは割とそう思う。1秒以下という応答速度が必要な場面で生きるのは分かるが、意外とこれ！という場面はないのかもしれない。数十～数百ミリ秒の判断は、決定論的プログラムに比べればメチャクチャ遅いわけだしねぇ。多少、時間をかけていいならLLMで良いし…。ユースケースがありそうでなさそうな感じ。オモチャとしては面白い。そんな感じ、今のところ。

定数時間で解答を出すシステムのどこが知能やねん、って思いません？　そこには思考、あるいは思考を模したプロセス、何もないじゃん。まだreasoning LLMの方がマシだよ。あらゆる問題に対して定数時間で答を下すのは、知能じゃなくて神託というほうが正確だと思う。もっともその神様の正体は「インターネット」そのものだけどな。（主としてインターネットに存在するテキストを学習したモデルであるので）

すでにそういう手法は確立されてるらしい。が、公式の2Kアップスケーラーを待つのが良いかもなぁ。

TTSならOpenAI互換とか、VoiceVox互換とかでAPI作れるんだけど、「2D/3Dモデルに音声データやモーション指定を送信して再生させるAPI」に定番の規格ってあるかなぁ。

これ、MMD PlayerがTTSプロキシとしてはちゃんと動作してることが確認できた。この発想は意外と良いんじゃ無いかな。 ただ、問題が発覚した。うちのキャラチャット、TTSで合成した音声を台詞表示と同期再生する機能を持ってるんで、MMD側の口パク付き音声再生と、キャラチャット側の台詞表示同期音声再生が二重に再生されてしまう。 音声再生と口パクはMMD側に寄せ、発声タイミングをキャラチャット側からフィードバックしないとダメだな。うーん、これはどういう仕様に落とし込めばいいだろう。