大模型这个词这两年从技术圈一路烧到了普通职场人的聊天里但真正落到我到底能用它干什么这个问题上很多人还是懵的。我自己从最早折腾本地部署到后来把OCR、工作流编排、知识库这些东西串起来做业务中间踩的坑不算少。这篇就围绕大模型的应用和工具这条线把我在实际项目里验证过的东西摊开讲——包括模型怎么选、OCR怎么接、Dify这类编排工具怎么用、私有化部署要注意什么。不管你是刚接触大模型想找个切入点还是已经在做企业级应用需要补全某块拼图下面这些内容应该都能对上你的需求。1. 先把大模型的能力边界摸清楚再动手1.1 大模型不是万能接口它擅长什么不擅长什么很多人第一次用大模型容易走两个极端要么觉得它什么都能干把一堆任务全丢进去要么试了一次发现答得不对就判定这东西不靠谱。这两种判断都偏了。大模型的核心能力其实就三块自然语言的理解与生成、基于上下文的推理、以及跨领域的知识关联。它本质上是一个概率模型根据你给的输入预测最合理的输出所以它在有明确模式可循的任务上表现极好在需要精确计算或实时数据的任务上就容易翻车。举个具体的例子。你让它把一段合同文本里的甲方乙方、金额、签署日期提取出来这个任务它做得很好因为这是典型的模式识别加信息抽取。但你让它算一下这份合同分三期付款、每期含税价和不含税价分别是多少它就可能算错因为数学运算不是它的强项。正确的做法是把抽取和计算拆开大模型负责从文本里把关键字段捞出来计算交给代码去做。这个思路在后面讲OCR和Dify工作流的时候会反复用到。还有一个常见的误解是认为大模型的知识是实时的。实际上模型的训练数据有截止时间它不知道昨天发生了什么。所以凡是涉及最新信息、企业内部数据、个人私有内容的场景都必须通过**检索增强生成RAG**的方式把外部知识喂给它。这也是为什么Dify这类工具会火——它把RAG的整套流程做成了可视化编排不用从零写代码。1.2 不同任务该匹配什么类型的模型模型选型这件事我的经验是不要一上来就追求最大的那个。参数越大确实能力越强但成本、延迟、部署门槛也水涨船高。实际项目里我一般按任务复杂度分三档来选任务类型典型场景推荐模型规模理由简单抽取/分类关键词提取、情感判断、字段识别7B-14B任务模式固定小模型足够速度快成本低中等推理/生成摘要、问答、文案生成32B-70B需要一定理解深度但不需要顶级推理复杂推理/多步任务合同审查、代码生成、多轮规划70B以上或闭源API需要强推理能力小模型容易断链这里有个实操细节同一个业务里往往需要混用不同规模的模型。比如一个合同处理流水线OCR后的文本清洗用7B的小模型就够了但关键条款的风险判断可能需要调更大的模型或者云端API。Dify的工作流编排恰好支持在一个流程里切换不同模型节点这个后面会详细讲。另外关于开源和闭源的选择我的建议是验证阶段用闭源API快速跑通生产阶段根据数据敏感度决定是否转私有化。闭源API的好处是省去了部署和运维调用简单适合快速验证想法。但如果你的数据涉及企业机密或者合规要求那就必须走私有化部署这条路。私有化部署的硬件门槛现在比前两年低了不少一台带24G显存的消费级显卡机器就能跑14B级别的模型量化之后7B模型甚至能在16G显存的卡上跑得挺流畅。1.3 从能用到好用的关键提示词工程模型选对了只是第一步提示词写得好不好直接决定输出质量。我见过太多人拿着同样的模型因为提示词写得随意结果输出一塌糊涂然后怪模型不行。提示词工程不是什么玄学核心就几条原则第一角色设定要具体。不要写你是一个助手要写你是一个有十年经验的合同审查律师擅长识别付款条款中的风险点。角色越具体模型输出的专业度和风格就越贴近你的预期。第二输出格式要约束。如果你需要结构化数据就在提示词里明确要求JSON格式并给出字段示例。比如请以JSON格式输出包含以下字段party_a甲方名称、party_b乙方名称、amount合同金额数字类型、sign_date签署日期格式YYYY-MM-DD。这样后续程序解析起来才不会出错。第三给例子比讲道理管用。这叫少样本提示Few-shot在提示词里放两三个输入输出的示例模型就能很快理解你要什么。尤其是字段抽取这类任务给例子比写一大段规则描述有效得多。第四复杂任务拆步骤。如果一个任务涉及多个环节不要让模型一步到位而是引导它分步思考。比如合同审查可以拆成先识别合同类型→再提取关键条款→然后逐条评估风险→最后汇总输出。这种链式思考的方式能显著提升复杂任务的准确率。2. OCR大模型应用里绕不开的前置环节2.1 为什么OCR在大模型项目里这么重要大模型再强它也只能处理文本。但现实世界里大量的信息是以图片、PDF、扫描件的形式存在的——合同、发票、报表、证件、问卷。这些内容不转成文本大模型就无从下手。所以OCR光学字符识别实际上是大模型应用流水线里的第一道关卡它的质量直接决定了后面所有环节的上限。我做过一个问卷处理的场景用户拍照上传填好的问卷系统需要自动识别里面的手写和印刷内容然后结构化入库。这个场景里OCR的准确率如果只有90%意味着每十份问卷就有一份的关键信息可能出错后续大模型再厉害也救不回来。所以OCR这块不能凑合得认真选型和调优。2.2 通用OCR和文档结构化OCR的区别市面上的OCR工具大致分两类。一类是通用文字识别就是把图片里的文字转成文本不关心版面结构。另一类是文档结构化识别它不仅能识别文字还能理解文档的版面布局把标题、段落、表格、印章这些元素区分开甚至直接输出结构化的字段。对于大模型应用来说我更推荐用第二类。原因很简单大模型处理一大段没有结构的纯文本效果远不如处理带有明确结构标记的文本。比如一份合同如果OCR只输出一坨文字大模型很难判断哪句是甲方义务、哪句是违约责任。但如果OCR能输出带标签的结构化结果大模型的抽取准确率会高出一大截。具体到工具选择国内常用的有百度OCR、腾讯OCR这些云服务也有开源的PaddleOCR、Tesseract。云服务的优势是准确率高、接入简单缺点是按调用量收费数据要上传到云端。开源方案的优势是数据不出本地、免费缺点是需要自己部署调优准确率尤其是手写体和复杂版面的识别率可能不如云服务。提示如果你的场景涉及合同、证件这类敏感文档优先考虑本地部署的开源OCR方案或者使用支持私有化部署的商业OCR。数据合规这根弦不能松。2.3 把OCR接入大模型流水线的实操要点OCR识别出来的文本不能直接丢给大模型中间需要做几步处理。我总结了一个比较通用的流程第一步版面分析。把OCR结果按区域切分区分出正文、表格、页眉页脚。表格单独处理因为表格的结构信息用纯文本很难表达最好转成Markdown表格或者JSON。第二步文本清洗。OCR结果里经常有识别错误、多余空格、乱码字符。这一步可以用规则做初步清洗比如去掉连续空格、修正常见的形近字错误。更彻底的做法是用一个小模型做纠错把OCR文本和上下文一起喂进去让它修正。第三步分块。大模型的上下文窗口是有限的一份长文档不可能一次性全塞进去。需要按语义把文本切成合适大小的块每块之间保留一定的重叠避免切断关键信息。分块的大小要根据模型窗口和任务类型来定一般512到1024个token一块比较常见。第四步结构化抽取。把分好块的文本逐块喂给大模型让它按预设的字段模板抽取信息。这里要注意抽取的提示词里一定要包含字段定义和输出格式要求否则模型每次输出的格式可能都不一样后续程序没法解析。这套流程听起来步骤多但用Dify这类工具编排起来其实很快拖几个节点连起来就行。下面讲Dify的时候会具体展开。3. Dify工作流把大模型能力串成流水线3.1 Dify解决的核心问题是什么单独调用一次大模型API很简单几行代码的事。但真实业务往往是一条流水线上传文件→OCR识别→文本清洗→分块→向量化→检索→大模型生成→格式化输出。这条链路上每一步都涉及不同的技术组件如果全用代码写开发和维护成本很高。Dify的价值就在于把这些组件做成了可视化的节点你只需要拖拽连线、配置参数就能搭出一条完整的工作流。我第一次用Dify是在一个知识库问答项目里。当时的需求是把一批产品文档导入让用户能用自然语言提问系统基于文档内容回答。如果用传统方式做需要自己搭向量数据库、写检索逻辑、拼接提示词、处理多轮对话工作量不小。用Dify的话知识库创建、文档上传、向量化、检索配置这些都有现成的界面工作流里拖一个知识检索节点加一个LLM节点半天就能跑通原型。3.2 工作流编排里几个容易踩的坑Dify好用归好用但实际用起来有几个坑我踩过这里提前给你标出来。第一个坑是上下文超长。工作流里如果前一个节点的输出很长直接传给下一个节点很容易超出模型的上下文窗口。尤其是知识检索节点如果召回的文章块太多拼起来可能几千甚至上万token。解决办法是在检索节点设置合理的召回数量一般3到5块就够并且在LLM节点前加一个文本截断或摘要节点把过长的内容压缩一下。第二个坑是变量传递。Dify工作流里节点之间的数据传递靠变量如果变量名写错了或者类型不匹配流程就会报错。我的习惯是每加一个节点就先单独测试它的输出确认变量内容符合预期再往下连。不要一口气连完再调试那样出了问题很难定位是哪个节点的事。第三个坑是SSL证书问题。本地部署Dify的时候如果调用的外部API是HTTPS的有时候会遇到证书验证失败的错误。这个通常是因为容器环境里的根证书不全或者系统时间不对。排查的时候先确认系统时间准确然后检查容器内是否能正常访问目标域名。如果是自签名证书需要在配置里显式信任。第四个坑是迁移。Dify支持导出和导入应用配置但迁移的时候要注意版本兼容性。不同版本的Dify工作流的节点格式可能有差异直接导入旧版本的配置可能报错。迁移前最好先确认两边的版本号必要时先在测试环境验证一遍。3.3 一个完整的合同信息抽取工作流拆解光讲理论不够直观我把之前做的一个合同信息抽取工作流拆开给你看。这个流程的目标是用户上传合同PDF系统自动识别并提取甲方、乙方、金额、签署日期、付款方式这几个关键字段输出结构化JSON。整个工作流大概是这样串的文件上传节点接收用户上传的PDF文件。文档提取节点把PDF转成文本。如果是扫描件这一步会调用OCR如果是电子版PDF直接提取文本层。文本清洗节点用代码节点做正则清洗去掉多余空格和乱码。分块节点按段落把长文本切成块每块控制在800token左右。LLM抽取节点对每个块调用大模型提示词里定义好要抽取的字段和输出格式。这里我用的是14B级别的模型因为字段抽取任务不算复杂小模型够用且速度快。结果合并节点把多个块的抽取结果合并去重处理冲突。格式化输出节点把最终结果整理成标准JSON返回。这个流程里最关键的是第5步的提示词设计。我的提示词大概长这样你是一个合同信息抽取助手。请从以下文本中提取指定字段。 需要提取的字段 - party_a: 甲方名称 - party_b: 乙方名称 - amount: 合同总金额只保留数字 - sign_date: 签署日期格式YYYY-MM-DD - payment_method: 付款方式 如果某个字段在文本中找不到值设为null。 请以JSON格式输出不要添加任何额外说明。 文本内容 {{input_text}}实测下来这套流程在标准合同上的字段抽取准确率能到95%以上。出错的主要是两种情况一是合同用了非常规的表述方式比如甲方不叫甲方而叫委托方二是金额有大写和小写两种写法模型偶尔会搞混。针对第一种情况我在提示词里补充了常见别名的说明第二种情况则是在后处理节点里加了校验逻辑如果大小写金额不一致就标记出来人工复核。4. 私有化部署什么情况下必须走这条路4.1 私有化部署的决策依据不是所有项目都需要私有化部署。我一般用三个问题来判断数据敏感吗调用量大吗需要定制吗三个问题里只要有一个答案是肯定的就值得考虑私有化。数据敏感是最常见的驱动力。金融、医疗、法律这些行业的数据不能出企业内网用云端API就违规了。调用量大是成本考量如果每天要调用几十万次云端API的费用累积起来可能比自建还贵。需要定制则是指你要对模型做微调让它更适应特定领域的任务这个只有私有化部署才能做。私有化部署的硬件投入这两年降了不少。跑一个14B的模型做推理一张24G显存的卡就够整机成本控制在一两万以内。如果只是跑7B的量化模型16G显存的卡也能凑合。当然如果要跑70B级别的大模型那就需要多卡或者专业级显卡成本会高不少。4.2 部署工具的选择和对比私有化部署大模型现在主流的工具是Ollama和vLLM。两个的定位不太一样工具适用场景优势局限Ollama个人开发、小规模测试安装简单一条命令跑起来模型管理方便并发能力弱不适合生产环境高并发vLLM生产环境、高并发吞吐量高支持连续批处理显存利用率好部署配置相对复杂需要一定的运维经验我的建议是开发和测试阶段用Ollama快速验证想法生产环境上vLLM保证并发和稳定性。Ollama的安装确实简单下载安装包一行命令拉模型几分钟就能跑起来。但它的并发处理能力有限几个人同时用还行几十个人同时请求就会排队。vLLM在这方面强很多它用了PagedAttention技术显存利用率和吞吐量都有明显优势但配置起来需要调一些参数比如GPU显存利用率、最大并发数这些。4.3 私有化部署后的模型微调思路私有化部署的一个额外好处是可以做微调。微调的目的是让模型更适应你的特定任务比如你的业务里有大量专业术语通用模型可能理解不准微调之后就能显著改善。微调不是必须的很多场景用提示词工程加RAG就能解决。但如果你的任务有大量标注数据且通用模型怎么调提示词都达不到要求那就值得考虑微调。微调的数据准备是关键一般需要几百到几千条高质量的输入输出对。数据质量比数量重要一百条精准的标注数据可能比一千条粗糙的数据效果更好。微调的方法现在也比较成熟了LoRA和QLoRA是常用的轻量级微调方案不需要全量更新模型参数只需要训练一小部分适配层显存需求大幅降低。一张24G的卡就能对7B模型做LoRA微调。微调完之后把适配层和基础模型合并就能得到一个定制化的模型。注意微调不是一劳永逸的。基础模型更新了微调的效果可能会退化需要重新训练。所以微调适合相对稳定的任务场景如果你的业务变化很快还是优先用提示词工程和RAG来适配。5. 知识库与RAG让大模型用上你的私有数据5.1 RAG的基本原理和为什么需要它大模型的知识来自训练数据它不知道你公司的内部文档、产品手册、客户资料。RAG检索增强生成就是解决这个问题的先把你的私有文档转成向量存起来用户提问的时候先从向量库里检索出最相关的文档片段把这些片段和问题一起喂给大模型让它基于这些片段来回答。这个思路听起来简单但实际效果好不好取决于几个关键环节。文档切分要合理切得太碎会丢失上下文切得太大会引入无关信息。向量化模型要选对中文场景下用专门针对中文优化的embedding模型效果更好。检索策略要调优单纯的向量相似度检索有时候不够可以结合关键词检索做混合检索提升召回质量。5.2 知识库流水线的搭建步骤用Dify搭知识库流水线大致分这么几步第一步文档准备。把你的文档整理成Dify支持的格式PDF、Word、Markdown、TXT都行。文档质量很重要如果原始文档本身排版混乱、内容重复检索效果肯定好不了。我一般会先人工过一遍把无关内容删掉把结构理清楚。第二步分段设置。Dify提供了自动分段和自定义分段两种模式。自动分段会按固定长度切简单但可能切断语义。自定义分段可以按标点、按段落来切效果更好但需要调参数。我的经验是对于结构清晰的文档按段落切分每段控制在500到1000字之间比较合适。第三步索引方式选择。Dify支持高质量索引和经济索引两种。高质量索引会用embedding模型做向量化检索精度高但消耗资源经济索引用关键词匹配速度快但精度低。生产环境建议用高质量索引。第四步检索测试。知识库建好之后一定要用真实的问题去测试检索效果。看看召回的内容是不是真的相关有没有漏掉关键信息。如果效果不好回头调整分段策略和检索参数。5.3 提升RAG效果的几个实战技巧RAG做出来容易做好难。我踩过的坑和总结的技巧有这么几个技巧一给文档块加元数据。每个文档块除了内容本身还可以附加来源、章节、时间等元信息。检索的时候可以按元数据过滤比如只检索某个产品线的文档或者只检索最近半年的内容。这个在Dify里可以通过文档的元数据字段来实现。技巧二用重排序提升精度。初步检索出来的结果可能排序不够准可以加一个重排序模型对召回的文档块重新打分排序把最相关的排到前面。Dify的工作流里可以加一个重排序节点来做这件事。技巧三多路召回。不要只依赖向量检索可以同时用关键词检索和向量检索把两路结果合并去重。这样既能召回语义相关的内容也能召回关键词精确匹配的内容覆盖面更广。技巧四提示词里明确要求基于检索内容回答。如果不加约束大模型可能会用自己的知识来回答而不是基于你检索出来的文档。提示词里要明确写请仅基于以下参考内容回答问题如果参考内容中没有相关信息请回答根据现有资料无法回答。这样能有效减少幻觉。6. 从工具到落地几个真实场景的完整思路6.1 问卷拍照上传加OCR识别的场景这个场景我在前面提过这里展开讲一下完整思路。需求是用户在手机上填问卷某些字段需要拍照上传比如身份证、营业执照系统自动识别图片内容并填入对应字段。技术链路是这样的用户拍照上传→图片传到后端→调用OCR接口识别→识别结果做清洗和字段映射→回填到问卷表单→用户确认或修改。这里的关键点在于OCR结果的字段映射。OCR返回的是一堆文本怎么知道哪段文本对应哪个字段如果是身份证可以用版面分析定位到姓名、身份证号、地址的位置如果是营业执照可以用关键词匹配找到统一社会信用代码、公司名称。更通用的做法是把OCR文本喂给大模型让大模型按预设的字段模板抽取。这样即使版面有变化抽取逻辑也不用改。用户体验上有个细节要注意OCR识别不可能100%准确所以一定要给用户确认和修改的机会。不要识别完直接提交而是把识别结果填到表单里让用户核对。这样既提高了效率又避免了错误数据入库。6.2 企业知识库问答的落地要点企业知识库问答是RAG最典型的应用。员工有问题不用翻文档直接问系统系统基于内部文档回答。这个场景的落地难点不在技术而在知识的组织和更新。我做过的一个项目里最初把所有的文档一股脑导入结果检索效果很差因为文档里有大量过时内容和重复内容。后来做了几件事一是按部门和时间给文档分类检索时可以按分类过滤二是定期清理过时文档保证知识库里的内容都是有效的三是建立了文档更新机制新文档及时入库旧文档及时下架。另一个要点是回答的引用来源。企业场景下用户往往需要知道答案是从哪份文档来的以便进一步查阅。所以系统在回答的时候要附上参考文档的来源和链接。Dify的知识库检索节点会返回文档的元信息可以在输出里带上这些信息。6.3 合同关键字段自动提取的场景合同处理是OCR加LLM抽取的经典组合。除了前面讲的工作流拆解这里补充几个实操中遇到的特殊情况。情况一合同有多个版本。比如有主合同和补充协议关键信息可能分散在不同文件里。这种需要先把多个文件的内容合并再做抽取。合并的时候要注意文件的顺序和关联关系。情况二金额有大小写。合同里的金额通常有中文大写和阿拉伯数字两种写法抽取的时候要同时提取并做一致性校验。如果两者不一致说明可能有问题需要标记出来人工复核。情况三日期格式不统一。有的写2024年1月1日有的写2024-01-01有的写二〇二四年一月一日。抽取的时候要统一转换成标准格式方便后续处理。情况四表格里的信息。合同的付款计划、交付清单这些往往以表格形式存在。OCR识别表格的准确率通常比正文低所以表格内容要单独处理最好用支持表格结构识别的OCR方案。这些特殊情况处理起来没有捷径就是要在实际数据上反复测试发现问题就补充规则或调整提示词。我一般会准备一个测试集包含各种格式的合同样本每次调整完流程都跑一遍测试集确保没有引入新的问题。7. 模型选型与成本控制的平衡7.1 免费API和付费API的取舍刚开始做验证的时候免费的大模型API是很好的选择。国内几家主流厂商都提供一定额度的免费调用足够跑通原型。但免费额度通常有并发限制和调用频率限制不适合生产环境。从免费转到付费的时机我的判断标准是当你的应用开始有真实用户且对响应速度和稳定性有要求的时候。免费API的延迟波动大有时候几秒才返回用户体验很差。付费API的SLA有保障响应稳定而且通常提供更高的并发额度。成本控制方面有几个实用的策略一是按任务复杂度选模型简单任务用便宜的小模型复杂任务才用贵的大模型二是缓存重复请求如果同样的输入经常出现把结果缓存起来避免重复调用三是控制输出长度在提示词里限制最大输出token数避免模型生成冗长的内容浪费额度。7.2 本地模型和云端API的混合架构实际生产环境里我比较推荐混合架构敏感数据和简单任务走本地模型复杂任务和非敏感数据走云端API。这样既保证了数据安全又控制了成本。具体怎么分我的做法是涉及用户隐私、企业机密的文本处理走本地对外的、公开的、或者已经脱敏的内容走云端。简单任务比如文本分类、关键词提取走本地小模型复杂任务比如长文推理、多步规划走云端大模型。这种混合架构在Dify里实现起来很方便工作流里可以配置多个模型节点根据条件走不同的分支。比如加一个条件判断节点如果输入文本包含敏感标记就走本地模型节点否则走云端API节点。7.3 推理成本的实际测算很多人关心私有化部署到底划不划算我拿一个实际案例算一下。假设你的应用每天处理1000份文档每份文档平均2000token用14B模型推理。如果用云端API按目前主流厂商的定价每百万token大概几块到几十块不等一天的成本大概在几块到几十块之间一个月下来一两百到一两千。如果私有化部署一张24G显存的显卡大概一万多加上主机其他配件整机两万左右。电费按满载300W算一天24小时大概7度电一个月电费几十块。这样算下来如果月调用量对应的云端费用超过几百块一年左右就能回本。调用量越大私有化越划算。当然这只是纯成本角度还要考虑运维成本。私有化部署需要有人维护处理硬件故障、模型更新、性能调优这些事。如果团队里没有专门的运维人员这部分隐性成本也要算进去。8. 一些零散但重要的经验8.1 关于模型输出的稳定性大模型的输出有随机性同样的输入两次调用可能得到不同的结果。这在某些场景下是问题比如你需要严格一致的结构化输出。解决办法是把temperature参数调低甚至调到0让模型尽量选择概率最高的输出。但即使这样也不能保证100%一致所以关键业务逻辑不能完全依赖模型的输出格式要在后处理环节做校验和容错。8.2 关于提示词的版本管理提示词是会被反复修改的改来改去很容易乱。我的做法是把提示词当成代码来管理每次修改都记录改了什么、为什么改、效果如何。Dify的工作流里可以给节点加备注我一般会在备注里写清楚这个节点的提示词版本和修改记录。这样出了问题能快速回滚到之前的版本。8.3 关于测试集的建设不管是OCR、抽取还是问答都需要一个测试集来评估效果。测试集不用很大几十到几百条就够但一定要覆盖各种边界情况。我一般会从真实数据里挑一些典型的、容易出错的样本组成测试集每次调整流程都跑一遍看准确率有没有提升。没有测试集的话你根本不知道自己的调整是变好了还是变差了。8.4 关于数据安全最后再强调一下数据安全。大模型应用涉及的数据往往包含敏感信息从数据采集、传输、存储到处理的每个环节都要考虑安全。传输用加密通道存储做脱敏或加密处理环境要隔离。如果用的是云端API要仔细阅读服务条款确认数据不会被用于模型训练。如果是私有化部署要做好访问控制和审计日志。这些经验都是我在实际项目里一点点积累的有些是踩了坑才明白的。大模型这个领域变化很快工具和模型都在不断更新但底层的思路和方法论是相对稳定的。把OCR、工作流编排、知识库、私有化部署这几块搞明白基本上大部分企业级应用场景都能覆盖了。