求职指南 · 转行大模型指南
大模型应用开发岗一天在做什么?细分岗位画像
大模型应用开发不是一个岗位,而是一组围绕“把模型用起来”的岗位:RAG 工程、Agent 开发、推理部署/LLMOps、应用算法都会被写成类似 JD。选方向时不要只看标题,要看日常任务、项目证据和面试题模块是否匹配你的背景。
作者:吴师兄 | 适合:看 JD 看晕、不知道自己该投哪类大模型岗位的人 | 前置:知道 RAG、Agent、微调、推理部署的基本含义
招聘软件里“大模型应用工程师”“LLM 工程师”“AI 应用开发”“大模型算法工程师”这些名字经常混着用。同一个标题,在不同公司可能对应四类工作:
学习内容与项目面试，在同一条路上。
所以读 JD 时不要先问“岗位名是不是高级”,要先问“它每天解决什么问题”。下面按真实工作形态拆。
| 岗位类型 | 一句话解释 | 日常任务 | 更适合谁 | 面试高频模块 |
|---|---|---|---|---|
| RAG 工程 | 让模型基于企业资料回答问题 | 文档处理、切块、Embedding、检索、重排、引用、评估 | 后端、数据、企业系统、知识库项目背景 | RAG 基础、向量检索、重排与优化 |
| Agent 开发 | 让模型调用工具完成多步任务 | 工具 schema、任务规划、状态机、记忆、异常兜底 | 后端、全栈、自动化、研发工具背景 | Agent、Prompt 工程 |
| 推理部署/LLMOps | 让模型服务稳定、便宜、跑得快 | 模型服务、并发、显存、KV Cache、监控、灰度 | 后端、SRE、平台工程、基础架构背景 | 推理优化、模型架构 |
| 应用算法/微调 | 让模型更适合某个场景 | 数据构造、SFT/LoRA、评估、偏好数据、实验对比 | 算法、研究生、做过训练或评估的人 | 模型微调、RLHF 与对齐 |
这四类不是互斥的。一个小团队里,同一个人可能既做 RAG,又写 Agent,还要管评估和部署。转行准备时可以先选一个主战场,但要知道旁边三块会被追问。
RAG 工程的日常不是“把文档丢进向量库”这么简单。真实工作更像一条数据和系统管线:
| 时间片 | 可能在做的事 | 面试会怎么追问 |
|---|---|---|
| 上午 | 看用户 badcase:为什么这道制度题答错了 | 是没召回、召回了没用、还是模型编了? |
| 中午 | 调切块策略和 Embedding 选型 | chunk size 为什么这么设? overlap 怎么定? |
| 下午 | 加混合检索、重排或 Query 改写 | BM25 和向量检索怎么融合? RRF 的 k 怎么解释? |
| 晚些 | 做评估集和错误分类 | Recall@k、MRR、答案正确率怎么量化? |
| 发布前 | 加引用溯源、拒答、权限过滤 | 没依据时怎么拒答? 不同用户能不能看到同一份文档? |
RAG 很适合后端转型,因为它一半是数据管线和服务系统,一半是模型行为。站内的RAG 智能问答系统就是按这个链路设计的:从文档处理到检索、重排、记忆、引用、评估一步步补齐。
如果你简历里只有“基于 LangChain 搭建知识库问答”,会很薄。把它升级成“构建保险知识库 RAG,通过切块策略、混合检索和重排将召回质量从错误样例中逐步修正,并支持引用溯源和离线评估”,面试空间就完全不同。
Agent 开发的核心不是让模型“更聪明”,而是给模型设计可控的行动环境。它每天会碰到三类问题:
| 问题 | 典型场景 | 工程关键点 |
|---|---|---|
| 工具怎么暴露 | 搜索、数据库、代码执行、工单系统 | schema 清晰、权限边界、参数校验 |
| 任务怎么推进 | 多步搜索、调研报告、自动排障 | 状态机、ReAct、记忆、终止条件 |
| 失控怎么兜底 | 循环调用、成本过高、误操作 | 步数限制、人工确认、超时、审计 |
Agent 岗很容易被写得很炫,但面试追问通常很朴素:工具调用失败怎么办? 模型胡乱传参怎么办? 长任务上下文爆了怎么办? 什么时候让模型决定,什么时候写死流程?
如果你想走这类岗位,建议用Deep Research Agent做项目样本。它不是“会聊天的机器人”,而是搜索、阅读、反思、生成带引用报告的长程任务系统,更接近面试官会问的工程问题。
推理部署/LLMOps 更像后端基础架构和模型服务的交叉岗位。它关心的是“模型已经选好了,怎么让它稳定、可观测、可扩展地服务业务”。
常见任务包括:
后端和 SRE 背景在这个方向很有优势,但也要补模型推理直觉。比如 P99 延迟升高时,你不能只看服务 CPU,还要知道输入长度、输出长度、并发和 KV Cache 都会影响显存压力。
应用算法/微调介于纯算法和应用开发之间。它不是从零训基座模型,更常见的是围绕业务场景做数据、微调和评估:
| 任务 | 真实问题 | 面试会看什么 |
|---|---|---|
| LoRA/SFT | 模型语气、格式、工具调用不稳定 | 数据怎么构造,为什么不用 Prompt 解决 |
| 偏好数据 | 两个答案哪个更好 | 标注规范、DPO/RLHF/GRPO 基本理解 |
| 评估体系 | 模型改了到底有没有变好 | 指标、评估集、人工复核、线上反馈 |
| 失败样例分析 | 为什么新模型某些场景退化 | 数据覆盖、过拟合、灾难性遗忘 |
研究生和算法背景更容易切这个方向。后端同学也能靠应用项目逐步靠近,但不建议一开始就把自己包装成微调专家。先讲清 RAG/Agent 场景,再说明你理解什么时候需要微调,会更可信。
| JD 关键词 | 更可能是哪类岗位 | 你该准备什么 |
|---|---|---|
| 知识库、问答、向量库、检索、引用 | RAG 工程 | RAG 项目、检索/重排/评估题 |
| Agent、工具调用、工作流、自动化、MCP | Agent 开发 | Deep Research 或最小 Agent 项目 |
| vLLM、SGLang、推理、显存、并发、部署 | 推理部署/LLMOps | 推理优化、后端稳定性案例 |
| SFT、LoRA、DPO、RLHF、评测、数据构造 | 应用算法/微调 | 微调基础、评估、训练数据理解 |
| 业务系统、客服、办公、金融、企业知识 | 应用落地综合岗 | RAG/Agent + 后端经验 + 业务表达 |
如果一个 JD 里四类关键词都有,优先看“任职要求”和“加分项”的位置。写在第一二条的是真核心,写在最后的往往是加分。
研一/研二可以用“主线 + 加分线”选:主线选 RAG 或 Agent,因为最容易做出项目和实习成果;加分线根据实验室或课程背景选微调、评估、多模态。不要一开始就把四类岗位全投,那样简历会没有焦点。
3 年 Java/后端建议先从 RAG 工程、Agent 开发、推理部署里选一个。RAG 最容易把数据管线、接口、权限、评估讲清楚;Agent 更适合做过流程自动化、研发平台或工具系统的人;推理部署适合偏平台、SRE、性能优化的人。
不是。RAG 是最常见入口之一,但应用岗还包括 Agent、推理部署、评估平台、应用算法等方向。RAG 适合作为多数人的第一个深项目。
不能简单比较。Agent 更贴近复杂自动化,但工程不确定性也更高;RAG 更成熟、更容易落地。先选能做深、能讲透、能匹配 JD 的方向。
优先看 RAG 工程、Agent 开发和推理部署/LLMOps。这三类都能复用服务化、数据处理、并发和稳定性经验。
如果没有论文和训练项目,先用应用项目冲应用岗和应用算法岗。算法岗可以投,但不要把全部筹码压在纯算法筛选上。
看 JD 是否包含模型调用、RAG/Agent、评估、推理部署、微调等真实链路,再看面试是否追问项目和模型行为。只写“AI 赋能”但没有技术链路的要谨慎。