RAG 不是魔法，是一条工程流水线：从入门到生产落地的完整指南

摘要：RAG 解决的是”让大模型说得对，而不只是说得像”。它不是银弹，但在企业知识问答场景下，它是目前成本最低、幻觉控制最可靠的方案。

一、大模型为什么会”胡说八道”？

某连锁酒店集团上线了一套基于通用大模型的AI客服。产品经理兴奋地演示：客服机器人能流利地聊旅游攻略、推荐周边景点，甚至帮用户规划行程。

但上线第一天，一个客户问：“行政套房的退改政策是什么？” AI 自信地给出了一个听起来合理、却完全错误的回答，因为这家酒店的退改规则从未出现在任何公开训练数据里。

大模型够聪明，但是它没有访问”你私有知识”的能力。

大模型有两个结构性缺陷：

知识截止日期：训练数据有时间边界，模型不知道你上周更新的价格表
幻觉（Hallucination）：当模型”不知道”时，它不会说”我不知道”，而会编一个听起来靠谱的答案
解决这个问题有两条路：微调（Fine-tuning） 或 RAG（Retrieval-Augmented Generation，检索增强生成）。

RAG 的核心思路非常直观：在用户问问题的那一刻，从知识库里把相关资料找出来，塞给大模型，让它基于真实文档回答。

二、RAG 是怎么工作的？

用户提问
  ↓
从知识库中找出最相关的文档片段（检索）
  ↓
把问题 + 文档片段一起喂给大模型（增强）
  ↓
大模型基于真实资料生成答案（生成）

就是这三步：检索 → 增强 → 生成，这就是 RAG 名字的来源。

2.2 完整的工程流水线

离线链路（知识库建设）：*

原始文档（PDF/Word/网页/数据库）
  ↓  文档解析
结构化文本
  ↓  文本切片（Chunking）
语义完整的文档片段
  ↓  向量化（Embedding） —— [BGE/Qwen]
向量 + 原始文本
  ↓  写入向量数据库
索引建立完毕

在线链路（用户问答）：*

用户提问："行政套房如何退改？"
  ↓  查询理解（意图识别/改写）
  ↓  混合检索（稠密向量 + 稀疏关键词）
召回最相关的文档片段（Top-K）
  ↓  重排序（Reranking）
精选最高相关性的片段
  ↓  注入 Prompt
大模型生成带引用的答案

酒店客服场景下，离线链路就是把酒店的退改政策、房型介绍、会员权益文档全部处理入库；在线链路就是客人每次提问时实时检索和回答。

三、如何选型？

在真正动手之前，先把工具选好，否则后期迁移成本高。我们需要明确：Embedding模型、向量数据库和Reranker 是检索链路上的三道工序。Embedding 负责把文本变向量，向量库负责存储和快速召回，Reranker 负责精排。

3.1 向量数据库：按场景选，而不是按名气选

向量数据库是 RAG 的”记忆中枢”，存放所有文档的向量表示。

数据量 < 10 万条，团队已有 PostgreSQL：直接用 pgvector 扩展，零运维成本，够用（甚至SQLite都行）
数据量百万级，需要高性能：Milvus（开源，分布式，支持十亿级向量）或 Qdrant（Rust实现，性能极优，部署简单）
不想自己运维，接受数据出境：Pinecone（全托管，开箱即用，但数据在境外服务器）
需要内置混合检索（向量+关键词）：Weaviate/ES（内置 BM25 + 向量双路检索）

建议从 pgvector/sqlite 起步，规模增长后迁移到 Milvus 或 Qdrant。

3.2 Reranker 选型：按场景选

Reranker 用于在向量库粗召回后进行精准重排：

企业内网私有化/中文为主：BGE Reranker（开源，多语言，效果好，但需自建GPU推理）
快速上线/不想维护模型：Cohere Rerank（API托管，效果稳，但需接受数据出域）
垂直行业（医疗/法律/代码）：自研 Reranker（用业务专有query-doc数据微调）

3.3 框架选型：LangChain vs LlamaIndex vs 自研

场景	推荐
快速原型，需要大量预置集成（数据库、API、工具）	LangChain
数据密集型应用，需要精细化文档处理和索引管理	LlamaIndex

