什么是 RAG（检索增强生成）

定义

RAG（Retrieval-Augmented Generation，检索增强生成）是一种 AI 架构模式：在大语言模型生成回答之前，先从外部知识库检索相关文档，将其作为上下文注入提示词，使模型基于检索到的事实生成回答，而非仅依赖训练记忆。

这个概念最早由 Facebook AI Research 在 2020 年的论文中提出（Lewis et al., NeurIPS 2020）。到 2025 年，RAG 已成为企业 AI 应用的主流架构——据 Databricks 统计，约 60% 的企业 LLM 应用已在使用 RAG 技术。Gartner 预测，到 2027 年，超过 75% 的企业生成式 AI 应用将使用 RAG 或类似的检索增强技术。

RAG 的运行流程可以概括为三步：

检索（Retrieval）：用户提问后，系统先在企业知识库中搜索相关文档片段
增强（Augmentation）：将检索到的内容作为上下文，与用户问题一起组成增强提示词
生成（Generation）：大语言模型基于增强提示词生成回答

但这三步看似简单，背后涉及的技术栈和工程决策却异常复杂。一个生产级 RAG 系统的架构层次远不止"把文档放进向量数据库"这么简单。

为什么企业需要 RAG

大语言模型有三个固有限制，恰好是 RAG 解决的核心问题：

知识截止：模型的训练数据有截止日期。一个 2024 年训练的模型不知道 2025 年的公司政策、产品手册或行业法规变更。RAG 通过实时检索，让模型访问最新文档。这对于政策频繁更新的行业（如金融合规、劳动法规）尤为关键——模型不需要重新训练，只需更新知识库即可。

幻觉：模型有时会生成看似合理但完全错误的信息。这在企业场景中是不可接受的——一个错误的合规建议可能导致法律风险。RAG 把相关事实放在模型的"眼前"，让它基于事实回答，从架构层面减少幻觉风险。根据 Stanford HAI 2025 年的研究，RAG 架构可将幻觉率降低 50-70%，但无法完全消除。

私有数据不可达：标准大模型无法访问企业内部的合同、报告、知识库、工单系统。RAG 在查询时动态连接这些数据源，不需要把企业数据放进模型训练集——这对数据安全和合规至关重要。企业可以在自己的基础设施内运行 RAG 系统，数据不出域。

RAG 不是什么

RAG ≠ 微调替代品

这是一个常见误解。RAG 和微调解决不同的问题，它们是互补而非替代的关系：

微调改变模型的行为——语气、格式、领域术语理解。适合让模型"说话像我们的人"。例如，用企业历史客服对话微调模型，使其回复风格与品牌调性一致。
RAG 提供实时事实——让模型"知道我们最新的政策和数据"。例如，确保模型回答的退换货政策是昨天刚更新的版本。

何时选择 RAG？ 当你的知识频繁更新、需要引用来源、涉及私有数据时。

何时选择微调？ 当你需要模型掌握特定的推理模式、领域术语、输出格式时。

何时两者都用？ 成熟的企业部署通常同时使用两者：微调负责风格一致性，RAG 负责事实准确性和可追溯性。据 McKinsey 2025 年的调查，已有 35% 的企业 GenAI 应用同时使用 RAG 和微调。

RAG ≠ 万能方案

RAG 有明确的适用边界：

结构化数据查询（如"上季度各区域平均客单价"）——需要 SQL 查询或 Text-to-SQL 能力，不是向量检索
实时数据（如库存、定价、系统状态）——标准 RAG 从静态索引检索，需要配合 Function Calling 实现实时查询
跨长文档推理（如理解一份 50 页合同的完整脉络）——简单的分块策略会丢失全局上下文，需要更高级的文档理解技术
复杂多跳推理（如"对比我们三个竞品的定价策略差异"）——需要 Agentic RAG 架构，单轮检索不够

RAG 架构详解：五层技术栈

一个能稳定运行的 RAG 系统不只是"把文档放进向量数据库"。核心架构分为五层，每一层都有关键决策点：

第一层：文档摄入

解析 PDF、Word、HTML、Excel 等格式，提取文本和元数据。这一层的挑战在于：

