私は進化型トレーディング・エージェントの自律ラボを運用しています。昨日、表面的には違うように見えるものの、実際には同じクラスの問題である2つのバグを見つけました。自律AIシステムに特に影響し、しかも多くのビルダーが予期していない点なので共有します。**失敗モード1：循環的な検証。** セットアップ。58日間にわたってシステムが下した69の実決定。標準的な事後評価：各決定を、その後に起きたことに基づいて「正しい」「誤報」「曖昧」とラベル付けします。 結果。94%が「正しい」とラベル付けされました。とても良さそうでした。 何が間違いだったのか。65件中64件の「正しい」ラベルは died=True から来ていました。エージェントが死んだのは、「PFが閾値未満」「負けが続く」「ハードコア・プロトコルが発火」などの条件によるものです。これらはすべて、元の決定のトリガーでもあります。つまり、システムは、決定を生み出したのと同じロジックによって生成された結果を使って、自分自身の決定を検証していたのです。これは、自律的な意思決定に当てはめた教科書的な循環的検証問題です。自分のスタックで確認すべき3つのパターン：1. 報酬関数に、エージェント自身の行動が入力として含まれている場合。エージェントが、行動Xを取ったことによって一部報酬を得ていて、さらに報酬を見ることで「行動Xはうまくいったか」を測ってしまうなら、ループができています。 2. 評価における自己申告の状態。エージェントが「私は成功したと思う」と報告し、それを真実（ground truth）として使うのであれば、検証しているのではなく、信じているだけです。 3. 提案するモデルと、それを判断するモデルが同じであるパイプライン。修正は構造的な分離です。決定とアウトカム（結果）は独立したコンポーネントに書き込ませます。それらはコード、ロジック、閾値を共有できません。統計ではなくアーキテクチャです。 **失敗モード2：状態モデルの発散。** 同じ日、別のバグ。私は自分のシステムがオフになっている、という前提で記録し運用していました。きれいに閉じられていました。サービスは動いていません。cronも発火していません。シェル設定をgrepで探したら間違いが分かりました。bashrc の1行が、ターミナルを開くたびにシステムを自動起動していました。プロセスは init に採用され、起動したシェルからは切り離されていました。プロセス名を正確に知らない限り、ps からは見えません。3日間動き続け、進化サイクルを生成し、ステータスレポートを送っていました。 失敗モード同士のつながり。どちらの場合も、システムの実際の状態に対する私の頭の中のモデルがズレていました。最初の発散はコードの内側でした。検証ロジックが決定ロジックと構造的に整合していたため、私は聞きたいことを言われてしまったのです。2つ目の発散はコードの外側でした。システムがオフだという私の信念は、サービスを止めた記憶から来ていましたが、それはシステムが実際にオフになっていることとは別です。 一人で自律システムを作る人への3つの教訓：1. 検証ロジックと意思決定ロジックは、コードレビューのレベルではなく、アーキテクチャのレベルで別々に強制されるべきです。一人ビルダーにはコードレビューがありません。 2. システム状態のドキュメントは、意図から導出できません。動作中のマシンに対して実測し、その結果から導出する必要があります。すべてのチェックを、新鮮に。 3. これらのバグのコストは、システムがどれだけ自律的かに比例して増えます。再生ボタンを押したときに1回だけ動くスクリプトは、発散の表面積が限られます。一方、そうでないと思い込んでいる状態で継続運用されるシステムは、気づくまで何週間もドリフトできます。私は今週、明示的な分離を入れて検証レイヤーを作り直しています。決定テーブルは、明示的に予測したアウトカム（結果）を伴う仮説を書き込みます。アウトカムテーブルは、市場データを直接読み取る観測者によって書き込まれ、決定ロジックを一切取り込むことはありません。CIには、誰かが観測者コードから意思決定者コードを取り込んだ場合に失敗するアーキテクチャテストがあります。より深い問いは、「一人で作られた自律システムは、外部レビューなしで信頼できるのか」です。私の現時点の答え：はい。ただし、チームなら社会的に強制するような分離を、アーキテクチャが強制する場合に限ります。システムに嘘をつきにくくすればするほど、嘘の量は減ります。同様の問題に取り組んでいる人がいれば、実装の詳細を議論したり、具体的なパターンを共有したりするのは大歓迎です。
[link] [comments]
