从PDF到结构化知识库：工业文档的AI知识萃取全流程技术方案

摘要

工业领域的核心知识大量存在于PDF标准文件、学术论文、技术手册和老师傅口述记录中。这些非结构化文档无法直接被AI系统调用。本文给出一种从PDF到结构化知识库的完整技术方案，覆盖文档解析、实体抽取、关系构建、知识条目生成和向量化存储五个环节，附带核心代码实现和效果对比数据。该方法已在航空高温合金加工缺陷诊断等7个行业中验证可用。

一、问题定义

工业AI诊断系统最核心的资产不是模型，是知识库。但工业知识很少以结构化形式存在——它们散落在GB/T标准文件、学术论文PDF、车间操作手册甚至老师傅的口头经验里。

要让AI能准确调用这些知识，必须先完成一件事：把非结构化文档拆成一条一条可检索、可组装的知识条目。

一条知识条目，就是一个“查询条件→判断规则”的映射。比如：

• 输入“GH4169电子束焊热影响区裂纹”→输出金相判据+成因排序+排查步骤

• 输入“磨削声音高频尖叫AND火花发白”→输出“砂轮钝化，建议停机修整”

下面给出从PDF到知识条目的完整技术路线。

二、整体架构

整个知识萃取流水线分为五个环节：

PDF文档输入 → 文本解析与清洗 → 实体抽取与关系构建 → 知识条目自动生成 → 向量化存储与检索

# 知识萃取流水线核心架构 class KnowledgeExtractionPipeline: def __init__(self): self.parser = DocumentParser() # 文档解析 self.cleaner = TextCleaner() # 文本清洗 self.extractor = EntityExtractor() # 实体抽取 self.builder = RelationBuilder() # 关系构建 self.generator = EntryGenerator() # 条目生成 self.vectordb = VectorDB() # 向量化存储 def run(self, pdf_path): raw_text = self.parser.parse(pdf_path) clean_text = self.cleaner.clean(raw_text) entities = self.extractor.extract(clean_text) relations = self.builder.build(entities) entries = self.generator.generate(entities, relations) self.vectordb.store(entries) return entries

下面逐个环节拆解。

三、文档解析与文本清洗

3.1 PDF解析的选型

工业PDF分两类：原生电子文档（有文字层，可直接提取）和扫描件（需要OCR）。

对原生PDF，使用PyMuPDF或pdfplumber提取文字和表格。PyMuPDF速度快，适合大批量处理。pdfplumber对复杂表格的识别更好，适合包含大量工艺参数表的工业标准文件。

对扫描件，使用PaddleOCR做中文识别。工业文档里经常有特殊符号——比如γ′相、μm级、°C——需要确认OCR引擎对这些符号的识别率。

import fitz # PyMuPDF import paddleocr def parse_pdf(file_path): """解析PDF，自动判断原生/扫描件""" doc = fitz.open(file_path) text = "" for page in doc: page_text = page.get_text() if len(page_text.strip()) > 50: # 原生文档，直接提取 text += page_text else: # 扫描件，走OCR ocr = paddleocr.PaddleOCR(use_angle_cls=True, lang='ch') img = page.get_pixmap() result = ocr.ocr(img, cls=True) text += "\n".join([line[1][0] for line in result[0]]) return text

3.2 文本清洗的工业特有问题

工业文档的文本清洗和通用NLP不同，有三个特殊问题需要处理。

特殊符号保留：γ′相、σ相、°C、μm这些符号不能洗掉，它们本身就是关键实体。清洗规则需要设置白名单。

图表混排处理：PDF里的表格经常被解析成错位的碎片文字。需要检测文字密度突变区域，识别表格边界，用专门的表格提取模块重新解析。

多栏文档处理：很多标准文件分两栏排版，直接按行提取会把左右栏的文字混在一起。需要识别栏位边界，按栏分别提取。

四、实体抽取与关系构建

4.1 工业领域的实体类型

通用NER模型在工业文档上效果很差。“GH4169”会被当成普通数字字母组合，“γ′相”根本不在词表里。需要定义工业领域专用的实体类型。

我定义的实体类型：

4.2 基于大模型的少样本实体抽取

工业领域标注数据极少，从头训练一个NER模型不现实。现在的做法是用大语言模型做少样本实体抽取——给模型几个标注好的示例，让模型按同样的格式从新文档里抽取实体。

def extract_entities(text, model): """用大模型做少样本实体抽取""" prompt = """ 从以下工业文档中抽取实体，按JSON格式返回。 实体类型： - material: 材料牌号 - process: 工艺类型 - defect: 缺陷类型 - parameter: 工艺参数 - range: 参数范围 - standard: 标准编号 示例输入：GH4169电子束焊接后热影响区出现液化裂纹， 裂纹沿晶界分布，浇注温度需控制在980-1020°C。 示例输出： {"material": ["GH4169"], "process": ["电子束焊接"], "defect": ["液化裂纹"], "parameter": ["浇注温度"], "range": ["980-1020°C"], "standard": []} 现在处理以下文本： {text} """ response = model.generate(prompt.format(text=text)) return json.loads(response)

4.3 关系构建

实体之间的关系需要明确的工业逻辑来构建。最核心的关系链路有四种：

（材料牌号）→[进行]→（工艺类型），比如GH4169→电子束焊接。这一层把材料和工艺对应起来，后续检索时用户输入材料加工艺能精准定位知识条目。

（工艺类型）→[可能产生]→（缺陷类型），比如电子束焊接→液化裂纹。这层建立了工艺和缺陷的因果链，是推理链的基础。

（缺陷类型）→[需要检测]→（检测方法），比如液化裂纹→金相分析。这层让知识条目里的排查步骤能关联到具体的检测手段。

