Assistants APIを低コストで使う方法

2023年11月6日にOpenAI DevDayが開催され、ChatGPTの新機能「Assistants API」が新たにリリースされました。

これまでのAPIは、Completionsと呼ばれる方式でしたが、これからはAssistants APIの方式が主流になりそうです。Assistants APIの特徴の一つに、会話履歴をプロンプトに含めなくても一貫性のある回答が得られるというのがあります。

Completionsでは、会話履歴をプロンプトに含める為の処理が煩雑だった、会話が進むごとにプロンプトが肥大化し高コストになっていた。Assistants APIを使えばこれらが解消するのですばらしい。

これは本当でしょうか？

結論を言うと、前者はその通りですが、後者は間違いです。しかも、Assistants APIの仕組みを理解せずに安易に実装してしまうと、とんでもない請求が来るかも知れません。

この記事では、Assistants APIのコストに焦点を当てた解説を行います。

Assistants APIはCompletionsに比べ多機能であることから、いづれCompletionsはオワコン化しそうです。

一方で、第二世代Completionsとも言えるAssistants APIは高機能であるが故にCompletionsと比べ方式が複雑で全容を理解することが難しい面もあります。

APIドキュメントを一見すると、実装の流れとしてまずアシスタントを作成し、スレッドを作成し、メッセージを作成し、ＲＵＮすれば良くて、会話履歴はスレッドで記憶するから、メッセージ（プロンプト）に会話履歴を含める必要が無いんだと一応の理解ができます。

ここで注意が必要なのが、会話履歴をプロンプトに含めて送信しないのだから、会話履歴のコストは発生しないだろうという思い込みです。

実際は、Completions方式と同様にAssistants APIでも会話履歴のコストが発生します。

これに気付いたユーザーはOpenAI公式の開発者フォーラムでも発信しています。

デベシュザチャンプさんのテスト結果では、確かにプロンプト毎にContext Tokens(累計)が増えていることが確認できますが、具体性に欠けていたので実際にテストしてみました。

■テストに使用するAPIリクエスト

Create assistant	モデルに応じたアシスタント(インスタンス)を作成例え）GPT3.5のAIアシスタント確保、GPT4のAIアシスタント確保。
Create thread	スレッド(トークルーム)を作成例え）仕事のトークルーム確保、趣味のトークルーム確保。
Create message	メッセージ(トークメモ)を作成例え）何のお仕事ですか？、あなたの趣味は何ですか？
Create run	GPTモデルに質問や命令を送信例え）トークメモの発信。
Retrieve run	APIリクエストの結果を取得例え）アシスタントからの回答問い合わせ。
List messages	メッセージのリストを取得例え）アシスタントからの回答一覧を取得。
Delete thread	スレッド(トークルーム)を削除例え）仕事のトークルーム解放、趣味のトークルーム解放。
Delete assistant	アシスタント(インスタンス)を削除例え）GPT3.5のAIアシスタント解放、AIGPT4のアシスタント解放。

■テストに使用するプロンプト

日本語全角の足し算で、一貫性のある（会話の流れを引き継ぐ）質問文。
1回目：１＋１＝
2回目：その答え＋１＝
3回目：その答え＋１＝

■テスト結果１

実行順	使用API	コンテキストトークン数	生成トークン数	質問	回答
1	Create assistant	0	0
2	Create thread	0	0
3	Create message	0	0	１＋１＝
4	Create run	24	10
5	Retrieve run	0	0
6	List messages	0	0		１＋１＝２です。
7	Create message	0	0	その答え＋１＝
8	Create run	49	10
9	Retrieve run	0	0
10	List messages	0	0		２＋１＝３です。
11	Create message	0	0	その答え＋１＝
12	Create run	74	10
13	Retrieve run	0	0
14	List messages	0	0		３＋１＝４です。
15	Delete thread	0	0
16	Delete assistant	0	0

コンテキストトークン数(質問に要するトークン)、生成トークン数(回答に要するトークン)は都度API実行時のトークン数であり、累計ではありません。

■テスト結果１の所見

テスト結果では、初回の質問でのトークン数24に対して、2回目の質問ではトークン数49であり、2回目の質問文字数だけのトークン数では無いことがわかります。3回目の質問でも同様な結果でした。

一方、回答でのトークン数は常に10であり、3回の回答ともに文字数は同じであるので妥当な結果です。

以上のことから、プロンプトに会話履歴が含まれている可能性が高いと言えます。

ここで少し補足します。生成トークン数が何故List messagesでは無くCreate runで発生しているのか疑問を持つ人がいるかも知れません。

List messagesでは会話履歴全てが送信されるので通信量は多くなりますがトークン消費とは別です。なので何度List messagesを実行してもトークン消費からするとノーコストになります。

Assistants APIでのコストの抑え方

プロンプトに会話履歴を含むと高コストになります。テストした手順では、一貫性が不要な会話の場合も高コストになってしまいます。ではコストを抑えるにはどうすれば良いでしょうか。Completions方式にするのも一つの手ですが、やがて非推奨になるかも知れないリスクがあるのでAssistants APIで実現したいところです。

どのようにやるのか？は簡単で、スレッドを毎回削除するだけです。ChatGPTのブラウザ画面でもよく使う「New chat」に相当します。合わせてアシスタントも削除しても構いません。

アシスタントやスレッドの作成や削除は、テスト結果からもわかるようにゼロトークンノーコストです。一貫性の不要な会話の場合は、この手順を強く推奨します。

試しに会話毎にスレッドを削除するようにしたテスト結果がこちらです。

■テスト結果２

実行順	使用API	コンテキストトークン数	生成トークン数	質問	回答
1	Create assistant	0	0
2	Create thread	0	0
3	Create message	0	0	１＋１＝
4	Create run	24	10
5	Retrieve run	0	0
6	List messages	0	0		１＋１＝２です。
7	Delete thread	0	0
8	Create thread	0	0
9	Create message	0	0	その答え＋１＝
10	Create run	26	156
11	Retrieve run	0	0
12	List messages	0	0		長いので#1参照
13	Delete thread	0	0
14	Delete assistant	0	0

#1(AIの回答)･･･「その答え+1」というフレーズだけでは、具体的な答えが何であるかを知ることはできません。もし特定の問題や数値があれば、その答えに1を加えた数値を提供することができます。例えば、「答えが4である」という場合、4 + 1 = 5となります。具体的な問題や文脈を教えていただければ、もっと詳しい回答をすることができます。

■テスト結果２の所見

1回目と2回目の質問でコンテキストトークン数がほぼ変わらないことがわかります。これは質問毎のコストしか発生していないことを意味します。

生成トークン数は劇的に増えていますが、会話毎にスレッドを削除することで一貫性のある会話ができなくなり、2回目の質問の意味をAIが汲み取れなくなった結果、質問内容が不明である旨の長文の回答をしている為です。

以上のことから、会話毎にスレッドを削除することでトークン数を少なくできることが言えます。

■テスト結果の考察

それぞれのテスト結果をグラフにしたのが以下です。Ｘ軸が会話回数、Ｙ軸は消費トークン数、青線がテスト結果１、赤線がテスト結果２です。

テスト結果１では、会話回数の増加に伴いトークン数も比例して増えています。一方、テスト結果２では会話回数が増えてもトークン数が変わりません。

一貫性のある会話が不要である場合、テスト結果１とテスト結果２のトークン量の差分が不要なゴミトークンとなります。