企业官网建设流程全解析

1. 大模型落地，别只盯着模型本身

这两年跟不少团队聊过大模型落地的事，发现一个特别普遍的现象：大家一上来就问“用哪个模型”“参数多少”“要不要微调”，但真正跑起来之后卡住进度的，往往不是模型本身，而是模型外面那一圈东西——文档怎么解析、流程怎么编排、接口怎么调、私有化环境怎么部署。模型是发动机，但光有发动机，车是跑不起来的。

这篇内容我想聊的是“大模型的应用和工具”这个题目。它不是一个具体的项目，而是一整条链路：从最底层的模型选型和部署，到中间层的文档识别、工作流编排，再到最上层的业务场景落地。适合谁看？如果你是把大模型往业务里塞的开发者、技术负责人，或者正在做企业级 AI 应用的技术同学，这里面的东西应该能帮你少走点弯路。如果你只是想调个 API 玩玩，前半部分可能对你有点重，但后面关于工具链和踩坑的部分同样有参考价值。

我自己的判断是，2024 年之后，大模型应用的竞争已经从“模型能力”转移到了“工程能力”。谁的文档解析更准、谁的流程编排更稳、谁的私有化部署更省心，谁就能真正把大模型用起来。下面我按“模型层—工具层—编排层—部署层”这个顺序，把整条链路拆开讲。

2. 模型选型与接入：别被参数迷了眼

2.1 通用模型和垂直模型怎么选

选模型这件事，我的经验是先分场景，再谈参数。通用对话、文案生成、代码辅助这类任务，用主流的大参数通用模型基本都能覆盖，DeepSeek 系列在这类任务上的表现这两年确实比较稳，尤其是推理和代码方向，社区反馈也集中。但如果你做的是 OCR 后处理、合同字段抽取、问卷结构化这类任务，通用模型反而不一定是最优解，因为这类任务的核心难点在“输入质量”和“输出格式约束”，不在语言理解本身。

我一般会按三个维度来筛：任务类型、输入形态、输出约束。任务类型决定你要不要推理能力强的模型；输入形态决定你要不要先做 OCR 或文档解析；输出约束决定你要不要用结构化输出或者函数调用。举个例子，合同字段抽取这个场景，输入是扫描件 PDF，输出是固定字段的 JSON，那模型选型其实不是第一优先级，OCR 的准确率和字段对齐逻辑才是。

提示：不要一上来就微调。我见过太多团队花两周做微调，最后发现把 prompt 和输出格式约束做好，效果就已经够用了。微调应该是最后手段，不是第一手段。

2.2 API 调用和本地部署的取舍

接入方式上，API 调用和本地部署是两条路。API 调用胜在快、省心、按量付费，适合验证阶段和中小流量场景。但一旦涉及企业数据、合同、问卷这类敏感内容，私有化部署就成了硬需求。私有化部署的核心不是“把模型跑起来”，而是“把模型跑稳、跑便宜、跑得可维护”。

本地部署我一般会看三件事：显存够不够、推理框架选哪个、并发怎么扛。显存这块，7B 级别的模型量化后大概 6-8G 显存能跑，13B 大概 12-16G，70B 级别就得上多卡或者量化到 4bit。推理框架上，vLLM 和 SGLang 是目前比较主流的选择，前者生态成熟，后者在特定场景下吞吐更好。并发这块，别只看单次推理速度，要看 P99 延迟和吞吐曲线，很多模型单次快但并发一上来就崩。

2.3 免费 API 和付费 API 的实际差异

社区里经常有人问免费大模型 API 能不能用。我的看法是：验证阶段可以用，生产环境要谨慎。免费 API 通常有三个隐性成本——限流、稳定性、数据合规。限流不用多说，QPS 一上来就卡；稳定性上，免费通道的 P99 延迟波动很大；数据合规这块，企业数据走免费通道基本是不合规的。所以我的建议是，验证阶段用免费 API 快速跑通流程，一旦要上生产，立刻切到付费或者私有化。

