1. 大模型落地别只盯着模型本身这两年跟不少团队聊过大模型落地的事发现一个特别普遍的现象大家一上来就问“用哪个模型”“参数多少”“要不要微调”但真正跑起来之后卡住进度的往往不是模型本身而是模型外面那一圈东西——文档怎么解析、流程怎么编排、接口怎么调、私有化怎么部署。模型是发动机但光有发动机车是跑不起来的。我自己从最早折腾本地部署到后来帮几个团队做企业知识库和文档自动化踩过的坑基本都集中在“模型之外”。所以这篇不打算讲什么Transformer原理、注意力机制推导那些东西网上够多了。我想聊的是大模型到底能用在哪些具体场景里每个场景需要配什么工具这些工具之间怎么串起来以及串的过程中会遇到什么幺蛾子。关键词里出现的DeepSeek、OCR、Dify、华为云其实正好对应了四个层面模型层、感知层、编排层、基础设施层。把这四层理清楚一个完整的大模型应用方案基本就成型了。不管你是刚入门想跑个Demo还是已经在做企业级落地这套框架都能直接套用。下面我按“场景拆解—工具选型—实操流程—问题排查”这个顺序展开每个部分都会给到具体的配置和参数能抄作业的地方直接抄。2. 大模型到底能干什么四类高频场景拆解2.1 文本生成与对话最成熟但也最容易做砸文本生成是大模型最基础的能力写文案、做摘要、改语气、当客服这些场景门槛最低但做好不容易。我见过太多团队直接拿一个通用模型套个对话框就上线结果用户问三句就露馅——要么答非所问要么胡编乱造要么语气跟品牌调性完全不搭。这里面的核心问题在于上下文管理和提示词工程。一个能用的对话系统至少需要三层结构系统提示词定义角色和边界历史对话做上下文压缩当前问题做意图识别。很多人只做了第一层后面两层完全靠模型自己发挥效果自然不稳定。以DeepSeek为例它的对话接口支持多轮上下文但默认不会帮你做历史压缩。如果你直接把十轮对话全塞进去token消耗会飙升而且模型对早期内容的注意力会衰减。我的做法是保留最近三轮完整对话更早的内容用摘要替代摘要由模型自己生成。这样既控制了token又保留了关键信息。提示系统提示词里一定要写清楚“不知道就说不知道”否则模型在垂直领域会大量编造。这个坑我踩过不止一次后来在提示词里加了“如果问题超出知识范围请明确告知用户并建议转人工”幻觉率直接降了一半。2.2 文档解析与OCR大模型落地的“最后一公里”企业场景里大模型最大的价值往往不是聊天而是把非结构化文档变成结构化数据。合同、发票、问卷、报表、扫描件这些东西不解析成文本模型再强也吃不到。OCR就是这个环节的入口。但OCR不是万能的我实测下来通用OCR对印刷体中文的识别率能到95%以上但遇到表格、手写体、复杂排版、多语言混排识别率会断崖式下跌。比如有人反馈PaddleX的OCR管道识别不了韩文这其实不是模型的问题而是默认配置里没有加载韩文字典。解决办法是在创建pipeline时显式指定语言参数或者换用支持多语言的识别模型。另一个常见需求是从文档中抽取关键字段。比如Java项目里上传合同文件需要自动读取收入、单位、时间这些字段。单纯靠OCR只能得到一堆文本还需要后面接一个信息抽取环节。我的方案是OCR输出文本后用大模型做结构化抽取提示词里给出字段定义和输出格式JSON让模型直接返回结构化结果。这样比传统的正则匹配灵活得多字段位置变了也不怕。2.3 工作流编排把零散能力串成自动化流水线单个模型调用解决不了复杂问题。一个完整的文档处理流程可能是上传文件→OCR识别→文本清洗→大模型抽取→结果校验→写入数据库→通知用户。这么多步骤靠代码硬编码也能做但维护成本高改一个环节要动整个代码。Dify这类工作流编排工具就是来解决这个问题的。它把每个步骤做成节点用可视化连线的方式定义数据流向支持条件分支、循环、变量聚合。你不需要写太多代码就能搭出一个可运行的自动化流程。但Dify也不是没有坑。最常见的问题是上下文超长。工作流里如果前面节点输出的文本太长后面的大模型节点就会报token超限。解决办法是在中间加一个文本分割或摘要节点把长文本压缩后再传给模型。另外Dify的SSL错误和凭证验证失败也是高频问题通常跟网络环境或API Key配置有关后面会专门讲排查方法。2.4 私有化部署数据不出门是硬需求很多企业用大模型第一要求就是数据不能出内网。这就涉及到私有化部署。华为云这类平台提供了一站式的大模型部署方案从算力到模型到接口都打包好了适合不想自己折腾底层设施的团队。私有化部署的核心考量是算力成本和模型选择。一个70B参数的模型推理至少需要两张A100成本不低。如果场景对精度要求没那么高7B或13B的模型配合好的提示词效果也能接受。我的建议是先用小模型跑通流程验证业务价值再根据实际效果决定要不要上大模型。3. 工具选型每个环节用什么为什么这么选3.1 模型层DeepSeek、通用大模型与微调的取舍模型选型没有绝对的好坏只有适不适合。我一般从三个维度评估任务复杂度、数据敏感度、成本预算。DeepSeek在代码生成和逻辑推理上表现不错API价格也相对友好适合做开发辅助和复杂流程编排。通用大模型在创意写作和开放域对话上更强但垂直领域需要靠提示词或微调来补。如果数据绝对不能出内网那就只能走私有化部署路线华为云等平台都有成熟的方案。微调这件事我的态度是能不微调就不微调。微调成本高、周期长而且模型更新后微调成果可能失效。大部分场景用“好提示词少量示例”就能达到可接受的效果。只有当任务非常垂直、格式要求极严、且你有大量标注数据时微调才值得考虑。3.2 感知层OCR工具怎么选参数怎么调OCR工具大致分三类开源本地方案PaddleOCR、Tesseract、云服务API百度OCR、华为云OCR、专用软件望言OCR等。开源方案的优势是免费、可离线、可定制缺点是部署麻烦、多语言支持参差不齐。云服务API的优势是开箱即用、识别率高、支持多语言缺点是要联网、有调用成本、数据要出内网。专用软件适合非技术用户但灵活度低。我的选型逻辑是如果数据敏感用PaddleOCR本地部署如果追求识别率且数据不敏感用云服务API如果只是偶尔用找个在线工具就行。PaddleOCR的多语言支持需要手动配置。比如识别韩文需要在创建pipeline时指定langkorean并且确保下载了对应的字典文件。Tesseract也是类似默认只装了英文中文和其他语言需要额外下载语言包。3.3 编排层Dify工作流的节点设计与变量传递Dify的工作流核心是节点和变量。每个节点做一件事节点之间通过变量传递数据。常见的节点类型包括开始节点、LLM节点、代码节点、条件分支、变量聚合器、结束节点。变量聚合器是个容易被忽略但很有用的节点。当你有多个分支输出时用聚合器把它们合并成一个变量后面节点就不用关心数据来自哪个分支。这个设计在复杂流程里能省很多事。Dify本地部署也不复杂Docker Compose一把梭。但要注意版本兼容性不同版本的插件接口可能不一样。离线安装插件时需要把插件包下载好放到指定目录然后在界面里手动上传。3.4 基础设施层华为云上的大模型部署要点华为云在大模型部署上提供了一些便利比如预置的模型镜像、弹性算力、API网关。如果你不想自己配环境可以直接用它的托管服务。从华为云获取数据到本地流程通常走API或SDK。需要注意的是网络连通性和鉴权配置。API Key要妥善保管不要硬编码在代码里用环境变量或密钥管理服务。注意私有化部署时模型文件往往很大下载和加载都需要时间。建议提前规划好存储和内存别等到部署时才发现磁盘不够。4. 实操流程从文档上传到结构化输出的完整链路4.1 环境准备与依赖安装先列一下我常用的环境配置Python 3.10PaddleOCR 2.7DifyDocker部署DeepSeek API Key华为云账号如需云服务PaddleOCR安装pip install paddlepaddle paddleocrDify本地部署git clone https://github.com/langgenius/dify.git cd dify/docker docker compose up -d启动后访问本地端口默认是80。第一次登录需要设置管理员账号。4.2 OCR识别与文本预处理以识别一份中文合同为例from paddleocr import PaddleOCR ocr PaddleOCR(use_angle_clsTrue, langch) result ocr.ocr(contract.jpg, clsTrue) for line in result[0]: text line[1][0] confidence line[1][1] print(f文本: {text}, 置信度: {confidence})如果识别韩文把langch改成langkorean。如果报错说找不到字典检查是否下载了对应语言包。识别出来的文本往往有噪声比如多余空格、换行错乱、识别错误。我一般会做三步清洗去掉首尾空格、合并被错误分割的句子、用大模型做一次纠错。4.3 大模型结构化抽取把OCR文本传给DeepSeek让它抽取字段import openai client openai.OpenAI( api_keyyour-api-key, base_urlhttps://api.deepseek.com ) prompt 从以下合同文本中抽取以下字段以JSON格式返回 - 收入金额 - 单位名称 - 签订时间 合同文本 {text} response client.chat.completions.create( modeldeepseek-chat, messages[{role: user, content: prompt.format(textocr_text)}] ) print(response.choices[0].message.content)这里的关键是提示词要明确输出格式。我试过不给格式要求模型返回的字段名每次都不一样后面解析很痛苦。加上“以JSON格式返回”并给出字段列表后输出就稳定了。4.4 Dify工作流搭建在Dify里搭一个文档处理流程开始节点接收文件上传OCR节点调用OCR服务识别文本代码节点清洗文本LLM节点结构化抽取条件分支判断抽取是否成功变量聚合器合并成功和失败分支结束节点返回结果每个节点的输出变量要命名清楚比如ocr_text、cleaned_text、extracted_json。变量名不要用中文避免兼容性问题。如果流程里文本太长导致上下文超限在OCR节点后面加一个文本分割节点把长文本切成小块分别处理后再合并。4.5 结果校验与入库大模型抽取的结果不能直接信一定要做校验。我的做法是金额字段用正则检查是否为数字时间字段用日期解析库检查格式单位名称跟已知单位列表做模糊匹配校验不通过的记录打上标记转人工复核。校验通过的写入数据库。这一步看起来麻烦但能避免大量脏数据进入系统。我见过太多团队跳过校验结果后面做报表时发现数据乱七八糟回头清理成本更高。5. 常见问题与排查技巧实录5.1 OCR识别不了特定语言怎么办问题PaddleOCR识别韩文返回空或乱码。原因默认语言配置是中文没有加载韩文字典。解决创建pipeline时指定langkorean并确保字典文件已下载。如果还是不行检查PaddleOCR版本老版本可能不支持某些语言。5.2 Dify SSL错误和凭证验证失败问题Dify调用外部API时报SSL错误或者提示“an error occurred during credentials validation”。原因通常是网络环境问题或者API Key配置错误。排查步骤检查API Key是否有效有没有多余空格检查网络是否能访问目标API如果是自签名证书需要在Dify配置里跳过SSL验证仅测试环境查看Dify日志定位具体错误信息5.3 Dify工作流上下文超长问题LLM节点报token超限。原因前面节点输出的文本太长。解决在中间加文本分割或摘要节点。分割用代码节点实现摘要用LLM节点实现。摘要的提示词可以是“用200字总结以下内容”。5.4 大模型输出格式不稳定问题每次返回的JSON字段名不一样或者格式不对。原因提示词没有明确约束输出格式。解决在提示词里给出JSON示例并强调“严格按照示例格式返回”。如果还是不稳定用代码节点做后处理提取关键字段。5.5 私有化部署模型加载慢问题模型文件太大加载时间长内存不够。原因模型参数量大硬件配置不足。解决换小模型或者增加内存。70B模型至少需要140G内存13B模型需要26G左右。提前规划好硬件。5.6 常见问题速查表问题可能原因解决方法OCR识别率低图片质量差、语言配置错误提高图片分辨率、指定正确语言Dify SSL错误网络问题、证书问题检查网络、配置证书上下文超长文本太长分割或摘要输出格式不稳定提示词不明确给出JSON示例模型加载慢硬件不足换小模型或加内存API调用失败Key错误、网络不通检查Key和网络6. 一些踩坑之后的个人体会大模型应用这件事模型本身的重要性可能只占三成剩下七成都在工程细节上。我见过太多团队花大量时间选模型、调参数结果卡在OCR识别不准、工作流跑不通、API调不了这些“小事”上。我的建议是先用最小可行方案跑通全流程再逐步优化每个环节。不要一上来就追求完美先让数据从上传到输出跑起来哪怕识别率只有70%也能验证业务价值。跑通之后再针对瓶颈环节做优化比如换更好的OCR、加文本清洗、调提示词。另外工具是为人服务的不要被工具绑架。Dify好用但不是所有场景都需要工作流编排。有时候一个Python脚本加几个API调用比搭一套工作流更简单直接。选型的时候多问自己这个工具解决了我什么具体问题如果没有它我用最笨的方法能不能做如果能那就先用笨方法等真的痛了再换。最后说一个容易被忽略的点日志和监控。大模型应用的不确定性比传统软件高得多同样的输入可能得到不同的输出。没有日志出了问题根本没法排查。我从第一个项目开始就坚持记录每次调用的输入、输出、耗时、token消耗后来这些日志成了优化提示词和排查问题的核心依据。这个习惯建议你也养成。