企业官网建设流程全解析

1. 简历上那个"RAG项目"为什么没人问

我帮人改过不下五十份简历，有个现象特别有意思：十个做大模型方向的人，八个简历里都躺着一段"基于RAG的智能问答系统"。但你仔细看描述，几乎一模一样——"使用LangChain搭建知识库，实现文档检索与问答，提升回答准确率"。这种写法投出去，面试官扫一眼就划过去了，连追问的欲望都没有。

问题不在于RAG这个方向不行，恰恰相反，RAG是目前大模型落地最扎实的场景之一。问题在于，绝大多数人做的RAG项目，本质上是在跑通一个教程，而不是在解决一个真实问题。教程跑通了，代码能跑，demo能演示，但简历上写出来就是没有辨识度。面试官一天看几十份简历，看到"LangChain+RAG+知识库"这个组合，脑子里自动归类为"跟着视频敲了一遍"，然后就没有然后了。

我先把结论摆在这里：RAG项目难进简历，核心原因是它太容易"看起来一样"了。向量库用Chroma还是FAISS，切分用RecursiveCharacterTextSplitter还是按标题切，检索用相似度还是MMR，这些在简历上根本区分不出水平高低。真正能拉开差距的，是你在这个项目里遇到了什么具体问题、做了什么非教科书式的决策、拿到了什么可量化的结果。

这篇文章我想把这件事彻底讲透。从为什么你的RAG项目在简历上"隐身"，到怎么把它拆解成有说服力的项目经历，再到面试时怎么接住追问。适合正在准备大模型方向求职的人，也适合已经做完项目但不知道怎么包装的开发者。我会尽量用我实际帮人改简历时遇到的真实案例来讲，不整虚的。

2. 拆解"简历隐身"的四个真实原因

2.1 项目同质化：你做的和别人做的没有区别

先说最扎心的一个原因。现在网上关于RAG的教程多如牛毛，从LangChain官方文档到各种"零基础可复制教程"，流程高度统一：加载文档、切分、向量化、存库、检索、拼prompt、调LLM。你跟着做一遍，别人也跟着做一遍，最后产出的项目在技术栈和架构上几乎完全重合。

我见过一个求职者，简历上写"基于RAG的企业知识库问答系统"，我问他你这个和企业微信自带的智能助手有什么区别，他愣了半天说不出来。这就是问题所在——你的项目没有回答"为什么需要你重新做一个"这个问题。如果市面上已经有成熟方案，你的项目价值就必须体现在"我解决了通用方案解决不了的具体问题"上，而不是"我也能搭一个"。

同质化的直接后果是，面试官无法通过项目描述判断你的能力边界。他看到的是一堆技术名词的堆砌，而不是一个工程师在真实约束下做取舍的过程。简历筛选阶段，HR或者初筛面试官往往用关键词匹配，你的项目描述里全是通用词，自然就被淹没了。

2.2 描述停留在"用了什么"，没到"解决了什么"

第二个原因出在描述方式上。大部分人写项目经历的习惯是罗列技术栈："使用LangChain框架，结合Chroma向量数据库，采用OpenAI Embedding进行文本向量化……"这种写法的问题在于，它只说明了工具，没说明价值。

我帮人改简历时有个基本原则：每一句话都要能回答"所以呢"。你说你用了混合检索，所以呢？检索准确率提升了多少？你说你做了多轮对话记忆，所以呢？用户追问的解决率从多少到了多少？没有"所以呢"的答案，这句话在简历上就是废字。

更麻烦的是，很多人根本不知道自己项目的效果数据。因为做的时候就没测过。教程跑完，随便问几个问题，感觉回答还行，就结束了。没有评测集，没有对比实验，没有bad case分析。这种情况下你就算想写出量化结果也写不出来，因为手里根本没数据。

2.3 缺少工程约束：demo和产品的差距被忽略了

第三个原因是项目本身缺乏工程约束。教程里的RAG是理想环境：文档格式统一、问题清晰、知识库规模小、没有并发、不用考虑成本。但真实场景里，文档可能是扫描件PDF、表格、带公式的技术手册；问题可能是模糊的、带错别字的、需要多跳推理的；知识库可能几十万条，检索延迟和成本都是硬约束。

我认识一个做企业级知识库的朋友，他跟我说他们项目最难的部分根本不是RAG本身，而是文档解析。公司内部文档有Word、PDF、Excel、PPT、还有扫描件，光是把这些格式统一成可处理的文本，就花了整个项目一半的时间。表格里的数据怎么保留结构，扫描件的OCR错误怎么纠正，这些才是真实项目里吃功夫的地方。

如果你的简历项目完全没有体现这类工程约束，面试官会默认你做的只是玩具级demo。而玩具级demo在简历上的分量，说实话，不如不写。

