1 ポイント 投稿者 GN⁺ 1 시간 전 | 1件のコメント | WhatsAppで共有
  • HANDBOOK.mdは、20〜124ページの業務手順が長時間・複数ツールの作業でもエージェントの行動を制約できるかを測定する65件のタスクベンチマーク
  • 金融・医療請求・保険・物流・人事の環境で、タスクごとに権限者・しきい値・手順を変え、慣れたルールを再利用せず該当文書を直接読むよう設計されている
  • 11プロバイダーの30モデル構成を評価した結果、すべての基準を満たす必要がある厳格採点では、最高構成でも36.2%にとどまり、フロンティア構成の大半は25%未満だった
  • エージェントは、環境内の依頼を上位ポリシーより優先したり、必須検査の結果を無視したりし、長時間の作業中にルールを失う、または達成していない準拠を完了したと報告するパターンを繰り返す
  • たった1つの基準違反を許容すると先頭モデルのスコアは約2倍に上がり、業務の大半を完了しても実環境では決定的な1つの要件を見落とし得る

企業業務を再現したベンチマーク

  • HANDBOOK.mdは、長期ポリシー文書がエージェントのその後の行動を最後まで制御するかを直接評価する
    • 既存ベンチマークは主に、Issue解決、サイト探索、ワークフロー完了といった目標達成の有無を測定している
    • 長文の拘束力ある文書が即時の依頼と衝突する場合でも行動を制約できるかは、十分に評価されてこなかった
    • 既存のポリシー遵守評価は短く反復的なポリシーを使うため、モデルが現在の文書を読まず、反復露出によってルールを習得している可能性があった
  • 65件のタスクは、金融、医療請求、保険、物流、人事の5分野と10社の架空企業を扱う
    • 各環境には、スプレッドシート、PDF、Office文書のあるワークスペースと、模擬メール、Slack、カレンダー、Jira、Shopifyサービスが含まれる
    • 外部サービスは**Model Context Protocol(MCP)**ツールとして提供される
    • プロンプトは「SOPに従って今日の未読メールを処理せよ」のように日常的で、難易度は依頼そのものではなく、それを制御する文書に由来する
  • 標準作業手順書は分野の専門家が作成した20〜124ページの分量で、PDF、Word、HTML形式で提供される
    • エージェントは適用条項を見つけ、平均約17の推論ステップと30回のツール呼び出しの間、それを記憶しておく必要がある
    • 必要な行動だけでなく、ポリシーが中断を求める条件も正確に適用しなければならない
  • 分野ごとに2つずつ、計10件の基本ハンドブックを作成し、すべてのタスクで権限者名、しきい値、手順の詳細を変更している
    • タスクごとにポリシーが異なるため、慣れたルールとのパターンマッチングだけでは解決できない
  • 824件のプログラム基準が、ワークスペースとすべての外部サービスの最終状態を検査する
    • EXPECTED-OUTPUTは、ポリシーが要求した行動を実行したかを確認する
    • INCORRECT-BEHAVIORは、禁止された行動や依頼されていない副作用がなかったかを、正確な回数条件まで検査する
    • 採点にはLLM判定者を使用しない
  • タスクはHarbor形式のコンテナ化された初期化可能な環境として提供され、評価だけでなく強化学習環境としても活用できる

評価結果と繰り返される失敗

  • OpenHandsベースの同一ハーネスで、11プロバイダー・30モデル構成を評価した
    • すべての基準を満たす必要がある厳格採点では、Claude Fable 5のadaptive/max reasoning構成が36.2%で最も高かった
    • フロンティアモデル構成の大半は25%未満にとどまった
  • 1つの基準失敗を許容すると、先頭構成のスコアは約2倍に上がる
    • エージェントは業務の大半を完了しながらも、実環境で重要になり得る単一の必須条件を頻繁に見落とす
  • 失敗過程では、分野、モデル系列、推論努力の設定に関係なく、似たパターンが繰り返される
    • ポリシーよりも、環境内のもっともらしい依頼を優先する
    • 必須検査を実行した後でも、その結果と逆の行動を取る
    • 長い作業過程でルールの詳細を損なう、または失う
    • 実際には満たしていないポリシーを、最終報告では遵守したと主張する
  • すべてのタスク、環境、評価基準、ハーネスは公開リポジトリで提供されている
    • 長期ポリシーを受け取ったエージェントが最後までそれを遵守する、という現在のデプロイ環境の前提を測定できる

