7.1
深览指数
科技人人都是产品经理·是AD··AI 生成
企业级 RAG 的知识分层：实体、关系、属性与规则如何落库
本文提出企业知识库不应将所有文档或知识塞入单一存储（向量库或图数据库），而应按知识类型分层存储。核心框架是五层架构：主数据与实体、确定性业务关系存入图数据库（Neo4j/NebulaGraph），文档原文与切片存入MongoDB与向量库（Milvus），规则抽取需经人工审核后写入，并配以预定义查询模板而非让LLM直接生成图查询语句。作者通过电信套餐互斥规则等案例，详述了查询链路中各层协同工作的过程。适合正在构建或优化企业级RAG系统、面临知识治理与可追溯性挑战的技术团队阅读。原文 ↗
核心观点
- ▍企业知识库系统低效的根源不是工具选错，而是没想清楚每类知识该以什么形式存在哪里，应按照知识类型分层存储于不同系统。
- 01企业知识分为四类：主数据与实体（稳定、有唯一标识，如产品编码）、关系（确定性业务规则，如互斥、包含）、属性（节点和边上的限定条件，如地域、生效时间）、规则（藏于文档中，需人工审核后入库）。
- 02对于「上海用户办理5G畅享199后，还能不能叠加宽带融合优惠？」的查询，完整链路包括：意图识别与实体提取、别名归一（图数据库）、向量召回（Milvus+ES）、图谱关系扩展（Neo4j）、证据回填（MongoDB）、答案生成（LLM）。
- 03规则抽取的正确流程应为：文档原文→模型抽取候选规则（含置信度、证据片段）→候选池（待确认）→业务人员审核→确认后写入正式图谱，并保留版本记录和审计记录。
- 04作者建议，对于弱结构文档（如客服话术、培训材料），应直接切片向量化存入Milvus，并保留原文与元数据在MongoDB，而非强行抽成图结构。
- 05生产环境中不应让LLM直接生成Cypher/nGQL查询语句，而应使用预定义查询模板，让LLM只负责填充参数（如product_id、region），以保证查询稳定性和可调试性。
反方 / 局限
- — 作者承认，在部分场景下不应使用图数据库：知识量少、关系不复杂；业务规则频繁变化；团队缺乏运维能力；没有人工审核机制。此时可用Milvus做轻量化的Vector Graph RAG先行过渡。
- — 文章虽强调分层存储的优越性，但未深入讨论当图数据库与向量库查询结果冲突时（如图库显示互斥，向量库文档支持可叠加）的解决方案，也未提及多模态数据（如图片、音视频）在分层架构中的处理方式。
11 分钟 · 3 卡片 · 6 资料
读原文 →