企业官网建设流程全解析

简介：用Dify搭建基于知识图谱的RAG系统，是当前AI应用开发中颇受关注的方向；这份课件材料专门针对希望掌握知识图谱与检索增强生成结合实践的开发者，帮助解决传统RAG难以利用实体关联关系的问题。资源包内含3个文件，以两个JSON格式的语料数据集和一份GraphRAG工作流配置YAML文件为主体，整体大小约633.23MB；其中两个JSON数据集分别提供完整版与精简版食谱语料，YAML配置则对应Dify中的GraphRAG应用编排，能够支撑从数据准备到配置演示的完整链路。目前已有2586人学习/下载。读者拿到这套材料后，可以快速搭建一个基于知识图谱的RAG演示Demo，理解如何将实体、关系等结构化信息注入检索流程，并借助Dify完成问答或推荐类场景的原型验证；这对需要落地知识密集型问答、智能客服或业务知识库的开发者来说，是一份省去大量数据整理时间的参考课件。 最近在给团队做内部技术分享，选来选去定了一个题目：基于知识图谱的RAG系统。折腾了大概一周，用Dify搭了一套完整的Demo课件材料，从Neo4j建图谱、实体抽取、工作流编排到最后的问答演示，全流程都跑通了。这套材料后来在组内讲了两遍，反馈还不错，有不少人照着复现也成功了，所以整理出来分享给有同样需求的人。

先说清楚这套东西到底是什么。Dify是目前很流行的开源LLM应用开发平台，它把Agent、工作流、知识库、模型管理这些事都封装成了可视化组件，让搭建RAG应用的门槛低了很多。传统RAG是“文档切块+向量检索”，但这套Demo换了一条路：先用Neo4j把业务数据构造成知识图谱，再在Dify工作流里同时做向量检索和图谱查询，最后把两边结果一起交给大模型生成答案。简单说，就是“向量检索负责找相关内容，知识图谱负责找精确关系和推理路径”，两者互补。

这篇文章我就按自己搭建的完整过程来写，包含架构选型理由、Neo4j建图谱的具体操作、Dify工作流的节点配置、课件怎么组织，以及最后调试时踩过的一堆坑。如果你是做RAG相关开发、想给团队做技术分享，或者正在对比“图谱RAG”和“传统RAG”的效果差异，这篇内容应该能帮你省下不少时间。

1. 为什么选择“知识图谱+RAG+Dify”的组合

1.1 传统RAG的局限在哪里

做了这么久RAG应用，一个越来越明显的感受是：光靠向量检索，很多问题根本答不对。向量检索的核心逻辑是“语义相似度”，它擅长的是“找到相关文本片段”，而不是“回答需要多跳推理的问题”。

举个例子，一个简单的企业知识库问答：“A公司通过哪家公司间接持有B公司5%以上的股份？”如果资料分散在几份股权说明文档里，传统RAG通常只会找到其中一份文档里最相似的段落，然后凭这段文字组织答案。它很难拼凑两个文档、三跳关系去推理出一个最终结论。

还有一类问题，比如“某部门所有在职员工的入职时间排序”，这种查询本质上是结构化数据操作，但你偏偏用非结构化文档去近似处理，结果自然不稳定。语义相似度到一定程度就触顶了，不是换个大模型就能解决的，这也是图谱RAG最近越来越受关注的原因。

1.2 知识图谱能补上哪块短板

知识图谱本质上是一个“实体-关系”网络。拿股权穿透举例，公司是实体节点、持股关系是边，查询“A公司间接持股B公司”，可以通过图的路径搜索直接得到一条或几条关系链，逻辑上完全精确。

我把两种检索方式做了个对比：

知识图谱不是替代向量检索，而是补上后者缺失的“精确关系推导”能力。在生产环境中，两者的关系通常是互补的——先通过图谱定位关键实体和路径，再用向量检索补全上下文文本。

1.3 Dify在中间扮演什么角色

Dify的重要性在于把工程化问题简化了。你不用自己开发Agent编排系统、不用处理数据库会话管理、不用单独开发管理后台，Dify把工作流、知识库、模型接入、日志追踪这些基础能力都内置了。

还有一个很现实的原因是团队协作。组里有人擅长写Python服务，有人擅长写提示词，也有人只懂业务。Dify的可视化工作流让这几类人能同时参与一个项目。做课件和Demo的时候尤其重要——你不需要现场写一堆代码，拖拽节点就能演示完整链路。

2. Demo课程材料的整体设计思路

2.1 先定场景，再定数据

搭建课件材料最容易犯的错误是一上来就搞数据，结果做完发现场景讲不清楚。我建议的顺序是：先确定演示场景，再反推需要什么数据。

