大模型应用落地实战：RAG、微调与部署的技术栈全解析-平芜编程栈

如果你最近在看杭州的算法岗位，会发现一个很明显的变化：大模型应用落地方向的缺口，比预训练、纯研究方向的缺口大得多。很多公司挂在招聘网站上的JD，标题写着"算法工程师"，点进去一看，要求的是会部署开源模型、能做RAG、懂微调、能上手写服务——这就是典型的"偏应用落地"岗位。作为一名在杭州做算法、这两年深度参与过大模型项目落地的人，我想把这类岗位的真实工作内容、技术栈选择、落地流程和踩过的坑，一次性讲清楚。这篇文章适合准备转方向的同学、正在面试这类岗位的人，也适合已经在做落地但想找参考的同行。

1. 杭州大模型落地岗到底是什么

1.1 岗位定位：把模型变成业务价值的人

先给这个岗位画个像。杭州的算法工程师，偏大模型应用落地，要干的不是发论文，也不是从头训练一个几十B的底座模型，而是把现成的开源大模型或API能力，结合具体业务场景，做成一个能跑、能用、效果稳定的系统。

我接触过的落地项目大致分几类：企业知识库问答、客服智能助手、文档自动处理、报表生成、代码辅助工具、工业场景的质检报告生成。这些项目有一个共性——业务方不关心你用的什么模型架构，只关心"这个功能好不好用、准不准、快不快、贵不贵"。所以这类岗位的技术要求，往往不是模型结构设计能力，而是系统工程能力+算法调优能力的结合。

具体日常工作大概是：跟业务方聊需求、整理和清洗数据、选模型和部署框架、做推理优化、写接口和服务、上线后维护和迭代效果。听起来像全栈，但实际上，核心还是算法——你要知道模型为什么答不好，是数据问题、提示词问题、检索问题还是模型本身能力不够，然后针对性地解决。

1.2 为什么这类岗位集中在杭州

杭州有个很特别的地方：场景密度高。电商、金融、安防、制造、医疗、教育，各行各业都有数字化转型的需求，而这些需求里相当一部分现在都要用大模型来做。

电商平台的商品描述生成、客服对话总结、智能导购；安防企业的视频结构化描述、告警事件摘要；制造业的工艺文档问答、设备维修知识库——这些都是典型的大模型应用落地场景。有场景，才有算法工程师的坑位。

另一个原因是杭州的互联网基础设施发达。GPU资源、云服务、数据中台这些底座比较成熟，算法工程师去落地时，不需要自己从零搭一套基础设施，更多精力可以放在业务和模型之间的"最后一公里"上。

1.3 这个岗位和纯算法岗有什么不同

很多同学会纠结："算法工程师"和"算法应用工程师"是不是一回事？我的体会是，杭州这类偏大模型落地的岗位，有几个明显特征：

要求全栈但不要求深：Python是基本功，Java或Go可能也要懂一点，Docker、K8s要会操作，前端不用精通但要能写个调试页面。
业务理解比模型创新重要：你不需要发明新模型，但要能听懂业务方的真实需求，并且把它翻译成技术方案。
效果评估是日常：模型答得好不好，不能拍脑袋，要建立评测集、做A/B、持续迭代。

说实话，刚转过来的人容易踩一个误区：以为大模型应用落地就是调API、写Prompt。真上了项目会发现，Prompt只是最表层的东西，后面还跟着一连串的数据治理、检索优化、推理加速、服务稳定性问题，任何一个环节出问题，模型都落不了地。

2. 大模型应用落地的核心技术栈

2.1 模型选型：开源还是API，先算账再拍板

做落地项目，第一步永远是选模型。杭州这边的主流做法，可以分成三条路：

方案	适用场景	优点	劣势
闭源API调用	快速验证、非核心数据场景	效果最好，开发成本低	数据出域风险，单量大了费用高
开源模型私有化部署	数据敏感的政企、制造客户	数据不出域，可定制	需要GPU资源，运维成本高
混合方案	大流量+敏感数据混合	兼顾效果和合规	架构复杂度高

