LLMオーケストレーションとは？

プロンプトエンジニアリングではない

プロンプトエンジニアリングは一つの呼び出しを改善します。オーケストレーションは呼び出しがいくつあるか、どのモデルが行うか、出力がどう組み合わさるかを決めます。優れたプロンプトを持っていてもオーケストレーションが全くない場合、あるプロバイダーの調子が悪い一時間で落ちるシステムになります。

この区別が重要なのは、両者の最適化の仕方が異なるからです。より良いプロンプトは安価で、品質をわずかに高めます。より良いオーケストレーションはトークンを消費し、信頼性を大きく高めます。

オーケストレーション層が決めること

どのモデルか。複数に尋ねるか。返す前に回答を確認するか。拒否、タイムアウト、レート制限にどう対処するか。このステップの出力が次の入力になるか。始める前に全体が費用に見合うか。

これらはそれぞれポリシーであり、それぞれ独立して誤りうるものです。だからこそオーケストレーションは、アプリケーションコード全体に判断を散らすのではなく、独立した層として名指す価値があります。

一般的な手法

ルーティングは適切なモデルへリクエストを送ります。フォールバックは失敗を処理します。コンセンサスは複数のモデルに尋ね、その一致を見ます。ベスト・オブ・Nは候補を生成し一つを残します。ジャッジは回答を採点します。検証はモデルの外にある何かと主張を照合します。パイプラインはステップを連鎖させます。タスク分解は大きなリクエストを小さく分けます。

ClawAIはこのうち九つを独立したオーケストレーションモードとして実装し、さらにジャッジと比較をそれぞれ独自の面として持ちます。それぞれこのサイトにページがあり、必要かどうかを決める前にそれが何かを説明しています。

オーケストレーションしないとき

オーケストレーションはコストとレイテンシを増大させます。三つのモデルでのコンセンサスは約三倍のトークンを消費し、最も遅いモデルと同じ時間がかかります。答えを一目で確認できる質問には、これは割の合わない取引です。

成り立つ目安はこうです——誤りが高くつき、確認が難しいときにオーケストレーションする。それ以外は一つのリクエストを一つのモデルに送り、回答を読めばよいのです。

よくある質問

オーケストレーションはエージェントフレームワークと同じですか？

重なりますが同じではありません。エージェントは多くの場合ツールを使って自ら次のステップを決めます。オーケストレーションはそれを取り巻くポリシー——どのモデルか、いくつか、失敗時にどうするか——であり、エージェントが全く存在しないワークフローにも同様に当てはまります。

オーケストレーションにフレームワークは必要ですか？

いいえ。別のモデルで再試行することは既にオーケストレーションです。フレームワークが役立つのは、そうしなければ機能ごとに再実装することになるほどポリシーが多くなったときです。

どれくらいのコストがかかりますか？

トークンで見ると、ポリシーが行うモデル呼び出しの回数にほぼ比例します。ルーティングされた一回の呼び出しはルーティングされていない呼び出しとほぼ同じコストで、三つのモデルでのコンセンサスは約三倍です。コストは予測可能で、それゆえに賭けではなく予算の判断になります。