RAG 工程师负责让大模型基于企业自有资料回答问题，核心是把「检索得准」这件事做好。
RAG 是 Retrieval-Augmented Generation 的缩写，中文叫「检索增强生成」。它要解决的问题很具体：大模型不知道你公司内部的资料，直接问它会答错或者编造。RAG 的做法是先从企业自有文档里检索出相关片段，再让模型基于这些片段作答。
这个岗位最容易被误解的地方是「以为难点在模型」。实际上大部分工作量在检索侧：文档怎么切分、用什么向量模型、怎么处理表格和扫描件、检索结果排序对不对、召回不到时怎么办。模型只负责把检索到的内容组织成一句话，检索没找对，模型再强也没用。
因此 RAG 工程师的工作更接近搜索工程而不是算法研究。判断一个 RAG 做得好不好，标准也不是「回答通顺」，而是「有没有依据、依据对不对、找不到时会不会老实说不知道」。
RAG 的工作围绕一条流水线展开：文档进来 → 切分 → 向量化 → 存储 → 检索 → 重排 → 生成。每一环都可能是效果差的原因，日常大量时间在定位是哪一环出了问题。
「找不到就说不知道」是这个岗位的职业底线。宁可回答覆盖率低一些，也不能让系统在没有依据时编造内容——企业用户对错误答案的容忍度远低于对「查不到」的容忍度。
RAG 的能力结构是「搜索工程 + 数据处理 + 一点模型理解」，其中搜索工程的比重远高于多数人的预期。
一个实用的判断标准：遇到「回答不准」时，你的第一反应是换个更大的模型，还是先去看检索召回了什么。后者才是这个岗位该有的直觉。
RAG 是大模型在企业侧落地最成熟的方向之一，需求来自任何有大量内部文档的组织：客服知识库、法务合同、医疗资料、制造工艺文档。相比纯 Agent，RAG 的业务价值更容易衡量，因此项目落地率也相对高。
差异化在于能不能处理「难啃的文档」和「说不清的问题」——扫描件、复杂表格、需要跨多篇文档综合的问题。这些是框架解决不了、必须靠工程判断的部分。
RAG 面试会重点考察你对检索环节的理解，以及有没有处理过真实的脏文档。
只用向量检索有什么问题？
准备建议：第三个问题是价值观题，答「让模型自由发挥」基本会被否掉，正确方向是明确告知没有依据。
能讲出自己踩过的具体坑（比如表格被切碎导致召回失效），比背诵流程有说服力得多。
RAG 是 Retrieval-Augmented Generation（检索增强生成）的缩写。RAG 工程师负责让大模型基于企业自有资料回答问题，工作包括文档解析清洗、切分策略、向量化与索引、检索重排、引用溯源和效果评测，核心是把检索做准。
微调是把知识写进模型参数里，需要训练资源，知识更新要重新训练；RAG 是把资料放在外部知识库，检索后交给模型参考，资料更新只需更新知识库。企业内部资料变动频繁且需要引用溯源，因此多数场景优先选 RAG。
多数人以为难在模型，实际大部分工作量在检索侧：文档怎么切分、表格和扫描件怎么解析、混合检索怎么配、召回结果怎么重排。模型只负责把检索到的内容组织成回答，检索没找对，换更大的模型也没用。
以搜索工程和数据处理为主：文档解析（PDF、Office、OCR、表格版面）、向量检索与关键词检索的原理及适用场景、向量库使用、评测集构建与召回准确率度量，编程以 Python 为主。对模型的理解是必要的，但比重低于多数人的预期。
知道岗位做什么，和让 HR 从你的简历里看出你能做，是两件事。简历里的经历要按这个岗位的 JD（岗位要求）重新组织关键词，还得先过得了机器筛选。基础功能免费； 秋招冲刺包 ¥499：AI简历姬 1 年会员（简历诊断、JD 匹配优化、AI 模拟面试） + 1 次 1V1 深度语音求职指导 + 1 年微信答疑。
用于提升求职方向判断与准备效率，不承诺录用结果；不提供代投服务，不保证内推或 Offer。
内容说明：本页内容按公开资料整理并经人工复核，用于帮助了解岗位，不构成招聘承诺。薪资、行业数据只在能追溯到公开来源时展示，其余留空。具体岗位职责和要求，请以用人单位发布的招聘公告为准。
TEMPLATES