我的建议是，除非客户明确要求数据不能出域，否则第一版先用API快速把流程跑通。原因很简单：先验证业务价值，再考虑成本和合规。很多项目死在第一步——业务方根本不确定大模型能不能解决问题，你直接花几周部署一个开源模型，结果效果不达标，前面全白做。

等API验证了效果，再来审视数据敏感性和成本模型。如果确实需要私有化，再基于开源的Qwen系列、GLM系列、Llama系列去部署。国内场景我优先看Qwen和GLM，中文能力和商业许可都更合适。

2.2 部署与推理框架：从Ollama到vLLM

选完模型就是部署。很多时候第一步用Ollama在本地跑通模型，最多是拿A100测一下并发上限。Ollama的优势是零门槛，支持GGUF量化格式，一条命令就能把模型跑起来，非常适合原型阶段。我在帮客户快速验证的时候，经常用它对模型做能力摸底——先把几个候选模型都拉到本地，跑同一批测试问题，看输出质量，再决定用哪个。

但到了正式上线，Ollama就不太够了。并发一大，它的调度和吞吐优化明显不如专用推理框架。生产环境我主要用vLLM：

# 用vLLM启动Qwen2.5-7B-Instruct，开8个并发，最大输入长度8192 vllm serve Qwen/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --max-num-seqs 8 \ --max-model-len 8192 \ --gpu-memory-utilization 0.95

vLLM的PagedAttention机制能显著提高显存利用率和吞吐，实测同样的7B模型，比原生Transformers库的推理吞吐能高出好几倍。如果是超大并发场景，还可以考虑TensorRT-LLM，但配置复杂度会高不少。

这里有个关键参数要解释一下：--max-model-len是最大序列长度，包括输入和输出。很多RAG场景要喂很长的上下文，如果设小了，输入超长会直接报错；设太大，显存占用会指数级增加。7B模型在24GB显存下，我一般设8192比较稳，16GB就降到4096。

2.3 微调：默认别用，除非确定要

接着说一个落地项目里最容易踩的坑——微调。很多业务方的第一反应是"模型答得不行，是不是要训练一下"。作为算法工程师，你必须先判断：效果不好的原因是什么？

我的经验是，70%的效果问题靠Prompt和RAG就能解决，20%是数据问题，真正需要微调的只有10%。原因很现实：微调成本高、周期长，而且如果基座模型本身能力不够，微调也救不回来。

什么情况下才考虑微调？三个条件同时满足时：

业务有非常特定的输出格式（比如必须按固定JSON结构输出）
你有几百条以上高质量的业务数据
Prompt即使写得很详细，模型依然稳定地不遵守格式

真到了这一步，首选是LoRA或QLoRA，不是全参微调。原因很直接：消费级显卡也能跑、训练快、模型体积小、部署起来不用换整个模型。用LLaMA-Factory做LoRA微调，几行配置就能跑：

model_name_or_path: Qwen/Qwen2.5-7B-Instruct template: qwen stage: sft finetuning_type: lora lora_rank: 32 lora_alpha: 64 dataset: business_sft.json per_device_train_batch_size: 1 gradient_accumulation_steps: 8 learning_rate: 2.0e-4 num_train_epochs: 3.0 fp16: true

数据量不用多，我做过一个工业文档格式化的项目，1200条人工整理的高质量样本，LoRA微调后输出格式准确率从70%提到了95%以上，效果很明显。

2.4 RAG架构：落地项目的主旋律

如果说微调是备选项，RAG就是必选项。杭州大部分大模型落地项目的本质，都是"私有知识+通用模型"。企业有自己的文档、数据库、知识库，模型没有这些知识，最简单的办法就是把知识检索出来，拼到Prompt里让模型回答。

