再現性の低いバグを確率で追い詰める！ベイズ推定版git bisect「Git bayesect」が登場

Hacker Newsで、再現が不安定な（ノンデターミニスティックな）バグの原因コミットを特定する新ツール「Git bayesect」が公開されました。通常のgit bisectは二分探索を用いて「成功か失敗か」を明確に判断しますが、Git bayesectはベイズ推定を活用。100%再現しない「たまにしか起きないバグ」に対しても、統計的に怪しいコミットを効率よく絞り込めます。Flaky Test（不安定なテスト）に悩まされているエンジニア必見のツールです。

git bisectはリグレッションの特定には最高だけど、バグが決定論的に再現することに依存しているんだよね。でも、もしバグが非決定論的だったらどうする？あるいはもっと悪いことに、元々ずっと非決定論的だった挙動が、例えばテストの不安定さが「時々」から「頻繁に」に変わったせいで顕在化したら？タイトルにあるリポジトリに加えて、その背後にある数学についても少し書き留めてみたよ： https://hauntsaninja.github.io/git_bayesect.html

これすごく面白いし、数学的に納得感があるな。技術的には決定論的なバグでも、正確な再現手順がないような厄介なケースでも役立ちそう。単なるパス/フェイルじゃなくて、同じテストを複数回実行してコミットごとの確率を出すような使い方はサポートしてる？Beta分布を適切に更新するためには、試行回数も考慮に入れる必要があるよね。

最高にクール！最近、パフォーマンスのリグレッションをbisectしようとしたんだけど、ベンチマーク自体がかなりノイジーで、繰り返さないと「良い」コミットか「悪い」コミットかの判別が難しかったんだ（実際には何度も繰り返したよ）。しきい値を決めてbayesectを使えばいいんだろうけど、それだと情報が削られてしまう。各ステップで生のベンチマークスコアを渡せるように一般化するのはどれくらい大変そうかな？

LLMとのやり取りを含むテストには便利そう。

場違いな質問かもしれないけど、これの用途って何なのかな？どう役立つのか、あるいは何を証明する助けになるのか気になって。全く理解できてないんだけど、確率に関連する話だよね？純粋な興味で聞いてるんだ。編集：回答ありがとう！そもそもgit bisectのことすら知らなかったから、新しく学ぶことができて良かった。

本当に面白い試みだし、数学の解説も素晴らしい。Beta-Bernoulli共役を使って周辺尤度を閉じた形式で求めているのがエレガントだね。不安定さのレベルを変えてbisectとbayesectを比較するベンチマークを取ってみたよ。90/10の不安定さではbisectの精度が約44%まで落ちる一方で、bayesectは96%を維持した。70/30だと9%対67%になったよ。単純な二分法よりもエントロピー最小化による選択が重要だね。あと、コード構造を使って事前分布を重み付けすると、精度がさらに10〜15%向上することがわかった。呼び出しグラフで多くの推移的依存関係を持つような密接に関連した関数を変更するコミットは、孤立したコードを触るコミットよりも犯人である可能性が高いからね。この事前分布の計算はタダだし、テスト実行も不要だよ。情報理論的に言うと、構造的事前分布を使えばテストを実行する前にI_priorビット分の情報が得られるから、必要なテスト総数をlog2(n)/D_KLから(log2(n) - I_prior)/D_KLまで減らせる。1024コミットのリポジトリで80/20の不安定さの場合、グラフ事前分布ありで精度92%、純粋なbayesectで85%、git bisectで10%という結果だった。今、これをsem (https://github.com/ataraxy-labs/sem) というツールに組み込んでいるところだよ。これには構造的なシグナルを提供してくれるエンティティ依存関係グラフがあるんだ。

結果に対する確信度がどのくらいか確認できるように、事後確率をどこかで公開したりはしないの？

このツールは、「あるコミットを1回テストする」のと「あるコミットを2回テストする」のが同じコスト（時間）だと想定しているのかな？インタープリタ言語ならそうかもしれないけど、LLVMのコンパイルに15分待つような環境なら、1秒で終わる不安定なテストを何度も繰り返すほうがいいと思う。修正は簡単そうだけどどうだろう？いずれにせよ素晴らしいアイデアだね！

テストのみを変更するコミットのケースは、事前分布の扱いで興味深いエッジケースだね。不安定性のリグレッションをbisectしている時、実はテストファイルのみを触っているコミットが真の犯人（タイトなタイムアウトの検証やリトライロジックの変更など）であることはよくあるから。でも、コード変更のシグナル重視だと、それらを触っているコミットよりも低い重み付けになってしまうんだよね。