2.4 没有失败记录：全是成功叙事反而不可信

最后一个原因比较微妙。很多人的项目描述全是"实现了""优化了""提升了"，一路顺风顺水。但真实项目不可能没有坑。面试官看到这种完美叙事，第一反应不是佩服，而是怀疑——要么你做的太简单没遇到问题，要么你在隐瞒。

我自己的经验是，简历和面试里适当暴露一两个"踩坑-定位-解决"的完整链路，反而比堆成功案例更有说服力。因为它证明你真的动手了，真的遇到了非教科书问题，真的有能力排查。一个能讲清楚"为什么我的检索在长文档上效果差，我怎么定位到是切分粒度问题，最后怎么解决的"的人，比一个只会说"我用了RAG效果很好"的人，可信度高出一个量级。

3. 把RAG项目改造成简历亮点的具体路径

3.1 先给项目找一个"非做不可"的真实场景

改造的第一步，是给你的项目换一个具体的、有约束的场景。不要写"企业知识库问答"，太泛了。要具体到某个垂直领域、某类特定文档、某群特定用户。

举个例子，同样是RAG，你可以把它定位成"面向法律合同审查的条款检索助手"，或者"面向医疗器械说明书的故障排查问答"，或者"面向内部运维手册的on-call支持系统"。场景一具体，约束就出来了，你的技术决策就有了依据。

我帮一个做HR方向的朋友改过简历，他原本写的是"基于RAG的员工手册问答"。我让他改成"面向新员工入职场景的政策问答助手，覆盖考勤、报销、假期三类高频问题，支持口语化提问"。改完之后，面试官立刻有了追问方向：口语化提问怎么处理的？三类问题的检索策略有区别吗？这就是场景具体化带来的好处。

场景选择有个技巧：选你真正熟悉的领域。如果你在电商公司待过，就做商品知识库；如果你学过法律，就做法规检索。因为只有你熟悉这个领域，你才知道真实用户会怎么提问，才知道哪些回答是"看起来对但实际错"的，这些细节是编不出来的。

3.2 用"问题-决策-结果"三段式重写项目描述

场景定了，接下来是描述方式。我推荐一个三段式结构：遇到了什么问题，做了什么决策，拿到了什么结果。

对比一下两种写法。原来的写法："使用LangChain和Chroma搭建RAG系统，实现文档检索问答。"改造后的写法："针对内部技术文档中代码片段和正文混排导致检索召回率低的问题，设计基于文档结构的自适应切分策略，将代码块、表格、正文分别处理，检索命中率从62%提升到81%。"

第二种写法里，"代码片段和正文混排"是问题，"自适应切分"是决策，"62%到81%"是结果。面试官一看就知道你遇到了具体问题，做了具体设计，有具体数据。这三样东西加起来，就是可信度。

这里的关键是结果必须可量化。如果你做项目时没测数据，现在补测也来得及。构造一个几十条问题的评测集，人工标注正确答案，然后对比优化前后的命中率。这个过程本身也是项目的一部分，可以写进简历。

3.3 把技术选型写成"取舍"而不是"清单"

技术栈的写法也要改。不要列清单，要写取舍。比如不要写"使用FAISS向量库"，而要写"在FAISS和Milvus之间选择了FAISS，因为项目知识库规模在十万级以内，FAISS的本地部署和零运维成本更符合需求，实测检索延迟在50ms以内"。

这种写法传递的信息量完全不同。它说明你了解多个方案，知道各自的适用边界，并且能根据实际约束做决策。这是工程师和"调包侠"的核心区别。

我整理了一个常见技术点的取舍写法对照，你可以参考：

这张表里的每一行，都是一个可以展开讲的面试话题。你写进简历的每一个取舍，都要准备好被追问"为什么"。

3.4 补上评测环节，让项目有"闭环"

大部分人的RAG项目缺最后一环：评测。做完就完了，没有系统性地验证效果。补上这一环，项目立刻完整很多。

评测不需要很复杂。构造一个50到100条的问题集，覆盖不同类型（事实型、推理型、多跳型、拒答型），人工标注标准答案，然后用命中率、召回率、答案准确率几个指标衡量。更进一步，可以做A/B对比，比如切分策略A vs 策略B，检索方式A vs 方式B。

有了评测数据，你的简历描述就有了底气。而且评测过程本身会暴露很多问题，这些问题就是你面试时的谈资。我见过一个求职者，他在评测时发现模型对"否定式提问"处理很差，比如问"哪些情况不需要审批"，模型总是回答需要审批的情况。他针对这个问题做了prompt优化和检索策略调整，这个案例在面试时讲出来，面试官印象非常深。

4. 面试追问环节：RAG项目最容易被问到的六个问题

4.1 "你的切分策略是怎么定的，为什么这么定"

