2026-09-22

RAG 是什么技术：企业知识库问答怎么实现

RAG 是什么技术？本文从文档处理、索引召回、查询重排序、答案生成、效果评估与权限治理出发，系统讲解企业知识库问答如何实现及生产化落地。

一、企业是否应该采用 RAG：先判断问题，而不是先选向量数据库

判断是否需要 RAG，首先要看知识如何变化、答案能否追溯，以及不同用户可见的内容是否一致。向量数据库、嵌入模型和重排序器只是实现组件，不能替代场景判断。若问题本身不需要外部知识检索，提前搭建复杂索引只会增加维护环节。

RAG 更适合承载“持续变化且必须有依据”的事实知识。典型场景包括内部制度咨询、产品故障支持、工程文档查询、合同与合规条款核验。这些内容往往没有进入通用模型的训练数据，或者在模型训练完成后仍频繁修订。此时，系统应在每次请求发生时读取当前有效资料，并保留答案与原文之间的对应关系，而不是试图让模型永久记住企业事实。

长上下文与 RAG 并非替代关系。对于几份固定材料的总结、比较或审阅，将全文直接交给模型通常更简单。但随着资料规模扩大，完整塞入上下文会带来更多 token 消耗，也可能使关键信息被大量无关内容稀释。若还要按部门、项目或密级过滤资料，检索层就成为必要的控制点。常见做法是先召回少量高相关证据，再让模型在较长上下文中完成综合分析。

微调也不应被当作企业知识更新通道。制度版本、价格规则或产品参数一旦变化，重新准备样本并训练模型既慢，也难以确认旧事实是否被彻底覆盖。微调更适合统一措辞、输出字段、拒答方式和任务流程。较稳妥的分工是：RAG 负责提供可更新、可引用的事实，微调或提示工程负责约束模型如何使用这些事实。

GraphRAG 则适用于另一类难题：答案并不直接存在于某个段落中，而要把分散文档里的人员、组织、设备、事件等关系串联起来。Microsoft Research 的相关工作展示了以实体关系图支持跨资料推理的路径。但图谱抽取需要处理实体消歧、关系校验和增量维护，查询链路也更长。因此，除非评测已经证明向量检索在多跳问题上存在稳定缺口，否则不应把 GraphRAG 作为默认架构。

立项前可以用四个问题做快速筛选：知识是否经常更新，回答是否必须附带来源，资料是否需要按用户权限隔离，单次问题是否只涉及文档中的局部内容。多数答案为“是”时，RAG 通常值得投入；若只是偶发地处理少量固定文本，先采用长上下文往往更经济。架构选择应从答案责任和知识生命周期出发，而不是从数据库类型出发。

二、文档处理：多数 RAG 问题在检索前就已经产生

RAG 的离线处理不能被简化为“抽取文字、切成几段、计算向量”。检索系统只能使用已经进入索引的信息：标题关系被破坏、表格字段错位、旧制度未下线，后续即使更换检索算法或大模型，也只能在失真的语料上寻找答案。工程上应先建立统一的数据接入流水线，再讨论索引参数。

第一步是将不同来源转换成统一但不失结构的中间格式。PDF、Word、网页、邮件、工单与数据库记录的存储形式不同，解析后至少要区分正文、标题、列表、表格、附件和分页位置。扫描版文件需要先执行 OCR，并保留页码或区域坐标，便于定位原文。表格不能简单按视觉顺序拼成一串文本，否则模型可能无法判断某个数值对应哪一列；更稳妥的做法是让表名、列头、行标识与单元格内容形成可独立理解的记录。

第二步是清洗，但清洗目标不是让文本“看起来整齐”，而是消除会误导检索的内容。页眉、页脚、版权模板、导航菜单和邮件签名可能在每页重复出现，容易因高频而占据召回结果；乱码和解析残片会降低关键词与向量表示的质量；重复文件、过期页面及失效条款则可能让系统给出已经不适用的结论。删除前应保留原始文件及处理记录，以便出现争议时复现数据链路。

每个文档和文本块还应携带可用于判断适用范围的元数据，例如来源地址、文件标识、版本号、发布与生效日期、归属部门、保密等级、适用产品及解析时间。元数据不是附加说明，而是后续检索过滤、答案引用、增量更新和访问控制的基础。若只保存正文，系统很难区分“内容相似”与“当前用户可以使用且仍然有效”。

