简介：本资源是一个面向NLP与知识图谱初学者及实践者的中式菜谱领域知识图谱项目，聚焦知识图谱构建、可视化与基于知识库的智能问答（KBQA）三大核心能力，适用于人工智能课程设计、毕业设计或知识图谱入门实战。项目包含72个文件，以50张菜品实拍JPG图、7个核心Python脚本（如question2sparql.py实现自然语言转SPARQL、jena_sparql_endpoint.py启动查询服务）、7个JSON配置/数据文件（含vizdata.json等可视化元数据）及4张PNG效果图为主，整体包体仅989KB，轻量易部署。已有1214人学习下载，体现了较强的教学适配性与工程参考价值。读者可直接复用三元组数据（aifoodtime_ntriples.nt）、实体词典（entities_list.txt）和完整KBQA流水线，快速搭建支持食材反查菜品、多版本做法对比、图文联动展示的可运行系统，并通过index.html实现交互式知识图谱可视化。
1. 中式菜谱知识图谱不是“把菜名列成表格”，而是让系统真正理解“麻婆豆腐为什么用豆瓣酱、不放蚝油”
很多人第一次接触“中式菜谱知识图谱”时，会下意识把它当成一个带搜索功能的电子菜谱库——输入“宫保鸡丁”，返回做法、食材、热量。但真正的知识图谱要解决的是更底层的问题：当用户问“我有鸡胸肉和花生米，能做什么川菜”，系统不能只匹配菜名关键词，而要推理出“宫保鸡丁”的核心约束是“糊辣味型+荔枝口+花生米为辅料+必须用干辣椒和花椒”，再排除掉“鱼香肉丝”（缺泡椒）、“回锅肉”（需五花肉）等干扰项。这背后依赖的是对“川菜本体”的结构化建模：菜系、味型、烹饪技法、食材属性（如“豆瓣酱”在知识图谱中既是调味品，又属于“发酵类调料”，还关联“郫县产”地理标签）、火候等级（“旺火快炒”与“小火慢㸆”不可互换）。本文聚焦于从零构建一个可落地的中式菜谱知识图谱系统，覆盖知识抽取、图谱存储、可视化呈现和 KBQA 问答引擎四个关键环节，所有步骤均基于开源工具链，无需定制硬件，单机即可完成原型验证。
2. 用 Neo4j + Python 构建中式菜谱知识图谱：从原始菜谱文本到结构化三元组
2.1 为什么选 Neo4j 而非关系型数据库或 Elasticsearch？
中式菜谱知识图谱的核心诉求是关系遍历与路径推理。例如，“适合糖尿病患者的低GI川菜”需要同时满足三个条件：菜系=川菜、食材含“苦瓜/山药/魔芋”（低GI食材）、烹饪法不含“糖醋/红烧”（高糖工艺）。在关系型数据库中，这类多跳关联查询需嵌套 JOIN 多张表（菜系表、食材表、工艺表、营养表），SQL 复杂度指数级上升；Elasticsearch 擅长关键词匹配，但无法表达“豆瓣酱→属于→发酵调料→产地→郫县”这样的层级继承关系。Neo4j 的原生图存储模型天然支持深度关系查询，其 Cypher 查询语言用MATCH (a:Ingredient)-[:USED_IN]->(b:Dish)-[:BELONGS_TO]->(c:Cuisine)即可直观表达语义路径，且社区版已支持百万级节点规模，完全满足菜谱图谱初期需求（主流公开菜谱数据集约 5–10 万条）。
提示：不要用 Neo4j Desktop 的默认配置直接导入大规模数据。首次启动后，务必修改
conf/neo4j.conf中的dbms.memory.heap.initial_size=2g和dbms.memory.heap.max_size=4g，否则导入 1 万条以上节点时会因内存溢出失败。
2.2 从 JSON 菜谱数据提取三元组：用 spaCy 规则匹配替代通用 NER
公开菜谱数据（如 Food.com 或国内某美食平台 API 返回的 JSON）通常包含字段：name（菜名）、ingredients（食材列表）、steps（步骤文本）、tags（标签如“川菜”“家常”）。直接用通用 NER 模型（如 zh-core-web-sm）识别“豆瓣酱”“花椒”效果差——它会把“花椒”识别为地名（四川花椒），把“料酒”误标为时间词。正确做法是构建领域词典驱动的规则匹配器：
import spacy from spacy.matcher import Matcher nlp = spacy.load("zh_core_web_sm") matcher = Matcher(nlp.vocab) # 定义食材词典（从《中国食物成分表》提取 2000+ 条） ingredient_patterns = [ [{"LOWER": "豆瓣"}, {"LOWER": "酱"}], [{"LOWER": "花椒"}, {"OP": "?"}], # 支持“花椒粒”“花椒粉” [{"LOWER": "料"}, {"LOWER": "酒"}], ] matcher.add("INGREDIENT", ingredient_patterns) def extract_triples(recipe_json): doc = nlp(recipe_json["steps"]) matches = matcher(doc) ingredients = set() for match_id, start, end in matches: span = doc[start:end] ingredients.add(span.text.strip()) # 生成三元组：(菜名, USES, 食材)、(菜名, BELONGS_TO, 标签) triples = [] for ing in ingredients: triples.append((recipe_json["name"], "USES", ing)) for tag in recipe_json.get("tags", []): triples.append((recipe_json["name"], "BELONGS_TO", tag)) return triples # 示例：处理单条数据 sample = { "name": "麻婆豆腐", "ingredients": ["豆腐", "牛肉末", "豆瓣酱", "花椒", "蒜苗"], "tags": ["川菜", "下饭菜"] } print(extract_triples(sample)) # 输出：[('麻婆豆腐', 'USES', '豆瓣酱'), ('麻婆豆腐', 'USES', '花椒'), # ('麻婆豆腐', 'BELONGS_TO', '川菜'), ('麻婆豆腐', 'BELONGS_TO', '下饭菜')]这段代码的关键在于：不依赖模型预测，而用精确字符串模式匹配。[{"LOWER": "豆瓣"}, {"LOWER": "酱"}]确保只匹配“豆瓣酱”而非“豆瓣”或“酱”，{"OP": "?"}允许“花椒”后跟零个或一个字（适配“花椒粉”）。实际项目中，需将ingredient_patterns扩展为包含 300+ 常见中式调料、主料、辅料的列表，并加入同义词映射（如“郫县豆瓣酱”→“豆瓣酱”）。
2.3 用 Neo4j Python Driver 批量写入三元组：控制事务大小防超时
Neo4j 对单次事务有默认超时（30 秒）和内存限制。若一次性写入 10 万条三元组，必然失败。必须分批提交，且每批内使用UNWIND语句批量创建节点与关系，而非循环执行CREATE：
from neo4j import GraphDatabase driver = GraphDatabase.driver("bolt://localhost:7687", auth=("neo4j", "password")) session = driver.session() # 分批写入（每批 1000 条） batch_size = 1000 for i in range(0, len(all_triples), batch_size): batch = all_triples[i:i+batch_size] # 构建 Cypher：UNWIND 批量处理，MERGE 避免重复节点 cypher = """ UNWIND $triples AS t MERGE (d:Dish {name: t.dish}) MERGE (i:Ingredient {name: t.ingredient}) CREATE (d)-[:USES]->(i) """ session.run(cypher, triples=[ {"dish": t[0], "ingredient": t[2]} for t in batch if t[1] == "USES" ]) # 同理处理 BELONGS_TO 关系 cypher_tag = """ UNWIND $triples AS t MERGE (d:Dish {name: t.dish}) MERGE (c:Cuisine {name: t.tag}) CREATE (d)-[:BELONGS_TO]->(c) """ session.run(cypher_tag, triples=[ {"dish": t[0], "tag": t[2]} for t in batch if t[1] == "BELONGS_TO" ]) session.close() driver.close()参数说明：
MERGE是关键：它先尝试匹配已有节点，不存在时才创建，避免同一道菜被重复写入多次；UNWIND将传入的 Python 列表展开为 Cypher 内部行集，比循环调用run()快 10 倍以上；batch_size=1000是经验值：小于 500 事务开销大，大于 2000 易触发内存 GC。
3. 用 ECharts 实现菜谱知识图谱可视化：解决“只显示 25 个标签”的渲染瓶颈
3.1 为什么 ECharts 比 Neo4j Browser 更适合业务场景？
Neo4j 自带的 Bloom 可视化工具虽开箱即用，但存在硬性限制：默认最多渲染 25 个节点（官方文档明确说明），且不支持自定义力导向布局参数、无法嵌入 Web 页面、导出图片分辨率低。而 ECharts 的graph组件通过layout: 'force'可承载 5000+ 节点，且提供gravity（引力）、edgeLength（边长）、repulsion（斥力）等精细控制，能确保“川菜”“鲁菜”“粤菜”三大菜系中心节点稳定居中，避免食材节点挤成一团。
3.2 从 Neo4j 导出子图数据：用 Cypher 查询限定范围，避免全量导出
直接MATCH (n) RETURN n会拖垮服务。必须按业务逻辑裁剪子图。例如，展示“麻婆豆腐”的关联网络，需查询其 2 度邻居（即：麻婆豆腐→使用的食材→这些食材又被哪些菜使用）：
// 查询麻婆豆腐的2度关联子图（返回节点+关系） MATCH (d:Dish {name: "麻婆豆腐"})-[:USES|:BELONGS_TO*1..2]-(related) WITH collect(DISTINCT d) + collect(DISTINCT related) AS nodes, [r IN [(d)-[rel:USES|:BELONGS_TO]-(n) | rel] | {source: id(d), target: id(n), label: type(rel)}] AS rels RETURN {nodes: nodes, links: rels} AS result此查询返回一个 JSON 对象，其中nodes包含所有唯一节点（去重），links包含所有关系。注意id(d)返回 Neo4j 内部 ID，前端需映射为可读名称。
3.3 ECharts 配置关键参数：解决中文重叠与力导向发散问题
option = { tooltip: {}, animationDurationUpdate: 1500, series: [{ type: 'graph', layout: 'force', force: { // 核心参数：防止节点飞散 gravity: 0.1, // 引力值越小，节点越靠近中心（0.05~0.2） edgeLength: [100, 200], // 边长范围，避免过短导致重叠 repulsion: 200, // 斥力，值越大节点越分散（但过高会飞出画布） layoutAnimation: true }, data: nodes.map(node => ({ name: node.name || node.properties.name, symbolSize: node.labels.includes('Dish') ? 30 : 15, // 菜名节点更大 category: node.labels[0] // 用于颜色分组 })), links: links.map(link => ({ source: link.source, target: link.target, label: { show: true, formatter: link.label } })), categories: [ {name: 'Dish', itemStyle: {color: '#c23531'}}, {name: 'Ingredient', itemStyle: {color: '#2f4554'}}, {name: 'Cuisine', itemStyle: {color: '#61a0a8'}} ], label: { show: true, position: 'right', fontSize: 12, // 关键：解决中文重叠 formatter: '{b}', distance: 10 } }] };参数说明：
gravity: 0.1：设为较低值，确保菜系节点（如“川菜”）成为视觉锚点，其他节点向其聚拢；edgeLength: [100, 200]：强制边长在合理区间，避免“豆腐”到“豆瓣酱”过短、“豆瓣酱”到“川菜”过长；label.distance: 10：增大标签与节点距离，防止中文文字紧贴节点圆圈造成遮挡；symbolSize动态设置：菜名节点 30px，食材节点 15px，一眼区分层级。
4. 构建 KBQA 问答引擎：用规则模板 + 向量检索实现“能答 80% 常见问题”
4.1 KBQA 不等于“把问题丢给 LLM”：为什么纯大模型方案在此场景失效？
直接用 ChatGLM 或 Qwen 接知识图谱，看似简单，实则灾难：用户问“广东人不爱吃的川菜有哪些”，模型可能编造“开水白菜”（实际是川菜名菜）；问“孕妇能吃的清蒸类川菜”，模型会漏掉“清蒸鲈鱼”（因训练数据未强调“清蒸”与“川菜”的交叉）。根本原因是：大模型缺乏对图谱结构的显式感知，它只能泛化语义，无法执行“查找所有带‘清蒸’标签且菜系=川菜的节点”这样的确定性操作。因此，KBQA 必须分层设计：高频确定性问题走规则引擎，长尾模糊问题走向量检索。
4.2 三类问题的路由策略与实现
| 问题类型 | 示例 | 解决方案 | Cypher 模板 |
|---|---|---|---|
| 实体属性查询 | “麻婆豆腐用什么调料？” | 正则匹配提取实体+关系 | MATCH (d:Dish {name:$dish})-[:USES]->(i:Ingredient) RETURN i.name |
| 关系路径查询 | “豆瓣酱还能做什么菜？” | 固定跳数关系遍历 | MATCH (i:Ingredient {name:"豆瓣酱"})<-[:USES]-(d:Dish) RETURN d.name |
| 语义相似查询 | “有什么适合老人吃的软烂川菜？” | Sentence-BERT 向量化+ANN 检索 | 将问题向量与预存的“软烂”“易消化”等标签向量比对 |
Python 实现路由核心逻辑：
import re from sentence_transformers import SentenceTransformer from sklearn.metrics.pairwise import cosine_similarity model = SentenceTransformer('paraphrase-multilingual-MiniLM-L12-v2') # 预存标签向量（"软烂"、"清淡"、"低油"等） tag_vectors = model.encode(["软烂", "清淡", "低油", "少盐", "易消化"]) def route_question(question): # 规则匹配：提取菜名+关系 dish_match = re.search(r"(.+?)的(.+?)是什么", question) if dish_match: dish, prop = dish_match.groups() return "entity_attr", {"dish": dish.strip(), "prop": prop.strip()} # 关系反查：提取食材名 ing_match = re.search(r"(.+?)还能做什么", question) if ing_match: ingredient = ing_match.group(1).strip() return "relation_path", {"ingredient": ingredient} # 语义匹配：计算与预存标签的相似度 q_vec = model.encode([question]) sims = cosine_similarity(q_vec, tag_vectors)[0] top_tag = ["软烂", "清淡", "低油", "少盐", "易消化"][sims.argmax()] if sims.max() > 0.6: # 相似度阈值 return "semantic", {"tag": top_tag} return "fallback", {} # 调用示例 print(route_question("麻婆豆腐用什么调料？")) # ('entity_attr', {'dish': '麻婆豆腐', 'prop': '调料'}) print(route_question("豆瓣酱还能做什么？")) # ('relation_path', {'ingredient': '豆瓣酱'}) print(route_question("有什么适合老人吃的软烂川菜？")) # ('semantic', {'tag': '软烂'})4.3 Cypher 查询结果转自然语言：用 Jinja2 模板避免硬编码
直接返回["宫保鸡丁", "鱼香肉丝"]不友好。需根据问题类型动态生成回答：
{%- if query_type == "entity_attr" -%} {{ dish }} 使用的{{ prop }}包括：{% for item in results %}{{ item }}{% if not loop.last %}、{% endif %}{% endfor %}。 {%- elif query_type == "relation_path" -%} {{ ingredient }} 还可用于制作：{% for item in results %}{{ item }}{% if not loop.last %}、{% endif %}{% endfor %}。 {%- elif query_type == "semantic" -%} 符合“{{ tag }}”要求的川菜有：{% for item in results %}{{ item }}{% if not loop.last %}、{% endif %}{% endfor %}。 {%- endif -%}调用时传入render(template, query_type="entity_attr", dish="麻婆豆腐", prop="调料", results=["豆瓣酱","花椒","蒜苗"])，输出：“麻婆豆腐使用的调料包括：豆瓣酱、花椒、蒜苗。”
5. 知识图谱可视化与 KBQA 的联调技巧：用 Neo4j 浏览器快速验证 Cypher 逻辑
5.1 在 Neo4j Browser 中调试 Cypher 的三个必查项
可视化前端和 KBQA 后端都依赖 Cypher 查询，但开发时容易忽略底层数据质量。每次上线新问答前，必须在 Neo4j Browser 中手动验证以下三点：
- 节点标签一致性：运行
MATCH (n) RETURN labels(n), count(*) AS cnt GROUP BY labels(n)，确认没有Ingredient和ingredient（大小写混用）或Dish和dish并存； - 关系方向正确性：执行
MATCH ()-[r:USES]->() RETURN type(r), count(*) GROUP BY type(r)，确保USES关系始终从Dish指向Ingredient，而非反向； - 属性完整性：对高频菜名抽样检查，如
MATCH (d:Dish {name:"麻婆豆腐"}) RETURN d.name, size((d)-[:USES]->()) AS used_count，确认used_count≥ 5（典型川菜至少用 5 种以上食材）。
注意：若发现
used_count为 0，说明该菜名在导入时未成功匹配到任何食材——大概率是规则匹配器漏掉了“郫县豆瓣酱”中的“郫县”前缀，需回溯ingredient_patterns补充[{"LOWER": "郫县"}, {"LOWER": "豆瓣"}, {"LOWER": "酱"}]。
5.2 可视化与问答结果的一致性校验：用“点击节点触发问答”验证闭环
在 ECharts 图谱中，为每个节点绑定点击事件，点击“麻婆豆腐”节点时，自动构造问题“麻婆豆腐用什么调料？”，并调用 KBQA 接口。若返回结果与图谱中该节点实际连接的食材节点不一致（如图谱显示连向“豆瓣酱”，但 KBQA 返回“甜面酱”），说明数据源或 Cypher 查询存在偏差。此时应立即在 Neo4j Browser 中执行：
MATCH (d:Dish {name:"麻婆豆腐"})-[:USES]->(i) RETURN i.name对比返回结果与 KBQA 输出，定位是数据导入错误（i.name本身错误）还是 Cypher 拼写错误（如:USE写成:USES）。
5.3 性能压测：用 Apache Bench 模拟并发问答请求
KBQA 接口上线前，必须验证其在真实流量下的稳定性。用ab工具模拟 50 并发、持续 60 秒的压力测试：
ab -n 3000 -c 50 'http://localhost:5000/qa?question=麻婆豆腐用什么调料%EF%BC%9F'关键观察指标：
Time per request（平均响应时间）应 < 800ms；Failed requests必须为 0；- 若
Requests per second< 30，说明 Neo4j 查询未加索引，需执行：CREATE INDEX dish_name_index ON :Dish(name); CREATE INDEX ingredient_name_index ON :Ingredient(name);
最终交付的不是一个静态图表，而是一个可交互、可验证、可扩展的知识服务入口——用户点击“川菜”节点，看到其下属所有菜品；点击某菜品，右侧弹出结构化配料表；输入自然语言问题，系统给出精准答案而非泛泛而谈。这才是中式菜谱知识图谱的真正价值。
本文还有配套的精品资源，点击获取
