做文档系统的人都知道“存、管、协作”只是基本功真正的价值在于把文档里的内容变成可计算、可调用、可决策的数据。这次围绕 Filez AI文档中台V9 的实践本质上做了一件事把大模型能力通过文档中间件的方式注入公文写作和合同审查这两个高频办公场景。简单说就是让系统能看懂文档、能按要求处理文档、还能把结果用可靠的方式吐出来。这篇内容适合正在做企业文档平台、知识管理系统或者想往办公场景里接大模型但不知道从哪下手的同学参考我会把这套方案的设计逻辑、核心实现、踩坑记录和落地经验完整写出来。1. 从“存文件”到“懂内容”文档中间件要补上的一课1.1 文档系统老三样解决不了的痛点传统文档系统做了这么多年核心能力基本围绕三件事存储、协作、权限。文件能传上去、能多人编辑、能设置谁能看谁能改到这一步绝大多数企业就觉得自己“文档管理做得不错了”。但真到了公文和合同这种强业务场景问题马上暴露。公文是什么是有固定格式、固定要素、固定语体的材料。一份通知、一份报告、一份会议纪要里面的标题、主送机关、正文、落款每一块都有规范写得好不好往往要经验丰富的老员工逐字逐句把关。合同更麻烦动辄几十页条款密密麻麻法务要逐条比对金额、期限、违约责任、争议解决方式一个数字不一致后面可能就是几百万的纠纷。这类工作不是“存”能解决的也不是“搜”能解决的。传统文档系统里有个全文检索把关键词一搜出来一堆文件然后呢还是得人肉打开一一核对。文档系统缺的是一个“消化层”——把文档里的非结构化内容拆解成结构化信息再按业务规则和模型能力进行加工。这个消化层就是我现在说的文档中间件。1.2 大模型进文档场景卡点到底在哪大模型确实很强强在语言理解、强在生成、强在能按你给的上下文回答问题。但直接拿大模型去处理企业正式文档会遇到一长串问题。第一个卡点是格式。企业文档的主流格式是docx、wps、pdf里面还有表格、页眉页脚、批注、扫描件。大模型的输入是文本你得先把这些格式干净地解析成纯文本而且不能丢信息。一个合同扫描件如果不做OCR模型看到的就是一堆乱码自然什么都干不了。第二个卡点是长度。一份完整的合同可能有几万字超过模型的上下文窗口。就算窗口够大把全文塞进去模型也会“迷失”——前面的条款忘了后面的条款又覆盖了前面的关注点抽取结果的准确率会断崖式下跌。第三个卡点是可信。公文和合同都是强业务材料模型如果凭空生成了原文里没有的条款或者把金额算错没人敢用。要让模型“说话有依据”必须要求它引用原文位置、给出可回溯的出处。第四个卡点是权限和数据安全。企业文档有严格的访问权限同一个合同法务能看销售未必能看。大模型调用如果不做权限控制等于把机密文件泄露给所有能问系统的人。这些问题凑在一起结论就很明确了不能简单地把文档往模型里一扔了事需要在文档和大模型之间加一层做转换、约束、防护的中间层。Filez V9 的 AI文档中台本质就是把这层做成了标准化能力而不是每个业务场景单独搞一套模型接入这也是我这次实践里最有感触的一点。2. 方案选型与整体架构为什么用中间件而不是套壳2.1 Filez V9 的定位把文档处理能力前置成标准化服务接到这个项目的时候需求方其实提得很直白我们要做一个“AI公文助手”和一个“AI合同助手”。如果按传统思路那就是两个独立的功能模块各自对接模型、各自做文档解析、各自写提示词最后得到两套互相不通的系统。但这两者的底层能力高度重合——都要解析文档、都要切片向量化、都要调用大模型、都要做权限校验、都要做流式输出。所以我坚持把中间公共能力抽出来做一个文档中间件层。Filez AI文档中台 V9 的核心价值也在这个地方它把文档接入、解析、索引、检索、模型编排、输出协议、安全审计这些事情全部封装成标准接口上层的公文应用和合同应用只管写自己的业务逻辑。用中间件有三个直接好处。第一是复用文档解析和向量化只做一遍所有应用共享第二是解耦模型升级或替换不影响业务层今天用这个模型明天换成另一个中间件内部改配置就行第三是可控权限校验、审计日志、内容安全过滤都集中在中间件层完成避免每个应用各搞一套导致漏管。2.2 模块拆解解析、索引、编排、输出四件事具体到 Filez V9 的架构我会把它拆成四个层次来说明。接入层负责连数据源。企业文档基本都在域内的共享存储、网盘系统或者业务系统里接入层要把这些文档拉取或挂接进来同时拿走原生的权限元数据。这个非常关键因为后续的权限过滤完全依赖这一层在入口处把用户的身份和文档所有者关联起来。解析层是整个方案的底座。docx 用 zip 包解析提取正文段落、表格、样式和结构pdf 按文字版和扫描版分流扫描版接 OCR 识别表格要做单元格级别的还原因为合同里的金额、日期经常在表格里。这里有一个原则宁可多保留结构信息也不要压成一段平铺的纯文本否则后面切片和抽取都会很难受。语义索引层负责把切好的文档块做 embedding存入向量库同时保留每个块对应的原始位置信息页码、段落编号、表格行号。公文和合同场景不建议只做向量检索要配合关键词检索做混合召回因为合同里的“金额大写”“违约责任”这类强术语向量匹配不一定准关键词却能稳准狠地命中。模型编排层是核心业务逻辑所在。它接收来自应用层的任务请求根据任务类型选择合适的模型和提示词模板结合检索结果组装上下文再调用模型推理。所有模型返回结果都要经过一层格式化校验比如 JSON 解析、字段校验、原文引用检查不合格的直接触发重试或降级策略。输出层统一走 SSE 做流式返回同时做操作审计谁在什么时间用什么文档问了什么都有记录。2.3 模型层设计可插拔与混合调度行业内现在的模型选择很多通用大模型、开源垂类模型、本地部署模型都有。真实项目里我没见过只用一家模型的更常见的做法是“混合调度”先把任务按难度和敏感度分类再决定用什么模型。公文写作这种对生成质量要求高、上下文逻辑强的任务适合用能力更强的通用模型合同条款抽取和比对如果用本地知识库配合 RAG中小规模模型微调之后也能达到不错的准确率而且数据不出域合规性更好。Filez V9 的中间件层做了模型网关业务方不用管后端接的是哪家只面向统一接口开发。这样还有个好处模型供应商偶尔抽风网关可以把流量切到备选模型上不至于整个业务瘫痪。模型的可插拔还带来一个实操上的便利——评估选型。我先用同一个测试集跑多个模型对比输出质量和速度再决定默认路径。这个过程不用改任何业务代码都是中间件的配置改动节省了大量比选的工作量。3. 公文智能化落地从要素抽取到合规校验3.1 公文写作辅助的完整链路公文这个场景我一开始以为模型随便就能写好结果做下来发现真正的难点不在“生成”而在“规范约束”和“参考材料使用”。公文写作有一个特点它不是凭空创作是“给定材料出成品”。比如写一份工作总结需要先汇总各部门的业务数据写一份通知需要明确依据、事项、时限。所以我把公文助手的链路设计成“材料输入—要素抽取—提纲生成—初稿撰写—格式校验”五步。用户上传一批参考资料系统先把这些文档全部解析、切片、向量化存成临时的项目语料库。然后让大模型做要素抽取抽出发文单位、文件类型、核心事项、时间节点、涉及对象用抽取结果生成写作提纲。提纲经用户确认后再基于语料库做 RAG 式检索生成初稿每个段落都带上出处引用。初稿出来之后进格式校验环节检查标题层级、字体段落、落款位置这些硬性规范。这一步的重点是给业务方一个“可干预”的窗口。公文不是全自动生成的写的人需要在关键节点上有控制权。所以产品上我留了提纲确认和段落编辑两个交互点系统生成的只是可修改的初稿而不是定稿。这样既提升了效率又保住了人的最终决策权。3.2 规则与模型的分工不能全交给大模型很多做 AI 文档的人容易走一个误区既然大模型这么强那就什么都让模型来。实际上在公文这种格式极其固定的场景规则系统的效率和准确率远高于模型。格式校验就是典型的规则活。公文用几号字、标题怎么断行、落款怎么对齐、页码怎么编这些是明确的标准用正则和模板校验一两毫秒就出结果准确率百分之百。如果让模型来做不但反应慢还会出现“自以为对了但实际格式错了”的幻觉。我和研发敲定的分工方式是凡是“有明确标准、可枚举、可用逻辑判断”的事情全部走规则引擎只有“需要理解语义、需要归纳总结、需要根据材料生成”的事情才交给大模型。具体到公文场景要素抽取、提纲生成、正文撰写用模型格式检查、敏感词过滤、要素完整性核对用规则。这个分工在效果和成本之间取得了很好的平衡。公文的硬性错误被规则引擎拦住模型的调用量大幅减少因为很多文件根本不需要生成正文只需要检查格式或者只做要素抽取成本自然降下来了。项目上线之后我统计过在综合办公场景里接近一半的请求根本不会落到大模型上纯规则直接给出结论。公文生成部分的 Prompt 设计我也总结了一个模板思路。系统提示词里固定了三块角色定义你是谁、任务定义你要干什么、输出约束按什么格式输出。核心约束是“依据参考材料作答不得虚构引用材料中不存在的政策依据和数字”这个约束配合 RAG 的出处引用能显著降低编造概率。用户侧还提供“正式”“简洁”“详尽”三种语气档位通过少量示例实现不必每个功能单独训练模型。4. 合同智能化落地条款审查与风险抽取的工程实现4.1 合同审查任务拆分抽取、比对、报告合同场景和公文完全不同公文重生成合同重分析。一份合同拿来法务关心的是关键条款有没有缺、标的金额是否前后一致、付款期限是否明确、违约责任是否对等、管辖约定有没有问题。这些任务本质上是对合同文本进行结构化抽取和逻辑校验而不是让模型写出一个新合同。我把合同助手拆成了三轮流水线。第一轮叫“要素抽取”从合同文本中抽出合同双方、标的物、总金额、大写金额、付款节点、发票类型、保密期限、违约条款、争议解决方式等关键字段统一转成 JSON 结构第二轮叫“逻辑校验”针对抽取出来的结构化结果做一致性检查比如大小写金额是否一致、付款节点与交付节点是否逻辑冲突、违约责任是否双方都约定第三轮叫“风险报告”把前两轮的结果汇集成一页可读性强的审查报告按风险等级排序给出修改建议。这个流水线设计里最重要的一点是把“抽取”和“生成报告”分开。抽取是严格的、结构化的要求模型只输出 JSON不能有废话报告是可以带解释的要求模型把风险点说清楚。如果混在一起模型既要做结构化又要做自然语言输出质量会很不稳定经常出现明明抽取对了但解释跑偏的情况。4.2 结构化输出与原文溯源把幻觉压到最低合同审查最不能接受的就是模型幻觉。法务拿你生成的报告去修改合同如果报告里出现一条合同里根本不存在的风险点那个后果是实打实的法务纠纷。所以我从一开始就对模型做了两条硬约束一是所有抽取结果必须回填原文引用二是所有风险结论必须对应到具体条款号。技术上是怎么做的模型输出的 JSON 里每个字段除了 value 之外还有一个 evidence 字段存放来源片段通常是条款号加原文句子。比如提取到“合同总金额: 1,000,000 元大写壹佰万元整”evidence 字段就指向第三条第二款。系统侧写了一个校验模块在模型返回后验证 evidence 是否真的存在于原文档切片中如果找不到原文对应就认为本次抽取不可信自动触发重抽。为了进一步压降幻觉我还给模型加了“可拒答”的开关。模型如果觉得某份合同的某个条款提取不出来可以直接在字段里返回 null并在 confidence 里给一个低置信度而不是硬编一个结果。系统对这种空值会走人工标记流程。这相当于给模型留了一个“不知道就说不”的出口实测下来整体字段准确率比强行让模型作答高了不少。一致性的逻辑校验这块我用的是规则模型结合。比如金额数字大写小写校验、日期格式校验、合同主体名称是否出现在盖章区域这些用代码写逻辑判断而条款语义的合理性比如付款时间和交付时间是否矛盾这种需要理解业务逻辑的才让模型来做。整个项目里合同审查的用户采纳率能到 80% 以上靠的就是这种“能算就算、不能算就查、查不到就明说”的保守策略。5. 核心实现细节切片、提示词、流式输出5.1 文档切片决定效果上限的第一件事很多人做大模型文档应用把精力都花在调提示词上我却发现真正的效果分水岭在切片策略。同样的模型切片方式不同抽取准确率能差出二十个百分点。这就像让人读材料材料被工整地分好章节段落和揉成一大团给你看阅读理解效率完全不同。我用的切片策略是“结构优先 语义补全”。先解析文档的标题层级结构以一级标题、二级标题作为天然边界把文档切成一棵结构树而不是无脑按固定字符数切。合同这种规范文本最合适一个章节往往就是一个完整语义块“违约责任”这一整章切在一起模型能看到完整的责任条款而不是被拦腰截断。对固定字符数切片我做过两个关键处理。一个是重叠窗口相邻切片之间保留 100 到 150 个字符的重叠避免一个条款刚好被切断导致信息丢失另一个是表格式内容强制整块保留不能把一张完整的金额表拆成两半。建的向量库我特意记录了每条切片对应的文档ID、版本号、页码、段落序号这些元数据在最终溯源时都要用到。检索时默认只召回相关度高的 top 5 切片控制输入长度同时也减少无关片段对模型判断的干扰。5.2 Prompt 模板让模型按业务逻辑说话模板这块我踩过不少坑总结出来的经验是结构化输出的提示词必须给示例必须给边界。只有一句话“请抽取合同关键信息”是不够的模型会随机发挥。我的合同抽取模板大概长这样你是合同审查助手。你的任务是从用户提供的合同文本中抽取指定字段。 字段列表contract_name, party_a, party_b, total_amount, amount_uppercase, payment_terms, delivery_date, penalty_clause, dispute_resolution 输出要求 1. 只输出JSON对象不要输出解释。 2. 每个字段包含value和evidenceevidence必须是合同原文原句。 3. 如果某字段在合同中未出现value返回nullconfidence返回0。 4. 禁止编造原文中不存在的信息。 示例 {contract_name:{value:设备采购合同,evidence:本合同为设备采购合同,confidence:0.99}}这个模板看起来简单但每个约束都有大用。“只输出JSON”保证了下游能被代码直接解析“evidence必须是原文原句”给溯源提供了基础“value返回null”给了模型合法的拒绝路径“示例”是对模型输出惰性最好的校准。公文生成模板又是另一套结构。生成前先给模型导入参考材料摘要和相关段落再给出当前文件类型的写作规范最后才让模型开始写。关键提示词是“严格基于参考材料不添加参考材料之外的业务数据和事实性信息”。这样处理之后公文里的数据基本都能在材料里找到对应审阅的人在追溯时也能轻松核验。5.3 SSE 流式输出页面侧怎么配公文和合同审查都涉及长文本生成或长报告生成等待时间动辄十几秒。如果只用普通 HTTP 请求用户盯着一动不动的小菊花体验会非常差。这个项目里我把所有生成类接口都改成了 SSE 流式输出实现逐字推送首字延迟控制在 1 到 2 秒内用户看到内容开始滚动等待耐心就大幅提升。前端实现我会特意说一下因为这里的坑比后端多。用 fetch 发起请求时设置 stream: true然后通过 ReadableStream 逐步读取响应文本。读取的每一块数据都要按 SSE 格式解析注意处理“数据跨包”的情况也就是一个输出片段被 TCP 包拆成两段的情况需要拼接后按换行符切分。前端同时要维护一个允许取消的 AbortController。用户如果觉得生成内容跑偏了点一下停止前端立即调用 abort 终止请求后端收到信号也要中断模型推理释放计算资源避免继续白白计费。这个取消链路的完备程度是我做这个项目时反复检查的一个点因为跑测中真的出现过前端断了、后端还在继续生成的情况。页面渲染侧为了让长报告刷起来更顺滑我没有直接渲染流式字符串而是在前端做了一个“按段落刷新区”的逻辑只有在流式文本出现了可能的结尾标点句号、换行、表格结束符时才触发DOM更新避免每个 token 都刷新一次导致浏览器卡顿。这个优化折腾了一晚上效果立竿见影长报告页面帧率稳定很多。6. 实测中的坑与排查手册6.1 长文档、扫描件、复杂版式怎么处理这个项目落地过程中我记录了一批高频问题挑几个有代表性的按现象、原因、解法整理出来。第一个问题长合同抽取结果漏条款。一份四十页的合同指定要抽二十个字段结果模型只返回了十五个漏掉的多集中在合同末尾的补充协议部分。后来定位是切片召回问题补充协议的语义和前文相似度没那么高向量检索没召回到。解决办法是调整检索策略把“基于向量相似度召回”改成“按文档结构强制覆盖式召回”将文档按章节分块后每个章节都至少有一个片段进模型上下文字段覆盖率大幅提升。第二个问题扫描版合同 OCR 结果错乱。扫描 PDF 本身解析出来是图片集成 OCR 后模型经常把“定金”识别成“订金”“百分之”识别成“百分 之”。这类问题靠调提示词解决不了只能在 OCR 后加一道“术语纠偏”层用合同领域的常见术语词典做替换纠正。同时把 OCR 的置信度信息透传到下游低置信度的区域强制人工复核避免模型在错误原文基础上越走越远。第三个问题插入密级标记或页眉页脚后表格错位。扫描 OCR 生成的文件会把页眉页脚和正文表格混在一起导致表格结构识别错误。解决方案是在解析阶段把页眉页脚区域识别并过滤掉只保留真正的正文区域。这一步别看简单处理不好所有表格抽取的准确率都会一起崩。6.2 权限隔离、审计与内容安全怎么做企业级文档应用权限隔离是底线。Filez 这类文档系统本身有成熟的权限体系中间件要做的事情是把它延伸到 AI 检索链路里。具体是这么做的检索入口接收当前用户身份先从权限系统批量拿到用户可访问的文档ID列表建立会话级白名单。向量检索的结果必须落在白名单内白名单之外的文档即使向量相似度再高也一律拦截。这个拦截不是在前端兜住的而是在检索模块内部完成保证绕过 UI 也拿不到权限外内容。内容安全这块我在中间件层设置了双保险。输入侧对用户上传的文档做格式和大小校验并对提取到的内容进行合规检查识别潜在的风险类型输出侧对模型生成的文本做敏感词过滤和策略校验拦截违规范表述。所有调用大模型的记录包括用户身份、访问的文档、提交的问题、模型返回内容统一写入审计日志按周归档。审计不只是为了运维排障更是为了事后责任追溯这个在企业采购评审的时候几乎是必查项。权限还有一个容易漏的细节版本缓存。同一份合同被频繁编辑会有多个版本如果 AI 检索直接命中旧版本给出的结论就过期了。我在索引层维护了文档版本号编辑后触发重新解析和重新索引并标记旧版本索引为失效。这样能让“AI 看到的”和“用户当前访问到的”保持同步避免因为版本不一致导致审查结论错误。7. 从 POC 到生产的经验评估、成本、模型选择7.1 怎么判断一个 AI 文档功能真的能上线从 POC 到生产这段路比很多人想的长。有些功能演示时效果惊艳但一放到真实场景就崩原因在于测试样本太干净。真实企业文档满是批注、修订痕迹、历史版本、乱码符号模型毫无抵抗力。我定了一套上线评估门槛一个 AI 文档功能至少要过四关。第一关是“样例集准确率”用 50 份真实脱敏文档做测试集抽取类任务准确率不低于 90%生成类任务可接受率不低于 80%第二关是“抗噪声测试”故意混入重复段落、乱码字符、OCR错误文本看系统会不会崩溃准确率下降不能超过 10 个百分点第三关是“边界行为测试”给模型发越权文档、超大文件、空文档看系统能不能优雅拒绝而不是报错第四关是“成本护航”单次调用的平均成本要低于业务方设定的阈值否则功能再好也很难持续运营。这套门槛看起来繁琐但它在筛掉“演示型功能”上非常有效。我见过不少项目在演示PPT里效果惊人结果一上生产就翻车核心原因就是没做抗噪声和边界行为测试。早点设好关卡后面运维会省心得多。7.2 成本优化级联策略与模型分级最后说成本因为这是所有 AI 项目绕不开的问题。直接让大模型处理所有文档账目很快就撑不住。我在这套体系里用的核心策略是“先规则后模型”的级联以及按任务难度做模型分级。以合同审查为例一份合同进来先走规则引擎做格式检查、数字一致性校验、条款完整性判断。只有规则引擎无法确定、需要语义理解的环节才转发到模型。实测大约百分之六十的合同问题能被规则层直接定位只有剩下的百分之四十才消耗模型算力。这一层裁剪让整个项目的模型调用次数下降了一倍以上。模型分级方面我按任务的容错度把模型分成三档。第一档是强逻辑、强生成、容错度低的任务比如公文正文生成、合同风险报告用能力最强的通用大模型第二档是抽取类任务比如合同要素抽取、会议纪要结构化这些任务语言逻辑相对简单、模式固定用开源中小模型加微调就能胜任成本只有大模型的十分之一左右第三档是纯规则可替代的任务一律不调用模型。这样分配下来项目的单位文档处理成本被压到了一个相当可观的数字业务方也真正愿意把功能推广到全公司使用。模型的选择上我不太建议一上来就微调。先用通用模型配合 Prompt 和 RAG 把业务跑通收集足够的标注数据后再考虑微调这样微调的起点更高、迭代路径更清晰。毕竟对于文档场景RAG 带来的实时知识和出处依据比微调更依赖微调更多是优化输出格式和领域措辞。等到模型调用量足够大、数据积累足够多再启动微调才能把性价比打磨到最优。这个项目从设计到落地折腾了几个月回头看过往路径最大的体会就是给文档场景接入大模型重活不在“接入模型”这个动作上而在模型之外的文档解析、切片策略、权限融合、输出约束和成本取舍。哪一块做扎实了项目的稳定性就高一块。尤其是切片和权限这两块一个决定模型能力的上限一个决定系统能不能真正走进企业生产环境。公文和合同这两个场景做下来我越发觉得好的 AI 文档产品不是拿大模型炫技而是把文档处理这门老手艺研究透之后再把模型恰到好处地嵌进最需要它的环节。