用 LlamaIndex 处理文档摄入和检索，用 LangChain 处理 Agent 编排和工具调用是常见路径。当然我更推荐直接拿 Vercel AI SDK 写/排布 Agent runtime，LangChain 往往过于厚重。

3.4 完整技术栈配套参考

方案	Embedding	向量库	Reranker	适用场景
快速 MVP	OpenAI	sqlite	Cohere	小团队、快速验证、无运维负担
企业私有化	BGE-M3/Qwen	Milvus/Qdrant/pgvector	BGE Reranker	数据不出域、多部门权限控制、中文为主
已有 ES 系统	BGE/OpenAI	ES (Dense+BM25)	BGE/Cohere	历史架构复用、已有庞大搜索业务
大规模生产	BGE/Qwen	Milvus	独立 Reranker	亿级数据、高并发检索、多业务线共享

四、工程落地的真正难点在哪里？

很多团队在 PoC 阶段”感觉可以用”，但一到生产就暴露各种问题。

4.1 文档解析质量决定效果上限

腾讯云行业经验：文档解析质量对最终效果的影响，远大于模型选型。

酒店有大量 PDF 合同、PPT 培训材料、Excel 价格表。这些文件进入系统的方式直接决定了后续所有环节的质量：

PDF 扫描件：OCR 识别准确率参差不齐，手写体、多栏布局、表格都是雷区
表格结构：把表格解析成纯文本后，行列关系往往丢失，检索出来的片段完全无法理解
多栏排版：工具如果按物理位置读取文字，经常把两栏内容混排成乱码
分块（Chunking）策略同样关键*：

策略	适用场景	风险
固定长度	格式统一的纯文本	可能从句子中间截断
语义分块（按段落/章节）	结构清晰的文档	分块大小不均匀
父子分块（小块检索，大块作为上下文）	技术手册、法律条文	索引复杂度高
滑动窗口（固定窗口+重叠区域）	叙事性长文档	存储冗余

推荐起点*：300–500 Token 的语义分块，50–100 Token 重叠，优先在段落/章节边界处切分。然后用实际业务问题集测试并根据结果调整。

4.2 混合检索：稠密与稀疏的结合

单纯向量检索会漏掉很多精确匹配场景：

搜索 “XR-7200 型号的保修期”：关键词匹配（稀疏向量/BM25）更精准，型号是精确字符串
搜索 “三包政策”：语义检索（稠密向量）更强，文档里可能写的是”售后保障""维修条款”

生产级 RAG 的标准配置是：稠密向量检索（语义） + 稀疏向量检索（BM25 关键词）并行召回，再通过 RRF（倒数排序融合）等算法结合。这一配置能将召回率显著提升。

4.3 Reranker 精排：解决“排不准”的问题

普通的向量检索（如 bi-encoder 双塔模型）是提前把问题和文档分别独立计算向量再作对比，速度快但缺乏深度交互。而 Reranker（通常是 cross-encoder 交叉模型）会把“用户问题”和“候选文档片段”拼接在一起联合计算相关性分数，精准度极高。

注意*：Reranker 会增加一定的系统延迟。典型的工程取舍是：让向量库快速粗召回 Top 50，再用 Reranker 精排选出最相关的 Top 5 给大模型。

4.4 生产级系统的隐藏问题

PoC 阶段完全看不见的工程问题，往往是生产环境的主要故障来源：

权限管理：给普通住客看的内容，和给 VIP 会员看的内容不同。文档权限必须在检索阶段就进行过滤，不能靠大模型自己判断。例如，利用 Qdrant 的 Payload 过滤能力（通过 must/should/must_not 条件），是实现字段级权限隔离的标准工程手段。
实时更新：政策文档随时会变，知识库需要支持增量更新，不能每次都全量重建索引。
兜底策略：当检索不到相关内容时，模型不能编造答案。必须有明确的兜底逻辑：引导用户转人工，或者明确说”我不知道”。

五、什么时候你其实不需要 RAG？

在投入建设之前，先做一个自检。

5.1 RAG vs 微调（Fine-tuning）：不是竞争，是分工

维度	RAG	微调
核心作用	引入外部知识，回答基于事实的问题	调整模型行为风格和领域适配
知识更新	实时生效，更新文档即可	需要重新训练，周期以天或周计
成本	主要是检索和存储，增量成本低	训练成本高，需要 GPU 算力
幻觉控制	有据可查，可追溯到原始文档	仍可能产生幻觉