一个标准的RAG流程看上去不复杂：文档切分、向量化、存入向量库、用户问题向量化检索、拼Prompt、模型生成。但每个环节都有大量细节。

文档切分这块我踩过不少坑。按固定长度切是最省事的，但如果一个表格被切成两半、一个合同条款被拆散，检索质量会直线下降。我现在做企业文档时，会先做版面分析，按标题层级切块，再把同一章节的语义块合并。表格要单独处理，最好转成Markdown或HTML格式再进模型，否则很多模型读不懂结构化的表格内容。

向量化选哪个Embedding模型也很关键。通用场景可以用BGE或text-embedding系列，如果是垂直领域（比如法律、医疗），最好用领域微调过的向量模型。检索方面，纯向量检索在专业术语多的场景里经常翻车，我现在的做法是BM25关键词检索+向量检索的混合方案，再用Rerank模型对前20个结果重排，效果比单用向量检索稳定得多。

部署RAG服务时，我自己习惯用FastGPT或Dify这类开源平台快速搭一套验证原型，到了生产环境再根据需求定制化。这样既能快速给业务方演示效果，又不至于一开始就陷入工程细节里。

3. 一个落地项目的完整生命周期

3.1 需求拆解：先搞清楚业务方真正要什么

一个真实的大模型落地项目，生命周期通常从一个模糊的需求开始。我在杭州做过的项目里，最常见的一句话是："我们想做一个智能问答系统。"

这句话基本等于什么都没说。要往下做，必须先拆清楚几个问题：

用户是谁？是内部员工还是外部客户？他们会在什么场景下提问？
需要覆盖什么知识范围？有没有现成的知识文档？
对准确率的要求是什么？有些场景90%就可以上线，有些错了要赔钱。
数据能不能出域？API能不能用？服务器在哪？
预算和工期是多少？这直接决定了技术选型。

我的做法是，在需求会之后一定会再约一次业务方的"深度访谈"，带上他们已经有的知识库样本，问他们最头疼的Top20个问题是什么。这一步不是为了收集需求，而是为了建评测集——拿这20个问题作为初始的效果验收标准。

3.2 数据准备工作：决定效果上限的地方

很多同学轻视数据准备，觉得模型能力强，随便丢点文档进去就能答。真实情况是，数据准备决定了效果的上限，模型和Prompt只是在逼近这个上限。

以我做过的一个企业制度问答项目为例。客户给了一个共享盘，里面各种格式的文档混在一起，Word版本就有好几版、PDF扫描件清晰度不一、Excel表格格式混乱。我们花了两周时间做数据治理：

格式统一：PDF扫描件走OCR转文本，Word、PPT、Excel全部转成统一的Markdown格式。
去重去旧：识别文档之间的版本关系，只保留最新版本。
敏感信息过滤：有些文档混入了身份证号、手机号，上线前必须清洗，不然模型会把这些信息检索出来。
质量抽检：抽样看转换后的文本有没有乱码、断行、表格错乱。

这个过程很琐碎，但没有任何捷径。数据清洗的时间通常占整个项目周期的50%以上，这很正常，不要觉得是在浪费工时。

3.3 技术选型：确认单场景的MVP路径

数据准备的同时，就要并行做技术选型。对于大多数知识库问答类项目，我的MVP路径是：

私有文档 -> OCR/格式解析 -> 清洗 -> 分块 -> Embedding -> 向量库 用户问题 -> 召回（BM25 + 向量） -> Rerank -> 拼接Prompt -> 大模型生成 评估 -> 人工标注bad case -> 优化分块/召回/Prompt -> 循环

向量库的选择，数据量小（百万级向量以内）用pgvector或Chroma就够了，简单省事；数据量大或者并发高，再上Milvus或Qdrant。不要一上来就堆中间件，很多项目死在过度设计上。

