如果你最近在看杭州的算法岗位会发现一个很明显的变化大模型应用落地方向的缺口比预训练、纯研究方向的缺口大得多。很多公司挂在招聘网站上的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.95vLLM的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显存A10080GB看着余量很大但一开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部署起来、把文档喂进去、把问题跑出来你对这个领域的理解就能超过只看文章的人一大截。国内大模型的发展速度摆在这里应用落地的人才需求还会持续旺盛。把这篇文章里的基础打牢你就已经在正确的路上了。 大模型应用落地实战：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.95vLLM的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显存A10080GB看着余量很大但一开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部署起来、把文档喂进去、把问题跑出来你对这个领域的理解就能超过只看文章的人一大截。国内大模型的发展速度摆在这里应用落地的人才需求还会持续旺盛。把这篇文章里的基础打牢你就已经在正确的路上了。