RAG 不是“把文档塞进向量库”这么简单

很多团队第一次做 RAG，会把流程理解为：文档切块、生成 Embedding、存入向量数据库、检索 Top-K、交给大模型回答。这个流程能跑通 Demo，却很难直接支撑企业知识库、智能客服、研发助手和内部制度问答。

真正决定效果的，往往不是“用了哪个大模型”，而是文档有没有解析正确、切分是否保留语义、问题有没有改写完整、召回是否兼顾关键词与语义、重排有没有把关键证据推到前面，以及回答能否做到有依据、可追溯、权限不越界。

图 1：RAG 把闭卷问答变成基于外部资料的开卷问答

一、什么是 RAG？

RAG 的全称是 Retrieval-Augmented Generation，中文通常译为“检索增强生成”。它把大模型的参数化知识，与外部知识库、搜索系统、数据库或工具返回的数据结合起来：先找证据，再组织上下文，最后让模型基于证据生成回答。

2020 年的 RAG 论文把预训练生成模型看作“参数化记忆”，把外部文档索引看作“非参数化记忆”。外部知识可以独立更新，不必每次都重新训练模型；回答也能附上来源，从而提高知识密集型任务的可更新性与可追溯性。

图 2：离线索引与在线查询组成完整 RAG 流程

RAG 能解决什么，不能解决什么

补充模型训练数据中没有的企业私有知识

使用持续更新的制度、产品、新闻与业务数据

为答案提供出处、页码、URL 或文档版本

通过证据约束降低“凭空编造”的概率

但 RAG 不能直接提升模型本身的逻辑推理上限，也不能保证百分之百正确。检索可能漏掉正确文档、召回错误版本，模型也可能误读证据。因此，RAG 更像一套“知识获取与证据治理系统”，不是万能补丁。

二、RAG、微调与长上下文怎么选？

图 3：RAG、微调与长上下文解决不同类型的问题

需要模型学习固定输出格式、语气或操作习惯时，微调更合适；需要回答频繁更新、可追溯的事实时，优先考虑 RAG；材料很少、只做一次性分析时，可以直接使用长上下文。很多生产系统会把三者组合：微调负责行为，RAG 负责知识，长上下文负责临时材料。

三、索引阶段：先把知识整理成可检索的形态

图 4：文档解析需要保留结构、来源与权限元数据

1. 文档加载与解析

PDF、Word、网页、表格和扫描件的解析质量，直接决定后续检索上限。只抽取纯文本，往往会丢失标题层级、表格行列关系、图片说明、脚注和页码。复杂文档还需要版面识别或视觉文档检索，避免“文字抽到了，但结构已经被打散”。

建议每个知识块至少保留：正文、文档 ID、版本、章节路径、页码或 URL、发布时间、所属部门、租户与访问角色。回答中的引用、增量更新、权限过滤和问题回放，都依赖这些元数据。

2. 文档切分：块不是越小越好

图 5：切分大小需要平衡检索精度与上下文完整性

切得太小，容易命中关键词，却可能把条件与结论拆开；切得太大，检索结果会混入大量无关信息，增加上下文成本，并让模型难以聚焦。固定的 500 tokens 只是起点，不是通用答案。

图 6：常见文档切分策略与适用场景

务实的路径是：先用结构化或递归切分跑通基线，再根据失败样本调整。制度、技术文档和 Markdown 优先按标题结构切分；FAQ 可以一问一答为单位；代码按类、函数和调用关系切；复杂 PDF 需要保留表格与图片块。父子块策略很实用：用小块精准检索，返回包含前后文的父块给模型。

四、检索阶段：关键词、向量与细粒度匹配

图 7：三类主流检索方法各有优势

1. BM25：不要低估关键词检索

向量检索擅长理解“意思相近”，但产品型号、合同编号、错误码、人名和专业缩写，往往需要精确匹配。BM25 基于倒排索引，速度快、可解释，在企业搜索中仍然非常重要。

2. Dense Embedding：把语义相似映射到向量空间

Dense Retrieval 通常使用双编码器分别编码问题和文档，再按余弦相似度或内积搜索近邻。文档向量可以提前计算，因此在线速度快，适合大规模召回。DPR 证明了稠密检索在开放域问答中的实用性，但它把整段文本压缩成一个向量，也会损失细节。

