OpenAIのDev-dayの内容の可能性について考察

背景・目的

• 11/6にOpenAIのdev-dayがあった
• いくつか新機能が発表されたので、それの活用方法について考察する

発表されたこと

発表されたことのうち、気になったポイントは以下

• JSONの出力を担保できる機能
• アシスタントAPI
• TextToSpeech API
• GPT4のモデル更新
• Function Callingを複数候補返してくれる
• GPTs

全体について考察した後、それぞれについて活用可能性について考えてみる

全体感

LLMの可能性が広がった部分はあまりなくて、LLMを使ったアプリケーションの構築が簡単になった印象。
LLMの可能性が広がった部分はGPT4のモデル更新の部分で、LLMの情報についてLLMが返せるようになったのが良さそうだなと思う（まだ試していないけど、今まではLLMの使い方についての質問は情報が新しすぎて回答してくれなかったので、その点に期待）。
アシスタントAPIとして新しいインターフェースが増えたので、その辺りlangchainやllama_cppなどのフレームワークがそのAPIに対応されるのかどうかが、今後注目していきたいポイント。

JSONの出力を担保できる機能について

JSON形式のレスポンスではない場合にエラーを投げるようにできる。
JSON形式を返すようにするFine Tuningやプロンプトチューニングの工数を減らせるというのは、アプリケーション開発で有用そう。

アシスタントAPI

今までWebUIでしかできなかった、CodeInterpreterやKnowledgeRetrievalがAPIで使えるようになった。
大量のデータを渡してそのデータを元に回答させられるようになるので、RAGベースの質問応答システムを作るのが簡単になった。（ドキュメント量が膨大な場合は別途ベクトルDBを立てた方が良さそうだけど、例えば社内のスキーマをもとにSQLを生成させるとかのユースケースの場合は使えそう）
とはいえ、少し使ってみたところ、日本語の質問に対して英語で回答がきたり、作業をする前に作業していいですか？という確認が挟まったりしたので、その辺り、期待する動作をしてもらうためのプロンプトチューニングは必要かもしれない。

TextToSpeech API

音声の種類もいろいろある。OpenAIのAPIだけで音声対話エージェントを作れるようになるのは有用そう。
日本語の精度は要検証。

GPT4のモデル更新

処理できるトークン数が128kまで増えたこと、2023/4までの情報が増えたこと、安くなったこと、全て嬉しい。
ここが、一番可能性が増えるところという気はする。

LLMに関する開発の仕方についての情報が入っていれば、LLMに関する開発をLLM自身にさせることができるようになりそう。

トークン数が増えることは、単純に文脈を増やせることになるので、よりカスタマイズの幅が広がる。とはいえ、Claudeなど競合のLLMでもトークン数は多いものもあるので、新しいことができるようになったのか？といえばそうでもないかもしれない。

• 人狼とか、LLMをAIとして、できるようになると面白そう。
• 論文の要約とかはできるようになっていそう。
• コーディング面で、複数ファイルを加味した提案とかはあり得るかも
• 短編小説を書くとか

Function Callingを複数候補返してくれる

A,Bとどちらの解釈もできるようなケースに有用なのかも？
具体的なユースケースはピンときていないけど、一つの自然言語に複数の意図があるケースとかもあるケースは便利かもしれない。

• 関数A,Bが、A ⊆ Bの関係の時
  • より特化した関数Aを使いたいのに、Bが推薦されるときに、二つ候補が出るようになれば、適切なものを選べる
  • 例
    • 掛け算関数と足し算関数があって、100円のお菓子を三つ買った合計の値段は？という質問に対して、どちらの関数も使えるけど掛け算関数を使ってほしい
• 関数A,Bが、無関係の時
  • どちらの意図がより近いのか？の指標があれば、アプリケーション側で選べるけど、確率値とかも返してくれないとそれは難しそう。ルールベースで判断とかになるのか？
  • それか、解釈が一つに定まらないので、質問し直すとかはあるのかもしれない
  • 例は思いつかず・・。
• 関数A,Bが、並列関係の時
  • 二つとも関数を呼び出して、その結果をLLMにまとめさせるとかもあり得るかも
  • 例
    • 電車の経路検索関数と車の経路検索関数があって、東京までの行き方を教えてという質問に対して、両方の関数を呼び出してその結果をまとめて安い方を選んでもらう
• 関数A, Bを順番に評価したい時
  • これは、一つ目の関数を二つ目に渡す場合、LLMがそれを提案できるのか不明だけど、できたら便利そう
  • 例
    • ユーザーID検索関数とユーザー情報取得関数があって、〇〇さんの情報を教えてという質問に対して、ユーザーIDの検索とユーザー情報取得関数を順番に適用して、最後にユーザーの情報を返す

GPTs

試しに、長いトークンを活かせるものとして、AI人狼アプリを作ってみた感想

LLMアプリケーションをチャットベースで作るのは、今までにない体験だった。
ざっくりやりたいことを伝えたら、アプリケーションのタイトルとアイコンを作ってくれて、それでアプリケーションは動く状態になる。

左半分が設定を行うチャット欄で、右半分が検証用のチャット欄になる。左半分は、タブでConfigureと切り替えることができて、チャットを使わず直接アプリケーションの設定を修正することもできる。

GPTsが聞いてくるのは基本的に英語だったが、こちらからは日本語で説明しても問題なく指示を解釈してくれていた。

Configureでは、ファイルのアップロードやWeb Browsing, 画像生成, Code Interpreterなどの機能を追加することもできる。（デフォルトは、Web Browsingと画像生成になっていた）

Actionsは、OpenAPIのスキーマを設定してFunction Callingの関数を登録することができた。

とはいえ、上記の人狼ゲームがすぐに期待通り動くようになったかといえばそうではなかった。

ChatGPTは基本的な人狼ゲームのルールは、特別教えなくても知っていたものの、いくつか下記のような問題があった。

• ユーザーに見せてはいけない情報もテキストで出してしまう（全員の役職をテキストで出してしまう）
• 細かいルールが意図と異なる（人狼の襲撃が騎士もいないのに失敗する。人狼を追放したのにゲームが終わらない）
• 毎回のテキストの表現が安定しない

アプリケーション開発の視点で考えると、アプリケーションの品質を担保するのがかなり難しいと感じました。
（自動テストなどの環境もまだないですし・・）

どういった種類のアプリケーションが、GPTsのアプリケーションとの相性が良いのかは、引き続き考えてみようと思います。

まとめ

OpenAIの新機能の利用可能性について考えてみました。
全体として、LLMによる開発の工数が減る方向の機能だったので、今後もさらにLLMの応用となるアプリケーションが出てくる予感がしました。
また、気づいたことなどがあれば、ここに追記していこうと思います。