1. 项目背景企业内部为什么需要一台“轻型AI中台”先说个扎心的现状很多企业折腾数字化折腾了五六年ERP、OA、CRM、财务系统一个不少但一线员工每天干得最多的活儿还是从A系统的截图里抠出几个数字再一个字一个字敲进B系统。日复一日重复录入全公司每天几千次没人想干但系统之间不打通只能这么干。我这次做的项目核心就一句话部署一个轻量级的AI中台把“文件识别、关键信息抽取、跨系统填单”这些动作交给模型去完成同时把上下游对账数据做自动核对。项目上线后效果最直观的两个数字是单据处理时间从人均15分钟压到不到1分钟月度对账从3个人忙3天变成1个人盯2小时。这台中台没有上很重的底座没有动不动就几十个节点的微服务全家桶就三台服务器加一套Docker编排前前后后从搭环境到跑通核心链路大约两周。这篇文章就把整个过程拆开讲清楚从设计取舍、模型选型、具体部署步骤到坑点排雷希望给同样被重复录入和对账问题折磨的团队一条能抄作业的路线。先说清楚这个方案适合谁。如果你的企业已经有一定信息化基础业务系统多但数据割裂财务和业务部门天天为对账拉扯技术团队规模不大预算也不算宽裕这个方案就非常契合。它不追求大而全的AI平台目标是快速解决“录入慢、对账乱”这两个最实际的业务痛点。适合的团队规模从几十人的小公司到上千人的中型企业都能覆盖关键是看你想让AI介入的深度。2. 整体设计思路轻量中台应该做什么、不做什么2.1 中台不等于“重台”先界定边界一说中台很多架构师容易上头动辄就要上完整的机器学习平台、模型仓库、特征平台、多租户体系、任务调度中心。对中小企业来说这套东西落地那天就是项目死亡那天因为根本没有那么多人去维护。轻型AI中台的定义我倾向于把它拆成三个必要模块模型服务层、业务编排层、数据集成层再加一个贯穿始终的运维监控。模型服务层负责把大模型和专用小模型包装成标准API业务编排层负责处理“识别单据、提取字段、填回系统”这类具体流程数据集成层负责和各业务系统做数据对接。其余什么项目管理、实验管理、模型训练平台统统不要。这个思路背后有个很现实的逻辑轻型中台的定位是“解决一两个痛点”而不是“建设一个平台”。我先跟业务部门聊了整整三天把他们对系统的所有抱怨都记下来筛掉一半不痛不痒的最后聚焦到两个核心场景。第一个场景是采购订单和发票信息的跨系统录入第二个场景是供应商往来对账。所有的架构设计都围绕这两个场景展开。2.2 两个核心业务场景的需求拆解场景一重复录入。业务部门的同事收到供应商发来的PDF订单、Excel清单、图片格式的发货单需要把其中的关键字段提取出来录入到ERP和OA系统。以前的做法是人工打开两个窗口对照着敲键盘一天下来眼睛都快瞎了。我们拆解后这个场景的技术需求其实就几件事多格式文档解析PDF、Excel、图片、字段识别合同号、订单号、金额、日期、供应商名称等、数据格式化统一日期格式、金额精度、自动填单调用ERP和OA的接口。拆完之后发现真正有AI含量的是字段识别这一步其余的都是标准化接口工作。场景二对账困难。财务部门每个月初要对一遍供应商往来款。业务部门的采购数据一套口径财务系统的付款数据另一套口径两边导出来的Excel经常对不上。这个场景的技术需求更朴素数据抽取从两边系统导出的Excel里读取数据、规则匹配按供应商、合同号、期间、金额做比对、差异分类是时间差、手续费、折扣还是录入错误、结果推送把差异表自动发给相关责任人。这里面没有太多“智能”核心是把对账规则工程化、自动化。场景拆完之后我发现一个关键点AI中台的价值不在于技术本身多花哨而在于把杂乱的信息变成标准化的数据流。重复录入的本质是信息形态不统一对账困难的本貰是数据口径不统一中台要做的就是用一层“翻译器”把这两层不统一消解掉。3. 技术选型与部署架构不追新只求稳3.1 模型层选型通用大模型处理文本专用模型处理图像这次项目在模型选型上做了很实际的取舍。文本类数据PDF订单、Excel清单、邮件往来我们用了现在社区非常成熟的本地部署大模型路线通过Ollama这类工具在服务器上跑开源模型。这类模型的好处是私有化部署数据不出内网运维简单推理成本可控。图像类的单据识别截图、拍照单据、扫描件我们选用了开源的OCR框架搭配一个轻量的专用检测模型。为什么不直接让大模型硬读图片实测下来的教训是大模型处理复杂表格图像时速度和准确率都不稳定而专用OCR模型对印刷体单据的识别准确率在干净环境下能做到98%以上CPU推理速度也能接受。这里有个很重要的经验不要指望一个模型解决所有问题。当初我也测试过直接用视觉语言模型去识别整张单据结果单据上既有商品表格又有手写备注还有印章模型输出的JSON结构经常错乱要么字段名对不对齐要么金额识别串行。后来回归到“OCR出结构化文本 大模型做信息抽取”的两段式方案准确率和稳定性都上来了。第一段OCR负责把图像转成带坐标的文本第二段大模型拿到文本后按预设的JSON Schema提取字段。两段各司其职出问题时也容易定位。3.2 服务框架选型Docker Compose起步不上K8s部署形态上我强烈建议一开始就用Docker Compose不要迷信Kubernetes。原因很简单K8s的运维复杂度是几何级数上升的团队只有两三个人光理解Pod、Service、Ingress那套概念就要花不少时间。而Docker Compose足以管理一台机器上的5~8个容器写一个YAML文件一条命令把全套服务拉起来日志、网络、卷管理都够用。本次部署的容器清单大概是这样Nginx容器作为统一入口做反向代理和负载均衡Ollama容器承载大模型推理OCR服务容器自己封装了一个FastAPI接口包住开源OCR框架中台核心API容器负责业务编排、数据转换、调用外部系统PostgreSQL容器存业务数据和日志Redis容器做任务队列和缓存。六个容器三台宿主机前四台服务部署在两台带GPU的机器上数据库和Redis单独放一台机器。整体架构不复杂但每个模块职责清晰出了问题看日志就能定位到具体容器。3.3 关键网络与安全设计企业内网环境还要考虑一个容易被忽略的问题各业务系统之间的网络策略。ERP系统在财务内网OA系统在办公网两个网络之间只打通了几个特定端口之前人工录入时人坐在电脑前可以同时访问两个系统但服务部署后机器调用就需要额外开网络策略。这个环节我踩了一次坑后面实战部分会单独讲。总之在架构图上必须预留出AI中台和各业务系统之间的明网络边界图每一对调用关系的方向、端口、协议提前列清楚再去找网络管理员申请策略而不是等部署完再临时开。数据库访问这个环节不同系统的数据库连接方式差异也很大。我们对接的ERP是个老系统数据库在SQL Server里还有几个表用数据库链接直接读而OA系统自己带了一套API接口。架构上我坚持所有对外依赖都封装在“集成适配器”里跑出数据接口有的纯Excel走的是公网协议的也要在内网做好地址和端口映射。这样即使依赖的系统换了接口中台主体代码也不需要动。4. 部署落地实操从零到一让AI中台跑起来4.1 基础环境准备与宿主机资源配置既然是轻型中台资源配置就不搞全面豪华阵容。我这次的实际配置是两台GPU推理机加一台CPU业务机。GPU机用的是NVIDIA显卡双卡方案显存合计48GB跑一个7B参数模型和OCR服务并发压力不大时响应时间能控制在1秒左右。CPU机器给了32核、128GB内存跑数据库和API服务非常充裕。操作系统用的是Ubuntu 22.04 ServerDocker版本选24.x稳定版本。配置完成后先做一轮“地基测试”跑几个基础容器把Docker网络、存储驱动、GPU支持全部验证一遍。这里特别提醒Ollama官方容器需要nvidia-container-toolkit这个组件的支持否则GPU在容器里是不工作的。安装这个工具包之后一定要执行nvidia-smi确认宿主机能看到GPU再进容器里跑一次GPU推理验证。这个步骤看似基础但很多人在这卡了很久因为容器内看不到GPU还以为是驱动问题其实是没装好toolkit。4.2 模型服务部署Ollama拉起大模型Ollama的部署很简单拉取镜像、挂载模型目录、映射端口重点在于模型的选择。这次在重复录入场景里我选了7B量级参数的中文优化模型在字段抽取这类任务上效果满足要求而且显存占用不高4位量化之后模型文件大约4~5GB推理速度和效果平衡得很好。正式使用之前我拿真实业务单据跑了几百条样本字段提取的准确率从最初选型模型的86%提升到最终模型的97.5%所以选模型千万不要只看跑分一定要用自己业务的数据来测。模型文件下载需要一些时间好在是一次性的。之后写Ollama的Docker Compose配置时把模型存储目录用Named Volume挂出来后续升级模型只需要替换文件重启容器即可。启动之后用curl调一下API确认模型加载正常把返回的延迟、吞吐量记录下来作为后面压力测试的基线。4.3 中台核心服务与API网关配置中台核心API我用Python FastAPI来实现这个框架写REST接口效率高天然支持异步和OpenAPI文档方便前后端联调。代码仓库里按模块拆分成ocr_worker、llm_extractor、business_flow、integration_adapter几个目录每个目录都是一个独立服务在GUNICORN或Uvicorn下运行再用Docker Compose统一编排。Nginx层配置需要特别注意路径转发规则。前端请求遵循https://ai-mid.example.local/api/model/ocr或.../api/model/extract这类路径格式Nginx根据api/model这段前缀把流量分发给OCR服务或大模型抽取服务。业务流程类的请求走api/flow前缀转发给中台核心API。反向代理还承担了统一的CORS跨域处理因为前端页面可能是零散的如果不做CORS统一浏览器端调用会很麻烦。踩坑记录Nginx层我一开始没配client_max_body_size默认1MB结果供应商发来的扫描件一张就十几MB直接返回413错误。后来改成200MB才算解决这种细节不实际跑业务根本发现不了。4.4 数据库与消息队列的容器化部署PostgreSQL容器和Redis容器部署相对简单按官方镜像直接跑就行。但是有几个参数踩过坑PostgreSQL的内存参数官方镜像默认配置比较保守如果不调shared_buffers和work_mem大批量对账任务很容易跑出慢查询。我根据服务器128GB内存的实际情况把shared_buffers设为8GBwork_mem设为64MB实际对账跑批速度提升明显。Redis在项目里承担两个角色一个是作为任务队列把OCR请求和抽取请求异步化避免高并发时直接把模型服务打垮另一个是作为限流缓存记录每个调用方的日调用量。任务队列这块强烈建议用Redis的Stream类型比直接硬背List做队列要可靠得多消费者的抵消和重试机制都是现成的万一任务处理失败积压的任务不会丢。4.5 部署流程验证与上线前检查清单全部服务启动后我按下面这个清单逐项验证过一遍基础网络连通性Nginx能正常访问各容器服务端口可达。模型推理验证用3张真实单据测试OCR和大模型抽取确认接口返回的JSON结构符合预期。业务流程端到端测试从上传PDF到ERP系统自动生成草稿单据全链路走通需要多久误差容限是多少。异常场景测试上传一个空白PDF、一个带乱码的Excel、一个超大文件看服务会不会挂错误返回是否友好。备份与恢复演练把数据库卷导出、再导入一次确认数据完整性。监控告警确认配置的邮件告警和日志采集是否正常收到测试消息。这套检查下来基本可以放心交给业务去试用了。实际上线后的头两周我持续盯着日志和告警每天做一次数据质量抽检发现问题随时调整提示词和校验规则。5. 消除重复录入的实现路线与核心细节5.1 多格式文档解析的管道设计消除重复录入的第一步是让系统能“看懂”各种格式的单据。这里说的格式不只是文件后缀还包括版式横版表格、竖版单据、带页眉页脚的扫描件、手写备注混乱的清单。我设计了解析管道分四个阶段依次处理。第一个阶段是文件格式检测不只看扩展名还要读取文件头Magic Number因为实际业务里经常出现“PDF其实是图片”、“Excel其实是CSV”这类货不对板的情况。第二个阶段是结构解析PDF和Excel分别走对应解析器抽取文本块图片和扫描件走OCR流程。第三个阶段是版式重组因为表格类单据光有文本不行还得恢复行列关系这一步用的OCR模型输出的位置坐标把文本块重新拼装成二维表格结构。第四个阶段才是交给大模型做字段抽取。这里给大家一个定位问题的经验如果某类单据识别率低永远要看是哪个管道阶段出的错。比如某个供应商发来的Excel里有多行表头和多级合并单元格解析器抽出来的Text是乱的这种问题改OCR没用要改Excel解析的逻辑。我会给每个阶段都输出中间日志数据存到一张临时表里方便回溯问题出在哪个环节。5.2 字段抽取与自动填单的工程实现字段抽取的核心是给大模型定义一个足够严格的输出结构JSON Schema并且写清楚每个字段的抽取规则和校验逻辑。举个例子金额字段不仅要识别数字还要区分是含税金额还是不含税金额币种是什么格式对不对。我会在提示词里明确告诉模型提取原始值、判断币种、统一转换为分存储同时输出置信度评分。凡是置信度低于80%的字段自动流转到人工确认队列。自动填单是在抽取完成后的动作。系统根据单据类型选择对应ERP或OA接口把抽取到的字段按接口规范组装成参数发出。这个环节的工程细节比AI细节多得多比如ERP接口要求工单主表和明细表同时创建主键怎么生成、明细行怎么排序、失败重试怎么做。我们的做法是设计了一个固定的“填单事务模板”把创建逻辑封装成原子操作成功则标记任务完成失败则记录完整请求和响应快照方便人工排查。这里重点提醒不要把抽取结果直接写进ERP正式库。我坚持先在业务系统里创建一个“待审草稿”状态AI填单的结果全部是先落成草稿业务员核对无误后一键确认。这样既保证了效率又给人工留了一个安全网。实际操作中超过95%的草稿确实是一键确认的但恰恰是剩下那5%的异常单据幫我们避免了很多潜在错误。5.3 录入质量校验与反馈闭环AI不是一次就能达到交付标准的必须建立反馈闭环。我们的做法是每一次人工修改草稿字段都会被记录下来形成“模型错误样本”。每周导出这些错误样本进行分析归纳哪类单据结构导致抽取失败、哪类字段定义容易混淆、哪类异常值需要补充规则。然后把分析结论转成两类改进一类是提示词优化调整字段描述和示例另一类是预处理增强增加对特定版式的清洗步骤。这个闭环运行了大概一个月系统的字段抽取准确率从初期的89%逐步提升到了98%而且错误集中度明显下降。一开始的错误集中在日期格式和金额单位上后来加上了“自动年份推断”和“金额中文大写校验”两条规则这两类问题基本绝迹。说白了AI中台的打磨不是上线就结束而是上线后持续喂数据给规则和模型它才会越来越好用。6. 对账模块:从手工Excel走向自动核对6.1 对账数据模型的落地对账模块没有用AI而是用一套严谨的数据模型来解决问题。我们先把对账的“账本”抽象成两层账面流水层和差异分析层。账面流水层从各业务系统的导出文件中抽取关键字段供应商名称、单据编号、业务日期、借贷方向、金额加载到中台的统一中间表中。差异分析层则是一条条“差异结论记录”记录每一笔勾对结果完全匹配、有差异或单边存在。在数据模型设计上最重要的决策是采用“原始数据一票到底”原则。也就是中间表里保留从原系统导出的所有原始字段不在加载阶段做任何清洗归纳这样后续如果有对账规则调整可以随时基于原始数据重新跑不需要再去追根溯源。这个原则在项目初期遭到了部分同事的质疑觉得冗余字段太多但对账出问题需要反查时这个设计帮了大忙。6.2 对账规则引擎与差异分类逻辑对账规则引擎我用的是规则表驱动的方式每个规则就是一个SQL配置挂在规则表里由任务调度器按周期执行。匹配的主键是供应商编码加上单据编号辅以金额比对。第一次匹配尽量用精确匹配匹配不上的自动进入模糊匹配流程允许容纳日期三天的浮动和金额几分钱的差异银行手续费场景常见。差异分类是财务人员最在意的一环因为不同差异的处理路径完全不同。我把差异分类做成了四类时间性差异两边其实都有只是记账时间不在同一月、金额性差异实质性的金额不等需要核实、单据缺失一边有单据另一边完全没有、关联性差异两边数字对得上但业务属性对不上比如费用归属部门不同。分类做对之后财务人员拿到差异表就知道该找谁、做什么事而不是几十行数字干瞪眼。6.3 异常处理与人工复核闭环自动对账再准也不能完全替代财务复核毕竟账务问题涉及资金风险。所以我的设计是自动对账只负责“筛选和分类”所有有差异且金额超过阈值的记录系统自动推送给财务人员复核。每个差异记录有一个独立的状态流转待确认、处理中、待更新、已关闭。这套闭环跑了两轮之后财务部门反馈最明显的变化是月度对账不再是一场“无休止的开会核数”而是变成“看系统生成的差异清单集中处理少数真正有问题的事项”。整个对账周期从三天缩短到两小时关键不是系统算得快而是系统把“该看什么”给筛出来了。人工花时间的地方从“大海捞针”变成了“处理异常”效率自然就上去了。7. 实战踩坑记录与性能排查实录7.1 模型并发与GPU显存冲突问题上线第一周遇到的最严重的问题是GPU显存溢出导致整个OCR服务和模型服务全部无响应。排查过程很经典先是Nginx层看到大量502超时再看容器日志发现Ollama服务输出显存不足的报错。原因是PDF解析高峰期多个图片识别任务同时到达OCR服务和文本抽取服务都抢着用显存模型碎片化导致可用显存不足。解决思路有两个层面。底层是对GPU资源做显存隔离让OCR服务独占一张卡大模型独占总另一张卡互不干扰。上层是限流在Redis里做好并发信号量OCR任务同一时间最多接受三个其他请求排队。改完之后高峰期的稳定性立刻上去再也没有出现过整个服务全军覆没的情况。7.2 跨系统调用与网络策略导致的链路中断这个问题干扰了我整整两天。中台服务本身正常运行但调用ERP接口时有大量请求超时。我一开始怀疑是接口写的有问题反复查看不能头绪后来用curl在宿主机上直连ERP地址发现能通但进了容器再curl就超时了。这时候才想起来Docker容器默认走NAT网络出网时会获取宿主机同一网段IP但目标机器的防火墙只允许特定IP段访问ERP端口容器IP不在白名单里。确认原因之后解决的方案是把中台容器全部加入macvlan网络让容器拥有宿主同网段的独立IP网络策略就不用改了。这个教训告诉我们企业内网的网络策略往往比容器集群本身复杂得多部署前一定要先做“容器内网络连通性”测试而不是只在宿主机上测通就完事。7.3 进程重启与数据不一致的恢复策略跑批对账任务时如果服务重启很容易造成中间表已经写入但最后的目标表状态未更新的情况数据就变得不一致。我们的对账任务拆分成多个子任务每个子任务之间用任务ID关联且以“幂等写入”为原则——同一个任务ID多次执行结果都应该是覆盖式更新而不是累加式写入。这样即使中断重启重新跑掉失败子任务就能恢复一致性。还有一个小坑是关于模型容器服务异常的。Ollama容器启动时加载模型需要时间如果容器健康检查未通过编排工具就会反复重启容器导致模型一直加载不完。后来把容器重试策略改成“不要自动重启靠外部监控拉起”反而稳定很多。这跟传统Web服务依赖K8s自动重启的思路不太一样模型服务这类有加载态的服务自动重启反而会打断加载过程。7.4 性能瓶颈排查的实操记录项目上线后我做了两轮性能优化。第一轮瓶颈在OCR服务单张图片识别时间平均3秒批量高峰期队列积压严重。优化方向是把OCR模型的推理线程数调大、把输入图片做预压缩分辨率从4000px压缩到1600px识别时间降到1.2秒质量损失可接受。第二轮瓶颈在大模型字段抽取单次抽取要1.5秒于是把提示词模板简化了实验输入文本长度缩短30%配合并行处理把吞吐量提升了两倍。有一个通用建议排查性能问题不要凭感觉要在每个处理阶段打点计时写进日志。我加了几行Python代码记录每个阶段的耗时分布然后发现所谓“模型慢”其实大部分是等待队列时间和网络IO时间真正的推理消耗并不是最大的。这个结论很重要它否定了我一开始想换更大算力模型的想法实际上只需要优化队列和预处理就够了。8. 项目复盘与个人心得整个项目从立项到落地满打满算不到两个月回顾来看最有价值的并不是写了几万行代码而是把AI技术用对地方的过程。重复录入和对账困难本质上都是数据孤岛和数据质量的问题AI在里面扮演的角色是“弥合者”——把人类从机械劳动里解放出来。实际使用中业务部门一开始对AI系统普遍持怀疑态度觉得“机器填单肯定不靠谱”但当他们看到系统能把每天三个小时的工作缩到半小时而且出错率明显低于人工时态度自然就转过来了。这里有个个人体会想分享做这种落地型项目技术选型千万别追新。社区里每天都有人发布新的模型框架看着确实吸引人但对业务稳定优先的企业场景选那些生态成熟、文档齐全、社区案例多的方案比选最新的模型可靠得多。我这次选的都是已经被大量用户验证过的工具链虽然谈不上炫酷但成功率和可控性远高于新颖方案。真金白银的经验是让AI在一条窄而清晰的业务流程里小步跑起来比规划一个宏大平台目标实际得多。最后留一个扩展方向的建议。这台轻型AI中台目前解决的是录入和对账它的能力边界完全可以再拓宽把单据里的历史数据沉淀下来做趋势分析把合同文本里隐藏的风险条款抽取出来做审查辅助甚至做成一个面向各业务部门自助申请AI能力的小平台。只要底层的模型服务、业务编排和数据集成三层结构保持稳定往上叠加新的业务场景其实就是编写新的流程编排和适配器的事情。改造会越来越简单收益会越铺越广。项目收尾时我觉得这可能是做数字化项目最让人有成就感的地方——技术终于不是被展示用的花瓶而是实实在在地让人少加了不少班。