Prompt设计在这个阶段很重要。我比较激进，会把Prompt模板放在配置文件里，方便随时改，不经过代码发布。SFT阶段好的模板值得反复打磨，一个稳定格式化的Prompt模板，能让后续的bad case处理省一半力气。

3.4 上线与迭代：A/B测试和效果监控

上线不是终点，而是起点。大模型项目的效果是会随数据漂移衰减的——业务方的文档在更新、用户提问的方式在变化，这些都会影响检索和回答质量。

我在生产环境里一般会部署两层监控：第一层是技术指标，包括响应时间、Token消耗、检索命中的文档来源分布；第二层是业务指标，比如用户点了"有帮助"还是"没帮助"、转人工的比例有没有下降。

有了监控就能做迭代。每周从线上日志里抽一批bad case，人工看一遍，把问题归因（是检索没召回？还是模型没理解？还是Prompt指令不够清晰？），然后针对性优化。这个循环跑起来之后，系统的效果才会稳步提升。

4. 踩坑实录与问题排查

4.1 推理速度慢：先看吞吐再看时延

落地项目最常见的抱怨就是"太慢了"。客户说的慢，可能是首字延迟高（TTFT），也可能是整体生成慢。排查时先分野，再看资源。

如果首字延迟高，大概率是Prompt太长。一次RAG问答，把检索出来的5个文档块全塞进去，Prompt可能就有3000字，模型光"读"就要一两秒。解法是控制检索到的段落数量、压缩上下文，或者用上下文缓存。

如果是整体生成慢，看输出长度是不是太长。有些场景只需要输出"是/否"或一句话，但Prompt里没做限制，模型默认生成了几百字，自然慢。加个max_tokens限制能立竿见影。

并发上不去是另一类问题。一个7B模型FP16裸加载，大概要14GB显存，A100（80GB）看着余量很大，但一开vLLM，显存分配不当还是会OOM。我一般把--gpu-memory-utilization设为0.9以上，留出一点余量给上下文KV Cache，同时限制--max-num-seqs，避免单请求把上下文塞爆。

4.2 回答质量差：先找"病根"再开药

回答质量差，要按优先级排查：

上下文里有没有答案：如果检索出来的文档块本身就不含答案，那模型再强也答不对。我经常直接看日志里拼出来的Prompt，答案基本一目了然。
检索到的文档对不对：向量检索有时会召回一些表面语义相近但内容无关的段落，添加Rerank能有效缓解。
Prompt是否符合模型的理解方式：不同模型的指令遵循能力差异很大，同一个Prompt模板在Qwen上好用，换到Llama上可能效果断崖式下降。
模型本身能力不足：如果是推理、数学、多步任务这类问题，别费劲，直接换更大的模型或改走API。

4.3 大模型"幻觉"控制：给回答加上证据链

企业级场景最怕的是模型一本正经地胡说八道。控制幻觉我的做法是"软硬兼施"：

硬约束：Prompt里明确要求"只能基于给定的上下文回答，如果上下文中没有答案，直接说不知道"。同时让模型在输出时带上引用来源，比如"根据《考勤管理制度》第3章第2条"。如果检索不到相关证据，宁可不让模型硬答。
软约束：在业务逻辑层加一个"兜底判定"——当检索结果的相似度分数整体偏低时，直接返回"知识库中暂未找到相关信息"，不进入模型生成环节。

这样一套组合下来，我在知识库问答类项目里，把幻觉率从百分之十几压到了百分之二左右，客户那边才勉强敢让系统对内部用户开放。

5. 做这行需要的能力模型与学习建议

5.1 底层算法基础不能丢

虽然是应用落地岗，但算法基础依然是门槛。面试时必问的包括：Transformer的注意力机制、不同位置编码的区别、LoRA的原理和参数设置逻辑、RAG各环节的细节、大模型解码策略。

