Fable 5、Opus 4.8、Sonnet 4.6：如何在自己的代码上公平比较 LLM

当新模型发布时，公告回答的是「它在基准测试上好了多少」——却不回答我唯一关心的问题：它会给我的工作带来什么改变。我做了一个受控实验：三个 Claude 模型—— Fable 5、 Opus 4.8 和 Sonnet 4.6 ——拿到了逐字相同的任务：审计这个博客的代码库，各自在隔离的仓库副本中工作，并采用事先商定的评分标准。文章介绍这套可在任何项目上复现的方法论、实验结果，并单独讲述实验如何两次失败以及从中得到的教训。

为什么基准测试回答不了我的问题

公开基准测试有两个问题，且都是根本性的。第一是数据污染：测试样例渗入训练集，模型部分「记住」答案而非解题。这不是边缘化的怀疑，而是一整个研究方向的主题： Xu 等人（2024）的综述 系统梳理了基准污染研究，而 EMNLP 2025 的综述 记录了行业的回应——从静态测试转向动态生成。

第二个问题更简单：基准测试衡量的不是我的任务。我不需要一个最擅长解奥数题的模型。我需要一个能在我的 Laravel 博客中找到真实 bug、不编造不存在的 bug、并证明其修复有效的模型。

由此得出一个简单的想法：比较模型的最佳测试台是自己的项目。它的代码以这种组合不会出现在训练集中，其上的任务正是我付费要解决的，而结果我可以亲手验证，因为我熟悉这段代码。

实验设计：一个提示词，三个隔离世界

三个模型的任务逐字相同——只有分支名和结果文件夹不同。四个阶段：审计博客文章的双语系统，每条发现都要有 файл:строка 形式的证据并附代码引用；为三个主要发现选择方案并描述权衡；实现一个修复并自检；用俄语和英语写结果说明。这是完整的工程工作循环，而非孤立的「问答」——这种方法也 为 Anthropic 所推荐:在真实产品任务上按事先商定的评分标准评估智能体。

三条规则让比较变得公平：

隔离。 每个模型在单独的 git worktree 中工作——拥有自己的工作目录副本和自己的分支。模型在物理上无法看到彼此的结果或互相干扰。

在提示词本身中防幻觉。 任务的关键句：「编造的发现（不存在的代码、错误的行号）比没有发现更糟」。没有这个激励，被要求找问题的模型倾向于无论如何都「找到」问题。有了它——每条发现都必须经受人工核查。

将提示中的线索排除在计分之外。 仓库中有 CLAUDE.md，描述了项目已知的坑——例如在带语言前缀的 URL 上会失效的相对资源路径。三个模型都读这个文件，因此这类发现是「免费的」：它们计入细致度，但不计入深度。

评分标准：只评估可以亲手验证的东西

启动前我固定了六个维度，每个五分：审计准确性（按 файл:строка人工核查发现样本）、深度（提示中未提及的已确认发现）、权衡推理质量、代码与自检的真实性、俄语和英语文本质量、纪律性（零次向人提问、零次违反限制）。原则与好的代码审查相同：一个维度越少依赖品味、越多依赖可验证的事实，就越值得信任。

第一次是如何失败的

第一次运行我做错了——而这成了实验中最可迁移的部分。我在同一个仓库文件夹中并行打开了三个交互式会话。几分钟后，工作树中躺着无法归属的未提交修改：共享的 checkout 意味着当一个会话执行 git checkout -b时，三个会话的分支都会切换，它们的修改和提交混在一起。其中一个会话还执行了 git stash 并把所有东西都扫了进去——包括我自己与实验无关的文件。

“同一文件夹中的并行 AI 智能体不是并行实验。那是一个有三个作者的大冲突。”

– 让我付出重启代价的结论

2回のセッションの結果は不適格と認めざるを得なかった。たとえ最後まで仕上げたとしても、誰の修正を評価しているのか正直に言えなかっただろう。2回目の実行は、すでに分離されたworktreeで、料金プランの制限に突き当たった。2つのエージェントは起動時に落ち、3つ目はインターフェース上では「動作中」に見えたままハングした。診断を下したのはステータス表示ではなくファイルシステムだった。20分間、その作業コピーには1つのファイルも現れなかった。これが2つ目の持ち帰るべき教訓だ。エージェントの生存はディスク上の変更で確認する。再起動後、3つのモデルすべてが同等の条件で完全なサイクルを通過した。

結果：モデルが同じところと異なるところ

最も重要な結果は、起きなかったことだ： どのモデルにもハルシネーションはない。私は各モデルの3つ以上の発見を手動で確認した — すべての引用と行番号は文字単位まで正確だ。監査タスクにとってこれは主要な信頼の閾値であり、3者すべてがそれを通過した。

そこから差異が始まる：

	Fable 5	Opus 4.8	Sonnet 4.6
