传统 RAG 有不少缺点，比如抓不住实体间的深层关系，上下文碎片化，还容易让模型出幻觉，多跳查询也不行。后来就有了 GraphRAG，把知识图谱融进去了，能解决这些问题。

它主要分三步：先构建知识图谱，从数据里抽实体、关系，做好质控和融合；再做图谱检索，定位核心实体，找相关子图和路径；最后结合这些结构化知识让模型生成答案。

还有几种不同的 GraphRAG 方法，各有侧重，微软的 GraphRAG 全局感知强，LightRAG 轻量高效。评估的时候看检索、生成质量和系统性能，生产部署主要难在图谱动态维护、性能扩展、安全和成本控制。

这个菜谱图 RAG 系统搭了 Neo4j+Milvus 双库，配了六核心模块，能智能分析查询复杂度选检索策略，复杂查用多跳推理，中等查组合检索，简单查办底，还带降级机制，数据从图库转结构化文档再建向量索引，支持交互式问答。

环境上需配 Python3.12.7 虚拟环境，用 Docker 启动 Neo4j 图数据库和 Milvus 向量库，配置.env 文件填连接及 LLM 密钥，Neo4j 会自动导入菜谱、食材等节点和关系数据。系统是模块化设计，有六大核心模块，能智能分析查询的复杂度和关系密集度，匹配图 RAG 检索、组合检索或传统混合检索策略，还带降级机制，数据从 Neo4j 提取后构建结构化文档、分块再做 Milvus 向量索引，支持交互式问答和流式输出答案。

 RAG 的图数据建模和 Neo4j 集成，先把 Markdown 菜谱数据用 LLM 转成 nodes 和 relationships 两类 CSV 文件，再导入 Neo4j。设计了菜谱、食材、烹饪步骤等核心节点，还有需要食材、包含步骤等带属性的关系，各节点用 nodeId 唯一标识。用专门模块加载图数据，也给了基础、多跳和复杂推理的 Cypher 查询示例。还会把图数据转成结构化文档，相比传统 RAG，图 RAG 从图库构建文档、靠图遍历获上下文，分块优先保语义，还给每个块关联图节点 ID，元数据也更丰富。

 Milvus 向量索引的构建，是连接图数据和向量检索的关键。核心流程是把图数据库的结构化文档，经分块后用模型转成向量，再存入 Milvus 建索引。核心是 Milvus 索引构建模块，封装了 Milvus 操作，默认用中文优化的 BAAI/bge-small-zh-v1.5 模型做 512 维向量化。设计了适配烹饪知识图谱的专属集合 Schema，包含菜谱名、节点 ID、菜系等丰富图谱元数据，还做了字段长度优化，同时支持批量插入优化，让索引构建更高效、检索更友好。

智能查询路由和检索策略，核心是做智能查询路由器，给不同复杂度查询匹配最优检索策略。路由器先从查询复杂度、关系密集度、推理需求、实体数量四个维度，用 LLM 深度分析查询特征，推荐传统混合、图 RAG 或组合检索策略；若 LLM 分析失败，会降级为基于关键词的规则分析来判断。还会统计各策略使用情况，分析后按推荐策略执行检索，简单查用传统混合检索，复杂推理用图 RAG 检索，中等复杂则用组合检索，适配不同查询需求。

实践中挨踩的6个坑：

1.建 Neo4j 和 Milvus 环境时，容易忘改.env配置里的本地地址，部署到服务器还写localhost，直接连不上数据库，白忙活半天。

2.图数据导入 Neo4j 时，没核对 nodes 和 relationships 的 CSV 里 nodeId 是否一致，关联关系全错，查菜谱连不上对应的食材和步骤。

3.文档分块时照搬传统 RAG 的固定长度分块，把菜谱的食材和步骤切散，破坏语义，后续向量检索根本拿不到完整信息。

4.Milvus 建 Schema 时，随便设字段长度，比如菜谱名、步骤描述字段设太短，导入时数据被截断，检索出来的内容缺斤少两。

5.做智能查询路由时，只依赖 LLM 分析，没做好规则降级兜底，一旦 LLM 调用失败 / 返回格式出错，整个检索直接卡壳，系统崩掉。

6.图 RAG 检索时，多跳推理没设跳数上限，比如查菜谱关联信息时无限遍历，导致数据库查询超时，系统响应巨慢卡得要紧