PDF 表格提取：许多企业文档以 PDF 表格形式存储关键数据，传统解析器容易丢失表格结构。需要使用 OCR + 布局识别（如 unstructured.io、LlamaParse）来保留表格语义。
元数据保留：文档来源、更新日期、作者、部门、密级等元数据对后续的权限控制和结果过滤至关重要。
增量更新：企业文档频繁更新，系统需要支持增量索引——只处理变更的文档，而非每次全量重建。

第二层：分块（Chunking）

将长文档切分为检索单元。这是 RAG 系统中影响最大的设计决策之一：

固定长度分块：最简单，按 token 数（如 512 或 1024）切分，配合重叠窗口（如 10-20%）。缺点是可能在句子中间切断，丢失语义完整性。
语义分块（Semantic Chunking）：按段落、章节或主题切分，保留语义完整性。效果通常优于固定长度，但实现更复杂。
递归分块：先用大粒度（章节）切分，再按需细分（段落），构建层次化索引。兼顾粗粒度概览和细粒度精确匹配。
父子分块（Parent-Child Chunking）：检索时用小块（精确匹配），生成时用大块（提供完整上下文）。这是目前效果最好的策略之一。

实操建议：chunk size 没有万能最优值。建议在 A/B 测试中以 256/512/1024 token 三种粒度对比检索效果，选择你的数据集上 RAGAS 评分最高的方案。

第三层：向量化（Embedding）

将文本块转换为高维向量，用于语义相似度搜索。关键决策：

模型选择：OpenAI text-embedding-3-large、Cohere embed-v3、BGE-large-zh（中文）、E5-mistral-7b 等都是当前主流选择。中文场景建议重点评测 BGE 系列和 Qwen Embedding。
维度：更高维度通常意味着更好的语义区分能力，但也带来更大的存储和检索开销。768-1534 维是大多数场景的甜蜜点。
多语言支持：跨国企业需要选择多语言 embedding 模型，确保中英文混合检索的效果。

第四层：检索

混合搜索（语义向量 + 关键词 BM25）通常优于单一方法。这一层的技术决策包括：

向量数据库选型：主流选项包括 Pinecone（托管服务）、Milvus（开源，适合大规模）、Weaviate（开源，内置混合搜索）、Chroma（轻量，适合原型）、Qdrant（Rust 编写，高性能）。选型需考虑数据规模、QPS 需求、部署方式和预算。
混合检索：纯语义检索可能遗漏关键词精确匹配（如产品型号、法律条款编号），BM25 + 向量搜索的组合可将召回率提升 15-25%。
重排序（Re-ranking）：用 cross-encoder 模型（如 Cohere Rerank、BGE-reranker）对初次检索结果重新打分，可显著提升精度。代价是增加 100-300ms 延迟。
检索数量：通常检索 top-5 到 top-20 文档块，经过重排序后取 top-3 到 top-5 注入提示词。

第五层：生成

将检索到的上下文注入提示词，指示模型仅基于上下文回答。关键要点：

提示词工程：明确指示"仅基于以下上下文回答，如果上下文中没有相关信息请说'我不知道'"，可有效减少幻觉。
上下文窗口管理：注意总 token 数不要超过模型上下文窗口。即使是 128K 上下文的模型，过长的上下文也可能导致"中间遗忘"现象。
引用标注：在生成时要求模型标注信息来源（如"[文档1]"），实现可追溯性。

大部分质量问题出在前四层，而非 LLM 本身。 如果检索不到正确的文档，再强的模型也无法生成正确回答。这就是为什么 RAG 系统的优化应该遵循"先优化检索，再优化生成"的原则。

企业落地 RAG 的常见坑

坑一：忽视文档质量

"垃圾进，垃圾出"在 RAG 系统中体现得淋漓尽致。如果知识库中充斥着过时的、重复的、格式混乱的文档，RAG 的输出质量必然糟糕。

解决方案：在构建 RAG 系统前，先做一次知识库治理——清理过期文档、统一格式、消除重复、标注版本。这往往是最耗时但回报最高的投资。

坑二：分块策略不当

将操作手册中的连续步骤强行切分到不同块中，导致模型只看到半截步骤。

解决方案：根据文档类型选择分块策略。流程文档按步骤分块，政策文档按条款分块，技术文档按章节分块。

坑三：没有评估体系

很多企业部署 RAG 后无法回答"效果到底怎么样"——因为没有评估体系。

解决方案：生产级 RAG 系统需要量化评估。业界常用 RAGAS 框架的四个指标：

