/3,031 字/阅读约 11 分钟
修 5 坏 2,还是修 3 坏 0?——一次 55 题的多路召回实验,与两个能亲手操作的复盘页
给检索链路补一条字面路(BM25)去修专名盲区:55 题实测,两条路全程都开能多答对 5 题、但也弄坏 2 题;改成「查询点了名、且语义路确实没找到」才补路,则多答对 3 题、零回退。本文记录四配置对比、λ 的两次扫描(含一个被数据否决的方向)、以及一条必须诚实标注的「不算数的修复」,文末附两个无需后端、离线的交互式复盘页。
给检索链路补一条字面路(BM25)去修专名盲区:55 题实测,两条路全程都开能多答对 5 题、但也弄坏 2 题;改成「查询点了名、且语义路确实没找到」才补路,则多答对 3 题、零回退。本文记录四配置对比、λ 的两次扫描(含一个被数据否决的方向)、以及一条必须诚实标注的「不算数的修复」,文末附两个无需后端、离线的交互式复盘页。
把一句 RecursiveCharacterTextSplitter(1000, 200) 换成「清洗 → 画像 → 分层 → 校验 → 回退」的自适应分块器,全库 1959 → 1120 块、HTML 残留 38.3% → 0%、单篇最多块数 143 → 45。但改起来容易、证明它变好很难:A/B 显示六个检索配置全部正向,同时也让「多路召回 +11.1%」缩水到 +2.2pp——原来那部分增益是在补偿脏文本,不是互补召回。本文连同评测自身的三个陷阱(wall-clock 时间窗、judge 随机失败、n=18 时符号会翻)与一次生产语料重建的前置验证一起记录。
详述 RAG(检索增强生成)的完整技术链路,包括文档入库、向量化、召回重排、Prompt 拼接,以及基于 Node.js + ChromaDB + SQLite 的三层混合记忆进阶方案。