企业官网建设流程全解析

在杭州做算法工程师这几年，我最大的感受是：真正值钱的不是“能训模型”，而是“能让模型在业务里好好干活”。现在大模型一火，很多团队都在喊“落地”，但真上手才发现，从Demo到生产环境，中间隔着一整套工程化、产品化、数据闭环的硬功夫。这篇东西就结合我在杭州做“大模型应用落地”的真实经历，聊聊这个岗位到底在干什么、有哪些可以复用的流程、踩过哪些坑，以及给想走这条路的人一点参考。如果你是做算法的、做后端的，或者是被老板塞了“用大模型改造业务”任务的同学，这篇文章应该能帮你少走不少弯路。

1. 杭州做算法工程师，为什么我选择“应用落地”这条路

1.1 大模型时代的岗位分化：算法研究员 vs 应用工程师

现在行业里“算法工程师”这个称呼已经被大模型彻底重新定义了一遍。以前我们理解的算法工程师，要么是写特征、调参、跑模型的机器学习工程师，要么是发论文、刷榜、搞SOTA的研究员。但大模型起来之后，岗位开始明显分成两拨：一拨继续往底层走，做预训练、做对齐、做推理优化，需要极强的数学和系统能力；另一拨则往应用走，核心不是“训练出一个新模型”，而是怎么把已有的开源模型或API用出花来，让它解决具体业务问题。

我选择的是后者，而且坐标在杭州。说实话，杭州这边做底层大模型的岗位并不算多，玩家集中在少数大厂和研究院，但做应用落地的需求却非常旺盛。这里电商、金融、制造、安防、物流的企业密度极高，大量业务场景都等着被大模型重新做一遍。所以“偏大模型应用落地”的算法工程师，在杭州反而比“纯研究”更好找机会，也更容易直接看到自己的工作产生商业价值。

应用落地的岗位，日常工作不是发明新模型，而是设计Prompt、搭RAG链路、做微调、跑评测、优化响应速度，甚至还要自己写一些服务端代码。听起来杂，但这个“杂”恰恰是应用落地工程师的核心竞争力。因为你需要贯穿整个链路：懂一点模型、会一点数据、懂一点部署、还要能和产品经理及客户有效沟通。

1.2 应用落地到底落在哪里：场景、数据、价值

很多刚转过来的人会问：大模型应用落地，到底是在落什么？我的理解是，落地的本质是“在合适的场景里，用合适的模型能力，切进现有业务流程，并且能稳定产生可量化的收益”。这个定义里三个关键词缺一不可。

第一个关键词是“合适的场景”。不是所有业务都适合上大模型。比如简单的关键词匹配、固定规则判断，你用大模型反而又慢又贵又不可控。真正适合的场景，通常需要一定程度的语义理解、内容生成、信息抽取，或者是对自然语言交互有强需求，比如客服对话、文档解析、智能问答、辅助创作、代码检查等。

第二个关键词是“合适的数据”。杭州很多企业手里有大量历史工单、产品文档、数据库表格、售后记录，这些数据散落在各个业务系统里，格式五花八门。落地大模型的过程中，至少有40%的时间是在清洗、整理、抽取、标注、切成合适的结构喂给模型。数据质量直接决定模型效果，这是所有做落地的人用脚投票得出的结论。

第三个关键词是“可量化的收益”。老板要的不是“我们上线了一个智能助手”，而是“客服人力节省了20%”“工单处理时长缩短了35%”“质检漏检率下降了50%”。如果你不能在项目开始时就想清楚怎么评估价值，后面很可能做个自娱自乐的玩具。

2. 一个可复用的落地流程：从需求到上线的五个阶段

2.1 需求澄清：先搞清楚“客户要什么”

我踩过最大的坑，就是接到需求直接开始找模型。产品经理说“我们想做个智能问答”，我就去找开源模型、调API、做Demo，做出来人机交互效果还不错，结果用户一问：“这个能接我们内部的员工数据吗？”当场傻眼。

所以我现在做任何大模型落地项目，前两周基本不碰代码，全部在开需求会、看用户流程、翻历史数据。一定要搞清楚的几件事包括：用户原本是怎么完成这个任务的？痛点到底是什么？当前流程里哪一步最耗时、最容易出错？这个场景对错误率的容忍度有多高？如果模型答错了会产生什么后果？

比如做客服工单分类，用户可能不是要一个“会说话的机器人”，而是要一个能自动判断工单优先级和归属组别的系统。如果只做一个聊天机器人，可能完全不解决核心痛点。再比如做内部知识库问答，用户往往已经有一个搜索系统，只是搜索精度不够。你要做的不是重新发明对话，而是把大模型嵌进原来的检索流程里，做一个“重排序+生成答案”的增强模块。

