上周五晚上九点我路过财务部看到小林还在工位上屏幕上开着三个系统窗口正把销售系统里的订单号一个个复制到财务系统里核账。她跟我抱怨了一句每周五都是这个流程数据明明是一个源头出来的为什么每次都要重新录一遍、重新对一遍。这句话我记了很久也是后来我下定决心去做这个轻型AI中台的直接契机。这几个月我利用手头的服务器资源把一套基于开源组件的轻型AI中台从规划到落地完整走了一遍针对性解决的就是标题里那两件事消除重复录入、消减对账困难。没有动辄几个亿的DataOps平台没有几十人的算法团队用的全是社区成熟的开源方案——本地部署大模型做底座可视化编排平台做应用层再把OCR、向量检索、工作流串起来跑通了两条真实业务链路。这篇文章不是什么概念科普而是一个可以跟着复现的实战记录。我会把技术选型过程、两个核心业务场景的落地细节、完整部署步骤、以及我在部署和运行阶段踩过的最典型的几个坑全部摊开来讲。适合正在考虑搞AI中台但预算有限的中小公司IT负责人也适合想用本地大模型解决实际业务问题的后端工程师和数据同学。1. 很多人把中台想复杂了这个项目到底要解决哪两件事1.1 重复录入的本质是数据搬运工太多先说重复录入。你去任何一家业务系统多的公司里看都会发现同一个数据被录入了好几次。销售在CRM里录一份合同财务开票系统里要再录一遍购买方信息和金额仓储系统发货时还要手工对照着填一次收货单位。数据本身从源头到末端没有任何变化变化的是不同系统的表结构、字段命名和业务口径。过去为什么宁可让员工重复劳动也不做系统打通因为传统系统集成的成本实在太高了。两个系统之间要开发接口要约定报文格式要解决字段映射还要考虑后续升级维护。一个接口的开发周期以周为单位而公司里可能同时存在几十个这样需要打通的点。业务部门等不起那就只能靠人肉搬运。AI中台在这里的价值不是更聪明的系统集成而是把搬运工作本身自动化。让大模型读一张采购单、一份合同、一张发票把里面的关键要素抽取出来再按目标系统的字段规则自动填进去。人从打字员变成审核员重复录入这个动作自然就消失了。1.2 对账困难的本质不是算法不行而是数据没先说同一种话再说对账困难。我一开始以为对账难在算法不够智能真做起来才发现卡点根本不是匹配算法而是两边数据根本不在同一套口径上。举几个最常见的例子。业务系统的收入确认日期和银行流水的到账日期可能差两三天同一张采购单在A系统里金额是含税价在B系统里是不含税价对方单位名称在合同里叫北京华信科技有限公司在发票里却写成华信科技北京有限公司。这些差异叠加在一起财务对账的时候只能靠人脑去判断这两个到底是不是同一笔。所以AI中台要做的最重要的一件事不是一上来就做差异分析而是先把两边数据变成可比较的形态。先做字段映射和标准化再做匹配最后才是差异识别。这一步捋顺了对账难的问题直接消掉一大半。1.3 为什么轻型两个字是关键现在市面上讨论AI中台很多方案都喜欢往大了做讲起来全是数据底座、模型工厂、特征平台、MLOps一套下来预算至少千万级实施周期按年算。但对于绝大多数中小企业甚至大公司的某个事业部来说真正要解决的痛点可能就两三个。轻型的核心含义就是用最小的成本最快地解决最痛的问题。不需要自研模型用现成的开源大模型不需要自研平台用Dify这类开源编排工具不需要建大数据集群一台带GPU的服务器就能跑起来。我这次全部采用本地部署的路线一方面是因为财务数据、客户信息、合同内容这些敏感数据不允许出内网另一方面也是想验证一下轻量到什么程度还能干成事。两周内把MVP跑通一个月内让业务部门实际用起来这才是中小企业需要的中台节奏。2. 技术选型复盘我为什么最终选了 Ollama Dify 这一套2.1 模型服务层本地部署大模型是底线整个方案里模型层是第一块拼图。我最早考虑过直接调云端大模型API效果确实好但一个现实问题摆在那要处理的是财务单据、合同文本、客户信息这些数据别说传出去连走公网都会让合规那边炸毛。所以结论很明确必须本地部署私有化运行。模型服务层我选了Ollama。原因不复杂安装简单、依赖少、对GPU的要求灵活而且社区里现成的模型可以直接拉取。这次我用的是DeepSeek系列的开源模型来跑表单理解、字段抽取和对账辅助。选择DeepSeek主要看重它中文能力强在处理中文发票、合同条款、公司全称这些文本时明显比同参数级的其他模型更稳。Ollama配合本地GPU跑起来之后模型调用方式和OpenAI兼容接口层面非常省心。如果你所在团队已经有用惯了vLLM或者llama.cpp的也可以平替。但Ollama对中小团队最友好的地方在于它把模型下载、加载、常驻管理、并发控制都做成了傻瓜式操作可以少操很多心。2.2 应用编排层Dify 承担了80%的脏活模型层就绪之后接着要想的是怎么让业务人员用得起来总不能让他们打开终端去敲Python调模型接口。我选Dify作为应用编排层核心看中的是三点。第一它天生支持对接Ollama这类本地模型供应商可视化配置就能把模型接进来。第二它内置了知识库和检索增强生成RAG的完整链路后面做合同条款问答、制度查询直接能复用。第三它支持编排多步骤工作流这意味着读文档、抽字段、填表单、送人工确认这条链路不需要写一堆胶水代码在界面上就能拉出来。实际用下来Dify让我少写的代码量在一千行以上。模型调用、Prompt管理、日志追踪、权限控制都有现成的界面这对一个主要精力在业务落地的团队来说价值非常大。2.3 模型选型7B、14B、32B怎么实测取舍模型参数档位的选择直接决定了显存需求、推理速度和效果上限。我在这套中台里前后测了7B、14B、32B三个档位的模型结论值得分享一下。模型档位显存占用16bit精度推理速度实测表格/单据字段抽取效果适用场景7B约6-8G很快简单表单可以长表格容易漏字段短文本分类、轻量抽取14B约12-16G中等大部分表格理解够用偶有口径漂移表单自动填充主力32B约24G以上明显变慢效果好但排队时间长复杂合同条款理解、高精度场景对仅做把采购单里的供应商、金额、日期抽出来这类任务14B是性价比最高的档位单卡24G显存就能跑得动速度和质量的平衡点最好。7B用在从聊天记录、备注文本里提取关键词这类轻量任务上没问题但放到整张结构化表格上就不太够用了。32B我最后只在合同条款深层理解这类非高频场景里保留了一个实例平时不常驻。3. 消除重复录入的实现细节从人填表到AI填表3.1 场景还原一张采购单在三个系统里被录入三次先还原一下部署前的业务流程。业务员收到供应商发来的采购单是一张PDF或者照片。他先要打开ERP系统把采购单号、供应商名称、订单日期、物料明细、金额逐行填进去然后打开OA系统走审批再把同样的信息填一遍审批通过后财务人员拿到单据还要在财务系统里把供应商、含税单价、税额这些字段再录一次。一张单子三个系统三次录入中间任何一次敲错一个数字后面对账就多一个差异点。这就是典型的重复录入加对账困难的组合问题。AI中台要替代的是把这张采购单从解析到填表的整个过程自动完成。拆解下来就是四步原始单据解析、业务要素抽取、目标系统字段映射、自动提交或人工确认。3.2 基于表单理解Agent的自动填充链路我在Dify里搭了一套表单自动填充Agent工作流核心流程是这样的接收端业务员把采购单文件传到指定入口可以是钉钉/企微机器人也可以是一个简单的上传页面。解析端如果是PDF或图片先调用OCR服务转成文本如果是Excel或Word直接解析成纯文本。抽取端把原始文本交给本地大模型Prompt里明确要求输出JSON格式字段包括供应商全称、采购单号、签订日期、物料清单、含税总金额、币种、付款条件。这个环节是AI中台的核心能力所在Prompt设计得非常关键。映射端拿到JSON后通过一段Python脚本按目标系统的字段规则做映射。比如ERP里的供应商字段是编码而非名称就调用基础资料接口把名称翻译成编码。提交端调用各系统的API自动填入表单。考虑到业务系统的稳定性我在提交前插入了一个人工确认环节——所有字段自动填好页面展示给业务员他扫一眼点确认系统才真正提交。这套链路跑通之后业务员处理一张采购单的时间从十五分钟缩短到一两分钟主要时间花在审核AI填得对不对而不是自己打字。3.3 OCR与模型分工用本地视觉模型吃掉不规范的纸质单据整个链路里最容易翻车的环节其实是OCR而不是大模型本身。如果单据是结构化的电子文件比如规整的Excel大模型抽取非常轻松。但现实业务里永远有大量的扫描件、拍照件、传真件表格线歪的、印章盖在文字上、字迹深浅不一。我在OCR选型上坚持走本地路线核心原因是合规。发票、合同这些单据直接传云OCR是在给自己挖坑。我用了PaddleOCR作为基础识别层它在中文字符、表格线检测上的表现在开源方案里算是第一梯队。每次扫描件先过PaddleOCR识别出文本块再做版面还原把表格结构尽量还原成表头-单元格的对应关系然后再交给大模型做字段抽取。这里有一个重要经验不要试图让一个大模型直接读懂扫描图片里的表格那样鲁棒性会很差。正确的做法是OCR负责看得见大模型负责看得懂两者各管一段。这个分工在后面踩坑章节我还会再展开说。4. 消减对账困难的实现细节把人对账改成机器先对一遍4.1 先把四张表的口径拉齐字段映射与标准化对账困难最终的落地表现是财务人员每月要把业务系统里的应收/应付数据、银行实际的流水、发票系统里的开票记录、以及内部账套里的科目余额四张表来回比对。做AI中台之前我一直以为对账的难点是找差异做之后才明白真正的难点是在找差异之前先把四张表变成同一套语言。我建立了一张字段标准化配置表把四张表里的关键字段逐一映射到统一口径维度业务系统口径银行流水口径统一标准化规则金额含税金额实际到账金额统一转为不含税金额并保留两位小数日期业务确认日期银行入账日期统一按自然日格式化允许三天在途时间差异客商名称客户全称账户名称/付款方备注去除公司后缀、括号及地域差异做归一化单据号订单号流水备注中的单据号提取由字母和数字组成的连续串做匹配键标准化这一步既用了规则脚本处理确定性的格式转换也用大模型处理那些规则处理不了的脏文本。典型的就是客商名称归一化纯粹靠正则根本写不全交给大模型按统一规则重写后准确率高很多。4.2 用向量相似度做模糊匹配解决同一笔交易两种写法的难题口径拉齐之后你会发现还有一个顽固问题两边数据里这同一笔长得不完全一样。对方单位名称差几个字备注里单据号格式不同金额因为手续费导致差几块钱。这些数据用传统的关系型数据库JOIN是永远对不上的。我的方案是在匹配环节引入向量检索。具体做法是把标准化之后的对账记录里的关键字段客商名称、摘要、备注、金额近似值拼成一段文本用Embedding模型转成语义向量写入向量数据库。做匹配时拿另一侧数据的向量去检索最相似的N条候选再结合金额、日期做二次过滤最后形成一个带置信度分数的匹配建议。比如银行流水摘要里写货款-华信科技和业务系统里记账摘要写华信科技北京有限公司 9月订单款传统关键字匹配根本对不上但向量化之后这两条文本的语义方向非常接近余弦相似度很高系统会先把它们作为疑似匹配对推给财务复核。这一步直接解决了我之前最头疼的脏数据问题。匹配不是终点人审闭环必须保留。我设了一条规则相似度超过0.95且金额日期一致的直接自动勾稽相似度在0.8到0.95之间的进入待复核队列由财务一键确认低于0.8的才真正进入人工排查列表。这样设计之后财务真正需要一行行肉眼看的数据量降到了原来的五分之一以下。4.3 异常报告怎么设计才不会又被扔进垃圾桶很多系统做对账报表习惯于把所有对不上的记录全部列出来一张Excel几百行发给财务财务根本看不过来最后结果就是报表被归档问题还留在那。这次我让AI中台在生成异常清单之前先对每一条差异做一次归因解释。系统会先判断这条差异属于哪个类别是时间差导致的未达账项还是金额口径不一致还是名称写法差异或者是真正的漏记错记。自动生成的报告按风险等级排序同时附上机器对该差异的初步解释。比如某条流水在系统中找不到对应单号模型会结合备注信息、金额相似度、对方名称相似度给出一个结论疑似与业务单BD20241008-003存在两日到账时间差建议核对9月29日以后入账流水财务只需要验证这个解释是否成立而不是从头大海捞针。正确的归因做到位AI中台在财务同学心里的信任度才算真正建立起来。5. 从0到1部署实录硬件、安装、调优全记录5.1 硬件清单与资源预算16G显存够不够用我最开始只有一台旧工作站单卡16G显存。实测发现跑7B模型做轻量任务完全没问题但要常驻14B模型同时做表单抽取和对账归因显存就吃紧了并发一上来就开始排队。后来调到一台双卡机器上显存问题彻底缓解。根据这几个月的实测我给不同预算的团队列个参考场景推荐硬件说明试点验证1-2个应用单卡16G显存跑7B模型做轻量抽取够用但别贪高并发正式上线3-5个应用单卡24G显存14B模型常驻兼顾效果和并发多部门推广5个以上应用双卡48G显存14B7B双模型常驻OCR和向量检索齐跑另外提醒一句中台不是一台放在你工位下面的玩具机最终是要让业务部门通过内网访问的。所以网络部署至少要满足模型服务绑定内网地址Dify平台对业务部门开放数据链路全在内网闭环。5.2 Ollama 部署细节模型文件管理、并发参数、开机自启Ollama的安装本身没什么好说的一条命令就搞定。真正要花心思的是运行参数。我在部署时做了三件事设置OLLAMA_HOST让服务监听内网IP而非本机回环设置并发参数控制同时处理的请求数设置OLLAMA_KEEP_ALIVE控制模型在显存中的驻留时间。举个例子Linux上用systemd管理Ollama服务时我改了service文件里的Environment。要注意OLLAMA_MAX_LOADED_MODELS这个参数多应用场景下如果不限制Ollama会把多个模型同时驻留显存直接导致显存被打满后面我会在踩坑章节详细说。模型管理上建议把下载好的模型文件和模型运行时的缓存目录单独挂到数据盘避免系统盘被几个大模型文件塞满。这个看起来很基础的细节实际操作中真的会踩坑。5.3 Dify 部署细节Docker Compose 编排、接入 Ollama、环境变量Dify的官方部署方式是Docker Compose直接拉取全套容器就能起来包括API服务、Web服务、Worker、数据库以及可选的向量数据库和Redis。整个过程我没有改代码只调了两个地方。一个是模型供应商配置。Dify后台模型供应商页面里可以直接添加Ollama填上Ollama的内网地址一般是http://内网IP:11434把要用的大模型名称填进去就能在应用里调用了。模型名称要跟Ollama里实际拉取的模型完全一致比如我用的模型全名是deepseek-r1:14b这里就不能只写deepseek。另一个是向量数据库。Dify默认支持多种向量库我用的是Qdrant同样走Docker方式部署。Dify界面上配置好之后知识库上传文档时会自动完成切片和Embedding写入。这一步做完Dify后台就能直接创建聊天助手和工作流应用了。5.4 向量检索服务的初始化embedding 模型选择与索引构建向量检索这块最关键的是选对Embedding模型。中文场景不建议用通用英文Embedding模型跑效果会差很多。我用了BGE系列的中文Embedding模型在客商名称、摘要文本的语义匹配上表现明显更好。初始化向量索引时有两个参数要特别注意文档分片大小和重叠长度。分片太大检索时片段粒度太粗命中不精准分片太小上下文信息不完整模型理解困难。我最后用的分片大小是500字符、重叠100字符对合同和制度类文档效果比较均衡。建立索引后一定要做一次抽样验证拿几条真实业务数据去搜检查相似度排序是否符合预期。不要等上线了才发现检索结果全是垃圾那段debug时间会非常痛苦。6. 踩坑实录三个最典型的部署与运行故障排查过程6.1 Ollama 服务偶发假死显存没释放还是并发队列堵了现象很典型Dify里的工作流跑了一周某天开始所有请求都超时日志里全是连接错误。第一反应是不是模型崩了重启Ollama服务确实能恢复但过一两天又复发。我开始逐步排查。先用nvidia-smi看显存占用发现显存几乎被打满但奇怪的是Ollama刚启动时只加载了一个模型。再用ollama ps查看当前驻留的模型结果发现除了表单抽取用的14B模型还有一个7B模型和一个小模型也同时驻留在显存里。原因就出在OLLAMA_MAX_LOADED_MODELS这个参数上如果不设置或设置太大Ollama会根据请求自动把用到的模型全部加载进显存多个模型挤在一起显存不够就开始交换整个服务就假死了。修复方案明确设置OLLAMA_MAX_LOADED_MODELS1强制同一时间只驻留一个模型同时把不同模型放到不同的Ollama实例或服务端口上避免相互挤占。改完后再没有因为这个原因复发过。6.2 Dify 的应用流偶发超时连接池与大上下文的全链路定位第二个坑是Dify工作流偶发超时而且很有规律每天上午十点前后必现下午偶尔来一次。排查过程分了三步先看Dify日志发现大量请求卡在等待模型供应商响应这一步再看Ollama侧日志发现上午那个时段模型推理耗时突然从两三秒涨到三十秒以上最后点开具体请求发现那些超时的请求都是长上下文请求。根因有两个。一是上午是业务高峰期并发请求多Ollama默认串行队列处理不过来大量请求排队。二是Dify里有些Prompt里把历史对话和参考资料全部塞进了上下文导致模型输入Token膨胀推理时间和显存占用都上去了。调整方案在Dify侧对应用做流量拆分高频短任务走一个轻量模型长文档理解任务单独走一个模型同时限制上下文长度给工作流节点加上了最大Token截断。并发方面把OLLAMA_NUM_PARALLEL设置成按显存余量计算的合理值让Ollama能够并行处理互相独立的请求。改完之后高峰期的平均响应时间重新回到了三秒以内。6.3 中文表格识别乱码从通用视觉模型到本地OCR的切回最开始我图省事想直接让大模型看扫描件的图片结果发现一个非常麻烦的问题识别结果里频繁出现错字、漏行最离谱的是金额栏的收款人三个字被识别成收 款 人中间多了空格后面字段抽取全乱了。排查过程是这样的我先拿原始图片和模型输出对比发现模型对密集表格的辨认能力并没有宣传的那么好特别是表格线、印章、手写批注混在一起的扫描件输出稳定性很差。然后又对比了一条关键链路让同一个模型去读OCR出来的文本发现正确率一下子上来了很多。原因也简单视觉大模型对中文密集表格的抗干扰能力不足而OCR模型经过专门训练对版面结构更敏感。数据库场景下的表格乱码最佳路线是专业OCR配合规则做版面还原大模型只做语义抽取。我把这条链路的顺序改过来之后识别准确率从不到八成直接拉到了95%以上问题彻底解决。7. 上线三个月后的复盘效果、成本、还能怎么扩展7.1 重复录入工时下降多少才算及格上线三个月数字算是比较实的财务和业务侧日均处理的单据量没有变但单张单据的综合处理时间从平均十五分钟降到了不到三分钟。人工介入的动作从逐字段录入变成了查看并确认。重复录入相关的工时整体下降了接近60%。更重要的是错误率的下降。以前人肉录入一张单子总有一两个字符出错的风险现在字段由模型从原始单据抽取再经过标准化和规则校验录入类错误基本归零。财务那边反馈最明显的感受是月底对账的不平项少了因为源头录入错得少了后续所有环节都跟着顺了。7.2 对账异常率的变化与复核机制的调整对账单侧的月度异常条目数从上线前的每个月两百条左右降到了现在的四五十条而且这四五十条里大部分是AI已经做过归因解释、只需要财务确认的情况。财务真正需要从头人工排查的最后只剩十几条。财务部门的操作习惯也发生了实质变化。以前是月初花两三天时间逐笔核对现在变成每天花十分钟看AI推送的待确认队列效率提升的同时还不用加班了。新的复核机制是月度抽盘加异常点抽查也就是说因为AI把源头的账目录错了堵住财务不再需要等月底大扫除。7.3 下一步玩法从填表/对账延伸到知识库问答与报表解释这套中台跑稳之后我目前的规划是先把知识库问答做起来把采购合同、财务制度、报销标准这些文档传进去让新员工直接问AI差旅报销要什么材料供应商准入流程是什么减少事务性咨询对老员工的占用。再往后可以尝试让AI解释财务报表里某个科目变动的原因这个需要的数据质量要求更高我打算先在单个事业部试点。中台的边界很重要。我不会盲目往里面塞功能每个新增应用都要先回答一个问题它是替代人工真的在减少重复劳动还是仅仅在制造一个新的演示Demo。目前看来把基础能力平台化之后新增一个应用的成本确实在快速下降这也是将这套轻型架构继续扩展的信心所在。如果只让给后来者一句忠告我想说别一上来就追求建设一个宏大完整的中台。先把一两个真正让人痛到不行的流程跑通AI的能力自然会沉淀为平台能力中台是打出来的不是规划出来的。