一次给一家做供应链贸易的朋友梳理财务流程时，我看到他们财务部三个人，每天光是往ERP、OA、财务系统里重复录单据、月底对账，就要搭进去大半天。这种“数据搬运工”式的劳动，在很多企业里都被当作理所当然。聊到最后我给了个建议：自己搭一个轻型AI中台。不用买昂贵的商业平台，也不需要完整的算法团队，一台普通服务器、一套Docker编排、一个开源大模型，两周内就能把“重复录入”和“对账困难”这两块硬骨头啃下来。这篇就围绕这个部署思路，把方案选型、模块设计、实操过程和踩坑记录完整摊开来讲。
1. 先搞清楚：轻型AI中台解决的是哪两类问题
1.1 重复录入：系统越多，搬运工越多
我见过不少企业的真实状态：仓库管库存用WMS，采购下订单用ERP，财务记账用总账系统，OA又管审批流程。一张采购入库单到了月底，仓库在WMS里录一次，采购在ERP里补一次应付单，财务在总账里再录一遍凭证，OA那边还要填一张相同的审批单。一次搬运是几秒钟，十次百次就是人力黑洞。
根子在于系统孤立。很多传统软件对外开放接口要额外收费，或者定制周期动辄按月算，企业只好靠人肉在两个系统之间“摆渡数据”。更麻烦的是信息标准不统一：同一个供应商，在ERP里叫“深圳市华鑫电子有限公司”，在财务账上叫“华鑫电子”，到了银行回单上可能变成“深圳华鑫电子”。字段一致性和格式规范全都靠人的记忆去补。
AI在这里真正能发力的地方，不是替代某个业务系统，而是做一层统一入口的“智能摆渡”：一次录入，自动识别、自动清洗，再分发到各个系统。录入动作从“打开四个系统填四次”变成“对着一个页面拍一张照、核对一遍”，后面的事交给中台的工作流去执行。
1.2 对账困难：格式差异和口径不一致是根因
对账为什么难？本质上是两套数据模型对不上。银行流水是银行口吻：日期、对方户名、金额、附言；业务订单是业务口吻：订单号、客户全称、含税金额、账期。同一笔收款，银行附言可能只写“货款”，ERP里却对应三张订单。同一个客户，上个月叫“张三”，这个月改叫“张三个人工作室”，系统里旧数据也没跟着改。
传统的对账流程，财务人员把两边数据导成Excel，用VLOOKUP按金额和日期硬匹配，匹配不上的再手工翻流水、翻合同。遇到多银行账户、跨期回款、部分收款、混合付款这些情况，一天能核掉五十笔就算效率高。月底对不平的时候，财务和业务互相认为是对方的错，最后只能先挂账，等年底统一调整。
AI的做法完全不同：先把两边数据清洗成同一套标准模型，用确定性规则锁死大头（订单号、金额、日期组合），再用语义匹配解决名称不一致、附言模糊的问题，最后由差异报告把“哪里对不上、为什么对不上、建议怎么处理”全部摊在桌面上。财务从“逐笔核销”变成“审差异”，工作量降一个量级不说，口径没对齐的问题也暴露得清清楚楚。
1.3 为什么必须“轻型”而不是“重型”
真正的大厂AI中台，动辄是大数据平台、特征平台、模型训练平台、MLOps体系，团队几十上百人，费用和周期都不适合绝大多数中小企业。大部分企业的真实场景，数据量没到PB级，模型不需要自训练，业务规则以确定性逻辑为主，AI在其中更多是“识别”“抽取”“匹配”“分发”这些辅助性工作。
所以“轻型”体现在几个维度：基础设施轻，单机或双机就能跑，不需要K8s集群；模型轻，7B级别的开源模型加量化，一块消费级显卡甚至纯CPU都能扛；编排轻，用Dify这类可视化的自托管平台，不写大量胶水代码；接入轻，不改原有业务系统的底层结构，全部走API对接。
我自己的经验是：这种轻量方案，部署周期一到两周，硬件投入几万块以内，后期运维一个人兼职就能维护。它解决的是“一个团队三台服务器一个月能交付”的落地问题，而不是“一个平台所有人上去搞机器学习”的宏大叙事。
2. 部署方案选型：单机Docker Compose搞定一切
2.1 架构分层：接入层、能力层、编排层、集成层
部署之前先想清楚架构，不要一上来就装环境。我习惯把轻型AI中台分成四层，每层职责单一，排查问题时也方便定位。
接入层是用户或业务系统触发入口，包括H5表单、企业微信/钉钉机器人、API接口和文件上传，这一层负责把人工录入、拍照上传、PDF导入、系统推送都收进来。能力层提供AI原子能力，主要是OCR文字识别和大模型推理，OCR负责把图片变成文本，大模型负责把文本变成结构化字段。编排层是核心，用工作流把“识别字段→清洗映射→查出重→调业务API→回写状态→通知处理人”这一串动作按顺序跑起来。集成层则是和现有系统的对接，为每个业务系统封装一个HTTP适配器，统一处理认证、超时、幂等和重试。
这套分层对应到具体组件，就是：前端表单接Dify，Dify调用Ollama上的开源模型，OCR服务独立部署，数据库存流程日志和待处理数据，再通过一套自定义API网关对接ERP、OA和财务系统。层与层之间全部走HTTP，任何一层挂了都不影响其他层启动，这是容器化部署最舒服的地方。
2.2 模型选型：DeepSeek蒸馏版加Ollama，CPU也能跑
大模型是轻型AI中台的核心能力来源，但选型必须克制。我建议优先考虑DeepSeek-R1的蒸馏版本，比如deepseek-r1:7b，或者Qwen2.5-7B-Instruct。原因很直接：7B级别模型量化到Q4_K_M后，模型文件只有4到5GB，显存占用6GB左右，连一张2060S都能跑；即便没有GPU，一台16核32G内存的纯CPU服务器也能推理，只是速度慢一些。
部署工具我最常用Ollama，它把模型管理做得特别省心：一条命令拉模型，一条命令启动服务，并且直接暴露OpenAI兼容的API接口。Dify、n8n这些平台要接模型，填一个Base URL和模型名就能用，不需要自己写推理脚本。如果后续想换更强的模型，比如32B级别，只需要在一台带更大显存的机器上再启动一个Ollama实例，把Dify里的模型供应商切换一下就行，业务无感。
需要说明的是，这套组合是当前开源社区里相当成熟的做法，我根据自己的落地经验做了裁剪。如果你的场景是海外文档识别，可以替换成对应语种微调过的OCR模型；如果对结构化输出要求极高，可以在模型外面套一层函数调用框架，而不是只靠提示词。
2.3 为什么是Docker Compose而不是K8s
很多人一听到“部署中台”就觉得要上Kubernetes，我反而建议先用Docker Compose。轻型AI中台的组件数量通常不超过十个，单机或双机拓扑，管理节点、网络插件、持久化存储这些K8s带来的是额外的运维负担，而不是问题。Compose用一份YAML文件描述所有服务，docker compose up -d一条命令就全部拉起来，日志用docker compose logs查，升级就是改镜像tag再重启，一个人完全玩得转。
中台内部的状态数据基本围绕事件流转：流程实例、待确认任务、匹配结果、审计日志，这类数据PostgreSQL加上Redis足够。为什么不上一套专门的大数据体系？因为重复录入和对账都属于事务型场景，数据量级在百万行以内，列式存储的收益还不明显。等哪天流水到了千万级、需要做复杂聚合分析了，再引入Doris或ClickHouse也不迟，而且它们同样可以用Compose起步，不影响现有架构演进。
顺带提一句监控：中台跑起来之后，我会用Zabbix盯几个关键服务——Ollama的端口、Dify的worker进程、PostgreSQL连接数。容器还在不代表服务健康，端口有响应才是真的活。
3. 模块一：智能录入，消灭重复填报
3.1 统一输入入口：一次录入，多点分发
智能录入模块的设计目标是：所有需要人工敲键盘的数据，尽可能变成一次操作。我把入口做成一个H5页面，支持两种输入方式：一种是直接填表，字段布局和原来的单据完全一致；另一种是拍一张纸质单据或上传PDF，由系统自动识别后预填到表单里，人工只做核对。
这个入口页面不需要从头开发，Dify本身就能发布Web App，也可以嵌入企业微信。更重要的是，表单提交后不是直接入库，而是触发一条工作流：系统先调用识别能力抽取字段，再走清洗映射，然后按单据类型分流——采购入库单同时写ERP的应付单、OA的审批单和财务的往来台账，销售出库单则写订单系统、开票申请和客户对账单。
这里有一个关键设计：所有下游系统的写入操作不做“先失败再来回折腾”，而是采用事务补偿思路。工作流每成功写入一个系统，就把返回的单据编号记录到流程上下文中；如果中间任意一步失败，已经写入的部分通过适配层的反向接口做冲销或标记待处理，同时通知运维人员介入。实际跑下来，这套“记录+补偿+告警”的模式比一味的重试靠谱得多。
3.2 单据识别：OCR加结构化抽取，把图片变成字段
单据识别的链路分两步：先用OCR把图片变成文本，再用大模型把文本变成JSON字段。OCR方面我推荐PaddleOCR，中文识别精度高，Docker镜像直接可用，训练成本为零。部署时可以把OCR服务独立成一个容器，给足CPU和内存配额；如果识别压力非常大，也可以把OCR模型单独部署到Jetson Orin或RK3588这类边缘板卡上，把压力从中台主服务上卸掉。
识别出的原始文本质量参差不齐，比如扫描件会有错字、表格线识别不全、金额被印章遮挡。这些情况不要指望OCR自己能解决，正确姿势是让大模型来做脏数据的“修复和结构化”。我会给大模型设计固定的抽取提示词，要求它只输出JSON，并给出允许的枚举值。比如供应商名称必须从对账名册中选择标准名称，不能自由发挥；单据类型限制在“采购入库单、销售出库单、费用报销单、其他”。
为了让结构化结果真正可靠，提示词只是第一步，输出后的程序校验才是关键。拿到模型的返回结果后，我会用代码做四件事：检查JSON能否正常解析；检查必填字段是否为空；检查金额、日期、数量是否符合业务范围；检查枚举值是否命中白名单。任何一个环节不通过，这条数据直接进入待确认池，绝不自动写下游系统。
3.3 清洗映射：规则挡九十，模型纠十
录入清洗这层，我的原则是“确定性规则优先，大模型兜底”。重复录入之所以让人头大，很大程度上是因为同一个实体在不同系统里有不同叫法，所以我会先建一张标准映射表，把“供应商全称、简称、银行户名、曾用名”关联起来。系统拿到OCR和模型提取的供应商名称后，先在映射表里做精确匹配和别名匹配。
规则解决不了的长尾情况才轮到模型。比如模糊匹配“顺丰速运”和“顺丰快递”到底是不是同一家，大模型可以根据上下文判断；比如OCR把“0”识别成“O”，造成单号差一位，模型结合整体语境也能纠正过来。但模型给出的结果同样要回到规则框架里做最终校验。
我习惯在清洗完成之后加一道“抽检机制”：每周随机抽取百分之五的已处理单据，比较模型抽取结果和人工复核结果，统计字段级准确率。这个数字一旦低于98%，就说明提示词或者映射表需要更新。很多团队上线后从不做抽检，等对不上账了才发现某类单据的供应商名称一个月来全被识别偏了，这种亏我吃过，所以强烈建议把抽检做成固定流程。
4. 模块二：对账自动化，把差异摊在桌面上
4.1 数据对齐：银行流水与业务单据的匹配策略
对账模块第一步是把两边数据源拉到一个标准模型里。银行流水可以通过网银导出的Excel或接口获取，业务单据则从ERP拉取。两边数据不是简单丢到一个表里就完了，必须先做清洗：金额统一转成“分”为单位，避免浮点数精度问题；银行流水里的手续费、利息这类非交易记录打上标记；日期统一成业务日期而不是入账日期。
清洗完之后进入匹配阶段，我按三级策略递进。第一级是强规则匹配，拿我方单据号或对方唯一流水号做精确匹配，这类结果基本可以无脑自动核销。第二级是组合索引匹配，用“日期前后三天内+金额一致+归一化后的对方名称一致”这组条件做匹配，命中率很高，适合没有唯一单号的场景。第三级是语义匹配，名称像但金额、日期略有偏差的数据，交给大模型判断是否为同一笔业务。
匹配结果要形成一张明细表：每笔银行流水对应哪张业务单据、置信度多少、命中了哪条规则，全部可追溯。如果对账流水规模到了几百万行，PostgreSQL扛不住复杂聚合时，可以把明细数据落到Doris或ClickHouse这类列式仓库里，但初期完全没有必要，普通数据库加索引就够用。
4.2 置信度与差异分级：AI先判，人再复核
匹配不是非黑即白的，我用置信度做分级处理，让财务人员只处理机器搞不定的部分。
| 匹配级别 | 判定规则 | 处理方式 |
|---|---|---|
| 高置信 | 单据号加金额完全一致，或日期、金额、名称组合全部命中 | 自动核销，进入对账完成列表 |
| 中置信 | 金额一致，名称相似但未归一，或日期偏差在三天内 | 推荐给财务人工确认，一键采纳或驳回 |
| 低置信 | 金额对不上，或找不到任何强关联字段 | 进入异常池，提示财务排查业务原因 |
差异报告要把原因归类写清楚：部分收款、跨期回款、客户名不一致、手续费未计入、重复付款、金额拆分记录，每一类都对应一个建议动作。比如“部分收款”建议联系业务确认剩余款项；“手续费未计入”建议标记为银行费用并调整余额。
这套分级体系最大的价值是给了财务人员一个明确的“工作量梯度”：打开系统第一眼看到的不是一万笔待核销，而是二十笔需要判断的低置信差异。服务器可以晚上自动把流程跑完，第二天早上财务只需要对着差异报告点确认或补充说明。
4.3 对账工作流的编排实现
对账流程在Dify里是一条定时触发的工作流，不需要写一行代码。节点顺序是我的最终落地版本：定时触发对账任务 -> 从各银行接口拉取流水 -> 从ERP拉取业务单据 -> 清洗标准化 -> 逐笔执行三级匹配 -> 计算置信度 -> 生成差异报告 -> 推送到企业微信/钉钉通知财务 -> 财务在审阅页面确认或驳回 -> 回写核销状态和备注。
有一个容易被忽略的点是“中途失败要从断点续跑”。对账任务凌晨跑，很可能跑到一半接口超时。我会给每个批次打上唯一批次号，流程里每个节点都记录执行状态，失败后重新触发时先检查已执行到的步骤，而不是从头拉一遍数据。对账数据本身是增量式的，拉取接口建议按日期游标做增量同步，而不是每次全量拉取，否则数据量上来了单次执行时间会越来越长。
工作流跑完之后的输出物，不只是“对平了”的结果，更是一份可审计的过程记录。谁在什么时间确认了哪笔差异、模型给出的理由是什么、人工修改的最终动作是什么，全部留痕。这一点在对账场景里比AI能力本身更重要，因为财务数据的追溯性要求比录入场景严格得多。
5. 实操全过程：从0到1部署记录
5.1 环境准备与硬件建议
我建议的起步配置是这样：一台16核32G内存的服务器，配一块12G显存的NVIDIA显卡，比如RTX 3060，系统盘200G SSD，再用一块1T的机械盘或SATA SSD放模型文件和业务数据。如果预算紧张，暂时不买显卡也可以，CPU模式先跑通流程，识别速度慢一些但对账这种批处理任务完全能接受。
操作系统推荐Ubuntu 22.04 LTS或者Debian 12，软件源、驱动、Docker支持都比较省心。部署前把Docker Engine和Compose插件装好，确认nvidia-container-toolkit也已安装，否则显卡没法透传给容器。内网环境如果无法直接从镜像仓库拉取，先在能联网的机器上把需要的镜像docker save成tar包，再拷贝到内网机器docker load导入，模型文件同理，拷贝到指定目录后挂载进容器即可。
所有部署过程中涉及的内网镜像离线导入、私有仓库搭建，都属于常规运维操作，合规、稳妥。这里特别提醒：进入生产环境前，所有组件版本必须固定，不要用latest标签，否则一个月后重启容器，镜像版本漂移，你根本不知道跑的是哪一版代码。
5.2 编排文件示例与参数说明
下面是一份精简版的docker-compose.yaml，覆盖Ollama、Dify前后端、PostgreSQL和Redis，正式部署时建议以Dify官方仓库的compose文件为基础，按需裁剪：
services: postgres: image: postgres:15-alpine environment: POSTGRES_USER: dify POSTGRES_PASSWORD: <请替换为强密码> POSTGRES_DB: dify volumes: - pg_data:/var/lib/postgresql/data restart: always redis: image: redis:7-alpine restart: always ollama: image: ollama/ollama:0.5.4 volumes: - ollama_models:/root/.ollama ports: - "11434:11434" deploy: resources: reservations: devices: - driver: nvidia count: 1 capabilities: [gpu] restart: always dify-api: image: langgenius/dify-api:1.0.0 environment: MODE: api DB_USERNAME: dify DB_PASSWORD: <请替换为强密码> DB_HOST: postgres DB_PORT: 5432 DB_DATABASE: dify REDIS_HOST: redis REDIS_PORT: 6379 depends_on: - postgres - redis - ollama volumes: - dify_storage:/app/api/storage restart: always dify-web: image: langgenius/dify-web:1.0.0 ports: - "3000:3000" depends_on: - dify-api restart: always volumes: pg_data: ollama_models: dify_storage:启动命令很简单：
docker compose up -d docker compose logs -f先确认所有服务进入healthy状态，再拉模型：
docker exec -it ollama ollama pull deepseek-r1:7b进入Dify后台，在模型供应商里添加Ollama，Base URL填http://ollama:11434，模型名填deepseek-r1:7b，保存后就能在应用里选择它了。这里有个小细节：Dify容器访问Ollama一定要用服务名ollama，不要填localhost，因为容器网络是隔离的。
5.3 接通内部系统与上线切换
中台本身跑起来只是第一步，真正花时间的是和业务系统的对接。每个业务系统都需要写一个适配层，解决三件事：认证方式、幂等控制、错误语义。比如ERP接口需要在请求头带token，OA接口用的是签名参数，这些差异全部封装在适配层里，Dify工作流只需要调用统一的HTTP工具，不关心下游细节。
幂等控制尤其重要。AI中台向业务系统写数据时，如果网络超时重试，可能造成重复单据。我的做法是生成一个全局唯一的请求流水号作为幂等键，下游系统按这个键做去重，要么返回成功，要么返回“该单据已存在”，绝不产生第二条脏数据。
上线切换我建议“存量不动、增量试跑”：新录入的对账单走中台入口，老的存量单据继续走原有流程，并行观察一周。期间人工照常处理对账，系统同时跑一遍并输出匹配结果，对比人工处理和中台输出的差异率。当一周差异率降到可接受范围，再逐步停掉老入口。这样即便AI在某些边缘case上不给力，也不会影响当月结账。
6. 部署后必看的七个问题与避坑手册
6.1 模型输出“看着对，实际错”怎么拦截
LLM最大的坑是“生成性”而不是“正确性”，它会一本正经输出格式正确但内容有偏差的结果。比如金额多一位零、日期格式对但月份错了、供应商名称编出一家不存在的公司。我踩过的坑是：早期只靠提示词要求“不要编造”，结果还是有单据被错误写入ERP。后来彻底改成“结构化校验+人工兜底”：所有模型输出必须通过JSON Schema校验、枚举白名单校验、金额范围校验，任何一个不通过就进人工队列。
更强的手段是让模型走函数调用而不是自由文本输出。Dify的Agent节点支持工具调用，可以让模型先决定调用哪个函数，由函数定义参数结构，程序端强行控制字段类型和必填约束。相比裸提示词，这种方式把“生成”变成了“填参”，出错率明显下降。我现在的原则是：能用规则校验的坚决不靠模型自觉，模型只是规则处理不了的补充。
6.2 并发一上来就超时怎么办
中台刚上线时没人用，你觉得速度快，一旦多个部门同时提交，几秒内几十个请求打到Ollama上，就会出现排队等待，进而超时。Ollama支持并发参数，但受限GPU显存，并发太高反而触发OOM，得不偿失。我的实测经验是：单张12G显存显卡跑7B量化模型，并发调到2到3比较稳妥，再多就排队。
缓解思路有几个：一是把高频调用做缓存，相同模板的发票识别结果如果单据号一致，直接返回历史结果，不开新推理；二是把轻量文本分类（比如判断单据类型）用规则或小模型处理，只有真正需要泛化能力的任务才调大模型；三是Dify工作流里给HTTP请求和模型节点都配好超时时间，超时后走降级路径而不是报错重试。对账这种批处理任务则反过来，不求实时返回，设定夜间低峰批次跑，并发压力天然就小。
6.3 内网拉镜像、装依赖的离线方案
很多企业的服务器在隔离内网，docker pull和pip install都走不通。我的做法是“内网私有仓库+离线包”两手准备：在一台能联网的机器上把所需镜像全部docker pull好，然后docker save成tar文件，用U盘或内网文件服务器搬运到目标机器，docker load导入，再tag推送到内网Harbor或Registry上。Compose文件里所有镜像地址都写成内网仓库地址，团队其他成员部署时直接从内网拉。
模型文件也类似，Ollama模型可以直接拷贝模型目录，也可以从模型导出平台手动下载GGUF文件，放到挂载目录后重新识别。Python依赖同理，可以在内网搭一个PyPI镜像源，或者用pip download提前把wheel包下载好。这里有一个容易翻车的点：离线环境的镜像tag一旦没锁定，导入时版本错乱，跑起来报各种诡异的错，所以离线包里必须有完整的版本清单，镜像名、tag、sha256都列清楚。
6.4 数据合规：财务数据不出内网
轻型AI中台部署在内网，本身就是合规优势，但还要守住几个边界：所有模型推理必须在本地Ollama完成，绝不把票据图片、银行流水、客户信息发送到外部API；Dify的对外入口要加访问控制，按角色区分“提交录入、复核对账、查看报表”三种权限；所有人和系统之间的交互操作写入审计日志，保留周期至少180天。
我还建议单独拉一条“数据脱敏链路”：对账报告和差异分析在呈现给前端之前，把账户号脱敏，手机号打码，仅保留后四位。AI中台处理的数据越敏感，越要养成“最小可见”的习惯——不是所有人都需要看到完整的银行卡号和交易附言，默认不给，特殊情况再单独申请。
6.5 模型幻觉导致供应商名错乱
结构化抽取场景里，供应商名是最容易翻车的字段。原因是模型看到OCR文本中的简称，会“脑补”成完整的公司名，但它补的并不一定来自白名单。后来我在提示词里明确要求“只能从提供的候选列表里选，不要自己生成”，并且把候选名单作为上下文传入，同时在下游做一步数据库检索校验，如果标准名称不存在，就转到人工。整套兜底跑下来，供应商名称准确率能稳定在97%左右。
6.6 对账批次重复执行产生脏数据
定时任务最怕重复触发。某次凌晨任务执行到一半，网络抖动导致重试，结果同一批银行流水被匹配了两次，自动核销记录重复入账。后来我调整为“批次+状态机”机制：每次对账生成唯一批次号，按流水号做去重，匹配状态严格区分“待匹配、已匹配、已核销、已驳回”，核销动作必须是幂等操作。现在无论重试多少次，结果都是一样的，财务再也不用半夜起来删数据。
6.7 日志乱码和中文显示问题
容器里的日志中文变乱码，通常不是编码问题，而是地区语言环境没设对。我在容器环境变量里统一加LANG=C.UTF-8，另外把数据库连接的字符集参数设成utf8mb4。Dify导出的CSV默认编码如果是GBK，用Excel打开没问题，但接第三方系统时就乱了，所以导出统一转成UTF-8 with BOM。这种问题看起来小，真遇到时能折腾大半天，写在避坑手册里给后来者省时间。
最后分享一点自己的体会
这套轻型AI中台的落地路径，我前后帮几家企业跑过，每次都验证同一件事：不要追求一步到位把所有系统都接上，先把最痛的那条流程打通，比如“一张入库单只录一次”，或者“月底对账从两天变成两小时”。跑通一条，团队看到效果，后续推广阻力就小很多。中台真正的价值从来不在于模型能不能写诗、会不会聊天，而在于把“人搬数据”变成“数据找人”。后面我计划把发票查验、库存预警、供应商自动评级的场景也接进来，等有新成果再单独写一篇分享。
