这两年我经常被同一类问题问到现在学 AI 大模型工程师还来不来得及2026 年这岗位会不会被工具化浪潮直接冲垮我自己的回答是会被取代的是那些只会把几个 API 拼在一起的人不会被取代的是能拆解模型能力、把它接进真实业务流程还能控制成本和风险的人。这也是“AI 大模型工程师”这个 title 越来越被人事写进 JD 的原因。它不是算法研究员不是纯后端开发也不是写提示词的“调包侠”。它是夹在模型与业务之间的那层人既要知道模型能干什么、不能干什么又要把它变成稳定、可上线、能评估的系统。下面这篇文章我不谈空泛的“未来趋势”只讲 2026 年这个岗位真正要求的东西以及从本地部署、微调到 RAG、Agent 的实操思路。1. 先搞明白2026 年的 AI 大模型工程师到底在解决什么问题1.1 角色定位已经变了不再是“调包侠”2024 年以前打开招聘软件搜“大模型”一半岗位写的是提示词优化、Agent demo另一半写的是论文复现。到了 2026 年很多团队已经把算法研究员、AI 应用工程师、AI 平台工程师分开了。AI 大模型工程师既不属于纯算法也不属于纯后端而是站在中间那层的人知道模型能力边界善于把模型接进系统能在白盒和黑盒之间灵活切换。我用一个真实场景解释一下。企业要做内部知识库问答数据分布在飞书文档、本地 Word、数据库里员工提问时希望能基于这些内部资料回答并且回答必须带出处。这件事如果只靠在线大模型 API第一是数据外发合规上不好交代第二是问答准确率没法保证第三是知识更新一次就要重新准备一次上下文。所以现实做法是用本地向量库做检索再用大模型做总结。这个链路涉及文本切分、向量化、召回、重排、提示词编排、流式返回、权限控制。每一环都不深但每一环出了问题最终答案质量都会崩。AI 大模型工程师的核心价值就是把这些环节串起来并且用工程手段保证它稳定。正因如此这个岗位对“全栈理解力”的要求往往比对单一算法深度的要求更高。你不需要从零训练一个模型但你得知道模型推理时吃什么资源微调时数据格式是什么上线后怎么监控指标。1.2 日常工作重心已经迁移到“模型可用性”现在的项目里我每天处理最多的问题不是“模型回答得对不对”而是“模型回答得稳不稳”。什么叫不稳同一道数学题温度调到 0.1 时连续问五次三次改了过程一次答案少了单位同一个客服场景用户把问题换个说法模型就开始自由发挥同一个知识库文档更新后旧答案还在引用过期内容。这些都是大模型落地时的常态问题也是 2026 年工程师必须承担的责任。我自己的总结是工作重心已经从“模型能力”迁移到“模型可用性”性能可用推理速度能不能撑住并发显存占用会不会抖动响应会不会超时。质量可用输出格式是不是稳定专业术语对不对有没有一本正经地胡说八道。成本可用私有化部署时 GPU 要买几张线上调用时 token 费用大概多少有没有办法用更小的模型解决 80% 的需求。流程可用模型要接入审批系统、工单系统、数据分析平台API 是不是兼容鉴权怎么做日志怎么留。这些问题的答案都不在最新的论文里而在真正的系统设计里。这也是为什么我不太建议新人一上来就埋头研究大模型原理更合理的路径是先把一个开源模型部署起来跑通一个端到端任务再反推需要补什么底层的知识。2. 大模型工程师要具备的核心能力我按重要程度排序2.1 模型部署与推理优化永远是基本功很多人低估了“把模型跑起来”这件事的复杂度。搞一个大模型 demo 确实不难难的是让它稳定承载业务流量。2026 年还在做 AI 应用的公司通常不会再满足于“在网页上聊天”。他们要做的是把模型能力变成 API给内部系统调用。这时候你至少要懂几种推理引擎的差异Ollama 适合本地开发和快速验证vLLM 适合高并发生产环境llama.cpp 生态适合在 CPU 或边缘设备上压榨性能。推理优化也不只是启动参数的问题。比如并发请求一多显存里的 KV Cache 会迅速膨胀上下文一长首 token 延迟和总延迟都会翻倍。很多刚上手的人以为“模型能跑起来就行”结果压测一上要么 OOM要么响应时间夸张。这些坑没有实际部署过几次是背不下来的。2.2 提示词和上下文工程依然值得花时间这两年有个反智说法“提示词会被 AI 淘汰”。实际情况恰恰相反模型越强越考验你把自己真实意图表达清楚的能力。提示词不是几句花哨话术而是一套上下文工程你需要设计系统指令约束角色设计 few-shot 示例约束格式设计后处理校验输出设计多轮记忆的裁剪策略。在很多团队里模型回答跑偏最后排查下来不是模型不行而是上下文设计有问题。举个常见的例子。让大模型从合同里抽取字段很多人只写一句“请帮我抽取甲方、乙方和金额”结果模型输出一会儿用 JSON一会儿用 Markdown 表格。正确做法是在提示词里给一个明确的 JSON Schema加一条“无法抽取的字段输出 null”的约束然后在代码层再做一次 JSON 解析解析失败就用正则补偿。这种细节看起来不起眼但决定了一个功能能不能交付给业务方。2.3 RAG 和 Agent 是应用层的主战场大模型落地无非两条主线一条是把外部知识接进来叫 RAG另一条是让模型调用工具完成任务叫 Agent。RAG 解决的问题很简单模型没学过你的内部数据你不能每次把几千页文档塞进上下文所以要先检索再回答。但 RAG 工程化绝不简单切分粒度、向量模型选择、检索策略、重排模型、引用溯源都是调优空间。Agent 进一步把模型从“回答问题”提升到“完成任务”。典型场景是用户说“帮我查一下上个月各个区域的销售额并生成对比图表”。大模型需要自己决定调用哪个查数工具、拿到结果后怎么写分析结论、最后调用哪个画图接口。这里真正难的不是让模型说“我要调用工具”而是把工具清单、参数约束、错误重试设计得足够清晰否则 Agent 会陷入死循环。2.4 微调是进阶项不是刚起步就必学我见过太多人一上来就学微调花大量时间调参最后做出来的模型效果还不如直接用好一点的基座模型加提示词。这是方向错了。微调的正确使用场景是你需要模型稳定输出某种风格或格式或者需要它掌握特定领域的术语与规则而提示词和 RAG 都搞不定。比如让模型固定生成客服话术要求不能出现“我猜”“可能”这类模糊词或者让模型从法律文书中按固定结构抽取信息。这种时候LoRA 这类参数高效微调技术才值得上。2.5 评估能力才是拉开差距的地方2026 年的 AI 大模型工程师必须比上一代开发工程师更懂“测试”。因为传统软件的输入是确定的输出是可以断言的大模型生成的文本却每次都不一样你没法用 assertEquals 来验收。你需要会搭建评估集。比如一个客服问答系统先准备几百条真实提问标注标准答案或参考答案然后每次迭代模型或改提示词都跑一遍同样的评估集对比命中率、拒答率、格式正确率。没有这套机制你改了一个 Prompt到底是变好了还是变坏了全靠感觉。3. 完整实操把一个大模型接到业务系统里3.1 选模型前先算清楚显存账2026 年开源模型的格局肯定还会变但选型逻辑不变不是模型越大越好而是你的 GPU 显存、业务延迟和效果要求能匹配。我做项目时习惯先算一笔显存账。模型显存占用有几个部分参数本身占大头推理时的 KV Cache 和激活值占另一部分如果是训练或微调还要算上梯度和优化器状态。用常见模型规模举个例子模型规模精度参数量占显存估算搭配的最低显存建议7B / 8BBF16约 14~16 GB单卡 24 GB 可以流畅推理7B / 8BINT4 量化约 5~6 GB单卡 16 GB 甚至 12 GB 可跑14BBF16约 28~32 GB单卡 48 GB 或双卡 24 GB14BINT4 量化约 10~12 GB单卡 24 GB 稳妥32BBF16约 64~70 GB双卡 48 GB 或更高32BINT4 量化约 20~24 GB单卡 48 GB 或双卡 24 GB这只是个粗略估算。KV Cache 的大小还和并发数、上下文长度直接相关。上下文越长KV Cache 占用越大这一点很容易被忽略。所以做技术方案时不要只看“模型能在某张卡上启动”还要看“并发 20 路、每路 8K 上下文时还能不能撑住”。3.2 先用 Ollama 快速验证再用 vLLM 接生产本地部署的开胃菜我建议从 Ollama 开始。它把模型下载、运行、暴露 API 这几件事封装得非常简单特别适合验证模型效果。装好 Ollama 之后命令行里拉取模型就能直接跑# 拉取并运行一个 14B 级别模型具体名称以实际仓库为准 ollama run qwen2.5:14b运行起来后它会默认监听本机的 11434 端口同时提供一个兼容 OpenAI 格式的接口。你可以在应用代码里直接请求from openai import OpenAI client OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama, ) resp client.chat.completions.create( modelqwen2.5:14b, messages[ {role: system, content: 你是客服助手请简短回答。}, {role: user, content: 如何修改登录密码}, ], temperature0.2, ) print(resp.choices[0].message.content)这套代码和调用云端 API 的写法几乎没有区别。好处是你在本地验证过的 Prompt 和业务代码以后想切换到其他服务只需要改 base_url。但 Ollama 在高并发生产场景下不是最优解。当并发请求上来Ollama 的调度策略和吞吐控制不如专门的推理引擎精细。所以生产环境我通常用 vLLM它对连续批处理和 PagedAttention 的优化更成熟吞吐量明显更高。vllm serve Qwen/Qwen2.5-14B-Instruct \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9启动之后它会提供一个/v1/chat/completions接口应用代码依然可以沿用上面的 OpenAI SDK只换 base_url。这就是为什么我一直强调要尽早把自己的业务代码封装成“对接 OpenAI 兼容协议”的形式。模型是你随时可能替换的组件但接口层保持稳定系统才不会频繁返工。3.3 输出规范化和多轮记忆才是工程难点很多人以为部署完模型就大功告成实际上只完成了第一步。接业务时你还要处理两个让人头大的问题模型输出格式不稳定、多轮对话记忆不可控。先说输出格式。前几天有个项目需要模型从客服对话里抽“客户诉求”和“紧急程度”我让模型返回 JSON。结果线上日志里出现了三种情况正常 JSON、被 Markdown 代码块包裹的 JSON、以及夹杂了额外解释文字的 JSON。前端一解析就报错。处理方式不是赌模型每次都乖而是做三层防御第一层在系统提示词里明确输出 Schema并给一个标准示例。第二层在后端代码里先把返回内容里的 Markdown 代码块剥掉再用json.loads解析。第三层若解析失败把错误信息重新喂给模型让它修正一次。这种事情看起来琐碎可生产环境里 80% 的“模型不行”问题其实都出在这类工程细节上。至于多轮记忆我的建议是别把整段历史都丢给模型。要设计一个摘要 关键信息的机制对话太长了就把早期内容压缩成摘要再拼上最近几轮原始对话。4. 从 RAG 到 Agent应用侧真正的两条增长曲线4.1 RAG 不是简单“连一个向量库”RAG 这个概念流行了这么久可很多团队做出来的效果依然不行。最常见的原因是只做了“文档切块-向量化-相似度检索”的最小闭环然后发现模型回答得牛头不对马嘴。RAG 工程化的核心我认为不是向量检索本身而是对源头内容和召回结果的理解。第一文档切分策略要跟着内容结构走。不是所有文档都适合固定按 500 字切代码文档要按函数或模块切规章制度要按条款切产品说明书要按章节切。切得太碎语义不完整切得太大向量检索的准确性下降还更容易把无关信息带进来。第二召回不能只靠向量相似度。现在主流做法是多路召回向量检索算一路关键词检索算一路有条件的话再加一路基于规则或基于业务标签的召回最后用重排模型对多路结果统一排序。只靠向量距离对专有名词、编号、型号这类信息特别容易失灵因为向量模型没学过这个企业的黑话。第三回答的引用溯源必须做。企业内部用 RAG最忌讳的是模型一本正经地篡改事实。我会在提示词里要求模型“只依据提供的资料回答资料中没有的信息就明确说不知道”并且在返回结果里带上命中的文档 ID。这样用户能看到答案出处排查问题时也能定位到是检索错了还是生成错了。4.2 Agent 的难点不是模型而是工具边界很多人对 Agent 的理解是“让大模型自己规划步骤”。没错模型确实能规划但现实系统不能只靠模型一张嘴。真正落地的 Agent通常会拆成几个层次任务规划层大模型决定要做什么、按什么顺序做。工具层把业务系统封装成一个个可被调用的函数比如查库存、发工单、查天气。执行层代码按模型的规划去调用工具并把执行结果回传给模型。边界控制层设置最大循环次数、超时时间、敏感操作二次确认。我举个简单例子。做一个内部“数据问答助手”用户问“华东区上个月退货率最高的三个品类是什么”Agent 的链路是先判断需要查数据库然后生成 SQL执行后拿到结果再生成分析结论。模型一旦生成错误 SQL执行层要么拒绝要么把报错信息返回给它重试。但要注意重试不能无限循环我会加一个最大尝试次数超过就返回“当前无法完成查询”。工具说明的撰写也非常重要。给模型提供工具时每个工具的 description 要写清楚“这个工具能查到什么、参数有什么限制”。因为模型是靠描述来选工具的工具描述写得含糊Agent 就会经常用错工具。4.3 评估集是应用迭代的仪表盘我为什么一直强调评估因为大模型应用和传统程序不一样它没有“编译通过就上线”这种安全感。你改了 Prompt改了切分参数改了重排模型看起来都对但实际回答质量可能已经悄悄变差了。所以我会建议每一个认真做 AI 应用的人都建一个“回归评估集”。具体操作不复杂整理 100 到 300 条真实用户问题尽量覆盖各种问法。每条问题标注标准答案或至少标注“期望回答包含的关键点”。每次改动系统后跑一遍这套问题人工或调用一个大模型来对结果打分。记录每次改动的分数低于阈值的改动直接回滚。有了评估集讨论就不再是“我觉得模型变好了”而是“这一版在 200 条测试集上的准确率从 82% 升到了 86%”。虽然大模型输出有随机性但至少你能用数据把迭代方向稳住。5. 大模型微调实战从数据到 GPU 训练我踩过的坑5.1 数据质量决定微调上限要聊微调先得把一件事说透微调不是在“教会模型新知识”更多时候是在“对齐模型的输出风格和行为”。很多技术文章会告诉你 LoRA 怎么配、学习率设多少却很少有人强调90% 的微调失败问题都出在数据上。你需要做一份适合指令微调的数据集。单条数据至少包含三个部分指令或用户问题、期望模型输出必要的时候还要加一个上下文。数据不是越多越好早期用几百条高质量样本往往比几万条从网上爬来的垃圾数据更有效。数据清洗里有个特别容易被忽视的细节剪掉“模型不该学的东西”。比如你手工写了几十条回答每条都以“作为 AI 助手”开头模型学习后很可能每次回答都带上这句废话。还有如果你的数据里大量出现“好的我来帮你”那模型也会越来越啰嗦。我的经验是数据要人工逐条看一遍比让程序跑一遍清洗脚本重要。因为只有人才能发现“这条回答的语气和其他条不一致”“这条事实写错了”“这条指令和答案不对应”。5.2 用 LoRA 微调的完整套路LoRA 是目前做微调时最常用的手段。它不改变原始模型的全部参数只训练一部分低秩矩阵显存占用小训练速度快效果在很多场景下也够用。用 Hugging Face 的 PEFT 库大致流程是这样先加载底座模型并把它量化到更低精度以节省显存from transformers import AutoModelForCausalLM, AutoTokenizer from peft import LoraConfig, get_peft_model model_name Qwen/Qwen2.5-7B-Instruct model AutoModelForCausalLM.from_pretrained( model_name, load_in_4bitTrue, device_mapauto, ) tokenizer AutoTokenizer.from_pretrained(model_name)然后配置 LoRA 参数lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM, ) model get_peft_model(model, lora_config)接下来是训练。数据集用 Instruction 格式整理好每轮对话拼成一整段labels一般设置为输入序列本身让模型去预测每个 token。训练参数方面常见的选择是batch_size1 或 2 配合梯度累积learning_rate1e-4 到 2e-4num_epochs3 左右。训练完成后把 LoRA 权重单独保存model.save_pretrained(qwen-lora-output) tokenizer.save_pretrained(qwen-lora-output)推理时再把它加载到基础模型上。这样做的好处是你可以保留一个干净的底座模型针对不同业务场景训练不同 LoRA按需加载互不污染。5.3 微调踩坑实录过拟合和遗忘我自己最早做微调时犯过一个新手特别容易犯的错数据集只有几百条却训练了十几个 epoch。结果模型在训练样本上表现得完美无缺一到新句子就开始胡言乱语甚至把训练集里的专有名词原封不动地背出来。这本质上是过拟合。模型已经记住了答案而不是学会了规律。后来我把 epoch 降到 2 到 3并且刻意留出 10% 的数据不参与训练作为验证集。每次训练完都在验证集上看 loss。如果训练集 loss 一直降验证集 loss 却升上来了立刻停止训练。还有一个常见问题是灾难性遗忘。模型微调后业务想要的风格是学到了但通用能力反而退步了。比如你教它写营销文案它学会了但你再问它“一公里等于多少米”它开始答非所问。缓解办法有两个方向一是把一些通用问答样本混进训练数据里二是在微调之后做一次混合验证既看业务场景的效果也抽一批通用问题测试常识是否还在。如果发现遗忘严重就要降低学习率、减少训练步数或者重新调整业务数据与通用数据的比例。6. 给想入行的人学习路线和作品集建议6.1 按“四阶段”去推进别急着啃论文如果现在有人问我从零基础到胜任 AI 大模型工程师最短的学习路径是什么我会建议按下面四个阶段每一阶段都要有拿得出手的成果第一阶段是“会用”。学会调用各类云端模型 API把聊天补全、结构化输出、多轮对话做熟。这一阶段你至少能做出一到两个小应用比如翻译助手、客服问答机器人。第二阶段是“本地化”。学会下载开源模型用 Ollama 在本地跑起来再通过 OpenAI 兼容 API 接到自己的应用里。这一阶段你会真正理解模型资源消耗、上下文限制和推理延迟。第三阶段是“检索增强”。把 RAG 全链路做通包括文档切分、向量化、召回、重排、引用溯源。一个有价值的练习是做一个小型企业制度问答机器人要求回答必须带出处。第四阶段才是“微调和 Agent”。针对一个垂直场景准备数据用 LoRA 微调并尝试做带工具调用的 Agent。这两件事都会逼着你补很多系统知识比如显存管理、并发控制、结果评估。我在带新人时发现一个规律凡是能按这个顺序走下来的人后面学什么都很快一上来就卡在“Transformer 的注意力公式推导”里的人反而容易坚持不了。不是原理不重要而是你应该带着“为什么模型会这样”的问题去回头补原理效率会高得多。6.2 面试时一份“过程完整”的作品集比什么都管用最后聊几句求职和面试。AI 大模型工程师这个岗位面试官最怕听到的话就是“我跑过某某开源项目的 demo”。因为 demo 谁都能跑它证明不了你有独立的工程判断力。我建议作品集不要只放最终效果截图而是放一份完整的技术说明也就是把这几个问题讲清楚你选这个模型是基于什么资源条件和业务要求数据是怎么处理的清洗规则是什么为什么这么切分系统上线后遇到了什么问题你又是怎么定位并解决的有没有评估数据提示词或模型改完后效果变化是多少我见过一个候选人作品只是一个几千条数据的垂直领域客服机器人但他把微调数据清洗中的矛盾项、验收时发现的幻觉问题、以及最终怎么用检索兜底解决的过程讲得清清楚楚。这种作品集比那些“用大模型做了个聊天网站”的华而不实项目强太多了。如果你也想走这条路不妨现在就打开一个开源模型从部署一个最普通的问答机器人开始。过程中遇到的所有报错、OOM、格式漂移都是你未来面试里最有说服力的素材。真正把大模型当成工程来做而不是当成玩具来玩才算一只脚迈进了 2026 年 AI 大模型工程师这扇门。 AI大模型工程师实战：2026年核心技能与部署微调全攻略
这两年我经常被同一类问题问到现在学 AI 大模型工程师还来不来得及2026 年这岗位会不会被工具化浪潮直接冲垮我自己的回答是会被取代的是那些只会把几个 API 拼在一起的人不会被取代的是能拆解模型能力、把它接进真实业务流程还能控制成本和风险的人。这也是“AI 大模型工程师”这个 title 越来越被人事写进 JD 的原因。它不是算法研究员不是纯后端开发也不是写提示词的“调包侠”。它是夹在模型与业务之间的那层人既要知道模型能干什么、不能干什么又要把它变成稳定、可上线、能评估的系统。下面这篇文章我不谈空泛的“未来趋势”只讲 2026 年这个岗位真正要求的东西以及从本地部署、微调到 RAG、Agent 的实操思路。1. 先搞明白2026 年的 AI 大模型工程师到底在解决什么问题1.1 角色定位已经变了不再是“调包侠”2024 年以前打开招聘软件搜“大模型”一半岗位写的是提示词优化、Agent demo另一半写的是论文复现。到了 2026 年很多团队已经把算法研究员、AI 应用工程师、AI 平台工程师分开了。AI 大模型工程师既不属于纯算法也不属于纯后端而是站在中间那层的人知道模型能力边界善于把模型接进系统能在白盒和黑盒之间灵活切换。我用一个真实场景解释一下。企业要做内部知识库问答数据分布在飞书文档、本地 Word、数据库里员工提问时希望能基于这些内部资料回答并且回答必须带出处。这件事如果只靠在线大模型 API第一是数据外发合规上不好交代第二是问答准确率没法保证第三是知识更新一次就要重新准备一次上下文。所以现实做法是用本地向量库做检索再用大模型做总结。这个链路涉及文本切分、向量化、召回、重排、提示词编排、流式返回、权限控制。每一环都不深但每一环出了问题最终答案质量都会崩。AI 大模型工程师的核心价值就是把这些环节串起来并且用工程手段保证它稳定。正因如此这个岗位对“全栈理解力”的要求往往比对单一算法深度的要求更高。你不需要从零训练一个模型但你得知道模型推理时吃什么资源微调时数据格式是什么上线后怎么监控指标。1.2 日常工作重心已经迁移到“模型可用性”现在的项目里我每天处理最多的问题不是“模型回答得对不对”而是“模型回答得稳不稳”。什么叫不稳同一道数学题温度调到 0.1 时连续问五次三次改了过程一次答案少了单位同一个客服场景用户把问题换个说法模型就开始自由发挥同一个知识库文档更新后旧答案还在引用过期内容。这些都是大模型落地时的常态问题也是 2026 年工程师必须承担的责任。我自己的总结是工作重心已经从“模型能力”迁移到“模型可用性”性能可用推理速度能不能撑住并发显存占用会不会抖动响应会不会超时。质量可用输出格式是不是稳定专业术语对不对有没有一本正经地胡说八道。成本可用私有化部署时 GPU 要买几张线上调用时 token 费用大概多少有没有办法用更小的模型解决 80% 的需求。流程可用模型要接入审批系统、工单系统、数据分析平台API 是不是兼容鉴权怎么做日志怎么留。这些问题的答案都不在最新的论文里而在真正的系统设计里。这也是为什么我不太建议新人一上来就埋头研究大模型原理更合理的路径是先把一个开源模型部署起来跑通一个端到端任务再反推需要补什么底层的知识。2. 大模型工程师要具备的核心能力我按重要程度排序2.1 模型部署与推理优化永远是基本功很多人低估了“把模型跑起来”这件事的复杂度。搞一个大模型 demo 确实不难难的是让它稳定承载业务流量。2026 年还在做 AI 应用的公司通常不会再满足于“在网页上聊天”。他们要做的是把模型能力变成 API给内部系统调用。这时候你至少要懂几种推理引擎的差异Ollama 适合本地开发和快速验证vLLM 适合高并发生产环境llama.cpp 生态适合在 CPU 或边缘设备上压榨性能。推理优化也不只是启动参数的问题。比如并发请求一多显存里的 KV Cache 会迅速膨胀上下文一长首 token 延迟和总延迟都会翻倍。很多刚上手的人以为“模型能跑起来就行”结果压测一上要么 OOM要么响应时间夸张。这些坑没有实际部署过几次是背不下来的。2.2 提示词和上下文工程依然值得花时间这两年有个反智说法“提示词会被 AI 淘汰”。实际情况恰恰相反模型越强越考验你把自己真实意图表达清楚的能力。提示词不是几句花哨话术而是一套上下文工程你需要设计系统指令约束角色设计 few-shot 示例约束格式设计后处理校验输出设计多轮记忆的裁剪策略。在很多团队里模型回答跑偏最后排查下来不是模型不行而是上下文设计有问题。举个常见的例子。让大模型从合同里抽取字段很多人只写一句“请帮我抽取甲方、乙方和金额”结果模型输出一会儿用 JSON一会儿用 Markdown 表格。正确做法是在提示词里给一个明确的 JSON Schema加一条“无法抽取的字段输出 null”的约束然后在代码层再做一次 JSON 解析解析失败就用正则补偿。这种细节看起来不起眼但决定了一个功能能不能交付给业务方。2.3 RAG 和 Agent 是应用层的主战场大模型落地无非两条主线一条是把外部知识接进来叫 RAG另一条是让模型调用工具完成任务叫 Agent。RAG 解决的问题很简单模型没学过你的内部数据你不能每次把几千页文档塞进上下文所以要先检索再回答。但 RAG 工程化绝不简单切分粒度、向量模型选择、检索策略、重排模型、引用溯源都是调优空间。Agent 进一步把模型从“回答问题”提升到“完成任务”。典型场景是用户说“帮我查一下上个月各个区域的销售额并生成对比图表”。大模型需要自己决定调用哪个查数工具、拿到结果后怎么写分析结论、最后调用哪个画图接口。这里真正难的不是让模型说“我要调用工具”而是把工具清单、参数约束、错误重试设计得足够清晰否则 Agent 会陷入死循环。2.4 微调是进阶项不是刚起步就必学我见过太多人一上来就学微调花大量时间调参最后做出来的模型效果还不如直接用好一点的基座模型加提示词。这是方向错了。微调的正确使用场景是你需要模型稳定输出某种风格或格式或者需要它掌握特定领域的术语与规则而提示词和 RAG 都搞不定。比如让模型固定生成客服话术要求不能出现“我猜”“可能”这类模糊词或者让模型从法律文书中按固定结构抽取信息。这种时候LoRA 这类参数高效微调技术才值得上。2.5 评估能力才是拉开差距的地方2026 年的 AI 大模型工程师必须比上一代开发工程师更懂“测试”。因为传统软件的输入是确定的输出是可以断言的大模型生成的文本却每次都不一样你没法用 assertEquals 来验收。你需要会搭建评估集。比如一个客服问答系统先准备几百条真实提问标注标准答案或参考答案然后每次迭代模型或改提示词都跑一遍同样的评估集对比命中率、拒答率、格式正确率。没有这套机制你改了一个 Prompt到底是变好了还是变坏了全靠感觉。3. 完整实操把一个大模型接到业务系统里3.1 选模型前先算清楚显存账2026 年开源模型的格局肯定还会变但选型逻辑不变不是模型越大越好而是你的 GPU 显存、业务延迟和效果要求能匹配。我做项目时习惯先算一笔显存账。模型显存占用有几个部分参数本身占大头推理时的 KV Cache 和激活值占另一部分如果是训练或微调还要算上梯度和优化器状态。用常见模型规模举个例子模型规模精度参数量占显存估算搭配的最低显存建议7B / 8BBF16约 14~16 GB单卡 24 GB 可以流畅推理7B / 8BINT4 量化约 5~6 GB单卡 16 GB 甚至 12 GB 可跑14BBF16约 28~32 GB单卡 48 GB 或双卡 24 GB14BINT4 量化约 10~12 GB单卡 24 GB 稳妥32BBF16约 64~70 GB双卡 48 GB 或更高32BINT4 量化约 20~24 GB单卡 48 GB 或双卡 24 GB这只是个粗略估算。KV Cache 的大小还和并发数、上下文长度直接相关。上下文越长KV Cache 占用越大这一点很容易被忽略。所以做技术方案时不要只看“模型能在某张卡上启动”还要看“并发 20 路、每路 8K 上下文时还能不能撑住”。3.2 先用 Ollama 快速验证再用 vLLM 接生产本地部署的开胃菜我建议从 Ollama 开始。它把模型下载、运行、暴露 API 这几件事封装得非常简单特别适合验证模型效果。装好 Ollama 之后命令行里拉取模型就能直接跑# 拉取并运行一个 14B 级别模型具体名称以实际仓库为准 ollama run qwen2.5:14b运行起来后它会默认监听本机的 11434 端口同时提供一个兼容 OpenAI 格式的接口。你可以在应用代码里直接请求from openai import OpenAI client OpenAI( base_urlhttp://localhost:11434/v1, api_keyollama, ) resp client.chat.completions.create( modelqwen2.5:14b, messages[ {role: system, content: 你是客服助手请简短回答。}, {role: user, content: 如何修改登录密码}, ], temperature0.2, ) print(resp.choices[0].message.content)这套代码和调用云端 API 的写法几乎没有区别。好处是你在本地验证过的 Prompt 和业务代码以后想切换到其他服务只需要改 base_url。但 Ollama 在高并发生产场景下不是最优解。当并发请求上来Ollama 的调度策略和吞吐控制不如专门的推理引擎精细。所以生产环境我通常用 vLLM它对连续批处理和 PagedAttention 的优化更成熟吞吐量明显更高。vllm serve Qwen/Qwen2.5-14B-Instruct \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9启动之后它会提供一个/v1/chat/completions接口应用代码依然可以沿用上面的 OpenAI SDK只换 base_url。这就是为什么我一直强调要尽早把自己的业务代码封装成“对接 OpenAI 兼容协议”的形式。模型是你随时可能替换的组件但接口层保持稳定系统才不会频繁返工。3.3 输出规范化和多轮记忆才是工程难点很多人以为部署完模型就大功告成实际上只完成了第一步。接业务时你还要处理两个让人头大的问题模型输出格式不稳定、多轮对话记忆不可控。先说输出格式。前几天有个项目需要模型从客服对话里抽“客户诉求”和“紧急程度”我让模型返回 JSON。结果线上日志里出现了三种情况正常 JSON、被 Markdown 代码块包裹的 JSON、以及夹杂了额外解释文字的 JSON。前端一解析就报错。处理方式不是赌模型每次都乖而是做三层防御第一层在系统提示词里明确输出 Schema并给一个标准示例。第二层在后端代码里先把返回内容里的 Markdown 代码块剥掉再用json.loads解析。第三层若解析失败把错误信息重新喂给模型让它修正一次。这种事情看起来琐碎可生产环境里 80% 的“模型不行”问题其实都出在这类工程细节上。至于多轮记忆我的建议是别把整段历史都丢给模型。要设计一个摘要 关键信息的机制对话太长了就把早期内容压缩成摘要再拼上最近几轮原始对话。4. 从 RAG 到 Agent应用侧真正的两条增长曲线4.1 RAG 不是简单“连一个向量库”RAG 这个概念流行了这么久可很多团队做出来的效果依然不行。最常见的原因是只做了“文档切块-向量化-相似度检索”的最小闭环然后发现模型回答得牛头不对马嘴。RAG 工程化的核心我认为不是向量检索本身而是对源头内容和召回结果的理解。第一文档切分策略要跟着内容结构走。不是所有文档都适合固定按 500 字切代码文档要按函数或模块切规章制度要按条款切产品说明书要按章节切。切得太碎语义不完整切得太大向量检索的准确性下降还更容易把无关信息带进来。第二召回不能只靠向量相似度。现在主流做法是多路召回向量检索算一路关键词检索算一路有条件的话再加一路基于规则或基于业务标签的召回最后用重排模型对多路结果统一排序。只靠向量距离对专有名词、编号、型号这类信息特别容易失灵因为向量模型没学过这个企业的黑话。第三回答的引用溯源必须做。企业内部用 RAG最忌讳的是模型一本正经地篡改事实。我会在提示词里要求模型“只依据提供的资料回答资料中没有的信息就明确说不知道”并且在返回结果里带上命中的文档 ID。这样用户能看到答案出处排查问题时也能定位到是检索错了还是生成错了。4.2 Agent 的难点不是模型而是工具边界很多人对 Agent 的理解是“让大模型自己规划步骤”。没错模型确实能规划但现实系统不能只靠模型一张嘴。真正落地的 Agent通常会拆成几个层次任务规划层大模型决定要做什么、按什么顺序做。工具层把业务系统封装成一个个可被调用的函数比如查库存、发工单、查天气。执行层代码按模型的规划去调用工具并把执行结果回传给模型。边界控制层设置最大循环次数、超时时间、敏感操作二次确认。我举个简单例子。做一个内部“数据问答助手”用户问“华东区上个月退货率最高的三个品类是什么”Agent 的链路是先判断需要查数据库然后生成 SQL执行后拿到结果再生成分析结论。模型一旦生成错误 SQL执行层要么拒绝要么把报错信息返回给它重试。但要注意重试不能无限循环我会加一个最大尝试次数超过就返回“当前无法完成查询”。工具说明的撰写也非常重要。给模型提供工具时每个工具的 description 要写清楚“这个工具能查到什么、参数有什么限制”。因为模型是靠描述来选工具的工具描述写得含糊Agent 就会经常用错工具。4.3 评估集是应用迭代的仪表盘我为什么一直强调评估因为大模型应用和传统程序不一样它没有“编译通过就上线”这种安全感。你改了 Prompt改了切分参数改了重排模型看起来都对但实际回答质量可能已经悄悄变差了。所以我会建议每一个认真做 AI 应用的人都建一个“回归评估集”。具体操作不复杂整理 100 到 300 条真实用户问题尽量覆盖各种问法。每条问题标注标准答案或至少标注“期望回答包含的关键点”。每次改动系统后跑一遍这套问题人工或调用一个大模型来对结果打分。记录每次改动的分数低于阈值的改动直接回滚。有了评估集讨论就不再是“我觉得模型变好了”而是“这一版在 200 条测试集上的准确率从 82% 升到了 86%”。虽然大模型输出有随机性但至少你能用数据把迭代方向稳住。5. 大模型微调实战从数据到 GPU 训练我踩过的坑5.1 数据质量决定微调上限要聊微调先得把一件事说透微调不是在“教会模型新知识”更多时候是在“对齐模型的输出风格和行为”。很多技术文章会告诉你 LoRA 怎么配、学习率设多少却很少有人强调90% 的微调失败问题都出在数据上。你需要做一份适合指令微调的数据集。单条数据至少包含三个部分指令或用户问题、期望模型输出必要的时候还要加一个上下文。数据不是越多越好早期用几百条高质量样本往往比几万条从网上爬来的垃圾数据更有效。数据清洗里有个特别容易被忽视的细节剪掉“模型不该学的东西”。比如你手工写了几十条回答每条都以“作为 AI 助手”开头模型学习后很可能每次回答都带上这句废话。还有如果你的数据里大量出现“好的我来帮你”那模型也会越来越啰嗦。我的经验是数据要人工逐条看一遍比让程序跑一遍清洗脚本重要。因为只有人才能发现“这条回答的语气和其他条不一致”“这条事实写错了”“这条指令和答案不对应”。5.2 用 LoRA 微调的完整套路LoRA 是目前做微调时最常用的手段。它不改变原始模型的全部参数只训练一部分低秩矩阵显存占用小训练速度快效果在很多场景下也够用。用 Hugging Face 的 PEFT 库大致流程是这样先加载底座模型并把它量化到更低精度以节省显存from transformers import AutoModelForCausalLM, AutoTokenizer from peft import LoraConfig, get_peft_model model_name Qwen/Qwen2.5-7B-Instruct model AutoModelForCausalLM.from_pretrained( model_name, load_in_4bitTrue, device_mapauto, ) tokenizer AutoTokenizer.from_pretrained(model_name)然后配置 LoRA 参数lora_config LoraConfig( r16, lora_alpha32, target_modules[q_proj, k_proj, v_proj, o_proj], lora_dropout0.05, biasnone, task_typeCAUSAL_LM, ) model get_peft_model(model, lora_config)接下来是训练。数据集用 Instruction 格式整理好每轮对话拼成一整段labels一般设置为输入序列本身让模型去预测每个 token。训练参数方面常见的选择是batch_size1 或 2 配合梯度累积learning_rate1e-4 到 2e-4num_epochs3 左右。训练完成后把 LoRA 权重单独保存model.save_pretrained(qwen-lora-output) tokenizer.save_pretrained(qwen-lora-output)推理时再把它加载到基础模型上。这样做的好处是你可以保留一个干净的底座模型针对不同业务场景训练不同 LoRA按需加载互不污染。5.3 微调踩坑实录过拟合和遗忘我自己最早做微调时犯过一个新手特别容易犯的错数据集只有几百条却训练了十几个 epoch。结果模型在训练样本上表现得完美无缺一到新句子就开始胡言乱语甚至把训练集里的专有名词原封不动地背出来。这本质上是过拟合。模型已经记住了答案而不是学会了规律。后来我把 epoch 降到 2 到 3并且刻意留出 10% 的数据不参与训练作为验证集。每次训练完都在验证集上看 loss。如果训练集 loss 一直降验证集 loss 却升上来了立刻停止训练。还有一个常见问题是灾难性遗忘。模型微调后业务想要的风格是学到了但通用能力反而退步了。比如你教它写营销文案它学会了但你再问它“一公里等于多少米”它开始答非所问。缓解办法有两个方向一是把一些通用问答样本混进训练数据里二是在微调之后做一次混合验证既看业务场景的效果也抽一批通用问题测试常识是否还在。如果发现遗忘严重就要降低学习率、减少训练步数或者重新调整业务数据与通用数据的比例。6. 给想入行的人学习路线和作品集建议6.1 按“四阶段”去推进别急着啃论文如果现在有人问我从零基础到胜任 AI 大模型工程师最短的学习路径是什么我会建议按下面四个阶段每一阶段都要有拿得出手的成果第一阶段是“会用”。学会调用各类云端模型 API把聊天补全、结构化输出、多轮对话做熟。这一阶段你至少能做出一到两个小应用比如翻译助手、客服问答机器人。第二阶段是“本地化”。学会下载开源模型用 Ollama 在本地跑起来再通过 OpenAI 兼容 API 接到自己的应用里。这一阶段你会真正理解模型资源消耗、上下文限制和推理延迟。第三阶段是“检索增强”。把 RAG 全链路做通包括文档切分、向量化、召回、重排、引用溯源。一个有价值的练习是做一个小型企业制度问答机器人要求回答必须带出处。第四阶段才是“微调和 Agent”。针对一个垂直场景准备数据用 LoRA 微调并尝试做带工具调用的 Agent。这两件事都会逼着你补很多系统知识比如显存管理、并发控制、结果评估。我在带新人时发现一个规律凡是能按这个顺序走下来的人后面学什么都很快一上来就卡在“Transformer 的注意力公式推导”里的人反而容易坚持不了。不是原理不重要而是你应该带着“为什么模型会这样”的问题去回头补原理效率会高得多。6.2 面试时一份“过程完整”的作品集比什么都管用最后聊几句求职和面试。AI 大模型工程师这个岗位面试官最怕听到的话就是“我跑过某某开源项目的 demo”。因为 demo 谁都能跑它证明不了你有独立的工程判断力。我建议作品集不要只放最终效果截图而是放一份完整的技术说明也就是把这几个问题讲清楚你选这个模型是基于什么资源条件和业务要求数据是怎么处理的清洗规则是什么为什么这么切分系统上线后遇到了什么问题你又是怎么定位并解决的有没有评估数据提示词或模型改完后效果变化是多少我见过一个候选人作品只是一个几千条数据的垂直领域客服机器人但他把微调数据清洗中的矛盾项、验收时发现的幻觉问题、以及最终怎么用检索兜底解决的过程讲得清清楚楚。这种作品集比那些“用大模型做了个聊天网站”的华而不实项目强太多了。如果你也想走这条路不妨现在就打开一个开源模型从部署一个最普通的问答机器人开始。过程中遇到的所有报错、OOM、格式漂移都是你未来面试里最有说服力的素材。真正把大模型当成工程来做而不是当成玩具来玩才算一只脚迈进了 2026 年 AI 大模型工程师这扇门。