Hugging Face 介紹 relore，供程式代理追查修補與維護決策

Hugging Face 工程師於 9 月 21 日介紹開源工具 relore，將 GitHub 議題、拉取請求與審查討論整理成程式代理可查詢的專案記憶。起點是 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` 查找宣稱修復指定議題的討論；`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)

工程團隊可先固定版本，以自家已解決議題測試漏查率、過期決策與重複修補辨識，再接入自動修改流程，並保留回到原始討論核對的入口。尤其中文討論應另測斷詞與召回表現；現有文件採英文全文搜尋設定，尚不足以證明繁體中文檢索品質。這是依實作提出的驗證重點。