月底我去财务部帮忙处理对账桌面上Excel窗口开了十几个同一笔银行回单被人为改了三次摘要两个系统的订单号格式对不上最后只能靠人眼逐行打勾。这种场景我见得太多——不是没有系统而是系统之间各说各话不是大家不努力而是重复录入和对账这种事靠人肉真扛不住。几个月前我们给一家集团下属子公司搭了一套轻型AI中台目标就两个让AI把重复录入的活干完让系统把对账的差异自动标出来。这里说的“中台”不是那种动辄几十人团队的大工程而是几台服务器上一组容器化服务把OCR识别、大语言模型、规则引擎和流程编排串成一条流水线。整套东西从设计到上线用了不到两周运行效果比预期好很多。这篇文章会把整套架构逻辑、技术选型和部署过程完整拆一遍包括踩过的坑和排查思路。适合正在被重复录入和对账难题困扰的企业IT负责人、财务数字化岗位的同学也适合想用本地大模型做实际业务的运维和开发工程师。1. 先搞清楚重复录入和对账难到底难在哪1.1 重复录入的真相系统之间缺一个“翻译层”先明确一个判断重复录入不是人的问题是系统集成缺失的问题。销售在CRM录了合同商务在ERP里要再录一遍销售订单财务在财务系统又要录发票——每个系统的字段语义、格式规则、校验逻辑都不一样。大家不是想偷懒而是系统之间根本没有一条自动转换的通道。传统思路是做接口开发但老系统的接口往往不开放文档缺失字段定义混乱集成成本很高。于是很多企业选择了最原始的办法让文员复制粘贴让会计重新录入。这个办法短期不花钱长期却把人力成本越拖越高出错率也随单据量线性上升。轻型AI中台要做的第一件事就是把“系统之间的人工翻译”变成“机器自动翻译”。通过OCR识别纸质单据或PDF再用大语言模型理解语义把字段映射成目标系统需要的格式经过规则校验后自动写入。这个过程替换的不是某个人而是整套重复搬运的流程。1.2 对账困难的本质时间、口径、状态三个不一致对账难表面看是数据对不上本质上是三个层面的不一致叠加在一起。第一是时间差。银行流水很多是T1甚至T2才入账业务系统按交易发生日记账月底最后几天产生的交易两边天生对不齐。第二是口径差。一笔订单含税还是不含税、退货怎么冲抵、满减如何分摊业务侧和财务侧的定义经常不同两边拿各自口径做同一道题答案自然不一样。第三是状态差。一边单据还在草稿状态另一边已经变为已审核一边审核通过另一边被退回修改。系统之间的状态流转没有同步机制核对时就会产生大量“假差异”。用Excel做对账本质是靠人眼临时记忆这些差异规则再逐行判断。单据量少还行量一大就彻底失控。AI中台的做法是先把所有来源数据统一成标准流水模型再用规则引擎做确定性匹配把模糊的部分交给大模型判断最后输出差异报告给财务复核。这样系统处理的是“规则和模型”而不是“某一个具体的Excel文件”。1.3 为什么不是“换一套ERP”或“无限加人”很多企业第一次听到AI中台第一反应是“我们要不要干脆换ERP”我的回答通常是不建议。换ERP意味着流程重构、数据迁移、全员培训周期以年计算预算以百万计算中小企业折腾不起。即使换完新ERP内部模块打通了跟上下游伙伴和银行系统的对接问题依然存在。加大人力也治标不治本。单据量涨一倍人不是只涨一倍沟通协调成本会超线性增长。重复录入本身是反人性的工作人员流动率高培训成本高出错率反而更不可控。所以轻型AI中台的定位很明确在所有存量系统外面套一层“智能翻译和智能核对层”。它不替代任何核心系统不推倒重来用最小的侵入换取最大的自动化收益。对预算有限、系统老旧、老板又急着要效果的团队来说这是回报率最高的一条路。2. 技术选型与整体设计能轻则不重2.1 三个设计原则能帮你少走一半弯路在动手部署之前我建议先把设计原则定下来。我们当时给自己立了三条规矩后来发现这几条规矩省了很多麻烦。原则一能开源就不自研。OCR、大模型推理、流程编排这些能力在开源社区已经非常成熟完全没必要从零写。自研看着有面子维护起来全是坑。原则二能轻则轻拒绝一上来就上K8s。轻型中台的核心价值是快速见效单机Docker Compose足以覆盖绝大多数业务量。等业务量真正增长到需要水平扩展的时候再迁到集群不迟但第一版一定别把复杂度堆上去。原则三接口标准化不做私有协议。所有服务对外只暴露HTTP接口数据格式统一用JSON消息传递走标准HTTP回调或消息队列。这样未来替换任何一个组件都不会影响整条链路。这三条原则的本质是保证系统的可替换性和可运维性。后续做审计、迁移、排障都会轻松很多。2.2 核心组件选型对比我把整套中台的组件整理成一张表方便你直接参考能力域推荐组件解决什么问题容器编排Docker Docker Compose服务一键启动环境一致快速交付结构化存储PostgreSQL Redis流水数据、任务状态、缓存加速OCR识别PaddleOCR / MinerU扫描件、图片、PDF转成可读文本大模型推理Ollama本地部署运行Qwen等轻量模型做字段抽取和语义判断流程编排n8n 或 Node-RED定义自动化流程、定时任务、跨系统调用监控告警Zabbix / Prometheus Alertmanager主机、容器、服务可用性监控选型逻辑是“每个能力只选一个最接近业务的工具不追求大而全”。比如OCRPaddleOCR对中文场景识别效果好社区活跃部署也简单如果PDF是文档类而非扫描件用MinerU直接做版面分析和文本抽取效果比传统OCR更理想。大模型推理这里多说一句。很多人一上来就想部署几十B甚至上百B的模型我强烈建议先从3B到8B的轻量模型开始比如Qwen2.5系列。原因很简单企业业务场景里字段抽取和语义判断这类任务对推理能力要求没有那么高但对接入延迟和服务器资源非常敏感。一个能在CPU上流畅运行的量化模型比一个跑不动的大模型有用得多。2.3 整体架构一条流水线串起四个环节整套中台的架构可以用一句话概括从数据接入到业务写入一条流水线串起四个环节。第一个环节是数据接入。文件上传、FTP目录扫描、数据库定时任务、消息队列都可以作为入口。单据可能是扫描件、PDF、Excel也可能是邮件附件接入层把这些异构入口统一收拢。第二个环节是智能处理。OCR先做文本识别大模型再做字段提取和语义理解规则引擎最后做校验。这个环节是整个中台的核心解决的问题是“把非结构化信息变成结构化业务数据”。第三个环节是业务编排。n8n这类流程引擎负责把处理结果按规则分发调用ERP接口写入数据创建复核工单触发通知推送。所有步骤可配置、可追溯、可回滚。第四个环节是输出与闭环。写入目标系统、生成对账差异报告、把异常项推送到待办池人工确认后落库归档。没有闭环的自动化只是玩具。这四个环节对应到两条具体业务链路上一条是智能录入链路解决重复录入一条是自动对账链路解决对账困难。下面进入实操部分。3. 实操部署两周内把中台跑起来3.1 基础环境准备硬件怎么配系统怎么装先讲硬件。我们当时用的是一台64GB内存、16核CPU的服务器没有独立显卡。如果你们的单据量不大32GB内存、8核CPU起步完全够用如果打算跑8B量化模型建议32GB内存以上要跑视觉模型或者大批量OCR再加一块NVIDIA显卡会更从容。磁盘建议留500GB以上模型文件、Docker镜像、业务数据会分散吃掉不少空间系统盘千万别塞满。系统方面推荐Ubuntu 22.04或24.04 LTS。Docker和Docker Compose装好后基本没有其他系统层面的依赖。在内网环境部署时有一个容易被忽略的环节提前把需要用到的模型文件下载好用离线方式拷入服务器。我们第一次部署时没准备离线包结果现场等下载等了大半天非常被动。Docker安装完成后建议把镜像仓库地址配置好避免反复拉镜像时因为网络原因失败。这里顺带提醒所有容器服务尽量固定端口映射和存储卷位置方便后期备份和迁移。3.2 编排核心服务数据库、推理服务、流程引擎下面这份docker-compose.yaml是整套中台的最小骨架。它把PostgreSQL、Ollama和n8n三个核心服务编排在一起启动后你就有了一套可运行的雏形。version: 3.8 services: postgres: image: postgres:15-alpine environment: POSTGRES_DB: ai_middle_platform POSTGRES_USER: aiuser POSTGRES_PASSWORD: change_me volumes: - pgdata:/var/lib/postgresql/data ports: - 5432:5432 healthcheck: test: [CMD, pg_isready, -U, aiuser] interval: 10s timeout: 5s retries: 5 ollama: image: ollama/ollama:latest volumes: - ollama:/root/.ollama ports: - 11434:11434 restart: unless-stopped n8n: image: n8nio/n8n:latest environment: - N8N_HOST0.0.0.0 - N8N_PORT5678 - DB_TYPEpostgresdb - DB_POSTGRESDB_HOSTpostgres - DB_POSTGRESDB_DATABASEai_middle_platform - DB_POSTGRESDB_USERaiuser - DB_POSTGRESDB_PASSWORDchange_me ports: - 5678:5678 depends_on: postgres: condition: service_healthy restart: unless-stopped volumes: pgdata: ollama:这个文件有三个细节值得说明。第一PostgreSQL加了健康检查n8n只有在数据库可用后才启动避免启动顺序混乱。第二Ollama的数据目录挂载到命名卷模型文件不会因为容器重建而丢失。第三所有服务都设置了restart策略服务器重启后能自动拉起。启动命令很简单docker compose up -d docker compose ps看到三个服务处于Up状态后再单独把OCR服务加进来。我建议OCR单独跑一个容器避免和推理服务抢资源也给后续替换留下余地。加进来之后用docker compose ps再确认一次所有容器都是健康状态然后再开始配置业务链路。3.3 智能录入链路从扫描件到自动写入现在解决第一个核心问题消除重复录入。我以“供应商送货单自动录入ERP”为例拆解整条链路。操作流程分为六步把送货单扫描件或拍照件上传到指定目录或者通过网页表单、企微机器人发送给中台接口。中台调用OCR服务识别图片中的文本和表格区域。把OCR原文交给本地大模型模型根据提示词提取结构化字段。规则引擎校验必填项、金额一致性等。调用ERP开放接口生成采购入库单。记录完整日志校验失败或接口异常的单据自动进入人工复核队列。其中第三步是整个链路的技术关键点。我把提示词模板贴出来你们可以直接抄你是一个单据信息抽取助手。从下面OCR识别出的原始文本中 提取字段supplier、delivery_date、material_code、quantity、 unit_price、total_amount。 要求物料编码保持原样金额统一转为数字无法确定的字段填null。 只输出JSON不要任何解释。 原始文本 {ocr_text}为什么这里要用大模型而不是传统正则表达式因为送货单来自不同供应商模板五花八门正则表达式换一家供应商就要改一次而大模型只需要在提示词里描述字段语义就能适应格式变化。当然大模型也不是万无一失所以还要靠第四步的规则引擎兜底。规则引擎的校验逻辑可以用JSON表达比如{ supplier: {required: true}, delivery_date: {type: date, required: true}, quantity: {type: number, min: 0}, unit_price: {type: number, min: 0}, total_amount: {type: number, equal_expected: quantity * unit_price} }这里有个细节很多人容易忽略金额校验不要只判断“是否为空”要主动计算“数量乘以单价”是否等于总金额。很多重复录入错误其实在源头就可以用这种简单规则拦截省得对账时再返工。我们在实际项目里就是靠这条规则把送货单的错误率压下去一大截。3.4 自动对账链路从银行流水到差异报告第二个核心问题是消减对账困难。我以“银行流水与业务收款记录核对”为例讲清楚整条链路。流程是每天凌晨定时任务从银行导出的电子回单Excel读取流水同时从业务系统的数据库只读视图拉取收付款记录。两边的数据先经过清洗层统一成标准格式包括交易日期、金额、收付方向、摘要四个字段。然后进入第一轮规则匹配相同金额、日期相差不超过3天、摘要含有关键业务编号的直接标记为“已核对”。这一轮能解决大约70%到80%的常规单据。剩下未匹配的记录进入第二轮交给大模型做语义判断。比如银行回单摘要写着“XX化工货款”业务系统收款单备注是“合同HT2025-0018”两者金额一致但日期差了两天传统规则匹配不上大模型却能判断出这大概率是同一笔业务。判断结果不是直接写死而是生成“疑似匹配”标记供财务人员复核确认。再往下是差异分类输出。我们把差异分成四类多收、少收、时间差、无业务凭证。每类差异对应不同的处理动作比如“时间差”自动标记为正常待后续核对“无业务凭证”推给业务部门追查。最后是闭环设计。差异报告每天生成后自动推送到财务负责人的待办池人工确认结论回填到系统。这些确认过的结论会成为后续对账的参考模型判断越用越准。只有走通这一步财务团队才愿意信任这套流程真正的价值才会落地。3.5 人工复核界面让业务敢用AI的关键设计很多技术团队做自动化项目容易犯一个错误一上来就追求100%全自动把人工环节全部砍掉。实际上业务部门根本不敢接受这种方案出了问题连回溯入口都没有。我们的做法是在n8n流程里单独挂一个“复核节点”。所有识别结果不是直接写进ERP而是先进入待办池由财务人员或库管员在页面上确认。确认动作留给人工识别动作交给AI。运行半个月后团队对AI的准确率有了体感才逐步放开部分低风险单据的自动写入权限。这个设计虽然多了一点点人工成本但换来了信任和回溯能力。自动化项目最怕的不是AI出错而是出错之后没人敢承担责任。留一个复核入口就是给业务部门留一条安全通道。4. 部署实施中踩过的坑与排查技巧4.1 模型推理慢、内存吃紧的排查思路第一次跑的时候我们用Ollama部署了一个8B量化模型机器是16核CPU加64GB内存单条提示词响应要十几秒并发一多直接排队。排查下来问题出在三个地方。第一并发参数没有调。Ollama默认配置会尝试并行处理多个请求但CPU推理的并行能力有限并发一高反而互相拖慢。把并发数调到2或3单次响应时间反而快了不少。第二模型选型偏大。对字段抽取这类任务3B到4B模型完全够用换成小模型后响应时间降到三五秒准确率并没有明显下降。第三提示词里塞了太多历史示例每次请求都带着一大段上下文token计算量大。精简提示词后响应时间又缩短一截。后来我们还做了一个优化把OCR识别和大模型推理拆成异步任务。用户提交单据后立即返回“处理中”后台跑完再通知结果。这样即使单个请求耗时三五秒用户体感上也不觉得慢整体吞吐量也能上来。4.2 OCR识别质量差问题不一定在OCR本身OCR识别不准多数人第一反应是换更好的OCR模型。但根据我的观察很多场景的识别问题出在图片质量上而不是模型能力上。常见的现象有手机拍的单据歪斜、有阴影扫描件有黑边印章盖住了关键字段。PaddleOCR自带方向分类器和版面分析但前提是输入图片足够清晰。我们的经验是在OCR之前加一个图像预处理环节先做方向校正再做亮度均衡最后裁掉无用边缘。另外有个技巧OCR识别出的原始文本不要做太多过滤原样交给大模型处理。很多人喜欢先用正则清理空格和换行结果反而把关键信息弄丢。大模型本身对文本中的噪声有很强的容错能力保留原始上下文更有利于准确抽取。4.3 老系统没有API打通数据流的三种办法这是项目里被问得最多的问题。老ERP系统可能连接口文档都没有数据库直接操作又怕出事。我的经验是按优先级用三种办法。第一种利用系统自带的导入导出功能。绝大多数业务系统都支持Excel导入导出只是格式不友好。我们可以让中台在后台生成符合导入模板格式的Excel文件再调用系统的命令行或定时任务完成导入。这个方案侵入性最小实施也最安全。第二种申请只读数据库账号。如果老系统用的是Oracle、SQL Server这类数据库可以让DBA开一个只读账号给中台拉数据。只读权限严格控制绝不直接执行写操作。写入仍然走应用的导入通道或者由业务人员确认后手动操作。第三种Web页面自动化操作。这是最不推荐的方案因为它依赖页面元素定位系统一升级就失效。仅在完全没有其他通道时才考虑而且要做好随时维护的准备。整体优先级就是文件优先数据库只读次之UI自动化最后。4.4 对账结果总有少量差异如何逐步收敛上线初期对账模块识别出了大量差异财务那边一度有情绪。后来我们做了三件事把差异量控制到了合理范围。第一降低自动化目标预期。先做到95%自动核对剩下5%由人工确认而不是追求100%全自动。这个预期必须先对齐。第二把每次人工确认的结论沉淀下来。财务确认“差异类型为时间差”之后这个结论回写到规则库里下一次遇到类似记录自动套用规则模型的判断负担也会越来越轻。第三建立一个简易的对账知识库。把历史对账中出现的典型案例、判断依据整理成文档定期加入到大模型的提示词参考中。这样模型的判断会越来越符合企业实际业务语义而不是停留在通用理解水平。这三件事本质上都是在做同一件事让系统在真实业务反馈中持续学习。没有这个过程任何花哨的模型都跑不出好结果。5. 落地效果与可扩展方向5.1 实际落地效果数字比吹嘘实在说下我们当时的数据。送货单录入方面原来每单需要文员手工录入三到五分钟现在从上传单据到写入ERP平均不到三十秒其中大部分时间是OCR和模型推理消耗人工只需要在异常队列里偶尔确认一下。对账方面原来每月末财务两个人对三天经常还要加班现在每天自动生成对账报告月末只需要集中处理少数疑难点当天就能出结果。客户公司后来统计过每个月省下来的工时超过六十个小时这还不算因为错账返工带来的隐性成本。当然要说明这套效果是在单据格式相对规范、业务量几百到上千单的场景下取得的。不同业务形态效果会有差异但方向是明确的只要重复录入的痛点是真实的这套架构就值得一试。5.2 扩展方向从录入对账走向更多智能化场景这套中台跑通以后可以顺理成章地向其他场景扩展。如果数据量快速上涨可以把分析型查询从PostgreSQL迁到Doris这类列式存储上让对账统计和报表更流畅。如果对高并发推理有要求可以把Ollama换成vLLM这类推理框架模型也可以换更大的版本效果和吞吐量都有提升空间。监控方面建议尽早接上Zabbix或Prometheus加Alertmanager把主机负载、容器状态、服务接口可用性都纳入告警范围。中台本身作为自动化基础设施一旦出问题影响的是整条业务线不能让它变成盲区。边缘部署是另一个方向。如果你有Jetson设备或者RK3588这类开发板可以把OCR或目标识别模型量化后部署到边缘端在车间入口直接完成单据识别和物体检测减轻中心服务器的压力。我们也在探索把送货单拍照识别前置到仓库门口让文员连上传这一步都省掉。5.3 最后的几点个人体会从这套项目里我最大的体会是轻型AI中台真正做成功靠的不是模型多强而是流程设计多扎实。先把录入和对账的具体场景摸清楚再谈AI先保留人工复核的闭环再谈自动化先让业务看到效果再谈规模化推广。还有一个很朴素的建议日志一定要写全。我们每次处理单据都会记录完整的过程信息包括OCR原文、模型输出、规则校验结果、最终写入状态。这些日志在初期调试和后期追溯时都是救命稻草千万别省。如果你正在为重复录入或对账难题头疼又不想启动一个伤筋动骨的大项目这套轻型AI中台的思路可以直接拿来用。从一个场景开始把流水线跑通再逐步扩大范围你会看到自动化带来的价值比想象中更快显现。