第三步是按内容结构分块。固定字符长度可以作为兜底策略，但不应成为所有文档的统一规则。制度文件宜沿章节、条款和例外条件切分，避免把约束条件留在上一块；操作手册应将动作步骤、前置要求、风险提示和结果判断尽量放在同一语义单元内；工单可围绕问题、排查过程与解决方案组织；表格则需要把列定义与对应数据一起保留。切块尺寸还要适配嵌入模型和生成模型的上下文限制，而不是直接复制某个通用参数。

文本块过短时，检索可能命中一句结论，却遗漏适用对象、否定条件或时间范围；块过长时，大量无关段落会稀释主题，并增加生成阶段的上下文占用。判断切分是否合理，可以抽样检查：任意文本块脱离原文后，是否仍能回答“它在说明什么、适用于谁、条件是什么”；若不能，就需要合并上下文或补充结构信息。

生产环境中可同时保存细粒度子块与较完整的父级内容。检索阶段使用较小单元提高定位能力，命中后再回取所属章节、相邻步骤或完整条款交给模型。这样既避免整章参与向量匹配造成主题模糊，也减少模型依据孤立句子作答的风险。父子关系、段落顺序和原文位置应在入库时建立，而不是等生成答案时临时猜测。

文档处理完成的标准，不是“文件已经导入”，而是能够稳定回答四个问题：内容是否被正确解析，文本是否仍然有效，适用边界是否可过滤，命中片段是否能还原到完整证据。任何一项缺失，都会在后续表现为“明明检索到了，答案却不可靠”。

三、索引与召回：不要把语义相似度当成唯一答案

索引层的任务不是替模型“理解全部知识”，而是以可接受的延迟，把可能包含证据的文本块送入后续环节。Embedding 模型将查询与文档块映射到同一向量空间，向量索引再通过近似最近邻算法寻找距离较近的候选。这里得到的是“语义上可能相关”，并不等于“能够回答问题”。

Embedding 选择要在企业语料上验证

通用评测排名只能用于缩小候选范围。企业真正需要测试的是模型能否区分内部术语、相似产品名称、否定表达以及带条件的制度条款。选型时至少检查以下因素：

• 中文与行业表达：使用真实问题验证缩写、别名、专业词汇和中英文混写，不要只测公开问答数据。
• 输入长度：模型可接收的长度应与文本块策略匹配。直接截断长块，可能把结论、适用条件或例外条款留在编码范围之外。
• 部署约束：结合数据出域要求、推理吞吐、延迟和硬件资源判断采用本地还是外部服务。
• 版本稳定性：查询与文档必须使用兼容的编码模型。模型更换后通常需要重新生成文档向量，不能只升级查询侧。

企业检索通常需要两条召回路径

向量检索擅长处理措辞变化。例如，用户询问“差旅票据怎么算”，系统仍可能召回标题为“费用报销核算规则”的内容。但企业知识中还存在大量不能模糊匹配的字符串，如 ERROR_CODE_4012、合同编号、药品通用名和设备型号。此类查询中，一个字符的差异就可能指向完全不同的对象，BM25 等关键词检索往往更可靠。

混合检索不应理解为把两种分数直接相加。更稳妥的做法是分别生成排名，再用 RRF 依据候选在各列表中的名次合并结果。若业务对特定字段有强约束，也可以增加规则加权，但应通过评测集确定，而不是凭经验固定权重。

元数据过滤应发生在候选进入上下文之前

文档块除了正文，还应携带部门、产品线、发布日期、有效状态、文档版本和访问权限等元数据。检索时先按用户身份与问题范围过滤，再执行向量或关键词召回，可以避免已废止制度、其他区域版本或无权查看的内容进入候选集。权限过滤尤其不能只在答案展示阶段处理，因为受限文本一旦进入模型上下文，就已经形成数据泄露风险。

过滤条件也不能无限收紧。用户问题中的部门或时间可能缺失，错误推断会直接导致零召回。工程上应区分硬条件与软条件：访问权限、租户边界属于硬过滤；产品偏好、时间倾向可以作为排序特征，并为无结果情况设计逐级放宽策略。

Top-k 应由评测结果决定

候选数量过小，可能漏掉分散在多个文本块中的定义、条件与例外；数量过大，则会把内容相近但适用范围不同的片段送给模型，增加错误引用和上下文竞争。合理范围取决于问题类型、切块粒度、索引质量以及后续是否配置重排序器。

