プロトタイプを超えて:生産準備が整ったAIエージェントのための15の苦労レッスン

AIエンジニアとビルダーのためのガイド 通常、Python のいくつかの行と ChatGPT API キーで始まります。 あなたは文脈のいくつかの行を追加し、ヒットし、それがまったく反応していることに驚きます。それから、あなたはそれを役に立つ何かをすることを望んでいます。それから、信頼できるように。それから、あなたなしで。それはあなたがもはやLLMを呼ぶだけではないことに気づいたときです。 私は過去1年間、スクリプトと包装を組み合わせ、LangChainチェーンをジョギングし、システムよりもカードの家のように感じ、絶えず疑問に思った。 ” では、実際にこの商品をどうやって運ぶのか。 私は理論的にはエレガントに見えたパターンを追いかけましたが、実際のユーザーが現れた瞬間に崩壊しました。私はノートブックで完璧に機能し、生産で壮観に失敗したエージェントを構築しました。 しなかった。 私が助けてくれたのは、物事を減らすこと、物事を取り戻すこと、そしてLinkedInで賢く見えたのではなく、負荷の下で実際に働いたことに注意することでした。 あなたが似たような挑戦を経験したことがあるなら、それはあなたのために書かれています。 このガイドは、その苦労した明確さの蒸留物です。 APIの包装やチェーンから安定した、コントロール可能な、スケーラブルなAIシステムに移行するための実践的なガイドとして考えてください。 パート1 - Get the Foundation Right 初期のエージェントのプロトタイプは、しばしばすぐに組み合わせられます:いくつかの機能、いくつかのプロンプト、そしてそれで、それは機能します。 あなたは、「それがうまくいけば、なぜ物事を複雑にするのか」と尋ねるかもしれません。 最初は、すべてが安定しているように感じます:エージェントは反応し、コードを実行し、予想通り行動しますが、モデルを交換し、システムを再起動したり、新しいインターフェイスを追加したりすると、物事が壊れます。 メモリ管理の不良、ハードコード値、セッションの持続性がない、または固い入力ポイント。 通常、問題は論理や推奨事項ではなく、より深いものです。 このセクションでは、あなたのエージェントが信頼できるように成長し、スケールできる基盤、堅固な基盤を作成するのに役立つ4つの主要な原則をカバーします。 1.外部化国家 : The Problem エージェントが中断された場合、事故、タイムアウト、何であれ、再開することはできません。 再生可能性:テストとデバッグのために起こったことを再生したい。 : sooner or later, you’ll want to run parts of the agent in parallel, like comparing options mid-conversation or branching logic (Memory management is a separate topic we’ll cover soon.) Bonus challenge エージェントの外部、データベース、キャッシュ、ストレージ レイヤー、または単純な JSON ファイルにすべての状態を移動します。 The Solution : Your Checklist エージェントは、session_id と外部状態 (例えば、DB または JSON に保存) を使用して、任意のステップから開始します。 エージェントをいつでも中断して再起動できます(コードの変更後でも) 進歩を失ったり、動作を破ったりすることなく。 状態は機能を失うことなく完全に連続化できます。 同じ状態は、会話中に並行して動作する複数のエージェントインスタンスに供給できます。 2.知識の外部化 : LLMs は実際に覚えていません。たとえ1つのセッションでさえ、あなたが彼らに言ったことを忘れ、会話の段階を混同したり、トレードを失ったり、そこになかった詳細を「記入」したりすることができます。 The Problem モデルは始まりと終わりに焦点を当て、重要な中間の詳細を失う。 より多くのトークンはより多くの費用がかかります。 限界は依然として存在する:トランスフォーマーはO(n2)の複雑さで自己注意で動作するので、無限の文脈は不可能である。 これが一番辛いのは: 会話は長い 文書は広い 指示は複雑 : 従来のコンピュータのように「ワークメモリ」と「ストレージ」を分離してください. あなたのエージェントは、モデルそのもの以外の知識を保存、取得、概要し、更新するように、外部メモリを処理する必要があります。 The Solution : Common approaches メモリバッファ: 最新の k メッセージを格納します. プロトタイプを迅速に作成しますが、古い情報を失います。 Summarization Memory: 歴史を圧縮して文脈に適合します. トークンを節約しますが、歪みや色合いの喪失をリスクします。 RAG(Retrieval-Augmented Generation)とは、外部データベースからの知識を収集し、スケーラブルで新鮮で検証可能ですが、より複雑で遅延に敏感です。 知識グラフ:事実とエンティティの間の構造化されたつながり. Elegant and explainable, but complex and high barrier to entry. : Your Checklist すべての会話履歴は、プロンプトの外に保存され、アクセスできます。 知識源は記録され、再利用可能である。 ストーリーは、コンテキストウィンドウの限界を打つことなく無限に成長することができます。 3 - Make the Model Swappable(モデルを交換可能にする) : LLMsは急速に進化しています:OpenAI、Google、Anthropic、および他の人々は常にモデルを更新しています。エンジニアとして、私たちはこれらの改善を迅速に活用したいです。 Problem : Solution 設定または環境変数で model_id パラメータを使用して、どのモデルを使用するかを指定します。 統一された API を介してモデルと話す抽象的なインターフェイスやクラスを作成します。 オプションとして、ミドルウェア層を慎重に適用します(フレームワークにはコミットオフが付属します)。 : Checklist モデルを変更すると、コードを破ったり、メモリ、オーケストラ、ツールなどの他のコンポーネントに影響を与えることはありません。 新しいモデルを追加するということは、単に構成を更新し、必要に応じて単純なアダプター層を追加することです。 モデルの切り替えは迅速かつシームレスで、理想的にはあらゆるモデルをサポートするか、少なくともモデルファミリー内で簡単に切り替えることができます。 4 - One Agent, Many Channels (一人のエージェント、多くのチャンネル) : あなたのエージェントが単一のインターフェイス(たとえば、UI)で始まっても、ユーザーはすぐに、Slack、WhatsApp、SMS、たぶんデバッグのためのCLIをより多くの方法で相互作用する必要があります。 Problem : 統一された入力契約、API、またはすべてのチャンネルが供給する普遍的なインターフェイスを作成します。 Solution : Checklist エージェントは、CLI、API、UI、またはその他のインターフェイスを介して動作します。 All inputs funnel through a single endpoint, parser, or schema すべてのインターフェイスは同じ入力形式を使用します。 ビジネス論理は、どのチャンネルアダプターにも存在しません。 新しいチャンネルを追加すると、アダプターを書き込むだけで、コアエージェントコードに変更はありません。 Part 2 - Move Beyond Chatbot Mode(チャットボットモードを超えて移動) タスクは1つだけですが、すべては単純ですが、AIインフルエンサーの投稿のように、ツール、意思決定論理、複数の段階を追加すると、エージェントは混乱に変わります。 トラックを失い、エラーをどうするか知らない、正しいツールを呼ぶのを忘れて、あなたは再びロゴで孤独に残され、そこで「うん、すべてがそこに書かれているように見える。 これを回避するために、エージェントは明確な行動モデルを必要とします:彼らは何をしているか、彼らはどのようなツールを持っているか、誰が決定を下すか、人間がどのように介入するか、そして何かが間違っているときに何をすべきか。 このセクションでは、エージェントをシンプルなチャットボットを超え、ツールを使用し、エラーを管理し、複雑なタスクを実行できる一貫した行動モデルを構築するのに役立つ5つの重要な原則を説明します。 5 - ツール使用のための設計 : これは明らかに聞こえるかもしれませんが、多くのエージェントはまだ「Plain Prompting + raw LLM output parsing」に頼っています。それは、ランダムにボルトを回すことによって車のエンジンを修正しようとしているようなものです。 Problem 脆弱性:文法またはフレーズの順序の小さな変更は、あなたのパッサージを破り、あなたのコードとモデルの予測不可能な間の絶え間ない武器競争を作り出すことができます。 「ジョン・スミスを呼ぶ」「ジョン・スミスを呼ぶ」「ジョン・スミスを呼ぶ」 メンテナンスの複雑さ:パッシングコードは混乱し、デバッグが困難になります. 各新しいエージェントの「スキル」は、より多くのパッシングルールを書くことを意味します。 限られた機能:複数のツールを信頼できるように呼び出したり、単純なテキストで複雑なデータ構造を伝えるのは難しい。 : モデルに JSON (または他の構造化された形式) を返し、あなたのシステムが実行を処理するようにしてください. This means the LLMs interpret user intent and decide to do, and your code takes care of それは、正しく定義されたインターフェイスを通じて正しい機能を実行することによって起こります。 Solution what どう ほとんどのプロバイダー(OpenAI、Google、Anthropicなど)が現在サポートしています。 または : function calling structured output あなたのツールは、名前、説明、パラメータを含む JSON スケジュールとして定義します。 モデルを呼び出すたびに、あなたはプロンプトと一緒にこれらのツールスケジュールを提供します。 The model returns JSON specifying: (1) the function to call, (2) Parameters according to the scheme. モデルがJSONを返します。 あなたのコードは JSON を検証し、それらのパラメータで正しい関数を呼び出します。 オプションとして、関数の出力は最終反応生成のためにモデルに戻すことができます。 : ツールの説明はプロンプトの一部です. 明確でない場合は、モデルが間違ったツールを選択する可能性があります. あなたのモデルが機能呼び出しをサポートしていない場合、またはそれを避けたい場合は? Important プロンプトエンジニアリングを通じて JSON 出力を生成し、Pydantic のようなライブラリで検証してください。 : Checklist 答えは厳密に構造化されている(例えば、JSON) ツールインターフェイスは、スケジュール(JSON Schema または Pydantic)で定義されます。 出力は、実行前に検証されます。 フォーマットのエラーがシステムを崩壊させない(笑えるエラー処理) LLMは、どの機能を呼び出すかを決定し、コードは実行を処理します。 6 - コードにコントロール論理を置く 今日のほとんどのエージェントはチャットボットのように振る舞います:ユーザーは何かを言い、エージェントは答えます。 Problem: この設定で、あなたのエージェントは: ユーザープロンプトなしで自分で行動する パラレルでタスクを実行 Plan and Sequence Multiple Steps(複数のステップ) Retry failed steps intelligently 背景での作業 積極的になる代わりに反応的になる。 次の仕事を見つめ、次に何をすべきかを決め、ポケットされるのを待つことなく前進する人。 What you really want is an agent that thinks like a scheduler つまり、あなたのエージェントは: イニシアチブ 連鎖の複数のステップ 失敗から回復 タスク間の切り替え 働き続ける、誰も見ていない時でも Move the control flow out of the LLM and into your system. The model can still help (e.g., decide which step comes next), but the actual sequencing, retries, and execution logic should live in code. Solution: This flips your job from to モデルは、人形マスターではなく、より広い建築の一部になります。 prompt engineering システムデザイン Let’s break down three ways teams are approaching this shift. 1. Finite State Machine (FSM) Break the task into discrete states with defined transitions. What it is: LLMの役割: 1つの州内で行動するか、次の選択を助ける。 最適:線形、予測可能な流れ。 Simple, stable, easy to debug. Pros: ツール:StateFlow、YAML 構成、コード内の古典的な状態パターン。 2. Directed Acyclic Graph (DAG) Represent tasks as a graph — nodes are actions, edges are dependencies. What it is: LLMの役割:ノードとして作用するか、グラフを生成するのに役立ちます。 Branching flows, parallel steps. Best for: Flexible, visual, good for partial recomputation. Pros: LangGraph, Trellis, LLMCompiler, or DIY with a graph lib. Tools: 3. Planner + Executor それは何ですか: あるエージェント(またはモデル)が計画を構築し、他の人々は段階的にそれを実行します。 Big model plans, small ones (or code) execute. LLM role: Modular systems, long chains of reasoning. Best for: 利点:関心の分離、スケーラブル、コスト効率。 ツール:LangChainのPlan-and-Execute、または独自のPlaner/Executorアーキテクチャ。 Why This Matters You gain control over the agent’s behavior リリース、デバッグ、個々のステップをテストできます。 部品を独立してスケールしたり、モデルを交換したりできます。 You make things visible and traceable instead of opacous and magical. あなたは物事を目に見えるかつ追跡可能にする。 Checklist エージェントは、FSM、DAG、またはプランナー構造に従います。 LLMは行動を示唆するが、流れを駆動しない タスクの進行を視覚化できます。 Error handling is baked into the flow logic. エラー処理はフローの論理に埋め込まれている。 7. Keep a Human in the Loop(人間をループに置く) ツール、コントロールフロー、構造化された出力でさえ、完全な自律性はまだ神話です。 彼らは責任を問われることはできないし、現実世界では、彼らは間違った呼びかけをするだろう(遅かれ早かれ)。 Problem: 理解 When agents act alone, you risk: deleting records, messaging the wrong person, sending money to a dead wallet. Irreversible mistakes: : violating policy, law, or basic social norms. Compliance issues skipping steps, hallucinating actions, or just doing something no human ever would. Weird behavior: : users won’t rely on something that seems out of control. Broken trust 責任を問わない:それが壊れたとき、何が間違ったのか、誰が混乱を所有しているのかは不明です。 Solution: Bring Humans Into the Loop (HITL) 人間をコパイロットとして扱い、落とし穴ではなく、システムを設計し、 , あるいは すべてが完全に自動的でなければならないわけではありませんが、時には「あなたは確信していますか?」が、あなたが構築できる最も価値のある機能です。 pause ask ルート Ways to Include Humans Critical or irreversible actions (e.g., sending, deleting, publishing) require explicit human confirmation. Approval gates: エスカレーションパス:モデルの信頼性が低い場合、または状況が曖昧な場合、レビューのために人間にルートします。 インタラクティブな訂正:ユーザーが送信される前にモデル応答をレビューおよび編集できるようにします。 フィードバック ループ: ヒトのフィードバックをキャプチャして、エージェントの行動を改善し、時間とともにモデルを訓練します(Reinforcement Learning from Human Feedback)。 Override オプション: 人間がエージェントのワークフローを中断、override、または再ルーティングできるようにします。 Checklist 敏感な行動は、処刑前に人間によって確認される。 There’s a clear path to escalate complex or risky decisions Users can edit or reject agent outputs before they’re final Logs and decisions are reviewable for audit and debugging The agent explains it made a decision (to the extent possible) why 8.Feed Errors Back into Context(フィードエラーを文脈に戻す) ほとんどのシステムは、エラーが発生したときに崩壊したり、停止したりします。自律的なエージェントにとっては、それは死んでしまいますが、盲目的にエラーを無視したり、それらを取り巻く幻覚を起こしたりすることは、同じように悪いことです。 Problem: What can go wrong: 脆弱性:外部ツールエラーや予期せぬLLM出力であろうと、あらゆる失敗は、プロセスを壊す可能性があります。 Frequent restarts and manual fixes waste time and resources. Inefficiency: 学習なし:自分の過ちを知らなければ、エージェントは改善したり、適応したりすることができません。 Errors unaddressed can lead to misleading or fabricated responses. Hallucinations: Treat errors as part of the agent’s context. Include them in prompts or memory so the agent can try self-correction and adapt its behavior. Solution: How it works: Capture error messages or failure reasons clearly. Understand the error: The agent reflects on the error and tries to fix it by: (1) detecting and diagnosing the issue, (2) adjusting parameters, rephrasing requests, or switching tools, (3) retrying the action with changes. Self-correction: Error context matters: Detailed error info (like instructions or explanations) helps the agent correct itself better. 単純なエラーログでさえパフォーマンスを向上させる。 Incorporate error-fix examples into model training for improved resilience. Training for self-correction: If self-correction repeatedly fails, escalate to a human (see Principle 7). Human escalation: Checklist: Errors from previous steps are saved and fed into context Retry logic is implemented with adaptive changes. リトリロジクスは、適応的な変更によって実装されます。 繰り返しの失敗は、人間のレビューや介入に逆戻りを引き起こす 9.Split Work into Micro-Agents(マイクロエージェントに分割作業) タスクが大きくなり混乱するほど、文脈のウィンドウが長くなり、LLMがプロットを失う可能性が高くなります。複雑なワークフローは、数十のステップでモデルをその甘い場所を超え、混乱、トークンの無駄、およびより低い精度につながります。 Problem: Divide and Conquer. 利用する , each responsible for one clearly defined job. A top-level orchestrator strings them together. Solution: small, purpose-built agents Why small, focused agents work 管理可能なコンテキスト:ショートなウィンドウがモデルを鋭くします。 one agent, one task, zero ambiguity. Clear ownership: より高い信頼性:シンプルなフローは、迷う場所が少なくなることを意味します。 簡単なテスト:各エージェントを単独でテストできます。 速いデバッグ:何かが壊れたとき、どこを見るべきかを正確に知っています。 There’s no magic formula for when to split logic; it’s part art, part experience, and the boundary will keep shifting as models improve. A good rule of thumb: if you can’t describe an agent’s job in one or two sentences, it’s probably doing too much. Checklist 全体的なワークフローは、一連のマイクロエージェント呼び出しです。 Each agent can be restarted and tested on its own. エージェントの定義を1〜2文で説明できます。 第3章 行動の安定化 ほとんどのエージェントのバグは赤いエラーとして表示されず、奇妙な出力として表示されます。 それは、LLMは心を読まないから、彼らはトークンを読んでいるからです。 The way you frame requests, what you pass into context, and how you write prompts, all of it directly shapes the outcome. And any mistake in that setup becomes an invisible bug waiting to surface later. This is what makes agent engineering feel unstable: . if you’re not careful, every interaction slowly drifts off course このセクションは、そのフィードバックループを緊縮することについてです。プロンプトは投げ出しの文字列ではなく、コードです。コンテキストは魔法ではありません、あなたが明確に管理する状態です。 10 - Prompts as Code を扱う Too many projects treat prompts like disposable strings: hardcoded in Python files, scattered across the codebase, or vaguely dumped into Notion. As your agent gets more complex, this laziness becomes expensive: Problem: It’s hard to find, update, or even understand what each prompt does バージョン制御はありません - 何が変更されたか、いつ、なぜ変更されたかを追跡する方法はありません。 最適化は推測に変わる:フィードバックループなし、A/Bテストなし そして、プロンプト関連の問題をデバッグすることは、コメント内のバグを修正しようとしているような感じです。 コード. 彼らは行動を定義します. したがって、あなたが本物のコードのようにそれらを管理します: Solution: スピードは from your logic: store them in , , , or use template engines like Jinja2 or BAML Separate them txt .md .yaml .json with your repo (just like functions) Version them これらをテストする: (1) フォーマット、キーワード、JSONの有効性に関する単位テスト応答、 (2) プロンプト変数の評価を実行し、 (3) パフォーマンスを測定するためにLLM-as-a-judgeまたは heuristic scoringを使用する コードレビューのように迅速なレビューを処理してください. 変更が出力の行動に影響を与える可能性がある場合、それは2つ目の目に値します。 Bonus: Checklist: Prompts live outside your code (and are clearly named) 彼らはバージョン化され、 diffable They’re tested or evaluated 重要なときのレビュー エンジニア・ザ・コンテキスト・スタック(Engineer the Context Stack) 私たちはすでに、メモリの充電と課題ごとにエージェントを分割することによって、LLMの忘却性に取り組んでいますが、さらに深い課題があります。 私たちはモデルに情報を形式化し、提供します。 Problem: どう Most setups just throw a pile of role: content messages into the prompt and call it a day. That works… until it doesn’t. These standard formats often: Burn tokens on redundant metadata ツールチェーン、ステータス、または複数の知識タイプを代表するための闘い 複雑な流れの中でモデルを適切に導くことができない And yet, we still expect the model to “just figure it out.” That’s not engineering. That’s vibes. Solution: Engineer the context. 入力パッケージ全体を慎重に設計されたインターフェイスのように扱い、それはまさにそれだからです。 : Here’s how 完全なスタックを所有する:何が入ってくるか、どのように順序をとり、どこに表示されるかを制御します. システム指示から取得したドキュメントまで、メモリのエントリまで、すべてが意図的でなければなりません。 チャット形式を超えて:より豊富で密集したフォーマットを構築し、XML スタイルのブロック、コンパクトなスケジュール、圧縮されたツール トラック、さらには Markdown セクションを明確にします。 全体的に考える: コンテキスト = モデルが見るすべてのもの: プロンプト、タスク状態、以前の決定、ツールログ、指示、さらには以前の出力です。 これは、あなたが最適化している場合に特に重要になります: packing more meaning into fewer tokens Information density: コスト効率:低いコンテキストサイズで高いパフォーマンス セキュリティ:モデルが見るものを制御し、タグ化する Error resilience: explicitly signaling edge cases, known issues, or fallback instructions. エラー抵抗性:エッジケース、既知の問題、またはバックバック指示を明示的にシグナル化する。 促進は戦いの半分に過ぎない。 あなたがまだやっていない場合は、あなたのエージェントが大きくなったときになります。 Bottom line: コンテキストエンジニアリング 12 - セキュリティレイヤーを追加 Even with solid prompts, memory, and control flow, an agent can still go off the rails. Think of this principle as an insurance policy against the worst-case scenarios: 迅速な注入:ユーザー(または他のシステム)は、エージェントをハイジャックする指示をスライスします。 敏感なデータ漏洩:モデルはPIIまたは企業の秘密を明らかにします。 毒性または悪意のあるコンテンツ:望ましくない憎しみの発言、スパム、または許可されていないコンテンツ。 confident but false answers. Hallucinations: 範囲外の行動:エージェントは「創造的になる」し、決してすべきでないことをする。 No single fix covers all of that. You need リクエスト/応答サイクルのあらゆる段階で問題を解決する複数のセキュリティー。 defense-in-depth Quick Checklist ユーザ入力検証(ジャイルブレイクフレーズ、意図チェック)が実施されています。 For factual tasks, answers . must reference RAG context The prompt explicitly tells the model to stick to retrieved facts. プロンプトは明示的にモデルに、回収された事実に固執するように言います。 出力フィルターは、PIIまたは許可されていないコンテンツをブロックします。 答えには、情報源への引用/リンクが含まれます。 エージェントとツールは最小の特権に従う。 重要な行動は、HITLの承認または監視を通じて行われる。 これらのレイヤーを標準のDevOpsとして扱う:それらをログし、テストし、安全に失敗する。 Part 4 - Keep it Working Under Load 生産では、失敗はほとんど一度に起こらないし、しばしばすぐに気づかないこともあるし、時にはまったく気づかないこともある。 このセクションでは、エンジニアリングの規律を構築し、エージェントを継続的に監視し、すべてがスムーズに動作することを保証します。 . ログやトラッキングから自動テストまで、これらの実践により、エージェントの行動が明確かつ信頼できるようになります。 13 - 完全な執行の道を追跡する : エージェントは開発、アップデート、または通常の操作中に必然的に悪い行動を起こすでしょう。これらの問題をデバッグするには、エラーを再現し、エラーを特定するのに何時間もかかる可能性があります。あなたが既にステータスを外部に保ち、エラーを文脈に圧縮するなどの重要な原則を実装した場合、あなたは前方にいますが、最初から効果的なデバッグを計画することは、後で深刻な頭痛を救います。 Problem : エージェントの意思決定および行動プロセスの各ステップを通じてユーザーの要請からの全旅程をログします. Individual component logs are not enough; you need end-to-end tracking covering every detail. Solution : Why this matters デバッグ:どこで、なぜ事態が間違ったのかを迅速に特定する。 アナリティクス:ボトルネックと改善の機会を特定する。 : Measure how changes affect behavior. Quality assessment 再生可能:あらゆるセッションを正確に再生します。 監査:エージェントの決定と行動の完全な記録を保持する。 Minimum data to capture 入力:以前のステップからのユーザーリクエストとパラメータ エージェントステータス:各ステップの前に重要な変数。 プロンプト:LLMに送信された完全なプロンプト(システム指示、歴史、文脈)。 LLM 出力:処理前の原料応答。 ツール呼び出し:ツール名と参数を呼び出しました。 ツールの結果:ツールの出力またはエラー エージェントの決定:次のステップまたは選択された回答。 メタデータ:タイミング、モデル情報、コスト、コード、プロンプトバージョン 可能な限り、既存のトラッキングツールを使用してください: LangSmith、Arize、Weights & Biases、OpenTelemetryなど。 : Checklist すべてのステップが詳細に記録されています。 session_id と step_id でリンクされているログ。 完全な通話チェーンをレビューするインターフェイス。 どんな瞬間でも完全に再現する能力。 14 — Test Every Change : 今のところ、あなたのエージェントはリリースする準備ができていると感じるかもしれません:それは、おそらくあなたが望むように働くかもしれません。しかし、更新後に動作し続けるかどうかをどうやって確信できますか? コード、データセット、ベースモデル、またはプロンプトへの変更は、静かに既存の論理を破ったり、パフォーマンスを悪化させることができます。 従来のテスト方法はLLMのすべての不思議をカバーしません: Problem モデルドリフ:モデルやデータの変更によるコード変更なしでパフォーマンスが時間とともに低下 Prompt Brittleness: 小さな prompt tweaks can cause large output changes. 迅速な脆弱性:小さな prompt tweaks can cause large output changes. Non-Determinism: LLMsはしばしば同じ入力に対する異なる答えを提供し、正確な試験を複雑にします。 再生しにくいエラー:固定入力でさえ、バグは追跡しにくい場合があります。 The butterfly effect: changes cascade unpredictably across systems バトル効果:システム間で予測不可能な変化 幻覚とその他のLLM特有のリスク : クラシックなソフトウェアテストとLLMに焦点を当てた品質チェックを組み合わせた徹底的で多層的なテスト戦略を採用する。 Solution Multi-level testing: unit tests for functions/prompts, integration tests, and full end-to-end scenarios. 複数のレベルのテスト:機能/プロンプトの単位テスト、統合テスト、および完全なエンド-to-エンドシナリオ LLMの出力品質に焦点を当てる:関連性、一貫性、精度、スタイル、安全性 予想出力または許容可能な結果範囲を含むゴールデンデータセットを使用して回帰チェック テストを自動化し、CI/CDパイプラインに統合 批判的または複雑な評価のための人間を巻き込む(ヒューマン・イン・ザ・ロック) Iteratively test and refined prompts before deployment (デプロイ前) さまざまなレベルでのテスト:コンポーネント、プロンプト、チェーン/エージェント、および完全なワークフロー : Checklist 論理はモジュール化され、個別および組み合わせで徹底的にテストされています。 出力品質は、ベンチマークデータに基づいて評価されます。 テストは、一般的なケース、エッジケース、失敗、および悪意のある入力をカバーします。 騒音または敵対的な入力に対する堅固性が確保されます。 すべての変更は自動テストに合格し、未確認の回帰を検出するために生産中に監視されます。 15 - Own The Whole Stack この原則はすべてを結びつけるものであり、それは他のすべてを通り抜けるメタルールです。 今日では、ほとんどすべてのタスクを処理するための無数のツールとフレームワークがありますが、これはプロトタイプ作成の速度と簡単さにとって素晴らしいことですが、フレームワーク抽象にあまりにも依存することは、柔軟性、制御、時にはセキュリティを犠牲にすることを意味します。 これは、管理する必要があるエージェント開発において特に重要です: LLMsの固有の予測不可能さ 過渡期と自己訂正の複雑な論理 あなたのシステムがコアタスクを書き換えることなく適応し、進化する必要性 彼らはあなたのエージェントがどのように振る舞うべきかを規定します。これはプロトタイプを加速させることができますが、長期的な開発を管理し、カスタマイズすることを困難にします。 Frameworks often invert control あなたが見た多くの原則は、オフ・ザ・シェルフのツールで実装できますが、時には、コアロジックの構築は明示的に同様の努力を要し、あなたにより良い透明性、制御、および適応性を提供します。 一方で、完全にカスタマイズし、何もかもをゼロから書き直すことは過剰なエンジニアリングであり、同様に危険です。 キーは エンジニアとして、あなたはいつフレームワークに頼るか、いつ完全なコントロールを取るかを意識的に決定し、関連する妥協を完全に理解します。 balance : the AI tooling landscape is still evolving fast. Many current tools were built before standards solidified. They might become obsolete tomorrow — but the architectural choices you make now will stick around much longer. Remember Conclusion LLMエージェントを構築することは、もはやAPIを呼び出すことだけではなく、現実世界の混乱に対処できるシステムを設計することです:エラー、状態、文脈の制限、予期せぬ入力、および進化する要件。 The 15 principles we covered aren’t theory, they’re battle-tested lessons from the trenches. They’ll help you turn fragile scripts into stable, scalable, and maintainable agents that don’t break the moment real users show up. 最終的には、それはあなたのプロジェクト、あなたの目標、あなたの創造です。しかし、覚えておいてください:LLMは強力ですが、それは複雑なシステムの一部に過ぎません。エンジニアとしてのあなたの仕事は、プロセスを所有し、複雑さを管理し、全体をスムーズに走らせることです。 もしあなたが一つを取り除いたら、これを以下にしてください。 l. なぜなら、それが唯一の方法で「wow, it answered!」から「yes, it keeps working」へと移行するからです。 slow down, build solid foundations, and plan for the long hau 繰り返し繰り返し、テストし、学び続けること、そして忘れないでください、循環中の人間は落とし穴ではありません、彼らはあなたのエージェントを土台にし、効果的です。 これは終わりではありません、実際に提供するビルドエージェントの始まりにすぎません。 テクノロジーのプロとしてあなたの視聴者を成長させるために苦労していますか? The Tech Audience Accelerator is the go-to newsletter for tech creators serious about growing their audience. You’ll get the proven frameworks, templates, and tactics behind my 30M+ impressions (and counting). https://techaudienceaccelerator.substack.com/embed?source=post_page-----e58139d80299---------------------------------------&embedable=true