3. 文档解析与 OCR：大模型应用的“入口关”

3.1 OCR 为什么是大模型落地的第一道坎

大模型再强，它读不了扫描件。企业里的数据大量存在于 PDF、图片、扫描件里，OCR 就是把这些非结构化数据变成结构化文本的第一道关。这道关过不好，后面模型再强也是白搭。我见过一个合同抽取项目，模型换了三个，效果一直上不去，最后发现是 OCR 把“收入”识别成了“收人”，模型再聪明也救不回来。

OCR 的选型上，Tesseract 是老牌开源方案，适合英文和印刷体，但中文和复杂版式下准确率会掉。PaddleOCR 在中文场景下表现更好，尤其是版面分析和表格识别。百度 OCR、华为云 OCR 这类云服务在通用场景下准确率高、接入快，但按量计费，量大之后成本要考虑。选哪个，取决于你的文档类型、量级和合规要求。

3.2 不同语言和场景下的 OCR 踩坑

社区里有个典型问题：用 PaddleX 的 pipeline 识别韩文识别不出来。这类问题的根因通常是模型没加载对应语言的权重，或者 pipeline 的配置里语言参数没设对。PaddleOCR 的多语言支持需要显式指定语言，默认往往是中英文。类似地，Java 调百度 OCR 识别合同文件时读取收入、单位、时间等关键字段，难点不在 OCR 本身，而在字段定位和正则匹配，因为 OCR 出来的文本是带坐标的，你需要根据坐标做版面还原。

VBA 调百度云 OCR 这种场景我也见过，通常是 Excel 里批量处理图片。这种方案的坑在于 VBA 的 HTTP 请求库比较弱，超时和重试要自己写，而且百度云 OCR 的 token 有效期是 30 天，过期后要重新获取，VBA 里做这个逻辑比较别扭。我的建议是，如果量不大，用 Python 写个脚本批量跑，比 VBA 省心得多。

3.3 OCR 后处理：比 OCR 本身更重要

OCR 出来的是原始文本，直接喂给大模型效果往往不好，因为里面有换行错乱、字段粘连、识别噪声。后处理这一步我一般做三件事：版面还原、字段切分、噪声过滤。版面还原是把 OCR 的坐标信息还原成阅读顺序；字段切分是按业务规则把文本切成字段块；噪声过滤是去掉页眉页脚、水印、乱码。

注意：OCR 后处理的规则要跟业务方一起定，不要自己拍脑袋。我见过一个项目，开发把“合计”当成噪声过滤掉了，结果业务方要的就是合计金额。这种坑，只有跟业务对齐才能避免。

4. 工作流编排：Dify 这类工具到底解决了什么

4.1 为什么需要工作流编排

大模型应用不是“输入—模型—输出”这么简单。真实场景里，一次请求可能要经过文档解析、意图识别、知识检索、模型推理、结果格式化、人工审核等多个环节。如果每个环节都写死在代码里，改一个逻辑就要发一次版，迭代效率极低。工作流编排工具的价值就在于把这些环节可视化、可配置、可复用。

Dify 是这两年比较火的一个选择，它的核心能力是把 LLM 应用拆成节点，用连线的方式编排流程。知识库、变量聚合器、条件分支、循环这些节点，基本覆盖了常见的 RAG 和 Agent 场景。我自己的体验是，Dify 适合快速验证和中小规模生产，但如果流程特别复杂、性能要求特别高，还是得回到代码层。

4.2 Dify 本地部署和离线安装的实操要点

Dify 本地部署一般用 Docker Compose，官方仓库里有现成的 compose 文件。部署前要确认几件事：Docker 版本、端口占用、数据卷挂载路径、环境变量里的数据库和 Redis 配置。我踩过的坑是数据卷没挂对，容器重启后数据全丢，所以部署前一定要把 volumes 配好。

