员工需要在多个地方反复搜索
制度、操作手册、案例记录和产品信息可能分散在共享网盘、业务系统和数据库中。
企业 RAG 与 AI 知识系统
让团队从企业知识中找到有出处的回答
把经批准的文档、数据库和内部系统接入 AI 助手。每次查询先按用户权限筛选数据，再检索相关内容，并在回答中列出来源，方便团队核对。
RAG 可以减少缺乏依据的回答，但不能保证每个答案都正确。我们会根据业务风险设置引用、拒答、评估和人工复核规则。
数据流程示意
先检查权限，再检索并生成回答
只有用户有权查看的信息，才会进入本次检索和模型上下文。
- 01
已登录用户
查询带有已验证的身份和角色信息。
- 02
权限检查
检索前先应用数据源和租户筛选条件。
包含已授权数据源排除受限数据 - 03
混合检索
语义和关键词搜索找出相关段落，再调整排序。
- 04
附来源回答
助手根据检索到的内容回答，并列出引用来源。
有来源支持的回答现行流程要求发布前获得批准。[1] 例外情况需按既定路径上报。[2]
[1] 流程第 4.2 节[2] 上报指引
贯穿全流程的控制
- 评估问题集
- 审计记录
- 数据更新状态
回答规则
回答 · 拒答 · 转人工处理
难点不只是接入 AI 模型
企业知识通常分散在不同文档和系统中，数据负责人、更新时间和访问权限也各不相同。知识助手要用于日常运营，必须先处理这些实际问题。
数据更新后缺少清晰的同步机制
如果系统没有处理删除、替换和重新建立索引，回答可能继续引用过时文档。
不同用户可访问的信息不同
当部门、客户或租户的权限存在差异时，一个不区分权限的搜索索引并不足够。
团队没有统一的回答评估方法
如果缺少代表性问题和预期证据，团队很难判断检索质量是提高了，还是仅仅发生了变化。
受控的知识系统适合哪些场景
建议先选择一个能明确界定数据、用户、权限和复核责任人的流程。以下是常见起点，并非预制产品。
内部制度和流程搜索
帮助员工找到现行指引，并在执行前打开引用段落核对。
客户服务和技术支持
检索经批准的故障排查、服务和产品信息，遇到例外情况时转交人工跟进。
产品和销售知识
从持续维护的目录、规格和经批准的商业资料中回答详细问题。
员工入职和运营指引
按岗位提供相关流程，同时避免显示与工作无关的内部内容。
受权限控制的记录查询
围绕一个明确的运营问题，整合可访问的文档、数据库记录和 API 结果。
正式使用前，
评估不只看回答措辞，也要检查系统选择了哪些证据。试点开始前，我们会先确定测试问题、失败处理方式和复核负责人。
- 01
数据和引用是否相关
检查检索段落能否支持回答，以及引用是否指向正确章节。
- 02
有代表性的测试问题
根据实际业务准备常规、模糊、过时和带有误导性的问题。
- 03
证据不足时的处理
当授权数据无法支持回答时，助手应拒答或转交指定人员处理。
- 04
权限和租户测试
确认用户无法检索或推断其岗位、机构或记录范围以外的内容。
- 05
数据生命周期检查
测试更新、删除、替换和重新建立索引，避免系统继续使用已废止内容。
- 06
运营监测指标
在约定的服务范围内监测检索质量、响应时间、模型用量和成本。
权限场景示意
内容进入模型前，
用户身份、数据负责人和查询时筛选会共同生效。模型只应收到该用户针对此次查询有权检索的信息。
- 接入 OAuth2、SAML 或 Active Directory
- 查询时按 metadata 筛选
- 租户和文档级数据隔离
- 记录证据及回答决定
用户身份
运营经理 · 已验证员工角色
该角色可以访问
现行运营流程和经批准的产品手册
不会进入检索
人事文件和职责范围以外的客户记录
可以提供的结果
仅根据授权段落回答，列出引用来源并保留审计记录
技术架构
根据数据特点和控制要求选择检索架构
实际组合取决于文档质量、更新频率、语言、数据规模、响应速度和部署要求。以下模式会按用途选用，不一定全部需要。
01文档和数据接入
自动 ETL 流程可处理 PDF、DOCX、JSON 和 API payload，配合版面感知 OCR、metadata 提取，以及 recursive 或 sliding-window 分段。每项数据同时保留负责人、版本和权限信息。
02混合检索
稠密向量检索可按需采用 HNSW 或 Flat 索引，以及 cosine 或 inner-product 距离。BM25 负责关键词匹配，再通过 Reciprocal Rank Fusion 合并候选结果。
03Cross-encoder 重排序
Cohere Rerank 或 BGE-Reranker 等次级模型，可在组合 prompt 前对 top-k 候选内容重新排序，减少无关上下文和不必要的 token 用量。
04按权限检索
企业身份系统可通过 OAuth2、SAML 或 Active Directory 接入。查询时的 metadata 筛选会先应用租户、角色和文档规则，再把文本加入模型上下文。
05评估和日常运营
版本化测试问题、检索记录、引用检查、审计日志、数据更新任务和用量监测，让上线后的变化可以追踪和复核。
先明确业务流程和数据边界，
OpenAI、Claude、DeepSeek 和 Qwen 可作为生成或推理模型的评估选项。选择时要结合部署方式、供应商条款，以及模型在约定测试问题中的实际表现。
OpenAI
工具集成、模型能力和企业控制
Claude
长上下文和文档量较多的流程
DeepSeek
需要评估成本和部署安排的场景
Qwen
需要评估中文表现和部署安排的场景
选择标准
- 数据处理方式
- 语言表现
- 响应时间和成本
- 上下文和工具支持
- 托管限制
先完成有限试点，
试点应集中测试一个实际流程，并使用真实权限和有代表性的问题。明确证据、失败处理和运营负责人后，再逐步扩大使用范围。
- 01
检查数据源和权限
梳理用户、问题、系统、数据负责人、敏感程度和更新方式。
- 02
建立有限试点
接入已批准的数据，打通一个有实际用途的用户流程。
- 03
评估检索和回答
衡量证据相关度、引用、拒答、权限规则和回答质量。
- 04
接入日常业务流程
集成身份验证、应用、API、复核队列、日志和支持流程。
- 05
持续监测和改进
扩大范围前，先检查数据变化、失败问题、用量、响应时间和成本。
系统仍需要人工管理的部分
RAG 改变的是查找和呈现证据的方法，不能取代对数据质量、权限或业务决策负责的人员。
- 回答即使带有引用，也可能误解内容或遗漏重要背景。高风险决策仍需安排适当的人工复核。
- 如果授权数据不完整、相互矛盾或没有及时更新，回答也可能出现同样的问题。
- 权限控制依赖正确的身份、metadata 和数据源设置。岗位或连接方式发生变化后，需要重新测试。
- 模型和检索表现会随设置、数据内容或供应商更新而变化，正式使用后仍要持续评估。
企业 AI 私有化、云端与混合部署
先明确数据可以在哪里处理，再选择模型。私有化部署并不自动解决安全问题，还需检查访问权限、日志以及各项外部服务接收的数据。
| 方案 | 数据与模型边界 | 运营维护要求 |
|---|---|---|
| 云端模型服务 | 向模型供应商发送允许使用的检索内容，事先核实数据保留条款、处理区域及允许传输的数据。 | 供应商负责模型运行；项目方仍需管理数据接入、访问权限、调用量和支持。 |
| 私有化部署 | 在约定的私有环境内运行检索服务和选定模型，并检查遥测及配套服务是否符合数据边界要求。 | 自行规划计算资源、模型更新、备份与评估。专用基础设施可能在低使用量时仍产生固定费用。 |
| 混合部署 | 指定数据源或检索服务保留在私有环境，只将授权内容发送给云端模型。需逐项确认传出的数据。 | 同时维护两侧系统，处理内容过滤、身份验证、网络中断及供应商变更。 |
FAQ
常见问题
企业 AI 知识库的成本如何构成？
文档解析与清理、数据源接入、权限映射和评估决定初期开发范围。持续费用包括索引更新、模型调用、存储、监测及支持。先测试典型问题与文档格式，再评估扩大部署所需的资源。
什么是 RAG 检索增强生成？
RAG 会先从经过授权的数据源中检索相关内容，再把这些内容交给 AI 模型作为回答依据。这让答案更容易追查，但不代表每次回答都正确。
企业知识系统可以使用哪些数据？
项目可以按需求处理 PDF、DOCX、结构化数据、数据库、API 和现有知识库。每类数据源都需要适合的解析、元数据、更新、删除和权限处理。
系统能否沿用现有用户权限？
可以，但需要正确映射身份、源数据权限、元数据和索引边界，并经过测试。具体方案取决于企业的身份系统、数据仓库、租户模式和部署环境。
RAG 可以避免 AI 给出错误回答吗？
不能。数据质量、文档解析、检索设置、权限信息和模型行为都会影响结果。我们会根据约定场景设置引用、拒答、评估、日志和人工复核机制。
系统可以接入哪些 AI 模型？
系统可以按需求接入 OpenAI、Claude、DeepSeek 或 Qwen 等服务。实际模型和供应方式会根据语言、数据政策、部署、响应时间、成本和集成要求确认。
明确范围、时间安排和下一步
先从团队真正需要回答的问题开始
准备一小批有代表性的问题、相关数据源，以及应该拥有访问权限的人员。我们可以共同明确数据边界、试点范围和判断效果所需的证据。
第一步是讨论实际范围，不会预先假设 AI 可以取代业务流程负责人。