这是RAG项目必问题。面试官想知道的不是你用了什么切分器，而是你理解不理解切分对检索效果的影响。

回答的框架应该是：先说文档特点，再说切分目标，最后说具体策略和验证结果。比如："我的文档是技术手册，特点是章节结构清晰但代码块和表格多。切分目标是保证语义完整，避免把一段完整说明拆散。所以我先按标题层级切，遇到代码块和表格单独处理不切分，超长段落再用递归切分兜底。验证下来，相比固定长度切分，检索命中率提升了大概15个百分点。"

这里有个细节要注意：切分粒度不是越细越好，也不是越粗越好。太细会丢失上下文，太粗会引入噪声。你要能说清楚你的文档特点决定了你偏向哪一边。

4.2 "检索效果不好时你怎么排查"

这个问题考的是排查思路。很多人会直接说"换更好的embedding模型"，这是典型的跳步。

正确的排查链路应该是分层的：先看是召回问题还是排序问题。如果正确文档根本没被召回，那是召回层的问题，要检查切分、embedding、检索方式；如果正确文档召回了但排在后面，那是排序问题，要考虑加rerank。再往下，如果是召回问题，还要区分是query理解问题还是文档表示问题。

我一般会建议用"黄金问题集"来定位：准备一批已知答案的问题，看正确文档在检索结果里的排名分布。如果大量正确文档排在10名开外，说明召回有问题；如果都在前5但最终答案不对，说明是生成环节的问题。这个排查方法讲出来，面试官会觉得你有体系。

4.3 "多轮对话怎么处理的"

RAG项目一旦涉及对话，就绕不开多轮。用户第二句问"那这个呢"，你得知道"这个"指什么。

处理方式有几种：一是query改写，把带指代的问题改写成独立问题再检索；二是把历史对话拼进检索query；三是维护对话状态。每种方式都有代价，query改写会增加一次LLM调用，拼历史会引入噪声，维护状态复杂度高。

你要能说清楚你选了哪种，为什么选，效果如何。比如："我用了query改写，因为我的场景里用户追问比较频繁，指代消解是刚需。代价是每次追问多一次LLM调用，延迟增加约300ms，通过缓存高频追问模板来缓解。"

4.4 "知识库更新了怎么办"

这是工程问题。教程里的知识库是静态的，真实场景里文档会更新、会新增、会删除。

回答要覆盖几个点：增量更新怎么做（只处理变化的文档），向量库怎么同步（删除旧向量、插入新向量），缓存怎么失效（如果做了检索缓存）。如果知识库规模大，还要考虑更新的批处理和限流。

我见过一个比较好的回答："我把文档做了版本管理，每次更新只重新处理变更的文档。向量库用文档ID做关联，更新时先删后插。检索缓存设了TTL，文档更新后缓存自然过期。对于大批量更新，走离线任务队列，避免影响线上检索。"

4.5 "怎么防止模型胡说"

RAG的核心价值之一就是减少幻觉，但RAG本身不能完全消除幻觉。面试官问这个，是想看你对幻觉来源的理解。

幻觉可能来自几个环节：检索没召回到正确文档，模型基于错误上下文生成；召回了但模型没理解对；上下文里根本没有答案，模型硬编。对应的解法也不同：检索问题优化检索，理解问题优化prompt，无答案情况要设计拒答机制。

拒答机制是个加分项。你可以说："我在prompt里明确要求，如果上下文没有相关信息，必须回答'根据现有资料无法回答'，并且我在评测集里专门加了拒答类问题来验证这个机制的有效性。"

4.6 "这个项目如果重做，你会怎么改"

这是开放题，考的是反思能力。好的回答应该体现你对项目局限性的清醒认识，以及你对更优方案的理解。

比如："如果重做，我会在项目初期就建立评测体系，而不是最后补。因为评测前置能让我更早发现切分和检索的问题。另外我会把文档解析单独抽成模块，因为实际做下来发现这块的复杂度被低估了。还有我会考虑引入agentic rag的思路，让检索策略能根据问题类型动态调整，而不是一套策略打天下。"

这个回答里提到了agentic rag，说明你关注领域前沿，同时又能落地到具体改进点，比空谈"引入大模型微调"要实在得多。

5. 从RAG到Agent：让项目叙事更有延展性

5.1 为什么单纯RAG在简历上越来越不够看

这两年RAG从新鲜概念变成了基础设施。会搭RAG的人越来越多，单纯"我会RAG"已经构不成差异化。招聘方现在更看重的是，你能不能把RAG作为组件，嵌进更复杂的系统里解决问题。

这就是Agent方向火起来的原因。Agent的核心是让模型自主决策、调用工具、多步执行。RAG在Agent体系里，往往只是"知识检索工具"这一个环节。如果你能把RAG项目升级成Agent项目，叙事空间立刻大很多。

