2026-09-21

RAG 是什么：企业知识库问答怎么做

RAG 是什么？本文从适用场景、数据治理、文档切块、混合检索、重排序到效果评估，系统讲解企业知识库问答如何落地。

一、先判断是否该用 RAG：它解决的是知识供给，不是所有智能化问题

企业评估 RAG 时，首先要确认问题是否真的出在“模型拿不到正确资料”。RAG 的核心作用，是在回答前从外部知识源选取相关内容，再让模型基于这些内容组织结论。它适合补充企业内部知识和时效性信息，但不能替代计算系统、业务流程或数据治理。

一个场景是否适合采用 RAG，可以先检查三个条件。第一，答案依赖企业私有信息，或者所需知识会频繁变化，例如制度文件、产品手册、项目记录和内部案例。第二，问题存在可供查证的资料依据，而不是只能依靠主观判断。第三，业务要求说明结论来自哪里，用户需要查看原文、版本或发布日期。三个条件大体成立时，把知识保留在外部资料库中并按需检索，通常比将知识固化进模型参数更容易更新，也更便于追溯。

反过来，如果答案来源不明确，企业长期没有沉淀相关材料，或者不同文档之间本身相互矛盾，引入 RAG 只会更快地暴露知识缺口。向量索引能够帮助寻找内容，却不能创造不存在的事实，也不能自动判断哪一份冲突文件具有最终效力。此时应先补齐资料、确定责任部门和版本规则，而不是直接建设检索链路。

这些方案并不互斥。例如，客服助手可以用 RAG 查找售后政策，用订单接口读取当前状态，再通过工作流发起申请。关键是把“知识问答”和“确定性操作”分开：模型可以解释规则，但金额计算、权限校验和交易提交应由可测试的程序完成。只把所有能力都接到向量数据库上，容易产生看似完整、实际不可执行的回答。

超长上下文同样不能消除检索的必要性。将大量文件整体放入提示词，看似减少了检索环节，实际会扩大输入成本，并把无关章节、重复版本和冲突表述一并交给模型。长文本中的关键信息还可能因位置和噪声而未被充分利用。对企业系统而言，更稳妥的组合是先缩小资料范围，再使用较长上下文完成跨段落比较、摘要和推理。

是否采用 RAG，最终可以归结为一个工程问题：答案能否在受控资料中找到，并且是否值得为这些资料建立更新、权限、引用和评估机制。如果问题没有可验证的标准答案，应设计人工判断或专家审核；如果流程必须严格执行，应调用规则引擎、数据库和接口；如果知识源残缺，则先治理内容。只有当主要瓶颈确实是“正确资料没有在正确时间进入模型上下文”时，RAG 才是对症方案。

二、数据治理先于向量化：知识库质量决定答案上限

向量模型只能判断文本是否相近，不能替企业裁决哪份文件有效。若知识库同时保存现行制度、历史版本和未经审核的经验记录，检索越充分，冲突内容反而越容易一起进入上下文。上线前应先解决知识来源、适用范围和生命周期问题，再讨论嵌入模型与向量库。

先给知识源排优先级

第一步不是导入文件，而是建立知识源清单。每类来源都要明确责任部门、更新方式、审核状态和冲突处理规则。权威等级不宜简单按文件格式划分，而应依据业务场景确定。例如，正式制度通常高于个人笔记；产品规格应以已发布版本为准；FAQ 可以解释标准文档，但不应覆盖其中的约束条件；工单适合补充案例，不应自动成为通用结论。

元数据不是装饰，而是检索边界

字段值应使用受控枚举，避免同一部门或产品出现多种写法。这些信息一方面用于检索前过滤，另一方面支撑引用展示、访问授权和过期治理。

否则，一份文字高度相似但适用于其他市场的规定，很可能排在正确答案之前。

入库要保留文档结构与证据位置

企业文档不能直接抽取成连续纯文本。可靠的入库流水线通常需要处理以下环节：

• 识别正文区域，清除重复页眉、页脚、水印和目录噪声；
• 保留章节标题及父子层级，使片段仍能解释自身所处语境；
• 解析表格的行列关系，关联正文中的附件、图示和脚注；
• 检测跨文件或跨页面的重复内容，避免同一结论挤占召回结果；
• 记录文件标识、页码、段落路径和字符区间，便于回到原文核验。

解析质量应通过抽样验收，而不是只看任务是否成功。重点检查表格是否错位、标题是否丢失、附件是否断链，以及否定条件、例外条款是否被切散。只保留语义文本却丢失原始位置，会让引用看似存在，实际无法审计。

