简介这套Python毕业设计源码围绕知识图谱与生成式AI的智能食谱推荐系统展开面向计算机相关专业正在做毕设的学生也可用于课程设计或期末大作业。项目经导师指导并通过审核源码已完成本地编译与调试评审得分98分难度适中且结构清晰。压缩包共42个文件、约681KB主要包含前端React工程19个tsx组件、9个less样式、3个ts配置、后端Python入口main.py、YAML配置和shell部署脚本等覆盖界面、逻辑、配置与发布多个环节。已有404人学习下载适合需要快速理解知识图谱与生成式AI在推荐场景落地的学习者也可作为项目实战与二次开发的基础模板。借助该源码可掌握前端与Python后端联调思路并参考其目录组织、模块划分和部署脚本为独立开发同类推荐系统提供实用蓝本也可辅助毕业设计文档撰写与答辩展示。1. 一个毕业设计标题背后为什么把知识图谱和生成式AI绑在食谱推荐上知识图谱和生成式AI这两个词近几年经常一起出现但当它们出现在一个Python毕业设计标题里说明不是简单的技术拼盘。拿到这个源码包第一件事不是急着pip install而是先想清楚它要解决的痛点传统推荐系统只告诉你猜你会喜欢却回答不了为什么推荐这道菜也接不住我今天想吃清淡点这种动态需求。知识图谱把食材、菜品、口味、营养之间的关系结构化生成式AI负责把结构化关系翻译成能看懂的理由甚至生成一份可执行的食谱。这个方向适合想用推荐系统做毕设、又不甘心只调一个协同过滤模型的学生也适合想看看图谱和生成式AI怎么落地的工程师。下面按我复现这个系统的路径展开。2. 拆解系统架构数据从食材到知识图谱再到生成式AI的完整链路2.1 实体与关系怎么设计食材、菜品、营养、口味四类节点设计知识图谱的第一步不是写代码而是画一张节点关系图。食谱推荐涉及的实体至少包括菜品Dish、食材Ingredient、营养Nutrient、口味Taste另外还需要菜系Cuisine和用户User。把它们全部设成独立节点而不是属性是为了后续能走多跳查询。比如用户喜欢辣辣的食材有哪些这些食材出现在哪些菜里如果口味只是菜品的一个字符串属性这种查询就要在Python里全量循环而在图里就是一次Cypher。关系的种类建议控制在10条以内菜品到食材用CONTAINS且带上用量和单位作为关系属性菜品到口味用HAS_TASTE菜品到菜系用BELONGS_TO食材到营养用HAS_NUTRIENT用户到菜品用RATED或LIKED用户到口味用PREFER。为什么关系属性很重要后面计算相似度时共享食材不能只数名称重叠还要看用量级别一道菜用300克豆腐和一道菜用10克豆腐完全不是一个量级。把amount和unit放在关系上可以留给算法一个加权因子。下面是一个种子数据文件的参考结构。我一般会用JSON而不是直接写Cypher因为JSON更接近爬虫或公开数据集的原始形态也好做清洗。[ { name: 宫保鸡丁, ingredients: [ {name: 鸡胸肉, amount: 200, unit: 克}, {name: 花生米, amount: 50, unit: 克}, {name: 干辣椒, amount: 10, unit: 克} ], tastes: [辣, 甜, 麻], cuisine: 川菜, cooking_method: 炒, time_minutes: 20 } ]这个文件里每个字段都对应图谱中的一个属性或关系。ingredients数组经过解析后每个元素会变成一条CONTAINS关系。注意不要把ingredients整体存成一个列表属性那样虽然导入方便但后续所有涉及食材共同出现的查询都无法用索引性能会很难看。2.2 图谱存储选型Neo4j vs 原生Python图库我选哪个我见过不少毕设源码是用 NetworkX 存图理由是少装一个数据库、答辩部署省事。这个选择不是不行但有个现实问题当数据量到几千道菜、几万条关系时NetworkX 的 Python 遍历会明显变慢而且演示时没有办法向台下老师展示实体关系路径。Neo4j Community 版虽然显得重但它自带Browser可视化MATCH p(...)-[...]-(...) RETURN p一敲路径高亮就出来了答辩效果完全不一样。存储方式适合规模查询语言演示效果主要成本Neo4j Community万级节点以内没问题Cypher可视化路径直观需要JVM内存消耗偏高NetworkX千级节点Python原生需要自己画图实现快但多跳查询写起来啰嗦RDFLib适合语义推理SPARQL偏学术对普通Python开发者门槛高如果你的目标是快速跑通后端接口NetworkX完全可以兜底但我接这类项目一般默认选Neo4j并在源码里把图操作封装成一个GraphStore接口这样后续从Neo4j切到NetworkX只需要改一个实现类。数据量不大时这个抽象层不复杂但能让你在毕业设计答辩前不慌。不要把Cypher语句散落在业务代码里否则换个存储就要重写。Neo4j安装后第一件事是去neo4j.conf调内存参数。新版本社区版默认堆可能只有512M导入稍大一点的JSON就会卡死。常见配置是dbms.memory.heap.initial_size2G dbms.memory.heap.max_size4G dbms.memory.pagecache.size2G这是给开发机用的经验值不是严格的性能调优。如果机器内存只有8G建议调低为1G/2G/1G。总之先把内存预算弄清楚再谈导入速度。2.3 生成式AI在这里的角色推荐理由与动态食谱生成生成式AI在整个系统里不是推荐引擎本体它的定位是前端表达层知识图谱算好排序生成式AI把它包装成人话。为什么这么切因为大模型擅长文本生成却不擅长稳定地约束实体关系如果让模型直接推荐菜品它很可能会一本正经地推荐一道图里根本不存在的菜。把这个风险放到架构层图谱负责事实模型负责话术。在这个源码里生成式AI有两个具体任务。第一根据推荐列表生成个性化推荐理由列表来自图谱打分结果Prompt里会带上用户偏好和候选菜第二根据用户限制条件改写食谱比如少油、不要花生、做成一人份。第二个任务需要模型有更强的指令跟随能力Prompt里最好给出明确的输出格式。指令跟随的实现有一个小门道把约束条件放在Prompt末尾也就是模型最后读取的内容位置效果比放在开头好。另一个关键参数是temperature——推荐理由生成可以用0.7让表达有变化但生成结构化食谱时温度要降到0.2左右否则菜谱里的火候和用量会飘。严格一点的实现会让两个任务走不同的LLM配置而不是用一个服务函数包打天下。3. 从零复现核心模块构建知识图谱的最小可运行方案3.1 准备数据从公开食谱数据抽取实体关系先做好心理准备公开食谱数据几乎没有干净的。爬虫抓下来的菜谱里主料和辅料混在一起食材名称带数量、带备注甚至同一个食材出现三种写法。我的处理顺序是先规则抽取再人工小样本校验最后才考虑实体识别。对毕业设计而言规则抽取完全够。常见做法是直接用正则把标记字段切出来。比如主料豆腐 400g牛肉末 100g按分号切再按空格或逗号切数量。这一步不需要完美关键是每个源文件都统一成我们2.1里定义的那个JSON结构。为了能重复运行我会在解析脚本里用一个parse_raw_recipe(text)函数返回标准字典。import re RAW_INGREDIENT_RE re.compile(r([\u4e00-\u9fa5A-Za-z])\s*(\d\.?\d*)\s*(克|斤|毫升|ml|g|kg)?) def parse_raw_ingredients(text: str): items [] for segment in re.split(r[;、,], text): segment segment.strip() if not segment: continue m RAW_INGREDIENT_RE.search(segment) if not m: items.append({name: segment, amount: 0, unit: }) continue name m.group(1) amount float(m.group(2)) if m.group(2) else 0 unit m.group(3) or items.append({name: name, amount: amount, unit: unit}) return items这个正则([\u4e00-\u9fa5A-Za-z])只匹配连续的中英文作为食材名量词单独放后面。实际数据里有鸡蛋2个\d能匹配到2有少许盐这种没有数字的就会走if not m分支把整段当作食材名。这种脏数据不能丢宁可让命名含混也不要因为解析失败把整道菜丢掉。后面还有一个归一化步骤会把这些名字收拢。3.2 用Py2neo写入Neo4j批量导入与去重逻辑数据清洗完后写入Neo4j。用Py2neo还是官方neo4j驱动都可以Py2neo的对象API更贴近Python习惯。写入的关键是去重同一个食材可能被多道菜引用如果每导入一道菜就CREATE一个食材节点图谱里会出现十倍碎片。解法是节点按唯一属性MERGE关系按唯一路径MERGE事务分批提交。from py2neo import Graph, Node, Relationship graph Graph(bolt://localhost:7687, auth(neo4j, yourpassword)) def ensure_indexes(): graph.run(CREATE CONSTRAINT IF NOT EXISTS FOR (d:Dish) REQUIRE d.name IS UNIQUE) graph.run(CREATE CONSTRAINT IF NOT EXISTS FOR (i:Ingredient) REQUIRE i.name IS UNIQUE) def add_dish_ingredient_relations(dish, ingredients): dish_node graph.nodes.match(Dish, namedish[name]).first() if dish_node is None: dish_node Node(Dish, namedish[name], cuisinedish.get(cuisine, )) graph.create(dish_node) for ing in ingredients: ing_node graph.nodes.match(Ingredient, nameing[name]).first() if ing_node is None: ing_node Node(Ingredient, nameing[name]) graph.create(ing_node) rel Relationship(dish_node, CONTAINS, ing_node, amounting[amount], uniting[unit]) graph.merge(rel, CONTAINS, amount)注意最后的graph.merge(rel, CONTAINS, amount)它把关系类型和属性amount作为身份标识。这样做有风险同一个关系如果amount值不同会被当成不同关系。更稳的写法是去掉身份参数先查一下是否存在同类型、同起终点的关系但那个查询会慢一些。对几千道菜的数据量我宁可用慢一点的查重也要保证关系不重复。实际开发里可以把merge的身份参数固定为CONTAINS但我更推荐自己先做relationship_exists()。另外批量导入一定要分事务。Py2neo里graph.begin()和tx.commit()是开源常用的方式。我一般每500条菜谱提交一次避免单事务过大导致锁等待和后端超时。如果导入到一半进程杀了重启后从断点继续只要约束是UNIQUE重复执行不会爆炸。3.3 图谱查询通过Cypher计算相似菜品的三条路径知识图谱建好之后推荐系统才有推理可言。以用户吃过麻婆豆腐为例候选推荐来自于三条路径共享食材最多、口味标签重叠、同菜系。这三条路径不是凭空拍脑袋它们对应现实中的决策逻辑——你爱吃麻婆豆腐可能也爱吃辣、且配料接近的菜。共享食材路径是最核心的一条也是评委最容易理解的。Cypher这样写MATCH (target:Dish {name: 麻婆豆腐})-[:CONTAINS]-(i:Ingredient)-[:CONTAINS]-(candidate:Dish) WITH target, candidate, count(DISTINCT i) AS shared_ingredients WHERE candidate target AND shared_ingredients 2 RETURN candidate.name AS name, shared_ingredients ORDER BY shared_ingredients DESC LIMIT 10;这条查询从目标菜出发找出所有与它共同指向某个食材的候选菜再按共享食材数量排序。WHERE candidate target是必须的否则第一个返回结果一定是它自己。shared_ingredients 2是过滤条件把只因为都用了水或盐而偶然相似的菜去掉。这个阈值可以根据数据量调整如果数据集很小改成 1。口味路径同理只是把中间节点换成TasteMATCH (target:Dish {name: 麻婆豆腐})-[:HAS_TASTE]-(t:Taste)-[:HAS_TASTE]-(candidate:Dish) WITH target, candidate, count(DISTINCT t) AS taste_overlap RETURN candidate.name, taste_overlap ORDER BY taste_overlap DESC LIMIT 5;同菜系路径最简单也最弱因为同菜系里的菜可能差别很大比如川菜的麻婆豆腐和开水白菜没有任何食材交集。所以我把它作为加权特征而不是单独召回条件。三条路径的召回结果在4.1里合并成一个打分。4. 让推荐不再像黑匣子图谱路径排序 生成式AI融合的两种做法4.1 基于图谱的推荐打分从吃过麻婆豆腐到推荐宫保鸡丁有了图谱路径之后推荐逻辑变成了一个多路召回再排序的问题。我不会在Cypher里直接完成加权排序因为权重、用户个性化参数经常要调整把逻辑放在Python里更好改。先从用户历史中拿到所有吃过的菜对每道菜执行多路径召回将候选菜的得分累加。from collections import defaultdict def candidate_scores_from_dish(graph, dish_name): return graph.run( MATCH (d:Dish {name:$dish})-[:CONTAINS]-(i:Ingredient)-[:CONTAINS]-(c:Dish) OPTIONAL MATCH (d)-[:HAS_TASTE]-(t:Taste)-[:HAS_TASTE]-(c) OPTIONAL MATCH (d)-[:BELONGS_TO]-(cu:Cuisine)-[:BELONGS_TO]-(c) WHERE c d RETURN c.name AS name, count(DISTINCT i) AS shared, count(DISTINCT t) AS taste_overlap, count(DISTINCT cu) AS same_cuisine , dishdish_name ).data() def recommend_for_user(graph, user_liked_dishes, top_k10): scores defaultdict(float) for liked in user_liked_dishes: rows candidate_scores_from_dish(graph, liked) for row in rows: score (2.0 * row[shared] 1.5 * row[taste_overlap] 0.8 * row[same_cuisine]) scores[row[name]] score return sorted(scores.items(), keylambda x: x[1], reverseTrue)[:top_k]这里defaultdict(float)的好处是候选菜不用预先注册。权重2.0/1.5/0.8是经验值不是解析出来的最优解——我把它们放在配置里方便答辩时现场演示调参。为什么要这个比例共享食材是最强信号权重给最高口味重叠比同菜系更接近用户主观体验同菜系的0.8只是加分项防止召回完全为空。需要注意这个打分没有归一化如果用户吃过10道菜和只吃过1道菜候选得分范围完全不同。简单做法是最终除以用户菜品数量得到平均贡献或者用score score / max_score_in_current_user做排序。毕业设计答辩时评委通常会问这个分数有没有归一化提前做好这个点会加分。4.2 用生成式AI生成个性化推荐理由Prompt模板与温度参数图谱输出了排序结果但用户看到的不能只是一行行菜名。把候选菜和用户偏好拼进Prompt让LLM输出推荐理由。关键是把事实与话术分离Prompt里用固定模板指出只能从候选列表里选不能新增菜。def build_recommendation_prompt(user_prefs, candidates): candidate_text \n.join(f{i1}. {name} for i, name in enumerate(candidates)) return f 你是中餐推荐助手。下面是从知识图谱中检索到的候选菜列表已经按相似度排序。 根据用户偏好从列表中选择3道菜为每道写一句不超过50字的推荐理由。 必须使用列表中的菜名不要发明新菜。 用户偏好{user_prefs} 候选菜 {candidate_text} 模型侧调用时temperature建议设置在0.7到0.9之间理由生成需要一点多样性但如果发现每次回复的菜名对不上候选就统一降到0.3以内。max_tokens也不要给太大理由生成给300足够否则模型会替你做决定写一大段。resp llm_client.chat.completions.create( modelgpt-3.5-turbo, messages[{role: user, content: build_recommendation_prompt(user_prefs, top_candidates)}], temperature0.7, max_tokens300 )源码里这个llm_client建议封装在LLMBackend类里因为学校机房可能没有外网答辩时很容易出现超时。我见过一个同学现场开演前发现API key到期最后解决办法是本地接了一个量化模型走Ollama接口。所以封装时把base_url和model都做成配置项切到本地只要改两个字段不用改业务代码。4.3 兜底策略图谱缺失时怎么避免翻车知识图谱最怕未知实体。用户输入今天想吃三文鱼图谱里只有鲑鱼如果不做实体对齐推荐列表直接为空。处理方式分两层第一层是别名表把常见同义词集中映射比如三文鱼映射到鲑鱼第二层是模糊匹配用编辑距离或简单包含关系在所有Ingredient节点里找最接近的。def resolve_ingredient_alias(name, graph): alias_map {三文鱼: 鲑鱼, 西红柿: 番茄, 马铃薯: 土豆} if name in alias_map: return alias_map[name] matcher graph.nodes.match(Ingredient) candidates [node[name] for node in matcher if node[name]] # 简单包含匹配适合小规模图谱 for candidate in candidates: if name in candidate or candidate in name: return candidate return None这段代码逻辑很直白先用显式别名表再退到图节点遍历做包含匹配。它不适合大数据量但毕设数据量在几千节点时一次全遍历也就几十毫秒。如果不想遍历Neo4j层面可以做WHERE i.name CONTAINS $partial的查询走全文索引前需要先建索引。兜底原则是宁可返回没找到也不要让整个接口500。还有一个容易被忽视的兜底LLM生成食谱时可能输出一个图谱里根本不存在的食材组合。例如图谱里只有鸡肉和花生模型却写出加虾仁。解决方法是生成后解析出食材提及与图谱Ingredient节点集合求交集不在白名单里的词替换成可选配菜或直接删除。这一步在源码里通常是validate_generated_ingredients()函数别省略否则演示时模型随手给一个奇怪食材整个系统的可信度就崩了。5. 避坑指南这5个坑让我的毕业设计多走了两个月5.1 中文菜品名称不一致同一道菜两个名字现象图谱中同时存在西红柿炒鸡蛋和番茄炒蛋两个节点没有关系。用户已经吃过前者推荐算法在找共享食材时只能看到西红柿和鸡蛋而后者写的是番茄和蛋两个候选因此完全失联。初次跑推荐时我总觉得效果差打印出候选列表才发现是同一个菜被拆成了两个节点。原因数据来源不同站点有的叫番茄炒蛋有的是西红柿炒鸡蛋导入脚本只做了去空格和大小写处理。中文菜名不像英文食材有固定拼写同一种东西可以有绰号、地域叫法靠一套规则根本覆盖不完。解决在导入阶段维护一个dish_synonym.json别名表把所有出现的变体映射到规范名。规范名选择出现频次最高的写法。这个表不用一次性做完整第一版可以只录入高频重复项然后跑一遍推荐把仍然明显的重复导入日志并手动补录。要验证是否修好可以查图谱里包含番茄的节点数量MATCH (d:Dish) WHERE d.name CONTAINS 番茄 OR d.name CONTAINS 西红柿 RETURN d.name, count(*) AS c;如果还有两个高频名称并列就继续补别名。这个操作是项目里性价比最高的没有之一。5.2 Neo4j内存不够导致导入卡死现象用Py2neo批量插入到一半进程报ConnectionResetNeo4j浏览器也连不上后台日志出现OutOfMemory重启后数据库无法正常启动最后只能删库重导。原因Community版默认堆内存太小我的数据量只有4000多个节点但导入脚本在一个事务里把整个JSON一次性create完JVM直接打爆。更隐蔽的是Neo4j默认的死锁检测和事务日志也会吃内存。解决开发机内存如果只有8G先把neo4j.conf改成2G堆1G页缓存然后重启服务。更重要的是导入端分事务批量提交def batch_import(graph, dishes, batch_size500): tx graph.begin() for i, dish in enumerate(dishes): add_dish_ingredient_relations(tx, dish) if (i 1) % batch_size 0: tx.commit() tx graph.begin() tx.commit()注意这里传入的是tx而不是graphPy2neo里的graph.create和tx.create表现不同事务里必须用后者的创建逻辑。改完后再导内存曲线会平稳很多。要验证可以看Neo4j的logs/neo4j.log出现Started表示没有重启崩溃。5.3 生成式AI生成不存在的食材组合现象推荐理由里的菜名是图谱中有的但模型在解释时写加入100克虾仁实际上这道菜图谱里根本没有虾仁用户看到会认为系统在胡说。原因大模型训练时见过太多菜谱只要Prompt里给了菜名它就会按记忆补全常见配料不会去核对图谱。你只约束了菜名没约束配料幻觉就钻了空子。解决生成后做食材合法性校验。把图谱所有Ingredient节点名称做成一个集合用正则从LLM输出里提取食材词不在集合里的删除或替换成可选配菜。更推荐在Prompt末尾加一行只能使用以下白名单食材……实测对指令跟随能力较强的模型很有效。温度也要压下来0.3以下。校验脚本的核心就一行safe_ingredients {ing[name] for ing in graph.nodes.match(Ingredient)} unseen [w for w in generated_ingredients if w not in safe_ingredients]如果unseen非空就把对应句子整体标记为建议不要说它是事实。5.4 推荐结果冷启动用户没有历史记录现象新用户注册后登录推荐接口返回空数组前端直接白屏。这个坑特别容易在答辩演示时被考官戳到因为考官很可能让现场新建一个账号。原因推荐逻辑完全依赖用户与菜品之间的LIKED关系新用户没有行为历史图谱里没有任何可展开的路径于是排序函数返回空。解决给推荐服务加一个user_based_recommend的判断分支如果该用户没有历史记录直接返回全局热门菜TOP20。热门菜的计算不要在查询时实时聚合可以在导入完成后跑一个统计任务把每个Dish的入度被多少用户评分或浏览写入节点属性hot_score。接口侧返回MATCH (d:Dish) RETURN d.name AS name, d.hot_score AS hot_score ORDER BY d.hot_score DESC LIMIT 20;这样冷启动接口永远有数据前端文案改成大家都在吃而不是为你推荐语义上也正确。5.5 前端展示查询超时现象点击推荐按钮后转圈10秒钟才出现结果有时直接返回 Request Timeout。第一次出现时我以为是前端问题后来开开发者工具发现接口耗时12秒问题在后端。原因Cypher查询没有限制返回行数候选菜多的时候把上千行数据全取回来了而且后端每次请求都新建Graph连接Neo4j握手开销被反复支付。更糟糕的是查询里OPTIONAL MATCH三个分支同时展开中间节点数量成倍膨胀。解决第一所有推荐查询都加LIMIT 20永远不要RETURN大字段。第二把Graph对象设计成FastAPI的依赖单例不每请求重连。第三加一层Redis缓存key是rec:{user_id}:{top_k}有效期5分钟。这三步做完接口一般能从10秒降到200毫秒。如果还想更快在Neo4j侧给Dish的popularity属性建普通索引但别建全文本索引那个对CypherORDER BY没有帮助。6. 把源码变成能演示的系统验证方法和三个细节6.1 离线评估留出法算Recall10推荐系统不好评估但毕设答辩需要数字。把用户行为按时间排序前70%作为训练集后30%作为测试集。训练集用来生成图谱中的用户偏好关系测试集的菜品作为标准答案。计算推荐列表在标准答案上的召回率def recall_at_k(recommended, actual, k10): if not actual: return 0.0 return len(set(recommended[:k]) set(actual)) / len(actual)逻辑说明除以所有真实菜品数而不是交集大小是因为召回率衡量推荐出来的占用户实际消费的比例。这个指标比较粗糙但足以用来判断图谱路径调整是否向正确方向移动。你会经常发现权重改一点数字掉一截这就是图谱里实体关系质量不足的信号。6.2 三个值得加到源码里的细节第一给Ingredient.name和Dish.name建唯一约束导入时会自动去重查询也会走索引。第二把Cypher里的路径控制在3跳以内超过3跳的推荐语义已经稀薄还拖慢查询。第三把用户偏好、推荐结果都做一层缓存接口响应从2秒降到200毫秒演示体验完全不同。6.3 演示时的节奏演示时建议按冷启动热门榜到用户点了几道菜再看推荐变化的顺序讲让观众先看到推荐器在没有数据时的底座再看到图谱带来的个性化更新。生成式AI的话术放在最后作为价值放大器不要让大模型抢掉图谱展示的时间。我第一次跑这个系统时只顾着调LLM的Prompt结果推荐结果因为食材别名没有对齐而惨不忍睹后来花了最多时间做的其实是实体对齐。这个教训一直在我脑子里。希望帮到你。本文还有配套的精品资源点击获取
简介这套Python毕业设计源码围绕知识图谱与生成式AI的智能食谱推荐系统展开面向计算机相关专业正在做毕设的学生也可用于课程设计或期末大作业。项目经导师指导并通过审核源码已完成本地编译与调试评审得分98分难度适中且结构清晰。压缩包共42个文件、约681KB主要包含前端React工程19个tsx组件、9个less样式、3个ts配置、后端Python入口main.py、YAML配置和shell部署脚本等覆盖界面、逻辑、配置与发布多个环节。已有404人学习下载适合需要快速理解知识图谱与生成式AI在推荐场景落地的学习者也可作为项目实战与二次开发的基础模板。借助该源码可掌握前端与Python后端联调思路并参考其目录组织、模块划分和部署脚本为独立开发同类推荐系统提供实用蓝本也可辅助毕业设计文档撰写与答辩展示。1. 一个毕业设计标题背后为什么把知识图谱和生成式AI绑在食谱推荐上知识图谱和生成式AI这两个词近几年经常一起出现但当它们出现在一个Python毕业设计标题里说明不是简单的技术拼盘。拿到这个源码包第一件事不是急着pip install而是先想清楚它要解决的痛点传统推荐系统只告诉你猜你会喜欢却回答不了为什么推荐这道菜也接不住我今天想吃清淡点这种动态需求。知识图谱把食材、菜品、口味、营养之间的关系结构化生成式AI负责把结构化关系翻译成能看懂的理由甚至生成一份可执行的食谱。这个方向适合想用推荐系统做毕设、又不甘心只调一个协同过滤模型的学生也适合想看看图谱和生成式AI怎么落地的工程师。下面按我复现这个系统的路径展开。2. 拆解系统架构数据从食材到知识图谱再到生成式AI的完整链路2.1 实体与关系怎么设计食材、菜品、营养、口味四类节点设计知识图谱的第一步不是写代码而是画一张节点关系图。食谱推荐涉及的实体至少包括菜品Dish、食材Ingredient、营养Nutrient、口味Taste另外还需要菜系Cuisine和用户User。把它们全部设成独立节点而不是属性是为了后续能走多跳查询。比如用户喜欢辣辣的食材有哪些这些食材出现在哪些菜里如果口味只是菜品的一个字符串属性这种查询就要在Python里全量循环而在图里就是一次Cypher。关系的种类建议控制在10条以内菜品到食材用CONTAINS且带上用量和单位作为关系属性菜品到口味用HAS_TASTE菜品到菜系用BELONGS_TO食材到营养用HAS_NUTRIENT用户到菜品用RATED或LIKED用户到口味用PREFER。为什么关系属性很重要后面计算相似度时共享食材不能只数名称重叠还要看用量级别一道菜用300克豆腐和一道菜用10克豆腐完全不是一个量级。把amount和unit放在关系上可以留给算法一个加权因子。下面是一个种子数据文件的参考结构。我一般会用JSON而不是直接写Cypher因为JSON更接近爬虫或公开数据集的原始形态也好做清洗。[ { name: 宫保鸡丁, ingredients: [ {name: 鸡胸肉, amount: 200, unit: 克}, {name: 花生米, amount: 50, unit: 克}, {name: 干辣椒, amount: 10, unit: 克} ], tastes: [辣, 甜, 麻], cuisine: 川菜, cooking_method: 炒, time_minutes: 20 } ]这个文件里每个字段都对应图谱中的一个属性或关系。ingredients数组经过解析后每个元素会变成一条CONTAINS关系。注意不要把ingredients整体存成一个列表属性那样虽然导入方便但后续所有涉及食材共同出现的查询都无法用索引性能会很难看。2.2 图谱存储选型Neo4j vs 原生Python图库我选哪个我见过不少毕设源码是用 NetworkX 存图理由是少装一个数据库、答辩部署省事。这个选择不是不行但有个现实问题当数据量到几千道菜、几万条关系时NetworkX 的 Python 遍历会明显变慢而且演示时没有办法向台下老师展示实体关系路径。Neo4j Community 版虽然显得重但它自带Browser可视化MATCH p(...)-[...]-(...) RETURN p一敲路径高亮就出来了答辩效果完全不一样。存储方式适合规模查询语言演示效果主要成本Neo4j Community万级节点以内没问题Cypher可视化路径直观需要JVM内存消耗偏高NetworkX千级节点Python原生需要自己画图实现快但多跳查询写起来啰嗦RDFLib适合语义推理SPARQL偏学术对普通Python开发者门槛高如果你的目标是快速跑通后端接口NetworkX完全可以兜底但我接这类项目一般默认选Neo4j并在源码里把图操作封装成一个GraphStore接口这样后续从Neo4j切到NetworkX只需要改一个实现类。数据量不大时这个抽象层不复杂但能让你在毕业设计答辩前不慌。不要把Cypher语句散落在业务代码里否则换个存储就要重写。Neo4j安装后第一件事是去neo4j.conf调内存参数。新版本社区版默认堆可能只有512M导入稍大一点的JSON就会卡死。常见配置是dbms.memory.heap.initial_size2G dbms.memory.heap.max_size4G dbms.memory.pagecache.size2G这是给开发机用的经验值不是严格的性能调优。如果机器内存只有8G建议调低为1G/2G/1G。总之先把内存预算弄清楚再谈导入速度。2.3 生成式AI在这里的角色推荐理由与动态食谱生成生成式AI在整个系统里不是推荐引擎本体它的定位是前端表达层知识图谱算好排序生成式AI把它包装成人话。为什么这么切因为大模型擅长文本生成却不擅长稳定地约束实体关系如果让模型直接推荐菜品它很可能会一本正经地推荐一道图里根本不存在的菜。把这个风险放到架构层图谱负责事实模型负责话术。在这个源码里生成式AI有两个具体任务。第一根据推荐列表生成个性化推荐理由列表来自图谱打分结果Prompt里会带上用户偏好和候选菜第二根据用户限制条件改写食谱比如少油、不要花生、做成一人份。第二个任务需要模型有更强的指令跟随能力Prompt里最好给出明确的输出格式。指令跟随的实现有一个小门道把约束条件放在Prompt末尾也就是模型最后读取的内容位置效果比放在开头好。另一个关键参数是temperature——推荐理由生成可以用0.7让表达有变化但生成结构化食谱时温度要降到0.2左右否则菜谱里的火候和用量会飘。严格一点的实现会让两个任务走不同的LLM配置而不是用一个服务函数包打天下。3. 从零复现核心模块构建知识图谱的最小可运行方案3.1 准备数据从公开食谱数据抽取实体关系先做好心理准备公开食谱数据几乎没有干净的。爬虫抓下来的菜谱里主料和辅料混在一起食材名称带数量、带备注甚至同一个食材出现三种写法。我的处理顺序是先规则抽取再人工小样本校验最后才考虑实体识别。对毕业设计而言规则抽取完全够。常见做法是直接用正则把标记字段切出来。比如主料豆腐 400g牛肉末 100g按分号切再按空格或逗号切数量。这一步不需要完美关键是每个源文件都统一成我们2.1里定义的那个JSON结构。为了能重复运行我会在解析脚本里用一个parse_raw_recipe(text)函数返回标准字典。import re RAW_INGREDIENT_RE re.compile(r([\u4e00-\u9fa5A-Za-z])\s*(\d\.?\d*)\s*(克|斤|毫升|ml|g|kg)?) def parse_raw_ingredients(text: str): items [] for segment in re.split(r[;、,], text): segment segment.strip() if not segment: continue m RAW_INGREDIENT_RE.search(segment) if not m: items.append({name: segment, amount: 0, unit: }) continue name m.group(1) amount float(m.group(2)) if m.group(2) else 0 unit m.group(3) or items.append({name: name, amount: amount, unit: unit}) return items这个正则([\u4e00-\u9fa5A-Za-z])只匹配连续的中英文作为食材名量词单独放后面。实际数据里有鸡蛋2个\d能匹配到2有少许盐这种没有数字的就会走if not m分支把整段当作食材名。这种脏数据不能丢宁可让命名含混也不要因为解析失败把整道菜丢掉。后面还有一个归一化步骤会把这些名字收拢。3.2 用Py2neo写入Neo4j批量导入与去重逻辑数据清洗完后写入Neo4j。用Py2neo还是官方neo4j驱动都可以Py2neo的对象API更贴近Python习惯。写入的关键是去重同一个食材可能被多道菜引用如果每导入一道菜就CREATE一个食材节点图谱里会出现十倍碎片。解法是节点按唯一属性MERGE关系按唯一路径MERGE事务分批提交。from py2neo import Graph, Node, Relationship graph Graph(bolt://localhost:7687, auth(neo4j, yourpassword)) def ensure_indexes(): graph.run(CREATE CONSTRAINT IF NOT EXISTS FOR (d:Dish) REQUIRE d.name IS UNIQUE) graph.run(CREATE CONSTRAINT IF NOT EXISTS FOR (i:Ingredient) REQUIRE i.name IS UNIQUE) def add_dish_ingredient_relations(dish, ingredients): dish_node graph.nodes.match(Dish, namedish[name]).first() if dish_node is None: dish_node Node(Dish, namedish[name], cuisinedish.get(cuisine, )) graph.create(dish_node) for ing in ingredients: ing_node graph.nodes.match(Ingredient, nameing[name]).first() if ing_node is None: ing_node Node(Ingredient, nameing[name]) graph.create(ing_node) rel Relationship(dish_node, CONTAINS, ing_node, amounting[amount], uniting[unit]) graph.merge(rel, CONTAINS, amount)注意最后的graph.merge(rel, CONTAINS, amount)它把关系类型和属性amount作为身份标识。这样做有风险同一个关系如果amount值不同会被当成不同关系。更稳的写法是去掉身份参数先查一下是否存在同类型、同起终点的关系但那个查询会慢一些。对几千道菜的数据量我宁可用慢一点的查重也要保证关系不重复。实际开发里可以把merge的身份参数固定为CONTAINS但我更推荐自己先做relationship_exists()。另外批量导入一定要分事务。Py2neo里graph.begin()和tx.commit()是开源常用的方式。我一般每500条菜谱提交一次避免单事务过大导致锁等待和后端超时。如果导入到一半进程杀了重启后从断点继续只要约束是UNIQUE重复执行不会爆炸。3.3 图谱查询通过Cypher计算相似菜品的三条路径知识图谱建好之后推荐系统才有推理可言。以用户吃过麻婆豆腐为例候选推荐来自于三条路径共享食材最多、口味标签重叠、同菜系。这三条路径不是凭空拍脑袋它们对应现实中的决策逻辑——你爱吃麻婆豆腐可能也爱吃辣、且配料接近的菜。共享食材路径是最核心的一条也是评委最容易理解的。Cypher这样写MATCH (target:Dish {name: 麻婆豆腐})-[:CONTAINS]-(i:Ingredient)-[:CONTAINS]-(candidate:Dish) WITH target, candidate, count(DISTINCT i) AS shared_ingredients WHERE candidate target AND shared_ingredients 2 RETURN candidate.name AS name, shared_ingredients ORDER BY shared_ingredients DESC LIMIT 10;这条查询从目标菜出发找出所有与它共同指向某个食材的候选菜再按共享食材数量排序。WHERE candidate target是必须的否则第一个返回结果一定是它自己。shared_ingredients 2是过滤条件把只因为都用了水或盐而偶然相似的菜去掉。这个阈值可以根据数据量调整如果数据集很小改成 1。口味路径同理只是把中间节点换成TasteMATCH (target:Dish {name: 麻婆豆腐})-[:HAS_TASTE]-(t:Taste)-[:HAS_TASTE]-(candidate:Dish) WITH target, candidate, count(DISTINCT t) AS taste_overlap RETURN candidate.name, taste_overlap ORDER BY taste_overlap DESC LIMIT 5;同菜系路径最简单也最弱因为同菜系里的菜可能差别很大比如川菜的麻婆豆腐和开水白菜没有任何食材交集。所以我把它作为加权特征而不是单独召回条件。三条路径的召回结果在4.1里合并成一个打分。4. 让推荐不再像黑匣子图谱路径排序 生成式AI融合的两种做法4.1 基于图谱的推荐打分从吃过麻婆豆腐到推荐宫保鸡丁有了图谱路径之后推荐逻辑变成了一个多路召回再排序的问题。我不会在Cypher里直接完成加权排序因为权重、用户个性化参数经常要调整把逻辑放在Python里更好改。先从用户历史中拿到所有吃过的菜对每道菜执行多路径召回将候选菜的得分累加。from collections import defaultdict def candidate_scores_from_dish(graph, dish_name): return graph.run( MATCH (d:Dish {name:$dish})-[:CONTAINS]-(i:Ingredient)-[:CONTAINS]-(c:Dish) OPTIONAL MATCH (d)-[:HAS_TASTE]-(t:Taste)-[:HAS_TASTE]-(c) OPTIONAL MATCH (d)-[:BELONGS_TO]-(cu:Cuisine)-[:BELONGS_TO]-(c) WHERE c d RETURN c.name AS name, count(DISTINCT i) AS shared, count(DISTINCT t) AS taste_overlap, count(DISTINCT cu) AS same_cuisine , dishdish_name ).data() def recommend_for_user(graph, user_liked_dishes, top_k10): scores defaultdict(float) for liked in user_liked_dishes: rows candidate_scores_from_dish(graph, liked) for row in rows: score (2.0 * row[shared] 1.5 * row[taste_overlap] 0.8 * row[same_cuisine]) scores[row[name]] score return sorted(scores.items(), keylambda x: x[1], reverseTrue)[:top_k]这里defaultdict(float)的好处是候选菜不用预先注册。权重2.0/1.5/0.8是经验值不是解析出来的最优解——我把它们放在配置里方便答辩时现场演示调参。为什么要这个比例共享食材是最强信号权重给最高口味重叠比同菜系更接近用户主观体验同菜系的0.8只是加分项防止召回完全为空。需要注意这个打分没有归一化如果用户吃过10道菜和只吃过1道菜候选得分范围完全不同。简单做法是最终除以用户菜品数量得到平均贡献或者用score score / max_score_in_current_user做排序。毕业设计答辩时评委通常会问这个分数有没有归一化提前做好这个点会加分。4.2 用生成式AI生成个性化推荐理由Prompt模板与温度参数图谱输出了排序结果但用户看到的不能只是一行行菜名。把候选菜和用户偏好拼进Prompt让LLM输出推荐理由。关键是把事实与话术分离Prompt里用固定模板指出只能从候选列表里选不能新增菜。def build_recommendation_prompt(user_prefs, candidates): candidate_text \n.join(f{i1}. {name} for i, name in enumerate(candidates)) return f 你是中餐推荐助手。下面是从知识图谱中检索到的候选菜列表已经按相似度排序。 根据用户偏好从列表中选择3道菜为每道写一句不超过50字的推荐理由。 必须使用列表中的菜名不要发明新菜。 用户偏好{user_prefs} 候选菜 {candidate_text} 模型侧调用时temperature建议设置在0.7到0.9之间理由生成需要一点多样性但如果发现每次回复的菜名对不上候选就统一降到0.3以内。max_tokens也不要给太大理由生成给300足够否则模型会替你做决定写一大段。resp llm_client.chat.completions.create( modelgpt-3.5-turbo, messages[{role: user, content: build_recommendation_prompt(user_prefs, top_candidates)}], temperature0.7, max_tokens300 )源码里这个llm_client建议封装在LLMBackend类里因为学校机房可能没有外网答辩时很容易出现超时。我见过一个同学现场开演前发现API key到期最后解决办法是本地接了一个量化模型走Ollama接口。所以封装时把base_url和model都做成配置项切到本地只要改两个字段不用改业务代码。4.3 兜底策略图谱缺失时怎么避免翻车知识图谱最怕未知实体。用户输入今天想吃三文鱼图谱里只有鲑鱼如果不做实体对齐推荐列表直接为空。处理方式分两层第一层是别名表把常见同义词集中映射比如三文鱼映射到鲑鱼第二层是模糊匹配用编辑距离或简单包含关系在所有Ingredient节点里找最接近的。def resolve_ingredient_alias(name, graph): alias_map {三文鱼: 鲑鱼, 西红柿: 番茄, 马铃薯: 土豆} if name in alias_map: return alias_map[name] matcher graph.nodes.match(Ingredient) candidates [node[name] for node in matcher if node[name]] # 简单包含匹配适合小规模图谱 for candidate in candidates: if name in candidate or candidate in name: return candidate return None这段代码逻辑很直白先用显式别名表再退到图节点遍历做包含匹配。它不适合大数据量但毕设数据量在几千节点时一次全遍历也就几十毫秒。如果不想遍历Neo4j层面可以做WHERE i.name CONTAINS $partial的查询走全文索引前需要先建索引。兜底原则是宁可返回没找到也不要让整个接口500。还有一个容易被忽视的兜底LLM生成食谱时可能输出一个图谱里根本不存在的食材组合。例如图谱里只有鸡肉和花生模型却写出加虾仁。解决方法是生成后解析出食材提及与图谱Ingredient节点集合求交集不在白名单里的词替换成可选配菜或直接删除。这一步在源码里通常是validate_generated_ingredients()函数别省略否则演示时模型随手给一个奇怪食材整个系统的可信度就崩了。5. 避坑指南这5个坑让我的毕业设计多走了两个月5.1 中文菜品名称不一致同一道菜两个名字现象图谱中同时存在西红柿炒鸡蛋和番茄炒蛋两个节点没有关系。用户已经吃过前者推荐算法在找共享食材时只能看到西红柿和鸡蛋而后者写的是番茄和蛋两个候选因此完全失联。初次跑推荐时我总觉得效果差打印出候选列表才发现是同一个菜被拆成了两个节点。原因数据来源不同站点有的叫番茄炒蛋有的是西红柿炒鸡蛋导入脚本只做了去空格和大小写处理。中文菜名不像英文食材有固定拼写同一种东西可以有绰号、地域叫法靠一套规则根本覆盖不完。解决在导入阶段维护一个dish_synonym.json别名表把所有出现的变体映射到规范名。规范名选择出现频次最高的写法。这个表不用一次性做完整第一版可以只录入高频重复项然后跑一遍推荐把仍然明显的重复导入日志并手动补录。要验证是否修好可以查图谱里包含番茄的节点数量MATCH (d:Dish) WHERE d.name CONTAINS 番茄 OR d.name CONTAINS 西红柿 RETURN d.name, count(*) AS c;如果还有两个高频名称并列就继续补别名。这个操作是项目里性价比最高的没有之一。5.2 Neo4j内存不够导致导入卡死现象用Py2neo批量插入到一半进程报ConnectionResetNeo4j浏览器也连不上后台日志出现OutOfMemory重启后数据库无法正常启动最后只能删库重导。原因Community版默认堆内存太小我的数据量只有4000多个节点但导入脚本在一个事务里把整个JSON一次性create完JVM直接打爆。更隐蔽的是Neo4j默认的死锁检测和事务日志也会吃内存。解决开发机内存如果只有8G先把neo4j.conf改成2G堆1G页缓存然后重启服务。更重要的是导入端分事务批量提交def batch_import(graph, dishes, batch_size500): tx graph.begin() for i, dish in enumerate(dishes): add_dish_ingredient_relations(tx, dish) if (i 1) % batch_size 0: tx.commit() tx graph.begin() tx.commit()注意这里传入的是tx而不是graphPy2neo里的graph.create和tx.create表现不同事务里必须用后者的创建逻辑。改完后再导内存曲线会平稳很多。要验证可以看Neo4j的logs/neo4j.log出现Started表示没有重启崩溃。5.3 生成式AI生成不存在的食材组合现象推荐理由里的菜名是图谱中有的但模型在解释时写加入100克虾仁实际上这道菜图谱里根本没有虾仁用户看到会认为系统在胡说。原因大模型训练时见过太多菜谱只要Prompt里给了菜名它就会按记忆补全常见配料不会去核对图谱。你只约束了菜名没约束配料幻觉就钻了空子。解决生成后做食材合法性校验。把图谱所有Ingredient节点名称做成一个集合用正则从LLM输出里提取食材词不在集合里的删除或替换成可选配菜。更推荐在Prompt末尾加一行只能使用以下白名单食材……实测对指令跟随能力较强的模型很有效。温度也要压下来0.3以下。校验脚本的核心就一行safe_ingredients {ing[name] for ing in graph.nodes.match(Ingredient)} unseen [w for w in generated_ingredients if w not in safe_ingredients]如果unseen非空就把对应句子整体标记为建议不要说它是事实。5.4 推荐结果冷启动用户没有历史记录现象新用户注册后登录推荐接口返回空数组前端直接白屏。这个坑特别容易在答辩演示时被考官戳到因为考官很可能让现场新建一个账号。原因推荐逻辑完全依赖用户与菜品之间的LIKED关系新用户没有行为历史图谱里没有任何可展开的路径于是排序函数返回空。解决给推荐服务加一个user_based_recommend的判断分支如果该用户没有历史记录直接返回全局热门菜TOP20。热门菜的计算不要在查询时实时聚合可以在导入完成后跑一个统计任务把每个Dish的入度被多少用户评分或浏览写入节点属性hot_score。接口侧返回MATCH (d:Dish) RETURN d.name AS name, d.hot_score AS hot_score ORDER BY d.hot_score DESC LIMIT 20;这样冷启动接口永远有数据前端文案改成大家都在吃而不是为你推荐语义上也正确。5.5 前端展示查询超时现象点击推荐按钮后转圈10秒钟才出现结果有时直接返回 Request Timeout。第一次出现时我以为是前端问题后来开开发者工具发现接口耗时12秒问题在后端。原因Cypher查询没有限制返回行数候选菜多的时候把上千行数据全取回来了而且后端每次请求都新建Graph连接Neo4j握手开销被反复支付。更糟糕的是查询里OPTIONAL MATCH三个分支同时展开中间节点数量成倍膨胀。解决第一所有推荐查询都加LIMIT 20永远不要RETURN大字段。第二把Graph对象设计成FastAPI的依赖单例不每请求重连。第三加一层Redis缓存key是rec:{user_id}:{top_k}有效期5分钟。这三步做完接口一般能从10秒降到200毫秒。如果还想更快在Neo4j侧给Dish的popularity属性建普通索引但别建全文本索引那个对CypherORDER BY没有帮助。6. 把源码变成能演示的系统验证方法和三个细节6.1 离线评估留出法算Recall10推荐系统不好评估但毕设答辩需要数字。把用户行为按时间排序前70%作为训练集后30%作为测试集。训练集用来生成图谱中的用户偏好关系测试集的菜品作为标准答案。计算推荐列表在标准答案上的召回率def recall_at_k(recommended, actual, k10): if not actual: return 0.0 return len(set(recommended[:k]) set(actual)) / len(actual)逻辑说明除以所有真实菜品数而不是交集大小是因为召回率衡量推荐出来的占用户实际消费的比例。这个指标比较粗糙但足以用来判断图谱路径调整是否向正确方向移动。你会经常发现权重改一点数字掉一截这就是图谱里实体关系质量不足的信号。6.2 三个值得加到源码里的细节第一给Ingredient.name和Dish.name建唯一约束导入时会自动去重查询也会走索引。第二把Cypher里的路径控制在3跳以内超过3跳的推荐语义已经稀薄还拖慢查询。第三把用户偏好、推荐结果都做一层缓存接口响应从2秒降到200毫秒演示体验完全不同。6.3 演示时的节奏演示时建议按冷启动热门榜到用户点了几道菜再看推荐变化的顺序讲让观众先看到推荐器在没有数据时的底座再看到图谱带来的个性化更新。生成式AI的话术放在最后作为价值放大器不要让大模型抢掉图谱展示的时间。我第一次跑这个系统时只顾着调LLM的Prompt结果推荐结果因为食材别名没有对齐而惨不忍睹后来花了最多时间做的其实是实体对齐。这个教训一直在我脑子里。希望帮到你。本文还有配套的精品资源点击获取