理由很简单：不懂这些底层原理，出了问题就是黑盒，只能瞎试。懂了原理，才能从"哪里可能出问题"入手去排查。比如你知道KV Cache会占显存，就会理解为什么max-model-len影响那么大；你知道温度参数是调节采样分布的，就知道前沿应用该调高还是调低。

5.2 工程能力是硬通货

说实话，在杭州这类岗位，工程能力的重要性经常超过算法水平。业务方不关心你调参多优雅，他们只关心服务能不能7×24稳定跑。所以这几个能力点要重点补：

Python后端开发：FastAPI写服务、接口设计、并发处理
Linux基础与容器化：Docker打包、K8s部署、GPU调度
数据库和缓存：Redis、MySQL、pgvector/Milvus
基本前端能力：能写一个简单的调试/演示页面

很多科班出身、算法很强但写代码不规范的同学，在这类岗位上反而吃亏。我见过太多"模型效果调得很好，但代码一上生产就崩"的情况。

5.3 大模型应用学习的推荐路径

如果你正在准备转入这个方向，我建议的路径是这样的：

先跑通最小闭环。找一台有显卡的电脑（没有就用云GPU），用Ollama部署一个7B模型，自己搭一套最简RAG（文档切分+向量化+检索+拼Prompt），看能不能回答几个问题。这一步能让你快速建立"应用到底是怎么转起来的"的整体认知。

再深入理解关键环节。把RAG里的每个环节单独拎出来深入研究：尝试不同的分块策略看效果变化；比较不同的向量模型；给检索结果加上Rerank看能提升多少；自己写一个Prompt模板感受模型的指令遵循能力。这个阶段你会踩很多坑，但这些坑都是宝贵的经验。

最后系统化工程能力。学会vLLM部署、写API服务、做并发优化、搭建评估流程。到这一步，你在杭州找这类岗位，基本有竞争力了。

资源方面，我平时从"动手学大模型"这类开源教程里补细节，Hugging Face的文档是绕不开的参考，LLaMA-Factory做微调可以快速上手，vLLM的GitHub页面也能学到很多推理优化的知识。

5.4 面试和谈薪：拿什么证明你行

杭州的算法应用岗面试，几乎没有纯八股。面试官更愿意听你讲项目——你做过什么场景、遇到过什么问题、怎么解决的、效果怎么样、上线没有。

我强烈建议在面试前，哪怕是自己做一个小项目，也要把"从需求到上线"的完整过程跑一遍，并且把过程中的关键决策记录下来。你能说出"为什么选vLLM而不是Ollama""为什么用混合检索而不是纯向量检索""效果从70%提到90%靠的是什么"，比背100个八股问题都管用。

薪酬方面，杭州偏大模型应用的算法岗，跟传统算法岗比有溢价，因为缺口大、跟业务结合的难度高。但谈薪的核心还是你能否证明自己有独立的项目落地能力。学历和论文在社招场景下权重没那么高，作品和深度才是王道。

6. 写在最后：我的几点真实体会

整个大模型应用落地方向，变化是真的快。我去年还在给人讲怎么用RAG搭知识库，今年很多场景已经在用Agent方式做了，工具链也从手动拼代码变成了Dify、Coze这类低代码平台。但有一些东西是不变的——对业务的理解、对数据的敬畏、对效果的死磕。

我自己的体会是，做这行最重要的能力是"定位问题"的能力。系统一旦效果不好，你要能快速判断问题出在数据、模型、检索还是Prompt，而不是东一榔头西一棒子地乱试。这个能力没有捷径，只能在一次次真实项目的bad case里磨出来。

最后给准备入行或转岗的朋友一个建议：不要只看教程，一定要自己动手做一遍。哪怕做个最简单的知识库问答，亲手把Ollama部署起来、把文档喂进去、把问题跑出来，你对这个领域的理解就能超过只看文章的人一大截。国内大模型的发展速度摆在这里，应用落地的人才需求还会持续旺盛。把这篇文章里的基础打牢，你就已经在正确的路上了。