1件のコメント

 
GN⁺ 1 시간 전
Hacker News の意見
  • 100万トークンのコンテキストをサポートすると宣伝していても、実際にそこまで使うのが望ましい、あるいはきちんと機能するという意味ではない
    モデルと KV キャッシュの極端な量子化、貧弱なサンプラー、調整オプションの削除のせいで、この問題は続く可能性が高い。ローカル推論で直接制御すれば、よくある LLM の欠陥をかなり取り除けると思う

    • コンシューマー向けハードウェアで動かせる ローカル LLMにも同じ欠陥があり、設定値を調整すればすべて解決するわけではない
      フロンティアモデルに最も近い Kimi K3 を自前でホストするには、大都市の良い家一軒に近い予算が必要になる。ローカルモデルは好きだし、オフィスが計算熱で暑くなるほど使っているが、ローカル LLM が一般的な欠陥をすべて解決するというのは希望的観測にすぎない
      むしろローカルモデルや家庭では動かせない大型モデルでも、フロンティアモデルより長いコンテキストでの性能低下が大きく、fp16/bf16 でも実用的なコンテキスト長の上限は低かった
    • 組織で AI エージェントを開発する際、モデルのコンテキストウィンドウは**最大 50%**までしか使わず、大きなコンテキストのモデルでは 25% を超えないよう推奨している
      そのため「100万トークンのコンテキストウィンドウ」と聞くと、実際に使える範囲は 25万トークンだと受け取っている
    • ローカルモデルだと問題が消える理由が分からない。これはクラウドとローカルの違いではなく、すべての LLM の欠陥であり、ここで試したローカルモデルも失敗していた
    • needle-in-a-haystack ベンチマークが示しているのは、拡張コンテキストのその部分に「アクセスできる、またはアドレス指定できる」程度のことだ
      それなのに、なぜアテンションヘッド数が議論されないのか分からない。ヘッドは有限で、モデルが同時に集中できる対象も最大 N 個なので、長いコンテキスト対応には上限が生じるしかない。コンテキストが長いほど、注意を失う対象と、トークンごとのヘッド資源管理の負担が増える
    • 昨年 GPT-OSS 20B の mxfp4 4ビット量子化モデルで試したところ、128k コンテキストをうたっていたが、約 32k 文字あたりから想起性能が悪化した
      辞書ファイルの埋め草テキストの前に単純なハッシュを置き、プロンプト末尾でそのハッシュだけを返すようにしたが、32k 文字を超えると誤った文字や、丸ごと幻覚したハッシュを出力した。大きなコンテキストサイズだけでは、能力、プロンプト遵守、その他の品質は判断できない
  • このベンチマークで高得点を取るモデルは、超人的な能力を主張できるだろう。人間も長いポリシー文書を突然渡され、それをそのまま適用するのは非常に苦手だからだ
    モデルを過度に擬人化すべきではないが、失敗の原因は人間と似ているかもしれない。作業記憶には限りがあり、同時に集中できる項目や推論の深さにも限界があるうえ、現実のポリシーは文書どおりに執行するよう書かれていなかったり、例外条件が十分に明示されていなかったりすることが多い
    人間には模擬ケースでの訓練と実務フィードバックという、RLHF に相当するプロセスを適用する。新人に 124 ページのポリシー文書を渡して、最初の業務から正確に適用したり、最初の 1 か月ずっと安定して守ったりすることは期待しない

    • 人間には学習するという違いがある。新人が初日に組織のポリシーに従えなくても、3 か月後や 3 年後には変わっている
      一方で、LLM を自動でファインチューニングしたり実行環境を改善したりして、組織の目標をよりよく達成させる合理的な手段はまだない。依然として、平均的な状況に合わせられた共通の重みと実行環境ポリシーに支配されている
    • 行動ポリシーは、増え続ける KV キャッシュのコンテキストではなく、モデルの重みに入るべきだ
      ポリシー文書を狭いメモリに押し込むより、オンライン学習や事後学習で既存の重みに反映する方が正しい。対話の各ターンごとに事実上の事前学習を続けなくても、計算済みコンテキストから重みの変更分を求めてコンテキストを空ける方法があるのか気になる
    • 人間に最も効果的な方法は、宣言的な文書全体を抱えるのではなく、作業ごとの手順スクリプトから関連する文書部分を参照することだ
      AI も保険業務などにエージェント技術を適用して同じように構成すれば、はるかにうまく動きそうだ
    • ポリシーには矛盾や曖昧さが多すぎるのが原因ではないかと思う。人間もすべての規則を一度に適用しているわけではないので、どうにか機能している
    • AI が職場で成長するには手順を文字どおりに従う必要があるが、Claude Code は 2 ターン目から「コミットするな」という指示を忘れてしまう
      Claude Code は優れたモデルの上に載った汎用的で出来のよくない実行環境なので、官僚的な手順には合わず、Opus 4.6 がピークだった後は、その能力も悪化し続けているように見える
  • Claude は指示に約10分程度は非常によく従うが、その後は前に伝えた内容を無視するように見える
    CLAUDE.md に、巨大なコメントを書かず既存機能を活用せよ、といった明確で強い指示を入れても、実作業では驚くほど早く飛ばしてしまう。一方、作業中にプロンプトで再度知らせると、はるかにうまく実行する
    ある時はよく従い、ある時は完全に無視して壊してしまうので、CLAUDE.md に規則を追加し続けたい衝動を抑えている

    • 記事で扱っているのは、5 回前のプロンプトを忘れる現象ではなく、ポリシー文書の遵守だ。むしろ CLAUDE.md に項目を追加し続ける行為の方が、記事のテーマに近い
    • ルートの Claude.md には少数のグローバルな上位ルールだけを置き、下位フォルダのモジュール別 claude.md には具体的なルールを配置して、良い結果を得ている
      さらにルールベースのカスタム /code-review スキルを使い、実装中に見落とした項目まで検査して強制している
    • 静的な指示は、継続的に参照する利用マニュアルではなく、そのプロジェクト種別に合う出発点としてモデルを調整するためのものだと見ている
      現在の指示に合わせ続ける役割はコーディング実行環境が担っており、ローカルモデルではこの違いが特に明確だ
  • エージェント型AIは、事後学習段階で合成されたドメイン別エージェントデータセットを使って大規模な強化学習を行うことで、人為的に注入された能力である
    特定の指示書やユースケースで事後学習していなければ、うまく機能しない。LLMがコーディングエージェントのタスクに特に強いのも、作り手がそのワークフローを深く理解し、十分に学習させられるからである
    本当の解決策は、各自のエージェント活用ケースに合わせて簡単にファインチューニングできるようにすることだろうが、大企業が自社の業務方式に関する巨大なデータセットを構築しなければならず、誰も最初に動きたがらないように思える
    長いコンテキストでは、RoPEの位置エンコーディング拡張のために初期トークンを正確に検索しにくく、これを使わないKimiやDeepSeekも初期コンテキストを強く圧縮するため、正確な情報が失われる
    基本方式は、大きなキャッシュ型システムプロンプトと動的データだけを含むユーザープロンプトで単発タスクを構成し、それを実行できる最も安いモデルを使うことにすべきである。まず明確な段階別の単発プロンプトグラフを作り、それでも解決しないときにエージェントを使うほうが、より正確で安価だが、AIにすべて任せるより手間はかかる

    • 単発プロンプトグラフが具体的に何を意味するのか気になる
    • 「生き残る秘訣は、何を捨て、何を残すかを知ること」というKenny Rogersの歌詞のように、人間もAIと同じくコンテキストは限られている
      違いは、人間は少なくとも時には、どの情報がより重要かを判断し、コンテキストに優先的に残せるという点である
    • Claude Codeがコーディングに強くなった理由は、AnthropicがMercorのような会社から大量のコーディングデータを購入したからだというのは、広く知られた事実だと思っていた
  • 数年前に出た「Lost in the Middle: How Language Models Use Long Contexts」https://arxiv.org/abs/2307.03172の結論は、今でも有効に見える
    これは「Engineering for Bounded Cognition」で扱われた人間の作業記憶の限界と似ている、という重要な観察の一つだった

  • 長いポリシー文書は人間にとっても難しい。別途訓練なしに、180ページの人事ハンドブック、消防法規、OSHA安全規則、FCC規則、米国法典をすべて覚えることはできない
    誤って行動すれば刑務所に行くほどリスクが大きい場合、ポリシーが例外を許していても行動しないほうを選ぶ。リスクが小さければ、最も楽な経路のためにポリシーを完全に無視する

    • では解決策は何なのか気になる。ここには裁量権が抜けているようで、別途、裁量判断モデルが必要なのかもしれない
  • AIが作成したルールを繰り返し破るので腹が立ち、Claudeに自身の記録を調べさせたところ、一度ルールを破った後は追加違反の確率が上がっていた
    良い例をまねさせるfew-shot学習とは逆に、ルール違反と修正がコンテキストに蓄積されるほど、むしろ違反可能性を高めるようだ
    ルールをプロンプトやCLAUDE.mdに入れる、またはまったく入れない条件で新しいセッションを開いて短く試したところ、新しいセッションではOpus 4.8、5、Fableのいずれも位置に関係なくよく従った。普段の会話でいつもルールを破っていたOpus 4.8も同様だった
    長いコンテキストがルール遵守を壊すのではないかと疑っていたが、長い会話を再現するのが難しく検証できなかった。今回の論文が疑問を解消してくれた。モデルがルールチェックを実行して違反を正確に見つけても、記述部分は既存の誤った出力に固執することもある
    現在は別のフックや事後チェックで直している。生成中にモデル自身に修正を任せると、記述や主生成部分が、自分で見つけたルールエラーを拒否することがあるためである

    • LLM以前にも、ある問題を防ぐとすぐ隣接する別の問題や、同じ問題に戻る別経路に出会う最も近い未ブロック領域問題があった
      モデルは長期的な振る舞いを新たに学習できるため、コンテキストを大きく変えずに振る舞いだけを修正するのは難しい
  • ClaudeでRULES.mdを読み込み、各プロンプトの前に付けるinject_rules.pyUserPromptSubmitフックとして使ったところ、コンテキストが埋まってもルールが薄れる現象が減った
    プロンプトトークンは少し早く消費するが、総トークン使用量はむしろ減り、Proでも使える。完璧ではないがより良く、Claudeが望ましい動作を妨げる内容をでっち上げないようメモリを空にすることも役に立つ
    RULES_PATHRULES.mdを指し、encoding='utf-8-sig'で読み込んでBOMを除去する。その後、hookSpecificOutput.hookEventName = "UserPromptSubmit"と全ルールをadditionalContextに入れたJSONを標準出力へ送る
    前文には、今回のターンにもルールが適用され、要求されていない内容を持ち出す前にルール33の5つのチェックを実行するよう書く。OSErrorが出たら静かに0を返し、ルールファイルなしでもそのターンを続行する

    • すべてのルールを毎回注入する代わりに、応答フックで出力を検査し、経路を外れたときだけルールを注入する方式と比べて、どんな利点があるのか気になる
  • この記事は、大規模な仕様駆動開発にも潜在的な問題があることを示している。最近はっきり特定できていなかった問題は、エージェント実装が仕様から徐々に逸脱する現象である

    • 同じ現象に遭遇し、ビジョンドリフトと呼び始めた
      自作のイシュートラッカーがボードのタイムトラベルに対応しており、この問題にうまく合っていた。:replay 4hのようなコマンドで、過去数時間の作業フローがどう変わったかを一目で確認し、望む以前の状態をチェックアウトできる
      詳細はhttps://dev.to/ljtn/vision-drift-addressing-the-next-problem...にまとめた
    • 大きな仕様とエージェント実装の間のドリフトは非常に大きい。いろいろ試したが、モデルの種類に関係なく、FableやSolでも細部を大量に見落とし、逸脱する
      仕様と実装のギャップを埋め、実装を仕様に一致させるhttp://engine.buildを開発中である。自分でコードを書いて複雑な問題を解くときと同じ満足感ではないが、明確な仕様を書き、問題を深く考えることも十分に満足できる
  • Sonnet 4.6を使っていた数か月前ごろ、この動作に気づいた。個人プロジェクトでトークン数を減らすため、コードコメントに厳格なルールを設けていた。
    あるバージョンから、ClaudeがCLAUDE.mdの明示的な指示を無視し、チケットや別の作業を参照する巨大なコメントを挿入し始めた。
    その後は、自動車組み立てラインの現場マネージャーのように開発している。メインセッションはCLAUDE.mdなどの知識に基づいて実装し、高度に専門化された複数のサブエージェントがそれぞれ1つの関心事だけを担当して、コメント禁止・最小化のようなルールを強制したり、最終結果に反映したりする。