让索引状态跟随源系统变化

RAG 可以在不调整模型参数的情况下更新外部知识，但“可更新”不等于“自然一致”。入库流程必须覆盖新增、修订、失效、撤回和删除，并为每次变更保存来源标识、处理时间与索引状态。

工程上还应设置同步延迟、解析失败、版本并存和孤立片段等监控项，并定期从源系统反查索引。判断数据治理是否合格，可以用一个直接标准：任何答案片段都能说明来自哪里、适用于谁、何时有效，并能在源文档撤回后按约定时限停止被召回。

三、切块与索引设计：不要用一个固定参数处理所有文档

切块不是把长文本裁成模型能接收的长度，而是为检索构造可独立判断、可准确引用的知识单元。真正需要优化的问题是：用户提出一个具体问题时，系统能否召回包含完整条件、结论与适用范围的片段。若只按固定字数截断，条款中的例外说明、操作步骤的前置条件、表格中的字段含义都可能被拆开。

块太大时，检索结果可能命中主题，却把大量无关段落一并送入模型，相关证据反而被稀释；块太小时，召回内容看似精确，却缺少条件、例外或结论，模型只能自行补足缺口。相邻块重叠可以减少句子恰好落在边界上的问题，但无法修复错误的文档结构。例如，一条制度的正文与但书被分到两个片段，即使设置重叠，也未必能保证两者同时进入候选集。

工程实践中常从数百 token 量级设置多组候选块长，并配置一定的相邻重叠，再用真实问题集比较效果。这些参数只能作为实验入口，不是跨文档通用的最佳配置。更稳妥的实现是先识别标题层级、列表、条款、问答对和表格，再对过长的语义单元做二次切分；过短片段则可与父级摘要或标题路径组合后参与检索。

索引也不应等同于“文本加向量”。每个知识片段至少应保存以下信息：

• 可供生成模型阅读的正文，以及经过规范化的检索文本；
• 文档标题、章节层级和父子片段关系；
• 稳定的文档标识、片段标识与原文页码或段落位置；
• 发布时间、更新时间、有效状态和业务版本；
• 部门、角色、密级等权限标签；
• 关键词、实体或其他可用于过滤和关键词检索的字段。

向量适合发现语义近似内容，但对精确编号、产品型号、缩写、日期和专有名词未必稳定。因此，正文倒排索引、结构化过滤条件与向量字段应并存。标题路径还能在生成阶段补足语境，例如同样名为“审批条件”的片段，位于采购制度和费用制度时含义并不相同。

最后，索引必须具备重建和回滚能力。每次发布应记录原始文档批次、解析器版本、切块规则、文本清洗逻辑、Embedding 模型及索引配置，并保留片段到原文的映射。模型升级后若召回率下降，团队才能判断问题来自文档解析、块边界变化、向量表示变化，还是索引过滤配置。没有版本记录的知识库一旦效果波动，通常只能全量重做，难以完成可验证的修复。

四、从用户问题到有效召回：用混合检索解决“搜不到”和“搜不准”

企业 RAG 的在线链路不应从向量查询直接开始。用户输入往往不是一个合格的检索式：它可能省略产品名称，把错误现象写成口语，沿用上一轮对话中的指代，或者混入版本、地区、岗位等隐含条件。若原问题未经处理就送入索引，后续即使增加召回数量，也只会得到更多表面相似、实际不适用的文本。

第一步应把对话输入整理成可独立理解的问题。查询处理模块需要提取用户真正要完成的任务，并补齐对象范围、适用版本、时间条件和用户身份。例如，“这个报错怎么处理”应结合会话历史还原为具体产品、版本和错误码。缩写、内部别名和口语称呼可以映射到知识库中的标准术语，但原始词也应保留，避免改写时丢失精确线索。

复杂问题不宜强行压成一个检索式。若问题同时要求查规则、找数据并比较差异，可拆成若干子查询分别召回，再在生成阶段合并证据。拆分的价值不是让问题变短，而是避免多个检索目标互相干扰。实施时应保留子查询与原问题的对应关系，否则模型可能只回答其中一部分。

因此，企业知识库通常应并行执行向量检索和 BM25，再用排名融合汇总候选，而不是只选其中一种。包含错误码、型号或条款编号时，可提高关键词结果的影响；故障描述、流程咨询等自然语言问题，则可适当偏向语义召回。还要做候选去重，避免同一文档的相邻切块占满上下文。

