接手企业数字化建设这几年，我最大的体会是：文档处理是所有业务系统都绕不开、却又最容易被低估的一环。尤其是公文和合同这两类典型的高价值文档，它们格式要求严格、术语密度高、审批链路长，而且出错代价极高。过去我们尝试过让业务系统各自对接大模型，结果不到两个月就乱了——有的团队调通用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能把你在这些事上花的时间从几小时压缩到几分钟，让你有余力去思考更本质的问题。这大概就是文档中间件这一层存在的最大意义。
