1. 为什么要做“轻型AI中台”做了十多年企业信息化我越来越确认一件事很多企业真正缺的并不是更智能的算法而是把已有数据用起来的极低成本通道。这个“部署轻型AI中台”的项目最初就来自一个很具体的痛点——财务和业务部门每天都在录单、对账录到晚上八九点对账对到月初想骂人。项目本身不大目标也很朴素消除重复录入消减对账困难。但真正落地之后我发现它带动的其实是整个公司的数据流转方式。项目涉及两个核心模块一个是OCR单据识别与自动填单另一个是跨系统对账的智能匹配。前一个解决“录一遍又录一遍”的问题后一个解决“账对不上、源头难查”的问题。适合谁参考如果你是中小团队或者在一家系统多但数据孤岛严重的公司这套轻量方案非常对症。它不追求大而全的中台概念不用买昂贵的AI平台也不用雇算法团队只要能用开源组件加适度开发搭起来。我最早构思的时候团队里也有争议有人提出直接用RPA有人建议上重型数据中台。但最终我们选择了“AI中台”而不是单纯RPA原因在于RPA适合固定流程一旦单据版式变化就得重配而AI识别模型对版式变化有天然鲁棒性不选重型中台则是因为项目周期不允许预算也不允许。我们最后定的策略是大模型负责理解和生成规则专用模型负责具体识别流程引擎负责串联人工只处理异常兜底。整个项目从立项到初版上线只用了六周。虽然规模不大但效果很直接单据录入时间下降了70%对账异常从月初三天的加班压缩到半天内就能处理完。这篇文章我尽量把过程中的设计取舍、踩坑记录、参数调整都摊开讲给准备做同类项目的朋友一个能直接抄作业的参考。2. 整体设计方案与关键选型逻辑2.1 先拆解需求重复录入和对账困难分别属于什么类型的问题拿到需求第一件事不是选型而是把问题拆到能动手的程度。重复录入这个事本质上是一个信息在不同系统之间的搬运问题。业务人员在A系统录了一版数据到了财务环节又要对着纸质单据或者PDF在ERP里重新输入一遍。搬运过程不产生任何价值只会引入错误和延迟。所以解法核心是找到一个可靠的手段从原始单据自动提取结构化数据再通过接口写入下游系统。对账困难则更复杂一点。它表面上是金额对不上实际是多方数据在时间维度、口径维度、粒度维度上不一致。比如业务系统的订单金额含税财务系统的金额不含税比如退款单在A系统是负数记录在B系统被拆分成了三笔调整项比如同一个客户ID在两套系统里根本不一样。纯粹的规则脚本能解决一部分但规则写多了就会变成面条代码。所以这里必须引入AI的判断能力——让模型在“规则不明确”的时候做语义理解匹配多方数据的内在关联。我把项目拆成三个功能域采集识别、流程编排、智能匹配。每个功能域有独立的输入输出互不干扰这样团队成员可以并行推进。2.2 选型思路为什么用“小模型大模型流程引擎”方案对比阶段我画过一张表对比了几条路线今天拿出来分享一下路线优点痛点适用场景纯RPA脚本开发快页面一改就废维护烦短期零时解决方案重型数据中台统一数据模型建设周期长需要专门运维大型集团长期建设OCR模型规则引擎识别稳定复杂语义处理吃力表单固定、单据规整小模型识别大模型问答流程编排兼顾精确与泛化架构复杂度中等单据种类多、系统多、口径乱我们最终选了第四种组合但其中有个关键细节值得展开能用小模型解决的绝不上大模型。单据OCR识别、字段分类这类任务专用小模型又快又省精度反而更高。大模型只在两个环节介入一是生成匹配规则和字段映射的配置代码二是对规则引擎无法判定的模糊匹配对做语义判断。所以严格来说这个“AI中台”是三个层次的协作感知层用OCR专用模型认知层用大模型做语义判断和规则生成执行层用工作流引擎做调度和回写。每一层各司其职不像很多宣传中的AI中台那样把所有事都扔给一个大模型。2.3 部署方式本地化部署还是纯云端这中间还有个比较关键的决策——部署方式。原始输入里的热词大量出现了本地部署、内网部署、离线部署这些词我们最终也选择了本地化部署。原因有三条第一单据数据涉及客户信息、价格信息属于敏感数据上公有云过一道心里不踏实。第二公司网络环境并不总是畅通尤其是仓库和门店场景断网时也要能识别录单。第三长期算账本地部署虽然前期要买机器但推理调用量大以后比按Token付费便宜得多。关于算力选型我多说一句。我们最开始测试时用了一台带RTX 4090的机器后来发现实际并发量只有十几个用户瓶颈根本不在GPU而在数据库写入。后来把OCR切换到CPU推理的小模型大模型保留GPU推理整体资源占用低了很多。当地业务场景主要是结构化文本和单据图像时CPU小模型能顶掉大半活。3. 核心功能实现识别、填充、匹配、对账3.1 单据采集与字段提取的完整流程这张流程图我脑子里跑了无数遍原始单据进来先经过图像预处理再做版式分析然后进入字段提取最后输出结构化JSON交给下游流程。图像预处理这一步很多人会忽略但恰恰是它决定了识别精度的上限。扫描件要矫正倾斜拍照件要处理透视变形低光照要增强对比度这些不做好再强的模型也白搭。我们实际用了一套组合OpenCV做透视矫正和边缘检测加上自研的清晰度判断——模糊图直接打回重拍不浪费模型算力。字段提取这一层我们的选型是PaddleOCR加微调。这里有一个比较重要的原则不要用通用大模型直接做OCR。推理慢单张成本高关键是精度并不一定更好。PaddleOCR的文本检测加识别管线在单据场景下只要版式不是过于离谱字符准确率能做到98%以上。剩下那2%通过字段级的规则校验兜住。有个细节我们针对每一类单据采购单、销售单、退款单、银行回单做了独立的“字段白名单”。比如银行回单我们只要交易流水号、交易时间、金额、对手账户这五个字段其余信息就算识别出来也直接丢弃。这个白名单机制让输出数据结构非常稳定下游流程解析JSON时几乎不用容错。3.2 消除重复录入自动填充和系统回写数据从单据里提出来之后下一步是“填到该填的地方去”。这里我们做了一个轻量级的填单引擎。填单引擎的核心是一个字段映射配置表。每一条配置描述了三件事源字段从哪来、下游系统的接口字段叫什么、写入前需要做什么转换。举例业务系统的“订单总金额”字段可以直接映射但财务系统的“不含税金额”就要做一次价税分离计算客户ID这种字段不同系统编码规则不同就需要配置对照翻译器。自动填充的触发方式也要设计好。我们提供了三种单据上传后自动识别并预填界面用户确认后一键提交批量导入时异步处理处理完成后通知API方式直接由上游系统调用。三种方式对应不同场景但共用同一个填单引擎避免各做一套逻辑。这里有个血泪教训回写下游系统之前必须做字段级的数据校验。有一次我们没校验金额范围单据里某个字段识别成了“-0.01”写进了ERP结果导致那条订单的账直接对不上。后来我们加了校验规则金额必须大于0、日期必须在合理区间、客户编码必须存在主数据表里。校验不通过的单据进入待人工处理队列而不是直接卡死流程。3.3 智能对账从“逐笔匹配”到“聚类匹配”对账模块比录入复杂得多因为账目不是简单的一一对应关系。初期我们用的是常规的逐笔匹配两边数据按金额、日期相等来配。测试之后发现正确率只有六成原因很典型业务系统一笔订单在财务系统里被拆成了两笔收款或者两笔订单合并成一次结算。逐笔匹配在这种多对多场景下天然失效。后来我们改成了聚类匹配策略。核心逻辑是先把两边待对账的数据按客户维度分组组内进行组合匹配——也就是允许一对多、多对一、多对多。这一步用到了规则引擎加一个轻量的匹配算法。规则引擎生成候选组合算法计算匹配度得分超过阈值的自动确认低于阈值的进入大模型判断。大模型在匹配环节的用处比你想象中更朴实。它不负责算账而是在规则无法判定时读取两条记录的完整描述信息理解“这笔退款对应的是哪张订单”输出判断理由和建议分录。我们把大模型的输出连同用户之后的操作记录下来不断回流成新的规则。跑了一段时间后需要人工介入的异常单比例越来越低规则也越来越厚。这个过程中我也摸索出一个排查对账异常的顺序先查时间口径再查金额口径再查主数据映射最后才是真实漏单。按这个顺序排查大部分异常都能快速定位而不是眉毛胡子一把抓。3.4 数据口径规整与主数据映射对账困难的另一个根本原因是“同一个事物在两套系统里长得不一样”。为了处理这个我在中台里加了一个轻量的主数据映射服务。服务维护了各类业务实体的对照关系包括客户编码对照、商品编码对照、仓库编码对照等。上游系统同步数据过来时映射服务统一做一次翻译转成中台的标准编码后续所有匹配逻辑基于标准编码运行而不是带着两套原始编码做模糊匹配。这里的实现没有技术难度难点在数据本身。我们初期从各个系统导出编码表人工核对建立了第一版映射关系。运行过程中遇到映射不了的编码自动进入待确认队列由业务负责人确认一次之后永久生效。这个“确认过一次就不再重复确认”的机制真的很有用对账麻烦的一半就这样被解决了。4. 部署落地的关键环节与配置实录4.1 硬件规划与部署架构部署这个环节原始输入里反复出现了docker、反向代理、本地部署、集群部署这些词我按实际项目的部署方式展开讲讲。我们最终物理部署是一台GPU服务器加一台应用服务器。GPU服务器的配置我列出来供参考CPUIntel Xeon 8核内存64GBGPURTX 4070 Ti 12GB存储系统盘SSD 500GB数据盘4TB企业盘应用服务器是一台4核16GB的普通云主机负责跑API网关、流程引擎和MySQL数据库。OCR识别服务在GPU服务器上大模型推理服务也在GPU服务器上通过Docker Compose统一编排。选这个规格前我们用真实的单据样本跑过基准测试。结论是OCR识别单张耗时约0.8秒大模型语义判断单次约3秒日常工作流完全够用。相比之下同时开多个大模型服务就有点吃力所以实际运行时大模型只保存了一个量化版本显存占用控制在10GB以内。4.2 Docker编排与服务部署步骤部署方式上我用Docker Compose做了一栈式编排。为什么不用Kubernetes因为组件规模就六个服务K8s反而增加运维复杂度Docker Compose一条命令拉起全部服务维护成本最低。编排的核心服务列表如下服务名作用容器内部端口api-gateway统一API入口与鉴权8080ocr-service单据识别接口8090llm-service大模型语义判断接口8091flow-engine流程调度与任务管理8092mapping-service主数据映射与字段翻译8093mysql配置、日志、结果存储3306部署过程有几步关键操作值得记下来。第一步构建镜像并启动全部服务用docker compose up -d --build一条命令完成。第一次部署最常碰到的坑是服务间网络不通我提前在compose文件里定义好外部网络所有服务共享同一张自定义网络确保服务名可以直接相互访问。第二步初始化数据库表结构。这里注意顺序必须先启动MySQL并等待初始化完成再启动其他依赖数据库的服务。我在compose里配置了depends_on再加了健康检查脚本避免服务一启动就报连接失败。第三步配置API网关。网关负责统一对外暴露接口并做Token校验。原始输入里有人提到nginx反向代理配置我这边也是用Nginx做前置接入把外网请求转发到网关端口同时挂载了SSL证书保证数据传输加密。4.3 模型部署参数与推理优化模型部署有几个参数我没有交给默认值都是逐个试出来的。OCR服务用的是PaddleOCR的推理服务模式。性能方面的关键参数有两个rec_batch_num设置成8相当于一次并行处理8张图的文本识别det_db_thresh调到了0.3让文本框检测更灵敏一点。这些参数需要一个一个试在我们的单据样本集上0.3比默认0.5的召回率提升了4个百分点同时精度没有明显下降。大模型这一侧我们选的是一个7B参数量的开源模型用GGUF格式量化到Q4级别部署。加载时设了上下文长度4096这个长度处理单条对账记录完全够用而且显存占用明显下降。实时性要求高的接口我加了流式响应配合缓存映射。比如相同格式且字段版本未变的单据结果直接走缓存不用重复推理。实测整体服务的P95延迟从5.2秒降到了2.8秒体感变化很大。4.4 内网环境的部署适配考虑到实际环境不一定有外网我把所有依赖镜像提前打包成离线tar包导入到内网机器的本地镜像仓库。这个操作虽然笨但在内网环境里非常可靠。踩过的坑是某些基础镜像内部依赖了外部的Apt源离线环境中Docker构建会卡住。后续我统一改用已打包好的基础镜像构建过程全部在能联网的机器上完成内网只做镜像加载和容器启动整个部署时间压缩到了半小时以内。5. 常见问题与排查技巧实录5.1 识别准确率不够怎么办很多朋友一上来就问准确率这其实是个“系统指标”而不是“模型指标”。识别结果会经过字段白名单、规则校验、必填项检查三层过滤最终落到系统里的错误数据是极少的。如果实际使用中觉得识别率不够我建议不要一上来就重新训练模型先按这个顺序排查第一检查图像质量拍照件是否模糊、反光、倾斜第二确认单据类型是否在已配置的版式清单内第三看字段白名单是否覆盖了当前业务需要的关键字段。大部分“识别不准”的问题出在这三层之外——比如一个本该处理的红头文件被当成了单据来识别。真实需要微调模型的场景我们当时的做法是从实际单据里抽出有明显识别错误的样本用这些样本做增量训练。每批50到100张跑一轮微调然后把模型回滚对比防止增量学习导致的灾难性遗忘。5.2 跨系统接口对接时的兼容性问题对接ERP和业务系统时最麻烦的不是接口写得有多复杂而是对方系统的接口随时可能升级。有一次上游系统悄悄改了字段名从cust_id改成了customer_code我们的填单引擎直接跑失败了。后来设计了一个接口适配层所有对接外部系统都走适配器。适配器负责做字段名翻译、格式转换、协议适配。一旦外部系统变化只需要修改适配器而不影响中台核心代码。另外一个实用技巧是每次对接外部系统都要求对方提供一个测试环境并且把我们调用接口的字段都记录成调用日志。出问题时查日志比问对方管理员高效得多。5.3 数据不一致的对账问题怎么根治对账问题很难一次根除只能持续收敛。基础的规则匹配能解决80%的问题剩下的大多出在口径差异上。我总结了一套排查口诀“先时间后金额先主数据后异常单”。时间口径问题指的是两边系统统计的时间基准不同比如业务系统按下单时间财务按回款时间。金额口径问题多半是含税不含税、折扣、分摊逻辑不一致。主数据问题就是前面说的编码映射不存在或映射错误。按这个顺序查完真正需要人工介入的异常单已经不多了。每处理完一次人工对账都应该把处理结果记录成样本定期把样本反馈给大模型微调或者规则库。我们在落地中期人工介入比例每个季度递减核心原因就是这套闭环机制在起作用。5.4 并发量上来之后性能下降如果同一个时刻大量单据涌入比如月末轧账日服务会遇到性能瓶颈。我们的应对是分两层第一层是API网关做限流超流量直接排队返回提示避免打挂后端服务第二层是OCR和大模型服务做成独立部署支持单独扩容。实际操作中还可以在采集入口做一个“错峰策略”。比如门店端扫描单据后先暂存在本地后台任务在夜间低峰期统一上传识别。这个策略既避免了月底性能瓶颈也兼顾了网络不稳定场景。还有个不算问题的问题机器风扇声音。GPU服务器满载推理时的噪音真实存在放在办公室环境会被投诉。我们机房隔音做了处理这也是一个值得提前规划的小细节。6. 给正在规划同类项目的人几条实在建议6.1 从小场景跑通再谈中台“AI中台”这个词很容易让人上来就规划一堆能力。我实际走过的路是反过来的先选一个最痛、最具体、最容易量化的场景把它完整跑通再复用这套能力扩展下一个场景。我们这个项目的第一个场景是“采购单录入和对账”跑通后销售单、退款单、银行回单这些场景几乎都是复制流程配置实现的。先有场景再有平台而不是先建平台再找场景这个顺序能帮你避免做了一大堆没人用的功能。6.2 大模型不是必需品但也不是玩具大模型在这个项目里的定位始终是“最后一道兜底”。能用规则和专用模型解决的绝不上大模型。真正的分工是专用模型做高频的确定性任务大模型做低频的模糊判断任务。如果你预算有限连一个大模型推理服务都买不起也不影响项目启动。先跑通OCR加规则引擎加流程编排预留一个大模型的接口位等条件成熟再接上。很多收益在OCR和规则这一层就已经能拿到了。6.3 重视数据回流这是中台能长大的关键很多系统的能力越用越弱是因为用过的数据都丢了。如果你的AI中台能把每次人工纠错、每次匹配调整都记录下来形成数据闭环这个系统就会越用越聪明。我们的大模型推理成本从上线初期到现在降了将近一半原因就是规则库越来越全需要大模型的场景越来越少。关于怎么设计日志结构和数据回流机制我建议业务人员参与数据字典定义。最开始我们完全按技术习惯建表结果统计报表时发现很多字段维度没覆盖返工了一次。后来让财务和业务各出一个人直接定义“什么数据必须记录下来”后面用起来顺了很多。这个项目做下来我最大的体会是企业数字化转型最缺的往往不是技术而是把一个具体问题看清楚、把一个朴素方案执行到底的耐心。轻型AI中台这个名字听起来新但做的事情很实就是让单据自动流转让账目自动对齐把人的时间还给真正需要判断力的事情上。希望这篇记录能帮你少走几步弯路。