需求澄清阶段还要同步确认技术边界：有没有内网部署要求？数据能不能出域？GPU预算是多少？并发量有多大？这些问题越早暴露越好，否则到上线前才发现合规过不去，整个方案都得推翻。

2.2 技术选型：开源模型、商用API还是本地私有化

技术选型是应用落地里最纠结的一环，没有银弹，只有trade-off。国内能用的商用API响应快、效果强、省心，但随之而来的是数据安全、单次调用成本和长期依赖问题。杭州不少企业客户很在意数据隐私，尤其是金融、医疗、政务、制造领域，明文把业务数据发到第三方API是过不了合规的，导致很多需求只能走私有化部署路线。

私有化部署也不是非要用70B的大模型不可。很多业务场景根本不需要那么大参数量，7B到14B的中小模型用量化版跑在单张或双张消费级显卡上，配合RAG和精心设计的Prompt，效果完全够用。我常用的一套默认配置是：Qwen系列开源模型或Llama系列的中小尺寸版本，用vLLM做推理加速，加上嵌入模型做检索，配合Redis做缓存。

选模型时有个经验法则：先跑通业务流程，再调模型。不要一上来就追求“最强”，不一定划算。要测的是：在典型问题上，这个模型能不能及格？比如分类任务准确率有没有到90%？抽取任务的F1有没有超过85%？如果及格了，再考虑它的推理速度、上下文长度、对中文的支持程度。等流程稳定了，再针对瓶颈去升级模型或做微调。

2.3 数据处理：让模型用对数据

模型选好后，数据才是真正决定效果上限的东西。大模型应用里最常见的数据处理包括：文档清洗、切分、结构化抽取、向量化、构造训练集/评测集。

文档清洗是个容易被低估的步骤。很多企业内部文档是PDF、扫描件、PPT、Excel，直接拿给模型用会有大量噪声。比如PDF里表格的排版容易乱、扫描件需要OCR、模板里的页眉页脚会混淆检索。我一般会先用一套解析管线把这些原文档统一转成Markdown或JSON结构，把没用的横幅、页脚、水印去掉，再按章节结构切分成语义完整的块。切分粒度是其中的关键细节：太大会降低检索精度，太小会丢失上下文。一般经验是256到512个token左右一块，具体得按文档类型试。

向量化之前，还要决定用哪种Embedding模型。中文场景用开源的BGE、M3E之类的嵌入模型，再配合一个重排序模型（reranker），往往能把最终检索效果提升一截。嵌入式向量和重排序是两套独立环节：向量负责粗召回一批候选，重排序负责从候选里挑出真正相关的段落。这个组合在实践上非常有效，成本也不高。

2.4 模型部署：从GPU资源到服务化

部署环节是应用落地工程师跟纯算法工程师差别最大的地方。纯算法可以只输出一个“效果报告”，但落地你必须让模型变成可以被业务调用的服务。

最小可用的一套方案是用vLLM把开源模型部署成一个OpenAI兼容的HTTP接口，然后用Python的FastAPI包一层业务逻辑，做权限校验、数据组装、日志记录。vLLM比纯HuggingFace Transformers的推理快很多，因为它自己做了PagedAttention、连续批处理这些优化，吞吐量能翻好几倍。

部署前记得看显卡天梯匹配模型显存。比如一个7B模型，FP16权重大约需要14GB显存，加上KV Cache和激活显存，一张24GB的4090或3090勉强跑得动但并发不高；如果做INT8或INT4量化，可以用更小的卡，但效果会有轻微损失。上线之前一定要做压测，不要等到业务流量上来才发现单卡扛不住。

2.5 效果评估与迭代：跑分不代表用户满意

做过落地项目的人都会告诉你：公开榜单分数和用户满意度之间，通常隔着一条马里亚纳海沟。你拿MMLU或C-Eval说模型多牛，用户不关心。用户关心的是：我问它“这个订单为什么被锁定”，它能不能看到正确的订单状态并解释清楚原因。

所以每个项目都要建一个属于自己业务的评测集。从真实历史数据里抽100到200条典型问题，标注好标准答案，形成回归测试集。每次改Prompt、换模型、更新知识库，都先跑一遍这条评测集，对比准确率、完整度、有害率这些指标。没有这个闭环，你后期根本没法判断改动到底是变好还是变坏。

迭代不是拍脑袋。我通常按这么个节奏走：先拿通用Prompt跑Base模型，看问题集中在哪——是检索不到内容、模型理解错意图、还是生成格式不对；再针对问题去修数据或Prompt；最后才考虑微调。很多问题根本不用动模型权重，数据修干净就好了。

3. 关键技术拆解：RAG、微调、Agent、多模态怎么选

3.1 RAG是落地最稳的起点

RAG（检索增强生成）应该是最近一年大模型落地里出现频率最高的词，也是我用的最多、最推荐优先考虑的一套方案。它的核心逻辑很简单：不直接让模型凭记忆回答，而是先从外部知识库检索相关片段，再把片段拼进Prompt里，让模型基于这些材料回答。