確認された発見	11	5	9
自明でないユニークなもの	3	1	2
修正の自己検証	一時DBでの統合レンダリング、xmllint、他人の失敗したテストの帰属	リンター＋レンダリング；自身のバグを捕捉	リンターとルート一覧のみ
トークン / 時間	164k / 21分	101k / 12分	131k / 12分
ルーブリック別の合計（30点満点）	30	24	25,5

定性的な差異はスコアより情報量が多い。 Opus 4.8 — 壊れた見出しに気づかなかった唯一のモデル Content-Type sitemap内で（他の2つは見つけた）そして自身の修正にそれを残した。さらに彼のロシア語テキストに英語の単語が漏れ込んだ —「и even путь к картинке」。 Sonnet 4.6 は正しい修正をしたが、その自己検証は宣言的なものだった：実行の代わりにリンター。 Fable 5 はまさに自己検証で際立った： php が私のマシンではメインカタログにマウントされたdockerコンテナのラッパーであることを発見し、すべてのチェックを使い捨てコンテナ経由で再構築し、自身の修正を一時DB上で統合的に実行した。「やった」と「やったことを証明した」の間の差 — これこそがエージェントタスクにおける最も差別化する軸だ。

もう1つの有用なシグナルは収束だ：3つのモデルすべてが独立に、sitemapに関する同じ問題を主要な発見として挙げた。独立した監査者がトップの発見で一致するとき、それは専門家間一致の安価な代替となる：問題はほぼ確実に実在する。

参加者の中からの審判

ルーブリックによる評価を行ったのは Fable 5 — 比較に参加したのと同じモデルだ。これは方法論上の穴であり、率直に語る必要がある：LLM審判は自身のテキストへの評価を系統的に高くつける。しかもその傾向は、モデルが自身のテキストを認識するほど強くなる — これは PanicksseryらによるNeurIPS 2024の論文で示されている。バイアスは2つの方法で緩和でき、私は両方を使った：第一に、ルーブリックを嗜好の軸から検証可能な事実へ最大限に移した — 行の正確さ、修正の完全性、漏れ込んだ外国語の単語は審判の好みに依存しない；第二に、利益相反を明示的に宣言し、争いのある軸を別のモデルや人間による相互評価に委ねた。私の総括の主観的な軸 — テキストの質、推論の質 — はこの補正を念頭に読むべきだ。

誠実性の限界

モデルごとに1回の実行はn=1だ：1〜2点の差は何の意味もなく、信頼すべきは定性的な断絶のみ — 見逃されたバグ、自己検証の深さ。実験は1つのドメインの1つのタスクで3つのモデルを測定する；「Fable 5 が全般的に優れている」はそこからは導けない。そしてコストを忘れてはならない：トップモデルは最も倹約的な参加者より1.6倍多くのトークンとほぼ2倍の時間を費やし、さらに そのトークンは定価でも それ自体も高価だ — 定常的なタスクにはこれはよりシンプルなモデルを支持する有力な論拠となる。

私が持ち帰るもの

方法論は、どのプロジェクト、どのモデルにも機能する短いチェックリストに集約された：

• テスト課題は、合成された小問題ではなく、自分のコードでの実際の作業の完全なサイクル。
• 全員に1つのプロンプト、別々のworktreeによる分離、結果は別々のブランチへ。
• プロンプトにはハルシネーションの明示的なコスト：でっち上げの発見は発見がないより悪い。
• 全員が利用できるヒント（ドキュメント、リポジトリ内のメモ）は深さの採点から除外する。
• ルーブリックは実行前に固定され、印象ではなく検証可能な事実に依拠する。
• 発見のサンプルは手で確認する；独立したモデル間でトップの発見が一致することは、それが実在するシグナルだ。
• 参加者である審判 — 宣言された利益相反：争いのある軸は相互評価に委ねる。
• エージェントの生存はインターフェースのインジケーターではなくディスクで確認する。

計画外のボーナス：実験は自ら元を取った。3つの独立した監査がブログ内に実際の問題を見つけた — 英語ページのないsitemapからコントローラー内の死んだクエリまで — そして2つの準備済みの修正がすでにブランチにあり、本番への移植を待っている。ベンチマークを読むのとは違い、自分のコードでモデルを比較することは、意見だけでなく何かを後に残す。

出典と指針

• Benchmark Data Contamination of Large Language Models: A Survey (Xu et al., 2024) — ベンチマーク汚染問題の体系化；自分のコードでのテストを支持する主要な論拠。
• データ汚染下でのLLMベンチマーク：静的評価から動的評価へ（EMNLP 2025） — 業界が静的テストから動的テストへと移行する様子。私の実験は動的テストの一例である。
• AIエージェントの評価を解き明かす（Anthropic Engineering, 2026） — エージェント評価の実践：実際の製品から取ったタスク、検証可能なルーブリック、軌跡と結果の区別。
• LLM評価者は自身の生成物を認識し好む（NeurIPS 2024） — なぜモデル審判が自分に高い評価を付けるのか、そしてそれにどう対処するか。
• worktreeで並列セッションを実行する（Claude Code Docs） — 並列エージェントセッションを分離する標準的な仕組みであり、これがなければ最初の実験実行は破綻していた。