调参时应同时观察“证据是否进入候选集”和“正确证据最终排在什么位置”。先逐步扩大召回规模测量召回率，再结合重排序后的准确率、推理延迟和上下文占用确定阈值。若扩大 Top-k 仍找不到证据，问题通常不在候选数量，而在文本切块、字段过滤、编码模型或关键词索引。用更大的候选集掩盖索引缺陷，只会让“能搜到一些相关内容，却无法稳定答对”的问题更难定位。

四、查询处理与重排序：解决“搜到了相关内容，却没排到前面”

企业问答中的检索失败，不一定是知识库缺少资料。更常见的情况是：相关片段已经进入候选集，却因为查询表达不完整、排序信号单一或上下文拼装不当，没有被送到模型面前。排查这类问题时，应分别查看候选集合、排序结果和最终上下文，不能只根据答案对错判断检索质量。

先处理查询，但不要覆盖用户原话

用户很少按照制度文件的书面语言提问。直接用原句检索，容易找到词面接近但约束条件不一致的内容。

检索前可以增加查询处理层，常用操作包括：

• 结合会话历史补全被省略的对象、部门或业务场景；
• 将内部简称映射为正式名称，同时保留简称参与匹配；
• 识别“今年”“上一版本”“合同生效后”等时间条件，并转换为可检索的范围；
• 把包含多个判断条件的问题拆成若干可独立验证的子问题；
• 生成更接近制度、合同或技术文档措辞的检索表达。

改写结果只能作为新增检索入口，不能替换原始问题。工程上应同时保存原句、标准化版本、扩展词和拆分结果，并记录每条候选内容由哪一种查询召回。否则，一旦改写模型误判了主体或时间，后续排序再准确，也只是在错误方向上挑选材料。

用级联排序分配算力

单靠向量相似度排序，容易高估“主题相近”的内容；只用关键词检索，又可能漏掉同义表达。更稳妥的方案是让不同检索与排序机制分工，而不是要求一个模型完成全部判断。

这种级联结构的价值在于把高成本判断留给较小的候选集合。线上参数应根据候选规模、响应时限和误答成本联合调整，不能只追求离线排序分数。

精排结束不等于上下文已经可用

排名靠前的片段仍需经过上下文组装。首先应合并内容高度重复的块，避免同一段制度因不同文件副本反复出现。其次，对依赖前后文才能理解的条款，可补入标题、定义段或相邻段落。再次，应按原章节顺序排列同一来源的材料，避免将“例外情形”放在“适用条件”之前。

还要限制单一来源占用的上下文比例。若前排结果都是同一文件的近似片段，它们会挤占模型窗口，使另一份真正决定结论的合同附件或最新通知无法进入。可按来源、文档版本和章节进行配额控制；发生冲突时，则优先保留时效明确、适用范围匹配且能直接支持结论的证据。

多条件问题要检查证据覆盖，而不是只看最高分

“外地员工试用期内离职，差旅费是否报销，需要哪些审批”包含人员范围、任职阶段、费用规则和审批流程。即使某个片段与“差旅费报销”高度相关，也不能说明证据已经完整。系统应为每个子问题维护覆盖状态：哪些已有直接依据，哪些只有间接信息，哪些仍未找到材料。

当一次检索无法覆盖全部条件时，可以分别检索各子问题，再按主体、时间、版本和规则依赖关系合并证据。只有证据覆盖达到预设要求，才进入答案生成；否则应继续检索、要求用户补充条件，或明确提示现有资料不足。判断排序链路是否有效，最终不是看第一条结果“像不像答案”，而是看送入模型的证据能否完整支撑用户提出的全部约束。

五、答案生成：把模型从“自由回答”约束为“基于证据回答”

检索完成后，生成层的任务不是让模型“结合常识回答”，而是把检索结果转换成可核验的结论。两者的差别在于：前者把资料视为参考，模型仍可自行补全；后者把资料视为证据边界，任何关键结论都必须能回指到具体文本。

Prompt 应定义清楚回答契约：只能使用当前提供的资料；资料未覆盖的内容不得用模型记忆补齐；直接记载的事实与基于事实形成的推断必须分开表达；每项重要结论需要附带文档标题、章节、页码或其他可定位信息。仅在答案末尾列出几份“参考文档”并不足够，因为用户无法判断某句话究竟由哪段材料支持。

