実行する価値のある最適化と、印象的に見えるだけの最適化

最適化作業には、技術的に興味深いものへの引力があります。推論レベルのテクニックは実に賢く、十分に文書化されており、実装するのに満足のいくものです。

また、これらは、ほとんどの展開において、役立つもののリストの 5 番目以下に位置します。

実際に作業する順番

まず、行う必要のない作業を削除します。未使用のツール定義が呼び出しごとにコンテキストを占有します。 2 年前にエッジケース用にプロンプ​​トセクションが追加されました。検索すると、3 つで済む箇所を 10 個のパッセージが返されます。これは純粋な無駄であり、何の貢献もしていないため、削除しても品質には何のコストもかかりません。

次に、再試行を修正します。実行が失敗して再起動すると、1 つの結果に対して 2 倍の代償が発生します。再試行は通常、単一で対処可能な最大の非効率であり、成功とは別に測定しない限り、再試行は目に見えません。

第三に、シーケンシャルだが独立しているものを並列化します。ほとんどのエージェント コードは、ステップを連続して実行します。これは、そうしなければならないからではなく、そのように読み取るためです。

4 番目に、ステップごとにモデルのサイズを適切に調整します。分類と抽出のステップでフロンティア機能が必要になることはほとんどありません。フロンティア機能を実行すると、何のメリットもなく永続的なコストがかかります。

5 つ目は、推論レベルのテクニックです。

テクニックよりも順番が重要な理由

最初の 4 つは安価でリスクが低く、規模が大きいことが多いです。 5 番目は洗練されたもので、その影響は、そもそも経過時間のうちどれだけが推論に費やされたかによって制限されます。

If inference is a third of your run time, a twenty percent inference improvement is a seven percent run improvement.これには価値がありますが、トラフィックのシェアに 100% のコストがかかる再試行の前には価値がありません。

選ぶ前に測ってください

上記のすべては、内訳を知っていることを前提としています。標準のインストルメンテーションはステップごとではなく実行ごとにレポートするため、ほとんどのチームはそうではありません。

ステップごとの測定は、このリストのすべての決定の前提条件です。それがなければ、最適化は好みの問題となり、好みによって興味深いオプションが確実に選択されます。

あらゆる最適化は品質に関する仮説です

最適化の前に評価を行うことにこだわる理由は、これらの変更はすべて品質を低下させる可能性があり、削減のほとんどはすぐには目に見えないためです。

機能が必要であることが判明したステップ上の小型モデル。実際の特殊なケースを処理する段落を削除したトリミングされたプロンプト。取得されるパッセージが少なくなりますが、質問で 4 番目のパッセージが必要になるまでは問題ありません。

事前に定義した基準に照らして各変更をスコアリングすることで、節約と延期が区別されます。これはまさにオプティマイザーの機能であり、コストのみの改善として変更を提示することをオプティマイザーが拒否する理由はこのためです。

地味な結論

ほとんどのエージェント システムで最も効果が高い最適化作業は、未使用のツール、蓄積されたプロンプト テキスト、不要な取得、連続する必要のないステップなどを削除することです。

どれも書くのに興味深いものではありません。それがおそらく、代替案についてこれほど多くのことが書かれている理由でしょう。

次へ

オプティマイザーとトークン監視のページでは、ステップごとの測定と評価による最適化について説明します。 AI 可観測性のページでは、実行内の計測について説明します。