Compound AI Systems

Compound AI システムは、単一のモデルではなく、相互に作用する複数のコンポーネントから構築される AI アプリケーションです。システムは、モデル、検索サービス、データベース、決定論的ルール、外部ツール、人間によるレビューを1つの協調的なワークフローに組み合わせることができます。たとえばコンピュータービジョンにおいては、あるモデルがオブジェクトを検出し、トラッキングソフトウェアが識別情報を維持し、ビジネスルールがイベントを解釈し、モニタリングサービスが本番環境のパフォーマンスを監視するといった形になります。最大の特長はコンポジション（構成）であり、パーツが情報を交換し意思決定を行う方法からシステムレベルの動作が生まれます。

Compound AI システムの仕組み#

コンパウンドシステムは、大規模なタスクを専門的なステージに分割します。一般的なコンポーネントには、データの前処理、1つ以上の AI モデル、ストレージ、検証ロジック、API、オーケストレーション層が含まれます。OpenAPI Specification で説明されているような明確なコントラクトによって、各サービスが受け入れ、返すデータが定義されます。

制御は、従来のコードが固定されたシーケンスでコンポーネントを呼び出す決定論的な方法と、AI agent orchestration 層が実行時にツールとルートを選択する動的な方法のいずれかになります。AI orchestration は、アプリケーション全体の依存関係、リトライ、リソース、データフローを調整します。

一般的なパターンには、検索が言語モデルにコンテキストを提供する retrieval-augmented generation や、カメラ、レーダー、その他の入力を組み合わせるセンサーフュージョンパイプラインがあります。独立したモデルから統合されたシステムへのより大きな移行については、Berkeley AI Research overview of compound AI systems で説明されています。(bair.berkeley.edu)

コンパウンドシステムが重要な理由#

コンポジションにより、開発者は1つの巨大なモデルを再トレーニングすることなくアプリケーションを改善できます。ワークフローの残りの部分を安定させたまま、専門的なコンポーネントを置き換えたり、スケーリングしたり、最適化したりできます。また、ルールや検証ステージを使用することで、確率的なモデル出力に完全に依存するよりも優れた制御を提供できます。

これらの利点により、システムレベルのトレードオフが生じます。

• 障害伝播： 誤った検出、取得の失敗、または利用できない API は、下流のすべての決定に影響を与える可能性があります。
• レイテンシとコスト： 各モデルの呼び出し、ネットワークリクエスト、検証ステージは、全体のレスポンス予算の一部を消費します。
• インターフェースのドリフト： 1つのサービスを更新すると、その出力フォーマットや前提条件が変更され、別のコンポーネントが予期せず破損する可能性があります。
• 困難な評価： 優れたコンポーネントが、優れたエンドツーエンドの結果を保証するわけではありません。

したがって、machine learning operations はワークフロー全体をカバーする必要があります。OpenTelemetry observability guidance は、分散サービス全体で何が起きたかをトレース、メトリック、ログがどのように明らかにするかを説明し、一方 MLflow experiment tracking はモデルの構成と評価結果を記録できます。(opentelemetry.io)

関連する概念と主な違い#

Compound AI システムは、複雑なモデルの単なる別名ではありません。

model ensemble は、通常は投票、平均化、スタッキングを通じて、複数のモデルからの予測を組み合わせます。アンサンブルはコンパウンドシステム内の1つのコンポーネントになり得ますが、通常はデータベース、ツール、ワークフローロジック、および運用サービスを欠いています。

エージェンティックなワークフローにより、モデルは自律的にアクションやツールを選択できます。コンパウンドシステムはより広範です。多くは、自律エージェントなしで、固定パイプライン、イベント駆動型サービス、または人間の承認を使用します。

同様に、RAG は検索と生成を含む特定のコンパウンドパターンです。Compound AI は、言語モデルを使用せずに、コンピュータービジョン、予測、最適化、ロボット工学、および従来のソフトウェアを調整することもできます。

実社会での応用#

• Manufacturing visual inspection： カメラが製品をキャプチャし、Ultralytics YOLO26 model が欠陥を検出し、ルールベースのロジックが重大度と場所をチェックし、本番システムが各アイテムを拒否または承認します。不確実なケースは人間の検査官にルーティングされ、保存された画像は後の再トレーニングをサポートします。

• Traffic and parking analytics： 検出によって車両が特定され、multi-object tracking がフレーム間で識別情報を維持し、幾何学的ロジックによって車線または駐車領域の占有率が決定され、ダッシュボードがカウントとアラートを集約します。エラーは重複カウント、見逃された混雑イベント、または誤った空き状況の推定を引き起こす可能性があるため、すべてのステージを一緒にテストする必要があります。

次の簡略化された例は、知覚が決定論的な意思決定ロジックにフィードする様子を示しています。

from ultralytics import YOLO

# Perception component
model = YOLO("yolo26n.pt")
results = model("https://ultralytics.com/images/bus.jpg")
result = results[0]

# Policy component
person_class = next(i for i, name in result.names.items() if name == "person")
person_count = int((result.boxes.cls == person_class).sum())
decision = "review" if person_count >= 4 else "continue"

print({"people_detected": person_count, "next_step": decision})
result.save(filename="compound_system_input.jpg")

ここでは、YOLO が構造化された観測結果を生成し、個別のポリシーロジックが次のアクションを決定します。本番システムには、ストレージ、通知、アクセス制御、または人間によるレビューを追加できます。

実践的な設計ガイダンス#

測定可能なエンドツーエンドの目標から始め、各コンポーネントに1つの明確な責任を割り当てます。すべての境界でスキーマとタイムアウトを定義し、コンポーネントを独立してテストし、モデルの精度だけでなく現実的なワークフローを評価します。

トレースを使用して個々のリクエストを追跡し、レイテンシとコストの予算を設定し、利用できないサービスに対してリトライや安全なフォールバックを提供します。Kubernetes health probes は、デプロイされたサービスが準備状況と稼働状況のシグナルをどのように公開できるかを示しています。

リスク管理は、データアクセス、外部ツール、人間のオーバーライド、下流への影響を含め、システム全体に対処する必要があります。NIST AI Risk Management Framework は、これらのリスクをガバナンス、測定、管理するためのライフサイクル指向のガイダンスを提供します。チームは Ultralytics Platform を使用して、より広範なコンパウンドアプリケーション内のビジョンコンポーネントのデータセットアノテーション、トレーニング、デプロイ、および本番モニタリングを接続できます。(nist.gov)