人工智能与数据
├── 数据工程侧（大数据开发／数据治理／BI 与可视化）
├── 数据洞察侧（数据分析师）
└── 模型与策略侧
├── 算法工程师
├── 机器学习工程（MLOps）
├── AI 应用与提示工程
│ └── 大模型应用工程 ← 本篇
└── 推荐与搜索算法
定位一句话：大模型应用工程师负责把大模型从"能对话"变成"能干活"——模型本身由上游提供，这个岗位负责的是能力接进生产系统的那一层工程：选哪个模型、怎么给它上下文与工具、什么时候需要微调、怎么把推理成本压到可接受、怎么证明它比上一版更可靠。
与同领域 AI 应用与提示工程的边界：两者高度相邻。区别在分工颗粒度——AI 应用与提示工程（见 L2-人工智能与数据-03-AI应用与提示工程|本篇相邻岗位页）更强调任务定义、提示迭代与评测；大模型应用工程更强调模型选型、微调、推理部署与成本治理这类"工程侧"的重活。小团队里通常由同一人身兼两职。
一句话定义：大模型应用工程师负责大模型的选型评估、微调与对齐、检索增强与工具编排、推理部署与成本优化、评测监控与迭代，交付物是稳定运行、效果可衡量、成本可控的模型应用系统。
这个岗位与算法研究岗的最大区别是约束条件完全不同：研究岗追求能力上限，应用岗必须在延迟、成本、稳定性、合规这四重约束下工作。一个在测试集上表现优异的大模型应用，可能因为一次接口超时、一次知识库更新、一次输出格式漂移而在生产上掉链子——所以应用岗的核心工程能力，落在评测与兜底设计上。
职责边界（五类日常）
一、模型选型与能力评估
在能力、上下文长度、推理成本、响应延迟、可部署性、数据合规之间做取舍（商用接口、开源自部署、混合方案）。
- 先做能力边界测试：把业务里最难、最容易出错的那批样本拿出来，逐模型对比，而不是只看公开榜单。
- 明确"哪些能交给模型、哪些必须走规则或人工"：涉及钱、承诺与合规判断的环节，通常只让模型做初筛或建议。
- 选型不是一次性的：模型迭代快，需要建立周期性重评机制，并把调用层封装好，让换模型的影响范围可控。
二、微调与对齐
判断什么时候需要微调，构建指令数据与偏好数据，设计训练与评估流程，防止能力退化与过拟合。
- 该考虑微调的典型信号：任务形态固定且要求严格的输出格式、需要稳定的业务风格、检索无法覆盖的领域表达习惯、或因上下文太长导致成本不可接受。
- 不必微调的典型情况：知识类问题（改知识库比改模型便宜得多）、需求还在频繁变化、缺乏高质量的领域数据。
- 成本要算全：训练只是开始，长期还有版本管理、效果回归与再训练。"微调容易、维护难"是这个环节最常见的低估点。
三、检索增强与工具编排
搭建知识库流水线（文档解析、切分、向量化、索引、召回与重排），设计多步流程与工具调用，处理长文档与多轮上下文管理。
- 失败模式最集中在这一层：检索没给对、上下文太长导致关键信息被淹没、工具调用失败没兜底。
- 排查要分层：先看"检索到没"，再看"给模型的上下文是否清晰"，最后才判断"模型是否真的不会"。
- 工具调用要有权限约束：可调用范围、参数校验、失败重试与幂等设计都要提前定，避免模型触发不该做的动作。
四、推理部署与成本优化
服务化与并发处理、量化与加速、缓存与批处理、模型分级路由、弹性伸缩与降级策略。
- 分级路由是性价比最高的一招：简单任务用小模型、复杂任务用大模型，能在效果基本不变的前提下显著降本。
- 缓存与去重：高频重复请求的结果可缓存；批量离线任务可用批处理降低成本。
- 降级策略：上游服务不可用时，返回什么、提示什么，必须提前设计，否则高峰期体验会直接崩塌。
- 业务方最终按单位成本看效果，因此成本优化是这个岗位的硬指标，而不是"顺手做的事"。
五、评测、监控与迭代
建设评测集与自动化回归、线上质量监控、合规与安全审查、版本管理与灰度发布。
- 没有评测就没有迭代：这是这个岗位最容易欠下的技术债，也是最难补回来的一个。
- 监控看两类：服务指标（延迟、错误率、超时率、成本）与质量指标（格式错误率、无依据回答率、人工修正率、用户反馈）。
- 合规方向性要求：敏感内容拦截、数据脱敏、提示注入防护属于设计前提；本篇不提供任何绕过安全机制的具体做法。
- 版本与灰度：模型、提示、知识库三者都要能独立回滚——这是排障效率的分水岭。
一个模型应用从立项到上线要过哪几关
- 场景可行性判断——这个任务模型能做到什么程度，边界在哪，达不到时人工怎么接；
- 做出能跑的最小版本——先打通链路，验证端到端是否成立，不追求效果；
- 建立评测基线——把当前版本的成绩记录下来，后续所有改动都与它比较；
- 迭代效果——按"检索 → 上下文 → 提示 → 模型 → 微调"的顺序依次尝试，顺序颠倒会浪费大量时间；
- 成本与延迟核算——把调用量、上下文长度与并发估清，确认单位成本可接受；
- 灰度上线与长期监控——小流量验证，观察服务与质量两类指标，并留出回滚路径。
第 3 步常被跳过，结果后面所有"变好了没"的判断都失去依据。
什么时候该考虑微调
- 任务形态固定：输入输出结构稳定，且重复量大，提示的边际收益已经见底；
- 风格与格式要求刚性：必须严格按某种口径输出，靠提示总有小比例偏离；
- 成本压力明确：用更小的模型微调后达到可接受效果，长期成本显著更低；
- 有足够的高质量样本：领域标注数据是前提，样本质量差会直接教坏模型。
反之，如果问题本质是"知识不在模型里"，那答案永远是改检索，而不是改权重。
相邻岗位辨析
| 岗位 | 与之的区别 | 重叠区 |
|---|---|---|
| 大模型应用工程师（本篇） | 侧重模型侧选型、微调、推理与部署，交付可运行的模型应用系统 | 与 AI 应用、算法、平台、后端高度协作 |
| AI 应用与提示工程 | 侧重场景拆解、提示迭代与评测，工程深度相对轻 | 检索增强、评测体系、上线风控 |
| 算法工程师（模型训练） | 做预训练与对齐研究，本岗使用与适配现成模型 | 微调方法、数据构造、评测指标 |
| 机器学习工程（MLOps） | 提供平台与部署能力，不负责应用效果与业务目标 | 服务化、监控、版本管理 |
| 数据开发工程师 | 保障数据管道与治理，本岗保障知识库与训练数据可用 | 数据清洗、文档解析、数据合规 |
| 后端开发工程师 | 负责系统架构与稳定性，本岗负责模型链路逻辑与效果 | 服务架构、缓存、限流降级 |
三组最容易混的场景：
- 大模型应用工程 vs 算法工程师：都要碰模型。分界是"改权重还是改用法"——本岗的默认动作是调检索、调上下文、调配比，只有在提示与检索都到顶时才考虑微调。把微调当成万能药，是新人最常见的路径错误。
- 大模型应用工程 vs MLOps：都要部署模型服务。分界是是否对业务效果负责——MLOps 保"服务活着"，本岗保"业务能用、成本能接受"。大模型场景下两者的工具差异还体现在：本岗更多面对上游接口而不是自建训练集群。
- 大模型应用工程 vs 后端开发：都写服务。分界是系统的不确定性来自哪里——后端面对的是可控逻辑，本岗面对的是概率性输出，因此需要额外的评测、兜底与监控设计。把模型当普通接口来用的团队，上线后一定会出问题。
判断口诀：模型不会，还是没给对上下文与工具 → 先排查后者；改权重 → 微调；改调用方式 → 提示与编排；建平台保部署 → MLOps；保系统架构稳定 → 后端。
不同落地场景下的重心差异
- 客服与知识问答：重心在知识时效、检索质量与转人工策略，对错误容忍度低。
- 内部办公与流程自动化：重心在稳定性与格式合规，通常要求与既有系统对接。
- 研发与代码场景：重心在上下文准确注入与结果校验，仓库级检索是关键。
- 垂直行业（法律、医疗、金融）：重心在专业语料质量、可追溯性与合规审查，人工复核是标配。
- 内容生产与营销：重心在批量效率与风格一致性，成本敏感度较高。
入行与转出（公开口径）
- 背景：计算机、软件工程、人工智能、数据科学等专业为主流；从后端、算法、数据岗转型的案例很多；垂直行业（法律、医疗、金融）背景者结合领域知识也具备竞争力。
- 前置知识：扎实的编程与工程能力（Python、服务化、并发与性能）；大模型原理与能力边界；检索与向量数据库；模型训练与微调的基本流程（含数据构造）；评测方法论；算力与成本的基本估算能力；数据合规与安全常识。
- 面试通常怎么考察：多问"生产上出过什么问题、怎么定位的"——考察的是排查能力而非概念；也会问成本估算、微调与检索的取舍、评测集怎么建。有真实上线经验的人，通常在这一关明显占优。
- 常见入口：① 校招进大厂 AI 平台或业务团队；② 从后端开发转模型应用（工程能力优势明显）；③ 从算法岗转应用落地（需补工程与产品意识）；④ 从数据科学、数据分析转方向；⑤ 从业务领域专家＋自学工程切入垂直行业应用。
- 适配画像：动手能力强、愿意快速试错的人；能同时关注效果、成本与稳定性的工程思维者；对大模型的能力边界保持清醒、不迷信也不轻视的人；善于把模糊需求转化成可评测目标的人。
- 两个常见认知误区：① 以为这个岗位就是"调接口"——真正的门槛在评测、成本与稳定性；② 以为效果不好就换更强的模型——多数问题出在检索与任务定义上。
- 职业特点：技术变化最快、学习压力最大的岗位之一，同时机会窗口也大；"会用模型"的门槛在下降，但"能把它做成可靠产品"的能力依然稀缺；长期可向 AI 架构、AI 产品、算法负责人方向延伸。
- 转出方向：转 AI 架构师、转 AI 产品经理、转智能化解决方案与行业交付、转算法方向（补建模与训练能力）。