RAG架构：企业内部知识助手有据答复的设计决策

本指南面向设计员工端助手检索管道的架构师和工程负责人，阐述各项决策及其默认值。如需工程交付，请参阅我们的企业知识与RAG服务；如需了解打包产品，请参阅AI知识助手。知识助手是我们业务运营AI自动化指南所涵盖的AI步骤之一。

本指南目录

• 为何检索决定质量
• 管道决策一览
• 摄取与分块
• 检索：关键词、向量还是混合
• 权限：在模型看到任何内容之前过滤
• 时效性与删除
• 有据可查的答复与拒绝
• 评估RAG系统
• RAG、长上下文、微调还是搜索：替代方案与选择标准
• RAG管道中的AI
• 现有交付记录与缺失内容
• 本指南的局限性
• 常见问题
• 下一步

为何检索决定质量

检索增强生成（RAG）由Lewis等人于2020年提出，将语言模型与外部索引相结合：系统首先找到与问题相关的段落，再要求模型基于这些段落作答。对于企业知识而言，这一点尤为重要。模型从未在贵司合同或流程文档上训练过，而这些文档每周都在变化。

其影响容易被忽视：当助手给出错误答案时，原因通常出在模型上游。正确的段落从未被索引、在错误位置被分割、排名低于噪声，或被过滤掉。更换模型很少能解决这些问题。以下决策才是质量成败的关键所在。

管道决策一览

摄取与分块

从来源清单而非爬取开始。对每个系统记录所有者、访问模型、更新频率，以及它是否持有当前版本的真实信息。重复项和过期副本是置信错误答案最常见的原因，因此在索引任何内容之前，先确定哪个来源优先。

分块是对检索影响最大的决策。固定大小的窗口虽简单，但会将流程和表格从中间截断。结构感知分块按标题、列表项或表格行拆分，并将标题路径与每个块一起存储，这样标题为“退款 > 损坏商品 > 欧盟境外”的段落就能被独立找到并引用。对于长流程，为匹配建立小块索引，但将父章节传给模型，使答复能看到完整步骤列表。在每个块上保留文档元数据：来源、所有者、访问权限、版本和日期。

检索：关键词、向量还是混合

向量检索能找到用不同词语表达相同意思的段落。关键词检索能找到精确匹配：产品代码、合同编号、名称以及嵌入模型会模糊处理的内部术语。企业问题两者兼有，这正是混合检索成为合理默认值的原因。微软在其搜索服务文档中描述了常见模式：并行运行全文和向量查询，通过倒数排名融合合并两个排名列表。

重排器随后将每个候选结果与问题一起读取并重新排序。它比第一阶段检索更慢，因此仅对候选结果运行，但它往往是提升答复质量最具性价比的单项改进。保持最终集合简短且多样。Liu等人在《Lost in the Middle》中表明，模型对长上下文开头和结尾处信息的利用优于中间部分，因此更多上下文并不自动等于更好。

权限：在模型看到任何内容之前过滤

助手绝不能引用提问者无法打开的文档。在检索中强制执行，而非在提示词中：将访问权限与每个块一起存储，将提问者的身份和所属群组传入搜索查询，并在生成前丢弃其无权查看的任何内容。在生成后过滤，或要求模型隐瞒受限内容，会通过摘要和提示泄露信息。

OWASP在其2025年LLM应用Top 10中将向量和嵌入弱点列为LLM08，包括通过索引的未授权访问、共享向量存储中的跨租户泄漏以及被污染的内容。其缓解措施与本设计相符：对向量存储进行细粒度、权限感知的访问，从可信来源进行经验证的摄取，按访问级别分类内容，以及不可篡改的检索日志。当助手不仅能回答还能执行操作时，我们的AI智能体安全指南中的控制措施同样适用。

时效性与删除

企业知识会发生变化，索引必须跟进。在来源系统提供变更事件时，按变更事件重新索引；没有时，按计划执行。将最后更新日期与每个块一起存储，并在引用旁边显示，让用户可以看到某条政策段落已有两年历史。删除与更新同等重要：当文档被撤回或某人的访问权限被撤销时，索引必须在数据政策承诺的时限内反映这一变化，问题和答复的留存也需要单独制定规则。

有据可查的答复与拒绝

生成步骤是一份契约：从段落中作答，将每项声明引用到段落，当段落不支持答复时说“我不知道”，并指向文档所有者。NIST的生成式AI概况将“幻觉”（即对虚假内容的自信陈述）列为生成式AI的核心风险之一；引用和拒绝是用户核查的方式。对于人力资源、法律或财务等受监管话题，将答复路由至待审核草稿队列，而非直接回复。

RAG、长上下文、微调还是搜索：替代方案与选择标准

四个标准决定选择：知识变化的频率、不同人是否可以看到不同文档、答复是否必须可追溯至来源，以及涉及多少文档。实践中，各方案通常结合使用：RAG用于事实，轻量微调或指令用于格式，搜索作为回退。选择首先解决哪个知识问题是企业AI就绪度评估的一部分。

现有交付记录与缺失内容

• 现有内容。 Netbase JSC已为未公开姓名的客户交付检索增强型知识助手、文档AI和MLOps管道；匿名RAG记录描述了系统类型和Netbase JSC的角色。交付遵循Netbase JSC的安全实践，包括基于角色的访问控制、管理员仪表板的MFA、传输中TLS和静态AES加密、安全代码审查及漏洞扫描。
• 缺失内容。 该记录未发布客户名称、语料库规模、准确率、采用率或节省时间等数据，因此本文不提供上述任何信息。本页的默认值是设计指导，而非该项目的实测结果。

本指南的局限性

• 默认值适用于单一组织内基于文档和记录的内部助手；面向公众的聊天机器人、多租户产品和受监管建议需要额外控制措施。
• 引用研究论文和供应商文档是为了说明方法，并非背书；检索质量取决于您的内容，必须在您的问题上进行测量。
• 索引中的个人数据带来数据保护义务，本指南不能替代相关合规要求；在GDPR或其他隐私法适用的情况下，请寻求法律建议。

常见问题

RAG的最佳分块大小是多少？ 没有统一答案。按文档自身结构拆分，将标题路径保留在每个块中，并在评估集上测试不同大小；政策文件、合同和工单之间的正确答案各不相同。

向量检索是否足以满足企业知识助手的需求？ 通常不够。企业问题混合了语义和精确术语（如代码和名称），因此混合关键词与向量检索加上重排器是更安全的默认选择。

如何防止RAG助手泄露受限文档？ 将访问权限与每个块一起存储，并在检索查询内按提问者权限过滤，在模型看到任何内容之前执行，然后用不应看到特定答复的用户进行测试。

我们应该微调模型而非使用RAG吗？ 微调能塑造风格和词汇，但无法保持事实时效性、引用来源或遵守访问权限。对于不断变化的企业知识，RAG是基础，微调是可选的补充。

下一步

分享您员工今天搜索的来源、查看权限范围以及10个真实问题，我们将预约解决方案评审，为您勾勒检索设计及其评估集。您也可以了解AI自动化与智能体或更多Netbase JSC洞察。

相关服务与解决方案