RAG 技术详解：让大模型连接企业知识库

摘要

大语言模型虽然具备强大的生成能力，但它存在知识滞后、事实幻觉、无法访问私有数据等问题。RAG，即 Retrieval-Augmented Generation，检索增强生成，是当前企业 AI 应用中最常用的技术方案之一。它通过“先检索、再生成”的方式，让大模型基于外部知识库回答问题。本文将介绍 RAG 的基本原理、系统架构、关键技术点和工程实践建议。

一、为什么需要 RAG？

大模型本身的知识主要来自训练数据。训练完成后，模型参数基本固定，因此它无法自动知道企业内部最新文档、产品手册、合同条款、代码仓库或客户支持记录。

如果直接向模型提问：

我们公司最新的报销政策是什么？

模型可能无法回答，甚至可能编造一个听起来合理但实际错误的答案。

RAG 的核心思路是：不要让模型凭空回答，而是先从可信知识库中找出相关内容，再让模型基于这些内容生成回答。

二、RAG 的基本流程

一个典型 RAG 系统通常包括以下步骤：

1. 文档采集 从 PDF、网页、数据库、Notion、Google Drive、代码仓库等来源获取数据。
2. 文档切分 将长文档切成较小的片段，例如每段 300 到 800 个 token。
3. 向量化 使用 embedding 模型将文本片段转换成向量。
4. 存入向量数据库 将文本片段及其向量存入 Milvus、Pinecone、Weaviate、FAISS、pgvector 等系统。
5. 用户提问 将用户问题也转换成向量。
6. 相似度检索 从向量数据库中找到与问题最相关的文本片段。
7. 构造 Prompt 把检索到的内容和用户问题一起交给大模型。
8. 生成回答 模型基于检索结果生成答案，并最好附带引用来源。

三、RAG 的系统架构

一个工程化 RAG 系统通常包含以下模块：

数据接入层 负责从不同数据源同步文档，例如企业网盘、知识库、数据库、CRM 系统和客服工单。

预处理层 负责清洗文本、去除无效内容、处理表格、识别标题结构，并对文档进行合理切分。

索引层 负责生成 embedding，并将向量、文本、标题、来源、权限等元数据写入索引系统。

检索层 负责根据用户查询召回相关内容。常见方法包括向量检索、关键词检索和混合检索。

重排序层 使用 reranker 模型对初步检索结果重新排序，提高上下文质量。

生成层 将高质量上下文注入 prompt，让大模型生成最终答案。

权限与审计层 确保用户只能看到自己有权限访问的内容，并记录查询、检索和回答过程。

四、文档切分是 RAG 的关键

很多 RAG 系统效果不好，并不是模型能力差，而是文档切分不合理。

如果切分太小，片段缺少上下文。例如只保留一句话：

它适用于高级用户。

模型不知道“它”指什么。

如果切分太大，检索结果可能包含大量无关信息，浪费上下文窗口。

较好的做法是根据文档结构切分，例如按标题、段落、表格、代码块进行分块。同时保留父标题、章节路径、文档来源和更新时间等元数据。

例如一个切片可以包含：

文档标题：员工报销制度
章节：交通费用报销
内容：员工因公出差产生的出租车、地铁、高铁费用可凭发票报销……
更新时间：2026-03-15
权限：Finance, HR

这样模型在回答时更容易理解内容来源和适用范围。

五、向量检索与混合检索

RAG 系统常用向量检索，因为它能根据语义相似度查找内容。

例如用户问：

出差打车能不能报销？

即使文档中写的是：

因公外出产生的出租车费用可申请报销。

向量检索也能找到相关内容。

但向量检索并不总是完美。对于精确关键词、编号、代码函数名、合同条款等场景，传统关键词检索仍然很重要。

因此，实际系统中常采用混合检索：

最终结果 = 向量检索结果 + BM25 关键词检索结果 + 权限过滤 + 重排序

这样既能理解语义，又能保证精确匹配能力。

六、Rerank 提升检索质量

向量数据库通常会召回前几十个候选片段，但这些片段排序不一定最优。Reranker 可以对“用户问题”和“候选片段”进行更精细的相关性判断。

例如向量检索召回 50 个片段，reranker 再选出最相关的 5 个片段交给大模型。

这一步会增加一些延迟，但通常能显著提升回答准确性，尤其适合企业知识问答、法律文档、技术文档和客服系统。

七、RAG 的常见问题

RAG 系统常见问题包括：

检索不到 可能是文档没有同步、切分不合理、embedding 模型不适合领域语言，或者用户问题表达与文档差异太大。

检索到了但回答错误 可能是 prompt 没有限制模型必须基于上下文回答，或者检索结果中存在过期信息。

权限泄露 如果没有在检索阶段做权限过滤，用户可能看到不该看的内容。

引用不准确 模型可能引用了错误段落，因此需要把引用逻辑放在系统侧，而不是完全依赖模型自由生成。

延迟过高 RAG 系统涉及检索、重排序和生成，多模块串联后容易变慢，需要做缓存、批处理和索引优化。

八、RAG 工程实践建议

第一，优先保证数据质量。脏数据进入知识库后，模型只会更快地生成错误答案。

第二，保留丰富元数据，包括文档来源、更新时间、作者、权限、章节路径等。

第三，使用混合检索，而不是只依赖向量检索。

第四，对重要场景引入 reranker。

第五，回答中尽量提供引用来源，让用户可以验证。

第六，对模型设置约束：如果上下文中没有答案，应明确回答“不知道”，而不是编造。

第七，建立评估集，持续测试召回率、准确率、幻觉率和响应延迟。

九、总结

RAG 是大模型落地企业场景的重要技术方案。它通过连接外部知识库，解决了模型知识滞后、无法访问私有数据和容易幻觉的问题。

一个高质量 RAG 系统不仅需要大模型，还需要良好的数据治理、文档切分、向量索引、混合检索、重排序、权限控制和评估体系。真正的难点不在于“把文档丢给模型”，而在于构建一个可维护、可验证、可扩展的知识增强系统。