1. 大模型应用与工具的全景拆解1.1 从热搜词看真实需求分布把“大模型, DeepSeek, OCR, Dify, 华为云”这组词摊开来看其实能拼出一张很典型的技术落地地图。DeepSeek代表底层模型能力Dify代表应用编排层OCR代表非结构化数据入口华为云代表算力与部署基座。这四个东西凑在一起恰好就是一套完整的企业级大模型应用最小闭环数据进来、模型处理、流程编排、服务出去。我翻了一圈相关热搜词发现大家的关注点集中在几个很具体的方向上。一类是部署层面的比如“dify本地部署教程”“ollama部署大模型”“企业大模型私有化部署”“dify迁移”一类是调用层面的比如“deepseek api如何调用”“codex接入deepseek”“免费大模型api”还有一类是具体业务场景的比如“java使用百度ocr识别上传合同文件时读取收入、单位、时间等关键字段”“在问卷中添加拍照上传功能对问卷进行ocr识别”“vba调用百度云ocr识别”。这些搜索词背后其实是同一批人在不同阶段遇到的问题。刚开始接触的时候关心“怎么装”装完了关心“怎么连”连上了关心“怎么用在实际业务里”用起来了又关心“怎么不出错”。所以这篇文章我打算按这个真实的使用路径来组织而不是按教科书那种“先讲原理再讲应用”的顺序。1.2 这套组合到底解决什么问题先说清楚一个基本判断大模型本身不产生价值大模型加上业务数据加上流程编排才产生价值。单独一个DeepSeek或者单独一个Dify能做的事情很有限。但当你把OCR接进来处理扫描件和照片把Dify作为编排层把模型能力串成工作流再部署在华为云或者本地服务器上保证数据不出内网这套东西就能解决很多以前需要大量人工才能完成的任务。举个具体的例子。一家做供应链管理的公司每天收到几百份供应商发来的合同扫描件以前需要三四个文员逐份打开、找到金额、找到签约日期、找到甲乙方名称手动录入到系统里。现在用OCR把图片转成文字用大模型做字段抽取和结构化用Dify编排整个流程最后自动写入数据库。整个过程从收到文件到入库不超过两分钟人工只需要处理异常情况。这个场景里OCR负责“看得见”大模型负责“看得懂”Dify负责“管得住流程”云平台或者本地服务器负责“跑得稳”。四个环节缺一不可但每个环节都有坑下面我逐个拆。1.3 适合谁来参考这套方案如果你是完全没接触过大模型的小白这篇文章能让你知道这套东西大概长什么样、能干什么、从哪里开始学。如果你已经在用Dify或者DeepSeek但总觉得哪里不对劲这篇文章里关于工作流上下文超长、SSL错误、迁移注意事项的部分应该能帮到你。如果你是企业里的技术负责人正在评估要不要做私有化部署文章里关于模型选型、OCR方案对比、部署架构的部分可以直接拿去用。我不打算讲太多理论重点放在“我实际怎么做的”“踩过哪些坑”“哪些参数必须调”。所有涉及具体操作的地方都会给出可复现的步骤和配置你照着做基本能跑通。2. 核心工具链的选型逻辑与配置要点2.1 DeepSeek作为推理引擎的接入方式DeepSeek在这套体系里的角色是“大脑”负责理解文本、抽取信息、生成回复。接入方式主要有三种每种适合不同的场景。第一种是直接用官方API。这是最省事的方式注册账号拿到key之后用HTTP请求就能调用。适合快速验证和小规模使用。但要注意官方API有速率限制免费额度用完之后需要充值而且数据要出你的服务器对数据敏感的场景不太合适。第二种是通过第三方平台接入。比如有些云平台提供了DeepSeek的托管服务你不需要自己部署模型直接调用接口就行。这种方式的好处是稳定性有保障坏处是费用通常比官方API高一些而且你依然要把数据发出去。第三种是本地部署。用ollama或者vllm这类工具把DeepSeek的模型文件下载到本地在自己的服务器上跑推理。这种方式数据完全不出内网适合金融、医疗、法律这些对数据安全要求高的行业。但代价是需要GPU资源DeepSeek的7B版本至少需要一张16G显存的卡才能跑得比较流畅67B版本则需要多卡并行。我个人的建议是先用官方API跑通流程验证业务价值。确认有价值之后如果数据敏感就转本地部署如果不敏感就继续用API但做好费用监控。不要一上来就折腾本地部署容易在环境配置上耗掉太多时间。关于API调用的具体代码Python环境下大概长这样import requests url https://api.deepseek.com/v1/chat/completions headers { Authorization: Bearer YOUR_API_KEY, Content-Type: application/json } data { model: deepseek-chat, messages: [ {role: system, content: 你是一个合同信息抽取助手}, {role: user, content: 请从以下文本中提取甲方名称、乙方名称、合同金额、签约日期...} ], temperature: 0.1 } response requests.post(url, headersheaders, jsondata) print(response.json())这里有个细节值得注意temperature参数建议设低一点0.1到0.3之间比较合适。因为信息抽取任务需要的是稳定和准确不需要模型发挥创造力。设高了反而容易产生幻觉把不存在的金额编出来。2.2 Dify作为编排层的部署与配置Dify解决的核心问题是把多个步骤串成一个自动化流程并且提供可视化的管理界面。没有Dify的时候你需要写代码来协调OCR调用、模型调用、数据库写入这些步骤。有了Dify你可以用拖拽的方式画出一个工作流每个节点做什么、数据怎么流转一目了然。部署Dify有两种方式。一种是直接用官方的云服务注册就能用适合快速上手。另一种是本地部署用Docker Compose把Dify的各个组件拉起来。本地部署的步骤大致是安装Docker和Docker Compose下载Dify的docker-compose.yml文件执行docker compose up -d然后访问本地的80端口就能看到界面。这里有个坑很多人会遇到SSL错误。当你用本地部署的Dify去调用外部API的时候如果Dify容器内部的证书链不完整就会报SSL certificate verify failed。解决办法是在docker-compose.yml里给Dify的容器挂载宿主机的证书目录或者直接在环境变量里加上跳过证书验证的配置。但跳过验证不是好习惯生产环境还是要把证书配好。另一个常见问题是“dify an error occurred during credentials validation”。这个通常出现在配置模型供应商的时候原因可能是API key填错了、网络不通、或者模型名称写错了。排查顺序是先用curl在宿主机上直接调一下API看通不通如果通再进Dify容器里调一次看是不是容器网络的问题。如果容器里不通检查Docker的网络模式是不是bridge需不需要加host网络。Dify的工作流里有一个很容易被忽视的配置上下文长度。当你的工作流里有多轮对话或者多个节点传递数据的时候上下文会不断累积。如果超过了模型的最大上下文长度就会报错或者截断。解决办法是在工作流的开始节点就设置好最大上下文长度并且在每个节点里只传递必要的信息不要把整个历史都往下传。2.3 OCR方案的对比与选择OCR是这套体系里的“眼睛”负责把图片和PDF里的文字提取出来。选OCR方案的时候主要看三个维度识别准确率、对中文的支持程度、以及是否支持结构化输出。目前市面上常见的方案有这么几类。第一类是云服务商的OCR比如百度OCR、华为云OCR、腾讯云OCR。这些服务的优势是准确率高、支持多种证件和票据的模板识别、直接返回结构化字段。缺点是按调用次数收费数据要上传到云端。第二类是开源的OCR引擎比如PaddleOCR、Tesseract。优势是免费、可以本地部署、数据不出内网。缺点是准确率尤其是中文手写体的准确率不如商业服务而且需要自己处理版面分析和字段抽取。第三类是针对特定场景优化的OCR工具比如专门识别验证码的、专门识别发票的。热搜词里有个很具体的需求“java使用百度ocr识别上传合同文件时读取收入、单位、时间等关键字段”。这个场景我建议用百度OCR的“合同识别”或者“通用文字识别自定义模板”功能。百度OCR的Java SDK用起来不算复杂核心步骤是引入Maven依赖、创建AipOcrClient、调用basicGeneral或者custom接口、解析返回的JSON。但要注意合同类文档的版面差异很大没有哪个OCR能保证100%准确所以后面一定要接大模型做校验和纠错。还有一个热搜词是“php ocr识别验证码”。验证码识别是个比较特殊的场景因为验证码通常有干扰线、扭曲、粘连。普通的OCR引擎直接识别效果很差。通常的做法是先做图像预处理灰度化、二值化、去噪再用专门训练过的模型来识别。如果验证码比较简单用Tesseract加上合适的预处理也能达到可用水平。如果比较复杂可能需要用深度学习的方式自己训练一个小的识别模型。2.4 华为云在部署架构中的角色华为云在这套体系里主要承担两个角色算力提供者和网络入口。算力方面如果你不想自己买GPU服务器可以在华为云的ModelArts或者ECS上部署模型。华为云的昇腾系列芯片对国产大模型的支持比较好DeepSeek在昇腾上的推理性能经过优化比通用GPU方案在某些场景下更有性价比。网络方面热搜词里有个“飞牛nas如何设置华为云ddns”这其实反映了一个很普遍的需求如何让外网安全地访问内网的服务。华为云的DDNS服务可以把动态的公网IP映射到一个固定的域名上这样你在外面就能通过域名访问家里的NAS或者服务器。配置步骤大致是在华为云DNS控制台创建域名解析记录在NAS上安装DDNS客户端配置好API密钥和域名信息客户端会定期把当前的公网IP更新到DNS记录上。但这里要提醒一句把内网服务暴露到公网是有安全风险的。至少要做好这几件事改掉默认端口、启用强密码或者密钥认证、开启访问日志、限制访问来源IP。如果只是自己用更安全的做法是用内网穿透工具或者虚拟局域网方案而不是直接把端口映射出去。3. 从零搭建一套可用的工作流3.1 环境准备与基础服务安装在开始搭建之前先确认你手头有什么。如果只是想做实验一台装了Docker的普通电脑就够了模型用API调用OCR用云服务。如果想做私有化部署至少需要一台带GPU的服务器显存建议不低于16G内存不低于32G硬盘不低于500G。基础环境的安装顺序是这样的先装Docker和Docker Compose这是Dify运行的基础。然后装Python环境版本建议3.10以上后面写脚本和调API都要用。如果要做本地模型推理还要装CUDA驱动和对应的深度学习框架。Docker的安装在不同系统上略有差异。Ubuntu上的命令大概是sudo apt update sudo apt install docker.io docker-compose-plugin sudo systemctl enable docker sudo systemctl start docker装完之后用docker --version确认一下版本。Docker Compose现在一般作为Docker的插件安装命令是docker compose而不是docker-compose注意区分。接下来拉取Dify的代码git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d等几分钟用docker ps看一下容器是不是都起来了。正常情况下你会看到api、worker、web、db、redis这几个容器。然后浏览器访问http://localhost:80应该能看到Dify的登录界面。第一次访问需要设置管理员账号。3.2 模型接入与工作流编排实操Dify起来之后第一件事是配置模型供应商。进入设置页面找到模型供应商选择DeepSeek或者OpenAI兼容的接口。如果你用的是DeepSeek官方API填上API key和base URL就行。如果你用的是本地部署的模型base URL填你本地服务的地址比如http://host.docker.internal:11434/v1这是ollama的默认地址。配置好模型之后就可以创建工作流了。我以一个“合同信息抽取”的工作流为例说明各个节点怎么连。开始节点接收用户上传的文件。接下来是一个条件分支如果文件是图片或者扫描PDF走OCR节点如果是文本PDF或者Word直接走文本提取节点。OCR节点调用百度OCR或者PaddleOCR把图片转成文字。文本提取节点用Python的pdfplumber或者python-docx库把文字读出来。两个分支汇合之后进入大模型节点。这个节点的提示词很关键我一般这样写你是一个专业的合同信息抽取助手。请从以下文本中提取以下字段甲方名称、乙方名称、合同金额、签约日期、合同有效期。如果某个字段在文本中找不到返回“未找到”。请以JSON格式输出不要添加任何额外说明。提示词里明确要求JSON格式输出这样后面的节点可以直接解析。temperature设0.1max_tokens根据合同长度设2000到4000。大模型节点之后接一个代码节点用来解析JSON并做校验。比如检查金额是不是数字、日期格式对不对。如果校验不通过走异常分支通知人工处理。如果通过走数据库节点写入。整个工作流画完之后点右上角的“运行”可以测试。测试的时候建议用几种不同类型的合同各跑一遍看看有没有遗漏的情况。3.3 OCR与大模型的协同处理细节OCR和大模型之间的配合有几个细节值得展开说。第一个是OCR结果的清洗。OCR出来的文本经常有换行错乱、空格多余、特殊字符乱码的问题。如果直接丢给大模型会影响抽取准确率。我一般会在OCR节点后面加一个代码节点做预处理把连续的空格替换成一个、把中文之间的换行去掉、把明显的乱码字符过滤掉。第二个是分块策略。如果合同很长超过了模型的最大上下文长度就需要把文本切成块。切块的时候不能随便切要按段落或者按章节切保证每个块里的信息是完整的。Dify的工作流里可以用“文本分割”节点来做这件事分割符设成“\n\n”或者“第X条”这样的模式。第三个是字段抽取的提示词优化。同一个模型提示词写得好和写得差准确率能差出20%以上。我的经验是把字段列表写清楚、给出每个字段的示例格式、明确说明找不到的时候返回什么、要求模型只输出JSON不要解释。如果某些字段容易混淆比如“合同金额”和“含税金额”要在提示词里明确区分。第四个是结果校验。大模型有时候会编造信息尤其是当文本里确实没有某个字段的时候。所以一定要在流程里加校验规则金额必须是数字且在合理范围内、日期必须符合YYYY-MM-DD格式、甲乙方名称不能为空。校验不通过的记录标记出来让人工复核。3.4 私有化部署的架构设计与迁移当你的工作流验证通过、准备上生产的时候就需要考虑私有化部署了。私有化部署的核心诉求是数据不出内网所以模型、OCR、Dify都要部署在自己的服务器上。架构上我建议分成三层。最底层是基础设施层包括GPU服务器、存储、网络。中间层是服务层跑模型推理服务、OCR服务、Dify。最上层是应用层对外提供API或者Web界面。模型推理服务可以用ollama或者vllm。ollama的好处是安装简单、模型管理方便适合快速部署。vllm的好处是推理性能更好、支持并发适合生产环境。如果用的是DeepSeek的模型ollama上直接ollama pull deepseek-r1就能拉下来。OCR服务可以用PaddleOCR的Docker镜像部署起来也不复杂。但要注意PaddleOCR的模型文件比较大第一次运行的时候需要下载如果服务器不能上外网需要提前把模型文件拷贝进去。Dify的迁移是个容易被忽视的问题。如果你在测试环境调好了工作流想迁移到生产环境不能只迁移数据库还要迁移文件存储和配置。Dify的数据存在PostgreSQL里文件存在本地或者S3兼容的存储里。迁移的时候要先把数据库导出把文件目录打包然后在生产环境恢复。环境变量里的配置也要同步更新尤其是数据库连接串、Redis地址、模型API地址这些。迁移完之后一定要做回归测试把主要的工作流都跑一遍确认没有因为环境变化导致的问题。4. 常见问题排查与避坑经验4.1 部署与连接类问题速查这类问题出现频率最高我整理了一个速查表问题现象可能原因排查方法解决方案Dify页面打不开容器没起来docker ps看容器状态看日志通常是端口冲突或数据库没连上SSL证书验证失败容器内证书链不完整进容器curl测试挂载宿主机证书或配置CA bundle凭据验证错误API key错误或网络不通宿主机和容器内分别curl检查key、检查网络模式模型调用超时网络延迟或模型负载高看模型服务的日志增加超时时间、加GPU资源OCR识别率低图片质量差或预处理不够人工看几张识别结果加图像预处理、换OCR方案工作流上下文超长传递了过多历史信息看每个节点的输入输出精简传递字段、设置最大长度关于SSL错误我想多说两句。很多人遇到这个问题第一反应是加verifyFalse跳过验证这在测试环境可以但生产环境绝对不能这么干。正确的做法是把根证书和中间证书配置到容器的信任链里。具体操作是找到宿主机的/etc/ssl/certs目录在docker-compose.yml里把它挂载到容器的对应目录然后更新容器的CA证书。关于“dify an error occurred during credentials validation”这个错误的排查有个小技巧先在Dify的模型供应商配置页面点“测试”按钮如果报错去看Dify的api容器日志里面会有更详细的错误信息。常见的原因包括API key前后有空格、base URL多了或少了一个斜杠、模型名称大小写不对。4.2 工作流运行时的典型故障工作流跑起来之后最常见的故障是“上下文超长”。这个问题的根源在于Dify的工作流默认会把所有历史节点的输出都传递给下游节点。如果你的工作流有十个节点每个节点输出1000字到最后一个节点的时候上下文就有10000字了。如果模型的最大上下文是8000字就会报错。解决办法有三个。第一个是在开始节点设置“最大上下文长度”限制整个工作流能传递的文本总量。第二个是在每个节点里只输出必要的信息不要把整个输入都原样输出。第三个是用“变量聚合”节点把多个分支的输出合并成一个减少传递的数据量。另一个常见故障是“变量引用错误”。Dify的工作流里节点之间通过变量来传递数据。如果你在节点B里引用了节点A的输出变量但节点A的执行路径没有走到节点B就会报变量未定义。解决办法是在工作流里加条件判断确保引用的变量一定存在或者给变量设置默认值。还有一个坑是“循环依赖”。Dify的工作流不允许出现环如果你画的连线形成了一个圈保存的时候就会报错。排查方法是把工作流图缩小看看有没有哪条线绕回去了。4.3 模型输出不稳定的应对策略大模型的输出不稳定是个老问题。同样的输入今天跑出来是这个结果明天跑出来是那个结果。造成不稳定的原因主要有三个temperature设高了、提示词不够明确、模型本身的能力边界。应对策略我总结了几条。第一temperature能低就低信息抽取类任务设0.1创意生成类任务可以设0.7到0.9。第二提示词里把输出格式写死要求模型必须按JSON输出并且给出JSON的schema。第三在流程里加校验和重试机制如果模型输出不符合格式要求自动重试一次重试的时候在提示词里加上“上次输出格式错误请严格按照JSON格式输出”。如果某个字段的抽取准确率一直上不去可以考虑换一种思路不用大模型直接抽而是让大模型先做文本分类判断这段文本里有没有目标字段然后再用规则或者小模型来抽。这种“大模型规则”的组合有时候比纯大模型效果更好。4.4 数据安全与权限管理要点私有化部署的一个核心诉求就是数据安全但很多人部署完了之后忽略了权限配置。Dify默认的管理员账号密码是公开的如果不改任何人都能登录。API key如果泄露了别人就能随便调用你的模型。我建议至少做这几件事第一Dify的管理员密码改成强密码并且开启登录失败次数限制。第二API key定期轮换不要写在代码里硬编码用环境变量或者密钥管理服务。第三如果Dify要对外提供服务前面加一层反向代理配置HTTPS和访问控制。第四数据库和Redis不要暴露到公网只允许内网访问。第五定期备份数据库和工作流配置万一出问题能快速恢复。还有一点容易被忽视日志里可能会记录敏感信息。Dify的日志默认会记录请求和响应的内容如果处理的是合同、身份证这类敏感数据日志里就会包含这些信息。建议配置日志脱敏或者把日志的保留时间设短一点。5. 从单点工具到体系化能力的演进路径5.1 什么阶段该用什么方案我见过很多人一上来就想搭一套完整的私有化大模型平台结果在环境配置上卡了两周最后不了了之。其实这套东西的落地应该分阶段来。第一阶段是验证期。这个阶段的目标是确认“大模型OCR工作流”这套东西在你的业务场景里到底有没有用。用官方API、用Dify的云服务、用百度OCR的免费额度花一两天时间搭一个最小可用的流程跑几十条真实数据看看效果。如果效果不行趁早换方向沉没成本很低。第二阶段是优化期。验证通过之后开始调提示词、调工作流、加校验规则把准确率从70%提到90%以上。这个阶段还是用云服务但开始关注成本和稳定性。如果调用量大了费用上来了就开始考虑哪些环节可以本地化。第三阶段是私有化期。当业务价值确认了、准确率稳定了、调用量也上来了再开始做私有化部署。这时候你对整个流程已经很熟悉了知道哪些环节是瓶颈、哪些环节可以简化部署起来会顺利很多。5.2 模型微调到底要不要做“大模型微调”是个热搜词但我个人的经验是大多数场景不需要微调。微调的成本很高需要准备标注数据、需要GPU资源、需要调参和评估。而且微调之后模型可能会丧失通用能力在非微调场景下表现变差。什么情况下才需要考虑微调一是你的任务非常垂直通用模型怎么调提示词都达不到要求。二是你有大量的标注数据至少几千条高质量样本。三是你有持续的GPU资源来做训练和推理。对于绝大多数信息抽取和流程自动化场景提示词工程加上工作流编排就能达到可用水平。把精力花在优化提示词和加校验规则上投入产出比比微调高得多。5.3 后续扩展的方向这套体系搭起来之后可以往几个方向扩展。一个是接入更多的数据源比如从华为云的对象存储里自动拉取文件、从数据库里定时读取数据。另一个是增加更多的输出渠道比如把抽取结果推送到企业微信、钉钉、或者写入业务系统。还有一个是加监控和告警当工作流失败率超过阈值的时候自动通知运维。热搜词里有个“dify知识库流水线”这其实是一个很有价值的扩展方向。把企业的文档、手册、FAQ导入Dify的知识库结合大模型做检索增强生成可以搭建一个内部知识问答系统。这个系统的搭建难度比信息抽取低但实用价值很高适合作为第二个落地场景。我在实际项目里的体会是不要追求一步到位先把一个场景做深做透让业务方看到效果然后再横向扩展。大模型应用落地的最大障碍不是技术而是信任。业务方信任你了后面的推进就会顺利很多。