企业把大模型用进知识库，最常见的失败不是”模型不够聪明”，而是”答非所问、张口就来”。RAG（检索增强生成）正是为解决这个问题而生。本指南面向企业决策者与技术负责人，把企业 RAG 知识库的原理、核心流程、选型与落地坑位讲清楚，帮助你判断该怎么做、用什么、避哪些坑。
RAG 是什么？为什么它能降低大模型幻觉？
RAG（Retrieval-Augmented Generation，检索增强生成）是一种”先检索后生成”的架构：先从企业私有知识库中检索与问题最相关的文档片段，再把这些片段连同问题一起交给大模型，让模型基于真实材料作答。
大模型的”幻觉”，本质是它在没有依据时凭概率”猜”出一个看似合理的答案。RAG 改变了这一点：模型不再只靠训练时记住的参数，而是被约束在当前检索到的真实文档上回答。这带来三个直接好处：
- 有据可依：答案来自企业自己的文档，而非模型的”记忆”，事实准确率显著提升。
- 可溯源：每条结论都能标注来源段落，业务方可一键核对原文。
- 易更新：知识更新只需替换或新增文档，无需重新训练模型，分钟级生效。
对企业而言，RAG 是当前把知识库接入大模型、且能控制风险的最务实路径。
企业 RAG 的核心流程有哪几步？
一套完整的企业 RAG 包含六个环节：文档切分、向量化（Embedding）、检索、重排、生成、引用溯源。每一步都直接影响最终答案质量，缺一不可。
- 文档切分（Chunking）：把 PDF、Word、网页、工单等原始文档切成语义完整的片段。常用切片长度为 300–800 个 token，并设置 10%–20% 的重叠（overlap），避免句子被截断丢失上下文。表格、代码、图纸说明需要专门的切分策略。
- 向量化（Embedding）：用 Embedding 模型把每个片段转成几百到几千维的向量，语义相近的片段在向量空间中距离更近。中文场景建议选对中文友好的模型（如 BGE、M3E 等开源系列），可私有化部署。
- 检索（Retrieval）：把用户问题同样向量化，在向量库中做相似度检索，召回 Top-K（常取 20–50）个候选片段。生产中通常做”向量检索 + 关键词检索”的混合检索，兼顾语义与精确匹配。
- 重排（Rerank）：用更精细的重排模型（Cross-Encoder）对候选片段重新打分，把最相关的 3–8 个排到最前。重排往往是准确率提升最明显的一步。
- 生成（Generation）：把重排后的片段拼入提示词，交给大模型生成答案，并要求它”只依据给定材料作答，无依据则说明无法回答”。
- 引用溯源（Citation）：在答案中标注每段结论对应的文档来源与位置，供用户核对，这是企业场景区别于消费级问答的关键。
一个常见误区是只做”向量化 + 检索 + 生成”，省掉重排和溯源。结果就是召回一堆似是而非的片段、答案无法核对，业务方很快失去信任。
向量数据库怎么选？Milvus、Qdrant、PGVector 对比
选型没有标准答案，取决于数据规模、团队技术栈和运维能力。简单说：已有 PostgreSQL 且数据量不大优先 PGVector；追求高并发、超大规模选 Milvus；想轻量快速上手选 Qdrant。
下表从企业落地角度对三者做对比：
| 维度 | Milvus | Qdrant | PGVector |
|---|---|---|---|
| 定位 | 分布式向量数据库 | 轻量高性能向量库 | PostgreSQL 向量扩展 |
| 适用规模 | 千万到十亿级向量 | 百万到亿级向量 | 百万级以内最舒适 |
| 水平扩展 | 强，原生分布式 | 支持分片，中等 | 较弱，依赖 PG 方案 |
| 部署运维 | 组件较多，运维偏重 | 单二进制，部署轻量 | 复用现有 PG，几乎零新增 |
| 混合检索 | 支持 | 支持（含过滤） | 需配合全文检索扩展 |
| 上手难度 | 偏高 | 低 | 低（懂 SQL 即可） |
| 私有化 | 友好，开源 | 友好，开源 | 友好，开源 |
| 典型场景 | 大型企业、海量文档、高并发 | 中型项目、快速迭代 | 已有 PG 栈、数据量可控 |
落地建议：
- 从小做起：MVP 阶段若数据量在百万向量以内，PGVector 能让你省下一整套新组件的运维成本。
- 预判增长：如果可预见数据量将达千万级、并发要求高，直接上 Milvus，避免后期迁移。
- 平衡之选：Qdrant 在性能、部署轻量和带元数据过滤的混合检索之间取得较好平衡，适合大多数中型项目。
RAG 还是微调？两者怎么选
一句话结论：知识频繁变化、要求溯源、追求低成本，选 RAG；要改变模型的语言风格、固定输出格式或注入难以文档化的隐性能力，才考虑微调。两者也可以叠加使用。
- 更新方式：RAG 改文档即生效，分钟级；微调需重新训练，周期以天/周计。
- 可溯源性：RAG 天然可标注来源；微调把知识揉进权重，难以追溯。
- 成本：RAG 以检索与推理成本为主，整体可控；微调有显著的训练算力与数据准备成本。
- 适用场景：知识密集型问答、制度查询、产品手册、客服 → RAG；特定文风改写、结构化抽取的稳定输出 → 微调。
多数企业知识库场景，RAG 是主力，微调是补充。
怎么治理 RAG 的幻觉？
治理幻觉的核心是”不让模型在没有依据时硬答”。具体做法是在检索、生成、校验三个环节同时设防，把答案牢牢锁在真实文档上。
实践中行之有效的方法包括：
- 混合检索 + 重排：先用向量 + 关键词召回，再用重排模型精排，保证喂给模型的是高质量片段。
- 相似度阈值过滤：低于阈值的片段直接丢弃，宁可召回少也不召回错。
- 强约束提示词：明确要求”仅依据给定资料回答，资料不足时回答’无法确定’“，禁止自由发挥。
- 引用强制化：要求每条结论附带来源，无来源的结论视为不合格。
- 答案校验：对生成结果做二次校验，检查是否每句话都能在检索片段中找到支撑（即”忠实度”检查）。
- 兜底拒答：检索为空或置信度过低时，转人工或返回”未找到相关信息”，而不是编造。
这套组合拳无法把幻觉降到零，但能把它压到企业可接受、可监控的水平。
企业 RAG 私有化部署与数据安全怎么做？
涉及核心工艺、客户隐私或受等保要求的数据，建议把大模型、Embedding 模型、向量库与检索服务全部部署在企业内网，数据不出域。这是兼顾大模型能力与合规要求的主流做法。
私有化落地的关键点：
- 全链路内网化：从文档接入、向量化到生成，全部在内网或私有云完成，不调用外部 API。
- 模型本地化：选用可商用、可私有部署的开源大模型与中文 Embedding 模型，按业务规模选择参数量级。
- 权限与隔离：按部门、角色做知识库分级与行级权限控制，确保用户只能检索到有权查看的文档。
- 合规对齐：对照《网络安全法》《数据安全法》《个人信息保护法》及网络安全等级保护（等保 2.0）要求，做数据分类分级、访问审计与日志留存。
- 审计可追溯：记录每次问答的检索来源与生成结果，满足合规审计与问题回溯需要。
数据敏感度不高、追求快速上线的场景，也可采用云端 API + 私有向量库的折中方案，按调用计费、降低初期投入。
怎么评测企业 RAG 的效果？
RAG 评测要分两段看：检索质量和生成质量。检索看”找得全不全、准不准”，生成看”答得对不对、忠不忠于原文”。两段都要量化，才能持续优化。
常用指标如下：
- 召回率（Recall）：相关文档中被成功检索出来的比例，衡量”有没有漏检”。
- 准确率/精确率（Precision）：检索结果中真正相关的比例，衡量”有没有混入噪声”。
- 命中率（Hit Rate）/ MRR：正确片段是否出现在 Top-K、排名靠不靠前。
- 忠实度（Faithfulness）：生成答案是否完全由检索片段支撑，直接反映幻觉程度。
- 答案相关性（Answer Relevancy）：答案是否切题、是否回应了用户真实意图。
落地建议：先由业务专家构建一份 50–200 条的”标准问答评测集”，覆盖高频与边界问题；每次调整切分策略、Embedding 模型或重排方案后，跑同一套评测集对比指标变化，用数据驱动迭代，而不是凭感觉调参。
企业 RAG 常见的坑有哪些？
最常见的坑不在模型，而在”前半段”：文档切分粗糙、缺少重排、没有溯源、不做评测。这几个问题任何一个都足以让 RAG 项目”看起来能用、实际不敢用”。
按出现频率排列的高频坑：
- 切分太随意：按固定字数硬切，把完整语义切碎，导致检索召回一堆残缺片段。应按语义边界切分并设置重叠。
- 省掉重排：只靠向量检索就直接生成，相关性不够，答案飘。重排往往是性价比最高的一步。
- 没有溯源：答案无法核对，业务方一旦发现一次错误就全盘不信任。引用溯源必须从第一天就做。
- 从不评测：没有评测集，调参全凭感觉，无法判断改动是变好还是变坏。
- 盲目追求大模型：以为换更大的模型就能解决问题，实际瓶颈常在检索质量。先优化检索，再谈模型。
- 忽视数据治理：源文档本身陈旧、重复、矛盾，RAG 只会忠实地放大这些问题。“垃圾进、垃圾出”在 RAG 同样成立。
避开这些坑，企业 RAG 才能从”演示能跑”走到”业务敢用”。
企业 RAG 不是把文档丢给大模型就完事，而是一套”数据治理 + 检索工程 + 评测迭代”的系统工程。把切分、重排、溯源和评测这几件事做扎实，再结合自身数据敏感度选择私有化或云端方案，知识库才能真正成为可信赖的企业资产。趣果科技专注 LLM·RAG 集成与企业 AI 应用定制，可协助企业从场景梳理、选型到私有化落地完成全流程建设。