これは、私自身が応用 AI エンジニアリングに移行する前に欲しかったガイドとして書きました。
この役割は、従来のソフトウェアエンジニアリングと広く重なりますが、ほとんどのソフトウェアエンジニアが移行する際に学ばなければならない、いくつかの重要な概念が追加されています。この記事を、理解すべき中核トピックの概要として捉え、より深く知りたい場合は、記事内のリンク先リソースを参照することをお勧めします。
この記事を読み終える頃には、応用 AI エンジニアリングとは何か、その仕事に実際に何が必要とされるのか、そしてそれが従来のソフトウェアエンジニアリングをどのように超えているのかについて、はるかに明確な理解が得られるはずです。
もし、非常に優秀なエンジニアチームと共に応用 AI の最も興味深い問題に取り組むことに興味があれば、私たちは常に採用を行っています。私たちのウェブサイト varickagents.com から応募するか、候補者を紹介していただければ、2 万ドルの紹介ボーナスを支給します。
とはいえ、応用 AI エンジニアリングを理解する最善の方法は、ソフトウェア構築に関する考え方の変化から始めることです。
ソフトウェアエンジニアリング vs AI エンジニアリング
SWE と AI エンジニアの最大の違いは、従来のソフトウェアエンジニアリングが決定論的に考えるように訓練するのに対し、応用 AI は確率論的に考えることを強いる点です。
通常のソフトウェアでは、ロジックを書き、実行し、何かが壊れた場合、通常はそれを追跡できます。構造化された入力は、決定論的に構造化された出力を生成します。
応用 AI はそのようには機能しません。知能への非決定論的な API 呼び出しを中心に構築するため、同じ入力でも毎回異なる結果が返ってくる可能性があります。そのため、仕事は単にソフトウェアを構築することではなくなり、システムが意図したとおりに動作しているかどうかを測定することになります。
これを実現する方法が評価（エバル）です。そこで、開発したエージェントが誤りを犯していないことを保証する評価スイートを構築する方法を詳しく説明します。私たちの仕事の非決定論的な性質を考えると、これは応用 AI 開発者にとって最も重要なスキルの 1 つであると私は学びました。
記事の次のパートでは、AI エージェントの各パーツ（もちろんモデル自体は除く）の開発について説明します。これは、モデルに API を呼び出すことはできても、それ以外のすべては自分で構築する必要があるからです。これはハーネスエンジニアリングと呼ばれます。
そして最後に、本番環境で 1 つのエージェントから複数のエージェントへ移行する方法と、それがなぜ分散システムの問題になるのかについて説明します。この記事を最後まで読めば、応用 AI エンジニアへの移行ができない理由はないはずです。
評価（エバル）
応用 AI エンジニアは、評価（エバル）を使用して不確実性を測定された信頼に変えます。従来のソフトウェア開発では、ロジックを書き、コードをテストしたため、システムを信頼します。応用 AI では、モデルが実行ごとに異なる動作をする可能性があるため、そのようにシステムを信頼することはできません。そのため、AI エンジニアはエージェントの周りに測定レイヤーを構築する必要があります。
評価（エバル）とは、エージェントにタスクを与え、実行させ、その行動を採点するプロセスです。その目標は、エージェントが作業を正しく完了したこと、そしてエージェントが与えられた境界内に留まったことの 2 つを証明することです。
最初のステップは、結果を採点することです。これは評価プロセスの中で最も簡単なステップです。私が普段扱っている請求書エージェントの場合、これは請求書が正しい場所に届いたか、重複がフラグ付けされたかを確認することを意味します。最終結果を、本来あるべき結果と比較するだけです。
2 番目のステップは、軌跡を採点することです。これは、エージェントがその結果に至るまでにたどった経路、つまり、呼び出したツール、触れたフィールド、渡した引数、途中で試みたアクションです。これは、エージェントが正しい最終回答に到達したとしても、その過程で危険なことを行う可能性があるため重要です。正しく請求書を分類しながらも、銀行口座の詳細を変更したり、承認前に支払いを送信したりする可能性があります。
軌跡自体は単なるログです。エージェントが呼び出したすべてのツールと渡した引数の順序付きリストです。採点するということは、そのログに対してチェックを記述することを意味します。
いくつかのチェックは決定論的です。send_payment が承認呼び出しの前に決して出現しないことを確認したり、エージェントが書き込みを許可されたフィールドのみに書き込んだことを確認したりします。その他は判断呼び出しです。エスカレーションが適切だったかどうか、推論がアクションを正当化したかどうかなどです。これらはルーブリック（評価基準）とともに 2 番目のモデルに送られます。
従うべき一般的な原則は、決定論的チェックは通常、安全性違反をキャッチし、判断モデルが品質を評価するということです。
結果は、テストケースごとに 2 つの評価となります。エージェントが正しい回答を得たかどうか、そして正しく動作したかどうかです。これらは別々に報告する必要があります。なぜなら、請求書を 95% の確率で正しく分類するが、4% の実行で禁止フィールドに触れるエージェントは、複合スコアでは優れているように見えても、本番環境では大きなビジネス上の問題を引き起こすからです。
この記事は、評価（エバル）とその他すべてのトピックへの入門編として機能するため、より深く学ぶための他のリソースもリンクしています。効果的な評価を構築する方法を理解するのに役立ったものは次のとおりです。
それぞれを一通り読むことをお勧めしますが、Lenny と Hamel の記事を先に読んでから、評価コース（少し実践的です）に進むとよいでしょう。
しかし、評価にはテストするエージェントが依然として必要であり、モデル以外のすべては自分で構築する必要があります。その周辺システムはハーネスと呼ばれます。次のセクションでは、ツール呼び出しからコンテキストウィンドウの最適化まで、ハーネスエンジニアリングプロセスの各パーツについての考え方を説明します。
ハーネスエンジニアリング
モデル単体ではエージェントではありません。モデルは推論、分類、作成、決定を行うことはできますが、単独で企業内で運用することはできません。どのようなアクションを実行すべきかを述べることはできますが、その周りにシステムを構築しなければ、そのアクションを安全に実行することはできません。そして、そのシステムがハーネスです。
ハーネスとは、モデルの周りにあるすべてのもので、API 呼び出しを機能するエージェントに変えるものです。使用できるツール、認識するコンテキスト、記憶する状態、制約するガードレール、そしてタスクが完了するまで動作を続けさせるループです。
ハーネスの最初の部分は、ツールの実行です。
モデルはテキストの読み書きしかできないため、モデルが何かを行うことを決定しても、実際にそれを実行するわけではありません。レコードを更新したり、メールを送信したり、データベースを検索したりするための構造化されたリクエスト（JSON 文字列）を出力します。
ハーネスはそのリクエストを受け取り、検証し、実際の操作を実行し、結果をテキストとしてモデルに送り返します。
2 番目の部分は、コンテキスト管理です。すべての指示、ツールメニュー、ツール結果、以前のメッセージは、モデルのコンテキストウィンドウ内のスペースを占有します。ハーネスは、モデルが今すぐ見る必要があるもの、要約すべきもの、削除すべきものを決定する必要があります。これがないと、エージェントは無関係な履歴に迷い込んでしまいます。
ハーネス開発プロセスの各パーツについて、より詳細な記事を今後執筆する予定ですが、今のところは、エージェント向け継続学習プラットフォームである Arize のエンジニアによる、コンテキスト管理に関する彼らの思考プロセスを深く掘り下げたこの講演を聞くことをお勧めします。
効果的なコンテキスト管理を実際にエージェントに適用する方法についてさらに学ぶには、以下のブログをお読みください。
ハーネスエンジニアリングにおける 3 番目の部分は、状態とメモリです。モデルは呼び出し間でステートレスであるため、エージェントが記憶する必要があるものはすべてモデルの外部（通常はデータベース、ファイルストア、またはタスクレコード）に存在する必要があります。コンテキストはモデルが現在見ているものです。状態は、エージェントが知っているが現在見ていないすべてのものです。
4 番目の部分は、ガードレールです。モデルは誤ったアクションを正しいアクションと同じ自信を持って要求する可能性があるため、ハーネスは権限をチェックし、入力を検証し、安全でないアクションをブロックし、リスクの高いステップを人間にルーティングする必要があります。
最後に、これらすべてがエージェントループで結び付けられます。コンテキストを構築し、モデルを呼び出し、その応答を検査し、許可されていればツールを実行し、結果を保存し、コンテキストを更新し、タスクが完了するまで繰り返します。
ハーネスエンジニアリングは、応用 AI エンジニアとして行う作業の大部分を占めるため、このセクションはじっくりと時間をかけて取り組んでください。応用 AI エンジニアとしてのあなたの仕事のすべては、確率論的なシステムが決定論的なソフトウェア内で動作できるようにするための運用環境を構築することです。
しかし、本番環境は通常、1 つのエージェントで終わるわけではありません。
ワークフローが大きくなるにつれて、作業を分割したいという本能が自然に働きます。しかし、2 つ目のエージェントを追加すると、システム設計が変わります。
1 つのエージェントの場合、複雑さのほとんどは 1 つのループ内にあります。複数のエージェントの場合、同じ環境に対して複数のループが動作することになります。各エージェントは、別のエージェントが変更したばかりの状態を読み取ったり、別のエージェントが依存しているメモリに書き込んだり、その結果がワークフロー全体に影響を与えるツールを呼び出したりする可能性があります。
その時点で、難しい部分はもはやプロンプト、評価、ハーネス設計だけではありません。それは分散システムの問題になります。つまり、どの状態を誰が所有するのか、誰がメモリに書き込めるのか、どのツールが再試行しても安全なのか、そして 2 つの妥当なエージェントが誤った順序でアクションを実行した場合に何が起こるのか、ということです。
マルチエージェントデプロイメントは分散システムの問題である
最初のエージェントが機能し、ワークフローが大きくなると、新しい応用 AI エンジニアは自然と作業を役割に分割しようとします。1 つのエージェントが調査し、1 つが計画し、1 つが実行し、1 つがレビューする、といった具合です。
しかし、2 つ目のエージェントは、設計の単位をエージェントからシステムへと変更します。複数のループが同じ環境で動作するようになります。あるエージェントが顧客ステータスを更新している間に、別のエージェントが古いステータスに基づいて計画を途中で作成している可能性があります。どちらも合理的な決定を下しましたが、システムがそれらの決定を誤った順序で相互作用させてしまいました。
これは分散システムの問題です。良いニュースは、分散システムエンジニアがこれらの障害を何十年も前に解決していることです。あなたの仕事は、それらをたまたま LLM を含むループに適用することです。以下は、AI エンジニアリングに適用できる分散システムからの解決策のリストです。
単一書き込み者原則。重要な状態のすべてについて、それに書き込めるエージェントは正確に 1 つとします。他のエージェントはそこから読み取るか、変更リクエストを送信します。これをツールレベルで強制します。実行エージェントだけが CRM に書き込める場合、調査エージェントは、どれだけ推論が貧弱でも CRM を破損できません。
冪等性キー。エージェントは、何かが失敗したりタイムアウトしたりしたときにツール呼び出しを再試行しますが、ツールが現実世界で何かを変更する場合、再試行は危険を伴う可能性があります。最初のリクエストが失敗したように見えたからといって、エージェントが同じ支払いを 2 回送信するのは避けたいところです。修正方法は、すべての変更を伴うツール呼び出し（つまり、外部システムのデータを変更するアクション）に一意のキーを添付することです。ツールが同じキーを再度見つけた場合、アクションを 2 回実行する代わりに、元の結果を返す必要があります。Stripe の API はこのように動作しており、支払い、メールなどを扱う際のエージェント開発にも適用できます。
書き込み時の事前条件。エージェントは、しばしば古い世界観に基づいて行動します。エージェントが計画を立てた時点と、外部システムを更新しようとする時点の間に、何かが変更されている可能性があります。古い書き込みを防ぐために、変更を加えるツールは、変更を行う前に条件を必要とする必要があります。例：「ステータスがまだ「保留中」の場合にのみ「承認済み」に設定する」。ステータスがすでに変更されている場合、ツールは新しい状態を静かに上書きする代わりに、明確に失敗する必要があります。
明示的なハンドオフ。定義されたスキーマを持つメッセージとして作業を渡し、オーケストレーターによって順序付けます。エージェントはタスクを発見するのではなく、受け取る必要があります。
TLDR
この記事は、応用 AI エンジニアとして私が学んだ最も重要なトピック、すなわち評価（エバル）、ハーネスエンジニアリング、マルチエージェントシステム設計の概要を提供します。
何かを得て帰っていただけるなら、これを覚えておいてください。モデルは知能を提供しますが、それを信頼できるものにするすべて（測定レイヤー、運用環境、調整ルール）は、あなたによってエンジニアリングされます。これらを理解すれば、ソフトウェアエンジニアリングからの移行は、すでに持っているスキルの延長線上にあるものになります。
この種の仕事に興味があり、非常に優秀なエンジニアリングチームと共に応用 AI の最も興味深い問題に取り組みたいとお考えなら、私たちは常に採用を行っています。私たちのウェブサイト varickagents.com から応募してください。すぐにでも始めていただけます。また、採用が決定した候補者を紹介していただければ、2 万ドルの紹介ボーナスを支給します。