3. Late Interaction：在质量与速度之间找新平衡

ColBERT 一类 Late Interaction 方法，会分别编码查询和文档，但保留 token 级向量，在最后阶段做细粒度交互。它比单向量更能识别局部匹配，又比对每个候选执行完整 Cross-Encoder 更容易扩展。

向量数据库怎么选

图 8：向量数据库选型应围绕业务约束

选型不要只比较单机 QPS。企业场景更需要关注：元数据过滤是否稳定、能否在检索前执行租户与角色权限、更新与删除是否及时、是否支持稠密与稀疏混合检索、索引重建与备份是否容易，以及团队是否具备相应运维能力。

五、在线查询：先把用户问题变成“好检索的问题”

图 9：查询改写与检索计划决定召回方向

多轮对话中，用户经常说“它呢”“上一款的条件是什么”。如果直接检索，系统并不知道代词指向谁。查询改写要结合对话历史补全实体，同时删除无关寒暄，形成可独立理解的问题。

Multi-Query：生成多种表达并行检索，提高召回率

Query Decomposition：把比较、因果、多跳问题拆成多个子问题

HyDE：先生成一个假设答案，再用答案向量寻找相关文档

Metadata Filter：按时间、产品、地区、部门和权限缩小范围

Retrieval Routing：根据问题类型选择文档库、SQL、搜索引擎或不检索

一个简化的查询编排逻辑

def answer(question, history, user):
query = rewrite_query(question, history)
plan = route_query(query)
candidates = hybrid_retrieve(query, plan.sources, acl=user.acl)
ranked = rerank(query, candidates)[:8]
context = build_context(ranked, token_budget=6000)
return generate_grounded_answer(query, context)

六、混合检索：向量 + BM25 已成为常见基线

图 10：两路检索并行执行，再通过 RRF 融合

关键词检索与向量检索的原始分数含义不同，直接加权往往需要反复调参。RRF（Reciprocal Rank Fusion）只利用结果的排名位置，将多路结果合并，不要求不同检索器共享同一种分数尺度。Elasticsearch 与 Azure AI Search 的官方文档都把 RRF 用作混合检索的重要融合方式。

七、Re-rank：初召回负责不漏，精排负责排对

图 11：高召回初筛与高精度重排形成漏斗

双编码器检索速度快，但问题和文档分别编码，无法针对当前问题做深度交互。Cross-Encoder 会把“问题 + 候选文档”一起送入模型，能更精确判断是否真正回答了问题，但计算成本更高。因此生产系统通常先召回 50–200 个候选，再重排到 5–20 个。

重排不是所有查询都必须开启。简单事实问答可以根据初排分数和延迟预算动态决定；复杂比较、多跳问题、表述模糊的问题，更值得使用重排。

八、上下文构造：检索结果还要再加工

图 12：从原始候选到高质量上下文的加工流程

检索结果常包含重复块、同一文档的相邻片段、旧版本和无关内容。上下文构造器需要去重、扩展邻居、控制来源多样性、压缩冗余、按逻辑顺序排列，并确保每个片段仍保留唯一的 chunk_id 与来源定位。

上下文不是越多越好。材料过多会增加成本和延迟，也会产生“上下文稀释”：真正的关键句被埋在大量相似内容中。应通过离线评测确定 Top-K、重排数量和 token 预算，而不是沿用默认值。

九、生成与引用：让每个事实都有证据

图 13：回答、引用与拒答组成生成阶段的三角约束

一个可靠的 RAG Prompt 应明确要求：只基于给定上下文回答；事实性陈述附来源；证据不足时说明无法确认；资料相互冲突时列出不同版本和时间，而不是自行选择一个看起来合理的答案。

你是企业知识助手。请严格遵守：
1. 只使用“参考资料”中的信息回答。
2. 每个关键结论后标注来源编号。
3. 资料不足、冲突或超出权限时，明确说明无法确认。
4. 不得补写资料中不存在的人名、数字、日期和条款。
5. 先给直接答案，再补充条件、例外和操作步骤。

引用不是装饰。系统需要保存“答案句子—证据块—原始文档位置”的映射，支持用户点击回到原文，也方便审计和失败回放。