这么做的好处有三个：第一，不需要重新训练模型就能引入私有知识；第二，知识可以实时更新，改了知识库立即生效；第三，回答可以附上引用来源，方便溯源和审核。在杭州很多企业的内部知识库场景里，RAG已经成了标配。

但RAG不是“简单把文本扔进向量库”就完事。检索质量是最大瓶颈。除了前面说的切分和重排序，还有个容易被忽略的点：文档之间的交叉引用。比如一篇操作手册里说“详见SOP-1023”，单纯按段落检索可能找不到SOP-1023的内容。遇到这种情况，需要在离线阶段做实体链接或关系关联，把这种引用信息一起送进上下文。RAG链路的每一步都会影响最终效果，所以不要等做完了再整体优化，每一步都要单独验证。

3.2 微调的必要性和风险

微调是很多人一听大模型落地就兴奋的地方，但我必须泼盆冷水：大部分业务场景用不到微调，或者说不该一开始就微调。因为微调成本高、周期长，而且如果基座模型已经够聪明，你只需要给它正确的数据格式和示例，它就能通过In-context Learning做得很好。

那么什么情况下才需要微调？我总结三种典型情况：第一种，模型的输出格式必须严格遵循某个schema，比如从医疗报告里抽取结构化字段，Prompt怎么写都偶尔会“跑偏”，微调可以强制体系；第二种，业务领域术语特别重，模型因为不认识这些术语而频繁出错，比如特殊的设备型号、行业黑话；第三种，需要的推理模式不是通识能力，而是某种特定的格式化行为，比如把表格数据转成特定报表格式。

微调的数据准备比模型训练本身更考验功力。一个高质量微调集少则几百条，多则几千条，每条都要确保“输入明确、输出正确、格式统一”。我建议从大模型生成的初始结果开始，人工修正后再喂回去训，效率和效果都更好。微调完一定要做同分布的验证集评测，防止过拟合到训练集。

3.3 Agent和多模态的场景限制

Agent是当下更热的方向，但在杭州真实业务里，能稳定跑的Agent很少。Agent本质上是“让模型自己规划调用哪些工具、按什么顺序调用”。听起来很美好，但模型规划一旦出错，会造成连锁反应。比如让Agent自动操作数据库，它可能写出一个性能极差的查询，直接拖垮线上库。所以Agent的落地路径通常是“受限Agent”：不给完全自由，只允许它在预设工具集里按固定流程走，每一步都由代码校验结果，而不是全让模型判。稳妥压倒聪明。

多模态在杭州也有不少需求，比如工业质检、单据识别、安防监控。不过多模态大模型的可靠性还需要人工兜底。我做过一个OCR+大模型的混合方案：用传统OCR识别关键字段，再用视觉语言模型做泛化抽取，最后加规则校验。多模态落地别指望一个模型搞定所有事，多引擎组合是常态。

4. 实战案例：一个工业质检报修系统的大模型改造

4.1 业务背景与目标

这个项目来自杭州本地一家制造型企业。他们原来的质检报修流程是：产线工人发现设备故障，拍照上传到工单系统，填写故障描述，然后由维修工程师根据描述初步判断故障类别和优先级，分配给人处理。问题很明显：描述不规范、分类靠个人经验、工单流转速度慢。

客户最初提的需求是“做个智能聊天机器人，让工人能问设备问题”。但我们进场调研后改了方向，因为没有对话机器人不是核心痛点，核心痛点是“从故障描述到故障标签映射”这一步太慢太不准。最后跟客户对齐的目标是：自动从工人填写的故障描述里抽取关键信息，生成结构化故障标签，并给出维修建议和优先级判断。准确率目标定为：分类准确率不低于90%，抽取字段的F1不低于85%。

4.2 我做的具体事情

技术方案上没有选择微调大模型，而是走“小模型兜底+大模型增强”的路线。第一步，收集过去两年大概5万条历史工单，做清洗和标注，梳理出约12个大类、60多个小类的故障标签体系。第二步，先训练一个传统的文本多分类模型做第一层兜底，保证高频常见问题快速命中。第三步，对兜底模型置信度低的样本，再调用开源大模型做细粒度语义分类和字段抽取。

这里有个关键设计：不能让大模型独立决策。我设定了一个规则引擎，如果兜底模型置信度高于0.9就直接出结果；如果低于0.5就交给人工复核；中间区间才交给大模型分析，并且大模型输出后还要经过引擎的格式校验，不合规就打回重问。这种“分级决策”的设计大幅降低了幻觉影响，客户用下来体验很稳。