判断原则*：99% 的企业知识问答场景，RAG 已经够用。只有需要大幅改变模型的输出风格，或者做深度领域适配时，才考虑微调。

5.2 RAG vs Long Context：窗口大了，RAG 还有必要吗？

大模型的上下文窗口已经扩展到 100K–1M Token。长上下文有三个实际问题：

成本：超长 Prompt 每次调用费用远高于检索几个片段。
“中间迷失”：模型处理超长上下文时，对中间位置信息的注意力会显著下降。
延迟：处理时间更长，用户体验变差。

建议*：文档量极小（<100页）时直接写进 Prompt 更高效；文档量大、需精准引用、需权限隔离时，RAG 是更好的选择。

成本：100K Token 的 Prompt，每次调用费用远高于检索几个片段
“中间迷失”（Lost in the Middle）：模型在处理超长上下文时，对中间位置的信息注意力会显著下降
延迟：处理超长上下文的时间更长，用户体验变差

实用建议*：文档量极小（几十条以内）时，直接写进 Prompt 更高效；文档量大、需要精准引用来源、需要实时更新时，RAG 是更好的选择（我的经验是小于100页文档都行）

你的核心需求是"从大量文档中找答案"？

  → 是 → 上 RAG

数据量极小（<50条），且短期不会更新？

  → 是 → 直接写进 Prompt，不必上 RAG

需求主要是"让模型输出风格更专业/更像某个领域专家"？

  → 是 → 考虑微调，而不是 RAG

六、RAG 是如何一步步演进到今天的？

酒店客服系统从最初的”能用”到今天的”好用”，走过了 RAG 技术演化的每一代。

Naive RAG（2022–2023 主流）

最基础的形态：向量化 → 检索 → 生成。

天花板*：召回率不稳定。因为底层的 bi-encoder（双塔模型）对查询和文档是分别独立编码的，没有进行深度的词法与语义交互，导致精度上限受限。

Advanced RAG（2023 主流）

引入了查询改写（如通过 HyDE 假设性文档扩展或 Sub-query 分解，把模糊问题变成精确的检索 Query）、混合检索（稠密+稀疏）和 Reranker 重排序。

在酒店场景，这一代的准确率从 60% 提升到了 80% 以上。

Agentic RAG / DeepSearch（2024–2025 主流）

固定流水线，变为由 Agent 动态规划：

简单事实问题 → 直接向量检索，一次回答
复杂多跳问题 → 分解子问题，多轮检索，聚合答案
已有答案在上下文里 → 跳过检索，直接生成

酒店客服遇到的”帮我规划三天行程，包含住宿、餐厅推荐和景点”，就是 Agentic RAG 负责解决的场景。

天花板*：对叙事型私有数据（例如：跨多份合同的关联分析）的全局理解仍然困难。

GraphRAG（Microsoft 2024）

在文档中抽取实体和关系，构建知识图谱，再做全局检索。适合处理跨文档的关联分析（如追踪不同合同文档中的供应商影响）

DeepSearch Agent（2025 +趋势）

结合推理型大模型，实现多轮规划、反思、验证的搜索流程。在召回质量不够时，系统自动扩大搜索范围或更换策略：

ICL（上下文学习）：* 在给大模型的提示词中提供几个现成的参考样例，让模型模仿并输出符合预期的格式。
CoT（思维链）：* 引导大模型一步一步地进行逻辑推理（如“让我们一步步思考”），从而提高解决复杂问题或数学/代码任务的准确率

七、如何知道你的 RAG 系统够不够好？评估体系

没有评估就是在凭感觉开车。评估不只是看最终答案对不对，而要分层评估：检索层看召回率和排序准确率（如 MRR、NDCG、Precision@K），生成层看答案是否有幻觉、是否切题。

7.1 RAGAS 框架：四个核心指标

生成层的评估目前最流行的是 RAGAS 框架：

指标	衡量什么	酒店场景示例
Faithfulness（忠实度）	答案是否只基于检索文档，没有幻觉	回答退改政策时，有没有编造不存在的条款？
Answer Relevance（答案相关性）	答案是否真正回答了用户的问题	用户问退改，结果回答的是入住流程？
Context Recall（上下文召回率）	检索片段是否覆盖了回答所需的全部信息	政策文档有3个关键条款，检索到了几个？
Context Precision（上下文精确率）	检索到的片段有多少是真正有用的	检索到了10个片段，有几个是相关的？