更稳妥的做法，是在进入模型前为每个文本块分配稳定标识，并保留文档版本、页码、标题层级和更新时间。生成时要求引用绑定到具体文本块，输出后再由程序检查：引用标识是否存在，引用片段是否真的包含相关事实，金额、日期等关键值是否与原文一致。引用应证明答案，而不是充当装饰。

拒答能力是生成质量的一部分。系统若要求模型无论如何都给出确定答案，模型就会倾向于用语言连贯性填补证据空缺。工程上应把“无法回答”设计成正常状态，并区分未检索到材料、材料本身缺项、用户问题含义不清和权限不足等原因，方便后续采取补充文档、改写查询或转交人工等动作。

在制度解释、法律咨询、医疗信息和财务核对等高风险场景中，不宜直接让模型从长段资料生成最终答复。可先执行证据抽取，把适用对象、条件、金额、日期、比例、型号及例外条款整理为结构化字段，再基于这些字段生成自然语言。对于格式稳定的关键事实，还应使用规则、数据库记录或计算逻辑进行二次校验。模型负责表达，不应承担所有事实验证工作。

上下文编排同样会改变答案。检索结果正确，只说明证据进入了候选集合，不代表模型一定会采用正确证据。生成前需要去除重复片段和低相关内容，将直接回答问题的材料放在更显著的位置，并按文档版本、主题或时间组织上下文。若新旧制度同时出现，应显式标注生效状态，而不是交给模型自行猜测。

• 限制上下文中的无关材料，避免有效证据被噪声淹没。
• 优先保留原文边界完整、来源明确且版本有效的文本块。
• 对冲突内容增加版本标签，并在输出中暴露冲突。
• 生成后检查引用覆盖率、关键字段一致性和无依据陈述。

因此，答案生成并非在检索结果后追加一次模型调用，而是一条包含证据编排、回答约束、引用验证、事实校验和拒答处理的链路。只有把“答案是否有证据”落实为可检查的系统规则，才能真正缓解“资料已经搜到，答案仍然不准”的问题。

六、效果评估：分开测检索、生成和端到端业务价值

RAG 不能只用“最终回答看起来是否合理”来验收。一个错误答案可能来自文档解析失败，也可能是候选片段排序不当，或者模型忽略了已经提供的证据。若不分层测量，团队通常只能反复调整提示词，实际问题却留在上游。

第一步是建立可回归的评测集。样本不能只取常见问法，还应覆盖低频业务问题、需要组合多份材料才能回答的问题、知识库中没有结论的问题、受访问权限约束的问题，以及答案会随版本或日期变化的问题。评测集应尽量来自真实搜索日志、客服记录和业务人员访谈，而不是全部由实施团队自行编写。

每个问题至少需要标注以下内容：

• 可接受的标准答案，以及不能出现的错误结论；
• 回答所必需的证据片段，区分核心证据与补充材料；
• 允许引用的文档、版本和生效时间；
• 用户身份及其可访问范围，用于验证越权检索；
• 知识不足时应直接拒答，还是可以给出有限结论。

对于表达方式不同但含义一致的答案，不宜采用简单字符串匹配。更稳妥的做法是先把关键事实、条件、数值和适用范围拆成检查项，再结合人工复核判断。

检索评测的核心，是确认必要证据能否稳定进入候选集。仅看这些排名指标仍不够，还要检查回答所需事实是否被完整覆盖，以及候选上下文中混入了多少主题相近但结论无关的片段。

如果标准证据没有被召回，不应先修改生成提示。应沿数据链路反查：原文是否被正确解析，表格和标题关系是否丢失，切块是否把条件与结论拆开，索引是否纳入关键字段，查询改写是否改变原意，以及关键词、语义和元数据过滤能否互补。尤其要单独检查权限过滤与版本过滤，避免通过提高召回率把过期内容或无权访问的材料带入上下文。

生成评测要在“证据已给定”的条件下进行。可将标准证据直接放入上下文，隔离检索变量，再检查答案是否与材料一致、引用是否真正支持对应结论、关键条件是否遗漏，以及面对证据不足时能否拒绝作答。若材料已经齐全而输出仍然错误，问题通常落在上下文排序、重复信息干扰、新旧版本冲突、提示规则不清或模型能力不足。

