Hugging Face、コーディングエージェントが修正・保守の判断経緯をたどるツール「relore」を紹介

Hugging Face のエンジニアは9月21日、GitHub の Issue、プルリクエスト、レビューの議論を、コーディングエージェントが検索できるプロジェクトの記憶として整理するオープンソースツール「relore」を紹介した。きっかけは Transformers でのデバッグだった。エージェントがコードを変更しようとしていたとき、実際には別のコントリビューターがすでに修正を提案していたが、関連する議論が複数のページに分散していた。このツールは、エージェントが進行中の作業や過去の決定を先に見つけ、そのうえで次の行動を判断できるようにすることを目指す。[公式紹介](https://huggingface.co/blog/huggingface/relore-repository-memory)

検索の中核には PostgreSQL の全文検索を採用し、議論からエラーメッセージ、ファイルパス、シンボル、テスト識別子も抽出して、厳密な絞り込みを可能にする。クエリを複数の検索経路に分解し、結果を統合して順位付けする仕組みだ。現時点ではベクトル埋め込みを使用していないため、共通のキーワードを含まない同義の言い換えは検索で取りこぼす可能性がある。[検索の仕組み](https://github.com/huggingface/relore/blob/main/docs/how-search-works.md)

もう一つの設計上の特徴は、投稿者の属性を保持することだ。リポジトリへの書き込み権限を持つユーザー、一般のコントリビューター、ボットを異なる信頼レベルに分類し、デフォルトの検索結果から機械生成コンテンツを除外する。これにより、エージェントが自らの過去の推測を再び証拠として扱う可能性を抑える。ただし、権限が示すのは情報源の属性であり、個々の技術的判断の正しさを保証するものではない。[信頼レベルの説明](https://github.com/huggingface/relore/blob/main/docs/how-search-works.md)

ワークフローでは、`inflight` が指定した Issue を修正すると表明している議論を探す。`why` はコード行を起点にコミット、プルリクエスト、その周辺のレビューコメントをたどる。`grep`、`symbol`、`copies` は、サーバー側に保持されたリポジトリのコピーを検索する。こうして過去の判断理由と現在のコードを照合できるため、特定の互換性対応が今も必要かどうかを確認するのに適している。[CLI ドキュメント](https://raw.githubusercontent.com/huggingface/relore/main/docs/cli.md)

現在公開されている成果は、主に内部での利用と限定的な評価に基づく。検索ドキュメントに掲載されたアノテーションはモデルが生成したもので、判断理由を検索する評価ケースの一部にはデータリークがあることも認めている。これを根拠に、開発効率全体が向上すると推論することはできない。導入側はインデックスの鮮度も個別に確認する必要がある。サービスのポーリングが成功していても、すべての議論が最新の状態に同期されているとは限らない。[評価の制約](https://github.com/huggingface/relore/blob/main/docs/how-search-works.md)、[プロジェクトの説明](https://github.com/huggingface/relore)

エンジニアリングチームは、まずバージョンを固定し、自社の解決済み Issue を使って、検索の取りこぼし率や、古くなった決定・重複する修正を識別できるかを検証するとよい。そのうえでコードの自動変更フローに組み込み、元の議論に戻って確認できる導線も残す。特に中国語の議論については、単語分割と再現率を別途検証する必要がある。既存のドキュメントでは英語向けの全文検索設定が使われており、繁体字中国語の検索品質を裏付けるには不十分だ。これらは実装に基づいて挙げた検証上の重点項目である。