Faithfulness（忠实度）：回答是否由检索到的上下文支撑（目标 > 0.90）
Answer Relevancy（回答相关性）：回答是否切中问题（目标 > 0.85）
Context Precision（上下文精度）：检索到的文档是否相关
Context Recall（上下文召回）：需要的信息是否都被检索到

建议在上线前构建 50-100 个测试问题集（包含问题和标准答案），持续追踪 RAGAS 评分变化。

坑四：权限控制缺失

企业知识库中不同文档有不同的访问权限（如薪资制度仅限 HR 和管理层），但基础 RAG 实现通常忽略权限。

解决方案：在元数据中标注文档权限，在检索时做权限过滤（pre-filtering 或 post-filtering）。这是企业级 RAG 与开源 demo 的核心差异之一。

坑五：忽视用户体验设计

用户不关心背后用了什么技术——他们关心的是"能不能快速得到准确回答"。如果 RAG 系统每次回答都需要 10 秒等待，用户很快就会回到手动搜索。

解决方案：优化检索链路延迟，提供流式输出（streaming），展示检索来源增强信任，对"不知道"的情况优雅降级。

RAG 2.0：Agentic RAG 与未来趋势

传统 RAG 是单轮检索——用户提问，系统检索一次，生成回答。但许多复杂问题需要多轮检索和推理：

"我们公司去年的最佳表现部门今年表现如何？"——需要先检索去年数据，再检索今年数据，然后对比分析。
"这个合同有哪些风险条款？"——需要逐条分析合同内容，而非简单检索。

Agentic RAG 是 2025-2026 年的重要趋势：将 RAG 嵌入 Agent 的推理循环中，使系统能够：

判断是否需要检索——简单问题直接回答，复杂问题才触发检索
多轮检索——根据中间结果决定是否需要补充检索
跨源检索——同时检索向量数据库、SQL 数据库、API
自我纠错——如果第一次检索结果不相关，调整查询策略重试

据 Gartner 预测，到 2027 年，超过 40% 的企业 RAG 部署将演进为 Agentic RAG 架构。这意味着 RAG 正从一个静态的"检索-生成"管线，进化为一个动态的、自适应的知识推理系统。

其他值得关注的趋势：

多模态 RAG：不仅检索文本，还能检索图片、表格、图表。对于工程图纸、医学影像等场景意义重大。
知识图谱增强 RAG（GraphRAG）：用知识图谱补充向量检索，增强跨文档推理能力。Microsoft 在 2024 年开源的 GraphRAG 框架引起了广泛关注。
本地化 RAG：在终端设备上运行的小型 RAG 系统，保护隐私的同时提供个性化服务。

RAG 的企业价值：可追溯性

RAG 区别于其他 AI 方案的核心优势是可追溯性：每个回答可以链接到源文档的具体位置。

在法律、金融、医疗等受监管行业，"这个回答从哪里来？"不是一个可选功能，而是合规硬性要求。RAG 从架构层面提供了这种能力——回答基于检索到的文档，文档有元数据（来源、日期、作者），可以审计和回溯。

这不仅是合规价值，更是用户信任的基础。当 AI 回答能够附带"根据《员工手册》第 3.2 条"这样的引用时，用户的信任度和采纳率会显著提升。Accenture 2025 年的研究显示，带引用的 AI 回答用户采纳率比无引用高出 47%。

与 LnkChat 平台的关联

LnkChat 平台在架构决策（ADR-001）中将 RAG 列为四类一等公民能力之一（RAG / Workflow / Agent / Tool Use）。这意味着：

RAG 是平台层的核心构造块，不是某个产品功能的附属
LnkChat AI Knowledge（企业 AI 知识库）以 RAG 为核心架构
RAG 可以与 Workflow、Agent、Tool Use 组合使用，形成更复杂的企业 AI 应用

以上 Capability 映射基于 LnkChat 自身的产品模型，不是行业通用的 RAG 定义。

结论

RAG 不是一项孤立的技术，而是企业 AI 基础设施的核心组件。理解它的五层架构、避开常见的落地坑、建立量化评估体系，是每个企业 AI 团队的必修课。

更重要的是，RAG 正在从静态管线向 Agentic RAG 演进——这意味着企业今天构建的 RAG 基础设施，未来可以平滑升级为更强大的自适应知识推理系统。投资 RAG，不仅是解决当下的问题，更是为未来的 AI 能力栈打下地基。