简介面向高校知识图谱课程大作业及自然语言处理入门者的一份古诗词问答系统完整源码包基于Neo4j图数据库实现诗词知识存储、检索与问答。项目涵盖爬虫采集、CSV清洗与合并、实体和关系抽取、图谱构建、模型训练、问题分类与答案生成等完整环节Python脚本按功能模块拆分主线流程清晰可直接在本地环境运行调试也可作为扩展实验的起点便于对照理解知识图谱构建与问答系统的整体链路。压缩包共43个文件以11个Python脚本、11个CSV数据文件、13个TXT配置与停用词等文件为主另含模型文件、JSON词典及诗词数据整体体积仅828KB代码和数据紧凑目录结构清晰易于迁移改造或二次开发。已有298人学习下载适合作为课程设计参考、毕业设计拓展或知识图谱项目入门样例。1. 基于知识图谱的古诗词问答系统从数据建模到 Neo4j 落地的完整方案“床前明月光”是谁写的李白写过多少首含“月”的诗带有“柳”这个意象的古诗词通常表达什么情感这些看似简单的提问用传统关系型数据库做关键词匹配很容易翻车——读者想要的可能是整首诗、作者生平甚至是同类意象的横向对比。知识图谱把这些问题变成图上的路径查找诗人节点连到诗作节点诗作节点连到意象节点一个问句翻译成图查询答案就是路径上的某个节点或属性。这比全文检索更接近“理解”也比纯规则匹配更可扩展。这篇文章要拆解的是一个可落地的方案古诗词语料如何抽成实体和关系如何设计适用于 Neo4j 的图模型中文问句如何转换成句子对应的 Cypher 查询计划以及在哪几个环节特别容易翻车。我假设你手里已经有一个包含诗题、朝代、作者、正文的古诗 CSV 数据集规模大概在几千首到几万首之间——这是最常见的起步条件下面所有代码都按这个前提写。你不需要预先精通自然语言处理也不需要背熟 Cypher 的全部语法。跟着这篇文章的节奏你会得到一个能跑起来的问答服务以及一套可以继续加料的知识图谱扩展思路。2. 古诗词图谱的数据模型实体、关系与 Neo4j 建模要点2.1 古诗词领域有哪些实体类型需要建先把业务问题翻译成图结构。一首古诗至少涉及作者、朝代、诗作本体往下拆还有意象、典故、词牌、体裁这些维度。以“月”为例它既是意象节点也可以和具体诗作建立“描写了”的关系甚至能和情感标签关联。实体节点怎么定决定了后面问答能回答什么问题、不能回答什么问题。常见做法是保持 5 类核心实体作者Author、诗作Poem、朝代Dynasty、意象Image、典故Allusion。每一类实体都带少量必要属性不要贪多——例如作者节点保留“姓名、字、号、生卒年、籍贯”诗作节点保留“诗题、正文、创作年份若无则留空、体裁”。属性越少图谱越干净查询和数据维护的成本也越低。节点的标签Label就是上表中的类名属性键名统一用小驼峰或全小写下划线后面写 Cypher 时能省掉大量大小写排错的时间。Cypher 本身对属性名大小写敏感所以建图前先定好命名规范最好用一张表记下来贴在项目文档里。2.2 关系类型怎么设计从用户问题反推关系方向关系是知识图谱的灵魂也是知识图谱问答系统最容易搞砸的地方。设计关系时思考方式不是“我有什么数据”而是“用户会问什么”——先列 20 个典型问题再一个个翻译成图路径看看路径走哪个方向最自然。举几个高频问题对应的关系设计用户问“李白写了哪些诗”路径是 李白节点 —[:wrote]→ 诗作节点所以作者到诗作的关系是“李白 wrote 静夜思”方向从作者指向作品用户问“静夜思的作者是谁”路径刚好是反向用 $poem-[:wrote]-$author。问题问“静夜思里有哪些意象”路径是 诗作 —[:contains]→ 意象问“含‘月’的诗有哪些”路径反向。这种设计中关系方向并不追求绝对“正确”而是固定成一种约定查询时理解方向就永远不出错。除核心关系外还要考虑跨实体关系。例如诗人属于某个朝代诗作也有创作年代这两类信息很多时候重叠处理方式是只保留一条路径作者 —[:lived_in]→ 朝代诗作通过作者间接关联到朝代。这样问“盛唐诗人有哪些”时不需要每首诗都挂朝代节点图里也不会出现冗余的多级路径。2.3 Neo4j 图模型与前两种“错误建模”的对比不少第一次做知识图谱的开发者会陷入两种误区一种是把所有信息全塞进一个节点譬如在诗作节点里挂一个数组属性存放所有意象词这样做确实能节省查询时间但“含‘月’的诗有哪些”这类问题就必须全表扫描数组属性图数据库的索引优势完全发挥不出来另一种是把每个字都抽成节点导致图结构过度膨胀查询路线七拐八绕性能和可维护性双双崩盘。正确的方式是遵循“节点放实体、关系放语义”的原则。实体特征用属性实体间语义关联用关系。在意象这个例子里抽取时只保留有明确语义且反复出现的意象词比如“月、柳、酒、江、山、花、雪、风、雨、舟”手动维护一个意象词表即可不需要做一个通用的分词器。一个诗作节点到意象节点的关系数量控制在 38 条既能回答大多数问题又不会让图谱稀疏得没有查询价值。2.4 用 Cypher 建约束和索引数据质量的第一道防线建好模型后先别急着导数据。Neo4j 是 schema-optional 的但不等于不需要约束。给每个实体类型建立唯一性约束能防止重复导入把图谱弄脏。下面是创建约束和索引的 Cypher 语句CREATE CONSTRAINT author_name IF NOT EXISTS FOR (a:Author) REQUIRE a.name IS UNIQUE; CREATE CONSTRAINT poem_title IF NOT EXISTS FOR (p:Poem) REQUIRE (p.title, p.author) IS UNIQUE; CREATE INDEX image_name IF NOT EXISTS FOR (i:Image) ON (i.name); CREATE INDEX poem_year IF NOT EXISTS FOR (p:Poem) ON (p.year);创建约束的这段代码里poem_title用了复合唯一性约束原因是同一首诗名可能在不同朝代反复出现仅凭title无法唯一定位把author一起放进约束里才能保证数据不会串味。image_name和poem_year建的是普通索引用于后续按意象名精确查节点和按年份过滤诗作这两类查询在问答系统中出现频率极高。注意 Neo4j 5.x 版本的语法是FOR ... REQUIRE老版本则用ON ... ASSERT。如果你的数据库是 4.x这段脚本需要对应调整。建完约束后可以用SHOW CONSTRAINTS和SHOW INDEXES验证是否创建成功也可以在生产导入脚本里先跑这一段作为前置检查。3. 数据导入 Neo4jCSV 处理全流程与 Cypher 写入3.1 原始数据清洗编码、空值与字段规整古诗文数据的源头通常是爬虫得到的网页或 OCR 文本质量参差不齐。导入 Neo4j 之前必须先把 CSV 处理成标准格式否则 Cypher 里的LOAD CSV会在第几百行突然中断而且报错信息极其晦涩排查起来想摔键盘。我的惯例是用 Python 的 pandas 做三层清洗。第一层修编码统一转成 UTF-8去除不可见字符和全角空格第二层处理空值作者缺失就用“佚名”朝代缺失就用“未知”年份缺失就留空字符串而不是null避免 Cypher 里的类型不一致第三层做去重按诗题作者合在一起去重重复条目直接丢弃。import pandas as pd df pd.read_csv(poems_raw.csv, encodingutf-8-sig) # 去除正文里的换行符和多余空白 df[content] df[content].str.replace(r\s, , regexTrue) # 空值填充 df[author] df[author].fillna(佚名) df[dynasty] df[dynasty].fillna(未知) # 按诗题作者去重 df df.drop_duplicates(subset[title, author]) # 输出清洗后的文件 df.to_csv(poems_clean.csv, indexFalse, encodingutf-8)这段清洗脚本里最关键的其实是第一行encodingutf-8-sig它会在导出时自动加上 BOM 头。很多从 Windows 环境导出的 CSV 文件是 GBK 编码直接喂给 Neo4j 的LOAD CSV会乱码或报错而加了 BOM 头的 UTF-8 文件被 Neo4j 读取时表头第一列不会出现\ufeff这种隐藏前缀。正文里\s替换的作用是把多行诗句压成一行因为 CSV 的单元格如果换行在 Neo4j 导入时容易把字段切分错位。清洗后推荐顺手做一个可视化抽查比如随机打印 20 条记录看字段是否对齐这一步能避免后面把所有脏数据一股脑灌进图里。别偷懒我在这一步省过时间结果导入后查“苏轼的诗”返回了 0 条记录原因是作者名里混入了不可见的空格。3.2 MERGE 与 CREATE 的选择导入脚本的边界条件数据清洗到位后就进入真正写库的环节。导入时用MERGE还是CREATE取决于数据源是否可信。如果你每次导入的都是全量数据且已经做过应用层去重那么CREATE更快但更常见的情况是增量导入、重复执行脚本、或者多条数据指向同一个作者节点这时就必须用MERGE——它的语义是“有则匹配无则创建”天然具备幂等性。MERGE的性能比CREATE慢原因在于它要先走索引查找节点再决定是否创建。所以在导入脚本里我会根据数据规模分层处理作者和朝代这种低基数的实体全量MERGE诗作这种高基数的实体先用 Python 去重再MERGE。网络传输和事务控制也要注意默认情况下大批量写入时事务太大容易内存溢出通常按 10005000 条记录提交一次事务比较稳妥。3.3 完整的 Neo4j 导入 Cypher分步执行与错误定位清洗完 CSV 后核心导入分成四步建作者节点、建朝代节点、建诗作节点、建立关系。我用一个 Cypher 脚本把这几步串起来这样每一步出错时能快速定位是数据问题还是语句问题。// 第一步导入作者节点 LOAD CSV WITH HEADERS FROM file:///poems_clean.csv AS row MERGE (a:Author {name: row.author}) ON CREATE SET a.dynasty row.dynasty; // 第二步导入朝代节点 LOAD CSV WITH HEADERS FROM file:///poems_clean.csv AS row MERGE (d:Dynasty {name: row.dynasty}); // 第三步导入诗作节点 LOAD CSV WITH HEADERS FROM file:///poems_clean.csv AS row MERGE (p:Poem {title: row.title, author: row.author}) ON CREATE SET p.content row.content, p.dynasty row.dynasty, p.year row.year; // 第四步建立关系 LOAD CSV WITH HEADERS FROM file:///poems_clean.csv AS row MATCH (a:Author {name: row.author}) MATCH (p:Poem {title: row.title, author: row.author}) MATCH (d:Dynasty {name: row.dynasty}) MERGE (a)-[:wrote]-(p) MERGE (a)-[:lived_in]-(d);这段脚本必须放在 Neo4j 的 import 目录下执行文件路径用file:///前缀。如果你把 CSV 放在桌面上Neo4j 是读不到的——这是新手最常踩的坑。第一到第三步分别建三类节点每步都扫描整个 CSV数据量在几万行时不会太慢但如果上了几十万行建议先用 Python 把作者去重成独立的小 CSV 再导入避免反复全量扫描。第四步里wrote和lived_in都用MERGE因为同一条 CSV 可能多次匹配到同一作者用CREATE会产生重复关系。验证导入是否成功最简单的是在浏览器打开 Neo4j Browser执行MATCH (n) RETURN count(n)看节点总数再执行MATCH ()-[r]-() RETURN count(r)看关系总数。如果两个数都符合预期导入就是成功的不行的话回到这一步检查 MATCH 是否因为名称不一致而匹配为空——例如 CSV 里的“李白”和作者表里的“李白 ”带着尾随空格关系就建不出来。3.4 导入过程中的性能与内存调优导入慢的时候先确认是不是走了全表扫描。检查方式是EXPLAIN一条简单的点查语句执行计划里如果出现NodeByLabelScan说明缺少索引或约束补上之后会改成NodeIndexSeek。第二个常见是堆内存配置Neo4j 默认的堆大小对几万条数据足够但导入时如果有大量MERGE和事务提交建议把server.memory.heap.max_size调到 12 GB 后再跑否则容易出现OutOfMemoryError且日志里的提示很隐晦。还有一个容易忽略的点是 CSV 的字段顺序。LOAD CSV WITH HEADERS是按表头名取值的顺序无所谓但如果你用了不带WITH HEADERS的旧写法字段顺序就必须和 CSV 里的列顺序严格一致。项目里有人为了“性能”去掉WITH HEADERS结果列一调整整个导入就静默失败——数据进去了但字段全错位。我建议永远保留WITH HEADERS这点性能开销在数据量达到十万级之前都可以忽略。4. 问答系统的核心模块意图识别与 Cypher 生成4.1 面向古诗词问句的意图分类不靠大模型也能做得很准问答系统能不能回答好取决于意图分类和实体抽取的准确率。在古诗词这个垂直领域里问句模式其实高度收敛常见意图就 6 类查作者、查作品、查意象、查名句出处、查朝代的代表诗人、查主题词相关的诗。这些意图不需要上大模型用规则加词典就能跑到 90% 以上的准确率而且完全可控、可解释、可调试。我是这样设计意图识别层的先把问句做正则模式匹配按照“触发词优先——实体确认——参数抽取”的顺序执行。触发词表例如“作者是谁、谁写的、何人所作”映射到作者查询“含有的意象、描写了哪些景、哪些画面”映射到意象查询。匹配不到触发词时再退到关键词词典做模糊匹配最后兜底返回“无法理解”并给出示例问法。intent_rules { author: [作者是谁, 谁写的, 何人所作, 谁的作品], poem: [写了哪些诗, 代表作, 有哪些作品], image: [意象, 描写了, 哪些画面, 景物], dynasty_poet: [诗人有哪些, 代表人物, 哪些诗人], source: [出自哪首诗, 出处, 哪首诗里的], keyword: [关于, 写什么, 内容], } def detect_intent(question: str) - str: for intent, triggers in intent_rules.items(): for t in triggers: if t in question: return intent return fallback这段实现里意图匹配的顺序就是规则的优先级顺序。例如“静夜思里描写了哪些意象”会同时命中poem里的“代表了”和image里的“意象”这时image排在后面却被期待命中——实际上这题的期望结果是意象查询所以要把image规则放到poem前。规则之间的优先级就是意图判定的部分逻辑调整顺序比加新规则更能解决冲突。也有处理不了的情况“举头望明月”的下一句是什么这是名句补全不属于上述 6 类。因为问答系统的知识来源是图谱本身图谱里没存这样的上下文序列数据这类需求超出了知识图谱问答的边界需要对接全文检索引擎或大模型生成。设计系统时一定要提前跟需求方对齐“能回答什么、不能回答什么”否则验收时会被当成缺陷提一堆出来。4.2 实体识别与问题解析把“李白的静夜思”拆成三元组意图定了之后接下来要从问句里抽出实体指称。常见做法是维护一个同义词别名表通过字符串匹配或最大正向匹配来命中实体。比如“诗仙”必须映射到“李白”“东坡”必须映射到“苏轼”这些别名词条数量不多但覆盖了绝大多数古诗词问答的实体名称变体。更复杂的情况是问题里同时出现多个实体例如“李白写的静夜思里有什么意象”这里有“李白”和“静夜思”两个实体。我的处理方式是写一个抽取函数把所有命中的实体放进列表再结合意图去决定哪些参与路径构造。作者意图和作品意图都只需要一个实体做主查询意象意图则需要作者或作品 一个意象词实体之间是 AND 关系还是嵌套关系取决于具体问法。def extract_entities(question: str, entity_dict: dict) - list: entities [] for entity_type, aliases in entity_dict.items(): for alias in aliases: if alias in question: entities.append({type: entity_type, value: alias}) return entitiesentity_dict的格式是{author: [李白, 诗仙, 李太白], poem: [静夜思, 床前明月光]}。抽取顺序上先抽长词再抽短词避免“月”先被抽出导致“明月”匹配不上。匹配时要注意边界比如“望庐山瀑布”是诗名但如果问题里写“望庐山瀑布的作者是谁”“瀑布”也可能被抽成语料里的其他实体所以实体抽取后还要和同一个意图里的触发词做交叉验证确认这个词在该意图下成立。实体识别的问题在于无法覆盖用户随意的说法。比如用户输入“李白夜里想家写的诗”既没有标准实体名也没有触发词规则引擎完全失效。这个阶段不需要把准确率推到 100%一个可用方案是识别失败时返回提示语“换个说法试试比如李白写的诗有哪些”把用户的输入框变成期望格式的引导这比强行猜用户意图要靠谱得多。4.3 Cypher 模板与参数绑定问答系统的灵魂一步实体识别完成后下一步就是把“意图实体”组合翻译成 Cypher 查询字符串。这里最关键的是建立“模板 参数”的结构而不是把用户输入直接拼接进查询语句——前者安全、可复用后者容易被注入而且一旦实体名里带着引号查询会直接语法报错。cypher_templates { author: MATCH (p:Poem {title: $title})-[:wrote]-(a:Author) RETURN a.name AS author, poems_by_author: MATCH (a:Author {name: $author})-[:wrote]-(p:Poem) RETURN p.title, p.content, images_in_poem: MATCH (p:Poem {title: $title})-[:contains]-(i:Image) RETURN i.name, poems_with_image: MATCH (p:Poem)-[:contains]-(i:Image {name: $image}) RETURN p.title, } def generate_cypher(intent: str, entities: dict) - str: template cypher_templates.get(intent) if not template: raise ValueError(fUnsupported intent: {intent}) return template这里将生成的 Cypher 传给 Neo4j 驱动时参数必须用$name这种参数化形式不能用 f-string 直接拼。Cypher 的$param是参数占位符驱动会把它安全地替换成转义后的字面量杜绝注入风险同时也能利用查询缓存提升性能。生成后的模板再拼接session.run(cypher, **entities)执行得到的结果集就是答案来源。不同意图之间参数名要统一。例如作者意图和诗作意图都用$author和$title不要在这个模板里叫$name下个模板里叫$authorName统一命名方便维护也能避免参数绑定时空值的尴尬。生成流程里最容易忽略的环节是实体不存在的情况。例如用户问“杜甫写了哪些诗”图里确实没有杜甫这个作者时查询结果会是空列表这时要给出预设的兜底文案“暂无相关数据可能是语料库未收录”。这部分逻辑写在执行层而不是模板层保证所有模板的行为一致。4.4 用 Python 驱动跑通最小问答链路有了模板和参数整个问答链路就可以闭合了。我用 neo4j 官方驱动写一个最小可运行的查询执行器完整串起“问句 → 意图 → 实体 → Cypher → 答案”的流程。from neo4j import GraphDatabase driver GraphDatabase.driver(bolt://localhost:7687, auth(neo4j, password)) def answer(question: str) - str: intent detect_intent(question) entities extract_entities(question, entity_dict) if not entities: return 我没听明白请试试这样问李白写了哪些诗 if intent author and poem in [e[type] for e in entities]: cypher cypher_templates[author] else: cypher cypher_templates.get(intent) with driver.session() as session: result session.run(cypher, **{e[type]: e[value] for e in entities}) return [record.data() for record in result]这段代码里最值得注意的细节是**{e[type]: e[value]}这一行实体列表里可能有多个实体但模板需要的是author和title这样的具名参数直接展开字典就能确保参数名正确绑定。如果你的图谱里存的是中文名那么value必须和图里的属性值完全一致这一点很容易被忽略——图里写“李白 ”带着空格这里匹配“李白”就什么都查不到。执行结果是一个列表最终返回给前端展示前建议在服务层做一层格式化。作者查询返回人名诗作查询返回诗题列表意象查询返回意象词列表每一类的结果展示格式都不同统一放在一个函数里处理而不是让调用方自己解析record.data()的原始结构。服务层同时还要处理空结果的情况空列表不能直接返回给用户应该转为友好提示。这个最小链路跑通之后你的问答系统就算有了骨架。接下来真正的工作量其实都在数据侧别名表是否齐全、意象抽取是否准、模板覆盖的意图够不够多、边界问法能不能兜住。上面这四个部分每个环节都可以单独调优但它们之间的依赖关系是单向的——实体抽取的准确率直接决定 Cypher 生成的质量想跳过某一步直接得到完美问答是不现实的。5. 古诗词问答系统避坑与常见问题排查5.1 中文编码乱码与导入后查询无结果导入 CSV 后查询“李白”能匹配到节点但查询“苏轼”却返回空——这类问题往往不是查询写错了而是数据里个别字段的编码不一致。常见的原因是一个 CSV 文件混入了 GBK 和 UTF-8 两种编码pandas 统一读取时会按第一个字符推断后续的乱码字符被当作合法字符存进了图。解决方式是在清洗阶段强制指定编码并做一轮字符白名单校验。像是[\u4e00-\u9fa5]范围之外的可视字符都打印出来人工过一遍确认是繁体字还是乱码。如果在导入后发现节点名带着不可见字符可以在 Cypher 里用RETURN toHex(unicode)定位具体问题再清洗 CSV 后重新导入已经污染的数据则需要先执行MATCH (n) DETACH DELETE n清空再重灌。5.2 Cypher 查询参数类型不匹配LOAD CSV读入的所有字段默认都是字符串类型比如year字段在 CSV 里是1045在 Neo4j 里存成字符串1045和 Cypher 里用整数1045比较时返回空集。这类错误极其隐蔽因为数据看起来“有值”但查询就是查不到。解决方式是导入时显式转型toInteger(row.year)。如果你需要做年份范围查询例如“写于公元 1000 年之前的诗”转型必须在导入阶段完成不能在查询阶段每次转。如果你在导入之后才发现类型有问题可以用ALTER修改属性类型但更推荐的做法是重新执行导入脚本。5.3 关系方向搞反导致答案为空(Author)-[:wrote]-(Poem)和(Poem)-[:wrote]-(Author)是等价的但新手经常在模板里写反方向尤其是处理“某某诗的作者是谁”时误把路径写成(Poem)-[:wrote]-(Author)结果自然是空集。Cypher 里关系是有向的无向匹配要显式写成MATCH (a)-[r:wrote]-(b)但这样会丢失方向信息不推荐在问答模板里使用。排查时先在 Neo4j Browser 手动执行带方向的关系查询确认图里的关系是否正确建立。如果是导入时建错了方向更正脚本里把MERGE (a)-[:wrote]-(p)改成MERGE (p)-[:wrote]-(a)即可关系类型不需要改方向是 Neo4j 存储的一部分。5.4 别名表和实体抽取顺序造成的误匹配“月”既可能指意象“月”也可能是“明月几时有”这个作品的一部分。实体抽取按词表扫描时如果先匹配到“月”后面的“明月”就不会被识别导致查询意图偏离。解决方式是建立分层词表长词优先匹配。按字符串长度从长到短排序并且在匹配时做左右边界校验——例如“明月”左右不是汉字时才命中避免从“春江花月夜”里错误抽出“江花”这种不存在实体。这个问题在规则引擎里永远存在没有一劳永逸的解只有通过不断往词表里补充边界案例来逼近完美。5.5 Neo4j 连接超时与性能下降排查问答系统上线后偶尔会出现首次查询特别慢、后续查询正常的现象这是 Neo4j 连接池在冷启动时的建立过程。driver 默认会维护一个连接池但初次请求需要建立物理连接和鉴权耗时会比后续请求高。如果每次都慢极大可能是查询走了全表扫描。排查方式是给慢查询语句加PROFILE前缀分析执行计划看是否出现了NodeByLabelScan。如果是就在对应属性的查询上加索引如果加了索引但仍然慢检查是否在查询里对属性做了函数操作比如toLower(a.name)这类写法会让索引失效Cypher 里要用a.name $name配合预归一化数据来规避。6. 问答服务的进阶优化图谱可视化、路径解释与知识回收问答系统跑通之后最值得追加的三个能力是结果解释、知识回收和可视化辅助。结果解释是指用户搜“静夜思的作者”系统不仅返回“李白”还能返回一条可视化路径静夜思 —— wrote —— 李白让读者直观看出答案是从哪条关系上来的这种信息对使用者的信任度提升非常明显。实现方式也不复杂查询计划不变只是把最终执行的MATCH路径原样返回前端拿到路径节点和关系后渲染成图。我习惯在返回结果里加一个trail字段里面是路径上经过的节点类型、名称和关系类型这样前端不需要解析原始图数据直接渲染即可。路径解释要做得克制每个查询最多返回一条主路径别把整个图谱子图都丢出去。第二个值得做的是把用户的实际问题回收定期统计哪些问句命中了 fallback。这些问句是最宝贵的需求清单——某用户连续三次问“表达思乡的诗句有哪些”说明你缺一个“情感 → 诗作”的关系维度。把这批问题聚类后你会发现下一轮迭代方向不是优化算法而是补知识要么补关系要么补属性要么补实体词表。可视化辅助方面Neo4j Browser 自带图谱渲染可以直接用来验证模型。但面向终端用户我更建议用 Python 的 pyvis 库把查询结果导出为网页互动图几行代码就能出效果而且不依赖额外服务。示例如下from pyvis.network import Network net Network(height400px, width100%, directedTrue) net.add_node(李白, label李白, color#f66) net.add_node(静夜思, label静夜思, color#66f) net.add_edge(李白, 静夜思, labelwrote) net.show(graph.html)这段代码虽然只是静态地画了两个节点一条边但把它接上查询结果后就变成了一个可视化查询工具。节点颜色、大小可以按实体类型和关系数映射整套代码大概 200 行左右却能极大提升方案的说服力。我在做方案汇报时就靠这个可视化页面让非技术背景的人看懂了知识图谱问答系统与传统搜索的差别。走到这里整套基于知识图谱的古诗词问答系统已经具备了一个可交付项目的全部要素合理的数据模型、可复现的导入流程、够用的问答链路、明确的排错手册以及扩展方向。作为一线实践者我最大的感受是知识图谱问答的难点不在算法而在工程耐心——数据清洗、别名维护、模板迭代这些脏活累活才是决定系统好不好用的核心因素。也希望这篇笔记能让你少走几段弯路希望帮到你。本文还有配套的精品资源点击获取