2026 年 6 月 28 日 - Dev Journal

今天的目标是决定在多种搜索/验证方案中选择哪条路线
- 在保持 chunkText 原样作为输入的前提下，需要判断如何组合 BM25、PostgreSQL 全文搜索、embedding、reranker、Qwen direct‑evidence validator
- 起初并未确定最终设计，而是收集了通过 ChatGPT 获得的各搜索方式的优缺点以及 是/否 响应流程作为判断材料
- 随后基于各方案的模拟和综合比较表，决定优先采用 F 策略
- F 策略是将 BM25 + embedding + reranker + Qwen direct‑evidence validator 进行串联的方式
- 即把 chunkText 直接作为搜索输入，先用 BM25 和 embedding 广泛收集候选，再用 reranker 重新排序，最后让 Qwen 验证检索到的 JSONL 是否直接对应当前代码块的依据
- 接下来的验证采用 Qwen 对每个表 docs_chunks、api_mapping、label_prototypes 各测试 50 条的方式进行
- 在每个表中取约 50 条样本，分别放入相关案例和不相关案例，观察应返回 是 的案例和应返回 否 的案例的响应如何分布
- 此测试不仅检查搜索是否成功，还要确认 Qwen direct‑evidence validator 是否将检索到的 JSONL 认可为实际代码块的直接依据或予以废弃
- 手工进行时发现实际需要测试的量比预想的要大得多
- 已制作了 50 条 Godot 测试项，每项都需要检查 docs_chunks、api_mapping、label_prototypes 三个表
- 对于公共函数/语法，先创建一个 Godot 代码块，然后生成 docs_chunks 期望 是/否 数据、api_mapping 期望 是/否 数据、label_prototypes 期望 是/否 数据，随后将提示词 + 测试代码 + 6 条数据放入，观察响应模式的变化
- 若不是公共函数，则需要分别制作 Godot 3 和 Godot 4 的代码，工作量几乎翻倍
- 若要以后用 F1‑score 等分类指标整理结果，需要手工记录所有案例的 true/false 结果
- 因此判断在一天内完成全部 50 条几乎不可能，今天的目标缩减为 5 条 并进行
- 完成 5 条后，决定不再单纯增加测试数量，而是先分析已有的 是/否 响应模式再继续
- 实际上已在 50 条中完成了 5 条
- 即使只做了 5 条，也发现基于 Godot 3 的 JSONL 与基于 Godot 4 的 JSONL 的响应流程出现了差异
- 特别是版本差异的代码，使用 Godot 3 的 JSONL 检查 Godot 4 代码时，因公共字符串或迁移依据仍可能得到 是，反之亦然，若 source/target 字符串混杂，结果会变得模糊
- 因此从下一个测试起，需要先区分是公共语法还是版本差异，再将 JSONL 生成基准版本 与 检查代码版本 分离记录原始响应，而不是仅看 6 条响应是否为 是/否
- 这过程表明不仅要修改验证提示词，还需同步调整提示策略和数据集收集策略
- 今后在生成 JSONL 时，需要更细致地划分收集/生成标准，避免公共语法、Godot 3 专用依据、Godot 4 专用依据、双向迁移依据混在一起
- 同时官方文档的 Markdown → JSONL 转换仍在进行，截至今天整体 1,570 条 Markdown 中约有 600 条已转为 JSONL
- 测试记录文档: Qwen Godot 代码 JSONL 依据匹配测试检查清单
- 模式参考: Qwen 测试用 JSONL 模式与用途
- 调查备忘: Retriever 搜索方案 ChatGPT 备忘
- 供参考的拆解文档: Retriever 搜索方案拆解文档
- 各方案详细文档: A 当前 full‑text, B BM25 only, C embedding only, D BM25 + embedding, E Qwen query profile, F reranker + validator
- 回顾: docs/retrospectives/2026-06-28.md