Skip to content

docs(logs): add Log 10 for retrieval baseline and candidate store (2026-06-18)

赵烜熠 requested to merge zxy into main

📝 变更概述 (Overview)

本次提交属于文档更新，主要归档“灵枢”项目的第十篇开发日志（Log 10）。

在前一阶段完成轻量 Commit 采集脚本解析规则修正与测试用例设计后，本阶段继续围绕原型系统中的检索模块进行整理，重点梳理当前 retrieval 模块的职责、内置候选补丁库结构、规则化召回打分逻辑，以及后续与真实 JSONL commit 数据、BM25 和 Milvus 向量检索之间的衔接关系。

当前官方 benchmark 仍未发布，因此本阶段仍以检索基线梳理和接口稳定性记录为主，暂不涉及真实百万级 commit 入库、Milvus 向量索引构建或 Top-3 命中率评测。

🔍 详细变更列表 (Changes)

1. 归档 Log 10：检索基线与内置候选库整理

新增第十篇开发日志，记录当前原型系统中检索模块的阶段性设计与作用，主要包括：

  • 梳理 retrieval 模块在整体 pipeline 中的位置；
  • 明确当前检索模块仍属于原型阶段的规则化召回基线；
  • 整理内置候选补丁库的字段结构；
  • 说明候选补丁字段与未来真实 upstream commit 字段之间的映射关系；
  • 分析当前规则化打分逻辑；
  • 梳理 retrieval、rerank 和 advisor 模块之间的输入输出关系。

2. 整理内置候选补丁库字段

本阶段对当前内置候选补丁对象进行了整理，主要关注以下字段：

  • commit_id：候选补丁提交编号；
  • title：补丁标题；
  • subsystem：补丁所属内核子系统；
  • summary：补丁修复逻辑简述；
  • stable：是否具有 stable 回合信号；
  • score：检索阶段生成的基础相关性分数。

这些字段为后续将内置候选库替换为真实 JSONL commit 数据提供了基础映射关系。

3. 梳理规则化召回打分逻辑

日志中记录了当前检索基线主要考虑的几类打分因素：

  • 故障假说与补丁标题、摘要之间的关键词重叠；
  • 故障特征中的子系统与候选补丁子系统是否匹配；
  • BUG、PANIC、OOPS 等基础错误签名与补丁描述之间的关系；
  • Cc: stable 等 stable 信号对候选补丁排序的辅助加权作用。

当前打分逻辑主要用于原型流程验证和后续对照实验，不作为最终检索方案。

4. 明确与 JSON Schema 和 Commit JSONL 的衔接关系

本阶段进一步梳理了当前 retrieval 字段与前期 Schema 设计之间的对应关系，并提出后续将轻量 Commit 采集脚本输出的 JSONL 数据接入检索模块的初步思路：

  • 读取 ingest_commits.py 输出的 JSONL；
  • 将每条记录转换为候选补丁对象；
  • 在字段缺失时使用默认值；
  • 复用当前规则化检索逻辑进行排序；
  • 将候选结果继续传递给 rerank 和 advisor 模块。

5. 明确当前检索基线的局限

日志中同时记录了当前阶段存在的问题：

  • 候选补丁库仍然是内置样例，数据规模较小；
  • 规则化打分无法真正理解宕机现象与补丁修复逻辑之间的深层语义关系；
  • 候选补丁字段仍缺少真实 diff、修改文件、修改函数和版本范围等信息；
  • 当前检索效果尚未经过官方 benchmark 验证；
  • 尚未接入真实 JSONL commit 数据和 Milvus 向量检索。

📂 日志归档位置

新增日志已归档至：

  • docs/logs/2026-06-18-log10-retrieval-baseline-candidate-store.md

📌 后续计划

下一阶段将围绕规则化重排与 Top-3 可解释输出继续推进，重点包括：

  • 梳理当前 rerank 模块；
  • 分析候选补丁从召回阶段进入重排阶段的接口；
  • 整理规则化重排器的排序依据；
  • 梳理 Top-N 候选结果到 Top-3 推荐结果的压缩流程；
  • 分析 advisor 模块如何生成推荐理由；
  • 明确推荐理由中应包含的函数、子系统、错误类型和 stable 信号；
  • 为后续接入真实候选补丁和更复杂重排模型做好准备。

注：本次合并仅涉及 docs/logs/ 目录下的开发日志归档，不包含业务逻辑代码修改。

Merge request reports