GPT4V for AI Character 実践活用ノート １「発表まとめ編」
こんにちは、IKA（https://twitter.com/Abelia12345）です。
最近、授業出てなくて教授から安否報告を求められたのでVR連動膝枕耳かきマシン作ったなどと伝えたら案外肯定と応援の返信が来て良い先生だなと思いました。男性諸君、東工大に来よう！
本題です。先日、OpenAIの様々な大型アプデ発表がありました。
今回は、AIキャラクター制作の観点で見た注目の発表内容の振り返りとその分析、そして具体的な活用方法を見ていこうと思います。
※発表内容が多すぎるので、「発表まとめ編」と「活用編」の
２編でお届けします。（活用編は後日追加）
発表振り返り
AIキャラクター開発者が注目すべきは、
・Vision（GPT4V）のAPI登場
・TTS（合成音声）API
・Assistant API
・code interpreter＆Knowledge Retrieval
・pararell function calling
です。ほぼ全部かも笑。
順に説明します。
Vision：gpt-4-vision-previewモデルの登場
参考：https://platform.openai.com/docs/guides/vision
ChatGPT（月額有料オプション付きのWeb/スマホアプリの方）では少し前から使えていましたが、
テキストに加え「画像入力」に対応したgptモデルのAPIが使えるようになりました。
画像入力のToken消費量は驚くことに
512pixel×512pixelあたり170tokenです。
（※デフォで+85Token付きます）
読み込める画像の最大解像度は長辺が2048・短辺が768です。
これを超える画像は自動でリサイズされるので、くそでか論文誌１ページ.pngの文章（本文）とかは詳細には読み込めなさそう。
言語差もありますが、自分でも日本語文字OCRタスクやらせてみたところでかい文字にしか反応してない感じで微妙でした。
結局tokenあたり純テキストと画像とで含められる文字量はほぼ同じかそれ以下かも。論文翻訳タスクが上手く行ってるデモを４月に見せられた時は少し期待したもんですがね。
とはいえ１枚当たり最大でも、1500tokenに収まる計算で、
文字にしてしまえば数文字という情報でも文字に起こすというのがUX上の課題だったのを画像添付で楽々できるようになったので革命です。
これまでも視覚の再現はimg2txt→ChatGPTという２つのモデルを介して疑似的に行うことはできていましたが、GPT4Vは完全にマルチモーダルなモデルなので、直接画像入力を受け付けます。既存のGPT4モデルと比較しても、応答速度などにパフォーマンスの悪影響が出ないのが良いですね。
ということで次回後述しますが、
これでAIキャラに人間でいう「視覚」を持たせることができるようになりました。
しかし、色々注意点もあります。
gpt-4-vision-previewが画像入力に対応してるモデルとなるわけですが、
他の最新モデルがfunction callingに対応している一方で、こちらは対応していないみたいです。これは痛い。
サービスレベルで組み込むにしても、１日あたり１００回までとリクエスト制限がかかってますので、それも難しいケースが多いでしょう。
(レート制限Tier5は知りません。最近RateLimitのページが更新されたようでようやくランクアップ条件など色々明確になりました。)
TTS：高品質な多言語対応の合成音声生成モデルAPI
参考：https://platform.openai.com/docs/guides/text-to-speech
合成音声モデルをAPIとして提供し始めました。OpenAIからTTSは初です。
スマホアプリの方では、音声対話機能として少し前から登場してましたが、
注目すべきは、
・多言語対応
・フィラー（あー、えーと）が自動で挟まる
という点です。
ElevenLabの合成音声も多言語対応ではありますが、フィラーまではありませんでした。フィラーが自然な音声対話において如何に重要かは言うまでもありませんが、Voiceでも天下を取りに来てしまいましたね。
まあしかし、ElevenLabでもそうだったのですが、
多言語対応のうちの日本語は、少々外国人話者風のアクセントになっていて、聞き取れるけど自然ではないです。
（ElevenLabは韓国・中国人風、OpenAIは英語話者風）
話者スタイルも６種ということでmoe~moeボイスはありませんでしたし、
任意の声でファインチューニングできるわけでもなさそうなので、今後に期待ですかね。
（余談ですが、ElevenLabではファインチューニングこそできますが、大分学習させた声色とずれる上、本人の声であることの証明認証の突破が必要になるなどこちらもAIキャラ活用ではお勧めしないです。）
Assistants API
参考：https://platform.openai.com/docs/assistants/overview
「Assistant」新しい概念になります。
一言で何を目的にしたAPIかと言えば、
今までのChatGPTという形式でユーザーに提供してきたほぼすべてのものを、完全に個々の開発者で改変・複製できるようにしたものです。
逆に、これまでのChatGPTはAssistantの一例と捉えることができます。
具体的には、ユーザーごとに会話のセッション、勝手にセッションのタイトル名が付いたり～、独自のツールライブラリを提供出来たり～という感じで、これをノンコーディング風のエディタ―とともに発表されました。
ChatGPTにはまだ、UXUIやツールの多様性で袖口を広げる余地があると判断したということでしょう。
ChatGPTの機能面を丸々再現できるAPIを公開してUGCを狙い、もしChatGPTよりありがたがられるものを作れるんならやってみろよという挑発のようですね。
詳細はまた後日とされていますが、作ったAssistantを販売できるレベニューシェア型のストアプラットフォームが出るみたいですよ。
多分、chatracter.aiとかは冷や汗だらだらなんじゃないでしょうか。もとよりキャラクターに対する扱いの浅さのためか、日本では流行ってないようですが。
Code Interpreter＆Knowledge Retrieval
参考：https://platform.openai.com/docs/assistants/tools/code-interpreter
Code Interpreterは、pdfとかcsvファイルとか投げて解析させられたり、投げたPythonコードの実行を行ってくれたりするやつです。
Knowledge Retrievalは、投げた書類に含まれる情報が膨大であっても（つまり、promptに含めるにはoverで雑多な情報でも）、文脈に応じて適切な箇所のみを拾ってくる感じのやつですね。
ただし、精度の面は、恐らくですが、もとより提供されてた公式のembeddingモデル使ってるだけなので、そもそも検索文の生成あたりの上手さが気になります。そこらへんの過程のフィードバックがなさそうなので、なんとも分からんです。
加えて、AIキャラの唯一希少性、キャラクター性、発言一貫性など重要な要素に「長期記憶」が関わってきますが、なまじRetrievalの処理が向こうで行われて結果的に拾い上げた文章だけを返す仕様になってしまってるため、
改変なども難しく現状はまだ長期記憶再現機能の代替にはならないということは念を押しておきます。
いずれも、ニーズの高い機能で、これまで下々の民がこぞって自力実装してきた様子を見かねたのか、とうとうOpenAI直々にToolとして実装してきたという感じです。
ここ大事なのですが、Assistants API上でのみ使えるToolになります。
解析するファイルをアップロードしたりする処理も実装する関係で、いずれにしろではありますが、往来のチャットモデルのfunction callingにこれらの名前のツールを登録したからといって、処理まで発動してくれるわけじゃないということです。
向こうの処理としては、恐らくToolとしてcode interpreterなど公式提供のツール名が投げられた場合に、
１．まず向こうで管理してるDescriptionや引数が付け足され生成
２．それを拾ってファイルやコードを読み取り・編集・実行等の処理を挟んで
３．返り値についての情報などをプロンプトに追加する
（＋α. Instructモデルで次の生成を行うかYes/Noで行動続行）
って感じなのでしょうが、それはAssistants APIを経由した場合になります。
なので、これらを既存のAIキャラやチャットボットサービスに組み込みたい場合には改めて、Assistants APIに移行する必要がありそうです。
（ここだけ不満不安なんですが、モデルごとに受け付ける機能についてドキュメントに詳しく記載がないものもあったりと、(pararell) function calling対応のもの、Vision対応のもの、上のTool対応のモデル・APIが流石にごちゃごちゃしてきて辛い。）
Pararell Function Calling
これまでのFunction Callingは、登録したツールの中から一つだけ選んで発動指示を生成という仕組みでしたが、
Pararell function callingでは文字通り、一度に複数回分のツール発動指示を生成できるようになりました。
ポイントとして、
例えば往来のFunction Callingでは、順当な実装をすれば
「近くのハンバーガー屋さんを探す」というミッションに対し、
１．位置情報≒現在地点の地名の検索
２．地名と併せ、「ハンバーガー屋さん」で検索
(ここで情報が取得できなかった場合は、検索用語や地名を変えて再検索 )
３．理想の情報が手に入り次第ユーザーに伝える
という挙動になっていたはずです。
これを、Pararell Function Callingでは、
１．位置情報≒現在地点の地名の検索
２．地名と併せ、「ハンバーガー屋さん」「humberger shop」をGoogle検索＆ぐるなびで「ハンバーガー」で一挙に検索
(ここで情報が取得できなかった場合は、検索用語や地名を変えて再検索 )
３．よさげな情報をユーザーに伝える
という挙動を取り得るようになります。
整理すると、
・ツールの発動内容が並列で発動しても良い
・それらの発動判断に同時に発動するツールの発動結果が深く依存しない
場合に生成時短とコストを抑えられるようになったということです。
Function Callingを上手く扱えてるプロダクトを見かけないので、インパクトは地味ですが、個人的には長い目で見るとありがたいですね。
まとめ
以上になります。これまでで一番情報量が多かったですね。
OpenAIのAPIに頼ってる割合の大きいスタートアップは、弊社EuphoPia含め対応が本当に大変そうですね。
TTSモデルや公式実装のツールも出してきたりと後出しジャンル被りで大打撃お通夜のところも多いんじゃないでしょうか。
Assistant APIについては弊社で開発した
AIキャラクターチャットアプリで自力実装した部分と被ってる点が多くて、先に出してくれたらすげ～楽だったんだけど～…って感じで泣きました。
（開発したものはこちら「いちゃいちゃっと：https://twitter.com/ivy_ichaichat」）
それではお先不安ですが、
次回は、これらのポテンシャル、特に「視覚」の発揮の仕方を説明していきたい思います。
では、明日くらいにまた上げます。
（上げたらこの箇所がリンクに代わります。）
この記事が気に入ったらサポートをしてみませんか？