企业级 RAG 的知识分层：实体、关系、属性与规则如何落库
企业级RAG如何真正落地？关键在于“知识治理”与“存储分层”
先说几个核心判断：企业级RAG系统要想避免“召回乱、查询慢”的窘境，核心问题不在于选哪个数据库工具，而在于——有没有想清楚每一类知识该存放在哪里、以什么形式存在。
很多团队在做企业知识库时，容易走进一个误区：要么把所有文档一股脑塞进向量库，要么把所有知识硬塞进图数据库。结果系统要么召回乱成一锅粥，要么查询慢得像牛车，要么最终的答案看着就不可信。
问题根源往往不是工具选错了，而是没想清楚每一类知识的特性和它们在系统中的“身份”。
举个例子：用户问“上海用户办理5G畅享199后，还能不能叠加宽带融合优惠？”
Milvus可以高效召回相关政策文档、活动说明和客服口径。但像“5G畅享199套餐与老融合优惠是互斥关系”、“宽带融合优惠的适用客户群是新装用户”、“优惠生效时间是2026年7月到12月”这类
确定性业务关系
一、企业知识的四类“身份”，决定了它们的存储方式
第一类：主数据与实体——稳定、可复用，需要精确命中
这是业务的骨架，是所有问答的起点。包括产品、套餐、活动、客户群、区域、渠道等。它们的特点是：稳定、有唯一标识、可复用，并且需要精确命中。
不能只把它们存成文档切片，因为文档里写的是一份政策里的某个产品描述，而主数据关心的却是“这个产品在整个业务系统中是谁”。
推荐存入：Neo4j / NebulaGraph 图数据库，作为节点（Node）。
第二类：关系——业务规则的骨架，必须精确
在企业业务中，关系不是模糊的，而是确定的。比如套餐包含哪些权益、两个优惠互斥、活动适用于哪类客户群、规则来源自哪份文档、哪个别名对应哪个标准名称……这些关系的真实性无法从语义相似度推断出来。
向量库擅长的是“找和这份文档内容相似的文档”，但它永远不知道两个产品之间是否互斥。
推荐存入：Neo4j / NebulaGraph 图数据库，作为边（Edge）。
第三类：属性——查询时的过滤条件
每个实体和关系都有属性，比如产品的状态是生效中还是已下架、互斥关系的适用范围是哪个区域、有效期是多久。属性的核心价值是做查询时的过滤条件。如果没有属性，查出来的关系是“全局的”，根本无法判断这条互斥规则是否在上海生效、是否还在有效期内。
有了属性，查询就可以精准限定：比如“查5G畅享199在上海当前生效的互斥关系，且经过人工确认的”。
第四类：规则——从文档中来，但不能直接进图
这可能是企业知识里最难处理的部分。规则通常藏在文档里，比如“新装宽带用户不可重复享受老融合优惠”或“合约期内退订需收取违约金”。这类规则往往有时间、区域、渠道、客户群的多重限制，并且会随政策更新而变化。
一个常见的错误做法是：让大模型直接从文档中抽取规则，然后直接写入图数据库。正确的流程应该是：文档原文 → 模型抽取候选规则 → 记录候选关系（含置信度、证据片段、来源文档）→ 进入候选池（待确认状态）→ 业务人员审核确认 → 写入正式图谱并保留版本记录和审计记录。
二、弱结构文档：不要强行抽成图
企业里有大量文档并不适合直接进图数据库：政策原文、客服话术、培训材料、FAQ、投诉处理口径、会议纪要……这些内容语言自然、颗粒度不一、结构不稳定，但它们是系统回答问题的“原始证据”。
正确处理方式：文档 → 切片 → 向量化 → 存入Milvus。同时保留原文字段在MongoDB中，以及文档状态、版本、上传时间等元数据，并建立切片与产品/活动/规则节点的关联ID。这样，Milvus负责语义检索，MongoDB负责原文回填，而切片本身通过ID与图谱中的产品、规则建立引用关系。
三、查询链路：五层如何协同工作
用一个具体例子说明整条查询链路：用户问“上海用户办理5G畅享199后，还能不能叠加宽带融合优惠？”
Step 1 — 意图识别 + 实体提取：LLM抽取出产品（5G畅享199）、区域（上海）、动作（叠加办理）、目标（宽带融合优惠）等关键要素。
Step 2 — 别名归一：图数据库将“畅享199”映射到标准产品ID“product_5g_199”，将“宽带融合优惠”映射到标准ID。
Step 3 — 向量召回：Milvus + ES召回相关政策原文、活动说明、客服口径，同时过滤条件为region=上海、status=生效中。
Step 4 — 图谱关系扩展：以product_5g_199为起点，查询conflicts_with、applies_to、requires等关系，通过属性过滤确认区域和有效期，查出“5G畅享199与老融合优惠互斥（上海，生效中）”“宽带融合优惠适用于新装用户”等关键信息。
Step 5 — 证据回填：从MongoDB中找到政策文档原文片段，作为答案的支撑依据。
Step 6 — 答案生成：LLM基于以上信息，给出“如果用户已享受老融合优惠，则不能叠加；如果为新装宽带用户且宽带在网，则满足办理条件”的精确回答，并附上依据来源。
四、什么情况下不该上图数据库？
并非所有RAG项目都需要图数据库。以下情况可以暂缓：知识量少、关系简单、靠文档语义检索即可满足；业务规则频繁变化且尚未稳定；团队缺乏运维Neo4j / NebulaGraph的能力；没有人工审核机制、关系质量无法保证。
如果以上条件都符合，可以先用Milvus做轻量化的Vector Graph RAG：把实体、关系、文档切片都向量化，通过ID引用串联，待关系稳定后再逐步沉淀到图数据库。
五、一个容易踩的坑：让模型直接生成图查询语句
很多团队尝试让大模型自动生成Cypher或nGQL查询语句。这在Demo阶段很流畅，但在生产环境容易出问题：模型可能引用不存在的边类型、变长路径查询容易路径爆炸、模型不了解图谱的实际数据分布、每次生成的查询不一致难以调试和监控。
推荐做法是：预定义查询模板，让LLM负责填参数，而不是生成查询本身。比如模板是“查找产品{product_id}在区域{region}的所有互斥关系，过滤条件：生效中、人工确认”，LLM只需要识别出product_id和region的具体值即可。这样既保证查询稳定，又降低图数据库的运行风险。
六、总结：企业知识分层存储的核心原则
- 主数据 + 标准实体：Neo4j / NebulaGraph（节点）
- 确定性业务关系：Neo4j / NebulaGraph（边 + 属性）
- 候选关系（待确认）：候选池（MongoDB或专用表）
- 文档原文 + 版本：MongoDB
- 文档切片 + 语义向量：Milvus
- 关键词 + 产品编码：Elasticsearch
- LLM：意图理解 + 关系抽取 + 答案生成
图数据库（Neo4j / NebulaGraph）真正的价值，不是让RAG更“炫”，而是：让知识不只是能被检索到，还能被治理、被校验、被追溯、被复用。最终目标不是建一个很大的图，而是建立一套可治理（有人工审核机制）、可追溯（有证据链和版本记录）、可复用（别名归一、节点去重）、可解释（答案有关系路径支撑）、可审计（每条关系有来源和确认记录）的企业知识能力。