我选的是“智能股权风险分析助手”这个场景。原因很简单，第一，股权结构天然适合用图来表达，公司与人作为节点、持股关系作为边，非常符合直觉；第二，股权穿透分析是金融、合规、审计等领域真实存在的痛点，听众容易理解；第三，它包含多跳查询、条件筛选、路径发现等多种图谱能力，方便展示不同层级的RAG效果。

数据方面，我造了一份模拟数据集：大概12家公司和20个人，相互之间形成了直接持股、间接持股、交叉持股、任职关系等约60条关系。数据集不大，但足够覆盖各种演示效果。

2.2 课件章节规划

整套课件我按由浅入深分成了六个部分：

1. 背景与痛点：传统RAG的不足、知识图谱RAG的概念。
2. 技术栈介绍：Dify、Neo4j、嵌入模型、大模型各自承担什么角色。
3. 知识图谱构建实战：在Neo4j中设计节点、关系，并完成数据导入。
4. Dify工作流搭建：接入Neo4j查询工具、配置知识库、串联完整的RAG链路。
5. 效果演示与对比：同一问题分别问传统RAG和图谱RAG，观察差异。
6. 问题与优化方向：常见故障、效果调优思路。

每章我还配套了作业和思考题。比如“如果要增加‘企业风险事件’节点，如何设计图谱结构？”“当图谱数据量大到百万节点时，Cypher查询性能怎么优化？”这样学员不只是看热闹，还能带着问题继续研究。

2.3 技术选型和版本确认

确定方案后，需要把技术栈锁死，避免在分享时出现版本不兼容的尴尬。

我使用的核心组件如下：

• Dify社区版：1.x版本，使用Docker Compose安装。
• Neo4j：5.x社区版，使用Docker运行。
• 嵌入模型：本地部署了bge-m3（也可以通过Dify配置API方式接入），用于文档向量化。
• 大模型：通过Dify接入的DeepSeek（根据你的网络环境可以选择其他兼容模型），处理最终答案生成。

特别提一下，Neo4j新版对Cypher语法要求更严格，尤其注意“不在事务中直接返回大量数据”这类限制，后面会详细说。

3. 知识图谱构建环节的实操细节

3.1 图谱Schema怎么设计

图谱设计是决定后续查询上限的核心环节，一套好的Schema能让Cypher语句简洁清晰，而糟糕的Schema则会让关系查询变得极其复杂。我设计了四类节点：

• 公司（Company）：属性包括名称、统一社会信用代码、注册地、成立日期。
• 个人（Person）：姓名、身份证号（演示可用虚拟数据）。
• 企业风险事件（RiskEvent）：事件类型、发生时间、事件详情。
• 行业分类（Industry）：行业名称、分类代码。

关系类型设计了以下几种：

• (Person)-[:HOLDS]->(Company)：表示个人持股，属性为持股比例、持股时间。
• (Company)-[:HOLDS]->(Company)：表示公司间投资，属性为持股比例、投资时间。
• (Person)-[:APPOINTED_AS]->(Company)：表示任职，属性为职位、任职开始时间。
• (Company)-[:BELONGS_TO]->(Industry)：表示所属行业。
• (Company)-[:HAS_RISK]->(RiskEvent)：表示该公司关联的风险事件。

这里有个经验点：关系一定不要设计成泛化的“RELATED_TO”，否则查询时难以区分语义。宁可把关系类型写得具体冗余一些，也不要图省事用通用关系字段去硬扛。

3.2 实体和关系抽取的两种做法

如果业务数据是结构化表格，比如Excel或数据库，最直接的做法是写Python脚本调用py2neo或Neo4j官方驱动直接导入，字段一一对应就可以了。

如果数据源是非结构化文档，就需要先做信息抽取。我首次实现时直接在Dify工作流里配置了一个“LLM节点”做实体抽取，输入原始文本，输出JSON格式的实体和关系列表，然后通过工具节点写回Neo4j。但这样速度比较慢，代码量也比较大。为了课程演示方便，我改成了脚本实现：用Pandas读取Excel数据，调用大模型API对文本字段做补充抽取，最后以CSV文件批量导入Neo4j。

建议第一次做图谱项目时，先用结构化数据把闭环跑通，等理解了图谱的查询和存储逻辑之后，再考虑非结构化的抽取方案。不要一上来就上高难度流程，否则很容易陷入“数据清洗三个月，图谱实际只建了两天”的困境。

3.3 用Neo4j导入并验证数据

我用的是Neo4j的LOAD CSV命令。导入之前把节点文件（companies.csv、persons.csv）和关系文件（holds.csv、appointed.csv）准备好，然后逐个执行Cypher导入。

LOAD CSV WITH HEADERS FROM 'file:///companies.csv' AS row CREATE (c:Company { id: row.id, name: row.name, credit_code: row.credit_code, registered_address: row.registered_address });

