从爬虫到Neo4j：构建军事装备知识图谱的完整实践

简介：这是一份面向计算机相关专业学生与开发者的军事装备知识图谱网页应用构建源码项目，适用于毕业设计、课程设计或项目初期立项演示。系统围绕爬虫与Python技术实现，从互联网抓取军事装备数据后，基于百度文心ERNIE 3.0模型进行实体识别与关系抽取，将结果整理为三元组并存入Neo4j数据库，进而构成数据爬虫、数据管理、数据处理、知识问答、新闻热点、词条查询和图谱展示七大功能模块，覆盖知识图谱从数据获取到可视化的完整链路。资源包共包含2000个文件，以大量图片样本、Vue前端组件、Python处理脚本、JSON配置及CSV数据文件为主，压缩包整体约179MB，目录结构清晰，便于按模块定位和检索。目前已有79人学习下载。代码经测试运行成功，同时附有项目文档和全部资料，答辩评审分达95分，高完成度的实现方案既能支撑课设毕设实战，也可供入门者以此为基础二次开发。

1. 军事装备知识图谱：从爬虫、BERT到Neo4j的一条完整落地链路

很多人拿到知识图谱相关的课程设计或毕设题目，第一反应是先装一个 Neo4j，然后卡在“数据从哪来”。这个高分项目不是只给一个空壳页面，而是一条闭合的工程链路：Python 爬虫采集公开军事装备资料 → 清洗成结构化语料 → 深度学习模型做实体识别和关系抽取 → 三元组批量写入 Neo4j → Flask 提供接口、ECharts 渲染成交互网页。它把“数据、算法、存储、展示”四个最容易脱节的环节串在了一起，目录里源码、文档、数据集、模型训练记录都齐，照着跑就能得到一个可演示可答辩的完整应用。适合做课程设计、毕业设计，也适合想完整走一遍“深度学习 + 图数据库”全流程的工程师。

2. 爬虫与语料工程：把公开资料变成可训练的装备语料

知识图谱的地基不是模型，是数据。不少人在这一步就翻车了：拿 requests 去硬抓几十个页面，断点续传、反爬、编码问题全撞上，最后只攒了几百条数据，模型根本训不动。所以这一章先说数据怎么来、怎么清洗、怎么变成算法能吃的三元组。

2.1 为什么用 Scrapy 而不是 requests + BeautifulSoup

项目里爬虫用的是 Scrapy，不是简单的 requests 脚本。原因很直接：装备类公开资料分布在百科词条、专题页、新闻站，单站几百个 URL，字段结构相近但页面样式不统一，且不少站点有访问频率限制。requests + BeautifulSoup 适合一次性爬几十页的验证脚本，一旦页面数量上千，代理切换、请求重试、并发控制、异常续爬就全都得自己造轮子，Scrapy 中间件和 Downloader 已经把这些能力内置好了。

import scrapy from scrapy.spidermiddlewares.httperror import HttpError from twisted.internet.error import TimeoutError, TCPTimedOutError class EquipSpider(scrapy.Spider): name = "equip_spider" start_urls = ["https://example-archive.org/military/equipments"] custom_settings = { "CONCURRENT_REQUESTS": 4, "DOWNLOAD_DELAY": 1.2, "USER_AGENT": "Mozilla/5.0 (Windows NT 10.0; Win64; x64)", "RETRY_TIMES": 3, } def parse(self, response): for item in response.css("div.equip-card"): yield { "name": item.css(".title::text").get(), "category": item.css(".category::text").get(), "intro": item.css(".desc::text").get(), "source_url": response.url, } next_page = response.css("a.next::attr(href)").get() if next_page: yield scrapy.Request(response.urljoin(next_page), callback=self.parse)

