最近在做知识图谱相关的东西，团队里落地了一个基于Qwen3的实体关系抽取管线，把一堆非结构化文档（技术方案、故障报告、产品需求）自动转成了结构化三元组。整个过程踩了不少坑，也整理出了一套能直接复用的方法。这篇就围绕“用Qwen3抽知识图谱”这件事，把设计思路、Prompt写法、代码管线、常见问题一次说清楚，适合正在做NLP抽取、知识库构建、语义搜索或者文档结构化的同学参考。
1. 为什么我改用大模型抽知识图谱
先说个背景：知识图谱的价值在于把分散的实体和关系组织成网络，方便做问答、推理、可视化分析。但真正卡住落地的从来不是图数据库选型，而是“数据怎么进去”。以前想从一个文档库里捞实体和关系，基本得靠命名实体识别加关系分类模型，这一套下来，效果和成本都挺感人。
1.1 传统抽取方案的三大痛点
过去我们用的是基于深度学习的序列标注方案，比如用BERT系的模型做NER，再用一个分类器判断实体间的关系。这套路本身没错，只是放到真实业务里处处别扭。
第一，标注数据永远是瓶颈。我们当时为了抽“设备故障原因”这类关系，硬是让业务专家标了两千条工单，标完一算，告警信息里的说法五花八门，不够模型泛化的。标注的本质是把人类对语言的理解固化成标签，而成千上万的领域表达方式，根本不是几千条样本就能覆盖的。
第二，模型定死了关系的边界。传统关系抽取在上游定义关系类别时就锁死了，比如“影响”“导致”“包含”这几种。但业务方跑来说“我还想看供应商和备件之间的关联，能不能加上”，你就得重新标数据、重新训练，一个迭代周期按周算。知识图谱本身是动态演进的，schema一变，模型就要回炉，这在现在的业务节奏里几乎不可接受。
第三，长尾实体表现极差。我印象很深的一次，文档里写了“二号机组西北侧第三个冷却风扇”，传统的NER把“二号机组”抽出来了，“冷却风扇”也抽出来了，但“西北侧第三个”这个位置修饰信息直接丢了。可这种限定恰恰是知识图谱里最有价值的约束条件。
其实说白了，传统方案适合“高度受控的领域、稳定的schema、大批量样本”，而真实业务里大多是不受控的表达、老变的schema和稀缺的标注样本，这就是我们转向大模型直接抽取的核心理由。
1.2 Qwen3带来的是什么
Qwen3聪明的地方在于，模型本身对语言的泛化能力已经够强了，你只要把“抽取规则”用自然语言描述清楚，再给它几个例子，它就能按你的规则从文本里把实体和关系捞出来，而且可以随时调整。
只需要使用通用的能力，Qwen就表现得比我们之前用BERT系模型更适用。Qwen3的优势不止是单点能力提升，而是工程上确实好用：
- 上下文长度宽裕，处理长文档省心。我们经常要抽上千字的检修报告，老方案是先做窗口滑动再做拼接去重，Qwen3基于更大上下文窗口可以整段处理，逻辑关系不容易断。
- 思维链机制应对复杂抽取更稳定。关系抽取牵涉到“先找实体、再看实体间有没有描述性关联、再判断关系类型”，这类需要推理的任务，Qwen3的慢思考模式能显著降低漏抽和误抽。
- 工具调用和结构化输出自然。我们最终要把结果转成JSON导入图数据库，Qwen3可以直接按schema输出JSON，少了解析和清洗的脏活。
1.3 什么场景适合用、什么不适合
结合我们自己的实践，判断一个场景适不适合用LLM抽知识图谱，主要看三点：样本量、schema变动频率、实体复杂性。
适合的场景：
- 冷启动构建：没有标注数据、没有已有图谱，纯靠LLM从零抽一个可用图谱。
- 文档规模中等（几千到几十万篇），对成本不太敏感。
- 关系类型经常扩展，想通过改Prompt快速迭代。
不适合的场景：
- 海量数据 + 低预算 + 高吞吐需求（比如每天处理几千万条日志，LLM才力成本扛不住）。
- 对精度有极苛刻要求，且关系类型非常固定，这时候传统小模型加规则反而更稳。
- 短文本高频抽取，比如每句话都要抽一遍，LLM的延迟优势体现不出来。
我们的经验是：LLM抽取的主力价值在于“把非结构化文本变成有结构的三元组”，而不是陪跑每一次高并发查询。如果在抽取阶段做了清洗和去重，把结果固化成图数据库，后续就不用在每个查询上都调用LLM，成本是可控的。
2. 抽取方案的前期设计，顺序比编码更重要
很多朋友一上来就直接写Prompt让模型输出JSON，试两轮发现效果不稳定，就开始调温度、换模型版本，这是没抓住本质。LLM抽取知识图谱的关键在于“先定本体，再写Prompt”。
2.1 先定Schema，再谈抽取
本体（Ontology）是知识图谱的骨架，明确规定了“有哪些实体类型”和“有哪些关系类型”。先定这个，Prompt才能写得具体，模型也才知道该抽什么。没有schema约束的大模型抽取，会产出大量信息冗余的乱图，吃力不讨好。
举个例子，处理“设备事故报告”这个场景：
实体类型我定了：
RepairOrder（工单） Equipment（设备） FailureMode（故障模式） Staff（维修人员） Cause（故障原因） Material（备件）关系类型：
REPORTS（工单 报告 设备） HAS_FAILURE_MODE（设备 具备 故障模式） REPAIRED_BY（设备 由 人员维修） USES_MATERIAL（维修单 使用 备件） ATTRIBUTED_TO（故障 归因于 原因）这里有个关键心得：schema的粒度决定抽取上限。太细导致模型频繁误判，太粗导致图谱表达力变弱。我们的标准是——关系必须能回答业务问题。比如业务想查“哪种备件换下来后故障率最高”，那“使用备件”和“归因于原因”是必抽的，其它花活先不碰。
2.2 Prompt模板的设计原则
schema定了之后，Prompt就不能随意写了。我的模板分四块：任务说明、schema定义、输出格式、Few-shot示例。四个缺一不可。
任务说明的关键词是“抽取”和“不得臆造”。我会明确写：“你是一名信息抽取专家，请从文本中抽取所有符合schema的实体和关系，不要添加文本中不存在的内容。”
schema部分必须严格写，注意是“严格”。我之前试过给模型“宽松的schema描述”，比如“找出故障相关的设备和原因”，结果模型把“环境温度高”也抽成了故障原因，抽了一堆假节点。后来改成枚举类型和关系，问题就减少了。
输出格式我最推荐JSON Lines或一个JSON数组。每个三元组用{head, relation, tail}的结构。不要用自然语言输出，除非你想在解析上再多写50行代码。
Few-shot示例我给三条：正例两条，反例一条。正例告诉它怎么抽，反例告诉它边界在哪。比如抽“原因”时不把现象也当成原因：
正例：“变频器过压跳闸，原因可能是电网波动。”
{"head": "变频器过压跳闸", "relation": "归因于原因", "tail": "电网波动"}
反例：“变频器过压跳闸，指示灯亮了。” 不抽“指示灯亮了”作为原因，因为它只是现象，不是原因。
2.3 关于幻觉，必须提前打预防针
LLM抽取最大的问题是幻觉——文本里没有的东西，它凭概率补出来了。补充的实体和关系听上去很合理，但会让下游的图谱产生大量脏数据。
我们的应对方式：在Prompt里强制加一句约束“只从输入文本中抽取，不要补全或联想”。但这只能减少，不能根治，真正有效的还是后置校验。在后文中会讲到怎么用规则和模型双重校验，把幻觉过滤掉一大半。
除此之外，我建议在schema里加一个source_span字段，让模型输出它在原文中找到的文本片断。这个字段有两个作用：一是便于人工核对，二是后续可以用BM25或向量检索做回源校验，判断这段内容是否真的在原文里出现。这比直接信模型输出靠谱得多。
3. 实操：搭建一条可用的抽取管线
纸上谈兵完了，这里给大家一条可以直接落地的参考管线。我们用Python做胶水语言，调用Qwen3的API，批处理本地文本，最终把三元组写成JSONL并导入图数据库。
3.1 环境准备与基础调用
这部分不复杂，关键是选对参数。API调用上我推荐使用兼容OpenAI格式的SDK，能少记很多原生接口的细节。
实测下来这几个参数对抽取稳定性的影响最大：
temperature=0.1（低温度，减少随机性，抽取不要创造性）max_tokens按需开足，抽取复杂文档时输出可能很长，截断叫天天不应response_format={"type": "json_object"}（限定输出JSON，解析省心）
3.2 核心抽取函数
封装一个extract_kg函数，输入文本，输出三元组列表。核心代码如下：
import json from openai import OpenAI client = OpenAI( base_url="https://your-endpoint", api_key="your-api-key" ) SYSTEM_PROMPT = """ 你是一名信息抽取专家。请从用户提供的文本中抽取知识图谱三元组。 只允许抽取以下实体类型和关系类型： 实体类型: RepairOrder, Equipment, FailureMode, Staff, Cause, Material 关系类型: - REPORTS: RepairOrder -> Equipment - HAS_FAILURE_MODE: Equipment -> FailureMode - REPAIRED_BY: Equipment -> Staff - USES_MATERIAL: RepairOrder -> Material - ATTRIBUTED_TO: FailureMode -> Cause 规则: 1. 只从文本中抽取实体，不要联想或补全。 2. 关系必须符合上述类型定义，不要在关系里表达额外的动作。 3. 输出格式为JSON对象，包含一个"triples"数组，每个元素是{"head": str, "relation": str, "tail": str}。 4. 如果某一实体没有对应关系，可以省略。 示例: 输入: 变频器过压跳闸，原因可能是电网波动，由王师傅完成检修。 输出: {"triples": [ {"head": "变频器过压跳闸", "relation": "ATTRIBUTED_TO", "tail": "电网波动"}, {"head": "变频器过压跳闸", "relation": "REPAIRED_BY", "tail": "王师傅"} ]} """ def extract_kg(text: str) -> list[dict]: resp = client.chat.completions.create( model="qwen3", temperature=0.1, response_format={"type": "json_object"}, messages=[ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": text[:4000]} # 分块策略见3.3 ] ) content = resp.choices[0].message.content data = json.loads(content) return data.get("triples", [])这里有个细节，text[:4000]分块不是拍脑袋定的，而是结合上下文窗口和成本折中出来的。对大部分工单、事故报告来说，4000字能覆盖完整事件描述，超过这个长度再切成多块，块与块之间保留50字重叠，避免实体被拦腰截断。
3.3 批处理与断点续跑
真实业务里文本量不是一条两条，而是上万个文档。这时必须考虑批处理和断点续跑。不要一口气全部放进内存，而是做成输入文件 -> 逐条处理 -> 追加写入的模式。
import json from pathlib import Path def process_corpus(input_dir: Path, output_jsonl: Path): out_handle = open(output_jsonl, "a", encoding="utf-8") for doc_path in input_dir.glob("*.txt"): text = doc_path.read_text(encoding="utf-8", errors="ignore") try: triples = extract_kg(text) record = { "doc_id": doc_path.stem, "triples": triples } out_handle.write(json.dumps(record, ensure_ascii=False) + "\n") out_handle.flush() # 写完即刷盘，避免中途挂掉丢数据 except Exception as e: print(f"[ERROR] {doc_path.name}: {e}") out_handle.close()flush()这步很关键。有一次我们处理到三千多篇的时候进程挂了，发现前面琐碎数据全没写上，因为没及时刷盘。后来改为逐条flush，重续时从已有的输出行了数，跳过已处理文档，基本不浪费时间。
3.4 结果落地与校验
抽取结果不能直接进图数据库。我们内部一般做三级校验：
第一级是JSON结构校验，保证每条三元组都是head/relation/tail三件套。
第二级是schema合法性校验，把所有relation映射到已定义的关系列表，不在列表里的丢弃。这一步能清掉模型脑补出来的关系，我们的经验是掉这个比例在3%-8%之间，别嫌麻烦，一定要做。
第三级是空值过滤。实践中发现，模型偶尔会输出"head": ""或者"tail": "无"这种垃圾三元组，直接过滤掉就好。
校验完之后，再写入Neo4j或其它图数据库。如果还没有图数据库，也建议先写JSONL存档，后面想怎么玩都行。
4. 踩坑记录与性能优化，这些经验花了不少代价
实操过程中我们碰到的问题不少，按出现频率和破坏力排序，以下几个方面最值得留意。
4.1 常见问题速查表
| 问题 | 表现 | 原因 | 解决 |
|---|---|---|---|
| JSON解析失败 | 模型输出附加了多余文字，或者截断导致不完整 | 上下文太长，输出超限，没限定json格式 | 使用response_format约束；文本分块；增加max_tokens |
| 幻觉实体 | 输出里出现原文没有的实体 | 模型联想补全 | 系统提示强约束；加source_span字段回源校验 |
| 实体边界错 | “变频器”抽成“变频器过压” | 未加边界指令、schema不清晰 | 在Few-shot里注明实体往往是最小名词短语，不要带修饰 |
| 同义重复 | “王师傅”和“维修工老王”同时存在 | 缺乏实体对齐 | 后续做别名归并，或用同一规则做同义词合并 |
| 关系错置 | “由A检查”抽成“检修到A” | 文本表达复杂，模型理解错误 | Few-shot示例补充复杂句式；降低temperature |
| 长文本信息丢失 | 文档后半部分的三元组漏抽 | 文本太长、模型注意偏斜 | 分块加重叠窗口，逐块抽取再合并去重 |
4.2 同义实体对齐的两种思路
这是建图谱时最容易被低估的问题。“薛工”“薛师傅”“薛维保”可能指的是同一个人，但模型不会自动帮你合并。不做对齐，图谱里会出现几十个悬空节点，关系根本串不起来。
我们实验过两种方案。方案一是基于规则+词典匹配，适合名字规范化较好的场景，比如“王师傅”写成“王师傅”固定格式。方案二是用向量相似度做聚类，把每个实体用Embedding编码，再按相似度阈值归并，适合别名比较散的情况。
需要注意的是，阈值不能拍脑袋设。我们试过0.85的阈值，误合并率偏高，把两台不同型号的设备并到了一起。后来改成0.93，误合并少了，但同义实体漏网增多。工程上的取舍是：宁可漏合并，也不要错合并。因为漏合并导致的冗余节点可以通过图谱可视化人工发现，而错合并会直接污染关系链条，非常难洗。
4.3 成本与性能的平衡策略
大模型抽取的成本大头在输入token。一篇1000字的文档，按token估算大概1500到2000token，如果抽几十万篇，成本是很可观的。我们的做法是分三档分流：
第一档：用规则或轻量模型先捞明显实体（比如工单号、日期、设备编号），这种高置信度的内容直接入库，不浪费大模型算力。第二档：对真的很复杂的语义关系，才交给Qwen3抽取，这部分通常只占数据量的三到五成。第三档：反复调用模型仍失败的低置信度文本，直接转入人工标注队列，不要无限重试。
重试机制本身也是成本黑洞。我们限定了每条文本最多重试一次。因为大多数抽取失败是文本本身表达不清，再试几次意义不大，重试只会拖慢整体进度。
4.4 从结果反推Prompt迭代
这里的经验是：把模型输出的错误case收集起来，每周做一次“错误复盘”，然后针对高频错误修改Prompt。比如我们发现早期模型经常把“张三说设备正常”抽成“设备正常”，还补了一条“张三确证设备正常”的关系。复盘后我们在Prompt里加了规则：只抽事实性关系，不抽言语行为类关系。修复后这类错误大幅下降。
这个迭代流程建议写进团队规范，比临时调Prompt可重复得多。配合source_span字段，复盘时能快速定位模型在原文中抽取的哪个片断，改起来精准很多。
5. 这个东西还能怎么扩展
跑通基础管线之后，后续还能往几个方向做深，简单说两个我们正在尝试的。
第一个方向是“增量更新”。图谱不是建一次就永远不变的，每周都有新的工单和报表进来。我们做了一个轻量方案：新旧文本向量化后做相似度去重，只对新出现的文本走抽取流程，已有图谱中高置信度的部分不再重复抽。这能省不少成本。
第二个方向是“小模型蒸馏”。Qwen3抽取效果虽好，但每次调API的成本和延迟不适合某些实时链路。我们正在把一批高质量抽取结果当作训练数据，用来微调一个小参数模型。目标是把常见关系类型的抽取快速转移到本地小模型上，大模型只处理冷启动和难样本。这个方向还在验证中，目前看效果取决于训练数据的多样性，但思路值得一试。
最后分享一个个人习惯：做这类任务，不要一开始就把目标定为“全自动、零人工”。更实际的路径是“先让模型抽，再用规则和人工抽查兜底，最后固化成稳定的抽取模板”。知识图谱本身是越用越准的资产，前期花时间打磨schema和Prompt，后面每次增量抽取都会越来越省力。这套基于Qwen3的抽取管线，目前在我们团队已经从实验走向了常态化运行，希望这篇整理也能让你在构建知识图谱的路上少踩几个坑。