LOAD CSV WITH HEADERS FROM 'file:///holds.csv' AS row MATCH (a:Company {id: row.from_id}) MATCH (b:Company {id: row.to_id}) CREATE (a)-[:HOLDS { ratio: toFloat(row.ratio), since: date(row.since) }]->(b);

导完数据之后，不要急着往下做，先用几条查询验证图谱的完整性。第一步我会检查节点总数、关系总数，然后抽一个具体的实体做路径查询，看看真实数据长什么样。

MATCH p = (a:Company {name: '甲公司'})-[*1..3]-(b) RETURN p LIMIT 20;

如果路径能正常返回，说明图谱基本没问题。这一步很关键，课件里我特意标注：“必须用真实查询验证数据，不要只看Neo4j Browser里的节点可视化图，可视化好看不代表查询结果正确。”

4. Dify工作流编排与知识图谱接入

4.1 工作流整体结构

Dify工作流的搭建是本Demo的核心。我设计的完整链路如下：

1. 用户问题输入（sys.query）。
2. 问题分析节点（LLM）：判断问题是否需要图谱查询，提取关键实体。
3. 图谱查询节点（HTTP请求）：将实体转换为Cypher查询，请求Neo4j。
4. 文档检索节点（知识检索）：同时执行向量检索，寻找相关文本块。
5. 结果融合节点（LLM）：综合图谱查询结果和文档检索结果，生成最终答案。
6. 答案输出节点。

这里强调一下，图谱查询和文档检索是并行执行的，而不是串行。一开始我做成串行，先查图谱，再查文档，结果响应时间翻了一倍。并行设计不仅在Dify中展示效果更好，也更接近生产环境中的混合检索架构。

4.2 如何让Dify安全地连接Neo4j

Dify本身没有内置Neo4j插件（截止到我使用的版本），所以连接方式通常有两种。第一种是写一个独立的查询服务（比如FastAPI），封装成HTTP接口给Dify调用；第二种是直接在Dify的HTTP请求节点里调用Neo4j HTTP API。

我演示时采用第二种方案，因为不需要额外部署一个服务，课件现场更简单。但要注意Neo4j的HTTP API默认需要开启事务端点，请求体要按官方格式组织：

{ "statements": [ { "statement": "MATCH (n) RETURN n.name LIMIT 10", "parameters": {}, "resultDataContents": ["row"], "includeStats": true } ] }

Dify的HTTP请求节点里，在请求头中配置“Authorization: Basic base64(账号:密码)”，请求方法为POST，请求体用JSON格式。响应里取“results[0].data”，这就是图查询结果。

4.3 Cypher生成怎么做才靠谱

这是整个项目最实用的经验。工作中直接让大模型“写Cypher”然后执行，是很危险的做法。首先是安全问题，大模型生成的Cypher可能意外修改或删除数据。更常见的问题是，大模型不了解你的图谱结构，生成的查询经常字段错误。

我的做法分为两步：

第一步，在图谱查询节点之前增加一个“图谱Schema提示词”固定内容。把节点、关系、属性全部列清楚，并附带3个标准示例查询，让LLM严格按照这个结构去生成Cypher，不要自创格式。

第二步，把Neo4j的用户权限设置为只读。创建一个专用账号，仅授予读权限：

CREATE USER readonly IF NOT EXISTS SET PASSWORD 'yourpassword' SET ACCESS READ ONLY;

哪怕LLM真的生成了一条带写入操作的语句，数据库层面也能挡回去。这个设置我在课件里专门强调过，因为在实际企业场景里，大模型直接操作数据库的权限最小化是必须的。

4.4 检索结果融合的策略

融合策略我调试了很多轮，最终稳定的版本是这样设计的：

先在提示词里告诉大模型：“以下是知识图谱查询返回的结构化关系信息，它们是精确事实；以下是文档检索返回的文本片段，它们是补充上下文。请优先以图谱信息为准回答关系类问题，文档信息用于补充细节。如果两者冲突，以图谱信息为准，并说明冲突点。”

这里有一个补充提示词的细节：图谱查询结果往往是多跳路径，大模型不一定能顺畅地理解图路径。我建议在提示词中明确要求“将图谱查询结果转化为自然语言描述后再进行回答”，比如把“甲 -> 持股60% -> 乙”这样的结果描述为“甲公司直接持有乙公司60%的股权”。

在实际演示时，我用了一个实际案例验证融合效果。问题是“查询张三所有直接或间接持股比例超过20%的公司”，传统向量RAG的回答非常零散，知识图谱RAG则能清晰梳理出每一条持股路径并计算间接持股比例。这个对比效果成为了整个Demo的高光时刻。

5. 课件演示设计：从数据准备到现场效果