但我要提醒一句：不要为了追热点硬套Agent。如果你的场景确实只需要单轮检索问答，硬加Agent反而显得画蛇添足。Agent适合的是那种需要多步推理、需要调用多个工具、需要根据中间结果调整策略的场景。

5.2 把RAG包装成Agent的一个具体思路

假设你原来的项目是"技术文档问答"。升级成Agent的思路是：让Agent先判断问题类型，事实型问题直接检索，对比型问题分别检索再综合，操作型问题检索后还要调用代码执行工具验证。

这样一改，你的项目描述就从"RAG问答"变成了"基于Agent的技术支持助手，能根据问题类型动态选择检索策略和工具"。技术含量和叙事层次都上去了。

具体实现上，可以用LangChain的Agent框架，把检索封装成tool，再配上其他工具（比如计算器、代码执行器）。关键是要设计好路由逻辑：什么情况下走检索，什么情况下走其他工具，什么情况下需要组合。

我帮人改过一个类似的项目，他原本只是RAG问答，我建议他加了一个"问题分类-策略选择"的前置环节。改动不大，但简历描述从"实现文档问答"变成了"设计基于问题类型的自适应检索策略"，面试时的可讲内容多了好几倍。

5.3 Agent项目在简历上的描述要点

如果你决定往Agent方向包装，描述时要注意几点。第一，突出决策逻辑，不要只写"用了Agent框架"，要写"Agent根据问题复杂度决定检索轮次"。第二，突出工具编排，说明你集成了哪些工具，工具之间怎么协作。第三，突出失败处理，Agent执行失败时怎么回退，怎么给用户兜底。

这里有个常见误区：很多人把Agent写得很玄乎，什么"自主智能体""全自动决策"，但一问细节就露馅。Agent的本质是"LLM+工具+循环控制"，你要能把这个循环讲清楚：什么时候继续，什么时候停止，停止条件是什么，异常怎么处理。这些讲清楚了，比堆概念强得多。

6. 简历之外：项目经历的真正价值在哪

6.1 项目是拿来"讲"的，不是拿来"列"的

我改简历这么多年，最大的体会是：简历上的项目描述只是引子，真正的价值在面试时的展开。你写"优化了检索策略"，面试官一定会问怎么优化的。如果你答不上来，简历写得再漂亮也是负分。

所以改造项目的重点，不是把描述写得多花哨，而是确保你对项目的每个细节都了如指掌。你知道为什么这么设计，知道替代方案是什么，知道效果数据，知道踩过什么坑。这些东西在脑子里，简历上随便怎么写都能接住追问。

我建议的做法是：先别管简历怎么写，先对着项目问自己二十个"为什么"。为什么用这个切分粒度？为什么选这个embedding模型？为什么检索TopK设成5不是10？每个为什么都能答上来，简历自然就好写了。

6.2 一个可复用的项目复盘模板

我平时帮人复盘项目，会用下面这个模板。你可以拿它来梳理自己的RAG项目：

• 场景：解决谁的什么问题，有什么约束
• 难点：技术上最难的点是什么，为什么难
• 决策：面对难点做了哪些选择，为什么这么选
• 验证：怎么证明选择是对的，数据是什么
• 局限：项目还有什么不足，如果重做会怎么改

这五块填完，你的项目就从一个模糊的"我做过RAG"，变成了一个立体的、有细节的、经得起追问的经历。简历描述从这五块里提炼，面试展开也从这五块里展开，前后一致，可信度自然高。

6.3 别忽视"软"的部分：协作、沟通、推进

最后说一个容易被忽略的点。技术项目不只是技术，还有协作。你在项目里怎么和产品对齐需求，怎么和运维协调部署，怎么推动一个技术方案落地，这些"软"的部分在简历上也可以体现，而且往往是区分"执行者"和"负责人"的关键。

比如你可以写"主导技术方案选型，输出对比文档并推动团队评审通过"，或者"与业务方对齐评测标准，将主观评价转化为可量化的命中率指标"。这类描述传递的是你不仅能写代码，还能推动事情往前走。

当然，这部分要基于真实经历，不能编。如果你确实只是执行角色，那就把执行做到极致，把技术细节讲透，一样有竞争力。最怕的是技术细节讲不清，协作经历又编不圆，两头落空。

我在实际帮人改简历的过程中发现，那些最终拿到好offer的人，往往不是项目最"高大上"的，而是对自己项目理解最深的。他们能把一个看起来普通的RAG项目，讲出场景的独特性、决策的合理性、排查的体系性。这种深度，是任何模板都包装不出来的，只能靠真正动手、真正思考、真正复盘积累出来。所以与其纠结简历怎么写，不如先把项目做扎实，把每个环节都想透。项目扎实了，简历只是水到渠成的表达。