手把手把 RAG 教程做成「你自己的」项目
需求→架构→代码→评估集→badcase→方案对比→简历→面试稿,一条完整证据链,对应 RAG 教程 10 章
照教程跑通一个 RAG demo,不等于你有了一个能写进简历的项目。真正能写的 RAG 项目,是你围绕一个具体真实场景,产出一条完整的"证据链":需求、架构、可运行代码、评估集、badcase 复盘、方案对比、简历描述、面试追问稿,每一环都能讲清"为什么这么做"。面试官不看你会不会调 API,而看这条链断在哪。这一篇教你把站内 RAG 教程的 10 章,变成一个证据齐全、追问打不穿的个人项目。 作者:吴师兄 适合:跑过 RAG demo 但简历写不出深度、面试被追问就卡住的人 前置:知道 RAG 是什么,愿意围绕一个场景做深 为什么"跑通 demo"不算有项目 结论先行:demo 证明的是"我能按教程复制",项目证明的是"我能独立解决一个问题",面试官要的是后者。 跑通 demo 的过程是:装依赖、贴代码、喂几个文档、问一句、返回答案、截图。这条路径里你没有做过任何一个"取舍决定"——chunk 切多大是教程给的,embedding 用哪个是教程选的,好不好也没量过。于是你的项目在面试官眼里是一张白纸:问什么都只能答"教程里是这么写的"。而项目之所以值钱,恰恰在于那些教程不会替你做、必须你自己拍板并能解释的决定。把这些决定和它们的依据攒起来,就是下面说的证据链。 【项目证据链·本篇核心】一个能写进简历的 RAG 项目必须产出的 8 项证据 一句话:简历上每写一个技术点,背后都要有一份"证据"撑着;缺哪一环,面试官就会在那里追穿。下面这 8 项是一条完整证据链,顺序也大致是你该产出的顺序。 证据 它回答面试官的什么问题 缺了会被追穿在哪 ① 需求说明 你解决的是谁的什么问题,边界在哪 "这系统给谁用、为什么要用 RAG 不用直接问大模型" ② 架构图 / 模块说明 数据怎么流、每个模块干什么 "画一下你的架构""这一步为什么要有" ③ 可运行代码 你是真做过还是抄的 "现场跑一下""这段检索是你写的吗" ④ 评估集 你怎么知道它做得好 "召回率怎么测的、测试集哪来的、多少条" ⑤ badcase 复盘 你能不能定位并解决问题 "有没有答错的,你怎么发现、怎么修的" ⑥ 消融实验 / 方案对比 你的技术选择有没有依据 "chunk 为什么切这么大""换个 embedding 会怎样" ⑦ 简历描述 你能不能把这件事讲成一句有分量的话 简历一行话立不住,面试官第一问就想拆穿 ⑧ 面试追问稿 被往深里问两层你还接得住吗 追问第二层就"这个我没深究过" 为什么少一环就会被追穿:这 8 项不是并列的清单,而是一条因果链。没有①,你说不清为什么用 RAG;没有④,你的"效果好"是空话;没有⑤⑥,你的技术选择全是"跟着教程";没有⑧,前面做得再实也会在追问的第二层塌掉。面试官的追问方式就是顺着这条链往下戳,戳到第一个没有证据的环节,这个项目在他心里就"水"了。所以做项目不是"把功能实现",而是"把这 8 份证据一份份攒齐"。 RAG 10 章 → 你要产出的证据 → 对应简历/面试点 下面这张表把站内 RAG 智能问答系统教程 的 10 章,逐章映射到"做完你能拿出什么证据"和"面试会怎么追问"。你不需要每章都写成简历亮点,但每章都该留下至少一条能讲的东西。建议边学边把每章的产出记进一个项目文档,这份文档最后自然长成你的证据链。 教程章 做完你能拿出的证据 面试会怎么追问 为什么需要 RAG 需求说明:场景、为什么不用纯大模型/微调 "这个场景为什么选 RAG 不选微调" 整体架构 一张能手画的架构图 + 每个模块职责 "把你的链路画一下,数据怎么流" 文档预处理与切分 chunk 策略 + 大小的对比数据 "切多大、为什么、试过别的吗" Embedding 选型 选了哪个模型、和备选的对比 "为什么这个 embedding,维度/成本怎么权衡" 检索召回·混合检索 向量+关键词混合的召回对比 "只用向量行不行、混合提升了多少" 重排与检索优化 加 rerank 前后的指标变化 "rerank 解决什么问题、值不值这点延迟" Query 理解与改写 改写/扩写对难 query 的效果 "用户问得含糊你怎么办" 多轮与记忆 多轮指代消解的处理 "第二轮'它呢'你怎么接住上文" 引用溯源 答案带引用、可回溯到原文 "怎么防止它编、答案能不能定位来源" 系统评估与上线 评估集 + 指标 + badcase 闭环 "召回率/忠实度怎么量、错了怎么迭代" 看完这张表你会发现:证据链的④⑤⑥(评估、badcase、对比)不是集中在最后一章,而是分散在 03、04、05、06、10 里——每做一个技术选择,顺手记一次"对比数据",评估集就攒出来了。教程配套的 简历与面试附录 可以对照着看怎么落成⑦⑧。 两类人怎么各有侧重 结论:同一套教程,研究生该把"算法证据"做深(评估、消融),在职后端该把"工程证据"做扎实(上线、稳定性、成本),各自吃自己的老本。 人群 证据链里重点砸哪几环 起点与打法 里程碑 研一/研二在校生 ④评估集、⑥消融实验做深,把 chunk/embedding/rerank 都跑出对比曲线 有时间,可以在 03-06 每步都做多组对比,评估集做到几十上百条,冲实习/秋招偏算法侧 一个能讲清"每个参数为什么这么定"的项目 + 一段实习 3 年 Java/后端 ②架构、③代码工程化、⑩上线闭环做扎实,补延迟/成本/稳定性 别去和应届生拼刷论文,把 RAG 当一个真实系统:并发、缓存、超时、降级、监控全上,直接复用你的后端经验 把"我做过高并发系统"翻译成"我做过能上线的 RAG 系统" 两类人都要过①②③,区别在往哪加码:研究生的杠杆在"我把这个方案研究透了、有数据支撑",在职后端的杠杆在"我这套东西真能扛住线上、有稳定性和成本意识"。后者常被忽视——很多算法候选人恰恰答不好"你这 RAG 上线后 p99 延迟多少、成本怎么控",这正是后端的主场。想更系统地看后端经验怎么翻译,看 后端/Java 转大模型怎么把老本变成新能力。 一个具体反例:跑通 demo 就写"独立搭建 RAG 系统" 这是最常见、也最容易被当场拆穿的做法。你跟着教程把 demo 跑通,截了图,简历上写下"独立搭建基于 RAG 的智能问答系统,实现文档检索与问答"。看起来很正常,面试官一追就露: 问"你召回率怎么测的"——你没有评估集,答不上来,只能说"看着还行"。 问"chunk 切多大、为什么"——你用的是教程默认值,不知道为什么,更没试过别的。 问"有没有答错的 case,你怎么发现的"——你从没系统看过 badcase,只跑过几个顺手的问题。 三个问题下来,面试官心里已经给这个项目打了"demo 级"的标签,后面就算你别的答得好,这个项目也帮不上忙了。问题不在于你用了教程——用教程学是对的——而在于你止步于"跑通",没有产出证据链里④⑤⑥这几环。同样一个教程项目,把评估集、badcase、对比数据补上,它就从"减分项"变成"能撑起半场面试的主项目"。 行动清单 从第 1 章开始做,别跳:打开 RAG 智能问答系统教程,从 为什么需要 RAG 起步,边做边把每章产出记进一个项目文档(就是你的证据链草稿)。 项目雏形出来后自测追问:用 简历 AI 追问工具 把你写的项目描述喂进去,看每个技术点会被追问什么,缺证据的地方回去补。 对照真实追问补讲法:去 真实面经里 RAG 是怎么被追问的 看别人被问到哪一层,把你的面试追问稿(第⑧环)补厚。 概念不熟就回题库:某一章的原理没吃透,去 RAG 基础题库 对着刷,把"是什么/为什么"补齐再往下做。 想有人从面试官视角帮你拆项目、模拟追问:训练营 提供项目陪跑和真实面试官视角的模拟追问,适合你已经做出雏形、但吃不准"会被追到哪一层"的阶段。 本篇和相邻篇的分工 避免你读串:本篇只讲"怎么把 RAG 教程做成一个有完整证据链的项目"。项目描述该怎么用三维法(动作/技术/结果)写进简历,交给 第 18 篇 简历怎么写;面试里逐层追问链的应对模板,交给 第 20 篇 项目深挖。想做 Agent 方向的项目、和 RAG 有什么不同,看 第 17 篇 把 Agent 教程做成项目。 看几个真实反馈:RAG 项目为什么要绑定业务场景 我挑这几条 RAG 相关反馈,是想说明一个很朴素的问题:RAG 项目只写"知识库问答"太泛了,必须落到行业文档、权限边界和质量评估里,才像真的做过。样本都做了脱敏,看思路就行。 背景 原始卡点 RAG 项目怎么改 反馈结果 可借鉴点 211 金融本硕跨专业 有金融知识,但没有大模型项目 做金融知识库问答和智能风控 Agent,把业务知识转成文档检索、规则解释和风险判断链路 拿到蚂蚁金融大模型算法岗 offer 行业背景要落到文档、规则、问答和评估上,不要只写"懂金融" 985 控制本硕,原 Java 后端方向 简单后端项目和目标岗位不匹配 用金融业务场景重做 RAG 项目,补检索、引用、评估和服务化表达 拿到金融行业相关双 offer 后端项目要换成模型系统语言,让面试官看到新岗位相关性 双非本科 + 211 硕士,车企方向 缺产业落地项目,不知道怎么贴近车企岗位 围绕车企座舱知识库做 RAG/Agent/上下文工程项目 拿到车企相关 offer,反馈基础薪资提升约 20% RAG 最适合和目标行业结合,场景越具体越容易讲深 所以你做 RAG 时,不要只问"用哪个向量库",先问"我服务的是哪类文档、谁来问、错了会有什么后果"。业务问题立住了,chunk、召回、重排、引用溯源和评估才有选择依据。 常见问题 RAG 项目怎么做才能写进简历? 围绕一个真实场景,产出完整证据链:需求、架构、可运行代码、评估集、badcase 复盘、方案对比、简历描述、面试追问稿。核心是每个技术选择都有对比数据支撑、每个"效果好"都有评估集背书,而不是跑通 demo 就写。 照着 RAG 教程跑通 demo,能直接写进简历吗? 不能直接写,但可以作为地基。demo 只完成了证据链的架构和代码两环,缺评估集、badcase、方案对比。补上这几环,同一个项目就从"demo 级"变成能撑住面试追问的主项目。别止步于截图跑通。 RAG 项目实战大概分哪几步? 按站内教程 10 章走:先想清为什么用 RAG(需求),再搭架构,然后文档切分、embedding 选型、检索召回、重排、query 改写、多轮记忆、引用溯源,最后评估上线。关键是每步顺手记下你的选择和对比数据,评估集和证据链就攒出来了。 我是在职后端,做 RAG 项目该突出什么? 突出工程证据:把 RAG 当真实系统做,并发、缓存、超时降级、监控、p99 延迟、成本控制全上,再配一个评估闭环。这些正是很多算法候选人的短板,直接吃你的后端老本,比拼刷论文更有优势。 一个 RAG 项目要做多少条评估集才够讲? 没有硬指标,几十条起、能覆盖典型问法和几个难 case 就足够讲清"你怎么量效果"。重点不是数量多,而是你能说出这些 case 怎么来的、召回率/忠实度怎么算、发现过哪些 badcase、又怎么修的。 相关阅读 RAG 智能问答系统实战教程:从为什么需要 RAG 到评估上线 简历里的大模型项目怎么写才不被面试官一眼看穿 面试官是怎么逐层追问项目细节的、怎么准备 把 Agent 教程做成能写进简历的项目 真实面经里 RAG 相关的追问链长什么样