这段逻辑里最值得关注的是custom_settings里的四个参数。CONCURRENT_REQUESTS设为 4，配合DOWNLOAD_DELAY的 1.2 秒，是把目标站点压力控制在一个礼貌区间内的常见做法，既不会因为并发太高被拉黑，也不会因为太慢拖垮整个采集周期。RETRY_TIMES处理临时网络抖动，USER_AGENT伪装成浏览器。目录里还有代理中间件的配置示例，如果你要爬的站点对 IP 敏感，把那部分打开即可。

2.2 清洗与句子切分：消除网页噪音，保住完整语义

爬下来的文本不能直接喂给模型，里面混着导航栏、版权信息、HTML 残留标签和乱码。清洗分两步：先剥掉标签和脚本块，再按句号、问号、感叹号切分成短句。这里有个很多人忽略的细节：中文语料切句不能只按.切，因为英文句点会出现在缩写、数字和小数里；默认按中英文句号、问号、感叹号切最稳。

import re from bs4 import BeautifulSoup def clean_html(raw_html: str) -> str: soup = BeautifulSoup(raw_html, "html.parser") for tag in soup(["script", "style", "noscript"]): tag.decompose() text = soup.get_text(separator="\n", strip=True) text = re.sub(r"[\u200b\u3000]", "", text) return text def split_sentences(text: str): parts = re.split(r"(?<=[。！？!?])\s*", text) return [s.strip() for s in parts if len(s.strip()) >= 10] raw_text = clean_html(html_content) sentences = split_sentences(raw_text)

clean_html用 BeautifulSoup 把 script、style 这类与正文无关的块直接移除，再用get_text统一提取文本。split_sentences里的正则用了(?<=...)后行断言，切句后不丢失标点，过滤掉少于 10 个字符的碎片——实战中太短的句子往往是导航文字或标题碎片，放进训练集会变成噪声。清洗脚本跑完之后，语料按“装备名.txt”落盘，每个文件里是一行一条的干净句子，方便后面标注。

2.3 三元组粗标：规则打底、人工修正，最后输出统一 JSON

深度学习关系抽取需要监督数据，但全人工标注几百条三元组不现实。项目里的做法是“规则粗标 + 人工抽样修正”：先基于依存句法触发词和装备词表做自动标注，再用标注工具抽检修正。触发词如“研制”“服役”“装备”“列装”，配合正则定位实体词，提取(头实体, 关系, 尾实体)形式的三元组。粗标的正确率通常在 60% 到 70%，人工修正后能提到 85% 以上，对关系分类训练已经够用。

{ "sentence": "歼-16是由沈阳飞机工业集团研制的一款重型多用途战斗机，于2011年首飞。", "triplets": [ {"head": "歼-16", "relation": "研制", "tail": "沈阳飞机工业集团"}, {"head": "歼-16", "relation": "首飞时间", "tail": "2011年"} ] }

标注产出的 JSON 是后续所有流程的统一接口：NER 需要的是sentence和实体边界，关系分类需要的是sentence加head/tail的字符串和位置。目录里的data/annotated/文件夹存了清洗后生成的粗标结果和人工修正记录，格式就是上面这种，照着格式扩展新的实体类型就行。粗标阶段有个经验值：每种关系至少保留 120 条正样本，否则模型倾向于把所有实体对都预测成频率最高的那个关系，后验评估时非常难看。

3. 深度学习抽取：BERT-NER 与关系分类，别把模型当黑匣子

数据准备好之后，进入核心算法环节。项目在实体识别和关系抽取两层都用了深度学习方案，模型选型和训练参数的设置决定了最终三元组的质量。这一章不写数学推导，只讲怎么选择、怎么调参、怎么评估。

3.1 选型理由：为什么用 BERT 而不是 Word2Vec + BiLSTM