引用准确性需要逐条核对，不能只检查答案末尾是否存在来源链接。常见失败包括引用了相关但不能证明结论的段落、结论与引用来自不同版本，以及模型拼接多份材料后产生原文中不存在的推断。

离线分数最终要接受业务结果校验。指标改善可能只是让答案更像标准答案，并不一定减少用户处理时间。上线前应保留现有方案作为基线，开展隐藏方案信息的人工盲测，再通过小流量 A/B 测试观察真实使用效果。除正确率外，还要持续记录尾部延迟、每次问答成本、转人工比例、问题是否真正闭环，以及用户是否采用答案继续办理业务。

评测集应纳入发布流程：文档解析、切块规则、嵌入模型、重排序器、提示词或生成模型发生变化时，都运行同一组回归测试。新增错误样本经过脱敏和标注后继续沉淀。这样才能判断一次优化究竟改善了哪一层，又是否以权限安全、时效性、成本或延迟为代价。

七、生产化治理：让知识持续更新，并确保用户只看到该看的内容

RAG 上线后的主要风险不是模型突然失效，而是知识版本、访问权限和索引内容逐渐脱节。生产系统需要把文档变更视为可追踪的数据流水线，而不是定期执行一次全量向量化。

新增文件进入系统后，应依次完成解析、切分、向量生成、元数据写入和索引发布；文件被修改或撤回时，也要同步处理原文本、向量记录、关键词索引与缓存。每个切片至少关联文档版本、生效区间、来源位置和处理状态。新版本确认可用后，再将旧版本标记为失效，避免两套制度同时进入候选结果。解析失败或索引未完成的文档不能静默上线，应进入告警与重试队列。

权限校验必须发生在召回阶段。先检索全部内容、再让模型隐藏敏感信息并不可靠，因为受限文本已经进入模型上下文，也可能出现在日志和缓存中。检索条件应组合用户身份、组织归属、项目关系、文档级别及有效期限；权限变更后，还要及时刷新过滤数据。将敏感资料保留在企业控制的知识环境中，有助于缩小数据暴露面，但这不能替代细粒度授权。

线上监控不能只看接口是否成功。至少应观察无结果查询占比、弱相关召回占比、拒答比例、引用访问情况、端到端耗时和单次调用成本。用户点踩、专家修订及转人工案例需要按“知识缺失、切分错误、排序错误、生成偏离、权限阻断”等原因归类，并沉淀为持续回归的评测样本。

实施时宜先限定一个知识域和一类稳定问题，用基础 RAG 建立可测基线。只有评测证明瓶颈位于召回、排序或多跳关系时，再分别引入关键词与向量混合召回、重排序、查询拆解或 GraphRAG。组件一次堆得过多，通常只能增加延迟和排障难度，无法判断准确率提升来自哪里。

RAG 和大模型微调有什么区别，企业应该选哪个？

RAG 解决的是外部知识的查询、更新和引用问题，适合制度、手册、项目资料等频繁变化的内容；微调更适合调整输出格式、术语习惯、任务步骤或行为边界。若问题是“模型不知道最新文件”，优先采用 RAG；若模型已经拿到正确证据，却长期不能按固定规范执行，可考虑微调。两者可以组合，但微调不应承担知识版本管理。

长上下文模型能否取代 RAG？

通常不能。长上下文扩大了单次可输入的信息量，却没有自动解决文档筛选、权限隔离、版本控制和来源追踪。材料很少且范围固定时，可以直接装入上下文；当资料持续增长、不同用户可见范围不同，或需要稳定引用时，仍需检索层先缩小证据集合。长上下文更适合作为召回后的阅读空间，而不是完整的知识治理方案。

为什么系统明明检索到了正确文档，最终答案仍然不准确？

“命中文档”不等于“提供了足够证据”。正确片段可能排序靠后、被上下文截断，或缺少适用条件和例外条款；提示词也可能允许模型脱离证据补全。排查时应分别检查候选排名、实际注入内容、上下文长度、引用覆盖和回答约束。生成阶段应要求结论绑定出处，证据不足时明确拒答，而不是自由推断。

建设企业 RAG 知识库需要多少文档才能开始？

没有通用的最低文档数量。能否开始取决于知识域是否清晰、问题是否重复出现、文档能否回答这些问题。结构稳定的制度文件也可用于建立首个基线。与其追求规模，不如先准备一组真实问题、标准答案和对应证据；如果这组样本无法定义，导入更多文档只会扩大噪声和治理成本。