财务部的小王每天上午雷打不动要做两件事把供应商发来的PDF发票手工录入ERP再把银行流水和业务系统的回款记录一条条拉出来比对。这两件事我观察了很久它们几乎消耗了财务团队三分之一的工作时间而且越到月底对账差异越多返工越频繁。这正是我决定在公司内部部署一套轻型AI中台的原因。所谓轻型AI中台不是像大厂那样搭一套K8s集群加数据湖的重型平台而是把本地部署的大语言模型、流程编排、规则引擎和单据识别能力组合起来形成一个专门处理“数据识别、结构化、匹配、流转”的智能调度层。它解决的就是两个最接地气的问题把重复录入交给机器自动完成把对账差异从靠人肉排查变成机器自动配对加AI辅助说明。整套系统的核心不在“模型有多聪明”而在“流程有多稳”。下面我就从选型思路、系统设计、核心环节实现、完整部署过程到常见问题排查把这次落地的整个链路记录下来。如果你正在推进企业数字化建设、负责财务信息化或者对本地部署大模型应用感兴趣这篇应该能帮你少走不少弯路。1. 整体设计与选型思路1.1 先想清楚AI中台在这里到底解决什么问题很多人一听到“AI中台”第一反应就是大数据平台、模型训练平台那套思路。但在我们这种几十人IT团队的企业里真正的痛点根本不是缺乏算法能力而是业务数据流转太原始。供应商发来的是PDF、扫描件、Excel财务系统是老的客户端架构ERP有API但不全开放银行流水只能导出Excel再手动整理。每多一个系统就多一次人工搬运。AI中台在我这里的定位是业务系统之间的“智能翻译官”。它不理解业务战略不负责数据挖掘只做一件事情从各种非结构化、半结构化数据中提取出标准字段按照你定义好的规则和流程写入正确的目标系统并且在出错时及时找人确认。这个定位听起来很朴素但它直接决定了后面所有技术选型的方向——我们要的不是算力最强的大模型而是稳定、可控、能在内网跑起来的组合能力。另一个关键问题是确定边界。一开始我们也想过做一个“全能中台”统一登录、统一权限、消息中心、调度中心一套全上。后来复盘过去做平台失败的经验基本都是范围失控拖死的。所以这次只圈定了两个业务目标录入自动化和对账预配对。所有模型、流程、规则都围绕这两个目标展开其他需求一概不接。这种“窄而深”的策略是轻型AI中台能够在一个月内真正落地而不是PPT落地的最重要原因。1.2 选型路线为什么是“Docker Compose Dify Ollama”部署方案我们对比了三类。第一类是云服务方案。直接把OCR和大模型能力都用云端API开发快、效果也不差。但财务数据、供应商数据出内网这件事法务和财务负责人那一关根本过不去合规风险太大直接排除。第二类是重型自建方案。Kubernetes全家桶加机器学习平台加数据湖再招两个算法工程师。这个方案的维护成本以季度为单位增长而且我们也没有足够的GPU资源和大数据体量去喂饱这套平台更别说还要额外招人长期维护。也排除。第三类是轻型组合方案。核心是Docker Compose管理所有组件Dify做工作流编排和Agent调度Ollama加载开源大模型再配合Python写的对接服务和规则引擎。整个系统跑在一台64G内存的服务器加一张16G显存的GPU卡上成本可控交付周期短。选Dify而不是直接用LangChain写全套是因为Dify已经解决了应用接入层的问题可视化编排工作流、Prompt管理、知识库管理、日志追踪、API封装全都现成。我们的开发量集中在业务对接层而不是重复造轮子。Ollama则胜在轻量一条命令就能启动一个模型服务而且支持内网离线运行不需要开通外网访问这对财务场景至关重要。1.3 系统架构与数据流转设计整体架构分四层数据接入层邮件收取、FTP目录监听、人工上传统一收拢进一个输入目录或消息队列。智能处理层文档解析PDF/扫描件转换、OCR识别、大模型字段抽取、规则校验、字段补全。业务对接层调用ERP接口、财务系统中间表写入或通过Webhook通知审批人。人机协同层一个轻量的复核页面展示机器识别结果和置信度人工确认或修改后放行。数据流转的主链路是原始单据进入输入目录后由监听任务触发处理流程。文档先做解析和预处理抽取出字段后先按规则库做硬校验校验不通过的直接进入人工队列通过后交给模型做进一步标准化。标准化结果写入待办表再由对接服务通过幂等接口写入业务系统。整个处理过程全部记录审计日志每一步都能回溯。这个架构最重要的设计原则是“人机协同兜底”。我们设置了明确的置信度阈值高于95%的自动写入低于70%的直接进入人工处理70%到95%之间走抽检或关键字段复核流程。这样既保证了效率也守住了财务数据这条底线。2. 核心环节一消除重复录入的实现方案2.1 重复录入的三类典型场景第一类是供应商单据。采购同事收到供应商邮件发来的PDF发票或送货单需要把发票号、日期、金额、税号、物料清单手工敲进ERP系统。一天几十张单据每张要五分钟还要仔细核对金额和税率眼睛都看花。这个场景的特点是格式不统一每个供应商的模板都不一样。第二类是银行单据。银行回单、流水明细从网银导出来是Excel但要录入资金管理系统时又有一套字段要求。手工调整列、复制粘贴、格式转换费时费力还容易漏行。第三类是客户订单。销售通过邮件或IM发来订单截图、PDF、Excel报价单客服需要把这些内容重新录入到OMS系统。很多客户是固定格式但总有例外例外就是错误高发区。这三个场景都有一个共同特点数据本身已经存在只是存在于非结构化的载体里。搬一次就是浪费一次时间搬错一次就是一个对账差异。要消除重复录入本质上不是消灭键盘而是消灭“数据的二次编码”这个环节。2.2 单据识别与结构化抽取的技术方案处理流程分四步文档预处理、OCR识别、LLM字段抽取、校验输出。文档预处理就是把PDF、图片、Excel统一转成模型可以处理的形式。文本型PDF直接用PyMuPDF提取文本层扫描件需要先转图片再走OCR。我们用的是PaddleOCR它在中文单据上表现比Tesseract好不少尤其对发票、送货单这类印刷体中文识别很稳。表格结构的还原用PP-Structure的表格识别能力能把表格区域转成HTML结构这样模型能理解行列关系。预处理完成后把文本内容、表格结构和图片片段一起交给大模型。这里的关键不在于模型多大而在于你如何约束它。我们的Prompt模板里包含三要素任务说明、输出Schema、Few-shot示例。任务说明要讲清楚“从以下单据中提取字段并严格按照JSON格式输出”输出Schema用JSON Schema定义字段类型和枚举值模型输出后直接用解析器校验Few-shot示例每类单据放2到3个典型的输入输出对让模型明白你的格式习惯。抽取时模型参数也得注意。temperature设置成0top_p设置成0.9左右减少随机性。输出格式用结构化输出模式而非自由文本这是保证后续程序能直接处理的基础。模型我们用的是Qwen2.5 14B的Q4量化版在16G显存上跑得很流畅抽取准确率在测试集上能到96%以上。这个准确率看着不算高但注意这是“严格逐字段匹配”的准确率实际业务上更关注关键字段金额、编号、日期的准确率这三个字段我们单独做了规则校验兜底。2.3 与ERP系统的对接方式与幂等设计识别出来结构化字段后写入ERP是另一个容易翻车的环节。我们优先走ERP的API接口。如果目标系统没有标准API就用中间表方案建一张待入账表ERP侧通过定时任务读取并处理。最不推荐的是用RPA模拟人工点击虽然通用但屏幕分辨率、系统版本、响应速度都会影响稳定性维护成本极高。每次写入都必须做幂等设计。什么是幂等就是“同一个单据即使提交两次也只会在目标系统生成一条记录”。实现方式很简单在待入账表里加一个业务主键比如发票号加供应商加固定金额生成的摘要写入前先按主键查询已存在就直接返回原记录。平时不起眼但万一监听任务重复触发或网络重试这个设计能避免灾难性的重复单据。对接服务本身我们写了一个Python Flask应用监听Dify工作流的Webhook回调。Dify跑完抽取流程后把结构化结果POST到这个服务服务再做最终校验、记录日志、调用ERP接口。ERP返回成功后回调更新状态失败则标记为待人工处理并把错误信息关联到该单据上。2.4 人机复核与兜底机制机器不是万能的总有单据识别不出来或者识别错。所以复核机制不是“要不要”的问题而是“怎么设计”的问题。我们最终采用三层兜底。硬校验不过的比如金额前后不一致、必填字段缺失、日期格式非法自动进入人工队列。置信度低于阈值的比如模型对某个数字拿不准进入人工补充队列。正常自动处理的单据每天抽检5%确保模型没有悄悄退化。复核界面一定要轻量。我们用一个简单的Web页面左侧显示原始单据图片或PDF预览右侧显示识别出来的结构化字段关键字段旁边显示置信度。操作员只需要看一遍核对金额和单据号点确认或修改后提交。整单复核时间控制在30秒内。这个界面不要追求花哨能用、够快、字段和原单能对上就是最好的。3. 核心环节二对账困难消减的实践3.1 对账困难的根本原因拆解对账难难在三个字不一致。同一笔交易在A系统里是“20250601 收款 100.50”在B系统里可能是“2025-06-01 进账 100.5”在C系统里甚至金额被分成两笔。人工核对的时候脑子要同时处理日期格式差异、金额精度差异、单据编号规则差异、时间口径差异这本身就违背了人脑的工作方式。具体拆解最常见的是四类时间口径不同银行流水的记账日、ERP的入账日、渠道账单的出账日往往相差1到3天。编号规则不同回单号、流水号、订单号、发票号各系统有各自的编码规则无法直接关联。金额拆分与合并一笔订单分两次收款或者多笔订单合并打款流水对不上单据。数据缺失或错误手工录入时漏了一位卡号小数点打错上传时Excel列错位。这些问题靠人肉排查本质上是拿时间换确定性而且很依赖当事人的经验和细心。一旦关键人员休假或者离职对账节奏就会崩。AI中台的价值不在于消灭所有差异而在于把差异从“大海捞针”变成“明确标出类别你只需看这十几条”。3.2 数据口径统一先做一张对账事实表开始自动化对账之前我们第一步做的不是写匹配算法而是统一数据口径。所有参与对账的数据源不管是银行流水、ERP应收、渠道账单还是手工Excel都要先清洗进一张“对账事实表”。事实表的核心字段固定为对账日期统一取业务发生日期并归一化为YYYY-MM-DD格式、金额统一为分整数存储避免浮点误差、单据编号统一为大写去空格、来源系统标识、业务类型、对方账户或主体。清洗规则包括去除金额前后空格和千分位逗号、日期格式统一转换、编号中的小写字母转大写、全角字符转换半角、币种按统一汇率折算。这张表就是整个对账系统的地基。口径不统一的时候再智能的匹配算法都是空转。我们当时一次性把近两年的历史数据全部清洗入表跑出来的基础差异清单让财务团队都吃了一惊——很多延续多年的“糊涂账”其实只是格式问题根本不是真正的金额差异。3.3 自动配对规则从精确到模糊的渐进式算法统一口径之后配对就变成一个算法问题。我们按复杂度分了三级。第一级是精确匹配。三要素完全一致金额、日期、单据编号。这类直接自动结对生成配对成功记录占全部流水的70%到80%。第二级是模糊匹配。比如金额一致但日期差一天或者编号差一位。这种情况不能直接自动结对而是标记为“疑似匹配”并附上匹配理由。财务人员只需要看一眼确认或驳回。这一级能再解决15%到20%的流水。第三级是AI辅助识别。完全无法匹配的孤单由大模型分析差异原因并打标签可能是手续费、滞纳金、汇率差、合并打款、重复付款、遗漏入账等。模型不直接下结论而是给出“最可能的原因加依据”财务人确认后归类。配对算法我们用的不是复杂机器学习模型而是一个带权重的评分函数。金额完全一致得50分日期误差在3天内得20分编号前几位一致得10分付款方名称相似经验证后加10分总分超过70分进入疑似匹配列表。这些规则全部写死在规则引擎里可配置、可解释、可审计。我在这个环节强烈建议不要急着上深度学习模型先用手工规则把大块问题解决掉规则解决不了的尾巴再用LLM去分析成本最低、效果最可控。3.4 LLM辅助差异归因让机器先解释一遍对账特别让人烦的地方在于看到差异之后还要想“这一条为什么差”。我们让LLM来做这部分工作。具体做法是把银行流水记录、ERP记录、配对失败摘要打包成一段结构化的文本输入给本地部署的模型Prompt要求它分析两边的数据差异列出可能原因每个原因给出概率和依据字段最后以固定的JSON格式输出。比如“差异原因多笔订单合并支付依据流水金额等于订单A加订单B金额之和日期相差1天双方账户一致”。这个功能上线后财务团队的反馈非常一致原来排查一条差异平均要10到15分钟现在看一遍AI给出的差异分析再核对一下两个关键字段两分钟就能确认归类。更重要的是因为模型是本地部署财务数据不进外网合规上没有心理负担。我必须强调LLM在这里是“辅助归类”而非“自动决断”。所有AI归因结果都只是草稿必须人工确认后才允许修改账务状态。原因很简单对账结果直接关系到资金和财务报表这个级别的操作AI只能提建议不能替人做决定。这也是我们向财务部门推广项目时最有力的“信任建立点”。4. 实操部署全过程记录4.1 硬件环境与部署规划部署在一台普通的2U服务器上64GB内存、16核CPU、一张RTX 4080 16GB显卡、1TB NVMe SSD。这套配置在当前市场不算贵但对我们的业务量来说完全够用。如果你预算更低纯CPU部署7B量级模型也能跑只是单条识别耗时会长一些。如果你的单据量很大可以考虑两张卡分别跑OCR和LLM。所有组件用Docker Compose统一编排包括Dify、Ollama、PostgreSQL、Redis、向量数据库Dify内置的Weaviate或Qdrant、对接服务。容器化最大的好处不是技术炫酷而是环境一致性换一台服务器一份compose文件加一个挂载目录就能复现整个环境。升级时也只操作容器镜像不影响宿主机。存储上要单独规划一下。原始单据、识别结果、审计日志都要保留至少留半年的量。我们用了一个简单的目录约定按日期分目录存放原始文件处理结果写入数据库PDF和图片原文件只保留路径引用避免数据库被二进制文件撑爆。4.2 大模型本地部署与量化选型大模型用Ollama加载。安装很直接下载安装包然后执行 ollama pull qwen2.5:14b。如果想跑DeepSeek系列的蒸馏版本也可以拉取 deepseek-r1:14b。这两个都是中文场景下非常稳的选择。14B模型在Q4_K_M量化下占用约9GB显存16GB卡跑起来单条识别耗时2到4秒足够支撑我们每天几百张单据的量。量化选型有个实践结论Q4_K_M在很多文本抽取任务上和满精度几乎没差别但在表格结构还原和数字识别的极端场景下会掉点。我们的处理方式是文本类单据用Q4量化扫描件表格类单据单独做一个使用Q8或FP16模型的服务按文件类型路由。这是细节但就是在这些细节上一个系统的“好使”和“勉强能跑”就区分出来了。Ollama本身不需要做什么复杂配置但建议关注两个环境变量OLLAMA_NUM_PARALLEL控制并发请求数OLLAMA_MAX_LOADED_MODELS控制同时加载的模型数量。我们用默认并发配置就够了如果你们业务有高并发再调这两个参数不要上来就调容易显存溢出。4.3 Dify工作流编排实战Dify安装在Docker Compose编排里跑起来之后核心工作是创建一条“单据识别与录入”工作流。工作流的触发节点用Webhook。这样外部系统比如监听FTP目录的脚本可以把文件路径或者文件Base64内容POST进来。工作流内部按顺序串联以下节点文档解析节点调用OCR服务或解析服务把PDF和图片转成文本和表格结构。LLM字段抽取节点配置模型供应商为Ollama模型选qwen2.5:14bPrompt用上文所述的三要素模板。代码节点写一段Python代码做硬校验和置信度判断。校验规则包括金额一致性、日期格式、必填字段置信度低于阈值的输出“需要人工复核”标记。HTTP请求节点把结构化结果POST到对接服务的特定接口触发ERP写入或人工队列入库。这些节点全部可视化拖拽完成每个节点都有日志跑挂了能看得到具体是哪一步出错。和LangChain那种纯代码编排相比Dify对业务同事的理解门槛低很多财务的同事甚至能自己在界面上看每个单据走到了哪一步。一个容易踩坑的地方是Dify的HTTP请求节点默认超时时间不长而大模型抽取在高峰期可能要花十几秒。要在节点配置里加大超时时间同时对接服务那端要接受异步回调不然前端会一直显示“处理中”。4.4 对接服务与业务系统集成细节对接服务是一个独立的Python Flask应用职责有三块接收Dify回调、调用ERP接口、维护待办与日志。Docker里单独起一个容器和Dify用同一个Docker网络通过服务名互相访问。ERP接口对接是整个过程最费周章的部分。老ERP的接口文档不全字段命名和我们的标准字段对不上。我们写了一个字段映射配置表用YAML维护把ERP的字段名映射到中台的统一字段名。这样以后换ERP系统只需要改映射配置不需要改处理逻辑。接入流程的实际细节新增单据时服务先查询一次业务主键是否已存在存在就返回已有记录ID不存在才调用ERP新增接口。ERP返回成功后在待办表标记状态为“已入账”并记录ERP的单据号。调用失败时标记“入账失败”错误信息拼进日志触发通知Webhook让值班人员第一时间知道。日志表会记录每一次调用的请求、响应、耗时和最终状态这个表也是后续排查问题和向审计解释过程的关键。5. 常见问题与排查技巧实录5.1 识别准确率不达标时的排查顺序如果你的抽取效果不稳定我建议按这个顺序排查不要一上来就换大模型。首先看预处理。扫描件有没有去做OCR文本型PDF是不是直接读了文本层但没有保留表格结构表格结构丢失会让模型分不清哪个数字属于哪个字段这是准确率暴跌的头号原因。其次看Prompt。你的任务说明是否够具体Few-shot示例里的输入输出是否覆盖了业务中的典型格式我们当时加了两个反例告诉模型什么样的输出是错的准确率立刻涨了几个点。最后看输出校验。你的JSON校验逻辑是否太宽松比如日期字段只检查格式不检查合理性9月31日这种非法日期也会放过。多写几条硬校验宁可多走人工队列不要错放。我这里给一个判断基准金额、日期、单据编号、供应商名称四个关键字段的准确率至少要达到98%以上才可以考虑全自动写入。达不到宁可多一点人工复核。5.2 并发与资源瓶颈处理实际运行中我们遇到过一段时间的排队积压。原因是下午两点到四点是供应商发单高峰OCR和LLM服务同时被十几个请求打满。排查后发现是Ollama默认并发处理能力有限而且Dify的Worker数量设置太低。解决方法是组合拳给Ollama调高OLLAMA_NUM_PARALLEL参数控制在4到6Dify的Worker从1个扩到3个给OCR服务加了一层内存队列避免请求直接怼到PaddleOCR进程上。调整后高峰期的吞吐量翻了近三倍积压问题基本消失。如果你们量更大我建议把OCR和LLM拆到两台机器上。OCR吃CPU和内存LLM吃显存拆开后各自扩容都更灵活。不要一台机器硬扛所有环节瓶颈定位和维护都会痛苦很多。5.3 数据安全与权限管理财务数据的中台安全怎么强调都不过分。我们的原则是整套服务只允许内网访问不对公网开任何端口所有对接服务必须校验来源IP和TokenDify的登录打开SSO操作日志全量留存任何单据的识别结果、修改记录、入账状态都可追索。对模型的限制也一样。模型不做任何摘要、纠错、分析以外的功能Prompt里明确规定“如果遇到无法识别的数据输出error不进行猜测”。比如供应商名称拼写异常时宁可标记人工也不让模型自动“纠正”成它猜的名称。这个约束能防止很多说不清的数据事故。5.4 上线后的运营细节系统上线不等于项目结束反而开始了真正的运营。我们建立了三个常规动作每周统计各场景的自动处理率、人工复核率和异常率自动处理率低于85%就去检查是哪类单据拖了后腿每月用最近一个月的数据重新跑一遍测试集确认模型准确率没有下滑每季度根据新出现的模板补充Few-shot示例和规则。还有一点是我特别想提醒的模型会更新但你的业务标准不应该跟着模型跑。文档、规则、示例都要版本化管理模型升级前后要做一轮回归测试用历史单据跑一遍看有没有倒退。我们专门攒了一个“回归数据集”一百多张各种类型的单据每次升级模型或改Prompt都必须全量通过才能上线。这是轻量级方案里性价比最高的质量保障手段。这次部署给我的体会比预想的要深。项目中真正带来效率提升的不是某一个模型有多强而是把文档解析、LLM抽取、规则校验、人机复核、系统对接这一整条链路串起来的设计。越是看起来“AI”的东西越要把它落在无比具体的业务规则和流程里否则就是空中楼阁。如果让我再分享一条经验那就是一定要从最痛的一两个场景切入先用历史数据做一次回放测试看看方案在真实数据上的表现再决定是否推广。不要一上来就铺开所有场景。先跑通一条线让财务同事看到实实在在的分钟级成果后面所有场景的推广都会顺畅得多。