办公文档处理这块很多人第一反应是直接丢给大模型结果要么超长上下文爆掉要么推理慢得让人想砸键盘。我在做一个本地AI前置预处理模块时踩了一圈坑才想明白真正决定整套系统能不能跑起来的不是模型本身而是文档进来之后、模型调用之前的那一层——分片策略和L0硬规则调度。这篇就把我在Node.js环境下做这层的完整思路和踩坑过程摊开讲包括怎么切文档、怎么用自然语言硬规则做前置过滤、调度器怎么设计才不会把自己绕进去。适合正在做本地AI应用、需要处理大量办公文档、又不想被大模型成本和延迟绑架的开发者参考。1. 为什么前置预处理层值得单独拎出来做1.1 直接调模型的三个现实问题我最初的做法很朴素用户上传一个Word或者PDF解析出纯文本拼上prompt直接发给本地模型。跑第一个demo的时候感觉良好等到真实办公文档进来问题全暴露了。第一个问题是上下文长度。一份带表格和附录的项目方案纯文本轻松超过三万字本地部署的模型上下文窗口往往只有8K到32K直接塞进去要么截断丢信息要么报错。第二个问题是推理延迟。本地模型在消费级显卡上跑一次生成几百token就要好几秒如果每个文档都全量送进去用户等一轮下来体验极差。第三个问题是成本与资源占用。本地部署虽然没有API费用但显存和算力是实打实的瓶颈并发几个请求就把机器拖垮。这三个问题指向同一个结论不能把原始文档直接喂给模型中间必须有一层做减法和结构化。1.2 前置预处理层到底负责什么我把它定义成三个职责。第一是分片把长文档切成模型能消化的块同时保证语义不被切碎。第二是L0硬规则过滤用自然语言描述的规则做快速判断把明显不需要模型介入的内容挡在外面比如页眉页脚、空白段落、重复的免责声明。第三是调度决定哪些分片先送模型、哪些可以合并、哪些直接走规则出结果。这一层的价值在于它把模型要处理什么这件事从模型手里抢了过来。模型只负责它真正擅长的语义理解和生成脏活累活前置层干完。实测下来加了这层之后同样的文档集模型调用次数能降到原来的三分之一左右端到端延迟下降一半以上。1.3 为什么选Node.js来做这层有人会问文档处理和AI不都是Python的天下吗为什么用Node.js。我的考虑是这层本质上是IO密集型的编排逻辑不是计算密集型。它要同时处理文件读取、分片、规则匹配、任务队列、和本地模型服务的HTTP通信这些全是异步IO。Node.js的事件循环模型天然适合这种场景而且如果前端也是JS技术栈整条链路可以共用类型定义和工具函数。本地模型服务通常单独跑一个进程通过HTTP暴露接口Node.js这边用axios或者原生fetch调用就行不需要在同一个进程里加载模型。这种解耦让预处理层可以独立部署、独立扩容。2. 办公文档分片切得对不如切得巧2.1 按固定长度切是最省事也最坑的做法最开始我用的是最粗暴的方案按字符数切每2000字一片重叠200字。跑起来没报错但结果惨不忍睹。一个完整的操作步骤被从中间切断模型拿到半句话根本不知道在说什么表格被切得七零八落行列对应关系全丢了。固定长度切分的根本问题是它不理解文档结构。办公文档是有层级的标题、段落、列表、表格、代码块每一级的语义边界都不一样。按字符切等于无视这些边界把语义单元打碎。我后来改成按结构感知的方式切。先用解析库把文档转成带结构标记的中间格式然后按标题层级和段落边界来切。具体来说一级标题到下一个一级标题之间算一个大块如果这个大块还是超长再按二级标题切以此类推。段落是最小切分单位绝不从段落中间断开。2.2 不同格式文档的解析差异办公文档格式五花八门解析方式差别很大这里踩的坑最多。Word文档.docx相对好处理用mammoth或者docx这类库能拿到带样式的HTML或者结构化文本标题层级信息保留得比较完整。但要注意很多Word文档的标题是手动加粗放大的并没有用真正的Heading样式解析出来全是普通段落。这种情况需要做启发式判断字号明显大于正文、加粗、独占一行、前后有空行满足这些条件就当成标题处理。PDF是最麻烦的。文本型PDF用pdf-parse能提取文字但阅读顺序经常是乱的尤其是多栏排版提取出来会串行。扫描型PDF更麻烦得先走OCR。我的做法是PDF先尝试文本提取如果提取出的文字密度过低比如每页少于100字就判定为扫描件转走OCR流程。多栏PDF目前没有特别完美的方案我的折中是按坐标聚类把x坐标相近的文本块归到同一栏再按y坐标排序。Excel和PPT这类办公场景里通常是作为附件或者补充材料我的处理是提取纯文本内容表格转成Markdown表格幻灯片按页切分。这类文档一般不会太长分片压力小。2.3 分片粒度怎么定才合理分片粒度没有标准答案取决于你的模型上下文窗口和任务类型。我的经验值是单片控制在模型上下文窗口的60%到70%。留出余量是因为还要拼prompt模板、规则说明、以及模型输出的空间。举个例子如果本地模型上下文是8K token中文大概1个token对应1.5到2个汉字那8K token约等于12000到16000字。按70%算单片控制在8000到10000字比较稳妥。但这是上限实际我倾向于切得更小2000到4000字一片因为小片推理快、并行度高而且规则过滤的命中率更高。重叠部分我设的是片长的10%主要为了防止跨片的语义断裂。比如一个概念在上一片结尾提出、下一片开头展开有重叠就能保证两片都包含完整语境。重叠不能太大否则重复内容会浪费模型算力还会导致同一信息被多次提取。2.4 分片元数据的设计光有文本内容不够每个分片还得带上元数据后面调度和结果合并全靠它。我设计的元数据字段包括分片ID、来源文档ID、在文档中的顺序号、所属章节路径、字符数、预估token数、是否包含表格、是否包含代码块、上一片和下一片的ID。这些字段看着琐碎但每一个都有用。顺序号用于结果合并时还原顺序章节路径让模型知道这片内容在文档里的位置生成摘要时能带上上下文是否包含表格影响prompt模板的选择表格内容需要特殊的处理指令预估token数用于调度时的负载均衡。提示元数据里的token预估不要用精确分词器去算太慢。用字符数乘以一个经验系数就够了中文0.6、英文0.3误差在可接受范围内。3. L0自然语言硬规则让规则自己说话3.1 什么是L0硬规则为什么要用自然语言写L0这个概念是我从分层处理里借来的。L0是最底层、最快、最不需要智能的一层它处理的是那些用确定性逻辑就能判断的事情。比如如果这段文字和上一段完全重复就跳过、如果这段是页眉页脚就丢弃、如果这段包含关键词机密就标记为敏感。传统做法是用代码写死这些规则if-else堆一大坨。问题是规则会变业务方今天说包含内部资料的也要标记明天说页脚里的页码不算内容每次改都要动代码、重新部署。我的做法是用自然语言描述规则用一个轻量解析器把规则转成可执行的判断逻辑。规则文件长这样rules: - name: 跳过页眉页脚 condition: 文本长度小于20且包含第和页 action: skip - name: 标记敏感内容 condition: 包含机密或内部资料或禁止外传 action: tag tag: sensitive - name: 合并短段落 condition: 文本长度小于50且不以句号结尾 action: merge_with_next这样业务方改规则只需要改YAML不用碰代码。解析器把condition字段翻译成可执行的判断函数action字段决定命中后怎么处理。3.2 规则引擎的实现思路规则引擎的核心是条件表达式的解析和执行。我没有引入完整的表达式引擎那太重了。我的做法是定义一套有限的语法支持包含、不包含、长度比较、正则匹配、以及and/or/not组合。解析器用递归下降的方式把条件字符串转成AST然后编译成一个函数。function compileCondition(expr) { // 简化版把自然语言条件转成判断函数 const ast parseExpression(expr); return (text, meta) evaluate(ast, text, meta); } function evaluate(node, text, meta) { switch (node.type) { case contains: return text.includes(node.value); case length_lt: return text.length node.value; case and: return evaluate(node.left, text, meta) evaluate(node.right, text, meta); case or: return evaluate(node.left, text, meta) || evaluate(node.right, text, meta); case not: return !evaluate(node.child, text, meta); default: return false; } }这套东西不复杂但足够覆盖办公文档处理里90%的规则场景。关键是它可测试每条规则可以单独写单元测试改规则不会影响其他规则。3.3 规则执行顺序与短路优化规则不是越多越好执行顺序很关键。我的原则是先执行开销小、命中率高的规则。比如跳过空白段落这种判断成本几乎为零命中率又高放最前面。正则匹配类的规则开销大放后面。短路优化也很重要。如果一个分片已经被标记为skip后面的规则就不用跑了。如果已经被标记为sensitive某些后续的脱敏规则可以直接跳过。我在规则引擎里加了一个状态机每个分片有一个处理状态规则根据当前状态决定是否执行。实测下来一个包含20条规则的规则集经过顺序优化和短路之后平均每个分片的规则执行时间在1毫秒以内相比模型推理的秒级延迟完全可以忽略。3.4 规则与模型的边界在哪里这是最容易搞混的地方。我的判断标准是能用确定性逻辑判断的绝不交给模型。模型只处理需要语义理解的事情。举个例子这段文字是不是在描述一个操作步骤——这个用规则很难判断因为表达方式太多样交给模型。但这段文字是不是和上一段重复——这个用编辑距离或者simhash就能算交给规则。这段文字里有没有提到人名——规则可以用姓氏词典做粗筛模型做精判两者结合。边界划清楚之后模型要处理的分片数量大幅下降。我统计过在一个典型的项目文档集里经过L0规则过滤后真正需要送模型的分片只占原始分片的40%左右剩下的要么被跳过要么被规则直接处理掉了。4. 调度层设计让分片有序流动4.1 调度要解决的核心矛盾分片和规则都准备好之后调度层要回答一个问题这么多分片按什么顺序、用什么并发度送进模型。核心矛盾在于并发度高吞吐量大但本地模型服务的显存有限并发太高会OOM并发度低稳定但慢。而且不同分片的优先级不一样用户当前正在看的那份文档肯定比后台批量处理的文档要优先。我的调度器设计目标是三个优先级可配、并发可控、失败可重试。4.2 基于优先级的任务队列我用的是多级优先队列。任务分三个优先级交互式用户实时请求、近线用户刚上传、预期很快要看、离线后台批量处理。每个优先级一个队列调度器按优先级从高到低取任务。同一优先级内部用最短作业优先策略。分片的预估token数就是作业大小的代理指标token少的分片先处理这样能快速产出第一批结果用户感知上的首响时间更短。队列的实现我用的是内存队列加持久化备份。内存队列负责快速调度同时把任务状态写到本地文件或者轻量数据库进程重启后能恢复。办公文档处理这种场景任务丢失的代价不高但能恢复总是好的。4.3 并发控制与背压并发控制这块我踩过坑。最开始没做限制所有分片一股脑发出去本地模型服务直接被打挂。后来加了并发上限但设得太死又浪费了算力。我的做法是动态并发。调度器维护一个当前在途请求数同时监听模型服务的响应时间。如果响应时间在正常范围内逐步提高并发如果响应时间明显上升或者出现超时降低并发。这个逻辑类似TCP的拥塞控制慢启动、拥塞避免。class AdaptiveConcurrency { constructor(min 1, max 8) { this.current min; this.min min; this.max max; this.inFlight 0; this.avgLatency 0; } canDispatch() { return this.inFlight this.current; } onComplete(latency) { this.inFlight--; this.avgLatency this.avgLatency * 0.8 latency * 0.2; if (this.avgLatency 2000 this.current this.max) { this.current; } else if (this.avgLatency 5000 this.current this.min) { this.current--; } } }背压体现在任务入队时。如果队列长度超过阈值新任务要么等待要么被拒绝并返回系统繁忙。办公场景下我倾向于等待因为用户对文档处理的延迟容忍度比在线对话高。4.4 失败重试与降级策略本地模型服务不是永远可靠的可能因为显存不足、进程崩溃、请求超时等原因失败。调度器必须处理这些情况。我的重试策略是指数退避加最大次数限制。第一次失败等1秒重试第二次等2秒第三次等4秒最多重试3次。重试时会把分片重新入队但优先级降一级避免失败任务反复占用高优先级资源。如果重试仍然失败走降级策略。降级分两种如果这个分片不是关键路径比如是后台摘要任务直接标记失败记录日志继续处理其他分片如果是关键路径用户实时请求返回一个基于规则提取的简化结果同时告知用户部分内容处理失败。注意降级结果一定要明确标记不能让用户以为这是模型的完整输出。我在返回结构里加了一个degraded字段前端据此显示不同的提示。5. 踩坑实录那些文档里不会写的问题5.1 中文分片的标点陷阱中文分片和英文不一样英文按空格和标点切很自然中文没有空格标点又分全角和半角。我最初用句号、问号、感叹号做切分点结果发现很多文档里用的是英文标点或者中英文混排切分逻辑直接失效。后来我改成多标点联合切分同时识别中文标点。和英文标点.!?;并且处理省略号、破折号这些特殊情况。还有一个坑是引号中文引号是成对的如果切分点落在引号中间会导致引号不匹配模型理解出问题。我的处理是切分后检查引号配对不配对就往前或往后调整切分点。5.2 规则冲突与优先级规则多了之后必然冲突。比如一条规则说包含机密的标记为sensitive另一条说包含机密且长度小于100的跳过。一个短小的机密段落同时命中两条规则到底该跳过还是标记我的解决方案是给规则加优先级高优先级规则先执行且执行后可以锁定状态。标记为sensitive的规则优先级高于跳过规则所以先标记然后跳过规则看到已经标记了就不再执行跳过。这个逻辑需要在规则引擎里显式实现不能靠规则书写顺序来隐式决定否则维护起来是灾难。5.3 模型返回格式不稳定本地模型和云端API不一样输出格式的稳定性差很多。同样的prompt有时候返回纯JSON有时候JSON外面包一层markdown代码块有时候还会加一句好的以下是结果。我的处理是三层解析先尝试直接JSON.parse失败则用正则提取代码块内容再parse再失败则用更宽松的规则提取花括号内容。如果三层都失败就把原始返回记录下来标记为解析失败走降级。这个问题的根本解法是在prompt里明确要求输出格式并且给few-shot示例。但即使这样也不能假设模型一定听话解析层必须足够健壮。5.4 内存泄漏与长时运行Node.js处理大量文档时内存管理要特别注意。我遇到过一次跑了几小时后内存涨到几个G的情况排查发现是事件监听器没有移除。每次处理一个文档就注册一个监听器处理完没清理累积起来就泄漏了。解决办法是统一用once代替on或者在finally块里显式移除监听器。另外大文本对象处理完后要及时置空让GC能回收。Buffer和Stream用完要destroy。这些在短时间测试里看不出来只有长时间运行才会暴露。6. 性能实测与调优经验6.1 实测数据我在一台配置为16核CPU、32G内存、单张消费级显卡的机器上做了测试文档集是50份混合格式的办公文档总字数约80万。对比了三种方案方案模型调用次数端到端耗时峰值显存直接全量送模型50约42分钟超限失败仅分片不过滤320约18分钟7.2G分片加L0规则加调度128约9分钟6.8G可以看到加了L0规则过滤后模型调用次数从320降到128降幅60%。端到端耗时从18分钟降到9分钟主要收益来自规则直接处理掉的分片不需要等模型。6.2 调优的几个关键点分片大小不是越小越好。我试过把分片切到500字结果分片数量暴增调度开销和模型调用开销反而上升。2000到4000字是比较甜的点。规则执行要向量化。如果规则很多逐条对每个分片执行会很慢。我的优化是把所有分片先收集起来对每条规则批量执行利用数组方法减少函数调用开销。模型调用要复用连接。Node.js的HTTP agent默认连接数有限我调大了maxSockets并且启用了keep-alive减少了TCP握手开销。这个优化在大量小请求场景下效果明显。6.3 监控与可观测性这套系统跑起来之后必须能知道它内部在发生什么。我加了几个关键指标每个分片的处理耗时、规则命中率、模型调用成功率、队列长度、当前并发度。这些指标通过一个简单的HTTP接口暴露出来用的时候直接curl就能看。日志方面每个分片从进入到完成有一条完整的trace包含分片ID、经过的规则、模型调用耗时、最终状态。出问题的时候拿分片ID一搜就能定位。7. 一些可以复用的设计取舍7.1 为什么不用现成的调度框架有人会问为什么不用Bull、Agenda这类现成的Node.js任务队列。我的考虑是这些框架面向的是通用任务调度而我的场景有特殊性任务之间有顺序依赖同一文档的分片要按序合并、有优先级动态调整、有基于模型服务状态的动态并发。用现成框架反而要写很多胶水代码去适配不如自己写一个轻量的。当然如果团队规模大、需要分布式调度那还是应该用成熟框架。我的场景是单机、中小规模自研的成本更低。7.2 规则和模型的配比怎么调这个没有固定答案取决于你的文档特点和准确率要求。我的经验是先用规则覆盖所有能覆盖的剩下的交给模型。规则覆盖率高系统就快、就省规则覆盖率低说明规则设计得不够好需要迭代。我一般会先跑一批文档统计每条规则的命中率命中率低于5%的规则考虑删掉或者合并命中率高于50%的规则考虑是不是可以拆得更细。7.3 这套架构的扩展方向如果文档量继续增长这套架构可以往几个方向扩展。分片和规则层可以水平扩展多个进程并行处理不同文档。模型服务可以做成集群调度器根据各节点的负载分发请求。规则可以做成热加载改规则不用重启进程。但这些扩展都要在真正需要的时候再做过早优化只会增加复杂度。我现在的原则是单机能扛住就不分布式内存能放下就不上数据库。整套东西做下来我最大的体会是本地AI应用的门槛不在模型而在模型之外的那层工程。分片切得好不好、规则设计得合不合理、调度稳不稳定这些决定了系统能不能真正用起来。模型本身的能力反而是相对确定的你选一个合适的开源模型它的表现就在那里。但前置层做得好能让同样的模型发挥出完全不同的效果。