7.2 建立评估数据集

第一周与真实业务人员深度合作，准备好 50–100 个代表性问题，写好标准答案和参考来源。每次改动系统（换 Embedding、调分块策略）都跑一遍评估，确保指标不退化。

八、RAG + 知识图谱 + Agent

随着酒店系统越来越复杂，单纯的 RAG 开始遇到新问题：客户不只想查政策文档，还想问”我的历史订单里有没有 VIP 套房的权益没用完？”

这涉及结构化数据的关系查询，向量检索无法稳定处理。这时候需要引入更高级的架构。

第一层：RAG 为基座（非结构化知识）

解决核心问题：“答案藏在哪些文档里？“

第二层：知识图谱扩展（结构化关系）

它解决的核心问题是：“答案藏在哪些文档里？”

知识图谱的查询不是向量检索，是通过 Text2Cypher（将自然语言转为图查询语言）来完成，Agent 负责把用户的自然语言翻译成 Cypher 查询发给图数据库。

判断什么时候引入知识图谱*：当你的核心问题是”查实体关系、多跳推理、供应链/风控分析”时引入。如果只是文档问答，不必急着上图数据库。

值得一提的是，Milvus 的工程实践表明：某些场景下不需要真正的图数据库，通过向量库模拟实体-关系的子图扩展，可以实现类 GraphRAG 的效果，显著降低工程复杂度。这是技术选型时值得权衡的方向。

第三层：Agent 编排（处理复杂多步任务）

当问题需要跨多个工具、多个数据源、多步规划时，就到了 Agentic RAG 的领域：

用户："帮我分析这次季度销售下滑的原因，结合客诉记录和竞品动态"
Agent 规划：
  Step 1 → 查知识图谱（销售数据 + 客诉关联）
  Step 2 → 检索 RAG（竞品分析文档）
  Step 3 → 调用外部 API（行业数据）
  Step 4 → 聚合结果，生成分析报告

Agent 根据问题动态决定调用哪些工具、做多少步推理。

三层架构的选型建议：*
只有文档问答需求 → 只上 RAG，不必引入图谱和 Agent
既有文档问答、又有结构化关系查询 → RAG + 知识图谱
需要处理复杂多步任务、动态规划 → RAG + Agent
三种需求都有 → 完整三层架构，但要做好工程治理，避免过度工程化

Multi-Agent 与企业 KB 的适用场景与边界

基于 Multi-Agent ，通过“主Agent分发 + 子Agent专业回答”的架构，可以实现知识的精准检索和专业解答。

适合的场景：

场景	说明
中大型企业	部门多、知识分散，需要统一入口
知识密集型行业	金融、医疗、制造等政策流程复杂
高咨询量场景	HR、财务、IT 日常咨询量大
多语言环境	可配置多语言 Agent 服务不同地区员工

不适合的场景：

场景	原因	替代方案
小团队	知识量少，单 Agent 足够	使用单 Agent + 完整知识库
实时操作需求	需要直接操作业务系统	集成 API 或使用 RPA
高度个性化咨询	如薪酬谈判、职业规划	保留人工服务通道

相比传统单一 Agent 方案，这种架构具有更好的专业性、可扩展性和可维护性，适合中大型企业的知识管理

九、总结

各司其职，缺一不可：Embedding 决定“找不找得到”，向量库决定“查得快不快”，Reranker 决定“排得准不准”。没有好的 Embedding 会导致根本召回不到正确内容；没有 Reranker，召回了相关内容，但顺序全乱
文档质量是地基：“把文档扔进去”不等于”知识库建好了”。
Embedding 模型的选型和稳定性同等重要：一旦确定，轻易不要换。换 Embedding 模型意味着全库重新向量化，早期选型失误的代价极高。
混合检索是标配：BM25 + 向量的方案从第一天就该设计进去。
别过早引入知识图谱：先把 RAG 做到极致，再决定是否升级到图谱+Agent。
可观测性是持续优化的前提：记录每次检索的召回文档和用户反馈。
RAG 是一条需要持续迭代的工程流水线，理解每个环节，才能真正让大模型为业务服务。