把「同一件事的多方报道」聚成一条时间线，听起来是道相似度题，实际做下来：纯余弦区分不了「同一领域」和「同一件事」（语料两两余弦最大仅 0.706），加实体词会把 Arxiv 每日批次串成 10 条大簇，最后只能退回最保守的口径。v2 把判同交给模型，第一次评测就被教做人——模型错判时置信度同样是 0.95+，校准阈值救不了。而上线之后最反直觉的发现是：判同明明准了，缺的却是「有人跟它撞题」。
给检索链路补一条字面路（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 vs LLM Wiki + grep / Agent 自主检索」的四派立场梳理（谨慎派、混合派、场景决定论派、演进视角派）、四个辩论冲突点，以及一组可直接落地的决策框架：按更新频率、查询频率、数据规模、领域特性决定上不上 RAG。
详述 RAG（检索增强生成）的完整技术链路，包括文档入库、向量化、召回重排、Prompt 拼接，以及基于 Node.js + ChromaDB + SQLite 的三层混合记忆进阶方案。