用户第二轮问「那它支持导出吗」——这三个字没法直接检索。多轮对话 RAG 的核心动作是 condense：用对话历史把带指代、带省略的追问改写成独立完整的问题再去检索。本文讲清指代消解与历史压缩的做法、改写偏移的坑、以及「检索结果也要进历史」这个常被忽略的细节。

向量检索的粒度是个两难：块太小匹配得准但上下文残缺，块太大上下文完整但语义被稀释。父子检索（small-to-big）用「小块检索、大块生成」把两个诉求拆开——索引里存的是子块，命中后回父块。本文讲清它的原理、三种常见形态、最小实现与工程取舍。

文档改了一段、换个 embedding 模型、升一次切块参数——RAG 索引的一致性问题藏在所有「小改动」里：漏更新、新旧混杂、部分重建。本文把变更分三类讲清各自的正确姿势：文档增删改要级联，模型迁移要全量重建加双索引灰度，参数变更等于重建，并给出成本估算方法。

一千万条 768 维 float32 向量要吃 30GB 内存——规模一上来，向量存储就成了 RAG 最贵的一块。本文讲清三条压缩路线：标量量化降精度、PQ 降基数、二值化极限压缩，各自的原理、召回代价与「粗排压缩向量 + 精排原始向量」的标准补偿手法。

应用层的权限校验管不住 RAG——检索是直接对索引执行的，「谁能看到哪些文档」必须做进检索层。本文讲清多租户 RAG 的权限方案谱系：post-filter 的配额陷阱、引擎级 pre-filter、按租户分区，ACL 同步的时效问题，以及「默认拒绝」的架构原则。

用户问「你好」「帮我写首诗」，也被送去向量库里转一圈——检索噪声污染回答，还白烧延迟和成本。查询路由是检索之前的分流器：判断这个问题需不需要检索、走哪个索引、要不要追问澄清。本文讲清路由的决策维度、实现谱系（规则→分类器→LLM）、失败代价与降级设计。

向量库的召回率忽然下降、延迟忽然变高，八成不是玄学而是 HNSW 参数没调对。本文拆解 HNSW 三个核心参数 M、efConstruction、efSearch 各管什么、动谁的成本，给出「先建图、再扫 efSearch」的调参顺序，以及 top-k 大于 efSearch 这类高频踩坑。

传统嵌入向量要么全存要么全废，维度定死；嵌套表示（MRL）训练出的向量有个特殊性质——只取前 128 维依然可用，取前 256 维更好。本文讲清它的直觉原理、两种用法（截断降维与级联检索）、以及「普通模型向量不能随便截」这条红线。

「最新版的报销制度是什么」——语义检索能命中所有版本的报销制度，但只有元数据知道哪份是最新的。过滤条件（时间、部门、版本、类型）与语义检索是互补的两轴，合不好会出现「过滤后召回骤降」的经典翻车。本文讲清 pre/post-filter 的取舍、过滤条件的抽取与兜底。

「这本书的核心论点是什么」「三个季度业绩的整体趋势如何」——这类需要通读全库的问题，切块检索天然答不好：证据散在几十个块里，谁也匹配不上查询。RAPTOR 对分块递归聚类、逐层生成摘要，建出一棵可检索的摘要树。本文讲它与 GraphRAG 的分工、构建成本与适用边界。

「换了 reranker 感觉好了一些」「调大 chunk 之后好像更准了」——没有评测集，一切调优都是感觉。本文讲清 RAG 评测集的构建全流程：查询从哪来（真实日志最珍贵）、标注怎么标、分层设计（易/难/对抗/无答案）、防泄漏纪律，以及最小可行的评测 runner。

BM25 不懂同义改写，向量检索不懂精确词匹配。SPLADE 用语言模型给每个词算出词表上的权重分布——文档自己「长出」了相关扩展词，查询与文档在同一个扩展词表上匹配。它输出的是稀疏向量，能直接进倒排索引。本文讲清它和 BM25、dense 检索的三足关系与工程账。