军事装备文本的特点是实体密集、专业术语多，比如“歼-16”“有源相控阵雷达”“沈阳飞机工业集团”这些词在通用语料里很少出现，从头训练词向量很难得到有区分度的表示。项目采用的是中文预训练模型bert-base-chinese或hfl/chinese-wwm-ext，这两个模型在通用中文语料上预训练过，迁移到装备领域只需少量微调。“chinese-wwm-ext” 比bert-base-chinese多了全词掩码的训练策略，对中文实体边界的学习更好，目录里默认配置用的就是后者。如果你的机器只有 CPU，bert-base-chinese也能跑，就是训练轮数要拉长，小数据集上建议将epochs从 5 降到 3，过拟合会明显缓解。

3.2 NER 实现：BIO 序列标注与 BERT + CRF 解码

实体识别被设计成序列标注任务，标签体系用 BIO：B表示实体开始词，I表示实体内部词，O表示非实体。项目定义了四类实体：装备型号、研制机构、国家/地区、时间。训练时要将每个句子编码成input_ids、attention_mask和标签序列，模型输出每个 token 属于各类别 BIO 标签的概率，最后用条件随机场（CRF）约束标签转移，避免出现“I 开头却没有对应 B”这类非法序列。

from transformers import BertTokenizerFast, BertForTokenClassification from transformers import Trainer, TrainingArguments tokenizer = BertTokenizerFast.from_pretrained("hfl/chinese-wwm-ext") model = BertForTokenClassification.from_pretrained( "hfl/chinese-wwm-ext", num_labels=len(label2id) ) def tokenize_and_align_labels(examples): tokenized = tokenizer( examples["tokens"], truncation=True, max_length=128, is_split_into_words=True, padding="max_length" ) labels = [] for i, label in enumerate(examples["ner_tags"]): word_ids = tokenized.word_ids(batch_index=i) prev_word = None label_ids = [] for word_id in word_ids: if word_id is None: label_ids.append(-100) elif word_id != prev_word: label_ids.append(label[word_id]) else: label_ids.append(-100) prev_word = word_id labels.append(label_ids) tokenized["labels"] = labels return tokenized training_args = TrainingArguments( output_dir="./ner_model", learning_rate=2e-5, per_device_train_batch_size=16, num_train_epochs=5, evaluation_strategy="epoch", save_strategy="epoch", ) trainer = Trainer(model=model, args=training_args, train_dataset=train_ds, eval_dataset=eval_ds) trainer.train()

TokenizeAndAlignLabels里word_ids的处理是 NER 训练最容易出错的点：BERT 分词器会把一个中文词切成多个子 token，每一个子 token 都要对齐到同一个标签，多余的[PAD]和子词位置用-100遮住，这样计算损失时才不会把填充位置算进去。学习率2e-5是微调 BERT 的标准起点，太高会把预训练权重冲坏，太低收敛极慢。max_length=128对装备描述这种短句足够，若语料里出现 200 字以上的长句，把它提到 256 会让训练时间增加近一倍，收益却不明显。

3.3 关系分类：基于实体对的句子级分类

NER 找出实体，关系分类判断两个实体之间属于哪种关系。项目把任务建模成句子级多分类：在原始句子的头实体、尾实体前后插入[E1]、[/E1]、[E2]、[/E2]标记，让模型在 attention 计算时能区分出实体的边界，再取[CLS]位置的表示做分类。这个方案比单纯拼接两个实体的 embedding 准确率高，因为实体上下文信息被保留了。

import torch from transformers import BertTokenizer, BertForSequenceClassification tokenizer = BertTokenizerFast.from_pretrained("hfl/chinese-wwm-ext") model = BertForSequenceClassification.from_pretrained( "hfl/chinese-wwm-ext", num_labels=len(rel2id) ) def build_input(sentence, head, tail): marked = sentence.replace(head, f"[E1]{head}[/E1]", 1) marked = marked.replace(tail, f"[E2]{tail}[/E2]", 1) return tokenizer(marked, max_length=128, padding="max_length", truncation=True) inputs = build_input("歼-16由沈阳飞机工业集团研制，2011年首飞", "沈阳飞机工业集团", "歼-16") outputs = model(**inputs) pred = torch.argmax(outputs.logits, dim=-1).item() print(rel2id_inv[pred])

