这是我做 RAG 项目过程中的一篇复盘。起因很简单：项目集成了 Qdrant + LangChain4j，父子分块、混合检索、流式生成都跑通了，但配置参数全是抄默认值。改一个参数对不对、要不要上 Reranker、混合检索到底有没有用——一个都答不上来。于是搭了一套评测流程，跑了一圈下来，发现收获最大的不是"优化了多少"，而是"知道哪些方向不用再投入了"。这篇文章记的是这个过程中踩过的坑、得到的几个反直觉结论，以及做完之后我对"评测"这件事的想法变化。希望对同样在转 AI 方向、手头有 RAG 项目但没系统做过评测的同行有点帮助。一、为什么要做评测：参数都是拍脑袋定的我的 RAG 项目长这样：/rag/add ParentChildSplitter(父 = chunkSize*4, 子 = chunkSize, overlap = chunkOverlap) → 子块 embedding → Qdrant(dense) → 子块 → Bm25Retriever(进程内存索引) /rag/chat RrfFusionRetriever(denseTopK + bm25TopK, rrfK=60) → Reranker(NoOpReranker) → finalTopK → 回链 parentText 去重 → LLM → { answer, citations }父子分块、混合检索（RRF 融合 dense 与 BM25）、流式生成、引用可追溯，听起来挺完整。但仔细一看配置： RAG 评测实战复盘：从拍脑袋调参到知道哪些事不用做
这是我做 RAG 项目过程中的一篇复盘。起因很简单：项目集成了 Qdrant + LangChain4j，父子分块、混合检索、流式生成都跑通了，但配置参数全是抄默认值。改一个参数对不对、要不要上 Reranker、混合检索到底有没有用——一个都答不上来。于是搭了一套评测流程，跑了一圈下来，发现收获最大的不是"优化了多少"，而是"知道哪些方向不用再投入了"。这篇文章记的是这个过程中踩过的坑、得到的几个反直觉结论，以及做完之后我对"评测"这件事的想法变化。希望对同样在转 AI 方向、手头有 RAG 项目但没系统做过评测的同行有点帮助。一、为什么要做评测：参数都是拍脑袋定的我的 RAG 项目长这样：/rag/add ParentChildSplitter(父 = chunkSize*4, 子 = chunkSize, overlap = chunkOverlap) → 子块 embedding → Qdrant(dense) → 子块 → Bm25Retriever(进程内存索引) /rag/chat RrfFusionRetriever(denseTopK + bm25TopK, rrfK=60) → Reranker(NoOpReranker) → finalTopK → 回链 parentText 去重 → LLM → { answer, citations }父子分块、混合检索（RRF 融合 dense 与 BM25）、流式生成、引用可追溯，听起来挺完整。但仔细一看配置：