大模型应用开发岗一天在做什么？细分岗位画像

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