build_input里用了两个特殊标记把实体包起来，replace(..., 1)只替换第一次出现位置，防止多个同名实体时标错。训练时这类数据每个实例对应一个关系标签，损失函数是标准的 CrossEntropyLoss。数据组织上容易忽视的是方向问题：(沈阳飞机工业集团, 研制, 歼-16)和(歼-16, 研制, 沈阳飞机工业集团)在主客体交换后语义完全不同，目录里的数据已经按主客顺序排好，自己扩展数据时务必保持“主体在前、客体在后”的一致性。

3.4 评估与 badcase：P/R/F1 只是开始，边界错误要看全

项目提供了一套完整的评估脚本，对 NER 和关系分类分别计算精确率、召回率和 F1。跑完一轮后别只看 F1 数值，建议把识别错的样本打印出来逐条看。军事装备里最常见的 badcase 是实体边界错误：“沈阳飞机工业集团”被识别成“沈阳飞机”或“沈阳飞机工业”，前者丢失了机构信息，后者把机构名字截短了。这种错误在序列标注里很常见，处理手段是检查标注数据里有没有边界不一致的情况，比如同一篇语料中“歼-16”有时标成B-I-I，有时标成B-I，模型就会困惑。把训练数据里的实体边界统一后，F1 通常能涨 2 到 3 个百分点。

4. Neo4j 建模与批量导入：三个决策点决定图谱好不好用

模型产出的三元组是一张“平面”的关系表，放进 Neo4j 才能变成图谱。但直接LOAD CSV导入只是第一步，数据建模的决策直接决定后续查询好不好写、前端可视化顺不顺。这一章把建模、导入、接口三层一次说完。

4.1 节点与关系建模：实体类型确定后，别随意加属性

项目定义的核心节点有四类：装备、机构、国家、时间。关系类型对应模型里的关系集合：研制、服役、装备、首飞、列装。一个常见的设计失误是想把所有信息都塞进节点属性，比如把“首飞时间”和“服役时间”都挂在装备节点上。短期看查询方便，但知识图谱的意义在于关系可以被遍历，“歼-16 与 2011 年首飞”如果只是一个属性，就丢失了时间节点与其他实体的关联路径。项目里所有关系都建模成边，时间也作为独立节点存在，这样“查询所有 2010 年后首飞的装备”就能用一条路径表达式完成。

建模完成后，在 Neo4j 里对name字段建唯一约束，这是防止重复节点的第一道防线。写入数据前先违约创建一下约束，后面MERGE时才不会踩“同一实体出现两遍”的坑。

4.2 批量导入：LOAD CSV 配合 PERIODIC COMMIT

数据量几千条时，用py2neo逐条写入也能跑，但上万条三元组后事务提交会越来越慢。项目采用LOAD CSV方案：先从 Python 侧把三元组导出成 CSV，再用 Cypher 批量导入。节点和关系各自导入，节点先建、关系后挂。USING PERIODIC COMMIT 500相当于每 500 行自动提交一次事务，避免单事务内存压力过大。

# 将 Python 导出的节点/关系 CSV 复制到 Neo4j 的 import 目录 cp data/export/equipment_nodes.csv /var/lib/neo4j/import/ cp data/export/relations.csv /var/lib/neo4j/import/

USING PERIODIC COMMIT 500 LOAD CSV WITH HEADERS FROM 'file:///equipment_nodes.csv' AS row MERGE (e:Equipment {name: row.name}) ON CREATE SET e.category = row.category, e.wiki_id = row.wiki_id; USING PERIODIC COMMIT 500 LOAD CSV WITH HEADERS FROM 'file:///relations.csv' AS row MATCH (head:Equipment {name: row.head_name}) MATCH (tail:Organization {name: row.tail_name}) MERGE (head)-[r:研制]->(tail) SET r.source = row.source;

