AI評価の解説：基礎から自己改善型エージェントまで

イージーモード：evalって何？ - evalとは、AIエージェントが行ったことが正しいかどうかを確認するテスト - 「正しい」の本質は、あなたやあなたの組織が正しいと考えることをソフトウェアに組み込むこと - 例：顧客ミーティングを記録し、フォローアップの下書きを書き、送信前に停止するGTMエージェント - この文脈では、evalは顧客ミーティングが記録されたか、フォローアップの下書きが書かれたか、エージェントが送信前に一時停止したかをチェックすること - evalは実は新しいものではなく、ソフトウェアに常に存在してきたユニットテストの進化版 - evalを設定するレシピは実は非常にシンプル：エージェント + システム + タスク + 検証者 - GTMエージェントの例では、エージェント、Salesforceへの読み書きアクセス、一連のタスク（リードステータスの更新、通話の記録、フォローアップの作成など）、そして検証者（タスクが正しく行われたかどうかを判断するツール）がある - 検証者はシンプルなPython関数や、コンテンツ/散文のチェックにすることができる - ルーブリックは、検証不可能なタスクに対して「良い状態」を定義するための優れた方法であり、検証者が機能し続けることを可能にする - ルーブリックを作成してもエージェントが機能しない場合、根本原因は：チェックリストが不完全、モデルが十分に賢くない、コンテキストが悪いか不完全、またはプロンプトが十分に良くない、のいずれかになる ハードモード：エージェント環境って何？ - 環境 = エージェントが作業を行い、そのパフォーマンスを測定する場所 - ChatGPT時代のテキスト入力・テキスト出力から、エージェント時代のプロンプト入力・現実世界の作業出力への移行に伴い、環境が必要になった - 例：Claude Code/Codexがあなたのコンピュータで作業する場合、環境はファイル、ブラウザ、メール、アプリ、権限 - 今日エージェント環境を構築する場合 = 既存のツールの再現・シミュレーションであり、エージェントには本物に見えるが実際には本物ではない（本番を上書きしない） - 基本的に、社内のライブシステムやデータを壊すことなく、エージェントのパフォーマンスをテストできるようにしたい - エージェントとevalを構築する際のニーズ：(1) チームごとにタスクを管理（GTM ≠ SWE）、(2) チーム固有の環境、(3) すべてのインフラを自分で構築せずにスケールで実行 - エージェント環境を設定するための人気ツールは、Harborと呼ばれるオープンソースフレームワークで、evalを実行するために必要なすべてのエージェント環境抽象化を提供し、すべてを管理する必要はないが、必要に応じて低レベルにアクセスできる - Harborのプリミティブは以下をカバー：環境構築、検証者構築、指示構築、サンドボックスインフラ - 初心者向けパス：既存のHarbor形式のevalを取得 → Claude Code/Codexに説明を依頼 → 自分のエージェント用に調整 - LangSmith Engine：スケールでevalを作成；良い/悪い出力を判断でき、コードに住まずにフィードバックを提供したい人のためのUI - 複数の実際のエージェント/モデル（例：フロンティア + GLM + 小型Qwen）を環境で実行し、奇妙なパターンを探すことで環境を検証 - 環境エンジニアリングはエージェントエンジニアリングと同様に反復的；人間が構築し、出力をレビュー - スケールでevalを実行するには、evalスイートが必要。evalスイートとは、会社として実行しているエージェントタスクのコレクション。各タスクは、入力プロンプト、検証者、環境で構成される - 新しいモデルが出るたびに、evalスイート（またはスイートからのタスクの選択）を実行し、コスト vs. 速度 vs. インテリジェンスのトレードオフを評価する ゴッドモード：自己改善エージェントって何？ - 現実世界のエージェント → 本番データ → 本番をevalに変換（そしてevalを使って改善）→ エージェントを継続的に改善、という継続的なサイクル - 過激な見解：チームが本番データをevalに変換するのが本当に得意なら、エージェントを継続的に改善できる - evalは失敗を見つけるために存在する；その後、その失敗が二度と起こらないようにエージェントを変更する - 2つの改善バケット：ハーネスエンジニアリング & 小型モデルのファインチューニング - ハーネスエンジニアリング：（始めるのに安価な場所）：プロンプト、ツール定義/説明、モデル選択、モデル組み合わせ（例：Sol+Opus、GLM+Opus）を調整 - ファインチューニング（狭い本番タスクで）：オープンモデル + ファインチューニングインフラが存在；*その*タスクでOpusに匹敵し、約10倍安価；GTMエージェントはフロンティア数学を必要としない - ゴッドモード = 実際の本番データを収集 → eval/環境に変換 → 改善方法を選択（まずハーネス；後で特定タスク用のファインチューニングされたインテリジェンスを所有） - ボトルネックは多くの場合、人間が検証者/ルーブリックを更新すること - 自律性に関する2つの質問：どうやって速く回すか；人間がループにいなくても実行できるか？ - 目標：ループ上の人間の接触点を最小化する - エージェントトレースは、エージェントを使用する組織にとって最初の実践的なステップ - トレース = すべてのアクションのログ：ツール呼び出し - 人間はエージェントが*何を*するかをうまく推論できない；ライブの動作（別名トレース）を見ることで、正しい/間違いが明確になる - 悪い結果を見る → トレース（レシート）を読む → 間違ったステップを見つける → エージェントを変更して繰り返さないようにする - 人間の接触点は、より賢いモデルがリリースされるたびに減少する - 今日の人間の役割#1（事前）：マイニング/改善エージェントに、良い状態と悪い状態がどのようなものかを説明する（探すべき行動のプロンプト）；主に事前で、時間とともにいくつかの編集を行う - その後、エージェントは失敗したツール呼び出し、指示従順の失敗などを発見し、改善を提案できる（新しいプロンプト、新しい/異なるツールなど） - 良いevalスイートまたは良い本番の悪い行動測定があれば、一晩実行されるエージェントは修正を提案するのが非常に得意になる - 人間の役割#2：本番をeval/環境に変換する際、*会社*が気にすることをレビューする - 最もレバレッジの高い組織的行為：人間が「良い状態」がどのようなものかを書き留めること