企业级 RAG 的知识分层：实体、关系、属性与规则如何落库
企业知识库的问题不是工具选错，而是没想清楚每类知识该以什么形式存在哪里。本文把企业业务知识拆成主数据/实体、关系、属性、规则四类，配以文档切片，给出一套”图数据库负责确定性关系、向量库负责语义检索、文档库负责原文证据”的五层分层落库方案，并用电信套餐互斥规则贯穿整条查询链路。
基本信息
- 来源：人人都是产品经理，作者 @是AD
- 原文链接：https://www.woshipm.com/ai/6427380.html
- 原始素材：2026-07-11-134228-tg-a6bf2c（raw/articles/）
- 类型：企业级 RAG / 知识图谱方法论
- 阅读时长：约 14 分钟
核心观点
-
企业知识库低效的根源不是工具，而是没做知识分层——把所有文档塞进向量库或所有知识塞进图数据库，都会导致”召回乱、查询慢、答案不可信”。正确做法是先判断”每类知识该以什么形式存在哪里”，再选工具落库。
-
企业业务知识分四类，存储方式完全不同：① 主数据与实体（产品、权益、活动、客户群、区域、渠道，特点是”稳定、有唯一标识、可复用、需要精确命中”→进图数据库当节点）；② 关系（包含/互斥/适用/依赖/来源于/别名是/限制于/覆盖，是业务的真实逻辑，无法从语义相似度推断→进图数据库当边）；③ 属性（节点和边上的限定条件，如 region、valid_from、valid_to、confidence、source_doc_id，核心价值是做查询过滤）；④ 规则（藏在文档里、有时间/区域/渠道/客群限制、会随政策更新）。
-
规则绝不能让模型直接抽取后写入图数据库——正确流程是”文档原文 → 模型抽取候选规则（含置信度、证据片段、来源文档）→ 进候选池（待确认状态）→ 业务人员审核 → 确认后写入图谱 → 保留版本记录和审计记录”。这是全文最强调的一条治理红线。
-
弱结构文档不要强行抽成图——政策原文、客服话术、培训材料、FAQ、投诉口径、会议纪要这类”语言自然、颗粒度不一、结构不稳定”的内容，应走”切片 → 向量化 → 存 Milvus，原文存 MongoDB，切片通过 ID 与图谱产品/规则节点建立引用关系”的路径，让 Milvus 负责语义检索、MongoDB 负责原文回填。
-
五层协同的查询链路是分工而非竞争——以”上海用户办 5G畅享199 后能否叠加宽带融合优惠”为例：意图识别+实体提取（LLM）→ 别名归一（图库）→ 向量召回并按 region/status/channel 过滤（Milvus+ES）→ 图谱关系扩展查互斥/适用/依赖（图库）→ 证据回填原文片段（MongoDB）→ 答案生成（LLM）。Milvus 召回相似政策，但”两个产品是否互斥”这种确定性关系只能靠图库查。
-
不是所有 RAG 都要上图数据库——知识量少、关系不复杂、规则频繁变化尚未稳定、团队缺乏 Neo4j/NebulaGraph 运维能力、没有人工审核机制时，可先用 Milvus 做轻量化 Vector Graph RAG（实体/关系/切片都向量化、用 ID 引用串联），待关系稳定后再逐步沉淀到图数据库。
-
别让大模型直接生成图查询语句——让 LLM 自动生成 Cypher/nGQL 在 Demo 阶段流畅，但生产环境会引用不存在的边类型、变长路径爆炸、查空或超大结果集、每次生成不一致难调试。推荐”预定义查询模板，LLM 只负责填参数”，既保证查询稳定又降低图库风险。
实操内容保留
知识分层存储原则总表（全文结论）
| 知识类型 | 存储位置 |
|---|---|
| 主数据 + 标准实体 | Neo4j / NebulaGraph（节点） |
| 确定性业务关系 | Neo4j / NebulaGraph（边 + 属性） |
| 候选关系（待确认） | 候选池（MongoDB 或专用表） |
| 文档原文 + 版本 | MongoDB |
| 文档切片 + 语义向量 | Milvus |
| 关键词 + 产品编码 | Elasticsearch |
| 意图理解 + 关系抽取 + 答案生成 | LLM |
八种确定性业务关系（图数据库的边类型）
- 包含：5G畅享199 → 包含 → 100G流量包
- 互斥：5G畅享199 → 互斥 → 老融合优惠
- 适用：宽带融合优惠 → 适用于 → 新装用户
- 依赖：宽带融合优惠 → 依赖 → 宽带在网状态
- 来源于：规则A → 来源于 → 政策文档B
- 别名是：“畅享199” → 别名是 → 5G畅享199套餐
- 限制于：活动C → 限制于 → 上海区域
- 覆盖：规则2026版 → 覆盖 → 规则2025版
实体节点属性示例（产品）
product_id: P1000199
canonical_name: 5G畅享199套餐
aliases: ["畅享199", "199融合", "5G 199套餐"]
product_code: P1000199
status: 生效中
launch_date: 2025-01-01
valid_regions: ["上海", "浙江", "江苏"]
channels: ["线上营业厅", "客服热线"]关系边属性示例（互斥关系）
relation_type: conflicts_with
subject: 5G畅享199套餐
object: 老融合优惠
region: 上海
valid_from: 2026-01-01
valid_to: 2026-12-31
confidence: 1.0（人工确认）
source_doc_id: policy_doc_202601
confirmed_by: 业务负责人A
confirmed_at: 2026-03-15候选规则字段（进候选池前）
候选关系 ID / subject（主体）/ predicate（关系类型）/ object（客体）
置信度 / 来源文档 ID / 证据原文片段 / 抽取时间
状态：待确认 / 已确认 / 已驳回
确认人 / 确认时间 / 备注六步查询链路（电信套餐叠加咨询）
Step 1 意图识别 + 实体提取（LLM）
产品:5G畅享199 / 区域:上海 / 动作:叠加办理 / 目标:宽带融合优惠 / 关注点:互斥限制、办理条件
Step 2 别名归一（图库）
"畅享199" → product_5g_199；"宽带融合优惠" → benefit_broadband_bundle
Step 3 向量召回（Milvus + ES）
召回政策原文/活动说明/客服口径，过滤 region=上海, status=生效中, channel⊇线上
Step 4 图谱关系扩展（图库）
以 product_5g_199 为起点查 conflicts_with / applies_to / requires + valid_in 属性过滤
Step 5 证据回填（MongoDB）
找到政策原文片段作为答案依据
Step 6 答案生成（LLM）
给出结论 + 原因（互斥关系 + 区域 + 生效时间）+ 依据（政策文档A 第3条）弱结构文档处理路径
文档 → 切片(chunk) → 向量化 → 存入 Milvus
同时保留：
原文 → MongoDB
文档状态、版本、上传时间、所属业务域等元数据
切片与产品/活动/规则节点的关联 ID查询模板示例（LLM 只填参数，不生成查询）
查询模板：查找产品 {product_id} 在区域 {region} 的所有互斥关系，过滤条件：生效中，人工确认。
LLM 只需识别：product_id = product_5g_199 / region = 上海关键概念
- 知识四分层：主数据/实体、关系、属性、规则的分类落库法，是本文的核心框架
- 企业级知识图谱：本文提供了”四类知识 + 弱结构文档”的落库方法论，与既有的知识准入/证据链治理观点互补
- RAG 知识库：本文明确 RAG（Milvus 语义检索 + MongoDB 原文回填）在五层架构中承担”找相似文档/回填原文证据”的角色，而非承担确定性关系判断
- 混合检索：Milvus + Elasticsearch 分别承担语义召回与关键词/产品编码精确命中
- 产销品别名图谱：本文的”别名是”关系和 aliases 属性、Step 2 别名归一即别名图谱的落地形态
- 候选规则池：模型抽取的候选关系先进待确认状态、经业务审核再入图的治理机制
- 图查询模板填参：用预定义 Cypher/nGQL 模板 + LLM 填参替代 LLM 直接生成查询，是本文的生产级避坑做法
- 涉及工具：Milvus、MongoDB、Elasticsearch、NebulaGraph（Neo4j 为文中并列的另一图数据库选项）
与其他素材的关联
- 与 2026-07-05-woshipm-enterprise-knowledge-graph-6-lessons（企业级知识图谱6点经验）：那篇从”知识准入 → AI 抽取 → 业务定规则 → 挂回对象 → 证据链 → MCP 服务化”六步治理讲运营商项目复盘；本文从”知识该分成哪四类、每类存哪里”的数据建模视角切入，两者一个讲治理流程、一个讲落库结构，互为表里。
- 与 2026-07-07-woshipm-enterprise-kg-hybrid-architecture（MongoDB+Milvus+ES+NebulaGraph 混合架构实战）：那篇强调真实项目里图数据库先只做产销品与别名归一、别把所有规则入图；本文的”规则走候选池审核后再入图""弱结构文档不强行抽成图""不是所有 RAG 都要上图”与之完全一致，且补上了四类知识的判定标准和确定性关系的八种边类型。三篇共同构成企业级 RAG/知识图谱的完整知识块。
- 与 混合检索 / 2026-05-30-ai-rag-production-100-yuan：本文的 Milvus + ES 分工在混合检索（稠密向量 + BM25 + RRF）层面有更细的技术印证。
- 与 置信度门控：本文的 confidence 属性和候选池”待确认/已确认/已驳回”是关系级的置信度治理，与问答级的置信度门控互补。
原文精彩摘录
问题的根源不是工具选错了，而是没想清楚每类知识该以什么形式存在哪里。
不能只存成文档切片，因为文档是”某一份政策里写了这个产品”，但主数据是”这个产品在整个系统里是谁”。
向量库可以找到”和这份文档内容相似的文档”，但它不知道两个产品是否互斥。
属性的核心价值是做查询时的过滤条件。如果没有属性，查出来的关系是”全局的”，不知道这个互斥规则是否在上海生效、是否还在有效期内。
错误做法是：让模型直接从文档抽取，然后写入图数据库。（正确流程是文档原文 → 模型抽取候选规则 → 进入候选池待确认 → 业务人员审核 → 确认后写入图谱并保留版本与审计记录）
图数据库真正的价值，不是让 RAG 更”炫”，而是让知识不只是能被检索到，还能被治理、被校验、被追溯、被复用。最终目标不是建一个很大的图，而是建立一套可治理、可追溯、可复用、可解释、可审计的企业知识能力。