十、从 Naive RAG 到 Agentic RAG、GraphRAG 与多模态 RAG

图 14：复杂问题需要不同的检索与上下文组织方式

Agentic RAG

基础 RAG 每次都执行固定检索流程。Agentic RAG 则让模型根据问题决定是否检索、查哪个知识源、是否拆分问题、是否验证结果，以及何时停止。它更灵活，但也引入循环次数、工具错误、权限和成本控制等新问题。

GraphRAG

普通向量 RAG 擅长定位局部片段，遇到“整个组织有哪些主题”“多个实体之间是什么关系”这类全局问题时容易碎片化。Microsoft GraphRAG 会从原始文本抽取实体与关系、构建社区层级并生成社区摘要，为全局搜索与关系分析提供不同于向量 Top-K 的上下文。

多模态与视觉文档检索

财报、技术手册、合同和研报往往包含表格、图表和复杂版面。仅抽取文本可能丢失行列关系。视觉文档检索会直接比较问题与页面图像或页面级表示，适合文本、表格与图片共同承载信息的文档。

十一、怎么量化 RAG 效果？

图 15：RAG 评测需要拆成检索、生成和系统三层

检索指标

Recall@K：正确证据是否出现在前 K 个候选中

Precision@K：前 K 个结果里有多少真正相关

MRR：第一个正确结果排得是否足够靠前

nDCG：考虑多条相关结果与排序位置的综合质量

生成指标

Faithfulness：回答中的声明是否能被上下文支持

Answer Relevance：回答是否真正解决用户问题

Citation Precision / Recall：引用是否正确、是否覆盖关键结论

拒答质量：没有证据时能否不猜测，并给出合理的下一步

RAGAS 的核心价值，是把检索上下文、回答忠实度和答案相关性拆开评估，帮助团队判断问题究竟出在召回还是生成。实际生产还应加入人工黄金集、规则校验和线上反馈，不能只依赖 LLM 裁判。

十二、常见失败与排查方法

图 16：RAG 常见故障现象、根因与优先处理方式

排查时要保存完整 Trace：原始问题、改写结果、过滤条件、每路召回列表、融合分数、重排结果、最终上下文、模型输入输出和引用映射。只看最终答案，无法判断故障发生在哪一层。

十三、企业级 RAG 的生产架构

图 17：企业级 RAG 平台需要权限、观测和评测贯穿全链路

生产环境通常需要把知识处理与在线问答拆开。离线侧负责解析、切分、向量化、索引版本与增量更新；在线侧负责查询理解、检索、重排、生成与引用。AI 网关负责鉴权、限流、模型路由和缓存，Tracing 系统记录每一步耗时和结果。

权限必须在召回阶段生效，而不是检索完再从 Prompt 中删除。否则文档内容可能进入日志、缓存或模型上下文，形成数据泄漏。多租户系统应把 tenant_id、角色和数据范围作为索引字段或独立命名空间。

十四、项目落地路径：从简单基线逐步升级

第一阶段：可运行基线：结构化切分 + Dense Retrieval + Top-K + 引用；先建立 100–300 条真实问题黄金集。

第二阶段：提高召回：加入 BM25、RRF、查询改写、元数据过滤，重点提升 Recall@K。

第三阶段：提高精度：加入 Cross-Encoder / Late Interaction 重排、父子块、上下文去重压缩。

第四阶段：提高可靠性：Claim 校验、引用映射、冲突处理、拒答阈值、权限审计和失败回放。

第五阶段：复杂任务：按需引入 Agentic RAG、GraphRAG、视觉文档检索和结构化数据工具。

图 18：RAG 上线前检查清单

面试中怎么回答“你做过 RAG 吗？”

不要只说“文档 Embedding 后存进向量库”。更完整的表达是：我把系统拆为离线索引和在线查询两条链路；离线侧按文档类型解析并结构化切分，保存版本、页码和权限元数据；在线侧先做多轮问题改写与意图路由，再并行执行 BM25 和向量召回，用 RRF 融合并通过重排模型筛选；最后做去重、父块补全和 token 预算控制，模型只能基于证据回答并附引用。效果通过 Recall@K、MRR、Faithfulness、引用准确率、P95 延迟和成本进行回归评测。