简介本资源是一个面向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_size2g和dbms.memory.heap.max_size4g否则导入 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语句批量创建节点与关系而非循环执行CREATEfrom 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:ibatch_size] # 构建 CypherUNWIND 批量处理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_size1000是经验值小于 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_typeentity_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平均响应时间应 800msFailed requests必须为 0若Requests per second 30说明 Neo4j 查询未加索引需执行CREATE INDEX dish_name_index ON :Dish(name); CREATE INDEX ingredient_name_index ON :Ingredient(name);最终交付的不是一个静态图表而是一个可交互、可验证、可扩展的知识服务入口——用户点击“川菜”节点看到其下属所有菜品点击某菜品右侧弹出结构化配料表输入自然语言问题系统给出精准答案而非泛泛而谈。这才是中式菜谱知识图谱的真正价值。本文还有配套的精品资源点击获取