2026 年 6 月 28 日 | idea_world

今天的目标是决定在多种搜索/验证方案中选择哪条路线
- 在保持 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 是否与当前代码 chunk 直接对应
- 接下来的验证计划使用 Qwen 对每个表 docs_chunks、api_mapping、label_prototypes 各抽取 50 条进行测试
- 在每个表中取约 50 条样本，分别放入相关案例和不相关案例，观察应返回 是 的案例和应返回 否 的案例的响应如何分布
- 这项测试不仅检查搜索是否成功，还要确认 Qwen direct‑evidence validator 是否认可或废弃检索到的 JSONL 作为代码 chunk 的直接依据
- 手工进行时发现实际需要测试的量比预想的要大得多
- 已经制作了 50 条 Godot 测试项，每项都需要检查 docs_chunks、api_mapping、label_prototypes 三个表
- 对于公共函数/语法，先创建一个 Godot 代码 chunk，然后生成 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 代码时，因公共字符串或迁移依据仍可能得到 是，反之使用 Godot 4 的 JSONL 检查 Godot 3 代码时，若出现 source/target 字符串混杂，结果也可能变得模糊
- 因此从下一个测试起，不仅要看 6 条响应是否为 是/否，还要先区分是公共语法还是版本差异，再将 JSONL 生成基准版本 与 检查代码版本 分离记录原始响应，这将成为新的策略
- 在此过程中，发现不仅要修改验证提示词，还需要同步调整提示策略和数据集收集策略
- 今后在生成 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