RAG Architecture（检索增强生成架构）
RAG ArchitectureRAG 就是加个向量库
亦作、亦称：检索增强生成架构 · RAG Architecture · 生产级 RAG · RAG 架构工程
RAG Architecture（检索增强生成架构） 反对「加个向量库」的简化：生产 RAG 是 15+ 组件的系统，入库分块、混合检索、重排、接地与评测在模型被调用前就决定成败。朴素 RAG 约 40% 无法召回正确上下文，失败约 73% 在检索而非生成——先建评测，再谈组件。
为什么 RAG 是架构而不是功能
把 RAG 当「加个向量库」的团队通常 demo 成功、pilot 惊艳，真实流量一到就静默失败：API 返回 200、模型回答流畅、答案却是错的，而问题几乎总在 LLM 之前。沿错误答案倒推，断点通常在这五处之一：文档没入库；入库但分块把答案切成两半；分块存在但相似度排到 47 位；排位够但元数据过滤缺失；检索到了但模型忽略检索结果。
行业口径：朴素 RAG（固定分块 + 单向量相似度）约 40% 无法召回正确上下文；RAG 失败约 73% 在检索而非生成；80% 的缺陷在入库与分块层。这正是「架构」的含义——生产 RAG 是 15+ 组件的系统，决定成败的组件在模型被调用之前就已经定死。
入库与分块：80% 的缺陷在这层
分块按结构而非字符数：固定 512 token 窗口会把表格拦腰切断、让章节标题与正文分离；尊重标题/表格/列表边界的分块器在几乎所有公开基准上胜出。标题路径（如「退款 > 企业计划 > 例外」）要附在每个分块上——它既是嵌入需要的上下文，也是引用要给的出处。
元数据是检索基础设施：来源系统、文档日期、产品线、访问级别、版本。近半生产查询在相似度计算前就需要过滤（「当前政策」「EU 租户」）；ACL 不按用户、按分块端到端执行，检索就会变成合规事故。新鲜度是流水线不是批任务：入库时做内容哈希、变更检测、增量重嵌入，并暴露「索引新鲜度」指标。
检索：混合检索 + 重排是生产标准
纯向量在精确匹配（零件号、错误码、专名）上失败，纯关键词漏掉改写表达。2026 年生产标准是混合检索加重排：混合（BM25+向量）MRR 66.4% vs 纯语义 56.7%；混合再叠 cross-encoder 重排，比纯向量检索降低约 69% 错误率，代价约 200-400ms 重排延迟。
典型流水线形态：查询重写 → BM25 top-20 + 向量 top-20 → RRF 融合（k=60）到 top-30 → cross-encoder 重排到 top-5 → LLM 带引用生成。两个现场经验：加大 top-k 不是修复，是把检索问题换成延迟与噪声问题；嵌入模型会漂移，要按自己的查询集每季度重测检索，而不是盯厂商排行榜。
接地与评测：模型之后的两道闸门
检索把正确上下文交给模型，接地决定模型是否真的用它。三个约束最有效：
- 引用是硬契约：每个论断映射到检索分块 ID 并渲染为来源链接，让错误答案可调试、无出处答案可见
- 许可的「我不知道」：上下文没有答案时明说并转人工或扩大搜索，让弃答比编造便宜
- 上下文纪律：顺序重要（模型过度关注首尾）、矛盾版本要去重（两个版本同框是抛硬币）、别塞满（检索页数越多噪声越大）
评测必须最先存在：100-300 条真实问题，检索与生成分开打分，每次变更都跑。把 RAG 当搜索产品而不是 prompt 产品来预算——索引基础设施、重排延迟、季度重测、权限管道、评测集维护都是持续成本。
什么时候 RAG 是错的工具
诚实边界，检索文档不是万能答案：
- 实时运营真相：查订单状态是数据库查询加 API，不该走索引
- 稳定有界知识：语料小且年度才变时，长上下文提示或微调可能比整套检索装置更便宜更简单
- 计算伪装成问题：分析类问题（哪个区域增长最快）要的是对仓库生成 SQL，不是对 PDF 做相似度搜索
架构良好的助手通常是三路路由器：文档知识走 RAG、实时状态走工具、分析走结构化查询生成。把一切塞进向量索引是仅次于跳过评测的第二大设计错误。
常见误解
日常交流中容易听到的简化说法，未必准确，但能帮助理解误解从何而来。
- 「RAG 就是加个向量库」
- 「RAG 是功能不是架构」
相关术语
和本术语关联紧密的其他词条，便于串联理解。
🎯 考点练习
含该术语的高频面试题，含标准答案与追问。
- 初级概念高频查看详解 →
什么是大语言模型（LLM）？它能做什么、不能做什么？
LLM 是基于 Transformer、在海量文本上预训练的自回归语言模型，擅长语言任务，但不擅长精确计算、实时信息，且会产生幻觉。
- 高级系统设计查看详解 →
当 LLM 上下文窗口达到 1M token 时，"Lost in the Middle" 效应对 RAG 系统设计有何影响？如何工程化缓解？
即使上下文窗口达到 1M token，"Lost in the Middle"（Liu et al. 2023）与 Context Rot（Chroma 2026）仍使模型对中间位置信息的利用率显著下降——标称容量不等于有效容量。RAG 系统不能把检索结果无脑堆叠进超长上下文，而须做检索重排（首尾优先）、分层上下文预算（工作记忆 vs 长尾知识）、分块聚合（map-reduce）与位置探针评测。本题考察候选人能否把位置偏置从论文概念转化为 RAG 工程约束。
- 高级系统设计查看详解 →
基准污染诊断：当 SWE-bench Verified 得分异常高但实际能力不匹配时，如何系统性诊断并调整评估策略？
OpenAI SWE-bench Verified 审计发现 59.4% 任务存在缺陷，前沿模型被检测到从训练数据中召回答案（adwaitx.com 2026-02 技术分析）。当模型在基准上得分异常高（如 80%+）但实际能力不匹配时，候选人需要展示三条独立诊断路径（n-gram overlap 精确重叠、embedding similarity 语义重叠、ablation study 因果归因）的交叉验证能力，以及污染确认后从「单一基准分数」转向「基准组合 + 私有评测 + 过程评估」的评估策略重构能力。本题区分「会跑 benchmark」与「理解 benchmark 为什么可信」的候选人。
- 高级概念查看详解 →
在 MoE 模型的大规模部署中，Expert Parallelism 面临哪些工程挑战？请从负载均衡、通信开销、故障恢复三个维度分析。
Expert Parallelism 把 MoE 专家分布到多 GPU 以突破单卡显存上限，但 Top-K 路由导致负载不均、All-to-All 通信跨节点成为瓶颈、Expert 级 checkpoint 与弹性恢复比 Dense 模型更复杂。
延伸阅读
从知识库精选 3 篇文章，帮助深入理解该术语。
- 1
RAG 2026：从混合搜索到检索栈专用化的演进
2026 年年中，RAG 的瓶颈正在从模型层下移到检索层：混合搜索（BM25 + 稠密向量）以可验证的精度增益成为默认检索架构，而向量检索的计算负载又把问题推向硬件——Dnotitia 在 FMS 2026 发布首颗 VDPU（Vector Data Processing Unit）芯片并获 AI Application Award，宣称把宿主 CPU 利用率从 70-90% 压到接近 0。与此同时，arXiv 论文 TabooRAG 揭示了检索栈的另一个盲区：对齐同质性让安全对齐本身成为可迁移的拒绝服务攻击面，9 个主流 LLM 上的阻断攻击成功率达 59.1%-77.4%。本文沿「为什么检索成为瓶颈 → 混合搜索的增益与代价 → 检索硬件专用化机制 → 攻击面边界 → 企业选型决策」五步，给出 RAG 检索栈 2026 年的完整演进图景。
- 2
Agentic RAG 生产架构：从控制循环到检索-推理-反思的工程治理
当 RAG 系统从单次检索演进为多轮 Agentic 循环时，控制循环的收敛性、评估器的稳定性和上下文预算的可控性成为生产系统的三大工程挑战。本文从控制循环状态机出发，系统分析三类失败模式（循环不收敛、评估器漂移、上下文爆炸），给出最大轮数约束、评估器校准方法和分层预算管理的工程治理方案，附参数推荐值和决策框架。
- 3
RAG Reranking 工程决策：从 Cross-Encoder 到 LLM-as-Reranker 的生产部署权衡
Reranking 是 RAG 系统从'能用'到'好用'的关键杠杆，但生产部署面临延迟-成本-精度的三角权衡。Cross-Encoder 精度高但延迟大（50-200ms），LLM-as-Reranker 灵活但成本高昂（每次 rerank 消耗 token），ColBERT 延迟低但需要专用索引。本文给出基于查询复杂度和 SLA 约束的三层决策框架：简单 FAQ 跳过 rerank、中等复杂度用 cross-encoder、高难度推理用 LLM-as-Reranker + 级联过滤。附三种失败模式的诊断方法和生产 checklist。
外部参考
维基百科：查看「RAG Architecture」词条本页内容为本站原创撰写；维基百科链接仅作延伸参考。