「初めてエージェントワークフローを構築したとき、単純なクライアントのクエリに回答するのに38秒かかり、リクエストあたり1.12ドルを支払うまで、それは魔法を見るようなものでした」 自動代理人が複数のステッププロセスを計画し、行動するエージェントワークフローを構築し始めるとき、使い捨てられるのは簡単です 柔軟性は信じられないほどです! しかし、それに伴うオーバーヘッドも同じです これらの痛みのいくつかのポイントには、遅い実行、高いコンピュータ使用、および動く部品の混乱があります。 エージェントワークフローの真ん中は、パフォーマンスの問題と最適化の機会が通常現れる場所です。 過去1年間にわたって、これらのシステムを柔軟性を犠牲にすることなく劇的に速く、コスト効率的に作る方法を学び、このブックを作成することを決意しました。 私は最適化について話す前に、私は次の言葉を使用するときに私が何を意味するかを皆さんが知っていることを確認したいと思いました: : Predetermined sequences that may or may not use an LLM altogether. Workflows : Self-directing, and they can decide which steps to take and the order in which they choose to execute. Agents エージェントワークフロー:これは、一般的なパスを設定するハイブリッドですが、ワークフロー内のエージェントに特定のステップ内で移動する自由を与えます。 私は最適化について話す前に、私は次の言葉を使用するときに私が何を意味するかを皆さんが知っていることを確認したいと思いました: ワークフロー: LLM を完全に使用するか、または使用しない可能性のある事前定義のセクション。 エージェント: 自己指示、そして彼らはどのようなステップを取るか、そして彼らが実行することを選択する順序を決定することができます。 エージェントワークフロー:これは、一般的なパスを設定するハイブリッドですが、ワークフロー内のエージェントに特定のステップ内で移動する自由を与えます。 TRIM THE STEP COUNT エージェントワークフローを設計する際に誰もが心に留めておく必要があることは、あらゆるモデル呼び出しが遅延を加えるということです. 余分なジャンプはタイムアウトのためのもう一つのチャンスです. そして、それがまた幻覚の可能性を高め、主な目標から遠ざかる決断につながることを忘れないでください。 ここでのガイドラインは簡単です: 関連するステップを1つのプロンプトに統合する 単一のモデルが一歩で処理できる不要なマイクロ決断を避ける ラウンドツアーを最小化するためのデザイン ワークフローを設計するとき、私は常に単一のエージェントから始める(なぜなら、もしかしたら、ワークフローを必要としないかもしれないから)、それから特定のメトリックやコントロールに基づいて評価します。 失敗した場所に基づいて、評価スコアが最小基準を満たしていない部分を分解し、その時から繰り返します. Soon, I get to the point of decreasing returns, just like the elbow method in clustering, and choose my step count accordingly. 依存性を持たないものを平行化する 上記の点からコンテキストを借りて、連続チェーンも遅延のです. If two asks do not need each other's output, run them together! たとえば、私は顧客サポートエージェントのワークフローを模して、顧客が注文の状態を取得し、要求の感情を分析し、応答を生成するのを手助けすることができるようになりました。私は連続的なアプローチで始めましたが、注文の状態を取得し、要求の感情を分析することは互いに依存していません。 これらの2つの応答があれば、反応ジェネレーターに検出されたオーダーの状態と感情を送信し、12秒から5秒までの合計時間を簡単に剃りました。 不要なモデル呼び出しの削除 私たちはすべて、ChatGPTが数学に関して少しイフイになれる方法について話すオンラインの投稿を見ました。さて、これはこれらのモデルがそれのために作られたのではないという本当に良い思い出です。 また、どのような計算が必要であるかを知っているならば、なぜ単に使用可能な関数にコードするのではなく、独自のLLM数値を持っているのか? ルール、regex、または小さな関数がそれを行うことができれば、LLM呼び出しを省略します。 タスクにモデルを合わせる 「すべてのタスクが同じように作られているわけではない」は、タスク管理と生産性の基本原則であり、タスクの性質、要求、重要性が異なることを認識する。同様に、私たちは正しいモデルに正しいタスクを割り当てることを確認する必要があります。 今日では、人々が彼らのエージェントワークフローを最大の最悪のモデルで設計しているのを見ることは一般的ですが、それは遅延のコストで来ています。モデルが大きいほど、コンピュータが必要になるほど、したがって遅延です。確かに、あなたはそれをより大きなインスタンスにホストし、それで逃げることができますが、それは文字通りコストがかかります。 代わりに、私が再びワークフローを設計する方法は、最も小さいモデルから始めることです。私のGo-toモデルはLlama 3.1 8Bで、分解されたタスクのための忠実な戦士であることが証明されています。 サイズを除いて、色々ありました。 LLMの味はそれぞれのタスクで何をより良くするのか、それはあなたが達成しようとしているタスクの種類に応じて考慮すべきもう一つの考慮事項です。 部族知識 あなたのプロンプトを再考する それは現在の一般的な知識ですが、私たちが評価を通過するにつれて、私たちはLLMのプロンプトにより多くのガードレールを追加する傾向があります。これはプロンプトを膨らませ始めており、逆に遅延に影響を与えます。この記事で私が使用した数少ない方法は、静的な指示やスケジュールのためのプロンプトキャッシュでした。 これには、より良いキャッシュの再利用のためにプロンプトの末尾にダイナミックなコンテキストを追加することも含まれました. Seting clear response length limits so that the model does not eat up time, giving me unnecessary information. すべてを隠す 以前のセクションでは、プロンプトキャッシングについて話しましたが、それはキャッシングで最適化を試みるのを止めるべきではありません。キャッシングは最終的な答えだけでなく、適用可能な場所で適用すべきものです。 KVキャッシュは、部分的な注意状態や、もちろん、顧客データやセンサー状態などのセッション特有のデータでも実装できます。 SPECULATIVE DECODE ここでは、高度な群衆のための1つです:小さな「草案」モデルを使用して、次のトークンを迅速に推測し、より大きなモデルがそれらをパラレルで検証または訂正します。 Save Fine-Tuning For Last - And Do It Strategically (Fine-Tuningを最後に保存し、戦略的に行う) Finetuningは、最初の数日間に多くの人々が話し合ったものですが、現在、LLMの新しい採用者のいくつかは、なぜか、いつそれを使用するかを知らないように見えます あなたがそれを調べると、それはあなたのLLMがあなたのドメインやあなたのタスクをより詳細に理解する方法であることがわかりますが、これはどのようにして遅延を助けるのですか? さて、これは多くの人々が話していることではないが、私が最近この最適化について話した理由があり、私は少しでそれに到達します。あなたがタスクを行うためにLLMを調節するとき、推論で要求されるプロンプトは、あなたが他の場合に持っていたよりもはるかに小さいので、今、ほとんどの文脈で、あなたがプロンプトに置くものは、あなたの細かい調節プロセスを通じて重量に焼かれています。 これは、反対に、早期の長さを減らす上記のポイントに供給し、したがって、遅延の利点です。 モニター無制限 これは遅延を減らそうとしたときに私が取った最も重要なステップです. これは上記の最適化のいずれかに基盤を置き、何が効くのか、何が効かないのかを明確にします. Here are some of the metrics I used: Time to First Token(TTFT) 1秒あたりのトークン(TPS) ルーティング精度 ヒットレート ヒットレート マルチエージェントの連携時間 これらのメトリクスは、どこで最適化するか、いつ、なぜなら、それらがなければ、あなたは盲目に飛んでいるからです。 Bottom Line 最も速く、最も信頼性の高いエージェントワークフローは、単に起こるのではありません。彼らは、無情なステップカット、スマートパラレル化、決定的なコード、モデルの右サイズ、およびキャッシュの結果です。これを行うとあなたの結果を評価し、あなたは3〜5倍の速度の改善(およびおそらく大きなコストの節約)が完全に手の届くはずです。