12-Factor Agents: 信頼できるLLMアプリケーションのパターン

 (github.com/humanlayer)
1 ポイント 投稿者 GN⁺ 2025-04-17 | 1件のコメント | WhatsAppで共有
  • 12 Factor Agentsは、信頼できるLLMアプリケーションを構築するための原則を提示
  • AIエージェントフレームワークを使った経験をもとに、多くの製品は真のエージェントではないことを発見
  • 12 Factor Agentsは、LLMベースのソフトウェアを顧客に提供できるだけの十分に高い品質へと仕上げる方法を探求
  • 12の要因は、LLMソフトウェアの信頼性、拡張性、保守性を高める中核技術を含む
  • モジュール型の考え方を既存製品に統合することが、高品質なAIソフトウェアを迅速に提供する方法

12 Factor Agents - 信頼できるLLMアプリケーション構築の原則

  • AIエージェントフレームワークを使った経験をもとに、多くの製品は真のエージェントではないことを発見
  • 12 Factor Agentsは、LLMベースのソフトウェアを顧客に提供できるだけの十分に高い品質へと仕上げる方法を探求
  • 12の要因は、LLMソフトウェアの信頼性、拡張性、保守性を高める中核技術を含む
  • モジュール型の考え方を既存製品に統合することが、高品質なAIソフトウェアを迅速に提供する方法

要約: 12の要因

  • 自然言語をツール呼び出しに変換: 自然言語を使ってツールを呼び出す方法を理解
  • プロンプトを所有: プロンプトを所有し管理することが重要
  • コンテキストウィンドウを所有: コンテキストウィンドウを所有し管理することが重要
  • ツールは構造化出力: ツールは構造化された出力として扱うべき
  • 実行状態とビジネス状態を統合: 実行状態とビジネス状態を統合して管理

エージェントの約束

  • DAG(Directed Acyclic Graph): ソフトウェアは有向グラフとして表現でき、DAGオーケストレーターが人気を集めた
  • エージェントの約束: エージェントを使えばDAGを捨て、LLMがリアルタイムで経路を決定できる
  • エージェントはループで動作: エージェントは、LLMが次のステップを決め、ツール呼び出しを実行し、その結果をコンテキストウィンドウに追加するループとして動作

なぜ12-factor agentsなのか?

  • 既存フレームワークの限界: 多くのSaaSビルダーがエージェント構築を試みているが、既存フレームワークの限界により80%以上の品質を達成するのは難しい
  • モジュール型の考え方の重要性: モジュール型の考え方を既存製品に統合することが、高品質なAIソフトウェアを迅速に提供する方法

優れたLLMアプリケーションのためのデザインパターン

  • エージェントの中核要素: エージェントを優れたものにする中核要素があり、フレームワークを使えばその大半を得られる
  • モジュール型の考え方の統合: モジュール型の考え方を既存製品に統合することが、高品質なAIソフトウェアを迅速に提供する方法

関連リソース

  • Tool Useポッドキャスト: 2025年3月のエピソードで関連内容を扱う
  • The Outer Loop: 関連内容を扱うブログ
  • ウェビナー: @hellovai とともにLLM性能最大化に関するウェビナーを実施
  • オープンソースエージェント: この方法論を使ってOSSエージェントを構築

関連記事

1件のコメント

 
GN⁺ 2025-04-17
Hacker Newsのコメント

  • とても有益なWikiだ。感謝しているし、ぜひ活用したい。私は昨日ちょうどリリースした"AI Agents framework"を作った。このフレームワークはアクターモデル、状態機械、そしてアスペクト指向プログラミングに基づいている。特に5番目と7番目のポイントが気に入った

    • 実行状態とビジネス状態を統合すること
    • 自身の制御フローを所有すること
    • SecAIはこの点をうまく実現しており、グラフ制御フローライブラリとして、LLM呼び出しがグラフのノードに組み込まれている。ネゴシエーション、キャンセル、状態関係によってフローが強化され、より有機的になっている
    • 他のフレームワークでよく見落とされがちなのは、専用の開発ツールだ。失敗をプログラムし、すべてのステップを詳細に検査し、自動データエクスポートと簡単な統合を提供する
    • 最初の技術デモを公開し、すべての開発ツールを示すリファレンス実装を含めた
    • Send/StopボタンはシンプルなAPIで開始/一時停止/再開を可能にする。ネットワーク透過性を備えており、スケール可能だ

  • 素晴らしい。何年もこの作業をしてきて、自分なりの教訓リストを作ってきた。最も重要なのは、最下層の計画ループを所有することだ

    • 動的計画があっても構わないが、OODAループを所有し、解決策へ収束しているかどうかを判断するヒューリスティックを持つべきだ
    • ワークフローエンジンを内蔵し、モデルがそのエンジン上で実行されるワークフロー仕様を構築するようにすべきだ

  • このタイミングでこの資料が出てきて本当に助かる。感謝している

    • vvvvのようなオーディオビジュアル・サンドボックスを構想中だ。LMまたはシンプルなローカルニューラルネットワークノードを挿入して特定の作業を行わせ、出力を非常に制限するというアイデアだ
    • 質問から回答へのフローは非常に魅力的だ。多段階パイプラインもとても興味深い

  • DSPYのようなライブラリがfactor-2にどう当てはまるのか気になる

    • BAMLを使ってプロンプトを生成する例を見た。非構造化データから構造化情報を抽出するためにプロンプトを手書きするのは簡単ではない
    • DSPYの生のプロンプトを使うことについてどう考えているのか気になる

  • 古いブログ記事だが、フレームワークパターンについての内容には自分のキャリアを通して共感してきた。LLMはフレームワークよりもライブラリとして使うほうがよい

    • フレームワークのほうが魅力的で売りやすく、ロックイン効果や追加サービスにつながる

  • 素晴らしい。80%は苦労して学んだことで、残りの20%は価値ある読み物になりそうだ

    • LangGraphとpydanticスキーマで成功している。他の人たちが何を有用だと考えているのか気になる

  • もう一つ。スケール時のコストを計画する必要がある

    • スケールするとコストが高くつくことがあるので、決定論的コンポーネントで処理できるものはまず試すべきだ。幻覚とレイテンシを減らし、コスト削減に大きな違いを生む可能性がある

  • 原則に従いやすくするには、一貫したナラティブが必要だ。実世界の例を使うのがよい

  • HNのトップページに載ってとてもうれしい

  • BAMLがここにあるのを見るのは本当にすばらしい。LLMを関数として扱うことに100%同意する