5.1 演示前的数据准备清单

课件演示最怕现场翻车，数据准备阶段我做了三遍检查：

第一，Neo4j数据完整性检查。启动Neo4j后执行以下统计：

MATCH (n) RETURN labels(n), count(*) ORDER BY count(*) DESC; MATCH ()-[r]->() RETURN type(r), count(*) ORDER BY count(*) DESC;

确认节点和关系数量与预期一致。

第二，Dify知识库就绪检查。我用的是Dify的“结构化数据”类型知识库，上传的文件是待检索的股权说明文档、风险事件说明等材料。文件上传后必须确认“索引状态”显示为“已完成”，而不是“待处理”或“失败”。

第三，工作流连通性测试。先单独测试HTTP请求节点，用一条写死的Cypher语句确认能返回数据，再测试完整工作流，避免现场排查连接问题浪费大量时间。

5.2 三个必做的演示场景

我反复打磨后保留了三个核心演示场景，每一个都对应不同的技术看点：

场景一，多跳关系推理。问题是“甲公司通过哪些路径间接投资了戊公司？”用户提供的问题中提到的实体名称往往不完全一致，工作流需要通过LLM抽取实体后，在Neo4j中匹配近似名称。这个场景展示了图谱RAG在“路径推理”上的能力。

场景二，条件过滤+聚合计算。问题是“列出所有持股比例超过30%的自然人股东及其持股公司。”这展示了图谱RAG对结构化条件的支持。

场景三，图谱+文档混合检索。问题是“简要总结甲公司近两年的风险事件，并结合行业政策分析可能产生的影响。”图谱部分查询风险事件，文档部分查询行业政策文本，最终答案由两者融合生成。这个场景直观展示了“为什么既要图谱也要文档检索”。

5.3 现场演示的常见翻车预防

现场演示容易遇到的问题，我总结了一份清单：

• Dify工作流中模型API超时。演示前把模型服务的超时时间调大，并且准备好备用模型。
• Neo4j未启动或密码错误。做一个一键启动脚本，提前检查端口。
• 知识库索引未完成。如果索引状态一直卡住，检查Embedding模型的连通性。
• 用户问题的实体抽取不准。提示词里要明确“只抽取业务相关实体，不要抽取停用词”。

还有一个优化小技巧：在Dify工作流的“问题分析”节点中加上一个判断分支。如果用户问题不涉及任何已知实体类型，则直接跳过图谱查询，只用文档检索，这样可以避免无意义的数据库访问，也提高了响应速度。

6. 常见问题与排查技巧实录

搭建和调试过程中，我遇到了不少问题，这里记录一些有代表性的：

排查工具方面，我强烈建议在Dify的调试运行界面打开“追踪”模式。每次运行工作流，Dify会记录每个节点的输入输出、耗时和Token消耗。这套日志在做课件答疑时非常好用，学员看到某个节点输出异常，可以立刻定位问题出在哪一步。

还有一个值得记录的配置技巧：HTTP请求节点返回的数据量可能很大，尤其是路径查询时。我在Cypher语句里统一加了“LIMIT 20”或更小的限制，并利用Cypher的collect()函数压缩返回结构。这样既能保证演示的完整效果，也能避免因数据量过大导致Token超限。

7. 这套Demo还能怎么扩展

搭完这套知识图谱RAG之后，我个人的体会是：它最核心的价值不是“用上了知识图谱”这个技术标签，而是让你真正理解了如何根据问题类型选择检索策略。

目前这个Demo只覆盖了“图谱构建 + 双路检索 + 融合回答”的基础流程，后续可以扩展的方向有很多。

一个方向是图谱的自动更新。现在的数据是静态导入的，生产环境中业务数据每天都在变化，可以考虑接一个定时同步流程，将新数据写入Neo4j，同时联动更新Dify知识库中的文档切片。

另一个方向是引入Agent的主动决策能力。目前的流程中，是否需要查图谱是由大模型判断的，但后续可以加入工具调用（比如在公司详情页点击“深度穿透”按钮时直接触发图谱分析）。这种能力在Dify的Agent模式下可以用“工具”形式实现，会显著提升系统的交互性和业务价值。

最后再说一个个人建议：如果你也想做一套类似的课程或Demo，第一版不要追求复杂，先把“数据导入 → 图谱查询 → Dify工作流展示 → 效果对比”这条主线跑通，再迭代增加难度。我在第一版时总想着一步到位把多轮对话、知识图谱自动构建都放进去，结果做了两周还没产出可演示的内容。后来狠心砍掉一半功能，聚焦核心链路，两天就做出了第一个可用版本。技术分享类的课件，能够清楚传达一个核心观点，就已经成功了一大半。

本文还有配套的精品资源，点击获取