简介以小麦知识图谱为实例的完整数据与代码包面向农业科研人员与IT开发者演示如何将科研报告、气候数据、土壤检测等多源信息整理为结构化知识图谱解决农业领域数据分散、关联难查的问题。压缩包共27个文件约2.4MB包含12个Python脚本、11个txt文本、2个csv数据集、1个json及1个md说明其中Python脚本覆盖数据清洗、预处理、爬虫采集、Neo4j导入与查询等核心环节txt/csv/json文件则保存了原始数据、中间结果及图谱元数据md文档提供项目说明。已有340人学习下载。通过阅读和运行代码可系统掌握实体定义、关系建模、实体链接和图谱可视化流程既能用于小麦品种特性、病虫害防治等农业调研也可迁移到其他领域图谱建设对具备一定Python基础、希望上手完整知识图谱项目的读者尤为合适。1. 小麦知识图谱先解决“数据从哪来、代码怎么写”再谈智能应用做智慧农业落地的人大概都有这种经历想给农户做一个小麦病虫害问答小程序结果连“济麦22到底抗不抗条锈病”这种基础问题从已有数据库里都查不到准确答案。原因不只是缺模型而是缺一张把小麦品种、病害、农药、气候、农艺性状串起来的知识图谱。这个标题里最硬的骨头不是“图谱”这个词而是“数据源”和“代码”——数据源决定了你能讲出多少真话代码决定了这些话能不能被机器用起来。本文会按我实际跑通的路径来讲先从公开数据里找表格再用词典和规则把实体关系抽出来最后让图数据库告诉你“什么小麦抗什么病”。这套方案适合农业信息化工程师、植保数字化产品经理以及正在做智慧农业方向的研究生照着复现。2. 小麦知识图谱的数据源五类来源与取舍清单2.1 结构化数据源品种审定公告与植保登记数据结构化数据是知识图谱的起点因为它的字段边界清楚不用花大量时间做命名实体识别。最常见的公开数据源是国家和省级农作物品种审定公告。这里面有品种名称、审定编号、育种单位、特征特性、产量表现、抗病性描述、适宜种植区域基本都是规整的表格结构。另一个被低估的数据源是植保部门的农药登记数据里面有有效成分、登记作物、防治对象恰好能把“病害-农药”这条边补上。这些数据分布在不同网站上有的直接提供Excel下载有的藏在HTML表格里。我的常用做法是用 pandas.read_html 一把抓。import pandas as pd tables pd.read_html(https://example.gov.cn/audit/2024.html, header0, encodingutf-8) for df in tables: if {品种名称, 适宜区域}.issubset(df.columns): df.to_csv(wheat_varieties.csv, indexFalse, encodingutf-8-sig) print(df.head(3).to_string())逻辑说明read_html 会把页面里所有表格解析成 DataFrame 列表所以后面必须遍历并判断关键列名是否命中。header0 表示把第一行当列名。encoding 参数要按页面实际情况调整很多老农业网站的页面其实是 GBK 编码不改的话解析出来的列名会出现乱码。另外保存 CSV 时我用 utf-8-sig 而不是 utf-8这样文件拿给 Excel 打开时不会乱码。这里有个参数容易被忽略read_html 依赖 lxml 和 html5lib 两个解析库只 install pandas 是不够的。建议在项目初始化时一并安装否则第一次调用会报 ImportError而且报错信息很隐晦容易让人误以为是 pandas 版本问题。2.2 半结构化数据源百科词条与文献摘要结构化数据能给你骨架却给不了细节。一个品种为什么抗病适宜在什么气候区这些知识大多埋在半结构化的百科词条和科研文献摘要里。百科词条的特点是有一个 Infobox 信息框里面的键值对可以直接映射到本体属性文献摘要里则经常出现“某某基因过表达提高了对条锈病的抗性”这类高质量因果关系。抓百科 Infobox 的常见做法是拿 BeautifulSoup 定位表格然后顺着 tr 一行行读。from bs4 import BeautifulSoup import requests resp requests.get( https://baike.example.com/item/济麦22, headers{User-Agent: Mozilla/5.0} ) soup BeautifulSoup(resp.text, html.parser) infobox soup.find(div, class_infobox) if infobox: for row in infobox.select(tr): th row.find(th) td row.find(td) if th and td: key th.get_text(stripTrue) value td.get_text(stripTrue) print(f{key}: {value})逻辑说明先用 UA 头防止最简单的请求被拒再定位 Infobox 容器然后逐行拆键值对。这里 class 选择器要按目标站点实际结构去调不同百科平台用的类名不一样。拿到键值对后需要人工维护一张从百科字段到本体属性的映射表比如把“抗病性”落到 “resistant_to_disease” 字段把“适宜区域”落到 “suitable_region” 字段。这种映射表是数据源工程里最费时间、也最值钱的部分。2.3 非结构化数据源植保手册与专家经验的OCR抽取还有一类数据源是植保手册、地方农业站的技术文件通常以 PDF 或扫描件存在。这类文件里有大量老专家总结的实战经验比如“遇持续阴雨条锈病在返青期易高发”这是结构化数据里找不到的。问题是它们没有统一格式必须先做文本提取再做实体抽取。对于文字版 PDF我一般用 PyMuPDF 先提取文本如果提取出来是空白说明是扫描件得上 OCR。import fitz doc fitz.open(wheat_disease_manual.pdf) for page in doc: text page.get_text(text) if 条锈病 in text or 叶锈病 in text: print(f--- page {page.number} ---) print(text[:800])逻辑说明fitz 是 PyMuPDF 的默认别名get_text(text) 会按阅读顺序提取纯文本。参数 “text” 可以换成 “blocks” 或 “words”当你想保留版面位置信息时再用。这里的判断条件只是把包含目标病害的页面筛选出来方便人工标注。扫描件如果数量不大我建议不要一上来就写全自动 OCR 管线而是先抽出 20 页人工录入或只抽取关键描述段落往往比调 OCR 参数更省时间。2.4 数据预处理字段映射、单位统一与实体对齐多数据源汇合之后最先遇到的问题不是算法而是字段名和实体名对不上。同一个“济麦22”在审定公告里叫“济麦22”在百科里可能叫“济麦22号”。同一份“亩产”有的数据源用公斤有的用吨。所以在进图谱前必须做三件事字段重命名、单位统一、实体对齐。import pandas as pd df pd.read_csv(wheat_varieties.csv) alias_map { 济麦22号: 济麦22, 济麦22品种: 济麦22, 亩产量: 产量, } df[品种名称] df[品种名称].replace(alias_map) df.rename(columns{抗病性描述: 抗病性, 亩产: 产量}, inplaceTrue) # 统一单位如果产量列单位是公斤/亩全部转成吨/公顷 if df[产量].max() 1000: df[产量] df[产量] / 1000 * 15逻辑说明replace 方法在别名没有命中时不会报错所以适合几万行的字段归一化。rename 用来解决“同字段不同名”的问题。单位换算是最容易踩坑的地方一定要先看数据分布再写换算逻辑比如用 max 值判断当前列是公斤还是吨。这里的 15 是从“公斤/亩”换算到“吨/公顷”的系数不同来源可能还需要除以或者乘其他系数所以换算系数我一般写成常量放在配置里方便追溯。3. 本体建模与代码化用Python把小麦知识“定死”3.1 本体设计核心类、关系与属性本体建模不能一上来就写代码先要把概念和关系画清楚否则写出来的代码只是散装三元组。小麦领域里最常见的核心类有这些小麦品种、病害、虫害、农药、农艺性状、生育期、土壤条件、气象条件、产区。关系里面我至少会先定义这几条对象A关系对象B实例小麦品种resistant_to病害济麦22 resistant_to 条锈病小麦品种susceptible_to病害矮抗58 susceptible_to 赤霉病农药controls病害戊唑醇 controls 条锈病小麦品种has_trait农艺性状济麦22 has_trait 千粒重小麦品种suitable_for产区济麦22 suitable_for 鲁中平原病害occurs_in生育期条锈病 occurs_in 返青拔节期这张表既是给团队看的设计文档也是后面写代码时的校验清单。实现时不要一开始就做得太细。比如“抗病性”可以先只分成 resistant_to 和 susceptible_to 两种关系等之后数据量大了再细化成“高抗”“中抗”“中感”等带数值属性的关系。这能避免前期在关系粒度上反复返工。3.2 用owlready2定义本体类型我习惯用 owlready2 来做轻量本体建模它的好处是可以在 Python 里直接定义类和关系不用打开笨重的桌面工具。定义之后还能直接用 Python 对象创建实例非常适合理清本体结构。from owlready2 import * onto get_ontology(http://example.org/wheat#) with onto: class WheatVariety(Thing): pass class Disease(Thing): pass class Pesticide(Thing): pass class has_disease(ObjectProperty): domain [WheatVariety] range [Disease] class resistant_to(has_disease): pass class susceptible_to(has_disease): pass class controls(ObjectProperty): domain [Pesticide] range [Disease] yield_potential DataProperty(domain[WheatVariety], range[float])逻辑说明with onto 之下的 class 定义会把类和关系统一写进本体。ObjectProperty 是两个实体之间的关系DataProperty 是实体到数值的绑定。这里用 resistant_to 和 susceptible_to 继承 has_disease是为了后续推理方便比如查询“所有和病害有关的小麦”不需要分别匹配两类关系。domain 和 range 是可选参数但建议写上一是规范二是 Ne4o 转写的时候能检查出异常关系。注意owlready2 对缩进敏感类定义里不能写别的逻辑代码。3.3 实体与关系抽取词典规则最小实现拿到文本之后最朴素也最稳定的一种抽取办法是用词典加正则。这一步是整个构建过程里最像“黑匣子”的地方因为规则改一点点召回率就会变。我的经验是先用正则跑出第一版再根据漏抽取的样本迭代不要一开始就上大模型成本高且难调试。import re import jieba jieba.load_userdict(agri_terms.txt) text 济麦22对条锈病表现抗病对赤霉病表现中感。 pattern re.compile( r([\u4e00-\u9fa5\w]?)对([\u4e00-\u9fa5\w]?)表现(\S{1,3}) ) for match in pattern.finditer(text): variety, disease, level match.groups() if 抗 in level: rel resistant_to elif 感 in level: rel susceptible_to else: continue print(variety, rel, disease)逻辑说明这里用的是非贪婪匹配所以品种名不会吞掉后面的病害名。\S{1,3} 匹配“抗病”“中感”这样的短等级描述。先调库的目的是让自定义农业词表生效否则 jieba 可能把“条锈病”切开。实际跑的时候你会发现这个正则在遇到“济麦22条锈病抗性评价为高抗”这种语序时匹配不到这就需要再加一个正则分支。所以建议先把文本抽样 200 条统计常见句式再对应写正则不要凭感觉写。4. 从三元组到可查询图谱存储选型与批量导入代码4.1 存储选型RDF Store 还是图数据库知识图谱存到哪里会直接影响后面的查询体验。RDF Store 用 SPARQL 查询适合做复杂语义推理比如 OWL 规则推导。Neo4j 这种标签属性图数据库用 Cypher 查询更适合交互式检索和可视化。对小麦知识图谱这种数据量不大、但查询需求多变、还要接前端展示的项目我一般选 Neo4j。如果你已经建设了标准 RDF 数据湖那可以直接用 rdflib 导出 TTL再部署 Jena Fuseki。RDF/SPARQL - 适合语义推理、本体标准强 - 存储冗余多查询语法复杂 - 社区生态偏学术 Neo4j/Cypher - 查询直观可视化好 - 适合快速迭代 - 语义推理能力弱需要外挂规则4.2 用rdflib生成TTL文件即使最终选 Neo4j我也会先用 rdflib 做一个“导出快照”一方面可以给团队做数据验收另一方面万一 Neo4j 挂掉还能快速重建。from rdflib import Graph, URIRef, Literal, Namespace g Graph() WHEAT Namespace(http://example.org/wheat#) triples [ {s: 济麦22, p: resistant_to, o: 条锈病, otype: entity}, {s: 济麦22, p: yield_potential, o: 850, otype: literal}, ] for rec in triples: s URIRef(WHEAT[rec[s]]) p URIRef(WHEAT[rec[p]]) if rec[otype] entity: o URIRef(WHEAT[rec[o]]) else: o Literal(rec[o]) g.add((s, p, o)) g.serialize(wheat_graph.ttl, formatturtle)逻辑说明这里最关键的一步是区分对象是 URIRef 还是 Literal。如果错误地把“850”当成实体SPARQL 查询时用 FILTER 比较数值就会失灵。formatturtle 可读性最好方便在 Git 里做 diff。URIRef 的命名空间前缀建议在一开始就固定不要中途更换不然后面做数据融合会非常痛苦。4.3 用py2neo批量写入Neo4j在 Neo4j 里建图时最容易踩的坑是提交事务太大。几千条关系用一次事务提交内存直接飙升。我的习惯是先把节点批量 merge再批量建关系。from py2neo import Graph, Node, Relationship graph Graph(bolt://localhost:7687, auth(neo4j, your_password)) def ensure_node(label, name): node Node(label, namename) graph.merge(node, label, name) return node # 先写节点 for variety, disease, rel in relation_triples: ensure_node(WheatVariety, variety) ensure_node(Disease, disease) # 再写关系 for variety, disease, rel in relation_triples: a graph.nodes.match(WheatVariety, namevariety).first() b graph.nodes.match(Disease, namedisease).first() if a is not None and b is not None: graph.create(Relationship(a, rel, b))逻辑说明graph.merge 是幂等操作同一批次重复执行不会创建重复节点。但要注意节点写完后还要通过 nodes.match 重新查出节点对象再创建关系。如果你直接拿第一次创建的 Node 对象去 create后续再次跑脚本时会因为对象失效而报错。auth 里的密码建议从环境变量读不要硬编码进代码仓库。4.4 常用Cypher查询品种-病害-农药图谱一旦建好第一类要跑通的查询就是“品种得了什么病、用什么药治”。MATCH (v:WheatVariety {name: 济麦22})-[:susceptible_to]-(d:Disease)-[:controls]-(p:Pesticide) RETURN v.name, d.name, p.name这条语句把“易感”从品种流向病害再从“防治”关系反查农药。它的执行顺序是先按 name 属性定位济麦22 节点再向外扩展一层关系最后通过疾病节点反向找农药。实际使用中如果查询很慢优先检查两个地方一是给 WheatVariety 的 name 建了唯一索引二是所有关系都用了同向箭头。节点多以后无索引的 label 扫描会让人误以为服务器卡死了。再比如查“所有抗条锈病的品种”MATCH (v:WheatVariety)-[:resistant_to]-(d:Disease {name: 条锈病}) RETURN v.name这种查询跑通基本就是一个能用的知识图谱雏形了。5. 小麦知识图谱构建避坑数据源、代码与图查询的5个典型问题5.1 品种名同物异名导致图谱“分家”现象查“济麦22”查不到抗性数据但查“济麦22号”却能查到。看图谱时发现两个节点长得几乎一样关系却各挂各的。原因多个数据源里品种名的写法不一致导入时又没有做实体对齐。这是知识图谱里最经典的同物异名问题。解决在导入前建一张别名表统一替换后再进入本体。如果数据已经进了 Neo4j可以在节点上加一个 aliases 属性查询时用 OR 匹配。更稳妥的做法是在预处理阶段就把所有名称归一化。df[品种名称] df[品种名称].str.replace(号, , regexFalse)5.2 网页表格解析字段错位现象pd.read_html 读出来的表格列名对上了但数据行对应错位比如“适宜区域”下面出现了“产量”的数字。原因HTML 里有 colspan 合并单元格或者表头不是第一行导致解析器把数据推到了错误的位置。解决解析前先打印 df.columns 人工确认再用 header 参数调整表头所在行。对于合并单元格我一般会在读取后做一次“列探针”校验比如判断“适宜区域”列的值是否包含“省”“市”“流域”等字符如果命中率太低就说明表头错位直接放弃这个表格而不是硬修。5.3 关系抽取命中率低图谱稀疏现象正则跑完一千条文本只抽出不到两百条三元组图谱看上去稀稀拉拉。原因句式变化多样词典覆盖不足。比如“济麦22高抗条锈病”这种没有“对……表现……”结构的句子一个正则根本抓不到。解决先抽样两百条原始文本把高频句子成分列出来再针对每个句式写一个正则分支。比如补上“高抗”“中抗”“中感”的直接匹配模式。另一个办法是把 Doccano 这类标注工具用起来先人工标注三百条再训练一个轻量实体识别模型。但我还是建议先用规则把召回率提到 50% 以上再考虑模型否则会浪费大量调参时间。5.4 Neo4j写入慢、心跳断开现象用 py2neo 循环写入十几万条关系脚本跑到一半抛出连接中断甚至直接卡死。原因每写一条关系就开一个新事务且节点重复匹配内存占用巨大。解决把写入拆成三步先批量 merge 节点再建立关系索引最后用 UNWIND 一次性传参批量建关系。这样能避免循环内反复发起网络请求。如果仍然慢可以把 py2neo 换成 neo4j 官方 Python 驱动用 session 配合 UNWIND 批量提交。5.5 依赖版本不兼容现象昨天还能正常导入 owlready2今天跑脚本报“TypeError: init() got an unexpected keyword argument domain”。原因pip 在你没注意时把 owlready2 或 rdflib 升级了大版本语法不兼容。解决把项目依赖写进 requirements.txt并在虚拟环境里固定版本。我的习惯是锁 Python 3.10并把 owlready2、rdflib、py2neo、pandas、beautifulsoup4 都固定到已验证的版本。不要在小麦知识图谱这种项目里追求“最新版本”稳定能跑比什么都强。比如我在本地就直接用这样的 requirements.txt 锁住环境避免队友拿到手跑不起来。6. 图谱验证与进阶从查询到关系补全与交互问答6.1 验证图谱质量人工抽样与图指标建完图谱第一件事不是写漂亮界面而是验证能用。我一般看三个数字节点总数、关系总数、孤立点比例。如果关系数和节点数比值小于 0.8说明大量节点没有边图谱基本是死的。具体到质量我会随机抽 20 条三元组让植保顾问人工判断有没有错误。准确率低于 90% 就先别做应用回头调关系抽取规则或数据源对齐。6.2 进阶用知识图谱嵌入补全缺失关系当你觉得图谱太稀疏但又找不到更多数据源时可以试一下知识图谱嵌入。简单说就是把实体和关系映射成向量然后通过 TransE 这类模型预测缺失的关系。PyKEEN 可以快速跑通from pykeen.pipeline import pipeline result pipeline( trainingtriples_df, modelTransE, training_kwargsdict(num_epochs50), )这段代码会返回训练好的模型之后可以调用 result.model.predict 去回答“(济麦22, ?, 条锈病)”这类缺失关系。参数 num_epochs 在小数据集上 50 已经够看趋势不要一开始就调几百。它输出的候选三元组必须人工再筛一遍否则会把不存在的抗性关系补出来。6.3 把图谱做成问答与可视化最终价值要落到使用场景。最简单的是把 Cypher 查询包装成接口前端输入“济麦22用什么药”后端将问句转成模板查询再返回结果。这种轻量问答不需要大模型正则加模板即可。可视化方面Neo4j Bloom 足够日常演示你也可以用可视化本体建模编辑器快速验证图谱结构它在构建阶段比写代码改脚本直观得多。我做这个方向踩过最大的坑就是一开始沉迷于炫酷的可视化却忽略了数据源里的“同物异名”导致领导让演示时屏幕上两个“济麦22”节点尴尬并列。后来我给自己立了规矩先花一周理数据源和本体设计再花两天写代码。知识图谱也是一样数据源不稳后面全白搭。希望帮到你。本文还有配套的精品资源点击获取