面经策

什么是 Advanced RAG？ ​

  • 标签：AI、大模型、RAG

🏛 业务架构师 ​

Advanced RAG 是在 Naive RAG（切块→向量检索→生成）基础上的系统性增强，分三个环节：

  • 检索前：查询改写与扩展、自查询（抽取元数据过滤条件）、HyDE（先让模型生成假设答案再检索，对专业术语场景提升明显）。
  • 检索中：混合检索（向量+BM25 融合）、元数据过滤、调节 Top-K 与相似度阈值。
  • 检索后：Rerank 重排序、上下文去重压缩、父子分块扩展（小块检索、大块送模型）。

业务视角怎么理解：Naive RAG 在 Demo 阶段很美好，一上真实知识库就暴露三大症状——检索不到（行话/编码问题）、检索不准（相似但无关）、答案胡编（上下文污染）。Advanced RAG 的每一项技术都是对症下药的"手段库"。

我的落地建议：不要一次把所有增强全堆上——那是过度设计。正确姿势是：上线后建立 badcase 归因机制，"检索不到"就上混合检索和查询扩展，"检索不准"就上 Rerank，"答案胡编"就改提示约束。每加一层增强都有成本（延迟、复杂度），用评测集证明每项投入的边际收益，这才是业务架构师该有的克制。

🏗 系统架构师 ​

Advanced RAG 是在 Naive RAG 的"索引→检索→生成"三段骨架上，在检索前、检索中、检索后插入优化环节的架构形态。区别于 Modular RAG 的是：它还是线性流水线，只是每段加了增强。

三个环节的典型手段：

  • Pre-Retrieval（检索前）：查询改写、查询扩展、自查询（元数据抽取）、HyDE、意图路由；
  • Retrieval（检索中）：混合检索（向量+BM25）、元数据 pre-filter、调 Top-K、多路召回；
  • Post-Retrieval（检索后）：Rerank 精排、去重、上下文压缩、chunk 排序（关键信息放首尾对抗 lost-in-the-middle）。

我的架构判断：Advanced RAG 是当前生产的事实标准——Naive RAG 在真实语料上 recall 不足、幻觉偏高，而 Modular RAG 的完全组件化对多数团队是过度设计。落地路径也清晰：先上混合检索 + Rerank（两项合计通常端到端提升 15~30 个点），再按归因结果决定要不要查询改写和压缩。

工程纪律：每个环节独立开关 + 独立指标（改写命中率、召回率、重排一致性），否则多环节叠加后问题无法归因，这就是流水线架构的代价——可观测性必须先行。

💻 全栈开发专家 ​

Advanced RAG 是在 Naive RAG（查→检索→拼→生成）前后加优化环节的增强架构，分三段：

  • 预检索（Pre-Retrieval）：查询改写、查询扩展（Multi-Query）、子问题分解、HyDE、自查询（抽元数据过滤）、查询路由（多知识库选择）。
  • 检索本身增强：混合检索（向量+BM25）、元数据过滤、父子块 small-to-big、微调 Embedding。
  • 后检索（Post-Retrieval）：Rerank 精排、上下文压缩（去冗余句子）、丢掉低相关块、引用对齐。

一个典型生产链路：

query → 意图分类 →(模糊型)查询扩展 → 混合检索 top50
     → rerank 取 top5 → 上下文压缩 → 生成(带引用) → 校验

我的落地感受：Advanced RAG 不是全上，是按评测数据逐个加。我们项目最初的顺序是：混合检索（提升最大）→ rerank（第二）→ 查询改写（多跳问题才需要）。每加一个环节都要在 golden set 上确认净收益，因为每个环节都加延迟和成本——曾经加了三层优化，P99 从 2s 涨到 5s，用户体感反而变差，最后砍掉一层。ROI 意识是 Advanced RAG 落地的关键。