简介这是一份面向计算机相关专业学生、教师及企业开发者的电商行业知识图谱实战项目源码围绕实体关系构建展开可应用于商品推荐、商品搭配与智能问答等场景适合作为毕业设计、课程设计或项目立项演示也便于具备一定基础的学习者在此基础上二次开发。资源包共59个文件约15.49MB以21个Python源码文件为核心辅以10个CSV与10个TXT数据文件、5个JSON配置、3个Markdown说明及XMind思维导图、产品文档等涵盖数据处理、问答控制、模型定义与可视化视图等模块目录结构清晰。目前已有129人学习下载。项目代码均经测试运行成功答辩评审平均分达96分读者可获取完整可运行的工程源码、图谱搭建思路与数据样例快速理解电商知识图谱从数据到应用的落地流程。1. 从一份电商知识图谱源码说起它能解决什么电商推荐做久了会发现一个尴尬协同过滤能跑出不错的点击率但用户问「有没有适合送丈母娘的茶叶」时系统就哑了。原因在于传统推荐模型只学「用户-商品」的共现不理解商品背后的实体关系——茶叶属于礼品、礼品对应送礼场景、丈母娘是长辈。这类语义推理正是知识图谱的用武之地。这份 ECKG-master 源码包就是围绕电商行业实体关系构建的一套完整工程从 CSV 数据到图数据库再到商品推荐、商品搭配和问答系统三条应用链路代码可直接运行。它适合想入门知识图谱的 Python 学习者、需要毕设或课设素材的在校生以及想给现有推荐系统补一层语义能力的工程师。下面我按「数据怎么进图 → 三条应用怎么跑 → 坑在哪」的顺序拆开讲。2. 数据层拆解从 product.csv 到图数据库的实体关系建模2.1 先看清数据目录里有什么拿到源码包别急着跑 demo.py。先花十分钟把 Data 和 resources 两个目录翻一遍这决定了你后面能不能改数据、能不能换品类。核心文件分布如下路径作用关键字段/内容Data/product.csv商品主数据商品ID、名称、类目、属性Data/refer关联/引用数据商品间引用关系resources/cat_key.csv类目关键词映射类目 → 关键词resources/category.csv类目层级父子类目关系dict/*.txt实体词典food、producer、drug、disease、symptom 等Model/product.py商品实体模型属性封装与图节点映射Model/user.py用户实体模型用户画像字段Model/dialogue.py对话实体模型问答意图相关这里有个容易忽略的点dict 目录下的词典文件food.txt、producer.txt、drug.txt、disease.txt、symptom.txt、deny.txt、check.txt、department.txt看起来像医疗领域的词表但在这份电商图谱里它们承担的是「实体识别词典」的角色——用来从商品描述和用户问句中抽取命名实体。你如果做的是美妆或数码品类直接替换这些 txt 的内容即可不用改抽取逻辑。2.2 实体关系建模商品、类目、属性三张网电商知识图谱的骨架说白了就是三类节点和它们之间的边。这份源码的建模思路是商品节点Product以 product.csv 的每一行为单位商品ID作为唯一标识类目节点Category从 category.csv 读取层级形成「一级类目 → 二级类目 → 三级类目」的树属性节点Attribute商品的品牌、规格、适用人群等从 cat_key.csv 的类目关键词映射中提取边的关系主要有四种商品-属于-类目、商品-具有-属性、商品-搭配-商品、商品-相似-商品。前两种从 CSV 直接构建后两种需要靠 refer 目录下的关联数据和共现统计生成。我一般会先跑一遍数据加载确认节点数和边数对得上再往下做应用。2.3 用 example_create_graph.py 把数据灌进图库源码根目录的 example_create_graph.py 是建图的入口。运行前先确认 Config/config.conf 和 variable.ini 里的数据库连接参数。常见做法是本地起一个 Neo4j 实例把 bolt 地址、用户名、密码填进去。核心建图逻辑大致如下# example_create_graph.py 核心建图流程示意 from Model.product import Product from Model.user import User from Helper.DataHelper import DataHelper # 1. 初始化数据助手读取 CSV 和词典 helper DataHelper(config_pathConfig/config.conf) products helper.load_products(Data/product.csv) categories helper.load_categories(resources/category.csv) # 2. 批量创建商品节点与类目节点 for p in products: Product.create_node(p) # 商品ID作为唯一约束 for c in categories: Product.create_category(c) # 类目层级用 parent_id 串联 # 3. 建立商品-类目、商品-属性关系 helper.build_relations(products, categories) # 4. 基于 refer 数据生成搭配关系 helper.build_match_relations(Data/refer)逻辑说明DataHelper 封装了 CSV 读取、词典加载和批量写入图库的方法。create_node内部用的是 MERGE 语句而非 CREATE避免重复运行时产生重复节点——这是血泪经验我第一次跑没注意重跑三次后图里多了三倍商品。参数方面config.conf 里的batch_size控制每次写入的节点数默认 500数据量大时调到 2000 能明显提速但内存占用会上去。提示如果建图时报连接超时先检查 Neo4j 的dbms.memory.heap.max_size是否够用商品数据超过 10 万行时建议给到 2G 以上。3. 三条应用链路商品推荐、商品搭配与问答系统怎么跑3.1 商品推荐基于图路径的语义召回传统推荐用向量相似度这份源码走的是图路径召回。核心思路是给定一个用户已购商品在图中找到与它共享类目或属性的其他商品按路径长度排序。Controller/DataController.py 里封装了推荐接口调用方式如下# Controller/DataController.py 推荐调用示例 from Controller.DataController import DataController dc DataController() # user_id 对应用户top_n 控制返回数量 recs dc.recommend_by_graph(user_idU10086, top_n10) for r in recs: print(r[product_id], r[product_name], r[score])逻辑说明recommend_by_graph内部先查用户的历史行为节点再沿商品-属于-类目和商品-具有-属性两条边做两跳扩展最后用路径权重打分。参数top_n默认 10max_depth控制扩展跳数默认 2——调到 3 召回变多但精度下降实测 2 跳是电商场景的甜点区。和协同过滤的区别在于图召回能解释「为什么推荐这个」比如「因为你买的龙井属于绿茶这款碧螺春也是绿茶」。3.2 商品搭配从共现到图上的搭配边商品搭配解决的是「买了 A 的人还买了 B」之外能不能推出「A 和 B 在语义上搭配」。源码在 Helper/DataHelper.py 里提供了build_match_relations方法从 refer 数据中统计共现频次超过阈值的商品对建立搭配边。运行搭配查询# 商品搭配查询 from Controller.QSController import QSController qs QSController() # 查询与指定商品搭配的商品 matches qs.query_match(product_idP2001, min_weight0.3) print(matches)参数min_weight是搭配权重阈值范围 0~1默认 0.3。调低会引入弱关联商品调高则搭配结果更保守。我一般会先用 0.3 跑一遍看结果再根据业务反馈微调。注意 refer 数据的质量直接决定搭配效果如果原始数据里商品对本身就不合理图上也建不出好边。3.3 问答系统意图识别 图查询问答链路在 Handler/QSHandler.py 和 Controller/QSController.py 里。流程分两步先用词典做实体识别和意图分类再把自然语言转成图查询语句。比如用户问「有没有适合送长辈的茶叶」系统识别出实体「茶叶」和意图「送礼场景」然后在图上查类目茶叶且属性包含 送礼/长辈的商品。# Handler/QSHandler.py 问答处理流程 from Handler.QSHandler import QSHandler handler QSHandler() # 输入自然语言问句 answer handler.process(有没有适合送长辈的茶叶) print(answer[intent]) # 输出识别到的意图 print(answer[entities]) # 输出抽取的实体 print(answer[results]) # 输出图查询结果逻辑说明process方法内部先加载 dict 目录下的词典做分词和实体匹配再用规则模板匹配意图。这套方案不依赖深度学习模型好处是轻量、可解释坏处是泛化能力有限——问句换个说法可能就识别不了。常见做法是在词典里补充同义词或者加一层简单的意图分类模型。注意问答系统的效果高度依赖词典覆盖度。如果测试时发现某些问句识别不出实体优先检查 dict 下对应的 txt 是否包含该词。4. 避坑与排查跑这份源码时最容易翻车的五个地方4.1 现象建图脚本跑完图里节点数是数据行数的好几倍原因create_node如果用的是 CREATE 而非 MERGE重复运行会不断追加节点。源码里部分早期模块确实存在这个问题。解决检查 Model/product.py 里的建图语句把 CREATE 改成 MERGE并在商品ID上建唯一约束CREATE CONSTRAINT ON (p:Product) ASSERT p.id IS UNIQUE。跑之前先清库避免脏数据。4.2 现象问答接口返回空结果但实体识别正常原因实体识别出来了但图查询没匹配到节点。多半是实体名称和图中节点属性不一致比如词典里是「茶叶」图里存的是「茶叶类」。解决在 QSController 里加一层名称归一化或者统一数据入库时的命名规范。我一般会在建图前先跑一遍数据清洗把类目名和属性名统一成词典里的标准词。4.3 现象推荐结果全是同一个类目的商品多样性差原因图扩展时只走了商品-属于-类目一条边没有引入属性边做跨类目召回。解决在recommend_by_graph里把max_depth调到 2 以上并确保属性边已建立。另外可以在打分时对同类目商品做降权强制引入跨类目结果。4.4 现象Neo4j 连接报错提示认证失败原因config.conf 里的用户名密码和实际 Neo4j 实例不一致或者 Neo4j 版本升级后默认密码改了。解决先确认 Neo4j 服务已启动用浏览器打开 7474 端口验证账号密码。如果忘了密码停掉服务后重置认证配置。配置文件里的 bolt 地址注意端口是 7687 不是 7474。4.5 现象demo.py 跑起来报模块导入错误原因Python 路径没配好或者依赖库没装全。源码里用了 neo4j 驱动、pandas 等库。解决在项目根目录执行pip install -r requirements.txt如果没有该文件手动装 neo4j、pandas、numpy。另外确认运行目录是项目根目录否则相对路径导入会失败。VS Code 里可以在 launch.json 配cwd: ${workspaceFolder}。5. 进阶玩法把这份图谱接到真实推荐链路上跑通 demo 只是第一步。真正让这份资源产生价值的是把它接到你现有的推荐或搜索链路里。我一般会做三件事。第一把图召回作为一路召回源和协同过滤、向量召回做融合。具体做法是在 DataController 里加一个recommend_by_graph的批量接口输出(user_id, product_id, score)三元组然后和现有召回结果按权重合并。图召回的分数需要归一化否则量纲和协同过滤对不上。常见做法是用 min-max 归一化到 0~1再给一个 0.2~0.3 的融合权重具体看离线 AUC 表现调。第二用问答系统做搜索的语义兜底。电商搜索里长尾 query 占比很高传统倒排索引对「适合送长辈的茶叶」这种语义 query 召回差。可以把 QSHandler 的实体识别和意图分类结果转成类目和属性过滤条件拼到搜索请求里。这样不用改搜索引擎内核只在查询改写层加一层图谱增强。第三验证图谱质量。建完图别只看节点数跑几个典型查询验证边的关系是否正确# 图谱质量抽检 from Helper.DataHelper import DataHelper helper DataHelper() # 抽检商品-类目关系 sample helper.query(MATCH (p:Product)-[:BELONGS_TO]-(c:Category) RETURN p.name, c.name LIMIT 20) for row in sample: print(row) # 抽检搭配关系权重分布 weights helper.query(MATCH (a:Product)-[r:MATCH]-(b:Product) RETURN r.weight ORDER BY r.weight DESC LIMIT 50) print([w[r.weight] for w in weights])如果抽检发现大量商品挂在错误的类目下说明 cat_key.csv 的映射规则有问题需要回头改映射表。搭配权重如果集中在极低值说明 refer 数据太稀疏考虑引入外部共现数据补充。最后说个习惯从那以后我每次拿到一份知识图谱源码都强制先跑一遍数据质量抽检再跑应用宁可多花半小时验证也不愿在错误的数据上调三天参数。这份 ECKG-master 的代码结构清晰数据、模型、控制器分层明确改起来不算费劲适合拿来当知识图谱工程的起点。希望帮到你。本文还有配套的精品资源点击获取 电商知识图谱实战：从CSV到图数据库，构建推荐、搭配与问答系统
简介这是一份面向计算机相关专业学生、教师及企业开发者的电商行业知识图谱实战项目源码围绕实体关系构建展开可应用于商品推荐、商品搭配与智能问答等场景适合作为毕业设计、课程设计或项目立项演示也便于具备一定基础的学习者在此基础上二次开发。资源包共59个文件约15.49MB以21个Python源码文件为核心辅以10个CSV与10个TXT数据文件、5个JSON配置、3个Markdown说明及XMind思维导图、产品文档等涵盖数据处理、问答控制、模型定义与可视化视图等模块目录结构清晰。目前已有129人学习下载。项目代码均经测试运行成功答辩评审平均分达96分读者可获取完整可运行的工程源码、图谱搭建思路与数据样例快速理解电商知识图谱从数据到应用的落地流程。1. 从一份电商知识图谱源码说起它能解决什么电商推荐做久了会发现一个尴尬协同过滤能跑出不错的点击率但用户问「有没有适合送丈母娘的茶叶」时系统就哑了。原因在于传统推荐模型只学「用户-商品」的共现不理解商品背后的实体关系——茶叶属于礼品、礼品对应送礼场景、丈母娘是长辈。这类语义推理正是知识图谱的用武之地。这份 ECKG-master 源码包就是围绕电商行业实体关系构建的一套完整工程从 CSV 数据到图数据库再到商品推荐、商品搭配和问答系统三条应用链路代码可直接运行。它适合想入门知识图谱的 Python 学习者、需要毕设或课设素材的在校生以及想给现有推荐系统补一层语义能力的工程师。下面我按「数据怎么进图 → 三条应用怎么跑 → 坑在哪」的顺序拆开讲。2. 数据层拆解从 product.csv 到图数据库的实体关系建模2.1 先看清数据目录里有什么拿到源码包别急着跑 demo.py。先花十分钟把 Data 和 resources 两个目录翻一遍这决定了你后面能不能改数据、能不能换品类。核心文件分布如下路径作用关键字段/内容Data/product.csv商品主数据商品ID、名称、类目、属性Data/refer关联/引用数据商品间引用关系resources/cat_key.csv类目关键词映射类目 → 关键词resources/category.csv类目层级父子类目关系dict/*.txt实体词典food、producer、drug、disease、symptom 等Model/product.py商品实体模型属性封装与图节点映射Model/user.py用户实体模型用户画像字段Model/dialogue.py对话实体模型问答意图相关这里有个容易忽略的点dict 目录下的词典文件food.txt、producer.txt、drug.txt、disease.txt、symptom.txt、deny.txt、check.txt、department.txt看起来像医疗领域的词表但在这份电商图谱里它们承担的是「实体识别词典」的角色——用来从商品描述和用户问句中抽取命名实体。你如果做的是美妆或数码品类直接替换这些 txt 的内容即可不用改抽取逻辑。2.2 实体关系建模商品、类目、属性三张网电商知识图谱的骨架说白了就是三类节点和它们之间的边。这份源码的建模思路是商品节点Product以 product.csv 的每一行为单位商品ID作为唯一标识类目节点Category从 category.csv 读取层级形成「一级类目 → 二级类目 → 三级类目」的树属性节点Attribute商品的品牌、规格、适用人群等从 cat_key.csv 的类目关键词映射中提取边的关系主要有四种商品-属于-类目、商品-具有-属性、商品-搭配-商品、商品-相似-商品。前两种从 CSV 直接构建后两种需要靠 refer 目录下的关联数据和共现统计生成。我一般会先跑一遍数据加载确认节点数和边数对得上再往下做应用。2.3 用 example_create_graph.py 把数据灌进图库源码根目录的 example_create_graph.py 是建图的入口。运行前先确认 Config/config.conf 和 variable.ini 里的数据库连接参数。常见做法是本地起一个 Neo4j 实例把 bolt 地址、用户名、密码填进去。核心建图逻辑大致如下# example_create_graph.py 核心建图流程示意 from Model.product import Product from Model.user import User from Helper.DataHelper import DataHelper # 1. 初始化数据助手读取 CSV 和词典 helper DataHelper(config_pathConfig/config.conf) products helper.load_products(Data/product.csv) categories helper.load_categories(resources/category.csv) # 2. 批量创建商品节点与类目节点 for p in products: Product.create_node(p) # 商品ID作为唯一约束 for c in categories: Product.create_category(c) # 类目层级用 parent_id 串联 # 3. 建立商品-类目、商品-属性关系 helper.build_relations(products, categories) # 4. 基于 refer 数据生成搭配关系 helper.build_match_relations(Data/refer)逻辑说明DataHelper 封装了 CSV 读取、词典加载和批量写入图库的方法。create_node内部用的是 MERGE 语句而非 CREATE避免重复运行时产生重复节点——这是血泪经验我第一次跑没注意重跑三次后图里多了三倍商品。参数方面config.conf 里的batch_size控制每次写入的节点数默认 500数据量大时调到 2000 能明显提速但内存占用会上去。提示如果建图时报连接超时先检查 Neo4j 的dbms.memory.heap.max_size是否够用商品数据超过 10 万行时建议给到 2G 以上。3. 三条应用链路商品推荐、商品搭配与问答系统怎么跑3.1 商品推荐基于图路径的语义召回传统推荐用向量相似度这份源码走的是图路径召回。核心思路是给定一个用户已购商品在图中找到与它共享类目或属性的其他商品按路径长度排序。Controller/DataController.py 里封装了推荐接口调用方式如下# Controller/DataController.py 推荐调用示例 from Controller.DataController import DataController dc DataController() # user_id 对应用户top_n 控制返回数量 recs dc.recommend_by_graph(user_idU10086, top_n10) for r in recs: print(r[product_id], r[product_name], r[score])逻辑说明recommend_by_graph内部先查用户的历史行为节点再沿商品-属于-类目和商品-具有-属性两条边做两跳扩展最后用路径权重打分。参数top_n默认 10max_depth控制扩展跳数默认 2——调到 3 召回变多但精度下降实测 2 跳是电商场景的甜点区。和协同过滤的区别在于图召回能解释「为什么推荐这个」比如「因为你买的龙井属于绿茶这款碧螺春也是绿茶」。3.2 商品搭配从共现到图上的搭配边商品搭配解决的是「买了 A 的人还买了 B」之外能不能推出「A 和 B 在语义上搭配」。源码在 Helper/DataHelper.py 里提供了build_match_relations方法从 refer 数据中统计共现频次超过阈值的商品对建立搭配边。运行搭配查询# 商品搭配查询 from Controller.QSController import QSController qs QSController() # 查询与指定商品搭配的商品 matches qs.query_match(product_idP2001, min_weight0.3) print(matches)参数min_weight是搭配权重阈值范围 0~1默认 0.3。调低会引入弱关联商品调高则搭配结果更保守。我一般会先用 0.3 跑一遍看结果再根据业务反馈微调。注意 refer 数据的质量直接决定搭配效果如果原始数据里商品对本身就不合理图上也建不出好边。3.3 问答系统意图识别 图查询问答链路在 Handler/QSHandler.py 和 Controller/QSController.py 里。流程分两步先用词典做实体识别和意图分类再把自然语言转成图查询语句。比如用户问「有没有适合送长辈的茶叶」系统识别出实体「茶叶」和意图「送礼场景」然后在图上查类目茶叶且属性包含 送礼/长辈的商品。# Handler/QSHandler.py 问答处理流程 from Handler.QSHandler import QSHandler handler QSHandler() # 输入自然语言问句 answer handler.process(有没有适合送长辈的茶叶) print(answer[intent]) # 输出识别到的意图 print(answer[entities]) # 输出抽取的实体 print(answer[results]) # 输出图查询结果逻辑说明process方法内部先加载 dict 目录下的词典做分词和实体匹配再用规则模板匹配意图。这套方案不依赖深度学习模型好处是轻量、可解释坏处是泛化能力有限——问句换个说法可能就识别不了。常见做法是在词典里补充同义词或者加一层简单的意图分类模型。注意问答系统的效果高度依赖词典覆盖度。如果测试时发现某些问句识别不出实体优先检查 dict 下对应的 txt 是否包含该词。4. 避坑与排查跑这份源码时最容易翻车的五个地方4.1 现象建图脚本跑完图里节点数是数据行数的好几倍原因create_node如果用的是 CREATE 而非 MERGE重复运行会不断追加节点。源码里部分早期模块确实存在这个问题。解决检查 Model/product.py 里的建图语句把 CREATE 改成 MERGE并在商品ID上建唯一约束CREATE CONSTRAINT ON (p:Product) ASSERT p.id IS UNIQUE。跑之前先清库避免脏数据。4.2 现象问答接口返回空结果但实体识别正常原因实体识别出来了但图查询没匹配到节点。多半是实体名称和图中节点属性不一致比如词典里是「茶叶」图里存的是「茶叶类」。解决在 QSController 里加一层名称归一化或者统一数据入库时的命名规范。我一般会在建图前先跑一遍数据清洗把类目名和属性名统一成词典里的标准词。4.3 现象推荐结果全是同一个类目的商品多样性差原因图扩展时只走了商品-属于-类目一条边没有引入属性边做跨类目召回。解决在recommend_by_graph里把max_depth调到 2 以上并确保属性边已建立。另外可以在打分时对同类目商品做降权强制引入跨类目结果。4.4 现象Neo4j 连接报错提示认证失败原因config.conf 里的用户名密码和实际 Neo4j 实例不一致或者 Neo4j 版本升级后默认密码改了。解决先确认 Neo4j 服务已启动用浏览器打开 7474 端口验证账号密码。如果忘了密码停掉服务后重置认证配置。配置文件里的 bolt 地址注意端口是 7687 不是 7474。4.5 现象demo.py 跑起来报模块导入错误原因Python 路径没配好或者依赖库没装全。源码里用了 neo4j 驱动、pandas 等库。解决在项目根目录执行pip install -r requirements.txt如果没有该文件手动装 neo4j、pandas、numpy。另外确认运行目录是项目根目录否则相对路径导入会失败。VS Code 里可以在 launch.json 配cwd: ${workspaceFolder}。5. 进阶玩法把这份图谱接到真实推荐链路上跑通 demo 只是第一步。真正让这份资源产生价值的是把它接到你现有的推荐或搜索链路里。我一般会做三件事。第一把图召回作为一路召回源和协同过滤、向量召回做融合。具体做法是在 DataController 里加一个recommend_by_graph的批量接口输出(user_id, product_id, score)三元组然后和现有召回结果按权重合并。图召回的分数需要归一化否则量纲和协同过滤对不上。常见做法是用 min-max 归一化到 0~1再给一个 0.2~0.3 的融合权重具体看离线 AUC 表现调。第二用问答系统做搜索的语义兜底。电商搜索里长尾 query 占比很高传统倒排索引对「适合送长辈的茶叶」这种语义 query 召回差。可以把 QSHandler 的实体识别和意图分类结果转成类目和属性过滤条件拼到搜索请求里。这样不用改搜索引擎内核只在查询改写层加一层图谱增强。第三验证图谱质量。建完图别只看节点数跑几个典型查询验证边的关系是否正确# 图谱质量抽检 from Helper.DataHelper import DataHelper helper DataHelper() # 抽检商品-类目关系 sample helper.query(MATCH (p:Product)-[:BELONGS_TO]-(c:Category) RETURN p.name, c.name LIMIT 20) for row in sample: print(row) # 抽检搭配关系权重分布 weights helper.query(MATCH (a:Product)-[r:MATCH]-(b:Product) RETURN r.weight ORDER BY r.weight DESC LIMIT 50) print([w[r.weight] for w in weights])如果抽检发现大量商品挂在错误的类目下说明 cat_key.csv 的映射规则有问题需要回头改映射表。搭配权重如果集中在极低值说明 refer 数据太稀疏考虑引入外部共现数据补充。最后说个习惯从那以后我每次拿到一份知识图谱源码都强制先跑一遍数据质量抽检再跑应用宁可多花半小时验证也不愿在错误的数据上调三天参数。这份 ECKG-master 的代码结构清晰数据、模型、控制器分层明确改起来不算费劲适合拿来当知识图谱工程的起点。希望帮到你。本文还有配套的精品资源点击获取