接手企业数字化建设这几年我最大的体会是文档处理是所有业务系统都绕不开、却又最容易被低估的一环。尤其是公文和合同这两类典型的高价值文档它们格式要求严格、术语密度高、审批链路长而且出错代价极高。过去我们尝试过让业务系统各自对接大模型结果不到两个月就乱了——有的团队调通用API有的团队自己训练小模型有的干脆用正则硬写规则能力和数据完全割裂。最终让我们下决心引入AI文档中间件方案的原因是Filez AI文档中台V9把整个文档智能化的链路理顺了底层接模型上层给业务系统中间沉淀文档处理能力这正好补齐了我们最缺的那一层。这篇文章不会去复述厂商的宣传口径我尽量站在一个实际落地者的角度把V9在公文与合同智能化上的架构思路、部署方式、模型选型逻辑和踩坑经验都摊开讲清楚。如果你正在考虑给自己的企业做文档智能化改造或者已经在评估各类AI文档产品这篇文章应该能帮你少走不少弯路。1. 为什么文档这块业务最终需要单独抽一层中间件1.1 没有中间件的时候每个系统各接各的大模型先说说我们之前遇到的真实问题。公司里有OA系统、合同管理系统、档案系统、法务审核平台每个系统都有文档处理需求。OA需要自动生成公文初稿合同系统需要抽取关键条款和风险点档案系统要做全文检索法务平台要能比对合同版本差异。一开始大家的思路很直接调大模型API。OA团队调一个合同团队调另一个最后发现问题一大堆。首先是能力碎片化。同一个PDF解析的需求三个团队写了三套代码一套用paddleocr一套调用商业OCR服务一套直接转换文本。解析出来的结果结构都不统一后续想统一做知识库和检索数据根本没法对齐。其次是提示词和参数管理混乱。合同要素抽取的提示词在合同系统里写了一版在法务系统里又改了一版两版口径不一致抽出来的合同金额违约责任字段定义都不同。法务审核的时候对着两套结果来回校对工作量不减反增。最后是模型替换成本极高。后来我们想换更好的底座模型结果所有业务系统都要跟着改接口、调参数、回归测试一个迭代周期拖了大半个月。这时候我才意识到缺的不是接入大模型的能力而是统一管理这种能力的中间层。1.2 中间件到底解决哪三个问题把文档能力从业务系统里抽出来放到一个独立的中间件层本质上是解决三个问题第一个是能力复用。文档解析、OCR识别、表格还原、要素抽取、文本比对、格式校验——这些能力是所有文档类业务系统的公共需求。抽到中间件层之后OA系统能用合同系统能用档案系统也能用不需要重复开发而且输出数据的结构统一下游消费起来非常省心。第二个是模型解耦。业务系统不需要关心底层用的是ChatGLM、Qwen还是某个商用模型。中间件统一封装好接口上层只跟中间件打交道。底座模型想换就换只要中间件层做好适配和回归业务系统完全无感。这一点在模型迭代这么快的当下尤其重要。第三个是治理可控。哪些文档能进入模型处理、哪些敏感字段需要脱敏、调用记录怎么审计、权限怎么控制——这些治理能力必须在中间件层集中管控。散落在各个业务系统里根本没有办法形成统一的合规口径。这就像数据库中间件把读写能力从业务逻辑里抽出来一样AI文档中间件是把大模型相关的文档处理能力从业务逻辑里剥离开。Filez AI文档中台V9在架构上做的就是这个事情。1.3 Filez V9在中间件位置上的角色边界明确了中间件的定位接下来就要画边界V9到底管哪些事不管哪些事。从我的实践看V9作为中间件管的事可以分为四层文档接入层各类格式文件的解析、转换、OCR、知识处理层向量化、切片、索引、检索、模型编排层提示词管理、模型路由、输出结构化、能力服务层面向具体场景的高层接口比如公文起草、合同比对、要素抽取。这四层向上通过API和消息队列对外输出能力向下对接底层算力和大模型服务。边界之外的事V9不管也不应该管。比如业务流程的审批节点那属于OA和合同系统的职责比如最终的业务数据存储那属于各业务系统自己的数据库再比如组织架构和人员权限的主数据应该对接企业的统一身份认证体系而不是在V9里再搞一套。边界划清楚之后我们只把V9当成一个文档智能能力提供方业务系统负责编排流程V9负责把文档和模型之间的事处理好。还有一个值得说的地方借用中间件这个词意味着它必须具备足够的开放性。V9不是一套把业务锁死的封闭平台它的接口设计、模型接入方式、数据处理流程都留了扩展点这在后面对接我们的存量系统时省了很多事。2. Filez AI文档中台V9的能力剖面从解析到生成的全链路2.1 文档解析层比转成文本更深一层很多团队做文档智能化的第一步就做错了以为把PDF转成文本就完事。实际上一份真实的公文或合同版式信息、阅读顺序、表格结构、印章位置、手写批注全都是关键信息。丢掉版式信息直接做文本切片后续的要素抽取和语义理解准确率会大打折扣。V9的文档解析层我实测下来比较扎实的地方是它对复杂版式的处理。它先做版面分析Layout Analysis识别出标题区、正文区、表格区、页眉页脚、印章区再根据版面结构还原阅读顺序然后才对文本块做OCR或文本提取。这一步的价值在于后续不管做向量化检索还是做大模型的上下文拼接拿到的都是结构化的文档而不是一堆字。举个例子我们拿一份带骑缝章和复杂表格的工程合同去解析V9能准确识别出表格的行列结构而且把表头和数据单元格之间的关系保留了下来。这个能力在合同要素抽取时特别有用——合同总价在表格里对应的那一个数字不会跟预估金额投标保证金混淆。2.2 向量检索与知识库让模型回答有依据大模型在文档场景最大的风险是幻觉。一份合同里根本没写的条款模型可能一本正经地编出来一份公文中不存在的数据模型也能煞有其事地引用。要抑制幻觉最实用的手段就是RAG检索增强生成先把相关内容检索出来再让模型基于检索到的片段作答。V9的知识处理层在RAG链路的工程化上做得很完整。文档切片不是固定字数硬切而是结合章节标题、段落边界、表格结构做语义切分保留上下文完整性。向量化接口支持替换嵌入模型我们最终用的是bge-m3中文场景的表现比默认模型更好。检索阶段支持混合检索关键词和向量一起查再经过重排序模型bge-reranker把最相关的片段排到前面。这套链路走通之后我们的合同问答准确率明显上了一个台阶。用户问这个合同有没有约定仲裁条款系统不再是凭感觉回答而是明确告诉用户根据合同第X条第X款双方约定……还能顺便给出原文档引用链接。对于企业文档场景这种有据可查比答得流畅重要得多。2.3 生成与审核把大模型装进业务流程V9在生成和审核能力上不再是简单的给一段Prompt让模型生成文本而是把大模型嵌进具体的文档业务流程里。公文场景有起草、扩写、缩写、润色、审核合同场景有条款生成、风险点标注、版本比对说明。每个能力背后都有一套提示词模板和输出约束机制保证模型输出的格式稳定、内容可控。这里我要特别提一下结构化输出的设计。比如合同要素抽取V9的接口可以直接定义输出JSON Schema要求模型返回合同编号、甲方名称、乙方名称、合同总金额、付款节点、违约责任、争议解决方式等多个字段。模型必须按这个Schema输出字段缺失或者格式不对会被判定为抽取失败而不是返回一段自由文本让你自己去解析。一个小体验是有了Schema约束之后下游系统对接时数据结构天然对齐不需要再写大量的解析容错代码。3. 公文智能化的落地路径起草、审核、排版三段式3.1 起草阶段提纲先行素材库兜底公文写作和普通文章写作不一样它有固定的文种要求通知、请示、报告、函、纪要等有相对稳定的结构。直接让大模型写一份关于安全大检查的通知生成结果往往泛泛而谈缺乏实质性内容。我们实践下来更可靠的方案是提纲先行素材库兜底。具体操作是用户在V9的公文工作台里选择文种填写事由、发文单位、时间要求这几个要素系统先基于大模型生成一份提纲列出通知或请示、报告的开头、主体、结尾各部分要点。用户先审提纲确认方向没有问题再让模型逐段扩写。每扩写一段系统会自动检索企业内部的知识库把相关的制度文件、历史公文片段作为参考上下文避免生成的内容跟企业的实际制度脱节。这个流程最大的好处是人机协作而不是模型全包。提纲环节把方向定住扩写环节有素材库兜底生成出来的初稿质量明显比单纯一句Prompt生成的可用性高很多。我们的实测数据是一份常规通知的初稿起草时间从原来的40分钟压缩到8到10分钟后续人工调整主要集中在数据核对和个别措辞上。3.2 审核阶段格式校验与语义审查双通道公文审核是比起草更刚需的场景。传统人工审核一份公文要逐字逐句过一遍还要对照格式规范检查版头、主体、版记是否合规。这个过程既费时间又容易因为疲劳产生漏检。V9的审核能力设计了双通道规则通道和模型通道。规则通道跑的是可枚举的硬规则比如字体字号、行距、页边距、成文日期格式、印章位置等这属于传统的规则引擎就能解决的事不需要大模型。模型通道负责的是语义层面的审查比如语句不通顺、用词不规范、逻辑前后矛盾、数据引用存疑等这类问题需要理解上下文才能发现。双通道跑完之后V9输出一份审核报告逐条列出问题所在位置、问题类型、修改建议。我们的审核人员拿到的不是模型觉得有问题这样模糊的反馈而是结构化的问题清单可以直接定位到原文对应的段落。整体工作量估算下来一份五六页的公文审核时间从30到40分钟降到10分钟出头漏检率也有比较明显的下降。3.3 排版合规一个容易被忽略但极其重要的环节公文排版是一个看着简单、做起来极其繁琐的环节。标题用什么字体、几号字正文用什么字体、几号字行距是多少页码格式是什么落款位置怎么对齐都有严格规定。人工排一份长公文最少也要十几分钟而且不同人对规范的解读还会有差异。V9在排版这块做了一个很实用的功能审核通过后的公文可以直接按规范自动排版生成标准的格式化文档。你不需要记任何格式规则系统全部帮你处理。这块本身不涉及大模型是典型的文档处理能力但正是因为它和前面的大模型能力在同一个中间件里所以整个流程可以无缝衔接起草用模型审核用双通道最后排版用规则引擎一个工作台全部搞定。对于有大量公文处理需求的单位这个环节节省的人力是非常可观的。我们有个同事之前专门负责排版校对现在这部分工作量减少了大概七成。4. 合同智能化的完整管线从扫描件到风险标注4.1 第一步混合OCR把非结构化文本洗干净合同处理和公文最大的区别在于大量的存量合同是扫描件有的甚至是带手写批注、模糊印章、页面倾斜的扫描件。这种情况下解析环节直接决定后面所有环节的质量。V9的OCR策略是混合识别先对扫描件做图像预处理去噪、纠偏、增强对比度再走版面分析区分正文和表格区域表格区用表格结构识别模型还原行列关系正文区用文本OCR识别。对于带印章的区域它会额外做印章检测识别印章文字同时保留印章的位置信息。实际操作中需要注意OCR的质量直接影响后续要素抽取的准确率而OCR本身不可能做到100%正确。所以我们的流程里加了OCR置信度这个指标——低置信度的区域会标记为待人工确认而不是静默地把它当作正确文本传下去。这个小机制看起来不起眼但避免了模型在错误文本上做语义理解从而输出更离谱的错误结果。4.2 第二步要素抽取与条款风险识别文本干净了真正的大模型环节才开始。合同要素抽取简单说就是从一份几十页的合同里把谁、付多少钱、什么时候付、违约怎么办、争议去哪解决这类关键信息结构化地提取出来。V9在这个环节的做法是基于提示词工程加JSON Schema约束。系统会把合同文本按章节切好后送进模型模型按预设的Schema抽取出甲方、乙方、合同金额、付款节点、履约期限、违约责任、争议解决、知识产权归属、保密义务等字段。每抽取一个字段模型还要给出它在原文中的上下文引用方便人工核验。风险识别则是更高阶的能力。它能识别出合同中明显对某一方不利或者存在合规隐患的条款比如无限责任条款、单方解除权条款、管辖法院约定对己方不利、自动续约且未约定退出机制、违约金比例明显过高等。我们内部把V9的风险识别定位成第一道筛查法务人员依然会做最终判断但有了这道筛查很多明显的坑会第一时间被标记出来法务可以集中精力去处理真正复杂的问题。4.3 第三步版本比对与业务系统回写合同从初稿到定稿中间通常会经历多轮修改。对方发来一个修改版只告诉你你看看改了什么你得自己去逐页找差异这个场景做过的朋友都知道有多痛苦。V9的版本比对能力不是简单的文本Diff而是结合了大模型语义理解的结构化比对。它能识别出同一句话换了一种表述但含义相同的情况也能指出新增了违约条款这种实质性变化。比对结果按条款组织清晰标注新增、删除、修改和语义等价四类情况。版本确认之后V9可以把抽取到的结构化数据通过API回写业务系统合同管理系统自动生成台账记录法务平台自动创建审核任务财务系统拿到付款节点等字段做后续排期。这一步让合同智能化从文档层面真正延伸到了业务层面也是选择中间件方案而不是单点工具的最大价值所在。5. 大模型选型与本地化部署的取舍5.1 为什么放弃通用API选择私有化部署在规划阶段我们认真评估过直接调用国内各大厂的通用大模型API。从效果上讲商业API的通用能力确实很强尤其是在长文本理解和生成上表现稳定。但最终我们没有选这条路核心原因是三个第一是数据安全。合同和公文里装的是企业最核心的敏感信息很多还涉及商业秘密。即使服务商承诺数据不留存公司的合规部门也过不了这一关。第二是成本不可控。我们的文档处理量是有明显峰谷的月结、季结的时候合同审核量暴涨按API调用量计费峰值月份的成本让人肉疼。第三是定制能力受限。通用API没法针对我们的公文模板和合同要素Schema做专门的适配也就无法沉淀出属于我们自己的文档处理资产。所以最终方案是私有化部署开源模型加上微调和提示词层面的大量定制。V9本身对模型接入做了抽象底座模型是可替换的这一点给了我们很灵活的迭代空间。5.2 开源模型选型按场景匹配参数规模选型这事我的核心经验是按场景分模型不要一个模型打天下。公文起草和润色需要较强的中文写作能力和指令遵循能力合同要素抽取需要稳定的结构化输出和较长的上下文理解能力语义检索和重排序又是完全不同的技术需求。我们的底座模型最终选了Qwen系列的开源版本7B的Qwen2.5作为日常公文起草和对话的主力跑在单张消费级显卡上就能获得不错的性能合同文本理解因为涉及长文档和复杂逻辑用14B的版本效果和算力之间相对平衡。检索增强链路里的嵌入模型用bge-m3重排序模型用bge-reranker-v2-m3这两个是当前中文语义理解场景下性价比很高的选择。如果你们预算和算力都更充裕可以直接上量化后的72B版本效果会有明显提升但对应的显存和推理延迟也要提前做好评估。5.3 量化与推理框架显存、吞吐与延迟的平衡本地部署最大的现实约束是GPU。我们最初用一张RTX 4090 24GB跑7B模型的FP16版本勉强能跑但吞吐不够。后来做了GPTQ 4bit量化显存占用从16GB左右降到6到7GB单卡并发能力明显提升。14B模型跑了AWQ 4bit量化显存占用大概10GB出头单卡也能扛住。推理框架我们对比过vLLM和Ollama。vLLM的吞吐表现是明显更好的尤其在多并发场景下它通过PagedAttention等机制把显存利用率拉得很高Ollama胜在部署简单适合小规模试用。我们用vLLM作为正式环境的推理引擎配合官方的OpenAI兼容接口V9对接起来非常顺滑。这里有一个坑要提醒量化会带来一定程度的精度损失文本生成类任务体感不明显但在要素抽取这种对格式要求严格的任务上偶尔会出现字段截断或格式跳变。我们的应对方案是在提示词里反复强调输出格式同时加一层JSON Schema校验一旦发现格式不符就自动重试一次二次失败才判定为抽取异常转人工。5.4 微调什么时候值得做什么时候是浪费很多团队一上来就想着微调模型这是最常见的技术路线误判。以我们的经验先做RAG加提示词工程能解决的问题尽可能不要动用微调。原因很简单微调需要高质量数据集构建数据集本身就是大工程而且微调后的模型在通用能力上可能会有轻微回退。但如果出现以下情况微调就是必要的一是提示词怎么调都调不动模型始终不按你的格式要求输出二是需要模型掌握大量领域知识而这些知识难以通过检索完整覆盖三是业务场景非常垂直比如你希望模型能自动识别某个行业合同里特有的条款类型通用模型基本没见过这类表述。我们目前微调了一个7B的LoRA模型专门用于合同风险识别。训练数据来自法务团队标注过的500多份合同大概1万多条条款-风险类型-依据三元组。用LoRA在一个消费级显卡上训练了不到半天效果提升很可观风险类型识别的F1值涨了好几个百分点。这里要强调微调解决的是让模型更懂你的业务语言不是解决模型不懂常识的问题。别指望用微调弥补基础模型的能力短板。6. 上线4个月的实测反馈与踩坑记录6.1 公文场景效率提升背后的隐性成本上线4个月公文起草场景的效率数据很亮眼初稿生成时间从40分钟降到8到10分钟审核从30到40分钟降到10分钟左右。但我也要说清楚背后的隐性成本提示词和审核标准的持续迭代不是一次性投入。刚开始我们用V9生成公文初稿后业务部门的反馈是看着通顺但总感觉少了点专业味道。后来分析发现问题出在提示词里的示例不够具体模型缺少对本企业内部公文风格的参考。解决办法是把历史优秀公文脱敏后整理成几十组示例放进提示词的少样本里生成质量立刻上了一个档次。类似这种调优工作前两个月基本每周都要做需要安排专人负责不能把V9部署完就当甩手掌柜。6.2 合同场景准确率数据与人工复核机制合同要素抽取的准确率我们统计的F1值在0.88左右合同金额、付款节点这类结构化字段的准确性更高能达到0.93以上。风险条款识别的召回率在0.8出头也就是说还有不少风险点会被漏掉。这个数据我必须坦诚地说合同审核绝对不能完全依赖模型人工复核依然是必需品。所以我们的流程设计是机器筛查在前人工复核在后。机器把所有可能的风险点都标出来法务人员只需要关注被标记的位置集中判断这些点是不是真问题。这样既发挥了模型在速度上的优势又通过人工把关保证了最终质量。凡是合同审核类场景我建议一定要保留这个人工复核环节不要因为追求自动化率而牺牲业务安全性。6.3 三个值得记录的坑第一个坑是切片粒度与上下文丢失。合同里很多关键约束分散在文档的不同部分比如违约责任以补充协议为准这种话不在违约责任条款里而在附件里。用固定长度的切片做检索很容易漏掉这类跨章节的关联信息。我们的解决办法是适当加大切片重叠度同时在做要素抽取时把全文概览作为额外上下文送给模型让模型先理解整体再看局部。第二个坑是表格数据的误读。OCR对复杂表格的行列对应关系偶尔会判断错导致金额、日期这些数据抽取串位。AI模型本身无法发现这种错误因为它没有原文档长什么样的直观判断。后来我们加了一个校验逻辑凡是表格里抽出来的关键数字必须与邻近文本中提到的金额做交叉验证不一致就标记为待确认。效果相对有限主要是靠这种启发规则兜底。第三个坑是提示词越长效果不一定越好。一开始我们为了让模型输出更稳定把提示词写得很复杂各种说明和示例堆了一大堆结果反而适得其反。经过多轮实验发现把提示词里最核心的约束放在最前面示例控制在五组以内对模型的表现是最友好的。这跟人看说明书一样重点不突出等于没重点。7. 如果想要复制这套方案先想清楚这几件事7.1 业务边界要先于技术边界确定引入AI文档中间件首先想清楚的不是用什么模型而是这个平台管哪些业务。公文审核、合同抽取、知识库问答、档案智能检索——这些场景互相之间有交集但数据隔离要求、准确率要求、响应时效要求都不同。先定义清楚每个场景的输入输出和验收标准再去配置V9的能力才不会在实施过程中陷入反复。我们当初犯过的错是没一开始就划定清楚敏感文档自动脱敏后处理和敏感文档不走模型链路的边界。后来法务部门提出有几类合同绝对不能进模型链路我们重新调整了权限配置把这几类文档隔离在模型服务之外。这个调整在架构上不复杂但在流程和数据治理上差点造成返工。7.2 提示词资产要与业务沉淀同步管理V9给我最大的感触是提示词是一等公民是需要持续管理和迭代的资产。我把所有的提示词模板做了版本管理每次调优都记录变更原因和效果对比。上线几个月下来公文的起草提示词迭代了十几个版本合同抽取的提示词也改了七八轮。如果这些改动用完就丢下一次要回溯问题时将非常痛苦。建议围绕提示词建立一套简单的管理规范每类场景一份主模板模板变更必须有版本记录重大变更必须跑一遍回归测试确保新版本不会把之前已经正常的问题重新引出来。7.3 验收标准不要只盯着准确率最后想说的是验收标准。做文档智能化的团队很容易陷入对准确率、召回率这些指标的过度关注。准确率当然重要但从业务角度更要关注的是单位处理成本和端到端耗时。模型准确率差一个百分点如果人工复核流程能兜住业务体感可能区别不大但如果我们能把一份合同的处理时间从2小时降到20分钟这个改变对业务部门来说就是天翻地覆的。我们在验收V9的时候定了三个核心指标单份文档处理时间、人工介入比例、关键字段抽取准确率。三个指标综合起来看才能衡量一套文档中间件在真实业务流程里的价值单独看任何一个数字都是片面的。上线这几个月我越来越觉得文档智能化的本质不是用AI替代人而是把文档工业里那些重复、繁琐、低价值的部分自动化让人集中精力去做真正需要判断力的事。公文起草不是AI替你承担行文责任合同审核也不是AI替你承担法律后果但AI能把你在这些事上花的时间从几小时压缩到几分钟让你有余力去思考更本质的问题。这大概就是文档中间件这一层存在的最大意义。