MERGE是导入时的核心：节点已存在则匹配，不存在则创建，比CREATE安全得多。关系导入用MATCH先定位两端的节点，再MERGE建边。这里有一个性能细节：如果节点数量大，MATCH必须走索引，否则每次匹配都是全表扫描。所以在导入节点之后、导入关系之前，先执行CREATE CONSTRAINT把Equipment.name、Organization.name建上唯一约束，导入速度会有一个质的提升。项目源码里还附带了一个export_to_csv.py，负责把模型输出的三元组 JSON 转成 CSV，字段顺序和上面两张表完全一致。

4.3 Flask 查询接口：把 Cypher 结果包装成 JSON

网页应用不直接连数据库，而是通过 Flask 提供一组 /api/search、/api/graph 接口。后端用 neo4j 官方 Python Driver，查询结果转成 JSON 返回前端。这个设计的价值在于把 Cypher 查询和页面渲染解耦，前端调接口拿数据即可。

from flask import Flask, jsonify, request from neo4j import GraphDatabase app = Flask(__name__) driver = GraphDatabase.driver("bolt://localhost:7687", auth=("neo4j", "password")) @app.route("/api/graph", methods=["GET"]) def graph(): name = request.args.get("name", "歼-16") cypher = """ MATCH (n {name: $name})-[r]->(m) RETURN n.name AS head, type(r) AS rel, m.name AS tail LIMIT 200 """ with driver.session() as session: result = session.run(cypher, name=name) nodes, relations = set(), [] for record in result: nodes.add(record["head"]); nodes.add(record["tail"]) relations.append({"source": record["head"], "rel": record["rel"], "target": record["tail"]}) return jsonify({"nodes": list(nodes), "relations": relations}) if __name__ == "__main__": app.run(host="0.0.0.0", port=5000, debug=False)

接口里用$name参数化查询，避免 Cypher 注入，这是 Neo4j 官方推荐写法。LIMIT 200是保护性上限，防止一个节点的关联边过多把前端页面撑爆。返回的 nodes 用集合去重，relations 保留原始关系类型。前端拿到这两块数据后，ECharts 的关系图配置可以直接使用。

5. Neo4j 与网页应用常见问题排查：五条实战踩坑记录

这一章全是项目跑通过程中真实遇到过的坑，每条都按“现象 → 原因 → 解决”记录。如果你在复现时碰到类似问题，直接对号入座。

5.1 Neo4j 侧的坑：IP 访问被拒、内存崩溃、导入时连接断开

现象一：Neo4j 在本机 localhost:7474 能打开，局域网里用http://服务器IP:7474却始终连不上，浏览器报连接超时。

原因：Neo4j 默认配置里只监听了 localhost，也就是server.default_listen_address=localhost，它根本没对外网卡开放端口，跟防火墙没有关系。

解决：修改neo4j.conf里的监听配置，把server.default_listen_address改为0.0.0.0，同时确认server.bolt.listen_address也改成0.0.0.0:7687。改完后重启 Neo4j 服务，再用netstat -tlnp | grep 7474确认端口监听的地址不再是 127.0.0.1。

现象二：用USING PERIODIC COMMIT导入几万条关系时，Neo4j 进程直接卡死，日志里出现OutOfMemoryError，甚至系统开始疯狂使用 swap，机器响应变慢。

原因：Neo4j 默认的 JVM 堆内存和页缓存设置适合开发环境，几万条数据导入时的中间缓存超出了默认dbms.memory.heap.max_size的限制，触发长时间 GC 甚至 OOM。

解决：在neo4j.conf里根据机器物理内存调整三个参数：dbms.memory.heap.initial_size和dbms.memory.heap.max_size设置为物理内存的 25%（比如 16G 内存就设 4G），dbms.memory.pagecache.size设为物理内存的 50%。配置文件改完必须重启才能生效。你要是记不住这套比例，项目文档的部署章节里直接给了 8G、16G、32G 三档推荐值。

