最近帮几个朋友改了简历，发现一个特别普遍的问题：简历里都写了RAG项目，模板几乎长一个样——“使用LangChain搭建RAG知识库，调用OpenAI接口实现问答”。技术名词没毛病，代码也能跑，但面试官追问几句就露馅了。不是说项目是假的，而是描述方式把自己写成了流水线工人：谁调接口不是调？谁跑通Demo不是跑通？这套写法在面试官眼里，根本看不见你的判断力。
RAG（检索增强生成）这类项目，本来是最容易在简历里出彩的——它横跨文本处理、向量检索、生成策略、效果评测好几个环节，每个环节都有决策空间。问题在于，大多数人只写“干了什么”，没写“为什么这么干”“遇到了什么坑”“怎么证明有效”。这篇指南就是干这个用的：我会一边讲怎么重新组织结构，一边手把手带你把代码片段和思考过程放进简历和面试讲法里，让你从“会调库的”变成“能解决问题的”。
1. 先搞清楚一件事：RAG项目在简历里到底卖什么
1.1 面试官在RAG项目里真正想看的三层能力
一个RAG项目，表面上你是做了一个知识库问答工具，但放在简历里，你其实是在向面试官展示三层能力：第一层是工程能力——你能不能把一个想法的链路完整搭起来，处理文档、建索引、写接口、部署上线；第二层是算法理解——你对Embedding、分块、召回、排序这些环节是不是真的吃透了，还是只在调现成的API；第三层是问题解决能力——项目里一定有不顺利的地方，你是靠什么思路定位问题、怎么调整方案、最后怎么证明改好了。
大多数人的简历只覆盖了第一层，第二层勉强沾边，第三层基本空白。问题就出在这：面试官筛人，看重的恰恰是第二层和第三层，因为这两层代表你入职后能不能独立推进事情。调库的能力大家都有，遇到坏数据、检索不准、回答跑偏时谁能扛得住，才是差距所在。
我在面试时看到过一个有趣的对比。候选人A写：“负责开发基于LangChain的企业知识库问答系统，使用FAISS作为向量数据库，通过OpenAI接口生成回答。”候选人B写：“面向3000份产品文档构建问答系统。针对长文档切片后语义碎片化的问题，对比了固定长度切分、层级切分和滑动窗口切分三种策略，结合召回命中率评测把chunk_size定为512。发现单一向量检索对型号编码等精确匹配场景召回较差，引入BM25+向量的混合检索，首轮召回命中率从62%提升到81%。”
A是流水线描述，B是问题解决者描述。但注意，B描述的事情本身并不高深——任何人都能做这些评测，差别只在于你有没有把这个思考过程当回事、写下来、讲清楚。这就是整篇文章的出发点。
1.2 “流水线工人”式写法的三大死穴
我总结了简历里最典型的三种问题，大家可以对号入座。
死穴一：名词堆砌，没有判断。常见句式：“项目基于FastAPI+LangChain+LangGraph+RAG+pgvector技术栈实现。”恨不得把所有见过的热门框架全罗列上去。面试官看到这种描述的第一反应不是“好厉害”，而是“你到底用了哪个、为什么用这个、别的为什么不行”。任何一个追问都可能把你问倒，反而暴露短板。
死穴二：只写实现，不写决策。典型句式：“在项目中实现了文档的分块与Embedding，建立了向量索引，用户提问后通过相似度检索召回复片段，最后交给大模型生成答案。”这句话字面上没有错，但它描述的是一段任何人都能照着教程跑通的流程。你做过的关键决策——chunk_size怎么定、Embedding模型怎么选、top_k设多少、Prompt里要不要带来源、检索失败怎么兜底——一个都没提。
死穴三：没有量化结果。要么不写效果，要么写一句“回答准确率较高”。“高”是多高？基准是什么？怎么评测的？没有量化的项目描述在简历里等于没有说服力。你说效果好，凭什么让我信？你给我看评测路径：我抽了200个真实问题，定义了三级打分标准，准确率从最初的XX%提升到XX%。这才叫证据。
这三个死穴改起来其实不难，难的是很多人根本没意识到。下面我开始拆解怎么重构。
2. 从“做了什么”到“解决了什么”：把RAG经历重新翻译一遍
2.1 问题驱动的STAR写法
简历项目的经典表达方式是STAR：情境（Situation）、任务（Task）、行动（Action）、结果（Result）。问题在于，很多人写RAG项目时只写了A，甚至A写得也含糊——用了什么工具、调了什么接口。这里我建议你把重心从“行动”挪到“任务”和“结果”上。
具体怎么操作？回想你做项目的过程中，有没有出现过这些问题：文档格式五花八门，PDF、Word、Excel扫出来的文字乱序，不处理就直接切分会切出一堆残片；有些文档特别长，直接丢进Embedding会超过模型输入长度，而且命中的语义信息会被稀释；用户提问是口语化的，文档是书面化的，向量检索经常匹配不上；检索回来的片段明明包含答案，但大模型生成的回答和文档原文冲突……你做过的每一个调整，本质都是针对这些问题的一次决策。
把这些真实问题还原到简历里，你的项目就从“流水账”变成了“战斗记录”：遇到什么问题→我想到什么方案→我为什么选这个方案→实测效果如何。这个结构天然包含了判断力和领导力，哪怕你是团队里负责执行的普通成员，只要这个决策是你做出的，你就能大大方方写。
有一个细节要注意：不是每个问题都要写，挑两到三个最核心、最能体现技术深度的即可。RAG链路里常见的高光点包括：文档解析与清洗策略、分块策略的对比选择、Embedding模型的选型、混合检索、重排序（Rerank）、Prompt设计、评测方法、延迟优化。选两三个写得深入，远胜过十个都提一嘴。
2.2 可直接套用的项目描述模板
我提供一个比较通用的结构，你可以往里填自己的真实数据。
一句话项目定位：做什么用、给谁用、覆盖多少数据量。
我的职责：注明你负责的核心模块，不要什么都写。
关键决策：两到三条，每条都按“我做了X，因为Y，效果Z”的格式。这里举几个可以直接套的例子：
- “设计基于标题层级+段落结构的混合分块策略，替代固定长度切分。针对产品文档章节结构明显的特点，优先按章节切分，再对过长章节做滑动窗口二次切分。经200个真实问题的评测，召回命中率由55%提升至74%。”
- “构建BM25+向量检索的混合召回并动态加权。发现精确型号、参数数值等短文本查询在纯向量检索下效果不稳定，于是引入稀疏检索互补。加权系数alpha通过小规模网格搜索调参，在验证集上召回率再提升7个百分点。”
- “为每条检索结果附加来源文档及相似度分数，Prompt中要求模型仅依据检索内容回答，并输出来源标注。人工评测中‘答非所问’占比从18%降到6%。”
结果量化：一至两条，能量化尽量量化。可以写首轮检索命中率、回答可采纳率、端到端延迟、覆盖的文档量级、人工评测样本数。如果项目有上线，还写上“支持XX个用户的日常查询”，这个信息很有价值。
把这个结构套上去之后，你会发现简历同一段经历，读起来的份量完全不一样了。下面这个部分，我来讲怎么用代码进一步证明这些描述不是吹的。
3. 用代码证明思考：简历/作品集里的代码怎么选、怎么写
3.1 选代码的三个原则：片段化、决策化、可讲性
很多人在简历或作品集链接里贴整个项目仓库，几百个文件，面试官根本不可能细看。就算细看，大概率看到的是套壳调用、写死的配置、没有注释的脚本。与其这样，不如精选三到五个代码片段，每个片段背后都有一个可讲的决策故事。
选代码的时候，我给自己定了三个原则。第一，片段化。只截取关键函数或关键配置文件，配上一小段说明，而不是把整个工程丢过去。第二，决策化。这段代码存在的意义，不是为了实现某个功能，而是为了验证一个判断——比如分块参数对比、混合检索的权重调优、评测指标的计算。面试官看了会想：这个人做事情有方法，不是上来就写死。第三，可讲性。你自己对着这段代码能不能讲满三分钟？讲不满，说明你还没吃透，那就别放。
下面我给出三个可以直接参考的片段。它们都是我见过的真实项目中很典型、又不过分复杂的写法，你可以根据自己的项目改造。
3.2 片段一：分块参数评测脚本
分块策略是RAG项目里最值得写进简历的细节之一，因为几乎每个人都做过，但很少人用数据证明自己的选择。下面这个脚本的思路是：把不同的chunk_size和overlap组合跑一遍召回评测，用真实问题集验证哪个配置最优。核心不是代码多高级，而是“用评测代替拍脑袋”这个意识。
# chunk_size 对比评测脚本（简化示意） import random from langchain.text_splitter import RecursiveCharacterTextSplitter def evaluate_chunking(documents, questions, chunk_size, overlap): """返回：top5召回命中率，模拟召回评测""" splitter = RecursiveCharacterTextSplitter( chunk_size=chunk_size, chunk_overlap=overlap, separators=["\n\n", "\n", "。", "！", "？", "；", "，", " ", ""], keep_separator=True, ) chunks = [] for doc in documents: chunks.extend(splitter.split_text(doc)) # 实际项目中这里会转成向量并检索，这里用关键词包含模拟命中逻辑 hit = 0 for q in questions: keyword = q[:6] # 简化：取问题前6个字作为关键词 retrieved = [c for c in chunks if keyword in c][:5] if retrieved: hit += 1 return hit / len(questions) if __name__ == "__main__": # 假设已经加载了 documents 和 questions # documents = load_docs("data/") # questions = load_questions("eval_set.json") for size in [128, 256, 512, 1024]: for overlap_ratio in [0.1, 0.2]: score = evaluate_chunking( documents, questions, chunk_size=size, overlap=int(size * overlap_ratio), ) print(f"chunk_size={size}, overlap={overlap_ratio} -> hit_rate={score:.3f}")这段代码在简历里怎么讲？核心是说：我没有一上来就固定用某个chunk_size，而是把常见配置跑了一组对比，发现chunk_size=512、overlap=10%时在特定文档集上召回最好。面试官可能会追问：为什么512最好？这时你要能接住——大概是因为这批产品文档本身段落长度集中在300到600字之间，拆太小了语义被切断，拆太大了信息太杂会稀释Embedding的语义表达。如果你能说出这一层，这个追问就成了加分项。
注意一个容易翻车的点：代码里如果用了模拟命中逻辑，一定要诚实。这个简化版本只是为了演示思路，真实项目里你就得真的用Embedding做检索来评测。面试官一旦较真，你只能拿数据说话，现场编是编不出来的。
3.3 片段二：混合检索加权实现
混合检索是RAG项目中体现算法理解的一个好素材。它的背景是：纯向量检索对语义相似但字面完全不重叠的查询有效，但遇到型号、编号、精确术语时往往召回不准；而BM25这类稀疏检索擅长精确匹配，却不懂同义改写。把两者结合，用一个权重系数来调节，是工程上非常常见的做法。
# 混合检索：BM25 + 向量检索，按权重融合（简化示意） import numpy as np def hybrid_search(query, top_k=10, alpha=0.6): """ alpha = 0 时纯 BM25，alpha = 1 时纯向量检索。 实际项目中 alpha 可通过小规模验证集网格搜索确定。 """ # 稀疏检索分数：BM25 对候选文档打分 bm25_scores = bm25_index.get_scores(query) # dict: doc_id -> score # 稠密检索分数：向量相似度，这里假设已经算好，距离越小越相似 vector_scores = { doc_id: vector_index.similarity_search_with_score(query, doc_id) for doc_id in candidate_doc_ids } # 分数归一化到 0~1，再融合 merged = {} for doc_id in candidate_doc_ids: norm_bm25 = normalize_minmax(bm25_scores[doc_id]) norm_vec = 1 - normalize_minmax(vector_scores[doc_id]) merged[doc_id] = alpha * norm_vec + (1 - alpha) * norm_bm25 return sorted(merged.items(), key=lambda x: x[1], reverse=True)[:top_k]这段代码有一个值得强调的小细节：两个异构分数合并前必须先归一化，否则量纲不一致，加权就没有意义。这个细节放在简历里不一定要写，但面试官问“分数怎么融合”的时候，你能说出“BM25的分数分布和向量距离完全不是一个量级，我做了min-max归一化再按alpha加权”，面试官就会知道你确实动手写过。
alpha怎么确定？两种常见做法：一是凭经验先设0.6，观察线上badcase再调；二是在一个小规模标注集上做网格搜索，跑0.3、0.5、0.7几档，挑召回最优的一个。第二种做法写进简历里更有说服力。你可以补一句“在200条标注查询上评估，alpha=0.7时命中率最高”，这就把代码提升到了决策层面。
3.4 片段三：带来源与置信度的生成Prompt
检索生成这一环同样有讲究。一个常见的问题是：模型拿到的检索片段可能包含错误信息，或者和问题根本不相关，模型照单全收就会一本正经地胡说八道。一个务实的做法是：在Prompt里明确限定模型的回答边界，并要求标注来源。
# 生成阶段 Prompt 模板（简化示意） SYSTEM_PROMPT = """你是一名企业知识库问答助手。请遵守以下规则： 1. 只能依据下方“检索资料”中的内容回答，禁止使用资料之外的知识。 2. 如果检索资料不足，无法回答问题，请直接回复“资料中未找到相关信息”。 3. 回答末尾附上依据片段编号，格式为 [来源: n]。 检索资料： {context} 用户问题： {question} """ def format_context(retrieved_chunks): """把检索片段编号拼接成 Prompt 上下文""" lines = [] for i, chunk in enumerate(retrieved_chunks): source = chunk.metadata.get("source", "unknown") lines.append(f"[{i}] (来源: {source}) {chunk.page_content}") return "\n\n".join(lines)这段代码的价值在于：它体现了你对RAG可解释性和幻觉风险的意识。简历里可以写成“设计了带来源标注的Prompt模板，要求模型仅依据检索内容回答，并在回答后展示引用来源，显著减少无依据编造”。面试官听了会追问“你怎么知道来源标注真的减少了幻觉”，这时你可以说做了人工评测——抽100条问答，对比有无来源标注时回答的可采纳率。
如果你在项目中还做了“检索置信度低于阈值就直接拒答”的兜底逻辑，那更好。比如相似度分数低于0.6的查询统一返回“暂无匹配内容”，这个策略在专业场景里很有价值，可以单独写一条。
3.5 一个工程化的RAG项目目录结构示例
除了片段之外，如果你能展示一个清晰的工程目录，会给面试官留下不错的组织印象。不需要特别复杂，但要有层次、有评测入口，说明你考虑过可维护性。下面是我建议的最小目录，直接基于现在社区里常见的FastAPI + LangChain + pgvector/Milvus组合：
rag-qa/ ├── app/ │ ├── main.py # FastAPI 入口，提供 /ask 接口 │ ├── ingest.py # 文档解析、分块、向量化、入库 │ ├── retriever.py # 混合检索与重排序逻辑 │ ├── generator.py # Prompt 管理与大模型生成 │ └── schemas.py # 请求/响应数据结构 ├── scripts/ │ ├── evaluate_chunk.py # 分块参数评测 │ └── eval_retrieval.py # 召回命中率评测 ├── data/ # 原始文档 ├── tests/ # 接口与链路测试 └── requirements.txt为什么要把scripts单独拎出来？因为大多数人的项目里根本没有评测脚本。你加了这一层，等于告诉面试官：这个项目不是写完就完了，我思考过“怎么证明它好用”。这在初级岗位里是一个很明显的区分信号。另外，requirements.txt里用到的包名建议精简，每一行你都要能解释用途，免得被问住。
4. 面试追问：你的包装必须经得起扒皮
4.1 RAG项目必问的5类追问怎么答
简历只是敲门砖，面试才是分水岭。下面这五类追问，我几乎在每次RAG相关面试里都会听到，提前准备好回答逻辑，现场就不会卡壳。
第一类：分块参数为什么这么定？如果你在简历里写了chunk_size、overlap，准备好回答“为什么是512不是1024”“overlap为什么是10%不是50%”。参考逻辑：结合文档特点（章节长度、段落结构）和Embedding模型的输入上限，再用评测数据验证。如果当时确实拍脑袋定的，也要诚实说“我最初凭经验设了512，后来做了评测对比发现256到512之间差异不大，512综合表现最好”。
第二类：向量检索和BM25各自在什么场景下失效？向量检索的弱点是：精确匹配（编号、型号、法律条款原文）、短文本、低频词；BM25的弱点是：同义改写、语义匹配、口语化查询。这类问题考察的是你对两种检索机制本质的理解，不是背定义。你可以结合项目里的具体案例，比如“用户搜‘发票有效期多久’，文档里写的是‘发票自开具之日起XX日内有效’，向量检索能匹配上，BM25就不行”。
第三类：检索到了相关内容，但模型回答错了怎么办？这是一个典型的链路归因问题。排查思路是：先定位是检索召回不準还是生成环节出错。如果正确片段没有进top_k，优化检索；如果片段进去了但模型没参考，调整Prompt或增加Rerank。面试官想看到的是你有系统地拆解问题的能力，而不是蒙头调参。
第四类：RAG的幻觉问题你怎么控制？比较完整的回答应该包含多个层次：数据层做清洗和去重；检索层提高召回质量、加阈值过滤低置信度内容；生成层通过Prompt限定范围、要求引用来源；评测层建立人工评测集持续回归。你不需要全做到，说出两三个你实际做过的就很有说服力。
第五类：线上性能怎么样？这个问题的用意是考察你是否有工程意识。你可以准备的量化信息包括：单次查询的端到端延迟（比如1.8秒）、其中向量检索耗时多少、大模型生成占大头、是否有加上Rerank后的延迟变化、并发量怎么估算的、有没有做缓存。如果项目只是本地Demo，也别慌，可以说“目前是原型阶段，但我评估过瓶颈在大模型生成延迟，后续会通过缓存和异步化优化”，表现出你有这个意识就够了。
4.2 不会答怎么办：坦诚和延伸的边界
面试中最怕的不是不会，而是装会。你简历上写了技术栈，面试官顺着问了一个你没接触过的细节，这太正常了。关键是怎么处理。
我建议的分寸是：先明确区分“我没做过”和“我不了解”。如果是没做过，可以坦率说“这个场景我在项目中没实际遇到，但基于我对RAG的了解，我的思路是……”然后给出一个逻辑自洽的方案。这不算造假，反而显示了你在压力下的思考能力。如果完全不了解，就老老实实说“这块我还真没深入研究过，后续我会补上”，记录下来，别硬编。
这就是包装与造假的边界：包装是把真实的思考表达清楚，造假是把自己没做过的说成做过的。后者一旦被拆穿，整个简历的可信度就清零了。我见过最惨的案例是候选人在简历里写了微服务拆分，结果被问了一个分布式事务问题后彻底崩盘，前面的RAG部分讲得很好也白搭。所以，不熟的东西一个都不要写。
5. 一个初级RAG项目的“变形记”
5.1 改造前：典型的流水线描述
下面是一段我在简历里见过很多次的原始描述，你可能觉得很眼熟：
项目：基于RAG的知识库问答系统。项目中使用LangChain框架，将公司产品文档切分后进行向量化，存入Milvus向量数据库。用户提问时，通过Embedding检索相关文档片段，再调用大模型接口生成回答。项目采用FastAPI搭建后端服务。技术栈：Python、LangChain、FastAPI、Milvus、OpenAI API。
问题很明显：全是操作，没有判断，没有数据，没有个人思考。面试官看完只能得出一个结论——这个人能照着教程把Demo跑起来。至于为什么要用Milvus不用FAISS、分块怎么做、检索效果如何、有没有上线，完全看不到。
5.2 改造后：问题解决者版本
同一段经历，换一种表达方式：
企业产品文档智能问答系统：面向1200份产品手册与FAQ文档，基于RAG架构构建内部知识库问答服务，支持技术售后人员快速查询产品参数与故障处理流程。
负责核心检索链路设计与实现。针对手册中文字密集、段落边界模糊的问题，设计“按标题层级切分+超长段落二次滑动切分”的分块策略，并在200条真实售后问题上对比不同chunk_size的召回命中率，最终确定512/64的配置，首轮召回命中率由55%提升至74%。
发现纯向量检索对型号编码、故障码等精确匹配场景召回不稳定，引入BM25+向量的混合检索，通过alpha权重融合并对分数做归一化，召回率进一步提升约7个百分点。为控制生成幻觉，Prompt限定模型仅依据检索片段回答并标注来源，人工评测中无依据编造的回答占比由18%降至6%。
服务采用FastAPI提供接口，平均响应时间1.8秒，支持并发查询。技术栈：Python、LangChain、FastAPI、Milvus、sentence-transformers。
注意，这段描述里并没有夸大什么，用的全是RAG项目真实会遇到的环节。只是从“我调用了什么”变成了“我遇到了什么问题、做了什么决策、得到了什么结果”。这就是从流水线工人到问题解决者的本质跃迁。
5.3 面试口述：同样的经历换一种讲法
简历写好了，面试时怎么讲？很多人吃亏在讲得太散，东一句西一句。我建议按“背景→问题→方案→验证”四步走，讲一个完整的小故事。
举个例子，你可以这样讲：“这个项目是为售后团队做产品文档问答。一开始我用教程里最常见的固定长度切分，把文档切成长度相等的块，跑通之后发现很多问题查不准。后来我分析了一批badcase，发现我们这个产品手册章节结构很强，标题下面经常跟着一大段参数表格，固定切分很容易把一个完整的语义单元切开。所以我改成先按标题层级找边界，遇到特别长的章节再用滑动窗口二次切分。为了验证效果，我抽了200条真实售后问题，写了个脚本对比不同参数下的召回命中率，最后锁定了512的chunk_size，命中率从55%提到74%。”
这段口述的时间大概一分半钟，信息密度很高，面试官听完会自然追问细节——这正是你想要的。因为你讲的每一句话都是真实经历过、思考过的，追问只是在给你递加分的机会。
6. 写在最后：包装不是造假，是重新认识自己的工作
6.1 最容易翻车的几个细节
再说几个我在简历和面试里反复看到的问题，提醒大家别踩坑。
第一，量化数据要保守，但要有依据。你写在简历上的每个数字，都要准备好被追问“这个数据怎么来的”。如果评测样本只有20条，就写“在20条问题上的初步评测”，别写“准确率95%”。面试官听到太完美的数字反而会警觉。
第二，技术栈别写成全家桶。很多人喜欢把LangChain、LangGraph、pgvector、Milvus、FastAPI全部列上去，好像技术多样性等于能力强。实际上，每一项都可能被追问。你要么保证每一项都能讲出选择理由，要么就只列自己真正吃透的。记住：删掉一个名词永远不会扣分，写上一个不熟的才会。
第三，注意分清“团队项目”和“个人贡献”。在多人项目中，不要把所有模块都写成自己的功劳。一般做法是写明“负责检索链路设计与实现”，把团队里别人做的部分留给你知道的部分。面试官如果追问其他模块细节，你可以诚实说“这部分是我同事负责的，我从接口层面了解大概”，这样反而显得有边界感、真实可信。
第四，代码风格和注释别太“教程化”。简历附带的代码如果全是“# 导入库”“# 定义函数”这种注释，面试官会觉得你没做过真实项目。写代码的时候把核心设计意图写在注释里，比简单的步骤说明更有价值。比如“# 先归一化再融合，否则BM25分数会直接淹没向量距离”，这才像一个有经验的人写出来的注释。
6.2 我的习惯性自检清单
我每次帮别人改简历或者自己写项目总结的时候，都会过一遍下面的自检清单。你也拿它来检查一下自己的RAG项目描述：第一，这段经历里，有没有明确指出一个具体问题？第二，有没有说明你是如何定位到这个问题的？第三，有没有写出至少一个经过对比后做出的技术选型，并给出理由？第四，有没有用数字证明你的方案有效？第五，简历里出现的每一个名词，你能不能对着面试官讲满三分钟？
如果五个问题里有任何一个答不上来，说明这个项目要么还没做透，要么还没讲透。前者需要回去补实验，后者需要重新组织语言。就我个人经验来说，90%的情况是后者——项目本身做了一大堆，但从没认真梳理过，导致价值和能力完全没被看见。花一个晚上，把你做过的RAG项目按上面这个框架重新写一遍，你会惊讶地发现，原来自己早就不是流水线工人了，只是一个没学会“翻译”自己工作的工程师。希望这篇指南能帮你把这段经历讲清楚，讲出真正的价值。
