AI 赋能传统业务：智能文档解析与知识提取系统的工程实践

AI 赋能传统业务：智能文档解析与知识提取系统的工程实践

一、非结构化数据的困局：企业知识为什么总是"找不到"

企业内部积累了海量的非结构化文档——合同、报告、规范、邮件、会议纪要。这些文档承载着核心业务知识，但传统搜索技术只能做关键词匹配，无法理解文档的语义。当员工需要查找"去年 Q3 与供应商 A 签订的合同中关于违约责任的条款"时，关键词搜索几乎无能为力。

更深层的问题在于，文档中的知识是"锁定"在自然语言文本中的，无法被结构化查询和统计分析。一份 50 页的技术规范中，关键参数散落在不同章节，人工提取耗时且易遗漏。AI 驱动的文档解析系统，核心目标是将非结构化文本转化为结构化知识，让文档中的信息变得可查询、可统计、可推理。

graph TD
A[非结构化文档] –> B[文档预处理层]
B –> B1[格式解析<br/>PDF/Word/扫描件]
B –> B2[版面分析<br/>表格/段落/标题识别]
B1 –> C[文本提取层]
B2 –> C
C –> D[语义理解层]
D –> D1[实体识别<br/>人名/机构/日期/金额]
D –> D2[关系抽取<br/>签约方-合同-条款]
D –> D3[事件提取<br/>签署/变更/终止]
D1 –> E[知识结构化层]
D2 –> E
D3 –> E
E –> F[知识图谱/结构化数据库]
F –> G1[语义搜索]
F –> G2[智能问答]
F –> G3[合规审计]

style D fill:#e1f5fe
style F fill:#e8f5e9

二、文档解析的分层架构：从像素到知识

智能文档解析系统需要处理三类输入：原生数字文档（PDF/Word）、扫描件（图片 PDF）、以及混合格式文档（含表格、图表）。每一类输入需要不同的预处理策略，但最终都要汇入统一的语义理解管线。

文档预处理层解决"如何从文件中获取干净的文本"这个问题。对于原生数字文档，直接提取文本即可；对于扫描件，需要 OCR 识别，但 OCR 的错误率在低质量扫描件上可能高达 10% 以上；对于混合格式文档，版面分析（Layout Analysis）是关键——需要区分标题、正文、表格、页眉页脚，避免不同区域的内容被错误拼接。

语义理解层是系统的核心。传统 NLP 方案使用预训练的 NER 模型做实体识别，但领域文档中的实体类型（如合同编号、项目代码）往往不在通用模型的覆盖范围内。基于 LLM 的方案通过 Prompt 引导模型提取结构化信息，灵活性更高，但需要精心设计 Prompt 和输出格式约束。

知识结构化层将提取的实体和关系转化为可查询的结构。对于关系型数据，直接写入数据库；对于复杂的关联关系，构建知识图谱，支持图查询和推理。

三、智能文档解析的代码实现

以下实现展示了从文档预处理到知识提取的完整管线，重点关注 LLM 驱动的结构化信息提取。

import json
from dataclasses import dataclass, field
from typing import Optional
from enum import Enum

class DocumentType(Enum):
NATIVE_PDF = "native_pdf"
SCANNED_PDF = "scanned_pdf"
WORD = "word"
IMAGE = "image"

@dataclass
class ParsedDocument:
"""解析后的文档结构"""
doc_id: str
doc_type: DocumentType
sections: list[dict] = field(default_factory=list)
tables: list[dict] = field(default_factory=list)
metadata: dict = field(default_factory=dict)
raw_text: str = ""

@dataclass
class ExtractedEntity:
"""提取的结构化实体"""
entity_type: str # 实体类型：合同编号、签约方、金额等
entity_value: str # 实体值
confidence: float # 置信度
source_section: str # 来源章节
char_span: tuple[int, int] # 在原文中的字符位置

@dataclass
class ExtractedRelation:
"""提取的关系三元组"""
subject: str
predicate: str
object: str
confidence: float
source_section: str

class DocumentParser:
"""文档预处理与文本提取"""

def parse(self, file_path: str) -> ParsedDocument:
doc_type = self._detect_type(file_path)

if doc_type == DocumentType.NATIVE_PDF:
return self._parse_native_pdf(file_path)
elif doc_type == DocumentType.SCANNED_PDF:
return self._parse_scanned_pdf(file_path)
else:
raise ValueError(f"不支持的文档类型: {doc_type}")

def _detect_type(self, file_path: str) -> DocumentType:
"""检测文档类型：通过文本层是否存在判断原生/扫描件"""
# 简化实现：尝试提取文本，若文本量过少则判定为扫描件
text = self._extract_text_layer(file_path)
if len(text.strip()) < 50:
return DocumentType.SCANNED_PDF
return DocumentType.NATIVE_PDF

def _parse_native_pdf(self, file_path: str) -> ParsedDocument:
"""解析原生 PDF：提取文本并做版面分析"""
import fitz # PyMuPDF

