聚焦 AI Agent 全链路工程实践：RAG 检索、记忆系统、Agent 编排、Next.js 产品落地与 AI 协作工程化。下方为当前写作方向；首页文章列表仅展示本阶段内容。
说明：下文整理 RAG 查询转换 / 多路检索 的六种常见策略与工业级分层融合思路，附 LangChain 风格 Demo。文末 §四 MemoryOS 对照 说明在 MemoryOS 仓库里哪些适合现在做、哪些应放进 EP04-03。
检索是 RAG 系统的核心瓶颈。用户原始问句普遍存在碎片化、语义不对称、多维度混杂、关键词缺失等问题，直接单路检索极易出现召回不全、精准度不足、答案片面等缺陷。行业内形成了一套标准化 查询转换优化体系，包含多查询重写、RRF 多查询融合、Step-Back 回退检索、HyDE 对称检索、Map-Reduce 问题分解、Ensemble 多路混合检索六大主流方案。
本文逐一拆解每种策略的实现原理、使用方法 Demo、优缺点、适用场景，最后给出可直接落地的多策略分层融合生产级完整链路。
在RAG检索优化体系中，RRF（倒数排名融合） 和 MMR（最大边际相关性） 是两个极易混淆、但定位完全不同的核心算法：
两者并非替代关系，而是工业级RAG链路中前后衔接的互补组件。本文从定义、数学原理、优缺点、适用场景、落地代码到选型策略，做完整拆解。
做企业级RAG的团队，几乎都被「幻觉」困扰过：财务场景说错报销标准、法律场景漏了合同条款、技术场景记错参数配置，哪怕优化了分块、换了Embedding、加了重排，依然没法彻底杜绝事实性错误。
做RAG开发的人，大概率都陷入过一个死循环： 召回效果不好→换Embedding模型→调chunk大小→调top_k→换分块算法→折腾一圈，复杂问题还是答非所问，跨章节的问题永远漏信息，宏观问题抓不住重点，细节问题又断上下文。
说明：MultiVector / 父子块是 路径 B（原始长文档） 的检索优化；与 RRF vs MMR 搭配时，先分清「多表征入库」和「多路 Retriever 融合」是两层事。LangChain 实现见
langchain_classic.retrievers.multi_vector（0.3+ 部分能力在langchain-classic包）。
Embedding 换了几轮、分块调了无数遍，仍然漏召回——Often 不是模型不够强，而是 一个 Chunk 只有一条向量，只能对齐一种问法。多表征索引（MultiVector）的核心很朴素：同一父文档挂多条检索用向量，命中任意一条都回到同一份完整上下文。
说明：下文来自 MemoryOS Chat 流式链路的一次真实「假死」排查。后端连接池、中间件等问题见姊妹篇 Chat SSE 假死：FastAPI Depends 占死连接池；本文只讲 BFF 与浏览器之间 为什么要做背压、怎么做、为什么不能全扔给前端。
用户问：「2022 世界杯射手榜前 10 名」。终端里 SQL 已经 COMMIT，刷新页面却能看到完整回答——聊天框却停在「正在生成…」，只吐出几个字，甚至最后 network error。
这不是 LLM 没算完，是 管道某一截憋住了。其中很大一块，出在 Next.js BFF 怎么读 FastAPI、又怎么喂给浏览器。
做RAG开发的人，大概率都陷入过这样的死循环： 召回效果差→换更贵的Embedding模型→调Chunk大小→改Top-K参数→折腾一圈，结果还是经常答非所问——用户问“办公采购报销规则”，召回一堆“差旅办公耗材”的碎片；问具体单据明细，混进来一大堆语义相近但完全无关的内容，LLM跟着瞎编幻觉。