数据方面还做了不少特征工程：把设备编号、故障现象、报修时间、产线位置都结构化，和文本描述一起作为模型输入。后来发现，加入设备编号后，分类准确率直接提高了5个百分点左右。因为同一个设备的历史故障极具参考价值，模型能借助这部分信息做更准确的判断。

4.3 效果与教训

项目上线后，工单从提交到自动分类的平均耗时从原来的十几分钟缩短到几秒，分类准确率稳定在91%到93%之间，超出预期。维修工程师不需要再逐条读描述，而是直接看系统给出的标签和维修建议，派单效率明显提升。最直观的收益是：整体报修流转时间缩短了大概30%。

但这个项目也给我们几个挺深刻的教训。第一，客户给的“原始需求”往往不是真正的需求，一定要调研完再定义目标。第二，不要追求全流程自动化。大部分制造业场景，人工兜底复核是刚需，系统要设计成“人机协同”，而不是“无人驾驶”。第三，模型迭代必须有数据回流。我们后期在系统里加了“工程师修正标签”的按钮，用户每次修正都变成一条新的训练数据，模型每两周迭代一次，效果越跑越好。

5. 落地过程中最常见的坑和排查方法

5.1 幻觉问题：不是模型笨，是输入不对

做RAG类应用时，用户反馈最多的是“答案看起来很像那么回事，其实是错的”。这种幻觉大量出现时，我的排查顺序一定是先查检索，再查Prompt，最后才怀疑模型。

先看知识库里到底有没有正确答案，以及它有没有被正确切分和索引。很常见的情况是：知识库里有文档，但Embedding模型没有把关键段落召回，导致模型只能“瞎编”。解决方法就是调检索：换Embedding、加重排序、调整切分大小。另外一种常见原因是Prompt里给的信息不够明确，模型不知道“不知道时可以拒绝回答”。我一般会在系统Prompt里写死一句：“若上下文中没有明确信息，请直接回复‘未找到相关内容’，不要猜测。”别小看这一句，幻觉能少一半。

5.2 延迟和成本：能忍才叫落地

大模型部署完，业务方第一个问的就是：“多快？多贵？”如果单次问答要等5秒以上，很多前端交互就完蛋了。降延迟的办法有很多，按收益排序：一是上缓存，高频问题直接命中缓存；二是换小模型，如果小模型能答60%的简单问题，就做两层路由，简单问题走小模型，难问题才走大模型；三是用流式输出，用户先看到字在吐，体感上快很多；四是做推理优化，量化、批处理、PagedAttention这些都能降低单次延迟和单位成本。

成本方面有一个常见误判：只算模型推理的算力成本，没算数据准备和人工审核成本。实际上大模型项目的人力成本往往是GPU成本的几倍。做预算时一定要把数据标注、评测集制作、周期回归测试的人力都算进去，否则老板看成本一定会被吓到。

5.3 评测缺失：没有基线就没法优化

我还遇到过一个项目，做客服问答，模型效果时好时坏，但团队吵半天也说不清“到底是好是坏”，因为没建评测集。后来我花了一周时间，从历史会话里抽了300条高频问题，组织业务专家标好标准答案，跑了一个baseline。有了这个基线之后，后面每次改动Prompt、换模型、调参数，都会用同一批问题集跑一遍。一个月后，准确率从78%稳步提到88%，每一步都有据可查。

评测集不是一次建完就躺平。随着业务演进，新的问题类型会不断冒出来，要定期补充新题，同时保留旧题做回归，防止模型“越改越差”。这个机制是应用落地项目最重要的质量基础设施，早建早受益。

6. 关于“杭州算法工程师”这条路的几句实在话

说到底，“算法工程师，偏大模型应用落地”并不是一个花哨的title，而是一个需要沉下心跟业务死磕的岗位。在杭州这两年，我能明显感觉到，企业不再盲目追捧“大模型什么都能干”，而是更关心“你能不能把我们手头的烂数据、乱流程整理明白，让模型真正帮一线的人干活”。这个方向对算法工程师的要求不再是顶会论文，而是工程习惯、数据敏感度、业务理解力和快速学习能力。

如果你正准备入这行或转岗，我个人的建议是：第一，一定亲手完整做一个端到端的落地项目，哪怕是自己造一个数据，把RAG、部署、接口、前端串起来，这个手感非常重要；第二，别被“高级应用框架”迷了眼，先把Prompt、数据切分、评测这些基本功做扎实；第三，多和业务同事聊天，你会发现真正的技术难点常常不在模型里，而在组织协作、数据权限、流程规则那些“人尽皆知但没人写进文档”的细节里。

最后分享一个小经验：大模型落地项目做得顺不顺，很多时候取决于你愿不愿意先从最简单、最笨的功能开始交付。先让用户用起来，有了真实反馈和数据回流，后面再一步步优化路会越走越宽。我反正是靠着这个思路，在杭州把一个又一个“看起来很飘”的大模型需求，变成了稳定运行的线上系统。