GPT4V for AI Character 実践活用ノート 「活用編」
前回（https://note.com/abelia_0211/n/n6c1031d004ca）
ではOpenAI DevDayでの発表内容を振り返りました。
今回は、AIキャラクターへの活用可能性を見ていくことにしましょう。
特に、制限・注意点の類が多くなる内容になります。
GPT4Vで「視覚」実装
gpt-4-vision-previewを使うことで、AIキャラクターに視覚情報を与えられるようになりました。
画像をbase64にエンコードするか、URLを投げるかで使うことができます。
端的に言ってしまえば、視覚追加によるありがたみは
・ユーザー自身では言語化がむずかしい情報を与えられる
・ユーザー自身で言語化するべきではない情報を与えられる
・言語化するにしても手間がかかる情報を画像添付で省略できる
になるのですが、
副次的な効果として、「AIキャラが視覚を持ってるかのように演出することができる≒ユーザーは相手キャラが視覚をもってるかのように没入しやすい」
具体的なシチュに落とし込むならば、これらの強みは次のような活用例にまとめられます。
・内カメにして、相手の応答に対し、自分は表情やハンドサインのみで応答する（非言語入力）
・これから食べるご飯の画像を与えて、楽しみ共有する（手間の削減）
・テキストと画像などが複合していてかつ、２次元的な配置を持つPC画面のスクショを共有し、質問やリアクションを求める（手間の削減）
などが考えられます。
個人的には、AIキャラとは主に”会話”をするものですから、この手段の幅が広がったことが感慨深いですね。
というのも、相手との会話コストの低下及び取引できる情報量が増えることは、相手に対して感じるプレゼンス向上にもつながります。
価値ある能力を持つというだけで、実在感は向上するということです。
上で挙げた例は、だれでも考えつくべきものに過ぎません。
結論、今回のアプデ発表で最も影響が大きいのはこのGPT4V APIの登場になりますが、以上のことはChatGPT上単体でもできてしまうことでした。
次は、周辺機能やツールなどと組み合わせてより効果的に使ってく方法を検討していきます。
能動的に画像を取得させるには？
はい、ただGPT4Vを用いるのであれば画像入力は「ユーザー」が画像をしかるべきタイミングで用意して提供しなければなりません。
要するに、「見て見て！」と言っても見てくれません。悲しい
なので、相手に能動的に非言語的な「行動」として画像を取得してもらう機能は人間らしい能力幅として必須になります。
非言語的な行動を起こすためのLLM内ツールも提供されていましたね？
Function Callingの出番です。
Tool情報として"Get Image"などと組み込んであげて、
繋ぐ発動内容としては、スマホのカメラ（内・外）、Webカメから自動で写真を撮って入力情報に加えてくれるみたいなのがあると良いですね。
これで、つまるところ
デフォルトではキャラの目を手で開いて画像を瞳に映させなければならなかったのが、
カメラこそ自分で持ち運ばなければなりませんが対話中に自分で目を開いてくれるようになったというわけです。
更に、後述の仮想空間内のカメラなどを使えば、そもそもどこを向いて画像を収めるかまでの連携までできたりします。
と、ここまで実は仮定の話になります。
というのも、前回でも話しましたが、画像入力対応のgpt-4-vision-preview単体では、Function Callingに対応していません。
一応、他のモデルと動的にスイッチする、つまりToolとして能動的な画像取得を発動する際に、Function Calling対応のモデルからgpt-4-vision-previewに切り替えるという実装で行けると思いますが、
なまじ画像入力とテキスト入力があり得るという対応のため、
リクエストボディの構造で一番変わってほしくないmessageの構造が変わってしまっています。
まあ、テキスト情報だけの以降ならギリ問題ないかもですが、
function callingの発動指示履歴や逆にGPT4Vから元のモデルに戻るときの画像URLなどなど、会話履歴に齟齬が生じるのはもちろん、単純に実装が地獄そうですよね。
ChatGPTで、Pluginが使用可能なモデルとVision対応とで完全に分離している通りということです。
なので、恐らく皆さんのためになる情報としてはここがMAXになるかと思いますが、今後の方針としてはどちらにも対応したモデルの登場を待ちましょう。
仮にこの実装コストと賞味期限切れの早さも問題ないという方でも、
サービスに組み込むには、日に１００回程度しか使えないという話ですから、しばらくは個人用のプロトタイプに使う他ないのではないでしょうか。
Assistants APIで楽々AIキャラ実装
ChatGPTというサービスの主機能もろもろ叩けるように整備されたAPIが「Assistants」です。
結論から言うと、インスタントにAIキャラというものを作れますが、
技術力がある個人で、完成度の高い１体を作りたいという場合に
Assistants APIを使用するのはお勧めしません。
先に大きなメリットを挙げておきますと、
最強ツール「Code Interpreter」と「Knowledge Retrieval」が簡単に使えるようになります。
そして、会話のインスタンスもといスレッドの管理やファイル操作などまでAPI操作の範疇で楽々できるようになるなど、強力なメリットが輝く一方で、
AIキャラクターというジャンルに限れば少し疑問符が付く点もいくつかあります。
まずは、長期記憶能力です。
ChatGPTがすぐ物忘れをしてしまうのはこれまで使い込んできた皆さんなら良くわかると思います。
APIで設定できる内容として、まずLLMモデルに始まり、何回分のやりとりを記憶しておくかなどもありまして最大で１００など指定できるようですが、
まあ、日を跨ぐレベルで使うにはとうーんという感じです。
AIキャラである以上、個別ユーザーに一体のキャラを送り込むみたいな提供方法が想定されますが、このときユーザーあたりの会話スレッドインスタンスを複数用意できないようにする方が、理想的です。
というのも、強力なキャラ性を与えて運用する一方、少し話を続けた後で別インスタンスに言ったらごっそりそのことを忘れているなんてのは、自分の情報を伝えて対話取引の発展を願うというそもそもの対話動機が大幅に削減されてしまいます。キャラの成長がないという話ですね。
新たに発表されたモデルは１０万トークンを超える容量を持っていたりと、ごまかせる余地も出てきましたが、
Knowledge Retrievalも長期記憶能力として運用するには半端であることからも、
個人で一体を作ってカスタムして突き詰めていくのであれば、逆に枷となる機能も多いように感じるので、ここはスキルレベルと作りたい物のレベルとで相談した方が良いかもしれませんね。
対仮想空間インタラクション
これ、特に私が期待する項目です。
GPT4Vで実際の利便性だけ考えるなら、現実の写真だったりパソコンのスクショだったりってのが利用例として多そうですが、
現状、AIキャラは憑依させる理想的なロボットもとい肉体がない状況では、仮想空間に配置するということが多いです。
しかし一方で、これまでのAIキャラは仮想空間にいつつ、
その仮想空間内でのインタラクションは起こしづらくという半端な状態にありました。そこに存在してる感が環境作用の薄さによって逆に損なわれてたという感じですね。
これがGPT4Vによって大きく解決されます。
これまでの機能だけでも
・「こっち向いて」→頭を向けてくれる
・VR空間内のものに対して「○○（具体名）取って」→取って持ってきてくれる
・一緒にベッドにいって寝よう→寝室へ行って添い寝
・耳かきして！→膝枕耳かき開始
・強くして～→強くしてくれる
・視線で見ている位置に対してリアクション
くらいのことはできましたが、これらは事前にルールベース的にシナリオを限定してあげてプログラムしないといけない部分が多かったです。
しかし、ここに仮想空間内のカメラをGPT4Vにつなげてあげることで、
・頭をなでなでorぴこぴこハンマーで叩くなど→それぞれされたことを認識して反応（衝突した物体の内容検知及び事前のログメッセージのプログラムの必要なし）
・その右の青くてでかいの取って→取ってきてくれる（指示語や色だけでは本来判別できないオブジェクト名を視覚と統合して特定できる）
・非ルールベース的に（Rayや視線検知デバイスなど使わずに）視線を向けたら相手も反応する
といったことが可能になります。
仮想空間が仮想たる所以は、そのポテンシャルの少なさに合ったんですが、
こうやってAIキャラがインタラクトの糸口で増やしてくれたことで、より現実に近づきました。
まだ結局、モーションの生成モデルや汎用的なインタラクトシステムがないので、それぞれモーションや最終的なインタラクトのシステム自体は、動作名・イベント名に対してFinalIKなり物理コンポーネントや親子制御などを駆使した一連の手続き動作的に定義して用意しておく必要はあります。
（基底現実は一意の物理システムのみで動いてるので長期的には楽）
しかし、現実空間やARではできない強力なこととして、
仮想空間ならではの第三者視点を用いることができるというのがあります。
「頭をなでなでされる」ことを認識する能力がこれにあたります。
単純にキャラの目の位置にカメラを付けるだけでは、これは不可能です。
人間なら誰しも、脳内で俯瞰的な視点を以て周囲の状況を予測・把握することがありますが、一応は音や触覚など複合的に知覚を合わせることでそれを可能にしているのに対し、
Meshや身体部位ごとに受けた力や摩擦、接触している身体部位と相手オブジェ名の組み合わせを一々プロンプトに言語化して投げるのはLLM的にはナッセンスです（音のモーダルはモデル対応してないし）。
しかし、CGなら予測も何も実際に俯瞰視点のカメラを配置することができるので、こういった問題が疑似的にですがほぼほぼ解決します。
レンダリング負荷や逆に本来の目の位置からは見えてないはずのものを当たり前に認識してる前提で話されると不気味というかそれはガチの第三の目なのでよくないですが、こういった仮想空間内でのインタラクションの幅を大幅に広げることが可能になりました。
まあしかし、人が行う動作には、結果的な状態だけではなく過程の時間軸ありきのものも多く、
画像入力では完全に対応できないものやどこで切り取るべきか問題にまた視覚が必要であったりとまだ完ぺきではない問題も多いです。
短い映像であればコンマ秒ごとに切り取った画像を入力するってのでも良いかもですが、まあトークン量によるコストは切実な問題ですし、連続した画像の入力に対し、時間的な関連性や順序をどこまで正しく認識してくれるかについてはまだ調査が必要そうです。
一応、サッカーのシーンを実況させてみたみたいなデモは上がっていましたね。ただ１日リクエストは１００回までだったりと（画像の枚数ではないですが）毎秒認識させてとかいったやり方はできなさそうです。
大体は以上になります。
繰り返しになりますが、これらはFunction Callingが一体になってる活用例です。
できないことはないという話でしたが、実装コストや賞味期限が早そうなので、どちらも併せ持つモデルの登場が待ち遠しいですね。