ARTICLE · 1159698
一文讲透 RAG:从原始文档到 AI 精准回答,究竟经历了什么?
为什么给大模型一堆资料，它还是可能答非所问？
很多人使用大模型时，都遇到过类似的问题：明明已经把企业的产品手册、技术文档、规章制度上传给 AI，甚至搭建了一个内部知识库，但当真正提问时，AI 仍然会出现答非所问、遗漏关键信息、编造内容等问题。
问题出在哪里？
首先要理解一个事实：把文档交给 AI，不等于 AI 就真正掌握了这些知识。
企业的知识通常分散在 Word、PDF、Excel、网页、数据库和各种业务系统中。这些资料不仅格式不同，还可能包含重复内容、过期信息、无关段落和复杂的表格结构。即使把资料全部交给大模型，也不意味着模型就能在每次回答时准确找到所需的信息。
这正是 RAG 要解决的问题。
RAG，全称 Retrieval-Augmented Generation，中文通常称为“检索增强生成”。它的核心思想是：先从外部知识库中检索与问题相关的信息，再把检索结果交给大模型，让模型基于这些信息生成答案。
如果把大模型比作一位能力很强的专家，那么 RAG 就像为这位专家配备了一套经过整理、可以快速查阅的专业资料库。
但 RAG 并不只是“建一个知识库，再接一个大模型”。从原始文档到最终答案，中间需要经历文档预处理、数据清洗、文本切片、向量化、召回、重排和生成等多个环节。
任何一个环节出现问题，都可能影响最终回答的质量。
下面，我们从完整流程出发，把 RAG 的原理、关键技术、常见误区和落地方法讲清楚。
一、RAG 到底是什么？为什么企业需要它？
传统大模型主要依赖训练过程中学到的知识回答问题。这些知识有一定的覆盖范围，但并不天然包含某家企业最新的内部制度、尚未公开的产品资料、客户项目记录或实时业务数据。
如果直接让模型回答这些问题，就可能出现三类困难。
第一，模型不知道企业内部的专有知识。 例如，企业规定的差旅报销标准、某个产品的特殊配置要求，模型不可能凭空准确掌握。
第二，模型的知识不一定是最新的。 企业制度、产品版本、价格政策和业务流程可能持续变化，而模型训练完成后，并不会自动获得所有最新信息。
第三，模型可能给出看似合理、实际错误的答案。 当缺乏可靠依据时，大模型有时会生成不准确的信息，也就是通常所说的“幻觉”。
RAG 通过引入外部知识检索，改善这些问题。
例如，员工询问：“公司最新的差旅报销标准是什么？”
采用 RAG 的系统，可以先检索企业最新的差旅制度，找到与住宿标准、交通方式和报销流程有关的内容，再将这些内容连同员工的问题交给大模型，由模型组织成清晰的回答，并在适当情况下标注来源。
这个过程有三个关键角色：
知识库： 保存企业文档、业务知识和其他可检索的信息。
检索系统： 根据用户问题，找到最相关的知识片段。
大模型： 理解问题，结合检索到的资料生成自然语言答案。
因此，RAG 的价值并不是简单地让大模型“知道更多”，而是让模型在回答问题时，能够及时获取与当前任务相关的外部知识。
需要注意的是，RAG 并不能自动保证答案正确。检索到的资料可能已经过期，召回的内容可能不完整，模型也可能误读资料。因此，RAG 的效果取决于整个链路，而不是某一个单独组件。
二、RAG 处理数据的七个核心步骤
从一份原始文档到一个有依据的 AI 回答，完整流程可以分成七个步骤。
第一步：文档预处理——先让机器读懂资料
企业知识通常不是以统一、干净的纯文本形式存在的。
一份 PDF 可能包含正文、表格、图片、页眉、页脚和扫描页面；一份 Word 文档可能包含标题层级、目录、批注和复杂排版；Excel 文件则可能包含多张工作表、合并单元格和跨行表头。
如果直接提取文本，可能出现段落顺序混乱、表格关系丢失、图片中的文字无法识别等问题。
因此，在正式处理知识之前，需要先完成文档解析。
主要工作包括：
识别文档格式，例如 PDF、Word、Excel、HTML 和 TXT。
提取正文、标题、表格及必要的图片文字。
尽可能保留章节结构、页码、表格关系等信息。
统一编码、格式和文本表达方式。
为文档记录名称、版本、来源、更新时间等元数据。
特别需要注意表格。
例如，原始资料中有这样一张表：
如果解析时把表头和数据拆散，或者没有保留职级与标准之间的对应关系，后续检索就可能将不同职级的规定混在一起。
所以，文档预处理不只是格式转换，更重要的是尽可能保留原始资料中的语义和结构关系。
这一步的输出，是结构化程度更高、能够继续处理的文档内容。
第二步：数据清洗——去掉噪声，保留有效知识
完成文档解析后，并不意味着所有提取出来的内容都值得进入知识库。
原始文档中可能包含大量干扰信息，例如：
重复的页眉、页脚和目录。
与正文无关的广告、导航栏和版权声明。
重复段落、乱码和无效字符。
已经废弃的制度或过期的产品资料。
因文档转换而产生的错误内容。
这些信息如果未经处理就进入知识库，可能干扰后续检索。
例如，某份产品手册每一页都重复出现“某某科技有限公司官方网站”，如果系统将这些内容切分成大量独立片段，检索结果就可能被无关信息占据。
数据清洗的目标，是提高知识内容的有效性。
但清洗并不是删得越多越好。
真正重要的不是让文档变短，而是让有用的信息更容易被找到。
尤其在企业场景中，不能简单删除所有重复内容。重复出现的安全告警、制度条款或者业务记录，有时可能具有不同的时间、来源和适用范围，需要根据业务语义决定是否合并。
另外，过期信息不一定应该直接删除。对于需要追溯历史制度、分析历史项目的场景，可以保留历史版本，并明确标注生效时间、失效时间和适用范围。
这一步最终输出的是高质量、可追溯的干净数据。
第三步：文本切片——把长文档拆成适合检索的知识单元
这是 RAG 中非常关键的一步，也是很多系统效果不理想的重要原因。
假设企业有一份 200 页的产品技术手册。用户提问：“这个产品支持哪些身份认证方式？”
如果系统每次都把整份手册交给大模型，不仅会消耗大量上下文资源，还可能因为内容过长而遗漏重点。
因此，需要将长文档切分成较小的文本片段，也就是 Chunk。
但问题来了：每个片段应该有多长？
切得太大，一个片段里可能包含多个不相关主题，检索时容易引入噪声；切得太小，原本完整的语义关系又可能被破坏。
例如，原文写道：
“管理员可以通过多因素认证登录系统。普通用户的认证方式由企业管理员统一配置，具体支持范围以当前版本的产品配置说明为准。”
如果切片时将第一句话和第二句话分开，检索系统可能只找到“管理员可以通过多因素认证”，却遗漏普通用户的适用条件和版本限制。
因此，文本切片需要兼顾语义完整性与检索粒度。
常见方式包括：
1. 固定长度切片
按照字符数、Token 数量等设定切片大小。
优点是实现简单、处理效率高；缺点是可能在句子、段落甚至语义关系中间强行截断。
2. 按自然结构切片
优先按照章节、标题、段落、句子等自然边界切分。
这种方式有助于保留原文的语义结构，比较适合规章制度、产品手册和技术文档。
3. 语义切片
根据文本内容的语义变化决定切分位置，尽量让每个片段围绕一个相对完整的主题。
这种方式更灵活，但实现复杂度通常更高。
4. 重叠切片
相邻片段保留一部分重复内容，降低关键语句被切断后无法完整检索的风险。
例如，前一个片段覆盖第 1—10 段，后一个片段覆盖第 8—17 段。重叠范围应结合文档类型和检索效果调整，而不是越大越好。
在企业知识库中，还应考虑为每个片段保留标题路径、文档名称、页码、版本和来源等信息。
这样，当系统检索到某个片段时，不仅能找到正文，也能知道它属于哪份资料、哪一章节，以及适用于什么业务条件。
切片的核心原则是：让每个知识片段既足够完整，又足够聚焦，还能追溯到原始出处。
第四步：向量化——把文本转化成机器可比较的语义表示
完成切片后，下一步是向量化，也就是 Embedding。
计算机当然可以直接比较两个字符串是否相同，但用户的问题和文档内容通常不会使用完全一致的词语。
例如，知识库写的是“如何重置用户凭据”，用户问的是“账号密码忘了怎么办”。
两句话用词不同，但表达的意图可能非常接近。
Embedding 模型可以将文本转换成一组数值，也就是向量。语义上相近的文本，在合适的向量空间中通常会呈现出更接近的表示。
假设用户的问题是：
“账号密码忘记了，怎么处理？”
知识库中有三个片段：
A：用户密码重置操作指南。
B：公司年度市场推广计划。
C：服务器硬件采购标准。
虽然用户没有直接使用“密码重置”这几个字，但语义检索仍有机会将 A 排在前面。
向量化的主要作用，就是为后续语义检索提供基础。
在技术实现上，系统通常会使用 Embedding 模型分别处理知识片段和用户问题，再通过向量索引进行近邻搜索。
这里有两个容易被忽略的问题。
第一，向量模型不是越大越好。 需要结合中文能力、专业术语、行业语料、部署成本和检索效果进行评估。
第二，向量相似不等于事实正确。两个片段在语义上接近，不代表它们的结论相同，更不代表它们都适用于当前问题。
因此，向量检索应当被视为筛选候选知识的一种手段，而不是判断事实真假的最终标准。
第五步：召回——从海量知识中找到可能相关的内容
完成向量化后，系统已经建立了可检索的知识索引。
当用户提出问题时，RAG 就进入在线检索阶段。
例如，用户询问：
“企业版支持哪些身份认证方式？如何开启？”
系统会对问题进行必要的预处理，然后从知识库中寻找相关片段。
常见检索方法主要有两类。
第一类：关键词检索。
根据用户问题中的词语、专业术语、产品型号、错误码等进行匹配。经典方法包括 BM25。
这种方式对于精确名称、编号和特定术语往往很有价值。
第二类：向量检索。
根据问题和知识片段的语义相似程度，找到表达不同但含义相近的内容。
这两种方式各有优势。
例如，用户搜索“QVD-2026-65008”，关键词检索可能更容易找到完全匹配的漏洞编号；而用户搜索“这个漏洞会不会导致管理员权限泄露”，语义检索则有机会找到描述相同风险但措辞不同的技术报告。
因此，很多实际系统采用混合检索，将关键词检索与向量检索结合起来，再对结果进行合并和排序。
召回阶段还需要确定返回多少个候选片段，也就是 Top K。
如果只召回少量内容，可能遗漏关键证据；如果召回过多内容，则可能引入大量无关信息，增加后续模型的处理负担。
Top K 没有适用于所有场景的固定答案，需要通过实际问题集测试和调整。
另外，召回结果还应考虑访问权限、文档有效期、业务范围等条件。
例如，员工只能查询自己有权限访问的制度和项目资料。即使某份文档与问题高度相关，只要用户无权访问，就不应该被返回给模型。
召回的目标不是找到最多的内容，而是尽可能找到足够完整、真正相关、允许当前用户访问的证据。
第六步：重排——从“看起来相关”到“真正更相关”
召回阶段通常优先考虑检索效率，因此返回的候选内容中，可能既有高度相关的片段，也有主题接近但不能直接回答问题的片段。
这时就需要重排，也就是 Rerank。
可以把召回理解为初步筛选，把重排理解为更精细的复核。
例如，用户问：
“企业版如何开启多因素认证？”
初步召回可能得到以下结果：
多因素认证配置说明。
普通用户登录指南。
企业账号创建流程。
多因素认证的安全原理。
历史版本的认证配置说明。
这些资料都可能与认证有关，但相关程度、时效性和回答价值并不相同。
重排模型可以进一步结合问题和候选文本，判断每个片段是否真正有助于回答当前问题，并重新排列优先级。
经过重排后，系统可能优先保留当前版本的配置说明、具体操作步骤和必要的适用条件。
常见重排方式包括基于规则的排序，以及使用专门的 Reranker 模型进行相关性评分。
规则可以考虑文档版本、生效时间、业务类型和权威来源；模型则可以进一步判断问题与文本之间的语义关联。
需要注意，重排不能弥补所有召回缺陷。
如果真正有用的内容根本没有进入候选集合，重排模型就无法把它排到前面。
因此，排查 RAG 效果时，应该先确认正确答案是否被召回，再检查它是否被重排到合适的位置。
第七步：生成——让大模型基于检索证据回答问题
经过前面六个步骤，系统终于获得了一组相对相关的知识片段。
接下来，RAG 将用户的问题、检索到的资料以及必要的回答约束组合起来，交给大模型生成最终答案。
例如，系统提供给模型的内容包括：
用户问题：企业版如何开启多因素认证？
相关知识：当前版本的配置路径、启用条件和操作步骤。
回答要求：依据提供的资料回答；说明适用范围；必要时引用文档来源；没有明确依据时，不要自行编造。
大模型再对这些信息进行理解、归纳和组织，生成用户能够看懂的自然语言答案。
这一步不仅是把检索片段拼接起来，更涉及问题理解、上下文整合、冲突处理和表达组织。
一个高质量的 RAG 系统，还应尽可能提供答案来源，让用户能够回到原始文档进行核验。
如果检索到的资料不足以回答问题，系统应该明确说明缺少哪些信息，而不是为了让回答显得完整，就自行补充未经证实的结论。
如果检索结果中存在相互冲突的制度版本，也不能简单地把所有内容混在一起。系统需要结合生效日期、权威来源和业务适用条件进行判断；无法确定时，应当提示用户进一步确认。
这里还有一个关键事实：RAG 并不会因为提供了参考资料，就自动消除大模型幻觉。
模型仍可能忽略上下文、错误理解证据，或者在回答时引入资料中没有的信息。因此，需要通过提示词约束、来源引用、答案验证和拒答机制等方式进一步提高可靠性。
三、把七个步骤串起来：RAG 实际上分为两条链路
理解 RAG，不能只看七个步骤，还需要区分知识入库和问题回答两个阶段。
第一条链路：离线知识处理。
原始文档 → 文档预处理 → 数据清洗 → 文本切片 → 向量化 → 建立检索索引。
这条链路负责将分散、复杂的原始资料加工成可检索的知识资产。
在部分系统中，关键词索引、结构化元数据索引也会同步建立。知识库更新时，还需要处理增量入库、重复文档、版本替换和失效内容。
第二条链路：在线问答。
用户提问 → 问题处理 → 检索召回 → 结果重排 → 构造上下文 → 大模型生成 → 答案校验与返回。
这条链路负责根据用户的具体问题，从已经建立的知识索引中找到合适的内容，并组织成答案。
两条链路相互配合，但不能混为一谈。
例如，用户反馈“AI 找不到最新的产品说明”，问题可能出在知识入库：最新文档根本没有进入索引。
如果用户反馈“AI 找到了资料，却引用了错误的操作步骤”，问题则可能出在检索、重排、版本选择或生成环节。
只有把整个过程拆开观察，才能真正定位问题。
四、为什么有些企业建了 RAG，回答效果仍然不理想？
RAG 的技术流程并不复杂，但想让它在真实业务中稳定运行，需要解决不少工程问题。
1. 文档解析不准确，知识从入库时就已经出错
如果表格结构丢失、扫描文字识别错误、标题与正文错位，那么后续再好的向量模型也无法恢复全部原始信息。
解决办法是针对不同文档类型选择合适的解析方式，并对重要文档进行质量抽检。
2. 文本切片不合理，关键上下文被拆散
切片过大，容易引入噪声；切片过小，又可能破坏条件、例外和上下文之间的关系。
解决办法是结合文档结构、问题类型和实际测试结果调整切片策略，必要时采用父子切片或多层级检索。
3. 检索方式单一，关键词和语义无法兼顾
单纯依靠向量检索，可能漏掉精确编号、型号或特殊术语；单纯依靠关键词检索，又可能无法识别不同措辞背后的相同意图。
解决办法是根据业务场景评估关键词检索、向量检索和混合检索，而不是盲目追求某一种技术。
4. 检索结果不够准确，噪声影响大模型判断
即使正确资料被召回，如果排名靠后，或者大量无关内容占据上下文空间，模型也可能遗漏真正重要的信息。
解决办法是优化召回参数、使用重排模型，并针对复杂问题评估多轮检索、查询改写等技术。
5. 知识更新不及时，系统引用了过期信息
企业知识并不是一成不变的。制度、价格、产品版本和业务流程都会更新。
如果新文档没有及时入库，或者旧版本没有被正确标记和管理，RAG 就可能检索到已经失效的内容。
解决办法是建立知识更新、版本管理、有效期控制和失效文档处理机制。
6. 只关注答案是否流畅，不验证答案是否正确
一段回答写得专业、结构清晰，并不代表它符合原始资料。
企业需要对 RAG 建立专门的评估体系，分别检查检索和生成质量。例如，正确资料有没有被召回、相关内容排名是否合理、答案是否有证据支持、引用是否准确、无答案时能否正确拒答。
对于涉及财务、法律、医疗、生产控制和安全运维等高风险场景，还需要根据业务风险设置人工复核和权限控制机制。
归根结底，RAG 的效果不是简单由模型参数决定的，而是由数据质量、检索质量、生成质量和工程治理共同决定的。
五、RAG 不只是一个技术组件，更是企业知识工程
很多企业在建设 RAG 时，容易把注意力集中在向量数据库、Embedding 模型和大模型选型上，却忽略了更基础的问题：企业究竟拥有哪些知识？这些知识是否准确？由谁维护？哪些人可以访问？不同版本之间如何处理？
这些问题看起来不像模型技术那么新鲜，却直接影响 RAG 能否真正创造业务价值。
例如，一家制造企业建设售后知识库，需要整合产品说明书、维修手册、历史故障记录和服务规范。如果只是把所有文件上传进去，系统可能同时检索到多个产品版本的维修方案。
更合理的做法，是在文档处理阶段保留产品型号、版本号、适用设备、发布日期和故障类型等元数据，在检索时结合用户权限和具体产品条件进行筛选。
再比如，一家网络安全企业建设漏洞知识库，可以整合漏洞公告、技术分析、检测规则、修复建议和历史处置记录。检索时，除了考虑语义相似度，还需要重视漏洞编号、受影响版本、补丁状态和信息来源。
这说明，企业 RAG 的建设不仅涉及算法，还涉及知识治理、数据工程、业务流程和安全管理。
此外，RAG 也有自身的局限。
对于需要复杂计算、实时查询交易数据、执行跨系统操作或者完成多步骤业务任务的场景，单纯的知识检索可能不够，需要结合数据库查询、业务 API、工具调用甚至 Agent 工作流。
例如，查询“公司差旅报销制度是什么”，适合通过 RAG 检索制度文档；查询“我这个月还剩多少差旅预算”，则可能需要访问实时业务数据库；如果要进一步完成预算核对、申请单填写和审批提交，还需要接入业务系统及相应的权限控制。
因此，RAG 更适合被理解为企业 AI 的知识获取能力，而不是解决所有业务问题的万能方案。
六、企业如何评估一个 RAG 系统是否真正有效？
不要只问“回答看起来怎么样”，而应该建立可量化的评估方法。
可以从四个层面展开：
第一，知识处理质量。 检查文档解析准确率、表格信息保留情况、切片完整性、知识更新时效和元数据完整性。
第二，检索质量。 检查正确答案对应的知识片段是否能够被召回，重点关注 Recall@K、MRR、NDCG 等检索指标。
第三，生成质量。 检查答案的事实准确性、证据支持程度、引用正确性、问题覆盖率，以及无可靠依据时的拒答能力。
第四，业务效果。 关注用户解决问题所需时间是否缩短、人工重复咨询是否减少、业务处理效率是否提升，以及错误回答带来的风险是否得到控制。
在具体实施时，建议先建立一套具有代表性的测试问题集，覆盖常见问题、复杂问题、模糊问题、跨文档问题、版本冲突问题和无答案问题。
然后在每次调整切片策略、检索模型、重排模型或提示词之后，使用同一套测试问题进行对比。
这样才能知道系统究竟是变好了，还是只是回答得更像那么回事。
结语：RAG 的竞争力，最终取决于知识能否转化为可靠答案
从原始文档到 AI 回答，RAG 看起来是一条由七个步骤组成的技术流水线：文档预处理、数据清洗、文本切片、向量化、召回、重排、生成。
但真正理解 RAG 后会发现，它解决的并不只是一个检索问题，而是如何把分散在企业内部的文档、数据和经验，转化为大模型可以按需获取、理解和使用的知识。
文档处理决定知识能否被正确提取，数据清洗影响知识质量，文本切片决定知识单元是否完整，向量化提供语义检索能力，召回负责找到候选证据，重排负责提高相关性，生成则将这些证据组织成最终答案。
这七个环节相互关联，任何一个环节出现问题，都可能影响最终效果。
对于企业而言，建设 RAG 不能止步于“把文档上传到知识库”，更不能把希望全部寄托在更换一个大模型上。
真正值得投入的，是高质量知识治理、合理的检索架构、持续的效果评估，以及与企业业务场景的深度结合。
大模型决定 AI 能力的上限之一，而知识质量与检索能力，决定了它在具体业务中能否真正发挥作用。
让 AI 不仅会回答问题，还能依据企业知识给出准确、可靠、可追溯的答案，这才是 RAG 真正的价值所在。
end
推荐阅读
