PDF 小模型提取别急着上大模型先把链路跑通再说。先说下我自己的背景这几年一直在做金融文档处理相关的AI工程处理过不少基金合同、贸易合同、确权文件之类的扫描件。这类项目的典型诉求就一句话把几千份甚至几十万份PDF里的关键字段比如合同编号、甲方乙方、起始日期、付款条款、违约金额这些挖出来填进业务系统的表结构里。干过这活的都知道PDF这东西简直就是数据工程里最拧巴的钉子户看起来有个文档在那摆着但想让它变成干净的、可入库的结构化数据中间能翻车的环节多到你怀疑人生。今天要聊的这套方案核心路线就是“开源小模型 解析工具 规则兜底”的四层链路。不下重金、不调超大模型只用几B参数的小模型配合版面解析、OCR、字段校验和兜底重试机制把PDF合同提取准确率做到98%以上。适合刚好被合同/OA系统/流程自动化折磨的AI工程师也适合只想把手里现有PDF文档梳理出结构化数据的业务开发、数据分析师。先把结论摆前面这个问题的核心不是“模型强不强”而是“任务到底拆得细不细”。1. 项目概述两万亿美元合同为什么全都锁死在PDF里1.1 需求拆解合同数据提取为什么是个硬骨头先聊聊“两万亿美元”这个量级。我习惯把它理解成一个数据量级标志意思是天量的存量合同文档每天都在维护、到期、续签而这些合同的载体绝大多数是不可编辑、没有结构化标注的PDF。拆开来看其实有几种情况原生电子合同由Word/WPS导出带文本层但版面结构千奇百怪表格跨页、页眉页脚、混排字号都是常态。扫描件合同打印机扫描、传真、截图粘贴生成的图片型PDF纯靠OCR。混合型PDF一部分页面有文字层一部分是图片或者表格区域被转成矢量图形文本层存在但是顺序错乱。合同本身还有个特点字段维度特别高。不只是“合同编号”这种简单字段还有多级嵌套的条款列表、价格条款里密密麻麻的表格、附件清单里的补充协议编号。这些信息在PDF里没有统一的DOM结构完全依赖视觉呈现和阅读顺序。说白了人和AI看到的都是线但业务系统要的是立体的树。做这套东西之前要先想清楚一个逻辑PDF解析练的是“读懂版面”小模型练的是“读懂语义”而业务系统要的是“可校验的数据”。三步缺一不可任何人告诉你一个模型直接“端到端”就能从PDF抽字段十有八九是在演示环境里过拟合了。1.2 人工转录入模式为什么撑不住“两万亿美元”这里顺手算一笔账一份中大型合同大概10~20页需要录入的字段少说30个多则80个以上。老手人工录入一条字段信息平均20秒一份合同最快要10分钟以上而且平均差错率在1%~3%尤其是金额、日期、账号这一类高敏感字段错一个数字后续就可能引发问题。按一天8小时有效工时算一个人满打满算处理40份十万份合同就得2500人天。这个成本对企业来说非常夸张所以才催生了自动化提取需求。我做过的一个真实项目客户库里有六十多万份历史合同分布在五六套不同年代的归档系统里。目标很朴素不管过去生成的合同长什么样以后每天新增的合同都要能自动进系统提取成功率不能低于95%。当时我们定的框架就是“解析器负责版面理解、小模型负责语义抽取、规则引擎负责兜底纠偏”事实证明这条路走得很稳。2. 技术选型思考为什么坚决不碰超大模型2.1 成本、安全与吞吐量的现实约束项目启动时甲方问过一句是不是直接接GPT-4之类的闭源大型模型最省事技术上一听确实香零标注、开箱即用、提示词写清楚就能出结果。但深入考虑之后我们还是没有选择这条路原因特别现实数据合规合同内容属于商业敏感文件法律法规对合同数据的出境、在第三方服务器留存都有严格的合规要求。客户不希望合同文本离开公司内网就这一条直接毙掉了大多数云上API方案。成本模型这类任务不是一天只跑几百条而是全量历史回刷加上每日增量跑批。超大规模模型按Token计费一份合同拆开几千个Token几十万份合同的量级算下来完全超预算。而本地跑小模型核心成本只有硬件电费和一次性的调优人力。吞吐量要求生产环境最忌讳的就是调用外部API。网络波动、限流、并发限制都会让“批量回刷”变成“批量失败”在小模型本地推理的场景下这些外部依赖全部不存在跑批稳定性完全是可控的。当然不是说超大模型没用模型蒸馏阶段走“大模型先出样例、小模型再穷追猛打”的路子特别有用。后面我会详细讲训练数据准备。2.2 小模型的版本迭代3B~14B才是合同抽取的甜点区做合同提取主流选择是7B级别的开源模型。我们最终确定的是基于Qwen2.5-7B-Instruct做LoRA微调同时配套3B版本给高吞吐、低延迟的常规增量任务用。选中它有几个具体原因指令跟随能力强Qwen系在结构化输出上的稳定性在开源阵营里是公认靠谱的尤其是让它输出固定JSON schema时比很多同尺寸模型犯的格式错误少得多。中文合同经验足合同语料中大量中文法律名词像“不可抗力”“违约责任”“争议解决方式”这类词汇如果模型在中文语料上预训练不充分很容易出现术语改写和含义漂移。Qwen在中文任务上天然占优。部署门槛低7B模型在量化后INT8/INT4用一张消费级卡或者16G内存的推理环境就可以跑而且吞吐量非常可观。实际做AB测试时我们用了一份1000页带人工标注的合同样本在字段抽取准确率上7B微调版模型达到96.8%远超3B版本的91.2%而对比同场景下的大模型API基础提示词版本准确率不过93%左右。关键差异主要出在两个地方一是复杂嵌套表格的还原二是同义字段的归并。小模型在微调里见多了“本单位/我司/本公司”这类表述后泛化明显上升。2.3 规则引擎不是退步是必要兜底AI模型再强也有稳定性的边界。合同文本里可能出现打印模糊、盖红章遮字、扫描畸变、扫描件倾斜等各种肉眼都看着费劲的情况。这种脏数据模型再聪明也难以做到100%。所以链路里最后一道兜底永远是规则引擎对模型输出的JSON做格式校验对必填字段做存在性检查对金额/日期格式做正则匹配命中一轮就触发重试。重试不行就转人工工单。这个设计在工程上叫“差错降级出口”。模型能处理的尽量自动做模型不自信的、处理不了的系统老老实实交给人去兜底整个流程才敢上生产环境。这一点是我最想给正在做类似项目的工程师说的不要追求单个环节的100%要追求系统层面的99.5%。3. 链路设计与核心细节解析、清洗、抽取、校验四层结构3.1 第一层PDF版面解析这一层解决的是“把PDF变成机器能看的文本块”的问题。很多人一上来就拿pdfplumber提取文本但PDF里文本对象的顺序并不一定对应真实阅读顺序。特别是合同里多栏排版、表格区域带边框线、页眉页脚重复出现都可能导致抽出来的文本乱序。我的做法分两种情况原生文本型PDF首选PyMuPDFfitz速度快可以按坐标块读取文本。但要注意出来的结果要按坐标重新排序而不是直接用页面文本顺序。排序规则很简单按y坐标排序同一行内按x坐标排序跨页时把左右栏分开。扫描图片型PDF先转图片再用OCR走一遍。OCR选型上我用的是PaddleOCR同时对表格区域用PaddleStructure做表格结构识别把表格转换为HTML或者Markdown再交给后面的模型去做字段抽取。举一个实战细节原生合同PDF里经常出现“合同编号HT-2023-01234”但在文本层里编号可能被拆成两段中间插入了其它对象。这种情况下直接拼接字符串是错的必须先做坐标聚类把同一水平线、相邻位置的对象合并成行再按语义规则拼字段。3.2 第二层文本清洗与版面重构解析出来的文本流基本是“脏乱差”的直接喂给模型会严重干扰效果。这一层我做三件事去噪删掉页眉页脚、页码、装订边注、印章文字靠位置信息和关键词列表一起完成。段落合并把跨页的同一段落拼接起来同时保留表格等特殊块。合并规则不是简单的把两块拼一起而是根据段落末尾字符、下一块开头字符的类型判断是否续接。字段值预提取对于格式非常固定的字段合同编号、日期、金额、双方名称先用正则粗跑一遍把命中值连同上下文片段一并带入下一层。这一步极大地减轻了模型负担因为很多高频字段根本不需要推理模式匹配就能搞定。我经常用一个比喻文本清洗做得好不好决定了后面模型是“当填空题做”还是“当阅读理解题做”。清洗完再喂给模型相当于给了干净题干模型只需要填空准确率自然高。3.3 第三层小模型语义抽取的核心逻辑模型在这条链路里只做一件事根据给定的合同片段抽取预定义字段并输出JSON。这里有几个关键技术点提示词中的schema描述必须把每个字段含义、格式要求、候选值说清楚比如“contract_sign_date必须是YYYY-MM-DD格式”。模型对schema理解越好输出越规范。上下文窗口的利用小模型窗口通常较短不能把整份合同塞进去。所以要做切片按一级章节合同首部、双方信息、标的条款、违约责任等切段每段独立抽取相关字段再做聚合。few-shot示例高质量示例对准确率的影响非常大。每类字段给一两条典型的抽取示例模型会快速模仿样例格式尤其对金额、日期这类格式容易乱的字段效果立竿见影。我反复强调一个观点小模型和大型模型的差距不在“智力”而在“执行稳定性”。小模型只要把任务拆得足够简单、指令给得足够明确效果完全能打。最忌讳的就是把整份合同全量丢进去让模型一次性输出全部字段小模型立马露怯。3.4 第四层输出校验、纠错与人工协同模型输出的JSON先过一层“结构化校验器”。用JSON Schema定义字段格式凡是达不到格式标准的自动重试。重试次数一般设2次每次都带上上一次输出的错误信息让模型自己改。实测下来仅重试这一层就能把格式错误率从5%~8%降到1%以下。接着做业务校验金额字段必须大于0、日期必须合法、甲乙方名称不能为空。未通过的直接进入人工复核队列。这里有个小经验人工复核队列不要设计成“一条条看”要把同一份合同的所有字段合成一张卡让人只看标红的可疑字段同时在页面上把来源高亮出来这样可以大幅提升复核效率。4. 实操过程从环境搭建到跑通一条抽取流水线4.1 环境依赖与模型准备我这里用一个最小化的可复现环境为例说明。整体用Python模型推理用Transformers vLLM做本地部署文本解析用PyMuPDF和PaddleOCR。物理机配置只需要CPU一张16G显存卡即可跑7B量化模型。# 核心依赖清单 pip install pymupdf pip install paddlepaddle-gpu paddleocr pip install transformers accelerate vllm pip install pydantic jsonschema模型部分直接选用现成的开源预训练模型# 下载Qwen2.5-7B-InstructHugging Face或ModelScope huggingface-cli download Qwen/Qwen2.5-7B-Instruct --local-dir ./models/qwen2.5-7b如果不想自己下模型也可以直接用ModelScope的镜像国内网络环境下会快很多。模型下载完之后在vLLM里起一个本地OpenAI兼容接口from vllm import LLM, SamplingParams llm LLM( model./models/qwen2.5-7b, tensor_parallel_size1, dtypefloat16, max_model_len8192, ) sampling_params SamplingParams( temperature0.1, top_p0.9, max_tokens1024, stop[|im_end|] )temperature设置很低目的是让模型输出尽量确定。合同提取不是创意写作不需要发散确定性越高越好。4.2 存档下来的Prompt结构示例给模型的原生输入其实是一个很长的系统提示词。要想达到稳定输出建议把提示词结构固定成一个模板每次只替换字段定义和合同片段。下面是我项目中长期使用的一个精简版你是一个合同关键信息抽取助手。请从【合同正文】中提取以下字段并返回JSON。 字段定义 - contract_id: 合同编号字符串 - sign_date: 签订日期格式YYYY-MM-DD - party_a: 甲方全称 - party_b: 乙方全称 - contract_amount: 合同总金额数字单位元 - amount_in_words: 金额大写 - project_name: 项目名称 输出要求 - 只输出JSON对象不要输出任何解释、注释或多余内容 - 找不到的字段填null - 金额字段只返回数字 【合同正文】 {chunk_text}这里最关键的变量是chunk_text。按我之前说的切片策略一份合同可能被切成首部段落、标的段落、价款段落等多个块分别传给模型最终聚合。4.3 解析抽取的核心实现代码给一个最小可运行版本的链路代码。这个代码解决了从PDF到结构化JSON的最短路径非常适合先用起来再细化import fitz import json from vllm import LLM, SamplingParams llm LLM(model./models/qwen2.5-7b, dtypefloat16) def extract_text_from_pdf(pdf_path: str) - str: 基于坐标重排提取PDF文本保证阅读顺序基本正确 doc fitz.open(pdf_path) lines [] for page in doc: blocks page.get_text(dict)[blocks] text_lines [] for block in blocks: for line in block.get(lines, []): y round(line[bbox][1], 1) x round(line[bbox][0], 1) text .join([span[text] for span in line[spans]]) text_lines.append((y, x, text)) text_lines.sort(keylambda t: (t[0], t[1])) lines.extend([ln[2] for ln in text_lines]) return \n.join(lines) def chunk_contract(text: str, max_len: int 3000) - list[str]: 按空行切块保证每块不超过max_len字符 paragraphs text.split(\n\n) chunks, cur [], for p in paragraphs: if len(cur) len(p) max_len: chunks.append(cur) cur p else: cur \n\n p if cur: chunks.append(cur) return chunks def build_prompt(chunk: str) - str: system 你是一个合同关键信息抽取助手... user f请从以下正文提取字段\n{chunk} return f|im_start|system\n{system}|im_end|\n|im_start|user\n{user}|im_end|\n|im_start|assistant\n def extract_fields(pdf_path: str): text extract_text_from_pdf(pdf_path) res {} for chunk in chunk_contract(text): prompt build_prompt(chunk) out llm.generate([prompt], SamplingParams(temperature0.1, max_tokens512)) try: data json.loads(out[0].outputs[0].text.strip()) res.update(data) except json.JSONDecodeError: continue return res if __name__ __main__: print(extract_fields(sample_contract.pdf))这段代码虽然短但已经是完整MVP。生产环境还需要把解析、提取、校验拆成独立服务加缓存和队列但逻辑骨架完全一致。4.4 数据切块策略的细节优化切片策略上最开始踩过一个坑直接按未切块全文送进去7B模型的输出总是不稳定经常漏字段。后来改成“固定token数段落边界”的切法效果立刻上来了。# 错误的切法暴力截断 chunk text[:2000] # 正确的切法按段落边界切 chunks text.split(\n\n)暴力截断会把一句话从中间劈开模型在语义不完整的情况下只能靠猜。按空行切块虽然可能切得长短不一但每一块语义相对完整毕竟合同文档每个段落本身就是一个完整的条款主题。5. 常见问题与排查技巧实录5.1 问题速查表现象根因解决方式表格数据提取错位PDF表格无实体框线文本层顺序错乱改用PaddleStructure做表格还原而不是纯文本流OCR把“0”识别成“O”扫描质量差字体过小加OCR后处理规则金额字段单独过正则数字置换模型输出的JSON总是格式错误提示词里缺少明确输出约束在系统提示词中增加“只输出JSON对象”并配合few-shot示例金额字段带单位混入合同里同时出现数字和小写/大写金额字段定义明确“只要数字”单位另设字段合同太长导致关键段被截断单一文本块超过模型窗口按章节切块后聚合确保每块有独立主题同一份合同重复提取结果不一致模型推理时采样随机temperature降至0.1以下关闭随机采样5.2 结构化输出不稳定的深度修法小模型在JSON输出上最常出的问题是“往JSON里写注释”或者“在JSON后边追加多余文字”。这个问题如果只在提示词里说“不要输出注释”往往不够。更狠的方法是让模型输出固定前缀和后缀然后解析时强制剥壳raw out[0].outputs[0].text.strip() if raw.startswith(json): raw raw.removeprefix(json).removesuffix().strip() # 还要做一次括号匹配取出最外层JSON对象还有一招很好用如果模型连续两次输出格式非法不再重试模型而是把文本块降级给规则引擎用正则抽高频字段剩余字段转人工。这套降级策略在生产环境里把任务成功率提升到了99%以上。5.3 OCR识别错误对后续抽取的影响OCR识别错误是扫描件方案里最大的变量。常见的有“0”和“O”混淆、“1”和“l”混淆、“逗号”和“。”混用。我对金额字段做了非常严格的后置校验先把OCR文本中所有数字串提取出来再用正则重新排版比如金额要匹配^\d(\.\d{2})?$日期要匹配^\d{4}-\d{2}-\d{2}$。凡是不匹配的一律走人工复核。更狠一点的做法是把扫描件OCR之后做一次“反向打印”让模型看着OCR结果识别可疑字符。这个想法在具体实践中开销较大但遇到极脏的扫描件确实有效适合在重点合同复核环节启用。5.4 长合同怎么处理不丢字段长合同最让人头疼的是“模型窗口限制导致字段丢了”。比如合同里第45页的“送达地址”如果和前边的文本耦合得很松很容易在切块时被切到不同块而模型又不会跨块记忆所以聚合的时候会漏。我们采用的方案是“重叠切块”每个块保留前一块末尾的200个字符。这样即使一个字段被边缘分开模型也能从重叠区看到完整上下文。重叠比例不用太高10%左右就够。代价是重复内容会多消耗一点吞吐但换来的准确性完全值回票价。6. 效果评估与进一步扩展从“能跑通”到“能落地”6.1 字段级准确率怎么测生产上线前我们在万份人工标注样本上做了评估。评估维度不搞整篇内容对比而是做字段级拆解。每一类字段单独看准确率、召回率、F1值因为不同字段对业务影响权重完全不同。举一组实测数据字段类型准确率召回率备注合同编号99.2%98.7%主要靠规则识别模型辅助甲方乙方97.8%96.5%同义词归一后表现较稳合同金额98.5%97.1%存在大小写金额不一致干扰签订日期99.1%98.4%格式比较多依赖后处理违约条款描述94.3%92.6%长文本抽取难点依赖切块策略评估完就能发现真正拖后腿的是长条款类字段而这类字段恰恰最需要模型推理。所以后续优化方向很明确针对长文本描述类字段增加专项训练语料。6.2 数据溯源与复核机制设计合同数据是要进业务系统的来源必须可追溯。“这个字段是从哪份PDF第几页第几段抽出来的”要能回答。我的做法是在最终输出JSON上挂一个provenance字段记录每个字段的来源页码、文本片段、抽取置信度和抽取方式模型/规则/人工。这样即使未来某个字段被发现抽错了也可以直接定位原始段落排查。页面定位操作在代码里对应很简单论文类我用的是解析时记录每个文本块所在页码聚合结果时把source_page也一并写入。这个看似不起眼的设计在后续审计和模型迭代中发挥的作用极大。6.3 合同提取之后的延伸玩法提取出来的合同数据一旦落库能做的事就多了。合同到期自动提醒、金额汇总分析、跨合同条款一致性比对这些都是经典业务场景。往前走一步的话把合同文本和提取字段一起做成向量化索引进入RAG就能做“智能合同问答”比如“我们和某个供应商去年签了哪些合同、总共多少钱、有没有争议条款”。这条技术路线跟提取链路完全兼容等于把一次解析的成果反复复用。当然再往后如果要做“AI自动审合同”还需要把条款语义理解能力再往上提一个量级小模型可以作为一个高效的预筛器先把明显有问题的合同过滤出来再交给更强模型精读。这个分层协作的思路我认为才是未来AI工程最务实的落地路径。最后分享一个很个人的体会做这类项目的关键不在模型选型那一步而在于你是否能把“不确定的模型输出”用工程手段框在“确定的业务规则”里。每次看到一份布满扫描噪点的PDF被抽出干净的合同编号并且一路绿灯进入业务系统那种“驯服了混沌数据”的满足感可能就是我们做AI工程最上头的时刻。