（工艺参数）→[参考范围]→（参数范围），比如浇注温度→980-1020°C。这层把参数和推荐值绑定。

def build_relations(entities, text): """构建实体间关系""" relations = [] # 材料-工艺关系 for mat in entities.get("material", []): for proc in entities.get("process", []): if co_occur(mat, proc, text, window=100): relations.append({ "source": mat, "target": proc, "relation": "进行" }) # 工艺-缺陷关系 for proc in entities.get("process", []): for defect in entities.get("defect", []): if co_occur(proc, defect, text, window=100): relations.append({ "source": proc, "target": defect, "relation": "可能产生" }) return relations def co_occur(entity1, entity2, text, window=100): """判断两个实体在文本中的共现距离""" pos1 = text.find(entity1) pos2 = text.find(entity2) return abs(pos1 - pos2) <= window

五、知识条目自动生成

实体和关系抽取完之后，需要把它们组装成统一格式的知识条目。

一条知识条目的核心结构：触发条件加输出内容加证据来源再加置信度。触发条件是满足什么条件时这条知识被调用，用“材料加工艺加缺陷”作为主要索引维度。输出内容包括判据和成因排序和排查步骤和工艺建议，这是AI回答时调用的实际内容。证据来源标注信息来源，是推理时判断可信度的参考。置信度标记从高到底分三级，来源是公开标准或教材的为高，来自多篇论文共同结论的为中，来自单篇论文或经验总结的为低。

大模型生成知识条目的Prompt示例：

def generate_entry(entities, relations, context): """用大模型生成结构化知识条目""" prompt = f""" 根据以下信息生成一条知识条目，严格按JSON格式输出。 实体：{json.dumps(entities, ensure_ascii=False)} 关系：{json.dumps(relations, ensure_ascii=False)} 原文：{context} 输出格式： {{ "trigger": {{ "material": ["材料牌号"], "process": ["工艺类型"], "defect": ["缺陷类型"] }}, "output": {{ "criteria": "判据描述", "causes": ["成因1（概率%）", "成因2（概率%）"], "steps": ["步骤1", "步骤2"], "suggestions": ["建议1", "建议2"] }}, "source": "信息来源", "confidence": "高/中/低" }} """ response = model.generate(prompt) return json.loads(response)

六、向量化存储与检索

6.1 为什么需要向量化

结构化知识条目存进数据库之后，需要一个高效的检索机制。用户输入的自然语言查询和数据库里的知识条目触发条件之间，不是精确匹配的关系——用户说“叶片裂了”和知识条目里的“涡轮叶片热裂缺陷”是一个意思，但字面上不一样。

向量化的作用是：把用户查询和知识条目都转成语义向量，通过向量相似度找到最匹配的知识条目。

6.2 实现方案

使用text-embedding模型做向量化，存入向量数据库。查询时先做语义匹配，再做结构化过滤。

import chromadb def build_vector_store(entries): """将知识条目向量化存入ChromaDB""" client = chromadb.Client() collection = client.create_collection("industrial_knowledge") for i, entry in enumerate(entries): # 用触发条件+输出摘要生成向量 text = json.dumps(entry["trigger"], ensure_ascii=False) + \ entry["output"]["criteria"] embedding = get_embedding(text) collection.add( embeddings=[embedding], documents=[json.dumps(entry, ensure_ascii=False)], ids=[f"entry_{i}"] ) return collection def query_knowledge(collection, user_input, n_results=3): """语义检索知识条目""" query_embedding = get_embedding(user_input) results = collection.query( query_embeddings=[query_embedding], n_results=n_results ) return results["documents"][0]

七、效果验证

用航空高温合金加工缺陷诊断的知识库构建来验证这套方案的实际效果。

八、局限性与后续优化

当前方案还有几个需要改进的地方。

复杂表格处理比较薄弱，工艺参数表、成分对照表这些在PDF里经常是多层嵌套表格，解析出来容易串行或漏列。后续考虑用专门的表格识别模型来做这块。

跨文档实体对齐问题同样不容忽视，不同文献对同一种缺陷的命名可能不一样，需要建立实体别名表做统一映射。同一种裂纹在不同来源里叫法不同，如果不做对齐，知识条目会碎片化，影响调用效率。

长文本问答的准确率下降趋势也需要正视，当上下文超过模型窗口时，检索结果可能因为排序靠前的内容占满窗口而导致有效信息被截断。后续可以考虑做知识条目的分级摘要处理，让每条条目先返回核心判据和操作建议，细节在有需要时再展开查询。

九、总结

1. 工业文档知识萃取是一个端到端的系统工程，核心是定义好工业领域专属的实体类型和关系逻辑，这是传统NLP模型做不好的地方，恰恰是大模型加结构化规则能发挥优势的场景。

2. 文本清洗不是通用NLP的简单复用，工业文档有大量特殊符号和专业术语需要保留，PDF里表格和多栏排版也给解析带来了额外难度。

3. 知识条目需要统一格式——触发条件、输出内容、证据来源、置信度——四个字段缺一不可，少了任何一环，后续的推理链组装和安全边界判定就失去了支撑。

4. 向量化检索解决了自然语言查询和结构化触发条件之间的语义匹配问题，但检索效果严重依赖文档解析和实体抽取的上游质量，上游出错下游全偏。

作者：善春（Shan Chun）| AI安全协议研究者

开源协议：SCAI-16Layers
GitHub：https://github.com/shanchun-ai/ShanchunAI_Protocol_16Layers

下一篇预告：知识库建好了，检索也跑通了，但怎么防止AI在用户问出知识库覆盖不到的问题时胡说八道？下篇讲《工业AI防幻觉设计：知识边界判定与安全熔断机制》，关注专栏不错过更新。