Mozilla HacksのTeaching machines to triage Firefox bugsを読みました。Firefoxに日々届く大量のBugzillaチケットを、機械学習で適切なproduct/componentへ振り分ける bugbug の初期導入を紹介する記事です。
バグ報告は、開発者の目に届いて初めて修正へ進みます。ただし、Mozilla規模では毎日多くの報告や機能要望が届き、すべてを人手で正確に分類するのは難しくなります。この記事は、その最初の分類を機械に補助させることで、トリアージ担当者と開発者の時間を取り戻そうとする話です。
記事の要点
- bugbugは、新しく登録された未分類バグに対して、適切なproduct/componentを自動で割り当てる機械学習ツールです。
- 学習データには、過去20年分のBugzillaデータのうち、Mozillianがレビューして分類済みのバグが使われています。
- 運用時には、バグが最初に登録された時点まで履歴を巻き戻し、後から追加された情報を学習に混ぜないようにしています。
- 入力特徴量には、タイトル、最初のコメント、キーワード、フラグなどが使われ、モデルにはXGBoostが使われています。
- モデルは常に分類を実行するのではなく、十分に自信があるときだけ割り当てます。記事時点では60%のconfidence thresholdが使われています。
- 2019年2月末の本番投入後、記事時点で約350件のバグをトリアージし、開発者が動き始めるまでの中央値は2日と説明されています。
参照リンクから見えたこと
記事中のbugbugリポジトリを見ると、現在のbugbugは単なるcomponent分類器ではなく、test selection、defect prediction、regression検出、QA要否、spam判定など、ソフトウェアエンジニアリング向け機械学習の基盤として広がっています。前回紹介したFirefox CIのテスト選択も、この系譜の上にあります。
関連リンクのMarco Castelluccio氏の記事では、Bugzilla上の「bug report」と「feature request」を見分ける取り組みが紹介されています。これは、単に担当componentを当てる前段として、そもそもチケットの性質を理解する必要があることを示しています。
また、BugzillaやXGBoostへのリンクも確認しました。ここで面白いのは、最新の巨大モデルではなく、既存の構造化データとテキスト特徴量を使った実務的な分類器で十分に価値を出している点です。
気づき
今回の気づきは、bugbugが「人間の判断を置き換えるAI」ではなく、「自信がある範囲だけ先に動かす仕分け係」として設計されていることです。60%のしきい値を置き、誤分類を抑えながら、明らかなものだけ早く担当者へ渡す。この控えめな自動化だからこそ、トリアージの現場に入れやすかったのだと思います。
コメントを残す