![見出し画像](https://assets.st-note.com/production/uploads/images/110767391/rectangle_large_type_2_134c4f4110541955f360d27a19b6bc40.png?width=1200)
AITuberを高速に育てるための魔境入口
最近、お仕事で開発していた「AIVTuber/AITuber/AIドル」が、いくつか公開実験フェーズに入ったので、なんとなくノウハウっぽいものの一部をまとめておきます。
この話をまとめると
AITuberのデバッグは大変です。細かな実装はさておき何が大変なのか、
「AITuberを高速に育てるための魔境入口」としてまとめてみました。
ともあれ公開実験をライブで観てね!
公開実験ライブはこちら
たぶん(曜日によってですが)13時と15時に公開実験放送を実施しています。まあお目汚しかもしれませんが、真剣にテストすると、わかることがいっぱいあるので残しておきます。
急速な成長の過程を味わってみてください!
https://youtube.com/live/4sGnUjfOF-Q
https://youtube.com/live/QwJFPWKE23k
https://youtube.com/live/LxOyK9sFuZQ
https://youtube.com/live/1laKlcmptKM
(そのうち削除するかも…)
ちらみせコンフィグ画面
![](https://assets.st-note.com/img/1689249996685-zFoI5f7uhd.png?width=1200)
ちょっぴりはやく配信開始した第3回の公開実験冒頭で、コンフィグ画面が見えちゃったりしています。特に隠す訳ではないのですが、ガチな運用になったら隠しちゃうような内容ですよね。けっこう汎用的なAIを作るために様々なコンフィグ要素を内蔵しています。
データの徹底した外部化
上記のコンフィグもそうなんですが、できるだけUnityコード内にハードインプリしないようにしています。もちろんPoCとしての実装はハードインプリも多いのですが、設定、動画再生や、シナリオ、番組編成、プロンプトなどなど、可能な限り、外部ファイルやデータベースにしています。またデータベースと言っても、操作性や運用性を考えて、Google Spredsheetを活用しています。
AITuberのデバッグは大変。
開発段階では起きなかった現象がライブ配信中にはたくさんおきます。主にわかりやすい箇所ですと、YouTubeLiveコメントからのメッセージ取得→返答生成→発話です。どんなタイミングで取得すべきか、何を優先すべきか、どれぐらいの長さで発話すべきか、次の番組(一つのYouTube番組内に様々なミニコーナーが実装されている)はいつ始まるか、割り込まれたら何が起きるか…などなど、単体テストでは起きえないことがいっぱいおきます。普通のチャットボットのように1対1での処理ではありません。たくさんのユーザにアクセスされて、同時にいろいろ発言されて、加えて雰囲気を壊さない工夫をしていかないと、細かなUXは評価が難しい、というか、わからないですね。
実は、けっこう間が悪いタイミングで視聴者さんからコメントをもらうことも多くて、運用面での見直しなんかも必要になります。「UXとして適切な秒数」ってのはあるみたいです。
でもこれはVTuberのR&Dを長年やってきた側のノウハウとか、その文化理解とかもあるかもしれない。
⭐︎それが証拠にTwitchとかだと全然違うかも
デバッグのための配慮
もちろん、公開QAに入る前に、部品の単体テストなどは行っています。特にLLMへの問い合わせ、プロンプトは、感情表現やキャラクター設計のために凝ったことを実装しているので、いろいろコメントを通してみていただけると幸いです。具体的にはプロンプトインジェクション対策とか、顔の表情の変化とかです。ユニットテストの段階ではもっといろんな機能があったのですが、毎回のテストで少しづつ実践投入しています。
でも、LLM(今回はOpenAI版のgpt-3.5-turbo系)って、応答速度が30秒ぐらいかかることもあって、なかなか読めないんですよね…。
無料ユーザの条件にすら気を遣う必要がある
エラーメッセージは裏側で運用Slackに通知されているのですが、そのエラーメッセージ(OpenAIからの返答)もよくわからないメッセージが多いのもつらいですね。
今日はなんと番組途中でOpenAIのAPIが枯渇してしまいました。そんなエラーが出ているわけではないのですが、どうもダッシュボードを見るとそんな感じ(辛い)。慌ててクレジットカードを追加してみたら動きはじめる……なんてことが起きました。本来、リクエストのデイリーリミット(1日当たりのリクエスト数)は200回に設定されているのですが、いつの間にかクレカ登録がない無料ユーザは100回になっていた……なんということでしょう。
こんなふうにOpenAI側の仕様や制限がコロコロ予告もなく変わるのは辛いですね。クレジットカード番号やアカウントの電話番号はOpenAI側で控えられているので、たくさん無料アカウントを作ればいいということではなさそうです(すでに試したので辛みがある)。
開発側でテストをすればするほど起きるリスクもある
そもそも開発とプロダクトでアカウントごと分ける必要があります。 API、デイリーリミットの回数制限はAPIキー毎ではなく、アカウント全体だったりします。つまり、開発者Aが自分のビルドのテスト行う→開発者Bが自動化テストシーケンスを実施する→本番環境でいい感じ…と思ったら本番最中にたくさんお客様が来て…挙句APIが枯渇した!なんてこともよくあります。この問題でいうと、YouTube Data APIもデイリーリミットが厳しいうえに、GCPプロジェクトやGmailアカウントごとにロックがかかるので、十分なAPI回数を確保したうえで、1日の制限を計算して実施する必要があるのですが、規模が大きい開発になればなるほど慎重な管理が必要になりますね。
LLM特有の難しさはオンプレなら解決するか?
OpenAI等のクラウドAPIを叩くのではなく、オンプレミス環境(この場合、GPU搭載のその辺にあるPCを使う)なら解決することはあります。これはもう、ローカルLLM、すなわちLLLMを運用するしか!ってことも結構ありますが、構築したら構築したで、やっぱりAPIの単体テストからやりますので、あまり問題解決にはならないかもですね。それよりもAPIの枯渇やトークン消費などを適切にする技術のほうがいいかも。
追記:実は並列化という方法で解決している
一つのライブ配信に並列して、複数のバージョンのAIOSを試験しています。
詳細はまたリクエストがあれば語ります。
そして、ライブアップデートにも成功しました。
ホットスワップとでもいうか…。
最新版は英語も読める!
(読み上げ自体はVoiceVoxなので上手ではないですけど)
追記:見える形で助けを求める
実は実験放送5の途中のアップデートでAPIが枯渇した時や、謎のエラーが発生した時に、運営担当に助けを求める時の「隠語」を仕込んであります。
![](https://assets.st-note.com/production/uploads/images/110767419/picture_pc_1ab7a291d212f8ab070f16554de8713f.png?width=1200)
「おなかが痛くなった」が何のエラーなのか、を用意しておけば良いのですね。
VTuber用語の「お花摘み」(トイレ休憩)とかと同じと思えば尊いやつ…。
この手のUX実装はAIで解決できるか?
この手のUX実装はAIで解決できるか?考えてみましょう。
ほら、よくあるじゃないですか。「GitHub Copilotで効率化」とか「Chat GPT Code Interpreterで簡単」とか。まあそういうのも嫌いじゃないんですが、今のところ、AITuberの視聴体験とか、テストのケースを考えるもは人間の仕事だと思うんですよね・・・もちろん、渡したコードから「このAPIとロジックのテストケース書いて」みたいな時代はすぐ来るんでしょうけど。今のところ、UX開発者が一番、AI開発時代で喰っていける感じはするるよ・・・。LLMへのプロンプトとか、反応速度の調整とか、モデル側のチューニングも含めてなんで、完全に垂直エンジニアリングなんですけど、人工知能の中でもエージェント開発職人とUX開発職人みたいなやつ。
とはいえ今日出たばかりのこの本、気になる https://amzn.to/3PRzpG3
目次を読んでみると、状態遷移図からのコード生成とか、テスト駆動開発(TDD)によるテストとかちょこちょこっと刺さる項目がある。
そもそもUnityフロントエンド側で実装すべきではない処理もある
UnityC#で感情ステートマシンとかジョブスケジュールとかやろうとせずに、番組ディレクション部やNLP部分はPythonで書けるものはPythonで書いた方が良いところも多いと思います。ちなみにChatGPIにはFunction機能も出てきましたし、LangChainとかFakeLLMを使ったデバッグもありますので、この手のディスカッションが過去のものになる可能性は高いのですが…どこからどこまでをUnityで実装して、どこをPythonで実装するか、というのは意外としばらく手探りだったりすると思います。だからこそ「R&DのR」の職人芸なのですけど。
とはいえその後の開発者や運用者への手離れを考えると、チームメンバーの技術スタック的に難しいことやわからないことが多すぎるのもよくないので、いろいろ工夫して単体のEXEとVoiceVoxとOBSだけで動いています。
明日のライブはこちら。
2023/07/14 13:00~ AITuber実験放送5 - Experiment of AITuber
明らかに少しずつですが、良くはなっていると思いますので、どうかあたたかなコメントを投げてあげてください。内容はちょっと香ばしくても大丈夫ですが、YouTubeに怒られたり、ダミボちゃんに嫌われたり、周りのファンのみなさんに嫌われたりしないようにお気をつけください。
また、合間合間に入ってくる「MetaChatNews」もGREE VR Studio Laboratoryの実験番組です。 スマートフォン向けメタバース「REALITY」のアバターから生まれた MetaDreamers のキャラクターたちが様々なニュースについてゆる~く語り合います。研究っぽく表現すると、マルチエージェントによる個性付き、オチつき自動会話生成、ってことなんですけど、まあ技術的なサムシングは忘れて、個性豊かな雑談をお楽しみください。
プレイリスト https://bit.ly/MCNKWS23
ご感想ありがとうございます
ご質問に答えていきますね……!
プロンプトインジェクションについて
これ読んでふと思ったけどプロンプトインジェクション対策に時間割くのってどれぐらいがいいんだろうなって。もちろんセキュリティとか問題発言防止はあると思いつつ、一定以上はそもそも悪意ある投稿への牽制やコミュニティ文化治安で担保すべきな気もする。「おなか痛い」の話はめっちゃ面白い発想w https://t.co/N94C9kEIat
— Jun Tamaoki / 玉置絢 (@OKtamajun) July 14, 2023
プロンプトインジェクション対策は「全力肯定彼氏くん」の頃、かなり研究しました。
ChatGPT3.5元祖の頃は、プロンプトインジェクション対策が全トークンの半分ぐらいになっていた事もあります。
でも単純なサニタライズとか前処理はC#でやった方がいいですね。リクエスト自体が無断で、API費を払って、他のお客様の迷惑になる行為なので。
最近のGPT3.5-turbo-16Kではトークン量も多いですし、関数呼び出しとかで回避する方法もある、そもそも上記の通り、プロンプト部分は外部化かつライブアップデート&ホットスワップ可能なので、配信の真っ最中でも不正があれば、運営Slackに「おなかがいたい…」と通知が行き、対策が実施されます。
※実際のVTuber運用だと、YouTube上で警告すればいいことですね。
他にも質問あればこちらにコメントどうぞ〜
この記事が気に入ったらサポートをしてみませんか?