简介本资源面向农业科研人员、知识图谱初学者与IT从业者提供小麦知识图谱从数据源整理到图谱构建的完整实践素材帮助解决农业领域数据分散、结构化程度低、难以关联检索的问题。压缩包共27个文件约2.4MB以12个Python脚本为核心覆盖数据预处理、病虫害与肥料信息处理、爬虫采集、Neo4j导入等模块另有11个txt与2个csv存放原始及清洗后的数据1个json保存图谱结构化结果1个md说明文档辅助理解项目结构。已有340人学习下载。通过阅读与运行代码读者可掌握数据清洗、实体关系建模、图谱存储与查询接口的实现思路并借助可视化方式探索小麦品种、生长环境与产量之间的潜在关联为农业数据分析和知识图谱项目落地提供可复用的参考方案。1. 小麦知识图谱的数据源及代码从零散数据到可查询图谱的落地路径做农业信息化的朋友大概率遇到过这种场景手里攒了品种审定数据、栽培技术手册、病虫害防治记录、土壤养分检测报告格式横跨 Excel、PDF、CSV 和纸质扫描件想查一个「济麦22在山东偏沙壤土上拔节期该追多少氮肥」得翻四五个文件。小麦知识图谱要解决的就是这件事——把分散的、异构的小麦领域数据抽成实体和关系存进图数据库让「品种—农艺措施—病虫害—环境」之间的关联变成可查询、可推理的结构。这篇笔记不讲空泛概念只讲数据源怎么选、代码怎么写、坑在哪。适合已经会 Python、想把手头农业数据做成图谱的从业者也适合刚接触知识图谱构建、需要一个完整可复现案例的新手。2. 小麦知识图谱的数据源盘点与选型哪些能用哪些是坑2.1 四类核心数据源及其结构化程度小麦领域的数据源按结构化程度从高到低排大致是这么四类。第一类是品种审定与登记数据。国家和省级农作物品种审定公告里包含品种名称、亲本组合、选育单位、审定编号、适宜种植区域、产量表现等字段。这类数据通常是网页表格或 PDF 附件字段规整是最容易抽取的一类。品种名、亲本、适宜区域天然就是实体审定关系、亲本关系天然就是边。第二类是栽培技术资料。包括栽培技术规程、施肥建议、灌溉制度、播期播量推荐。这类数据半结构化常见形式是「品种 区域 生育时期 措施 用量」的叙述句。比如「济麦22在鲁中地区适播期为10月5日至10月12日亩基本苗15万至18万」。抽取难点在于同一句话里可能包含多个实体和多个关系需要做实体边界识别。第三类是病虫害与草害数据。包括病虫害名称、症状描述、发生条件、防治药剂、防治时期。这类数据里实体类型多病害、虫害、药剂、气象条件关系类型也多防治、诱发、并发是图谱里价值密度最高的部分但抽取难度也最大。第四类是土壤与气象数据。土壤类型、养分含量、pH 值、积温、降水等。这类数据往往是数值型的进图谱前需要做离散化或区间化处理否则一个「pH6.8」的节点没有查询价值应该归到「微酸性土壤」这个类别节点上。选型上我的建议是先做第一类和第二类跑通全流程再啃第三类。第一类数据质量高、抽取规则明确适合验证你的抽取脚本和图谱 schema第二类数据量大、覆盖广能撑起图谱的查询场景第三类数据虽然价值高但如果你一上来就做很容易卡在实体识别准确率上半个月出不来一个能查的图谱信心就没了。2.2 数据源获取的合规边界与清洗优先级数据获取这块公开的品种审定公告、农业技术推广站发布的栽培规程、公开发表的学术论文里的数据都是可以用的。但要注意两点一是不要抓取有明确版权声明或需要授权才能使用的商业数据库二是如果数据里包含农户个人信息、地块精确坐标必须做脱敏。清洗优先级我一般这么排优先级清洗动作目的P0去重、去空、编码统一为 UTF-8保证后续脚本不报错P1字段名标准化如「品种名称」「品种名」统一为variety_name保证抽取规则可复用P2数值字段单位统一亩、公顷、千克、公斤避免图谱里出现同一实体的不同量纲P3文本分句、去停用词、繁简统一提升实体抽取准确率P0 和 P1 不做后面全是血泪。我见过一个数据集里「济麦22」出现了七种写法包括全角空格、繁体和错别字如果不做标准化图谱里会生成七个不同的品种节点查询直接翻车。2.3 用 Python 做数据源摸底的最小脚本在正式抽取之前先写一个摸底脚本把每个数据源的字段、行数、空值率、样例值打出来。这一步花二十分钟能省后面两天。import pandas as pd import os def profile_source(filepath, encodingutf-8): 打印单个数据源的基本画像 if filepath.endswith(.csv): df pd.read_csv(filepath, encodingencoding) elif filepath.endswith((.xlsx, .xls)): df pd.read_excel(filepath) else: print(f跳过不支持格式: {filepath}) return None print(f {os.path.basename(filepath)} ) print(f行数: {len(df)}, 列数: {len(df.columns)}) for col in df.columns: null_rate df[col].isna().mean() sample df[col].dropna().iloc[0] if not df[col].dropna().empty else N/A print(f {col}: 空值率{null_rate:.2%}, 样例{str(sample)[:40]}) return df # 批量摸底 for f in [variety.csv, cultivation.xlsx, pest.csv]: if os.path.exists(f): profile_source(f)这段脚本的逻辑很直白按扩展名选读取方式然后逐列输出空值率和第一个非空样例。参数上encoding默认utf-8但如果你的 CSV 是 GBK 编码国内农业数据很常见要改成gbk否则会抛UnicodeDecodeError。样例值截断到 40 个字符是为了在终端里看得清楚。摸底之后你会对数据质量有个判断。如果某个关键字段空值率超过 30%要么补数据要么这个字段就别进图谱了硬塞进去只会让查询结果不可信。3. 从数据源到图谱实体关系抽取的代码实现3.1 定义小麦领域的 schema实体类型与关系类型写抽取代码之前先把 schema 定下来。schema 就是图谱的「表结构」定不好后面改起来很痛苦。小麦知识图谱我一般用这么几类实体和关系实体类型Variety品种、Region区域、GrowthStage生育时期、Measure农艺措施、Disease病害、Pest虫害、Pesticide药剂、SoilType土壤类型。关系类型suitable_for品种适宜区域、has_parent亲本关系、apply_at措施施用时期、prevent药剂防治对象、occur_in病虫害发生区域、induce环境诱发病虫害。schema 定好之后抽取代码就围绕「从文本里找实体再找实体之间的关系」来写。这里我用规则加词典的方式不依赖深度学习模型原因是农业领域标注数据少训练模型成本高而规则方式在小麦这种实体名称相对固定的领域里准确率反而更可控。3.2 基于词典和正则的实体抽取代码先建词典再写抽取函数。词典可以从数据源里自动积累也可以手工补充。import re from collections import defaultdict # 实体词典实际项目中应从数据源自动积累 人工补充 VARIETY_DICT {济麦22, 济麦44, 山农28, 鲁原502, 烟农1212} REGION_DICT {山东, 河南, 河北, 鲁中, 鲁西, 豫北} STAGE_DICT {播种期, 拔节期, 抽穗期, 灌浆期, 成熟期} MEASURE_DICT {追施氮肥, 灌溉, 喷施叶面肥, 化学除草} def extract_entities(text): 从一段文本中抽取所有实体返回 {实体类型: [实体列表]} result defaultdict(list) # 品种词典匹配按长度降序避免短名覆盖长名 for v in sorted(VARIETY_DICT, keylen, reverseTrue): if v in text: result[Variety].append(v) for r in REGION_DICT: if r in text: result[Region].append(r) for s in STAGE_DICT: if s in text: result[GrowthStage].append(s) for m in MEASURE_DICT: if m in text: result[Measure].append(m) # 数值单位正则抽取用量 dosage re.findall(r(\d(?:\.\d)?)\s*(公斤|千克|kg|亩), text) if dosage: result[Dosage] [f{d[0]}{d[1]} for d in dosage] return dict(result) # 测试 sample 济麦22在鲁中地区拔节期追施氮肥每亩用量15公斤。 print(extract_entities(sample))这段代码的核心逻辑是「词典匹配 正则补充」。词典匹配用sorted(..., keylen, reverseTrue)是为了防止「济麦2」这种短名先匹配到把「济麦22」截断。正则部分抽的是「数值单位」的组合用来捕获用量信息。参数说明VARIETY_DICT等词典在实际项目里应该从数据源里用频次统计自动生成候选再人工筛选。手工维护的词典覆盖有限但准确率高。如果你的数据源里品种名超过 200 个建议改成从文件加载词典而不是硬编码在代码里。3.3 关系抽取把实体对变成图谱的边实体抽出来之后下一步是判断两个实体之间是什么关系。最简单的方式是基于「共现 位置规则」如果品种和区域出现在同一句话里且品种在区域前面就认为存在suitable_for关系。def extract_relations(text, entities): 基于共现和位置规则抽取关系 relations [] # 品种-区域同句共现即认为适宜关系 for v in entities.get(Variety, []): for r in entities.get(Region, []): if text.index(v) text.index(r): relations.append((v, suitable_for, r)) # 品种-措施-时期措施和时期共现且品种也在句中 for v in entities.get(Variety, []): for m in entities.get(Measure, []): for s in entities.get(GrowthStage, []): relations.append((v, apply_measure, m)) relations.append((m, apply_at, s)) return relations ents extract_entities(sample) rels extract_relations(sample, ents) for r in rels: print(r)这里的关系抽取规则很朴素但胜在可解释、可调试。实际项目中如果文本里出现「不适宜」「不宜」这类否定词需要在规则里加否定检测否则会把「济麦22不适宜在豫北种植」抽成适宜关系这是最常见的翻车点之一。参数上text.index()在实体名是另一个实体名子串时会出错比如「济麦2」和「济麦22」所以词典匹配阶段就要保证实体名之间没有子串包含关系或者在比较位置时用更精确的边界匹配。3.4 把抽取结果写入 Neo4j 的完整代码抽取完实体和关系最后一步是入库。Neo4j 是知识图谱最常用的图数据库用py2neo或官方neo4j驱动都可以。下面用官方驱动写一个批量导入的脚本。from neo4j import GraphDatabase class WheatKG: def __init__(self, uri, user, password): self.driver GraphDatabase.driver(uri, auth(user, password)) def close(self): self.driver.close() def create_entity(self, label, name, propsNone): 创建实体节点label 是实体类型name 是实体名 props props or {} query fMERGE (n:{label} {{name: $name}}) SET n $props with self.driver.session() as session: session.run(query, namename, propsprops) def create_relation(self, head_label, head_name, rel_type, tail_label, tail_name): 创建关系关系类型用反引号包裹防止关键字冲突 query ( fMATCH (a:{head_label} {{name: $head_name}}) fMATCH (b:{tail_label} {{name: $tail_name}}) fMERGE (a)-[:{rel_type}]-(b) ) with self.driver.session() as session: session.run(query, head_namehead_name, tail_nametail_name) # 使用示例 kg WheatKG(bolt://localhost:7687, neo4j, your_password) kg.create_entity(Variety, 济麦22, {审定编号: 国审麦20180001}) kg.create_entity(Region, 鲁中) kg.create_relation(Variety, 济麦22, suitable_for, Region, 鲁中) kg.close()这段代码的关键点有三个。第一用MERGE而不是CREATE保证同一个实体不会重复创建这是图谱去重的第一道防线。第二关系类型用反引号包裹因为 Neo4j 里有些词是保留字不加反引号可能报语法错误。第三SET n $props是增量更新属性不会覆盖已有属性。参数说明uri一般是bolt://localhost:7687如果你改了 Neo4j 的默认端口要对应调整。your_password是安装 Neo4j 时设的密码别用默认的neo4j第一次登录会强制改。批量导入时每创建一条关系就开一次 session 效率很低实际项目里应该把 session 复用或者用UNWIND批量操作。4. 避坑与排查小麦知识图谱构建中最容易翻车的五个地方4.1 实体名不统一导致图谱「分裂」现象查询「济麦22」的适宜区域返回空结果但图谱里明明有数据。原因数据源里同时存在「济麦22」「济麦 22」「济麦二十二」三种写法被当成三个不同节点。解决在抽取之前加一层实体名归一化用映射表把变体统一到标准名。我的习惯是建一个alias_map字典在create_entity之前先过一遍。4.2 关系方向搞反导致查询语义错误现象查「哪些品种适宜鲁中」结果查出来的是「鲁中适宜哪些品种」虽然数据对但语义反了。原因suitable_for关系建成了Region - Variety。解决schema 定好之后写死在代码里关系方向不要临时改。如果实在拿不准用双向关系或者把关系名改成无方向的related_to但这样会损失语义精度。4.3 数值型数据直接入图导致查询无意义现象图谱里有一堆pH6.8、pH6.9的节点查询「酸性土壤适合种什么」查不出来。原因数值没有离散化。解决入图前把数值映射到区间节点比如pH6.5归到「酸性土壤」6.5pH7.5归到「中性土壤」。映射规则要写在抽取脚本里不要等到入图之后再补。4.4 批量导入时 session 未复用导致性能崩溃现象导入一万条关系花了两个小时还没跑完。原因每条关系都driver.session()开一次连接开销远大于写入开销。解决把 session 提到循环外面或者用UNWIND把批量数据一次性传入。下面是一个批量导入的优化写法。def batch_create_relations(self, relations): relations: [(head_label, head_name, rel_type, tail_label, tail_name), ...] query UNWIND $rels AS rel MATCH (a:%s {name: rel.head_name}) MATCH (b:%s {name: rel.tail_name}) MERGE (a)-[:%s]-(b) # 注意label 和 rel_type 不能参数化需要拼接所以要确保来源可信 with self.driver.session() as session: session.run(query, relsrelations)这里有个坑Neo4j 的 label 和关系类型不支持参数化只能字符串拼接。如果rel_type来自用户输入会有注入风险。农业领域的数据源一般可信但如果是开放平台必须做白名单校验。4.5 否定句和条件句被当成肯定关系现象「济麦22在旱地不宜追施氮肥」被抽成了济麦22 -[apply_measure]- 追施氮肥。原因规则抽取没有处理否定词。解决在关系抽取前加一个否定检测如果实体对之间出现「不」「不宜」「禁止」「避免」等词就跳过或者标记为否定关系。这个坑在栽培技术文本里特别常见因为技术规程里大量出现「不宜」「注意避免」这类表述。5. 进阶技巧用 Cypher 验证图谱质量与查询优化图谱建完之后怎么知道建得好不好我一般用三个 Cypher 查询来验证。第一个查孤立节点。孤立节点说明实体抽出来了但关系没抽到要么是数据源本身缺关系要么是关系抽取规则漏了。MATCH (n) WHERE NOT (n)--() RETURN labels(n) AS 类型, n.name AS 名称, count(*) AS 数量 ORDER BY 数量 DESC第二个查关系类型分布。如果某类关系数量异常少说明对应的抽取规则可能有问题。MATCH ()-[r]-() RETURN type(r) AS 关系类型, count(*) AS 数量 ORDER BY 数量 DESC第三个查同一实体名对应多个节点的情况这是实体归一化没做干净的信号。MATCH (n) WITH n.name AS name, collect(labels(n)) AS labels, count(*) AS cnt WHERE cnt 1 RETURN name, labels, cnt ORDER BY cnt DESC查询优化上给常用查询的实体属性建索引能显著提升速度。比如品种名是最高频的查询入口就给它建唯一约束加索引。CREATE CONSTRAINT variety_name_unique IF NOT EXISTS FOR (v:Variety) REQUIRE v.name IS UNIQUE;这个约束一建MERGE的时候如果出现重复品种名会直接报错相当于给实体归一化加了一道强制检查。我一般会在导入前先建约束导入时如果报重复就说明归一化没做到位正好倒逼去修数据。最后一个技巧是关于查询的。小麦知识图谱最常见的查询是「某品种在某区域某生育时期该做什么」对应的 Cypher 是MATCH (v:Variety {name: 济麦22})-[:suitable_for]-(r:Region {name: 鲁中}) MATCH (v)-[:apply_measure]-(m:Measure)-[:apply_at]-(s:GrowthStage {name: 拔节期}) RETURN v.name, r.name, s.name, m.name这条查询走的是Variety - Region和Variety - Measure - GrowthStage两条路径如果数据量大给name属性建索引之后响应时间能从秒级降到毫秒级。我做这类图谱项目最大的教训是别急着上模型先把规则和 schema 打磨好。我见过太多团队一上来就搞 BERT 做实体识别结果标注数据不够准确率还不如词典匹配白白烧了两周 GPU。农业领域的实体名称相对固定规则加词典的方式在 80% 的场景下够用剩下 20% 的硬骨头再考虑模型。另外图谱建完不是终点要拿真实查询去测查不出来的地方就是抽取规则要补的地方。希望帮到你。本文还有配套的精品资源点击获取