大模型这个词这两年从技术圈一路烧到了业务圈现在连做行政的同事都会问我能不能用大模型把这一堆扫描件自动录进系统。但真到落地那一步绝大多数人卡住的不是模型本身而是模型怎么接进现有流程——OCR识别出来的文字怎么喂给大模型、大模型输出的结果怎么落到业务系统、私有化部署之后怎么保证稳定调用。这篇就围绕大模型的应用和工具这条主线把我在实际项目里踩过的坑、验证过的方案、以及那些文档里不会写的细节完整地摊开讲一遍。内容会覆盖大模型能力边界、OCR与大模型的衔接、Dify这类编排工具的实战用法、私有化部署的取舍以及华为云这类云平台在其中的角色。不管你是刚接触大模型想找个切入点还是已经在做集成但总在某个环节卡壳下面这些内容应该都能对上你的场景。1. 先搞清楚大模型到底能干什么、不能干什么很多人一上来就问哪个大模型最强这个问题本身就没问到点子上。模型选型的前提是先明确任务类型不同任务对模型的要求差异极大选错了模型后面调参调到天亮也没用。1.1 大模型的三类典型任务与对应能力要求我把日常遇到的大模型任务粗分成三类这个分类直接决定了你该关注模型的哪些指标。第一类是文本理解与生成比如合同摘要、工单分类、客服话术生成。这类任务对模型的语义理解能力要求高对响应速度要求相对宽松。选型时重点看模型在中文长文本上的表现尤其是超过4000字的长文档很多模型在长上下文里会丢信息前面说的重点到后面就忘了。第二类是结构化信息抽取比如从OCR识别出来的发票文字里提取金额、税号、开票日期。这类任务看起来简单实际上对模型的指令遵循能力要求极高。模型必须严格按照你给的字段格式输出多一个字、少一个字段都会导致下游解析失败。我见过太多项目在这里翻车——模型输出了一段根据图片内容这张发票的金额是...结果JSON解析直接报错。第三类是多模态理解比如直接给模型一张图片让它描述内容。这类任务目前成熟度参差不齐简单场景识别物体、读取清晰文字可用复杂场景理解图表逻辑、判断图片中的异常还需要配合专门的视觉模型。1.2 免费API和私有化部署的真实差距热搜词里免费大模型API出现频率很高我理解大家想省成本的心情但这里有几个现实问题必须说清楚。免费API通常有三个隐性限制调用频率限制、上下文长度限制、数据隐私风险。前两个是明面上的第三个才是要命的。如果你处理的是企业内部合同、客户信息、财务数据把这些内容发给第三方API合规上就过不去。这不是技术问题是流程问题很多项目卡在这一步直接推倒重来。私有化部署的核心价值就在这里——数据不出内网。但代价也很明显你需要GPU资源、需要运维、需要处理模型更新。我一般建议按这个逻辑决策场景推荐方案理由个人学习、Demo验证免费API零成本快速验证想法内部工具、非敏感数据付费API稳定性和速度有保障涉及客户/财务数据私有化部署数据不出内网是硬要求高并发生产环境私有化API兜底兼顾成本和稳定性1.3 模型微调不是万能药大模型微调这个词被过度神化了。我见过不少团队遇到效果不好就想微调结果花了两周标注数据、跑了三天训练效果还不如好好写提示词。微调真正适用的场景其实很窄固定格式的输出任务、特定领域的术语理解、风格一致性要求极高的生成任务。比如你要模型永远按某个特定模板输出工单回复微调确实比提示词稳定。但如果是通用问答、文档摘要这类任务先把提示词工程做到位80%的问题都能解决。微调的成本也要算清楚标注数据的人力成本、GPU训练的时间成本、以及后续模型更新时重新微调的维护成本。我个人的经验是除非提示词优化已经做到极限且效果仍不达标否则不要轻易上微调。2. OCR与大模型的衔接最容易出问题的环节OCR和大模型看起来是两个独立的东西但在实际项目里它们几乎总是绑在一起出现。典型链路是图片/PDF → OCR识别 → 文字清洗 → 大模型处理 → 结构化输出。这条链路上OCR环节的问题会直接放大到后面所有环节。2.1 OCR工具选型PaddleX、Tesseract、百度OCR怎么选热搜里出现了PaddleX、Tesseract、百度OCR这几个关键词我分别说说实际使用感受。PaddleX的优势是中文识别准确率高尤其是印刷体文档。但它的坑在于环境依赖比较重而且不同版本的API变化较大。热搜里那条以下ocr代码识别不了韩文就是典型的版本/模型不匹配问题——PaddleX默认加载的可能是中文模型识别韩文自然不行需要显式指定多语言模型。Tesseract是老牌开源方案优势是轻量、离线可用。但中文识别效果确实一般尤其是复杂排版。如果非要用建议配合图像预处理二值化、去噪、纠偏一起用能提升不少。百度OCR这类云服务准确率最高尤其是手写体和复杂表格。但有两个问题一是按调用量收费量大成本不低二是数据要上传到云端敏感场景用不了。我的选型建议是内部非敏感文档用PaddleX本地跑敏感文档用PaddleX私有化对准确率要求极高且非敏感的场景用云OCR。2.2 OCR识别结果的清洗大模型前的必要步骤这一步是很多人忽略的。OCR原始输出里充满了噪声多余的空格、错误的换行、识别错的字符、表格结构丢失。如果直接把这些文字喂给大模型模型会被噪声干扰输出质量大打折扣。我通常做这几步清洗去除多余空白和换行OCR经常在每行末尾加换行导致一段话被切成很多行。用正则把连续换行合并但要注意保留段落分隔。修正常见识别错误比如0和O、1和l、5和S的混淆。这个可以建一个映射表针对你的业务场景定制。表格结构还原OCR识别表格时经常丢失行列关系。如果原文档是表格建议用支持表格识别的OCRPaddleX的表格识别模型、百度OCR的表格接口或者在清洗阶段用坐标信息重建表格。关键字段预提取如果只是要提取几个固定字段可以在清洗阶段用正则先粗提一遍把候选内容给大模型减少模型的负担。提示清洗规则一定要针对你的实际文档类型来定。我见过直接套用网上通用清洗脚本的结果把文档里本来就有的特殊符号也清掉了反而引入新问题。2.3 把OCR文字喂给大模型的提示词设计这一步的提示词设计和普通文本任务不一样因为输入是OCR结果天然带有不确定性。我的做法是在提示词里明确告诉模型输入可能包含识别错误让模型有一定的容错能力。一个实际用过的抽取提示词结构是这样的你是一个信息抽取助手。下面是一段OCR识别的文字可能包含识别错误。 请从中提取以下字段如果某个字段无法确定输出未识别。 字段合同编号、甲方名称、签订日期、合同金额 输出格式严格的JSON不要有任何额外文字。 OCR文字 {ocr_text}关键点有三个声明输入可能有错、明确无法识别时的输出、强制JSON格式。第三点尤其重要我后面会专门讲怎么保证模型输出可解析。3. Dify实战把大模型能力编排成工作流Dify是这两年很火的LLM应用编排工具热搜里dify教程dify工作流 上下文超长dify本地部署教程都指向同一个需求——大家想用它把大模型能力快速组装成可用的应用。我用Dify做过几个内部工具说说真实体验。3.1 Dify解决的核心问题让非算法同学也能搭应用Dify最大的价值不是技术多先进而是降低了编排门槛。以前要做一个上传文档→OCR→大模型抽取→存数据库的流程得写一堆胶水代码。Dify把这些步骤做成了可视化节点拖拖拽拽就能连起来。但要注意Dify不是万能的。它适合流程相对固定、节点类型标准的场景。如果你的业务逻辑特别复杂比如需要根据中间结果动态决定走哪个分支、需要调用十几个不同的外部服务Dify的编排能力会显得吃力这时候还是老老实实写代码更靠谱。3.2 本地部署Dify的坑SSL错误和离线插件热搜里dify ssl错误dify如何离线安装插件dify an error occurred during credentials validation这几个问题我全踩过。SSL错误通常出现在Dify调用外部API时。根本原因是Dify容器内的证书链不完整或者目标服务的证书不被信任。解决办法有两个一是把目标服务的CA证书挂载到容器里二是在Dify的环境变量里配置跳过证书验证仅限内网可信环境生产环境不要这么干。离线安装插件是企业内网部署的刚需。Dify的插件市场默认从公网拉取内网环境访问不了。正确做法是在有网的环境先把插件包下载下来然后通过Dify的本地插件安装功能上传。注意插件版本要和Dify主版本匹配版本不匹配会报各种奇怪的错。credentials validation错误多半是配置的模型API密钥或地址有问题。排查顺序是先确认网络能通、再确认密钥有效、最后确认模型名称拼写正确。我遇到过模型名称大小写写错导致验证失败的这种低级错误排查起来最费时间。3.3 上下文超长问题的处理思路dify工作流 上下文超长是个高频问题。大模型有上下文窗口限制超过就会被截断或报错。Dify的工作流里如果前面节点输出的内容太多传到后面节点就会超限。处理思路有几种在中间加摘要节点把长文本先让大模型压缩成摘要再传给下游。代价是可能丢失细节。分段处理把长文本切成多段分别处理后再合并结果。适合抽取类任务。用变量聚合器控制传递内容热搜里dify变量聚合器使用步骤详解就是干这个的。只把下游真正需要的字段传下去不要把整个上下文都带着走。我个人的经验是从设计阶段就控制每个节点的输出量比事后补救有效得多。每个节点只输出下游需要的最小信息集这是工作流设计的基本原则。4. 私有化部署企业场景绕不开的选择企业大模型私有化部署是热搜里的高频词说明这是很多团队正在做的事。私有化部署不是把模型下载下来跑起来就完事里面有一堆工程问题。4.1 硬件选型的现实考量私有化部署第一个问题就是用什么卡。我的建议是先明确你的并发量和模型规模再倒推硬件。一个粗略的参考7B参数的模型FP16精度下大概需要14GB显存加上推理时的KV Cache实际需要16-20GB。如果要做量化INT8或INT4显存需求能降到一半甚至更低但精度会有损失。并发量方面单张卡能支撑的并发数取决于模型大小和请求长度。我的经验值是7B模型在单张24GB卡上短请求几百token能支撑10-20并发长请求几千token可能只有3-5并发。这个数字因模型和推理框架而异一定要实测。4.2 模型部署框架的选择部署框架主要有几类原生推理框架如Transformers、高性能推理框架如vLLM、TensorRT-LLM、一体化部署工具如Ollama、Xinference。Ollama适合快速验证一条命令就能跑起来但生产环境不太够用并发和稳定性都一般。vLLM是目前生产环境的主流选择吞吐量高、支持连续批处理但配置相对复杂。Xinference的优势是支持多种模型格式、管理界面友好适合中小团队。选型时重点看三个指标吞吐量每秒能处理多少token、首token延迟用户等待时间、显存占用。这三个指标往往互相制约需要根据你的场景做权衡。4.3 华为云在企业部署中的角色热搜里华为云从华为云获取数据华为ict大赛云赛道都指向华为云。华为云在大模型部署这块提供的是算力平台的组合适合不想自己维护GPU集群的团队。它的优势是开箱即用的模型服务和相对完善的周边工具链。但要注意云上部署和本地部署在数据流上是有区别的——如果你的数据敏感度极高云上部署仍然需要评估数据合规问题。我一般建议非核心数据可以用云服务快速起步核心数据还是走本地私有化。5. 那些文档里不会写的实操经验前面讲的都是框架性的东西这一节专门讲那些踩过坑才知道的细节。5.1 保证大模型输出可解析的三个技巧大模型输出JSON格式不稳定是个通病。我总结了三个实用技巧第一用few-shot示例。在提示词里给一两个输入输出的完整示例模型会模仿示例的格式。这比单纯说输出JSON有效得多。第二加输出约束。在提示词末尾强调只输出JSON不要有任何解释文字、不要用markdown代码块包裹。很多模型默认会用json包裹输出这会导致解析失败。第三做后处理兜底。即使做了前两步仍然会有模型不听话的时候。写一个后处理函数尝试从输出里提取JSON部分比如找第一个{和最后一个}提取失败再重试或走降级逻辑。5.2 大模型调用的超时和重试策略生产环境里大模型调用超时是常态。我的配置一般是连接超时5秒读取超时60秒重试2次。读取超时设60秒是因为长文本生成确实需要时间设太短会误杀正常请求。重试要注意幂等性。如果第一次请求实际上成功了但响应超时重试会导致重复处理。对于抽取类任务重复处理问题不大对于有副作用的操作比如写数据库一定要做幂等控制。5.3 成本控制的几个实用手段大模型调用成本很容易失控尤其是用付费API的时候。几个实用手段缓存高频请求同样的输入直接返回缓存结果省下调用成本。用小模型做预处理简单任务用小模型复杂任务才用大模型。控制输出长度在提示词里限制输出长度避免模型生成一堆废话。批量处理能批量的一律批量减少请求次数。5.4 效果评估别只看准确率评估大模型应用效果时很多人只看准确率。但实际业务里召回率和误报率往往更重要。比如信息抽取任务漏掉一个字段低召回和抽错一个字段低准确对业务的影响完全不同。我一般会建一个小的评估集包含各种边界情况正常样本、模糊样本、异常样本。每次调整提示词或换模型都跑一遍评估集看各项指标的变化。这个评估集不需要很大几十条有代表性的样本就够但一定要覆盖你的真实场景。6. 从工具到落地一条完整的实践路径把前面讲的东西串起来给一条从零开始的实践路径。6.1 第一阶段验证可行性先用免费API或本地Ollama快速验证核心想法。这个阶段不要纠结模型选型、不要纠结工程架构就验证一件事大模型能不能解决你的核心问题。如果这个阶段效果就不行后面再怎么优化也是白搭。6.2 第二阶段搭建最小可用流程验证可行后用Dify或直接写代码搭一个最小可用流程。这个阶段的目标是跑通端到端不追求性能和稳定性。OCR、大模型、存储各环节先跑通哪怕是用最土的办法。6.3 第三阶段优化和加固流程跑通后开始优化。重点做三件事提示词优化提升效果、异常处理提升稳定性、性能优化提升速度。这个阶段是最耗时间的也是决定项目能不能上生产的关键。6.4 第四阶段监控和迭代上线不是终点。要建立监控体系跟踪调用量、成功率、延迟、成本等指标。同时持续收集bad case定期迭代优化。我在实际项目里最深的一个体会是大模型应用的难点从来不在模型本身而在模型和业务之间的那层胶水。OCR的噪声、格式的转换、异常的处理、成本的控制这些看起来不起眼的细节才是决定项目成败的关键。把精力花在这些地方比反复换模型有效得多。另外分享一个小技巧如果你在做OCR大模型的组合建议在OCR之后加一个置信度过滤环节。OCR工具通常会返回每个识别结果的置信度把置信度低的区域标记出来在喂给大模型时特别说明这部分可能识别不准。这样模型在抽取时会更加谨慎减少因OCR错误导致的抽取错误。这个技巧在发票、合同这类关键文档处理上特别有用能明显降低错误率。