现象三：LOAD CSV导入过程中报错Couldn't load the external resource，文件明明已经放在import目录里了。

原因：新版本 Neo4j 对import目录做了白名单限制，file:///后面的路径必须真实存在于dbms.directories.import配置的目录之下。很多人把 CSV 放在项目根目录，然后写绝对路径，就被拦了。

解决：把 CSV 复制到 Neo4j 的import目录下，或者临时修改dbms.directories.import指向你的数据目录。项目里提供了一个sync_import_dir.sh脚本，一键把导出目录同步到 import 目录。

5.2 算法侧与前端侧的坑：推理 OOM 和渲染卡死

现象四：BERT 模型训练时正常，推理阶段处理长文本时直接报CUDA out of memory，但批次已经设为 1。

原因：单条样本的max_length设置过大，或者同一批数据里存在超长句子，导致单个样本的中间张量超出了显存余量。有些句子的长度甚至超过了预训练模型允许的 512 token 上限。

解决：推理时把max_length压缩到 128 到 256，并启用truncation=True。如果单条句子还是超限，就在前端查询接口里把过长的句子跳过或先行切句。NVIDIA 显卡上也可以开启torch.cuda.amp混合精度推理，显存占用能降一半左右。

现象五：图谱页面在实体数量超过 500 时就卡成幻灯片，鼠标拖拽毫无响应，刷新也慢。

原因：ECharts 关系图全量渲染所有节点和边，图表内部做了大量力导向布局计算。数据上到上千节点时，浏览器主线程被同步计算拖垮。

解决：项目前端在/api/graph接口里加了LIMIT 200的硬性约束，同时前端对返回的节点按关联度排序，只渲染前 200 个节点。如果你确实需要展示全量图，用 ECharts 的zoom和增量加载，分批渲染节点，配合roam的缩放做局部展示。答辩演示时提前把数据量控制在 200 到 300 节点，体验最流畅。

6. 白盒验证与演示调优：让项目在答辩时站得住

项目跑到“能打开页面”不算完，还得让数据质量经得起追问。这里给出一套实操的验证流程，在答辩前花半小时跑一遍，问到任何一环都有数据撑腰。

第一步是三元组质量抽样。从 Neo4j 里随机导出 250 条关系，逐条回原文比对，记录“实体边界正确”“关系判断正确”“两者都错”三类数目，算出人工校验正确率。项目文档里的验收数据显示，修正后的数据集上正确率约为 86%。答辩时被问到“图谱准不准”，直接给出这个数字和抽样方法，比空谈模型效果更有说服力。

第二步是图谱完整性验证。用三条 Cypher 快速统计节点数、关系数、孤立点数：

MATCH (n) RETURN labels(n) AS label, count(*) AS num; MATCH ()-[r]->() RETURN type(r) AS rel, count(*) AS num; MATCH (n) WHERE NOT (n)--() RETURN count(n) AS isolated;

前两条看规模与预期一致，第三条看孤立点：如果孤立点占比超过 5%，说明关系抽取遗漏较多，要么补数据、要么在清洗环节把没有连接到任何实体的节点过滤掉。演示时打开 Neo4j Browser 跑一遍这三条，图谱结构一目了然。

第三步是演示环境预设。浏览器只保留一个标签页，预留 4G 以上内存给 Neo4j 和 Flask 进程；关闭 Neo4j Browser 自动刷新；前端页面的查询框预填“歼-16”这类实体关系丰富的装备名，一打开页面就有图可看。我自己的习惯是每次答辩前都强制走一遍“清空旧数据 → 重新导入 → 抽查 50 条 → 接口连通 → 页面渲染”的全流程，不跳过任何一步，因为任何一环在演示现场出事都没有后悔药。这套习惯替我挡掉了好几次现场翻车，希望也能帮到你。

本文还有配套的精品资源，点击获取