简介面向民航业知识图谱的自动问答系统Python项目是一套完整的学习与实战资源适合对知识图谱、NLP问答感兴趣的Python开发者也适用于民航业信息化人员参考。项目覆盖数据获取、预处理、实体识别与关系抽取、图谱构建、知识存储与查询、自动问答等关键环节借助BeautifulSoup、Scrapy、NLTK、spaCy、Neo4j及SPARQL等技术完整展示了从民航数据到智能问答落地的过程通过可运行代码演示了各技术栈的集成方式。压缩包共76个文件以28个Python脚本、13个HTML页面、12个TXT文档、12张PNG示意图、4个Jupyter Notebook为主另含JSON、CSS、JS、MD说明与license文件整体仅4.16MB目录按web、data、doc、lib等模块划分便于定位和学习。已有205人学习下载资源内包含可运行的问答系统、问题分类与答案搜索代码、测试问题及说明文档适合作为课程设计或毕业设计的直接参考尤其适合希望快速上手民航业知识图谱问答系统的读者。1. 民航业自动问答系统的数据难点在知识图谱不在算法民航业每天被问得最多的十个问题答案散落在航班计划、机场资源、收益系统和工单记录里几点起飞、登机口在哪儿、行李怎么转运、能不能中转、延误多久。这些数据格式、时效和口径都不一样航班动态还是分钟级变化通用大模型回答不了私域实时数据纯搜索又会返回一堆无关条目。因此更可靠的路线是先把民航业务做成知识图谱把航班、机场、航司、机型和旅客服务规则之间的关系存成图数据再用python实现意图识别、实体识别和Cypher查询生成让系统直接回答“CZ3121从哪里起飞、几点落地”这类问题。下面按这个落地顺序展开适合做民航、物流、交通行业问答系统的数据工程师、NLP工程师和后端开发前提是你已经装好python环境并且在vscode里配置完python调试入口。2. python构建民航知识图谱本体、实体抽取与Neo4j落库知识图谱问答和关系型数据库问答的区别在于图结构天然适合多跳检索。民航领域里“航班、机场、城市、航司”之间就是一张大网最短路径计算、邻接查询在属性图上的表达比SQL直观得多。python生态里构建端只需要做好两件事把业务对象抽象成本体把清洗后的数据通过Py2neo写进Neo4j。2.1 民航知识图谱的本体设计拆到几层最合适本体的粒度决定问答系统的上限。民航业务按旅客视角和运行视角切分常见做法是建六个核心类型City、Airport、Airline、Flight、Aircraft、ServiceRule。每个类型下再挂属性比如Flight的属性包括flight_no、plan_dep_time、plan_arr_time、status、gateAirport的属性包括name、code、city。下面这张表是一个最小但能跑通问答的本体清单实体类型关键属性常见关系数据来源CitynameHAS_AIRPORT城市表Airportname, code, cityLOCATED_IN机场表/系统字典Airlinename, codeOPERATES航司表Flightflight_no, dep_time, arr_time, status, gateDEPARTS_FROM / ARRIVES_AT航班计划Aircraftmodel, seatsUSED_BY机型表ServiceRulerule_type, content, apply_scopeAPPLIES_TO业务规则库第一次做民航图谱的人很容易把“航站楼、登机口、行李转盘”全部建成节点结果图谱膨胀到几百万节点回答“CZ3121几点起飞”反而要走四五跳。拆不拆的判断标准很简单这个属性会不会单独成为问题的查询起点。用户会问“T2在哪里”不会问“A320座位宽多少”。登机口、航站楼就作为Flight和Airport的属性保留。2.1.1 动态查询需求对应的边设计边要和问题一起建。民航系统里查询集中在四个方向航班维度的起降信息、机场维度的大屏状态、航司维度的运力分布、规则维度的服务条款。推荐关系集合为DEPARTS_FROM、ARRIVES_AT、OPERATED_BY、USED_BY、LOCATED_IN、APPLIES_TO。这里不要重复建反向边Neo4j查询时可以指定方向反向遍历减少存储冗余。在建边的时候就要想到MERGE操作。批量导入时同一个航班节点会被多条关系反复引用没有唯一约束就会产生重复节点后续问答匹配会同时命中多个实体。给Airport的code、Flight的flight_no建唯一约束是落库前必做的一步。提示Neo4j 5.x的项目里我把唯一约束直接写在启动脚本里4.x版本语法略有差异迁移时留意约束写法。2.2 用pandas清洗机场与航班数据并抽取三元组不管数据来自CSV还是接口拿到手的第一件事是清洗。航班数据的常见脏数据类型有JSON字符串被当成多列、时间格式不统一、机场名称混用简称。清洗后的目标是得到一张张三元组subject、predicate、object。下面这份代码处理的是最典型的脏数据时间格式混乱、航班号带空格、机场字段为空。import pandas as pd import numpy as np flights pd.read_csv(flights_raw.csv, dtype{flight_no: str}) flights[flight_no] flights[flight_no].str.strip().str.upper() flights flights[flights[flight_no].str.match(r^[A-Z]{2}\d{3,4}$, naFalse)] # 时间统一成 HH:MM:SS for col in [plan_dep_time, plan_arr_time]: flights[col] ( flights[col] .astype(str) .str.replace(r[^\d], , regexTrue) .str.slice(0, 6) .pipe(lambda s: s.str[0:2] : s.str[2:4] : s.str[4:6]) ) flights flights.replace(nan, np.nan).dropna(subset[dep_airport, arr_airport]) triples [] for row in flights.itertuples(): triples.append((Flight: row.flight_no, dep_from, Airport: row.dep_airport)) triples.append((Flight: row.flight_no, arr_at, Airport: row.arr_airport)) triples.append((Flight: row.flight_no, plan_dep_time, row.plan_dep_time))str.replace(r[^\d], , regexTrue)会把“2024-08-01 10:30:00”删成“20240801103000”所以后面用slice(0, 6)截取时分秒字段。真实数据里时间字段经常混入日期先做字符串清洗再截断比直接pd.to_datetime更抗脏数据。字段名统一全小写下划线否则后面写Cypher时参数大小写不一致bug很难肉眼发现。正则解决不了所有问题。机场名、城市名这类有枚举范围的字段需要在清洗阶段做实体对齐把“白云机场”映射到标准代码CAN。这一步放到NER阶段也能做但在清洗阶段做一次字典映射能极大减少图谱中的冗余节点。2.3 用Py2neo批量把图谱实体写入Neo4j写图库用Py2neo的Graph和事务。策略是先创建唯一约束再分批MERGE节点最后建立关系。不要一次把上万条关系放在一个事务里Neo4j单个事务过大容易出现堆内存溢出按500到1000条提交一批是行业内的常见做法。from py2neo import Graph, Node, Relationship graph Graph(bolt://localhost:7687, auth(neo4j, your_password)) graph.run(CREATE CONSTRAINT airport_code IF NOT EXISTS FOR (a:Airport) REQUIRE a.code IS UNIQUE) graph.run(CREATE CONSTRAINT flight_no IF NOT EXISTS FOR (f:Flight) REQUIRE f.flight_no IS UNIQUE) tx graph.begin() for row in flights.head(100).itertuples(): dep Node(Airport, namerow.dep_airport_name, coderow.dep_airport) arr Node(Airport, namerow.arr_airport_name, coderow.arr_airport) flt Node(Flight, flight_norow.flight_no, plan_dep_timerow.plan_dep_time, statusSCHEDULED) tx.merge(dep, Airport, code) tx.merge(arr, Airport, code) tx.merge(flt, Flight, flight_no) tx.merge(Relationship(flt, DEPARTS_FROM, dep)) tx.merge(Relationship(flt, ARRIVES_AT, arr)) graph.commit(tx)tx.merge(entity, label, key)是关键第一趟先创建机场和航班节点key分别是code和flight_no第二次再merge关系。即使脚本运行两遍也不会产生重复节点和重复边。很多生产事故都源于同一趟事务里先create节点再create关系导致大批重复边。需要特别纠正一个建模错误不加日期的flight_no不适合做唯一键。当日航班变成历史数据后同一条flight_no第二天会重复出现。民航动态数据要带上业务日期作为复合键比如flight_no flight_date上面约束也要改成复合属性键。这是从“演示可用”走向“生产可用”必须补的一步。2.4 为什么民航问答选属性图而不是RDF知识图谱领域经常把Neo4j和RDF三元组库放在一起比较。RDF适合跨机构、强语义推理的公开数据有OWL推理能力民航企业内部问答更依赖低延迟和灵活的条件匹配属性图模型更合适因为节点上可以直接挂JSON对象。航班状态、登机口这类属性高频变化在属性图上用MERGE更新一个属性就是一条语句的事RDF则要吃SPARQL和专门的推理规则链。对python团队来说Neo4j驱动成熟与pandas、FastAPI的衔接成本低于任何RDF存储。3. 自动问答系统的图谱查询链路与python实现图谱建好之后问答系统要解决三个问题用户这句话想问什么、句子里的实体对应图中哪个节点以及如何把自然语言翻译成Cypher并组装答案。这是经典Pipeline。民航领域问题固定一种可靠的做法是“意图识别用规则与统计打分实体识别用词典与少量标注样本查询生成用模板”。这个方向能快速交付可演示系统也方便后面逐步替换为模型。3.1 意图识别用规则模板而不是训练模型民航问答的意图数量远小于开放域问答。先在代码里定义意图flight_info查询航班信息airport_info查询机场信息airline_info查航司运力route_info查航线和中转regulation查服务规则smalltalk是闲聊兜底。分析会话日志会发现flight_info和airport_info占了八成以上冷启动阶段根本不需要训练意图分类模型。INTENT_RULES [ (airport_info, [机场, 航站楼, 大屏, 延误]), (flight_info, [航班, 起飞, 到达, 登机口, 几点]), (route_info, [航线, 中转, 经停, 怎么飞]), (airline_info, [航空公司, 准点率, 运力]), (regulation, [行李, 退改签, 服务, 规定]), ] def detect_intent(text: str) - str: base {flight_info: 0, airport_info: 0, route_info: 0, airline_info: 0, regulation: 0} for word in [航班号, CZ, MU]: if word in text: base[flight_info] 2 for intent, keywords in INTENT_RULES: for kw in keywords: if kw in text: base[intent] 1 return max(base, keylambda k: base[k]) if any(base.values()) else smalltalk这里的关键是优先级设计“CZ3121”这种航班号直接给flight_info加2分避免“航班几点到广州机场”因为同时命中“航班”和“机场”而落到airport_info。生产环境里容易犯的错误是关键词权重平均应该按业务优先级调整权重。规则缺点是扩展性差优点是可解释、可枚举。等积累到一万条带人工标注的客服会话再把detect_intent替换成FastText或BERT文本分类保持接口不变即可。3.1.1 意图识别结果如何影响流程一句“飞机延误了行李怎么转运”会同时命中flight_info和regulation。常见做法是在意图排序后加一个置信度规则最高分和次高分差小于等于1时进入多意图分支。两个查询分别执行再按“行李”“转运”等词合并答案。这种工程处理方式比调单个模型更值得投入。3.2 用LAC做命名实体识别并加载民航词典民航专有名词让通用NER很头疼航班号、机型A320、机场三字码CAN都像乱码。我用LAC做底座再挂民航词典。LAC的词典定制不需要训练把词表按行写到文本文件即可词典内容长这样CZ3121 n_f 航班号 广州白云机场 n_a 机场 白云机场 n_a 机场别名 CAN n_a 机场代码 A320 n_t 机型from LAC import LAC lac LAC(modelac) lac.load_customization(civilav_dict.txt) # 两列词 词性 def extract_entities(text: str): words, tags lac.run(text) entities [] for i, (word, tag) in enumerate(zip(words, tags)): if tag in (n_f, n_a, n_t, n_c, n_al): entities.append({text: word, type: tag.split(_)[1]}) return entities关键参数是modelac默认就是这种词法分析模式返回词列表和词性列表。词典用Tab制表符分隔词频高的实体放前面避免长词被拆开。词典不需要贪大机场库加城市库控制在几千行就够用大了会影响分词速度交互问答每轮多出几十毫秒都很难受。需要注意“白云机场”和“广州白云机场”会命中两个不同词条实体识别后必须做归一化用机场三字码作为主键所有别名映射到同一个code。这一步和第2章清洗时做的实体对齐是同一套字典不要各维护各的。3.3 把问题转化为Cypher查询模板实体和意图明确后查询生成不需要模型了。下面是一组常用的“意图-查询模板”映射意图问题样例生成的Cypher模式flight_infoCZ3121几点起飞MATCH (f:Flight {flight_no:$no}) RETURN f.plan_dep_time, f.statusflight_info广州到北京航班MATCH (a:Airport {code:CAN}),(b:Airport {code:PKX}) MATCH (f)-[:DEPARTS_FROM]-(a),(f)-[:ARRIVES_AT]-(b) RETURN fairport_info白云机场今天延误多少班MATCH (f)-[:DEPARTS_FROM]-(a:Airport {name:广州白云机场}) WHERE f.statusDELAYED RETURN count(f)route_info广州怎么飞北京MATCH pshortestPath((a:Airport {code:CAN})-[:AIR_ROUTE*..3]-(b:Airport {code:PKX})) RETURN p用python做查询生成时要把模板和数据解耦def build_cypher(intent: str, entities: dict): if intent flight_info and entities.get(flight): return ( MATCH (f:Flight {flight_no:$flight_no}) RETURN f.plan_dep_time AS dep_time, f.plan_arr_time AS arr_time, f.status AS status ) if intent airport_info and entities.get(airport): return ( MATCH (f:Flight)-[:DEPARTS_FROM]-(a:Airport {code:$airport}) WHERE f.status IN [DELAYED,CANCELLED] RETURN f.flight_no, f.status LIMIT 20 ) return None模板设计有一条纪律Cypher里只允许参数$flight_no这种占位符不允许把用户输入直接拼接进查询字符串。否则用户问“广州到南京的航班”时如果把“南京”原样拼进去轻则语法报错重则引发注入风险。参数用graph.run(cypher, flight_noCZ3121)传入py2neo会安全编码。还要考虑空实体问题意图识别是flight_info但实体列表里没有航班号这时应该反问“您问的是哪个航班”而不是生成一个返回全表的查询。3.4 时间与条件对齐问答里的日期归一化民航问答里时间是最常用的条件。用户输入“今天的”“明天上午的”“八点前的航班”如果直接匹配“今天”两个字日期是会变的。处理方式是把查询先做时间归一化基于当前时间偏移生成时间区间再传给Cypher。这里最容易翻车的case是凌晨三点问“今天的航班”。用户说的“今天”是自然日从00:00到23:59如果系统按“当前时间到现在24小时”去匹配会把00:00到03:00已经飞走的航班漏掉。所以时间归一化要显式区分自然日窗口today_window和滚动窗口rolling_window字段直接叫这个名字后面的回归测试也分开断言。4. 民航图谱问答落地中的四个高频拒答与超时问题问答系统上线前看链路是通的一旦客流高峰或者数据异常日志里就会冒出一堆answerNone。追根溯源问题集中在四块实体归一化不到位、图遍历没走索引、更新机制挡住新数据、把大模型当万能兜底。4.1 实体归一化不到位导致同一机场两套节点最典型的现场事故图谱里的白云机场出现三个节点广州白云机场、白云机场、CAN各有各的id航班却挂在CAN下面。用户问“白云机场延误情况”实体识别返回“白云机场”查询走到错误节点答案是“无数据”。实体归一化应该比第2章做得更彻底。所有实体入库前统一保留canonical_name和alias数组节点长这样name:广州白云机场, alias:[白云机场,CAN,旧白云]。实体链接阶段先把文本命中alias再通过alias找到canonical名去匹配图谱。代码上只是一个dict映射难点是让“清洗、抽取、落库、查询”复用同一套字典不要各写各的。4.2 查询计划里出现AllNodesScan就必然卡问“今天有哪些航班”这类开放问题时很容易全表扫描。Neo4j的EXPLAIN能直接看到执行计划如果开头是AllNodesScan而不是NodeIndexSeek说明缺索引或谓词没命中。先把索引补齐CREATE INDEX airport_code_idx IF NOT EXISTS FOR (a:Airport) ON (a.code); CREATE INDEX flight_no_idx IF NOT EXISTS FOR (f:Flight) ON (f.flight_no); CREATE INDEX flight_date_idx IF NOT EXISTS FOR (f:Flight) ON (f.flight_date);三行索引覆盖两个高查询频次字段。flight_date索引在按日查询时特别重要机场日均出港几百个航班加上日期条件能去掉数量级候选集。每次改完索引重新EXPLAIN确认计划从AllNodesScan变成NodeIndexSeek。执行计划里常见的几种关键字用一张表说明执行计划关键字含义常见原因AllNodesScan扫描全部节点缺索引或谓词未命中NodeIndexSeek走索引定位正常表现CartesianProduct笛卡尔积忘记join条件两个孤立pattern相乘多跳查询超时的另一个常见原因是关系方向没写。Cypher中(f)-[:ARRIVES_AT]-(a)和(a)-[:ARRIVES_AT]-(f)是等价的但如果漏掉箭头方向Neo4j会按无向边遍历候选集翻倍。在模板里显式写出方向不偷懒。4.3 当日数据增量更新与图谱一致性航班计划不是一次性导入运控每几分钟同步一次。常见做法用MERGE做upsert但问题在于一条flight记录有十几个字段只更新plan_dep_time就整个重建节点会让其他字段丢失。正确做法是MERGE后只SET需要变更的字段并带版本号MERGE (f:Flight {flight_no:$flight_no, flight_date:$flight_date}) ON CREATE SET f.created_at$now, f.version0 ON MATCH SET f.plan_dep_time$dep_time, f.versionf.version1这样每次更新都留下版本差异高并发轮询时事务冲突也更容易排查。数据删除也是坑航班取消时运控系统不会删除计划数据而是把状态改为CANCELLED。图谱里取消航班仍然有效因为用户会问“CZ3121为什么取消”。更新只改属性不做DELETE。统计延误时也要把CANCELLED考虑进去否则延误率数据会失真。4.4 大模型兜底的边界能用但必须隔离泛化能力不足时可以用“规则优先、大模型兜底”的思路经NER和模板匹配后如果所有模板都没命中把原始问题连同图谱schema一起送LLM让它返回Cypher或“无法回答”。但民航数据涉及旅客隐私和运行安全需要在内部网络部署不能把对话内容传公网。无论开源自部署还是商业API都要约定输出JSON格式的Cypher并再做一层白名单校验只允许MATCH、RETURN、WITH等只读关键字禁止MERGE、CREATE、DELETE。这个兜底路径必须加日志否则每周都有模型生成错误Cypher排错像大海捞针。5. 用回归脚本和Neo4j Browser验证问答质量问答可靠性靠的是回归集不是上线前肉眼测一轮。用户不会只问“CZ3121几点起飞”这种标准句他们可能问“南航CZ3121什么时候起飞”“白云到大兴的航班几点”“明天早上广州出港的延误航班”。把这类变形问题写成测试集每次改完代码跑一遍才不会今天修好A问题、明天拆了B功能。5.1 最小回归框架只需要几十行pythonimport yaml from py2neo import Graph cases yaml.safe_load(open(qa_regression.yaml, encodingutf-8)) graph Graph(bolt://localhost:7687, auth(neo4j, your_password)) for idx, case in enumerate(cases[cases]): cypher build_cypher(case[intent], case[entities]) result graph.run(cypher, **case[params]).data() actual normalize(result) assert actual in case[expected], fcase {idx}: {case[question]} - {actual} print(idx, PASS)回归集里不仅要有标准回答还要准备负例例如“白云机场计划航班”不应该匹配到“白云山机场”。断言时用包含关系不要要求完全相等因为图查询返回列表顺序不稳定。回归环境的Neo4j数据版本要固定如果每天更新数据回归用例里的航班号尽量选择长期存在的历史航班或者每天同步更新expected规则。否则早上过、晚上失败没人分得清是代码改动还是数据变化。5.2 在Neo4j Browser里叠加执行计划和标签显示调试单条查询时Neo4j Browser的EXPLAIN和PROFILE足够直观。输入EXPLAIN MATCH ...看Execution Plan面板重点关注EstimatedRows远大于实际返回数的节点通常就是缺索引或者笛卡尔积。还有一类“图谱明明写了上百种关系页面只出现一小部分”的问题。Neo4j Browser的Graph Visualization设置里Max labels和Max relationships默认都是25所以知识图谱只显示25个标签时不是数据丢了是浏览器把显示上限截断了。在Browser设置面板调大Max labels或者在Graph右侧设置图标里改数值刷新后就能看到全部节点类型。遇到“图里怎么只有一小部分节点”先检查这里再去怀疑数据没写进去。同样的逻辑推广到问答走查每次改NER词典或Cypher模板后用回归脚本跑一遍再开Neo4j Browser点选关系路径看“广州→CZ3121→北京”这条链是否完整。链路错误时优先按关系类型计数比如MATCH ()-[r:DEPARTS_FROM]-() RETURN count(r)快速定位哪类关系没建上再回头看导入数据的那一步。本文还有配套的精品资源点击获取