经过两路召回和RRF融合之后，我们拿到了一个初步排序的候选列表，通常是15到20条候选结果。但RRF融合做的只是"排名的融合"，它看不到每条结果的实际内容和用户查询之间的深层语义关系。两条结果在各自召回路里排名相同，RRF就会给它们一样的融合分数，但实际上一旦仔细比对内容，其中一条可能跟用户的问题完全不相关——只是碰巧在两个列表中排到了相似的位置。这就是Rerank的用武之地。和第一阶段的双编码器

整个RAG系统做下来，最大的感受是：RAG不是一个单一的技术点，而是一个系统工程。从文档的解析、切分策略的选择、Embedding模型的选型、向量数据库的配置，到检索参数的调优、Prompt的打磨、引用系统的设计，每一个环节都影响着最终效果。切分策略这方面，固定大小加重叠虽然简单，但对语义连续性的保护不够。如果后续要提升召回质量，值得尝试的方向是按语义边界切分，或者有条件的话用父子切割——小块检索

项目开发过程中遇到的问题很多，选取几个典型问题做个总结，同类项目可以参考规避。

如果先直接问问题，模型可能会按通用聊天方式回答；如果先给它一个明确身份，例如“你是企业知识库助手，只能根据提供的资料回答”，效果通常会更稳定。