Introduction 導入 正直に言えば、旅は誰にとってもほぼ同じように見えます。最初に、あなたはChatGPTを開いて、次のように考えます。 テキストの数行と突然、コード、マーケティングの混乱、またはレシピの提案があります。 「ウォー、これは魔法だ!」 次に次の段階が来る。魔法はゆっくりと混沌に変わります。プロンプトは長くなり、アウトカウントは積み重ね、あなたは電話を連鎖し始めます―そしてある日あなたは気づきます: 「いいね、私は実際に仕事そのものをやっているよりも、モデルに何が必要かを説明するのにより多くの時間を費やしている」 第三の段階は、ついに物事が興味深くなりつつある、カオスがカットする必要があることに気づき、あなたはエンジニアのように考え始めます。 だから、あなたに尋ねてみよう: まだプロンプトで遊んでいますか? 無限のスパゲッティチェーンに閉じ込められていますか? それとも、もっと大きな何かの端に立っているのでしょうか? where are you right now on this maturity curve? この記事では、LLMシステムのシンプルな成熟モデル - 迅速な実験から完全なアーキテクチャーへの旅 - エージェントが精油の良いチームのように一緒に働く場所 - あなたを歩きたいです。 ついに混沌から解放されるのを助けるアプローチですが、そこに到達する前に、ほとんどのプロジェクトがどのように進化するかを正直に見てみましょう。 AAC (Agent Action Chains) Why We Need a Maturity Model なぜ成熟モデルが必要なのか 現在、LLMシステムには標準的な成長経路はありません。各開発者やチームは独自のルートをとり、ハックを試み、独自のアプローチを発明します。 周りを見てください:いくつかのプロジェクトは「もう一つのプロンプトを追加して動作する」段階に停滞します。他のプロジェクトは、図面上は良いように見える長い連鎖を作り、最初の実際の負荷の下で崩壊します。そしてそこには、すべての方向に接続された100ブロックの悪夢にスパイラルするノーコードマップがあります。デモの日に、それはまだ生きているように見えます。しかし、それが生産に到達するとすぐに、何もスケールしません、何も追跡されません、そして誰も物事がどこで壊れたかを知ることができません。 何十ものチームやスタートアップは、同じ試行錯誤の道を歩き、同じ車輪を繰り返し再発明するのに何ヶ月もかかる。 そこは、A それはあなたに簡単なマップを提供します:あなたが今どこにいるか、そして前進するために何を変更する必要がある。他のフィールドはこれを前に経験しました。アジル成熟度モデルは、企業が本当にアジルであるか、あるいは単に「スプリント」としてタスクを再命名するかどうかを把握するのに役立ちました。 maturity model LLMシステムは今日も同じ転換点にあります。ハイプは巨大ですが、成熟度はほぼゼロです。進歩の共有モデルがなければ、私たちは混沌としたプロンプトやスパゲッティシステムに溺れ続けます。 Level 1 - The Script (Prompting Playground) レベル1 - The Script (Prompting Playground) これはほぼ誰もが始める場所です ChatGPT や単一の API 呼び出しとブームで、あなたは答えを持っています それは「現時点で」機能しますが、あなたが頭の中の詳細を保持できる限りだけです。 Signs. Chaotic queries, no repeatability, unpredictable results. Today it works, tomorrow the model gives you something completely different. 今日それは機能し、明日モデルはあなたにまったく異なるものを与えます。 Risks. ゼロコントロール. 何もここでは実際の製品やビジネスプロセスに統合できません. すべては運に依存します。 When it makes sense. 迅速な実験、プロトタイプのアイデア、またはあなたがLLMができることの感覚を得ているときに最初の「ワウの瞬間」ですが、ここに滞在することは危険です - これはシステムではありません、それはただの砂箱です。 Level 2 - The Complex Prompt (Prompt Engineering 2.0) レベル2 - 複雑なプロンプト(プロンプトエンジニアリング2.0) この段階で、人々はテキストで「魔法を投げ始める」ことを開始します. 単一のクエリはもう十分ではありません - あなたは役割の指示、詳細なステップ、そしてミニシナリオで調理された長いプロンプトを得る. 時には、それはスンプトを書くよりも、英語で小さなプログラムをコードするような感じがします。 Signs. あなたは「表現の魔法」を感じ始める:一つのフレーズを変更し、モデルはまったく異なるものを吐き出す。 Risks. 複雑さを増やすにつれて、プロンプトは維持できないモンスターに変わります 新しいステップを追加することは、しばしばすべてを書き直すことを意味します テストは痛ましい このアプローチをスケーリングする? ほぼ不可能です。 When it makes sense. 複雑なプロンプトはまだ適切な文脈で役に立ちます:迅速なMVP、マーケティングの使用事例、または研究プロジェクト. 時には、彼らは印象的な結果を提供します「ここと今」 しかし、長期的には、彼らは維持しません - これは一時的なクロックではなく、本当の基盤です。 Level 3 - The Linear Chain レベル3 - The Linear Chain 「巨大なプロンプト」の次のステップは、複数のLLM呼び出しを一つのシーケンスに接続することです。今、システムはテキストの1つの大規模なブロックではありません - それは一連のステップです:データを抽出し、それを処理し、それに基づいて答えを生成します。 Signs. この段階では、LangChain、n8n、またはMake.com で最初のワークフローが表示され始めます。 それはすでにプロンプトの1つの巨大なモノリットよりもはるかに優れているが、それはまだ厳密に線形であり、分裂や柔軟性はありません。 「まず分類し、次に文脈を取り出し、次に反応を生成する」 Risks. 最大の問題は硬さです これらのチェーンは石に彫られています:一歩を変更し、あなたはしばしば他のすべてを書き換えるようになります。新しいシナリオを追加することは痛みがあり、エラーは一度に全体のチェーンを破る傾向があります。 When it makes sense. このレベルは、小さなボットや単純な自動化のためにうまく機能します:メールの解析、概要の生成、迅速な回答の作成です。これは良い出発点です。 Level 4 - Spaghetti (Ad-hoc Systems) レベル4 - スパゲッティ(Ad-hoc Systems) これが本当の痛みの始まりです。単純な線形チェーンが機能しなくなったとき、開発者は「分支」と「if-else」の条件を積み重ね始めます。 臨時メモリが現れます - 時にはコードのマレージにすぎません、時にはカスタムストレージハック、時にはノード間で不便に通じる変数です。 論理は混乱し、システムは線形になるのをやめます。 Signs. コードのないプラットフォームのワークフローは蜘蛛ウェブのように見え始めます:何十ものノード、混乱した接続、ループがどこにでもあります。コードベースのプロジェクトはあまり良くありません:ロジックはプロンプトやヘルパー機能に散らばっており、重要な条件はプロンプト自体のテキストの中に隠されています。 Risks. これらのシステムは維持するための悪夢です. 何かが壊れるとき、 エラーは隠されている、デバッグは存在しない、そしてすべては「それがどのように機能するかを知っている」一人の人次第です。 どこ When it makes sense. スパゲッティシステムは通常、実験の副産物として現れるが、ここに滞在すると成長が殺される。多くのチームはこの段階に達し、ようやく気づく:解決策は「もう一つのハック」ではない――それは本当のアーキテクチャです。 Level 5 - Orchestrator + Roles (System Design Thinking) レベル5 - Orchestrator + Roles (System Design Thinking) これは、カオスがついにシステムに変わる段階です. 無限のチェーンや枝の混乱の代わりに、あなたは システムの各部分は、その機能を知っています: structured design with clearly defined roles. - the brain that decides who does what and in what order. Orchestrator - narrow experts, each handling a specific task: classification, response generation, data retrieval. Specialists - makes sure the system isn’t living like a goldfish, giving it access to past context and knowledge. Memory - catches errors and ensures resilience, so one failure doesn’t bring everything down. Guard - monitors execution, collects logs, and provides visibility. Observer - polishes the final output and delivers it to the next stage. Egress Signs. このレベルでは、形式的な契約(しばしば JSON)が役割を結びつけることがわかります。 コンポーネントを個別にテストしたり、システム全体を壊すことなく交換したり、拡張したりできます。 Risks. あなたは建築的に考え、デザインの役割を果たし、単に「もう一つのプロンプトに投げ込む」という欲求に抵抗する必要があります。 When it makes sense. 生産環境、ビジネスプロセス、現実世界の製品. 実験以外のすべてのものは、最終的にこの段階に進化する必要があります. それは、スケーラビリティ、メンテナビリティ、予測が可能な唯一の場所です。 そして、これはまさにどこに AACは、役割を公式化し、規律を追加し、「迅速なハッキング」から真のエンジニアリングへの重要な飛躍を可能にします。 AAC (Agent Action Chains) How to Use This Model このモデルをどう使うか 成熟度モデルの本当の価値は、鏡のように機能することです. それはあなたがあなたのプロジェクトを正直に見て、あなたがどこにいるかを見つめ、前進するために何を変える必要があるかを見つけることを可能にします。 For self-assessment. あなたがソロまたは小さなチームで何かを構築している場合、モデルは基本的に迅速なチェックリストです。 そのスナップショットは、今日の明日の瓶詰を特定し、事前に準備するのに役立ちます。 「我々はまだ急な土地に住んでいるのか? シンプルなチェーンを作ったのか? それとも、すでにスパゲッティに溺れているのか?」 For teams. 製品マネージャー、エンジニア、アナリストは、技術的な詳細に迷う必要はありません。 それが何を意味するかは誰もが正確に知っている。より少ない摩擦、より生産的な会話。 「我々は連鎖段階にいるが、我々はスパゲッティを直ちに超える必要がある」 For investors and partners. モデルはまた、チームの成熟のシグナルとして機能します。まだ原発で動作するスタートアップは、明らかに明るいデモを提供することができますが、それは危険な賭けです。 LLMシステムの進化は、あらゆるテクノロジーと同じ弓に従う:最初に魔法、そして混沌、そして最後に - エンジニアリング. We start with simple scripts, get stuck in complex prompts, try chaining things together, drowned in spaghetti... and only then realize: it's time to build architecture. LLMシステムの進化は、単純なスクリプトから始まります。 成熟モデルは私たちが現実に直面するのに役立ちます:私たちがどこにいるのか、そして次にどこへ行くべきかを知ることです. ある人にとっては、それは「モンスター・スンプト」を手放すことを意味します. ある人にとっては、混沌とした連鎖のから逃れることを意味します. そして、ある人にとっては、オーケストラ、役割、実際のシステムデザインがついに現れる次のレベルへと向かうための呼びかけです。 それがどこ この高度な成熟度を公式化するアーキテクチャのイメージに入りますが、AACは魔法ではありません。それは道を歩くことの結果です。 AAC (Agent Action Chains) 👉以下はAACシステムの設計パターンです、もしあなたがより深く潜りたい場合は。 ↓↓ 以下はAACシステムの設計パターンです、もしあなたがより深く潜りたい場合は。