doc = fitz.open(file_path)
sections = []
tables = []

for page_num in range(len(doc)):
page = doc[page_num]
# 按版面区域提取，保留位置信息
blocks = page.get_text("dict")["blocks"]
for block in blocks:
if block["type"] == 0: # 文本块
text = " ".join(
span["text"]
for line in block["lines"]
for span in line["spans"]
).strip()
if text:
font_size = block["lines"][0]["spans"][0]["size"]
# 根据字号判断标题/正文
section_type = "heading" if font_size > 14 else "paragraph"
sections.append({
"type": section_type,
"text": text,
"page": page_num + 1,
})
elif block["type"] == 1: # 表格块（图片形式）
tables.append({"page": page_num + 1, "type": "image_table"})

return ParsedDocument(
doc_id=self._generate_doc_id(file_path),
doc_type=DocumentType.NATIVE_PDF,
sections=sections,
tables=tables,
raw_text="\\n".join(s["text"] for s in sections),
)

class LLMKnowledgeExtractor:
"""基于 LLM 的结构化知识提取"""

def __init__(self, llm_client, schema: dict):
self.llm = llm_client
self.schema = schema # 定义需要提取的实体类型和关系类型

async def extract(self, doc: ParsedDocument) -> dict:
entities = []
relations = []

# 按章节提取，避免单次 Prompt 过长
for section in doc.sections:
if section["type"] == "heading":
continue # 标题不参与实体提取

result = await self._extract_from_section(section, doc.metadata)
entities.extend(result.get("entities", []))
relations.extend(result.get("relations", []))

# 实体去重与合并
entities = self._deduplicate_entities(entities)

return {"entities": entities, "relations": relations}

async def _extract_from_section(self, section: dict, doc_meta: dict) -> dict:
prompt = f"""从以下文本中提取结构化信息。

文本内容：
{section['text']}

需要提取的实体类型：{json.dumps(self.schema['entity_types'], ensure_ascii=False)}
需要提取的关系类型：{json.dumps(self.schema['relation_types'], ensure_ascii=False)}

输出格式要求（严格 JSON）：
{{
"entities": [
{{"type": "实体类型", "value": "实体值", "confidence": 0.0-1.0}}
],
"relations": [
{{"subject": "主体", "predicate": "关系", "object": "客体", "confidence": 0.0-1.0}}
]
}}

注意：
1. 仅提取文本中明确提及的信息，不要推断
2. 金额需包含数值和单位
3. 日期统一为 YYYY-MM-DD 格式
4. confidence 反映提取的确定性，模糊表述应降低置信度"""

response = await self.llm.complete(prompt)
try:
return json.loads(response)
except json.JSONDecodeError:
# LLM 输出格式异常时，返回空结果而非崩溃
return {"entities": [], "relations": []}

def _deduplicate_entities(self, entities: list[ExtractedEntity]) -> list[ExtractedEntity]:
"""基于 (type, value) 去重，保留置信度最高的"""
seen: dict[tuple, ExtractedEntity] = {}
for entity in entities:
key = (entity.entity_type, entity.entity_value)
if key not in seen or entity.confidence > seen[key].confidence:
seen[key] = entity
return list(seen.values())

四、文档解析系统的 Trade-offs

LLM 提取的精度与成本。 LLM 驱动的信息提取灵活性高，但精度不如专用 NER 模型。在合同金额、日期等关键字段上，LLM 可能产生幻觉——提取出不存在的金额或错误的日期。生产环境中，对高精度要求的字段应使用规则引擎或专用模型做二次校验，LLM 负责处理规则难以覆盖的长尾场景。

OCR 质量与处理延迟。 高质量 OCR（如云服务 API）准确率高但延迟大、成本高；开源 OCR（如 Tesseract）速度快但错误率高。对于低质量扫描件，可能需要多轮 OCR + LLM 纠错的组合策略，但这会显著增加处理时间。

分章节提取与上下文丢失。 将长文档按章节拆分提取，可以控制单次 Prompt 长度，但跨章节的实体关联会丢失。例如，合同签署方在第一章定义，违约条款在第五章引用，拆分提取后第五章的"甲方"无法关联到具体的签署方。解决方案是在提取后增加一轮全局关联步骤，但增加了系统复杂度。

五、总结

智能文档解析系统将非结构化文档转化为可查询的结构化知识，核心挑战在于处理文档格式的多样性、提取精度的稳定性、以及跨文档知识的关联。分层架构——预处理、语义理解、知识结构化——提供了清晰的关注点分离，但每一层都有需要权衡的边界条件。

落地路线建议：第一，从原生数字文档入手，验证语义理解层的效果后再扩展到扫描件；第二，对关键字段建立规则校验层，与 LLM 提取结果交叉验证；第三，构建文档解析质量的评估数据集，定期回归测试，防止 LLM 版本升级导致的提取效果退化。