这章学完后，我对RAG的理解从"简单的向量匹配"进阶到了"工程化的检索系统"。最触动我的是混合检索部分——以前只知道用Embedding做语义搜索，现在意识到BM25这类稀疏向量在精确匹配关键词（比如产品型号、专业术语）时依然不可替代。Milvus里同时存储稀疏和密集向量，再用RRF（倒数排序融合）整合结果，这种"组合拳"比单一检索靠谱多了。
查询构建让我看到了RAG与结构化数据结合的可能。特别是Self-Query Retriever，用LLM把"时长大于600秒的视频"这种自然语言自动转成元数据过滤条件，省去了写复杂过滤逻辑的麻烦。但Text2SQL部分也让我意识到实际落地有一定难度：模型幻觉表名、不理解JOIN关系、处理不了模糊业务术语（比如用户说"花费"实际对应cost字段）。文中提到的RAGFlow方案挺启发我——得先给数据库建个"知识库"，把DDL、字段描述、历史Q-SQL对都存进向量库，检索到相关schema再生成SQL，这样能大幅降低幻觉。
查询重构章节解开了我之前的一个困惑：用户问得不好，检索效果肯定差。HyDE（假设性文档嵌入）的思路很巧妙——不直接搜用户的问题，而是让LLM先写个"理想答案"，再用这个答案的向量去检索。还有Step-Back Prompting，先问"这背后的物理原理是什么"再解决具体问题，这种"退一步"的思考方式对复杂问答很有效。
最后是检索进阶的重排序和校正。以前觉得召回就完事了，现在知道还得用Cross-Encoder或ColBERT做精排，甚至用C-RAG（Corrective RAG）做"自我反思"——检索到文档后先评估是否相关，不相关就触发网络搜索，避免把垃圾上下文喂给模型。
不过实操中我也发现了坑点：ColBERT重排虽然比Cross-Encoder快，但自己实现时token级别的相似度计算容易出bug；还有LangChain的ContextualCompressionRetriever，如果pipeline里先重排再压缩，可能会出现结果重复的问题需要手动去重。
这章学完最大的感受是：生产级RAG不是"Embedding+LLM"那么简单，而是检索策略、查询理解、结果精排、错误修正的多层工程堆栈。每个环节都有学问，得根据业务场景（精度vs延迟vs成本）做trade-off。特别是看到LlamaIndex和LangChain的各种路由、压缩实现，意识到RAG系统正在从"脚本"转向"架构"，需要更严谨的工程设计思维。
学习资料参考：开源组织Datawhale all-in-rag项目