用户所属组织、访问级别、业务地区、产品版本以及文档有效期，都应成为索引元数据。检索时先限定可用范围，再在范围内计算相关性。否则，系统可能召回内容正确但用户无权查看的文件，或引用已经废止、尚未生效、仅适用于其他地区的规定。仅在提示词中要求模型“不要泄露”不能替代访问控制。

• 检查“搜不到”：目标证据是否进入索引，查询是否被错误改写，关键词与语义通道是否至少有一路命中。
• 检查“搜不准”：高排名结果是否满足产品、版本、地区、时效和权限条件，而不只看文本相似度。
• 记录召回轨迹：保存原问题、改写结果、子查询、过滤条件及各通道排名，便于复现失败案例。

对于需要沿多个实体关系查找证据，或要求从大量文档归纳整体主题的问题，可以评估 GraphRAG。它通过实体与关系组织知识，更适合跨文档关系链和全局分析，但代价包括实体消歧、关系更新、图查询维护以及更长的响应链路。工程上应先用问题集验证普通 RAG 的缺口：如果失败主要来自查询改写、过滤条件或混合检索配置，建设图结构不会解决根因。只有当核心问题确实依赖多跳关系或全局结构时，额外复杂度才可能值得承担。

五、重排序与答案生成：避免“召回了资料，仍然答非所问”

检索命中并不等于证据可用。第一阶段检索更像“扩大排查范围”：宁可带回少量噪声，也不要过早漏掉关键材料。真正决定哪些内容进入模型上下文的，应是后续重排序。Reranker 会联合读取用户问题与候选文档块，重新判断两者是否语义匹配，而不是继续依赖向量距离。

企业语料规模较大时，不宜让计算成本较高的精排模型扫描全部内容。更可控的做法是级联处理：先用关键词检索、向量检索等方式快速取得较宽的候选集合，再由轻量模型排除明显无关项，最后通过 Cross-Encoder 一类模型做精细排序。每一层都应记录候选数量、耗时与淘汰原因，便于判断质量损失发生在哪个环节。

重排序不能只看“主题相近”。例如用户询问某项制度的生效条件，一段介绍制度背景的文字可能语义高度相关，却无法回答条件是什么。评分时应额外考虑以下因素：

• 内容能否直接支持问题所要求的结论，而非仅仅出现相同主题；
• 资料是否处于有效期内，版本、地区和适用对象是否一致；
• 来源层级是否可靠，例如正式制度文件应优先于会议纪要或个人笔记；
• 文档块是否包含完整条件、例外条款和限定范围，避免只取到半句结论。

进入生成阶段前，还需要一次上下文编排。按相关性分数机械拼接，常会造成同一段内容重复出现、条款与标题分离，或把解释文字放在规则正文之前。工程上应先消除重复片段，将连续且属于同一章节的块合并，再补入标题、文档版本、发布时间以及理解当前段落所必需的前文。若令牌预算不足，应优先保留能够直接作答、来源明确且时效正确的材料，而不是平均压缩所有候选。

生成提示应被当作一份可测试的回答协议，而不是一句“请根据资料回答”。对影响审批、合规或业务执行的结论，还应附带原文片段及文档位置，使使用者可以回到来源复查。

引用本身也需要校验。模型生成的引文编号必须对应实际进入上下文的材料，引用片段应确实支持相邻结论，不能只证明相关背景。

出现错误答案时，先定位故障层级，再决定改哪里。把所有问题归因于“大模型不够强”，通常会导致无效调参。

因此，这一阶段的验收不应只看最终回答“像不像对的”。还要分别检查正确证据是否进入候选集、精排是否把它提升到可见位置、上下文是否保留完整语义，以及结论能否逐项追溯到证据。只有把这条链路拆开观测，答非所问才会从偶发体验问题变成可以定位和修复的工程问题。

六、答案评估与运营闭环：分别测检索、生成和业务结果

RAG 评估不能从模型自拟的问题开始。每条样本除参考答案外，还要标注作答所需的证据、答案适用的产品或时间范围、访问权限，以及是否应当拒答。否则，系统可能给出内容正确但版本不对、越权或缺少前提的回答，综合得分却看不出问题。

样本覆盖面比样本数量更重要。至少要纳入简称与别称、输入错误、上下文省略、多轮追问、新旧制度冲突、不同角色权限、需要合并多份材料才能回答的问题。还应专门建设不可回答集，例如知识库尚未收录、问题条件不足、证据相互矛盾或用户无权查看的内容。拒答不是异常分支，而是企业问答的基本能力。

