前阵子跟一位在集团做行政的朋友吃饭他吐槽说每个月光是要录进系统的合同就有两百多份更别提每天从各分公司收上来的公文材料——扫描件、传真件、各种格式的Word混在一起光做要素录入、错别字检查、条款比对就耗掉一个专职岗。聊完我回去把最近在Filez AI文档中台V9上的实践重新梳理了一遍愈发觉得这类场景真正缺的其实不是一个大模型而是把大模型“接到”文档工作流里的那一层中间件。大模型确实是文档智能化的引擎但要让公文和合同真正跑起来关键看中间这一层怎么设计。这篇文章就围绕AI文档中间件这条主线结合公文与合同两个典型场景从架构拆分、核心实现、踩坑实录三个角度展开。适合正在做文档智能化、合同管理系统、企业内部OA升级的研发和产品同学参考。哪怕你暂时不打算引入大模型里面关于文档解析、规则校验、任务编排的思路也能直接用在你现有的系统里。1. 为什么公文和合同场景非要加一层“中间件”不可1.1 先看业务现状公文处理的真实痛点在企业环境里所谓的“公文”远不止红头文件它还包括行政通知、制度发文、会议纪要、批示件、内部通报等。这些文件有几个共同特点第一结构高度模板化但又允许大量自由文本第二版式规范容易被打破比如字号混用、页码缺失、落款日期写错第三关键要素经常藏在扫描件里需要人工重新录入。我见过很多团队的处理方式就是配一个OCR服务把扫描件转成文本然后让业务人员自己去“理解”那些文本。结果呢传统OCR只能把图变成字但“哪些字是标题、哪些字是发文日期、哪些字是正文”这种语义信息OCR给不出来。而且扫描件质量稍差识别出来的文本就是一团乱码加断行的混合物业务人员看着更头疼。1.2 合同场景量大、复杂、风险高合同处理就更有代表性了。一份采购合同动辄十几页包含当事人、标的物、金额、支付方式、交付验收、违约责任、争议解决、保密、知识产权、不可抗力等条款。法务真正关心的是风险点而不是通读全文。传统的合同管理系统只能做到文件归档靠关键词搜索无法理解“付款条件明显不公”“违约责任过高”这类语义问题。合同处理的另一个痛点是要素录入。一份合同里的甲乙双方名称、统一社会信用代码、合同总金额、付款比例、合同期限这些字段都散落在不同条款里。人工录入不但慢还容易出错。我做过一次统计人工录入合同的字段错误率在3%-5%之间这个比例在合同量大时非常可怕一个数字录错可能直接影响付款流程。1.3 为什么业务系统不能直接“调大模型”有人会问我直接在OA系统里写代码调大模型API不就是一个中间件了吗这个问题很有代表性。实际做下来你会发现直连大模型的方案至少有四个绕不开的问题第一是模型依赖。今天用的模型效果好明天供应商改版、下线、调价业务流程就跟着坐过山车。中间件可以在模型层做适配把底层模型变化对业务隔离掉。第二是输出不可控。同样是“提取合同金额”大模型可能返回“人民币壹佰万元整”也可能返回“100万”还可能给你一句“根据合同文本金额为……”作为JSON字段。没有中间层做Schema约束和后校验业务系统拿到这种结果根本没法入库。第三是解析与推理耦合。文档解析PDF转文本、扫描件OCR和业务处理要素抽取、风险识别本来是两件事。如果每个业务系统都自己处理解析等于每个系统都重复造轮子而且解析质量问题还会被误判成“模型能力不行”。第四是审计和复核缺位。公文和合同处理需要留痕谁提交的、哪个模型处理的、原始文档是什么、模型输出是什么、人工有没有改过。直连模式天然没有这个能力。所以中间件在架构上的价值不只是“多包了一层”而是从架构上把文档处理拆成了“解析—增强—推理—校验—审计”的完整链路。1.4 中间件这一层到底做什么用大白话讲中间件就是一个“翻译官质检员”。业务系统不用关心底层用的是哪家大模型也不用处理PDF还是Word的差异只需要提交任务、拿结果。我用一个表格来对比直连和中间件的差异能力项业务系统直连大模型AI文档中间件方案文档格式适配每个系统自研统一解析层一处接入处处复用大模型输出不稳定需业务侧清洗Schema约束规则校验修复模型切换改动业务代码改中间件配置人工复核难以集成任务状态机可挂载复核工单审计追踪基本缺失全链路留痕性能治理缺少限流、缓存统一限流、降级、缓存策略这张表基本就是我给客户讲方案时反复强调的六点。说白了中间件不产生模型能力也不直接产生业务价值它的价值是让“模型能力”稳定地转化成为“业务价值”。2. AI文档中间件整体架构四层设计与核心模块2.1 一个可落地的分层结构参考Filez AI文档中台V9在这类场景的实践方式我把中间件拆成四个核心层外加一个贯穿始终的审计体系接入与任务层对外提供REST API/SDK管理任务状态负责鉴权、限流、排队。解析层负责文件格式识别与转换、OCR、版面分析输出标准化的“文档结构化数据”。推理层承载大模型调用、Prompt编排、RAG检索、few-shot示例管理。校验与输出层对模型结果做Schema校验、规则校验、修复与格式化最终把干净的数据交给业务系统。审计体系记录每个任务的输入、中间结果、最终输出、模型版本、人工修订记录。一个典型的数据流转是这样业务系统调API提交合同文件 → 中间件把合同PDF解析成文本和版面信息 → 根据业务类型选择合同抽取Prompt → 调用大模型生成JSON结果 → 校验层检查必填字段、格式、金额一致性 → 合法的结果返回给业务系统可疑的结果进入人工复核队列。这种分层的好处是每层都可以独立升级。解析层要加一个新的OCR模型不影响上层推理层要切换模型只改配置校验层要加业务规则也只是增量更新。2.2 解析层比想象中重要得多很多人低估了解析层的工作量。真实场景里你收到的文件可能有Word、PDF、扫描件、图片截图、拍照、Excel、WPS格式甚至有些合同是客户用手机拍了发过来的。Filez这类文档中台本身在文件格式兼容上有积累但如果自己从零搭解析层要拆成三个动作文字类文档解析docx可以直接用python-docx提取段落和表格PDF先用pypdf/pdfplumber抽文本有电子版文字就直接用避免不必要的OCR。这里有个细节PDF的文本提取顺序有时候是乱的尤其是双栏排版需要按坐标排序后重组段落否则模型拿到的文本是前后颠倒的。扫描件OCR必须走OCR。PaddleOCR在处理中文和表格方面表现不错Tesseract胜在免费轻量商用场景也可以直接集成成熟OCR服务。但OCR不是“扔图进去出文字”那么简单还需要版面分析比如检测标题区域、落款区域、红章区域这样才能把“这是发文日期”这种位置信息留给上层使用。文本清洗与标准化OCR出来的文本经常有全角半角混用、多余空行、乱码、表格线干扰等噪音。我通常会在清洗阶段统一做全角转半角、去控制字符、合并断行、识别并标记表格区域。这里分享一个实操心得解析层一定要保留“文本和版面的关联”。单纯把PDF转成字符串等于扔掉了所有位置信息。做到后面你会发现很多校验规则比如“落款日期必须在文末”“红章必须覆盖单位名称”是依赖版面信息的。所以我在中间件里保存的解析结果不是一个孤立的文本字符串而是一个包含段落、坐标、样式、表格结构的对象。2.3 推理层大模型选型与部署方式推理层的核心任务是调用大模型。选型时首要考量是数据和合规公文、合同属于企业内部敏感文档很多企业不允许出外网这种情况下必须私有化部署。以私有化部署为例我整理了一个粗略的显存参考模型规模量化方式预估显存适用场景7B左右FP16约15GB一般要素抽取、摘要7B左右INT4约6GB资源紧张的内部测试14B左右FP16约30GB较复杂的条款理解32B及以上INT4约20GB风险条款识别等强语义场景部署框架方面vLLM的并发性能最好适合生产Ollama适合快速验证llama.cpp适合CPU或混合部署。如果允许调用云端API也可以走OpenAI兼容接口中间件统一封装后续切换无感。这里需要特别强调训练和部署是两回事公文合同处理这种场景选“效果够用显存可控”的模型即可不必追求最大参数规模。2.4 校验与输出层让大模型结果“可入库”这一层是整个中间件的“质检岗”。很多POC项目之所以没法上线不是因为模型抽不出来字段而是抽出来的字段没法自动写进数据库。校验层要做的事包括必填字段检查比如合同金额、签署日期为空直接标记“需补录”。类型与格式校验日期必须是YYYY-MM-DD金额必须是数值或标准大写。一致性校验从合同正文里用正则抽出的金额和模型输出的金额比对不一致说明可能出错。置信度评估让模型在输出时附带conf字段也可以基于历史数据训练小模型低于阈值进人工。校验不过的结果不能直接返回失败而要进入“修复复核”流程。修复是指用规则引擎尽量纠正比如模型把“人民币壹佰万”输出成了“壹佰万”可以靠字典转换补上币种复核是指挂起一条人工任务由业务人员在界面确认或修改。这一套机制就是Filez AI文档中台V9在实际使用中最让业务方放心的部分——不是让AI全自动而是让AI先处理、人工只盯异常。3. 公文智能化落地要素抽取、版式校验与敏感信息检查3.1 第一步用结构化Schema约束大模型输出做公文智能化的第一步是把你关心的要素定义成结构化的Schema。以一份企业内部正式发文为例我通常会定义以下字段doc_type文件类型通知、通报、请示、批复、会议纪要等title文件标题issuing_department发文部门main_recipient主送对象cc_recipient抄送对象doc_number发文字号security_level密级公开、内部、秘密等及紧急程度body正文内容signing_name落款署名sign_date成文日期attachments附件列表及名称Schema定义好后把它写进Prompt要求模型严格按JSON返回。同时准备正则和规则作为兜底。比如“成文日期”可以优先用正则匹配“2025年4月15日”或“二〇二五年四月十五日”格式“发文字号”可以匹配“XX〔2025〕XX号”这类模式。这里有一个容易被忽视的点Prompt里的Schema和校验层的JSON Schema一定要保持一致并且版本化管理。我遇到过一次事故Prompt改了字段名没同步校验层结果上线后所有公文都校验失败。后来我把Schema定义放成公共模块Prompt由代码动态拼接从源头杜绝了手写两处导致不一致的问题。3.2 版式校验用规则管住格式大模型擅长语义理解但“页码格式对不对”“标题是否居中”“正文行距是否统一”这类版式校验更适合用规则来做。在Filez这些文档中台的实践里版式校验实际上是插入到解析层和校验层之间的一个独立规则引擎。举几个实际会跑在企业内部的规则红头部分的字体、字号一般在模板中定义好校验时比对解析出的文本样式。正文字号是否一致、段落间距是否异常通过解析层返回的样式信息判断。页码是否存在、格式是否正确直接检查PDF每页的文本和位置。落款日期和发文部门是否存在、是否位于文末区域结合版面坐标判断。附件说明是否在正文末尾、附件名称是否和正文后列出的附件一致。版式校验的产出不是简单“对/错”二值而是一个问题列表每条带位置、规则ID和建议修改方案。这样人工处理时效率会高很多。我见过太多模板从一开始就没规范到位导致后面所有校验都报警的情况所以这类规则一定要做成“可配置、可下发”不同子公司可以有不同模板。3.3 敏感信息筛查不放过手机号、身份证号和内部代号公文和合同处理过程中隐私合规是不可回避的一环。中间件里我习惯加一组“实体脱敏与告警”规则包括手机号、身份证号、银行卡号的模式识别正则企业内部代号、项目代号、员工编号的自定义词典邮箱、地址、网盘链接数字水印、隐藏文字Word里的隐藏段落这部分实现比较简单用正则自定义词典就可以做基础版进阶可以结合命名实体识别模型提升候选召回。筛查结果分为“需告警”和“需脱敏”两类在审批流里标记告警在对外输出文档里强制脱敏。举个例子一份合同扫描件经OCR后中间件在正文里识别出一个手机号码同时该合同又标记为“需外部审计”那这份文件进入复核队列后会要求人工确认该号码是否冗余公开。整个过程都会被审计日志记录方便事后追查。4. 合同智能化落地要素抽取、条款比对与风险识别4.1 合同关键要素抽取与历史比对合同要素抽取和公文抽取的逻辑类似但字段更多、更复杂。我常用的合同抽取Schema大致包括contract_name合同名称contract_no合同编号party_a / party_b甲方/乙方各自含name、unified_social_credit_code、legal_representative、address、contactsubject标的物/服务内容contract_amount合同总金额currency币种amount_uppercase金额大写payment_terms付款方式与条件contract_term合同期限含start_date、end_dateperformance_place履行地点liability_clause违约责任条款dispute_clause争议解决方式仲裁/诉讼管辖地effective_condition生效条件sign_date签署日期这样一个Schema跑下来基本能覆盖日常合同登记的需求。关键技巧有两个第一把Prompt写成“任务清单目标JSONfew-shot”三段式few-shot至少给两个完整示例一个强格式合同一个缺字段的合同让模型学会“缺了就填空字符串”而不是自己编造。第二后处理一定要做。模型输出的合同金额可能是“人民币100万元整”也可能“1000000元”我建议在中间件里写一个金额标准化模块统一转成数值和币种同时保留原始展示串。日期同理中文日期和阿拉伯数字日期统一转成ISO格式。条款比对则是法务审核的高频需求。中间件可以这样实现先把合同按条款标题切块第一条、第二条……然后用大模型为每一块生成语义摘要和关键词再做相似度匹配。具体步骤是解析并切分条款保留条款编号和标题。将标准模板条款和待审合同条款分别向量化Embedding模型。计算相似度矩阵找出“有对应但内容不同”的条款对。对有差异的条款调用大模型生成差异说明输出为“新增/删除/修改”三类。最终生成一份差异报告法务只需要看重点。这里有个经验直接用大模型比对“全文和模板全文”很容易漏掉细枝末节的修改。先向量粗筛、再模型细审误差会小很多。4.2 风险条款识别规则模型混合方案风险识别是最体现业务价值的功能。所谓风险无外乎付款条件苛刻、违约责任失衡、无限连带责任、管辖地约定不清、合同期限异常等。我的建议是不要只靠大模型而是做“规则模型”的混合方案规则层用关键词和正则命中常见高风险表述比如“不得解除”“全部赔偿”“单方决定”“放弃追索”等。模型层对于语义性风险比如“付款周期长且无验收标准”给大模型定义类别清单让它逐条判断并给出风险等级、风险描述、原文位置。为了让模型聚焦我一般会把合同按条款块拆分后分批传入而不是把整份合同一次性丢进去。这样既降低超出上下文窗口的概率也方便把风险点和具体条款对应起来。下面是风险识别Prompt的一个核心片段这种“只输出JSON数组”的方式在生产环境比较稳定RISK_PROMPT_TEMPLATE 你是一个合同风险审查助手。请分析以下合同条款识别潜在风险。 风险类型限值为payment_risk / liability_risk / term_risk / scope_risk / dispute_risk / compliance_risk / other 对每个风险输出JSON包含字段 - clause_index: 条款编号数字 - risk_type: 类型 - risk_level: high / medium / low - reason: 风险原因不超过50字 - suggestion: 修改建议不超过50字 只输出JSON数组不要额外说明。若没有风险输出空数组[]。 合同条款如下 {clauses} 如果业务系统做了合同模板标准化这个方案的效果会更好。因为模板里的条款通常不会触发风险模型需要关注的重点就集中在非标准条款上漏报率会显著下降。反过来如果一堆合同连模板都没有风险识别就只能当作“提示”使用务必让人工法务做最终确认绝不能直接自动通过。4.3 金额、日期等精确计算交给代码这里要特别强调不要依赖大模型做数学计算。合同金额加总、日期差计算、上下限判断这类任务让模型做就是给自己挖坑。模型的强项是语义理解数值计算应该由代码完成。例如合同里写“甲方应于每季度结束后15日内支付上一季度服务费”要判断付款周期是否合理正确的做法是模型抽取“季度”和“15日”这两个参数代码负责计算和比较。再比如“违约金不超过合同总金额的20%”模型只需抽比例代码判断是否在阈值内。我在中间件里实现了几个通用工具函数包括中文大写金额转数字、中文日期转ISO、条款编号解析等。下面是一段简化版的中文金额转换示例这种代码虽然不复杂但能把错误率从5%以上降到接近零import re CN_NUM { 零: 0, 壹: 1, 贰: 2, 叁: 3, 肆: 4, 伍: 5, 陆: 6, 柒: 7, 捌: 8, 玖: 9 } CN_SECTION_UNIT {万: 10000, 亿: 100000000} CN_SIMPLE_UNIT {拾: 10, 佰: 100, 仟: 1000} def chinese_number_to_int(text: str) - int: 简化版中文数字转整数仅用于金额/日期中的数字片段。 # 去掉“人民币”“整”等非数字部分 text re.sub(r人民币|元整|元|圆|整, , text) section 0 total 0 number 0 for char in text: if char in CN_NUM: number CN_NUM[char] elif char in CN_SIMPLE_UNIT: section number * CN_SIMPLE_UNIT[char] number 0 elif char in CN_SECTION_UNIT: section (section number) * CN_SECTION_UNIT[char] total section section 0 number 0 return total section number这种函数网上有很多版本但真要落地还要处理“十”开头的写法、“二十三万零五百”这种带零的写法以及“贰佰柒拾万”这类常见情况。我建议在单元测试里把历史合同的金额样本都跑一遍确保转换结果和人工录入一致后再上线。5. 实战避坑模型幻觉、长文本截断与成本控制5.1 模型输出幻觉的排查与对策跑这类项目遇到最多的就是模型幻觉。比如合同里根本没有约定违约金模型却“推断”出“违约金为合同金额的30%”这种错误一旦进库会很危险。我的排查思路是三层防线。第一层是Schema约束在Prompt里明确字段枚举和格式同时尽可能使用API的JSON模式OpenAI兼容接口通常支持response_format{type:json_object}。第二层是规则校验金额、日期、编码等字段用正则或者词典回验。第三层是关联验证比如让模型同时抽取“合同总金额”和每条付款金额代码再校验总金额是否等于分项之和不一致就打回重试。如果模型反复出错优先检查Prompt是否给足了few-shot示例。一个常见的反模式是“模型把甲乙双方搞混”。解决办法是在Schema里写清楚“甲方是付款方乙方是收款方”之类的业务语义并在few-shot里给出一个容易混淆的例子让模型明确知道该往哪个字段里放。5.2 长文档超限与分块策略大模型的上下文窗口有限处理长合同时尤其明显。虽然很多新模型的上下文已经达到128K甚至更多但把整份合同塞进去不仅贵而且效果会下降注意力分散。我的分块策略是先按文档结构章节、条款切分块大小控制在1000-1500字重叠200字左右避免切割断裂导致语义丢信息。对于要素抽取可以让每个块各自抽取一份结果然后再让一个汇总任务合并去重。对于风险识别按块识别后合并风险列表。对于比对按块检索后只把高相关块送给模型精审。切块后的任务可以并行提交但要注意并发限制和成本同一份合同多个块同时打大模型费用和速率都要提前测算。我一般会在接入层做统一的任务队列控制防止并发冲击导致接口超时。5.3 性能、稳定性与成本控制生产环境和POC最大的区别是流量模型。平时几百份合同随便打上线后可能一小时就有几百份任务涌入。这时候中间件的限流、队列、缓存机制就必须顶上。我一般会在接入层做几件事文件去重缓存按文件哈希缓存解析文本和抽取结果同一份合同反复提交不重复消耗模型资源。任务队列用Celery或者Redis队列做异步任务避免同步接口被长耗时任务拖死。限流与降级对每个模型通道配置限流每秒请求数、每日token上限超限自动降级到备用模型或降级到纯规则方案。Token预算提前根据文档大小估算token数超出预算直接拒绝或要求简化处理。下面是我在中间件服务里做的一个简化版接口示例可以看到解析、抽取、校验、缓存的调用链from fastapi import FastAPI, File, UploadFile from hashlib import md5 app FastAPI() app.post(/api/v1/contract/extract) async def contract_extract(file: UploadFile File(...)): content await file.read() doc_hash md5(content).hexdigest() # 1. 查缓存避免重复消耗模型资源 cached cache.get(doc_hash) if cached: return {from_cache: True, data: cached} # 2. 解析层PDF/Word/扫描件 - 文本 parsed parse_document(file.filename, content) # 3. 推理层Prompt 大模型 llm_result llm_chat( system_promptCONTRACT_EXTRACT_SYSTEM_PROMPT, user_textparsed.text, temperature0.1, max_tokens2048, response_formatjson_object, ) # 4. 校验层Schema 规则 validated validate_contract(llm_result, parsed.text) # 5. 审计日志写入 audit_log(doc_hash, file.filename, parsed.text, validated, model_versionqwen-2.5-14b) # 6. 写缓存 cache.set(doc_hash, validated, ttl3600 * 24) return {from_cache: False, data: validated}成本这块建议按“每万字文档消耗token数”做粗略估算。一份正规合同约5000-8000字正文token数约1万-1.5万加上Prompt模板和few-shot每次抽取调用大约消耗2万token。如果走云端API一个月处理1万份合同就是2亿token量级预算是必须提前谈的。私有化部署则主要看GPU成本和运维成本。5.4 常见问题速查表整理一份常见问题速查表方便直接照着排查问题现象可能原因建议排查方向模型输出字段缺失文档本身缺该信息 / Prompt暗示可略过强制Schema字段必填缺失也要输出空串金额大小写不一致模型把“壹佰万”转成“100万”或“100”后处理统一转标准数值并和OCR/正则结果比对甲乙双方颠倒文档中无明确“甲方/乙方”字样few-shot增加容易混淆的样本抽取时引用原文片段扫描件日期乱码OCR识别精度不足日期区域用专用模型/模板匹配必要时人工复核长合同处理超时单次请求token过长或模型推理慢分块并行异步处理同一文档结果不稳定采样参数或Prompt未固定temperature设为0.1以下固定prompt版本合规审计不通过缺少模型版本与调用追溯在审计日志中记录模型版本、采样参数、原始输出这个表基本涵盖了从POC到上线遇到的大部分坑。真要说哪一类问题最费时间还是“解析层数据质量问题”——很多次排查到最后发现不是模型不行而是前面文本给的太脏。最后再分享一点个人体会。很多人把AI文档中台简单地理解成“给大模型套一层壳”实际做下来你会发现中间件的核心是把业务规则、解析能力、模型能力和人工闭环揉在一起。中间件设计得好业务系统和模型各自都能轻松演进设计得不好两边都会被拖死。我在Filez AI文档中台V9的实践里最大的收获就是学会在“模型能力”和“业务确定性”之间找到平衡点。另一个经验是不要追求一次把全部文档场景AI化。从公文要素抽取和合同风险识别这两个小场景切入验证链路跑通后再横向扩展是比较稳妥的节奏。哪怕先只跑通一个“扫描件转可检索文本”的流程都能立刻减少大量人工录入工作。希望这篇实践笔记能帮你在自己的文档智能化路上少踩几个坑。