聊到“大模型技术链路”很多刚接触这个方向的朋友第一反应是这不就是调库、调接口、再套一层问答逻辑吗实际在企业里跑通一个真正能上线的大模型产品是一条贯穿数据加工、模型训练、推理部署、应用工程与效果评测的长链路。大厂之所以能快速推出AI产品核心不是某个算法工程师特别牛而是整条链路上每个环节都有专人负责、有明确的分工和流程。这篇文章我打算把这条链路拆开讲清楚顺带聊聊大厂AI团队的岗位配置最后给你一套小白也能直接上手的收藏整理方法让“收藏夹吃灰”变成“收藏即复用”。1. 先看懂完整技术链路从数据到应用的四段旅程1.1 数据侧模型效果的天花板其实在这里我见过太多人拿到开源模型权重就直接部署跑起来发现效果很差第一反应是“模型不行换更大的”。但真正的问题往往出在数据。大模型这条链路里数据决定上限训练决定下限推理决定成本应用决定价值。先说数据。企业在做模型时不会只用网上爬来的通用文本更多是自己业务场景里的真实数据。比如做一个客服机器人需要把历史客服对话、故障文档、产品手册、售后政策整理成结构化的问答对。这里有一个关键认知指令微调阶段也就是大家常说的SFT本质上是教模型“学会怎么组织回答”而不是教它“知识”。知识主要来自预训练阶段和检索增强后面会讲RAG。所以如果你给的问答对本身有错、有歧义、逻辑不自洽模型学得越多反而越糊涂。我做过一个比较典型的实验同样一个开源底座模型只用3000条高质量问答对做微调回答质量和稳定性明显优于用20000条从各种杂七杂八文档里硬凑出来的数据集。数据质量的重要性再怎么强调都不为过。1.2 训练侧预训练、微调、偏好对齐各自的职责训练不是一个动作而是分阶段的一组动作。预训练是在海量文本上学习语言规律和知识成本极高需要几千张显卡跑几个月这不是一般团队做得起的。企业通常直接采用社区开源底座模型把预训练这个环节跳过。SFT微调是用“问题—标准答案”这类有监督数据让模型学会特定场景的回答风格。参数上有一些常见的经验值学习率一般取1e-5到2e-5LoRA的rank通常在8到64之间训练数据量在几千到几万条之间。为什么rank不能盲目放大rank太大可训练参数多了在小数据量下容易过拟合rank太小模型学不进去效果不明显。偏好对齐是把“好坏偏好”教给模型。常见做法是让模型对同一个问题生成多个回答人工或规则排序然后通过强化学习方式让模型学会优选那些排名靠前的回答风格。这个阶段解决的是“模型能力不差但回答风格不讨喜”的问题比如语气太生硬、拒绝太多、回答过于啰嗦。1.3 推理侧部署一个能用的模型并不简单训练完之后模型要对外提供服务这一步叫推理部署。很多人觉得“模型都训好了部署不就是起个服务吗”实际上推理侧优化在大厂是一个非常独立的工种。先说显存估算。一个70B参数规模的模型如果用BF16精度存储权重光是权重就要占大约140GB显存。单张80GB的卡放不下需要多卡并行。这还只是权重实际推断过程中还有KV Cache这个缓存的大小和序列长度成正比。如果把上下文从2K扩到32KKV Cache会增长约16倍。这也是为什么大厂在长文本场景下要做各种KV Cache压缩、量化、淘汰策略。现在的通用做法是引入专门的推理引擎来提升吞吐和降低延迟。它们的核心思路是类似分页机制把显存碎片利用起来同时把解码过程拆成两个阶段分别优化。原理细节不展开但你需要记住一个结论模型权重能装下不等于服务能稳定跑起来。线上并发一上来显存、带宽、时延都会暴露问题。1.4 应用与评测产品好用才是终点模型部署好还没有结束要跟业务系统结合起来才算完成。这里有两个绕不开的概念RAG和Agent。RAG检索增强生成核心是“先从知识库里检索出相关内容再把内容塞给模型作为参考让模型基于参考作答”。它能解决两个问题一是模型知识截止时间的问题二是幻觉问题。业务知识不断更新时最优做法不是频繁重训模型而是更新知识库。Agent则是把复杂任务拆成多步执行。比如用户问“帮我对比这三款套餐并推荐一个”模型可能要先去查询套餐参数再按用户条件筛选最后生成推荐理由。每一步都可以调用外部工具。评测是最后一个必须重视的环节。上线前跑自动化评测集上线后持续回归防止模型优化了一个指标、却在另一个指标上崩塌。大厂内部通常会维护几百到几千条评测样本覆盖准确性、忠实度、完整性、格式遵循等多个维度。评测集不是一次性的它是模型的“考试大纲”。2. 大厂AI团队的岗位配置不止是一个“算法岗”2.1 岗位全景每条链路都有专门角色很多人想象的大厂AI团队是“一堆算法工程师天天调模型”实际完全不是这样。大模型从训练到上线涉及的岗位远远超出算法本身。我按实际项目经验整理了一份典型岗位表岗位方向核心职责技术落点算法工程师模型选型、微调、效果优化LoRA、全参微调、偏好对齐AI基础设施工程师训练集群、存储、网络调度GPU调度、分布式训练框架数据工程师数据清洗、构造、质检数据流水线、规则脚本MLOps/平台工程师模型版本管理、自动训练流程流水线编排、CI/CD推理性能工程师量化、推理引擎优化、高并发显存优化、缓存策略应用开发工程师API服务、业务系统对接服务编写、RAG、Agent产品经理场景定义、体验标准、反馈闭环需求分析、上线决策测试与评测工程师评测集构建、回归测试自动化评测、结果分析你会发现纯算法岗位只是其中一环而且往往不是人数最多的。一个稳定的大模型产品数据工程师和推理性能工程师的工作量常常被低估。2.2 一个虚拟项目的团队分工样例我给一个常见配置做参考。某企业内部知识问答项目20人左右的团队算法工程师4人数据工程师3人推理性能工程师2人MLOps平台工程师2人后端开发4人前端开发2人产品经理2人测试评测1人。为什么算法只有4个人因为底座模型是开源的核心工作是把数据质量做好、把评测集建好、把prompt调好。真正拖慢项目进度的往往是数据管道不稳定、推理服务在大并发下崩溃这类工程问题。算法调模型可能是几天就能出结果的事但数据清洗和评测回归是持续整个项目生命周期的事。这个配置还有一个特点每一道环节都有交叉评审。算法调整后必须跑一遍评测回归由测试评测岗位确认没有副作用推理性能工程师优化模型后要由后端接入线上再看看有没有接口超时。任何一个环节单独看起来都不是“顶尖技术”但合在一起就是壁垒。2.3 小团队和个人如何轻量化复刻这套配置如果你是个人开发者或小团队不可能按20人的配置去做。但思路可以复用先想清楚数据从哪来、评测怎么定义、模型怎么上线。个人实操时底座模型优先选社区开源权重微调用LoRA部署可直接使用主流的推理引擎评测用脚本维护一个精简测试集。说白了个人能外包的环节尽量外包。比如不训练底座模型用开源权重不走复杂的分布式训练用单卡加LoRA不自己写推理框架用现成引擎。最不该省的两个环节一个是数据质量一个是评测集这两件事自己亲手做收益最大。3. 小白友好“收藏技巧”把知识攒成自己的技术资产3.1 收藏之前先定一个分类框架这个标题里的“收藏技巧”我是认认真真想讲点实操的。绝大多数人收藏内容是看到一个好链接就扔进收藏夹三个月后打开收藏夹面对几百条内容毫无头绪。正确做法是收藏之前先建立一个大类的框架。对大模型领域我建议按技术链路来分类也就是顺着“数据—训练—推理—应用—评测”这五段去组织。每一条收藏进来之前先判断它属于哪个环节再放进去。举个例子你看到一篇讲“如何构造高质量指令数据”的文章就放进“数据”分组看到一篇讲“量化部署显存估算”的文章就放进“推理”分组。不要单独建“大模型干货”这种一个文件夹装所有的分类那等于没分类。3.2 “三遍收藏法”从收藏到内化光有分类还不够我建议采用“三遍收藏法”第一遍是快速扫读。收藏前先花两分钟扫一遍内容判断属于哪个环节值不值得收藏。不值得就直接关掉这一步能帮你砍掉一半的无效收藏。第二遍是重写。收藏后一周内用自己的话把这个资料的核心观点写在一页笔记上。不需要长篇大论两三句话即可比如“这篇文章讲了LoRA的rank对效果的影响建议8到32之间代码在xx库”。写不出来的说明没有真的看懂下来再去原文补一遍。第三遍是小项目验证。挑一个迷你任务验证学到的内容不一定非要跑到服务器上训练可以写一个评测脚本或者用一个小数据集跑一次LoRA微调。做过的知识才真正属于你。这个方法的本质是把“收藏”从被动囤积变成主动输入。我实测下来收藏夹从一百多条精简到十几条但每一条都知道在哪个环节、能解决问题使用率高了不少。3.3 一份可以直接抄的“按链路收藏清单”下面这份清单是我个人建议小白优先收集的内容类型你可以按这个方向去扩展链路环节值得收藏的内容类型收藏重点数据指令数据格式规范、清洗脚本模板问答对怎么写才规范、如何去重去噪训练学习率选择、LoRA参数设置指南各规模模型的经验参数、显存占用估算推理显存估算方法、量化方案对比权重、KV Cache、激活值如何计算应用RAG架构速查、Agent工具调用教程检索分块策略、工具定义写法评测评测集样例、人工评估标准表指标如何定义、边界case如何收集按这个链路去收集你会发现收藏的东西相互之间是有联系的而不是孤立的知识碎片。3.4 让收藏可以被检索做一个简单的资源表我建议所有重度学习者建一个简单的资源记录表字段不用多五列就够标题、所属链路环节、一句话摘要、是否已验证、备注。这个表比收藏夹更好用的地方在于它逼着你每次收藏都做一个判断。三个月后你想找“量化部署的资料”如果只是收藏夹里几百个链接你可能要翻很久但在表格里按“推理”环节过滤出来就是那几篇每个还带一句摘要效率完全不是一个量级。这算是我个人在大量收藏、大量踩坑之后摸索出最有效的一套方法了。4. 常见问题与避坑实录4.1 坑一模型选型盲目求大很多团队一上来就要用最大参数量模型觉得效果好。实际上模型越大部署成本、推理延迟、调优难度都会同步上升。我在实际项目里的经验是6B到14B量级的模型配合精心整理的业务数据和评测集在垂直场景里效果完全不输更大的模型但成本低得多。选型逻辑我建议这样做如果只是知识问答场景优先考虑RAG加一个小模型如果希望模型严格遵循复杂的指令格式再做SFT微调如果场景需要复杂的逻辑推理那时再考虑切换更大的模型。大模型是最后的选择不是第一选择。4.2 坑二微调之后效果不升反降微调后效果变差八成是数据有问题。最常见的是数据重复度过高模型反复看同样的内容会出现类似“复读机”的现象。其次是问答对里的回答不符合规范比如又长又啰嗦、或掺杂了过多语气词模型会把这种风格一并学过去。解决方案也很朴素微调前先做数据清洗算一下重复率人工抽样检查100条数据的质量不要在脏数据上花耐心调参。数据不对调参是白费功夫。4.3 坑三部署时显存爆掉部署阶段最容易出问题的是显存预估不足。权重只是显存占用的一部分还包括KV Cache和激活值。建议先按权重、上下文长度、并发数一起估算再预留约20%的余量。如果实在塞不下优先考虑量化比如从BF16压到8bit或4bit单卡能容纳的模型规模会大很多。对内部工具和轻量场景来说量化带来的质量损耗往往可接受。4.4 坑四评测只看“看起来对”“看起来对”和“稳定对”是两回事。同一个问题换几个问法就答偏了这种问题在人工抽查时很容易漏掉。建议建立三个维度的评测项幻觉检测看回答是否忠实于给定材料拒答率检测统计模型拒绝回答的比例是否异常指令遵循检测用规则去匹配格式要求是否满足。评测集不需要一开始就很大先维护50到100条高质量样本再逐步扩充重点是覆盖业务里的边界场景而不是追求数量。4.5 坑五盲目追求超长上下文上下文越长KV Cache占用越大推理成本基本线性上升。很多人为了“让模型读完整份文档”直接把上下文调到几十K结果单卡根本跑不动。实际操作中更好的顺序是先做内容截断和检索只把与问题相关的片段塞进上下文不够用再优化检索策略最后实在不行才考虑提升上下文长度。这条路是性价比最高的。我自己带项目的体感是真正拉开差距的不是谁代码写得花哨而是数据洁癖和评测习惯。数据不干净什么模型来了都白搭评测不系统改好一个指标却崩了另一个自己还浑然不觉。最后再分享一个小技巧每次准备收藏任何资料先问自己一句“这个资料能帮我解决技术链路中哪个环节的问题”答不上来就直接不收藏。这个习惯帮我节省了巨量时间收藏夹里的内容从一百多条减到十几条但每一条都在实际项目中用上了这才是“收藏”该有的样子。