正确证据未进入候选集，通常应检查查询改写、索引或召回策略；证据已召回却没有进入最终上下文，问题更可能出在重排序或上下文拼装；上下文完整但答案错误，则应继续检查提示约束、引用机制和模型生成。只有分层记录，失败才能被归因，而不是被笼统归为“模型效果不好”。

引用也要单独核验。回答附带来源，并不等于来源支持结论。评估时应检查引用片段是否真的包含对应事实、是否指向当前有效版本，以及一条引用是否被错误地用于支撑多个结论。能够定位到具体知识片段的价值，不只是方便用户核查，也让团队可以反向找到过期、冲突或表述含糊的原始材料。

离线评测用于比较方案，例如调整切块边界、替换检索方法或修改排序规则后，观察各类问题的变化；线上数据则用于判断系统有没有产生业务收益。两者不能互相替代：离线命中改善，不代表用户更快解决问题；人工转接减少，也可能只是用户放弃继续提问。因此应结合会话完成情况、后续追问和负面反馈分析。

运营闭环的核心是建立可归因的失败队列。知识缺失或冲突回流到内容治理，问法未被理解进入查询改写，语义被截断进入切块优化，目标材料未出现进入召回调整，相关材料排序靠后进入重排序处理，有证据仍答偏则进入上下文组织与提示策略优化。每个案例应保留问题、权限、知识版本、召回结果、最终上下文和模型输出，避免只保存一段错误答案。

任何变更上线前都应运行固定回归集，并按问题类型查看差异。局部参数可能修复某类问法，却让旧版本识别、权限隔离或多文档回答退化。成熟的 RAG 运营不是不断调高一个分数，而是让每次失败都有归属、每次修改都能验证、每次上线都知道改善了什么，又可能影响什么。

七、FAQ：企业建设 RAG 时的常见问题

有了超长上下文，还需要 RAG 吗？

需要，但两者不是替代关系。上下文窗口变长，解决的是模型单次能够接收多少材料；RAG 解决的是从企业知识中挑出哪些材料值得送入模型。若把大量文档直接塞进提示词，工程上可能增加处理负担，并影响权限管理和证据利用。长文本中部的信息也可能较难被模型稳定利用，即常说的“中间信息丢失”。

更稳妥的做法是先通过 RAG 缩小证据范围，再让长上下文承担跨章节阅读、多文档比较和复杂归纳。只有在资料集合较小、内容相对固定、单次任务确实需要通读全文时，直接使用长上下文才可能更简单。例如分析范围明确的合同材料，可以整体输入；从大规模合同库中回答条款问题，则应先检索。

RAG、微调和企业搜索应该怎样选择？

先区分要改变的是知识、行为，还是信息获取方式：

实际项目常组合使用：搜索负责发现与导航，RAG 基于证据生成解释，微调约束模型的任务行为。不要因为“回答不准”就直接微调；如果根因是资料缺失或检索失败，训练无法补回正确证据。

向量检索命中了相似内容，为什么答案仍然不对？

“语义相似”不等于“可用于作答”。命中的片段可能主题一致，却在产品版本、适用地区、客户等级或生效时间上不符合问题；也可能只召回结论，遗漏定义、例外条件和上下文。另一类问题发生在生成阶段：证据已经存在，但排序靠后，被无关片段干扰，或者模型把多个来源错误拼接。

排查时应分层查看链路，而不是只读最终答案：

• 先确认正确文档是否进入候选集；没有进入，检查切块、查询改写、关键词召回和元数据过滤。
• 再确认正确片段是否排在模型实际可见的位置；排序不佳时，引入重排序并降低重复片段占比。
• 最后检查答案是否严格受证据约束；要求给出来源、区分事实与推断，并在证据不足时明确拒答。

企业 RAG 上线前至少要评估哪些指标？

不能只用“回答看起来不错”验收。应建立来自真实业务问题的测试集，并把指标拆成三层：

• 检索层：正确证据能否进入候选结果、排序是否靠前、权限与时间等过滤条件是否准确、召回内容是否存在大量重复。
• 生成层：答案是否得到证据支持、引用能否对应原文、是否完整覆盖问题、证据不足时能否拒答，以及是否出现无依据补充。
• 业务层：任务完成率、人工转接情况、用户修正频率、响应时延与单次调用成本。

上线后持续收集低评分、追问与人工改写记录，判断问题究竟出在知识源、召回、排序还是提示与生成。只有能定位错误所在环节，RAG 才具备可运营性，而不是一次性的演示系统。