离线安装插件是另一个高频问题。Dify 的插件市场在没网的环境下用不了，需要手动下载插件包再导入。导入的时候要注意插件版本和 Dify 版本的兼容性，版本不匹配会报错。另外，Dify 迁移的时候，除了数据库，插件和知识库的文件也要一起迁，只迁数据库会出现“流程在但插件没了”的情况。

4.3 Dify 常见报错和排查思路

Dify 的报错里，SSL 错误和 credentials validation 错误是两个高频问题。SSL 错误通常是反向代理的证书配置问题，或者容器内的时间不对导致证书校验失败。credentials validation 错误一般是模型供应商的 API Key 或 Base URL 配错了，排查的时候先确认 Key 有没有过期，再确认 Base URL 能不能在容器内访问通。

工作流上下文超长是另一个典型问题。Dify 的工作流里，每个节点的输出都会进上下文，节点一多，上下文就爆了。解决办法是用变量聚合器做裁剪，只把必要的字段往下传，或者在节点里做摘要。这个问题的本质是“上下文管理”，跟模型本身的上下文窗口是两回事。

5. 私有化部署与企业级落地

5.1 企业私有化部署的核心考量

企业大模型私有化部署，核心不是“能不能跑”，而是“跑得稳不稳、管不管得住、成本可不可控”。稳定性上，要考虑模型服务的健康检查、自动重启、灰度发布；管理上，要考虑多租户、权限、审计日志；成本上，要考虑 GPU 利用率、批处理、量化。

华为云这类云厂商在企业级场景下的优势在于，它们提供的不只是 GPU，还有配套的模型服务、监控、安全能力。华为 ICT 大赛云赛道里也有大模型部署相关的题目，说明这个方向已经是行业共识。但云服务的问题是成本，量大之后自建可能更划算，这个账要提前算。

5.2 从华为云获取数据的实操路径

从华为云获取数据，一般走 OBS 或者 API。OBS 适合大批量文件，API 适合结构化数据。实操上要注意的是鉴权，华为云的鉴权用的是 AK/SK 签名，签名算法要按官方文档来，时间戳和签名串对不上就会报 403。另外，OBS 的桶权限要配好，私有桶需要签名 URL 才能访问。

5.3 大模型微调：什么时候该做，什么时候不该做

微调这件事，我的原则是“能不改模型就不改”。微调的成本不只是训练，还有数据标注、效果评估、版本管理、回滚。如果 prompt 工程和 RAG 能解决，就不要微调。只有当任务对格式、风格、领域知识有强约束，且 prompt 和 RAG 都搞不定的时候，才考虑微调。

微调的数据量上，一般几百到几千条高质量样本就能看到效果，但“高质量”是关键。我见过用几千条脏数据微调，结果模型学会了脏数据的毛病。微调后的评估也要做，不能只看 loss，要看业务指标。

6. 常见问题速查与避坑清单

6.1 模型接入类问题

6.2 文档解析类问题

6.3 工作流编排类问题

6.4 私有化部署类问题

7. 我踩过的坑和几条实在建议

第一个坑是“过早优化”。我见过团队在验证阶段就纠结模型选型，换了五六个模型，结果业务逻辑都没跑通。我的建议是，先用一个能用的模型把流程跑通，再谈优化。

第二个坑是“忽视输入质量”。大模型应用的瓶颈往往在输入端，OCR 不准、文档格式乱、字段定义不清，这些问题不解决，模型再强也没用。我一般会把 60% 的精力放在输入端，40% 放在模型和编排上。

第三个坑是“不做评估”。大模型应用的效果评估比传统软件难，因为输出是自然语言。我的做法是建一个小的评估集，每次改动都跑一遍，看关键指标有没有退化。这个评估集不用大，几十条就够，但要有代表性。

最后一个建议是“保持简单”。工具链越复杂，出问题的概率越高。Dify 这类工具能解决问题就用，解决不了再上代码。私有化部署能单机跑就先单机，扛不住了再上集群。大模型落地是个工程活，不是炫技，稳比快重要。