面向社招的LLM应用开发工程师岗位页面，介绍大模型应用开发、RAG检索增强、工具调用、评测集构建与线上服务监控等核心工作，梳理常见技能要求、业务场景和面试问题，适合有后端或AI应用经验、希望转向大模型落地的求职者参考。
结合LLM应用开发工程师招聘：岗位职责、技能要求与面试问题，了解岗位定位、职责场景、专业技能、招聘要求和面试重点，再结合完整简历进行参考。
LLM应用开发工程师处在基础模型能力与业务需求之间，负责把大模型接入企业知识库、客服系统、文档问答和内部助手等场景。与算法研究员不同，这一岗位更关注工程落地、检索质量、回答可控性和服务稳定性。
适合有后端开发、AI应用开发或数据工程背景，熟悉Python和API服务，愿意深入RAG、工具调用、评测与监控的人。如果此前做过搜索、推荐、知识管理或客服系统，转型会更有优势。
岗位通常从业务资料接入开始，完成文档解析、去重、切片、版本标记和权限过滤，再建立向量索引与关键词索引。用户提问后，系统进行混合召回、重排序、上下文组装和提示词调用，最后生成带引用的回答。
上线后还需要维护评测集、人工抽检和线上反馈闭环，根据召回率、引用准确率、拒答情况和响应延迟持续调整检索策略、提示词版本和缓存机制。
最常见的项目是企业知识库RAG改造和智能客服问答。业务方通常希望减少人工查找文档时间、提升首次解决率并降低转接率，因此岗位需要针对产品手册、工单和历史问答设计检索与回答流程。
另一类场景是内部知识助手，需要按角色限制文档可见范围，保证回答可追溯。项目推进中往往要协调开发、产品和业务专家，形成标准化实施文档，方便后续复制到更多业务线。
真正影响工作质量的是对检索与生成链路的理解，包括文本切片策略、Embedding模型选择、向量数据库使用、BM25与向量混合召回、重排序模型以及提示词版本管理。工具调用和函数调用能力也很关键，用于连接外部API和业务系统。
工程侧需要熟悉Python、FastAPI或类似框架、PostgreSQL、Redis缓存和异步任务，能够设计可观测的服务接口。评测方面要会构建评测集、定义召回率与引用准确率指标，并通过A/B测试或灰度发布验证优化效果。
招聘方通常看重是否完整做过RAG或LLM应用从0到1的落地，包括文档处理、检索优化、评测体系和服务监控。能说明如何定位回答错误、如何平衡准确率与延迟、如何控制成本，会比单纯罗列模型名称更有说服力。
协作能力也很重要，因为岗位需要与业务专家确认回答标准，与产品对齐需求优先级，与运维保障服务稳定性。有跨部门推动项目、编写实施文档和培训经验的人更容易匹配。
下面整理了LLM应用开发工程师岗位求职中常见的搜索问题，方便快速了解职责、业务场景、技能要求和面试关注点。
RAG中如何选择切片策略？
根据文档结构和问答粒度决定，常见有固定长度、按段落、按标题层级和语义切片，需要结合召回效果和上下文长度做权衡。
向量检索和BM25为什么要混合？
向量检索擅长语义匹配，BM25擅长关键词精确匹配，混合召回可以互补，再通过重排序模型优化Top-K结果。
如何构建和利用评测集？
从高频问题和错答案例中抽样，标注标准答案和引用来源，定期跑离线评测，跟踪召回率、引用准确率和拒答情况，并驱动提示词和检索策略迭代。
线上回答延迟高怎么排查？
先拆分检索、重排序、生成各阶段耗时，检查向量索引、缓存命中率和模型调用，再通过缓存、并行化和索引优化降低延迟。
如何控制大模型调用成本？
优化上下文长度、使用缓存、按场景选择合适模型、减少无效调用，并通过监控统计Token消耗和单次请求成本。
面试通常围绕RAG链路、检索优化、评测方法和线上问题排查展开，也会考察对工具调用、权限控制和成本控制的理解。以下问题接近真实面试中常被问到的表达。
提示词不是一次性写好的，需要像代码一样做版本管理。常见做法是记录每次修改的背景、评测结果和上线时间，配合人工抽检和线上反馈判断是否回滚。
服务监控方面，除了接口可用性和延迟，还要关注检索命中率、引用准确率、拒答率和用户反馈。低置信度问题可以转人工或触发澄清，避免错误回答直接影响业务。
LLM应用开发工程师可以继续深入RAG与检索方向，也可以扩展到Agent、多模态应用或大模型平台工程。随着经验积累，可能转向技术负责人、AI应用架构师或产品化方向。
上下游协作对象包括算法团队、数据工程、产品经理、业务专家和运维。理解业务语言、能把技术方案翻译成业务价值，是长期发展的关键能力。
