ChurnBench：変更台帳により鮮度エラーと推論エラーを分離する

本番環境では、エージェント型システムは複数の場所に存在し絶えず変化するデータに対して質問に答える。既存の検索ベンチマークはデータを固定するため、エージェントが正しい箇所を見つけたかどうかしか問えず、その回答が今も正しいかどうかは問えない。昨日の価格や退職したユーザーの権限を引用するエージェントは、推論を誤るエージェントと見分けがつかない。

ChurnBenchはベンチマークを時間を軸に再構築する。4つのソースからなる企業データファブリックをスナップショットではなくタイムラインとして生成し、すべての変更を追記専用のグラウンドトゥルース台帳に書き込み、正解をライブのストアではなくその台帳から計算する。グラウンドトゥルースは報告されるすべてのケースについて両方のタイムスタンプで解決されるため、取得時には正しかったが評価時には誤っている回答は検出され、推論エラーとは別に鮮度エラーとしてラベル付けされる。

この計測器は直感に反する発見をもたらした。システムがスケジュールに従って更新する場合、キャッシュの経過時間は陳腐化を予測しない。キャッシュ経過時間1日、14日、28日のいずれにおいても、鮮度エラーはそれぞれ7、4、4であった。これはスケジュールされた更新がtime-to-liveによって陳腐化を抑え、どの観測期間でもTTLの失効が観測されなかったためである。制御されたアブレーションがこのメカニズムを裏付ける。段階的更新を無効化すると、28日時点で鮮度エラーは4から45に増加する一方、1日時点では同一のままである。

システム構築者への結論は次のとおりである。ドリフトのベンチマークが掃引すべき変数は、ドリフト窓の長さではなく、各エンティティの変化率に対するTTL設定である。

すべての事実を追記専用台帳に記録し、両方のタイムスタンプで正解を解決する

回答は、そのデータを取得した時点では正しくても、使用される時点では誤っていることがある。固定されたベンチマークではその違いを見分けられない。

正解を追記専用台帳から計算することで、「両端で真であったか」を仮定ではなく検証可能にできる。

鮮度エラーと推論エラーを分離することで、デバッグの焦点がモデルではなく更新ポリシーに向く。

スケジュールされた更新はtime-to-liveによって陳腐化を抑えるため、キャッシュの経過時間は重要でなくなる。

アブレーションがメカニズムを切り分ける。段階的更新を除去すると、28日時点で鮮度エラーは4から45に増加する。

システムの下でデータが変化する場合、取得時点と評価時点の両方で正しさを採点し、キャッシュの経過時間ではなく各エンティティの変化率に応じて更新を調整すべきである。

ChurnBench、評価ハーネス、およびすべてのエラー別データがオープンソースとして公開された。論文は2026年9月10日にarXivに投稿され、2026年9月20日に改訂された。