台詞の最初の1文補完→キャラのCoTによる後続台詞文生成x3→編集者プロンプトによる選択
みたいなのもアリだな。ここまでやるとさすがに2文目以降の出力遅延が気になるレベルになるか？
こういう「編集者プロンプト」で台詞選択をするのもいいが、いっそCoTでもいいかもなぁ。
台詞の最初の文は通常通り、台詞として、小説文の補完文として得る。それに続く台詞は小説の登場人物によるCoTを行う。
こうすることで、応答速度と思考による精度向上の両立が取れるのでは。
で、この手法の良いところは、最初の出力文は台詞として確定するので、出力したら即座に音声合成に送れる。そうやって合成した音声を再生している隙に、後続文の推論、選択、音声合成をやる、ということが可能になってくる。これで台詞の精度を上げつつ（上がればいいな）、応答速度も低下しない。
「そうですね。」のような、返答の最初の文はおかしくないことが多い。となると、最初の文は敢えて選択せず、出力をそのまま採用し、これに続く文を3つ出力して、それを選択させてみようかな。
選択プロンプトとしては、
ユーザーが「今日は良い天気ですね」と発言しました。これに対するAIの返答としてもっとも適したものは、どれですか？
①「そうですね。でも雨が降っていますよ。」
②「そうですね。過ごしやすい気温ですね。」
③「そうですね。良かったですね。」
のようになる。これだと変な台詞を検出しやすくなるのではないか？
台詞全体を3個出力するよりコストも安いしな。試す価値あり。
台詞で矛盾が起きやすいのって、台詞が複文になるときが多い印象。
つまり、
ユーザー「今日は良い天気ですね」
AI「そうですね。でも雨が降っていますよ。」
こういうの。しかし、この文章のおかしさを、この台詞を出力させたモデル自身に判定させるのは厳しい。
キャラチャットで同じプロンプトで3つ台詞だして、良いのをfunction calling的に選択させるプロンプト、効果が多少あるかな程度で、応答速度を犠牲にするまでのものかは疑問。結局は評価も同じモデルでやるから、うまく最良の選択ができてない感じ。論理エラーの検出が一番したいことなのに、それが一番苦手な感じ。ちょっと戦略を立てよう。
ルーラのMP消費が0で話題になってるけど、昨今のリメイクだとだいたい消費1だったし、そんな大胆なアレンジでもないのではないか？というかドラクエ6から消費1だしな。
ドラクエ、瞬間移動コストはゼロに近くしておくから、その分世界中を飛び回っていっぱい探索してね、という思想があるんだと思う。
単純に、ボット発声中はマイクを切るという実装は無しではないのだけど、そうすると、ボットの発声を遮るとかはできないからな。
話者分離がまだ出来てないから、スピーカーから音声再生すると、その音声をマイクが拾って、ユーザー入力と見做されて音声認識されちゃう。ハウリングみたいなもん。まあヘッドセット使えばいいけど。
あるいは、「前回のボット発言と似た発言が音声入力されたら、それはハウリングと見做して弾く」みたいな処理を入れるのもいいけど、その判定も案外難しい。一字一句同じになるとも限らないしね。
AIでリアルタイム話者分離って、実用的なのあるのかなぁ。ちょっと大げさ過ぎる感じもする。
音声入力は非同期で受け付けるんで、キャラ発声中でも入力できるから、音声認識にかかる待ち時間が気にならないな。これは思ったよりリアルタイム会話になってる。ローカルでここまでできるんや…
faster-whisperでlarge-v3、fp16じゃなくてint8でも実用精度出るな。これならLLMの7B、Q8_0と同居可能だ。
faster-whisperでWhisper large-v3を使ったリアルタイム音声認識結果を、キャラチャットのユーザー入力として流し込めるようにして、キャラとの音声会話が出来るようになった。
キャラ発言中にこっちの音声入力も割り込める。
しかしもうVRAMがギリギリ。12GBは人権ないなぁ。
これ、できた。LLMがストリーム生成した台詞が、適度な長さ（フィラーに限り、最初の句読点まで）になったらその時点で即、TTSの生成キューに入れて、音声合成できたものから即再生。
今のところ理論上、音声応答速度は最速になったはず。良き。
https://x.com/EzoeRyou/status/1858130187407519808
そりゃ世界中をくまなく探索するんだよ。当時は探索の楽しみがあったよなぁ。
このキャラチャットシステムは、kv cacheを使っていてChatGPT並に応答が早いので、せっかくだから、音声応答も早くしたかったというのがあった。だいぶ早くなって満足。あとストリーム生成もさくっと実装したいところ。ちょっと作り的にめんどさがあって、滞ってるが。
ただし、問題点はある。
「はい、よろこんで、やらせていただきます。」
と、
「はい、」「よろこんで、やらせていただきます。」
は別の台詞なので、TTSでは後者は不自然な発声になることがある。
これの解決方法も一応ある。
「はい、」を生成、再生したあと、「はい、よろこんで、やらせていただきます。」を生成し、「よろこんで…」から再生すればOK。ただ、特にAI音声合成だとタイムスタンプが得られない（おそらくだいたいは）ので、「はい、」の再生時間を取得し、「はい、よろこんで、やらせていただきます。」からその再生時間の前後で無音領域を検索し、無音領域の後部分だけ再生する、みたいな工夫がいる。そこまでするのはちょい面倒。
LLMキャラチャットのTTS応答速度を上げる方法をちょっと考えていた。
フィラーを自動挿入する方法はありがちなんだけど、フィラーを含めての台詞生成だろ、と思うのでそれは避けたい。
そこで、「生成された台詞の最初の句読点までをフィラーと見做して、先に音声合成する」という案（実は以前から考えてた）を実装した。
「はい、よろこんで、やらせていただきます。」
という台詞がLLMで生成されたなら、
「はい、」の音声をまず生成し、「よろこんで、やらせていただきます。」を音声生成キューに入れる感じ。
これはまあまあイイ感じだ。ストリーム生成される台詞をストリームのままTTSに送る仕組みに今はなってないんで、これでは若干の遅延はあるけど、それでも台詞生成が律速だから十分効果ある。採用。
この場合だと「はい、」という音声データを生成したらキャッシュして次回からキャッシュを利用することで、応答速度を更に上げることも考えられるけど、TTS側が決定論的に音声を生成するならまだしも、AI生成なら毎回違う音声データが得られるんだし、キャッシュしない方が良いと思う。
