キャディ機械学習勉強会:12-Factor Agents

こんにちは、Data&Analysis部(D&A)です。
D&Aでは週1回、機械学習の勉強会を開催しており、本記事は、勉強会の内容を生成AIを活用して記事にまとめたものです。
※勉強会内容公開の経緯はこちら
※過去の勉強会は「社内勉強会」タグからもご覧いただけます。

はじめに

今回の勉強会では、信頼性・保守性の高いLLMアプリケーション構築の原則として提唱された12-Factor Agentsを紹介します。動機としてはLLMを用いたアプリケーションが高品質であるための体系的な理解が必要だと考えたためです。

本記事では、以下の資料を参考にしています。

  1. humanlayer/12-factor-agents

  2. Twelve-Factor App

12-Factor Agentsとは

12-Factor Agentsとは、大規模言語モデル(LLM)を活用したアプリケーション(以下ここではAIエージェントと呼称していきます)を信頼性が高く、スケーラブルで、保守しやすいものとして構築するために提唱された12の原則です。なぜ12かというとWebアプリケーション開発のベストプラクティスであるThe 12-Factor Appをなぞらえたものだと思います。

12-Factor Agentsを書いた背景

従来のソフトウェア開発では、必要な処理とその順序から最終成果物の定義を人が実装し(例: イベントトリガーやワークフローのためのDAGの記述等)、事前に定義された手続きやフローに基づいて処理が行われてきました。AIエージェントが将来もたらすものとは、LLMが指示に基づいてDAGを自動で記述するように処理の順序を適切に構築するという機能です。

理想的なAIエージェント(資料1より引用)

現在のエージェントは「LLMが次のステップを決定 → ツールを実行 → 実行結果をコンテキストに追加 → 再びLLMが次のステップを決定」というループ構造で実装されることが多く、DAGが不要になるという理想とは異なっています。むしろ、このループ(制御フロー)をどう管理するかが重要です。

ループとしてのエージェント(資料1より引用)

この実行順序のループを高い品質に保つための12の原則が12-Factor Agentsです。

12-Factor Agentsの概略

ここから12-Factor Agentsについて概略したものを紹介していきます。概ね4つのテーマに集約してみました。

  • 構造化された結果を返すものとして定義する(#1, #4)
  • プロンプトをコードとして管理する(#2, #3, #8)
  • 状態管理をし人の手を借りたりエラーを修正できるようにする(#5, #6, #7, #9)
  • 小さなエージェントを複数構築し単一の結果を得られるようにする(#10, #11, #12)

Agentは様々な経路から入力を受けつけ、出力は構造化されている

Agentは入力をスケジュールされたタスク、システムイベントや人のテキスト入力など様々なところから自然言語で受けつけるようにします。また出力結果はコンピュータが実行できるものでなければなりません。例えばプロンプトを受け取りAPIのURIを返すAgentのようなものです。原則1「Natural Language to Tool Calls」や原則4「Tools are just structured outputs」に書かれています。結果が構造化されていることでAgentがそれを実行したり他のAgentに渡せるようになります。Agentの起動条件については原則11「Trigger from anywhere, meet users where they are」に書かれています。

プロンプトやコンテキスト、制御フローをコードとして管理する

制御フローは当然ですが、プロンプトやコンテキストもフレームワークに任せずに内製し、バージョン管理を徹底できるようにします。それによってAgentをテスト可能にし改善可能なものにします。原則2「Own your prompts」ではプロンプトを内製することについて、原則3「Own your context window」ではコンテキストウィンドウを内製することについて、原則8「Own your control flow」では制御フローを内製することについて書かれています。このテーマは12 Factor Appの原則1「コードベース」の一部(コードはバージョン管理システムで常に変更を追跡している)と関わりがあると考えます。

状態管理をし、人の介入やエラー修正を可能にする

LLMは非構造化データを入力できます。そこでAgentを停止して人が追加の指示を入力することができます。また起こったエラーを入力し、それを解決するようにAgentを動かすこともできます。このようなAgentの状態や構造化された出力などを管理し柔軟なAgentの構築やリカバリーを容易にします。原則5「Unify execution state and business state」では状態管理について、原則6「Launch/Pause/Resume with simple APIs」はAPIの実行や一時停止させることについて、原則7「Contact humans with tool calls」は人の介在について、原則9「Compact Errors into Context Window」はAgentのエラー対応について書かれています。

小さなエージェントを複数構築し単一の結果を得られるようにする

複数のタスクを実行するのではなく単一のタスクを実行するAgentを作るように心がけます。またAgentはステートレスであることを心がけ、スケーリングできるような構成になるようにします。原則10「Small, Focused Agents」ではAgentのタスク設計について、原則12「Make your agent a stateless reducer」ではAgentのスケーラビリティについて書かれています。なお複数のステートレスなプロセスにするという考え方は12 Factor Appの原則4「プロセス」の発想に近しいと思います。

まとめ

このように、12-Factor Agentsは非構造データの入出力が可能なAgentを従来のソフトウェアのように開発するための原則です。GitHubに公開されているのでぜひご覧ください。