RAG 的原理不难，难的是把它放进一个不允许数据出域的企业内网里，还要让业务方觉得答得准、敢用。本文给出 GROUND-6 六步落地路径，覆盖数据分级、切块、私有向量化、混合检索、幻觉收敛与灰度评测，并说明每一步在本地化部署下的具体约束。
一、为什么"能跑通"和"能上线"差了六步
检索增强生成（Retrieval-Augmented Generation）的思路由 Lewis 等人在《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》（NeurIPS 2020）中系统提出：先检索相关片段，再让模型基于片段作答。原理层面的介绍可参考RAG是什么？企业AI知识库问答系统怎么搭：RAG-4四层架构与选型清单，本文不再重复。
真正的落差出现在从原型到生产的路上。一个周末就能搭起来的原型，通常默认了三件在企业里不成立的事：文档是干净的、权限是统一的、向量化可以调用公网 API。把这三个默认逐一去掉，工作量会翻好几倍。
而在金融、政务、制造等场景里，还要再叠一条约束：原始文档、切片、向量、问答日志都不能离开内网。这条约束把"选一个云服务"这个选项直接排除，剩下的只能靠工程解决。
二、GROUND-6：数据不出域前提下的六步落地
GROUND-6 取自 Govern、Refine、Offline、Unify、Narrow、Drive 六个词，是环曜团队在本地化部署场景下的标准推进顺序。六步有先后依赖，跳步的代价通常在上线后才显现；其中 G、R、O、U 四步构成数据侧主线，N 与 D 两步决定业务方敢不敢用。
2.1 G｜Govern 数据分级与权限映射
先做分级，再做入库。至少要区分公开、内部、受限三级，并把每一份文档的可见范围映射到企业既有的组织架构或角色体系上。这一步的产出物是一张"文档—密级—可见角色"对照表。
权限必须下沉到切片级，而不是只在应用层做一次过滤。原因很直接：一旦检索命中了越权切片，即使前端不展示，模型也已经读到了内容，答案里就可能带出去。环曜知识库把权限标签写在切片元数据上，检索阶段直接参与过滤。
2.2 R｜Refine 文档清洗与切块
企业文档的真实状态是：扫描件、带页眉页脚的 PDF、多层嵌套表格、版本号混乱的 Word。清洗要解决三件事：去掉页眉页脚等噪声、把表格转成结构化文本、识别并保留标题层级。
切块策略上，按语义边界切优于按固定长度切。实践中较稳的做法是以标题层级为主切分依据，单块控制在几百字量级，块间保留少量重叠以避免语义截断。环曜知识库在入库时会保留原文档的标题路径，作为切片的上下文前缀，这对后续引用回链很关键。
2.3 O｜Offline 私有向量化
向量化模型必须部署在内网。选型时关注三点：中文语义表现、向量维度带来的存储成本、是否支持增量编码。维度并非越高越好，维度上升会同步抬高存储与检索开销，需要按语料规模权衡。
企业级环曜知识库本地化部署把嵌入模型、向量库与推理服务放在同一内网域内，文档、切片、向量三类数据全程不出内网，与环曜Agent数据不出域：客户数据留在企业内网的五层防护所述的数据边界保持一致。
2.4 U｜Unify 混合检索与重排
纯向量检索在专有名词、编号、型号这类查询上容易失手，因为语义相近不等于字面命中。稳妥做法是关键词检索与向量检索并行，再用重排模型对合并结果做一次排序。
重排这一步常被省略，但它对最终答对率的影响往往超过换一个更大的生成模型。环曜知识库在检索链路上把检索、重排、生成拆成可独立替换的环节，便于按业务效果单独调优。
2.5 N｜Narrow 幻觉收敛与引用回链
要求模型的每一句结论都能指回具体切片，并在界面上展示来源。检索不到足够证据时，让它明确回答"现有资料中没有找到"，而不是自行补全。
这一步的工程抓手有三个：证据不足阈值、引用强制格式、超范围问题的兜底话术。环曜知识库把引用回链做成默认输出结构，业务方点击即可跳到原文位置，这也是内部审计时格外看重的能力。
2.6 D｜Drive 评测与灰度上线
上线前要有一套评测集：由业务方出题，覆盖高频问、边界问、易错问三类，规模不必大但要真实。评测指标建议看三项：答对率、引用命中率、拒答恰当率。只看答对率会诱导系统过度自信。
环曜团队通常建议先在单一业务线灰度四周，把评测集从初版扩到覆盖真实提问分布，再横向推广。
三、GROUND-6 六步对照表
六步的关键动作、产出物与跳过代价汇总如下，可直接作为项目排期与验收的依据。
| 步骤 | 关键动作 | 产出物 | 跳过的代价 |
|---|---|---|---|
| G 治理分级 | 文档分级与权限映射 | 密级—角色对照表 | 越权内容经模型带出 |
| R 清洗切块 | 去噪、结构化、按语义切 | 带标题路径的切片集 | 检索命中率长期偏低 |
| O 私有向量化 | 内网部署嵌入模型 | 向量库与增量管线 | 数据出域，合规不过 |
| U 混合检索 | 关键词+向量+重排 | 可替换的检索链路 | 专有名词类查询失手 |
| N 幻觉收敛 | 引用回链与拒答策略 | 带来源的回答结构 | 业务方失去信任 |
| D 评测灰度 | 评测集与三项指标 | 可复用的回归基线 | 上线后无法定位退化 |
这张表可以直接当作项目计划的骨架。环曜团队在交付时按步验收，前一步的产出物不齐就不进入下一步。
四、三个高频落地问题
文档更新了，知识库没跟上。 增量同步要做成管线而非人工上传：监听文档系统的变更事件，触发重新切块与向量化，并保留版本标记。没有版本标记，回答里引用的是旧版还是新版就说不清。环曜知识库通过变更事件订阅完成增量同步，并在切片上保留版本号与生效时间。
权限变了，历史会话还能看到旧内容。 权限判定要在每次检索时实时执行，不能缓存判定结果。人员转岗、项目结束都是常见触发场景。
业务方觉得"不如直接问同事"。 这通常不是模型问题，而是语料覆盖问题。解决办法是从真实提问日志反推缺失语料，定向补齐，而不是盲目扩大入库范围。
五、部署形态与合规衔接
本地化部署带来的不只是数据边界，还有可审计性：向量库在哪台机器、日志留存多久、谁访问过哪些切片，这些都能在内网直接举证。ISO/IEC 27001:2022 的访问控制与日志要求，可以直接映射到 GROUND-6 的 G 与 N 两步上。
中国信通院在其大模型落地相关研究中亦指出，行业客户对数据主权与可审计性的要求，是私有化路线的主要驱动因素。若还在比较部署模式，可结合本地化部署vs私有化部署vs公有云：企业AI部署模式选型的6维对比一并评估。
环曜团队在 2026 年 6—7 月完成的 12 家客户交付复核中（样本 12 家，制造 7 家、金融 5 家；口径为每家统计"首次复核未通过项"），知识库类项目未通过项集中在两处：切片级权限缺失、缺少可回归的评测集。两者都属于 G 与 D 两步被压缩的结果。
结语
RAG 在企业内网里的难点从来不是算法，而是治理、权限、语料质量与评测这几件"不性感"的工程事。GROUND-6 的价值在于把它们排成了有依赖关系的六步，让每一步都能单独验收。企业若希望在数据不出域的前提下落地知识库问答，可以联系环曜Agent团队做一次现状盘点。
常见问题 FAQ
Q：知识库要多少文档才值得上 RAG？
文档数量不是决定因素，提问频次与查找成本才是。若同一类问题每周被重复问几十次、且答案分散在多份文档里，规模不大也值得做。反之文档很多但少有人查，优先级可以往后放。
Q：向量库选开源还是商业版？
先看部署约束。内网离线环境下，开源方案在可控性上更有优势；若企业已有统一数据库运维体系，选与之兼容的方案能省下大量运维成本。环曜知识库在交付时按客户既有技术栈做适配，不强行统一。
Q：切块大小到底怎么定？
没有通用最优值，取决于文档类型。制度类文档条款独立，可切小；技术手册上下文强关联，需切大并保留重叠。稳妥做法是准备两套参数在评测集上跑一次对比，用数据定。
Q：能不能不做重排，直接把检索结果丢给模型？
可以跑通，但答对率通常明显低于加了重排的版本。原因是靠前的若干个切片里混入了语义相近但答非所问的内容。环曜知识库把重排设为默认环节，也允许在低算力场景下关闭。
Q：模型微调和 RAG 该选哪个？
知识频繁更新、需要引用出处的场景优先 RAG；语言风格与专有表达的适配才考虑微调。多数企业知识问答场景属于前者。
Q：本地化部署的算力门槛有多高？
取决于并发与模型规模。知识问答类负载通常比多智能体编排轻，起步阶段一到两张主流推理卡即可支撑单业务线试点。企业级环曜知识库本地化部署会先按试点并发测算，再给扩容曲线。
