baseline.json 中 为什么 Q001的mrr 是0.5，rag存在哪些问题？
cline 回答
Q001 MRR=0.5 的原因：
- MRR = 1/排名位置，Q001 的 mrr=0.5 说明正确答案在第2位（1/2=0.5）
- recall_at_3=1.0 说明正确答案被召回了，只是排序不够精准
- top1 返回的是”RAG基础介绍”，而不是具体的”分块参数建议”，存在语义漂移
RAG 存在的主要问题：
- 检索质量问题：向量相似≠内容相关，top1 是通用概念文档，不是精确答案
- 语义漂移：检索到的是包含关键词的文档，而非回答用户具体问题的内容
- 分块过大：chunk 包含整篇文档开头，而非聚焦在”分块策略”这个知识点
- 排序问题：recall 满分但 MRR 不高，说明排序(ranking)需要优化
改进方向：缩小 chunk 大小、添加 rerank 步骤、混合检索
claude 回答
001 MRR=0.5 的原因： 答案排在了 rank 2，不是 rank 1。
Query : “RAG 的分块推荐用多大？overlap 比例是多少？” Top-1 : “RAG系统架构与工程实践指南 一、什么是RAG …” ← 答案不在这里 Top-2 : “推荐分块大小在200到500个字符之间…” ← 答案在这里
Query 里有”RAG”，而介绍 RAG 定义的 chunk 全篇都在说 RAG，向量相似度反而最高——它把主题词的语义相似误当成了问题的答案相关。
这暴露了三个 RAG 的真实问题：
① 主题词干扰 高频词（RAG）主导了向量方向。查询里带着主题词，全库含这个词的 chunk 都得高分，淹没了真正有答案的 chunk。根本原因是 embedding 模型在语料层面把”RAG”当做强信号。
② 向量检索不区分”关于X”和”X的子问题答案” “RAG 的分块推荐多大”和”什么是 RAG”的向量距离很近——都在 RAG 的语义空间里。但前者是在问一个具体参数，后者是概述。向量检索无法区分这个意图层级的差异。
③ 精确词被忽略 “overlap”、“200到500字符”、“10%到20%“这些精确词如果用 BM25 来查，会直接命中答案 chunk。这正是 v5 混合检索要补的短板——向量擅长语义，BM25 擅长精确词匹配，两者不可互相替代。
延伸： 这个 case 在真实生产里很常见，表现为”用户问了很具体的问题，RAG 却给出了笼统的介绍性内容”。修复方向：混合检索（v5）+ Query 改写（v6：把”RAG 的分块推荐多大”改写成”分块大小 推荐 字符数 overlap”，剥离主题词干扰）。