简介这是一套基于知识图谱的百年党史智能问答系统项目源码面向高校计算机、人工智能、信息工程等相关专业学生及毕业设计开发者。系统采用知识图谱构建技术整合党史事件、人物关系与理论体系结合结构化数据建模、自然语言处理和深度学习匹配算法实现精准检索、多轮对话与语义推理可有效解决党史知识碎片化、问答匹配精度不足等问题。压缩包共107个文件约3.38MB涵盖Python逻辑脚本、前端HTML/CSS/JavaScript页面、模型与配置备份zbak/pyc/txt、字体图标及Bootstrap等样式资源qa_robot.html等界面文件可帮助还原问答交互流程整体目录结构清晰适合按模块逐项研读。项目已通过代码测试与功能验证现有64人学习既可作为课程实践、毕业设计的参考范例也便于在现有架构上扩展知识领域与优化问答效果。1. 为什么要把百年党史做成一棵知识图谱问答系统背后真正值钱的部分知识图谱不是炫技它是把百年党史这类强时序、强关联的领域知识从“一堆 PDF”变成“可被机器推理的结构化语义网络”的关键路径。传统的搜索引擎只能做关键词匹配用户问“XX 会议是在什么背景下召开的”你得先猜他想要的是时间、地点还是前因后果而知识图谱天然把实体和关系显式建模问句一旦解析成图查询答案的精确度远超全文检索也远好过从零训一个大模型来硬答。这套基于知识图谱的智能问答系统核心是把 SpringCloud 微服务编排和 Python 侧的 NLP 图数据库处理能力打通Python 负责实体识别、意图分类、Cypher 生成SpringCloud 负责服务注册、网关路由和接口复用。适合谁看正在做垂直领域问答、想用 Neo4j 落地知识图谱又被“到底怎么把自然语言变成图查询”卡住的后端或算法工程师。2. 知识图谱构建从半结构化史料到 Neo4j 的实体关系落地2.1 本体设计五个核心实体与四种关系如今做领域知识图谱最忌一上来就堆实体和关系最后图变得无比庞杂却没法查询。先定义一个极小的本体后续在迭代中逐步扩充字段实体类型为 persona人物、event事件、place地点、organization组织、time时间点/时间段关系类型则拆解为 participate_in人物参与事件、happen_at事件发生于地点、occur_in_time事件发生在时间、belong_to人物属于组织、related_event事件之间存在因果/承接关系。这个本体设计参考了通用百科图谱的本体范式并结合党史数据的强时序特性做了裁剪。CREATE CONSTRAINT persona_name IF NOT EXISTS FOR (n:persona) REQUIRE n.name IS UNIQUE; CREATE CONSTRAINT event_unique IF NOT EXISTS FOR (n:event) REQUIRE n.event_id IS UNIQUE; CREATE INDEX IF NOT EXISTS FOR (n:event) ON (n.year); CREATE INDEX IF NOT EXISTS FOR (n:place) ON (n.name);约束建好后数据层才有保障persona 节点按姓名唯一event 节点按 event_id 唯一。时间字段单独拎出来建索引是因为后面的问答条件里年份过滤是最高频的查询模式。注意这里我用的是 event_id 而非 event 名称做唯一约束因为事件名称在史料里存在大量别名表述拿名称做唯一键百分百会撞车。2.2 基于规则与分词标签的实体抽取流水线在垂直领域里纯深度学习的实体抽取模型效果并不比“词典 规则 词性标注”的组合好多少尤其当实体名词绝大多数是专有名词时。用 jieba 做自定义词典加载再配合正则规则抽时间短语和会议届次工程成本低且结果高度可控。import jieba import jieba.posseg as pseg import re jieba.load_userdict(data/dict/party_dict.txt) # 每行一个专名可带词频和词性 def extract_entities(text): entities {persona: [], place: [], organization: [], time: []} for word, flag in pseg.cut(text): if flag nr: entities[persona].append(word) elif flag ns: entities[place].append(word) elif flag nt: entities[organization].append(word) year_pattern r(?:19|20)\d{2}\s*年 time_matches re.findall(year_pattern, text) entities[time] time_matches return entities这段的关键是自定义词典。通用 jieba 词典对党史专名分词极不稳定比如“古田会议”会被切碎成“古田/会议”而加载用户词典之后词典中的词具有最高优先级。实体抽取完成后下一步要做实体链接——即将抽取出的“古田会议”映射为图谱中已存在的 event 节点映射规则先按名称精确匹配再把匹配不到的实体记入待人工审核表不允许静默丢弃。2.3 关系抽取与属性补齐的最短路径关系抽取在垂直领域不建议用开放关系抽取模型常见做法是设计一套事件模板表。对党史语料而言典型句式高度重复“XX 年 XX 月在 XX 地召开 XX 会议”“XX 担任 XX 职务”“XX 签署 XX 文件”把语法规则与触发词结合准确率能到 85% 以上远快过标注几千条训练集的方案。REL_PATTERNS [ (r(?Pperson某[\u4e00-\u9fa5]{1,6})担任(?Porg[\u4e00-\u9fa5]{2,20})(?:职务|一职), belong_to), (r(?Pevent[\u4e00-\u9fa5]{2,20}会议)于(?Ptime19\d{2}年\d{1,2}月), occur_in_time), ] def extract_relations(sentence): triples [] for pattern, rel_type in REL_PATTERNS: for m in re.finditer(pattern, sentence): triples.append((m.groupdict(), rel_type)) return triples正则写关系抽取的边界要提前想清楚事件名称如果超过十个字就几乎匹配不到所以在词典里要维护一个事件全名别名表。关系三元组抽出来之后直接写入 CSV再通过 py2neo 批量灌入库整个图谱构建流程不用写一行 Java。这个方案的好处是每一步产物都能人工检查坏处是模板需要持续维护但比较符合史料结构相对固定的场景。2.4 批量写入图数据库py2neo 事务批量提交逐条写入 Neo4j 的速度非常慢单条提交有网络往返开销数据量到几千条时差距极其明显。正确的做法是攒批提交每批 500 条左右用事务包裹。from py2neo import Graph, Node, Relationship graph Graph(bolt://localhost:7687, auth(neo4j, password)) def batch_write(triples): tx graph.begin() for i, (head, rel_type, tail) in enumerate(triples): head_node Node(event, event_idhead[id], namehead[name], yearhead[year]) tail_node Node(place, nametail[name]) rel Relationship(head_node, rel_type, tail_node) tx.create(rel) if i % 500 0: tx.commit() tx graph.begin() tx.commit()这里的执行原理是节点与关系在同一个事务里创建避免半途崩溃导致图里出现悬挂关系。批量写入如果拓扑有关联需要先保证头尾节点已存在否则会出现同一个实体被重复创建成多个节点这是后续所有问题的万恶之源。3. 问答解析链路把用户问句变成一条可执行的 Cypher3.1 意图识别从模板匹配到相似度兜底问答模块承接的是来自 SpringCloud 网关转发的用户问句。第一步并不是实体识别而是意图分类——我先判断用户在问“时间”“人物”“地点”“关系”“因果背景”中的哪一种。拿模板直接匹配就行因为领域问句的表达空间本来就窄大概几十个模板能覆盖绝大多数提问。INTENT_TEMPLATES { query_time: [{event}是什么时候, {event}召开时间, {event}发生于何时], query_person: [谁参加了{event}, {event}的参会人员], query_place: [{event}在哪里召开, {event}的地点], query_relation: [{person}和{event}有什么关系, {person}参与过哪些事件], } def classify_intent(question): for intent, templates in INTENT_TEMPLATES.items(): for tpl in templates: if tpl.replace({event}, .*).replace({person}, .*) in question: return intent return fallback意图模板匹配的坑在于用户问法永远超出模板因此必须留一条 fallback 路径。常见做法是接一个向量相似度召回把模板和问句都编码成向量模板库里所有模板逐一算余弦相似度取最大相似度且超过 0.7 阈值的那一个作为意图否则返回“无法理解请换个问法”。我一般用 SentenceTransformer 的中文模型做编码不用再训练效果够用。3.2 实体识别结果与意图的组合策略同样的实体在不同的意图下生成的 Cypher 完全不同。比如“1921 年召开了什么会议”实体是时间 1921意图是 query_event_by_time“谁参加了某某会议”实体是事件意图是 query_person。所以要先把整句问句做实体抽取再根据意图来组装查询语句。def build_cypher(intent, entities): if intent query_time: eid entities[event][0] return fMATCH (e:event {{event_id: {eid}}}) RETURN e.year, e.name if intent query_person: eid entities[event][0] return fMATCH (e:event {{event_id: {eid}}})-[:participate_in]-(p:persona) RETURN p.name if intent query_event_by_time: year entities[time][0][:4] return fMATCH (e:event) WHERE e.year {year} RETURN e.name这里要特别注意 Cypher 注入问题。如果实体值直接拼接进查询字符串用户输入恶意内容时会构成注入风险这在后面避坑章节专门展开。比较稳妥的生产做法是参数化查询先用 py2neo 的 run 方法把查询语句中的参数单独传递而不用字符串拼接的方式将实体写进 Cypher 语句中。3.3 模板加动态槽位的解析器封装把以上两步整合成一个解析器类对外只暴露一个parse(question) - {cypher, intent, entities}接口SpringCloud 侧依赖的就是这个极简接口不关心内部实现是规则还是模型。class QuestionParser: def __init__(self): self.templates INTENT_TEMPLATES self.encoder SentenceTransformer(shibing624/text2vec-base-chinese) def parse(self, question): intent, score self._match_intent(question) entities extract_entities(question) entities link_entities(entities) # 名称映射到图谱节点 event_id if not self._validate_entities(intent, entities): raise ValueError(关键实体缺失无法生成查询) cypher build_cypher(intent, entities) return {intent: intent, cypher: cypher, entities: entities}_validate_entities这一步容易被忽略但非常关键用户问“他是什么时候当选的”实体抽取结果可能为空此时如果不拦截生成的 Cypher 就是一个空条件的全表扫描在数据量上来之后会拖垮 Neo4j。拦截逻辑很简单——每个意图模板声明哪些槽位是必填的槽位缺失就直接拒绝生成查询。4. SpringCloud 服务化改造Python 算法模块如何融入微服务架构4.1 用 FastAPI 把问答模块包成独立服务Python 算法模块不能直接塞进 SpringCloud 的服务治理体系里但它可以是一个独立的微服务通过注册中心被网关发现。先把问答模块用 FastAPI 包一层 HTTP 接口对外暴露/qa/ask和/health两个端点。from fastapi import FastAPI, HTTPException from pydantic import BaseModel app FastAPI() class QARequest(BaseModel): question: str session_id: str default class QAResponse(BaseModel): answer: str cypher: str confidence: float 0.0 app.post(/qa/ask, response_modelQAResponse) def ask(req: QARequest): parser QuestionParser() try: result parser.parse(req.question) answers query_neo4j(result[cypher]) except ValueError as e: raise HTTPException(status_code422, detailstr(e)) return QAResponse(answerformat_answer(answers), cypherresult[cypher])FastAPI 的异步特性在这里并不产生决定性影响因为瓶颈在 Neo4j 查询耗时上但用它的 pydantic 模型做请求参数校验很适合微服务之间的接口约束。需要尤为注意的是每次请求都new QuestionParser()会导致模型重复加载部署时要改成模块级单例把 SentenceTransformer 和解析器只初始化一次。4.2 Nacos 注册中心与 SpringCloud Gateway 路由配置Python 服务要纳入 SpringCloud 的统一服务治理首推 Nacos 注册中心因为它在国内团队中使用率最高用 HTTP 接口即可完成注册不需要额外引入 SDK。Python 侧每隔 5 秒向 Nacos 发送心跳随后 SpringCloud Gateway 就能通过服务名qa-service来路由请求。spring: cloud: gateway: routes: - id: qa_service uri: lb://qa-service predicates: - Path/api/qa/** filters: - StripPrefix2 server: port: 8100路由配置将外部/api/qa/ask请求映射到qa-service下的/qa/ask接口。StripPrefix2的含义是去掉两层路径前缀即让网关把请求转发给 Python 服务时不携带/api/qa前缀。网关层在这一阶段还可以统一做鉴权与限流不需要在 Python 侧重复实现。4.3 OpenFeign 调用链与响应结构约定Java 侧调用 Python 服务直接用 OpenFeign 声明式客户端接口写得极其简洁。响应结构要和 Python 侧QAResponse严格对齐否则解析会翻车。FeignClient(name qa-service, path /qa) public interface QaClient { PostMapping(/ask) QaResponse ask(RequestBody QaRequest request); } Data public class QaResponse { private String answer; private String cypher; private Double confidence; }这里最容易踩的坑是 Python 端 FastAPI 默认响应的字段名是 snake_case如confidence而 Java 端如果用了 Lombok 的Data字段名必须完全一致。如果 Java 侧写的是confidenceScore反序列化出来的值就是 null前端拿到后还以为系统逻辑出错。接口定义好后日志爱链里使用同一个session_id贯穿整个请求后续排障效率会显著提升。4.4 Docker Compose 一键拉起整套依赖整套系统涉及 MySQL知识图谱原始数据备份、Neo4j、Nacos、Python 问答服务、SpringCloud Gateway单独手动启动非常痛苦。用 Docker Compose 把基础设施编排好开发环境一条命令搞定。version: 3.8 services: neo4j: image: neo4j:5.12-community ports: - 7474:7474 - 7687:7687 environment: - NEO4J_AUTHneo4j/password volumes: - ./neo4j/data:/data qa-service: build: ./qa_service ports: - 8200:8200 environment: - NEO4J_URIbolt://neo4j:7687 depends_on: - neo4j注意qa-service访问 Neo4j 的地址必须用容器名neo4j而不是localhost因为在 Docker 网络中每个服务有独立的网络命名空间。这个坑在本地能跑通、部署到服务器就报连接超时的场景下反复出现下文避坑章节还会重点复盘。5. 避坑指南与常见问题排查五个让系统一夜返工的真实故障5.1 服务名注册成功但网关一直 404现象Nacos 控制台能看到qa-service的实例状态为健康但网关路由到该服务的请求始终返回 404。原因网关用lb://qa-service做负载均衡但 Python 服务注册到 Nacos 时contextPath是/qa而网关路由的 Path 是/api/qa/**StripPrefix 处理后转发路径与 FastAPI 的路由前缀不匹配请求落到 FastAPI 根路径上找不到任何路由。解决把 FastAPI 的根路径前缀去掉统一让网关负责前缀剥离服务内部只暴露业务路径。我在排查时是先直接 curl 容器内的 Python 服务 IP 验证、再走网关完整链路验证两步一对比就能迅速定位是路由前缀的问题。5.2 Neo4j 中间节点大量重复导致关系错乱现象图数据库中“某会议”节点出现了十几个相同名称的 node关系散落在不同的重复节点上导致查询结果不稳定。原因批量写入时没有使用 MERGE 而用了 CREATE且实体对齐做得到位但并没有落到代码里同一个名称的实体被重复创建。解决写入前做两层去重第一层在 Python 侧用哈希集合对三元组去重第二层把创建节点的语句从CREATE改成MERGE依赖之前建好的唯一约束来合并。这个改动看似微小实际效果立竿见影——重复节点数量从上千个降到了零。5.3 SpringCloud 与 Python 服务时间超时导致前端转圈现象用户在界面输入问题后经常等待 10 秒以上才出结果偶尔直接超时。原因问句解析本身毫秒级但 Cypher 查询里存在深度不定的可变长关系路径某些查询展开成极大的笛卡尔积Neo4j 端运行耗时飙升至数秒。再加上 SpringCloud 默认的 Ribbon 超时设置偏短网关层直接掐断了连接。解决给 Cypher 查询所有可变长路径加了深度上限[*1..3]并在网关层将超时时间调至 30 秒。数据库端同时启用db.query.executiontimeout设置单条查询超过 5 秒强制终止保护整体服务可用性。5.4 中文分词在实体链接环节结果和预期不符现象“某某会议”被识别成组织或地点实体链接到图谱节点成功率为 60% 左右。原因自定义词典里没有带词性标签jieba 在词性标注时把部分专名默认标注成nt组织或ns地名导致分类错误。解决在自定义词典每一行末尾追加词频和词性标记例如“古田会议 100 nz”强制指定为专有名词词性。改完词典后实体链接准确率从 60% 提升到 90% 附近这属于投入产出比很高的低级修复。5.5 问句里有多个时间实体时取错年份现象用户问“1921 年到 1927 年之间召开了哪些重要会议”系统直接返回空结果或只按 1921 年过滤。原因实体抽取抽到两个时间实体而 Cypher 生成逻辑只取了第一个。解决解析器对时间实体做数组存储意图模板将这种包含范围语义的问句单独映射成WHERE e.year $start AND e.year $end的查询模式。问句模板的覆盖范围也因此加宽了一层在真实用户问题里这一类问题占比很高。def build_cypher_time_range(start, end): return ( MATCH (e:event) WHERE e.year $start AND e.year $end RETURN e.name, e.year ORDER BY e.year )这里的参数化写法本身就是一次很好的安全实践——参数值由驱动转义而非字符串拼接不管 start 和 end 里面有什么特殊字符都不会影响查询结构。6. 系统验证与进阶调优5000 条问答对回测和响应耗时优化的实操6.1 构造评测集做回归回测系统上线前如果只拿手工挑的 20 条问句验证上线后一定会被真实用户的问法教做人。我用半年内的真实日志整理出 5000 条问答对按 8:2 比例拆成开发集和测试集每条记录包含 question、gold_cypher、gold_answer、intent 四个字段。回测脚本逐个调用 parser 生成预测结果与标注答案对比生成指标。def evaluate(test_path): tp tn fp fn 0 for item in load_json_lines(test_path): try: pred parser.parse(item[question]) if pred[cypher].strip() item[gold_cypher].strip(): tp 1 else: fp 1 except ValueError: fn 1 precision tp / (tp fp) recall tp / (tp fn) f1 2 * precision * recall / (precision recall) return {precision: precision, recall: recall, f1: f1}回测的价值不在于算出多漂亮的分数而在于每次我改动词典或意图模板时能快速发现某个历史问题回归。例如增加一个“成立于”模板后N 条原本走 “belong_to” 意图的问句被错误引导到新模板回测能把这类隐性回归精确到个位数地暴露出来。6.2 响应耗时拆解与热点路径优化用日志中的耗时统计可以看到整个链路的瓶颈分布Python 解析服务平均耗时约 25msNeo4j 查询平均约 180ms网关转发与序列化约 20ms整体P95在 450ms 左右。这个数字在开发环境可接受但并发上来以后 Neo4j 的耗时部分会成为主要瓶颈。优化手段按收益排序依次是手段效果对 event.year 建索引时间过滤查询耗时下降约一半将高频实体与答案做成 Redis 缓存热问句查询耗时降到 10ms 以内将 Nacos 心跳间隔加大减少注册中心压力对问答链路无感知Neo4j 连接池调大并发下查询排队时间显著缩短Redis 缓存的 key 直接用规范化后的问句哈希值value 缓存解析结果与答案结果缓存过期时间设为 7 天。这样用户在同一个时间段反复问同类问题时几乎不走解析和数据库路径。6.3 结合大模型做开放问句兜底规则与模板的解析器有一个明确的边界——问句表达超出已知模板时系统会拒绝回答。为了兜住这部分流量我加了混合策略意图匹配置信度低于阈值时将问句、相关实体上下文和图的子图序列化结果拼接成提示词交给大模型总结生成答案。这种方式能用较少的成本覆盖长尾问法但绝不能替代模板解析成为主路径原因是大模型会自由发挥生成幻觉内容所以只有当 cypher 查询为空或意图置信度极低时才触发大模型来做最后的兜底。有趣的是很多用户并不知道背后有混合策略他们在界面感受到的是“这个系统比单纯搜索好用不少”。整套系统上线到现在我对图谱类项目最深的习惯变化是每次改动词典或模板之后强制跑一遍 5000 条回测集。哪怕只改了一个正则确认也没有想象中的简单。这样做的好处是心中有数不会有“应该不影响吧”之类的侥幸心理最终拿出来的数据自然也更有说服力。希望这些经验对你正在做的问答系统有帮助。本文还有配套的精品资源点击获取