15,344 文字
会場からの拍手をいただき、ありがとうございます。アプリを作って、ユーザーベースが急速に拡大している。2倍以上に増えていて、その成長は衰える気配もありません。その成功は喜ばしいことですが、課題は持続可能な形でスケールすることです。1,000人のユーザーに対して機能したことが、100万人には通用しないことがよくあります。どのLLMを使うか、コストの予測と管理をどうするか、といった重要な決断を迫られることになります。
そして、応答時間をいかに速く保つかということも。私はColin Jarvisで、OpenAIのAIソリューションチームを率いています。
そして私はJeff Harrisです。APIプラットフォームチームのプロダクトリーダーの1人です。今日は、私たちのプラットフォームでアプリをスケールする際の一般的な落とし穴やテクニックについてお話しします。最初に申し上げておきたいのは、アプリを最適化するための完璧な方法を示すような、単一のプレイブックは存在しないということです。
もちろんそんなものはありません。多くのテクニックがあり、様々なトレードオフが存在します。しかし、このトークを通じて、検討すべきアプローチとベストプラクティスのセットを提供し、皆さんが構築しているものに対して実際に役立つ最適化のアイデアを持ち帰っていただければと思います。そして最適化について話す前に申し上げたいのは、アプリの最適化は私たちの中核的な取り組みだということです。
より知的なモデルをリリースし、より高速なモデルを作り、GPT-4oはTurboの2倍の速さです。そしてコストも徹底的に削減しています。このチャートが好きなのは、2022年にリリースされたtext-davinci-003以来の進化を示しているからです。これは4o miniより性能が低いモデルでしたが、それ以来、トークンあたりのコストは約99%減少しています。
これは非常に良いトレンドに乗っているということです。もう1つの例を挙げると、GPT-4の32kバージョンで100万トークンを生成すると120ドルかかりました。かなり高額ですね。今日では、GPT-4o miniを使えば60セントで済みます。わずか1年半で200倍の改善を達成したことになります。これらの低コスト化に加えて、4o miniのような微調整された小型モデルにより、多くの新しいユースケースが可能になりました。
私たちのデータにもそれが表れています。7月に4o miniをリリースして以来、プラットフォーム上のトークン消費量は2倍以上になっています。APIの新しい使い方が大幅に増えているということです。しかし、モデルが増えると新たな疑問も生まれます。4o miniをいつ使うべきか？4oをいつ使うべきか？推論はいつ必要か？私たちは、皆さんのような開発者と様々な規模やユースケースで協力してきました。
そして、そういった判断を支援するための優れたメンタルモデルを開発してきました。Colinが精度の改善について、つまりモデルの出力の品質について説明します。その後、私が戻ってきてレイテンシーとコストの最適化について説明します。
いいですね。AIアプリのスケーリングには、精度、レイテンシー、コストのバランスを取り、最低のコストと速度で精度を維持する必要があります。これから説明する内容に関して、それを念頭に置いておくことが重要です。なぜなら、明らかにこれらはどれも特効薬ではなく、私たちはこの分野で効果的だと分かったトレードオフを共有しようとしているだけだからです。
これを実現するために、私たちは多くの顧客に一般化できるアプローチを確立しました。まず精度の最適化から始めます。つまり、精度目標を達成するまで、利用可能な最も知的なモデルを使用します。精度目標は通常、ビジネス上の意味を持つものです。
例えば、カスタマーサービスチケットの90%が最初の試みで正しくルーティングされる、といったものです。精度目標を達成したら、レイテンシーとコストを最適化します。目標は、可能な限り安価で高速なモデルで、その精度を維持することです。まずは、本番環境で確実に精度を確保する方法について説明していきます。
精度の最適化は、意味のある精度目標を設定することから始まります。まず適切な評価を構築して、モデルが期待通りに機能しているかを測定する必要があります。皆さんはそれをご存知だと思うので、簡単に要点を振り返り、実際の現場で効果的だったベストプラクティスをいくつか共有したいと思います。
次に、ROIを実現するための最低限の精度目標を設定します。これは多くの人が飛ばしてしまう部分です。しかし、多くの場合、本番環境にどの程度の精度が十分なのかという議論で行き詰まってしまいます。
そこで、顧客がそれを乗り越えるために使用した方法をいくつか共有したいと思います。最後に、精度目標を設定したら、実際の最適化に入ります。プロンプトエンジニアリング、RAG、ファインチューニングのテクニックを選択して、その精度目標を達成します。最初のステップは、ベースラインの評価を開発することです。
ChatGPTがリリースされてからほぼ2年が経ちますが、多くの人がこのステップを飛ばしています。ですので、ここで始めて、同じページにいることを確認したいと思います。皆さんは評価が何かご存知だと思うので、基本を簡単に振り返りましょう。私たちは顧客に評価駆動の開発を推奨しています。
LLMでは、評価を持って実際に最後まで実行され、意図した結果を生成することを確認するまで、コンポーネントが完成したとは考えられません。評価には多くの種類がありますが、私たちが考える2つの主要なものは、コンポーネント評価です。ユニットテストのような単純な評価で、通常は決定論的で、単一のコンポーネントが機能していることを確認するためのものです。
そして、エンドツーエンドの評価です。これはより黒箱的なテストです。プロセスの開始時に入力を行い、最後に出力を測定します。それは複数のステップのネットワークかもしれませんし、評価を通過するかもしれません。
かなりの作業量に聞こえるかもしれませんが、顧客と協力しながら効果的なスケーリング方法を見つけましたので、それを皆さんと共有したいと思います。カスタマーサービスの例を取り上げたいと思います。これは顧客によく見られるユースケースだからです。
reasonably複雑で、通常は指示やツールを使用して何かを実行しようとする複数のアシスタントのネットワークがあります。いくつか例を挙げると、シンプルなコンポーネント評価として、質問が正しい意図にルーティングされたか？単純な真偽のチェックです。その意図に対して正しいツールを呼び出したか？そして、顧客は目的を達成したか？23ドルの返金を求めてきた場合、実際にそれを得られたか？
そして、ここで見つけたベストプラクティスは、LLMを使って顧客になりすまし、ソリューションをレッドチームすることです。基本的に、多くの顧客LLMを立ち上げてネットワークを通過させます。これが自動化されたテストとして機能します。
ここでプロンプトを変更した場合、すべてが正しくルーティングされ完了されているかを確認します。ここで簡単にネットワークを示したいと思います。もし動作すれば。いいですね。このネットワークについて説明し、これがどのように機能するかを共有したいと思います。
ここには多くの詳細がありますが、主なポイントは、これが典型的なカスタマーサービスネットワークだということです。多くの意図があり、それぞれの意図が指示とツールにルーティングされます。現在、私たちがすべてのカスタマーサービス顧客にこのアプローチを適用している方法は、まず過去の会話をマイニングすることから始めます。
そして、それぞれに対して顧客が達成しようとした目的を設定します。12ドルの払い戻しを求めていた、返品を予約しようとしていた、など何でも構いません。それをLLMに与えて顧客になりすまさせ、ネットワークを通過させ、すべての評価に合格したかどうかをマークします。
この場合、この顧客はプランBを購入しようとし、アップグレードプランの意図に進み、それに成功しました。次に別の顧客を試します。そして正しくルーティングされなかったので失敗します。そして別のケースを試します。正しくルーティングされましたが、指示に従うことができませんでした。
これは100%正確ではありませんが、顧客がカスタマーサービスネットワークをスケールするのに使用しているのを見てきました。なぜなら、PRを上げるたびにこのような無人テストを再実行し、カスタマーサービスネットワークが退行していないかを確認できるからです。
これを共有したい理由は、かなり基本的に見えますが、カスタマーサービスネットワークの最大の問題は多くの場合、分岐だからです。ネットワークのここで何かを変更したとき、それがネットワーク全体にどのように影響するのか？この特定のアプローチを共有する理由は、ある顧客と一緒にこれを行った際、50のルーティングからスタートしました。
最終的にこの方法で400以上までスケールアップし、新しいルーティングの展開はどんどん速くなりました。これが基盤となり、ネットワークに重要な変更を加えるたびに1,000以上の評価を実行することになりました。評価を持っていれば、次のステップは本番環境へのデプロイメントで、これが顧客にとって最大のフリクションポイントの1つです。
本番環境にいつ投入するのか十分なのか？どの程度の精度が十分なのか？LLMで100%を得ることは決してないでしょう。では、どの程度が十分なのでしょうか？顧客の1つの例を取り上げたいと思います。カスタマーサービスアプリケーションで2回のパイロットを実施しました。精度は80から85%の間でした。
ビジネス側は出荷を快く思っていなかったので、目標とする精度を合意する必要がありました。そこで、異なるシナリオをモデル化し、精度目標をどこに設定するかを決定するためのコストモデルを構築しました。10万件のケースを取り上げ、いくつかの前提を設定しました。最初の前提は、AIが最初の試行で正しくトリアージするごとに20ドルを節約するということです。
エスカレーションされるケースについては、40ドルを失います。それぞれのケースで人間が数分間作業する必要があるからです。そしてエスカレーションされたケースのうち、5%の顧客がとても不満を持ってチャーンします。つまり、それぞれの顧客につき1,000ドルを失うことになります。
結果として、ソリューションの収支均衡点は81.5%の精度でした。そこで経営陣と合意し、90%を目指すことにしました。そうすれば出荷に十分な精度が得られます。この話の興味深い補足として、人々はLLMに対して、人間よりも高い精度を期待することが多いということです。おそらく会場の皆さんにとって驚きではないでしょう。
このケースでは、90%の精度マーカーを設定して達成したとき、彼らは人間との比較テストも実施したいと考えました。そこで、完全に人間が対応したチケットの並行チェックを実施しました。そのいくつかを取り出して、どのように機能したかをテストしました。結果として人間の精度は66%でした。最終的に90%での出荷は非常に簡単な決断でした。
ここでのポイントは、評価と精度目標があれば、どの程度最適化すべきかが分かるということです。この段階で、ビジネス側の同意を得て、それを測定する評価があり、90%が目標だと分かっています。そこで、その90%に向けて改善を重ねていく必要があります。
ここで私たちの最適化テクニックを振り返りたいと思います。この4つのボックスモデルは、OpenAI内でよく使用される資産です。通常、左下の角から始めます。プロンプトエンジニアリングが最初のステップです。明示的な指示のあるプロンプトから始めて、評価を作成し、評価がなぜ失敗するのかを理解し、そこから最適化を決定します。
モデルが新しいコンテキスト、つまり学習していない新しい情報を必要とするために失敗している場合は、検索拡張生成（RAG）が必要です。指示に一貫して従えない場合や、要求しているタスクやスタイルについてより多くの例が必要な場合は、ファインチューニングが必要です。
これについては他にも多くのリソースがあり、より詳しく説明しています。今は、過去6ヶ月ほどで見てきたこれらのテクニックについての重要な原則をいくつか指摘したいと思います。それぞれのテクニックのメタが少し変化しているからです。最初はプロンプトエンジニアリングです。
よく質問されるのが、長いコンテキストはRAGに取って代わるのかということです。答えは、今のところそうではありませんが、プロンプトエンジニアリングをより効果的にスケールできると考えています。長いコンテキストは、コンテキストウィンドウをどこまで押し広げられるかを理解するための良い方法だと考えています。例えば、5kトークンではなく60kトークンで詰め込むことができれば、評価に対するパフォーマンスを維持しながら、RAGアプリケーションをそれほど効果的にする必要がないかもしれません。
また、プロンプトの最適化を自動化することも見ています。メタプロンプティングと呼ばれる概念があり、アプリケーションを見るラッピングプロンプトを作成し、プロンプトと評価結果を与えると、プロンプトを反復させようとします。
基本的に、評価を実行し、プロンプトを反復し、それをラッピングプロンプトにフィードバックして、再びプロンプトを改善するという、ほぼグリッド検索のようなことを行います。これまで話してきたことはすべて手動の反復作業でしたが、メタプロンプティングの真の違いは、人々がモデルを活用してそれを加速し始めているということです。
そして、o1で特に効果が見られる領域の1つがメタプロンプティングです。顧客とこれを行い、カスタマーサービスのルーティンを生成して最適化しました。おそらく2週間かかる作業を1、2日に短縮できました。ぜひ試していただきたいですし、やり方を示すクックブックも用意する予定です。プロンプトエンジニアリングを超えると、RAGがあります。
会場の皆さんはRAGについてご存知だと思うので、ここ数ヶ月で見てきたRAGアプリケーションを機能させるための最も重要なポイントをいくつか指摘したいと思います。最初のポイントは、すべての問題が意味的検索を必要とするわけではないということです。かなり明白かもしれませんが、最も明白で単純な最適化の1つは、開始時に分類ステップを入れ、顧客が尋ねたことに基づいて、意味的検索が必要か、キーワード検索が必要か、または分析的な質問が必要かを判断することです。
私たちは、ベクトル、キーワード検索、特定の質問に答えるためのSQLクエリを書くことができるデータベースを選択する人が増えているのを見ています。これはかなり単純な最適化ですが、実際に大きな効果が得られる最適化の1つだと提案したいと思います。
もう1つは、検索をカバーするように評価を拡張することです。検索を追加すると、評価に新しい軸が加わります。RAGアププリケーションのようなフレームワークはこれを形式化しています。重要なのは、すべての評価例を拡張して、与えられたコンテキストを示すことです。
そして、正しいコンテキストを取得しているか、モデルは与えられたコンテンツで実際に回答できたかを強調することです。これもかなり単純ですが、RAGアプリケーションで作業する多くの人が行っていないことです。いくつかのポイントがありました。最後はファインチューニングです。
今日は蒸留について多く聞いていると思うので、ファインチューニングについてはそれほど詳しく説明しません。ファインチューニングの主なポイントは、小規模から始めて徐々に拡大することです。ファインチューニングが良好なパフォーマンスを発揮するために必要な例の数は、意外に少なく、通常50以上の例から始めれば十分です。
フィードバックループを作ることです。ポジティブとネガティブな応答をログに記録し、それらをフィードバックする方法を作ることです。これもかなり単純ですが、有用な側面です。最後は蒸留を検討することです。メタプロンプティングと同様に、スケールアップする方法を持ち、システムが学習し、それらのポジティブとネガティブな例を、持っているモデルの再トレーニングにフィードバックする方法を持つことです。
これはファインチューニングにとってかなり重要な側面です。これを実際の生活でどのように機能しているかを示すために、顧客の例を共有したいと思います。この例では、RAGパイプラインで2つの異なるドメインを使用している顧客がいました。そして、非常にニュアンスのある質問に答えようとしていました。
私たちが取り組んでいたベースラインは45%で、かなり悪い結果でした。これはコサイン類似度を使用した標準的な検索でした。また、彼らは規制産業で働いていました。そこで私たちは、まずベースラインの評価を得ました。45%は良くありません。そして精度目標を設定しました。そのために、偽陽性よりも偽陰性を最大化することにしました。
つまり、モデルが幻覚を起こすよりも、知らないと言うことを許容することにしました。そしてそれを使って、この場合の許容度を設定しました。そして95%の精度を目標に設定し、取り組みました。最適化へのルートはこちらです。それぞれにチェックマークとバツマークを付けた理由は、多くのことを試み、すべてが機能したわけではないことを示すためです。
しかし、パフォーマンスを向上させた主要な点は、まずチャンキングと埋め込みです。異なるチャンキング戦略でグリッド検索を行い、許容度を設定する正しい領域を見つけ出しました。85%に到達するために、先ほど話した分類ステップを追加しました。誰かが1単語を入力した場合、意味的検索ではなくキーワード検索を行いたいということです。
かなり単純ですが、20パーセントポイントの向上が得られました。また、再ランク付けのステップも追加しました。すべてのコンテキストを取得し、ドメイン固有の再ランカーをトレーニングしました。質問がどのドメインのものかに応じて、特定の再ランカーがチャンクのコンテンツを再ランク付けします。そして85%から95%に到達した最後の要素は、多くの人がこのRAGシステムに分析的な質問をすることでした。
多くの場合、RAGシステムは単に10個のドキュメントを取得し、これらの質問の多くに対して間違った答えを与えます。そこで、コンテンツに対してSQLを書けるようにツールを追加し、クエリ拡張も追加しました。顧客が求めているものを推測するためのクエリ拡張モデルをファインチューニングしました。
そしてそれが最終的に出荷したものです。精度の最適化について話したことをまとめると、まずアプリがどのようにパフォーマンスを発揮しているかを理解するための評価を構築することから始めます。次にROIを生み出し、アプリケーションを安全に保つ精度目標を設定します。そして、プロンプトエンジニアリング、RAG、ファインチューニングを使用して目標に達するまで最適化します。
その時点で正確なアプリができあがります。しかし、遅くて高価かもしれません。それらの問題を解決するために、Jeffに引き継ぎたいと思います。ご清聴ありがとうございました。
素晴らしいですね。最初に精度に焦点を当て、機能する製品を構築する必要があります。しかし、望ましい精度を達成したら、レイテンシーとコストを改善する時です。
これは明白な理由、つまりユーザーの時間と自身のお金を節約するためだけでなく、より深い意味があります。各リクエストのレイテンシーとコストを削減できれば、同じ予算と時間で より多くの推論を実行できます。これは同じリクエストにより多くの知能を適用する別の方法であり、精度を改善するもう1つの重要な方法です。
まずレイテンシーを改善するテクニックについて話し、その後コストについて説明します。レイテンシーについて最初に理解すべきことは、LLMはデータベースではないということです。リクエスト全体のレイテンシーに固執すべきではありません。それはLLMのレイテンシーを考える正しい方法ではありません。
代わりに、トータルリクエストレイテンシーを構成する3つの異なるサブコンポーネントに分解する必要があります。それらはネットワークレイテンシー、つまりリクエストがシステムに入ってからGPUに到達し、戻ってくるまでの時間です。入力レイテンシー、一般に最初のトークンまでの時間と呼ばれます。
これはプロンプトを処理するのに要する時間です。そして出力レイテンシー、生成される各トークンに対して、ほぼ固定のレイテンシーコストがかかります。これらを組み合わせたものが、トータルリクエストレイテンシーです。多くの顧客で見られるのは、時間の大部分がトークンの生成、つまり出力レイテンシーに費やされているということです。
通常90%以上の時間です。そのため、最初に最適化すべきと考えるかもしれませんが、長いドキュメントの分類器を構築している場合など、入力トークンの速度が支配的になるケースもあります。つまり、ユースケースによって異なります。トータルリクエストレイテンシーを分解しましたが、最初に申し上げたいのは、トータルリクエストレイテンシーについて考えるとき、それに固執しないようにと言いましたが、ほとんどの顧客はLLMが完了するまでの時間に注目しています。
ストリーミングチャットアプリケーションでない限り、顧客が気にするのは、答えが完了するまでの時間です。しかし、その枠組みでさえ、最終的に顧客が気にする点を知っていても、開発者としてはもう少し詳細に焦点を当てる必要があります。ネットワークレイテンシー、TTFT（最初のトークンまでの時間）、つまりプロンプトレイテンシーについて話しました。
そして出力レイテンシー、私たちはTBT（トークン間時間）と呼んでいます。トークン間時間に生成するトークン数を掛けたものが出力レイテンシーを構成します。これが基本的な公式で、リクエストがなぜこんなに時間がかかるのか、どうすれば速くできるのかを考えるときに、常に頭の片隅に置いておくべきものです。
では1つずつ分解して、各コンポーネントがどのように機能し、何ができるかについて説明しましょう。まずネットワークレイテンシーです。残念ながらネットワークレイテンシーは私たちの責任で、リクエストがシステムに入ってからGPUに到達するまで、そしてリクエストが完了してから戻ってくるまでの時間です。
サービスを通じてルーティングされるだけで、トータルリクエスト時間に約200ミリ秒が追加されます。良いニュースの1つは、これが過去6ヶ月ほど私たちが注力してきた中心的な課題だということです。歴史的に、私たちのシステムはかなり単純で、すべてのリクエストが米国の少数の中央チョークポイントを通じてルーティングされてきました。
そしてGPUに到達し、米国に戻って、そこから返信されます。つまり、標準的なリクエストでは、多くの場合、海を何度も往復することになります。これは低いネットワークレイテンシーには理想的ではありません。しかし、現在地域分散化を展開しており、メトリクスを注視していれば、ここ数週間でネットワークレイテンシーが低下しているのがわかるはずです。
まず申し上げておきますが、実際のデータセンターの場所は言えませんので、これは説明的なものですが、中央のチョークポイントだけでなく、リクエストに最も近いデータセンターを見つけ、完全にローカルで処理しようとしています。
これはネットワークレイテンシーを削減する本当に意味のある方法の1つです。さて、簡単に影響を与えられるもの、最初のトークンまでの時間です。これはプロンプトを処理するのに要するレイテンシーで、ここを最適化するための重要なテクニックがいくつかあります。第一に、明白なのは単にプロンプトを短くすることです。
Colinが先ほど、プロンプトにより多くのコンテキストや例を入れたいと言いましたが、それにレイテンシーコストがかからないと言えたらいいのですが、残念ながら少しのコストがかかります。プロンプトが長くなればなるほど、プロンプトの処理に時間がかかります。通常、プロンプトはモデルによって異なりますが、出力レイテンシーと比べてトークンあたり20〜50倍高速です。
これが、プロンプト内のデータ量とプロンプトの処理速度の間でトレードオフを行う必要がある理由です。今日リリースした本当に素晴らしい機能の1つが、プレイグラウンドでの生成です。プロンプトエンジニアリング用に調整したモデルに、プロンプトにこれらの機能を持たせたい、かつ簡潔にしたいと伝えることができます。
そしてモデルは実際に、これらの基準を満たし、詳細さと重要さの適切なバランスを取ったプロンプトを形成するのを助けてくれます。これが1つのテクニックです。プロンプトを改善する2つ目のテクニック、これについては多く話しますが、適切なサイズのモデルを選択することです。選択するモデルによって、最初のトークンまでの時間は大きく異なります。
o1とGPT-4oは、どちらも最初のトークンまでの時間が約200ミリ秒です。しかし1 miniは約50ミリ秒で、超高速です。そしてGPT-4o miniはその中間で、システム全体の多くのリクエストで見られる標準的な最初のトークンまでの時間である約140ミリ秒です。
そして、プロンプトレイテンシーを改善する3つ目の方法として、プロンプトキャッシングと呼ばれるものがあります。これは今日リリースしたばかりですが、繰り返しのプロンプトがある場合にリクエストを高速化する方法で、コストのセクションで後ほど詳しく説明します。
これが最初のトークンまでの時間、つまりプロンプトレイテンシーです。最後のコンポーネント、おそらく最も時間を費やすコンポーネントは、トークン間時間、つまり出力レイテンシーです。トークン間時間が最も時間を要し、これはGPT-4oや4o miniのような従来のモデルでは当てはまりますが、o1プレビューやo1 miniのような推論モデルでは特に顕著です。
モデルが頭の中で考えているそれぞれのトークンが出力トークンとなり、固定のレイテンシーコストが加算されるからです。そしてそこには多くのトークンが存在する可能性があります。では何ができるでしょうか？まず、トークン間時間について理解すべきことは、速度を決定する最大の要因の1つが単純に需要と供給だということです。
システムが処理しているトークン数と、システムが提供できる容量との関係です。ここに示すのは、私たちの典型的な1週間です。週末は需要が最も少なく、トークンが最も速く処理される時期です。そして平日は、通常太平洋時間の朝が最も需要が高く、モデルは週を通して最も遅くなります。
内部的にこれを最適化する方法は、モデルごとに設定するレイテンシー目標です。ここでの単位は1秒あたりのトークン数で、速いほど数字が大きいことを意味します。これらの数字が意味するのは、モデルが最も遅くなることを許容する値です。月曜日の午前8時、通常最も遅い時間の1つで、GPT-4oは少なくとも1秒あたり22トークン、できればそれ以上の速度を維持したいと考えています。
ここで見られるように、GPT-4oとo1はほぼ同じ速度でトークンを生成し、4o miniはより高速で、o1 miniは非常に高速です。しかし、多くの思考チェーントークンも生成しています。
小さなモデルを選択することもできますが、すべてのトラフィックを週末に移動することは現実的ではありません。できればそれは高速化の非常に単純な方法ですが。トークン間時間のレイテンシーを改善するもう1つの方法として考えられるのは、出力トークン数を削減することです。
これは総リクエスト時間に大きな違いをもたらします。100の出力トークンを生成するリクエストと1,000の出力トークンを生成するリクエストがある場合、後者は文字通り約10倍の時間がかかり、かなり遅くなります。
そのため、必要最小限の情報だけをモデルが提供するよう、簡潔な出力を促すプロンプトを考える必要があります。最後の方法として、トークン間レイテンシーについて少し微妙な点は、プロンプトの長さも影響を与えるということです。
1,000のプロンプトトークンを持つリクエストと100,000のプロンプトトークンを持つリクエストがある場合、2番目のリクエストは生成する各トークンに対して少し遅くなります。各トークンが100,000の長いコンテキスト全体に注意を払う必要があるからです。そのため、プロンプトを短くすることは生成速度に小さな影響を与えます。
そして最後の方法は、より小さなモデルを選択することです。4o miniで十分な場合、それはアプリケーションを高速化する非常に単純な方法です。さて、レイテンシーを分解し、ネットワークレイテンシー、プロンプトレイテンシー、そして出力レイテンシーについて説明しました。
最後にコストについて説明し、より少ないお金でより多くのリクエストを行う方法について説明しましょう。まず知っておくべきことは、すでに触れた多くのテクニックがレイテンシーとコストの両方を改善するということです。リクエストを高速化する多くの方法は、お金も節約することになります。非常に単純な例として、トークン単位で課金され、トークンは固定の時間もかかるので、トークンを少なくすれば明らかに大幅に高速化されます。
しかし、コストにのみ適用される最適化もあります。まず紹介したいのは、開発者コンソールの優れた使用制限機能で、プロジェクトごとの支出を確認し、支出が予想を超えた場合にアラートを受け取ることができます。これは、会社内で異なる取り組みが行われている場合に、それぞれがどれだけ支出しているかを把握し、週末に突然の使用量の増加に驚かないようにするための非常に単純な方法です。
これらのツールを使用し、コストを管理するためにプロジェクトを細かく設定することは常に良いことです。そして良好な可視性を維持してください。コストを実際に削減する方法の1つがプロンプトキャッシングです。これは今日リリースしたばかりの機能です。これがどのように機能するかというと、プロンプトがすでにそのプロンプトを見たことがあり、キャッシュに持っているエンジンに到達した場合、そのプロンプトのアクティベーション、つまりそのプロンプトに関連する内部モデルの状態を再計算する必要はありません。
代わりに生成ステップに直接進むことができます。これはプロンプト処理時間を短縮するだけでなく、お金も節約する方法です。プロンプトキャッシングについて考えるべき重要なポイントの1つは、プレフィックスマッチで機能するということです。この例では、左側に最初のリクエストがあります。
そして全く同じリクエストに最後に数行を追加して送信した場合、すべてプロンプトマッチとなります。しかし、プロンプトの最初で1文字でも変更すると、完全に一致しません。他のアクティベーションはプロンプトの速度に全く役立ちません。つまり、アプリケーションを構築する際は、静的な部分をプロンプトの最初に置くことが重要です。
つまり、エージェントの動作方法に関する指示、ワンショット例、関数呼び出しなど、これらすべてがプロンプトの最初に属します。そしてプロンプトの最後には、より可変な部分、つまり特定のユーザーに関する情報や、会話で以前に言われたことなどを置きます。
通常、システムはプロンプトキャッシュを5〜10分間保持します。これはすべて自動的に行われ、関与する必要はありません。プロンプトキャッシングの率を改善するもう1つの方法は、一定のリクエストの頻度を維持することです。プロンプトキャッシュは1時間以内に必ずクリアされますが、同じプロンプトプレフィックスを約5〜10分以内に継続的にヒットし続ける限り、そのプロンプトはずっとアクティブに保たれます。
これは金額の節約にどのように反映されるでしょうか？これは今日発表したばかりですが、最新のモデルすべてにおいて、キャッシュされたトークンで即座に50%の節約を開始できます。この実装の本当に素晴らしい点の1つは、追加の作業は必要ないということです。キャッシュされたプロンプトがある場合、今日からすぐに請求額が下がることを願っています。
この機能を使用するために追加料金を支払う必要はなく、トラフィックをより効率的にすることで節約できます。コスト削減について最後に取り上げたいのは、BatchAPIです。BatchAPIは少し見過ごされているかもしれませんが、プロンプトと出力トークンの両方が50%オフになります。これは非同期にリクエストを実行することで実現されます。
モデルにヒットしてできるだけ早く応答を得る代わりに、実際に多数のリクエストの連続であるバッチファイルを作成します。BatchAPIに提出すると、24時間以内にこのジョブを完了します。ピーク時以外にジョブを提出する場合は、多くの場合さらに早く完了します。
このサービスの本当に素晴らしい点の1つは、BatchAPIに渡すものは通常のレート制限にカウントされないことです。つまり、半額で使用できる完全に別の容量プールです。私たちが一般的に見てきたのは、ほとんどの開発者にはBatchから本当に恩恵を受けるケースが少なくともいくつかあるということです。
それはコンテンツ生成かもしれません。多数のサイトを作成している場合や、評価の実行、大量のバックログデータの取り込みと分類、埋め込みベースの検索用のデータのインデックス作成、大規模な翻訳ジョブなどです。これらはすべて、各トークンが40ミリ秒以内に生成される必要がないため、Batchの良いユースケースです。
そして、作業をそちらに移行できる範囲で、支出の半分を節約でき、もちろん他のレート制限も使用しないため、より同期的である必要のあるサービスをより多くスケールできます。これがどのように使用されているかの例を1つ挙げましょう。私たちのパートナーの1つであるEcho AIは、顧客の通話を分類し、要約します。
転写後、分類し、要点とフォローアップを記載します。BatchAPIはコストを50%節約します。なぜなら、完全に同期的である必要がないからです。これにより、コストを削減し、実際により低価格を顧客に提供することができます。彼らはこれを、入ってくるすべての通話をほぼリアルタイムで処理するシステムとして設計しました。
バッチジョブを作成し、時には数個のリクエストだけの小さなバッチジョブを作成します。そしてシステム内のすべてのバッチジョブを追跡し、完了次第顧客に通知できるようにしています。これは必ずしも1分未満の応答時間にはなりませんが、同期的にリクエストを実行するよりもはるかに安価で、より多くのスケーリングが可能になり、コストについてより多くの質問をすることができます。
BatchAPIは春にリリースしたばかりです。彼らは数ヶ月間使用していますが、すでに数万ドルを節約しています。これは初期のプロトタイピングとしては非常に良い結果です。現在、トラフィックの16%がBatchAPIに移行されており、彼らの特定のユースケースでは75%まで到達することを期待しています。
そして今後6ヶ月で約100万ドルの節約を目指しています。ワークロードを同期的である必要があるものとそうでないものに分割できれば、実質的な金額を節約できます。さて、私たちは多くの異なるアイデアを共有してきました。多くのことを共有しました。
良いニュースは、コストとレイテンシーを最適化するための多くのテクニックが高度に重複しているということです。1つを最適化すると、もう1つも最適化される傾向があります。そしてこれらのベストプラクティスの適切な組み合わせを適用できれば、知性、速度、手頃な価格のバランスを取る点で最先端の体験を構築することができます。
また、ここで言及しなかったテクニックも多くあり、おそらく私たちが知らないものもたくさんあると思います。もし私たちが見逃した効果的なものがあれば、トーク後にぜひ教えていただきたいと思います。最後にもう一度申し上げますが、精度、レイテンシー、コストのバランスを取るための1つのプレイブックがあればいいのですが。
そのようなものは存在しません。これがLLMアプリケーションを構築する上での中心的な技術であり、これら3つの重要な強みの間で適切なトレードオフを行うことです。私たちが考えるべきいくつかのアイデアを提供できたことを願っています。私自身、Colin、そしてチームを代表して、皆さんが何を構築するのかとても楽しみにしています。
ありがとうございました。
コメント