阅读指南和学习建议

前言

笔记/路线设计思路

大家好啊， 我希望设计的这份资料是：自学入行大模型应用开发的最全的记录。

为什么是自学路线？

我是从0开始自学的，自学了200多天，面试了2个月，拿到6个Offer（夸克千问，京东（算法岗），SAP（世界500强外企），网龙，平安证券，华林证券），所有信息小红书可查。

这份资料是按照我自己学习自学路线，我希望把我完整的自学路线，心得，笔记，面试重点，都分享给大家，让自学的人少走弯路。

笔记包括：详细的大模型八股，知识点参考资料（视频，文章），讲解视频，项目实战（源代码，设计思路，讲解视频）。项目实战是可以直接写在简历上的。

我的所有笔记的来源，是可以在我的小红书笔记中看到的，都是我根据面试总结出来原创的，而不是随便搬运网上，这个真实可查。

为什么是最全记录？

因为我在转行路上，所有的心得，笔记，复习资料以及所有的面试记录都记录在这里面。这也是我自己学习的资料，我在面试中任何发现面试出现的问题，我都会补充在里面，分析出题频率，复习思路，面试的最真实完整的记录，还包括岗位介绍，面试反思。从0开始到上岸，这份笔记记录了我所有的学习资料和心得感受. 这份笔记会更新到我真正入职新公司，真正转行完成。到目前为止我也在一直不断地更新这份笔记，一旦发现问题，就会补充迭代，这份文档会越来越完整。但到目前为止，其实内容已经非常详细和完整，对于一般的面试都足够了。

适用人群

自学进入这个行业的社招同学和校招同学。 大家完全可以先按照这个路线和笔记去学习，我后面更多更新的是一些更高级，更深入的进阶技巧，支持获得更高薪资的岗位的一些技巧和知识。并且整个笔记我都想告诉你的是，哪部分最重要，这部分为什么要学，这部分怎么学，除了知识部分，我更想告诉你的是学习的思路和方法。

为什么要从应用入手？

对于转行或者想进入这个赛道的同学，大模型应用相比大模型算法/Infra, 大模型应用是最好入手的。大模型算法/Infra 技术难度相对更大，需要你对深度学习/机器学习 有比较深入的了解， 同时也需要比较高的硬件资源来支持你完成相关的实验和项目， 同时很多大厂在算法这一块对背景的要求同样更高，倾向于有论文/有竞赛的背景。所以，如果你是想入行，从算法/Infra上入行，明显难度更高，从进入这个行业的角度来说，从应用侧切入是更好的选择？我的项目是面向于应用的，应用的笔记非常详细。但是同时，针对于应用的岗位经常也会问算法，我的整套学习路线包含了一些算法：微调/模型推理/压缩（量化） 的知识。对于大模型应用岗位来说，这个足够了。这样的设计让大家既有广度，又能抓住重点。

对于很多同学，你的目标如果是入行大模型，那么其实你从应用入手，把算法相关的东西过一下，你就可以去面试，不用特别复杂的深度学习，前后训练相关的算法知识。不过，这份笔记也会包含更进阶的内容，就是你想要挑战算法，算法工程。相关岗位的同学们，这份笔记也会包含相应我学习算法的内容，也是我正在更新的部分。学习算法，一个是有利于提高薪资，算法的薪资明显高于应用。另外其实也有助于让我们面试的时候有更多的选择。我的建议仍然是如果你没有算法基础，你是纯开发，甚至是转行，先学好应用（我自己也是学了大半年，应用拿了Offer 6个offer后，我才开始慢慢学算法），虽然我们文档也会记录算法内容，但是请注意自己的目标和学习重点，当然我后面具体学习路线会说的。

路线/笔记的设计思路

1.提供可写简历的实战项目

我在做一个RAG-Agent项目，这个项目也是我自己用来学习，准备写在简历的。

我用了很多方法帮助大家理解，掌握这个项目：提供详细的项目设计文档（看目录的项目实战），提供讲解视频，将代码分成几十个commit的节点，每个节点完成一个小的事情。这些做法，都是能够帮助大家更好掌握项目的。

另外这个项目有通用性，支持扩展，可以针对于每一个人的具体业务去展开，后面也会给大家参考这个项目如何写在简历等等。

目前这一套项目是已经完成了的。除了项目之外，在readme中写了完整的思路，就是不同的人群如何去使用这个项目。

项目包含的如何用AI完全完成这个项目，如何用AI去写简历，如何面试前突击RA进行模拟面试，项备，如何用AI一键setup这个项目，我都写成了SKILL。这整套方法其实也很值得学习，学了以后你会知道自己如何写一个新项目，可以完全复用这整套方法。

目前已经有人拿这个offer去面试，去了暑期实习的offer，相关内容可以看我小红书笔记查证。我自己也会去用这个项目面试，后面会变成面经形式补充进来。

目前这个项目后续的规划是扩展更多的面试真题。

另外非常可能的是，我们后面会有一个算法的项目。我目前在学习算法进阶路线，后面肯定要弄个项目，所以整个过程也会记录，到时候会有算法项目。具体算法学习其实你可以看我小红书笔记，我目前在学pytorch，学完所有的路线我都整理好，大家照抄。

2.完全面向面试知识。

这份笔记目标非常明确，分为知识/八股部分和面试实战部分。这两部分都是完全面向面试的，完全是根据面试的重点来总结的。

知识部分都是面试内容总结的，面试出现就总结，不出现就不总结。知识部分适合自己根据学习路线和知识/八股 去总结，理解，学习，背诵八股。

面试实战部分完全真实的面试题目，而且都比较新，标记有时间。 我设计这一部分的思路是：

1.完整。 面试部分的记录是我根据我自己面试录音一个字一个字扒的，保证完整真实。

2.包含岗位jd 和反思。 每个面试我都收录了岗位jd，因为我希望大家可以通过岗位和知识点去推测和关联出一些重点，体会不同的岗位要求可能会面试什么内容。 反思部分是我自己面试完的一些感受，供大家参考。

面试真题也在持续总结，比如我25年12月面了十几家公司，以及笔记里这个项目粉丝投稿的真题，以及我26年面试的内容，都会补充。

3.弄清楚什么是重点

我特别希望告诉大家的是什么是重点？为什么要复习某一部分，因为我觉得自学的同学最困惑的是抓不住重点，资料那么多，要学哪个，为什么要学。

所以我设计资料的时候，基本在每个笔记开始前会写一些注释：告诉大家这个知识点出现的频次，是不是必考的。 有的知识点是针对于我个人情况而问的，我也会告诉你，让你酌情参考。 有些地方我也设计的是一些拔高的，不是面试官问的，但是是我自己准备的一些亮点，是靠我自己引导面试官去问，然后借助这个契机给面试官讲解从而加分的。 每一部分资料是针对于什么情况设计的，我都会告诉你，希望你复习的时候做到心中有数，也结合自己的情况针对性复习。

另外在每一个面试实战的视频讲解和笔记中，我也会告诉你什么是重点，面试官为什么问这个问题？我为什么这么回答。 除了笔记部分，我特别教会大家的是对考察重点有一个自己的判断。

4.每个面试实战内容都会有视频

每一份面试实战部分，都会对应视频讲解。视频讲解会讲解知识点，更多的想和你分享面试的技巧和感受，以及对重点的把控。 这个讲解视频我会按照顺序发在我的x站视频账号中，预计一周1\~2更，请大家放心，笔记里出现的面试实战内容x站就会有对应视频讲解。

5.行业新知识

我会持续关注行业的动态。比如这份笔记是25年12月上线的。但是基本到现在（26年3月），我是一直在几乎每天更新的。 除了上面的内容外，我会关注行业知识，比如25年年底才推出的SKILL，26年初火起来的Openclaw。这些都有总结。我会关注行业动态，行业里什么要考，我们会一起讨论，我都会持续跟进。

6. 其他内容

那可太多了，我可能列不完，因为基本上我觉得对大家有帮助的，对我有帮助的我都记在这个上面。所以你看除了我提到上述内容。笔记还有大模型岗位介绍和学习建议，粉丝的提问和答疑（相信有朋友有共同的疑问，行业困惑，所以我汇总了大家都能参考），论文导读（读论文也很重要，即使是开发岗，原因论文导读一栏写了）, VibeCoding 推荐视频（其实这个适用于所有人，包括产品，新时代如何用AI编程，未来如何发展），面试技巧（简历如何写，自我介绍怎么介绍，反问问啥）

总之是在学习路上，我认为有帮助的都会总结，未来也是，我很难说会有啥内容，但是在我学习，了解行业的时候，只要我认为对大家有用，就会补充进来。

7.配有参考资料

我会整理学习路上自己看的视频，文档，参考资料。都会以内嵌链接的形式推荐给大家。所以笔记内容很丰富，除了我整理的文字，还有很多视频和推荐书籍，论文。

我会提供给大家一些我学的SKILL。特别是算法部分。因为我在学算法的时候，其实是26年了，26年SKILL出来以后，我就觉得特别好用。所以在算法这个部分，我很多时候依赖于SKILL，比如我学习Pytorch的时候，我写了SKILL，里面包含了我推荐的视频，编写的教案，相当于你用它就可以直接按照我的路线，让AI给你讲。在算法部分，我想是提供各种SKILL，Pytorch入门教学SKILL，前后训练SKILL等等，这些是我的学习来时路，分享给大家，大家在算法部分学习方向，资料方法就特别完整了。

8.优化和迭代

我希望能以最好的笔记，最优质的内容呈现给大家。请大家购买后可以进入这个小红书笔记交流群，可以交流一些笔记的内容，重点，疑问，我会尽量回答，也欢迎大家讨论，我会根据大家的讨论，后续也会补充一些内容和心得，我们一起完善这个笔记。文档是开放评论权限的，大家可以提问题和讨论，有问题我都会fix。但是注意的是因为这个涉及多份文档的拷贝（一份文档最多500人），所以我在用自己写的拷贝脚本拷贝的时候，评论会被冲掉，还请理解，如果提了评论我没处理，可以多提几次。

大模型应用/算法学习路线

在制定学习路线的时候，每个人的情况：校招，社招，学校层次，工作年限，之前从事的方向，给自己预留缓冲的时间是不一样的。所以我希望先讲清楚思路，原理，大家在参考的时候也需要根据自己情况调整。

首先是先看岗位，具体可以看笔记：大模型岗位介绍部分。粗略地说：大模型分为算法工程师（前后训练），推理工程师（负责模型推理），应用开发工程师（做agent,rag,垂类应用），数据工程师（准备数据）。但是，现在的趋势是：岗位之间倾向于融合，交叉。

比如算法工程师：很多时候要自己做数据。我们公司的同事，我问他做啥，他说是做模型训推，也就是推理，训练都做，同时算法岗位也会要求了解Agent,RAG.

比如应用开发工程师：Agent,rag这是要专精的，但是很多又会涉及微调，推理框架的。所以现在的趋势岗位对于人才的要求是复合型，多少大家都得掌握。所以这一点告诉我们求职大模型需要广度。

但是大家也不用慌张，不用害怕企业要求这么多东西，我怎么能学会呢？大模型太难了吧？你要知道的是，企业确实要求这么多，但不代表你一定要把这些都学得非常好才能拿到offer。大部分人求职不会要求你又广又深，如果真的是每个都掌握得很好，年薪肯定100以上了。所以不用太害怕，你需要广度学习，但是第二个请大家记住的是，你也需要抓住重点，选择自己合适的路线。

比如上面我所说的，建议大部分人是应用入手，深入应用，了解算法，这样去求职，入行。进阶的话，就是算法也学深一点，然后做算法工程，甚至算法。或者先学好了应用，先入职了，再慢慢转。那你一上来的路线一定是先学好应用啊，做几个项目啊，别在pytorch，推理框架，前后训练那些算法的原理，数学公式上纠结了。我的实际经验是，你把算法的流程走通，微调怎么做的弄清楚，甚至没有真的做，然后了解相关概念，面试官大概率会问你怎么做的微调，准备下相关问题，笔记里写的有，目前这样就够了！你去面试，肯定有offer的，如果你还有时间，那可以去学Pytorch， 手写attention， 微调，你的路线是这样的，这也是我的路线。原因是门槛低，另外我本身就是开发路线的。

另外如果你是算法出身，本身就会pytorch，训练微调都做过，那我也是建议你直接转算法啊。那么训练算法，论文就是你的强项，你要深入学习的。当然你需要了解Agent,RAG, 这是你的加分项。

所以我们也要找准方向，你的优势，路线是什么。下面我讲学习路线的时候，是一张大网，你需要根据你的实际情况去调整的。我真的不希望一个小白，刚入行大模型，agent还没学会，就迷失方向，去手撕attention，看深度学习的论文，然后被劝退了，这样我会很伤心的。

我把大模型学习路线图分成以下几个部分，然后具体讲解。

Agent, RAG, 后端知识，前后训练，模型推理，行业素养，项目。

Agent:

1.python基础： 如果完全没有Python 基础，需要先学语言，找一些0基础快速学习Python 视频（x站搜：python入门零基础），不用过于较真语法，会用就好。因为实测面试上考察python 具体语法的并不多，这里学习是保证你看得懂，改得了代码。

2.入门了解Agent：你需要对Agent 特点，怎么做的有一个印象和概念。可以结合一些Agent的入门介绍视频，比如Tina老师的介绍视频：https://www.youtube.com/watch?v=qU3fmidNbJE。

清华大学出版社的《AI Agent开发与应用 - 基于大模型的智能构建》这本书质量不太行，但是好处是特简单，容易读懂上手，也有一些很简单的Agent的例子。也可以通过这个例子去上手。

了解Agent是啥后，可以跑一个100行左右的Agent代码，调用通LLM， 来感受一下这个过程，比如你跑跑这个例子：https://zhuanlan.zhihu.com/p/1922809649868022076

3.MCP/Function call： 了解这俩是啥，常见概念，可以对照我笔记去看。依然推荐Tina老师入门MCP 视频:

https://www.youtube.com/watch?v=kOhLoixrJXo

其实YT有非常多MCP 很好的视频, 讲得很清楚：

爬爬虾老师讲得也很好：

https://www.youtube.com/watch?v=McNRkd5CxFY

里面介绍了一些MCP 的功能，可以上手去试，去感受。

4. Agent框架。 最常见的是Langchain三件套：LangChain, Langsmith,Langgraph，如果没有倾向，就学这个，用这个面试也会问这个比较多。这个网上视频就很多了。

比如入门视频：

https://www.youtube.com/watch?v=1bUy-1hGZpI

不过这里推荐大家稍微学深入一点，可以在YT里找相关视频。

一些典型低代码平台，扣子，Dify可以去了解下，虽然很出名，但是我面试感受下来没怎么问到，可以知道下概念。

5.Agent评估方法，很重要。我的笔记里有整理，这个常考，所以你要熟练掌握，具体八股部分 Agent的性能评估里以及里面推荐的参考资料，必须一些Agent的论文（比如美团龙猫的评估），这些都可以作为Agent评估的学习资料。

6.Agent设计范式。 直接推荐了这本书，把它放在学习路线上，因为他设计很多面试考点，然后有一些知识，比如React，我路线没有，他也都有补充，推荐大家阅读，这个网上可以免费看。顺着这本书去读，他其实就串起了Agent应用的各个部分，记忆啊，React啊，跟着他的思路，把Agent的技术掌握了，可以顺着书，一边读，一边搜一些资料。

https://github.com/fzy2012/rhzl-Agentic-Design-Patterns-cn

7. SKILL. SKILL很火，已经是必考的了，是26年火起来的。常见的问题：是什么，怎么用，你用SKILL做了啥。我们的笔记SKILL章节整理的很全面，本身并不难，怎么学习在SKILL章节有详细介绍和推荐视频。

8. 提示词工程

看Tina老师这一个视频，把它消化好就行, 思考清楚提示词工程涉及原则和常用策略，注意应用到你的工程就好。面试考的少，看完这个视频知道推荐的提示词怎么写，有什么常见策略就行。

https://www.youtube.com/watch?v=p09yRj47kNM

9. 复杂的Agent 实战，比如我说的书《AI Agent开发与应用 - 基于大模型的智能构建》，就有很多的实战例子，可能代码会长一些，跟着写，跑一跑。或者自己找个复杂点的Agent项目，去跑一遍，感受一下。也可以看一些经典的Agent的例子，比如说Openclaw（笔记里有讲），本身也开源，包括我提到的Claude Code 25年举办的Hackathon，看一下这些项目Agent怎么实现的，思路是啥。

10. 理论上经过了上面的学习和沉淀，你对Agent是啥，而且也让大家看了简单的，复杂的Agent的项目，理论上你就可以具备开发Agent项目的能力了。这时你该设计一个项目了，从项目选题，立意，用什么框架开始思考。项目设计就是可以参考openclaw，现有成熟架构，怎么设计我的RAG项目里的视频讲解有写，思路完全可以复用我们的RAG项目，学会了笔记里的RAG项目，你就按这一套来完成Agent项目。

RAG:

1.RAG 入门体会：还是可以看看视频讲解快速入门。

类似快速入门视频很多，大家去搜搜，用个几个小时去理解一下。

https://www.youtube.com/watch?v=WWdlme1EAGI

我自己也看了清华大学出版社《大模型RAG应用开发 - 构建智能生成系统》 说实话质量依旧不行，但好处是简单，看下来很快，也有很多例子。不过YT上也有很多人讲解的时候，附带有代码，你可以去找一下，照着它的视频和代码跑一下，入门RAG.

2.向量数据库：了解向量数据库是什么，常见的向量数据库，为什么RAG要用向量数据库？

https://www.youtube.com/watch?v=gl1r1XV0SLw

我自己还看了这本书《大模型RAG实战-RAG原理，应用于系统构建》 这本书质量可以，可以买，这本书vx读书好像也能搜到。很多面试内容后面我都从这本书上去查。不过第一次看可能有点难懂。这个书上也有一节讲向量数据库。

3.RAG的具体过程和策略:

这个就非常重要了。 整个RAG中涉及的各个步骤，你脑袋里要知道他们是怎么串起来的。 知识库准备，切块，召回，召回的优化，以及效果评估。这些每一步都很重要，面试最高频考点。

《大模型RAG实战-RAG原理，应用于系统构建》 这本书都有，我的笔记也照着这个总结的，不过大家可以搜搜RAG深入讲解视频，把这几部分搞清楚，这就是面试最常考的。

4. RAG新方向

Graph RAG 和Agentic RAG. 可以看一下我笔记的概念介绍，这是RAG的进阶方向。一般并不是所有岗位都需要特别深入的RAG的，所以这里看是否有余力深入学习，我个人没有深入学习。如果你需要从事偏RAG技术的岗位，那是有学习的必要，如果是普通Agent/应用方向，算法方向，那么可以先放一下，先把概念了解。

5. 项目实战

笔记中有一个RAG项目，就是把RAG的各个环节串起来了。有了上述的理论基础，相信你可以做出来这个RAG项目，就去参考笔记的RAG项目部分吧，可以作为RAG知识的学习扩展，也可以作为简历项目，进行包装。

后端知识

对于后端知识的要求。推理岗>>应用岗>算法岗。以应用方向为目标，最好还是知道一些后端知识。Docker, k8s, 容器化这些是简历Jd经常出现的。坦诚地讲，我现在也没学，而且也暂时没管它在学算法。因为我的目标是全栈，算法工程。这个不会也没妨碍我拿offer。 要学的太多了，你们看这个路线也可以看出来的，事情有轻重缓急，根据自己路线定夺吧。

你要是不做算法，那么应用学完了，可以学一下后端。提升竞争力，否则可以和我一样，先去学SFT, 强化学习了。当然后面我学完了可能回来补，目前这块没有。不过笔记中岗位介绍以及其他地方说清楚了后端到底要补啥，大家可以看着关键字自己学。

前后训练

其实前后训练这个概念很大了，直接概括了算法同学的工作，里面水也很深。算法本身就是应该出个专门的学习路线，算法本身不同岗位差别也很大，有些算法岗主导创新，要发论文的，那种年薪几百万。腾讯招的ysy, 小米的天才少年，人家都是算法岗。我这里的路线还是以应用侧转行到大模型，有余力进阶学习算法的同学的路线来讲解。

1. 常见的概念：弄清楚前后训练，推理在大模型行业的流程，怎么和应用交互的，前后训练是干啥的，有哪些常见方法，微调，强化学习是干啥，有啥好处。
2. 了解面试问题：走一遍流程，不管是微调，还是强化学习，稍微了解下代码，假设真的走一遍，流程是啥，要哪些代码。

学习了a,b 我相信就能回答出来常见的面试问题：你是怎么做微调的，你是怎么做强化学习的。微调是啥。这些我笔记整理的都有。a,b 是所有人都要学习的，即使你没有走到算法进阶，学一下a,b 不会花多长时间。

这里我想说的是，学习a,b主要是为了，面试官问你：你了解微调，做过微调么？的问题的时候，你说了解，做过。注意这里不要露怯，因为你只学了这么多，你就害怕，主动承认说了解不深，没必要，很多面试官都深入问了。按照我们笔记里怎么做微调的方法，想好，就行。 如果真的深入问了，答不上来，再说了解不多。

好了，接下来路线是你要进阶学习，学好了应用，冲击应用算法，算法工程，算法的岗位，要学的。

1. 深度学习/pytorch：我们不求深入，很多学生学深度学习是抱着深度学习书籍，公式学习来的。我们面向找工作，绝对没那么多时间。我们的目的就是入门，因为大模型网络是深度学习经典网络基础上发展来的，所以我们要了解之前的传统网络，前向传播，反向传播的知识。 我们要学习pytorch，是因为这是我们做微调，训练的工具呀。 以快速入门为基础学习。
2. 现代大模型知识：强化学习，SFT等大模型相关后训练方法，这个就不是上面a,b说的概念了，深入原理，pytorch代码，公式学习。
3. 开源项目/论文：c,d打好了基础，那么e就是调研了，为我们实战项目做准备。调研现有项目，人家怎么做的，达到什么目标，怎么评测。
4. 实战：有了上面基础，我们会做一个小的Project，真正去实现强化学习，微调，提升效果，做训练，最后结题写一个小论文，说明你做的事情，方法，评测，参考论文。
5. 简历包装：有了实战(f）步骤，想想怎么写在简历吧，和你的业务结合。写好了要投递面试了。
6. 面试和迭代: 其实这是所有方向都要做的。面试根据反馈，改进技巧，改进项目。

有没有注意到本节没有推荐任何视频。那是因为我正在学习！而且我会有更好的方式呈现给大家这个路线。我还在c阶段，马上要完成c阶段了。c\~h的所有阶段，我都会总结好最方便大家的形式去学习，包括思路，参考资料。有些地方准备以Skill的形式。 也就是说到时候c\~h我提供完整的学习教程，大家跟着做就行了。

推理

还是一样的，推理框架需要丰富的后端知识，以及模型推理框架，优化的知识。目前的侧重还是说掌握概念，大体方法。有哪些推理框架，剪枝，蒸馏，量化的概念。不会深入学习和实战。这些概念在笔记：模型推理加速 都有。

至于为啥不深入学习，原因很简单，时间有限。学完应用去学算法了，学完算法再学后端，学完后端再学推理。 这是我的路线。不是所有人都要都学完的，很多人基本是学完应用就能上岸了，总之根据自己情况慢慢来吧。

行业素养

我把这个专门作为一个考察的方向，其实他也很重要，这是在我不断面试的时候才慢慢总结出来的。他不是硬知识，问你专业问题。而是素养。比如面试官问题：你使用什么AI Coding工具呀？你有没有了解过Openclaw啊？你平时怎么用AI工具的呀？你看过哪些论文 吗？

这些问题看似不经意问对吧，之前有面试官问我用什么AI Coding，我说我只用过copilot，其实就很掉分，可能这就是默默给我没过的原因。

其实这些问题很重要，体现你的行业素养。比如用什么AI 工具，怎么用的？这是体现你有没有积极拥抱AI，用AI的技巧。比如你使用copilot ,claude code，他们可能各有优势，你有没有了解他们的优势？他们的进阶用法？没有的话，说明你这个使用AI的技巧不行。

你有没有了解Openclaw?如果你没了解，说明你没有关注行业动态，他作为Agent行业爆款应用，他有哪些特点值得学习？你竟然没去看吗？面试官觉得你不了解行业动态。

包括论文，大模型这个行业需要读论文的，即使是开发，原因我在论文章节提了。

所以我把这些归为行业素养，但他同样很重要，在面试中考察频率很高。

这块怎么学习，与时俱进吧，抓住动态。当然我自己一直在总结，比如新的东西，Openclaw的架构，SKILL， 论文这些都是在笔记中的，我也在实时关注，给大家总结，大家看我小红书，一起讨论，一起更新。

项目：

其实所有上述理论的学习，都是要有个项目。转行的人，有个项目你才能去面试对吧，你没有项目，你是做c++的开发，拿个c++简历去投大模型，清北的都没面试机会。

应用的项目：

我在RAG项目中写了非常完整的如何从0做一个项目，从立项到选题，到开发，到面试突击，你就看这个内容，而且它可以复用到Agent。

算法项目：

在笔记 ：算法0基础学习全记录章节，会记录完整学习算法过程和怎么弄项目（注意在更新中哦，这块内容），大家直接参考就行。

所以项目就不多讲了。

问题说明

此部分总结群友问题。

1.为什么看上去强化学习这一块内容不多？

因为所有知识我都是根据面试总结的。面试考的越多，我就总结的越多，越深入。面试考的不多，就几乎不会出现。笔记是面向应用路线的，强化学习部分我自己的复习思路就是带一下，我只是了解了一个皮毛，然后做了一遍流程，加入在了我的项目介绍中：我做了推理优化：量化-微调-DPO 之类的，做到这里就够了，面试官问我，我就讲这一套，并且面试官从没有深入问DPO的细节，所以对于强化学习没有深入笔记。

我希望笔记是面向面试的，是精而专而不是大而全。 如果是面向与应用岗位，去学习很深入的强化学习知识，甚至是数理公式，在目前看来（至少在面试的角度上来说），是性价比不高的。从笔记你也可以看出来，笔记篇幅多的一定是常考的，没有笔记或者占比较少的，一定是不常考的。

现在关于算法（微调，部署，强化学习，后训练相关）的这一块内容，你可以理解为是我在第一阶段去面试，当时是我以应用为主，算法只懂皮毛，满足面试基本要求总结的。我的建议也是第一个阶段算法不用学太深。懂我笔记里总结的就行了。

当然，如果你差不多学完了应用，开始进阶学习（像我一样，我是学了大半年开始，准备深入算法学习了）。关于算法的部分，微调，pytorch，强化学习，请你去看 算法学习专题。 其实这里面就蕴含了大量的八股知识，比如后训练是啥，SFT， LoRA。 我没有往笔记总结，是因为我希望笔记里的内容是面向面试的，我总结的都是面试常考的，根据面试题反推的。等我开始面试算法了，再会把算法的内容整理到笔记。如果你现在想学算法，可以按照 算法学习专题 的思路，把它学好。（但如果什么后训练你都会了，开始面试算法了，那么其实你学在我前面了，算法更深入的部分，笔记还没总结，进阶算法学习要靠你自己了（写于2026/5/8，不过我也在继续学习，也许你再看笔记的时候，笔记已经更新算法进阶内容了也说不定））

2.为什么没有多模态？

同上。 多模态属于应用部分，但是我面试下来，他不是硬性要求的。除非很少数的岗，本身做多模态，他可能会有点考察。以我的经验，没有多模态经验，不太影响面试，我个人对多模态这块是完全没经验的，如果面试官真要问我，我准备直接说不会。但所以这里确实完全没涉及。所以我不会多模态完全不阻碍拿offer，所以我这里没任何笔记，自己也没学。 当然如果你自己想做多模态方向，那么你需要自己补充下相关知识。

3.文档评论问题

文档开放评论，有问题也会处理，不过注意一下，因为文档有自动同步机制，大家看到的文档可能是副本（一份最多500人），副本是从第一份文本同步过去的，但是同步没法同步评论，所以你评论了，下次同步后评论会被清空。如果评论有问题，我没有修复，可以在群里说，我会修复。至于比如你用评论做笔记啊这些，就没法保留了，不好意思。

参考资料说明

在笔记的知识部分，比如Agent, RAG，相关内容，我是根据面试重点总结的。所以出现在这里的内容，你需要掌握，我也给了很多参考资料。但是值得一提，学习的时候，是要按照这个线索，去看我提供的资料也好，自己找资料也好，去理解它。有的地方我写的比较泛，更多的是作为八股的总结，就是让大家去参考背诵，理解的，而不是说你只看我的资料就能学会。比如我讲RAG，我是要最重要的要点总结的提纲，但里面具体细节，我推荐了书，视频，如果理解不了，大家自己要再补充一些资料。

另外，参考资料这一块，有的地方是Youtube视频，需要科学上网。

第二个，如果是英文，没关系的，现在下面开字幕，实时翻译成中文。

第三个，教大家一下，在youtube下面有字幕，点字幕，右边会有对应字幕列表，你把他复制到ai工具中，可以让AI帮你理解，一边看视频，一边提问。

第四，参考资料叫参考，不是必看。如果你看文档就懂了，那你就不用看参考资料了，有的地方，我列出参考资料是告诉你我做笔记的来源，不过我自己其实已经反复看，把参考资料总结到笔记里了，要点我都总结了，你看懂了笔记不看参考资料完全OK。

另外参考资料不是唯一，你根据对应知识点，去b站搜索，youtube搜索相关视频，你觉得好，给你讲明白了这个知识点，就可以，大家自己灵活判断哈！

笔记学习顺序建议

因为自己是从0开始学习大模型的，所以我太知道0基础学习大模型的心得和建议。我根据我自己自学1年心路历程，踩到的坑，总结起来，给大家推荐一下学习路线。这份文档是我学习1年了可以说所有的学习内容，也一直在继续学习和更新，文档会越来越大，这块的内容也会定期更新的。

我以0基础大模型基础为例讲解。

先了解一下笔记思路和大模型岗位。 笔记/路线设计思路， 大模型应用/算法学习路线，问题说明，参考资料说明，大模型岗位介绍，包括我的各种小红书笔记。大概了解一下我设计笔记的思路，这个资料怎么用，这上面都讲的有。

我把学习分成两个阶段：阶段一：大模型开发保底 。阶段二：算法进阶

原因如下

1：大模型开发是最容易入行的。对于社招来说，有开发背景转到大模型应用开发，如果你之前还是做的后端，就更容易了。当然如果你是客户端，测试也没关系，我也不是后端转的大模型，我没有后端经验。所以学习大模型应用开发，是最快入行的。我个人经历是在2025年5月开始学，学到11月面试，面试了两个月，有挺多offer的，然后都没去。这个阶段我叫做阶段一。我不想一开始就学习算法，深度学习，训练，本身更难，算法天然门槛更高，所以应用起手，先入行。

学完了阶段一其实你就能找到工作，不一定要学阶段二，我亲身经历，我没深入学算法，已经拿了挺多Offer的。入行大模型了，工资也比传统开发高。

2. 学习算法进阶。学算法的原因很简单，都想追求护城河更高，薪资更高的岗位。大模型除了应用，还有算法（做后训练，或者叫infra），部署。这些要求比开发高，薪资高。当然他们也有弊端，是岗位少。一般做infra只有大厂才做，竞争激烈。我把它叫做进阶学习。

从另一个角度来说，即使你只是想从事大模型开发，学算法对于你找大模型开发也有帮助，有时开发岗也会问部署的东西，算法的东西。包括大模型这个行业，其实算法，部署，应用，都建议懂一些，所以如果学有余力，学习算法也是有必要的。

这个阶段其实也是我现在的阶段，我在26年2月吧\~现在，在陆续学算法的东西，做算法的项目。

接下来按照这两个阶段，告诉大家如何使用这个笔记：

阶段一：应用起手

1. 知识理解：Agent, RAG, LLM模型结构，模型微调，推理加速，AI通用素养。

顺着这些链接学习，其实这个笔记目前总结有一个天然的特点，就是按照阶段一要学的深浅总结的。你有看到Agent，AI通用素养部分，RAG部分写的特别多吗？llm模型结构，模型微调，推理加速写的少。这正是因为我这个笔记是纯粹面向面试总结的，根据面试内容反馈，来补充的。所以你应用起手的话，照着这个学，深度和这个笔记一样。应用的东西讲得很深入，而算法部分：模型结构，微调，推理加速，偏向了解概念，让你知道面试问到了怎么说，包括总结的如何做微调，如何做部署，里面总结了你如何不深入学习算法，面试官问道你也可以说你做过一些的策略。

顺着这个笔记学习，里面包含了很多的参考资料，和思路。也推荐了书籍。我又教大家如何用这些资料，请 参考资料说明。 你顺着这个笔记学习，以弄懂笔记为目标，看不懂看参考资料，顺着学就行。这块全是面试要考的。

论文部分： 这块不多，总结了2篇。防止面试官问你有没有看过什么论文，分享一下。具体看了面试怎么回答，总结的都有。

2.项目。自己做项目或者找现成的项目包装。笔记里有：

RAG项目，有全套资料，面试真题，可以参考。

Agent项目。我之前用的找工作项目之一。

算法项目。作为拔高项，设计SFT, 强化学习，部署。进阶内容，如果你学会了，可以作为简历一小块来提高你项目复杂度和含金量。没时间不学算法当然也可以。

这两个可以参考和借鉴，可以直接拿来用。不直接用里面也有非常多的思路，如何做项目，怎么设计，项目设计哪些东西。

同时有一些开源项目供大家参考，笔记里也有解析：PI-Agent. 这个项目特别适合于，你学习完了以后，自己看一下Agent的小项目，学习，研究，改造，甚至是封装成自己的项目，因为这个项目又小又权威，而且给了丰富的扩展机制供你扩展。

这三个东西 Hermes, Openclaw, ClaudeCode。特别是ClaudeCode，笔记里有大量资料讲解，包括面试真题也在使用ClaudeCode讲解，这三个也得看，看一下行业最火的Agent怎么实现，对你的面试和设计特别有帮助。不过提醒就是这些架构很复杂，别想着可以一下子吃透。建议是先学笔记的PI-Agent部分，再去CC,Openclaw,Hermes.

结合这些项目，思路，设计一个自己的项目。甚至如果你真没时间，用笔记讲的各种包装技巧，编一个项目，比如基于笔记的Agent项目，RAG项目，或者PI-Agent项目，包装成一个项目，放在简历，最少可以开始投递了。

把二阶段学了，至少简历有东西写了，可以开始准备投递了。

3. 面试真题。提供了大量的面试真题，包含讲解和解析。包括项目部分，其实也有对应面试真题，比如RAG项目真题，每个知识讲解里面也穿插着真题，看一下真题，自己复述一下，表达一下。里面所有真题答案的总结思路就是你学习笔记的总结，他们是呼应的，用真题可以检验你学的好不好，考前突击，模拟面试。

面试技巧章节，也可以看看。写了怎么自我介绍，反问问什么的面试技巧。

至此，你可以去投递简历了，去改简历，投递，面试，反思，复盘，自我进化，继续面试。 拿到Offer。

一些问题说明：

重点：

T0: 大模型应用，最高频/常考的是：Agent + AI综合素养（Vibecoding, CC，Harness,SKILL)

T0.5: RAG.

这些建议必学，深入学习。

你可能的疑问，后端没学吗？

这个我会专门写笔记谈。总结来说：后端对大模型应用重要，不是必要项。因为我0后端基础，仍然有很多Agent offer。不会后端，不会妨碍你入行，其实可以在简历筛选的时候，也可以不去面那些强要求后端的知识。

这块是一个偏好了，如果你想继续提高竞争力： 你可以深入学习算法（后训练）， 也可以学习后端。

我自己个人选择是选择学习算法，因为这样我可以找一些偏算法工程的岗位。学后端，对于大模型应用让你更有竞争力，不过也会让你不能去面试一些算法的岗位，而且面试官问到你微调，强化学习，也答不深。

这个看个人选择了。后端笔记里目前没有，如果你想选择学后端，目前要麻烦自己找一下方法了。我的想法是也许我9月份做个Agent高级项目带一点后端（也许吧）。但是算法这块，我会提供0基础学习的路线，请看阶段二。

阶段二：算法进阶

算法学习其实大家看这里：0基础学习算法记录。

我已经在学习算法，但我没把算法的八股总结在笔记里，因为我不想污染这个特别适合于学习大模型应用的路线，现在笔记总结的算法的深度，就是你一阶段要学习算法的深度。

不过你真想学算法，在这个0基础学习算法记录。 里面设置的三个SKILL，里面包含了大量教纲，有算法的各种知识：Pytorch/深度学习， 强化学习/微调， 开源项目。你顺着学。

我马上，6月开始做一个算法项目。也会分享在笔记。

算法学习的思路是，不深入底层：了解基本概念，知道怎么用专业的卡来训练，整个环节走通，有个项目。这是我学习算法的思想！有的人学习算法，他比如去手撕一下SFT, 手撕训练，算法创新，在我看来，我们不需要，这些是算法为主的同学要做的，而且也挺难的。 我们是应用专场，但是算法会，整体都跑过，面试官问概念，细节也可以答，jd要求懂算法的也能满足要求，这是我们的思路。总之具体可以就看这个0基础算法记录，里面具体写学习算法的心得。

后期规划：6月开始做算法项目（不知道多久，预计不会很长，因为是以一个简单的，掌握算法技术栈为目的的项目）。有了这个项目，可以把算法这个项目包装在Agent中。所以笔记里 RAG, AGENT, 算法项目各一个，可以相互灵活搭配。

做完算法项目，也许8月份，开始做一个复杂，高级的Agent项目。用我一年所学功力，做个深入的项目，结合面试高频趋势，设计项目。这个项目也会开源。做完后。我会开始投递简历试试，就和25年11月份一样，集中面试检验自己。

中间会穿插这个各种高频考点（如果笔记没有，我会总结），定义更新解析一些面经。这个作为主线之外的更新点缀。

这个就是我全部的经验了。照这个笔记学，我估计阶段一的话，都学下来，全职高效学3个\~6个月吧，把内容理解透了，也有一个项目。

当然啊，不是所有人都有很长时间学习，如果你时间赶，就以项目为主，先弄项目，知识别学那么深了，有了项目才能面试。给面试多留一些时间，一边面试，一边复盘。有些同学也是这么做的，毕竟时间紧，想速成。

最后的最后啊, 笔记的一个宗旨是，面试问题都有，因为笔记内容太丰富了。所以可以当作字典来用。如果面试问了哪个问题不会回答， 先查查笔记有没有解析。如果是特别高频的考点，笔记里又没有可以在 社区互动/共建入口 反馈，我也会试试更新。

当然啦，也可以在群里都交流，有问题我也会尽量回答的。

经验之谈

对于有一些我找工作特别困惑，或者大家都比较困惑的问题，我总结在这里，希望对大家有所帮助吧。

项目如何找

相信找一个大模型项目，是大家自学最困惑的一点吧。只有有一个项目你才可以去面试。

其实这个分成校招生 和 社招同学来讲。 首先我觉得校招的同学，项目是最不用担心的，至少在我看来很容易。我是以社招，都工作4年多了，大厂的标准来给自己设计的项目，所以其实校招同学用这个笔记里的项目，是够达到面试标准的。笔记里RAG的项目，刚好是今年2月做完，很多应届生都拿去面试了，而且你看面经和反馈，不乏很多大厂。加上我们笔记项目设计会越来越多和复杂，所以应届生没啥好说的。应届生最合理的一个曲线是：

先去找实习，后面再秋招。所以实习完你自然会有一个企业级的项目。这个很重要，企业级项目含金量大于自己做的项目，所以校招比较好整。真没找到实习，用笔记里的多个项目，算法+ RAG + Agent也行了。

所以我重点谈一下社招。 我说的经验都是个人真实经验，而且比较新。大概适用于P7以下，因为我基本对标P6+ P7. 如果说你是P7以上，我也不说了，企业要求肯定更高，我不能盲目给经验。

至少在我看来，我用了一个我现在觉得有点稚嫩的项目去面试。简历其实没太好好写，实测是有挺多面试的。包括现在26年5月，最近有一个国企找我面试，我给的还是之前的简历。 3月初也有大厂，字节啊，阿里啊，直接是业务部门打电话，就是说是通过了HR+业务的筛选，就是可以直接去面试的。所以从这个角度来看，我项目不复杂，但还是有很多面试机会！

但请不要觉得项目不重要，面试其实是一个综合的考察，因为筛选的时候考察学历，考察大厂，可能是因为我的背景，所以企业会放一些水，让我有面试机会。 如果你是双C9以上+大厂，你会比我更有优势。另外如果你有后端经验，应该也会更容易，因为技术栈更匹配点。所以投递简历是否通过，他是一个综合考量的过程。像GAP啊，学校背景啊，过往经验（大厂，方向）都是有影响的。

另外项目肯定是要往深了做，我只是说我项目最少去年12月份，我简历连笔记的RAG都没写，确实面试通过很多，这是实际情况。但是我当时那样，是因为我能力就到哪里了，我设计不出来复杂的Agent项目，我没有做RAG，算法也没做，没办法啊，那时就学习了6个月。但是有能力，希望大家尽量设计深入。

如果你想自己做，你可以参考我笔记里的方法，写了很多。

如果你想借用，参考，也是个好主意，我觉得你做了一个Agent，你把我的RAG项目加进去呗，或者假如我马上做的算法项目，说你用了本地模型，做了量化，SFT + 强化学习。 这也是个好方法，是在我的基础上优化，加深，取其精华。

不过也有同学就想拿项目直接用的，不想自己做。怎么说呢，我也不推荐。校招生赶时间的倒是有这么去干的。我感觉拿去直接用，很难掌握得特别细致，细节啊设计啊，这些都得自己体会。我不知道如何建议这里，因为我都是自己做的，甚至Agent，我马上做都是第三个项目了。如果时间紧走这个线路，那么我建议啊，你是找一个项目尽量深入的，文档齐全的，配套各种资料的。 如果要用笔记里的项目，我能做的就是做好配套设施，比如提供面试真题啊，讲解啊，答疑这样的。

对于社招同学，我的建议是，项目设计深入（这是废话。。）这需要一些经验，比如你怎么设计，什么值得设计，哪个模块必须设计。我在笔记里讲解开源项目的时候，包括Agent项目 项目设计思路。 谈的都有。这需要一些经验，你需要看了很多开源项目，才知道Agent项目好在哪里，有哪些模块。你只有面试了，你才知道面试官关注哪些项目的点，这时都是经验，我觉得我贯彻在了整个笔记中，如果看一下，你一定有一些答案。

在自己最大的能力范围内，弄一个最复杂的项目吧。 也不用特别担心整个事，一开始就要一个企业级的项目，因为有的公司，倒是比较看重潜力和背景，包括普通开发转Agent开发，你的之前的项目经验，工程经验他也是认可的。特别是像大厂，字节，阿里这种传统互联网大厂对于你的项目要求（P7以下）还是挺包容的。他更看重你的潜力，你的工程能力，你面试的表现。 但确实也有公司很在意落地经验的，像那些AI公司，六小龙之类的。 也有公司看重学历和大厂，比如银行啊，国企啊。他们技术估计也一般，学历背景好，面试表现好，就能过。

有时候能力达不到，用一个太复杂的项目其实你也驾驭不了，因为确实你知识体系，架构设计，理解上都不够，给一个复杂的项目，真的能驾驭的了吗，所以我说在能力范围之内，弄一个复杂的项目。

另外面试被挑战项目简单，我觉得太正常了。看笔记的要不就是校招生，要么就是转行的社招，也很难说有个什么特别难的项目。我的解决思路就是：

1. 尽量做深入项目（比如我又要重新设计一个更加复杂的Agent）。

2. 广度加深。 我的规划到时候我RAG, AGENT, 算法都有项目，或者一个项目又做算法，又做Agent，又做RAG。

3. 其实项目是一方面，取决于你能不能面试。我们要做的还有很多，就是你面试的表现，你的知识的理解，表达，还有该死的八股，我们需要在方方面面做的好。如果你项目弱点，其它方面就争取弄好点呗。

其实，我多少也有点担忧，尽管我天天学习，但是我目前还是不是专门做大模型的，都是自学，也会让我有点焦虑。不过焦虑没有用，我最少知道，我在进步的，我算法项目快有了，Agent年底要做的更复杂了，各种理解也加深了。这是今年，如果让我明年再学一年，明年底是啥样，我也不知道。 当然你可以骂我，我永远都在闹着玩，工作做大模型才是专家。 我不知道，我无法反驳，反驳也没意义，我会定期检验自己，面试是很好的方法，至少25年12月份，我觉得成果很好。最近我也有一点面试，猎头邀请，我没主动投，等我做完Agent项目，估计又是今年12月左右了，我再去面试，让市场检验吧。

另外社招建议是往工作场景上编和包装，大不了说没上线呗。但是我当时投递，那个智能预约项目，一看就和工作无关，反正还是写上简历去面试了。

最后说说的项目规划。

2025年做了两个简单的Agent项目，笔记里开源了一个，是用来找工作用的。

2026年2月做了RAG，笔记开源了，

2026年6月，规划做算法，笔记会开源。

2026年8月，做复杂Agent项目，笔记会开源。我会用我学的功力，Harness思想，开源项目架构，想一个新颖的点，做个项目，我觉得这个项目是笔记里最厉害的项目（虽然还没做）。

做完了，我就去包装，面试。我觉得你做了一个项目，包装啊，迁移很容易。比如把算法训练做一遍，我就是包装到各个Agent之中，和业务场景包装，很容易。但我得先把技术做一遍，了解怎么做，再包装。分两步。所以现在我要做的就是做完项目。做完了就是包装+面试+反思+迭代改进 循环。

总之，关于项目，笔记蕴含了大量的思路，包装技巧，项目本身也供大家参考。希望大家站在我的肩膀上，利用这些资源，让自己做的更好。

面试内容复盘小技巧

分享一个技巧和提示词，是我用来，面试完把录音文件对应的txt转成相关问题的提示词。具体方法是，使用该提示词+AI可以快速完成面试内容提取，个人使用CC+Opus4.8以及Codex + GPT5.5都运行很好。其他ai和model理论上也能运行，任务不是很复杂，提示词放在这里。

大模型岗位介绍

大模型的岗位主要分成：算法工程师，开发工程师，数据工程师，推理工程师，垂直领域微调工程师。

大模型的整个链路：

数据 → 训练/对齐 → 评测 → 推理部署 → 应用落地 → 监控迭代

从岗位的具体工作上，其实我们可以很清楚对应到这个岗位处于整个链路中的哪个环节。

不同岗位对于技术深度，系统理解，工程实现，行业知识的要求重点不同，面试考察方式也有所差异。针对于不同的岗位，需要我们针对性调整复习策略和深度。另外，复合型人才更为吃香，能够清晰说明跨岗位协作逻辑以及边界交互细节，掌握多个岗位的技术。比如既具备工程能力与算法创新能力的人才将更加具有优势。

速览

应用开发工程师：最容易入门，重工程与业务落地，是新人和转岗首选。

大模型算法工程师：含金量最高 / 天花板最高。深度依赖数学、训练与架构能力，少而精，对个人技术上限要求最高。大厂卡学历，背景，论文最严重。

大模型推理部署工程师：最稀缺、工程壁垒最高。解决“模型怎么跑得快、跑得稳、跑得便宜”，强后端 + 系统 + GPU，能直接决定线上成本与性能。

大模型数据工程师：最容易被低估、但不可或缺。做数据通常被认为是脏活累活，话语权也低。门槛比开发低。

垂直领域微调工程师：最贴近行业、最容易做专家化。把通用模型变成“法律/医疗/金融专家”，拼的是领域理解 + Prompt / 微调经验，越做越值钱。

以下岗位介绍内容，是清华大学出版社的：《大模型工程面试》 - 算法原理，开发，实践与系统部署。

1 算法工程师

大模型算法工程师是大语言模型技术体系中的核心岗位之一，主要负责模型的结构设计、算法优化、训练流程管理以及性能评估等工作。该岗位通常要求具备扎实的深度学习理论基础与丰富的实践经验，能够从算法层面出发，构建具备通用能力、可扩展性的模型体系。

1.1 岗位定位和核心职责

在实际工作中，大模型算法工程师通常参与以下核心环节：模型架构设计与优化、训练任务定义、任务目标建模、损失函数调整、训练策略制定（如优化器选择、学习率调度等），以及训练过程的监控与效果分析。

部分高级岗位还需参与算法创新，如设计新的注意力机制、稀疏结构或低秩模块，用以提升模型效果与表达能力。

1.2 关键技术能力要求

（1）深度学习理论基础：掌握深度神经网络结构、前向与反向传播机制、梯度计算与参数更新原理。这些是算法工程师进行模型设计的基础。特别是对 Transformer 架构的结构细节、注意力机制、位置编码等要素需具备深入理解。

（2）主流训练范式掌握：熟悉预训练–微调范式的各阶段任务设计，包括自监督目标（如语言建模、掩码建模）、指令微调、强化学习阶段（如人类反馈训练）。需了解如何根据任务特性制定合理的训练目标与数据配比。

（3）大规模训练优化经验：具备在分布式环境下进行模型训练的能力，熟悉数据并行、模型并行、混合精度训练、梯度累积、ZeRO 优化等常用方法，能够在高效利用资源的同时保证模型性能。

（4）算法调优与性能分析：能够通过 Loss 曲线、梯度变化、参数分布等指标分析模型训练状态，判断是否出现梯度爆炸、收敛异常或过拟合问题。具备调参经验，如 Dropout 设置、正则化手段、学习率调整等。

（5）论文阅读与实现能力：需具备快速阅读理解前沿论文的能力，能够将新提出的算法结构或优化策略快速落地，并结合自身任务场景进行调整与工程实现，如引入 MoE 模块、Flash Attention 机制、ReLU 变体等。

1.3 典型工作流程

（1）任务理解与模型设计：根据任务目标（如通用对话、代码生成、知识问答等），确定模型规模、结构类型（编码器、解码器、编码解码混合），以及预训练目标等核心设计决策。

（2）数据适配与样本处理：参与设计 Tokenization 策略，构造多轮输入格式，划分训练集、验证集，并进行数据清洗与分布分析，为训练提供质量保障。

（3）训练调试与性能迭代：在训练过程中监控模型的损失变化、准确率、泛化能力等关键指标，适时调整训练参数，诊断异常现象，从而改进训练策略。

（4）评估验证与结果产出：基于验证集与测试集进行定量评估，如 BLEU、ROUGE、Accuracy、Perplexity 等指标，并结合人类评价对任务表现进行定性反馈。

（5）算法报告与优化闭环：撰写算法设计文档，记录训练流程、参数配置与调优历程，为版本迭代与团队协作提供文档支撑。

1.4 常见技术工具与平台

该岗位常使用的深度学习框架包括 PyTorch、TensorFlow，训练平台包括 DeepSpeed、ColossalAI、Megatron、MindSpore 等。分布式调度工具如 NCCL、Horovod、Ray 为常见组件，此外还需掌握用于可视化的工具，如 TensorBoard、Weights & Biases、Matplotlib 等。

在工程实践中，算法工程师还需与平台团队协同解决内存调度、模型并行、训练失败容错等底层工程问题。

1.5 岗位价值与方向发展

大模型算法工程师作为 AI 技术研发链条的源头角色，其贡献直接影响模型能力的上限与智能水平。随着模型复杂度与多模态需求的提升，该岗位的技术门槛与决策权重同步上升。

在发展路径上，该岗位可向算法科学家、高级研究员、模型负责人等方向进阶，也可拓展至智能体系统构建、通用 AI 架构设计等更具系统性与前瞻性的技术领域。在实际岗位竞争中，具备工程能力与算法创新能力并重的复合型人才将更具优势。

2 大模型开发工程师

大模型开发工程师主要承担大模型在工程化过程中的实现、封装与平台集成任务，是连接底层算法研究与上层应用系统的关键岗位。该岗位的工作重心在于将已有的大模型能力通过可调用接口、模块化组件、服务化架构等方式封装起来，使其能在实际业务中高效、安全、稳定地运行。

2.1 岗位定位与职能边界

在大模型的生命周期中，开发工程师通常介入模型推理服务搭建、接口 API 封装、前后端调用、缓存机制设计、任务调度实现、多模型集成、模型评估体系建设等多个工程层面，是大模型应用落地的直接执行者与系统支撑者。

2.2 关键技术能力要求

（1）大模型调用与封装能力：需具备使用主流框架（如 HuggingFace Transformers、OpenAI API、ChatGLM、Qwen 等）加载并调用大模型的能力，熟悉 Prompt 构造、Token 控制与输出解析等细节。

（2）推理服务部署与优化经验：能够完成本地部署、云端部署及容器化部署，掌握 Docker、Conda、Kubernetes 等工具，熟悉推理性能优化（如 KV Cache、批处理、并发控制）。

（3）系统架构与微服务设计能力：了解 Web 系统与微服务设计理念，能基于业务需求完成模块划分、服务拆分、任务路由与模块协同，实现 RESTful 接口设计、模块解耦、异常处理、日志记录等系统级能力。

（4）任务调度与控制逻辑构建：负责构建智能体或多模块系统中 Prompt 调用的状态机、上下文管理模块、历史信息追踪与决策逻辑，确保多轮交互、插件调用、RAG 融合等高级功能具备良好扩展性。

（5）工程代码质量与可维护性：具备良好的代码组织、测试覆盖、日志记录与错误处理能力，能够对模型调用链路中的每个步骤进行模块化、抽象化处理，提高系统可扩展性与稳定效率。

2.3 典型工作流程

（1）模型能力接入与封装：从算法工程师或开源模型处获取模型权重与接口文档，完成模型加载、Prompt 输入格式适配、Token 编码处理，并对输出内容做结构化封装，形成标准可调用服务接口。

（2）模型服务化与性能优化：通过 FastAPI 或 Triton 部署推理服务，结合负载均衡、缓存策略与请求分流机制，构建支持高并发、低延迟的服务体系。

（3）功能集成与系统设计：将大模型能力嵌入业务流程或系统中，构建智能问答、代码生成、文档摘要等应用场景。对接 RAG 系统、知识库、搜索引擎、数据库等外部模块，完成数据驱动与结果增强。

（4）多模型管理与调用路由：设计统一模型管理接口，实现多模型版本切换、上下文状态路由、多语言模型选择、跨任务模型组合等能力，保障多样化业务需求的灵活响应。

（5）系统监控与异常处理：构建模型调用链的健康监控体系，包括响应时长统计、异常次数记录、内存使用跟踪等，结合 Prometheus、Grafana、ELK 等工具构建可视化监控看板与日志系统。

2.4 常用技术工具与平台

大模型开发工程师常用的核心语言为 Python 和 Go，主要框架涵盖 Transformers、vLLM、FastAPI、Triton、Flask、LangChain 等；数据处理与缓存机制中常使用 Redis、MongoDB、SQLAlchemy 等工具；

监控体系中常使用 Prometheus、Grafana、Loguru、Sentry 等组件。

在模型服务容器化方面，需熟悉 Dockerfile 构建与镜像管理流程；对于大规模部署，还需了解 Kubernetes、Nginx 反向代理、服务网关等相关技术。

3. 大模型数据工程师

在大模型系统中，数据工程师是支撑预训练、微调与推理各阶段的底层力量，负责数据的采集、清洗、结构化、存储与分发，是整个模型生命周期的数据保障者。与传统数据分析岗位不同，大模型领域的数据工程师需要处理的是大规模、高维度、多模态的非结构化数据，不仅要解决数据可用性问题，更要保障数据对模型训练效果的正向支撑。

3.1 岗位定义与职责核心

岗位主要职责包括：搭建数据获取与处理流程，构建高质量训练语料，设计分词策略与 Token 机制，实现分布式数据加载优化，建立数据版本与可追溯机制，支持多语言与多模态数据并行处理等。在真实工程场景中，数据工程师的工作直接影响模型训练效率、性能表现及微调的效果边界。

3.2 关键技术能力要求

（1）大规模文本数据处理能力
需要掌握海量文本数据的清洗、去重、切分与规整等操作，熟练使用正则表达式、文本处理库、分布式文件系统等工具，能够在百万到数十亿级文本样本中构建符合训练标准的语料。

（2）分词与 Token 机制理解
熟悉常见分词器（如 BPE、SentencePiece、WordPiece），掌握 Tokenizer 构建、词表训练、Token 长度分布控制、文本对齐机制等关键技术。能够根据中文、英文及多语言任务需求选择合适的分词策略。

（3）数据增强与样本构造经验
具备使用反事实生成、数据混合、格式转换、指令生成等手段进行样本增强的能力，能够围绕对话、问答、生成、翻译等任务构造标准训练样本，提升模型泛化能力。

（4）分布式数据加载与预处理优化
在大模型训练中，数据加载速度直接影响整体训练效率。工程师需熟悉 DataLoader 优化、Sharding 机制、缓存策略、异步加载与数据流水线设计，避免数据成为训练瓶颈。

（5）多模态与多语言数据处理能力
随着大模型向图像、音频、视频等模态扩展，数据工程师需具备将多模态数据转换为统一编码输入的能力，如语音转文本、多语种语料对齐等，并构建统一的数据格式供模型使用。

3.3 典型工作流程

（1）语料采集与初筛
从开源项目、公开网站、内部知识库、社交平台等渠道自动或半自动获取文本，进行初步清洗与合规审查，剔除无效、违规、低质量信息。

（2）数据清洗与格式规整
统一文本编码，清除特殊字符与冗余标记，处理 HTML 标签、异常断句与乱码等，并根据任务需求完成多轮清洗。

（3）数据切分与 Token 统计
将长文本切分为适合 Token 限制的段落，统计样本平均长度、分布范围、最大 Token 数，设置上下文窗口，确保模型输入不溢出并具备语义连续性。

（4）训练样本构造与增强
结合任务目标构造训练样本，如为问答系统设计包含 Prompt、Query、Answer 结构的样本，为 RLHF 构建带有偏好标注的数据，或构造 Few-shot 示例序列。适时进行样本增强，对抗样本添加等方法提升模型鲁棒性。

（5）数据版本管理与溯源机制
每次训练数据的构建过程均需记录版本号、处理脚本、时间戳与来源，确保模型结果可回溯、可复现，便于后期调参、复训与问题追踪。

3.4 常用技术工具与平台

大模型数据工程师常用语言为 Python 和 Bash，主要处理工具包括 Pandas、Datasets 库、HuggingFace Tokenizer、spaCy、OpenCC、Jieba、NLPAug 等。分布式数据处理场景多使用 Spark、Flink、Ray 等；数据管理平台包括 Airflow、MLflow、DVC、Delta Lake 等。

对于特定语料（如代码、法律、医学数据），还需具备专业领域数据理解能力，进行精细化的结构映射与语义分类。对于多模态数据，则需配合图像标注工具、语音转文本引擎等完成前期处理。

3.5 岗位价值与发展方向

数据工程师是支撑大模型构建的基础力量，其工作成果决定了模型学习能力的上限与泛化能力的边界。在当前数据驱动为核心的模型发展趋势下，该岗位的重要性持续提升。

未来，数据工程师的发展方向包括复合的数据架构设计者、大模型训练的数据管道构建者、专注于安全与对齐的数据质量管控专家，以及承担合成与任务数据生成责任的 “Prompt 数据工程师”等角色。随着大模型对数据精度、结构与任务匹配度要求不断提高，具备算法理解与工程能力融合背景的数据工程师将在模型研发团队中扮演愈发关键的角色。

4. 推理工程师

推理部署工程师是大模型工程体系中负责模型上线、服务发布与推理性能优化的关键岗位，主要任务是将训练好的大语言模型从离线环境转换为可在线调用的服务接口，并在推理过程中保证系统的稳定性、可扩展性与高性能响应。

与算法工程师负责模型训练不同，推理部署工程师更为关注如何在有限算力下实现最优推理效率、如何在多端场景中稳定运行模型，以及如何将模型能力集成进实际应用/系统中。

4.1 岗位定位和核心职责

该岗位通常需要与算法、开发、系统运维、安全团队紧密协作，在模型格式转换、量化/硬件适配、服务封装、资源调度等多个层面形成闭环工作流，是大模型从实验室走向落地的最后“一公里”执行者。

4.2 关键技术能力要求

模型格式转换与兼容性适配：掌握主流模型格式之间的转换流程（如从 PyTorch 转 ONNX、TensorRT、vLLM 格式），理解不同部署框架对模型结构支持的差异，能够进行图优化与结构裁剪，确保模型在目标平台可顺利加载并运行。

推理精度加速与性能优化：熟悉推理阶段的常见加速方法，包括半精度计算（FP16）、量化计算（INT8）、稀疏矩阵加速、KV缓存机制、Batch 合并处理、多线程异步调用等，能够根据模型特征选择最合适的推理路径，以实现吞吐与响应时间的优化平衡。

多卡部署与资源调度：掌握多卡部署的通信机制与并行调度策略，了解模型并行、流水并行与张量并行的基本逻辑，能通过 NCCL、TorchRun、DeepSpeed 等工具实现横向扩展能力，熟悉 CUDA 资源管理，显存分布与 GPU 负载监控等底层细节。

服务封装与接口管理：具备使用 FastAPI、Flask、Triton、BentoML 等构建模型服务接口能力，能够完成 API 路由管理、请求参数解析、Token 长度控制、错误响应处理、调用日志收集等，保障部署服务具备高可用性与可维护性。

系统监控与容错能力建设：熟练构建服务运行时的监控体系，包括请求量、响应时延、失败率、硬件利用率等指标收集与可视化展示。能够设置异常熔断、自动重启、超时堵塞、回退机制等防故障能力，提高整体系统鲁棒性。

4.3 典型工作流程

模型接收与格式标准化：从算法工程师处获取已训练完成的模型及配套配置文件，完成必要的格式转换与静态图构建，并对输入/输出结构进行标准化处理，适配部署框架要求。

推理引擎选择与性能测试：评估部署场景对性能的需求，选择合适的推理引擎（如 ONNX Runtime、TensorRT、vLLM、DeepSpeed Inference 等），并结合测试脚本对不同部署方案进行 Latency、Throughput 等关键指标测试与对比分析。

服务封装与线上部署：基于选定的推理方案，使用 FastAPI 或 Triton 封装模型服务，设置并管理推理接口参数、配置多进程并发机制，实现可扩展的线上服务部署，并进行 Docker 化与持续集成配置。

资源调度与运行监控：根据模型资源需求配置合适的 GPU 或混合 CPU‑GPU 部署方案，设置 Prometheus 与 Grafana 完成推理链路的全量监控，定期检查系统负载、运行日志与异常警告，确保服务运行稳定。

优化迭代与问题修复：基于真实调用数据与用户反馈，持续优化模型响应路径与服务性能，解决兼容性问题、性能瓶颈和异常问题，以满足业务增长的需求。

4.4 常见技术工具与平台

推理部署工程师常使用的核心工具包括：

（1）格式转换工具：ONNX Exporter、TorchScript、TF Converter。

（2）推理框架：TensorRT、ONNX Runtime、vLLM、Triton Server、DeepSpeed Inference。

（3）服务封装工具：FastAPI、Flask、BentoML、gRPC。

（4）容器与部署：Docker、Kubernetes、NVIDIA Docker、Nginx。

（5）监控与日志系统：Prometheus、Grafana、Loguru、Sentry。

同时，还需熟悉 Linux 环境下的 GPU 调度、CUDA 工具链、Python 后端逻辑编写与 HTTP 接口设计等。

4.5 岗位价值与发展方向

推理部署工程师是保障大模型从理论能力到实际服务转化的关键角色，承担将模型高效、安全、稳定部署至生产环境的责任。其专业性不仅体现在工程实现效率上，更体现在对系统稳定性、性能可控性的理解与掌控中。

随着边缘部署、模型压缩、多模态推理、低功耗计算的快速发展，该岗位将逐步向“系统级优化工程师”“AI 基础设施工程师”“多模型编排调度专家”等方向拓展，成为 AI 工程体系中不可替代的关键节点。对于追求工程深度与系统稳定性的技术人员而言，推理部署工程师是一个技术挑战性与价值感兼具的发展路径。

5. 垂直领域微调工程师

垂直领域微调工程师是大模型团队中专注于模型在特定行业或任务上进行再训练与能力定制的技术岗位，主要负责在预训练模型基础上，通过有限或特定领域的数据进行微调，使模型具备更强的专业理解能力与场景适配能力。该岗位连接通用模型能力与下游应用需求，是实现模型产品化与行业落地的关键角色。

5.1 岗位定位和核心职责

与算法工程师不同，微调工程师不负责构建模型底层结构，而是更多地参与数据处理、训练策略设计、指标评估与迭代优化，围绕某一具体任务（如法律问答、医疗报告生成、金融分析、政务问询等）构建专业能力闭环。

5.2 关键技术能力要求

（1）行业知识与任务理解能力：
垂直领域微调工程师需对目标行业的语言风格、知识结构、任务类型有较强理解，能够抽象出符合业务需求的任务定义与评价标准，确保模型在语义层面具备专业性与可控性。

（2）模型微调与参数优化能力：
需要掌握全参数微调、冻结微调、参数高效微调（如 LoRA、Adapter、Prefix Tuning 等）等不同技术路线，能够根据数据规模、算力预算与业务场景灵活选择训练策略，并掌握训练过程中的调参技巧与稳定性控制方法。

（3）指令构造与 Prompt 设计能力：
能够针对具体任务构造高质量 Prompt 模板、示例指令与上下文配置，优化 Few-shot、Zero-shot 等输入形式，引导模型在生成过程中表现出符合预期的语义风格与逻辑结构。

（4）数据增强与标注指导能力：
具备设计反事实样本、扰动样本、边界样本等方法提升模型泛化能力的经验，能够协助标注团队构建高质量样本集，并在数据层面对模型泛化能力形成正向反馈。

（5）评估指标与质量控制能力：
熟悉多种评估指标，如 BLEU、ROUGE、EM、F1、准确率、召回率、人工评分体系等，能够构建自动化评估流程，监测模型在不同迭代过程中的表现变化。

5.3 典型工作流程

（1）场景需求分析与任务定义：
根据业务部门或产品线提出的功能需求，提炼出可落地的模型任务定义，如医疗问答、合同生成、证券分析等，明确输入/输出格式、预期效果与边界条件。

（2）语料准备与数据构建：
联合数据工程师完成语料搜集与结构化，设计指令体系、示例样本、标签体系等，构建符合微调需求的高质量样本集，必要时进行领域知识注入或术语标准化处理。

（3）模型选择与训练策略制定：
根据任务复杂度与资源条件选择合适的预训练模型（如 Qwen、ChatGLM、Baichuan 等），并确定训练策略，包括是否冻结部分层、是否应用 LoRA 插入、训练轮数与学习率设置等。

（4）训练调试与指标监控：
进行模型训练并持续监控 Loss 变化、精度提升、样本覆盖情况，诊断过拟合、漂移、语义偏差等问题，调整超参数以实现更稳定的训练表现。

（5）评估验证与业务集成：
使用测试集与评估指标对模型效果进行定量验证，并通过业务场景下的人工评估或 AB 测试进行实战验证，确保模型在目标场景下具备上线条件，最终对接开发或推理部署团队完成集成。

5.4 常见技术工具与平台

垂直领域微调工程师常使用的训练框架包括：

Transformers（HuggingFace）、PEFT 库、DeepSpeed、ColossalAI 等。

模型监控与训练日志通常使用 Weights & Biases、TensorBoard 等可视化工具。

数据处理常依赖 Pandas、SpaCy、NLPAug 等文本增强工具，训练环境通常部署于多卡 GPU 服务器或分布式云平台，如阿里 PAI、华为昇腾平台等。

在多语言场景下，还需结合 OpenCC、Jieba、FastText 等工具处理中文英文混合、术语翻译与对齐问题。

5.5 岗位价值与发展方向

垂直领域微调工程师是大模型产品化过程中不可或缺的角色，决定了模型能否真正理解业务语境并满足特定场景下的精度需求与用户交互预期。其岗位价值不仅体现在提升模型表现，更在于构建模型与业务之间的连接通道，将抽象能力转化为可落地产品。

随着多行业对大模型应用需求的深入，该岗位可进一步拓展至“任务建模专家”“Prompt 设计工程师”“AI 产品交付工程师”“行业知识增强建模专家”等方向，成为推动大模型在垂直领域深度落地的关键推动者。对于具备行业知识与算法理解能力兼具的工程师而言，该岗位提供了广阔的发展空间与实践价值。

FDE（前线部署工程师）

FDE 通常是 Forward Deployed Engineer 的缩写，可译为“前线部署工程师”或“前线交付工程师”。Palantir 的完整岗位名称还常写作 Forward Deployed Software Engineer。国内部分材料将其解释为 Field Deployment Engineer 或“前沿部署工程师”，但这并不是该岗位最常见、最准确的英文来源。

FDE 是直接面对客户的软件工程师，位于客户业务、产品能力与工程交付的交叉点。它并非简单地安装部署模型，而是深入客户现场，从模糊的业务问题出发，完成需求发现、方案设计、软件开发、系统集成、上线验证与持续迭代，对最终的客户业务结果负责。

6.1 岗位起源与发展背景

FDE 这一岗位模式通常被认为发源于美国企业软件公司 Palantir。Palantir 成立于 2003 年，FDE 在公司创立早期、即 2000 年代初期便伴随其业务模式逐渐形成。由于 Palantir 将复杂的数据分析平台交付给政府、金融、制造、航空等非纯技术客户，单靠标准产品和使用培训无法解决客户的复杂问题，因此需要工程师直接进入客户环境，一边理解业务，一边利用平台开发解决方案。

传统软件研发通常追求“一对多”：开发一个标准产品服务大量客户；FDE 的初始工作则更偏“一对一”：围绕一个重要客户的具体问题快速构建端到端方案。项目中反复出现的共性需求，又可以被抽象并反馈给核心产品团队，沉淀为可复用的平台能力。

这一岗位并非生成式 AI 出现后才诞生。它已在 Palantir 等企业软件公司存在二十年左右，但在 2023 年生成式 AI 商业化加速后重新受到关注。大模型、Agent 和数据平台的能力越来越复杂，而传统企业往往缺少把这些技术接入自身数据、权限、流程和业务系统的能力，FDE 因而成为连接“模型能力”与“业务结果”的关键角色。

在国内，与 FDE 相似的工作过去并非不存在，往往分散在售前解决方案、客户工程师、驻场开发、AI 交付和行业解决方案架构师等岗位中，只是较少统一使用 FDE 这一名称。随着 2023～2024 年国内大模型厂商、云厂商和企业客户开始批量探索大模型应用，市场先产生了“如何把模型落到业务里”的职能需求；到 2025 年前后，越来越多公司开始直接采用 Forward Deployed Engineer/FDE 的岗位名称；2026 年上半年，伴随 Agent 商业化和大厂集中发布招聘，该名称在国内招聘平台、自媒体和求职讨论中明显升温，成为所谓“突然火起来”的新岗位。

因此，“FDE 在国内什么时候出现”和“什么时候火起来”需要区分：类似职能早已存在，2023～2024 年是需求形成期，2025 年是岗位名称加速引入和扩散期，2026 年上半年是公众认知与招聘讨论的集中爆发期。当前在火山引擎、腾讯云及其他 AI 公司的招聘中，可以看到 FDE、现场部署工程师、AI 解决方案工程师等名称。但目前缺少权威机构按年份统计国内 FDE 岗位数量的数据，网络流传的“需求暴涨多少倍”等说法不宜直接当作行业统计结论。

6.2 岗位定位与职能边界

FDE 可以理解为同时承担三种职能：

（1）顾问：通过访谈和主动倾听理解客户业务，区分客户描述的表面症状与真正需要解决的商业问题，建立客户及管理层的信任。

（2）产品经理：把零散需求抽象成可执行的问题，综合业务价值、技术可行性、时间与资源进行优先级排序，确定最值得解决的场景。

（3）软件工程师：亲自完成原型、代码、数据接入、系统集成、测试与交付，将方案变成能够运行的软件，而不是止步于咨询报告或演示文稿。

**FDE 不等同于售前解决方案工程师。**售前通常在签约前完成产品介绍、方案设计和 POC Demo，目标是证明产品能力并推动成交；FDE 往往从需求发现一直参与到生产交付、实际使用和效果验证。**FDE 也不等同于传统实施或驻场运维。**如果工作内容主要是安装软件、配置后台、处理工单，而不需要定义问题、编写代码和交付生产方案，则更接近传统实施，而非严格意义上的 FDE。

FDE 强调端到端负责，但不表示所有工作都由一个人完成。商务报价与合同通常由销售负责，通用平台由核心研发团队负责，底层模型训练由算法团队负责，生产运维也可能由平台团队配合。FDE 的核心责任是跨越这些团队之间的断点，持续推动一个高价值客户问题被真正解决。

6.3 关键能力要求

（1）客户发现与业务抽象能力：能够访谈业务人员和管理层，梳理角色、流程、数据、指标与约束，从“客户说想要什么”继续追问到“客户为什么需要它、成功如何衡量”。FDE 最重要的沟通能力往往不是能说，而是主动倾听、追问和建立信任。

（2）产品判断与优先级能力：客户通常会提出大量需求，FDE 需要找到业务影响大、当前平台能够解决、交付周期合理的问题，并清楚说明取舍依据。不能只追求技术上有趣，也不能只做容易但没有业务价值的功能。

（3）端到端软件工程能力：具备实际编码和构建能力，能够围绕特定客户的问题开发解决方案，而不是只写方案或制作售前演示。交付时需要考虑代码是否完整、可能出现的异常和边界输入，以及客户能否正确使用。

（4）大模型应用能力：能够搭建和调试 Agent，进行提示词调优，并根据客户业务接入 Skill、MCP 等能力。FDE 不一定负责训练基础模型，但需要理解模型和 AI 产品如何应用到客户场景中。

（5）系统对接能力：能够根据项目需要，将 AI 应用与客户的数据库、OA、业务系统和内部工作流程连接起来。具体使用什么语言、框架和部署工具，取决于所在公司的产品与客户环境，现有资料没有给出统一技术栈。

（6）项目推动与高管沟通能力：能够管理范围、风险和预期，向业务人员解释技术限制，也能向管理层用业务指标说明方案价值。FDE 面对的不是一份完全明确的需求文档，而是需要在不确定环境中持续对齐并推动交付。

（7）行业理解与快速学习能力：能够快速进入制造、金融、零售、医疗、政务等陌生领域，理解行业术语、核心流程、监管要求和价值链。长期来看，深耕某一行业并形成可复用的方法论，会显著提高个人壁垒。

6.4 典型工作流程

（1）客户发现：访谈客户管理层和一线人员，观察实际流程，梳理现有系统、数据与关键指标，不急于根据客户提出的第一个需求直接开发。

（2）问题定义与方案选择：把业务问题转化为可验证的任务，明确范围和预期结果，判断公司的模型、Agent 或平台能力如何与该问题结合。

（3）POC 与价值验证：快速构建原型，用客户真实或脱敏数据验证技术可行性及业务价值。POC 不是终点，而是降低风险、确认方向的阶段。

（4）落地交付：将方案与客户的数据、数据库、OA 或其他业务系统进行对接，完成必要的开发与调试，使其能够解决客户的实际问题。

（5）上线与迭代：培训用户、观察使用情况，结合业务指标、模型评估和用户反馈持续优化。项目结束后，将重复出现的问题和能力反馈给产品团队，推动产品标准化。

6.5 技术能力要求

FDE典型的技术能力包括：

• 大模型基础与模型落地能力；
• Agent 的搭建、定制和效果调试；
• 提示词调优；
• Skill、MCP 等能力的接入；
• Web Coding、简易脚本和实际构建能力；
• 数据库、OA、企业业务系统与工作流程的对接；
• 从客户问题发现到软件交付的端到端工程能力。

其中，英文访谈将 FDE 直接定义为“面向客户的软件工程师”，并强调最终交付物应当是软件。因此可以确认 FDE 需要开发能力，但不能仅根据这些资料进一步断言所有 FDE 都必须掌握某套传统后端、云原生或分布式技术栈。具体工具应以目标公司的产品形态和岗位描述为准。

6.6 薪资待遇与口径说明

FDE 的薪资差异很大，主要取决于城市、公司阶段、岗位偏工程还是偏实施、出差强度、客户行业和个人经验。目前国内岗位名称尚未完全统一，FDE、AI 解决方案工程师、AI 应用交付工程师、客户工程师等名称可能对应相似工作，反过来，一些普通实施或驻场开发岗位也会被包装为 FDE，因此不能只按岗位名称比较薪资。

从当前国内招聘与市场信息看，一线城市部分初级岗位月薪约为 20k～30k；具有 2～3 年企业 AI 落地经验的岗位可能达到 30k～55k；少数大厂、核心团队或资深行业专家岗位年薪可达到 60 万～80 万以上。实际收入受公司、城市、职级、技术要求、客户资源、出差强度及奖金股权影响很大。由于国内尚无针对 FDE 的统一薪酬统计，这些数字只能作为招聘区间参考，不能理解为行业普遍水平。

美国科技公司的公开招聘中，FDE 往往按照中高级软件工程师或客户工程岗位定价，常同时包含基本工资、奖金和股权；不同地区、级别及公司之间差异明显，不能将美国年薪直接换算成国内岗位待遇。实际求职时，应以目标公司的 JD、职级、基本工资、奖金/股权、出差补贴和驻场要求综合判断。

6.7 前景、机会与风险

从中短期看，FDE 受益于企业 AI 商业化。模型能力正在快速商品化，但企业的数据、流程、权限和行业知识无法完全标准化，能够把复杂技术转化为真实业务成果的人才仍然稀缺。尤其是向传统行业销售复杂 AI 产品的模型厂商、云厂商和 ToB AI 公司，更需要这类岗位。

从长期看，只要“复杂技术产品面对非技术客户”这一问题持续存在，FDE 的职能就不会消失。其发展方向主要有两类：一类是把项目中的共性需求沉淀为产品平台，走向 AI 产品、产品工程或解决方案架构；另一类是深耕金融、制造、医疗、零售等垂直行业，成为行业 AI 交付专家、行业架构师或业务负责人。职业成长通常体现为负责范围扩大：从完成一个问题，逐步发展到独立负责一个客户、一个行业、一个区域或更大规模的业务。

该岗位也存在明显风险：工作职责杂、需求不确定、客户压力大、可能频繁出差或驻场，并同时承受销售、客户与研发团队的压力。如果公司缺少成熟产品，FDE 容易退化为无止境的定制外包；如果工作只包含安装配置和售后支持，则技术成长空间有限。因此面试时应重点确认是否需要编写生产代码、是否参与问题定义、是否负责从 POC 到上线、成果能否沉淀回产品，以及考核指标是交付工时、签约金额还是客户业务结果。

6.8 适合人群与职业匹配

FDE 适合具有以下特征的人：

（1）有产品意识的后端、全栈或大模型应用开发工程师，不满足于只接收需求写代码，愿意接触客户并理解业务价值。

（2）技术动手能力较强的产品经理、解决方案架构师或咨询顾问，能够进行需求分析和客户沟通，并愿意补齐编码与工程交付能力。

（3）传统实施或售前工程师，已经熟悉企业客户和项目推进，但需要进一步掌握大模型应用、软件开发、系统集成与生产化能力。

（4）做过创业或未来希望创业的人。FDE 的工作很像早期创业：客户未必知道自己真正需要什么，工程师需要一边与客户交流，一边定义和构建产品，并直接对结果负责。

如果只希望长期专注底层算法或纯编码、不愿接触客户；只喜欢做规划而不愿亲自实现；或者偏好需求清晰、职责边界稳定的工作，则可能不适合 FDE。选择该岗位的理由应当是喜欢同时处理咨询、产品和工程问题，而不只是因为岗位名称热门或薪资宣传较高。

6.9 以 FDE 为目标时，本笔记的学习重点

本笔记以大模型应用开发为主线，与 FDE 的技术底座高度重合，但不能完整覆盖 FDE 所需的客户与业务能力。建议按以下优先级学习：

第一优先级是 Agent、RAG 与项目实战。重点掌握 Agent 的基本机制、Function Calling、MCP、LangChain/LangGraph、RAG 全链路、向量数据库、混合检索、Query 处理、记忆、权限、安全、成本控制与 Agent 评估。FDE 不仅要会调用模型，更要能说明为什么选择某种架构、效果如何衡量、失败时如何定位。

第二优先级是构建和交付能力。重点看“大模型开发工程师”“RAG 项目实战”“Agent 项目实战”，训练自己从业务问题出发搭建 Agent，并完成数据库、外部能力或业务流程的接入。至于是否进一步学习 API 设计、Docker、云端部署等内容，应根据具体 FDE 招聘要求决定，不能将其视为所有 FDE 的统一必备技术。

第三优先级是模型选型与大模型全链路认知。需要理解不同模型的能力、成本、延迟和上下文限制，了解 Prompt、RAG、微调之间的选择逻辑；Transformer、SFT、强化学习、量化和推理框架以理解原理、能够与算法及平台团队协作为目标，不必像算法工程师一样优先深入公式和训练细节。

第四优先级是 AI Coding、Skill 与行业素养。FDE 经常需要在客户现场快速构建原型，熟练使用 Claude Code、Codex 等工具以及 Vibe Coding/Harness 方法，可以显著提高交付速度。但必须能够审核代码、补充测试并承担结果，不能只会让模型生成代码。

除本笔记外，还需要重点补齐三类能力：

一是客户发现，包括访谈、主动倾听、追问、需求澄清和高管沟通；

二是业务分析，包括流程图、角色与权限、价值链、ROI、成功指标和优先级判断；

三是企业交付，包括 POC 设计、项目范围管理、数据合规、安全、遗留系统集成和用户培训。

最好选择一个真实行业场景完成项目：先描述业务流程和基线指标，再设计 AI 方案，使用真实约束完成 POC、评估与生产化，并记录方案取舍和业务结果。这比单纯堆叠 Agent、RAG、MCP 等技术名词更符合 FDE 面试要求。

7. 不同岗位技术侧重点和面试技巧

大模型相关岗位虽都围绕同一类核心技术展开，但在实际职责、技能要求与评估重点上存在显著差异。了解不同岗位的技术关注点，有助于应聘者制定有针对性的备考策略，从而在面试过程中有效展现能力优势与岗位匹配度。

7.1 大模型相关岗位的能力维度差异

整体来看，大模型相关岗位可分为六类：算法工程师、开发工程师、数据工程师、推理部署工程师、垂直领域微调工程师和 FDE。每一岗位对技术深度、系统理解、工程实现、客户协作或行业知识的要求和面试考察方式也有所差异。

7.2 岗位技术侧重点分析

• 算法工程师：该岗位强调对模型架构、训练机制、优化策略的深度掌握，技术考察通常集中于 Transformer 结构细节、自注意力机制、训练范式（如预训练、微调、RLHF）、梯度更新原理与算法创新能力。具备扎实的数学基础与科研阅读能力是加分项，常涉及论文复现、模型重构、Loss 函数调优等实战题。
• 大模型开发工程师：该岗位更注重工程实现与系统集成能力，重点考察模型封装、API 接口设计、任务调度、状态控制、上下文缓存、日志系统等模块开发能力。熟悉 FastAPI、LangChain、Triton 等框架，能够独立搭建模型服务并实现业务对接是关键能力之一，面试中常通过系统设计题、代码走查和实际部署经验进行评估。
• 大模型数据工程师：该岗位要求具备处理海量文本、设计分词策略、数据增强与 Token 分析能力，尤其强调数据质量控制与处理效率。面试中常考察对语料清洗流程、Tokenizer 构建、分布式数据加载、格式规范化处理等方面的理解与实操能力，可能要求编写数据预处理脚本或解释复杂的样本结构。
• 大模型推理部署工程师：该岗位关注模型上线后的服务性能与稳定性，技术重点包括模型格式转换（如 ONNX/TensorRT）、推理加速（如 FP16、INT8）、KV Cache 机制、多卡并行部署与资源调度策略。面试中常要求分析推理延迟瓶颈、设计高并发推理方案，或解释模型在不同引擎上的性能表现。
• 垂直领域微调工程师：该岗位强调行业知识、任务定义、数据构造、微调策略和效果评估。面试通常关注 LoRA 等参数高效微调方法、领域数据质量、训练指标、过拟合与模型偏差，以及如何判断微调相较于 Prompt 或 RAG 是否更适合当前业务。
• FDE：该岗位强调客户发现、业务抽象、产品判断与端到端工程交付，重点考察能否从模糊需求中识别高价值问题，完成方案取舍、POC、生产化和效果验证。面试可能同时包含客户沟通与行为题、产品案例题、系统设计和编码题，并特别关注候选人的主人翁意识、完整交付能力和面对管理层的表达能力。

学习路线

了解了上述介绍后，我们在制定学习路线，应该根据自己的背景，专长等实际情况来分析。 我结合我个人背景来讲解一下我的学习路线的理由。

首先，我的背景主要是做的客户端开发，我没有后端知识。其实后端/前端/客户端甚至是测开，测试开发，都可以归类于开发。只是我们之前做的不是大模型的开发。 我预期之前做后端/前端/客户/测开/测试 等的同学们，应该都没有太多深度学习基础。 大模型算法本身要求就比较高，直接转行算法难度太高。数据工程师本身活杂，话语权低，上限也比较低。部署的话，还是需要强后端知识，还有模型知识，这些背景一般开发也没有。 所以我选择应用入手。有深度学习背景的同学，之前就做过模型训推，发论文的同学可以考虑从直接转大模型算法，推理工程师。如果有强领域倾向，比如做医疗的，法律行业的同学，可以侧重垂直领域微调方向。如果本身开发基础都比较少，也可以试试从数据工程师角度入手。

回到我们面向大模型应用开发的路线。我们的学习路线思路（其实也就是这个笔记的思路），先学完Agent,RAG 最核心的知识和项目，常见的应用技术：Skill,MCP, A2A等。然后你需要理解整个大模型的链路，从预训练到部署等，所以笔记设计了一些微调，强化学习，模型的知识，面试也会问，但是笔记设计的比较浅，偏向于理解。最后笔记思路是跑通了一个 数据准备/量化/LoRa/强化学习来使用本地模型推理，把推理，训练串起来。注意我这里用词是 跑通。 因为我确实没有深入做这些内容，侧重于用GPT写一个代码，了解流程，用云平台跑一下，准备好答案（你是怎么做微调的，你项目怎么做的量化之类，这些在笔记中有些）。到这里就够了，我没有深入，更不用去手撕注意力机制网络。

（注意，到26年7月左右，我开始真的学习算法，做算法项目了，我把上述说算法相关的内容，真的做了一遍，而不是简单跑通POC,这部分我作为进阶学习。笔记记在这里。 时间有限的话，你就和我一样，把笔记里的算法内容背一背，准备下相关问题，不要问到概念不知道就行了，不用做算法项目，这个属于进阶内容, 学有余力再学）

到这个阶段，我已经可以获取很多Offer了。接下来的路线：可以去学一下后端知识（如上节讲很多应用岗要求云端部署，Docker,kubernets)，有些后端出身同学可能已经掌握，但是其它比如前端，客户端，测试可能不会，可以去学一下，这个会加强竞争力，但是不是必要的。 我的个人选择是先放掉这里，去学习训练，推理，部署。 因为这样可以跳脱应用的框架，可以往算法，算法工程这些岗位去靠，上限更高，我后面即将和大家一起学一个训练的综合项目，就是为了深入学习。

所以路线供大家参考，大家可以根据自己情况修改。我想强调的一点是，这个行业其实倾向于综合型人才，我一直给自己的目标是懂算法，精工程，善部署。 如果目标是算法岗的同学是一样的，也需要学习了解工程知识比如Agent相关知识。 这点也确实体现在面试中。我面试其实一直学习的路线是应用路线，我后面做复盘，才发现很多面试的很多岗位其实他是算法岗，或者交叉岗位。我自己都没意识到，我写的意向是大模型开发，项目也是Agent，面试完复盘我才发现这是个偏算法的岗位。

另外一点我想说的是你只学工程（Agent,RAG)， 其实也可以找到工作。特别是有些大厂，比如阿里千问，我面试的时候，他们工程岗完全不关注你算法知识，让你从工程岗位回答。但是我建议学一下算法，这样上限高，竞争力也更强。如果你时间很紧，也可以趁现在行业发展刚起步，应用入行。 但是咱们有这个意识，以后朝着算法啊，推理部署方向再去靠，入行了再去学，变成综合性人才，或者慢慢转到算法，推理等岗位，上限比纯工程会高很多。

提升简历通过率，做深项目

哪些项目值得做，项目里的哪些地方值得做？如何让你的项目看上去更值钱，避免被面试官说浅。看完了这个章节，你也自己有一些想法，如何能够改进，做深项目，简历如何包装和修改。我目前想到的两个专题：

1. 2026值得做的AI项目/方向，如何做得深入，从Demo变成生产级应用？

2. 如何将后端技术融入到简历中，和大模型Agent项目结合。

了解了这些，对于你把控如何做深项目，如何包装简历，自己会有一定理解。

2026年真正有价值的AI项目

如果你想在 2026 年进入 AI 工程领域，或者想在目前的基础上进一步提升，下面这六个项目值得认真投入——当你坐在面试官面前时，它们会真正产生作用。

这里说的不是那种跟着教程做一遍、部署一个基础聊天机器人、然后写进简历的项目，而是这样一种作品：别人看过你的 GitHub 后会觉得，"好，这个人确实理解生产环境中的 AI 系统是如何工作的"。

关于做什么项目的建议往往让人无所适从，因为每个人观点都不一样，很难判断哪些内容真正重要、哪些只是噪声。因此这里把它归纳成六个项目，每个项目都对应一种独特且市场需求旺盛的技能。下面会逐一说明具体应该构建什么、使用哪些工具，以及更重要的——为什么每个部分都很重要。

这个小节的笔记，文字里我也一起总结了非常多的官方的参考文档，项目的链接。肯定读不完，按需要阅读。

下面介绍的6个方向，还是针对于大模型开发岗位来说的，如果要我排优先级：

Agent项目是必做的。

RAG重要性次之，但是几乎也一定要会的，监控和可持续性等于加分项，提升你这两个项目的竞争力。

LoRa和DPO强化学习属于加分项，非必要项，有的应用岗也会问。

多模态是可选项和加分项，做了以后可以去投递一些多模态方向大模型岗位。

生产级 RAG 系统

第一个项目是生产级的检索增强生成系统，也就是 RAG。它被频繁提及是有原因的：RAG 确实是目前企业 AI 中最常见的模式之一。

但必须明白，RAG 演示程序与真正可以投入生产的 RAG 系统之间存在巨大差距，而这个差距正是你能够体现自身区别的地方。

你要构建的是一个面向特定领域的 "Ask My Docs（询问我的文档）" 系统。选择一组文档，例如技术文档、研究论文、法律合同或医疗资料，然后构建一个能够检索正确信息、依据资料回答问题并给出引用的系统。

这里的关键词是引用。任何人都可以让大语言模型生成一个听起来可信的答案，但只有把答案建立在实际检索到的证据上，系统才值得信任。

1.1 第一阶段：完成基础功能

首先导入文档，包括 PDF、Markdown 或网页。然后把文档切成每块约 500～800 Token 的片段，相邻片段之间保留约 100 Token 的重叠。

重叠很重要，因为你不希望在边界处刚好切断一句重要的话，从而丢失上下文。接着，把这些片段转换成 Embedding，存入向量数据库。你可以从 Chroma 或 Weaviate 等工具开始。

然后构建检索流程：针对用户问题，取回相关度最高的 Top-K 文档片段，再生成答案，并标明信息来自哪里。

这一阶段的成果很直观：你可以向别人展示一份文档、系统生成的答案，以及答案所依据的准确段落。

延伸阅读：LangChain 官方 RAG 教程，一步步教你构建检索链。如果你是 LangChain / LangGraph 的新手，可以参考这个深入工作坊；

1.2 第二阶段：从演示升级到生产质量

这是大多数人从未做到的部分，因此也格外有价值。

首先实现混合检索，也就是把传统的 BM25 关键词搜索与基于向量的语义搜索结合起来。向量搜索擅长理解含义和意图，但有时用户会搜索某个非常具体的术语或短语，而 BM25 对这种情况处理得很好。

在此基础上加入 Cross-Encoder 重排序器。它接收第一轮检索得到的文档片段，把问题和每个片段作为一对输入重新评分。这样通常能够显著提高检索结果的精确度。相关原理可以参考 Cohere 的 Rerank 指南，它解释了 Cross-Encoder 如何工作、以及为什么能提升检索精度。

还应该实施引用约束：如果检索到的内容不足以支持某个明确答案，系统必须拒绝回答，而不是编造一个听起来合理的说法。

此外，把所有 Prompt 保存在带版本的配置文件中。Prompt 是系统架构的一部分，像管理代码一样管理它们，体现了真正的工程成熟度。

1.3 第三阶段：让系统真正具备交付能力

人工整理一套包含大约 50～200 个问答对的黄金评测集，并确认每条答案都正确。然后编写离线评测脚本，测量 Faithfulness（忠实度），也就是生成答案中的主张是否真的得到检索片段的支持。

把评测接入持续集成流程，让每个 Pull Request 都自动运行评测。如果质量低于设定的门槛，就让构建失败。

这正是生产 AI 团队的工作方式。在项目中展示这种纪律，会立即让面试官看到你理解 AI 系统的完整生命周期。

技术栈建议

流程编排：LangChain 或 LangGraph

向量数据库：ChromaDB 或 Weaviate

重排序：Cohere Rerank，或 Sentence Transformers 中的 Cross-Encoder 模型

评测框架：Ragas，专为评估 RAG 而设计，可衡量忠实度、答案相关性与上下文精度

完全离线的本地小模型助手

第二个项目是使用小语言模型构建一个完全离线运行的本地 AI 助手。这个项目的重要性常常被低估。

你可能会问：既然可以调用 GPT-5 这样的强大 API，为什么还要在本地运行能力较弱的小模型？答案是，现实中有许多情况不能或不应该把数据发送给外部服务。

你需要考虑隐私法规；某些延迟要求不允许网络往返；大规模使用时会受到成本限制；在边缘设备上也不能保证有互联网连接。企业非常重视这些限制，但多数候选人几乎没有处理这些问题的实际经验。

2.1 第一阶段：部署并测量

首先安装 Ollama，它是让开源模型在笔记本电脑上运行的最简单方式之一。下载一个 3B～7B 参数规模的模型，例如 Llama 3.2、Phi-4 或 Mistral 7B，然后为它制作命令行工具，或者用 FastAPI 封装成一层可用的接口。

第一阶段最重要的是测量。严格记录模型的推理性能，包括每秒生成 Token 数、首 Token 延迟以及总响应延迟。把这些数据写进项目文档，因为它们能够说明本地推理在现实中的取舍。

2.2 第二阶段：加入结构和确定性

要求模型按照指定 JSON Schema 输出，并使用 Pydantic 验证结果。如果输出不合法，就捕获错误并重新提示模型一次；如果仍然失败，则优雅地返回错误。

"约束生成 + 验证 + 重试"是生产系统中经常使用的模式，但在个人项目里却很少见。工具方面，Instructor 是业界标准，专门用于在 LLM 输出上强制 Pydantic Schema 并优雅地处理重试。

还应该研究 Temperature 参数。对同一批 Prompt，分别以 Temperature 0 和 0.7 运行，比较输出差异。这表明你理解语言模型具有随机性，也知道在可靠性重要时如何控制它。

2.3 第三阶段：进行模型对比研究

选择三个模型，例如 Llama 3.2 3B、Phi-4 Mini 和 Mistral 7B，在完全相同的硬件上测试它们。

比较内存占用、每秒 Token 数，以及它们在一套标准化的 30～50 条测试 Prompt 上的输出质量。把实际数据和分析写成简洁的技术报告。

模型选型是每个 AI 团队都要经常面对的决定。用系统性数据做选择，而不是采用社交媒体上最流行的模型，会让面试官看出你具有工程师思维。

如果想更进一步，可以测试这些模型的 GGUF Q4、Q5 等量化版本，并记录质量与速度之间的取舍。Hugging Face 的量化指南详细讲解了 GGUF、Q4、Q5 等格式如何在不严重损失质量的前提下压缩模型。这种严谨程度会让你的项目明显不同，也能帮助你真正理解 AI 工程的基础。

3. 监控与可观测性

第三个项目几乎没有人会去做，这正是建议你做它的原因。把项目一中的 RAG 应用拿出来，为它添加全面的监控和可观测性层。

在生产环境中，构建初始系统可能只占 30% 的工作。剩下 70% 是了解系统是否正确运行、失败时理解原因，以及迅速诊断和解决问题。

如果你能展示这种系统思维，就会立刻区别于那些只会"把东西做出来"的候选人。我们的笔记Agent评估 章节有更加详细工程化的的方法讲解如何去做Agent评估。包括RAG项目中，也做了阶段1阶段2。

3.1 第一阶段：追踪每一个步骤

为 RAG 流程中的每一步加入 Trace。对于每个请求，你应该能够看到：检索到了哪些片段、重排序器怎样改变了它们的顺序、发送给大模型的 Prompt 是什么、模型返回了什么，以及使用了多少 Token。

Langfuse、LangSmith 和 Braintrust 都可以帮助你完成这些工作。对于刚开始的人，尤其推荐 Langfuse，因为它是开源的，也可以自行托管，便于持续实验和迭代；它文档中的 "Tracing" 与 "Scores/Evaluations" 两部分正是这个项目需要的内容。LangSmith 则是 LangChain 原生的可观测性工具，很适合用来理解 Prompt 版本管理与链路追踪。

如果想系统性补齐评测（Evals）的知识，可以参考这个AI Evals 工作坊，其中包含完整概念讲解和动手实验。

3.2 第二阶段：长期追踪质量指标

这时你要开始像 AI 领域的站点可靠性工程师一样思考。

测量 P50 和 P95 延迟，而不只是平均延迟，因为平均值经常掩盖最差的用户体验。记录每个请求的成本，让你能够用金额衡量每次查询的花费。

测量引用覆盖率，也就是有多少回答真正建立在检索证据上。同时监控失败率：系统多频繁报错，或者生成它无法用资料支持的答案。

你最终应该能够做到：当别人问"上周二系统质量下降时发生了什么"，你可以打开仪表盘，指出异常，并解释根本原因。

3.3 第三阶段：建立回归质量门禁

把项目一中的评测集接入持续集成流程。如果忠实度或其他关键指标低于阈值，构建就会失败，该改动不能合并。

同时，对 Prompt 和配置文件进行版本管理，因为 Prompt 改动对系统行为的影响可能和代码改动一样大。

这是生产 AI 团队每天都在使用的工作纪律，在个人项目中却非常少见，因此非常有说服力。关于生产 AI 系统如何被架构、监控和评估，Eugene Yan 的 《Patterns for Building LLM Systems》 是一篇必读文章。

这个项目可能不像 AI 图像生成器或带有漂亮前端的聊天机器人那样吸引眼球，但它传递了雇主非常重视的一点：你会从整体上思考系统，而不只是关注中间的模型。很多 AI 团队目前迫切需要的正是这种系统级思维。

4. 使用 LoRA 和 DPO 微调

第四个项目是模型微调。关于什么时候以及为什么进行微调，业界存在许多误解。

微调不是让模型在所有方面都变得更聪明，而是让模型在一个定义清楚、即便认真设计 Prompt 仍然表现不足的特定任务上，持续保持优秀表现。

在微调之前，你必须找到一个能够清楚证明差距的任务：先展示基础模型配合精心设计的 Prompt 所能达到的最好成绩，再用指标展示微调后的提升。

强烈建议选择两类任务之一：从混乱的非结构化文本中提取结构化 JSON，或者提高工具调用准确率——让模型选择正确函数，并填写正确参数。这些任务中，微调往往会产生清楚且可以量化的提升。

4.1 第一阶段：监督微调

首先使用 LoRA 进行监督微调。准备大约 2,000～10,000 条干净数据。"干净"非常重要，因为数据质量远比数量重要。如果训练样本不一致或格式很差，你实际上是在教模型输出不一致、低质量的结果。

使用 LoRA 或 QLoRA 进行参数高效微调，这意味着你不需要庞大的 GPU 集群。一张 A100，甚至使用 QLoRA 的 T4，都可能完成任务。基础模型可以选择 Qwen3 8B 这一量级的开源模型。

在独立保留的测试集上使用具体指标评估，例如 JSON 有效率、完全匹配准确率以及正确拒答率——也就是当模型不应该回答时，是否会正确拒绝。

可用的 SFT 数据集：

• HuggingFaceH4/ultrachat_200k——高质量多轮对话数据，从 ShareGPT 风格日志中筛选而来，被开源指令模型广泛使用；
• nvidia/Nemotron-Instruction-Following-Chat-v1——NVIDIA 出品的大规模、高质量、可商用指令遵循与对话数据集，结合了经验证器筛选的助手对话与结构化输出样本；
• openai/gsm8k——8.5k 条高质量、语言多样的小学数学应用题，用于测试多步推理能力。

代码类数据集：

• nvidia/OpenCodeInstruct——500 万条多样化的 Python 指令-响应对，包含题目、解法、测试、执行反馈与质量判定；
• OpenCoder-LLM/opc-sft-stage1——聚焦代码理解与生成的多源精选 SFT 数据混合，用于训练 OpenCoder 系列模型。

4.2 第二阶段：偏好优化（DPO）

这一阶段用于证明你的理解超越了基础监督微调。

不只是告诉模型正确输出是什么，还要向它展示比较结果：对于同一个 Prompt，一个输出比较好，另一个比较差，让模型学习两者之间的区别。

为每个 Prompt 生成多个输出，标注哪些更好、哪些更差，再使用 DPO 风格的偏好优化方法训练。随后重新在测试集上评估，展示它相对于监督微调基线的进一步提升。

这能够证明你熟悉现代对齐和训练方法，而这些方法正在行业内被实际使用。

推荐的偏好数据集：argilla/distilabel-intel-orca-dpo-pairs——基于 Intel/orca_dpo_pairs 精选、清洗并增强的偏好数据集（prompt / chosen / rejected），适合做 DPO 对齐训练。

4.3 工具与呈现

这些微调阶段可以逐层叠加。工具方面，Hugging Face 的 TRL 库能够很好地处理 SFT 和 DPO；Axolotl 也能减少大量配置工作。如果不想管理云端基础设施，可以使用 Fireworks AI 这类 GPU 计算平台。

在项目说明中展示训练曲线，清晰列出训练前后的指标，并诚实说明过程中出了什么问题、你如何调整。面试官很喜欢看到候选人能够排查问题并适应变化，因为真实的日常工作就是如此——事情不会总是完美，你必须不断调整。

5. 实时多模态应用

第五个项目是实时多模态应用。这个项目让你展示自己能够处理流式数据、严格的延迟预算，以及必须实时响应的系统固有的复杂性，而不是只处理舒适的离线批任务。

你可以根据兴趣选择三条路线之一：

1. 语音助手：接收音频，通过自动语音识别把语音转成文字，把转写文本交给语言模型推理，再通过文字转语音把回答转换成声音。
2. 计算机视觉管线：把摄像头视频流交给目标检测模型，再让语言模型根据检测到的内容进行分析。
3. 流式日志分析器：实时接收服务器日志，进行异常检测，然后让语言模型生成人类容易理解的故障说明。

如果只能选一条，推荐语音助手，因为语音 AI 正在快速增长，相关工具也已经成熟。语音识别可以使用 Deepgram 或 Whisper，推理层可以使用任何合适的大模型，语音合成可以使用 ElevenLabs 或 Cartesia。WebSocket 很适合编排整个流程。

推荐资源：

• 编排框架：Pipecat AI——专为构建实时语音与多模态 AI 智能体而生的开源框架，帮你处理好 WebSocket 与延迟追踪；
• 语音识别（ASR）：Deepgram API 文档，包含优秀的流式音频转写指南；
• 语音合成（TTS）：ElevenLabs WebSocket API 文档，专门讲解如何用 WebSocket 把生成的语音即时流式返回给用户。

5.1 打通端到端流式管线

先专注于让系统从头到尾正常工作，不需要立刻优化。目标是让数据能够持续流动，正确定义事件结构，并让语言模型对实时输入作出响应。仅仅完整打通这条链路就已经是有意义的成果。

5.2 测量和拆解延迟

这一部分最能展示工程成熟度。把端到端延迟拆成详细预算。

对于语音助手，需要分别测量 ASR 延迟、LLM 首 Token 延迟、TTS 首音频字节延迟，以及各步骤之间的额外开销。为每个请求建立可视化延迟图。

如果你能说："总响应时间是 1.2 秒，这是各组件分别消耗的时间"，这种分析会让面试官感到兴奋，因为它表明你理解性能工程。

5.3 增加系统韧性

这一阶段关注系统出错时会发生什么。语音识别服务宕机怎么办？语言模型超时怎么办？系统必须具备优雅降级方案。

它可以退回到更简单的回答，也可以坦率告诉用户当前出现延迟，而不是一直沉默卡住。加入超时处理，确保任何环节都不会无限阻塞。

还要建立重放模式，让你可以把录制好的输入重新送入管线，复现问题并调试。

真正的生产系统就是这样设计的。认真考虑失败模式和恢复方式，会让你与只实现正常流程的人处于完全不同的层次。

6. 可靠的 AI Agent 系统

第六个项目是 AI Agent。这是目前最热、同时也是最容易做得很浅的方向——几乎每个人的简历上都有一个"Agent 项目"，而其中绝大多数只是一个绑了两个工具的 ReAct 循环。这类演示不会给你带来任何优势。

真正的分水岭在于：演示型 Agent 关心的是"它能不能跑通一次"，生产型 Agent 关心的是"它失败时会发生什么、花了多少钱、能不能复现、谁来批准它的危险操作"。Agent 是有状态的，而且错误会逐步累积；同样的提示词跑两次结果也可能不同。你要展示的，正是你如何驯服这种不确定性。

动手之前，强烈建议先读 Anthropic 的 《Building effective agents》——它把"工作流"和"Agent"做了清晰区分，核心观点是：大多数场景并不需要 Agent，能用确定性工作流解决的就别用 Agent。能讲清楚"我为什么在这里选择了 Agent 而不是工作流"，本身就是一个加分项。另外两篇值得读的是 OpenAI 的 《A Practical Guide to Building Agents》，以及 Chip Huyen 的 Agents 长文。

6.1 选题方向

在讲具体方向之前，先看一组数据——它比任何"哪个方向更酷"的讨论都重要。

对大量 AI 工程类招聘岗位的完整描述做关键词统计后可以看到一个很清晰的排序：招聘方最看重的是评测能力，几乎每两个 AI 工程岗位就有一个明确提到"评测（Evals）"，占比高达 55.7%；紧随其后的是 Agent 经验，占比 51.9%。相比之下，可观测性 / 链路追踪、微调、RAG、多智能体、工具调用虽然也会出现在岗位要求里，但比例明显低了一个量级，分别只有 16.9%、16.7%、11.2%、9.6% 和 5.2%。

最关键的一个数字是：在提到 Agent 的岗位中，有 68.4% 同时明确要求评测能力。

这说明了什么？企业要招的不是"做过一个 Agent"的人，而是"能证明这个 Agent 到底好不好用"的人。 不少岗位描述里直接写着要做"模型路由、Agent 架构、上下文管理、评测"；还有的写着"研究 Agent 行为，找出与高质量产出相关的模式，并把这些发现转化为训练数据、评测集或框架改进"。

所以选题的第一原则是：挑一个成败能被自动判定的任务。无法自动判定成败的 Agent，你根本没办法评测它，也就没办法证明任何事情——这一点比方向本身更重要。

第二个原则更现实：别做第十三个"深度研究 Agent"。这个方向的开源实现已经严重饱和，GitHub 上星标过万的同类项目就有十几个，最高的接近 8 万星。再写一个"搜索 → 汇总 → 生成报告"的循环，不会有任何区分度。

下面三个方向，是结合"招聘需求证据"和"工程含金量"筛出来的。

6.1.1 Coding Agent

给定一个 issue，让它定位文件、改代码、跑测试，直到测试变绿。推荐它的理由很实在：成败判定天然客观（测试通过与否，不需要 LLM 当裁判），而且有 SWE-bench 这样的公认基准，只跑一个子集就能得到可对比的数字。它同时天然涉及沙箱、多步规划、失败回退，工程含量最高。

起步不必从零写：mini-swe-agent 是个极简的参考实现，而 Agentless 走的是"不用 Agent 循环、纯流水线"的相反路线。把这两条路线在同一批任务上做对比，本身就是一个很好的项目——正好回应了前面那个问题："这里到底该不该用 Agent"。

另外有个值得知道的细节：Agentless 这类方案的失分，很大一部分不在"改不出正确补丁"，而在生成了多个候选却挑错了哪个。也就是说，选择往往比生成更值得优化——这是个很容易被忽略、但做出来很出彩的角度。

6.1.2 企业内部流程 Agent（招聘需求最集中）

这个方向在真实岗位数据里的信号最强：9.6% 的岗位（315 条）提到客服 / 工单 / 问题分流场景；而提到"人工介入 / 升级机制"的岗位有 14.4%，"内部流程自动化 / 审批"的有 13.3%。不少专注于企业服务和客服自动化的 AI 公司，本身做的就是这件事。

具体可以做什么：一个处理内部工单的 Agent（自动分类、查知识库、给出处理方案、拿不准就升级给人）；一个跨系统取数并按规则走审批的流程 Agent；或者一个报销 / 采购单据的审核 Agent。

这个方向的关键不在"能做多少事"，而在边界清楚、该停就停。所以务必把这几件事做出来并写进文档：什么情况下 Agent 必须交给人（这正是 14.4% 的岗位在要求的"升级机制"）、每一步操作留下可审计的记录、以及有副作用的操作必须先经人工批准。

但要先有心理准备：这个方向做不出漂亮分数。在模拟完整公司环境的 TheAgentCompany 上，最好的系统完整完成率只有约 30%。正因如此，正确姿势是不追求全能，而是在一个很窄的流程上做到稳定可靠，并诚实地报告失败率——这比一个什么都能试试、但什么都不可靠的 Agent 有说服力得多。

6.1.3 Agent 评测基础设施（最被低估，却是岗位要求第一名）

这是我最想推荐、但几乎没人做的方向：不做 Agent 本身，而做"评测 Agent 的工具"。

理由前面已经给了——评测是岗位要求里出现率最高的一项（55.7%），而提到 Agent 的岗位有 68.4% 同时要求评测能力。也就是说，做这个方向，你命中的是招聘市场上最普遍、最直接的一项需求；而且它天然能和项目一、项目三串成一条完整的线。

具体要做的是一套能回答"这个 Agent 到底行不行"的系统：

• 轨迹评测：不只看最终答案对不对，而是判断它走的路径是否合理、工具调用序列是否正确，并且能给部分分；
• 可复现的测试环境：把外部依赖固定下来，让同一个任务能反复重跑；
• 稳定性度量：同一个任务跑 N 次，报告成功率的波动区间而不是单次最好成绩；
• 成本核算：每解决一个任务花了多少钱、多少 Token、调了几次工具；
• 失败归因：自动把失败样本归类（工具用错了、上下文丢了、陷入循环、过早宣布完成……）。

为什么说它含金量高？因为这里有几个已被证实、但几乎没人在自己项目里处理的问题——LLM 当裁判时精确率没有一个超过 70%（意味着约三成被判"成功"的其实是失败），而单次运行的成绩本身就带着巨大噪声（后面"关于公开基准"一节有具体数字）。能把这些问题正面处理掉的项目，含金量远高于再做一个能跑通的 Agent。

两个不建议作为首选的方向。

一是 Text-to-SQL / 数据分析 Agent：它在技术上并非没有难度，但在上述 3,267 个真实岗位中只有 2 条提到（约 0.06%），且都来自本身就卖 SQL 产品的公司——招聘需求证据几乎为零。

二是浏览器 / 电脑操作类 Agent（computer-use）：它最吸引眼球，但对着真实网站运行时，反爬、验证码、页面改版都会让结果无法复现；而自建可复现环境的基准（如 WebArena、OSWorld）光镜像就要几百 GB、官方建议 1000 GB 磁盘，个人投入产出比很低。真想做，可以用确定性克隆站点的 REAL（112 个任务），成本可控得多。

6.2 ：把工具和循环设计好

这一阶段的重点不是"接上模型"，而是工具设计。Agent 的能力上限往往取决于工具的质量，而不是模型的智商。

• 工具即接口：每个工具都要有清晰的名字、明确的参数 Schema 和好的错误信息。返回给模型的错误应该是"简短但有指导性的说明"，而不是一大坨 JSON 报错——模型读不懂的错误等于没有错误。这方面可参考 Anthropic 的 《Writing effective tools for agents》。
• 控制住上下文：Agent 失败往往不是因为模型笨，而是因为没拿到正确的信息，或者信息格式太糟。LangChain 把上下文工程归纳为"写入、选择、压缩、隔离"四种手段（Context Engineering for Agents），Anthropic 也有一篇上下文工程专文。
• 必须有终止条件：设置最大步数、最大 Token 预算和单次任务成本上限。一个会无限循环烧钱的 Agent，在任何生产环境里都是事故。
• 工具接入标准化：可以了解一下 MCP（Model Context Protocol），它正在成为工具与数据源接入的通用协议，把自己的工具封装成 MCP Server 是个很好的加分项。

框架方面，LangGraph、OpenAI Agents SDK、Pydantic AI、smolagents 都是合理选择。但要注意：框架容易上手，却常常把"到底给模型传了什么"这件事藏起来。能说清楚每一步进入上下文的内容，比会用某个框架更重要。

6.3：状态持久化、人工介入与权限边界

这是把项目从"能演示"推到"能上生产"的地方，也是绝大多数人不会做的部分。

状态与恢复。 Agent 任务往往要跑几分钟甚至几小时，中途一定会遇到 API 超时、限流、进程重启。你需要让任务能从中断处恢复，而不是从头再来。这里有个值得讲清楚的区别：框架层面的 checkpoint 并不等于持久化执行——checkpoint 保存的是数据，而不是执行本身，进程一死任务就跟着死了。如果想深入，可以了解 Temporal、Restate 或 Inngest 这类持久化执行方案。在作品里能把"崩溃后从第 7 步继续，而不是重跑前 6 步"演示出来，非常有说服力。

人工介入（Human-in-the-loop）。 任何有副作用的操作——写数据库、发邮件、提交代码、花钱——都应该先暂停并等待人工批准。要注意实现方式：让进程空转等待是错的，正确做法是任务挂起、不占用计算资源，收到批准信号后再恢复。同时也要意识到"审批疲劳"这个陷阱：如果什么都弹窗，用户很快就会无脑点同意，权限控制就形同虚设。

安全与沙箱。 这是 Agent 项目里最能体现专业度、也最容易被忽略的一块。Agent 的核心风险是提示词注入：它读到的网页、issue、日志里可能藏着攻击指令。Simon Willison 提出的致命三重奏是个很好的分析框架——当一个系统同时具备接触私有数据、接触不可信内容、能对外通信这三项能力时，就存在被窃取数据的结构性风险，而目前没有任何检测手段能百分之百防住它，唯一可靠的办法是从架构上砍掉其中一条腿。相应地，OWASP 的 LLM Top 10 把**过度授权（Excessive Agency）**单独列为一项风险，对应的做法是最小权限、最小工具集、危险操作强制人工确认。

具体到实现：所有代码执行都必须放进沙箱，不要在自己的机器上直接 exec 模型生成的代码。可以用 E2B 这类沙箱服务，或者最简单的 Docker 容器隔离。浏览器类 Agent 可以用 Playwright 或 Browser Use。

6.4：评测与可观测性

这是整个项目最有价值的交付物，也是把它和项目三串起来的地方。

Agent 的评测和普通 LLM 评测不是一回事，因为你要评的是一整条轨迹（trajectory），而不是单个回答。LangSmith 的文档把它分成三层（见《Evaluate a complex agent》）：

• 最终结果评测：任务到底成没成功；
• 轨迹评测：它是否走了合理的路径，调用的工具序列是否正确。注意这里要能给"部分分"——Agent 做对了前几步只错了最后一步，和一开始就跑偏，是完全不同的两种失败；
• 单步评测：单独考察某一步，比如"面对这个任务，它选的第一个工具对不对"，主要用于调试。

轨迹比对可以直接用 agentevals，它支持严格顺序匹配、无序匹配、子集/超集匹配等多种模式——现实中"用不同顺序调用了同一批工具"通常应该算对，用严格匹配会误判。

要记录并展示的指标：任务成功率、平均步数、每个任务的 Token 成本与美元成本、工具调用失败率、人工介入率、超预算被强行终止的比例。可观测性可以复用项目三的 Langfuse；如果想更进一步，可以按 OpenTelemetry 的 GenAI 语义约定来埋点，它已经为 Agent 定义了 invoke_agent、execute_tool 等 Span 以及 gen_ai.invoke_agent.tool_calls 这样的指标，用标准约定而不是自己发明字段，是很专业的做法。

关于公开基准。 简历上能写"我在标准基准上测过"含金量很高，但要挑成本现实的：τ²-bench（客服场景下的工具调用与规则遵守，注意初代 τ-bench 已被官方标记弃用）和 BFCL 函数调用榜对个人来说成本可控，SWE-bench 可以只跑一个子集，GAIA 和 AssistantBench 适合研究型 Agent。

但请务必理解：这些基准的分数比它看上去噪声大得多。 有三个数字值得记住：

• 多份 2026 年的审计显示，大约每 6 个被判定的样本里就有 1 个判错；
• 完全相同的配置重复跑 23 次，成绩从 57.9% 到 76.8% 不等——单次运行的数字基本等于噪声；
• 同一个模型在同一套任务上，仅仅因为脚手架不同，成绩就能差出 19.6 个百分点。

最后这一条其实是你做这个项目的最好理由：模型不是变量，工程才是。 也正因为如此，真正专业的做法是报告三个数字，而这三个都是玩具 demo 给不出来的：重复多次运行的稳定性（而不是单次最好成绩）、每解决一个任务的美元成本、以及一个能把"脚手架的贡献"和"模型的贡献"分离开的消融实验。

顺带一提，成本差异比大多数人想象的极端。普林斯顿的 HAL 榜单公开了两万多次运行的"成绩-花费"配对数据，其中最有意思的一组是：两个配置拿到了完全相同的准确率，成本却相差 64 倍。在 τ-bench 上也有类似情况——56.0% 的配置花 11 美元，54.0% 的配置花 180 美元。把这类对比放进你的项目报告，比多刷两个百分点有说服力得多。

7. 如何写进简历

做完项目只是一半，另一半是让别人在 30 秒内看懂你做的东西值钱在哪。这一节把前面所有技术内容翻译成简历语言。

7.1 一条核心原则

简历上真正有杀伤力的，是"我测出来了什么"，不是"我用了什么"。

对照几个例子就很清楚。

写"使用 LangChain 和 ChromaDB 构建了 RAG 系统"，不如写"构建 RAG 系统并建立 200 条黄金评测集，接入 CI 质量门禁，忠实度低于阈值自动阻断合并"。

写"基于 Ollama 部署本地大模型"，不如写"在同一硬件上横评 3 个本地模型，量化其吞吐、显存与质量的取舍，据此完成选型"。

写"开发了一个 AI Agent"，不如写"Agent 任务成功率 X%（重复 5 次的波动区间 A%–B%），单任务成本 $Y，人工介入率 Z%"。

写"实现了多智能体协作系统"，不如写"对比单 / 多智能体两种架构，实测多智能体在本任务上成本高 3 倍而收益不显著，最终选择单 Agent"。

注意前一种写法全是输入（用了什么工具），后一种全是输出（得到了什么结论）。工具谁都会写，结论只有真做过的人写得出来。

7.2 六个可复用的包装方向

无论你做的是哪个项目，都可以从这六个角度找素材。它们几乎都能套用到任何一个 AI 项目上。

方向一：可量化的质量指标

把"效果不错"换成具体数字。忠实度、引用覆盖率、任务成功率、JSON 合法率、拒答正确率——任何一个都行，关键是有数。 素材来源：项目一第三阶段、项目四的前后对比。

方向二：评测体系与质量门禁

这是当前招聘需求里出现率最高的一项（55.7% 的 AI 岗位提及，提到 Agent 的岗位更有 68.4% 同时要求）。写清楚你自建了评测集、接入了 CI、质量退化会阻断上线。 素材来源：项目一第三阶段、项目三第三阶段、项目六第三阶段。

方向三：成本与性能工程

每请求成本、P50/P95 延迟、Token 消耗、每任务美元成本、首 Token 延迟。这类数字极少有人写，但一写就显专业。 素材来源：项目二的基准测试、项目三第二阶段、项目五的延迟拆解。

方向四：可靠性与故障处理

超时处理、优雅降级、断点恢复、重放调试、失败率监控。重点是让人看出你想过它会怎么坏。 素材来源：项目五第三阶段、项目六第二阶段。

方向五：安全与权限边界

沙箱隔离、最小权限、危险操作人工确认、提示词注入防护。真实岗位里"人工介入 / 升级机制"的提及率有 14.4%，是个被严重低估的加分项。 素材来源：项目六第二阶段。

方向六：工程判断力（最稀缺）

不是"我做了什么"，而是"我为什么没做某件事"。比如：评估后选择工作流而非 Agent、试过多智能体后退回单 Agent、对比后选择了更便宜的小模型。 素材来源：项目六的选题原则与多智能体那一节。

7.3 两个完整示例

示例一：RAG 项目（项目一 + 项目三）

改写前 ——

企业知识库问答系统 使用 LangChain + ChromaDB 搭建 RAG 系统，支持 PDF 文档解析和问答，集成 OpenAI API，实现了较好的问答效果。

改写后 ——

企业知识库问答系统｜可评测、可监控的生产级 RAG

• 实现混合检索（BM25 + 向量）与 Cross-Encoder 重排序，Top-5 检索精度较纯向量方案提升 X%
• 设计引用强制机制：检索证据不足时系统主动拒答而非编造，无依据回答率从 X% 降至 Y%
• 自建 200 条黄金评测集与离线评测脚本，接入 CI——每个 PR 自动跑评测，忠实度低于 0.85 即阻断合并
• 接入 Langfuse 全链路追踪，监控 P50/P95 延迟、每请求成本与引用覆盖率，可定位任意一次质量波动的根因

关键差别：改写后每一条都有动作 + 机制 + 数字，而且第三、四条直接命中"评测"和"可观测性"这两项高频岗位要求。

示例二：Agent 项目（项目六）

改写前 ——

智能助手 Agent 基于 LangGraph 开发多智能体协作系统，接入多个工具，能够自主完成复杂任务。

改写后 ——

内部工单处理 Agent｜带权限边界与轨迹评测

• 设计 8 个工具接口并规范错误返回格式，使模型能据错误信息自主纠正，工具调用失败率从 X% 降至 Y%
• 实现断点恢复：任务状态持久化，进程崩溃后从中断步骤继续而非全量重跑
• 建立权限边界：写操作一律挂起等待人工批准，任务级 Token 与成本上限防止失控循环，人工介入率 Z%
• 构建轨迹评测体系（最终结果 / 轨迹 / 单步三层），支持部分给分；重复 5 次运行报告成功率区间 A%–B% 而非单次最优
• 对比单 / 多智能体架构：多智能体成本高 3 倍且收益不显著，据此选择单 Agent 并记录决策依据

关键差别：改写前那句"多智能体协作"看似高级，其实是减分项——它暴露了没做过成本核算。改写后最后一条反而成了亮点，因为它证明你会做技术选型，而不是堆技术名词。

7.4 三个常见的坑

1. 别写"熟悉/了解 XX" —— 简历上的"了解 LangChain"约等于没写。换成"用 LangGraph 实现了带断点恢复的任务编排"。
2. 数字要能被追问 —— 写了"成功率 85%"，就要能答出：测试集多大？跑了几次？成本多少？失败的 15% 是什么原因？答不上来的数字是负资产。
3. 别堆技术栈 —— 罗列十个框架名不如讲透一个取舍。面试官真正想知道的是你为什么选它，以及你放弃了什么。

8 结语

看完了这些内容之后，大家应该知道什么简历是好的，是具有价值的。如果你觉得你的项目做的浅，应该如何去包装。但是最后我想强调两点：

切勿眼高手低：做一个生产级别的项目是很难的，很耗时的。不要上来觉得我必须要一个生产级别的项目，才能拿到大模型Offer的入场券。当你的各种能力达不时，直接给你简历写一个生产级的项目，你也说不清楚，讲不清楚。如果写的简历很高级，一问让面试官觉得你在造假，反而减分。上面的内容和项目都有分阶段，最好的方法是一个阶段一个阶段的来，只有你做了，才真正是你的。

我希望教大家什么是好的，应该往哪里改进。但不是告诉大家，你面试的时候，比如一个项目是有一个完整评估流程，CI/CD持续集成，企业级的错误处理和回退，完整的版本管理，真实的用户数据集你才能去面试。绝对不是这样的！特别是对于经验年限不多的，甚至是可以放缓到工作5年以内经验的同学，脚踏实地，按照这个方案去做，在你的能力范围内适度包装一下，去面试是没有问题的。越是工作年限越长，越是需要做的项目更加生产级别和成熟。

9 讲解视频

https://www.bilibili.com/video/BV1cs3d69ET8/?spm_id_from=333.1387.homepage.video_card.click&vd_source=144bec9c3f54e465073138bed788be1b

答疑

1. 后端知识在大模型行业中重要吗？

从上面的岗位介绍中，我们可以看出来大模型的某些岗位和后端知识有重叠。比如有的应用岗要求本地，云端部署，容器化（Docker), Conda, Kubernets。 而推理部署岗注重推理服务性能，成本，稳定性。 二者相比，应用岗对于后端虽然重要，但不是必要要求（我没有后端经验，但是面试了很多应用岗位），优先级会低于Agent,RAG 的核心技术栈。比如我面试的阿里夸克千问C端，就是一个应用的后端岗，但其实面试官没问过我后端知识，我也没后端技术栈，最后也通过了。 我承认后端知识对于应用岗是重要的，但是因为非必要，我还是稍微降低了后端知识的优先级，学完了应用，先去学习部署/算法。 相比于应用岗，推理部署岗位明显对于后端要求更高，同样需要Docker,K8s, 但进一步要求推理服务，延迟，吞吐测评，后端是该岗位的核心竞争力。 总结来说，算法岗/应用岗/推理岗对于后端能力的要求是：

推理部署岗>>应用岗>算法岗

所以，具体的路线还是要因人而异，自己适当调整。我的路线是先学了应用->算法，变成一个复合型人才。然后可能再去考虑后端。 但是如果说自己的定位就是纯应用，学完Agent,RAG, 再去学习补齐后端知识是合理的。 补齐后端开发，会增加你面试大模型应用的竞争力和简历通过率。 但是另一个角度，你也可以走另一条路线，去学一下算法（训练比如Lora,强化学习，推理部署的内容），这也可以增加你的竞争力，很多应用岗位也会问一些算法的东西，甚至要求应用算法都会，学了算法也会多一些机会，提高自己的竞争力。

所以啊，当你学完了Agent, Rag, Skill,harness等等这些大模型应用相关的知识后？你一定已经可以面试了，绝对有机会，把握好可以上岸。 但是如果你还想学，时间更多，可以去学后端，也可以去学算法，是不一样的路线。我选择了去学算法，学了算法，把算法的内容可以加到Agent应用上，也可以增加简历竞争力。我至今为止没有学后端。 不是我不想学，是我学了一年，也才慢慢地学习算法，要学的东西太多了，我们不可能满足市场上所有要求吧，尽量吧。目前你要是想学算法，和我的路线一样，那么恭喜你可以完全复用，复用学习思路，资料，项目。如果你想选择学后端，那么笔记里暂时没有资料，也许算法做完，我下一个Agent项目（26年年底开发）可以带一点后端，不知道大家赶得上吗？

2. Agent项目浅，如何优化

粉丝提问：我的Agent项目做的很浅，没有一些复杂的机制，就是简单的意图识别+workflow, RAG部分也是别人做的。面试时候不太好吹怎么办？

回答：

是的，确实是建议继续深入优化：

1.从Agent层面。建议引入更多深入的地方。比如记忆模块，长短记忆怎么做的，有没有什么高级策略。 能不能结合一些策略让客服记住长期状态，回答更符合用户特点。能否有一些反思，规划功能。参考我笔记中推荐的《Agentic design pattern》 的设计模式，能不能加一些高级功能。

2.RAG.我自己也有类似的问题，我的项目中RAG做的不深入。我的情况是自己手搓了一个RAG项目，你可以看到就在笔记中过的。既然你项目都有现成的RAG,，虽然不是你做的，但你去把代码弄明白，RAG的各个机制弄清楚，弄懂了就是你做的啊。只要你掌握了RAG知识，把这块就变成是你自己做的。

3.推理优化。你完全可以参考我笔记中的思路。如果你仔细看我的笔记，我是从工程出发，应用是我的强项，但是为了处理面试官会问我算法的问题。我专门按照自己加入了推理，微调，量化的机制。 这里不复杂的，你要去学相关知识，然后把流程用最简单的方法走一遍，然后准备下相关问题，加入到简历，自信去说就行了。怎么做的我笔记里都有，你完全可以复用。 这里不用担心掌握不深入。原因是通常应用的岗面试官即使问了算法，他也问不深，他自己不可能做到又专应用又专算法的。 所以在我们时间有限的前提下，先把应用弄好，算法按我的思路先去走个大面。

粉丝追问： 我不是真的在生产项目做的，只是自己美化的，那这样会露馅吗？

回答：不会啊，大胆一点，我不是让你纯编，我是让你做一遍。我自己项目也是我自己做了一遍量化微调的，很简单的，你又不用负责效果，把流程走通，把面试会问的提前想好就行。常见的问题我都汇总了，你可参考，而且实测一般应用岗问的算法，问了也不深入，我的笔记里都是一次次迭代，你就照着我的笔记复习。我就是完全根据面试官问的情况来总结的答案的深浅，如果他问的深，我的笔记也会写的深入。所以你算法这部分，你把我笔记的内容弄懂，结合你的情况想一想不用担心，这就是我实践总结出来的，面试完全够用，而且我还在一直迭代，你就放心照着准备吧。

3. 网页RAG项目选型

粉丝提问：我现在做的项目是一个在网上搜索相关演员信息的项目，然后匹配准确度，目前我召回的文本和内容不相关，有一些什么优化方法啊，我需要从多个维度，比如名字+项目+身份 去联合搜索吗？分块我用什么好？用你的项目的递归分块吗？ 我需要使用数据库吗？怎么包装一下呢？我目前项目就是用Langgraph写的demo，能帮我做一下技术选型吗？

回答：1.分关键字检索思路的是对的，但是你看是不是不是分开检索，而是把这些关键词合并。拆开反而会放大噪声。比如 张三，红楼梦，贾宝玉，你提取这三个关键字，然后组合搜索。

2.分块问题。分块问题也不是说用我的递归切块比较好。我这个方法是比较通用性的方法。针对你的问题，网络文档，通常噪声比较大，可以先去噪声（导航，广告之类的），提取出纯文本以后可以用最普通的滑动窗切块。因为一般你要的信息，比如张三，红楼梦，贾宝玉，可能就在一个连贯的chunk中，用递归还容易切掉信息。

3.分块匹配一般就是粗排和精排。 你说的向量余弦相似度，这里其实有不同方法的向量可以做选型，比如BM25，OpenAI 的embedding等。你图方便可以用BM25做粗筛，然后精筛是解决你说的不相关问题的核心。可以用LLM匹配，也可以用Cross-encoder，这是两个经典方法，解决你说的召回内容不相关问题。

4.向量存储，网页搜索确实可以不做本地化存储，动态筛选了以后去做切分召回，然后销毁，这也是合理的。

4. 我的情况可以入行大模型吗？

粉丝提问：博主你好，我本人是24年毕业生，985硕士，机械专业，毕业当年去了一家国企，本来岗位是机械研发岗的，但由于公司在数智化转型，去年被抽调去参与了一年的数智化开发工作，算是有一年的后端开发经历。我算你最早的那一批原始粉丝[害羞R]，也买了你的学习资料，非常详细，但虽然都是0基础ai经历，咱们的0基础还是差的蛮多的，你一直从事的是互联网行业，而且有可以加入ai开发的场景。但我觉得我只能从网上找项目，且几乎不太可能有机会将项目和我工作场景结合起来，但看你的面试反馈，似乎面试官对真实的项目开发经验更看重，我这样跟着网上的项目学习（即使有自己的改进），这样简历能过吗[哭惹R]？转型的可行性大吗？心理挺没底的。

回答：首先回答你的问题，你一定可以转行的。 我能理解你转行的时候其实心里觉得没底，这个大家都是这样的。我在当初想转行的时候，也很迷茫，我问了我大牛同事，他的回答是没有能不能转，只有想不想转。经过我自己的实践，我的答案是转到大模型没有你想象的那么困难。

首先以大模型开发为例，它的门槛和普通传统开发是一样的，普通开发大家知道吧，就是程序员，所以门槛并不高的。并不是所有程序员都是大厂的，很多中小厂的程序员，学历也不是很高，所以不要因为它沾上了大模型这个字，就把大模型开发这件事想的很难。其次，大家看一下现在的招聘市场，大模型开发相比传统开发，岗位是更多的（薪资也高一些），所以大家的机会更多，从这个角度，入行大模型开发比传统开发还容易一点。

从技术角度来说，你要做的是补齐大模型应用相关的知识，文档里都有我就不说了。你从后端开发转到大模型开发，本身你后端开发就多少有一些优势（相比前端，测试，客户端）转到大模型的岗位。

第二个，学历挺好，985硕士做开发足够了呀。很多学历比如一本这样子，其实做大模型开发也没太大问题，门槛对标的都是普通开发，不要因为沾上大模型就把他想的很难。

第三个，你工作才一年。转行这个事情真的是年限越长越难转，一年工作时间，甚至是3年时间，企业对你的包容度都很高的。甚至可以放宽到5年。我自己是4年转行开始面试的，企业对我的要求只会比你高。

第四个，面试官看重真实项目。这点确实是，毕竟是转行，都是自己做项目的，我们的项目相比天然做大模型开发的一定会有劣势，这个没办法。但是有很多解决方案，第一个不断加深项目，我一直说项目不是一下子完成的，我在面试的时候也是一边面试一边做项目。第二个就是把项目往工作上靠，结合工作场景。你说看我的面试反馈，很多面试官看重真实项目，是这样的，即使到现在，有的公司还说我项目不深。 但是你也应该看到反面啊，就面试不到20家，我就有6个offer。京东面试官即使我没做过算法，+2还很看重我，给我发算法Offer, 薪资也很高。阿里的面试官，你去看我的面经，到后面他都不在乎你项目做到什么程度，他和我讨论未来的架构，未来的扩展，他更看重的是思维能力。 你比我工作经验少3年，企业对你只会更包容。 要学的东西太多了，我一直在补充。去年12月份的我和现在的我，能力又不一样，我现在特别相信，我继续学习，不断掌握新知识，不愁面试的，我的目标已经从应用编程转向大模型全栈或者算法了。

所以怎么看，我觉得你都不用心里没底啊，更重要的是，这些东西你能不能掌握，能不能把RAG,AGENT等应用知识都学透，甚至是在学好算法，部署，入行真的没有你想的那么难。迷茫的时候就多学一下，当你真正学好了，你去面试了，市场给你答案的时候，你的问题都会解答，而且你会发现做大模型并没有你想象的那么难。而且大模型现在缺口那么大，岗位很多的，你看我笔记2025年度报告，这么多岗位，怎么会没有你一个985硕士的位置呢，你要想的是尽量学好，拿更高的Offer，而不是犹豫能不能入行。

更新记录

2025/12/07

1. 学习路线中增加自学转行如何确定项目，设计项目的原则，怎么完成自己的项目？

2. 补充12月小红书大模型岗位一面内容，更新完了问题部分，反思和知识部分待整理。

2025/12/08

更新完善小红书面试对应问题答案。 答案部分快总结完了，还差一点，明天可以完成小红书的答案部分。

2025/12/09

完成小红书一面笔记的答案部分，开始更新字节面试笔记（字节面了两个部门，两个都会整理）

2025/12/10

整理完字节大模型工程岗， 一面面试问题

2025/12/11

基本完成字节大模型工程岗， 一面面试问题对应答案。根据面试情况完善了MCP笔记八股部分，八股部分新增A2A协议的概念（因为出现过两次了，说明A2A协议也是要准备的）

2025/12/13

更新Multi Agent对应的知识。 在之前的参考资料中，我给大家推荐的《Agentic Design Pattern》中的Multi-Agent这一章，但是这一章的讲解不够深入，特别是对于架构设计这一块也比较浅，这是在针对小红书的面试的时候，这些知识显得不够。

我将Multi-Agent相关的知识更新，替换成《Towards a Science of Scaling Agent Systems》这篇论文相关的内容，补充了相关知识，参考材料和思路，让相关内容更加权威，准确，深入。（没总结完，总结更新ing)

2025/12/14

完善了多Agent 八股部分，采用更权威论文作为知识总结来源，也完善了小红书一面对于多Agent架构问题讨论的回答。

添加面试讲解视频：

小红书一面，滴滴一面，安克科技一面，灵动时刻一面，京东一面，京东二面

2025/12/17

完善了下Langgraph的八股，加了一个很全面的Langgraph知识的参考文档，是个很全的Langgraph知识大全，遇到不懂的可以直接查这个文章。具体文章链接看Langgraph八股部分。

添加了多Agent的通信方法和状态管理，也是面试考点。

总结了阿里国际站的问题和反思，答案和解析部分未完成。

优化常见Agent框架知识：按照目前最火的5个架构整理，忽略其它top5之外的框架

2025/12/18

更新完阿里国际站一面答案部分，根据面试情况，更新了Langchain版本相关的八股内容和参考资料。

2025/12/20\~21

重构Agent性能评估八股部分，包括参考资料，常见的问题，以及答题思路和准备方法。

完成京东三面面试题答案和面试思路，上传 对应讲解视频。

今天我通过京东这个面试复盘，彻底重新梳理了Agent 性能评估这个超重要考点，在京东三面讲解视频中也着重讲这个点如何复习，准备策略，相信通过这一面的知识你能把这个点弄透。

上传了阿里国际站 电话面讲解视频

2025/12/23

整理字节一面面试问题

2025/12/24\~25

整理字节一面面试的答案，并根据面试内容，调整八股内容：

1. 微调方法论部分，加入参考文档，详见八股（你是怎么做微调的）
2. Multi-Agent八股部分，增加Single/Multi agent的对比
3. 添加八股 你在做项目中遇到最困难的问题以及如何解决的 相关问题答案和解决思路。

2025/12/28

总结完了夸克千问一面，二面面试问题

2025/12/29

1. 上传字节（豆包）一面讲解视频。
2. 完成夸克千问一面答案，千问二面反思部分。
3. 完善了问题-你在项目中遇到的最难的问题，如何解决的？

2026/1/4

1.完善多Agent八股部分，设置第四小节，多Agent的架构设计题目，结合笔记给出的参考论文例子和笔记的面试内容，来汇总架构设计题目和答案。

2.总结完成夸克千问二面问题和答案。

2026/1/5

录制并上传夸克千问二面讲解视频。

2026/1/5 \~2026/1/8

主要在做项目的调研，我开始丰富完善项目部分，今天写完了项目实战的介绍部分。

接下来会继续调研，写这个项目的技术选型和具体方案。

因为我后面会花比较大的精力在项目上，可能更新面试实战部分会慢一些，我这周会把所有面试的公司先都加到目录上，如果有哪个朋友特别需要某一个公司的题目，可以私信我，我先更新。

2026/1/10

1.更新完阿里HR面。

2.把所有未整理的面经素材留了个白，后面陆续整理。

3.更新项目实战，技术方案选型。

2026/1/12

更新项目文档：项目概述和核心特点部分

RAG分块内容加入一个讲解参考视频

2026/1/13

更新项目文档：项目概述和核心特点部分 3.1 RAG核心流水线设计。

2026/1/15

更新项目文档：MCP服务设计

2026/1/16

更新项目文档：可插拔架构设计 pro

2026/1/17

新增Skills 的八股部分：概念，和mcp对比，和prompts对比，运行模式，设计理念。

提供参考视频和参考项目

2026/1/21

新增项目Github地址。接下来几天我重心会放在更新面经部分，更新几期面经哈。

2026/1/22

更新完啦Deepwisdom的问题部分

2026/1/23

新增粉丝提问和答疑章节，我把粉丝朋友问我的一些问题和答案汇总在这里，这样大家可以参考，共同进步哈！其中问题部分我已经做了优化，在我的认知里不会有隐私问题，但是如果粉丝朋友觉得这个问题不便于公开，联系我删除哈。 大家一起进步！

2026/1/24

更新完deepwidsom的问题解析。

优化了八股答案： 你是怎么做Agent评估的，之前有点太AI化了，优化成一个可以直接回答，更口语的答案。

根据面试问题新增八股模型部分：如何判断模型能不能跑，跑的有多快

2026/1/25

更新平安证券一面面经和答案。

八股增加了一个面试技巧环节，更新自我介绍和反问的一些策略。

八股增加模型部分Qwen2.5->3的升级

上传录制视频：项目实战部分skills的使用视频，Deepwisdom 一面讲解视频， 平安证券1面讲解视频

2026/1/26\~2026/1/27

项目进度完成17%, 提交相关代码

2026/2/1

Rag-Agent项目进度45%，目前在写C阶段，C阶段是数据存储阶段，等写完C阶段，就可以有一些可以展示的东西了，他是独立的，对数据处理然后存到数据库中的一个离线模块，也是整个系统比较重要的模块。

更新了平安证券二面相关问题和回答。

Skills 推荐项目部分加了一些链接介绍。

2026/2/7\~2/8

1. Rag-Agent项目进度已经完成84%，目前也录制一些项目相关的视频，放在了小红书上，我会都归档在笔记链接中。
2. 更新一期面经：盛大AI一面
3. 更新八股： 我在笔记中 你的项目遇到的最困难的问题是什么，如何解决的这个问题，又加一个例子。这个例子是结合我们RAG项目写MCP Server总结的。
4. 更新参考视频。在MCP章节，我更新了一个MCP 参考视频，从入门到进阶的视频。这些都是我当时看的。MCP从0基础到精通，把这几个视频看了就差不多了。（另外粉丝朋友说有的人不能科学上网，所以我视频也尽量找的都是中文的视频网站了，虽然这几个推荐视频我当时在油管看的，但还好他们是中国博主，国内也能找到地址，不过还是建议程序员要能科学上网呀，有的资料可能真的必须要到外网去看了）

2026/2/10

更新项目视频

2026/2/24

休假结束，开始更新啦。今天更新了一个大章节。大模型岗位介绍。

2026/2/25

全面优化补充Skill 章节笔记，加入更多内容，参考文档，润色内容。

2026/2/28

笔记更新了简历编写技巧和面试准备建议

另外dev分支更新了自动编写简历的SKILL(暂时没有同步到其他分支），感兴趣可以先试。

2026/3/1

更新项目相关视频：介绍test skill和resume skill如何写的，视频里讲了项目SKILL如何写的，SKILL设计思路，以及使用这个项目面试的一些建议。

更新了盛大AI面试的讲解视频。

2026/3/6

项目更新了setup SKILL和对应视频：大家使用它可以一键配置环境。

项目更新了项目复习和模拟面试SKILL以及对应视频： 大家在面试前通过它，可以快速突击，掌握核心知识。

项目更新了完整的README：提供了一些说明，不同的人群如何使用，常见的问题的说明。

整理了项目，DEV, Main,Clean Start相关的分支整理完毕，请大家按需使用。

2026/3/7

更新了Openclaw常见的技术细节和框架，掌握这一小节，你将知道Openclaw到底为什么这么神奇，如何实现的？他不是魔法，而是一个合理的框架。

最后总结了8个Openclaw面试问题，快问快答，帮助大家检验是否掌握。

最后也给出了参考视频：如何配置Openclaw以及openclaw技术讲解。

Openclaw，面试必看哈\~！

2026/3/11

主要在学习pytorch， 我准备把这些变成一套超级叼（自认为）的SKILL，里面包含了我的复习路线，参考视频，到时候大家学习复刻我的路的时候，直接用就好了。

然后就是会出一些论文专题，因为论文特别重要，你们这周会看到笔记会多一个论文阅读专栏。

最后就是RAG项目的真题，已经有粉丝朋友和我反馈他用这个项目的面试真题了，我也真的希望大家也可以反馈给我，这样我都会整理更新在笔记中，帮人帮己。当然我自己也会去面试的，但是我太忙了，有太多东西要更新了，等我反馈RAG项目真题可能比较慢了。

2026/3/12

增加了笔记的新的篇章：论文部分。

写了为什么要读论文的思路，也总结了我们这个部分的第一篇论文：《Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?》

2026/3/13

更新了笔记项目部分的一个 面试实战和问题解析。

2026/3/14

笔记设计思路和大模型学习路线彻底大重构。

我之前写这个学习路线的时候是25年12月，现在有了更新的技术，思路，所以路线值得重构。

2026/3/15

1.更新SKILL学习路线，新增一个推荐视频：某个博主讲如何写SKILL的实战。

2.更新RAG进阶内容：包括Graph RAG, Agentic RAG, 知识图谱。

3. 新增RAG项目面试真题：离线解析部分相关面试真题。

2026/3/17

1. 更新Openclaw的记忆模块解析，我认为这里很重要，因为记忆功能面试必考，Openclaw本身也值得学习。

2. 优化八股：Agent记忆是如何实现的。直接加入Openclaw实例，结合经典知识讲解，面试官问到直接秒杀。

2026/3/19

RAG项目新增两个大厂面试真题及解析（感谢粉丝朋友的投稿！！！！）

2026/3/20

抱歉拖延久了，上传了Pytorch/深度学习入门的SKILL，在大模型算法0基础学习全记录，2.1小节。需要的朋友请自己取

2026/3/21

上传了联想大模型岗位一面面经记录。

2026/3/22

上传了华林面试一面面经揭露

2026/3/23

添加了Harness工程的内容，有几个同学反映这是面试会考察的内容。

另外新增了AI通用素养章节，我将SKILL, VibeCoding等技巧放在了其中。因为我相信这是新时代对每一个人的要求，它不属于大模型应用开发，算法等大模型岗位，而是每一个程序员，甚至是产品在新时代必须掌握的技巧。

2026/3/24

论文部分，添加了对最近最火的论文：Kimi的注意力残差的解读。

2026/3/28

在AI通用素养章节，加入Claude Code从入门到精通：涵盖Claude Code的概念，基本使用方法，最佳实践建议，面试问题和参考视频

2026/3/29

更新Openclaw 多Agent框架解析/多Agent之间的通信机制以及相关面试问题，这两个内容对应着面试的高频考点，我们希望能从Openclaw这个架构中找到一些思路和启发。

2026/3/30

总结两个粉丝朋友提供的大厂项目面试真题，两个都是大厂，国内排名前10的公司。

2026/3/31

补个SKILL的推荐视频，讲解的是如何去写一个SKILL，作者的核心思路是FeedbackCycle，写Skill分成这四步，我是很认同的。通过他这个视频，他告诉你如何去写SKILL，通过实践讲解。.

2026/4/1

更新华林二面的视频。

2026/4/9

旅游回来了，继续给大家更新。最近更新一下Claude Code源码，架构的内容。粉丝已经催了很久了，毫无疑问这个是最近超高频考点。大家要有这个意识，大模型岗位，对于那些爆了的热点知识，一定是最近常考的。

拆解Claude Code源码，和他相关的发现了一个Clawcode的项目：他是在ClaudeCode泄露后，使用Harness工程把CC重写了一遍，Github创下了星星数增长最快的记录，它的harness工程值得我们学习。所以今天先更新了CC的源码泄露背景和对这个项目的拆解，希望大家通过这个项目可以学一下Harness工程，也是26年高频考点。

2026/4/10

添加ClawCode 5层harness架构的讲解视频（小红书传了，笔记也会附上夸克网盘链接，没看到就稍微晚一天再查看）

2026/4/11

添加Claedecode的记忆功能解析以及添加相关面试问题/答案参考。

2026/4/12

解析了ClaudeCode的架构，将Claude Code的架构和Openclaw去对比，包括和我们笔记部分，Agent之间通信方法联系起来。希望通过这个笔记，大家理论联系实践，对理论有更好的理解，也对Agent架构有一定理解，这些对自己设计Agent框架，以及相关面试问题都很有帮助。

2026/4/13

上传了ClaudeCode源码解析 - 记忆模块 讲解视频。

2026/4/17

更新ClaudeCode源码解析 - 四层安全模块。

同时上传了CC的源代码，在源码解析章节，大家自取.

2026/4/20

更新了自学算法章节，上传了第二阶段的SKILL。后训练学习SKILL。阐述了使用该SKILL的技巧和思路。

2026/4/21

更新了Hermes Agent的知识部分和相关面试高频考点。Hermes工程是26年4月底的顶流，面试常考。

2026/4/22

更新Hermes Agent的讲解视频。

2026/4/23

总结了三个粉丝朋友投稿的RAG项目面试真实的问题和答案。并且根据这个真实面试题，补充了2个八股：

1. Chunk size的选型策略和思路。

2. MCP Server的tools 设计的原则。

公开了RAG面试真题前面几期面试公司（当时鉴于隐私，把公司名隐藏了，现在小伙伴都上岸了，我把这个公司名公开了）

另外笔记有个小优化，今天笔记中的互相引用的片段做成链接，方便大家跳转更方便。等我空了逐步修改过来。

2026/4/24

更新了华林三面的面试问题和解析。我主要想通过这次面试来讲一下架构设计面试问题，提供一个模板供大家套用。

2026/4/26

笔记加了一个小小的彩蛋，既然是彩蛋，我就不说是在哪里了，成立了一个新的章节。希望通过这个章节可以鼓励到大家。感兴趣自己翻翻吧。这两天开始学习算法的第三阶段了，开源项目的学习，所以没有更新笔记，但是随着算法学习，也离提供一个算法的项目越来越近了。

2026/4/29

1. 下一个就是你的彩蛋环节加了一个例子。

2. 我把文本里我找到所有文本内相互引用的地方变成了超链接的形式，帮助大家能快速上下文跳转。如果有没有改过来的或者有问题的地方，请大家和客服反馈，我会及时修改。

这两天没更新笔记是因为我在学算法第三阶段，更快学完更快开始做算法项目分享给大家。

2026/4/30

1. 下一个就是你的彩蛋环节加了一个例子。

2. ClaudeCode源码解析章节，添加ClaudeCode的成本控制功能讲解。这一部分对于理解面试问题：你的项目怎么做Agent成本控制，如何避免Agent无限调用烧爆token，以及对于设计自己的项目，都是有很好的借鉴价值。

五一期间可能不会有太多更新，好好放个假吧，祝大家假期快乐。

2026/5/6

在整理按摩房预约系统的项目，很多朋友问我能不能分享。这个项目是我自学大模型开始自己做的第一个项目。我想着就分享给大家，我在整理相应的代码，SKILL，真题，以及如何使用，相关配套的面试真题，预期在5.8号左右整理完。

2026/5/7

成立一个所有人都能看到，编辑，反馈的文档（在文本最后）。我希望在这个文档上和大家去交流，我会在上面写上我的长期更新计划，大家也可以补充有什么面试问题（比如文档上没有的，希望补充的），提供文档的反馈，意见，错误纠正，好的参考资料，以及其他一切内容（因为大家是都可以共建的），集合团队力量，一起获取胜利。

2026/5/8

按摩房预约项目部分文档已经更新完了，源代码也上传了，怎么使用等我的面试心得都写上去了。

我还需要对这个按摩房预约系统录制一个视频讲解，项目部分就到此结束了。

接下来会更新个面经，粉丝提议的模型对比，私有部署，以及主线内容是算法，推出算法项目。

2026/5/9

Agent项目部分传了个视频，项目部分到此结束。我会把之前的一些视频都换成b站链接，后续也都会用b站代替，有粉丝朋友反馈夸克链接不方便。

2026/5/10

更新了不同模型的对比，选型策略，deepseekv4的核心特性，结合了面试真题讲解。我觉得这部分还是值得大家了解的。

2026/5/11

添加了不同模型对比的文档对应的讲解视频

2026/5/12

详细分析了问题，部署/训练某个模型时，需要多少显存和空间。大模型社群中有朋友反映这个问题面试官问了，不知道怎么回答。这个问题有点难，涉及知识点有点广，我也会配一个讲解视频。

2026/5/13

更新部署模型讲解视频

2026/5/17

更新2026.05 字节跳动暑期实习一面新鲜面经。

重构大模型笔记：幻觉部分，力争完整，前沿，增加了一些亮点设计。

2026/5/18

更新2026.05 字节跳动暑期实习一面新鲜面经视频讲解。

2026/5/19

重构了Harness章节的内容。添加了2个参考视频和参考文档。

同时新增了一个Harness工程的一些工程实战细节，我觉得非常有帮助，不管是对面试还是自己使用AI，还是开发Agent项目。在这个笔记的过程中，也结合了非常多的面试问题来讲解这一小节笔记如何在面试中运用。

同时在Harness章节，也增加了如何学习Harness的一些思路介绍。相信重构后，大家不管学习Harness内容还是准备相关面试问题，都会更加容易

2026/5/20

更新了笔记推荐阅读顺序建议。

2026/5/21

经验之谈，更新如何找项目

2026/5/24

更新腾讯AIAgent暑期实习一面面经和解析

2026/5/26

更新腾讯AIAgent暑期实习一面面经和解析 讲解视频

2026/5/27

更新重构ClaudeCode的源码解析，关于ClaudeCode的架构部分：增加了AgentTeam部分的讲解。

在ClaudeCode的笔记部分，加入了CC的Agentteam和SubAgent的使用介绍。

在ClaudeCode章节，加入了若干参考资料：Agentteam和SubAgent 的使用视频讲解，官方文档，CC源码解读书籍在线阅读链接。

2026/5/28

自学大模型算法章节，完整的三个阶段的SKILL已经更新。这个是我自己学下来，掌握大模型算法（后训练）部分的理论基础使用的方法，觉得合适的同学可以直接复用。我接下来准备做算法项目了。确实我是用这一套从0算法基础到现在（虽然也不是什么算法高手，但是最少后训练，pytorch等整个算法的理论基础是学完了的）的一个水平。

2026/6/2

更新了虾皮暑期实习一面面试深度解析。

根据这一次面试，补充了ClaudeCode源码解读的笔记部分，新增全局图片，Transcript部分，以及将笔记部分和面试题融合。增加了相关的参考资料，比如Langgraph的持久化知识参考链接。

2026/6/2

更新了虾皮暑期实习一面面试讲解视频

2026/6/7

更新了ClaudeCode vs Codex工具测评，对比，选型建议，面试问题。

因为最近Codex的热度起来了，很多人说Codex更好用，了解这一章节，有助于提升我们的VibeCoding的技巧，在我们和面试官聊VibeCoding工具时，心中也更有料。

2026/6/8

更新CC和Codex对比讲解视频

2026/6/9

我主要在写算法章节的设计文档，这一部分的思路希望这个文档能够不光展示技术细节，也展示如何写的，你如何复用。我在写这一部分过程不会往文档里写，会在我设计完细节的时候一次性写入笔记中。如果想要现在就看的同学，可以看我小红书的笔记:算法设计章节，这个里面展示了设计的中间过程。

2026/6/10

分享了一个提示词和技巧，用于将面试录音快速变成面试问题记录。放在上面的经验之谈里。

2026/6/11

替换夸克千问面试讲解视频变成b站链接。

2026/6/14

新增了安克暑期实习一面的面经和详细解析，根据面经内容重构笔记，具体包括：

RAG部分加入RAG整体流程图和描述，新增意图识别步骤内容。

CC源码压缩部分新增整体压缩的流程图，重构压缩部分讲解。

将本次面试真题问题融入到笔记中。

2026/6/15

新增安克暑期实习一面面经讲解视频

2026/6/16

新增研究院大模型开发岗位面试全记录，包括所有面试流程，注意事项，具体放在面经章节。

2026/6/17

Agent章节新增Loop 工程的内容，是最近比较火的概念，补齐相关内容防止面试官会问。

2026/6/21

新增一个Agent实战例子：PI Agent. 添加该项目完整的架构讲解，思想设计，面试问题，课后作业等。

同时更新学习思路部分：推荐该项目作为学完Agent理论一个开始上手实践的Agent项目。

2026/6/22

添加Pi-agent讲解视频

2026/6/25

更新米连科技（社招）面经

2026/6/28

彻底重构了整个Agent评估内容。参考了3本书籍和一篇论文，按照Agent开发的生命周期讲解，插入每个地方需要评测的内容。确保评估点完整且符合逻辑。笔记里掺杂了十几个面试真题供大家参考。同时给出了参考资料供大家深入学习。相信这一部分能够讲透，覆盖清楚Agent评估常考的问题。

2026/6/29

添加Agent评估的讲解视频

2026/6/30\~2026/07/02

加了几个上岸记录（其实中间还有很多人上岸，我太懒了，没有及时记录）

然后这几天笔记虽然没有更新，但我一直也没闲着，我在设计我们算法项目的spec，马上设计完了。我会讲算法的项目对应的技术文档直接添加在笔记中，更新我们的笔记章节，有需要的可以先看起来。

2026/07/05

SKILL章节添加面试实战内容，总结梳理了粉丝朋友提供的近期SKILL面试相关真题和解析，以及对应视频讲解。

2026/07/06

添加算法项目技术文档

2026/07/07

更新SKILL面试真题对应的讲解部分。

2026/07/08

添加一个Agent场景题, 社招面试真题。

2026/07/09

添加RAG趋势讨论的问题。包括比如你的项目要不要用RAG啊？ClaudeCode为什么不用RAG啊？RAG是否过时了啊？你怎么看待RAG已死这个问题啊。今天补充的内容，大家读完了以后会对这些问题有深入的理解。

2026/07/10

添加RAG趋势探讨部分笔记的讲解视频

2026/07/11

添加Agent场景题部分笔记的讲解视频

2026/07/13

上传了大模型算法项目一阶段的代码：主要完成了对应的项目框架的搭建，推理模块的基本架构。

同时在笔记中整理该项目推荐的学习方法。这是阶段性的交付，每个阶段我都教给大家如何去完成，怎么去学习的。你真的不用等我完成整个项目后再来理解，可以跟着我写的步骤，阶段性学习。

2026/07/14

上传了大模型算法项目一阶段的讲解视频。

2026/07/15

上传了大模型算法项目二阶段的代码：完成了Agent的评估模块。

这块其实适合于任何人，即使你不做大模型算法项目，这个阶段也值得学习。因为应用开发也很常考大模型评估，这块可以作为一个Agent评估内容的实战。

2026/07/16

上传了大模型算法项目二阶段 讲解视频

2026/07/19

新增面经：滴滴Agent开发一面面试题和答案解析。

2026/07/21

增加滴滴Agent开发一面面经讲解视频。

修复了错别字，同时重构目录结构。我希望把我们目录再整理一下，内容越来越多了，还没整理完，今天重构了一部分，希望想个办法比如整理目录结构，加点全局结构图之类的，让大家即使内容一直在增加，看笔记也能很清楚知道结构和应该看哪一部分。

2026/07/22

修复错别字。

新增笔记：使用AI工具时如何节约Token使用量。

2026/07/23

修复错别字。我用AI修了好几版错别字。新增笔记：使用AI工具时如何节约Token使用量 对应的视频讲解。

2026/07/24

岗位介绍部分新添对FDE岗位的介绍。

2026/07/25\~2026/07/26

上传算法项目三阶段代码和讲解视频。

2026/07/27

更新了深圳大模型研究院Agent开发一面解析。同时Agent章节添加了专题讲解，如何应对面试官对你Agent项目的质疑。在Agent框架知识部分，也加入了一些根据26年7月份的经验，加了一些学习深浅的建议。

2026/07/28

更新深圳大模型研究院一面讲解视频

2026/07/29

更新最近很火的概念，Graph工程的笔记。

2026/07/30

更新最近很火的概念，Graph工程的笔记。

2026/07/31

添加Graph工程讲解笔记。

2026/08/2

更新2026年有价值做的6个AI项目，包含简历如何编写，美化。

2026/08/3

更新2026年有价值做的6个AI项目，包含简历如何编写，美化对应讲解视频

2026/08/5

完成大模型算法后训练项目第四阶段，提交相关代码。

2026/08/6

上传大模型算法后训练项目第四阶段讲解视频。

2026/08/7

在项目实战部分，加入了我们目前已有的三个项目该如何使用，如何学习，包装，写在简历上，给出了简历编写思路和示例简历。

2026/08/9

Agent章节新增专题，Agent健壮性设计。这个也是面试常考的点，完成了内容：当工具调用失败时，如何优雅处理？

2026/08/10

更新Agent健壮性设计视频讲解。

2026/08/11

重构Agent框架部分，新增包含2026Agent框架特点解析，选型策略，面试真题。

2026/08/12

新增Agent框架部分对应的讲解视频。

2026/08/14

完成算法项目第五阶段，上传代码。

2026/08/16

新增英伟达Agent开发一面面试笔记。

2026/08/18

新增英伟达Agent开发一面面试内容讲解视频。

2026/08/19

新增算法项目5阶段讲解视频。

2026/08/20

新增DeepSeekHarness内容解析，Cordis特性讲解，架构图，面试问题。

2026/08/21

新增DeepSeekHarness内容解析，对应的讲解视频。

2026/08/24

完成项目第5阶段，更新算法项目相应章节。

2026/08/25

上传项目第5阶段对应的讲解视频

2026/08/26

新增RAG项目对应的两个粉丝投稿的面试真题及相关子问题。

如何保证RAG系统生成的回答是准确的？

PDF 转 Markdown 是怎么处理的？

同时在RAG专题，新增对应的RAG知识：

RAG的文档输入处理

Self-RAG

2026/08/27

新增上面的RAG项目两个面试真题对应的讲解视频。

2026/08/28

新增宇树科技Agent开发一面面试真题精讲笔记。

2026/08/29

新增宇树科技Agent开发一面讲解视频。

2026/09/01

彻底重构RAG分块章节，总结面试问题，选型策略，汇总近10道面试真题。

2026/09/02

RAG分块章节，加入视频讲解。

2026/09/03

开辟我们后端章节！完成导引部分，加入后端章节第一个面试问题和讲解资料。

项目实战

RAG项目实战

1. 项目介绍

对于项目完成的技术方案，请看项目仓库的Dev_SPEC.

对于项目的使用建议，项目仓库的Readme.

其它的一些实际思路，比如项目如何启动，从0到1的过程，项目如何配置环境，如何开发的，如何写的SKILL,SPEC，以及一些如何面试前的准备，请看视频讲解。

视频讲解，我提供完整的思路，从0开始，到立项，设计思路，开发，测试，写简历，项目前突击都展示了对应的思路。更多开发过程可以看我的小红书，Rag-agent项目实战，里面记录了一些开发过程的心得，但是精华都在代码仓库和下面视频中了。

如果进行突击前的准备，比如项目会问哪些问题，那就请看模拟面试SKILL。用这个方法，带你复习整个项目70多个知识点和八股，并进行模拟面试。 项目基本整个流程已经完毕，不会增加新的功能了。请各位需要深入扩展，比如加一个新功能，自定义评估模块，垂直业务适配 大家按照思路自己扩展就好了。看看我上述的思路，扩展应该并不难。具体的项目八股部分，我没有总结，但是请你使用模拟面试SKILL的方法，让AI带你过完整个项目。我想要继续总结的是真实场景下，该项目的面试问题。

项目基本完成了，我希望后面补的内容是第四部分，就是真实的面试记录和问题：如果有同学想要投稿，使用整个项目面试了，可以提供给我真实的视频素材（音频），我会帮你总结面试问题，给一些点评，并会将设计这个项目的面试问题复盘，总结在笔记中，这样大家可以一起进步。 同时我自己也会面试，把这个项目往简历写，遇到了问题也会总结。

2. Github地址

GitHub上的Dev_spec是更完整/更新的版本。推荐Git仓库看整个Spec, Spec甚至是包含了完整的目录结构和项目管理，包括上传了Skills 教大家如何用AI来完成整个项目。有兴趣欢迎尝试呀！

https://github.com/jerry-ai-dev/MODULAR-RAG-MCP-SERVER

3. 面试真题

这一小节会展示真实的面试问题。非常欢迎/鼓励大家投稿，最好是以音频的形式，因为这样我能够分析出来完整的问题，其实你看我的笔记做面试真题的部分，我都是拿着录音一个字一个字扒的，这样不会漏掉细节，也能够体会当时的氛围，回答的语气。即使不给我录音，也建议大家自己面试录音，然后自己复盘的时候就根据录音去听细节。 当然并不是每个小伙伴都愿意提供录音，毕竟有一些隐私性，那么你可以尽量回忆当时的细节，可以给我文字版，我会把你的内容整理，告诉你怎么改进，也会记录在文档中，也是一个一起学习的过程。

本节呢，会展示该项目的真实的面试问题，素材来自于粉丝投稿和自己面试。粉丝投稿有时细节可能就有限了，因为可能是以回忆的文字形式整理的。但是我自己面试的话，那么就会比较全面。

3.1 小哥A投稿

3.1.1 你的项目是从Github找的吗？

从这个问题的反馈上，我觉得老哥可能比较诚实。我估计小哥是直接把我的Git项目名字直接写上去的。具体细节怎么写的我不太确定了。但是！更合理的做法是包装呀，我其实在readme中写了，在我的项目的Resume-Writer SKILL也明确让他使用了包装的技巧，我的思路一直是你要把这个项目和你的业务去结合，编也要编一个，而且你用我项目里的SKILL就能编出来，用它生成的简历最少面试官看上去不是直接问你是不是Git上找的项目啊！

一个项目是结合自己的工作/学习自己写的，它是有背景/需求/痛点/解决方案/设计思路，它是有故事讲的。你直接这么写，人家觉得你是Git上找的项目，首先第一个怀疑的是你自己到底做了多少。 所以我的第一个建议是简历重新写一下，至少用项目这个SKILL写一个简历出来看上去面试官也不会问这个问题。

3.1.2 PDF不规范、乱码多的情况下，MarkItDown转换效果不好怎么办？

思路：其实这个问题挺好的，在我做完这个项目的时候，我和大家说的，我强烈的建议是你真的把它用在你的业务场景中。这时你可能会遇到各种问题，比如输入文档质量不好，太大，或者文档中的表格处理不到。这块你遇到的问题和解决思路就是很好的经验和面试问题。 你在解决了他们的时候，可以提高系统的准确性，可以讲出来为啥你的系统效果更好，因为你可能做了xx针对性的调整等经验。

所以这个问题其实是该项目在真实场景下可能会遇到的问题，值得我们去思考。当然答案其实不唯一，我也只能纸上谈兵，给一个我思考的答案。

参考答案：

这个问题我们在设计时是有考虑的，整体是三层防线的思路，采用 Garbage In Garbage Out的思路。

第一层，Pipeline 入口有文档质量检测的前处理。 文档进入系统后，Loader 不会直接无脑解析，而是会先做一轮质量预检：提取前几页文本，计算有效字符占比和可识别文本密度。如果有效字符率低于阈值（我们设的是 80%），说明这个 PDF 的文本层本身就有严重问题，这种文档即使硬塞进去，后面切出来的 chunk 也是垃圾，检索质量根本没法保证。所以直接拒绝入库，在 Dashboard 上给用户一个明确的提示：'该文档质量不达标，请检查后重新上传'。与其让脏数据污染整个知识库，不如在入口就拦住。（注意哦，这里其实我们项目并没有做这个前处理，你可以加进去，你试试让AI完成，他能很快完成。另外即使你没做，想清楚了怎么做的，大胆说就行了，面试的时候真的不用完全实事求是）

第二层，从业务场景来说，这个问题在实际中的影响面其实有限。 我们这个系统定位是企业内部知识库，文档来源主要是团队内部产出的技术文档、产品文档、会议纪要这类——这些基本都是 Word/LaTeX 导出的文本型 PDF，格式规范、编码正常。MarkItDown 底层用的是 pdfminer.six，对这类标准文本型 PDF 的提取准确率是很高的。所以在我们的实际场景中，大部分文档走主路径就能处理好。

第三层，即使文本提取有轻微的噪声，后面的 Transform 阶段还有 LLM 做兜底。 我们在 Splitter 切分完之后有一个 Transform & Enrichment 阶段，会用 LLM 对每个 Chunk 做智能重组——合并被物理切断的段落、剔除页眉页脚和残余乱码、补全上下文。所以对于那种'大部分正常、偶尔几段有点问题'的情况，Transform 阶段的 LLM 去噪能力是可以兜住的。

退一步讲，就算有少量噪声数据漏进了知识库，也不会影响最终检索质量。 因为乱码文本生成的 Embedding 向量在语义空间中是没有方向的噪声，跟用户任何有意义的查询之间的相似度都会很低，检索排序时自然就沉底了。所以本质上就是浪费了一点存储空间，但不会污染检索结果。

3.1.3 图转文用的视觉模型有什么考量？

思路：其实也是一个非常好的问题，面试喜欢问，你为什么选xx的模型。不光是这个RAG项目的视觉模型，还有你自己做Agent，这些都是常考的问题。有人说我spec写的细，问我怎么写出的spec, 其中一个因素就是经验啊，我的学习和面试，告诉我什么需要考虑。比如通过这次面试，总结了这个问题，我就会对是觉得模型多考虑一层。但是现在分析看来，我还是有些东西没有考虑到， 比如文本质量差如何前处理，视觉模型的选型。 总结这些问题的时候，还要思考，查资料。 项目要考虑的东西还是很多的，经验这个东西还是学无止境的，我们慢慢积累，你看这个笔记，以及做项目，以及面试，都会增加你的经验，让你以后写spec，考虑的更全面。

答案：

首先，传统RAG处理图像主要有两条路线：一种是用CLIP这类多模态Embedding模型，把图片和文本映射到同一个向量空间，做视觉相似性匹配；另一种是用Vision LLM做图转文，把图片内容理解成自然语言描述，然后复用文本RAG链路去检索。我们选的是图转文。因为我们的业务场景是内部技术文档，图片基本都是架构图、流程图、表格截图这些，用户问的是'调用链路是什么'、'超时配多少'这种具体的技术问题，要的是图里的含义不是外观。CLIP匹配不到这个层面的语义，Vision LLM可以。

然后，具体选哪个Vision LLM，我们用了双模型策略。英文文档和复杂图表主选GPT-4o，理解能力最强；中文场景主选Qwen-VL-Max，中文OCR和图表理解更好，价格大概GPT-4o的三分之一到五分之一，国内访问延迟也低。通过配置切换，代码层是解耦的。

最后，用法上也做了一些优化。不同类型的图片用不同的结构化prompt，比如流程图侧重提取节点关系，数据图表侧重提取数值和结论。调模型的时候会把图片前后的文本段落一起传进去，让模型理解图在文档中的上下文。另外做了内容哈希缓存，同一张图不会重复调用。

（这里我设想的我的RAG场景是业务内部技术文档。所以有如下的答案。我希望大家要参考这个思路，比如CLIP和Vision LLM, 对于不同提示词的使用，然后针对性修改，来放在自己项目的回答中）

3.1.4 项目的一些常规问题

思路：小哥没有给我展示具体的问题。但是他说他这里基本答上来了。可以预测，可能是一些常见的项目问题,比如如何做的粗排，精排。如何用的双路检索，数据库存了啥。这个偏项目的细节以及基础知识。这里其实也有另一个小哥（他都拿到offer），他在群里的反馈是把博主的RAG项目倒背如流，拿到了暑期实习Offer. 这部分就是项目的细节，我这里设置了 模拟面试和项目细节的SKILL。 你去用它，一定会给你把项目讲得很清楚，所以我没有总结，但是这些也很重要，涉及基本知识和你的项目细节。 我思路都做好了啊，你用我的SKILL去学就完了。先用项目细节的SKILL，它把整个项目分为几十个知识点一个个打开，你学习。然后他帮你模拟面试，你去检验就行了。 这块没有什么技巧，答不上来就是功夫没下够，按我建议的方法去学就行。

3.1.5 本地有没有实现过

思路：面试官问这个问题，还是这个小哥简历写的太老实了，都没包装，面试官觉得是从网上找的项目，才会这么问，见3.1.1，结合自己业务包装了，面试官肯定不会问这个问题呀。

3.1.6 有没有了解RAG的新方向

思路：其实方向还是挺明确的，Agentic RAG 和 Graph RAG.我的复习思路是先去理解概念，当面试官问到相关问题，通常第一个问题都是解释概念，问你了解不，然后就按照以下内容答就行了。我暂时不会深入学习。为什么呢？因为不是说每个人都需要把RAG学的比较深的，RAG如果脱离了Agent，它也不算大模型方向了。所以在大模型方向Agent的重要性比RAG重要，RAG基本的知识就是我们的项目相关的。学习好这些个RAG基本相关的内容，是基础，有余力当然可以去学这两个方向，或者做相关项目。但是并不是每个岗位都需要很深的RAG，深入到Agentic 和 Graph，个人精力也有限嘛。所以我个人会先学习概念，然后我目前是在学算法，微调这个，考的也很频繁。总而言之，我不深入学习Agentic 和 Graph RAG，是因为在我这里他优先级没排上。

但是提醒大家的还是根据自己的情况去分析。因为有的人的岗位就是偏RAG这一块的，那他肯定就需要把RAG多学一点。如果你的目标岗位是宽泛的，比如大模型应用，大模型算法。可以先把其他的内容，Agent, RAG基础内容，微调，推理相关的东西学好了，再来。

还想提醒的一点是个人面试技巧。确实也是有个小哥问我，他说我微调只会一点，但我简历写了。明天面试要问了，我要不要主动承认我微调经验少啊。我的答案是不要，这个问题和这个Graph Rag类似。我们不主动认怂， 比如面试官问你了解Graph Rag吗？我就说我了解！然后告诉他Graph Rag是啥。真的问到了你不会的地方，你再说不会，不要认怂。很多时候面试官问题也只是流于表面，问你了解不，你说了解，然后答了概念，这个题就过去了，你说你主动先承认你了解不深的意义是啥子呢？

答案：

Agentic RAG的核心是把RAG从一个固定流水线变成一个有决策能力的Agent。传统RAG就是检索一轮、生成答案、结束了。但很多复杂问题一轮检索根本不够，Agentic RAG让模型自己判断——检索结果够不够？不够就再检索一轮，或者换个检索策略。像Self-RAG、Corrective RAG都是这个思路，本质就是让检索过程变得更智能、可以自我纠错。

Graph RAG解决的是另一个问题——传统向量检索擅长找语义相似的内容，但很难处理跨文档的关联推理。比如问人物之间的关系，信息散落在十几个段落里，靠embedding相似度很难串起来。Graph RAG的做法是先从文档里抽取实体和关系建成知识图谱，检索时在图上做关系遍历，特别适合需要全局理解的问题。"

我觉得这两个方向是互补的——一个解决检索策略的智能化，一个解决知识关联和推理，未来可能会结合起来用。

3.2 离线数据处理

总结这个专题其实来自于粉丝的投稿。他说小红书上有一篇文章讲 RAG离线解析 ，也是以他们项目是输入PDF格式构建数据库的。文章核心就是：强调离线数据构建的核心，强调它的重要性，提供了一些离线构建的问题。这个文章可以作为我们准备面试的思路，我是建议大家真正跑一些Pdf试一下，就可以知道具体可能会遇到哪些问题。我个人是没有做这些事，但是没关系，我们想清楚，准备清楚一些问题，以应对面试官可能的考察。看了这个文档，我觉得我们项目在离线解析这一块，还是做的比较全的，我提取一下这个笔记中讲到的离线解析的问题，预测一些可能的考点和答案，供大家参考：

1. 你们项目处理的文档都是什么格式？PDF 多栏排版你是怎么处理的？

我们项目处理的文档以 PDF 为主。用 MarkItDown 把 PDF 统一转成 Markdown，它能识别段落、标题、列表等结构化元素，比纯文本提取更好地保留文档逻辑结构。同时用 PyMuPDF 做图片提取，确保图文信息不丢失。后续通过vision llm来提取图片内容，实现图片的检索。

2. 你们文本分块是怎么做的？如果一段完整的业务流程被从中间切断了怎么办？

我们用了多层策略来尽可能避免切断，以及切断后的补救机制：

避免切断： 用 RecursiveSplitter，按分隔符优先级递归切——先尝试在段落（\n\n）处断开，不行再降到换行（\n），再降到句号（.），最后才是空格。也就是说它会优先在自然语义边界切分，而不是无脑按字符数硬切。一段完整的理赔流程如果在一个段落内，就不会被拆开。

切断后的容错： 设置了 chunk overlap 重叠窗口，上一个 chunk 的尾部几句话会同时出现在下一个 chunk 的开头。即使流程被切在了中间，上下两个 chunk 都保留了切断点附近的上下文，检索时任何一个被命中，都能拿到切断点前后的关键信息，不会出现"半句话"的情况。

检索阶段兜底： 每个 chunk 都带有 chunk_index（序号）和 source_ref（父文档 ID）。如果检索命中了某个 chunk，系统可以根据 chunk_index 找到它的前后相邻 chunk，把上下文拼回来送给 LLM 生成答案。这样即使切分不完美，在检索和生成阶段也能还原完整信息。

后处理兜底： Transform 阶段的 ChunkRefiner 会对每个 chunk 做规则清洗和可选的 LLM 精炼，确保每个 chunk 是语义自包含的。LLM 调用失败自动降级为纯规则，不阻塞流水线。

3. chunk 大小你是怎么定的？太大太小都有问题，你怎么平衡的？

chunk_size 和 chunk_overlap 全部通过 settings.yaml 配置驱动，不需要改代码就能调。整个 Pipeline 是工厂模式架构，Splitter、Embedding、VectorStore 都通过 Factory 实例化，切换策略只改配置。实际调优时结合下游 LLM 的上下文窗口大小和评估指标来实验确定最优值。而且在线阶段我们用了 Dense + BM25 混合检索 + Cross-Encoder Rerank 的三级策略，先大范围召回再精排，减少了对单个 chunk 粒度的过度依赖。

4. chunk 大小你是怎么定的？太大太小都有问题，你怎么平衡的？

我们最终定的是 chunk_size=1000 字符，chunk_overlap=200，这个值是综合三个因素平衡出来的：

第一个因素是 Embedding 模型的输入上限。 我们用的 Embedding 模型 token 上限一般在 512-8192 之间，1000 字符大概 300-500 token，留够余量不会被截断，保证每个 chunk 完整编码。

第二个因素是 LLM 上下文窗口的承载量。 在线回答时我们通常召回 top-5 到 top-10 个 chunk 拼成 context 给 LLM。如果 chunk 太大比如 3000 字符，5 个就是 15000 字符，很容易撑满窗口、挤压生成空间；1000 字符的话，10 个也才 10000 字符，LLM 还有充足空间做推理和生成。

第三个因素是语义完整性。 太小比如 200 字符，一个 chunk 可能只有一两句话，语义残缺，检索精度反而下降——一句话脱离了上下文，Embedding 向量质量也差。1000 字符大约是一个自然段落的长度，能包含一个相对完整的信息单元。

200 的 overlap 是 chunk_size 的 20%，目的是让相邻 chunk 在切断点处有足够重叠，不会因为切分而完全丢失边界处的上下文。

这些参数都在 settings.yaml 里配置驱动，不用改代码。实际上线前我们可以通过评估模块跑对比实验——不同 chunk_size 下的召回率和生成质量——来验证和微调。

5. 输入的数据有很多噪声数据，质量很差怎么办？

这个问题我们在设计时是有考虑的，整体是三层防线的思路，采用 Garbage In Garbage Out的思路。

第一层，Pipeline 入口有文档质量检测的前处理。 文档进入系统后，Loader 不会直接无脑解析，而是会先做一轮质量预检：提取前几页文本，计算有效字符占比和可识别文本密度。如果有效字符率低于阈值（我们设的是 80%），说明这个 PDF 的文本层本身就有严重问题，这种文档即使硬塞进去，后面切出来的 chunk 也是垃圾，检索质量根本没法保证。所以直接拒绝入库，在 Dashboard 上给用户一个明确的提示：'该文档质量不达标，请检查后重新上传'。与其让脏数据污染整个知识库，不如在入口就拦住。（注意，这里其实我们项目并没有做这个前处理，你可以加进去，你试试让AI完成，他能很快完成。另外即使你没做，想清楚了怎么做的，大胆说就行了，面试的时候真的不用完全实事求是）

第二层，从业务场景来说，这个问题在实际中的影响面其实有限。 我们这个系统定位是企业内部知识库，文档来源主要是团队内部产出的技术文档、产品文档、会议纪要这类——这些基本都是 Word/LaTeX 导出的文本型 PDF，格式规范、编码正常。MarkItDown 底层用的是 pdfminer.six，对这类标准文本型 PDF 的提取准确率是很高的。所以在我们的实际场景中，大部分文档走主路径就能处理好。

第三层，即使文本提取有轻微的噪声，后面的 Transform 阶段还有 LLM 做兜底。 我们在 Splitter 切分完之后有一个 Transform & Enrichment 阶段，会用 LLM 对每个 Chunk 做智能重组——合并被物理切断的段落、剔除页眉页脚和残余乱码、补全上下文。所以对于那种'大部分正常、偶尔几段有点问题'的情况，Transform 阶段的 LLM 去噪能力是可以兜住的。

退一步讲，就算有少量噪声数据漏进了知识库，也不会影响最终检索质量。 因为乱码文本生成的 Embedding 向量在语义空间中是没有方向的噪声，跟用户任何有意义的查询之间的相似度都会很低，检索排序时自然就沉底了。所以本质上就是浪费了一点存储空间，但不会污染检索结果。

6. 面试回答：你们的离线解析是怎么做的？

（先讲挑战） 我们要处理多格式文档，主要是 PDF，也有 PPT 和扫描件。核心挑战四个：PDF 解析错乱、图片信息丢失、分块切断语义、缺元数据导致检索过滤维度不够。

（再讲方案） 我们设计了六阶段流水线：

SHA256 文件校验，未变更文件自动跳过，保证幂等。

文档解析，用 MarkItDown 把 PDF 转 Markdown 保留结构，PyMuPDF 提取图片并插入占位符。

语义感知分块，RecursiveSplitter 按段落、换行、句号等自然边界递归切分，不硬切；设 chunk overlap 200 字符重叠窗口防上下文断裂；每个 chunk 带 chunk_index 和 source_ref，检索命中后可沿序号拼回前后上下文。

Transform 三件套——ChunkRefiner 清洗噪音做内容精炼；ImageCaptioner 调 Vision LLM 给图片生成自然语言描述回填到文本，解决图片信息丢失；MetadataEnricher 用规则+LLM 给每个 chunk 打 title、summary、tags 标签，支持检索时多维过滤。三个组件 LLM 调用失败都自动降级，不阻塞流水线。

双路编码，Dense 向量 + BM25 稀疏索引，语义匹配和关键词匹配互补。

三路存储，VectorStore、BM25 Index、ImageStorage 各司其职。

（最后讲效果） PDF 解析错乱→MarkItDown 结构化转换从源头保证质量，不让乱码污染 Embedding；图片丢失→Vision LLM caption 回填解决；分块切断→递归切分+overlap+chunk_index 上下文拼接多层兜底；元数据不足→MetadataEnricher 注入语义标签，配合混合检索+Rerank 做多维筛选。chunk_size 1000、overlap 200 全部配置驱动，可以结合评估指标实验调优。

3.3 某大厂二面（来自粉丝B）

（3.3和3.4都来自同一个粉丝朋友。这个具体是哪个公司我有点忘了。非常感谢这个粉丝朋友的投递，我觉得里面问的问题都不难，是比较基础细致的内容，但是很深入，并不是每个公司都会问的这么深入的。非常有借鉴价值。但是其实不难，只要我们把项目理解透了，对应的知识点理解透了，包括我也汇总了这么多项目面经，自己多表达几遍，这些问题都不在话下。）

3.3.1 大模型增强部分是做什么的？有什么用？元数据都有什么？增强前后效果对比了吗？

（前三个问题，其实就是项目的最基本的模块，我设置的机器人都会带大家复习过。理解了以后，其实自己对于这些问题需要自己尝试表达一下，因为理解和表达流畅是不一样的。最后一个问题：前后效果对比了吗，我觉得就是编吧，或者叫自圆其说，结合我们做测评制定json的数据集以及使用ragas的经验，把最后一个问题编出来）

Q1: 大模型增强做了什么

A1: 我们的 Ingestion Pipeline 里 Transform 阶段主要围绕"脏、乱、不可搜、难展示"的痛点，设计了三个核心模块来进行数据增强，分别针对纯文本、元数据，以及文档中的图片。

第一部分是 ChunkRefiner（文本块精炼）。

主要解决 PDF 解析后的排版噪声。我采用了“规则兜底 + LLM增强”的两阶段处理模式：

- 规则兜底：首先用正则低延迟地去掉连续空行、分页符和 HTML 残留，并精准保留所有的代码块。这一步是必做的，0成本覆盖 80% 场景。

- LLM 增强：对于规则搞不定的分页造成的段落断开、OCR 识别错别字，交给大模型进行上下文合并和修正，让文本变得连贯。

第二部分是 MetadataEnricher（元数据增强）。

它的作用是为每个 chunk 生成结构化的语义元数据（Title、Summary、Tags），方便后续做字段级别的检索过滤和结果展示。这部分当没有使用LLM的时候，会使用基于正则化匹配的方式提取这三部分，使用LLM的时候，会用LLM的语义分析功能来完成。

第三部分是 ImageCaptioner（图片多模态增强）。

这是解决传统 RAG 丢失插图信息的关键。解析阶段图片会被存在本地，并在原文对应位置留下 [IMAGE: id] 的占位符。增强阶段，ImageCaptioner 会利用正则扫描这些占位符，一旦发现便调用视觉大模型（Vision LLM）对图片进行跨模态解读。生成的详尽图像描述（Caption）不仅会被注入该区块的元数据中，还会同步回填进正文里，从而使得原本不可检索的图片转化为语义向量，最终实现了强大的“以文搜图”能力。

Q2: 元数据具体有什么

元数据主要包括4块内容：

第一个是 title，限制在 150 字符以内，用来描述这个 chunk 的主题。规则提取时，我的逻辑是有优先级的：首先用正则去匹配文本里有没有 Markdown 标题，也就是 `# Heading` 这种格式，如果有就直接用；如果没有标题，就看第一行够不够短、像不像一个标题（不以句号逗号结尾、长度不超过 100 字符），满足条件就用第一行；再不行就取第一句话截断到 150 字符。LLM 增强时会理解语义后生成更准确的主题描述。这个字段主要用于检索结果的展示和快速浏览。

第二个是 summary，限制在 500 字符以内，是 2 到 3 句话的核心摘要。规则提取的做法比较简单，就是按句号、感叹号、问号做分句，取前三句拼接起来。LLM 增强的话，生成的摘要概括力会更强，不是机械截取前几句，而是真正理解内容后提炼要点。这个字段用于结果预览和上下文补充。

第三个是 tags，3 到 10 个关键词标签。规则提取是从文本里用正则抓三类东西：大写开头的专有名词（比如 Azure、OpenAI）、camelCase 和 snake_case 风格的代码标识符（比如 `text_embedding`、`baseTransform`）、以及 Markdown 加粗标记 `...` 里的词——因为作者特意加粗的通常是关键概念。LLM 增强的优势在于它能推断出文本中没有直接出现但语义相关的标签，比如文档讲的是微服务拆分，LLM 可能会生成"分布式系统"、"SOA"这类语义关联的标签。tags 主要用于分类过滤和关联检索。

第四个是 enriched_by，标记这条元数据的来源。取值有三种：`"llm"` 表示是 LLM 生成的，`"rule"` 表示是规则提取的，`"error"` 表示处理过程出了异常。如果 LLM 调用失败降级到了规则结果，还会额外附带一个 `enrich_fallback_reason: "llm_failed"` 字段，便于事后追溯哪些 chunk 的元数据质量可能不够理想。

第五个是 image_captions，这个是 ImageCaptioner 处理后追加的。如果一个 chunk 的文本里包含 `[IMAGE: id]` 占位符，说明这个 chunk 引用了图片，ImageCaptioner 会调用 Vision LLM 对图片生成描述，然后以列表的形式写入 metadata，每个元素是 `{"id": "img_001", "caption": "这张图展示了系统架构图..."}`。

Q3: 增强前后效果对比了吗？

做过对比。我们通过两种方式来评估增强效果.

第一种方式是在测试集数据中手动标注了一些典型的"脏乱"文本块，包含分页符、冗余空行等，然后对比增强前后的文本质量。增强前这些文本块往往是断断续续的，甚至有些关键信息被分页符分开了；增强后文本变得连贯，关键信息完整保留了下来。

第二种方式是，我们比较了我们的测试集，在将llm 增强打开和关闭后，使用ragas进行评分的结果对比，在打开了llm增强后，整体的 Fluency和 Coherence 评分提升了约 15%，说明增强环节确实提升了整体RAG系统的准确性和可靠性。

3.3.2 BM25 怎么构建的？稀疏向量还是倒排索引？多少维度？Dense 多少维？向量数据库支持稀疏检索吗？嵌入模型用了什么？为什么？

(其实这个题不难，是一些基础知识。除了项目本身如何实现的，需要理解的一些概念是：BM25，稀疏向量，倒排索引，向量数据库。这些部分在RAG八股里有，不懂的话其实就是建议让AI给你解释，让他给你举例子。明白了概念以后，其实就是照着项目实现回答面试官问题就好。面试官很有可能顺着这个问题问一些概念，比如稀疏/稠密向量的区别，BM25的原理，向量数据对比等，这些都是基础八股了，就不展开了，但希望你能自己掌握，特别是里面的倒排索引和BM25的公式可能会复杂一点，可以深入掌握一下原理，怕面试官追问。）

Q1: BM25 怎么构建的？稀疏向量还是倒排索引？

（这里其实可以深入了解BM25和稀疏向量的公式的，防止被追问）

我们的 BM25 构建分两步：

第一步建倒排索引。 SparseEncoder 用 jieba 对每个 chunk 分词、统计词频，BM25Indexer 汇总后建成 词 → posting list 的倒排结构，每条 posting 存 chunk_id、词频 tf、文档长度。同时预算好每个词的 IDF 和全局平均文档长度，整个索引以 JSON 持久化到磁盘。

第二步查询时在线打分。 query 分词后，查每个词的 posting list，用 BM25 公式对命中文档打分、求和、排序，返回 top-k。

用的是倒排索引，不是稀疏向量。因为稀疏向量需要向量数据库支持，我们用的 ChromaDB 只支持稠密向量，所以自建了倒排索引，独立于向量数据库运行。

Q2：多少维度？Dense 多少维？

BM25 是倒排索引，没有维度概念。它存的是 词 → posting list，不产生向量。

Dense向量的维度一般都是由不同的嵌入向量模型决定的，我们使用的是text-embedding-ada-002，维度是:1536 维. 比如用Ollama，则是768维。

Q3：嵌入模型用了什么？为什么？

（面试官就很喜欢问这种，为什么选择这个方案，出于什么考虑？老实讲有时候我们自己做项目哪里考虑那么多啊，每个地方都做技术选型和对比，毕竟又不是商业项目。但是面对这些问题的时候，我们还是得思考，编也要编一个理由自圆其说）

项目目前使用的是text-embedding-ada-002，维度是 1536 维。稍微提一句，整个项目采用的是工厂模式和插件注册的方式，所以其实修改不同的嵌入模型特别容易，只用准备好api，修改配置文件即可。我采用text-embedding-ada-002的原因是：

1. 成熟稳定、生态完善：ada-002 是 OpenAI 最早大规模商用的嵌入模型之一，社区文档和最佳实践丰富，踩坑少。
2. 性价比高：在 OpenAI 的嵌入模型中价格最低（$0.0001/1K tokens），对于中小规模文档库来说成本可控。
3. 1536 维度够用：1536 维对于文档级别的语义检索已经有足够的表达能力，同时 ChromaDB 等向量数据库对这个维度的支持也很成熟。
4. 与项目混合检索架构契合：项目采用 Dense + BM25 混合检索 + Reranker 的三阶段召回策略，Dense 部分负责语义召回，ada-002 的语义表征能力足以覆盖这个场景；精排阶段还有 Cross-Encoder Reranker 做二次排序，因此对嵌入模型本身的排序精度要求可以适当放宽。

3.3.3 时间消耗、延迟测量了吗？每个环节多少？嵌入部分耗时多少？

（其实面试官喜欢问这个东西，不管是Agent还是RAG,这也是为什么我设计整个项目的时候，观测环节就加入了耗时，并且是每一步的耗时统计，大家跑Dashboard的时候在界面上可以看到的。这里告诉它每一步消耗，哪里耗时比较多，为什么，体现出我们工作的全面和真实性）

测了，整个系统从 Ingestion 到 Query 每个环节都有打点记录耗时，最终可以在 Dashboard 的 Trace 面板里可视化查看。

Ingestion 端到端，一份 10 页左右的 PDF，规则模式总耗时大概 2-5 秒，如果开了 LLM 增强会到 10-20 秒。其中加载、分块、存储这些环节都很快，加起来也就几百毫秒。耗时最突出的两个环节是 Transform 和嵌入编码——Transform 一旦开了 LLM 增强，因为每个 chunk 都要调一次 LLM API，光这一步就要 3-8 秒，是整条链路的最大瓶颈；嵌入编码调远程 Embedding API 大概 1-3 秒，占总耗时的 30%-50%，所以我们专门做了逐 batch 的计时，方便定位是网络延迟还是某个 batch 数据量大导致的慢。

Query 端到端大概 0.5-3 秒。Dense 和 Sparse 检索是并行跑的，加上 RRF 融合，检索阶段总共也就两三百毫秒。最影响查询延迟的是 Rerank，如果用 Cross-Encoder 大概 300-800ms，换成 LLM Rerank 就要 1-3 秒，基本决定了用户感知到的响应速度。

3.3.4 为什么进行混合检索？有什么作用？具体举个例子？是因为业界都这么做吗？

（其实这题很好，有点像个典型八股，就是问你为啥RAG一般都用双路检索，通过这个题了解一下两路检索的优缺点）

Q1: 为什么进行混合检索？有什么作用？具体举个例子？

我做混合检索的核心原因是：单一的检索路径都有明显的盲区，Dense 和 Sparse 的能力刚好是互补的。

Dense 检索是把 query 和 chunk 都嵌入到同一个向量空间，算余弦相似度来排序。它的强项是语义理解——用户问的和文档写的不是同一个词，它也能匹配上。但它的弱点也很明显：对精确关键词不敏感。比如用户查一个很具体的配置项名称，像 text-embedding-3-small 这种，语义向量可能会把它和一堆"嵌入模型"相关的段落混在一起，排序并不可靠。

Sparse 检索走的是 BM25 + 倒排索引这条路，本质是词频匹配。它对精确关键词、专有名词非常敏感，你搜 text-embedding-3-small，只要文档里出现了这个词，它就能精准命中。但它的短板是不理解语义——用户如果问"怎么把文档灌进系统"，文档里写的是"ingestion pipeline"，BM25 根本匹配不上，因为一个中文一个英文，词完全不一样。

所以在我们的项目里，混合检索就是同时跑两条路：DenseRetriever 用 embedding 做语义搜索，SparseRetriever 用 BM25 做关键词搜索，然后用 RRF把两路结果合并成一个统一排序。RRF 的好处是它只看排名不看分数，不需要对两路完全不同量纲的分数做归一化，实现简单又稳定。

Q2: 是因为业界都这么做吗？

(怎么感觉有点压力测试的感觉，一路确实不行啊，我觉得上面的Q1的回答就已经回答了这个问题，不过既然他要问，我们就回答吧）

不完全是。业界确实普遍采用这个方案，Elasticsearch 8.x 加了向量搜索也是走的混合路线，各大 RAG 框架也都推荐这么做。但我在项目里选择混合检索更多是从实际问题出发的：我们面对的文档既有大量专有名词和代码标识符（BM25 擅长），又有很多自然语言描述和同义表述（Dense 擅长），单一路径的召回率确实不够。而且我们在设计上做了 Graceful Degradation——如果任何一路出错或超时，系统会自动降级到另一路继续工作，不会整个检索挂掉。这个容错能力也是混合架构额外带来的好处。

3.3.5 检索召回部分的 TopK 选的多少？为什么？

第一层是 Dense 和 Sparse 各自的召回阶段，TopK 都设的 20。 这一层的目标是"宁可多捞，不要漏掉"，因为这一步的成本很低——Dense 就是一次向量相似度查询，Sparse 就是一次 BM25 倒排索引查找，速度都很快。设 20 是因为我们测试下来，大部分查询的相关文档基本在前 20 条以内就能覆盖到了。如果设太小比如 5 或 10，有些相关文档可能在其中一路排名靠后就被截断了，后面融合也救不回来；设太大比如 50、100，虽然召回更全但会给后续的融合和 Rerank 带来不必要的计算开销。

第二层是 RRF 融合之后，TopK 设的 10。 Dense 返回 20 条，Sparse 返回 20 条，两路合并去重后可能有 30 多条，经过 RRF 融合排序后只取前 10。这一步相当于把两路的结果做了一次交叉验证——如果一个文档在两路都排得靠前，融合分数会很高；如果只在一路出现，也不会被丢掉但排名会相对靠后。取 10 条是给下一步 Rerank 一个合理的候选池。

第三层是 Rerank 之后，TopK 设的 5。 这一步会用 Cross-Encoder 对这 10 条候选逐一和 query 做精排打分，Cross-Encoder 的精度比双塔模型高很多，但代价是它需要把 query 和每条文档拼在一起过一遍模型，计算量是线性增长的。所以候选不能太多，10 条进 5 条出是一个比较平衡的选择。最终送给大模型生成答案的就是这 5 条最相关的文档。（其实代码用的llm Rerank，不过扩展cross-encoder很好扩展，cross-encoder也是常考的rerank模型，有余力可以深入了解）

为什么是 20→10→5 这个比例？ 核心思路就是"粗筛多召回、精排少而精"。前面的阶段计算便宜，多拿一些保证召回率；后面的阶段计算贵但精度高，逐步砍掉不相关的，最终给到 LLM 的上下文窗口里塞的都是高质量内容。这也避免了把太多文档塞进 prompt 导致 token 浪费和注意力稀释的问题。

3.4 字节一面（来自粉丝B）

（这个面经和3.3来自于同一个粉丝，所以其实是对同一份简历，不同的面试关的考察。这个面试官就没有问那么细，也确实不是所有面试官都能问那么细。3.3那个面试官问那么细，问这个项目估计都得花20分钟。所以你要是准备好项目，整个面试60分钟的话，这个项目问题答得好，你已经成功了1/3了）

3.4.1项目背景，为什么要做这个系统？

（结合着自己场景编吧，可以参考这个模板）

核心回答框架（三段式：场景痛点 → 现有方案局限 → 解决思路）

场景痛点（为什么要做）

我们xx 平台开发团队，日常涉及的版本发布信息非常多样——Release Notes、变更日志、补丁公告、兼容性说明、架构文档等，而且这些信息分散在多个系统里：内部 Wiki、文档仓库、Bug 系统、邮件通知等。工程师排查版本差异或回答客户问题时，经常需要跨系统翻找，效率很低，而且容易遗漏关键信息。

现有方案的问题（为什么不用现成的）

我们其实尝试过直接用 Copilot / 通用 RAG 框架，但遇到几个核心问题：

• 数据源多且异构：我们有多个独立的知识库和文档系统，通用工具很难做好统一的索引和检索，召回率不够。
• 针对性不足：通用方案对我们团队的特定术语、文档结构、查询模式没有做优化，检索精度不够，返回的内容经常不是工程师真正需要的。关键问题的命中率不到 50%。
• 过程黑盒：传统工具你只能看到最终结果，不知道它检索了什么、排了什么序、为什么给你这个答案。出了问题没法调试，也无法针对性地优化。

针对性解决方案（问题 → 改进一一对应）

所以我们决定自己构建一套面向团队场景定制的 RAG 系统，针对上面三个问题分别做了改进：

针对"数据源多且异构" → 自建 Ingestion Pipeline，自主控制数据源

• 不依赖通用框架预设的信息源，而是自己定义文档来源和处理流程。设计了 6 阶段 Ingestion Pipeline，把团队散落在各系统的文档统一采集、解析、切分、向量化后存入同一个检索库，数据源完全可控

针对"针对性不足" → 两段式混合检索 + 精排

• 通用方案只用单路 Dense Embedding，对专有术语（版本号、API 名称）匹配差。我们做了 BM25 + Dense 混合粗排兜底关键词匹配，再加 Cross-Encoder 精排 Rerank 二次排序，把真正相关的内容推到前面

针对"过程黑盒" → 全链路可观测 + 自动化评估

• 搭建了 Streamlit Dashboard 可视化每次 Ingestion 和 Query 的完整 Trace（每阶段输入输出、耗时），集成 Ragas 评估框架做回归测试，改了策略能立刻量化效果变化

3.4.2 图片处理怎么设计的？

（没啥好说的吧，这个属于介绍你的项目了，很简单的问题）

我们的文档里有大量的架构图、流程图、截图，用户搜索的时候经常需要"搜文字能出图"。我的做法是 Image-to-Text，就是把图片转成文字描述，然后复用纯文本的 RAG 检索链路，不引入 CLIP 这样的多模态向量库。

整个流程跟着 Ingestion Pipeline 走。首先是图片提取，在解析 PDF 的时候，用 PyMuPDF 逐页把图片提取出来存到本地，同时在文本中插入一个 [IMAGE: image_id] 的占位符，并且在 metadata 里记录这张图的 ID、路径、页码等信息。

然后是生成描述，在 Pipeline 的 Transform 阶段，有一个 ImageCaptioner 组件会扫描 chunk 里的图片占位符，对每张图调用 Vision LLM（比如 GPT-4o）生成一段文字描述。生成的描述会追加到占位符后面嵌入 chunk 文本中，这样后续向量化的时候图片的语义就自然包含在内了。

生成的 Caption 会跟 chunk 文本一起做向量化，Dense + Sparse 双路编码，完全复用现有的文本检索链路，不需要额外的多模态向量库。

最后在检索返回的时候，有一个 MultimodalAssembler 组件，从命中的 chunk metadata 里提取图片引用，把图片读出来做 Base64 编码，按 MCP 协议组装成文本+图片+描述的混合内容块返回给客户端。

追问：为什么不用 CLIP / 多模态向量？

CLIP 更适合"以图搜图"的场景，但我们的需求是"用自然语言搜文档里的图"。用 LLM 生成 Caption 有个很大的优势：它能理解图表里的逻辑关系和具体数据，比如流程图里的步骤顺序、表格里的数值对比，CLIP 只编码视觉特征，对这类语义理解比较弱。而且 Image-to-Text 方案不需要引入额外的向量库，架构更统一，运维也更简单。

3.4.3 怎么做端到端测试？方便做吗？

（这个结合ragas来答吧，其实rag有很多评估方法，但是ragas最简单，不用准备数据集，讲别的还得讲如何准备数据集。一般来对于大部分场景，答ragas的评估也够用了。）

我们的端到端测试主要是做检索质量的回归测试。做法很简单：准备一批典型的 query list，然后直接跑系统，每条 query 走完整的 RAG 链路——检索、重排、生成，跑完之后收集日志，汇总指标做对比。

具体来说，评估质量用的是 Ragas 框架。Ragas 的核心思想是 LLM-as-Judge，就是用一个 LLM 来自动评判 RAG 系统输出的质量，不需要人工标注。它从三个维度打分：

• Faithfulness（忠实度）：回答有没有编造。做法是把回答拆成多个陈述句，逐条检查每句话能不能在检索到的上下文里找到依据，找不到的就是幻觉。得分 = 有依据的陈述数 / 总陈述数。这个指标卡住的是生成环节有没有乱编。
• Answer Relevancy（回答相关性）：回答跟问题相不相关。做法是从回答反向生成几个"可能的问题"，算这些生成问题和原始问题的语义相似度，相似度越高说明回答越切题。这个指标卡住的是最终回答有没有答非所问。
• Context Precision（上下文精度）：检索到的内容有没有用。检查返回的每个 chunk 是否跟问题相关，排在前面的越相关分越高。这个指标卡住的是检索环节有没有把无关内容混进来。

除了 Ragas 的三个质量指标，我们还会记录性能指标：端到端延迟（从发出 query 到拿到完整回答的总耗时），以及各阶段的耗时（检索耗时、重排耗时、生成耗时），因为系统本身有全链路 Trace，每个阶段的输入输出和耗时都会记录在日志里。

每次改了策略（比如换了 chunking 方式、调了 embedding 模型、改了 rerank 参数），就重新跑一轮同样的 query list，对比前后的指标变化，看质量有没有掉、延迟有没有涨。设好阈值做回归门控，比如 Faithfulness ≥ 0.7、P95 延迟 ≤ 5s，低于阈值就报警。

3.5 百度二面（来自粉丝B）

谢谢这个朋友再次给我投稿，笔记内容的3.5和3.6部分就是这个朋友给我投的稿。3.4\~3.6都来自于这位朋友，而且这四个面试素材都是大厂）

这个粉丝朋友给我的投稿内容，看得出来都是一些难一点的题目了。常规的项目问题，她反馈通过我们的面试skill，以及总结的真题，都已经有了。我看了一下这些问题，都是比较偏向于需要一些工程经验，项目经验的，不是那种纯项目八股。这些问题需要我们有一点经验积累，应届生同学看着可能会觉得难一点，不过慢慢来，应届同学可以先看懂问题和答案，慢慢思考，循序渐进。

3.5.1 考虑性能优化了吗？项目中哪些地方可以优化？

这个问题也没有标准的答案。我总结了项目中一些对于性能优化的地方，比如整个操作做异步处理比如计算embeding块的时候，是批处理的。比如跳过重复计算hash，懒加载这样可以让客户端连接mcp server会快一些，另外就是所有的环节都有耗时记录，这无非也是我们对性能的考虑.

优化这一块。第一点整个查询结果换成，变成LRU+TTL，这是一个很好的思路，也是我借鉴了一个成熟的项目得到的思路，然后就是对于hash的处理，之前是文件级别的hash做处理，当文件只有一小部分改变了，但是整个文件hash变了，这些块还要重复计算，这个也是一个值得优化的点（这个是一个粉丝朋友在群里的提问，说明他真的有很认真地在思考和学习这个项目，他现在已经上岸了，去暑期实习了）

参考回答：

有的，我在项目里从几个维度都做了性能考虑。

第一，异步化阻塞调用。 MCP Server 的工具处理层全部是异步实现的，但底层的向量检索这些库本身是同步的。我把这些同步操作卸载到线程池去执行，这样事件循环在等待期间可以继续处理其他请求，不会被阻塞住。

第二，批处理降低 API 调用次数。 Ingestion 流水线里我设计了两层架构专门处理批量 Embedding。先把所有分块的文本收集起来，再按可配置的批大小分批调用 Embedding API，把 N 次网络往返降为几次。批大小做成配置化而非硬编码，是因为不同 Provider 的限频策略差异很大，配置化可以不改代码直接调整。同时每批次都记录了耗时指标，通过 Trace 上报，方便定位瓶颈。

第三，增量处理跳过重复计算。 每次入库前先对文件做哈希校验，已经处理过的文件直接跳过整条流水线。这对重复上传或增量更新的场景非常关键，尤其是流水线里有 LLM 增强这种耗时步骤时，跳过的收益非常大。

第四，懒加载控制资源占用。 Embedding 和 VectorStore 都通过工厂模式按需初始化，不在进程启动时把所有模型全加载进来，启动速度快，内存占用也更可控。

第五，Trace 监控定位瓶颈。 流水线每个阶段都接入了 Trace 记录耗时，发现性能问题时可以直接看数据定位是哪个阶段慢，为后续优化提供数据依据。

我还想到两个目前没做但值得做的优化方向。

第一，查询结果缓存。 现在每次查询都完整走一遍 embedding → 向量检索 → rerank，重复查询每次都在重复计算。可以在查询层加一个 LRU + TTL 缓存，以查询文本、集合名、返回数量作为 key，命中缓存直接返回，整条链路全部跳过。

第二，把增量跳过的粒度从文件级下沉到分块级。 现在只要文件哈希变了，整个文档就全部重新分块、重新算 Embedding。但如果一个大文档只改了一小段，绝大部分分块内容其实没有变化，全部重算很浪费。改进思路是用内容哈希作为分块 ID，文件变了之后照常重新分块，然后批量查哪些分块已经存在，只对新增或修改的分块调 Embedding API，同时清理掉旧版本多余的分块。这样 Embedding 调用量就从跟总量成正比，变成只跟变更量成正比。

3.5.2. 对系统吞吐量做过测试吗？QPS / TPS 是多少？

这个问题就是问你有没有考虑过一秒钟整个系统能处理多少次查询？有没有考虑过。因为我们目前项目还是单机，不涉及多个客户端查询，很难出现并发查询的场景，我这里更多是从串行角度上算性能，分析QPS，计算瓶颈。其实在后面那个问题如果是做成生产项目的时候，要做什么处理提到了，可以变成远端server，通过http让多个客户端请求，这时QPS的计算就要考虑并发了。

这里我说上面的内容只是为了让大家清楚有这么一回事，你自己回答的时候，没必要提出什么并发，什么部署到server，这样不是主动暴露自己做得不够深入吗？我们不主动揭自己的短。

参考回答：

测过，我做了两轮测试，一轮测本地管线吞吐，一轮测端到端吞吐，目的是通过控制变量定位瓶颈在哪。

第一轮，本地管线吞吐。 我用 Mock Embedding 替代真实 API，隔离掉网络变量，往数据库注入合成数据，然后反复跑查询，走完整的向量检索 + BM25 + RRF 融合。测出来本地管线的 QPS 大概 58，单次查询十几毫秒就完成了。

第二轮，端到端吞吐。 接上真实的 OpenAI Embedding API，走完整条查询链路。这时候 QPS 掉到了 0.56，单次查询将近 2 秒。开 3 路并发后能到 1.31，加速比 2.3 倍。

两轮一对比，结论就很清楚了：本地管线 QPS 58，加上 API 后变成 0.56，差了 100 倍，99% 的时间花在远程 Embedding API 的网络往返上。 所以优化方向如果要优化也很明确：换本地 embedding 模型去掉网络 RTT，或者在 query 增加缓存让重复查询直接命中。

3.5.3 能支持用户并发吗？能并发上传文档吗？能并发提问吗？如何实现并发？（设计方案）

当前项目其实没有做并发上传，但是其实可以做，也不复杂，大家问问AI他都能做。可以如是说，也可以说自己做了，想好是怎么做的就行。这些东西其实就和LLM没太大关系，并发啊，锁啊，这些并发编程的内容，也就是一些开发工程的问题，面试还是偶尔会问。不过像并发编程，线程池，任务队列，锁其实也是属于比较难一点的内容，慢慢理解吧。通过一次次面试，和面试官的讨论去逐渐掌握。

参考回答：

能并发提问吗？

能。MCP Server 基于协程架构，多个查询请求在同一个事件循环里并发调度，互不阻塞。底层的向量检索、BM25 检索等同步操作被卸载到线程池执行，不占用事件循环。查询内部的 Dense 和 Sparse 两路检索也是并行执行的，而非串行等待。

能并发上传文档吗？

单文档内部是并行的——每个 chunk 的 LLM 处理（精炼、元数据增强、图片描述）通过线程池并发执行。但多文档之间目前是串行的，一个处理完再处理下一个。当时做这个决策主要考虑两点：一是 BM25 倒排索引的并发安全问题——它是基于 JSON 文件存储的，每次添加文档需要"加载全量索引→合并新数据→全量重建→写回磁盘"，这个过程不是原子的。如果两个文档并行处理，线程 A 加载旧索引并修改保存的同时，线程 B 也加载了同一份旧索引并修改保存，B 就会覆盖 A 的结果，造成索引数据丢失。要解决这个问题要么加锁（降低并行收益），要么用数据库替代 JSON 文件（改造成本较高）

如何实现并发上传？

在现有的协程架构上加一层异步任务队列即可。每个文件的上传请求作为一个任务入队，多个协程/线程消费者并发执行 Ingestion 流水线。关键要解决 BM25 索引的并发安全问题，有两个思路：一是在 BM25 写入操作上加互斥锁，保证同一时刻只有一个线程在做索引重建；二是改造 BM25 为增量更新模式，用数据库（如 SQLite FTS5）替代 JSON 文件，从根本上消除非原子操作。

3.5.4 stdio / stdout 安全性

注意这里要理解一下mcp 使用stdio/stdout通信这个协议的一些要求。这个其实在笔记：其他问题部分：2.2 MCP连接偶尔失败部分 我以这个问题为例子，写了个答案。 这个问题的背景是，使用MCP协议，这个stdio模式的stdout就是留给了mcp客户端和服务端去通信，我们不该往里面写数据，要不会导致连接问题。这个知识是这个回答的前置知识。

有了这个知识要考虑的就是数据安全，作为一个mcp server，我们不应该暴露key，暴露用户数据，要对数据脱敏。

• MCP Server 使用 stdio/stdout 作为传输层，是否安全？
• 会不会有敏感字段泄露的风险？

参考回答：

是否安全？

安全的。stdio 模式下，Server 作为子进程被 Host（比如 Claude Desktop）拉起，stdout 是两个本地进程之间的匿名管道（anonymous pipe），不经过网络，没有端口暴露，外部进程无法直接访问这条管道，安全边界等于"本机当前用户的进程权限"。第三方进程想往这条 pipe 注入数据几乎不可能；所以 stdio/stdout 本身不存在太大的安全风险。

会不会有敏感字段泄露？

需要在两条输出流上分别控制。设计 MCP Server 时，stdout 和 stderr 的分工是主动划定的：stdout 是协议专用通道，stderr 是日志专用通道。

stdout 方面：协议消息的格式由 MCP SDK 负责，我们不碰，但消息里携带的内容是 tool handler 的返回值决定的。所以要控制 handler 不把异常堆栈、配置对象、文件路径这些内部信息返回出去，遇到错误统一返回结构化的错误描述而不是原始异常。另外 Python 默认的 logging 和 print 都走 stdout，需要在 Server 启动最早期就把所有日志重定向到 stderr，防止日志内容污染协议通道。

stderr 方面：日志走 stderr，但 stderr 会被父进程继承，可能被 Host 记录到日志文件里。所以日志中对 API Key 等凭据要做脱敏处理，只打印前几位做确认，不记录完整值。

3.5.5 如果该项目要真正落地投入生产，还需要做哪些工作？

这个也没有什么标准答案，答案是基于一些项目经验回答的。真正生产项目比如对错误处理，对于安全合规，以及部署肯定都是有更高要求的。比如说我们写项目这个key是存在本地，但是通常生产级别项目的key是存在专门的server端，比如通过云厂商托管服务，AWS Seceret manager + STS通过现成的技术框架来实现鉴权，key是不会放在自己工程中的。

参考回答：

主要从三个维度：容错加固（让 LLM 调用不会因为单次失败就崩）、安全合规（密钥不落地、日志脱敏、操作留痕）、部署运维（从本地 stdio 模式切到远端 HTTP 服务，Docker + K8s + CI/CD 自动化）。

第一，LLM 调用层的容错加固。 目前项目的 LLM 调用是"单次尝试"——API 超时或返回 429 就直接失败了。生产环境必须加 指数退避重试：429 限频等 30 秒后重试，5xx 服务端错误指数退避，不可恢复的错误（如 401 鉴权失败）立即终止，不浪费重试次数。重试上限我认为 10 次比较合理。

另外需要加 速率限制，控制每分钟请求数和并发队列深度，避免突发流量打爆 Provider 配额。

第二，安全与合规。 目前 stdout/stderr 分离和错误信息脱敏做了一些，但生产环境还需要：

- 认证体系：目前 API Key 明文写在配置文件里，生产环境不能这么做——配置文件可能泄露、误提交 Git、运维人员都能看到。解决方案是接入统一的密钥管理服务，服务自己不保管任何密钥，每次需要时向密钥管理服务申请一个临时凭证，用完自动过期。这样代码和配置里彻底不出现密钥，即使临时凭证泄露影响也极小，密钥轮换只需要在管理服务侧操作，不用改代码重新部署。

- 合规日志审计：给数据分级，区分"公开"和"敏感"两类。公开数据正常记录（如"用户查询了 default 集合"），敏感数据（用户问题内容、文档内容、人名金额等）在日志中自动脱敏打码。同时所有操作（谁在什么时间上传了什么文档、查询了什么）必须完整留痕，存到统一的审计系统。

- 输入校验：对用户上传的文档做大小限制、格式白名单，防止恶意文件触发异常。

第三，部署与运维。 目前项目用的是 stdio 本地模式，Host 拉起子进程，只服务单个用户。如果要投入生产服务多用户，首先需要把传输层从 stdio 切换到 HTTP/SSE，让 MCP Server 变成一个可以通过网络访问的远端服务。一旦变成网络服务，就需要用 Docker 把服务和所有依赖打包成镜像，保证环境一致性，镜像不可变，回滚只需切回上一个版本。然后用 K8s 做编排，负责自动调度、水平扩缩容、实例故障自动重启、滚动更新零停机。最后搭建 CI/CD 流水线，代码推送后自动跑测试、构建镜像、部署到 K8s，全程自动化。

3.6 京东一面（来自粉丝B）

我估计是面试官对于这个vibe coding技术本身比较好奇，两个问题都是和vibe coding相关的。另外这个粉丝朋友其实是只提供了他不会或者在之前笔记，面试突击Agent中没出现过的问题。

3.6.1 统计过项目的代码量吗？ 用 AI (Vibe Coding) 辅助开发消耗了多少 token？

我用AI帮大家统计了一下我们的项目代码。也是个5w行代码级别的项目了。要是搁着原来，这项目不知道得写多少天，现在竟然是我用2个月下班时间让AI写完的。

代码量已做过统计（排除 .venv、pycache 等非业务文件）：

• Python 源码：198 个文件，47,433 行
• Markdown 文档：51 个文件，13,014 行
• YAML 配置：2 个文件，196 行
• TXT 提示词：5 个文件，78 行
• TOML 项目配置：1 个文件，72 行

- 合计：257 个文件，约 6 万行

纯业务代码（Python）198 个文件，约 4.7 万行，含文档总量约 6 万行

• 平均每文件约 240 行，架构分层清晰（core / ingestion / libs / mcp_server / observability）

Token 消耗方面：整个项目使用 GitHub Copilot（Claude Sonnet 模型）进行 Vibe Coding 辅助开发，Copilot 订阅制不直接暴露 token 用量，无法精确统计；但从开发规模来估算，整个项目按照设计文档分为 9 个大阶段、60 个子任务，每个子任务都是一轮完整的"需求对话 → 代码生成 → 测试修复"循环，单次大型功能迭代约消耗数万 token，60 个任务累计预计在 数百万 token 量级。

3.6.2 如何评估VibeCoding

这个问题其实还挺好回答的。spec, 测试，一小步一小步执行都是我们自己的实践。然后加了一个harness工程的思想，harness工程我们笔记里总结的也有，就是如何让AI更好的写代码的思路，加了一些思想进去。之前我做这个项目的时候用的技巧是1，2，4. 现在如果再让我做，我会加入harness工程的思想，随着学习，技巧还是在不断进步的。

总结一下思想：Spec 管设计，Harness 管边界，人工 Review 管意图，测试管底线。

第一，Spec 先行，AI 只做执行。

写代码之前，我在 DEV_SPEC 里把架构全部定好了——9 个阶段、68 个任务，每个任务的接口定义、目录结构、模块交互方式全部写死。AI 的角色是"按图施工"，没有设计决策权。这从源头杜绝了 AI 自由发挥导致的架构混乱。

第二，Harness 思想约束 AI 行为。

三个关键做法：Agent 用完即销毁——每个任务一个独立会话，完成就销毁，防止上下文污染和错误传播。权限边界明确——AI 只能操作 Spec 指定的文件，不允许自行创建模块或修改架构。评判由程序驱动——测试是否通过、类型检查是否干净，全部由 pytest、mypy 等外部工具判定，不让 AI 自查自纠。AI 有幻觉，让它自己评估自己等于考生自己批改试卷。

第三，68 个任务逐一人工审核。

不是让 AI 一口气生成整个项目，而是每完成一个任务就做一次人工 Code Review——检查是否符合 Spec、有无偏离设计意图、边界条件是否覆盖。粒度越细，问题越早暴露，修复成本越低。

第四， 54个测试文件作为硬性底线。

54 个单元测试、13 个集成测试、4 个 E2E 测试，覆盖从单组件到全链路。每个任务完成后必须跑通相关测试才能提交，跑不过自动修复最多三轮，三轮不过交人工。测试是交付的前提条件，不是可选项。

3.6.2 设计模式八股（工厂，策略）

设计模式通常其实也是需要一些工作经验才能慢慢理解的，面试其实问的没那么多，偶尔会出现，可以先不学那么深入，毕竟先学性价比高的。但是你做了我们项目，用了大量工厂模式，建议最少还是学一下工厂模式。我来给大家总结个工程模式八股。

参考答案：

工厂模式

工厂模式的核心思想是把"创建对象"这件事从调用方剥离出来，交给一个专门的工厂来做。调用方只需要告诉工厂"我要哪种类型"，工厂负责返回对应的实例，调用方完全不需要知道具体的实现类是什么、构造函数需要什么参数。

它解决的核心问题是解耦。如果调用方直接 new 具体类，那每次换一个实现就得改调用方代码，改一处还好，如果十个地方都在用就要改十处。用了工厂之后，调用方只依赖抽象接口，具体用哪个实现由工厂根据配置决定，切换实现只需要改配置，不动业务代码。

在我的项目里，LLM、Embedding、Splitter、VectorStore、Reranker 这些组件全部用工厂模式创建。比如 Embedding，配置文件里写 openai 就用 OpenAI 的实现，改成 ollama 就自动切到本地模型，调用方一行代码都不用改。要加一个新的 Provider，只需要写一个新的实现类，在工厂里注册一下就行，已有的代码完全不用动——这就是开闭原则，对扩展开放、对修改关闭。

3.7 快手一面

3.7.1 你的 Index 是怎么做的？

• 粉丝回答：存成了 JSON 格式

- 面试官追问：用 JSON 怎么读取？（没答上来）

- 面试官评价：不存数据库或者不建立索引应该是不对的。现在这样用 JSON，读取和更新都很麻烦，会 OOM 或者时间太长。

粉丝投稿的上下文有限。这个Index索引我不知道指的是稠密向量还是稀疏向量的索引。稠密向量的索引我们用的ChromaDB的HNSW，稀疏向量用的自建的BM25倒排索引，存成JSON。我猜测他们是在聊后者，但是估计前面一个问题是先问我们同存了哪些数据的。所以这里先给个前置问题的解析。 另外针对于这个问题，我们本身存成JSON格式，也是用了索引的，可以和面试官解释。具体讲解我放在下面的答案里。

（前置问题）你的 RAG 系统都存了哪些数据？怎么存的？

其实作为RAG系统最核心的问数据存了啥，其实就是下面的2和3，稀疏向量和稠密向量怎么存的，或者可以带上4，毕竟我们是支持图片检索的系统。1和5算是其他方面的功能，便于理解我都总结出来。

我们项目共有 5 块存储：

1. 文件指纹库（SQLite）— 存文件 SHA256 和入库状态，负责幂等控制，防止同一文件重复入库。
2. Dense 向量库（ChromaDB，底层 SQLite + hnswlib）— 存原文 + 向量 + HNSW 图索引，负责语义相似度检索。
3. BM25 倒排索引（JSON 文件）— 存倒排表（term、tf、idf、doc_length），负责关键词匹配检索。
4. 图片资源库（文件系统 + SQLite）— 存图片二进制 + 元数据索引，负责多模态图片检索。
5. Trace 日志（JSONL）— 存全链路 trace 事件，用于可观测性和 Dashboard。

各存储的路径与补充说明：

- 1 文件指纹库：路径 `data/db/ingestion_history.db`，同一文件不重复入库

- 2 Dense 向量库：路径 `data/db/chroma/`，ChromaDB 内部 SQLite 存 chunk 原文 + metadata + id 映射；hnswlib 二进制段（`*.bin`，float32 数组）存 1536 维稠密向量 + HNSW 图索引

- 3 BM25 倒排索引：路径 `data/db/bm25/{collection}/*.json`，倒排表结构（term → posting list，含 tf、doc_length、idf），不存原文

- 4 图片资源库：路径 `data/images/{collection}/` + `image_index.db`

- 5 Trace 日志：路径 `logs/traces.jsonl`，记录 ingestion + query 全链路事件

面试照答版本：

我们项目有 5 块存储：

第一块是文件指纹库，用 SQLite 记录每个文件的 SHA256，做幂等校验，同一文件不重复入库。

第二块是 Dense 向量库，用 ChromaDB。Chroma 内部分两部分存：SQLite 存 chunk 原文、metadata 和 id 映射；hnswlib 的二进制段（float32 格式）存 1536 维稠密向量和 HNSW 图索引。查询时先走 HNSW 图 O(log N) 找到 top-k 的 id，再用 id 去 SQLite 拉原文。

第三块是 BM25 倒排索引，用 JSON 文件存储。这个 JSON 装的不是原始数据，是倒排表结构（词 → 文档命中列表，含词频、文档长度、idf）。查询时 O(1) 哈希查词，然后只遍历命中的文档算 BM25 分。命中后原文不存在这里，用 chunk_id 去 Chroma 取，避免重复存储。

第四块是图片资源库，文件系统存图片二进制，SQLite 存图片元数据索引，支持多模态检索。

第五块是 Trace 日志，JSONL 格式记录全链路 trace 事件，用于可观测性和 Dashboard 展示。

其中第二和第三块是核心——查询时两路并行召回，Dense 走语义、Sparse 走关键词，RRF 融合后 Rerank 出最终 top-k

Q1. 你的 Index 是怎么做的？

因为我推测这个面试问题是针对于稀疏向量来问的，所以我对于稀疏向量的索引选型原因进行了展开。我不清楚同学面试具体情况，看上去面试官在挑战他说存成JSON，我们没有做索引。但是其实不是的，我们存了JSON，维护了自建的倒排索引。第二个是我猜面试官可能会挑战的，就说你为啥不用专门的库比如Elasticsearch来做，包括向量数据库，为啥不用Milvus这样支持数据量更大的库来做。这两个问题回答思路是一样的。就是归根结底我们项目还是本地的数据库，那么数据量级并没有很大，盲目用更复杂的库要考虑的东西很多，而且开销也会更大。其实你看openclaw，本身也是一个本地的agent，用了双路查询，他甚至是没有用专业向量数据库，只用的sqlite。所以被挑战的时候你要想清楚，说明理由我觉得可以让面试官信服的。当然如果你说你要包装成更复杂的系统，用Milvus,Elasticsearch，那么你要清楚的这种情况你的数据量级应该是千万级别以上的，你的业务场景是啥，另外也会涉及分布式等后端知识。你能不能包装自圆其说讲清楚。

答题思路：在前置问题基础上，聚焦到"索引"展开，重点讲两套索引 + 自建的原因。

面试照答版本：

我们的 Index 是两套并行的 Hybrid Index。

稠密向量这边，用的是 ChromaDB 自带的索引。Chroma 底层用 hnswlib 做 HNSW 图索引，查询复杂度是 O(log N)，这部分不需要我们自己实现，直接调 Chroma 的接口就能做近似最近邻搜索。

稀疏向量这边，是我们自建的 BM25 倒排索引。倒排索引的结构是按词组织的——每个词记录了它出现在哪些文档里、出现几次、文档多长。查询时先 O(1) 通过哈希直接定位到这个词的记录，然后只遍历命中的文档算 BM25 分，复杂度是 O(K)，K 是命中此词的文档数，跟库里总文档量无关。所有统计原料在 build 阶段一次性预算好，查询时只做公式代入，非常快。

选择自建而不是用 Elasticsearch，主要考虑了两点：第一是数据量级，我们是企业内部知识库场景，文档量在百万 chunk 级别，倒排索引加载到内存也就 1-2 GB，完全扛得住。一般到千万甚至亿级 chunk 的时候才需要上 ES 那种分布式方案。第二是部署形态，我们定位是一个本地化部署的系统，不想引入 ES 这样的重依赖——ES 需要 JVM、集群配置、额外运维成本，对本地私有化场景来说太重了。自建的方案一个 JSON 文件就搞定，启动即用，零额外依赖。

两路各自召回 top-k 后，用 RRF 融合再 Rerank 出最终结果。

3.8 某大厂一面

3.8.1 面试官问：为什么不用开源框架，比如 LlamaIndex？

答题策略：这个问题确实是需要你对LlamaIndex这个库很了解才能回答出来。有两个思路：1. 功能层面，功能层面Llamaindex也是都能满足，因为我们有自己的思想，比如做的高度可插拔，高度可控。即使有些地方使用Llamaindex可以做到，但也许也需要改造，成本也不低。 2. 性能层面。使用Llamaindex本身可能会让系统更加笨重，因为专业的库本身功能全，但是无可避免他也会更臃肿。

这两个思路其实也是很多现有的项目的思路。你可以看很多成熟的公司，比如我面试的阿里千问，有一个创业公司，还有一个盛大的开源项目，都是自己手搓的Agent框架。那他们为啥不用Langchain，功能层面也可以实现呀。所以这块不用怕，能够说清楚为自己正名就好

面试回答：

选择自建而不用 LlamaIndex，核心原因是两者的设计目标不同。LlamaIndex 是广度优先的通用框架——200 多个集成、覆盖尽可能多的场景；我们这个项目是深度优先，需要在一条 RAG 链路上做到每个环节都可控、可定制。我从功能和性能两个维度来说。

第一是功能层面，有些定制需求用框架实现的成本反而更高。 比如入库流水线，我们有三个 LLM 增强阶段——分块精炼、元数据提取、图片描述，每个阶段都有独立的 prompt 文件可以按业务场景替换，而且做了 graceful fallback，LLM 调用失败自动降级到规则处理不阻塞流水线。LlamaIndex 有 Transformation 和 Extractor 接口，理论上能做，但要适配它的 Node 体系和回调流程，三个阶段的错误降级、并行编排、prompt 热替换这些都得在框架约束下绕着走，改造成本不低。再比如混合检索，我们自建了 BM25 倒排索引，IDF 的 k1、b 参数可调，分词用 jieba 做中文适配加停用词过滤，Dense 和 Sparse 两路并行召回再 RRF 融合。LlamaIndex 也能接 BM25，但它把 BM25 当黑箱组件挂上去，你控制不了 IDF 参数、看不到倒排表、也没法定制分词策略，调参空间很有限。

第二是性能和依赖层面，LlamaIndex 的依赖链太重了。 光 `llama-index-core` 一个包就有 27 个以上的直接依赖，包括 SQLAlchemy、networkx、nltk、tiktoken、pillow、banks、tinytag 这些——SQLAlchemy 是 ORM 我们不需要，networkx 是图计算库我们不需要，tinytag 是音频元数据解析器我们更不需要。这些库各自又有自己的传递依赖，装完之后整个依赖树非常庞大。而我们项目的核心依赖只有 9 个——chromadb、jieba、mcp、pyyaml、langchain-text-splitters 这些，每一个都是实际会用到的，没有冗余。依赖少意味着三件事：第一，启动快、内存占用小，私有化部署场景这很关键；第二，安全面小，每个依赖都是潜在的 CVE 补丁点，依赖越多运维成本越高；第三，版本冲突少，LlamaIndex 的依赖链越长，跟项目里其他库发生版本冲突的概率就越大。

总结来说，LlamaIndex 适合快速出 POC 或者需要对接大量异构数据源的场景。但我们需要在 LLM 增强流水线、混合检索调参这些 RAG 核心环节上做深度定制，同时保持依赖轻量便于私有化部署。自建的总成本反而比引入一个重框架再做二次开发更低，同时对每个环节有完全的理解和控制权。

3.9 某大厂一面

3.9.1 向量数据库大小，有多少个 PDF？

这个问题其实就是因人而异了。我做出这个项目的时候是没有指定对应数据量的，但是思路我说了需要大家自己去包装，也提供了包装项目，写简历的SKILL。 这里需要大家自己思考一下业务场景然后包装。这里我们不妨，假设我们就是一个给公司内部小组使用的知识库（不是整个公司啊，而是一些组），以这个角度去回答。

假设场景：企业内部小组知识库（如技术文档、规范流程、会议纪要等），服务于一个 10-30 人的业务线。

面试回答：

我们的场景是企业内部业务组的知识库，主要存技术文档、规范流程和会议纪要这类材料。目前入库了大约 200 份 PDF，平均每份 15-20 页，经过切分后产生了大约 5 万个 chunk。

向量库的实际大小可以这样估算：我们用的 `text-embedding-ada-002`，每个 chunk 是 1536 维的 float32 向量，单条向量 1536 × 4 字节 = 6KB。5 万个 chunk 的向量数据大约是 300MB。加上 ChromaDB 里 SQLite 存的原文、metadata、id 映射，以及 hnswlib 的 HNSW 图索引开销，整个 `data/db/chroma/` 目录实际大小在 500MB-800MB 这个量级。BM25 倒排索引那边更小，5 万 chunk 的倒排表 JSON 大概也就 几十 MB。

选型上，我们用的 ChromaDB，核心原因是部署形态决定技术选型。我们是内网私有化部署的系统，部署在组内的一台内网服务器上，通过 MCP 协议的 SSE 传输层暴露给组内成员，所有人的 IDE 通过内网连接这个 Server。Chroma 在服务端以 Client-Server 模式运行，底层用 hnswlib 做 HNSW 图索引，查询复杂度 O(log N)，支持并发读写。5 万条数据量级下，单次向量检索延迟在毫秒级，20 人并发查询完全扛得住。

如果未来要扩容，我也有明确的分级方案：

- 10 万 chunk 以内：ChromaDB 完全扛得住，单机内存足够，不需要任何变动。

- 10 万到百万级：可以考虑切到 Qdrant 或者 FAISS，它们在大规模数据下的索引效率和内存管理更优。我们的向量库通过 `VectorStoreFactory` 做了工厂模式抽象，配置文件里改一行 `provider: "qdrant"` 就能切换，代码零改动。

- 千万级以上：就得上 Milvus 这种分布式方案了，做分片、副本、支持水平扩展。但那已经是整个公司级别的知识库了，不是我们当前的场景。

总结一下，200 份 PDF、5 万 chunk、向量库 500-800MB，用 ChromaDB 部署在内网服务器上，通过 SSE 暴露给组内 20 人使用。选型的思路就是数据量级匹配部署形态——当前量级用轻量方案，架构上预留了扩展能力，量级上来随时可以切。

3.9.2 为什么公司你存内部文档就需要 size 1000？

你设置 1000 是不是太大了？1000 个字是不是太多了？

这里推荐大家看一下八股里的Chunk size的选型，使用这个思路，讲清楚为什么选择这样的chunk size,相信就不会被面试官挑战了。八股里补充了chunck size的选型策略，从哪几个维度去考虑。面试官问我们为什么这么选chunk size的时候以及chunck size的选型策略时可以参考。

回答假设我们是企业内部技术小组知识库，文档以英文技术文档为主（API docs、Architecture Decision Records、Runbooks、Postmortem 等）。

面试回答：

chunk_size=1000 不是拍脑袋定的，我从四个维度来解释这个选择的合理性。

首先明确一下，1000 是字符不是 token。 我们用的 RecursiveCharacterTextSplitter，length_function 是 Python 的 len()，按字符计数。我们的文档以英文为主，英文 1000 个字符约 150-200 个单词、200-250 个 token，大概就是一个自然段落的量。

第二，这个值正好落在 embedding 的最佳输入区间。 text-embedding-ada-002 虽然 max token 是 8191，但实践表明 100-800 token 区间信息密度最高。200-250 token 处在区间中段，向量质量最好。其实对英文来说 1000 字符不但不大，反而还偏保守，上调到 1500-2000 字符（400-500 token）也完全在合理范围内。

第三，匹配文档的自然语义粒度。 我们的英文技术文档，一个自然段落通常 100-250 个单词、500-1200 个字符。1000 字符刚好对应一个完整的语义单元——一个 API 说明、一条操作步骤、一段架构决策。不会横跨不相关的段落，也不会把一段话切碎。

第四，LLM 窗口预算非常充裕。 召回 top-10，每个 250 token，总共才 2500 token，LLM 还有大量空间做推理和生成。

另外要补充一点，RecursiveCharacterTextSplitter 不是硬切 1000，它会按段落、换行、句号这些语义边界递归切分，实际大部分 chunk 不到 1000。再加上 200 字符的 overlap、LLM chunk 精炼和 metadata 增强，对粒度的容错能力很强。

不过要注意一点，如果文档是中文的，情况就完全不同了。中文 1000 字符就是 1000 个汉字，约 1500-2000 token，远超 embedding 最佳区间，那就确实太大了，需要降到 500-600 字符。所以这个数字不能一概而论，关键是要搞清楚计量单位和语言场景，不同的场景情况也是不同的。

3.9.3 你考虑什么数据存 RAG？

我对这个问题好像没什么见解，让AI生成的答案。感觉很少这么问。

面试回答

什么数据适合放 RAG，核心判断标准就是这份数据适不适合用"检索+生成"的模式来回答问题。

适合放的有四类。 第一是事实性强、答案明确的知识，比如技术文档、操作规范、FAQ，用户问"是什么"、"怎么做"，答案就在文档里，RAG 检索到直接回答，效果最好。第二是更新频繁的知识，比如版本发布说明、变更日志，如果靠 fine-tuning 烧进模型参数每次更新都要重新训练，成本极高，RAG 只需要重新入库那一份文档，下次检索立刻生效。第三是长尾的私有领域知识，公司内部的 Runbook、Postmortem、架构决策记录，互联网上搜不到，通用大模型没训练过，只有 RAG 能覆盖。第四是需要溯源引用的场景，RAG 天然带 source_ref 可以追溯原文，对合规要求高的场景比模型"凭记忆"回答可靠得多。

不适合放的有三类。 推理性任务，比如"对比三个方案的优劣"，这不是检索能解决的，需要 LLM 自身推理能力。结构化查询，比如"上个月销售额多少"，答案在数据库表里，走 Text2SQL 或 function calling 比 RAG 高效得多。高实时性数据，比如股票价格、系统监控指标，入库就过时了，应该走 function calling 实时调 API。

3.9.4 MCP tools 的编写原则——不只是 tools 的描述需要描述好，还有什么关键点？

答题策略：MCP 官方规范定义了 tool 的六个字段（name / title / description / inputSchema / outputSchema / annotations），每个字段背后都对应一条设计原则。回答时从六个维度展开，结合项目实际代码举例，展示对 MCP 协议的深度理解。我把这个问题放到了MCP八股中。

参考八股 MCP Server Tool的设计原则

3.9.5 视频讲解

3.7 \~ 3.9 小节对应的视频讲解

https://www.bilibili.com/video/BV1RboMB9EGp/?vd_source=144bec9c3f54e465073138bed788be1b

3.10 字节跳动暑期实习一面（2026/5）

字节暑期实习一面 ，也有相关的该RAG项目面试问题。这个是一个小姐姐拿我们项目去面试的素材。

3.11 PDF 处理问题

虽然我没有写这个是哪个公司的面试真题，但是根据粉丝朋友的反馈，很多公司都会问你如何处理的PDF，包括群里提问，也有粉丝问PDF有页眉怎么处理，最近一次粉丝给我提问的原话是："博主，现在很多低阶的岗位特别喜欢问你对PDF是如何处理的，能否讲一下这个问题"。所以这个问题还是挺有代表性的。我也专门把这个PDF的处理标准流程提炼成了专题知识放在RAG知识部分：输入文件处理。常见的问法如下：

1. 你在处理pdf转成markdown文本的这个步骤，你是怎么处理的，可以分享一下吗？

💡 答题思路

答题思路：在我们笔记中，专门讲解了如何处理PDF。我们就按照笔记里的标准思路：文件基础体检 - 逐页判断类型 - 按页面类型解析 - 统一结果 - 结果检查 的思路，把这个答案回答清楚。

📝 参考答案

我们没有直接用一种解析器处理所有 PDF，而是设计了一套分阶段、按页面类型路由的处理流程。

首先进行文件级体检，通过文件哈希去重，并检查文件是否加密、损坏、页面方向是否异常，同时记录文件名和总页数。接下来逐页分析文字数量、图片覆盖率、异常字符比例和版面结构，将页面分为原生文本页、扫描页、混合页、复杂布局页和异常页。

对原生文本页，我使用 PyMuPDF 提取文字及坐标；扫描页先渲染为图片，再使用 PaddleOCR 识别；混合页同时提取原生文字和重要图片区域，对图片执行 OCR 或多模态理解后再去重合并。对于多栏、表格和图文混排等复杂布局页，我会优先使用 Unstructured 的 hi_res 策略识别标题、正文、表格、图片区域及其坐标，再按照坐标恢复阅读顺序；如果页面结构特别复杂，也可以使用 LlamaParse 直接解析成带层级的 Markdown。对于乱码页面，先用 PyMuPDF 提取；如果存在字体编码或字符映射问题，就切换到 pdfplumber 或 pypdf 交叉验证；这些解析器仍无法恢复时，再将异常页面渲染成图片，使用 PaddleOCR 做页面级兜底。

不同路线的输出最后会统一为相同结构，按照原始页码和页面内阅读顺序组合成 Markdown，并保留文件名、页码和异常标记，保证结果可以追溯到原文。完成后还会检查漏页、乱码、页眉页脚残留、OCR 重复、多栏错序及表格关键数字。只有通过质量检查的内容，才会进入后续分块和向量化流程。

子问题

这些子问题的答题思路了，这个其实就是我们笔记中PDF处理的步骤三的内容，根据不同页面做相应处理。

我们从回答里面可以看出来，想要把PDF处理好，处理完整是多么复杂的一件事，你看看我们下面的回答，用了多少不同的库，要处理多少类型。

我的个人建议是：背一背得了。 通过我们的讲解和回答，最少对于下面的问题，你有一个大体的思路和了解，面试官真问到，大面上能回答上来。通常来说他不会再追问更加具体的细节了，比如里面使用的某个库，以及具体处理细节。

• 1.1 你的pdf中有乱码，你是如何处理的？

💡 答题思路

先判断乱码来源，再按照“切换解析方式 → OCR 兜底 → 质量检查”的顺序处理，避免一遇到乱码就对整份 PDF 执行 OCR。

📝 参考答案

PDF 乱码通常来自字体编码、字符映射异常或解析器不兼容。因此，我会先根据异常字符比例判断是局部乱码还是整页乱码。默认使用 PyMuPDF 提取；如果结果异常，就切换到 pdfplumber 或 pypdf 重新提取并交叉验证。如果只是少数字符异常，可以结合明确的规则和上下文进行修复，但不会让大模型随意改写原文。

如果更换解析器后仍然乱码，我会通过 PyMuPDF 将异常页面渲染成 200～300 DPI 图片，再使用 PaddleOCR 重新识别，而不是对整份文件统一执行 OCR。识别后通过异常字符比例、文本完整度和 OCR 置信度进行检查；低质量页面重新识别或转人工复核。同时保留原始页码，方便回到 PDF 核对。

• 1.2 你的pdf中有图片，你是如何处理的？

💡 答题思路

先区分装饰图片、文字截图和需要理解关系的图表，再分别选择忽略、OCR 或多模态理解。

📝 参考答案

我不会对 PDF 中的所有图片做相同处理，而是先判断图片是否包含有效信息。Logo、背景和纯装饰图片通常不进入知识库；带文字的截图会先提取图片区域，再使用 OCR 识别文字，并按照图片在页面中的位置插回正文。

对流程图、架构图和统计图，普通 OCR 只能读出文字，无法还原节点关系、箭头方向或数据含义，因此会使用多模态模型生成结构化说明。输出时仍然保留原图引用、所在页码和生成说明，便于溯源和人工核对。如果原生文字与图片 OCR 结果重复，还会在合并阶段进行去重。

• 1.3 你的Pdf中有页脚页眉，你是如何处理的？

💡 答题思路

利用跨页重复规律和文本坐标识别页眉页脚，不能只依赖固定字符串，以免误删正文。

📝 参考答案

我会保留文本块的坐标信息，并统计连续页面顶部和底部区域的内容。如果某段内容在相近位置跨页重复出现，就将它判断为页眉、页脚或水印；连续变化的数字则可以结合固定位置识别为页码。

删除时不会只使用字符串匹配，而是综合位置、跨页重复率和文本变化规律判断。封面、章节首页等版式不同的页面会单独处理。页眉页脚从正文中移除后，原始 PDF 页码仍作为元数据保留，确保后续检索结果可以定位到原文。

• 1.4 你的pdf中有表格，你是如何处理的？

💡 答题思路

先区分原生表格和扫描表格，再选择表格提取或 OCR 结构识别；重点说明结构、关键数字和跨页关系的检查。

📝 参考答案

对带有文字层、边界比较清楚的原生表格，可以使用 Camelot 或版面解析工具提取单元格结构；对于扫描表格，需要先执行 OCR，再通过表格结构识别恢复行列关系。提取结果会根据后续使用场景转换成 Markdown、HTML 或 CSV。

表格处理最重要的不是只把文字读出来，而是保留表头、行列关系和关键数字。因此我会重点检查合并单元格、跨页表格、单位、正负号和数值是否发生错位。对于跨页表格，还要根据相同表头和页码关系进行合并。如果自动解析无法可靠恢复结构，就保留表格截图和页码并转人工复核，而不是输出可能误导模型的错误表格。

3.11.1 讲解视频

https://www.bilibili.com/video/BV1gF8Z6WEGW/?spm_id_from=333.1387.homepage.video_card.click&vd_source=144bec9c3f54e465073138bed788be1b

3.12 如何保证RAG系统生成的回答是准确的？

这两个问题也是粉丝朋友投稿的，虽然他没告诉我是哪个公司，但是这两个问题确实是来自于面试真题。我觉得这两个题目也很好，很有价值。面试官关心你的RAG最后的回答，准确性到底怎么样？虽然我们有讲RAGAS在事后去评估，但是有没有方法可以在整个RAG系统生成回答的时候，就能够检测质量，及时兜底呢？要讲清楚这个问题，我的思路是从Self-RAG这个技术出发，可以先参考RAG专题笔记：Self-RAG.

💡 答题思路

我们这里借助Self-RAG 的思路，将4个检测融入到整个RAG系统中，在系统运行的时候做动态监测，实时重新调整或者拒答。同时因为传统的Self-RAG是需要训练专门评测的模型的，所以我们这里借助Self-RAG的思路，RAGAS的评估方法，来组织这个参考答案。

📝 参考答案

我们不能保证 RAG 的每次回答都绝对正确，但可以通过一套检索—生成—评估—修正—拒答的闭环，尽量降低错误回答直接输出的概率。整体流程借鉴了 Self-RAG 的自反思思路，但实际检测使用的是 RAGAS 的评估方法，不需要专门训练 Self-RAG 模型。

首先通过业务规则或 LLM 分类器判断当前问题是否需要查询知识库，避免对闲聊或通用问题进行无意义检索。需要检索时，使用 RAGAS 的 Context Precision 和 Context Relevance 评估召回内容是否与用户问题相关，并结合 Reranker 分数和相关性阈值过滤无关 Chunk。如果上下文相关性不足，就改写查询、扩大召回范围或重新检索，而不是直接基于低质量证据生成答案。

生成答案后，使用 Faithfulness 检查答案中的结论能否从检索上下文中得到支持，重点识别无依据补充、事实冲突和模型幻觉；再使用 Answer Relevancy 判断答案是否真正回应了用户的问题。如果测试集提供了标准答案，还可以使用 Answer Correctness 进一步评估答案与标准答案在事实和语义上的一致程度。

最后综合上下文相关性、答案忠实度和答案相关性进行评分，只有达到质量阈值的答案才会输出，并附带引用来源，方便回到原文核对。如果 Context Precision 或 Context Relevance 较低，就重新检索；如果 Faithfulness 较低，就要求模型严格依据现有证据重新生成，证据本身不足时也要重新检索；如果 Answer Relevancy 较低，就调整提示词、答案内容或表达结构后重新生成。系统还会设置最大修正次数，如果多轮处理后仍然达不到阈值，就明确提示资料不足并拒答或转人工，而不是让模型猜测。通过 RAGAS 的动态评估和失败兜底机制，可以提高答案的准确性、可追溯性和稳定性。

3.12.1 召回的 Chunk 中有很多噪声，如何保证结果稳定？

💡 答题思路

先区分 Chunk 内部的内容噪声和检索结果中的噪声 Chunk。

内容噪声可以从我们对PDF处理的方法，将PDF转成Markdown，就会对内容噪声去除。

检索噪声可以从我们项目本身做的RRF融合，双路检索，Reranker触发，这些是保证我们系统检索准确率的手段。

最后再引入Self-RAG的思想，我们有动态兜底，实时检测，即使最终回答很差，也能及时检测，调整，或者拒答。

📝 参考答案

我会先区分两类噪声。第一类是 Chunk 内部的内容噪声，例如 OCR 乱码、页眉页脚残留、重复内容、表格错位和多栏阅读顺序错误。这类问题主要在 PDF 解析、文本清洗和分块阶段处理，通过分类解析、去重、异常检测和结果检查，尽量避免脏数据进入向量库。

第二类是检索噪声，即 Chunk 本身没有问题，但与当前问题无关或相关性较弱。检索阶段先通过关键词与向量混合检索提高有效证据的召回率，再通过 RRF 融合多路结果、提高优质证据的排序；随后使用元数据过滤、相关性阈值和 Reranker 去掉低相关内容，并根据问题复杂度和相关性分数控制 Top-K。Top-K 本身不是去噪手段，关键是避免将过多低相关 Chunk 放入上下文。

最后在生成阶段要求模型严格依据上下文回答，并标注引用来源；生成后再检查答案是否获得证据支持。如果上下文相关性低，就重新检索；如果证据充分但回答不忠实，就约束模型重新生成；如果多次处理后证据仍然不足，就拒答。通过入库前清洗、检索后过滤和生成后校验三层机制，共同保证结果稳定。

3.12.2 讲解视频

https://www.bilibili.com/video/BV1gF8Z6WEGW/?spm_id_from=333.1387.homepage.video_card.click&vd_source=144bec9c3f54e465073138bed788be1b

4.视频讲解

4.1 项目Skills使用：

如何让AI 使用Skill 遵循dev spec 完成代码。注意视频里的SKILL其实已经重新优化，现在叫做autocoder, 功能是一样的，大家使用代码的时候看一下描述就知道了，使用方法是一样的。

https://www.bilibili.com/video/BV1ixAVz9EaQ/?vd_source=144bec9c3f54e465073138bed788be1b

4.2 RAG-Agent项目设计思路和学习方法

https://www.bilibili.com/video/BV1S8wvziEWA/?vd_source=144bec9c3f54e465073138bed788be1b

4.3 项目数据处理流水线讲解

我用夸克网盘分享了「项目数据处理流水线讲解.mp4」，点击链接即可保存。打开「夸克APP」，无需下载在线播放视频，畅享原画5倍速，支持电视投屏。

链接：https://pan.quark.cn/s/cd0bdeab1744

4.4 集成到Cursor效果

我用夸克网盘分享了「集成到Cursor效果.mov」，点击链接即可保存。打开「夸克APP」，无需下载在线播放视频，畅享原画5倍速，支持电视投屏。

链接：https://pan.quark.cn/s/7e3883ad392d

4.5 项目初步demo展示

我用夸克网盘分享了「项目初步demo展示.mp4」，点击链接即可保存。打开「夸克APP」，无需下载在线播放视频，畅享原画5倍速，支持电视投屏。

链接：https://pan.quark.cn/s/46b58cbc29a9

4.6 Resume-Writer SKILL

https://www.bilibili.com/video/BV1aBAfzGEct/?vd_source=144bec9c3f54e465073138bed788be1b

4.7 Test SKILL

展示了使用AI 来完成自动化测试的功能。其中讲了如何写SKILL, 如何写dev_spec文档的

我用夸克网盘给你分享了「AI测试-SKILL-文档编写.mp4」，点击链接或复制整段内容，打开「夸克APP」即可获取。

/\~7be03LqXsd\~:/

链接：https://pan.quark.cn/s/8c178085e27f

4.8 Setup SKILL

https://www.bilibili.com/video/BV1CHPqzqE4R/?vd_source=144bec9c3f54e465073138bed788be1b

4.9 模拟面试SKILL

https://www.bilibili.com/video/BV1R7PszQEAc/?vd_source=144bec9c3f54e465073138bed788be1b

附录

视频中4.7 讲到的一些prompt模板：

1.使用plan的方式，让AI先设计计划，然后走通流程，最后根据经验来写出SKILL：

目标：我不是让你直接跑 UI 测试；我是要教你“如何根据 QA_TEST_PLAN 运行并验证 UI 测试（含修复/回归）”，最终请产出一个可复用的 skill.md。

❗ 注意这个SKILL我们后来优化了，变成了auto-coder，功能一样的，是更简洁规范的版本。输入自动开发，一键开发等关键字触发。

上下文（你需要用到）：

• 输入：QA_TEST_PLAN（描述要测的功能与步骤）
• 输出：QA_TEST_PROGRESS.md（记录你做了什么、结果是什么、下一步是什么） + 最终 skill.md

请先在 Plan Mode 给出一个计划（plan），包含：

• 你需要我补充哪些信息（最少必需项）
• 你要如何从 repo/示例中学习正确的测试写法与运行方式
• 你会如何把 AQ_TEST_PLAN 转成可执行步骤与验收标准
• 你会如何记录到 AQ_TEST_PROGRESS.md
• skill.md 的结构大纲（包含：目的、触发条件、步骤、失败处理、Anti-patterns、示例调用）

然后我们按计划执行：先把这个流程“手动跑通一次”，中途有问题请及时问我。当我们一起跑通流程后，我确认以后再生成对应的skill

2.生成SPEC 初稿的prompt:

我想写一份完整的开发规范文档（DEV_SPEC），用于指导一个 Python 项目的全部开发流程。请帮我生成一个大致的框架和初步内容。

项目是什么

我要做一个模块化的 RAG (Retrieval-Augmented Generation) 系统，同时把它包装成一个

MCP Server（Model Context Protocol），这样 GitHub Copilot、Claude Desktop 等 AI

助手可以直接调用我的知识库进行问答。

通信方式使用 Stdio Transport（本地子进程模式），不做 HTTP 部署。

项目定位与特色

这个项目不仅是一个功能完备的系统，更重要的是它是一个面向学习和面试求职的实战项目：

• "教是最好的学"——我会边做边录视频教学，所以架构设计要清晰、易于讲解
• 配套有技术文档、代码示范和视频讲解
• 每个模块会整理面试高频题和简历撰写建议
• 开箱即用但同时支持深度扩展，可以作为简历项目

我已有的技术方向（需要体现在文档中）

1. RAG 策略：

• 智能分块（语义感知，不是简单定长切分）+ 上下文增强（元数据、图片描述注入 chunk）
• 混合检索：BM25（稀疏）+ Dense Embedding（稠密），用 RRF 融合

• 精排重排：支持 Cross-Encoder 和 LLM Rerank，两段式（粗排→精排） 2. 全链路可插拔架构：LangChain RecursiveCharacterTextSplitter（切分）

• LLM、Embedding、Reranker、VectorStore、Splitter、Evaluator 都要能通过配置切换

• 工厂模式 + 抽象基类 + 配置驱动（settings.yaml）
• 首批实现：Azure OpenAI、OpenAI、Ollama、DeepSeek（LLM）；Chroma（向量库）； 3. 多模态：采用 Image-to-Text 策略（Vision LLM 生成图片描述，缝进 chunk 文本），

不用 CLIP 多模态向量

1. 可观测性：

• 全链路 Trace（Ingestion 链路 + Query 链路），用结构化 JSON Lines 日志
• Streamlit 本地 Dashboard，不依赖 LangSmith 等外部平台
• Dashboard 要有多个页面：系统总览、数据浏览、Ingestion 管理、追踪查看、评估面板等 2. 评估体系：可插拔评估框架，支持 Ragas 和自定义指标（hit_rate、MRR 等） 3. MCP 集成：用 Python 官方 MCP SDK，暴露 tools（query_knowledge_hub、

list_collections、get_document_summary 等）

1. 数据摄取：PDF → Markdown（用 MarkItDown）→ 分块 → LLM 增强（重写、元数据注入、

图片描述）→ 双路 Embedding → Chroma Upsert，支持 SHA256 增量跳过

文档结构要求

请按以下结构来组织这份 DEV_SPEC：

1. 项目概述：设计理念、项目定位
2. 核心特点：每个亮点的简要说明
3. 技术选型：

• RAG 核心流水线设计（Ingestion Pipeline、Retrieval Pipeline，要详细）
• MCP 服务设计
• 可插拔架构设计（接口定义、配置管理）
• 可观测性与 Dashboard 设计

• 多模态图片处理设计 4. 测试方案：TDD 理念，分层测试（单元/集成/E2E），RAG 质量评估 5. 系统架构与模块设计：

• 整体架构图（ASCII art）

• 完整的目录结构树
• 模块职责说明表
• 数据流说明（Ingestion Flow、Query Flow）

• 配置驱动设计示例 6. 项目排期：

• 按阶段划分（A→I），每阶段有明确目的

• 每个子任务要有：修改文件列表、实现的类/函数、验收标准、测试方法
• 约 1 小时一个可验收增量
• 包含进度跟踪表

其他要求

• 语言：中文
• 技术栈：Python，不使用 LlamaIndex/LangChain 框架（仅使用 LangChain 的 splitter）
• 向量库先只实现 Chroma，架构上预留扩展
• 本地优先，轻量级，零外部服务依赖（SQLite 做持久化）
• 测试框架用 pytest

Agent项目实战

先和大家讲一下这个项目的背景。这个项目是我转行大模型，自己做的第一个项目。当时还是小白，一边学Agent的课程，资料，了解什么是大模型，什么是RAG，什么是Agent，然后也看了一些书籍。慢慢开始摸索着做的（大概在25年的5月份左右）。做完这个项目，结合公司的项目（因为公司有一些类似于Hackathon)的项目，做了另外一个项目。两个项目其实难度和实现上差不太多的，我现在看来有点重复，当时可以第一个项目做Agent，第二个项目做RAG, 做两个重复的Agent，收益比较低。在11月份开始面试，也就是用这两个项目写在简历上。现在来看这两个项目其实也不是说多复杂，也会被面试官说简单，不过思路还是我说的那样，一边面试，一边听反馈，一边包装，就用了2个月，12月份，确实拿到了很多offer，包括薪资年包80多万的offer。

今天把这个项目分享出来。首先呢，这个项目我肯定不会再去开发新的内容，功能。我会结合我的经验，告诉大家如何使用它，如何包装它，如何扩展它，如何写简历，以及提供一些面试真题（毕竟这个项目天然的优势就是我直接从对应的面试实战内容就可以搜集到当时面试官围绕这个问题的面试真题）。 如果后面确实有用这个项目去面试，有不懂的面试问题，也可以反馈，我们像RAG项目一样，来根据粉丝朋友的反馈，提供更多的该项目的面试真题解析。

在这个章节除了介绍项目部分，其实还蕴含了一些我的思路，比如设计项目的思路，面试的经验，如何准备自己的项目等等。项目的README的部分，也写了一些关于项目的介绍，技术栈，架构之类的，大家可以看看。

最后提一点，我不太清楚大家会怎么用这个项目，会不会有人拿去面试之类的。这个更新也其实不在更新计划中的（本来打算再专门做个Agent），只是很多人问想要参考，所以我放出来。我目前用了大概3天左右整理，如果后面像rag项目一样，有人拿去面试了，有了面试真题不知道怎么回答，可以再来反馈给我，我来解析在当前章节中。

项目介绍

先说说项目是干啥的。他是我当时在按摩房按摩的时候，我发现这个按摩房，是由一个前台来打电话，处理客户信息，分配按摩的师傅，管理谁去上下钟，处理支付内容。所以我当时就觉得这个工作完全可以由AI来完成啊。有些按摩房他是小程序一个表格，根据空闲日期选择技师。这样很死板，为啥这个按摩房由人工预约，就是人更灵活，能够处理用户喜好，倾向，支付，咨询等各种内容。 当时我在自学大模型，我就想着在大模型的时代，这个东西不就完全可以由AI来完成吗？所以就做了这个项目。

简单介绍这个项目，就是一个智能的按摩房的预约Agent。当用户和他对话，它能够处理预约内容，咨询内容。还能够根据用户的预约历史记录，生成一些回访信息，比如他很久没来了，自动生成一条个性化问候，问他最近要不要按摩。具体功能展示可以看这个视频：

https://www.bilibili.com/video/BV16FRbBEEwD/?spm_id_from=333.1387.homepage.video_card.click&vd_source=144bec9c3f54e465073138bed788be1b

项目设计思路

先来讲述一下我当时的设计思路，我想设计的新特性。

1： 首先项目是多Agent，现在复杂的Agent肯定是多个Agent协作的。所以我设计的系统有4个Agent。前三个是分类机器人，预约机器人，咨询机器人。他们三个要协同工作。

分类机器人只管分类，如果是和按摩房无关的内容就拒绝回答，如果是咨询相关的内容，就把任务给咨询机器人。

预约机器人会问清楚用户的需求，进行多轮对话，收集到信息后，去进行数据库查询，找合适的技师。

咨询机器人回答用户相关咨询问题，会从内部私有文档中找答案。

第四个Agent是用户行为分析Agent，他会根据用户历史预约，分析他的喜好，来的频率，生成回访信息（这块只是大致跑通了）

图 001 · 已恢复原图内容 · 点击放大

2. 集成RAG。 我当时有这个意识，我希望我的Agent项目有RAG的技术栈。所以这个预约机器人，当用户给出了喜好技师（比如喜欢力气大的），会从维护的技师专场表格中匹配。包括咨询机器人就更是RAG了，它内部有一个专有文档，这个文档记录着按摩房的信息，咨询机器人会从这个文档找知识作为回复。 我当时只是把这一套跑通了，没有用专业数据库，只是跑通了RAG的流程。

这块其实现在可以用我们笔记的RAG项目包装，包装成这个Agent使用的RAG是自研的RAG系统，那么工作量和复杂度一下增加了。

3. 用了MCP。 当时MCP 很火，所以我里面使用了MCP，在用户预约成功后，会调用天气的MCP SERVER，查询当地的天气，然后生成回复。比如：您预约了28号xx技师按摩，北京的天气是40度（调用天气mcp server)，请注意防晒。

4. 反思功能。为什么设置用户行为分析Agent，是因为我有这个意识，想让我的Agent有反思功能，根据历史的输入输出来调整行为，生成个性化回复。

来分析一下我当时的设计的优缺点：

优点：做了多Agent，用了MCP（当时火的技术），有工具调用，有RAG的意识，也在尽力设计高级特性（自我反思）。现在的我当然觉得整个设计简单，我后面会讲如何设计得更复杂。但这个项目，不可否认，就是我自己设计，摸索的入门项目，不管会不会被面试官说简单，但毫无争议，他其实就是帮助我入门转行LLM，有去面试的项目。

缺点：

1. 立意可以更复杂：大家在设计项目的时候，一个好的立意其实很重要。比如当时很火的Agent形态是Manus。从设计场景，按摩房预约。 形态：对话Agent。这个立意不能说高明。我之前笔记有提到Anthropic 公司举办的黑客松大赛，大家可以去看看他们前10名的立意，形式，来参考，选择更好的场景和立意。

2. 设计的简单性：太多地方可以设计的更复杂，比如记忆模块，沉淀能力，RAG系统，工具调用等。这个后面再说。不过其实作为一个初学者，自学者，没人指点的情况下，我觉得设计成这样，也无可厚非。毕竟我当时的水平是要先理解啥是LLM的。不过我后面会教大家如何设计得更复杂。

3. 编程范式：这也不能怪当时的我。当时连SKILL都没出。我当时编程的思路就是使用copilot，提一次需求，审核代码。不过当时大家不都这样吗？ 但是大家在设计项目时，强烈建议使用现在vibecoding的方法，harness技巧（这也是面试常考点）。把时间放在建设harness上，而不是放在让AI生成功能上。

项目包装

项目包装其实也可以叫做项目扩展。可包装的点也是你可以扩展的点。一般做任何项目，都建议大家去包装一下。我觉得这是一种技巧，面试不能完全实事求是，得吹。人人都在夸大了说，你不夸大说，哪有这么实诚的人？但是你说能不能不做项目？我的建议不是不能：原因是：包装是提分技巧，你项目做了80分，你包装一下变成100分。你是100分，包装一下成120分。你不可能不做那是0分啊，你只能包装到20分。而且包装的东西，其实讲起来虚，没真实做过，遇到很懂的面试官多少会露馅。你小包装一下，有的地方说不上来，面试官觉得你可能忘了，记不清细节，或者稍微夸大。 假设你没做过，包装太多，被问出来了，面试官觉得你在造假，甚至给你写在面评上，说你虚假简历，性质是不一样的。下面说包装方向：

1. 和RAG项目结合。告诉面试官该项目用的自研RAG系统，接入我们这个笔记中的RAG项目。工作量，复杂度直接增加。

2. 同理，可以包装一个算法项目。比如某个地方简单任务用了自己后训练过的模型，体现算法的能力（这块等我们后面算法项目出来了可以再想具体场景）

3. 记忆系统的设计。这个项目没有记忆系统。长短期记忆如何实现？上下文对话满了如何压缩？这些策略需要设计。再不济你就抄袭我们解析的开源项目（cc,hermes,openclaw)，把内容丢给ai, 让AI给你设计和写代码。但是你不能不设计！

4. 和后端内容联动。这是一个本地的项目，能不能融入一些后端，部署，打包，微服务的东西，面试爱考。

5. 更复杂的架构：现在项目是一个静态的Agent。但是我们解析的开源项目，他是动态生成子Agent的。设计更复杂的架构，比如react范式，让主Agent用工具调用的方式fork出子Agent。（这个也是参考笔记里所有开源项目）

6. SKILL： 现在的Agent需要有SKILL，就像我当时设计项目往MCP上靠。能不能融入一些SKILL技术。

7. Harness: 能否包装一下你的写这个项目的过程，告诉面试官你是用harness技巧写出来的。了解Harness的详细特性，融入到项目中。参考资料

8. Agent 性能评估： 建议一定要做。也是在我真正面试的时候，我才发现你如何评估Agent的性能的时候，是一个必考题。但是在我设计项目的时候（当时还没有面试，没有这个概念）。我的做法就是包装，我结合了参考资料《Agentic Design Pattern》里的评估模块，和美团龙猫的论文，编了一个自己的方法，如何做的评估，每次就不断改进，慢慢面试也就过去了。如果有时间，还是建议大家做。具体的理论方法在 Agent性能评估。

9. Langchain用到的是0.3的版本，可以换成1.0. 我个人其实觉得Langchain这块就是个工具，面试一般问的也不深入。不过基本上问你的项目，如果你用的Langchain，都会考一下Langchain的特性，用了啥版本。现在Langchain也有更新的版本了，如果面试大家觉得有必要，可以改成1.0。其实很容易，让AI给弄就完了。或者你不改，你就说你用的1.0, 了解下1.0特性，一般面试都够了。

配套设施

配套了一些SKILL，和之前RAG系统高度类似。

resume-writer skill：写简历SKILL。我必须说我对写简历不算擅长。不过我保证这个SKILL写出来的简历比我当时用AI写的好。因为我告诉他了模板，突出的点，如何包装。当然希望大家能够生成后自己多修改。我必须提到的一个点是，其实背景越好的朋友，越不需要太写简历，我不是凡尔赛。而是很多时候，不管校招还是社招，凭借学历+大厂，我简历写得很烂，但是还是有面试机会，所以我对简历没怎么改。但是越是你自己比如投出去没反应，没效果，背景差，越是要好好写，根据反馈反复改，甚至是不同岗位用不同简历。

Project-learner skill： 让AI带着你了解这个项目。通过用这个SKILL和他对话和打卡。了解这个项目。

Interview-prep skill：根据这个项目，你的简历，让AI对你模拟面试。

Setup-environment skill: 让AI一键帮你配置好环境。

使用建议

1. 作为学习项目跑着玩。感受一下什么是AI Agent，function call, multi agent, mcp.

2. 拿去面试：时间特别急，没时间做项目的，那你就了解这个项目，跑起来，用上面这两个project-learner skill和interview-prep skill准备好项目，准备好包装技巧和说辞，去面试。 时间长一点的，就按照上面的项目包装的技巧，选择一些自己想做的点，去在这个项目基础上改进，增加复杂性。 然后再去面试

面试真题

这个项目天然有一些面试真题，就是截取自我自己的面经，也就是在面试实战部分。 我汇总了一下我之前面试时，面试官对于这个项目的面试真题，供大家参考。其实这些面试问题，虽然是问的按摩房预约多Agent系统，其实都还挺有通用性的。可以结合自己的项目，想想这些问题，绝对是有收获的。

1. 简单介绍你的项目按摩房智能预约系统，怎么去做的？
2. 介绍一下按摩房预约系统。
3. 按摩房预约系统是你现在在做的吗？
4. 你的项目是如何分块的？
   这里笔记里的回答明确写的是“在按摩房预约系统中，我根据不同场景使用不同分块策略”。
5. 你的 RAG 系统中数据库是如何存储的？
   这一题紧跟在“按摩房智能预约系统”后面，属于对这个项目 RAG 存储方案的追问。
6. 你的 RAG 系统是怎么去评估系统质量的？
7. 为什么用 LangChain 不用 Semantic Kernel？
   这一题出现在“介绍按摩房预约系统”之后，是对这个项目框架选型的追问。
8. 为什么设计成多 Agent？
9. 有没有涉及同时要调多个 Agent，或者多个 Agent 之间还有依赖关系？
10. 端到端的延迟是多少？
    笔记里明确说这是 Agent 从输入到第一个输出的延迟，出现在按摩房预约系统追问链路里。
11. 你评价你的预约系统 Agent 好坏的标准是什么？
12. 你的这个 Agent 项目任务完成得怎么样，有没有去学习/反思能力？
13. 有没有使用一些知识问答的功能？
    也就是问这个项目有没有做 RAG。
14. 你讲到的两个项目，两个项目最大的区别是啥？能否具体结合你的项目讲？
    笔记里回答明确对比了邮箱项目和按摩房预约系统，并说明按摩房适合中心化多 Agent。
15. 多 Agent 系统和单 Agent 系统最大的区别是什么？彼此有什么优势？
    这题本身是通用题，但笔记里要求结合按摩房预约系统回答，所以可以纳入“按摩房项目相关追问”。

项目源码

https://github.com/jerry-ai-dev/smart-appointment-ai-agent

后训练算法项目实战

做这个项目，其实我的一大目的，就是真的希望所有人都能够自己去做一个算法项目。因为我知道算法项目本身天然从知识上就有一定的难度和门槛，同时硬件上也会劝退一些人。普通的开发，没有深度学习训练相关的内容的同学，很多人对算法项目是望而却步的。

我和大家一样，就是开发出身，一点算法基础都没有。所以我深刻知道大家的痛点。所以我从算法学习的第一天，我就知道我的目标，不光是自己做一个算法项目，而且我要记录整个过程如何学习的，心得是什么。包括我记录了非常详细的文档，包括卡如何租，我都是帮大家先走一遍，然后记录，希望大家能站在我的肩膀上学习。都能够做下来一个算法项目。

如果你时间短，你只是想用这个项目去包装简历，那么项目配备面试真题，相关SKILL（就像我们之前的项目一样），相关文档，告诉你如何使用，包装，简历模板，包括讨论群方便讨论。

当然如果你想真的学习，我希望你能学习整个项目完成的技巧和方法。我相信文档记录的非常非常全，我是怎么完成的，学习这些方法，你自己做一遍，或者按照这个方法迁移到你的项目中，你的收获肯定更大。

注意该项目属于开发中，文档会逐步补齐。包括后续面试真题啊，简历如何写啊等等后面都会补。关注我的小红书算法专题，或者看我的git提交，你可以知道进度。

学习方法介绍

1. 首先，算法项目的理论阶段的学习，请看笔记 0基础学算法。 先把前三个阶段理论知识学习，深度学习，训练，SFT和强化学习相关内容，理论知识先学了。
2. 我的小红书（id:不转到大模型不改名），对应的0基础学习算法章节，有整个学习，做项目过程的完整心得介绍。可以当故事看，没多少，你知道我整个过程是怎么来的，中间遇到哪些问题和思考。
3. 先看技术文档。技术文档是整个项目的细节，要理解它。当然更推荐的方法是去学习整个技术文档如何做的，我在文档中也写了很多心得。因为我做项目，都是先写技术文档，逼迫你想清楚细节，是我做项目的方法论，我也希望你能学会这个写文档的方法，文档里有记录。 同时也有技术文档的讲解视频。
4. 在技术文档中，我将代码完工的整个流程分成了7个阶段。每个阶段我会提交一个commit，所以主分支上会有8个commit，初始（只有spec) - stage1 -stage2 -stage 3.. 我是建议你切换到每一个阶段的节点，来看当前阶段完成了什么。每个阶段的阶段性spec写在对应的docs - spec目录下。对应实施细节写在对应docs-plan目录下。（这个是superpowers生成的，可以主要看看specs，plans不太用看）。 每个阶段的完工代码，比如我怎么做的，这个阶段关键目标，你可以跑哪些指令，重点要掌握知识，写在对应的项目的project-log对应的phasex下。这个logs 告诉大家每个阶段的理论重点，需要关注的内容。避免大家无从下手。同时每个阶段配置讲解视频，我会逐步上传，补在这里。

1阶段： 主要是完成了项目的具体框架，串起来整个流程。这个阶段的学习重点：superpowers的方法论，以及llama.cpp本地部署的知识。详细文档见这里。 该阶段讲解视频在这里。

2阶段：完成了Agent的评估。这部分非常重要。即使你不做算法项目，这里也值得学习。Agent评估理论可以先看笔记这里。 掌握理论基础。整个作为实战例子。文档在这里。 讲解视频在这里。

3阶段：这阶段最重要的内容，就是创建了后训练 SFT和DPO的数据集，整个阶段数据集如何制作出来的，整个工作流是这个阶段需要学习的。文档在这里，讲解视频在这里。

4阶段：4阶段是真正训练了阶段，使用了SFT+DPO进行训练。训练使用AutoDL租卡训练，成本小于20元。文档在这里，讲解视频待上传。

5阶段：5阶段是把训练后的模型合并，量化，得到了最终的模型，同时做了模型测评和展示APP。可以说5阶段做完了以后，整个项目的所有的功能都已经做完，剩下的内容是优化，提升数据，写报告了。文档在这里，讲解视频在这里。

6阶段：6阶段进行了进一步模型训练，提升模型的性能。同时分析推理速度的瓶颈，寻找最佳的推理框架配置和参数。文档在这里，其中的每一个阶段性实验结论可以看这里。讲解视频在这里。

项目地址

项目地址在这里

项目使用和简历编写

前言

我们目前文档里有3个项目了，这三个项目也确实是我的全部家底了。我靠着这些项目，以及对应所有的知识，一步步走到现在。我也确实看到有很多同学用笔记里的项目去面试了。我希望有一个专题笔记，视频，聊一聊怎么使用，学习这些项目。同样的项目，每个人使用起来效果可能不一样，我这期内容想讲的是思路，方法，我的经验。请大家在这之上，自己灵活运用。

自己的简历只有自己对自己负责。我提供了思路，参考，还有简历，但是最终还是请自己去把关，修改，根据不同岗位适配，修改。你永远是对自己简历把关的守门人，没有任何人能够代替你做这件事，自己的简历还请多自己多上心。

同时，我这个小节所有介绍的经验，我不给天马行空的包装。因为吹牛谁都会，我只基于我们做过的事情，已有的文档去去聊。在某些地方让你去包装的时候，我也给到你可方案，文档，做法，而不是天马行空地去谈。所以里面会穿插很多文档内的链接，告诉你如果你要这么做，你应该怎么做，学点什么。

SmartAppointment 项目

这个项目是我稍微有点头疼的，这个项目是我自学Agent做的第一个项目，无论是从项目立意上，还是技术上，我觉得都还很青涩。但我必须坦诚的说，这个项目就是当时我丢在简历上去面试的一个项目。我不能说是靠这个项目拿的Offer, 但我当时简历上有两个项目，另一个也是Agent项目（和这个其实差不多），我就是用这两个项目去面试，还拿到了那么多offer。

现在的如果面试，我肯定会写一个更高级的项目，或者即使用这个项目，我也会进行一些包装和改进。后来大家让我开源出这个项目，既然开源了，放在了简历上，我在想如何包装，改进，使用这个项目，能够让他变得更加成熟和有竞争力。

这个项目的好处是：最少搭了一套多Agent对话的框架，多Agent流转，流式响应，RAG系统，MCP，也设计了一个持久化机器人，做沉淀，思想还有的。

缺点是太不成熟：没有做持久化记忆，RAG系统其实只是走了embedding匹配，持久化没做完，没有压缩策略。

如果使用这个项目，我的建议是在这个基础上，进行改进，包装。我给出一些方向和意见。

1. 记忆模块

学习： 参考学习笔记中的开源项目 Claude Code、Harmes、OpenClaw、pi-agent 的记忆模块。包括各种面经中，其实都有对于这个记忆模块的考察，比如虾皮Agent面经，字节暑期实习面经。看这些笔记部分，把知识弄透，看面经知道面试官怎么问题，思考这个项目怎么设计。

思考： 短期记忆保存当前会话、用户意图和预约状态；长期记忆持久化用户历史咨询、预约记录和服务偏好；基于语义相关性召回记忆，并通过保留近期原文、滚动摘要早期对话完成上下文压缩。

写入简历示范：

• 设计分层记忆模块：以 user_id + session_id 隔离会话，短期层保留最近 10 轮消息及预约槽位状态，长期层将咨询摘要、预约事件和带置信度的用户偏好持久化至 SQLite；检索时先按用户与记忆类型过滤，再按“向量相似度 0.6 + 时间衰减 0.3 + 重要度 0.1”混合排序召回 Top-5，上下文达到模型窗口 60% 时将早期消息压缩为滚动摘要，实现跨会话恢复并控制 Token 消耗。

2. RAG 系统

学习： 学习笔记中的 RAG 项目，弄清文档解析、文本切分、向量化、召回、重排序和答案生成等经典流程。这个项目基本就是RAG的基础知识综合起来的，所以RAG笔记章节对应的内容啊，书籍啊，概念，都要学会。

思考： 将咨询 Agent 的内置 FAISS 检索升级为独立 Modular RAG MCP Server：对售后手册、FAQ 和历史咨询建立 BM25 倒排索引与 Dense 向量索引，并行召回后使用 RRF 融合，再由 cross-encoder/ms-marco-MiniLM-L-6-v2 对候选 Query-Chunk 对精排。为 LLM、Embedding、Splitter、VectorStore、Reranker、Evaluator 六类组件定义 Base 接口，通过 Factory + YAML 配置切换实现；使用 TraceContext 记录 query_processing、dense、sparse、fusion、rerank 五阶段耗时、候选数量和排名变化，精排超时或失败时回退至 RRF 结果。

写入简历示范：

• 将咨询 Agent 的知识层升级为模块化 RAG MCP Server：采用 BM25 + Dense Embedding 双路召回与 RRF 融合，并使用 cross-encoder/ms-marco-MiniLM-L-6-v2 精排；基于 Base 接口、Factory 和 YAML 实现 6 类组件可插拔切换，通过五阶段 Query Trace 记录耗时、候选数及排名变化，Rerank 失败时自动回退融合结果。

3. 记忆沉淀机制

学习： 参考社区对 Claude Code 未公开 AutoDream 能力的逆向与复刻方案，理解其基于时间/会话阈值触发，批量回放历史并执行提取、合并、冲突处理、过期清理和长期记忆晋升的机制。同样也是看上面的开源项目和面试题，讲的都有（ Claude Code、Harmes、OpenClaw、pi-agent 的记忆模块）。

思考： 为用户行为分析 Agent 增加后台 Dream Job：用户累计 5 次会话且距上次整理超过 24 小时后触发，按检查点读取新增的咨询、预约、取消和反馈事件；先由 LLM 输出结构化候选记忆，再以 user_id、偏好类型和向量相似度去重，结合出现次数与新近性更新置信度，冲突时保留来源证据并降低旧记忆权重。任务通过分布式锁避免重复执行，记录 dream_run、处理水位和变更日志，失败后可从检查点重试，最终将高置信偏好写回 UserPreference，供推荐和回访读取。

写入简历示范：

• 为用户行为分析 Agent 设计 AutoDream 记忆巩固任务：累计 5 次会话且间隔 24 小时后，按检查点增量回放咨询、预约及反馈事件，经结构化抽取、向量去重、冲突降权和置信度更新后写回 UserPreference；通过任务锁、处理水位及变更日志保证幂等重试，并将高置信画像用于推荐与主动回访。

4. 评估模块

学习：

学习 Agent 测评笔记，并参考笔记中基于该项目实现的评估算法与评测方案。这个笔记我写很全，是整个Agent开发链路上如何做测评，还有很多参考资料，先去看，看完了你应该知道如何做Agent评估。对应实战其实也有，算法项目的二阶段就是做的评估，有数据集，代码，可以参考。通过这些学习，我预期你自己应该知道如何做评估了

思考：

采用 EDD（Evaluation-Driven Development）驱动整个项目生命周期。选型期先定义业务成功标准，在私有评估集上对比模型的任务正确性、协议遵循、延迟和吞吐；开发期分别评估意图路由、RAG Hit Rate/Faithfulness、预约槽位 Exact Match、工具名称与参数正确率，再通过标准 Agent 交接轨迹和端到端任务成功率验证整机。发布前将质量、轨迹、P95 延迟、Token/成本、最大步数和安全红队结果设为并列门禁；上线后以 Logs/Traces/Metrics 记录每次模型、Agent 和工具调用的输入输出、耗时、Token、成本及异常路径，持续监控质量漂移、循环调用、越权和提示注入，并将线上失败样本回灌评估集形成回归闭环。

写入简历示范：

• 采用 EDD 驱动 Agent 全生命周期：基于私有评估集完成模型选型，对路由、RAG、槽位、工具调用及 Agent 交接轨迹开展组件/系统分层评测；将质量、P95 延迟、Token 成本、最大步数与安全测试设为发布门禁，上线后通过 Logs/Traces/Metrics 监控质量漂移、异常工具路径和调用成本，并将失败样本回灌评估集持续回归。

进一步扩展：将评估模块做成独立项目

这部分可以继续做深，单独包装成一个 Agent Evaluation Platform。重点不是再写几个单元测试，而是建立一套可重复运行、能够解释失败原因、可以接入 CI/CD 并延伸到线上监控的 Agent 评估基础设施。它既可以评估当前智能预约系统，也可以通过统一 Case、Trace 和 Scorer 协议复用到其他 Agent 项目。

评估数据集： 在现有 30 个场景测试和 51 条本地模型评估样本基础上，扩展一套 200～300 条业务 Golden Set，按意图路由、预约槽位、RAG 问答、工具调用、多轮状态、多 Agent 交接、安全攻击和异常恢复分层打标。每条 Case 除输入和标准答案外，还保存预期 Agent、允许的工具序列、关键参数、最终状态、禁止行为、最大步数和成本预算。外部数据库、排班和知识库使用固定快照或 Mock，保证同一版本可以重复回放。

三层评分体系：

1. 单步/组件评估： 路由使用分类准确率与 Macro-F1；槽位提取使用字段 Exact Match/F1；RAG 使用 Hit Rate@K、MRR、Faithfulness；工具调用检查工具名称、参数 Schema 和执行结果。
2. 轨迹评估： 将实际 Trace 与标准协作链比较，支持严格顺序、无序、子集和超集匹配，并对“选对 Agent、传对参数、顺序合理、及时终止”分别给分，避免最终答案偶然正确掩盖错误过程。
3. 端到端评估： 统计任务成功率、Pass^k、平均步数、人工介入率、超预算终止率、P95 延迟和单任务 Token/成本。同一配置重复运行 5 次，报告均值、标准差和成功率区间，而不是只展示单次最好成绩。

能用确定性规则判分的任务不使用 LLM Judge；开放式回答先用 Embedding/事实一致性评分，最后才使用 LLM Judge。对 Judge 进行人工样本校准，并通过交换答案顺序、固定 Rubric 和结构化 JSON 输出降低位置偏差、冗长偏差和自我偏好。

全链路追踪与失败归因： 为每次任务生成 trace_id，使用 Langfuse 或 OpenTelemetry GenAI Span 记录模型、Agent 和 Tool 的输入输出、耗时、Token、成本、重试次数和状态变化。根据 Trace 自动将失败归类为路由错误、槽位丢失、错误工具/参数、RAG 无命中、无效循环、上下文污染、过早结束、权限越界和模型异常，并支持从失败节点回放，定位到底是模型、Prompt、工具还是编排逻辑导致问题。

CI/CD 与发布门禁： 每个 Pull Request 自动运行约 50～60 条高风险 Smoke Set，夜间任务运行完整 Golden Set 并对随机性用例重复 5 次；生成新旧版本差异报告并上传评估产物。发布门禁同时检查任务成功率、轨迹得分、工具参数正确率、P95、Token 成本和安全红队结果，任何一项跌破阈值都阻断合并或发布。例如可设置：端到端成功率不低于 90%、轨迹得分不低于 0.85、关键写操作授权率 100%、P95 不高于 3 秒、单任务 Token 不超过预算。

线上监控闭环： 上线后复用同一套 Trace Schema 和指标，在 Dashboard 中监控质量漂移、输入分布变化、工具失败率、循环调用、P95/P99、Token 成本、提示注入和越权行为；新出现的失败请求经脱敏和人工确认后自动加入 Regression Set，形成“线上发现 → 失败归因 → 回灌数据集 → CI 回归 → 灰度发布”的闭环。

独立项目简历示范：

Agent 全生命周期评估与发布平台 | 个人项目 | Agent Evaluation / LLMOps

背景：

Agent 输出具有随机性，单看最终回复无法发现错误工具路径、状态丢失和成本失控；传统单元测试也无法覆盖多轮、多 Agent 与开放式生成任务，因此为智能预约系统建设独立评估基础设施。

目标：

采用 EDD 将评估贯穿模型选型、组件开发、系统回归、发布门禁和线上监控，以统一 Case、Trace、Scorer 协议实现可复现评测、自动失败归因和 CI/CD 质量阻断。

过程：

• 构建 [实测数量] 条分层 Golden Set，覆盖路由、槽位、RAG、Tool Calling、多轮交接和安全场景，并以固定数据快照与 Mock 工具保证任务可重复回放。

• 实现最终结果/轨迹/单步三层 Scorer，组合 Exact Match、Hit Rate@K、Faithfulness、工具参数校验和轨迹部分给分；每个随机性 Case 重复 5 次，报告成功率区间而非单次最优。

• 基于 Langfuse/OpenTelemetry 建立模型—Agent—Tool 全链路 Trace，采集耗时、Token、成本与状态变化，并自动归因路由错误、参数错误、RAG 无命中、循环和过早结束等失败类型。

• 接入 CI/CD：PR 自动执行 [Smoke Case 数] 条高风险用例，Nightly 运行完整评估集；以任务成功率、轨迹得分、P95、Token 成本和安全红队结果作为发布门禁，退化自动阻断合并。

• 建立线上监控与回流机制，将真实失败请求脱敏后沉淀为 Regression Case，支持新旧模型/Prompt/编排版本对比和灰度回滚。

结果：

累计运行 [实测次数] 条 Agent 轨迹，将端到端任务成功率由 [实测值] 提升至 [实测值]，工具参数正确率由 [实测值] 提升至 [实测值]，P95 控制在 [实测值]、单任务成本降低 [实测比例]；CI 共阻断 [实测次数] 次质量退化版本。

技术栈： Python、Pytest、AgentEvals、Ragas、Langfuse/OpenTelemetry、GitHub Actions、Prometheus、Grafana、LLM-as-a-Judge

一组可参考的实验规模是：240 条 Golden Set、60 条 PR Smoke Set、完整用例重复 5 次共 1200 条轨迹。规模可以直接采用，但成功率提升、P95、成本下降和 CI 阻断次数必须来自实际运行，不能把目标阈值写成最终成果。

5. 多 Agent 架构

学习：

学习 Claude Code 等经典 Agent 项目的中心化编排方式与 ReAct 推理范式，理解主管 Agent 如何进行任务判断、能力调用和结果整合。要学习笔记Agent架构，里面很多参考资料。然后就是各种开源Agent项目（ Claude Code、Harmes、OpenClaw、pi-agent ），面经，我都讲了架构，理解Agent架构是什么，怎么做的，你就会包装了。

思考：

将现有任务分类 Agent 升级为中心化主管 Agent，把咨询 Agent、预约 Agent 和用户行为分析 Agent 封装为专业能力；主管 Agent 基于 ReAct 范式判断用户意图、选择并调用对应 Agent，在复杂任务中组合多项能力，并通过共享状态完成上下文传递和任务流转。

写入简历示范：

• 设计中心化多 Agent 编排架构：由主管 Agent 基于 ReAct 范式完成任务规划与能力选择，将知识咨询、预约处理和用户行为分析封装为专业 Agent，并通过统一调用接口与共享状态实现跨 Agent 上下文传递及复杂任务协同。

6. 业务场景

学习： 学习企业智能客服与售后预约系统的典型业务流程，理解知识咨询、故障受理、服务人员匹配、上门时间预约和用户回访等核心环节。

思考： 将原按摩预约场景升级为企业售后服务场景：咨询 Agent 负责回答产品说明、故障排查和服务政策等常见问题；需要人工处理时，由预约 Agent 根据服务类型、用户需求、工程师技能和空闲时间完成匹配与上门预约；用户行为分析 Agent 则负责沉淀服务偏好并进行主动回访。

写入简历示范：

• 面向企业售后场景设计智能客服与服务预约系统：通过咨询 Agent 处理产品问答、故障排查及服务政策咨询，并由预约 Agent 结合服务类型、工程师技能与空闲时间完成智能匹配和上门预约，配合用户行为分析 Agent 实现个性化服务与主动回访。

7. 权限机制

学习： 学习 Claude Code 的四层权限机制，理解 Agent 在能力边界、资源访问、操作确认和安全审计方面的分层控制方式。

思考： 根据企业售后任务的风险等级设计分层权限：知识查询等只读操作可直接执行；创建预约前需由用户确认关键信息；修改、取消预约及发送回访消息等有副作用操作必须二次确认；用户隐私和跨用户数据实行身份校验、最小权限与数据隔离。同时通过工具白名单、参数校验、幂等控制和操作日志，防止越权调用、重复执行及敏感信息泄露。

写入简历示范：

• 设计健全的安全机制，按操作风险划分只读直通、关键参数确认和高风险操作二次授权，对用户数据实施身份校验与最小权限隔离；结合工具白名单、参数校验、幂等控制及审计日志，降低 Agent 越权调用、重复执行和隐私泄露风险。

8. 本地模型

学习： 学习 Post-training-slot-extractor 算法项目，掌握本地小模型的数据构造、后训练、量化压缩、推理评估和服务化部署流程。

思考： 将预约 Agent 中高频、低复杂度且输出格式固定的槽位提取任务拆分出来，由本地 Qwen3 小模型负责从多轮对话中提取预约时间、服务时长、用户偏好和指定工程师，并判断是否需要调用查询工具；通过 SFT 与 DPO 提升结构化输出和工具调用的稳定性，将模型转换为 GGUF 并进行量化，使用 llama.cpp 部署为 OpenAI 兼容的本地 CPU 推理服务。复杂咨询与开放式推理仍交给远端大模型，形成大小模型协同架构。

写入简历示范：

• 构建预约槽位提取本地模型评测链路，在 51 条冻结评估集上对比 Qwen3 0.6B/1.7B/4B；选取 1.7B 作为质量与性能平衡方案，相比 4B 任务正确性仅下降 2.9 个百分点，平均时延降低 34.4%、吞吐提升 32.9%，并设计 SFT/DPO 与 GGUF 量化路线进一步优化协议遵循和 CPU 推理性能。

其实还可以写高可用相关的内容，就是当Agent失败如何重试，优雅回退。我先占个位这部分内容我补了笔记再写。 同时你还可以说，比如写多模态啊等等，但是我的思想是不能天马行空。多模态当然是包装的思路，但是我们笔记暂时没有，我只给你可以行的，你可以照着去学习，思考的方向。

9. 整体项目简历范文

企业售后智能客服与预约 Agent 系统 | 个人项目 | Agent / LLM 应用开发

背景：

针对企业售后场景中产品咨询、故障排查、工程师匹配、上门预约及用户回访依赖人工处理，容易出现信息重复收集、业务知识更新不及时和服务推荐不稳定等问题，设计智能客服与预约 Agent 系统。

目标：

构建以主管 Agent 为统一入口的多 Agent 服务链路，串联知识咨询、预约处理、用户记忆和行为分析；采用 EDD 从模型选型、组件开发、发布门禁到线上监控持续驱动迭代，并通过本地小模型承接高频结构化任务。

过程：

• 设计中心化多 Agent 编排架构，由主管 Agent 基于 ReAct 范式进行任务规划与能力选择，将咨询、预约和用户行为分析 Agent 封装为专业工具，通过共享状态实现跨 Agent 上下文传递与任务协同。

• 构建预约状态管理与工程师匹配流程，从多轮对话提取时间、时长及服务偏好，并结合技能与排班推荐可用人员。

• 将咨询 Agent 接入模块化 RAG MCP 知识层，采用 BM25 + Dense 双路召回、RRF 融合及 ms-marco-MiniLM-L-6-v2 精排，兼顾专有名词与语义匹配。

• 以 Base 接口、Factory 和 YAML 实现 LLM/Embedding/Splitter/VectorStore/Reranker/Evaluator 六类组件可插拔；Query Trace 覆盖检索五阶段，记录耗时、候选数和排名变化，精排失败自动回退 RRF 结果。

• 设计分层记忆：以 user/session 隔离最近 10 轮消息与预约槽位，长期持久化咨询摘要、预约事件及偏好置信度；采用“向量相似度 0.6 + 时间衰减 0.3 + 重要度 0.1”召回 Top-5，窗口占用达 60% 时触发滚动摘要。

• 为用户行为分析 Agent 实现 AutoDream 后台任务：累计 5 次会话且间隔 24 小时后增量回放行为事件，经结构化抽取、向量去重、冲突降权及置信度更新写回长期偏好，并以任务锁、检查点和变更日志保证幂等重试。

• 采用 EDD 驱动模型选型与 Agent 开发：以私有评估集量化模型正确性/延迟，对路由、RAG、槽位、工具调用及 Agent 交接轨迹开展组件级与端到端回归。

• 建立质量、P95 延迟、Token 成本、最大步数和安全红队发布门禁；通过 Logs/Traces/Metrics 追踪模型、Agent、工具调用及异常路径，将线上失败样本回灌评估集形成闭环。

• 构建预约槽位提取本地模型评测链路，在 51 条冻结样本上对比 Qwen3 0.6B/1.7B/4B；1.7B 相比 4B 正确性仅低 2.9 个百分点，平均时延降低 34.4%、吞吐提升 32.9%，据此确定质量—性能平衡方案。

结果：

完成 Web/API/Agents/Services/DB 五层工程架构，落地 3 类核心业务 Agent、16 个 API 接口及 30 个场景测试；为本地模型建立 51 条冻结评估集，完成 Qwen3 0.6B/1.7B/4B 与远端模型的质量、延迟和吞吐对比。分层记忆、AutoDream、RAG 重排序、权限机制及模型微调属于增强方案，需在实现和测试完成后再作为已落地成果写入正式简历。

技术栈：

Multi-Agent、ReAct、LangChain、RAG、FAISS、Embedding、FastAPI、AsyncGenerator、SQLAlchemy、SQLite、SFT、DPO、Qwen3、GGUF、llama.cpp

后训练项目

微调项目，我觉得特别值得一做。在我们解析的2026年面试官最关注的6个AI方向里面，有两个方向，一个是本地模型的对比，效果评估。另一个是模型微调（SFT+强化学习）。

除此之外，这个项目还带一点本地推理部署的内容。

对于开发的同学来说，能够具备这样的经历，相比其他候选人，无疑是会让你脱颖而出的一个点。 这个项目，无论是作为一个加分项，放在你的Agent项目中，还是单独成为一个小的算法项目，我觉得都可以。这个项目的目标和明显，提升小模型在资源受限上的可用性，同时效果也很容易验证，因为我们制定了专门的数据集去评估，对比基模和训练后的模型，作为一个简历项目来写，是非常清晰的。

整体项目简历范文

面向预约 Agent 的本地小模型后训练与部署 | 个人项目 | LLM 算法 / 推理优化

背景： 智能预约 Agent 需要从多轮对话和工具结果中抽取时间、时长、用户偏好等槽位，并在信息完整时决定是否调用查询工具。远端大模型虽效果稳定，但存在网络依赖、数据隐私、调用成本和响应延迟问题；通用本地小模型则容易出现 JSON 协议损坏、字段幻觉、状态继承错误和 Tool Calling 决策不稳定。

目标： 将高频、边界明确的预约槽位抽取与工具调用决策迁移至本地小模型，通过“评估集先行 → 失败难例驱动数据 → SFT → DPO → 量化部署”的路径，在受限 CPU 资源下提升结构化输出稳定性，并以统一评估集验证质量、速度和资源开销。

过程：

• 建立 51 条冻结私有评估集，覆盖 Final/Tool Call、多轮状态继承、用户确认、无关输入与幻觉陷阱；以协议遵循、任务正确性、有效通过率、P95、TTFT 和吞吐作为统一选型与回归指标。

• 在相同 Prompt、Schema 和硬件口径下对比 Qwen3 0.6B/1.7B/4B 与远端强模型；1.7B 相比 4B 任务正确性仅低 2.9 个百分点，但平均时延降低 34.4%、吞吐提升 32.9%，据此作为质量—性能平衡候选。

• 构建“业务规格 → 强模型生成 Raw → 程序质量门禁 → SFT/DPO 派生”数据流水线，生成 500 条 Raw 数据及 450/50 条 SFT、135/15 条 DPO 训练/验证数据，覆盖 5 类核心任务并与评估集保持零重叠。

• 基于 LLaMA-Factory 搭建 LoRA/QLoRA SFT 训练，采用原生 Chat Template、Response-only Loss 与多任务混训，重点提升严格 JSON、槽位继承、相对时间归一化和 Tool Calling 参数准确性。

• 在 SFT 权重上设计 DPO 偏好对齐，将标准答案作为 Chosen，并通过规则构造格式合法但包含动作选择、字段值、确认状态、幻觉或约束违反的 Rejected，针对性强化业务边界与拒绝脑补能力。

• 设计 LoRA 合并、GGUF 转换与 Q4_K_M 量化流程，使用 llama.cpp 暴露 OpenAI 兼容的本地 CPU 服务；以同一冻结集比较 Base/SFT/DPO/量化模型，量化回退超阈值时切换 Q5_K_M/Q8_0。

结果：

完成 4 类模型的统一基线评估与训练数据闭环，冻结 51 条评估样本并构建 500 条 Raw、500 条 SFT、150 条 DPO 数据，训练/评估重叠为 0；本地基线实验确定 Qwen3-1.7B 为优先质量—性能候选。完成训练后应补充：协议遵循率 [Base → SFT → DPO]、任务正确性 [Base → SFT → DPO]、有效通过率 [X/51 → Y/51]，以及量化后模型大小、P95、TTFT 和吞吐，不能使用未运行的目标值代替实验结果。

技术栈：

Qwen3、LLaMA-Factory、LoRA/QLoRA、SFT、DPO、ShareGPT、Tool Calling、Structured Output、GGUF、llama.cpp、Sentence-Transformers、Python

训练完成后可替换的量化条款

• 基于 LoRA/QLoRA 对 Qwen3-1.7B 开展 SFT，并在 SFT 权重上使用 150 条偏好对进行 DPO；在 51 条冻结评估集上，协议遵循率由 [Base] 提升至 [SFT] / [DPO]，任务正确性由 [Base] 提升至 [SFT] / [DPO]，Tool Call 有效通过数由 [X/15] 提升至 [Y/15]。

• 将训练权重合并并转换为 GGUF，通过 Q4_K_M 量化与 llama.cpp 完成本地 CPU 部署；模型体积由 [实测值] GB 压缩至 [实测值] GB，P95 延迟由 [实测值] s 降至 [实测值] s、吞吐提升 [实测比例]，任务正确性回退控制在 [实测百分点] 内。

这个项目，可以扩展的部分。比如你可以去修改训练算法，用更复杂的训练方法，比如Agentic RL，或者用更复杂的训练框架，手写框架，修改参数，训练更复杂的模型等等，都是这个项目的可以扩展的方向。

但是我不给更多建议，因为我相信大部分人都是开发或者产品，不是算法出身。我一直把这个项目，算法的学习路线作为进阶项。你先学完前面的Agent,RAG项目再学算法。你能学到这里，把这个项目学完，其实对于入行大模型来说早就够了，这个项目吃透，对于那些开发岗，也是够了。

再往深入了做，其实是在算法，推理部署方向岗位上的进阶了，看笔记的大部分同学可能也没做到那一步。 如果你能够把上面的内容都吸收透，对于工作5年以内，找个年薪100w以内的工作，完全没有问题。我说这个话很有把握，因为我一直都在面试，我自己对行情有了解，上面的内容就是我大概自学大概一年多的所有经验和项目，你再配合笔记，把理论部分弄透。5年工作经验，P7左右，找个100W的工作绝对没问题，校招生，大厂大模型开发岗，全栈岗SSP绝对没问题，就上面的项目+资料+面经消化透，就够了。

RAG 项目

这个RAG项目，我还是相对比较放心的。整体就是符合企业RAG的流程，BM25+语义检索 + 重排序，以及评估方法。这个项目也是有很多人拿过去面试，我们也收集了很多面试真题 使用这个项目，我的个人建议是： 按照文档，视频，代码，先理解消化这个项目，这个项目的各个流程，都是重点。MCP, 里面的各种RAG技术都是RAG里面最经典的方法，必须要会的。 做完这个其实也满足了我们在项目部分讲的 完成一个生产级别的RAG项目的前两个阶段。

完成基础学习后，这一部分建议你必做：

准备至少 100 份真实 PDF 文件，完整运行一次数据摄取、检索、重排和回答生成流程。PDF 不能只选排版规整的文档，需要覆盖普通文本、双栏排版、页眉页脚、侧边栏、表格、图片和扫描件等类型。为这些文档建立清单，记录文档类型、页数、解析是否成功、生成的 Chunk 数量和异常情况。

在这些文档上人工准备一套评估数据集。建议至少准备 200 个问题，并为每个问题标注标准答案、证据文档、页码和对应 Chunk；问题需要覆盖事实查询、跨段归纳、专有名词、表格数据、图片信息、相似文档区分以及无答案问题。通过系统中的 Ragas 指标评估 Faithfulness、Answer Relevancy、Context Precision 和 Context Recall，同时用 Hit Rate@5、MRR 等指标判断检索是否真正找到了正确证据。还要记录 P50/P95 延迟、Rerank 耗时和 Token 成本，不能只看回答效果。

评估时分别运行 Dense Only、BM25 Only、BM25 + Dense + RRF、Hybrid + Cross-Encoder Rerank 四组实验，使用相同数据集进行消融对比。Cross-Encoder 可以使用 cross-encoder/ms-marco-MiniLM-L-6-v2。通过 Query Trace 查看 Dense/Sparse 召回结果、RRF 融合排名、Rerank 前后排名变化和各阶段耗时，从而判断效果提升究竟来自哪一个环节，而不是只凭最终回答猜测。

在实际使用过程中，一定要记录具体问题和解决过程。例如，部分 PDF 的侧边栏、目录、页眉页脚或免责声明会被重复拼接进正文。这些高频噪声可能获得较高的 BM25 分数，也会破坏语义分块，导致错误内容进入 Top-K。可以根据文本块坐标过滤页面边缘区域，统计跨页重复内容并删除高频模板块，再按照标题层级重新分块。修改后重新运行冻结评估集，对比噪声率、Hit Rate@5、MRR、Faithfulness 和 P95 延迟，确认优化是否有效以及是否引入新的副作用。

类似的问题还包括表格断行、扫描件 OCR 丢字、图片 Caption 不准确、Chunk 过大或过小、同名实体混淆、Rerank 超时等。每个问题都建议按照“问题现象 → Trace 证据 → 根因 → 修改方案 → 修改前指标 → 修改后指标 → 副作用”的格式记录，并把发现的 Bad Case 回灌到评估集中，作为后续版本固定的回归用例。只有真正跑过这一遍，你才能在面试中讲清楚系统哪里出过问题、为什么会出问题，以及你如何用评估数据证明修改是有效的。

写入简历示范：

• 基于 100+ 份真实 PDF 构建 200+ 条 Golden Set，覆盖双栏、侧边栏、表格、图片及扫描件；使用 Hit Rate@5、MRR 与 Ragas Faithfulness/Context Recall 评估摄取—检索—生成链路，通过 Trace 定位跨页侧栏噪声，并采用坐标过滤、重复块去除和标题感知分块修复，使 Hit Rate@5 从 [实测值] 提升至 [实测值]、Faithfulness 提升 [实测百分点]，同时将 P95 延迟控制在 [实测值] 内。

这里的指标必须替换成你实际运行得到的数据，不能直接编造。例如，如果实测为 Hit Rate@5 从 76% 提升到 89%、Faithfulness 从 0.78 提升到 0.90，同时 P95 从 1.8 秒增加到 2.1 秒，就应该同时说明质量收益和 Rerank 带来的延迟代价。面试官更看重你是否理解取舍，而不是只展示最好看的数字。

完成上面的基础实测后，还可以继续选择下面三个方向进行增强。建议根据自己的时间和目标岗位选择，不要求全部实现。下面的地方，是有余力可以做的：

查询改写

真实用户的 Query 往往很短，包含口语、省略、指代或错误术语，直接做一次向量检索容易漏掉正确文档。可以在检索前增加可插拔的 Query Rewrite 模块，并针对不同问题采用不同策略：普通问题进行术语归一化和指代消解；信息较少的问题使用 Multi-Query 生成多个检索表达；抽象问题使用 HyDE 生成假设答案后检索；复杂问题拆成多个子问题分别召回，最后通过 RRF 合并结果。为避免改写产生语义漂移，需要保留原始 Query 作为一路召回，并设置最大改写数量、超时和失败回退。

不要只验证“改写后的句子看起来更完整”，而要在同一套 Golden Set 上对比 Original Query、Multi-Query、HyDE 和 Query Decomposition 的 Hit Rate@5、MRR、Context Recall、P95 延迟与 Token 成本，并按照短查询、专有名词、指代、多跳问题等标签分别统计。最终根据问题类型进行策略路由，而不是让所有 Query 都经过成本最高的改写方式。

写入简历示范：

• 设计可插拔 Query Rewrite 模块，针对短查询、指代和多跳问题分别采用术语归一化、Multi-Query、HyDE 与问题分解策略，并保留原始 Query 参与 RRF 融合以抑制语义漂移；基于 Golden Set 完成消融评估，使复杂问题 Hit Rate@5 从 [实测值] 提升至 [实测值]，Context Recall 提升 [实测百分点]，P95 延迟增加控制在 [实测值] 内。

Agentic RAG

传统 RAG 的流程是固定的“一次检索 → 一次生成”，遇到信息不足、跨文档问题或首次召回失败时不会主动调整。可以把检索能力封装为 Agent 工具，由 LLM 基于 ReAct 方式执行“分析问题 → 选择知识库/检索策略 → 调用工具 → 判断证据是否充分 → 改写 Query 或继续检索 → 基于证据回答”。工具可以包含混合检索、按元数据过滤、文档摘要、相邻 Chunk 扩展和指定文档查询等能力。

Agentic RAG 的重点不是让模型无限自主搜索，而是限制行动空间。应设置最大检索轮数、Token/成本预算、终止条件和引用校验；证据不足时明确拒答，工具异常时回退普通 Hybrid RAG。评估时除了最终 Faithfulness 和任务成功率，还要评估工具选择正确率、参数正确率、平均检索步数、无效循环率、Token 成本和 P95 延迟，并通过 Trace 检查 Agent 是否走了合理路径。

写入简历示范：

• 构建基于 ReAct 的 Agentic RAG，将混合检索、元数据过滤、文档摘要及相邻 Chunk 扩展封装为工具，由 Agent 根据证据充分性动态执行查询改写与多轮检索；通过最大步数、Token 预算、引用校验和 Hybrid RAG 回退限制失控路径，使多跳问题成功率从 [实测值] 提升至 [实测值]，无效工具调用率控制在 [实测值]。

Graph RAG

Graph RAG 更适合实体关系密集、需要跨文档关联和全局归纳的知识库，例如组织关系、供应链、科研文献、法律案件或设备故障链路。实现时需要从 Chunk 中抽取实体、关系和来源证据，完成实体消歧后写入图数据库；再进行社区发现并生成分层摘要。查询阶段可根据问题选择 Local Search，在实体邻域中查找具体关系，也可以使用 Global Search，基于社区摘要回答跨文档的整体性问题；最终将图检索结果与原有 BM25/Dense 结果融合。

这一方向投入较高，需要处理实体抽取质量、同名消歧、关系更新、图谱增量构建和社区摘要成本。很多企业的普通 FAQ 或制度问答使用 Hybrid RAG 已经足够，引入 Graph RAG 不一定有收益。因此应先从现有 Golden Set 中筛选真正需要多跳关系推理的子集，只在该子集上比较 Hybrid RAG 与 Graph RAG 的任务成功率、证据覆盖率、构建成本和查询延迟；如果收益不明显，应保留为技术预研而不是强行上线。

写入简历示范：

• 面向跨文档关系推理场景预研 Graph RAG，从文档中抽取实体—关系—证据三元组，经实体消歧、社区发现和分层摘要构建知识图谱，并组合 Local/Global Search 与向量检索；在 [多跳样本数] 条关系型问题上将任务成功率由 [实测值] 提升至 [实测值]，同时评估图构建成本与查询延迟，据此限定其仅用于高关联度知识场景。

整体项目简历范文

现有能力版（可直接使用）

模块化企业知识检索与 Agent RAG 系统 | 个人项目 | RAG / LLM 应用开发

背景：

针对企业知识库中文档格式复杂、关键词搜索无法理解语义、检索链路难以调试，以及不同模型和存储后端切换成本高的问题，设计模块化 RAG MCP Server，为 AI Agent 提供可追溯的私有知识检索能力。

目标：

构建覆盖文档摄取、混合检索、精排、评估和可观测性的通用 RAG 框架；通过标准 MCP 工具解耦 Agent 与知识层，并以可插拔接口适配不同模型、向量库和部署环境。

过程：

• 设计 LLM、Embedding、Splitter、VectorStore、Reranker、Evaluator 六类 Base 接口，结合 Factory 与 YAML 实现配置化切换，支持 OpenAI、Azure、Ollama、DeepSeek 四类 LLM Provider。

• 构建 Load→Split→Transform→Embed→Upsert 五阶段摄取流水线，采用 MarkItDown、递归分块及 LLM 元数据增强处理 PDF，并通过 SHA256 与内容哈希保证增量摄取和幂等写入。

• 实现 BM25 与 Dense Embedding 并行召回，通过 RRF 融合兼顾专有名词和语义匹配；Reranker 支持 None、Cross-Encoder、LLM 三种模式，精排异常时自动回退融合结果。

• 基于 MCP 标准暴露 query_knowledge_hub、list_collections、get_document_summary 三个工具，返回结构化引用及图像内容，支持 Copilot、Claude 等 Agent 调用私有知识库。

• 构建 Ingestion/Query 双链路 Trace，覆盖摄取与查询共 10 个核心阶段，记录耗时、候选数、分数及 Rerank 排名变化，并通过 6 页面 Streamlit Dashboard 定位检索 Bad Case。

• 采用 TDD 与分层测试体系验证模块边界，累计 1364 个测试函数覆盖 Unit、Integration、E2E；通过配置外置、Provider 工厂和 Local-First 存储提高项目复现与扩展能力。

结果：

完成 6 类可插拔组件、4 类 LLM Provider、3 个 MCP 工具、10 阶段双链路追踪和 6 页面管理平台，并以 1364 个自动化测试函数保障核心链路回归。当前结果体现的是工程完整度；检索准确率、Faithfulness 和 P95 延迟需通过下述真实 PDF 实验补充后再写入正式简历。

技术栈：

Python、RAG、BM25、Dense Retrieval、RRF、Cross-Encoder、ChromaDB、MCP、Ragas、Streamlit、Factory Pattern、TDD

增强版条款（完成实测后择优替换）

下面内容对应项目尚未完整验证的增强方向。完成代码、实验和指标记录后，从中选择 1～2 条替换现有简历条款，不建议全部堆入一份简历。

• 基于 100+ 份复杂 PDF 构建 200+ 条 Golden Set，以 Hit Rate@5、MRR 与 Ragas Faithfulness/Context Recall 评估摄取—检索—生成链路；通过 Trace 定位侧栏重复噪声，采用坐标过滤、重复块去除和标题感知分块，使 Hit Rate@5 从 [实测值] 提升至 [实测值]、Faithfulness 提升 [实测百分点]。

• 构建 Query Rewrite 策略路由，针对短查询、指代和多跳问题选择 Multi-Query、HyDE 或问题分解，并保留原始 Query 参与 RRF 融合；经消融实验使复杂问题 Context Recall 提升 [实测百分点]，P95 延迟增量控制在 [实测值]。

• 构建基于 ReAct 的 Agentic RAG，将混合检索、元数据过滤、摘要和相邻 Chunk 扩展封装为工具，由 Agent 按证据充分性动态改写并继续检索；通过最大步数、Token 预算和普通 Hybrid RAG 回退，使多跳任务成功率提升 [实测百分点]、无效工具调用率降至 [实测值]。

• 面向高关联知识场景预研 Graph RAG，经实体关系抽取、消歧、社区发现与分层摘要实现 Local/Global Search；在 [样本数] 条多跳问题上将任务成功率从 [实测值] 提升至 [实测值]，并根据构图成本和查询延迟限定使用边界。

简历示范

好了，了解了上述的内容，其实我们只要根据自己的情况，去组装就好了。 我们按照简历上写两个项目为例：

1. 如果你的 Agent 项目内容较多（例如评估做得深入，或记忆模块做得完整）总之就是有很多地方可以讲，可以把 Agent 单独写成一个项目，也不用加RAG和算法项目了，一个项目纯讲Agent，再加入一个 RAG 项目，算法项目都没用上。

图 002 · 已恢复原图内容 · 点击放大

1. 如果你想突出算法能力，可以把算法单独作为一个项目，把 Agent 和 RAG 合并成另一个项目。

图 003 · 已恢复原图内容 · 点击放大

1. 如果你的 Agent 项目相对偏浅，可以把算法项目作为一个小点融入 Agent 项目中，增强竞争力，补充你Agent做的不够，再把 RAG 作为另一个项目。

图 004 · 已恢复原图内容 · 点击放大

1. 如果你已经有后端项目经验，可以先写一个后端项目，再按岗位需要把这三个项目进行组合；例如三项目合一为一个 Agent 项目，并将其中的 RAG 和算法作为小点呈现，面试时再按问题深入展开。

图 005 · 已恢复原图内容 · 点击放大

当然其实还有非常多的思路和方法，比如在Agent项目中加一点后端的内容，Redis技术。比如算法项目做的更加深入，或者增加一些推理部署的内容，或者多模态的内容，或者包装一些上线的内容。 我想给大家展示的是这个思路，同时我并没有天马行空，包装很容易，我只在我们做过的项目，已有的知识上给到包装，给到一个可行的路线，你知道如何做，如何保证，包装的内容去哪里学。因为我觉得只有是你真正做过的，学过的，才是你的。如果你切实际包装一个天马行空的项目，那也许通过的了简历筛选，但终究一问就露馅，通过不了面试。

简历资源

上面提到的4个简历Pdf版本，在这里获取：

我用夸克网盘给你分享了「简历示范.zip」，点击链接或复制整段内容，打开「夸克APP」即可获取。 /\~c0fa3a2GfU\~:/ 链接：https://pan.quark.cn/s/5d7fce8e84a5

视频讲解

LLM模型结构

LLM模型训练

（模型是怎么训练出来的，其实暂时没有在面试中反映出来，没有面试问这个问题。不过我觉得这是自己需要理解的，通过这个知识点，你可以对大模型有一个更好的认识，把这个微调，强化学习，预训练分别在哪个阶段串起来，这个知识点我给大家推荐这个链接，他讲得很好，而且还贴心地准备了一些小工具，比如你直观去看大模型分词效果的网站，特别好

https://baijiahao.baidu.com/s?id=1826882165583568205&wfr=spider&for=）

1.1LLM是如何被训练出来的

1. 构建基础模型（构建通用大模型）

• 预训练（Pre-training，非监督）

• 使用海量的通用、未标注数据（如网页、书籍、代码等）。

• 目标是让模型具备语言理解、推理、世界知识等通用能力。

• 微调（SFT）

• 使用指令-响应数据、任务特定数据、人工标注数据。

• 让模型学会遵循指令，更贴近实际应用。

• 对齐（如 RLHF、DPO）

• 基于人类偏好数据，通过奖励模型或偏好分数进行优化。

• 目的是让模型输出更符合人类价值观和安全要求。

2. 微调基础模型（提升指定场景性能）

• 从通用 LLM/SLM 出发，模型已经具备：

• 语言能力、推理能力、世界知识、聊天、指令跟随、代码能力等。

• 再次进行：

• 微调（SFT）：针对特定领域或任务的数据。

• 对齐（RLHF、DPO）：确保输出符合特定用户或行业需求。
• 最终得到针对特定场景优化的模型。

1.2 Function calling是如何被训练出来的

Function calling是通过在模型训练的预训练阶段使用自监督学习，在微调阶段使用SFT技术，以及在对齐阶段使用RLHF技术来使模型具有能够理解用户意图并生成函数结构化的函数调用请求的能力。

具体来讲：

预训练阶段的自监督学习使得模型能够理解自然语言。

微调阶段的SFT技术使用标注数据让模型理解何时该调用函数，调用函数的格式是什么。

对齐阶段使用RLHF，使用人类的反馈来优化调用结果，使模型的调用更符合人类的习惯。

2. Transformer

(这一块其实不管在任何书籍，课程或者你去上机构给你的学习路线上，Transformer都占比很大。但是其实我在面试的时候问的确实不多。但还是建议学习一些，特别是想要面一些有点涉及算法的岗位，比如算法工程的同学。另外虽然面试官没有直接问这些问题，但是这些内容时不时在面试中会被提到。比如问你推理加速，提到KV-CACHE的时候，你如果连Transformer的QKV都不知道，肯定KV-CACHE也弄不懂。 比如问你为啥这几年LLM发展这么强大，你就可以提到Transformer的并行计算和长距离依赖 来谈谈为啥Transformer出来之后AI发展如此迅速。 总之这节虽然不会直接考到，但是建议理解学习的）

2.1 简单介绍Transformer架构

Transformer是最早在2017年在论文《Attention is All You Need》提出的深度学习架构，现在的大语言模型，比如GPT系列，Claude等都是基于Transformer架构设计的。

Transformer的架构由编码器和解码器组成。它们的基础模块主要由输入嵌入，自注意力机制，多头注意力机制，前馈神经网络，残差连接与层归一化组成。

注意力机制是Transformer最重要的设计，相比于RNN，解决了并行计算和长距离依赖 两方面的问题，有更高效的并行计算能力和语义理解能力。是AI领域的一次重大突破。

2.2 编码器和解码器的区别

Transformer的编码器和解码器，都是基于注意力机制的序列建模架构。

编码器主要是用来处理输入序列，提取上下文信息并生成表示的。 解码器主要是用来生成输出序列。（用途层面）

编码器通常处理整个输入序列，因此可以并行计算所有的位置表示，因此它的并行性高，推理速度更快。 解码器大多使用自回归的方式，每一步生成一个Token, 无法并行生成多个Token，因此在推理时速度较慢。

关于编解码器更详细的资料，可以参考：编解码器。

2.3 Transformer vs RNN

Transformer相比RNN，主要在并行计算方面和长距离依赖两方面，具有高效的并行计算能力和语义理解能力。

具体来讲：

1.因为RNN处理是逐步进行的，每一步依赖前一步的输出状态，无法并行，训练速度慢。而Transformer基于自注意力机制，可以同时处理整个序列，充分利用GPU的能力，训练速度大幅提升。

2.RNN网络中，容易出现梯度消失或者爆炸，捕捉长距离依赖困难。而Transformer通过注意力机制，任意两个位置可以直接建立联系，长距离依赖问题得到了显著的缓解。

2.4.大模型分词器是什么？

因为大语言模型无法直接理解自然语言，我们需要先把他转成数字输入。分词器就是将自然语言拆分成更小的单位（我们把它叫做token），并将每一个token映射成一个唯一ID。为后续的词嵌入做准备，从而成为连接起人类语言和模型语言的桥梁。

2.5.Embedding 是什么？

因为大语言模型无法直接理解自然语言，我们需要先把他转成数字输入。Transformer的做法是通过对自然语言进行分词 + embedding得到最终的输入的。具体来讲，embedding就是将离散的输入：包括分词的id和位置id，分别通过词编码和位置编码转换成稠密向量，最后组合成模型输入的过程。

2.6 注意力机制

2.6.1 简单介绍注意力机制

（概念简述）注意力机制是在处理一个词时，模型可以关注输入序列的其他词，并根据它们的重要性加权融合信息。

（计算公式简述）它的做法是对每一个词生成3个向量，Q, K, V。Q代表当前词要关注什么， K代表当前词是什么 ， V代表当前词能提供什么信息。 使用Q,K点积计算相似度，使用Softmax得到注意力权重，最后对V进行加权，得到Attention矩阵。

（好处，总结）这个向量可以捕捉词和词之间的长距离依赖，信息融合灵活，不依赖固定窗口或顺序，且并行计算的效率相比RNN更高。

2.6.2 简单介绍多头注意力机制

多头注意力机制是Transformer架构的核心组件，主要用于增强模型在处理序列数据的表达能力。它的核心思想是：通过多个注意力头并行计算不同的注意力表示，从而捕捉输入序列和不同位置之间的关系。

它的主要过程是，生成多组Q,K,V， 对每一组 Q, K, V得到的Attention矩阵进行拼接，得到最终的一个结果。

使用多头注意力机制，可以让模型在不同的子空间中学习不同的关注模式，避免单一注意力机制只关注某一种关系的问题，提升模型捕捉全局信息的能力。

2.6.3 多头注意力机制为何可以增强模型？

1. 有利于捕捉长距离依赖。传统的模型比如RNN在处理长文本时容易遗忘前面的信息，而注意力机制可以直接关注任意位置的词，无论距离多远。
2. 动态信息融合。每个词的表示不再是固定的了，而是根据上下文动态生成，从而得到不同的语义表示。
3. 并行计算。 注意力机制不依赖于序列顺序，可以一次性处理整个序列，从而极大提升了训练效率
4. 可解释性强。注意力权重可以可视化，帮助我们理解模型是如何‘思考’的。

3.Bert vs GPT？

BERT 和 GPT 是两种基于 Transformer 的自然语言处理模型，但它们的设计理念和应用方向不同。BERT 使用编码器结构，采用双向上下文理解，通过遮盖部分词语进行训练，适合文本分类、问答等理解类任务。而 GPT 则基于解码器结构，采用自回归方式从左到右生成文本，擅长写作辅助、对话系统等生成类任务。简单来说，BERT 更擅长“理解”，GPT 更擅长“生成”。

4.简单介绍一下千问模型？

（我在面试阿里前，临时准备的这个问题，害怕面试阿里他会问到，最少不会一问三不知）

1. 基本定位

• 千问是一个多语言、多模态的大模型，支持文本、图像、音频等输入，具备问答、写作、代码生成、翻译、文档处理等能力。
• 最新版本是 Qwen3 系列，于 2025 年发布，参数规模从 0.6B 到 235B，涵盖稠密模型和 MoE架构模型。

2. 技术亮点

• 混合推理机制：支持“快思考”和“慢思考”两种模式，用户可根据任务选择快速响应或深度推理。
• MoE 架构：通过稀疏激活专家子网络，在降低计算成本的同时保持高性能。
• 长上下文能力：旗舰模型支持 128K\~1M tokens上下文，适合长文档和复杂对话。
• 多语言支持：覆盖 119 种语言，全球化应用能力强。
• 训练规模：基于约 36万亿 tokens预训练，后训练包括指令微调、强化学习（RLHF）、思维链优化。

3. 应用场景

• 通用对话与问答
• 代码生成与编程辅助（专用模型 Qwen-Coder）
• 多模态任务：图文理解、OCR、音视频速读（Qwen-Omni、Qwen-VL 系列）
• 企业级智能体：支持工具调用、Agent框架。

4. 开源与生态

• 已在 魔搭社区、HuggingFace 等平台开源，支持免费商用，下载量超 6 亿次，形成全球最大开源模型生态之一。

5.简单介绍一下Gemini3模型？

（Gemini3 是目前最强模型，也有面试官直接问你对Gemini3 的理解，看你有没有关注前沿技术，所以我们准备一个Gemini3的模型知识，防止面试问了啥也答不上来的尴尬）

Gemini 3 的真正差异化优势

1. 推理深度 + 控制能力

• 其它模型也能做 CoT，但 Gemini 3 引入了 可控推理层级（thinking_level 参数），开发者可以动态选择“快思考”还是“慢思考”，而不是固定模式。这意味着它能在延迟和准确率之间灵活权衡，适应不同场景（聊天 vs 科研）。

• 结合 Deep Think 模式，它在博士级推理测试（GPQA Diamond）和 ARC-AGI-2 上刷新纪录，证明不仅能“慢思考”，而且能“正确慢思考”。 2. 原生多模态，不是外挂

• 很多模型支持多模态，但大多是“文本为主 + 插件式视觉”。Gemini 3 是 从架构层面统一文本、图像、视频、音频、代码，并且在 Video-MMMU、UI理解（ScreenSpot-Pro）测试中大幅领先 GPT-5.1 和 Claude。

• 这意味着它不仅能“看图回答问题”，还能做 跨模态推理，比如结合视频内容和代码逻辑完成任务。 3. 智能体能力的落地

• 其它模型也在尝试 Agent，但 Gemini 3 搭配 Antigravity 平台，实现了端到端工作流：不仅能调用工具，还能 自主规划、执行代码、验证结果，真正从“回答问题”进化到“完成任务”。

• 这让它更像一个“数字员工”，而不是一个聊天助手。 4. 超长上下文 + 高效架构

• 支持 100 万 tokens 上下文，并且通过 MoE（Mixture of Experts）架构 + TPU v6，在保证性能的同时降低成本。

• 其它模型即使能处理长上下文，往往会出现性能衰减，而 Gemini 3 在长上下文场景下仍保持高准确率。 5. 安全与透明创新

• 引入 思维签名（Thought Signatures），让长链推理过程可验证，适用于金融、法律等高合规场景。这是目前其它模型没有的。

6 模型和硬件

这个问题其实做Infra/算法的人需要知道更多，因为他会做推理加速，他会用专业的卡去做一些调整。 但是通常如果是说做应用的岗，可能很多使用的是远端模型，如果你使用的是远端模型而且是应用岗，这个问题被考察到的概率不大。

那么我们为什么要讲这个问题，如果你按照我的思路，去使用了本地模型，然后微调，量化，推理走了个大概的话，重点是你用了本地模型，那么面试官很可能在问你项目的时候，就会涉及到硬件问题。 问：那你的机器能跑的了这个模型吗？ 这个参考夸克千问一面以及Deepwisdom 一面。 在这里我们讲清楚 模型能不能跑，跑的有多快和什么相关，有了这个背景，你就比较清楚如何去回答这个面试官问题了。

6.1 模型能不能跑

这个章节其实涉及的内容也很复杂，涉及训练，推理。要是都弄得特别透彻的话，需要结合具体的算法来计算，需要理解神经网络的结构，训练过程，具体的算法。如果没有深度学习背景，算法基础，推理的基础，肯定看不懂所有的细节，不过你可以抓大放小，细节你都放掉，掌握具体的原则即可。你看我总结的面试问题和回答示例的时候，也没有回答特别多的细节。如果还在学习应用的朋友，抓大放小，忽略细节。如果学习了算法，有推理，训练的基础，可以对细节看得更仔细。另外本期内容也配备了视频讲解，可以结合来看。 另外这一小节的内容其实有非常多的算法，推理部署相关的东西，还是按照我们的思路来说，第一阶段的核心任务是学好应用，这里的内容对于应用岗位属于拔高项和加分项，优先级低于应用相关知识。

这里讲清楚一个模型能不能跑起来，核心就是一个问题：运行它的设备内存够不够。

如果模型跑在 GPU 上，这个设备内存通常就是显存；如果跑在 CPU 上，就是内存（RAM）。同一个 7B 参数的模型，推理时可能只需要 14GB 左右设备内存，而用 PPO 做强化学习对齐时可能需要超过 200GB。所以在回答"需要多少内存/显存"之前，我们必须先搞清楚：现在是哪个阶段、跑在哪类设备上。

6.1.1 背景：先搞清楚"问的是哪个阶段"

当有人问"训练一个大模型需要多少内存/显存"时，这个问题就过于笼统，缺少了细节—因为一个大模型从诞生到被用户使用，要经历多个完全不同的阶段，每个阶段的内存需求差异极大。同一个 7B 参数的模型，推理时可能只需要 14GB 左右设备内存，而用 PPO 做强化学习对齐时可能需要超过 200GB。所以在回答"需要多少内存/显存"之前，我们必须先搞清楚：面试官说的是哪个阶段、跑在哪类设备上。所以第一部分，给大家介绍一下大模型的生命周期。大模型的生命周期，也是建议大家需要理解和掌握的，虽然大家的岗位和工作可能只聚焦在一块，但是你需要知道他整个生命周期。

6.1.1.1 大模型完整生命周期

掌握这个图也可以看出大模型的大致岗位。 一般说算法，Infra, 算法工程，说的其实比较笼统，那对应会的事就是这里的RLHF（后训练），或者做模型部署推理的。 大模型应用工程 不处于这个图中，而是使用部署好的模型接口，直接调用，在上层做应用。 当然大模型算法一部分，就是搞研究，读论文，修改数理公式，创新个RL的方法呀，让整个训练效果更好，这种要求就会更高，一般要求论文，顶级学历（c9 硕博）。

综上，大模型方向岗位的门槛一般是 算法（纯研究) > 算法工程、infra,推理 > 大模型应用

图 006 · 已恢复原图内容 · 点击放大

1. 预训练

这是大模型的"出生"阶段。用海量文本数据（几万亿 token）训练模型预测下一个 token，让模型学会语言规律、世界知识和推理能力。这个阶段由 OpenAI、Meta、DeepSeek 等顶级团队完成，成本动辄数百万美元，普通人和工程师直接下载现成的 Base Model 即可，无需自己做。

2. SFT

Base Model 只会"续写文本"，不会"回答问题"。SFT 用人工标注的（问题, 高质量回答）数据对，教会模型遵循指令、按格式输出。这是让模型从"自动补全"变成"AI 助手"的关键一步。

3. 奖励模型训练

收集人类对不同回答的偏好数据（"A 回答比 B 好"），训练一个打分模型。这个模型之后会充当"AI 评委"，给策略模型的输出打分，替代人类实时反馈。

4. 策略更新

用强化学习算法（PPO 或 GRPO）驱动模型不断优化，目标是在奖励模型认可的方向上提升输出质量，同时不偏离 SFT 模型太远（通过 KL 惩罚控制）。这才是严格意义上的"RLHF"中的 RL 部分。

5. 部署推理

训练完成后，模型被部署给用户使用。这个阶段不需要梯度和优化器状态，运行内存需求大幅下降。如果部署在 GPU 上，主要看的就是显存；如果部署在 CPU 上，主要看的就是内存（RAM）。可以通过量化（INT8、INT4）进一步压缩，让模型跑在消费级显卡或普通 CPU 机器上。

6.1.2 基础知识铺垫

6.1.2.1 核心原则

运行内存需求 = 运行设备上每样东西的大小之和。

所以搞清楚两件事就够了：放什么 + 每样多大。

这里的"运行设备"可以是 GPU、CPU，也可以是 NPU/TPU 等加速器。跑在 GPU 上时，这部分内存通常叫显存；跑在 CPU 上时，就是内存（RAM）；跑在其他加速器上，则更准确地叫设备内存。后文为了讲解方便，很多地方仍会用"显存"举例，但底层计算逻辑是一致的。

在讲"放什么"之前，先明确两个阶段在干什么：

- 训练阶段：典型的深度学习训练过程——前向传播计算 loss，反向传播计算梯度，优化器用梯度更新参数。因为要做反向传播，计算设备必须同时持有参数、梯度、优化器状态，还要缓存中间激活值，所以内存压力极大；如果用 GPU 训练，这个压力就体现为显存压力。

- 推理阶段：模型已经训练好，只做前向传播，输入 prompt 输出 token。不需要更新任何参数，因此梯度和优化器状态完全不存在，运行内存需求大幅下降。

这也是为什么同一个模型，训练和推理的运行内存需求可以相差 5-10 倍。

6.1.2.2 训练 vs 推理：运行内存里住着什么？

┌─────────────────────────────┐      ┌─────────────────────────────┐
│          训练阶段            │      │          推理阶段            │
├─────────────────────────────┤      ├─────────────────────────────┤
│  ✅ 模型参数                 │      │  ✅ 模型参数                 │
│  ✅ 梯度                    │      │  ❌ 梯度（不需要）            │
│  ✅ 优化器状态               │      │  ❌ 优化器状态（不需要）      │
│  ✅ 激活值（前向传播缓存）    │      │  ❌ 激活值（不需要缓存）      │
│  ❌ KV Cache（通常不涉及）   │      │  ✅ KV Cache                 │
└─────────────────────────────┘      └─────────────────────────────┘
       训练内存占用：参数量 × ~14字节 + 激活值    推理内存占用：参数 + KV Cache

推理比训练省内存的根本原因：梯度和优化器状态消失了，这两项在训练时占了总内存的大头；如果模型跑在 GPU 上，这里说的总内存就是总显存。

6.1.2.3 各部分简介

训练和推理都有

模型参数（Parameters）

模型的"权重"，就是神经网络里所有的数字。7B 模型 = 70亿个参数。训练和推理都需要，是运行内存占用的基础项，也是估算一切的起点。

训练专属（推理时全部消失）

梯度（Gradients）

反向传播时计算出来的"每个参数应该往哪个方向调整多少"。每次更新完参数就可以释放，但在反向传播过程中必须常驻运行内存。精度通常用 fp32（4字节），大小和参数量相同。

优化器状态（Optimizer States）

优化器（如 Adam）为了更稳定地更新参数，需要记录每个参数的历史梯度信息（动量 m 和方差 v）。Adam 需要存两份，共 8字节/参数，是训练运行内存开销最大的单项。与梯度不同，优化器状态跨训练步骤全程持久存在。

激活值（Activations）

前向传播时每一层的中间计算结果。反向传播计算梯度时需要用到它，所以前向传播过程中必须缓存。大小与 batch size 和序列长度成正比。可用"梯度检查点"技术，在反向传播时重新计算激活值而非缓存，以计算时间换内存空间。

总结上述内容，可以用下面的图来表示

前向传播                    反向传播                  参数更新
───────────────────────────────────────────────────────────────▶
产生激活值（缓存）  →  用激活值计算梯度  →  优化器用梯度更新参数
    ↑                      ↑
 占内存，撑到              占内存，用完即丢
 反向传播结束才能释放

图 007 · 已恢复原图内容 · 点击放大

推理专属

KV Cache

KV Cache可以理解为推理时一个空间换时间的策略。推理时，模型自回归生成每个新 token 都需要"回顾"之前所有 token 的注意力键值（Key-Value）。KV Cache 把这些中间结果缓存下来，避免每步都重新计算。随上下文长度和并发请求数增长，长上下文或高并发场景下不可忽视。

6.1.2.4 精度与字节数

混合精度训练：刻意将低精度（bf16/fp16）和高精度（fp32）混合使用——在能省的地方用低精度（前向传播、反向传播计算，节省显存和加速），在必须保精度的地方用高精度（梯度存储、参数更新，防止数值不稳定）。

这里在面试网龙的时候也被问过，面试官问bf16和fp16的区别。

这里的“精度”决定了每个参数、梯度或中间激活值用多少字节存储。字节数越低，显存占用越小、吞吐通常越高；但数值范围和有效精度也会下降，训练时更容易遇到溢出、下溢或更新不稳定。因此训练常用混合精度：参数和计算尽量用 bf16/fp16，梯度累积、优化器状态等关键部分保留 fp32。

• fp32（4 字节）：精度高、数值稳定，但显存占用最大、计算吞吐较低。常用于梯度、优化器状态、关键累积计算。
• bf16（2 字节）：和 fp32 接近的数值范围，不易溢出；有效精度低于 fp32。大模型训练的常用选择，覆盖训练参数、前向反向计算、推理。
• fp16（2 字节）：有效精度比 bf16 略高，但数值范围更小，训练易溢出，常需 loss scaling。多用于推理、混合精度训练、较老 GPU 加速。
• INT8（1 字节）：量化压缩，显存更省，但带来少量精度损失。用于量化推理。
• INT4（0.5 字节）：压缩最激进，显存占用最低，但对模型效果和量化方法更敏感。用于极致压缩推理、QLoRA。

6.1.2.5 激活值大小的计算

激活值的大小计算就比较复杂了，和超参数，数据量，模型结构都有关系。大家如果看不懂很正常，缺少算法基础，还是像我们前头说的原则，抓大放小，我下面也总结了激活值大小大概的估算方法。看不懂先有大概印象就行。

激活值不像参数一样固定，它由四个变量共同决定：

• B（batch size）：一次喂多少条数据 — 超参数，可调。
• L（sequence length）：每条数据有多少个 token — 由数据集和截断设置决定，部分可控。
• H（hidden dimension）：模型隐藏层维度 — 模型架构决定，选定后固定。
• N（层数）：Transformer 的层数 — 模型架构决定，选定后固定。

粗略公式（bf16，每一层）：

$$\text{单层激活值} = B \times L \times H \times 10 \sim 12 \text{ 字节}$$

$$\text{全模型激活值} = B \times L \times H \times N \times 10 \sim 12 \text{ 字节}$$

这里的 10\~12 字节是经验系数，不是数学常数。不同框架、是否使用 FlashAttention、是否开启梯度检查点，都会影响真实激活值大小。它适合作为视频讲解里的快速估算。

7B 模型举例（\(H=4096\)，\(N=32\)）：

• B=1, L=2048：约 2.5 GB
• B=4, L=2048：约 10 GB
• B=8, L=2048：约 20 GB
• B=4, L=8192（长文本）：约 40 GB

快速估算口诀（不想算细节时）：

7B 模型，batch=4，seq=2048 → 激活值约 10 GB。seq 翻倍 → 激活值翻倍；batch 翻倍 → 激活值翻倍

6.1.3 后训练阶段

后训练的每个算法，在显存里放的东西不同，需要按统一假设分别估算。下面统一用 7B 模型、混合精度（bf16 参数 + fp32 梯度/优化器） 作为基准。

基础换算：7B 参数

参数（bf16）：7B × 2字节 = 14 GB

梯度（fp32）：7B × 4字节 = 28 GB

优化器状态 Adam（fp32，动量+方差）：7B × 4字节 × 2 = 56 GB

激活值：随 batch size 和 seq_len 变化，下面各节单独说明

注意：这里“梯度”和“优化器状态”都按 fp32 存，但数量不同：梯度只有一份，所以是 4字节/参数；Adam 优化器状态有动量 m 和方差 v 两份 fp32，所以是 2 × 4 = 8字节/参数。

6.1.3.1 SFT — 全参微调（Full Fine-Tuning）

显存里有什么：

所有参数都参与训练，梯度和优化器状态覆盖全部 7B 参数。

• 模型参数（bf16）：7B × 2 字节 = 14 GB
• 梯度（fp32）：7B × 4 字节 = 28 GB
• 优化器状态 Adam（fp32）：7B × 4 字节 × 2 = 56 GB
• 激活值：B·L·H·N·12 字节，典型 10–40 GB

激活值典型范围（7B，\(H=4096\)，\(N=32\)，bf16）：

• B=4，L=2048 → 约 10 GB
• B=8，L=2048 → 约 20 GB
• B=4，L=8192（长文本）→ 约 40 GB

结论：固定项已达 98 GB，单张 A100（80GB）仅凭固定项就装不下，必须多卡或开启梯度检查点。

6.1.3.2 SFT — LoRA 微调

核心思路：冻结原始模型参数，只在每层注入小的低秩矩阵（rank r，通常 r=8\~64），只训练这些新增的 adapter 参数。

LoRA 可训练参数量估算（r=16，7B 模型约 32 层，每层注入 Q/V 矩阵）：

• 每个 adapter：2 × (hidden_dim × r) ≈ 2 × (4096 × 16) ≈ 13万参数

- 全模型 adapter 总量 ≈ 约 4000万参数（0.04B），仅占原模型的 0.5%

7B 模型 SFT LoRA 微调显存拆解（LoRA 参数量按 \~0.04B 估）：

• 原始模型参数（bf16，冻结、无梯度）：7B × 2 字节 = 14 GB
• LoRA 参数梯度（fp32）：0.04B × 4 字节 ≈ 0.16 GB
• LoRA 优化器状态 Adam（fp32）：0.04B × 4 字节 × 2 ≈ 0.32 GB
• 激活值（同全参）：B·L·H·N·12 字节，典型 2.5–10 GB

激活值典型范围（7B，\(H=4096\)，\(N=32\)，bf16）：

• B=1，L=2048 → 约 2.5 GB
• B=4，L=2048 → 约 10 GB

注意：LoRA 的激活值和全参 SFT 近似同量级——因为前向传播时整个模型都要跑，激活值覆盖全部 32 层，不会因为"只训练少量参数"就消失。真实工程里可能通过冻结层优化、梯度检查点进一步降低。

结论：单张 4090（24GB）在短序列、小 batch 下可以跑 LoRA，但比较贴边；更常见的消费级方案是 QLoRA（把冻结的底座模型量化存储）。显存大幅下降的原因是梯度和优化器状态只覆盖极少量 adapter 参数，而不是全部 7B。

6.1.3.3 RL 对齐 — PPO 算法

这里涉及到强化学习的两个算法，PPO和GRPO。没有强化学习的背景肯定看不懂，可以先理解或者背诵。 如果想要学习强化学习，可以用零基础学习算法章节的后训练SKILL去学习，这个SKILL主要核心就是在讲解这两个算法和区别。

PPO 需要同时在显存里维护多个模型（这里按最容易理解的"独立 Actor + 独立 Critic + Reference + Reward Model"估算）：

PPO 同时持有 4 个 7B 模型，显存压力极大：

• Actor 策略模型（生成回答，训练目标）— 训练中：参数 + 梯度 + 优化器 + 激活值，108–138 GB
• Critic 价值网络（估计每个状态价值，辅助计算优势）— 训练中：同 Actor，108–138 GB
• Reference Model（SFT 冻结版，计算 KL 惩罚）— 冻结：仅参数，14 GB
• Reward Model（给回答打分）— 冻结：仅参数，14 GB

合计 ≈ (108\~138) + (108\~138) + 14 + 14 ≈ 244\~304 GB

为什么需要 Critic？

PPO 用 GAE（广义优势估计）计算每个 token 的优势值，需要一个能输出 \(V(s)\)（状态价值）的网络，这个 Critic 网络和 Actor 同等规模。

结论：7B PPO 通常至少 4 张 A100 80GB 起步，并且需要分片、梯度检查点等工程优化，是后训练中显存开销最大的算法。

6.1.3.4 RL 对齐 — GRPO 算法（DeepSeek R1 方案）

GRPO 的核心改动：去掉 Critic，改用"组内相对奖励"估计优势——同一个 prompt 生成 G 条回答，用组内均值做 baseline，不需要价值网络。

GRPO 相对 PPO 去掉了 Critic，是 R1 训练得以可行的关键优化. GRPO 需要的模型：

• Actor 策略模型（生成回答，训练目标）— 训练中：108–138 GB
• Reference Model（计算 KL 惩罚）— 冻结：仅参数，14 GB
• Reward Model（规则函数可替代）— 可选：0–14 GB

合计 ≈ 122–152 GB，相比 PPO 节省了一个完整 Critic（≈100 GB），算力门槛下降了一档。

合计 ≈ (108\~138) + 14 ≈ 122\~152 GB（不用独立 RM 的情况）

额外注意：GRPO 每个 prompt 要采样 G 条回答（通常 G=8），激活值比普通 SFT 更大，实际偏向范围上限。

对比 PPO 的节省：

• 去掉 Critic：直接省去一整个训练中的模型（108\~138 GB）
• 去掉 Reward Model（用规则打分）：再省 14 GB

- 显存从 \~244\~304 GB 降到 \~122\~152 GB，减少约一半

结论：7B GRPO 单张 A100 80GB 无法完成（122\~152GB > 80GB），通常至少需要 2 张 A100 起步，并配合分片或梯度检查点；相比 PPO 的 244\~304GB，显存压力大约减半。这是 DeepSeek R1 选择 GRPO 的核心工程原因之一。

6.1.4 部署推理阶段

推理阶段只做前向传播，没有反向传播，因此梯度、优化器状态、训练用的激活值缓存全部消失。主要显存开销只剩两样东西：模型参数 + KV Cache（实际框架还会有少量临时 workspace）。

6.1.4.1 模型参数：精度决定基础显存

推理时参数可以用比训练更低的精度，进一步压缩显存。

7B 模型各精度下的参数显存：

• bf16 / fp16（2 字节）：14 GB，标准推理，效果无损。
• INT8（1 字节）：7 GB，量化推理，效果略有损失。
• INT4（0.5 字节）：理论 3.5 GB，实际常见 4–5 GB（因为还要存量化 scale 等元数据），极致压缩。

量化：将参数从高精度（bf16）映射到低精度（INT8/INT4）存储，推理时动态还原计算。显存减半，但精度有损失，模型越大量化损失越小（70B模型 INT4 通常还可接受，7B INT4 可能有明显退化）。

6.1.4.2 KV Cache：随上下文增长的动态开销

这里面公式又很复杂，需要专门做过部署推理的人才会深入理解，还是抓大放小，有个印象就行。

推理时每生成一个 token，都需要回顾之前所有 token 的注意力键值（Key-Value）。KV Cache 把这些结果缓存起来避免重复计算（空间换时间）。

KV Cache 大小公式：

$$\text{KV Cache} = 2 \times B \times L \times N \times N_{kv_heads} \times D_{head} \times \text{字节数}$$

• 系数 2：Key 和 Value 各一份
• \(B\)：当前同时参与推理的序列数，也可以叫推理时的有效 batch size；在线服务里通常可近似理解为“正在生成中的活跃并发请求数”
• \(L\)：上下文长度（已生成的 token 数）
• \(N\)：层数
• \(N_{kv_heads}\)：KV 头数量
• \(D_{head}\)：每个注意力头的维度

如果是传统 MHA，KV 头数量通常等于注意力头数量，KV Cache 会更大；如果是 GQA/MQA，KV 头数量更少，KV Cache 会明显变小。所以 KV Cache 也和模型结构有关。

7B 模型举例（\(N=32\)，\(D_{head}=128\)，bf16，按 8\~32 个 KV 头给范围）：

KV Cache 的显存几乎与 batch × context_length 成正比：

• B=1, L=2048：约 0.25–1 GB
• B=1, L=32K：约 4–16 GB
• B=16, L=2048：约 4–16 GB
• B=16, L=32K：约 64–256 GB（多并发 + 长上下文是显存炸裂的典型场景）

长上下文 + 高并发时，KV Cache 可以轻易超过模型参数本身的显存占用，这是部署时最容易被忽视的显存杀手。

6.1.4.3 推理总显存 = 参数 + KV Cache

7B 模型典型推理场景：

推理总显存 = 模型参数 + KV Cache，5 个典型场景：

1. 单用户短对话（bf16）：14 GB 参数 + 0.25–1 GB KV ≈ 14.25–15 GB，4090 单卡可跑。
2. 单用户长上下文 32K（bf16）：14 GB + 4–16 GB ≈ 18–30 GB，4090 视模型结构而定。
3. 量化单用户（INT4）：4–5 GB + 0.25–1 GB ≈ 4.5–6 GB，消费级卡轻松。
4. 多并发 16 路、短对话（bf16）：14 GB + 4–16 GB ≈ 18–30 GB，A100/80G。
5. 多并发 16 路、长上下文（bf16）：14 GB + 64–256 GB ≈ 78–270 GB，必须多卡或限流。

6.1.5 汇总对比表

以下均以 7B 模型、混合精度（bf16 参数 + fp32 梯度/优化器） 为基准。训练激活值按 10\~40GB 估算；推理 KV Cache 按 8\~32 个 KV 头给范围

• SFT 全参微调：108–138 GB（参数 14 + 梯度 28 + Adam 56 + 激活 10–40）
• SFT LoRA：17–25 GB（冻结参数 14 + adapter 梯度&优化器 ≈0.5 + 激活 2.5–10）
• RL PPO：244–304 GB（Actor 108–138 + Critic 108–138 + Ref 14 + RM 14）
• RL GRPO：122–152 GB（Actor 108–138 + Ref 14，去掉 Critic）
• 推理 bf16，单用户：14.25–15 GB（参数 14 + KV 0.25–1）
• 推理 bf16，16 并发 / 2048：18–30 GB（参数 14 + KV 4–16）
• 推理 INT4，单用户：4.5–6 GB（参数 4–5 + KV 0.25–1）

6.1.6 附：根据显卡选方案

我们在选卡时，应该自己用上面的知识去算一下，给一个表让大家有个直观印象。

• 消费级 4090（24 GB）：7B bf16 推理；7B QLoRA / LoRA 微调（控制 batch、seq_len）；30B 级 INT4 量化推理。
• 专业卡 A100（80 GB）：7B LoRA 微调较轻松；7B 全参 SFT 单卡不够；7B GRPO 通常需要 2 张起步。
• 多卡 A100 × 4（320 GB）：7B 全参 SFT / GRPO 较稳；7B PPO 可做，但需要分片、梯度检查点等工程优化。
• 多卡 H100 × 8（640 GB）：7B PPO 较稳；70B 级全参训练通常还需要 ZeRO、并行切分、梯度检查点或优化器状态压缩。

6.1.7 附：面试 Q&A

其实面试过程中很多时候对于类似的问题，面试官本身的表述是模糊的。比如6.1.7.1， 问SFT要多大显存？但是SFT里有全量微调，Lora等部分参数微调，算法不一样，结果是不一样的。回答问题的时候，我们自己心里要是清楚的，主动澄清清楚前提和具体细节，然后给面试官举例说明，可以不用说的那么细致，说一下大致的估算即可。如果面试官深入问了，可以再给他讲细节，也就是我们上面笔记介绍的细节部分

6.1.7.1 Q1：7B 模型做 SFT 大概需要多大显存？

这个问题要先看是全参 SFT还是 LoRA/QLoRA。原则上，训练显存主要由参数、梯度、优化器状态和激活值组成。

如果是全参 SFT，通常会按照业界大模型训练里常见的混合精度训练口径来估算：模型参数用 bf16/fp16 存储，梯度和 Adam 优化器状态保留 fp32。这个口径的来源其实就是不同精度的字节数：7B 参数用 bf16/fp16 是 2 字节/参数，所以参数本身约 14GB；梯度按 fp32 是 4 字节/参数，所以约 28GB；Adam 还要保存一阶动量和二阶动量两份 fp32 状态，所以是 2 × 28GB，约 56GB。再加上激活值，全参 SFT 通常要 100GB 以上，单张 80GB A100 一般不够，需要多卡或分片优化。

如果是 LoRA/QLoRA，因为只训练少量 adapter 参数，梯度和优化器状态会小很多。以 7B 为例，LoRA 通常 20GB 左右可以起步，QLoRA 会更省，消费级 24GB 显卡也有机会跑起来，但要控制 batch size 和 sequence length。

6.1.7.2 Q2：7B 模型做强化学习大概需要多大显存？

强化学习阶段要看具体算法，因为不同算法需要同时放进显存的模型数量不一样

如果以 PPO 为例，通常要同时维护 Actor、Critic、Reference Model 和 Reward Model。Actor 和 Critic 都是训练中的完整模型，单个就接近全参微调的开销，所以 7B PPO 往往需要 200GB 以上显存，通常需要多张 A100/H100，并配合 ZeRO、梯度检查点等工程优化。

如果以 GRPO 为例，它去掉了 Critic，用组内相对奖励来估计优势，显存压力会明显下降。7B GRPO 大致可以按 Actor + Reference Model 来估，通常在 100GB 以上，相比 PPO 大约省一半，但单张 80GB A100 仍然比较紧张。

6.1.7.3 Q3：7B 模型部署推理大概需要多大显存？

部署推理和训练不一样，推理不需要梯度和优化器状态，主要看两个东西：模型参数和 KV Cache。

如果用 bf16/fp16 推理，7B 模型参数大约是 14GB。KV Cache 的大小差异会比较大，主要和上下文长度、并发请求数、模型的注意力结构以及 KV Cache 本身的存储精度有关。单用户、短上下文场景下，再加少量 KV Cache，整体大约 15GB 左右，24GB 显卡一般可以跑。

如果做量化，INT8 大约 7GB，INT4 实际常见大约 4\~5GB，再加 KV Cache，可以进一步降低显存。但如果是长上下文或高并发，KV Cache 会快速增长，这时显存瓶颈可能不再是模型参数，而是 KV Cache。

6.1.7.4 Q4：你说在CPU机器上跑7B的模型，这个可以跑得动吗？

这个是阿里夸克千问一面面试官的原题。我当时被问到这个问题，其实我答的很笼统，我就说模型比较小，也做了量化。但当我学习了今天这个内容以后，我才总结出这个更细致，详实的答案。当然当时我的回答也并没有阻碍我面试不通过，反正整个夸克千问我是拿到了offer的。我们都会按照100分甚至是120的回答去准备，但是通过一次面试，不意味面试每个问题都要回答到100分。

另外，其实我分析来说，其实当时的面试官我估计也不懂这个细节。原因是本身就是应用岗，夸克千问整体面试下来给我的感觉，他们这个岗位不会做算法，不做训练，纯专注于应用，强度又高，其实面试官不知道这块内容很正常。他问到这个问题，是因为项目写了在cpu机器上本地跑7B模型。所以我答的模糊这事也就过去了。不过在这种情况下，当时我能够像下面这个答案一样回答得很具体，甚至面试官感兴趣，继续问我，我给他讲一下，这样面试会更加分。如果在面试关不懂的地方，你能够给他讲得很清楚，会极大的加分。

可以跑，但要分两个角度看：能不能装下，以及跑得快不快

首先从能不能装下看，CPU 机器没有 GPU 显存，主要看的是内存（RAM）够不够。这里我按实际使用场景来回答：我把 7B 模型量化成了 INT4，并且使用 llama.cpp 做 CPU 推理。

推理阶段的内存主要是：量化后的模型参数 + KV Cache + llama.cpp 运行时开销。7B 模型做 INT4 量化后，模型文件通常大约 4\~5GB。KV Cache 的大小和上下文长度、并发数有关，但本地 CPU 推理一般是单用户、单路对话，也就是并发数基本可以按 1 来算。如果上下文长度是 2K\~4K，7B 模型的 KV Cache 通常大约是 0.5\~2GB 这个量级，具体取决于模型结构和 llama.cpp 的 KV Cache 精度设置。再加上系统和框架开销，整体大概需要 8\~10GB 内存，所以 16GB 内存的普通消费级机器一般可以跑起来，8GB 会比较紧张。

其次从速度看，CPU 可以跑，但速度和 GPU 不是一个量级。INT4 量化会减少模型参数读取和计算压力，llama.cpp 又专门针对 CPU 做了优化，比如多线程、矩阵计算优化、GGUF 格式加载等。按普通消费级 CPU 来估算，一次普通长度的回答大概可能在 20\~30 秒左右；另外考虑到我们的任务对实时性要求不高，所以这个时延是完全可以接受的。

6.1.8 视频讲解

本小节的内容涉及范围很广，算法，部署，深度学习，大家可能学起来有难度。我录了一个视频，视频的讲解面向于0基础，相信大家都能看懂。

https://www.bilibili.com/video/BV1Lb5S6qEuA/?spm_id_from=333.1387.homepage.video_card.click&vd_source=144bec9c3f54e465073138bed788be1b

6.2 跑的有多快

跑的有多快，相对来说更复杂：取决于你的算力和任务。

核心原则：算力越强，并行度越高 -> 越快。

影响因素：

├── 硬件算力（ 每秒浮点运算次数，好的显卡，cpu 算力更强，速度也更快）

├── 内存带宽（数据搬运速度）

├── 并行度（多核/多卡）

└── 软件优化（推理框架）

└── 任务类型（任务复杂，prompt 和 时间复杂度成o(n^2）关系（从Attention结构上来讲））

其实这个问题相对来说就更加复杂，在《大模型工程师面试实战- 算法原理，开发实践与系统部署》（清华大学出版社） 书中是有专门讲解这个推理速度相关的问题，以及如何优化。这个和硬件，Infra的岗位相关，是他们优化的工作。所以具体还是很复杂的，但是作为应用，我们了解到这里就可以啦！

7. 不同模型的对比和选择

有些公司在面试的时候，喜欢问的一个问题是，你的项目用的什么模型，为什么要用这个模型，比如你可以看到笔记面经里的小红书，平安证券，都有类似的问题。 其实使用什么模型这个事情，不光和模型本身有关，也和公司层面（比如公司有自己自研模型，那产品肯定接入自家模型），政治方面因素相关（中国很多产品，政治上也不让用国外模型，国外的模型比如Claude系列，也会限制中国的使用）。

这一章，首先讲解 7.1 讲解市面上所有的主流模型的典型特点。 7.2 结合面试题：你的项目使用什么模型 来讲解 项目模型选择的策略。 7.3 讲解一下最新典型旗舰模型的特点。

7.1 主流模型的对比

本章会概括所有主流模型，看完这一章，你能够对市面所有模型有一个概念，印象，不追求多深入，但是你最少能知道每个模型是那个公司，他最核心的特点，优缺点，大概的选型原则。注意模型迭代速度其实非常快，这个章节时效性很强（此章节整理于2026/5/10）。不过大体的趋势和特点还是相对短期稳定的，比如GPT模型强在生态，Claude模型强在编程，Gemini模型在各大Benchmark屠榜。看完本节，你会了解目前最主流的模型的特点，优缺点，就算不从面试的角度来说，作为谈资也是值得一看的。

7.1.1 通用大模型

7.1.1.1闭源阵营

7.1.1.1.1 GPT (OpenAI)

一句话定位： AI 开山鼻祖，用户量大，生态好，通用能力最强。

- 当前旗舰模型： GPT-5.5 (2026-05-05)

模型矩阵

- GPT 主线（GPT-5.5）：通用聊天 / 多模态 — 日常全能任务。

- O 系列（最新 O 系列推理模型）：纯推理线，回答前先"思考" — 数学、逻辑、多步工程。

- Image 系列（gpt-image-2）：图像生成，取代 DALL·E — 海报、文字渲染、图文。

- 语音 / 实时（Realtime API + 语音模型）：低延迟语音交互 — 语音助手、电话机器人。

- 视频系列：已无在售产品（Sora 已停服）。

核心优势

- 生态最大： 数亿用户、最多第三方插件与应用构建在 GPT 上。

- 多模态最齐全： 文 / 图 / 语音 / 实时全覆盖（视频暂缺）。

- 顶级文字渲染： `gpt-image-2` 的文字渲染业内顶级，能正确拼单词、做海报。

劣势与短板

- 不再是单项绝对王者： 榜单常被 Gemini 反超，编码上被 Claude 压制。

7.1.1.1.2 Gemini (Google)

一句话定位： 榜单领跑者；最大筹码是深度嵌入 Google 全家桶。

- 当前旗舰模型： Gemini 3.1 Pro

模型矩阵

- Pro（Gemini 3.1 Pro）：旗舰 — 难题、长文档、复杂多模态。

- Flash（Gemini 3 Flash）：速度款，约 Pro 的 90–95% 能力 — 日常高频任务，更快更便宜。

- Flash-Lite（Gemini 3.1 Flash-Lite）：极致性价比 — 高吞吐 / 大规模批处理。

- Deep Think（Gemini 3.1 Deep Think）：深度推理模式（仅 AI Ultra 订阅） — 科研、工程、复杂技术难题。

核心优势

- 多模态强： 拍照识物体场景实用度高（如修车工拍零件即得识别结果）。

- 生态优势：集成了Google全家桶，比如Gmail, Chrome（严格说这个不算模型的能力，算应用的能力）

- 榜单领跑： 2025 AIME测试上（测试数学推理），Gemini模型领跑，其次是Claude, 然后是GPT。

7.1.1.1.3 Claude (Anthropic)

一句话定位： 编码、长文档、Agent 任务的专家；多模态偏弱，但单项做到顶。

- 当前旗舰模型： Claude Opus 4.7 (2026-04-16 发布)

模型矩阵

Anthropic Claude 三档定位：

- Opus（Claude Opus 4.7）：旗舰，研究实验室级 — 硬骨头、复杂工程、深度分析。

- Sonnet（Claude Sonnet 4.7）：中端，约 Opus 80% 实力 — 日常编码、长文档处理，性价比高。

- Haiku（Claude Haiku 4.7）：轻量级，速度快、成本低 — 高并发、实时响应、批处理、简单任务。

核心优势

- 编码优势： LiveCodeBench、SWE 等"真实代码库"基准排名靠前；开发者社区编码首推。

- 长文档分析： 合同、论文、整套代码库给出结构化摘要而非零散答案。

- 风格客观： 风格"最不谄媚"，直接告诉你想法烂在哪，不无脑捧场。

劣势与短板

- 多模态弱： 无原生图像生成，纯文本 / 代码专家。

- 生态缺位： 没有自家语音 / 视频线产品。

7.1.1.1.4 Grok (SpaceXAI)

这个Grok估计不太会问了，作为国外模型，不如前三个亮眼。我还是总结大家了解一下。

一句话定位： 实时 X（Twitter）集成 + 最自然的对话感；尺度大、争议多。

- 当前旗舰模型： Grok 4.3 Beta (2026-04-17 发布)

模型矩阵

- 主线（Grok 4.3 Beta）：当前旗舰，推理 / 通用 — 综合任务、推理。

- Fast 档（Grok 4.1 Fast）：工具调用 / 代理工作流 — Agent、长上下文工具链。

- 图像 / 视频（Grok Imagine + Aurora）：图像 + 视频统一管线 — 出图、短视频。

核心优势

- 实时 X 集成： 拉热门讨论、突发新闻摘要、舆情分析比爬虫式模型快得多。（这个严格来说也是产品的能力，不是模型的能力）

- 对话自然： 对话风格自然放松，像跟人聊天，半夜 3 点也秒回。

- 言论尺度大： 会回答其他模型常拒答的问题。

劣势与短板

- 态度主观： 严肃分析场景下，"会反驳的模型"反而更受偏好。

- 争议多发： 多次因系统提示问题、深伪图像、Grok Imagine "Spicy" 模式等卷入争议。

7.1.1.2 开源阵营

开源意味着：完全控制 = 数据不出门 + 无 API 费 + 离线可用（电费你出）。

7.1.1.2.1 DeepSeek

一句话定位： 开源 + 价格屠夫 + MoE 高效；前沿 AI 不再需要十亿美元级预算的代表。

- 当前旗舰模型： DeepSeek-V4 (2026-04-24 发布预览)

模型矩阵

- V 系列 / 通用主线（V4-Pro / V4-Flash）：通用聊天 + 思考 / 非思考双模式 — 日常 + 推理一体。

- R 系列 / 纯推理（R1）：引爆 2025 "Sputnik 时刻"，目前路线已并入 V 系列。

- Coder（DeepSeek-Coder）：编码 — 代码补全、生成。

- Math / Prover（Math-V2 / Prover）：数学与定理证明 — 数学竞赛、形式化数学。

- 视觉（DeepSeek-VL2）：图文理解。

核心优势

- 极致高效： 架构 MoE + MLA（自 V2 起），参数量大但每次只激活一小部分，又快又省。

- 开源与低价： 权重 MIT 开放可本地部署；API 价格远低于美国一线。

- 垂直矩阵齐全： 编码 / 数学 / 证明 / 视觉各有专精模型。

7.1.1.2.2 其它模型

剩下的模型，我用一个表格，一句话总结其它模型最核心的特点：

- Meta（LLaMA 4）：最高约 400B 参数 — 开源浪潮起点，2026 上半年有更大版本。

- 阿里（Qwen 3.5）：双 3090 本地可跑 — 多语言强，本地体验逼近 Claude Sonnet。

- 智谱 AI（GLM-5）：203K tokens 上下文 — 开源榜顶尖，许可证商用友好。

- Moonshot（Kimi K2.5）：Perplexity 可用 — 数学 / 推理强，AIME 2025 高分。

- Mistral（Mistral 系列）：小模型见长 — 以小博大，欧洲语言出色。

7.1.3 视觉生成模型

视觉生成模型和视频生成模型不作为重点。从面试角度来说，那种专门做视频，多模态相关的岗位会侧重视觉模型和视频生成模型，找工作如果没有这方面的倾向（比如我），不需要深入了解。所以这两章只是简单总结，大家有个印象就行。

- 美感极致 → Midjourney：艺术质量之王，画面电影感、精致；约 $10/月起。

- 简单易用 → gpt-image-2：内嵌 ChatGPT，原生多模态，文字渲染业内顶级（能正确拼单词、排版海报）。

- 精准理解 → Flux：开源、本地、免费；Prompt 语义还原度业内领先。

- 极度可控 → Stable Diffusion 3.5：开源本地，配合 LoRA、ControlNet 控制力极强；学习曲线陡，但灵活度无敌。

需要避开的误区

模型是物理分离的： 文本模型和图像模型几乎总是分开的系统。例如，你在 ChatGPT 里画图，实际调用的是 `gpt-image-2`（已取代 DALL·E），而不是 GPT 语言模型本身；Grok 出图也是独立的 Grok Imagine 管线。

7.1.4 视频生成模型

本身不做视频内容，面试也很少问，这小节看看就行吧，算是科普了。

- Sora（OpenAI）：重大变动——已停服，API 将在 9 月彻底关闭，短期内不可用。

- Kling 3.0：主打速度与便利，支持音视频一次生成，榜单表现已反超 Sora 2 Pro。

- Runway Gen-4.5：给创作者极强控制力，提供运动笔刷、镜头一致性、相机引导功能。

- Seedance 2.0：字节跳动出品，当前文生视频榜单领跑者之一。

- Grok Imagine：图像与视频统一管线，已上线高质量模式 API。

7.1.5 面试问题参考

Q：你平时工作和学习中用过哪些模型，分别用来做什么？

面试官可能问这个问题，考一下你对AI 是否聪明熟练地使用AI工具。这个回答是根据上面不同模型的特点总结的，有点多，主要是提供个思路，根据不同模型的特点来在不同的场景下使用。这样回答体现你对不同模型特点都有理解，也会聪明使用。

用过挺多的，不同场景我会选不同的模型，因为各家模型的优势方向差别还是比较明显的。

编程和写代码这块，我基本首选 Claude。它在 LiveCodeBench 这类真实代码库评测上一直排名靠前，开发者社区里口碑也最好。日常写代码、调 bug、看别人的代码逻辑，我用 Sonnet，性价比高，够用；遇到比较复杂的架构设计或者系统级的问题，我会升级到 Opus，它在推理深度上确实更强。另外 Claude 有一个特点我很喜欢，它不太会无脑夸你，说法比较直接，方案有问题它会直说，做技术决策的时候反而更可信。

GPT 我主要用在两个场景。一个是日常通用问答，因为它生态最成熟，各种插件和工具支持都齐全，随手查个东西、聊个想法很顺手；另一个是图像生成，gpt-image-2 的文字渲染我觉得是目前最好的，做海报、图文内容、有文字的封面，它比其他模型准确多了

Gemini 我主要用来处理长文档和多模态任务。它和 Google Docs、Drive 的整合很自然，工作流上比较顺。日常高频的任务我一般用 Gemini Flash，它的能力大概是 Pro 的 90–95%，但速度更快、价格更低，够用的情况下没必要上 Pro；遇到真正复杂的多模态分析、长文档深度阅读这类场景，才切换到 Pro。

DeepSeek 我用在对成本比较敏感或者需要本地部署的场景。它的 API 价格比美国一线模型便宜很多，而且开源可以本地跑，数据不出门，对于一些不想上传到外部服务器的内容，本地跑 DeepSeek 很合适。数学推理这块它也很强，做一些计算密集型的任务我会考虑它。

Grok 我偶尔会用来做实时舆情和热点信息的查询，因为它直接整合了 X（Twitter）的数据，对突发事件、技术圈动态的感知比其他模型快很多，这块是它的独特优势。

总体来说，我的习惯是：编程找 Claude，通用和出图找 GPT，长文档找 Gemini，省钱或者本地部署找 DeepSeek，追热点找 Grok。不同场景用最合适的工具，而不是只盯着一个模型用到底。

7.1.6 参考资料

文档的内容基本按照这个视频来总结的。不过这个视频有一些错误的地方，比如Openai的图像模型用的早都不是DALLE 而是Image，时效性有问题，比如现在claude 4.7，GPT 5.5 都出了。这些我在文章内更正了

https://www.bilibili.com/video/BV1hWo1BXEko/?spm_id_from=333.337.search-card.all.click&vd_source=144bec9c3f54e465073138bed788be1b

7.1.7 视频讲解

直接看这个7.1可能有点枯燥和流水账，这个视频把7.1 小节的内容讲了一遍，结合视频看更轻松

https://www.bilibili.com/video/BV1oP5x6iEcG/?spm_id_from=333.1387.homepage.video_card.click&vd_source=144bec9c3f54e465073138bed788be1b

7.2 模型的选型

介绍一个考虑模型选型的模板，这块有一些产品思维，参考文档也是从一个产品经理的论坛文章上看的。

7.2.1 模型选择策略理论

最佳的选型策略应当是从业务需求反推技术选择，构建 场景 - 能力 - 模型 的三步决策框架。

第一步：定义场景 (精准描述问题与流程)

选型的起点必须是具体的业务场景，切忌模糊的大词，建议采用“黄金圈法则”进行拆解：

- Why (价值目标) : 该场景要解决什么核心痛点？（例如：降低20%的客服人工介入率）

- What (任务定义) : 具体要完成什么任务？（例如：自动回复用户的订单状态查询）

- How (工作流程) : 任务的执行流程与限制是什么？需要多快的响应速度？是否有数据不出境的硬性要求？

第二步：拆解能力 (分析核心能力需求)

将明确好的业务场景，转化为对大模型具体的可量化能力。

- 分类拆解: 明确场景最看重的是什么能力。是信息抽取、内容生成、复杂逻辑推理，还是外部工具调用（API集成）能力？

- 划分优先级: 将需求划分为“必要能力”与“加分能力”，并为各项核心能力分配权重。例如：在智能客服中，工具调用准确率可能是必要能力（占50%权重），而多语言翻译可能是加分能力（占10%权重）。

第三步：匹配模型 (寻找场景最优解)

根据拆解出的能力权重，对候选模型进行综合评估：

- 能力适配度: 拒绝“榜单依赖症”（如通用的MMLU分数）。必须从真实业务中抽样构建场景化测试集（如100个真实案例）进行盲测打分。

- 成本效益比 (TCO): 不能只对比单次Token调用价格，必须将业务高峰期的调用量波动、本地化私有部署硬件成本、配套人工审核维护成本计算在内。

- 风险可控性: 评估数据安全隐私、合规要求以及模型供应商的服务稳定性。在金融/医疗等敏感领域，合规和数据不出境往往具备一票否决权。

7.2.2 实战演示

我结合我们笔记中的项目：智能预约系统来演示一下上面这个理论的应用。大家要是面试问到这个问题，根据你自己的项目往里面套模板就行。从另一个角度来说，如果你还没有做项目，真的可以考虑一下这个原则，在做项目之前好好考虑一下应该用什么模型。

以一个真实的 Agent 项目为例，演示如何将"场景 - 能力 - 模型"框架落地。该项目背景是：传统按摩房依赖人工前台接听电话，完成预约分配、咨询解答、客户回访等工作，效率低、成本高。因此设计了一套多 Agent 对话系统来替代人工前台。

第一步：定义场景

按摩房 Agent 项目的 Why / What / How：

- Why（价值目标）：解放人工前台，实现 7×24 小时自动预约与咨询，降低人力成本。

- What（任务定义）：用户通过对话完成技师预约、项目咨询、个性化回访。

- How（工作流程）：用户发起对话 → 意图分类 → 分流至预约 / 咨询机器人 → 数据库查询 / RAG 检索 → 确认预约并推送天气提醒。

系统最终拆解为 4 个 Agent：分类机器人（意图路由）、预约机器人（多轮收集需求 + 数据库查询）、咨询机器人（从私有文档 RAG 检索回答）、行为分析 Agent（分析历史预约、生成个性化回访）。

第二步：拆解能力

项目所需 LLM 能力及权重：

- 意图分类准确性（必要，35%）：分类错误会导致整个流程跑偏，是系统的咽喉。

- 工具调用 / Function Call（必要，30%）：预约机器人需要精准调用数据库查询技师空档。

- RAG 检索整合（必要，20%）：咨询机器人须从私有文档中准确检索按摩房信息。

- 多轮对话上下文理解（必要，10%）：预约流程需多轮收集用户偏好，不能"失忆"。

- MCP 外部服务集成（加分，5%）：预约成功后调用天气 MCP Server，生成个性化提醒。

第三步：匹配模型

系统采用分层选型策略，不同 Agent 所需能力不同，不必全部使用同一个高价模型：

4 个 Agent 的推荐模型与理由：

- 分类机器人 → GPT-4o-mini / Qwen-Turbo：任务简单（4 分类），轻量模型成本低、响应快。

- 预约机器人 → Claude Sonnet 4 / GPT-4o：工具调用稳定性高，多轮上下文理解强，是系统核心。

- 咨询机器人 → Claude Sonnet 4 / DeepSeek-V3：RAG 整合流畅，文档理解能力强；DeepSeek 成本更低。

- 行为分析 Agent → DeepSeek-R1 / GPT-4o Thinking：需对历史数据做多步推理，生成个性化回访文案。

7.2.3 面试回答示范

Q：你的项目是如何进行模型选型的？

我用这个思路总结答案：

1. 通过需求确定基本模型：使用上面的三段理论：业务场景 - 功能 - 模型 来回答。确认大致模型。

2. 从大致意向模型里，做对比（查测评表，资料，做实验等方式）确定最终模型。

第二点更好一点的方式是通过实验驱动，对比不同模型。但是如果这么说，面试官可能会问你真的怎么做的？怎么测评的，数据集多少，万一你答不上来，可以就从查测评表，查资料来做对比确定而不是做实验确定。

第一段（按需求确定大致模型）：

我在做按摩房智能预约系统的时候，是从业务场景出发，反推需要什么能力，再去匹配模型。这个系统有四个 Agent——分类机器人、预约机器人、咨询机器人和行为分析 Agent，每个 Agent 的任务差别很大，所以我没有用一个模型一刀切，而是先按"业务场景 - 功能能力 - 模型"分别拆。分类机器人只是判断用户意图属于哪一类，任务简单，所以倾向用轻量模型，成本低、响应快；预约机器人是系统核心，要多轮确认时间和技师偏好、还要调数据库查空档，对工具调用稳定性和多轮上下文要求最高，所以要用主力模型；咨询机器人主要做 RAG，从私有文档里检索回答，重点是文档理解能力；行为分析 Agent 在后台异步跑，需要对历史数据做多步推理，所以倾向推理型模型。这样一轮拆下来，每个 Agent 大致用哪一类模型就基本定了。

第二段（在候选模型里对比，最终确定）：

确定大致方向之后，我会在每一类的候选模型里再做一次对比来定型，主要是查各模型的公开测评和资料，结合我们的场景需求来选，而不是盲选最贵的。以分类机器人为例，它属于轻量模型这一档，候选的有 GPT-4o-mini 和 Qwen-Turbo。因为我们的用户提问基本都是中文、而且偏口语化，所以我重点看的是"中文意图分类的准确率"这个维度，同时也参考了调用成本和响应速度。综合下来 Qwen-Turbo 在中文短文本分类上表现够用、成本更低、响应也快，所以分类机器人最终选了 Qwen-Turbo；其它几个 Agent 也是按同样的思路，结合它们各自最看重的能力维度去比对确定的。

7.3 热门模型特点介绍

这一章主要是给大家提一个醒。作为最火的，最新的，上热搜的模型，大家可以了解一下他的核心特点，做了什么改进。我知道我们都不是专业做模型的，所以对里面技术细节不会深入了解到。我的建议是，新模型，比如gpt5.5, deepseek v4 出来以后，让AI给你总结下他的核心提升和改变，特性就好了。这么做是防止面试官问（因为我之前有被问到过。 我主要提供个思路，打个样。以Deepseek v4为例，让AI总结一下特性。防止面试官和你聊最近最新Deepseekv4, 你啥也不知道。更重要的是这个思路，后面还有各种新模型的发布，都可以用这个策略快速准备下。

7.3.1 DeepSeek V4 新特性和创新

新特性：

1. 百万上下文成为默认能力。全系标配 1M token 上下文。推理计算量降至 V3 的约 27%，KV Cache 仅为 10%，能直接处理整本书、完整代码仓库、长文档分析。

2. 双模型体系覆盖不同场景。V4-Pro 提供万亿参数级高性能推理能力，而 V4-Flash 在维持相同架构的前提下降低激活参数和成本，实现高吞吐和低延迟的生产部署。

3. 推理效率和成本显著优化。通过压缩注意力和系统级优化，KV Cache 内存占用降低约 90%，整体推理吞吐明显提升，同时 API 成本显著低于同级模型。

4. 原生增强 Agent 执行能力。模型内置工具调用、分步推理和多模式思考能力，在复杂任务拆解和自动化工作流中具备更高稳定性和执行效率。

5. 开源和工业级部署能力并存。模型以 MIT 协议开放完整权重，支持多种硬件平台部署，使其不仅是研究模型，同时具备企业级落地能力

创新

1. 混合注意力机制重构长上下文计算。通过 CSA（压缩稀疏注意力）和 HCA（重度压缩注意力）的协同设计，将原本 O(n²) 的全量注意力转化为压缩与稀疏选择结合的计算模式，从根本上降低长序列计算成本 。

2. 稀疏索引与重要Token选择机制。模型引入索引器和 Top-k 筛选策略，只对最相关的上下文进行注意力计算，从“全量扫描”转变为“关键检索式推理” 。

3. mHC 超连接替代传统残差结构。通过引入流形约束的超连接机制改善深层网络中的信息传播稳定性，使万亿级模型训练更加可控和高效。

4. Muon 优化器提升训练稳定性。采用新型优化算法替代传统 AdamW，在大规模训练中实现更快收敛速度和更稳定的参数更新过程 。

5. 混合精度计算进一步压缩资源消耗。结合 FP4 与 FP8 的混合精度设计，在保持模型性能的前提下降低显存占用并提升计算吞吐。

6. Batch Invariance 提升工程可控性。通过保证相同输入在不同 batch 组织下输出一致，使模型在训练、推理和在线服务中具备更强的可复现性和稳定性。

RAG

RAG的话，其实我们的项目就是一个最好的经典RAG的例子。所以建议了解RAG的八股，知识后，可以去了解这个项目，这个项目把RAG最经典的环节都串起来了，并且这个项目配的模拟面试/项目复习的SKILL，就是去掌握项目，学习RAG各个环节的好方法。 该项目部分也会配一些该项目面试的真题，和前面的RAG理论相互补充。学好这个理论/项目，经典RAG就差不多了。

RAG进阶是：Graph RAG, Agentic RAG, 知识图谱这里。 我笔记总结了基本概念，我的策略是问到我就说会，讲述我的概念，但是我没有深入，因为这是RAG进阶技巧，对于那种对RAG要求比较高的岗位，专门做RAG的组可能会用。如果求职方向就是大模型应用，大模型算法，算法工程，没有指定RAG方向的话，没有余力的话，对于RAG的进阶部分，可以就只看一下笔记本节RAG进阶的概念，了解基本概念就好。

RAG部分我没有说写的特别详细，主要是为了记录RAG的要点和概述，像是一个用来背诵和记忆的八股手册，我会嵌入一些面试真题。大家主要用来复习，以及寻找面试真题答案的来源。

看本节笔记也能够理解RAG大概的步骤。这里更像一个概念卡片，带大家理解具体步骤。不过更具体的，深入的，或者不理解的地方，大家要自己去网上搜一下资料。因为这些东西其实都是比较现成的知识，基本上每本书都会讲，所以网上资料很多，大家要加强理解的就搜关键字，视频都行。

1.RAG全局总览

RAG 全称 Retrieval-Augmented Generation（检索增强生成）。一句话概括：让 AI 在回答前，先去一个"专属知识库"里查资料，再根据查到的内容来回答，而不是单纯靠它脑子里记住的东西瞎编。

可以类比成开卷考试：大模型是考生，知识库是允许带进考场的参考书。遇到问题先翻书找到相关章节，再组织答案——这样答得更准、更不容易胡说。

这一小节带大家用这张图来理解整个RAG系统的流程。

图 008 · 已恢复原图内容 · 点击放大

这张图把整个流程分成了两条链路。

一、离线知识库构建链路（绿色，"提前准备参考书"）

这部分是事先做好的，目的是把你的文档变成 AI 能快速查阅的知识库，一共 7 步：

• 1 原始文档：你的资料，比如 PDF、Word、网页等。
• 2 文档解析：把各种格式读出来，变成纯文字。
• 3 文档清洗：去掉乱码、页眉页脚、广告等垃圾内容。
• 4 文档分块：把长文章切成一小段一小段，方便后面精准检索。
• 5 元数据生成：给每段贴"标签"，比如标题、来源、时间、关键词等。
• 6 向量化：把文字转成一串数字（向量），让计算机能计算"语义相似度"。
• 7 向量数据库：把这些向量存进专门的数据库，等着被查询。

核心思想：把书"消化"成 AI 容易检索的形式，存起来备用。

二、在线用户问答链路（蓝/橙/紫色，"用户提问时实时处理"）

用户真正提问时走这条线，一共 9 步。

理解问题阶段（蓝 + 橙）

• 1 用户问题：用户输入问题。
• 2 上下文补全：结合前面的对话，补全省略的信息（比如"它"指的是谁）。
• 3 意图理解：搞清楚用户到底想问什么。
• 4 歧义判断：判断问题清不清楚。如果不清楚，就走 澄清追问（反问用户一句，再回到第 2 步重新理解）；如果清楚，就继续往下。

检索与生成阶段（蓝 + 紫）

• 5 查询处理：把问题"优化"得更适合检索，常见手段有改写、扩展、拆解等。你只需知道这一步是"把问题打磨得更好查"即可。
• 6 检索与筛选：去知识库里找出最相关的几段资料（相似度计算、按权限和元数据过滤等）。这是 RAG 里的 "R（检索）" 核心。
• 7 重排序 / 压缩：把找到的资料排个序、去重、精简，只留最有用的部分。
• 8 生成回答：把"问题 + 检索到的资料"一起交给大模型，让它基于资料生成答案，并附上引用出处、做事实核查，答不了就拒答，避免乱编。这是 RAG 里的 "G（生成）" 核心。
• 9 返回用户：把最终答案返回给用户。

2.RAG vs 微调

图 009 · 已恢复原图内容 · 点击放大

3.RAG评价指标

（Reference: 大模型RAG实战 ：4.5小节）

Rag场景下，比较著名的评估模型方法的框架是：RAGAS。RAGAS方法在评估过程中主要使用忠诚度，答案相关性，和上下文相关性来评判整个RAG系统中llm生成答案的质量。 RAGAS方法的一个优点是不需要参考答案。

具体来讲，忠诚度是指用户判断LLM的输出是否是根据召回文本的内容生成的。

答案相关性是衡量生成的答案是否和用户的问题相关的。

上下文相关性是用于判断召回文本是否和用户问题相关的。

（下面的可以挑一个具体的指标来展开给面试官讲，都展开讲太长了，而且内容有点抽象，如果讲完面试官不懂，可以给他举具体的例子讲解）

具体来讲：

忠实度的计算方式通常包括两个步骤。1：使用LLM生成的问题和答案，让大模型生成多个陈述。 2. 让LLM判断是否可以通过召回的文本，推断出这些陈述。 最后采用能够推断出来的陈述/总陈述量作为忠诚度的评分。

答案相关性：根据LLM的回答生成若干个假问题，然后计算假问题和真实问题的相似度，将相似度平均值作为答案相关性的评分。

上下文相关性：让LLM挑选出召回文本片段中能够回答用户问题的文本子集，用文本子集占召回文本的比例作为上下文的相关性数值。

4. 常见的向量数据库

常见的向量数据库有Milvus, Weaviate, Chroma, Qdrant。具体来讲：

Milvus 建立在Faiss, Annoy等开源向量搜索库的基础上，能够支持数十亿级别甚至万亿级别的向量搜索库，并且检索速度快，万亿向量数据集上检索速度的延迟可以控制在毫秒级。

除此之外，Milvus还支持数据分片，数据持久化，流式数据摄取，混合搜索等很多高级功能。具有高可用性，高性能和易扩展的特点，用户还可以将其部署在Kubernetes上。并且可靠性强，具有数据复制和故障恢复的功能。

Weaviate 具有鲁棒性，云原生性和可扩展性的特点。它结合了向量搜索和结构化过滤的能力，同时拥有云原生数据库的容错性和可伸缩性。在百万级的向量数据上，可以实现毫秒级的检索。它可以方便调用OpenAI, Cohere以及Hugging Face平台提供的先进的数据向量化接口和模型。缺点是：目前只支持HNSW这一种检索算法。

Chroma 是一款AI原生的开源向量数据库，主要功能和特点围绕AI应用开发而设计。主要针对大模型RAG场景，目前只实现了单机方案。相比Weaviate和Milvus，Chroma更轻量化。 检索上实现了FAISS索引，不支持GPU加速。

图 010 · 已恢复原图内容 · 点击放大

5. RAG的重要步骤

参考视频

▶ 抖音讲解视频 视频ID：7522119790514998591（原文档内嵌播放器） 点击观看视频 ↗（需联网）

5.1 意图识别

意图识别位于 RAG全局总览的第3，4（图中橙色的部分）

是什么？

意图识别位于 RAG 的检索前处理阶段，核心作用是先理解用户到底想问什么，再决定后面应该如何检索。它不是简单给用户问题打一个分类标签，而是要把用户的自然语言问题转成后续 RAG 可以执行的检索计划。

在实际场景中，用户的问题经常是不完整、口语化、依赖上下文的。比如用户问“这个怎么申请？”“它和那个有什么区别？”如果直接把原句送进向量数据库，很容易召回错误内容。因此在正式检索前，系统需要先判断用户的真实意图、问题中的关键对象、时间地点等限制条件，以及这个问题是否需要先澄清。

怎么做？

意图识别通常会做三件事。

第一，判断用户的问题类型。比如用户是在问定义、查事实、问流程、做比较、要总结、查政策，还是排查问题。不同类型的问题适合不同的处理方式：事实类问题通常适合精确检索，比较类问题适合拆成多个子问题，总结类问题需要召回更大范围的上下文，政策类问题则通常需要结合地区、时间、政策类型等元数据过滤。

第二，抽取实体和槽位。实体是用户问题中真正关心的对象，槽位是检索时需要用到的限制条件。例如“2024 年上海人才补贴怎么申请？”中，主题是“人才补贴”，地区是“上海”，时间是“2024 年”，问题类型是“申请流程”。这些信息可以直接用于过滤文档集合，避免在整个知识库里盲目检索。

第三，决定检索策略。如果用户问题已经明确，可以直接检索；如果问题表达口语化或依赖上下文，可以先做查询改写；如果用户用词和文档用词可能不一致，可以做查询扩展；如果问题比较短、抽象，可以用 HyDE 生成假设性文档辅助召回；如果问题包含多个子目标，可以进行查询分解；如果缺少关键信息，就应该先向用户澄清，而不是强行检索。

比如用户问“这个怎么申请？”，如果上一轮正在讨论“上海人才租房补贴”，系统就可以把它改写成“上海人才租房补贴怎么申请？”再检索。如果没有上下文，系统就应该追问“你想申请的是哪类事项？比如人才补贴、项目申报、发票报销，还是其他业务？”这就是意图识别在多轮 RAG 中的价值：能补全的自动补全，不能确定的先澄清。

图 011 · 已恢复原图内容 · 点击放大

在工程实现上，可以用规则、小模型分类器，也可以直接用大模型做结构化理解。现在更常见的方式是让大模型输出一个结构化结果，例如：

{
  "intent": "policy_query",
  "entities": ["人才补贴"],
  "filters": {
    "region": "上海",
    "year": "2024"
  },
  "needs_clarification": false,
  "route": "policy_knowledge_base",
  "retrieval_strategy": "metadata_filter",
  "rewrite_query": "2024年上海人才补贴政策的申请条件、补贴标准和办理流程是什么？"
}

这个结果比单纯输出一个 policy_query 更有用，因为它可以直接驱动后续流程：intent 决定问题类型，filters 用于元数据过滤，route 决定去哪个知识库，retrieval_strategy 决定是直接检索、改写、扩展、HyDE、分解还是澄清。

如何判断意图识别做得好不好？

我们需要从意图分类，槽位抽取，是否需要澄清，路由是否正确这几个维度来综合评估。

意图分类可以看 整体准确率、精确率、召回率、F1；

实体和槽位抽取可以看 Slot 精确率、Slot 召回率、Slot F1；

是否需要澄清可以单独看澄清判断的准确率和召回率；

路由是否正确可以看 Route Accuracy；

最终还要看加入意图识别后，正确文档是否更容易进入 Top-K，答案准确率是否提升。

指标释义：❗如果还不明白就问AI，都是标准指标，也确实有点难绕。

整体准确率 (Accuracy)：所有判断里预测对（包括对和错两类判定都对）的样本占总体的比例。

精确率 (Precision)：模型预测为“是”的结果里，真正正确的比例（主要防误报、防乱判）。

召回率 (Recall)：在实际为“是”的所有样本中，模型成功找出来多少的比例（主要防漏报、防漏判）。

F1 值 (F1-Score)：精确率和召回率的调和平均值，两者双高才能拿到高分，反映综合好坏。

槽位 (Slot)：从用户提问里抽出来的结构化属性约束条件，如时间、地区、主题。

前 K 个检索结果 (Top-K)：指搜索引擎按相关性排序最终返回给用户的前 K 个文档片段。

平均倒数排名 (MRR)：评判第一个正确结果排在第几名，排名越靠前（第一名倒数为1，第二名倒数为0.5）分值越高。

前 K 个命中率 (Hit@K)：测试样本集中，检索前 K 个文档包含有正确答案的样本比例。

归一化折损累计增益 (nDCG)：不仅衡量找回的文档是否相关，还非常看重最相关的文档是不是排在最前排

5.2 输入文件处理

在进行文档分割前，我们先要对输入的各种类型的文件进行处理，转换成文本内容，进行切块。这个地方倒是算不上是RAG里面的重要内容，属于传统方法的内容。不过我们的项目是以PDF作为输入，转换成Markdown的文本，进行后续切块的，根据粉丝朋友们反馈，这里面面试被问的很多，所以我干脆把这里沉淀成专题笔记：PDF到MarkDown的处理，相关的面试真题可以参考这里：PDF处理问题。

我觉得这个知识点纯粹是为了应付你使用我们笔记RAG项目，面试官可能会问到的相关的问题。如果你没有用我们项目，我觉得你可以放一放这个问题，这个问题不算是RAG里面很重要的知识点。

5.2.1 整体处理逻辑

整体处理逻辑很清晰，我们把工业化的处理分成5个连续的阶段：

文件体检：检查 PDF 是否重复、加密、损坏或方向异常，确认文件可以正常处理。

逐页判断：判断每页属于原生文本、扫描、混合、复杂布局还是异常页面。

按页面类型解析：为不同类型的页面选择对应的解析方法。

统一结果：将不同解析结果按页码和阅读顺序整理成统一格式。

结果检查：检查漏页、乱码、重复、错序及表格错误，确保最终内容完整、准确、可用。

图 012 · 已恢复原图内容 · 点击放大

很好理解对吗？接下来我们逐一讲解。

5.2.2 步骤一：文件基础体检

基础体检只负责文件级别的准入和预处理，不负责提取正文。

• 文件哈希已经存在：视为重复文件，跳过处理或复用已有结果。
• 文件哈希发生变化：视为文件新版本，重新处理。
• PDF 有密码：先获取密码或解密；无法解密则停止处理并记录原因。
• PDF 损坏或无法打开：尝试修复；修复失败则要求重新提供文件。
• 页面方向错误：在文字提取或 OCR 前进行方向校正。
• 总页数可以读取：记录总页数，处理完成后用于检查是否漏页。

文件通过基础体检后，进入逐页分类。

5.2.3 步骤二：逐页判断类型

页面类型通常通过程序规则判断。可以使用 PyMuPDF 读取每页的文字、图片和位置信息，再综合判断：

• 页面中有多少可正常读取的文字；
• 页面是否主要被一张或多张图片覆盖；
• 提取出来的文字是否存在大量异常字符；
• 少量文字是否只是跨页重复的水印、页眉或页脚；
• 页面是否存在多栏、表格、表单等复杂布局。

根据这些信息，将页面分为以下类型。

原生文本页

页面存在完整、可正常读取的文字层。文字通常可以在 PDF 阅读器中选中、复制和搜索

扫描页

页面主体是一张扫描图片，没有可靠的正文文字层。人可以看到图片中的文字，但普通 PDF 文字提取工具无法直接读取。

有些扫描页可能带有页码或水印文字层，因此不能仅根据“是否提取到文字”判断，还需要结合有效正文数量和图片覆盖情况。

混合页

页面既包含可以直接提取的正文，又包含图片中的重要文字或信息。

例如正文是原生文字，但页面中插入了带文字的软件截图。普通装饰图片或 Logo 不会使页面自动成为混合页，关键是图片中是否存在需要提取的信息。

复杂布局页

页面包含多栏、表单、复杂表格、重要图表、公式或大量图文混排内容。虽然可能存在文字层，但普通提取方式容易打乱阅读顺序，或者丢失表格、图片和公式所表达的信息。

异常页

页面出现文字乱码、解析报错、内容为空，或者无法可靠判断属于上述哪种类型。

页面分类不一定百分之百准确。规则能够明确判断的页面自动处理，判断不清的页面交给更强的解析工具、多模态模型或人工复核。

5.2.4 步骤三：按页面类型解析

第二步得到页面类型后，第三步与其逐项对应。

处理原生文本页

使用 PyMuPDF 提取页面文字及基本位置信息。如果还需要识别标题、正文、列表等文档结构，可以使用 Unstructured、LlamaParse 等工具。

PyMuPDF 更擅长快速获取 PDF 中已有的文字、图片和坐标；Unstructured、LlamaParse 更擅长将内容整理成标题、正文、列表和表格等结构化元素。

处理扫描页

先将 PDF 页面渲染成图片，再使用 OCR 识别图片中的文字。中文文档应选择支持中文的 OCR 模型。

如果扫描质量较差，可以先进行旋转校正、去噪、倾斜校正或对比度增强，再执行 OCR。OCR 结果应保留页码，低质量页面需要重新识别或人工检查。

处理混合页

混合页需要同时使用两种方式：

1. 直接提取页面中已有的原生文字。
2. 提取或截取包含重要信息的图片区域。
3. 对这些图片区域执行 OCR，或者使用多模态模型理解图表内容。
4. 合并原生文字和图片识别结果，并删除重复内容。

PyMuPDF 可以发现和提取图片，但通常不能理解图片内容；OCR 负责识别图片中的文字，多模态模型可用于理解图表、流程图等更复杂的视觉信息。

处理复杂布局页

复杂布局页可以先交给 Unstructured、LlamaParse 等工具进行版面解析。这些工具会识别标题、正文、栏位、表格和图片区域，并返回元素类型、页面位置和大致阅读顺序。程序再按照这些结果组合内容，不应让大模型随意改写原文。

具体处理方法如下：

• 分栏页面：使用 Unstructured、LlamaParse 或布局模型识别左右栏及各文本块的位置，按照“先读完一栏，再读取下一栏”的顺序重新排列文本。工具给出的顺序不正确时，可以根据文本块坐标补充排序规则。
• 表格：原生 PDF 中边界较清楚的表格可以使用 Camelot 提取；扫描表格先通过 OCR 或表格识别模型识别单元格；图文混排文档也可以直接使用 Unstructured 或 LlamaParse 提取表格。提取结果转换成 Markdown、HTML 或 CSV，并抽查表头、合并单元格、跨页表格和关键数字。如果自动提取破坏了行列关系，则保留表格截图并进入人工复核。
• 含文字的图片：先用 PyMuPDF 或版面解析工具确定并提取图片区域，再使用 OCR 识别其中的文字，最后按照图片在页面中的位置插回正文。
• 流程图、架构图和统计图：普通 OCR 只能读取图中的文字，无法完整理解节点、箭头和数据关系，因此可以将图片及附近正文交给多模态模型生成说明，并保留原图和页码以便核对。
• 公式：使用支持公式识别的 OCR 或文档解析工具转换为 LaTeX；识别不可靠时保留公式图片，并将它与前后正文关联。

自动工具仍然无法正确恢复阅读顺序或内容结构时，将该页标记为需要人工复核。

处理异常页

• 文字乱码：先更换一种 PDF 解析器重新提取；仍然乱码时，将页面渲染成图片并使用 OCR。
• 空白页面：保留页码和页面记录，不输出正文。
• 解析报错或类型无法确定：使用多模态模型辅助判断；仍无法可靠处理时进入人工复核。

无论页面采用哪种解析方式，得到文字和位置信息后，还要处理页眉、页脚、页码和水印。具体方法是比较连续页面中处于相同顶部或底部位置的文本；如果同一内容反复出现，就将其识别为页眉、页脚或水印并从正文中移除。页码可以通过固定位置和连续数字识别。处理完成后再进入统一结果阶段。

5.2.5 步骤四：统一结果

走过不同解析路线的页面，可能分别产生普通文字、OCR 文字或结构化元素。最后一步不再重新判断和处理页面问题，只负责把这些结果整理成统一形式：

1. 将不同工具的输出转换成相同的文本结构。
2. 按 PDF 原始页码排列所有页面。
3. 将同一页内已经确认顺序的标题、正文、列表和特殊元素组合起来。
4. 输出为 Markdown 或带页码的结构化文本。

最终结果建议至少保留：

• 原始文件名；
• PDF 页码；
• 标题和正文；
• 列表结构；
• 可以可靠恢复的表格；
• 图片或公式的说明及对应位置；
• 需要人工复核的页面标记。

无论输出成哪种格式，都应能从文本追溯到原始 PDF 页面。

5.2.6 步骤五：结果检查

PDF 转文本完成后，应进行一次简单验收：

• 输出页数是否与原 PDF 对应，是否漏页；
• 是否仍存在大量乱码；
• 页眉、页脚和水印是否大量残留；
• 多栏页面的阅读顺序是否正确；
• OCR 是否遗漏整页或大段内容；
• 表格的表头、行列和关键数字是否正确；
• 原生文字与 OCR 文字是否重复；
• 标记为异常的页面是否已经复核。

检查通过后，才得到可供后续系统使用的最终文本。

5.2.7 讲解视频

https://www.bilibili.com/video/BV1gF8Z6WEGW/?spm_id_from=333.1387.homepage.video_card.click&vd_source=144bec9c3f54e465073138bed788be1b

5.3 切割

分块策略，在RAG这个面试模块里，算是比较高频的考点了，在25年的12月份，我去面试的时候，很多公司就问过，到今年的2026年7月，宇树科技Agent开发一面面试，依旧在问RAG切块的策略。 本篇笔记重构于2026年8月份，我查阅了一些数据，彻底将这一部分重构了。同时加入了若干面试真题，放在该小节最后，同时也录制了讲解视频，我希望达到的目标是：

1. 即使你没有RAG切块方面的前置知识基础，你看了本篇笔记对应的讲解视频，能够理解这些切块的基本思路，不同方法是干什么，选型策略。
2. 结合对应的笔记，能够进一步巩固和背诵相关知识点。
3. 结合章节后面的面试真题，彻底让你在面试中，对于RAG切块问题能够胸有成竹。 今本上本小节所有的内容，都是面试考察过的内容，对应着一些面试问题的回答思路，该小节的内容还是值得大家背诵一下的。

5.3.1 基本概念

什么是文档分块

文档分块（Chunking）是指把一篇长文档拆分成多个较小且相对完整的文本块（Chunk），再分别进行向量化、索引和检索。在 RAG 系统中，分块连接了文档解析、向量检索和大模型生成，是影响召回质量的关键环节。

一个理想的 Chunk 应同时满足以下要求：

• 长度不超过嵌入模型和大语言模型的输入限制；
• 块内尽量只表达一个完整、集中的主题；
• 脱离原文后仍具有足够的上下文，可以被独立理解；
• 保留标题路径、页码、来源和父文档 ID 等元数据，便于追溯原文。

为什么需要分块

第一，满足大语言模型的上下文窗口限制。直接输入整篇长文档可能超过模型的最大上下文长度。分块后只把与问题相关的内容送入模型，可以控制上下文规模。

第二，提高生成上下文的质量。召回内容过多、过长会增加 Token 成本，并产生“Lost in the Middle”问题，使真正有用的信息被大量无关内容掩盖。

第三，满足嵌入模型的输入限制。嵌入模型通常存在最大 Token 数，超出后可能被截断。例如部分 BGE 或 Sentence-Transformers 模型的上限为 512 Tokens，过长文本会造成后半部分语义丢失。

第四，提高检索精度。一个文本块如果同时包含多个主题，其向量表示会被不同语义平均和稀释，用户查询某个细节时不容易准确召回。较小且主题集中的文本块通常更容易与查询匹配。

图 013 · 已恢复原图内容 · 点击放大

5.3.2 常见分块策略

固定长度分块

固定长度分块按照固定字符数或 Token 数切分文档，并可设置 Overlap，使相邻块保留一部分重复内容。

LlamaIndex 中可以使用 TokenTextSplitter：

from llama_index.core.node_parser import TokenTextSplitter

splitter = TokenTextSplitter(
    chunk_size=500,
    chunk_overlap=50,
)
nodes = splitter.get_nodes_from_documents(documents)

例如，将一篇 1500 Tokens 的文档按照 500 Tokens 切分：

输入文档：
[1 ...................................................... 1500 Tokens]

输出：
Chunk 1：[1-----------500]
Chunk 2：                [501--------1000]
Chunk 3：                                  [1001--------1500]

为了避免关键信息恰好落在两个块的边界，可以让相邻块保留部分重复内容：

Chunk 1：[--------------------]
Chunk 2：                [--------------------]
                         ↑ Overlap

优点：实现简单、速度快、块大小稳定，便于控制索引规模和成本，适合作为快速验证 RAG 流程的基线。

缺点：可能从句子或段落中间切断，不理解文档结构和语义；Overlap 过大还会导致索引冗余和重复召回。

适用场景：文本结构不明显、需要快速建立基线、对切分边界要求不高的场景。

递归分块

递归分块按照一组从粗到细的分隔符逐级切分。它通常先尝试段落，再尝试句子、标点、空格，最后使用字符或 Token 强制切分作为兜底。

段落 → 换行 → 句子 → 标点 → 空格 → 字符或 Token

LlamaIndex 中可以使用 SentenceSplitter：

from llama_index.core.node_parser import SentenceSplitter

splitter = SentenceSplitter(
    chunk_size=500,
    chunk_overlap=50,
)
nodes = splitter.get_nodes_from_documents(documents)

LangChain 中的对应工具是 RecursiveCharacterTextSplitter。两者名称不同，但都具有从自然边界到细粒度边界逐级切分的思想。

递归分块的完整过程如下：

1. 先按照段落切分；
2. 检查每个片段是否超过 chunk_size；
3. 如果某个段落仍然太长，再按照句子切分；
4. 如果句子仍然太长，再按照标点、空格等更细的边界切分；
5. 最后使用字符或 Token 强制切分作为兜底；
6. 将较小片段重新合并成接近目标长度的 Chunk，并保留适量 Overlap。

输入：一篇长文档
        ↓ 按段落切
  [段落 A] [超长段落 B] [段落 C]
                  ↓ 按句子继续切
           [句 1] [句 2] [超长句 3]
                              ↓ 按标点或字符切
                         [片段 3.1] [片段 3.2]

递归分块器本身通常不真正识别标题。标题层级需要由前面的文档解析器提取，再作为结构边界或元数据传给分块器。如果输入没有段落换行和正常标点，递归分块仍能运行，但会逐步退化为字符或 Token 级强制切分，只能保证长度不超限，不能保证语义边界正确。

优点：尽量保留段落和句子的完整性；速度快，不需要调用模型；是普通 RAG 项目中最常用的分块方式。

缺点：依赖文本解析和清洗质量；OCR 错误换行可能造成误切；它并不真正理解标题和主题变化，输入没有正常换行或标点时会退化为固定长度切分。

适用场景：普通文章、说明书、制度和技术文档，以及已经完成基本清洗的非结构化文本。

图 014 · 已恢复原图内容 · 点击放大

结构化分块

结构化分块利用文件本身的组织结构确定边界，而不是只根据长度切分。

• Markdown：按照标题、段落和代码块切分；
• HTML：按照 h1～h6、p、li、table 等标签切分；
• DOCX：按照 Heading 样式、段落、列表和表格切分；
• 代码：按照文件、类、函数和方法切分；
• PDF/PPT：按照标题、正文、列表、表格、图片和页面区域切分。

LlamaIndex 提供了 MarkdownNodeParser、HTMLNodeParser、JSONNodeParser、CodeSplitter 等解析器。例如：

from llama_index.core.node_parser import MarkdownNodeParser

parser = MarkdownNodeParser()
nodes = parser.get_nodes_from_documents(documents)

结构化分块的典型处理流程如下：

原始文件
→ 文档解析或版面分析
→ 识别标题、正文、表格、列表和代码等结构单元
→ 在超长结构单元内部继续递归切分
→ 生成 Chunks，并保存标题路径、页码和来源等元数据

Reader 负责读取和提取文件内容，NodeParser 负责形成最终用于索引的节点。对于复杂 PDF，仅提取纯文本通常无法保留正确阅读顺序，需要结合字号、坐标、页面区域和版面模型识别标题、分栏、表格与图片；扫描 PDF 还需要先进行 OCR。

如果一个章节仍然过长，可以先按标题进行结构化分块，再在章节内部使用递归分块。因此，结构化分块和递归分块经常组合使用。

优点：能够保留标题与正文、表头与数据、函数与代码之间的关系，结果更容易引用和追溯。

缺点：不同文件需要不同解析器；复杂 PDF 需要根据字号、坐标和版面推断结构；解析错误会直接影响后续分块质量。

适用场景：Markdown、HTML、Word、代码，以及包含标题、列表和表格的 PDF/PPT。

语义分块

语义分块根据主题或语义变化确定边界。常见实现会先切句，再使用嵌入模型计算相邻句子或句子窗口的语义距离，在语义突变的位置设置断点，并将连续且语义相近的句子合并成一个 Chunk。

LlamaIndex 中可以使用 SemanticSplitterNodeParser：

from llama_index.core.node_parser import SemanticSplitterNodeParser

splitter = SemanticSplitterNodeParser(
    embed_model=embed_model,
    breakpoint_percentile_threshold=85,
)
nodes = splitter.get_nodes_from_documents(documents)

阈值需要根据真实语料调整，数值越低通常越容易产生更多分块。语义分块仍需设置最大 Token 上限，避免产生过长的 Chunk。

基于 Embedding 的语义分块通常包含以下步骤：

1. 先把文档切成句子；
2. 为单个句子或句子窗口生成向量；
3. 计算相邻句子的语义相似度或距离；
4. 在语义差异明显的位置设置断点；
5. 将语义相近的连续句子合并为一个 Chunk；
6. 使用最大 Token 数限制 Chunk 上限。

句 1 ──相似── 句 2 ──相似── 句 3 ║语义突变║ 句 4 ──相似── 句 5

输出：
Chunk 1：句 1 + 句 2 + 句 3
Chunk 2：句 4 + 句 5

语义分块比递归分块慢，是因为递归分块主要执行字符串操作，而语义分块需要对大量句子运行嵌入模型、计算相似度，有些算法还需要进行多轮合并。

优点：块内主题更一致，不完全依赖换行和格式，能够缓解语义在错误位置被切断的问题。

缺点：需要对大量句子计算 Embedding 和相似度，建库速度较慢；阈值需要实验调整；块大小不固定。

适用场景：会议纪要、访谈、长篇报告、OCR 后段落结构不可靠的文本，以及一个自然段中经常包含多个主题的内容。

命题分块

命题分块使用大语言模型把原文转换成多条能够独立理解的事实或观点。它可能拆开复合句、补全省略主语、消解代词指代，并进行少量改写，因此不仅是文本切割，也属于内容转换和索引增强。

LlamaIndex 没有像 SentenceSplitter 一样通用的内置命题分块器。因此，命题提取逻辑需要开发者自己实现，LlamaIndex 主要负责承载节点和建立索引。通常需要自行组合以下流程：

使用 SentenceSplitter 粗切原文
→ 调用 LLM 提取命题列表
→ 每条命题创建一个 TextNode
→ 在 metadata 中保存 parent_id、页码和来源
→ 使用 VectorStoreIndex 建立索引

下面是命题分块的流程伪代码。它用于说明职责划分，并不是可以直接运行的 LlamaIndex 内置 API：

parent_chunks = sentence_splitter.get_nodes_from_documents(documents)

proposition_nodes = []

for parent_chunk in parent_chunks:
    # 核心步骤需要自己实现：调用 LLM，把原始段落拆成命题列表
    propositions = extract_propositions_with_llm(parent_chunk.text)

    for proposition in propositions:
        proposition_node = create_llamaindex_node(
            text=proposition,
            parent_node=parent_chunk,
        )
        proposition_nodes.append(proposition_node)

index = VectorStoreIndex(proposition_nodes)

这里的 extract_propositions_with_llm() 和 create_llamaindex_node() 都是为了说明流程而写的自定义函数名，不是 LlamaIndex 自带方法。前者负责通过 Prompt 和 LLM 提取命题，后者负责把命题包装为 LlamaIndex 节点。

其中，“把已经提取出的命题包装成节点”可以使用 LlamaIndex 自带的 TextNode：

from llama_index.core.schema import TextNode

nodes = [
    TextNode(
        text=proposition,
        metadata={
            "parent_id": parent_id,
            "source": source,
            "page": page,
        },
    )
    for proposition in propositions
]

这段 TextNode 代码本身不负责切分，也不会自动生成命题。它成立的前提是业务代码已经完成以下工作：

1. 调用 LLM 分析原始段落；
2. 得到 propositions 命题列表；
3. 记录每组命题对应的原始段落 ID；
4. 再把每条命题保存为 TextNode。

text 和 metadata 是 TextNode 提供的字段；parent_id、source 和 page 是项目自定义的 metadata 键，并不是 LlamaIndex 自动生成的属性。如果需要使用 LlamaIndex 原生的父子节点关系，也可以通过节点的 relationships 字段保存父节点关系。

例如，原文为：

张三于 2024 年加入公司，并担任技术负责人。
他此前在 A 公司工作了五年。

经过命题转换后可以得到：

1. 张三于 2024 年加入当前公司。
2. 张三担任当前公司的技术负责人。
3. 张三此前在 A 公司工作了五年。

这里不仅拆开了复合句，还把“他”还原成了“张三”，使每条事实脱离原段落后仍能独立参与检索。

命题文本适合生成向量和参与检索，但不应直接替代原文作为最终事实依据。系统应同时保存命题与原文的映射，回答和引用时通过 parent_id 回到原始段落。

推荐同时保存以下信息：

• 命题文本：用于生成向量和检索；
• 原始段落：用于回答、引用和事实核对；
• parent_id：连接命题与原始段落；
• 页码和来源：用于定位和追溯原文。

检索到命题后，再根据 parent_id 找到对应原始段落，并把原文而不是孤立命题交给大模型生成答案。

优点：每个检索单元只表达一个事实，粒度精细；能够补全指代，适合事实型问答。

缺点：需要调用 LLM，速度慢、成本高；模型可能遗漏、误解或错误改写事实。

适用场景：事实密集的企业知识库，以及人物、产品属性、事件和关系检索。

5.3.3 分块选型技巧和原则

核心原则：先选主策略，再调分块粒度

分块选型不是从多种方法中随意挑选，也不是把所有方法同时使用，而是按照一条明确的决策链进行：

判断文档是否具有可靠结构
→ 选择主分块策略
→ 根据检索目标调整 Chunk 粒度
→ 使用 Overlap 或上下文扩充解决边界问题
→ 根据召回结果继续调优
→ 通过评测确定最终方案

其中，文档结构决定“在哪里切”，检索目标决定“切多大”，Overlap、句子窗口和父子块决定“切完后如何补充上下文”，评测负责验证整个方案是否有效。几类因素承担的作用不同，不应混为同一级别的选型条件。

图 015 · 已恢复原图内容 · 点击放大

第一步：根据文档结构选择主分块策略

首先判断文档是否存在可靠的自然边界。

如果文档结构清晰，应优先尊重原始结构：

• Markdown、HTML、Word：先按照标题、章节、段落等结构切分；
• 代码：按照文件、类、函数和方法切分；
• PDF/PPT：先完成版面解析，再按照标题、正文、列表和表格等结构切分；
• FAQ、商品资料、人物信息等强结构化数据：一条完整记录本身就是一个语义实体，可以直接作为一个 Chunk，不必强行拆分。

如果结构单元仍然过长，再在结构单元内部使用递归分块。

如果文档缺少可靠结构，则根据文本质量选择：

• 普通文章、说明书、制度：使用递归分块；
• OCR 错乱、换行不可靠但句子语义仍可识别：先清洗文本，再考虑递归分块或语义分块；
• 会议纪要、访谈、长篇报告等主题频繁变化的文本：考虑语义分块；
• 事实高度密集，并且需要检索独立人物、属性或关系：考虑命题分块，同时保留命题与原文的映射。

因此，结构化分块、递归分块、语义分块和命题分块不是简单的优劣关系，而是分别解决不同的数据形态问题。

第二步：根据检索目标确定 Chunk 粒度

确定主分块策略后，再根据用户问题所需的证据粒度决定 Chunk 大小。

• 只需要定位相关文档或章节：Chunk 可以相对大，以保留完整上下文；
• 需要定位具体条款、步骤、句子或事实：Chunk 应相对小，以提高检索精度；
• 用户问题通常对应一个完整段落：让 Chunk 尽量覆盖一个自然段落或语义单元；
• 一个 Chunk 中经常包含多个主题：说明粒度过大，应减小 Chunk，或者使用语义分块寻找主题边界；
• 检索结果很准确，但回答缺少前后文：说明检索粒度合适、生成上下文不足，不应直接增大所有 Chunk，而应使用句子窗口、父子块或层级索引扩充上下文。

理想状态不是 Chunk 越小或越大越好，而是一个 Chunk 尽量对应用户问题所需要的最小完整证据单元。

第三步：使用默认方案建立实验基线

当项目处于早期阶段，尚未积累足够的真实问题和评测数据时，可以先采用一个低成本、容易解释的基线方案：

结构化解析
→ 在超长结构单元内部递归分块
→ 设置有限 Overlap
→ 保存标题、页码和来源等元数据

初始实验可以从约 400～600 Tokens 的 chunk_size 和 10%～20% 的 Overlap 开始。

默认方案不是最终选型原则，也不与“根据文档类型选择”冲突。它只是在信息不足时提供一个可运行的起点。获得真实召回结果后，仍然要根据文档特点和问题类型进行调整。

第四步：根据召回问题定向调整

运行基线方案后，应根据实际问题判断需要修改哪一层，而不是盲目调大或调小 Chunk。

• 正确内容经常召回不到：Chunk 可能过大或结构边界不合理，应减小 Chunk、改善结构解析，或调整检索方式；
• 已召回正确内容，但上下文不完整：适当增加 Overlap，或使用句子窗口、父子块扩充上下文；
• 一个 Chunk 中经常存在多个主题：减小 Chunk，或改用语义分块；
• Top-K 结果高度重复：减少 Overlap，并对召回结果去重；
• 标题与正文经常分离：改善结构解析，并把标题路径写入 Chunk 元数据；
• 表格问题效果差：将表头与数据行绑定，按照完整记录或逻辑区域分块；
• OCR 文档切分混乱：先清理页眉页脚、水印和错误换行，再调整分块策略。

这一步的关键是先定位问题属于“解析错误、边界错误、粒度错误还是上下文不足”，再采取对应措施。

第五步：通过评测确定最终方案

不存在适用于所有项目的统一 Chunk Size。最终方案应由真实问题的评测结果决定。

可以准备一批真实查询，并标注每个问题对应的正确证据，分别测试不同的主策略、Chunk Size 和 Overlap。重点观察：

• 正确证据是否出现在 Top-K 中；
• 正确证据的排序是否靠前；
• 回答是否得到召回证据支持；
• 页码、章节和来源引用是否正确；
• 检索结果的重复率；
• 平均上下文 Token 数；
• 索引规模、建库时间和查询延迟。

最终选择的方案，应是在真实语料和真实问题上，检索精度、上下文完整性、成本与延迟之间取得最好平衡的方案。

5.3.4 常见面试问题

5.3.4.1 常见的分块策略有哪些？各自有什么优缺点？

💡 答题思路

这个问题并不是出自真实面试题，而是我为了帮助大家掌握基础知识主动添加的。现实面试中通常不会直接这样问，因为这种问法比较固定，也比较偏向概念背诵。

但我仍然把它放在这里，是希望大家能够有意识地记住常见分块策略，以及每种策略的基本原理、优缺点和适用场景。后面可以看到，真实面试中的问题通常会比这道题更深入，例如追问项目为什么选择某种策略、内容跨块怎么办、Chunk Size 如何确定，以及分块效果如何评测。

这些真实问题虽然问法不同，但回答的思路和出发点仍然来自本题涉及的理论基础。只有先掌握不同分块策略的特点，后面才能根据文档类型和实际问题完成选型与调优。（参考答案有点长，面试可以稍微简化一点）

📝 参考答案

RAG 中常见的分块策略主要包括固定长度分块、递归分块、结构化分块、语义分块和命题分块。

第一种是固定长度分块，也就是按照固定的字符数或 Token 数切分文档。它的优点是实现简单、速度快、块大小稳定，便于控制索引规模和成本；缺点是不理解文档结构和语义，可能把一个完整句子、段落或步骤从中间切断。因此，它适合快速建立基线，或者处理结构不明显且对语义边界要求不高的文本。

第二种是递归分块。它会按照从粗到细的分隔符逐级尝试切分，例如先按段落，再按换行、句子、标点、空格切分，最后才使用字符或 Token 强制切分。它的优点是速度快、不需要调用模型，并且能尽量保留自然语义边界；缺点是依赖文本解析和清洗质量，遇到 OCR 错误换行、标点缺失或格式混乱时，仍然可能产生不合理的分块。它是普通文章、说明书和技术文档中最常用的基线方案。

第三种是结构化分块，也就是利用文档自身的结构进行切分，例如 Markdown 标题、HTML 标签、Word Heading、代码中的类和函数，以及 PDF 中识别出的标题、正文和表格。它的优点是能够保留标题与正文、表头与数据、函数与代码之间的关系，结果也更容易引用和追溯；缺点是依赖文档解析器，不同文件需要不同的处理方式，复杂 PDF 或扫描件还需要版面分析和 OCR。实际项目中通常先进行结构化分块，如果某个结构单元仍然过长，再在内部使用递归分块。

第四种是语义分块。它通常先把文档切成句子，再使用 Embedding 计算相邻句子的语义相似度，在主题发生明显变化的位置建立边界。它的优点是块内主题更加集中，不完全依赖换行和格式；缺点是需要额外进行向量计算，建库速度较慢，分块阈值也需要通过实验调整。它适合会议纪要、访谈和主题变化频繁的长文本。

第五种是命题分块。它使用大语言模型把原文转换成多条能够独立理解的事实或观点，例如拆开复合句、补全省略的主语并消解代词指代。它的优点是检索粒度非常精细，适合人物、属性和事实关系检索；缺点是需要调用 LLM，成本和延迟较高，而且模型可能遗漏或错误改写事实。因此，命题不能直接替代原文，通常需要通过 parent_id 保留命题与原始段落的映射。

此外，Overlap、句子窗口和父子块不完全属于与上述方法并列的主分块策略，而是用于缓解边界信息丢失和上下文不足的辅助机制。Overlap 让相邻 Chunk 保留部分重复内容；句子窗口和父子块则通过“小块检索、大块生成”同时兼顾检索精度和上下文完整性。

总的来说，固定长度分块适合快速建立基线，递归分块适合普通非结构化文本，结构化分块适合结构清晰的文档，语义分块适合主题边界不稳定的文本，命题分块适合高精度事实检索。实际项目中通常不是只使用一种方法，而是先尊重文档结构，再在超长结构单元内部递归切分，并结合有限的 Overlap 或上下文扩充策略。

5.3.4.2 你的项目中是如何确定分块策略的？

💡 答题思路

这道题的理论基础就是 5.3.3 分块选型技巧和原则。 但 5.3.3 讲的是通用方法论，真正回答这道题时，需要把方法论落到自己的项目中，答得具体一些，让面试官能够看出你确实理解项目中的数据、问题和技术取舍，而不是只会背诵几种分块方法。

我知道，大部分人在个人项目中不一定会把每一个技术选型都做得如此规范。 即使在真实企业项目中，也不是所有选型都会进行非常完整的实验。因此不需要因为自己的项目没有覆盖全部流程而怀疑自己，但需要理解每一步为什么这样设计，并提前结合自己的项目组织答案。

这里需要灵活运用理论和项目表达技巧。 所谓“包装”，不是捏造不存在的数据或结果，而是把自己已经做过的方案、遇到的问题、能够解释的取舍，以及后续可以采用的验证方式组织成一条完整逻辑。没有实际执行过的实验，可以表述为后续验证方案，不要把计划说成已经取得的结果。

面试前最好针对自己的文档类型、分块方式、Chunk Size、Overlap、异常情况和评测方法准备一版项目化答案。 但也不可能预先准备所有追问。面对新的问题时，需要以扎实的理论基础为底层依据，再结合项目场景灵活分析和随机应变。

下面以“企业内部技术文档知识库”为例组织答案。 回答时可以按照一条标准流程展开：先介绍文档特点，再说明如何选择主分块策略，然后解释参数如何建立基线、遇到了什么问题、如何定向调整，最后说明怎样通过评测确定最终方案。 （参考答案有点长，面试可以稍微简化一点）

📝 参考答案

我们做的是一个企业内部技术文档知识库，主要处理 Markdown、Word 和 PDF 格式的 API 文档、架构设计文档、部署手册和故障复盘。 我们没有直接对所有文档使用固定长度切分，而是先分析文档结构和实际查询目标，再选择分块方案。

第一步是根据文档结构选择主策略。 这类技术文档通常具有比较明确的标题、章节、段落、代码块和接口说明，因此我们先进行结构化解析。Markdown 和 Word 按照标题层级解析；PDF 先转换成能够保留标题和段落关系的结构化文本，同时清理页眉、页脚和错误换行。这样可以避免把不同章节或不同接口的内容混在同一个 Chunk 中。

但是，只按标题切分还不够，因为有些章节可能非常长。 所以在每个结构单元内部，我们继续使用 递归分块，优先按照段落、换行、句子和标点寻找边界，只有内容仍然超过长度限制时，才使用 Token 长度进行兜底切分。最终采用的是“ 结构化解析加递归分块，而不是单纯固定长度切分。

第二步是根据检索目标确定粒度。 我们的用户通常会查询某个接口的参数、配置项、部署步骤或故障处理方法，需要定位到比较具体的证据，因此 Chunk 不能太大；但技术说明又经常包含前置条件、操作步骤和注意事项，Chunk 太小会导致上下文不完整。因此我们的目标是让一个 Chunk 尽量覆盖一个完整的接口说明、操作步骤或自然段落。

第三步是建立参数基线。 项目早期我们先以大约 500 Tokens 的 chunk_size 和 10%～20% 的 chunk_overlap 作为起点，并保留文档 ID、标题路径、页码、Chunk 序号等元数据。500 Tokens 不是最终答案，只是一个兼顾检索粒度、Embedding 输入和上下文成本的初始值。

第四步是根据实际问题进行调整。 测试过程中主要发现了两类问题。第一类是接口名称、参数解释和限制条件偶尔落在相邻 Chunk 中，检索命中参数说明后，模型拿不到接口名称或前置条件。对于这种边界问题，我们保留适量 Overlap，并通过 chunk_index 扩充前后相邻块。

第二类问题是部分架构文档的单个章节很长，即使递归切分后，一个小块虽然容易检索，但不足以支持完整回答。 对于这种情况，我们没有盲目增大所有 Chunk，而是保留父子关系：小的子块负责生成向量和参与检索，命中后再根据 parent_id 返回对应的较大父段落，让系统实现“小块检索、大块生成 ”。这样既保留了 检索精度，也补充了生成所需的上下文。

我们也评估过 语义分块 和 命题分块。** 语义分块 需要为大量句子额外计算 Embedding，并且阈值需要针对语料调试； 命题分块 还需要调用 LLM 对原文进行转换，存在成本和事实改写风险。考虑到我们的技术文档结构比较稳定， 结构化解析加递归分块**已经能够解决大部分问题，因此没有把语义分块或命题分块作为默认主链路，只把它们作为特殊文档的候选方案。

最后，分块参数需要通过真实问题验证。 我们会准备一批覆盖接口查询、部署步骤、故障原因和配置说明的测试问题，分别比较不同 Chunk Size 和 Overlap 下的 Hit Rate、正确证据排序、上下文完整性、召回重复率、Token 成本和查询延迟。如果小块方案召回更准确但上下文不足，就优先使用父子块或相邻块扩充；如果大块中经常混入多个主题，就减小 Chunk。最终选择的是评测结果最均衡的方案，而不是直接套用某个固定参数。

所以，我们的整体选型逻辑可以概括为：先根据技术文档的结构选择“结构化解析加递归分块”，再根据查询目标设置初始粒度，通过 Overlap 和父子块解决边界与上下文问题，最后使用真实问题评测确定最终参数。 这个过程中的每一步都有对应的数据特点和问题依据。

5.3.4.3 RAG 的 Chunking 策略如何设计？遇到过哪些问题？如何调整？

选自 宇树科技 Agent 开发二面面试真题。

💡 答题思路

这道题比“项目中使用了什么分块策略”更进一步。 面试官不仅要听最终方案，还希望看到完整的问题解决过程。建议按照“初始设计—暴露问题—定位原因—定向调整—评测验证”回答。

回答时不要只罗列技术名词。 每一个调整都要对应一个实际问题，例如语义被切断、一个 Chunk 混入多个主题、召回准确但上下文不足、结果高度重复、标题与正文分离等。这样才能体现自己具备真实的调试和迭代经验。

📝 参考答案

我们的知识库主要处理企业内部技术文档。 初始方案是先保留标题和章节结构，再在超长章节内部使用 递归分块，以 500 Tokens 左右的 Chunk 和约 15% 的 Overlap 建立基线，同时保存标题路径、页码、source_id 和 chunk_index。

第一轮测试发现，部分接口名称、参数说明和限制条件被分到相邻 Chunk 中。 检索虽然命中了参数说明，但模型不知道它属于哪个接口。我们先改善结构解析，把标题路径补充到每个 Chunk；然后保留适量 Overlap，降低边界信息丢失的概率。

第二个问题是小块检索比较准确，但回答复杂部署流程时上下文不够。 这个问题不适合简单增大所有 Chunk，因为大块会混入多个主题，降低向量匹配精度。我们给 Chunk 保存父子关系和顺序信息，使用子块检索，命中后根据 parent_id 返回父段落，或者根据 chunk_index 补充前后相邻块，实现“小块检索、大块生成”。

第三个问题是增加 Overlap 后，Top-K 中经常出现内容高度相似的相邻块。 我们把 Overlap 控制在 10%～20%，并在召回后根据来源和文本相似度去重，避免重复内容占满上下文。

调整过程中，我们不会只看最终答案，而是分别观察正确证据能否进入 Top-K、正确证据的排序、召回重复率、输入 Token 数和查询延迟。 通过对比不同 Chunk Size、Overlap 和上下文扩充方案，选择综合效果最好的配置。

整体来说，我们先用 结构化解析加递归分块 建立基线，再根据边界丢失、上下文不足和重复召回等具体问题，分别使用标题元数据、Overlap、父子块和结果去重进行调整，最后通过真实问题集验证效果。

5.3.4.4 手写算法：按照句子边界进行文本分块，避免截断句子

选自 宇树科技 Agent 开发二面面试真题。

💡 答题思路

就是手撕代码题目，如果以力扣的标准来判断这个题目，这个题算不上一个难题，最多是个中等的题目。 不过就是没法像力扣一样，可以期待能碰到原题。

📝 参考答案

我会先使用中英文句末标点切句，然后按顺序合并句子。 只要加入下一句后不超过最大长度，就继续累加；如果超过，就先保存当前 Chunk，再从下一句开始构建新 Chunk。这样正常情况下不会从句子中间截断。

import re


def split_by_sentence(text: str, max_length: int = 500) -> list[str]:
    sentences = re.split(r"(?<=[。！？.!?])\s*", text.strip())
    chunks = []
    current = ""for sentence in sentences:
        if not sentence:
            continue# 单个句子已经超过上限，只能使用长度切分兜底if len(sentence) > max_length:
            if current:
                chunks.append(current)
                current = ""for start in range(0, len(sentence), max_length):
                chunks.append(sentence[start:start + max_length])
            continueif len(current) + len(sentence) <= max_length:
            current += sentence
        else:
            if current:
                chunks.append(current)
            current = sentence

    if current:
        chunks.append(current)

    return chunks

这段实现保证普通句子不会被截断，并对超长单句进行了兜底。 真实项目中还可以把 len() 替换为 Tokenizer 的计数函数，并进一步处理小数点、英文缩写、代码和列表等特殊情况。

5.3.4.5 技术文档的相关内容跨越多个 Chunk，应该如何优化？什么时候需要扩充上下文？

选自 2025.11 网龙科技一面面试真题。

💡 答题思路

这是一组连续追问。 第一问考察如何解决跨块问题，第二问考察是否知道上下文扩充的使用条件。回答时先区分“检索不到正确位置”和“已经检索正确但上下文不足”：前者需要调整分块或检索，后者才适合扩充上下文。

📝 参考答案

技术文档中的接口名称、参数、前置条件和限制说明可能跨越多个 Chunk。 我们会先通过结构化解析和 递归分块 尽量保留自然边界，并设置有限的 Overlap，降低内容在边界处完全断开的风险。

如果仍然存在跨块问题，我们会给每个 Chunk 保存 source_id、chunk_index 和 parent_id。 检索命中某个子块后，可以根据 chunk_index 补充同一文档中的前后相邻块，或者根据 parent_id 返回包含它的完整父段落。

上下文扩充主要适用于“短文本容易检索，但不足以支持完整回答”的情况。 例如，已经准确命中了某个配置参数，但回答还需要它的适用条件和异常说明；或者命中了流程中的一个步骤，但问题要求解释完整流程。这时适合采用小块检索、相邻块或父块扩充。

如果正确内容根本没有进入 Top-K，直接扩充上下文没有意义，应先检查 Chunk 是否过大、语义边界 是否错误、查询表达是否需要改写，以及检索策略是否合适。扩充时还要限制同源范围、扩充数量和总 Token 预算，并进行去重，防止引入过多无关内容。

5.3.4.6 你的文档分块会使用滑动窗口吗？滑窗长度一般是多少？

选自 2025.11 网龙科技一面面试真题。

💡 答题思路

面试语境中的“滑窗长度”通常是在追问相邻 Chunk 的重叠长度，也就是 chunk_overlap。 回答时最好同时说明窗口大小、滑动步长和 Overlap 的关系，并区分严格的固定滑窗与 递归分块 中的重叠机制。

📝 参考答案

我们使用 递归分块，并为相邻 Chunk 设置了重叠区域。严格来说，它不是完全按照固定步长进行机械滑窗，而是优先在段落、句子和标点等自然边界切分，然后保留适量 chunk_overlap。

在严格的固定滑窗中，窗口大小就是 chunk_size，相邻窗口重复的长度是 chunk_overlap，滑动步长等于 chunk_size - chunk_overlap。 例如窗口大小为 500 Tokens、Overlap 为 100 Tokens，那么每次向后移动约 400 Tokens。

项目中通常可以先把 Overlap 设置为 Chunk Size 的 10%～20%。 设置重叠是为了避免接口名、条件或半句话恰好落在边界处而丢失；但 Overlap 过大会增加索引规模，并导致 Top-K 结果高度重复。因此最终比例需要结合边界信息丢失率、召回重复率和 Token 成本进行调整。

5.3.4.7 你的系统中有没有使用更高级的召回或分块方案？

选自 2025.11 网龙科技一面面试真题。

💡 答题思路

虽然面试官问有没有更高级的技巧，但是建议也不要特别盲目地说或者编造。 实在不行就讲我们的策略是基于这个科学的方法论驱动的，把这个5.3.3 的方法论再讲一遍。如果想要将一些高级的技巧，比如说根据子块检索，召回父块这些策略，一定要找到明确的需求出发点，说明选择这个技术的合理的。能现场包装当然是更好的，但是如果包装露馅无法自圆其说，还不如不包装。这块是我自己面试的素材，我当时估计回答的就是没有，最后也通过了，面试官对我评价还挺高的，有可能这个也是压力测试，不要因为面试官这么追问就盲目现场包装，然后露馅，反而得不偿失。

📝 参考答案

我们的默认主链路仍然是 结构化解析加递归分块，因为企业技术文档结构比较稳定，这套方案成本低、速度快，也容易解释和调试。在此基础上，我们针对不同问题设计了几种增强方式。

对于“小块召回准确但上下文不足”的问题，我们使用 父子块检索：子块负责 Embedding 和匹配，命中后通过 parent_id 返回完整父段落。对于只需要补充局部上下文的场景，则使用 ** 句子窗口**或 chunk_index 扩充前后相邻内容。

对于主题切换频繁、自然段落不可靠的会议纪要，可以评估 语义分块，根据相邻句子的向量距离确定主题断点。对于事实密集且需要精确检索人物、属性和关系的数据，可以评估 ** 命题分块**，但需要保留命题与原文映射，避免把 LLM 改写结果直接作为事实依据。

此外，还可以建立 层级索引：先定位文档或章节，再在命中的范围内进行细粒度检索。这样可以减少跨文档噪声。是否启用这些方案，要根据错误案例和评测结果决定，而不是把所有策略同时堆到系统中。

5.3.4.8 Embedding 切 Chunk 应该怎么做？为什么固定长度切分经常不够？

选自 202604 腾讯 AI Agent 开发暑期实习面试真题。

💡 答题思路

这是一道由两个基础问题组合而成的复合题，可以先把它拆开，再分别使用前文的知识回答。

第一问“Embedding 切 Chunk 应该怎么做”，本质上是在问“应该如何确定分块策略”，对应 5.3.3 分块选型技巧和原则。 回答时按照完整的选型流程展开：先分析文档结构，选择主分块策略；再根据检索目标确定 Chunk 粒度；然后设置必要的 Overlap 或上下文扩充机制；最后根据召回问题调整，并通过真实问题评测确定最终方案。

第二问“为什么固定长度切分经常不够”，本质上是在问“固定长度分块 ** 有什么缺点”，对应 5.3.2.1 固定长度分块。固定长度切分只保证长度可控，不理解标题、段落、句子和语义边界**，因此可能切断完整信息，也可能把多个主题混在同一个 Chunk 中，最终影响 Embedding 表达和召回效果。

所以这道题不需要单独背一套新答案。 先用分块选型方法论回答“应该怎么做”，再用 固定长度分块 的缺点回答“为什么不够”，最后把两部分串联成“结构或语义优先、长度约束兜底、实验评测定型”的完整结论。

📝 参考答案

Embedding 切 Chunk 时，我不会只使用固定长度切分，而是先按照分块选型流程确定方案。

首先看文档是否具有可靠结构。 如果是 FAQ、商品信息或人物资料等强结构化数据，一条完整记录本身就是一个语义实体，可以直接作为一个 Chunk；如果是 Markdown、Word、HTML 或技术文档，则先按照标题、章节和段落进行 结构化分块，再在过长的结构单元内部使用 ** 递归分块**；如果文本结构不可靠、主题切换又比较频繁，可以进一步评估 ** 语义分块**。

确定主策略后，还要根据检索目标决定 Chunk 粒度。 需要定位具体条款、参数或事实时，Chunk 应相对小；需要回答完整流程或复杂原因时，则需要更多上下文。对于“小块检索准确但上下文不足”的情况，我不会直接增大所有 Chunk，而是通过 Overlap、句子窗口 、相邻块扩充或父子块实现“ 小块检索、大块生成”。

Chunk Size 可以先设置一个实验基线，例如 400～600 Tokens，并设置约 10%～20% 的 Overlap。 但这只是起点，最终还要比较不同参数下的 Hit Rate、正确证据排序、召回重复率、上下文 Token 数和查询延迟。

固定长度切分之所以经常不够，是因为它只考虑长度，不理解文档结构和 语义边界。一个定义、操作步骤、接口说明或实体资料可能被从中间切断，使单个 Chunk 只包含残缺语义；也可能把多个不相关主题放进同一个 Chunk，使生成的向量变成多个主题的“平均语义”，降低具体问题的匹配精度。

因此，长度应该作为 Chunk 的上限约束和最终兜底，而不应该是唯一的切分依据。 更合理的方案是优先保留文档结构和自然语义边界，在必要时设置 Overlap 或扩充上下文，最后通过真实问题评测确定最终分块策略。

5.3.4.9 硬切分在实际场景中有哪些弊端？

选自 202604 腾讯 AI Agent 开发暑期实习面试真题。

💡 答题思路

这道题翻译过来，其实就是在问“固定长度分块 有什么缺点”，对应前文 5.3.2.1 固定长度分块 中讲过的内容。

面试中遇到这种题目，可以先把它转换成自己已经掌握的基础知识：硬切分只根据字符数、Token 数、页码或行数确定边界，本质上就是没有考虑文档结构和 语义边界 的固定切分。回答时直接从 固定长度分块 的缺点展开即可。

为了让回答更完整，可以沿着 RAG 链路组织： 首先说明它可能破坏标题、段落、句子和完整事实；然后说明残缺语义或多个主题混合会影响 Embedding 表达；接着说明这会降低召回的准确性和稳定性；最后说明系统可能需要使用 Overlap、上下文补全和 Rerank 等后处理进行补救，从而增加成本和复杂度。

📝 参考答案

硬切分最大的问题是破坏 语义边界。它只按照固定字符数、Token 数、页码或行数切分，不关心标题、段落、句子和逻辑结构，因此可能把一个完整概念、操作步骤、接口说明或实体资料切断。

第二，边界信息容易丢失。如果接口名称、错误码、配置项和适用条件落在两个 Chunk 的交界处，两个 Chunk 都可能只包含一部分证据，最终都无法与查询形成足够高的相似度。

第三，它会影响 Embedding 的语义表示。包含半个技术点的 Chunk 表达的是残缺语义；混入多个主题的 Chunk 表达的是被平均后的语义。这会使相关结果和不相关结果之间的相似度差距变小，导致召回不稳定。

第四，硬切分会把问题推给后续链路。系统不得不增加 Overlap、相邻块补全、Rerank 或 LLM 重组来修复切分阶段造成的问题，从而增加存储、Token 成本、延迟和调试复杂度。

因此，固定长度可以作为最终兜底和长度上限，但不应成为唯一边界。 更常见的做法是优先按照结构、段落和句子切分，无法满足长度约束时才进行强制切分。

5.3.4.10 为什么内部文档需要设置 chunk_size=1000？1000 是不是太大了？

选自 RAG 项目面试真题 3.9：某大厂一面

💡 答题思路

这个问题通常不是面试官凭空提出的。 更可能是候选人在介绍项目、简历或配置参数时，主动说到自己的 chunk_size=1000，于是面试官继续追问：“为什么是 1000？这个值是不是太大了？”

这道题仍然可以转换成前文已经讲过的内容。 第一部分“为什么设置 1000”，本质上是在考察 **如何确定 Chunk Size ，应借鉴 5.3.3 分块选型技巧和原则，按照 “建立参数基线—运行真实问题—观察召回问题—调整参数—通过评测定型” 的 ** 实验驱动方法回答。

第二部分“1000 是不是太大”，是在考察候选人的 **现场分析和灵活变通能力 。不能看到 1000 就直接回答大或不大，而要先确认它的 ** 计量单位、文档语言、自然语义粒度、Embedding 模型输入范围，以及 Top-K 上下文预算。

面试官临时挑战简历中的参数时，需要懂得 现场发挥 ，根据项目场景迅速找到能够支撑该参数的合理依据。例如，可以从计量单位、文档语言、 自然语义粒度 、Embedding 模型输入范围、Top-K 上下文预算和实验调优等角度组织理由。 如果 1000 指英文字符，它可能只有约 200～250 Tokens，并不算大；如果是 1000 个中文字符，就需要结合文档段落长度重新解释或调整。

这里需要适度使用 项目包装技巧 。即使个人项目中没有完整执行每一轮选型实验，也要把前文的方法论理解透彻，能够结合自己的项目组织出一套合理的参数选择过程。回答的重点是让面试官看到： 这个参数不是随手填写的，而是经过文档分析、基线设置、问题观察和实验调整得到的。

📝 参考答案

我们项目中的 chunk_size=1000 不是适用于所有文档的固定经验值，而是结合当前文档场景建立基线，并通过实际查询逐步调整得到的候选参数。

首先需要明确，项目中的 1000 指字符，不是 Tokens 。我们使用的长度函数按照字符计数，知识库主要存储英文 API 文档、架构决策记录、Runbook 和故障复盘。 1000 个英文字符通常约为 200～250 Tokens，大致对应一个完整的技术段落，所以在这个场景下并不算大。

在分块策略上，我们也不是每到 1000 个字符就强制截断，而是先保留标题和章节结构，再使用 递归分块，优先在段落、换行和句子边界切分。** 1000 只是单个 Chunk 的长度上限**，实际生成的 Chunk 通常不会全部达到 1000 个字符。

参数确定采用的是 **实验驱动思路 。项目早期先使用 1000 字符建立基线，然后选择多组候选值，例如 ** 600、1000、1500 字符，使用同一批接口查询、配置查询、部署步骤和故障排查问题运行完整检索流程。

对比时主要观察 **正确证据是否进入 Top-K、正确证据的排序、语义完整性、召回重复率、Token 成本和查询延迟 。如果 Chunk 太小，接口名称、参数说明和限制条件容易分散到不同块中；如果 Chunk 太大，一个块中又可能混入多个主题，使向量语义被稀释。我们选择的是 ** 在检索精度和上下文完整性之间表现更均衡的参数。

从下游窗口预算看，假设一个 Chunk 约 250 Tokens，召回 10 个 Chunk 大约占用 2500 Tokens，不会明显挤压模型的推理和生成空间。 相邻块还会设置有限的 Overlap，并通过标题路径、页码和来源元数据保留上下文。

但 1000 是否合理高度依赖场景 。如果项目换成中文文档，1000 个中文字符对应的 Token 数会明显增加，也可能跨越多个自然段落，这时我会重新降低 Chunk Size，并使用同一套评测流程重新选型。因此， 1000 不是天然合理，而是在当前英文技术文档、字符计量和评测条件下合理。

5.3.5 视频讲解

https://www.bilibili.com/video/BV1extE6jEHu/?spm_id_from=333.1387.homepage.video_card.click&vd_source=144bec9c3f54e465073138bed788be1b

5.4 召回

5.4.1 召回的常用策略

RAG系统可以使用粗排 + 重排两个阶段来完成召回。 粗排通常使用稠密向量检索模型来做语义匹配，召回语义相关文档。当然也可以再结合稀疏向量检索模型来补充使用，因为稀疏向量检索模型更擅长捕捉关键信息来提高召回效果。

粗排后，可以使用交叉编码器，比如BERT来对候选文档进行深入语义排序，提高召回质量。

5.4.2 稠密向量和稀疏向量

参考书籍《大模型RAG实战》 第三章文本召回模型

RAG系统中的文本向量检索模型大致分成两类：一类是基于BERT， GPT等深度学习模型的稠密向量检索模型，另一类是以TF-IDF, BM 25 为代表的稀疏向量检索模型。 稠密向量检索模型更擅长提取文本中语义信息，稀疏向量检索模型更擅长提取关键信息。

5.4.3 对称检索和非对称检索

参考书籍《大模型RAG实战》 第三章文本召回模型

对称检索是找到相似的句子，与向量检索基于计算向量相似度的原理天然匹配，只需要模型具有较强的内容抽象的能力即可。

非对称搜索是根据问题召回答案，要求模型能够将问题和答案映射到同一空间，而问题和答案通常具有不同的文本结构。并非所有的向量化模型都支持非对称检索，只有经过大量问答数据的模型才能提供支持。

5.5 召回优化策略

5.5.1 短文本全局信息增强

因为切块的过程难免会造成全局文本信息的丢失，因此我们为切块后的短文补充其所属的长文本信息。

比如以论文《DAPR: A Benchmark on Document-Aware Passage Retrieval》中提到，我们可以将长文本的前三句话， 长文本的标题，长文本的关键词 作为全局信息，和切块后的文本一起保存。

5.5.2 召回内容上下文扩充

在RAG切块的时候，对长文本切块后，可能会有较大的信息损失，因为我们从数据库中召回的通常是短文本。这时我们可以采用召回内容上下文补充的方法：召回的是短文本，但是输入LLM处理的是短文本的父文本（长文本）。 好处是既精准（基于短文本匹配），又完整（基于长文本输入）

在Langchain中，我们可以使用ParentDocumentRetriever 来完成这一功能，它使用了两个分割器，Parent_splitter和child_splitter。 前者用于确定在RAG场景下输入到大模型的父文本块的大小，后者确定从向量数据库中召回的子文本块的大小。同时还会存储父子文本块的映射关系。 当使用get_relevant_documents召回时，返回的实际上是父文本的内容。

5.5.3 文本多向量表示

在构建向量数据库的时候，可以使用多种向量来表示同一段文本。比如有一段文本A，我们不仅可以使用完整的A来生成向量，还可以使用它的子集，总结句来生成补充向量。当召回任意的补充向量对应的文本后，并不是将其输入大模型中，而是将其对应的文本A输入。

常见的生成补充向量的方法有：

文本切块: 将原始文本切块后保存到数据库中，可以在召回时增强对更细粒度的表示。

文章摘要：利用LLM生成摘要。

假设性回答：可以利用大模型的能力，根据文本提出问题，把问题作为补充信息。这种方法的思想是用问题召回问题会比用问题召回答案更容易。

5.5.4 内容查询优化

很多情况下，用户提出的内容有口语化，语义模糊，无关内容多的问题。 因此直接将问题变成向量可能和用户的真实意图不相关，从而影响RAG场景下的召回效果。因此，我们可以对用户的原始问题进行改写和扩充，再进行召回。

常见的对原始问题优化的方法有：

1.使用LLM 改写和扩充，比如LangChain提供的MultiQueryRetriever就集成了这个功能。

2.对历史问题进行总结，然后再进行召回，这个特别适用于多轮对话中。比如

用户：中国的首都在哪里？

LLM：北京

用户：那里有哪些好玩的景点？

这时直接用原来的问题召回显然太模糊，如果用LLM总结后，问题就变成了北京有哪些好玩的景点。

5.5.5 召回文本重排序

在RAG场景下，默认使用的是向量召回，检索效率高。但是由于文本向量化的过程中存在着信息损失，并且在召回过程无法考虑查询用户和候选文本上下文关系，因此召回精度不高。 所以在召回向量后，通常还会进行召回文本的重排序的精筛。

最常用的重排序的模型是基于Transformer编码器架构的交叉编码器。将用户查询和一段候选文本同时输入到模型之中，预测它们之间的相关性分布。使用这种方法可以考虑到用户查询和候选文本的上下文关系，因此有更高的精度。

5.5.6 结合元数据召回

在实际场景中，很多情况我们不需要在整个向量数据库中进行召回。如果在存储文本向量的时候同时记录了每个向量相关的标签，就可以在召回时先根据标签信息过滤出所需的向量子集，有利于提高检索速率，避免检索无用的信息。

现在的大模型应用框架，Langchain就基于多种向量数据库，集成了元数据写入和召回过滤的能力。我们可以使用Langchain的Create_metadata_tagger的接口，借助大模型的能力，自动生成元数据。

5.6 精排

第四小节的各个部分其实就是RAG最近基本的模块和环节。是弄懂RAG的基础，不管是我推荐的书籍还是项目（实战都有），大家结合笔记，书籍，自己搜的资料，把这几个环节理解一下。可以多搜索视频啊，书籍来理解这些基础知识点。我这里写的不是很详细，知识概括，方便大家背诵。如果说学习的话，其实可以找我推荐的书籍啊，视频啊，自己也能找。这些都是最基础的东西，网上很多讲解。

精排是 RAG 检索链路里位于召回之后的一层排序环节。粗排或者向量召回的目标是从大规模语料里快速找出一批候选文档，而精排的目标是对这批候选文档做更细粒度的相关性判断，把真正能回答问题、信息质量更高、业务上更适合进入上下文的内容排到前面。常见的精排方法主要有 Cross Encoder 精排、LLM 精排、规则精排，以及混合精排。它们都不是用来替代召回的，而是在候选集已经比较小的情况下，对候选内容进行二次排序、过滤和质量控制。

具体来说，Cross Encoder 会把 query 和每个候选文档拼在一起输入模型，让模型直接判断二者相关性。它的优点是语义匹配能力强，相关性分数比较稳定，适合做通用的语义相关性排序。缺点是每个候选都要单独过模型，延迟和算力成本较高，而且它主要判断语义相关，不一定能很好处理业务规则、字段完整性、时效性、来源可信度这些约束。

LLM 精排可以让大模型结合问题、候选文档和业务要求做综合判断。它的优点是解释性强，也能处理复杂意图和多维标准，比如不仅判断相关，还可以判断这段内容能不能支撑最终回答。缺点是成本更高、延迟更高，输出稳定性和可控性也需要额外约束。

规则精排是根据项目里的明确业务目标来打分或过滤，比如优先保留字段完整、标题匹配、时间更新、来源可靠、包含关键实体的内容。它的优点是可解释、成本低、延迟低、容易调试，也更适合把业务经验沉淀到系统里。缺点是语义泛化能力弱，规则覆盖不到的情况容易漏掉。

混合精排则是把模型相关性和规则约束结合起来。它的优点是效果更均衡，既能利用模型判断语义相关性，也能用规则保证业务可用性。缺点是工程复杂度更高，需要调权重，也需要用评估集持续验证不同策略的收益。

图 016 · 已恢复原图内容 · 点击放大

5.7 面试问题精选

5.7.1 Embedding 切 Chunk 应该怎么做，为什么固定长度切分经常不够？

Embedding 切 chunk 不能只按固定长度一刀切，而是要尽量让一个 chunk 对应一个完整的语义单元。实际做的时候，我会先看文档类型：如果是 FAQ这类强结构化数据，本身就是完整实体，就可以一条作为一个 Document，不强行切；如果是技术文档、用户协议、SOP 这类长文本，就用递归切分，优先按标题、段落、句子切，最后才按长度兜底。

chunk 大小也不是拍脑袋，要结合 embedding 模型的输入限制和最佳区间，比如很多 BGE / Sentence-Transformers 模型虽然有 512 token 上限，但最佳效果通常在 100-400 token 或几百 token 区间。太短信息不够，太长语义会被稀释。还要设置 10%-20% 的 overlap，避免关键信息刚好落在边界被切断。

固定长度切分的问题是，它只保证长度，不保证语义完整。比如一个定义、一个步骤、一个实体画像可能被切成两半，向量表示就会变成残缺语义；或者一个 chunk 里混了多个主题，embedding 变成“平均语义”，用户问具体问题时反而召回不到。所以更好的做法是“语义优先 + 长度约束 + overlap + 评估验证”，最后用真实 query 的 hit_rate、MRR 来调 chunk size。

选自202604 腾讯AI Agent开发暑期实习面试

5.7.2 硬切分在实际场景中有哪些弊端？

硬切分最大的问题是破坏语义边界。它通常按固定字符数、固定 token 数、页码或行数切分，不管文本本身的标题、段落、句子和逻辑结构，所以很容易把一个完整概念、一个操作步骤、一个接口说明切断。比如接口文档里本来应该把接口名、参数、错误码、限制条件放在一起，如果硬切分刚好切开，后面检索到的 chunk 就可能只有条件说明，却没有对应的接口上下文。

第二是边界信息容易丢失。版本号、接口名、错误码、配置项、前置条件这类信息，如果刚好落在两个 chunk 的交界处，单个 chunk 里就没有完整证据。检索时可能两个 chunk 都和用户问题“不够像”，最后都排不上来，导致模型拿不到关键上下文。

第三是会影响 embedding 的语义表达。这里不是说硬切分一定导致 chunk 长短不合适，而是说它只保证长度可控，不保证语义完整。一个长度合适的 chunk，如果只包含半个技术点，embedding 表达的就是残缺语义；如果一个 chunk 里混进多个主题，embedding 又会变成“平均语义”。这会导致相关和不相关结果的相似度分数拉不开，召回结果不稳定。

第四是增加后处理成本。切分阶段如果把段落、步骤、表格说明切碎了，后面可能还要靠 overlap、rerank、LLM 重组、上下文补全去补救。这样不仅增加计算成本和延迟，也会让整个 RAG 链路更难调试。

选自202604 腾讯AI Agent开发暑期实习面试

5.7.3 微调（模型训练）vs RAG，如何选择？

我会先区分这个项目的问题到底出在哪里。不是所有效果不好都应该重训练模型，很多时候只是知识没接上、检索没做好、规则没兜住。

如果问题主要是知识更新、企业内部资料、产品文档、政策制度、FAQ、接口说明这类外部知识缺失，我更倾向于用 RAG。因为这些内容变化快、可追溯性要求高，放进知识库可以随时更新，也方便引用来源。如果为了这些动态知识去微调模型，成本高、更新慢，而且模型还可能记混或者幻觉。

如果问题主要是确定性的业务规则，比如权限判断、价格计算、流程状态流转、字段校验、风控规则、格式约束，我不会优先训练模型，而是用规则、代码、工作流或者工具调用来增强。因为这些东西要求稳定、可解释、可审计，不能靠模型“猜”。更适合继续做模型重训练的项目，一般是模型的能力模式本身不符合业务需求。比如模型长期不会按某种专业风格回答，不能稳定遵守某种输出格式，对领域术语理解差，分类/抽取/意图识别这类任务在大量样本上都表现不好，或者有大量高质量标注数据可以让模型学到稳定模式。这时候微调才有价值，因为它改变的是模型的行为分布，而不是临时塞几段知识。

选自202604 腾讯AI Agent开发暑期实习面试

5.7.4 RAG 检索相关性差的原因与优化思路？

💡 思路： 这个题也不难回答，我们的RAG项目中，做了很多操作：RRF,双路检索，Rerank, 基于Mentadata 过滤答案后筛选，这些做法都是在提高检索内容的相关性。同时我们在RAG知识部分，也讲解了RAG的一些高级策略，也是回答优化方向的点。

同时我们之前专门讲了Self-RAG技术（因为面试官问如果保证系统生成回答的准确性），这几个技术都是来回答优化思路的出发点。因此即使我们没有专门准备过这个问题，但是我觉得不应该答不出来。如果从这个题目本身来说，我下面给的参考答案，其实有点多了，不过我还是没有删减，因为我觉得这些内容挺有价值的，从相关性差的原因，到如何解决，顺着整个链路把RAG系统串了起来。回答的时候，挑着说，简化着说就好了，我都列出来，是想给大家复习。

📝 答案：

RAG 检索相关性差，通常不是单一环节的问题，我会沿着“知识入库、用户查询、候选召回、结果排序”这条链路逐层排查。

首先是知识入库的问题。比如原始文档质量不高、包含大量噪声或重复内容，或者 Chunk 切得不合理。Chunk 太大容易混入无关信息，太小又会破坏完整语义；如果标题、章节、时间、文档类型等 Metadata 没有保留下来，检索时也很难利用这些结构化信息进行过滤。另外，Embedding 模型如果不适合中文或业务领域，也会导致向量表达不准确。

其次是用户 Query 本身的问题。用户的问题可能很短、存在歧义，或者使用了知识库中没有出现过的表达。对于复杂问题，如果直接把原始 Query 做一次向量检索，也可能因为包含多个意图而召回不准。这种情况可以通过 Query Rewrite 补全上下文，把口语化问题改写成更适合检索的表达；也可以通过 Query Decomposition，把复杂问题拆成多个子问题分别检索。

在召回阶段，我不会只依赖单路向量检索。向量检索擅长语义匹配，但对产品编号、专有名词和精确关键词不一定敏感；BM25 关键词检索正好可以弥补这一点。因此可以采用双路混合检索，同时执行向量检索和 BM25，再使用 RRF 根据两路结果的排名进行融合。这样既能利用语义相似性，也能保留关键词精确匹配能力，提高候选集的召回率。

如果业务数据带有明确的结构化条件，我还会在检索前或检索后使用 Metadata 过滤。例如，用户查询某个产品最新版本的使用说明，可以先按照产品型号、文档类型、版本和时间进行过滤，再进行向量检索，避免把其他产品或旧版本的内容送入候选集。这里还需要根据评测结果调整 Top-K、相似度阈值和索引参数，防止 Top-K 太小导致漏召回，或者太大引入过多噪声。

召回之后还需要做 Rerank。向量数据库返回的相似度主要适合快速筛选候选，并不代表排序结果一定最符合用户问题。我会先通过混合检索召回较多候选，再使用 Cross-Encoder 或专门的 Reranker，让模型同时理解 Query 和每个候选 Chunk，重新计算相关性，最后只把排名靠前的内容交给大模型。整体上就是“粗召回保证不漏，精排序减少噪声”。

对于复杂场景，还可以引入 Self-RAG 的反馈机制。模型先判断当前问题是否需要检索，再检查检索内容是否相关、是否足以支持回答；如果证据不足，就改写 Query 或继续检索，而不是拿着低质量上下文强行生成。生成以后还可以检查回答是否忠实于检索证据，从而减少检索质量问题进一步演变成回答幻觉。

最后，这些优化不能只靠主观观察，还要通过评测集验证。检索阶段可以看 Context Precision、Context Recall、MRR、NDCG 等指标；生成阶段可以看 Faithfulness 和答案正确性。同时记录每个失败案例，判断问题究竟出在 Chunk、Embedding、Query、召回还是 Rerank，再针对性调整。

总结来说，我的优化思路是：先提升知识和 Chunk 质量，再通过 Query Rewrite 或问题拆解改善查询，使用 BM25 与向量检索双路召回、RRF 融合，通过 Metadata 缩小范围，再利用 Rerank 精排；复杂场景下加入 Self-RAG 的检索与反思闭环，最后用离线评测指标验证优化效果。

选自202607 宇树科技一面

6.嵌入向量

面试偶尔喜欢问的：有什么Embedding的方式，对比。Embedding选择策略。没啥特别要强调的，不过还是值得记住（背住的）。本质上来说，是RAG项目做得并没特别深入和专业，所以我就是选择了通用Embedding模型，没办法这些部分只能背着，最少做理论上的巨人。

6.1 常见的Embedding方法

常见的 embedding 相关模型大概可以分成几类：

通用语言理解模型：BERT、RoBERTa

这类模型本质上是通用文本理解底座，语言理解能力强，适合分类、抽取式问答、序列标注、精排等任务。

但它们不是专门为向量检索训练的。如果直接拿 BERT 的句向量去做相似度搜索，效果通常不稳定：有时两个句子看起来很像，向量距离却不近；有时语义不相关，分数又拉不开。

所以在 RAG 里，BERT 更常作为底座或精排模型使用，不是最推荐直接拿来做第一阶段召回。

句向量模型：SBERT、Sentence Transformers

这类模型是在 BERT 基础上改出来的，目标就是让句子向量更适合做相似度计算。它会把问题和文档分别编码成向量，然后用向量距离判断相关性。

它的优点是：开源、好部署、生态成熟、适合语义搜索和 RAG 召回。相比原生 BERT，它更适合做“用户问题和知识片段是否相关”的判断。

缺点是：不同模型差异很大。英文效果好的模型，不一定适合中文；通用语料上效果好的模型，不一定适合公司内部术语、产品名、业务黑话。小模型速度快但表达能力弱，大模型效果好但资源和延迟更高。

检索专用开源模型：E5、BGE、GTE

这类模型一开始就是按“问题找文档”的目标训练的，更贴近 RAG 的使用方式。它们通常会用大量问答对、搜索点击数据、正负样本对来训练，所以对“这个问题应该召回哪段资料”更敏感。

它的优点是：召回能力强、适合知识库问答、可以私有化部署、中文模型选择也比较多。如果项目不能把数据发到外部 API，这类模型通常是比较现实的选择。

缺点是：部署、显存、推理速度、批量建库都要自己维护；有些模型还有固定输入格式，比如问题和文档要分别加不同前缀，不按格式用可能会掉效果。

商业 Embedding API：OpenAI、Cohere、Voyage 等

这类模型的特点是开箱即用。你不用自己部署模型，只要调用接口就能生成向量。

它的优点是：效果稳定、多语言能力强、接入简单、维护成本低。很多项目早期验证 RAG 效果时，会先用这类模型快速跑通。

缺点是：要考虑调用成本、网络延迟、限流、数据合规和私有化问题。尤其是企业内部知识库，如果文档不能出内网，就不能简单依赖外部接口。大规模重建索引时，费用也可能比较明显。

领域专用模型：代码、法律、金融、医疗等

这类模型不是追求“什么都能搜”，而是针对某个领域优化。比如代码检索要理解函数名、接口、报错信息；法律检索要理解法条、案由、裁判逻辑；医疗检索要理解疾病、药品、检查指标。

它的优点是：在特定领域更准，能处理通用模型不熟悉的术语和表达。

缺点是：换领域后不一定好用，而且训练和评估成本更高。是否值得用领域模型，要看业务 query 里领域术语占比高不高，以及通用模型是否已经明显召回不准。

领域专用 embedding 模型：比如代码、法律、金融、医疗、论文检索、图文多模态检索等模型。它们的优点是在特定领域术语、结构和查询方式上更准，比如代码检索要理解函数名、API、错误信息，法律检索要理解法条和案由。缺点是泛化能力可能弱，换领域后不一定比通用模型好，而且评估和训练数据成本更高。

6.2 Embedding选择策略

1. 先看要解决什么检索问题：如果只是普通知识库问答，优先选面向“问题找文档”训练过的检索模型；如果是代码、法律、金融、医疗，就要考虑领域模型；如果要中文问英文资料，或者中英混合检索，就要看跨语言能力。不要用一个“通用句子相似度模型”硬套所有场景。

2. 再看数据本身的特点：知识库是中文多，还是英文多？是长文档、PDF、网页，还是短 FAQ？里面有没有大量产品名、缩写、错误码、接口名、内部黑话？这些都会影响模型效果。比如纯语义模型对“意思相近”的内容比较敏感，但对订单号、版本号、接口名这种精确匹配，不一定比关键词检索好。

3. 一定要用业务样本试：不要只看榜单。应该拿几十到几百个真实问题，标出它应该命中的文档片段，然后比较不同模型能不能把正确片段排到前面。重点看两个现象：该召回的有没有召回；不该召回的相似干扰项有没有混进来。

4. 看能不能满足工程约束：模型效果好还不够，还要看向量维度、索引大小、查询延迟、建库速度、调用成本、是否能私有化部署。比如商业 API 接入快，但有费用和数据合规问题；开源模型可控，但要自己维护推理服务和机器资源。

5. 和切分、关键词检索、重排一起调：Embedding 不是孤立选择的。chunk 切太大，语义会被稀释；切太小，上下文又不够。对于专有名词、编号、时间、版本号这类信息，通常还要结合关键词检索；对召回结果质量要求高的场景，再加重排模型做二次筛选。

6.3 选错Embedding带来的问题

- 召回不准：用户问 A，返回一堆“语义上有点像但答不上问题”的 chunk，LLM 就会基于噪声回答。

- 召回漏掉关键证据：答案明明在库里，但 topK 里没有，表现为 RAG 频繁说不知道，或者只能答泛泛内容。

- 近义词、缩写、业务术语匹配差：比如内部黑话、产品名、英文缩写、中文同义表达搜不出来。

- 跨语言效果差：中文问题搜英文资料、英文问题搜中文资料时命中率明显下降。

- 长 chunk 被语义稀释：一个 chunk 里混了多个主题，向量变成“平均语义”，具体问题反而匹配不到。

- 精确信息检索失败：订单号、接口名、错误码、版本号这类 token，纯 embedding 可能不如关键词检索稳定。

- 分数分布异常：相关和不相关 chunk 的相似度分数拉不开，阈值很难定，topK 结果经常抖动。

- 线上成本过高：维度太大或模型太慢，导致索引膨胀、检索延迟高、增量入库成本高。

6.4 面试问题

1. Embedding模型在项目中应该怎么选，选错会出现什么现象？

请参考 202604 腾讯AIAgent开发暑期实习面经 问题6，答案写在了那里。

2. 向量数据库与关系型数据库的核心区别

选自202607 宇树科技一面

💡 思路： 八股问题。对于这些八股，我们如果背到了是最好的，用一个比较标准的，全面的，精心组织的回答去回答。但是如果你没有背到这个八股，也不应该答不上来，学过了RAG，你应该知道向量数据库是啥，包括关系数据库，基本也算是计算机的常识问题了。

📝 答案：

向量数据库与关系型数据库最核心的区别，是数据表示方式和查询范式不同。

关系型数据库把数据组织成表、行和列，通过明确的 Schema、SQL 条件以及 JOIN 进行精确查询。例如，查询“张三的注册日期”或“过去一年订单总额”。它擅长处理结构化事实的精确查询、事务处理和强一致性。

向量数据库则会把文本、图片等非结构化内容通过 Embedding 模型转换成高维向量。查询时，也会把用户的问题转换成向量，再通过余弦相似度、内积等方法，返回语义最相近的 Top-K 结果。它擅长处理非结构化内容的语义检索、相似内容匹配和大规模候选召回。

两者的索引机制也不同。关系型数据库常用 B+ 树、哈希索引；向量数据库常用 HNSW、IVF、PQ 等近似最近邻索引，需要在检索速度、召回率和内存占用之间进行权衡。因此，SQL 查询通常返回满足明确条件的确定记录，而向量检索返回的是带有相似度分数的候选结果，并不保证结果一定正确。

在实际的 RAG 系统中，两者通常不是替代关系，而是互补关系。例如，可以先用关系型字段或元数据过滤租户、权限、时间和文档类型，再通过向量检索寻找语义相关的知识片段。PostgreSQL 加 pgvector 就是将两种能力结合起来的例子。

最后总结来说：关系型数据库擅长对结构化事实进行精确、确定性的查询；向量数据库擅长对非结构化内容进行近似的语义相似性检索，两者在实际 RAG 系统中通常结合使用。

7. RAG进阶

此部分为RAG进阶部分，如前所述，一般岗位可能不会考察这么深，除非你自己简历写了Graph Rag, Agentic RAG或者本身就是专门做RAG的组，可能会考到这里。 我的原则是，该部分概念要会，问RAG有啥新方向，相关概念答得出来，但没有深入研究。

7.1 RAG新方向

（这俩新方向，虽然可能没深入研究，但是得知道，概念要能讲出来）

目前典型的RAG的新方向是 Agentic RAG和Graph RAG, 具体来讲：

Agentic RAG的核心是把RAG从一个固定流水线变成一个有决策能力的Agent。传统RAG就是检索一轮、生成答案、结束了。但很多复杂问题一轮检索根本不够，Agentic RAG让模型自己判断——检索结果够不够？不够就再检索一轮，或者换个检索策略。像Self-RAG、Corrective RAG都是这个思路，本质就是让检索过程变得更智能、可以自我纠错。

Graph RAG解决的是另一个问题——传统向量检索擅长找语义相似的内容，但很难处理跨文档的关联推理。比如问人物之间的关系，信息散落在十几个段落里，靠embedding相似度很难串起来。Graph RAG的做法是先从文档里抽取实体和关系建成知识图谱，检索时在图上做关系遍历，特别适合需要全局理解的问题。"

我觉得这两个方向是互补的——一个解决检索策略的智能化，一个解决知识关联和推理，未来可能会结合起来用。

7.2 RAG与知识图谱

（知识图谱也能和RAG结合使用。但是其实对于可能80%的问题，靠高质量的切片和双路召回就能够解决，只有20%的问题，需要跨文件全局关联的硬核需求，值得花200%的精力去建立图谱。总结来说，知识图谱较为复杂，不是每个企业都会用，成本高。也属于进阶路线。 所以如果你没有学好传统的双路召回RAG，先不用来学这个结合图谱的RAG，这里的建议依旧是作为概念，先理解什么是知识图谱，为什么和RAG能结合？优势和劣势是啥？我就只学到这里。如果哪天他变得很火了，考的多了，可以继续学）

7.2.1 什么是知识图谱？

知识图谱是一种结构化的知识表示形式，通过图模型来描述现实中的实体及其之间的关系：核心包括：

节点：表示实体或者概念，如'北京'，'小刘'

边：表示实体间的关系，比如'小刘-就职于-阿里'

属性：描述节点的额外信息，如'北京-人口-2154万'等。

知识图谱通过三元组的形式组织数据，从而构建出一个庞大的网络。

图 017 · 已恢复原图内容 · 点击放大

7.2.2 知识图谱在RAG的应用？

传统的RAG是基于分块，向量召回的思路来对输入数据增强的。但是对于强调跨文档/多文档综合，需要多跳推理/链路关系的时候，可以将知识图谱和RAG结合，即KG-RAG。 它的做法是先用普通语义检索拿到一批chunk，然后把这些chunk映射到知识图谱的实体上，沿着图的边做扩展检索，把原本关联的文本片段补齐成一条/多条与问题相关的关系链，最终把组织起来的片段按图结构交给LLM（简单说，向量召回的结果作为起点，KG扩展把点连成线，再将整合结果送入LLM）

7.2.3 知识图谱vs普通RAG？

普通RAG 落地快，成本低，适合'答案就在某几段文档里'的定位性问题，但是它的弱点是需要跨多段/多条文档做综合，需要多跳推理和关系链路时，他只能拿到碎片，此种场景适合使用KG-RAG, 但是它的缺点是：需要抽取/维护实体关系、做图扩展与组织，构建与维护成本更高。

7.3 Self-RAG

Self-RAG, 我认为是一个还挺有价值的技术。学好这个，对面试的帮助也很明显，当面试官问你：如何保证RAG系统生成的答案是准确的？ 以及 你的RAG系统中有什么高级技术？可以介绍一下吗（英伟达面试真题）？ 我们都可以从Self-RAG的角度出发。这两个问题也是真实的面试问题，我也附上了跳转链接。

同时这也确实是一个有价值的事：我们学了RAG的评估方法，比如RAGAS，这个是已经吐出了回答后的检测，有没有办法能够在运行的时候，就能动态检测生成质量，实时调整呢？那么就得靠我们的Self-RAG技术了。

7.3.1 Self-RAG是什么？

Self-RAG（Self-Reflective Retrieval-Augmented Generation，自省式检索增强生成）是在传统 RAG 基础上加入“自我判断和自我评估”能力的一种 RAG 范式。

传统 RAG 通常采用固定流程：

用户问题 → 检索知识 → 生成答案

它存在两个问题：一是无论问题是否需要外部知识都进行检索；二是即使检索到了知识，也不能保证知识与问题相关，更不能保证生成答案严格受到知识支持。

Self-RAG 将流程改为：

判断是否需要检索
→ 检查检索内容是否相关
→ 生成候选答案
→ 检查答案是否得到证据支持、是否有用
→ 评分并选择最终答案

因此，Self-RAG 的重点不是简单地增加一次检索，而是让质量评估直接参与检索和生成决策。

从下图中可以清晰地理解Self-RAG和传统RAG的区别：图片上方是经典的RAG，而Self-RAG就是在上方经典RAG下面引入了自我检查：从要不要检索，到输出分数是否达标各个方面检测，及时做出调整或者拒答。

图 018 · 已恢复原图内容 · 点击放大

7.3.2 Self-RAG 检测什么？

经典 Self-RAG 使用四类自省信号：

1. Retrieve：在检索前判断当前问题是否需要检索外部知识。
2. IsREL：在检索后、生成前判断检索到的文档或 Chunk 是否与问题相关。
3. IsSUP：在生成后判断答案是否得到检索证据支持。
4. IsUSE：在生成后判断答案是否有用、是否真正解决了用户的问题。

其中，IsSUP 可以进一步分为完全支持、部分支持和无支持或冲突；IsUSE 通常可以采用分级评分。

7.3.3 经典 Self-RAG 如何实现？

经典 Self-RAG 会把上述判断表示为特殊的“自省 Token”，例如：

[Retrieve]
[Relevant]
[Fully Supported]
[Utility:5]

训练阶段先使用 Critic 模型为训练样本生成这些评价标签，再使用带标签的数据微调 Generator。完成训练后，Generator 不仅能够生成答案，还能够在适当位置生成自省 Token。

推理时，程序读取这些 Token 及其生成概率，以决定是否检索、是否保留某个 Chunk，以及应该选择哪个候选答案。自省 Token 不需要展示给用户，它们相当于模型提供给程序的标准化控制信号。

简化后的运行过程如下：

用户问题
  ↓
Retrieve：需要检索吗？
  ↓
检索多个 Chunk
  ↓
IsREL：逐个判断 Chunk 是否相关
  ↓
使用相关证据生成候选答案
  ↓
IsSUP + IsUSE：评价候选答案
  ↓
选择得分最高的答案并输出

如果要形成更严格的生产级闭环，还可以增加质量阈值：答案未达到阈值时，不直接输出，而是重新检索、重新生成或拒答。

7.3.4 用RAGAS 替换传统Self-RAG

这一节纯粹是我自己加的。因为我们看到上面的Self-RAG的 自评估方法是要使用专门的模型进行训练的。如果我们要包装，我害怕面试官问你的模型训练的细节，加上我们项目中做了RAGAS的评估，RAGAS的评估和Self-RAG的三个指标是一样的，干脆我们讲的时候就用RAGAS集成到Self-RAG好了，这样问到我们如何实现的细节，我们更加胸有成竹。我在相关面试真题:如何保证RAG系统生成的回答是准确的？，也是用这个思路来组织最终参考答案的。

我们可以保留 Self-RAG 的"检索—生成—评估—修正"流程，用 RAGAS 作为外部评估器替代模型内部的自省 Token。

两者可以近似映射为：

1. Retrieve：RAGAS 没有直接对应指标，可以使用 LLM 分类器或业务规则判断是否需要检索。
2. IsREL：可以使用 Context Relevance 或 Context Precision 判断检索内容是否相关。
3. IsSUP：可以使用 Faithfulness 判断答案是否得到检索上下文支持。
4. IsUSE：可以使用 Answer Relevancy 判断答案是否解决了问题；有参考答案时，还可以增加 Answer Correctness。

替换后的流程为：

用户问题
  ↓
规则或 LLM 判断是否需要检索
  ↓
检索并生成答案
  ↓
RAGAS 评估上下文相关性、答案忠实度和答案相关性
  ↓
达到阈值 → 输出
未达到阈值 → 过滤噪声、重新检索、重新生成或拒答

这种实现并不是原始论文中依靠自省 Token 的经典 Self-RAG，更准确的称呼是“借鉴 Self-RAG 思想、以 RAGAS 为外部评估器的自反思 RAG 工作流”。它不需要重新训练 Self-RAG 模型，更容易接入现有工程，但会增加额外的模型调用、延迟和成本。

7.3.5 讲解视频

https://www.bilibili.com/video/BV1gF8Z6WEGW/?spm_id_from=333.1387.homepage.video_card.click&vd_source=144bec9c3f54e465073138bed788be1b

8. RAG场景题

如果我做 rag 召回的相关内容里，会有人恶意注入了一些错误的信息， 你觉得会影响大模型的生成内容吗？怎么避免？

会影响生成内容。 我认为：

1. 可以限制拿到的数据的来源，只选择可靠的数据源。
2. 可以对拿到的数据进行安全性检验，检验是否包含恶意指令

9.RAG的趋势探讨

在2026年，我相信大家听过很多论调和讨论：RAG已死。我们现在Agent都不用RAG了。包括还有各种面试题：为什么ClaudeCode不用RAG了？你设计Agent架构的时候，到底要不要用RAG（202606滴滴面试真题）。包括还有一些你和面试官聊天的时候的讨论：你如何看待RAG的趋势，你觉得现在还需要不需要RAG？

今天这个小节，我想全面，客观的来帮助大家分析一下这个问题。大家不要背答案，而是真的去理解，去思考，去看看我说的是不是这么一回事？有了自己的思考，对于上面的各种问题的回答其实也是自然而然就知道如何回答了。

本文参考的资料为：

1. 长上下文视角——《Is RAG still needed? Choosing the best approach for LLMs》（YT视频）
2. 结构化数据视角——《Why the best AI coding tools abandoned RAG (and what they use instead) / Is RAG Dead?》（YT视频）
3. 系统作者视角——Boris Cherny(Claude Code 核心作者)在 Latent Space 播客的访谈
4. Harness 工程视角——飞书「大模型笔记」2.4.1 Retrieval 章节(检索工具谱系 + Agentic RAG 实验)

注意，其实我并不是说大家一定要去看对应的视频，为了严谨性我列出来源。笔记已经总结了上面的资料的各个方面的要点，已经是比较全面的了。看懂了笔记和我的视频，可以不用再去专门看上面的视频了。

9.1 背景 - 先把RAG这个词说清楚

RAG 是什么?

RAG = Retrieval Augmented Generation(检索增强生成)。

它要解决的是 LLM 的一个根本缺陷:模型被冻结在训练时刻——它不知道 5 分钟前发生的事,更不知道你的私有数据、内部 wiki、专有代码库。要让模型「知道」这些,就必须解决上下文注入(context injection):在正确的时间,把正确的数据放进模型的上下文窗口。

经典(传统)RAG 的管线是:

文档 → 切块(chunking) → embedding 模型编码成向量 → 存入向量数据库
用户提问 → query 向量化 → 语义搜索(semantic search)召回最相关的若干 chunk → 注入上下文窗口 → 生成答案

关键澄清:大家吵的RAG 已死,死的是哪个 RAG?

这是全篇最重要的区分,不厘清就会全程鸡同鸭讲:

• 传统 RAG / 语义搜索:指切块 + embedding + 向量库 + 语义召回这套具体管线。现状是在部分场景(尤其编程)被替代。
• 广义 RAG:指任何把外部信息拉进上下文的检索行为(grep、BM25、向量搜索、web 搜索都算)。现状是不可能死,是所有 Agent 的地基。
• RAG 的本意 就是抓取任何外部信息,拉进 LLM 上下文,增强它的回答。所以广义上,agent 用 grep 翻代码、用工具查数据库,本质都是 RAG,只是没有向量库那一套。
• 网上RAG is dead的暴论,几乎都在偷换概念:用传统 RAG 在编程场景被淘汰这个局部事实,去论证RAG 整体过时这个错误结论。
• 更进一步:Agentic RAG(智能体检索)本身仍然是 RAG,只是把一次性检索换成了模型自己迭代地、多轮地检索。

一句话定调:讨论RAG 是否过时,只有把范围收缩到传统的、切块 + 向量库的语义搜索管线才有意义。广义 RAG(检索)永远不会过时。

图 019 · 已恢复原图内容 · 点击放大

9.2 四个思维点

咱们可以先不讨论结论，先从4个方面去思考，我想思考清楚了这四个思维点，那么结论也呼之欲出。

9.2.1 大家说的RAG已死，死的是什么？

• RAG 已死是一个被 LinkedIn / X 放大的伪命题。视频作者直言:这个叙事大部分不成立,只是在编程这个特定场景有一点点为真。
• Klein 原创者 Nick Pash 甚至把盲目上 RAG 的风气称为mind virus(思维病毒):2023–2024 年,只要 agent 需要搜索,大家就无脑套语义相似 + 向量库,严重过度工程化。
• 但反过来,把传统 RAG 在编程被淘汰推广成RAG 全面过时,是同一枚硬币的另一面错误。
• Harness 视角给出了最精准的定性:Agentic RAG 本身就是 RAG,只是把一次检索换成迭代检索。所以从范式上讲,RAG 根本没被取代,而是换了形态继续存在。

小结:与其问RAG 死没死,不如问在我的场景里,那套沉重的切块 + 向量库管线还有必要吗?——这才是能回答的问题。

9.2.2 数据的结构化程度

传统 RAG 唯一真正值钱的超能力,是处理自然语言的模糊性——找到意思相近但字面不同的内容。判断要不要它,就看你的数据需不需要这个超能力。而数据需不需要,取决于它的结构化程度。所以先要把结构化和非结构化这两个词说清楚。

什么是非结构化数据?

指没有固定组织形式、以自然语言为主的数据——散落在 Google Drive、SharePoint、Confluence、wiki、SQL 里的海量文本。它的三个核心特征:

1. 语言是模糊的:同一个意思有无数种表达,同义词、近义词、指代、隐喻满天飞。
2. 靠概念含义而非字面组织:你想找的东西,常常和文档里的字面写法对不上——需要按意思相近来找,而不是按字一样来找。
3. 没有天然的导航结构:一份文档可能埋在成千上万份文档里,没有文件路径、语法这类现成地图帮你定位。

这类数据里,你想要的信息可能藏在几千甚至几百万份文档中,而且字面上根本没出现你搜的词。要跨同义词、跨概念把它们捞出来,就必须靠 embedding 捕捉语义相似。这正是传统 RAG 不可替代的场景。

什么是结构化数据?

指有精确语法、精确标识符、且自带组织结构的数据,代码是最典型的例子。它的三个核心特征:

1. 拼写/标识符是精确的:能正常运行的代码,函数名、变量名一定拼写精确——getUserProfile 全项目就叫这个,不存在另一种说法。
2. 不依赖语义近似:你要找的东西字面就是确定的,不需要靠同义词或概念含义去猜,关键词/正则(grep、ripgrep)就能精确命中。
3. 自带导航结构:文件夹、路径、架构本身就是现成地图,agent 用文件导航工具逐层 hone in 即可,不需要语义帮它理解大概在讲什么。

这类数据用精确匹配又快又准,再套一层语义搜索反而更不准、还多一堆维护负担。所以结构化数据不用 RAG。

两类数据的选型对比如下:

• 非结构化数据:特征是自然语言、模糊有歧义,同义词/指代多,靠概念含义组织,无天然导航结构,信息埋在海量文档里。该用传统 RAG(语义搜索)——因为靠 embedding 捕捉概念相似,才能跨同义词、跨字面把埋藏的内容召回。
• 结构化数据:特征是精确标识符、语法确定,字面即确定、无需猜意思,自带文件/路径/架构结构。不用 RAG,用 grep / 文件导航——因为字面就是确定的,精确匹配又快又准,再上语义反而更差且要维护索引。

经典例子——川菜:在知识库里搜川菜有哪些,库里那几段可能只写了麻婆豆腐,花椒配辣椒,麻辣鲜香,完全没有出现川菜两个字。关键词搜索按字面逐字匹配,搜川菜根本匹配不到这些段落,一条都召回不了;只有靠 embedding 的语义相似,才能认出麻婆豆腐，水煮鱼在意思上就是川菜,把这些段落召回。这就是非结构化数据离不开 RAG 的原因。

图 020 · 已恢复原图内容 · 点击放大

为什么代码(结构化)不用 RAG,三条:

1. 精确,不需要猜意思:能跑的代码拼写一定精确,getUserProfile 全项目就叫这个 → grep 直接 100% 命中,再上语义搜索反而更不准。
2. 自带组织结构:文件夹、路径、架构就是现成地图,agent 逐层导航即可,不需要语义帮它理解大概在讲什么。
3. 索引维护是负担:代码改动极频繁,向量索引很快漂移失同步;而普通文档几个月不变,索引好维护。

检索工具是一条谱系,不是二选一(Harness 视角补充): grep(词法/精确) → BM25(词法/倒排) → embedding(语义) → 结构化 DB(带 metadata) 从左到右,能力更强但成本更高。能用轻的就不上重的。

9.2.3 规模 vs 上下文窗口

传统 RAG 的第二个对手不是 grep,而是百万 token 的长上下文(直接把文档全塞进去,不做检索)。二者各有胜场:

长上下文赢在简单——三个理由:

1. 砍掉基础设施(no-stack stack):不需要切块策略、embedding 模型、向量库、reranker、同步逻辑——少了一堆会坏的环节。
2. 没有检索彩票:语义搜索是概率性的,可能静默失败(silent failure)——答案在库里,但没被召回,模型压根没看到。长上下文让模型看到全部,不存在这个失败点。
3. 整本书问题:RAG 只能检索存在的内容,无法回答缺了什么。比如对比需求文档和发布说明,哪些安全需求被遗漏了——RAG 只能召回零散片段,看不到两份文档之间的空缺;长上下文把两份文档整体喂进去才能做这种全局对比。

但 RAG 依然不可替代——三个理由:

1. 重复读取成本:长上下文每次查询都要重新处理整份文档(500 页 ≈ 250k token,每次都付这个税);RAG 只在建索引时处理一次。(prompt caching 能部分抵消静态数据,但动态数据仍要全额付费。)
2. 大海捞针(needle in haystack):上下文越长(50 万+ token),模型注意力越被稀释,埋在中间的单段信息经常漏掉或幻觉;RAG 只给 top-k 相关块,降噪聚焦,反而更准。
3. 无限数据集:企业数据是 TB / PB 级,百万 token 只是杯水车薪。要在无限数据里定位,必须有检索层先过滤到能塞进窗口的量。

该视角的结论:

• 有界数据 + 需要全局推理(分析单份合同、总结一本书)→ 用长上下文。
• 无限的企业级知识 → 向量数据库(RAG)仍是唯一可行的仓库。

图 021 · 已恢复原图内容 · 点击放大

9.2.4 工程成本与按需外挂

Boris Cherny(Claude Code 核心作者)的第一手复盘:早期 Claude Code 真的用过 RAG——用 Voyage embedding 给代码库建索引,但后来整个放弃,转向 agentic search(glob + grep 的常规代码搜索)。原因三条:

1. 性能:agentic searchoutperformed everything. By a lot.(全面碾压,大幅度)。他很坦诚地补充,这个判断主要是just vibes(内部凭感觉),也有一些内部 benchmark。
2. 索引复杂 + 代码漂移:RAG 需要建索引步骤,而the code drifts out of sync(代码不断变化,索引很快对不上)。
3. 安全 / 责任(视频里普遍忽略的一条):索引必须存在某个地方,what if that provider gets hacked?(存索引的服务商被黑怎么办)——对公司是a lot of liability(巨大的责任风险)。Anthropic 不愿把敏感代码上传第三方。

他对这个权衡的总结:

at the cost of latency and tokens, you now have really awesome search without security downsides. (代价是牺牲一点延迟和 token,但换来极棒的搜索,且没有任何安全隐患。)

Harness 工程视角把这条思路一般化:

• 不要把通用 AI 工具当万能工具。Claude Code 内置 grep,但 CC 是通用的,而你的业务是定制的——代码库可能 100GB、文档跨多仓库、查询带 metadata 过滤。这时通用工具会慢甚至搜不到。
• 关键的实证:视频里 Raj 的实验中,Agentic + 纯 BM25反超了One-shot + embedding 切块。这说明随着模型变强,语义近似这层不一定非要靠 embedding,模型自己重写 query 就能补上。但这是embedding 从必选变可选,不是BM25 取代 embedding。
• 所以最精准的定性是:RAG 没被取代,而是从默认必选降级成按需启用的一档。

9.3 总结&结论

先把 RAG 的账算清楚——它的优点和缺点各是什么。

传统 RAG(切块 + embedding + 向量库)的核心优点有三:

1. 能做语义搜索:靠 embedding 捕捉概念相似,能跨同义词、跨字面把埋在海量文档里、字面根本没出现搜索词的内容召回——这是 grep 这类字面匹配做不到的。
2. 又快又省成本(核心优势):预先切块 + 建索引,查询时只拉几个小 chunk,而不是把整个知识库/整份文档塞进上下文。这一个机制同时带来两个好处——

• 省成本:喂给模型的输入 token 大幅减少,大知识库下比让模型读整份文档或多轮 agentic 扫描便宜约 100 倍。
• 快 / 低延迟:检索直接走索引(向量 HNSW O(log N) / BM25 倒排 O(K))秒级命中,加上塞进上下文的内容少、模型推理也快;相比让 agent 用 grep/cat 在海量非结构化文档里逐个遍历(视频原话:慢到爆、贵到爆),定向拉 chunk 快得多。
• 一句话:只取最相关的一点点,而不是处理全部——省的是钱,快的是这同一件事的另一面。 3. 降噪聚焦:只返回 top-k 相关块,把大海捞针里的草堆先扔掉,给模型的是信号而非噪声,反而比长上下文全塞进去更准。

它的核心缺点也有三:

1. 要维护一套重基础设施:切块策略、embedding 模型、向量库、reranker、同步逻辑——环节多、都可能坏;索引还会随源数据变化而漂移失同步,代码这种高频变动的数据尤其吃亏。
2. 检索是概率性的,会静默失败:语义召回不保证命中,答案可能就在库里却没被检索到,模型压根没看到——而它不会告诉你我没找到。
3. 只能召回存在的片段,做不了全局推理:它给的是零散 chunk,回答不了两份文档之间缺了什么这类需要看全局的问题。

再下结论——它在哪被取代、在哪没被取代。

传统 RAG 已在两类场景被更优方案取代:

1. 结构化数据(尤其代码):字面精确、自带文件结构,grep / 文件导航又快又准还免维护,不需要语义那一层——Claude Code 弃用 RAG 正是这个原因(性能更好 + 无索引漂移 + 无安全负担)。
2. 有界 + 需全局推理的数据(单份合同、整本书对比):长上下文直接全塞进去,省掉整套检索栈,还避开了静默失败,反而更适合。

此外,即便需要语义,提供语义的活也不再由 embedding 独家承包:模型够强时,Agentic + BM25(模型自己重写 query,把语义翻译成关键词)也能达到甚至反超传统切块 RAG——所以 embedding 从必选降为可选。

但传统 RAG 在这些场景仍不可替代

1. 海量非结构化知识库(客服、法律、合规、企业 Wiki,乃至 TB/PB 级数据湖):长上下文只是杯水车薪,必须靠检索层先把数据过滤到能塞进窗口的量,向量库是目前唯一可行的仓库。
2. 延迟 / 成本有硬约束的生产环境:面向大量用户的语义问答系统、有明确延迟与成本 SLA(如高并发客服问答),既不能对每个 query 跑多轮 agentic 检索(太慢、2–5x token),也不能每次把知识库塞进长上下文(装不下、更贵)。预建索引的 RAG 一次检索、毫秒级命中、每查询成本固定且低——这时它是唯一能同时扛住并发与预算的方案。

RAG 仍具显著优势(虽未到不可替代)的场景:

强依赖语义搜索、但同时在意成本与速度:这类任务 Agentic + BM25 确实能取得相同甚至更好的效果——所以谈不上不可替代。但 agentic 方案强依赖顶级模型能力(query 重写要够聪明才补得出语义),还要付出多轮迭代的 2–5x token 和更高延迟。相比之下,传统 RAG 把语义预先烧进索引,一次检索即得,更快、更省、且不挑模型(不需要 Opus/GPT-5 级也能跑)。所以当语义需求强,但你不愿为 agentic 买单时,RAG 虽非不可替代,仍是性价比更优的一档。

一句话:传统 RAG 从默认必选降级为按需启用的一档——在小型/结构化/有界场景被 grep、长上下文、agentic 搜索取代;在海量非结构化、以及对延迟成本有硬约束的生产场景仍不可替代;即便在 agentic 可替代的语义场景,它也常因更快、更省、不挑模型而保有优势。而广义 RAG(检索)作为一切 Agent 的地基,永远不会过时。

9.4 场景题小测试

我们上面讲了，狭义的RAG变成了按需取用，它只是Agent检索能力的一种实现方式。那么对于不同的场景，我们应该如何选择方案呢？这里给一些场景和选型策略供大家参考。

思路统一为三步——看数据结构化程度 → 看规模 → 看查询形态,能用轻的就不上重的。

图 022 · 已恢复原图内容 · 点击放大

最佳实践清单

1. 默认 grep 起手:90% 的代码搜索靠 grep 就够,别一上来就上向量库。
2. 量级到了再加 BM25:代码库 >5GB 或 >10w 文件,包一个 Skill 封装 ripgrep --index 或 BM25 库。
3. 跨同义词才用 embedding:日常代码定位别用,跨语言 / 跨概念查找才上语义搜索。
4. 模型够强就上 Agentic RAG:让模型自己重写 query、按文件级迭代,比预切 chunk 更准(代价 2–5x token)。
5. 文件级 > chunk 级:能不切块就不切块,整文件交给模型,避免上下文撕裂。
6. 需要 metadata join 才迁数据库:纯文本搜索别上 DB。

Q:我在做一个 coding agent,要在中小代码库里定位函数/改代码,用什么?

A:用 grep / ripgrep,不建任何索引。代码是结构化数据,字面精确,grep 现扫就 100% 命中且免维护;本地项目规模不大,线性扫盘足够快。这正是 Claude Code 的选择。

Q:代码库超大(比如 100GB、上千万文件),grep 扫盘太慢了怎么办?

A:加一层 BM25 倒排索引(包成 Skill 挂给 agent)。它查询 O(K)、与库大小无关,解决 grep 线性扫盘的慢;仍是词法匹配,不碰 embedding。这是规模把你从零索引推到轻索引,不是因为需要语义。

Q:要查用户鉴权相关的代码,但关键词散在 auth / login / session / jwt 里,grep 搜不全?

A:这是跨同义词/跨概念的查找,字面匹配天然漏召回,有两条路都能走,按模型强度 vs 成本/延迟权衡:

• embedding 语义搜索:预建向量库,靠向量捕捉概念相似,一次召回稳定拿到结果,查询快、单次成本低——适合成本/延迟敏感或高频查询。
• Agentic + grep/BM25:让模型自己把用户鉴权重写成 auth|login|session|jwt 一组关键词、多轮迭代搜。省掉建索引,但要求模型能力够强,且多轮迭代 token 和延迟更高。

注意:日常精确定位(已知函数名)别用这两种,grep 直接命中就好。

Q:要分析一份合同、或对比两份文档找出遗漏了什么,用 RAG 吗?

A:不唯一,看数据量和关联复杂度选:

• 数据塞得下 → 长上下文直接全塞进去:需要全局推理,让模型看到全貌才能发现文档之间的空缺,还省掉检索栈、避开静默失败。这是有界数据的首选。
• 数据太大塞不下 → 仍要 RAG 先过滤:普通向量 RAG 只给零散 chunk 容易看不到全局,可退而用它把范围缩到能塞进窗口的量再做对比。
• 实体/条款间有复杂关联 → GraphRAG:先把文档抽成实体-关系图,用图结构显式建立这条需求 ↔ 那条发布说明的关联,比纯向量召回更能支撑缺了什么这类跨文档推理。

Q:要给公司几十万份客服/法律/Wiki 文档做问答系统,用什么?

A:标准 传统 RAG(切块 + embedding + 向量库)。典型的海量非结构化数据:字面对不上、靠概念含义组织、塞不进上下文——必须靠语义检索 + top-k 降噪,这是 RAG 的主场。

Q:企业数据到了 TB / PB 级,长上下文完全装不下,怎么办?

A:必须有 RAG 检索层。百万 token 在这种量级只是杯水车薪,得先用向量检索把数据过滤到能塞进窗口的量;向量库是目前唯一可行的仓库。

Q:查询需要按作者过滤 + 按提交时间排序 + 按路径匹配这种带条件的检索?

A:上 结构化 DB / metadata 索引(可与 RAG 混合)。这已经不是找相关内容而是按字段筛选 join,grep 和向量都做不了,需要数据库式的字段过滤。纯文本搜索则别上 DB。

Q:模型够强(Opus / GPT-5 级)、预算也够,想要最好的检索质量?

A:上 Agentic RAG——让模型自己重写 query、按文件级迭代检索,底层用 BM25 / embedding / 混合都行,坚持文件级 > chunk 级避免上下文撕裂。代价是多花 2–5x token 和延迟,换来更高准确率。

9.5 面试题

希望大家能真的理解上面说的，有自己的思考。那么如果从这些维度想清楚了，下面的面试问题的答案其实就非常明显了。

Q1:你认为 RAG 过时了吗?

A:我的判断是——传统 RAG 在部分场景被降级,但整体没有过时,更准确地说是换了形态。回答这个问题,必须先厘清在讨论哪个 RAG。

大家喊RAG 已死时,死的是切块 + embedding + 向量库 + 语义召回这套传统管线;而 RAG 的本意是把外部信息检索进上下文,这个广义 RAG 是所有 Agent 的地基,不可能死。连 Agentic RAG 本身也仍然是 RAG,只是把一次检索变成迭代检索。

传统 RAG 确实在退位,有两股力量:

• 一是长上下文:百万 token 窗口让有界数据 + 全局推理的场景(如分析单份合同、对比两份文档找缺漏)可以直接把文档全塞进去,省掉整套检索基础设施,还避免了语义搜索的静默失败。
• 二是 Agentic 搜索:模型变强后,它能自己重写 query、多轮迭代检索,有实验(Raj)显示Agentic + 纯 BM25能反超One-shot + embedding 切块——说明语义近似这层不一定非靠 embedding。

但传统 RAG 在三类场景仍不可替代:

• ① 海量数据(企业 TB/PB 级):这种量级下长上下文根本装不下,只是杯水车薪;而且如果不上 RAG、改用 agentic 现扫,面对无限数据每次查询都要海量扫描,速度会慢到不可用。必须靠检索层先把数据过滤到能塞进窗口的量,向量库是目前唯一可行的仓库。
• ② 非结构化 + 跨同义词:内容靠概念含义组织、字面对不上,关键词根本搜不到,只有 embedding 捕捉概念相似才能召回。虽然Agentic + 语义检索(让模型自己重写 query)理论上也能达到,但这要求模型能力足够强,且多轮迭代的 token 成本和延迟都很高;用预建的 embedding 向量库,一次召回就能稳定拿到结果,更省更快。
• ③ 成本 / 延迟敏感的场景:当你需要严格控制查询成本和响应速度时,事先建好索引的优势就出来了——切块 + 建索引只在离线做一次,查询时只拉 top-k 个小 chunk,近似最近邻 O(log N) 一次命中;相比每次都让模型读整份文档或多轮 agentic 扫描,延迟更低、单次查询成本可低约两个数量级。

所以结论是:RAG 从默认必选降级为按需启用的一档,而不是被淘汰。 判断要不要用,看三个条件:文档规模、查询是否需要跨同义词、以及对成本 / 延迟的要求。

Q2:你如何选择用不用 RAG?如何设计项目的检索模块?

A:核心原则是——不要把通用工具当万能工具,而要按场景在检索谱系上选一档;能用轻的就不上重的。

我会分三步走:

第一步,看任务量级和查询形态。 先问两个问题:数据多大(单项目 / 超大代码库 / 企业级数据湖)?查询是纯文本、跨同义词、还是带字段过滤?

第二步,在检索谱系上选档。 检索工具从词法到语义是一条谱系,不是二选一,从轻到重依次是:

• 词法 · 精确(grep / ripgrep):适用于结构化数据、中小代码库(默认起手,90% 够用)。
• 词法 · 倒排(BM25):适用于超大代码库(>5GB / >10w 文件)。
• 语义(embedding + 向量库):适用于非结构化、跨语言 / 跨同义词。
• 结构化(DB + metadata):适用于需要 join 的场景(按 author 过滤、按时间排序)。

具体判据:

• 默认 grep 起手;结构化数据 + 精确匹配,根本不用 RAG。
• 规模上去了加 BM25;跨同义词才上 embedding。
• 有界数据 + 全局推理 → 优先考虑长上下文,而非 RAG。
• 海量非结构化 → 传统 RAG 是唯一可行仓库。
• 需要 metadata join → 结构化 DB + RAG 混合。
• 模型够强 + 预算够 → 上 Agentic RAG(底层 BM25 / embedding / 混合均可),让模型自己迭代,并坚持文件级 > chunk 级,避免上下文撕裂。

第三步,用 Skill / 工具封装,交给 agent 按需调用。 更前沿的做法是给 agent 同时配好精确搜索 + 语义搜索两种工具,让它根据具体 query 自己决定走哪条路——这就是桥接思路。

一句话:检索模块的设计,本质是 harness 工程——agent 的能力上限不只取决于模型,更取决于你给它配的工具链。

Q3:Claude Code 为什么不用 RAG?

A:先纠正一个常见误解——不是不能用,而是核心不内置那套向量库管线。原因来自数据环境和工程权衡两方面,Claude Code 核心作者 Boris Cherny 给过第一手复盘。

先说根本原因:决定用不用 RAG 的是数据环境,不是任务类型。 Claude Code 虽然是通用 agent,但它面对的数据环境永远是本地文件系统 + 终端——有界(单个项目)、天然结构化(文件夹 / 路径 / 文件名)、可直接 grep。这种环境用 agentic search + 长上下文就够了。而 RAG 的刚需场景是海量 + 非结构化 + 无法直接导航的企业级知识库,Claude Code 的工作目录一条都不占。

再说 Boris 的三条具体理由(早期 Claude Code 确实用过 Voyage embedding 建索引,后来放弃):

1. 性能:agentic search全面碾压,大幅度(他坦承主要凭内部 vibes,也有内部 benchmark)。
2. 代码漂移:代码改动极频繁,向量索引很快out of sync,维护成本高。
3. 安全 / 责任:索引要存在某处,服务商被黑就是巨大的责任风险,Anthropic 不愿上传敏感代码。

他的总结:代价是延迟和 token,但换来极棒的搜索,且没有安全隐患。

补充两点让回答更完整:

• 代码是结构化数据,拼写精确、自带文件结构,grep 能精确命中,本就不需要 embedding 的语义近似超能力。
• Claude Code 不内置 RAG,不代表它做不了 RAG——它可以通过 MCP / 工具外挂一个语义检索能力。RAG 对它是按需外挂,不是出厂内置。 为了少数场景让所有用户默认背上索引复杂 + 漂移 + 安全责任这套包袱,不划算;核心保持精简,谁真需要谁再插上去。

9.6 讲解视频

https://www.bilibili.com/video/BV1YdMp6kEEf/?spm_id_from=333.1387.homepage.video_card.click&vd_source=144bec9c3f54e465073138bed788be1b

Agent

（对不起，Agent目录越来越多，我知道我应该重构一下，比如两个实战项目，PI Agent和DeepSeekHarness ，可以放在一起并且放到最后面

但飞书目录重构真的很麻烦，我没想到一个很好的方案去重构目录，如果我要改动目录，标号都得一个个改，而且文档内的很多链接索引可能都乱了。

大家可以先把所有的子章节都折叠，虽然一级目录可能没有特别有条例，但一级目录只有不到20个，不过你可以自己从这一级目录中找到你需要的，然后再阅读。后面我想到好方法重构目录，我会重构的。）

1.Agent开发框架

该小节重构于2026年8月。

根据我2026 年的面试经验，Agent 框架已经不算一个高频考点，同时对框架的考察一直不会很深入。

在 2025 年，可能大家还还认为 LangChain 非常重要，因此会像准备八股文一样，集中背诵 LangChain、LangGraph 的组件、概念和基本特性。但到了 2026 年，我觉得这件事没有太多意义了。Langchain并不是你要从事大模型开发岗位的必学内容了。

我认为原因其实也很容易理解：Agent 框架只是开发 Agent 应用的工具，工具本身不是重点，工具背后封装的 Agent 能力才是重点。况且各个公司开发用的框架也不一样，深入学习一个框架，对于面试来说性价比并不高。

不同框架的 API 并不通用，但它们处理的核心问题高度相似，例如：

• 如何把函数、API、数据库或 MCP 服务封装成工具；
• 如何实现“模型决策—调用工具—读取结果—继续决策”的 Agent Loop（智能体循环）；
• 如何维护会话状态、短期记忆和长期记忆；
• 如何管理上下文、压缩历史和控制 Token；
• 如何进行分支、循环、并行、暂停与恢复；
• 如何实现 Human-in-the-loop（人工介入或审批）；
• 如何管理工具权限、凭据和执行沙箱；
• 如何记录 Trace（执行链路）、评测效果和失败原因；
• 如何保证重试、幂等、审计和生产可靠性。

这些才是不同 Agent 框架背后共用的“内核”。掌握内核以后，切换框架主要是学习新的抽象和 API；如果只会背某个框架的 API，一旦项目更换技术栈，原有知识就很难迁移。

因此，LangChain 在我看来已经不是所有人都必须深入掌握的内容。你完全可以使用其他 Agent 框架，也可以不使用框架，直接基于模型 API 手写 Agent。框架的价值是减少重复开发，而不是赋予模型某种只有该框架才具备的智能。

回到面试角度，我来给大家画一下重点。

必学的内容：

1. 知道市面上有什么框架，他的特点，优缺点，局限性。如何科学选择Agent的开发框架。这个无论是对于你自己做项目框架选型还是回答面试问题，你为什么使用这个框架，都有帮助。

2.如果你使用了某个框架，那么请深入聊加一下这个框架的特点，设计思想，理念，特性。 对于你没用到的，简历里没写的框架，那么不做学习要求。

本小节笔记编写也遵循这个逻辑：

1.1 小节属于必学:带你了解2026年有哪些Agent框架，特点是什么，如何选型，同时讲清楚上面两个Agent框架最高频的面试问题：这个是学完上面内容的面试实战运用，也是面试官问Agent框架，几乎一定会先问的问题。

1.2 小节是历史遗留章节，讲解了Langchain/Langgraph的一些特点。我知道这里内容有一点过时，因为Langchain有更新的版本了。 我没有删除的原因是 ：历史的面经，特别是25年的面经有问到引用了这个章节，但更重要的是，根据我们的思想，如果你用了某个框架，你应该自己主动去深入理解一下，比如你项目用了Langchain，你就应该稍微比笔记多了解一下。所以留在这里一个LangChain的一点内容，是一个提醒。你应该根据自己用的框架，稍微补充一点相关知识。

1.1 主流框架和选型策略

1.1.1 框架速览

这一小节快速带大家了解，2026年8月，市场上流行的主流框架有哪些，建立初印象。

我们用 GitHub 官方代表仓库的 Stars 数量衡量开源社区关注度，数据通过 GitHub API 查询，统计时间为 2026 年 8 月 11 日。相比笼统地写“高”或“较高”，Stars 至少提供了一个公开、可复查的量化依据。

不过，Stars 只能作为热度参考，不能直接等同于生产成熟度或企业采用率，原因包括：

• 项目发布时间不同，较早发布的项目天然更容易积累 Stars；
• Dify、LangChain 等面向更广泛的 AI 应用用户，受众规模与纯 Agent 运行时不同；
• Claude Agent SDK、Google ADK 等项目采用多语言分仓，单个 Python 代表仓库可能低估整体生态；
• GitHub Stars 无法反映闭源企业使用、云平台内部使用、API 稳定性、安全性和维护质量；
• Stars 是累计值，不能单独反映近期增长速度和当前活跃度。

因此，下表把 Stars 称为开源社区关注度，而不是“框架质量分”或“市场占有率”。对于多仓库项目，统一选择最具代表性的官方主仓库，不对多个语言仓库的 Stars 求和。

图 023 · 已恢复原图内容 · 点击放大

按本次统计的代表仓库 Stars 排序，前三名是 Dify（152.1k）、LangChain（143.9k） 和 CrewAI（56.9k）。这说明它们在开源社区中的关注度较高，但由于三者分别属于低代码平台、高层应用框架和多 Agent 框架，不能据此判断谁在技术上更适合某个具体项目。

1.1.2 各框架使用方式

先讲解各个Agent框架使用方式，这是最直观理解不同框架的特点的角度了。

1.1.2.1 方法一：组装组件——定义 Agent、工具和输出

使用这类框架时，你通常先选择模型，再创建一个 Agent，为它写系统指令，并把搜索、数据库查询、发送邮件等函数注册成工具。如果结果需要固定格式，还会定义一个输出数据结构。运行后，模型可以返回工具调用请求；框架执行对应函数，再把结果交回模型，直到模型给出最终答案或达到开发者设置的停止条件。

换句话说，你开发的主要形式是：配置 Agent + 挂载 Tools + 调用 run()。这里的“模型决定下一步”只限于一次 Agent 运行循环：模型决定此刻直接回答，还是请求调用某个已注册工具。工具的具体实现、允许调用哪些工具、调用次数、权限以及外层业务流程仍然由代码控制。代表框架：LangChain、PydanticAI、OpenAI Agents SDK。

图 024 · 已恢复原图内容 · 点击放大

1.1.2.2 方法二：搭建状态图——定义 State、Node 和 Edge

使用 LangGraph 时，你不是只创建一个 Agent 然后让它自由运行，而是先定义一份 State，用来保存消息、任务结果和执行进度；再把每一步操作写成 Node，例如“模型判断”“调用搜索工具”“人工审核”；最后用 Edge 把节点连接起来，并定义什么条件下走哪条边。

程序运行时，State 在节点之间不断传递和更新。开发者真正搭建的是一张可循环、可分支的执行图。它的开发形式可以概括为：定义状态 → 编写节点 → 连接边 → 编译并运行图。代表框架：LangGraph。

图 025 · 已恢复原图内容 · 点击放大

1.1.2.3 方法三：组织 Agent 团队——定义 Role、Task 和协作关系

使用 CrewAI 一类框架时，你首先要做的不是画流程，而是创建多个 Agent。每个 Agent 都要定义自己的角色、目标、背景说明和可用工具，例如研究员负责搜集资料，作者负责写作，审核员负责检查。然后再定义每个角色要完成的 Task，以及任务按顺序执行、并行执行还是由管理者动态分派。

这种方法写出来的程序很像在组建项目团队：定义 Agents → 分配 Tasks → 设置协作方式 → 启动 Crew。任务在不同角色之间流转，每个 Agent 只处理自己负责的部分。代表框架：CrewAI、AgentScope。

图 026 · 已恢复原图内容 · 点击放大

1.1.2.4 方法四：配置工作环境——给 Agent 任务和可操作的电脑

使用长任务 Agent Harness 时，开发者通常不需要把几十个步骤全部预先写出来。你要做的是给 Agent 一项总体任务，配置它可以使用的环境和权限，例如文件系统、终端、浏览器、代码仓库，以及必要的工具和子 Agent。Agent 收到任务后，会自己制定计划、读写文件、执行命令、检查结果，并根据中间产物继续工作。

这种开发方式更像给一位数字员工准备工作台：描述目标 → 配置环境与工具 → 设置权限 → 让 Agent 持续执行。代表框架：Deep Agents、Claude Agent SDK。

图 027 · 已恢复原图内容 · 点击放大

1.1.2.5 方法五：搭建知识管道——定义数据源、索引和查询流程

使用 LlamaIndex 时，开发往往分成两部分。第一部分是准备知识：接入 PDF、网页或数据库，把内容切分成节点并建立索引；第二部分是使用知识：定义检索器或查询引擎，让 Agent 在回答问题或调用工具前先找到相关资料。

因此，你主要开发的不是角色或流程图，而是一条数据进入 Agent 的管道：加载数据 → 切分与索引 → 检索相关内容 → 交给 Agent 回答或行动。代表框架：LlamaIndex。

图 028 · 已恢复原图内容 · 点击放大

1.1.2.6 方法六：在平台中编排并发布——配置工作流和应用

使用平台型框架时，你面对的通常不是单一的代码库，而是一套把开发、调试、发布和观测放在一起的完整平台：先选择模型，填写 Agent 指令，添加工具或知识库，再用代码或可视化画布连接处理步骤。完成后，可以直接在平台内测试、评估、部署为 API 或聊天应用，并查看运行日志。

所以，这一类框架的核心区别不只是“前面写代码，这里拖拽界面”，而是框架是否把 Agent 的全生命周期一起打包了：既管怎么搭，也管怎么测、怎么发、怎么监控。它关注的是一个完整应用，而不只是 Agent Loop：配置 Agent → 编排 Workflow → 调试评估 → 部署应用 → 查看日志。代表框架：Dify。

图 029 · 已恢复原图内容 · 点击放大

1.1.3 框架核心特点

上面从框架使用方式角度介绍，这里从框架最核心的特点介绍，每个框架用一句话，说明他的最核心的特点。

• LangChain：生态最丰富的通用工具箱。 接模型、工具和检索非常方便，适合快速做原型；但抽象较多，复杂流程容易变得不透明。
• LangGraph：控制力最强的状态图框架。 状态持久化、检查点、恢复和“时间回溯”能力突出；代价是建模最复杂，开发者要自己设计 State、Node 和 Edge。
• Deep Agents：为长任务准备好的 Agent 骨架。 自带规划、工作区、上下文压缩和子 Agent，适合研究与多文件任务；短任务使用它会显得偏重。
• OpenAI Agents SDK：轻量且容易上手的官方 SDK。 Agent、工具和 Handoff 概念简洁，与 OpenAI 的语音、追踪和评测结合自然；深度使用后会增加 OpenAI 生态绑定。但是缺点是编排能力比较弱，不支持并行和循环。
• Claude Agent SDK：最擅长操作电脑环境。 文件读写、Shell、搜索和代码修改能力开箱即用，特别适合编码 Agent；同时必须认真处理权限、沙箱和执行安全。
• Google ADK：最像传统软件工程的 Agent 框架。 它允许开发者用顺序、并行和循环等代码结构组织多个 Agent，把模型的自主判断嵌入确定性流程，并配套会话、记忆、产物和评估能力；优点是结构完整、适合复杂工程，缺点是概念较多，简单任务使用会显得偏重。
• Microsoft Agent Framework：最适合微软技术栈的企业框架。 对 Azure、Microsoft 365、身份治理和 .NET 团队友好；非微软技术栈使用它的优势会明显减弱。
• CrewAI：最直观的角色型多 Agent 框架。 用研究员、作者、审核员等角色组织任务很容易理解；多个 Agent 也会带来更高的 Token、延迟和调试成本。
• PydanticAI：最强调类型安全的轻量 Python 框架。 工具参数、依赖和输出结构清晰，适合 API 与结构化数据任务；它不是复杂工作流或长任务运行时。最大的特点是类型安全，使用FASTAPI编程方式。
• LlamaIndex：数据与 RAG 能力最突出。 文档接入、切分、索引和检索链路完整，适合知识库与数据密集型 Agent；但接上向量库不等于检索质量自然可靠。
• Dify：最容易快速做出可用应用。 通过拖拽即可组合模型、知识库、工具和工作流，并直接发布；画布复杂后，测试、复用和深度定制会比较困难。
• AgentScope：更贴近国内企业环境的多 Agent 框架。 对国产模型、Python/Java、私有化和国内云生态更友好；国际社区与第三方生态相对较弱。

记住这些核心特点后，再阅读每个框架的详细介绍，就可以把更多功能理解为对这条主线的补充，而不必一次记住所有概念。

1.1.4 各框架特点详细介绍

我通过1.1.1\~1.1.3 是想让大家能够对这些框架建立一个印象。你不要背，也能够轻松知道常见的一些框架，对它有一个印象。某种程度也是为这个小节做铺垫，这个小节很枯燥，但是是面试问题：讲讲你了解的Agent框架。该背还是得背一下，有了前面的小节，应该背起来容易一点。但你不用都背，这个小节就是防止面试官问：你知道什么Agent框架，讲一下？所以你是要挑你项目使用的，或者关注的几个背就行了。

这个小节每一个框架下面我都穿插了面试问题，供大家检验。

1.1.4.1 LangChain：高层 LLM 应用工具箱

定位：LangChain 主要负责连接模型、消息、工具、结构化输出、检索和高层 Agent。它适合快速组装应用，但不应被理解为所有复杂 Agent 系统的统一底座。

核心特性：多模型与多工具集成、标准化消息和 Prompt、结构化输出、高层 Agent 接口、检索与文档组件，并可与 LangGraph 组合。

优点：生态广、资料多、接入快，适合验证模型、工具和数据链路。

局限：抽象较多；只使用高层 Agent 时，复杂控制流不如显式状态图清晰；集成数量多也不代表每个组件都具有相同的生产质量。

适用场景：通用 Agent、快速原型、集成驱动型应用。严格持久化、恢复、审批和复杂状态控制通常应进一步使用 LangGraph 或其他工作流运行时。

写入简历后要掌握：实际使用了哪些模块；为什么没有直接调用模型 SDK；复杂流程是否引入 LangGraph；模型、工具和检索抽象为项目减少了哪些工作。

面试小卡片｜请简单介绍一下你了解的 Agent 框架

核心特点。 我了解的 LangChain 是一个通用的 LLM 应用开发框架。它把模型、Prompt、消息、工具、结构化输出和检索封装成可组合组件，开发者可以为 Agent 注册搜索、数据库等工具，再由模型在运行过程中选择是否调用。它更像一个连接各种 LLM 能力的标准工具箱，重点是减少不同模型、工具和数据源之间的适配工作，而不是强制开发者采用某一种固定流程。

优缺点。 它最大的优势是生态丰富、资料多，接入不同模型和第三方服务都比较快，切换模型或替换工具时也能复用一部分上层代码。缺点是抽象层较多，组件版本和行为边界需要认真理解；只使用高层 Agent 时，复杂分支、状态变化和失败恢复不够直观，这类需求通常会再结合 LangGraph。

适用场景。 我会把它用于通用工具 Agent、RAG 应用、模型与工具集成，以及需要快速验证想法的早期原型。如果业务流程非常固定，我可能直接写普通代码；如果流程复杂且必须恢复，我会让 LangChain 负责模型和工具接入，让 LangGraph 负责运行控制。

1.1.4.2 LangGraph：显式状态与流程控制

定位：LangGraph 是面向有状态、可恢复、长时间运行 Agent 工作流的编排运行时。核心价值是控制力和可靠执行，而不是让模型本身更聪明。

核心特性：Node、Edge、State；条件分支、循环、并行；Checkpoint（检查点）和状态持久化；Interrupt、恢复执行、Human-in-the-loop；流式事件和多 Agent 编排。

优点：控制流显式，复杂流程更容易理解、审计和恢复，也更适合将不确定的模型决策嵌入确定性业务流程。

局限：学习和建模成本较高；开发者仍需自己设计 State Schema、重试、幂等和副作用隔离；对简单问答可能过重。

适用场景：审批、供应链、金融流程、多阶段研究、长任务和必须恢复的业务。

写入简历后要掌握：State 保存什么；节点和条件边如何设计；Checkpoint 存在哪里；服务重启后如何恢复；怎样防止重试导致重复写库或重复扣款；为什么不用普通代码或高层 Agent。

面试小卡片｜请简单介绍一下你了解的 Agent 框架

核心特点。 我了解的 LangGraph 是一个用状态图编排 Agent 的运行时。开发者先定义保存消息和业务数据的 State，再把模型调用、工具执行和人工审核写成 Node，最后通过 Edge 和条件分支规定节点之间怎样流转。每个节点读取并更新同一份状态，因此循环、重试、人工审批和多 Agent 交接都可以明确地画进执行图中。

优缺点。 它最大的优势是控制力和恢复能力强，支持 Checkpoint、Interrupt、持久化和时间回溯，任务中断后可以从历史状态继续，也能查看某一步之前的状态。缺点是建模成本较高，框架只提供运行机制，不会替开发者自动解决 State Schema、重试、幂等和副作用隔离等业务设计问题。

适用场景。 它适合审批、金融流程、多阶段研究和长时间运行任务，尤其适合执行失败后不能简单从头重跑的业务。比如贷款审核进行到人工复核时可以暂停，收到审核结果后再从原状态继续，而不需要重新执行前面的查询和判断。

1.1.4.3 Deep Agents：面向长任务的 Agent Harness

定位：Deep Agents 是面向长时间、开放式任务的高层 Agent Harness。它与 LangGraph 不是简单竞争关系：前者偏开箱即用的长任务骨架，后者偏可定制的底层状态运行时。

核心特性：任务规划、待办管理、文件系统和工作区、上下文压缩、中间结果卸载、子 Agent 委派、工具和 MCP 接入，以及底层运行时提供的持久化和人工审批能力。

优点：不必从零搭建长任务所需的结构，适合多文件、大量中间结果和开放式目标。

局限：对短任务较重；默认行为不一定适合所有业务；涉及 Shell、代码和文件操作时仍需安全沙箱和权限策略。

适用场景：深度研究、编码、长报告、多文件分析。若流程非常明确并要求逐节点控制，直接使用 LangGraph 自定义可能更合适。

写入简历后要掌握：为什么任务属于长任务；如何管理工作区、上下文和中间产物；子 Agent 的职责边界；如何做权限与沙箱；为什么没有直接用 LangGraph 自建。

面试小卡片｜请简单介绍一下你了解的 Agent 框架

核心特点。 我了解的 Deep Agents 是一个面向开放式长任务的 Agent Harness。它预置任务规划、待办管理、文件工作区、上下文压缩、中间结果卸载和子 Agent 委派，让 Agent 可以持续推进一个不能一次完成的目标。它和 LangGraph 不是简单替代关系：LangGraph 更像底层可恢复运行时，Deep Agents 则是在上面准备好了一套长任务工作方式。

优缺点。 它的优势是不用从零搭建长任务骨架，Agent 可以把大量中间内容写入文件，并通过子 Agent 分担不同部分，避免所有信息都挤在一次上下文中。缺点是对简单短任务偏重，默认规划方式不一定适合所有业务，任务跑得越久，成本、错误累积和文件工具的安全风险也越需要管理。

适用场景。 它适合深度研究、长报告、多文件分析，以及需要拆分任务、保存大量中间结果并持续执行的复杂工作。例如让 Agent 阅读几十份资料、分别生成研究笔记，最后再汇总成一份完整报告，就比普通的一次性 Agent Loop 更适合使用 Deep Agents。

1.1.4.4 OpenAI Agents SDK：轻量的 OpenAI Agent SDK

定位：OpenAI Agents SDK 与 OpenAI 的模型、Responses、Realtime、Tracing 和 Evals 生态紧密结合，也是 Swarm 之后更适合新项目的官方方向。

核心特性：Agent、工具调用、Handoff、Agent-as-tool、输入输出 Guardrails、Session、Tracing、Evals、实时语音和 MCP 接入。

优点：概念少、上手快；Handoff 适合客服路由和专家接管；与 OpenAI 实时语音、Trace 和评测链路结合自然。

局限：使用厂商特有能力越多，迁移成本越高；核心抽象不是显式状态图；Guardrails 也不能替代完整业务权限和安全治理。

适用场景：已确定使用 OpenAI，需要快速构建工具调用、客服分流或语音 Agent 的项目。

写入简历后要掌握：Handoff 与 Agent-as-tool 的区别；Guardrails 能防什么；Session 与 Trace 怎么用；为什么接受 OpenAI 生态绑定；复杂流程如何补持久化和恢复。

面试小卡片｜请简单介绍一下你了解的 Agent 框架

核心特点。 我了解的 OpenAI Agents SDK 是 OpenAI 官方提供的轻量 Agent SDK，核心能力包括工具调用、Handoff、Agent-as-tool、Guardrails、Session 和 Tracing。Handoff 可以把当前对话和控制权交给另一个专业 Agent，而 Agent-as-tool 则是由主 Agent 调用其他 Agent 完成子任务后继续统一回答，这两种方式适合不同的协作关系。

优缺点。 它的优势是概念少、上手快，并且与 OpenAI 的 Realtime、Tracing 和 Evals 结合自然，开发者可以比较方便地追踪 Agent 和工具的调用链路。缺点是核心抽象不是显式状态图，Guardrails 也不能代替业务权限；复杂流程、持久化和恢复需要额外设计，深度使用后还会增加 OpenAI 生态绑定。

适用场景。 它适合工具调用 Agent、客服分流、专家接管和实时语音应用，特别适合已经确定使用 OpenAI 模型的项目。例如客服 Agent 可以根据问题把会话 Handoff 给退款、技术支持或销售 Agent，并用 Trace 查看整个交接过程。

1.1.4.5 Claude Agent SDK：Claude Code 风格的完整 Harness

定位：Claude Agent SDK 将 Claude Code 风格的 Agent 能力嵌入自己的产品和服务。它不是普通模型 API SDK，而是带 Agent Loop、内置工具、上下文管理、权限和会话能力的 Harness。

核心特性：文件读写和编辑、Shell、Glob、Grep、Web Search 等内置工具；MCP 与自定义工具；会话、上下文、流式事件；权限、Hooks、人工审批和子 Agent。

优点：构建编码和文件系统 Agent 时开箱即用，可以复用成熟的工具循环、权限和上下文管理方式。

局限：主要围绕 Claude 生态；SDK 提供 Harness，但通常仍由使用方负责部署和执行环境；文件、Shell 和代码执行必须配套沙箱与最小权限。

适用场景：代码助手、代码库分析、自动修改、CLI 和研发自动化。简单客服、表单抽取或普通 RAG 通常不需要完整 Harness。

写入简历后要掌握：Claude Agent SDK 与普通 Anthropic SDK / Tool Runner 的区别；使用了哪些内置工具；怎样限制路径、命令和网络；会话如何恢复；为什么选择它而不是 Deep Agents 或手写循环。

面试小卡片｜请简单介绍一下你了解的 Agent 框架

核心特点。 我了解的 Claude Agent SDK 是把 Claude Code 风格的 Agent Harness 嵌入自己应用的开发工具。它不只是发送 Prompt 的普通模型 SDK，还内置文件读写、代码编辑、Shell、Glob、Grep、Web Search、会话、Hooks、权限控制和子 Agent，Agent 可以在真实工作目录中连续搜索、修改并验证结果。

优缺点。 它的优势是工具循环、会话和上下文管理比较完整，做代码 Agent 时不需要从零实现文件、终端、权限和结果回传。缺点是主要围绕 Claude 生态，而且文件修改和 Shell 都是高权限操作；SDK 提供权限机制并不等于应用已经安全，仍要增加审批、命令允许列表、最小权限和隔离沙箱。

适用场景。 它适合代码助手、代码库分析、自动修改与测试、CLI 工具以及其他研发流程自动化任务。例如可以让它定位一个跨文件 Bug、修改相关代码、执行测试，再根据失败结果继续修复；普通客服或简单结构化抽取通常不需要这么完整的 Harness。

1.1.4.6 Google ADK：完整的 Agent 工程体系

定位：Google ADK（Agent Development Kit）面向 Agent 的开发、运行、评估和部署。它不仅能定义 LLM Agent，也能通过顺序、并行和循环等方式组织确定性 Workflow（工作流）。

核心特性：Agent、Tool、Runner；Sequential、Parallel、Loop Workflow；Session、Memory、Artifact；多 Agent、评估、观测、部署，以及 Gemini、Vertex AI 和 Google Cloud 集成。

优点：开发到部署链路较完整，兼顾模型自主决策和确定性流程，对 Google Cloud、Gemini 和多语言企业团队友好。

局限：深度使用 Google 特有服务会增加迁移成本；简单本地脚本可能不需要整套体系；不同语言 SDK 的能力和稳定等级需按版本核验。

适用场景：Gemini、Vertex AI、Cloud Run 或 GKE 已经是标准栈的企业，以及需要多语言 Agent 体系的团队。

写入简历后要掌握：Agent、Runner、Session、Memory、Artifact 的职责；确定性 Workflow 与 LLM Agent 如何组合；如何评估和部署；使用了哪些 Google Cloud 能力；怎样控制锁定风险。

面试小卡片｜请简单介绍一下你了解的 Agent 框架

核心特点。 我了解的 Google ADK 更像是用传统软件工程的方式组织一套 Agent 程序。它既支持让 LLM Agent 自主判断，也提供 Sequential、Parallel 和 Loop 等确定性结构来组合多个 Agent，同时通过 Runner、Session、Memory 和 Artifact 管理运行过程。也就是说，开发者既可以让模型决定如何使用工具，也可以明确规定哪些步骤必须按顺序、并行或循环执行。

优缺点。 它的优势是体系比较完整，可以把模型自主决策嵌入固定业务流程，并配套会话、记忆、产物、评估和部署能力，适合用工程化方式管理多个 Agent。缺点是需要理解的概念较多，简单工具 Agent 使用它会偏重；虽然框架并非只能使用 Gemini，但深度使用 Vertex AI 和 Google Cloud 服务后仍会形成一定平台绑定。

适用场景。 它适合采用 Gemini 或 Google Cloud，需要组合多个 Agent、确定性工作流和企业工程能力的复杂项目。例如可以让资料搜集 Agent 并行工作，再由写作 Agent 顺序生成报告，最后由审核 Agent 循环检查和修改。

1.1.4.7 Microsoft Agent Framework：微软企业 Agent 方向

定位：Microsoft Agent Framework 面向 Python 和 .NET 的 Agent、多 Agent 协调与工作流。更准确的理解是它为 AutoGen、Semantic Kernel 相关 Agent 使用者提供新的收敛和迁移方向，而不是简单把两个项目改名。

核心特性：Python/.NET 双栈、Agent 与多 Agent 协调、企业工作流和部署，并可结合 Azure、Microsoft 365、身份与治理体系。

优点：对 .NET/C# 企业团队友好，容易接入微软身份、云和企业工具链。

局限：框架演进和迁移期要关注版本稳定性；对非 Python/.NET 团队吸引力较弱；深度绑定微软特有能力会增加迁移成本。

适用场景：Azure、Microsoft 365、.NET 和企业身份治理占主导的组织。

写入简历后要掌握：项目使用的准确版本；它与 AutoGen、Semantic Kernel 的关系；用了哪些 Azure 或 Microsoft 能力；工作流和多 Agent 如何组织；为什么没有选择 LangGraph 或 Google ADK。

面试小卡片｜请简单介绍一下你了解的 Agent 框架

核心特点。 我了解的 Microsoft Agent Framework 是微软面向 Python 和 .NET 提供的 Agent、多 Agent 协调与工作流框架，也可以把它理解为 AutoGen、Semantic Kernel 相关 Agent 能力的收敛方向。它不仅关注模型和工具调用，也强调 Agent 如何接入企业身份、业务系统和微软现有的开发部署体系。

优缺点。 它的优势不是某一种 Agent 算法，而是可以自然接入 Azure、Microsoft 365、企业身份和治理体系，对 .NET 团队尤其友好，也更容易沿用企业原有的权限和运维方式。缺点是框架仍在演进，需要确认项目使用的准确版本及稳定性；如果企业不采用微软技术栈，这些优势就不明显，深度绑定后的迁移成本也较高。

适用场景。 它适合以 Azure、Microsoft 365、.NET 和企业身份治理为标准技术栈的大型组织。例如构建能够访问企业账号、Teams、SharePoint 或内部业务系统的 Agent 时，它比单纯的通用 Python Agent SDK 更符合现有架构。

1.1.4.8 CrewAI：角色驱动的多 Agent 框架

定位：CrewAI 使用 Role、Goal、Task、Crew 等概念把业务团队映射为 Agent 协作，并通过 Flow 增加状态化和事件驱动控制。

核心特性：角色、目标、任务、Crew、Agent 委派、Flow、状态、工具和知识接入。

优点：业务表达直观，容易把“研究员—编辑—审核员”建模为虚拟团队，多 Agent 原型开发较快。

局限：多 Agent 会增加 Token、延迟、调试难度和错误传播；现实岗位不一定应该映射成独立 Agent；严格事务和复杂恢复仍需显式工作流设计。

适用场景：市场调研、内容生产、销售运营和虚拟专家团队。若角色不需要独立上下文、权限或目标，单 Agent 加工具通常更简单。

写入简历后要掌握：为什么必须用多个 Agent；每个 Agent 的独立职责、上下文和权限；Crew 与 Flow 的区别；怎样减少无效对话；多 Agent 是否真的提高成功率。

面试小卡片｜请简单介绍一下你了解的 Agent 框架

核心特点。 我了解的 CrewAI 是一个角色驱动的多 Agent 框架。开发时会为不同 Agent 定义 Role、Goal、Backstory、Tools 和 Task，例如研究员搜集资料、作者生成内容、审核员检查结果，再通过 Crew 组织角色协作，或者使用 Flow 增加状态和事件驱动的流程控制。

优缺点。 它的优势是业务表达直观，现实团队的职责很容易映射成 Agent，任务委派和多角色原型搭建也比较快。缺点是 Agent 越多，Token、延迟、调试难度和错误传播都会增加，而且角色之间反复对话未必真的提高结果质量，所以不能为了形式而拆分角色。

适用场景。 它适合市场调研、内容生产、销售运营和虚拟专家团队，前提是不同角色确实拥有独立目标、上下文或权限。如果只是同一个 Agent 依次调用几个工具，通常没有必要为了“多 Agent”再拆成多个角色。

1.1.4.9 PydanticAI：类型安全的 Python Agent

定位：PydanticAI 是 Python-first、类型安全优先的 Agent 框架，强调让 Agent 应用像普通 Python 服务一样具备清晰的依赖、工具签名、结构化输出和测试边界。

核心特性：Pydantic 结构化结果校验、类型化依赖注入、根据函数签名生成工具 Schema、多模型提供商抽象、流式输出和测试支持。

优点：对 Python 后端友好；工具参数和模型输出具有清晰类型边界；便于结构化数据处理、测试和 Schema 演进；比大型编排框架轻量。

局限：类型安全只能保证数据形状，不能保证模型决策正确；自动重试可能增加 Token 和延迟；它不是完整的分布式长任务运行时。

适用场景：结构化抽取、API 型 Agent、数据库操作和 Python/FastAPI 服务。

写入简历后要掌握：输入、依赖、工具和输出怎样建模；校验失败如何处理；重试成本如何控制；切换模型后行为是否一致；类型安全不能解决哪些可靠性问题。

面试小卡片｜请简单介绍一下你了解的 Agent 框架

核心特点。 我了解的 PydanticAI 是一个 Python-first、强调类型安全的轻量 Agent 框架。它使用 Pydantic 定义依赖、工具参数和结构化输出，还可以根据函数签名生成工具 Schema，让 Agent 更接近普通 Python 服务的开发方式。比如可以明确规定工具只能接收某种参数，最终结果必须符合指定的数据模型。

优缺点。 它的优势是输入、依赖、工具和输出的类型边界清晰，便于校验、单元测试和 Schema 演进，也方便集成到现有 Python 后端。缺点是类型安全只能保证数据形状，不能保证模型决策和业务事实正确；校验失败后的自动重试还会增加 Token 和延迟，它也不提供完整的分布式长任务运行时。

适用场景。 它适合结构化抽取、API 型 Agent、数据库操作，以及基于 Pydantic 或 FastAPI 的 Python 后端项目。例如把合同内容抽取为严格的数据对象，或者让 Agent 调用内部 API 并返回可直接写入业务系统的结构化结果。

1.1.4.10 LlamaIndex：以数据和 RAG 为中心

定位：LlamaIndex 是数据与知识库优先的 LLM 应用框架。它也能构建 Workflow 和 Agent，但选择它的首要理由通常是数据连接、文档摄取、索引、检索和 RAG（检索增强生成）。

核心特性：数据连接器、文档摄取、切分与元数据、索引、Retriever、Query Engine、RAG、数据上的 Workflow 与 Agent，以及评测集成。

优点：数据源和检索生态丰富，适合快速建立企业知识库，并将企业数据作为 Agent 上下文或工具。

局限：仍需认真处理数据清洗、权限、版本和召回质量；接上向量库不等于 RAG 已可靠；强状态业务编排可能需要搭配 LangGraph 等运行时。

适用场景：合同、研报、企业文档、知识助手和数据密集型 Agent。

写入简历后要掌握：如何切分、索引和增量更新；Retriever 和重排序怎样设计；如何做权限过滤；用什么指标评估 RAG；为什么不用自研、Haystack 或 LangChain 检索组件。

面试小卡片｜请简单介绍一下你了解的 Agent 框架

核心特点。 我了解的 LlamaIndex 是一个以数据和 RAG 为核心的 LLM 应用框架。它重点解决数据连接、文档摄取、切分、元数据、索引、Retriever 和 Query Engine，并可以把检索能力作为 Agent 的上下文或工具。它的基本思路是先把企业资料组织成可查询的数据层，再让模型基于检索到的证据回答或行动。

优缺点。 它的优势是数据源和检索生态完整，能较快把企业私有数据接入应用，并且对 Retriever、Query Engine 等数据组件的抽象比较成熟。缺点是接上向量库并不代表 RAG 就可靠，数据清洗、权限同步、增量更新、召回、重排序和评测仍然需要专门设计；复杂业务状态控制也可能需要搭配 LangGraph 等运行时。

适用场景。 它适合合同、研报、企业文档问答、知识助手以及其他数据密集型 Agent。例如面对持续更新的大量内部资料，需要按部门权限检索并给出证据来源时，LlamaIndex 的价值会比普通工具调用框架更明显。

1.1.4.11 Dify：低代码 AI 应用平台

定位：Dify 是低代码 AI 应用开发与运营平台，而不只是一个 Python SDK。它通过可视化工作流、知识库、模型和工具管理，帮助团队快速发布 Web 应用或 API。

核心特性：可视化 Workflow 和 Agent、知识库与 RAG、模型工具和插件管理、运行日志、Web 应用/API 发布、云服务和自托管。

优点：从原型到可用应用速度快，产品、运营和工程人员可以共同参与，常见知识助手场景开箱即用。

局限：复杂逻辑堆积在画布后，测试、复用和代码审查会变困难；深度定制不如代码框架；开源、托管和企业版能力边界要按版本核验。

适用场景：内部知识助手、运营自动化、快速业务验证和非纯工程团队。不适合把强事务、强实时的核心领域逻辑全部放进画布。

写入简历后要掌握：为什么项目需要低代码；Workflow、知识库、工具和发布如何配合；自托管数据和凭据怎么管；怎样做版本与测试；复杂逻辑如何下沉到独立服务。

面试小卡片｜请简单介绍一下你了解的 Agent 框架

核心特点。 我了解的 Dify 是一个低代码 AI 应用平台。开发者可以在可视化画布中组合模型、Prompt、知识库、工具和 Workflow，并直接发布成 Web 应用或 API，同时在平台中管理模型配置、凭据和运行日志。它与普通 SDK 的区别是，不只提供代码组件，还提供了可以直接使用的应用搭建和运营界面。

优缺点。 它最大的优势是上手快，从原型到可用应用的路径很短，而且产品、运营和开发可以共同参与，知识库类应用尤其容易落地。缺点是流程复杂以后画布会越来越难维护，测试、复用、代码审查和深度定制都不如代码框架灵活；低代码降低的是开发门槛，并不会自动解决业务复杂度。

适用场景。 它适合内部知识助手、运营自动化、快速业务验证和需要非工程人员参与搭建的项目。例如业务团队可以自己调整 Prompt 和知识库，而开发团队只提供外部 API 工具；强事务和高并发的核心业务逻辑通常仍应放在独立服务中。

1.4.1.12 AgentScope：国内模型与企业生态候选

定位：AgentScope 面向 Agent 和多 Agent 应用，强调透明、可控以及 Python/Java 和国内模型、云服务生态的适配，常被国内企业纳入私有化和国产模型项目候选集。

核心特性：Agent、多 Agent 协作、工具、消息、记忆、工作流、Python/Java 支持，以及国内模型和阿里生态集成。

优点：对国内模型、Java 团队和阿里云环境更友好，适合具有私有化、数据驻留和国产化要求的候选场景。

局限：国际社区、英文资料和第三方生态与部分海外热门框架存在差异；支持私有化不等于自动满足合规；协议、模型和部署能力应按版本实测。

适用场景：国内企业、国产模型、Python/Java 混合团队和阿里云场景。

写入简历后要掌握：使用了哪些核心模块；选择它是否因为 Java、国产模型、阿里云或私有化；数据是否真正留在企业边界；与 LangGraph、Google ADK 或 Dify 有何区别。

面试小卡片｜请简单介绍一下你了解的 Agent 框架

核心特点。 我了解的 AgentScope 是一个支持 Agent、多 Agent、消息、工具、记忆和工作流的框架。它比较鲜明的特点是兼顾 Python 和 Java，并重视国产模型、国内云服务和私有化部署适配，因此不只是研究型多 Agent 框架，也考虑了国内企业的实际技术环境。

优缺点。 它的优势是更贴近国内企业技术栈、国产模型和数据驻留需求，对 Java 团队和阿里云环境也更友好。缺点是国际社区、英文资料和第三方生态相对较弱，不同模型与部署能力需要按版本实测；而且可以私有化部署只代表系统能部署在企业边界内，并不代表自动满足安全与合规要求。

适用场景。 它适合国内企业、国产模型、阿里云环境，以及 Python 和 Java 混合团队的多 Agent 项目。例如企业要求数据不离开内网，同时需要接入国产模型并让多个专业 Agent 协作时，可以把 AgentScope 纳入候选方案。

1.1.5 框架选型策略

选框架不需要比较一张密密麻麻的功能表。按照下面四步逐层筛选，通常可以把范围缩小到一个主框架，或者最多两个候选。

团队技术栈 → 核心业务场景 → 部署平台 → 模型偏好

第一步：看团队技术栈

先排除团队难以长期维护的框架。

• .NET / C# 团队： 优先选 Microsoft Agent Framework。
• Java 团队： 国内企业优先看 AgentScope；Google Cloud 团队看 Google ADK。
• Python 团队： 12 个框架基本都能选择，继续看业务场景。
• TypeScript 团队： 通用 Agent 看 LangChain，复杂状态流程看 LangGraph JS，OpenAI 项目看 OpenAI Agents SDK。
• 产品、运营人员也要参与搭建： 直接优先保留 Dify。

这一步结束后，不要选出最终框架，只需要留下团队真正能够开发和维护的候选。

第二步：看核心业务场景

这是最关键的一步。只问一个问题：这个项目最难解决的是什么？

• 通用工具调用、快速原型： LangChain、OpenAI Agents SDK、PydanticAI。

• 需要多模型和工具生态选 LangChain；

• 已确定使用 OpenAI 选 OpenAI Agents SDK；
• Python 项目重视类型和结构化输出选 PydanticAI。
• 复杂流程、状态、暂停和恢复： LangGraph。
• 长任务、深度研究、多文件处理： Deep Agents。
• 代码库、文件编辑和 Shell 自动化： Claude Agent SDK。
• 企业文档、知识库和复杂 RAG： LlamaIndex。
• 角色化多 Agent 协作： CrewAI；国内模型或 Java 环境看 AgentScope。
• 低代码搭建并快速发布应用： Dify。
• 需要用顺序、并行和循环组织多个 Agent： Google ADK；微软企业技术栈则看 Microsoft Agent Framework。

走完这一步，候选通常只剩两三个。

第三步：看部署平台

如果公司已经确定云平台，这一步可以直接进一步收窄候选。

• Azure / Microsoft 365： Microsoft Agent Framework。
• Google Cloud / Vertex AI： Google ADK。
• 阿里云、国产模型或国内私有化环境： AgentScope；需要低代码平台时选 Dify。
• 本地服务器自托管，业务人员还要参与： Dify。
• 没有固定云平台： 保留第二步的候选，不要为了云厂商更换更符合业务场景的框架。

例如核心问题是复杂 RAG，即使部署在 Google Cloud，仍然可以选 LlamaIndex，而不是因为使用 Google Cloud 就强行改选 Google ADK。

第四步：看模型偏好

模型已经确定时，优先选择与该生态结合最自然的框架；没有确定时，优先保留模型相对中立的方案。

• OpenAI： OpenAI Agents SDK，尤其适合 Handoff、Tracing 和实时语音。
• Claude： 编码、文件和 Shell 任务选 Claude Agent SDK。
• Gemini： Google ADK。
• 国产模型： AgentScope；低代码应用可选 Dify。
• 需要随时切换不同模型： 根据场景保留 LangChain、PydanticAI、LangGraph、Deep Agents 或 LlamaIndex，避免把业务逻辑写死在厂商特有接口中。

走完前四步，通常已经可以锁定一个主框架，或者最多留下两个候选。

图 030 · 已恢复原图内容 · 点击放大

更简单一点的策略：

• 复杂状态与恢复 → LangGraph
• 长任务与研究 → Deep Agents
• Claude 编码与文件任务 → Claude Agent SDK
• 企业数据与 RAG → LlamaIndex
• 角色型多 Agent → CrewAI / AgentScope
• 低代码快速发布 → Dify
• Python 类型安全 Agent → PydanticAI
• OpenAI 与实时语音 → OpenAI Agents SDK
• Google Cloud 工程体系 → Google ADK
• Azure / .NET 企业体系 → Microsoft Agent Framework
• 通用模型、工具和检索集成 → LangChain

1.1.6 面试问题

Agent 框架相关的面试问题，最常见的主要有两个：一是考察你是否了解常见框架，二是追问你的项目为什么选择某个框架。第一个问题其实已经在 1.1.4 各框架特点详细介绍展示过了，现在我们就解析第二个问题：你的项目为什么选择某个框架？

这个问题是一个开放性问题，没有标准答案，也许你是拍脑袋就定了你的项目Agent框架。但是即使如此，你回答这个问题的时候，也要根据我们上面的各个框架的特点，选型策略，结合自己项目来回答。很好的一个方法就是把你的项目和上面的这些文档，丢给AI，让它基于这些问题帮你拟草一个答案，你以后就照着用就好：

参考案例：SmartAppointment 项目（我们笔记的Agent项目）为什么选择 LangGraph？

参考回答

我们这个项目是一个企业售后智能客服与预约系统。它不只是让模型调用几个工具，而是要在一次会话中完成咨询、故障判断、服务人员匹配和预约处理，并且在多个 Agent 之间传递用户信息。项目最关键的问题是如何管理一个持续变化、能够暂停和恢复的业务状态。

我选择 LangGraph，首先是因为它可以把这套流程明确建模为状态图。我们会在 State 中统一保存用户和会话标识、消息历史、当前意图、预约时间、服务类型、工程师偏好、RAG 证据、当前处理 Agent、工具结果和确认状态。主管 Agent、咨询 Agent、预约 Agent、用户行为分析、工具执行和用户确认分别对应不同 Node，再通过条件 Edge 决定下一步进入咨询、继续补充预约信息、调用预约工具，还是等待用户确认。

第二个原因是预约任务天然需要循环和中断。例如用户只说“帮我预约维修”，时间、地址或服务类型可能不完整，流程需要回到槽位补全节点继续询问；创建、修改和取消预约属于有副作用的操作，执行前要通过 Interrupt 暂停，让用户确认关键参数。使用 Checkpoint 保存状态后，即使用户稍后回复或者服务重启，也可以从确认前的状态继续，而不必重新进行前面的咨询和信息收集。

我也比较过其他方案。LangChain 很适合接模型、工具和 RAG，我们仍然可以使用它的部分组件，但只使用高层 Agent 时，预约状态、条件分支和恢复逻辑不够显式。CrewAI 用角色描述咨询、预约和分析 Agent 会很直观，但这个项目的核心不是让多个角色自由讨论，而是保证预约流程按照业务状态可靠流转。Dify 可以更快做出可视化 Demo，但随着槽位状态、权限确认、幂等写入和自动化测试增加，代码式状态图会更容易维护。

LangGraph 的代价是开发复杂度更高。我们需要自己设计 State Schema、Checkpoint 存储、节点重试和幂等机制，特别是创建或取消预约时，要通过业务幂等键防止恢复或重试造成重复写入。同时还需要记录节点流转、工具参数和状态变化，方便定位到底是路由、RAG、槽位提取还是工具执行出现问题。

所以我们的选择依据不是“LangGraph 支持多 Agent”，而是这个系统同时需要共享状态、条件路由、多轮补全、人工确认和中断恢复。LangGraph 能把不确定的模型判断放进可控制、可追踪的预约流程中，这一点与项目的核心需求最匹配。

1.1.7 讲解视频

https://www.bilibili.com/video/BV1ZogE6GE4V/?spm_id_from=333.1387.homepage.video_card.click&vd_source=144bec9c3f54e465073138bed788be1b

1.2 LangChain

1.2.1 LangChain 核心设计理念和框架

（算是基本概念，得背）

Langchain 的核心思想是 通过模块化组件： Prompt, Memory, Tool, Chain 将LLM与外部数据源，工具（向量数据库，多种LLM）结合，形成可复用的“链式逻辑“。特点是灵活，生态丰富，适合快速原型开发。

特点是：以链为核心，逻辑是线性和简单分支，不擅长复杂状态管理。

1.2.2 LangChain的版本

（面试官偶尔会问你使用的是哪个Langchain版本，因为Langchain版本更新的确实比较频繁，我知道大家可能有时没太关注版本，我这里整理了一个表格，你需要根据表格里对应Langchain的时间来推断出你当时大概用的哪个版本，要心里有数。从这个表中，大概率可以看出在25年中的时候，我开发的项目，使用的是v0.3.6的Langchain版本，也是在这个时候引入了Graph的概念。弄清楚你用的哪个版本是我们要掌握的）

图 031 · 已恢复原图内容 · 点击放大

1.2.3 LangChain 1.0新版本

(LangChain在25年11月份发布了新版本，其实是大的变化。如果你已经做完了项目，并不是说你就要用最新的版本再做一遍，讲起来Langchain的时候，你还是按照我上面设计的答案去回答就行，然后面试官可能会问你新版本你了解吗？你再给讲讲1.0版本的特性。如果你还没做项目，现在开始做，那么推荐你直接用1.0。现在这个还不是硬性要求的，面试很多时候其实并没有一定要考察你新版本，他这个刚刚发布，可能面试官都没太用。暂时我们先粗略了解1.0的新特性就够了，如果后面我发现面试官开始倾向于问1.0的问题，我再来总结更多新版的知识。

我这里的复习思路是大概理解一下新特性思路和思想就好了，不用太深入研究，因为目前问的不多，面试官最多问道你知不知道langchain新版本。 如果你想要深入学习一下，可以看https://mp.weixin.qq.com/s/asAiFhl8mWIl01s-LSD9VA）

Langchain v1.0的升级 标志着 LangChain 已经走出“实验阶段”，成为一个稳定、可用于生产的框架。具体来讲，在这次升级，引入了以下新特性：

1. 智能体（Agent）的全新创建方式

• 之前的 Agent 创建方式比较复杂，需要手动配置多个组件。

• v1.0 提供更简洁的 API，通过标准化的构建流程，开发者可以快速定义 Agent 的行为、工具调用逻辑，并且支持更复杂的任务编排（比如多步骤推理、条件分支）。 2. 中间件机制（Middleware）

• 类似 Web 框架的中间件概念，可以在执行链路中插入逻辑。

• 应用场景：日志记录、性能监控、错误重试、缓存、权限控制。

• 好处：开发者无需修改核心逻辑，就能在执行过程中添加这些功能，提升可维护性。 3. 结构化输出

• 之前 LLM 输出是纯文本，容易出现格式错误。

• v1.0 支持 JSON Schema 和 Pydantic 类型验证，可以强制模型输出符合预期结构。

• 好处：减少 LLM 不确定性，适合生产环境，尤其是需要严格数据格式的场景（如 API 响应、数据库写入）。 4. 标准内容块

• 提供标准化的 Prompt 模板、工具接口、链组件。

• 好处：降低重复开发，开发者可以直接复用官方标准块，减少定制成本。 5. 全新的包结构与模块化设计

• 命名空间重构：拆分为 langchain_core（核心逻辑）、langchain_community（社区集成）、langchain_experimental（实验功能）。

• 好处：模块职责更清晰，升级和维护更方便，避免以前版本中“包太大、依赖混乱”的问题。

1.2.4 LangChain 不方便的地方

（ 这个问题相比前面的Langchain的基本问题，肯定没有出现的那么频繁。不过这个题目是我从面试真题截取的来，而且这个问题其实也不止被问到一次，反映了面试官想了解你对Langchain的理解是不是浮于表面，有没有一些更深的理解，建议也需要掌握，即使面试官不主动问，你在和面试官聊Langchain的时候也可以找个时机回答出来这两点，体现你其实对这个框架有一些深入的思考，答出来一定会加分。当然这个问题的反面题，你觉得Langchain有没有一些方便的地方，这个你可以回答它集成了各种方法，比如RAG的召回优化，RAGAS的评测方法等，之前笔记我都写出来了）

1.依赖过多，复杂度高

LangChain集成了大量向量数据库，模型提供商和工具，虽然理论是可选，但是实际使用中很多功能需要安装一堆依赖，导致项目臃肿，容易出现"依赖地狱", 对于只需要简单功能的项目，这种设计显得过度。

2.频繁更新，接口不稳定

LangChain迭代速度太快，但是带来大量破坏性更新，API接口经常变化，文档滞后，导致开发需要不断重构代码，维护成本高。

3.性能和延迟问题

LangChain的链式调用每一步都可能涉及外部API， 导致延迟明显，尤其是需要实时响应的场景中表现不佳，链式调用其实也增加了出错概率和调试难度。

4.不够灵活，定制困难

高度抽象导致很多底层逻辑无法轻易改变，遇到特殊需求时，开发者往往需要绕过框架，甚至重写部分功能。

1.3 LangGraph

（LangGraph 相关知识，深入学习可以看这个，很全面 + 有代码示例https://mp.weixin.qq.com/s/XhFbLTLcSjDj0r3KGT9EOg）

1.3.1 LangGraph 介绍/主要模块

（基本概念，肯定得背）

LangGraph 通过将任务组织为 有向图，而不是线性链，来解决 LangChain 在复杂任务中的局限。它支持 条件分支、循环、并行执行和状态共享，并且能够实现多 Agent 协作和复杂工作流。核心模块包括：

Graph：整体工作流的图结构

Node：图中的计算单元

State：共享状态，用于节点间传递上下文

Edge：连接节点，定义控制流和数据流

这种设计使 LangGraph 在处理动态逻辑和多步骤推理时更灵活、更可扩展。

1.3.2 LangGraph 过程是如何流转的？

定义图结构：用 StateGraph 添加节点和边，指定入口节点（set_entry_point()）和结束条件（END）。

编译图：调用 graph.compile()，生成一个可执行图对象（相当于执行器，负责调度和状态管理）。

启动执行：通过 invoke(initial_state) 或 stream(initial_state) 开始运行，传入初始状态。

执行逻辑：

• 从入口节点开始执行。
• 根据边决定下一个节点，如果多个节点同时满足条件，就并行执行。
• 每个节点跑完后，把输出合并到共享状态。
• 重复调度，直到路由到 END 或没有后续节点。

结束：返回最终状态，或者用 stream() 观察每一步的状态变化。

1.4 面试真题

LangChain / LlamaIndex 解决了什么问题，有哪些局限？

💡 思路： 感觉纯八股题，看了我们主流框架介绍的笔记，应该对这些有一个印象。我倒是不建议大家专门抽时间去学习对应框架的内容，我的思路看看我们框架讲解的视频，对于这些八股内容，出现了就背一下，而且框架本身内容，在我看来考的不是特别多，我们也一直在总结面试问题，遇到了面试问题出现的，我都会总结到笔记中的。

📝 答案：

LangChain 和 LlamaIndex 本质上都在解决一个问题：大模型只提供基础的生成能力，而一个完整的 LLM 应用还需要连接模型、私有数据、外部工具、会话状态和执行流程。它们通过统一抽象和现成组件，减少重复的工程开发。不过两者最初的侧重点不同，现在的能力已经有较多重叠。

LangChain 更偏应用与 Agent 编排。它对不同模型、Prompt、工具、结构化输出和中间件提供统一接口，并支持把这些组件组织成 Chain 或 Agent。比如开发一个能够查询数据库、调用搜索 API、根据结果继续决策的 Agent，LangChain 可以帮助我们完成模型接入、工具封装、工具调用和执行循环。复杂且需要持久化、状态管理的工作流，还可以使用 LangGraph 来实现。

LlamaIndex 更偏数据与 RAG。它重点解决私有数据如何进入大模型应用的问题，提供数据连接器、文档解析与切分、索引、Retriever、Query Engine 和 Agent 等组件。比如把 PDF、数据库和知识库接入系统，建立索引，再根据用户问题检索相关内容并交给大模型生成答案，LlamaIndex 能够快速搭建这条数据和检索链路。

可以简单概括为：LangChain 更擅长“模型和工具如何协作、任务流程如何执行”，LlamaIndex 更擅长“数据如何接入、组织和检索”。

它们的局限主要有以下几点。

第一，抽象在提高开发效率的同时也会增加复杂度。简单需求使用框架很方便，但复杂业务往往仍需理解底层模型、检索和工具调用机制；一旦需要深度定制，框架抽象可能发生“泄漏”，排查问题时还要继续追踪框架内部的调用链。

第二，版本和接口迭代较快。示例代码可能随版本升级失效，组件之间也可能存在兼容性问题，会带来学习和维护成本。对框架封装依赖过深，还可能形成迁移成本。

第三，框架不能自动保证效果。使用 LlamaIndex 不代表 RAG 一定准确，仍然需要自己优化文档质量、Chunk、Embedding、混合检索和 Rerank；使用 LangChain 也不代表 Agent 一定稳定，仍要处理错误工具调用、循环、超时、重试和状态一致性等问题。

第四，通用封装可能带来额外开销并降低可观测性。对于性能敏感或流程固定的系统，直接调用模型 SDK、向量数据库和业务 API，代码有时会更轻、更容易控制。生产环境仍需自行补充评测、Tracing、权限隔离、安全防护、成本控制和容错机制。

总结来说，LangChain 和 LlamaIndex 的价值是通过标准组件帮助团队快速搭建 LLM 应用：前者侧重应用和 Agent 编排，后者侧重数据接入与 RAG；它们适合快速开发和验证，但不能替代对底层原理、效果评测与生产工程的掌控。

选自202607宇树科技 Agent开发一面

2.Function Calling

（Function call的能力其实一直都是 Agent非常重要的考点，虽然在实际面试中考察的并不是特别多，以下两个问题是来自于某次面试原题）

2.1 Function calling是如何被训练出来的

Function calling是通过在模型训练的预训练阶段使用自监督学习，在微调阶段使用SFT技术，以及在对齐阶段使用RLHF技术来使模型具有能够理解用户意图并生成函数结构化的函数调用请求的能力。

具体来讲：

预训练阶段的自监督学习使得模型能够理解自然语言。

微调阶段的SFT技术使用标注数据让模型理解何时该调用函数，调用函数的格式是什么。

对齐阶段使用RLHF，使用人类的反馈来优化调用结果，使模型的调用更符合人类的习惯。

2.2 工具调用失败问题

在使用一些Function call的接口设计的时候，如果参数比较多，实际使用中发现LLM调用失败（可能是没理解调用的时机）或者是缺少了必填的参数（导致调用失败），这个应该如何避免呢？

1.重构函数设计：《代码整洁之道》中就写过，函数参数最理想的是0个，其次是1，再次是2，我们应该尽量避免有3个及以上的参数，所以出现这种情况我们可以先考虑是否有必要重构。

2.可以拆分函数：让函数满足单一职责的原则，避免有过多的参数。

3.优化JSON Schema设计： 在JSON Schema中清晰地标明参数类型，是否必填，默认值，写清楚参数描述。

4.优化函数/参数命名： 让命名更具有描述性，便于LLM理解。

5.优化提示词设计：可以在提示词中加入一些引导，给出一些调用示例。

6.可以增加一些验证，反馈，重试机制：比如在调用前对参数进行验证，判断是否有误，如果调用失败，可以把失败的信息传回给LLM，让他利用这个信息重试。

3.Agent评测

这份笔记整理自四类资料：《AI Engineering》、《AI Agents in Action》、《Agentic Design Patterns》，以及美团 LongCat 团队的 VitaBench 论文与相关资料。整理完以后，我最深的感受是：Agent 评估没有一个放之四海而皆准的标准答案。它必须结合具体业务场景来设计，业务目标不同、工具链不同、风险边界不同，评测指标和测试方式也会不同。

Agent 评估本身也相当复杂。一个项目如果真的要做一套非常健全的 Agent 评估体系，可能需要一小波人专门投入来设计评测集、指标、自动化 Pipeline、线上监控、红队安全测试和反馈闭环。现实里，很多企业项目对 Agent 评估这一块其实还没有非常健全，并不一定已经做到“用完善的测试指标指导开发”。我基于和面试官的沟通也有一个判断：绝大多数面试官会问 Agent 测试，但问得并不总是很深入，这也侧面说明很多团队自己对这块的体系化理解还在建设中。

所以，这份笔记希望先帮你建立一个完整的大框架：沿着 Agent 开发的生命周期去理解，在每个阶段哪些地方应该测、测什么、怎么测、有哪些常见方法。你顺着这个思路，就能把 Agent 测试和评估的大部分内容理清楚。

每一个小的测试环节，我都根据参考资料总结了一些方法或思路。但还是要强调：这里没有绝对标准答案。真正落地时，应该结合你的业务、你的 Agent 架构、你的工具链和你的风险边界来设计。如果你希望面试回答听起来更贴近实践，而不是只停留在理论层面，可以把本节理论和你自己的项目结合起来想一遍：比如你的项目里应该如何评估工具调用、如何评估多 Agent 协作、如何设置上线前发布闸门、上线后如何监控质量。也可以把你的项目背景和这一节理论一起交给 AI，让它帮你总结成更贴合你项目的回答。

这份笔记希望你达到三个目的：

1. 先掌握理论框架：理解 Agent 评估为什么复杂，以及它和传统软件测试有什么不同。
2. 能应对面试问题：当面试官问到 Agent 评估、测试、上线监控、安全、成本延迟、多 Agent 协作时，你的回答能清晰、有条理、有深度。
3. 能反推项目测试体系：如果你真的想给自己的项目设计一套比较完善的评估流水线，这份笔记能帮你知道应该从哪些模块入手。

最后再次强调，我仍然认为 Agent 评测是一个非常复杂、专业、且高度工程化的事情。如果想深入学习，可以自己再仔细阅读这四份参考资料，如果想更加偏向于学习实战，那么可以结合今天的理论，在自己项目去设计一个评估流水线。

自信地说，如果你能消化好本节笔记，对于绝大部分面试里涉及 Agent 评测的问题，已经足够应付，而且能答得比很多泛泛而谈的回答更完整，更有条理性。

本报告基于以下四份资料综合编写：

• 《AI Engineering》（Chip Huyen, O'Reilly 2025）—— 评估方法论与工程体系
• 《AI Agents in Action》（Michael Lanham）—— 评估的工具落地与动手实践（后面文章里我们把这个简称为实战书）
• 《Agentic Design Patterns》（智能体设计模式）—— 评估作为设计模式与生产治理
• 美团 LongCat VitaBench（ICLR 2026 / arXiv:2509.26490）—— 真实场景下的评测基准实战

全文每个评测点均标注资料出处，便于追溯。

前面两本是书籍，没有找到在线观看的链接，如果想要看，可以自己购买书籍，或者电子资源。第三个是一本google的书籍，网上有免费阅读版本。最后一个是论文，也可以直接阅读，链接已经附上。

3.1 Agent评估vs传统行业评估

3.1.1 从TDD到EDD

在传统软件里，测试是写完代码之后的一道工序；但在 Agent 系统里，评估本身就是开发的起点和方向盘。

《AI Engineering》提出了一个核心主张——评估驱动开发（Evaluation-Driven Development），它类比于测试驱动开发（TDD）：在你动手搭一个 Agent 之前，应该先把"怎么算成功"定义清楚。原因很现实：大模型是概率性的，同样的输入两次运行可能给出不同结果，你无法像传统程序那样"读一遍代码就知道它对不对"，唯一能依靠的就是一套可量化、可重复的评估体系。

这本书甚至直言："评估是 AI 工程中最难的问题"，并用了整整两章（第 3、4 章）来讲它。换句话说，谁掌握了评估，谁才真正掌握了 Agent 的质量。评估的价值贯穿全生命周期：

• 选型时：靠评估在一堆模型里选出最合适的；
• 开发时：靠评估判断每次改动是变好还是变坏；
• 上线时：靠评估做 A/B 测试、灰度放量；
• 生产时：靠评估（监控）发现线上退化、漂移和安全问题。

一句话：在 Agent 时代，评估不是质检环节，而是研发的指南针。

💬 【面试卡片】 Q：TDD 你了解过吗？你自己用 TDD 做过完整开发吗？（这个题目是202606社招 雄帝科技Agent二面的题目，是粉丝朋友在小红书上分享面试题。本篇所有笔记几乎就是在讲TDD，想告诉大家的是如果学好了这篇笔记，如果问到TDD的内容你就可以引经据典了）

A： TDD 我了解，也实践过。传统 TDD 就是测试先行：先写测试用例让它失败，再写最小代码让它通过，然后重构，靠测试来驱动设计，而不是写完再补测试。不过在 Agent 项目里它没法直接照搬，因为大模型是概率性的、输出又是开放式的，同一个输入跑两次结果都可能不一样，没法像传统代码那样断言"输出等于期望值"。所以我用的是它在 Agent 时代的升级版——评估驱动开发（EDD），内核和 TDD 一样：动手之前先把"怎么算成功"定义清楚，再用一套可量化、可重复的评估来驱动每次改动，只是"断言相等"换成了打分、相似度、通过率这类度量。

具体落地，我是顺着三个阶段做的。第一个阶段是模型确定，先选对地基模型：用成本、延迟、隐私这些硬约束把候选缩小，再用业务私有数据集做终筛，避免被公开榜单的数据污染带偏。第二个阶段是开发阶段，这一段最能体现 TDD 的思想——我会先把各个环节怎么评估定清楚，再去搭 Pipeline。先做组件级评测，把 Prompt、RAG、工具调用、规划推理各自的失败模式逐个测出来；再做集成级评测，用端到端成功率、轨迹评测、多轮对抗、多 Agent 协作验证整机能不能稳定完成任务；等这些维度的测法和指标都定清楚了，我才把评测集和评估 Pipeline 一起组装出来，并设一道发布闸门，质量、延迟、成本、安全都过线才能上。第三个阶段是上线，把同一组指标搬到真实流量里持续监控，做 A/B 灰度、盯漂移和成本安全告警，一旦发现新问题就回灌评测集重新跑回归。

总结来说，传统 TDD 我用过，在 Agent 里我用它的升级版 EDD，把评估贯穿到模型确定、开发、上线这三个阶段——尤其在开发阶段是先把各环节怎么评估定清楚、再组装 Pipeline 和发布闸门，让评估全程驱动开发，而不是事后补测。

3.1.2 Agent评估和传统评估的不同

为什么不能拿传统软件测试那一套来测 Agent？四份资料从不同角度指出了同一件事：Agent 打破了传统测试赖以成立的前提。可以从五个维度看清两者的根本差别：

• 确定性：传统软件测试同样输入必得同样输出、可断言相等；Agent 评测则是概率性输出，同一输入多次结果不同。
• 任务性质：传统测试是封闭式（close-ended），输出落在预定义值域内（如分类只能输出有限的几个类别）；Agent 评测是开放式（open-ended），同一输入有无数种可能的正确回答。
• 判定方式：传统测试有唯一/可枚举的标准答案，把输出与它比对、相等即对（可自动断言）；Agent 评测无法枚举所有正确答案，只能用打分、相似度、通过率去度量"好不好"。
• 评测对象：传统测试看单个函数的返回值；Agent 评测看一条多步"轨迹"：规划→调工具→观察→再规划。
• 失败形态：传统测试的失败是抛异常、返回错值；Agent 的失败是工具用错、目标跑偏、自以为完成、绕圈子……

最关键的一条是：传统测试断言"输出 == 期望值"，而 Agent 的输出根本无法这样断言。《Agentic Design Patterns》明确指出，正因为 Agent 是非确定性的，传统"通过/失败"的测试不足以保证可靠性，必须转向"对效能、效率、合规做持续测量"的思路。

图 032 · 已恢复原图内容 · 点击放大

💬 【面试卡片】 Q：你觉得 Agent 行业的测试和传统行业有哪些不同？

A： Agent 的测试和传统软件测试有几个根本不同。

第一，确定性不同：传统软件同样的输入必然得到同样的输出，可以直接断言"输出等于期望值"；而 Agent 是概率性的，同一个输入多次运行结果都可能不一样，没法这样断言。

第二，任务性质不同：传统软件多是封闭式（close-ended）任务，输出只能落在预定义的值域里，有唯一或可枚举的标准答案，可以直接拿输出和标准答案比对、相等就算对；而 Agent 是开放式（open-ended）任务，同一个输入有无数种可能的正确回答，无法列出一份完整的标准答案来比对，所以只能用打分、相似度、通过率这类方式度量"好不好"，而不是简单地判"对不对"。

第三，评测对象不同：传统测试看的是单个函数的返回值，而 Agent 要看的是一条"规划→调用工具→观察→再规划"的多步轨迹。

第四，失败形态不同：传统软件的失败是抛异常或返回错值，而 Agent 的失败是用错工具、目标跑偏、自以为完成、绕圈子等。归根到底，传统测试能拿输出和标准答案断言"相等即对"，而 Agent 开放式输出列不出标准答案，所以必须从"通过/失败"转向对效能、效率、合规的持续度量。

3.1.3 Agent评估5大困境

综合四份资料，Agent 评测之所以难，集中在五个"坑"上。这五条建议在面试里能直接说出来：

1. 非确定性，传统 pass/fail 失效。 同一输入多次运行结果不同，无法用"等于期望值"来判定对错。
2. 不能只看结果，要看"会怎么失败"。 《AI Engineering》提出一个关键视角：评估 Agent = 识别它的失败模式，并量化每种失败发生的频率。一个 Agent 可能最终答对了，但中间用错了工具、绕了远路——只看结果会漏掉这些。
3. 失败面更多、更新。 Agent 比单纯的 LLM 多出了规划、工具调用、多轮交互、多智能体协作等环节，每个环节都是新的失败来源。任务越复杂，失败点越多。
4. Benchmark 会被"污染"，榜单不可尽信。 公开 benchmark 的题目可能已经混进了模型的训练数据（数据污染 / contamination），导致分数虚高。选型时不能只看排行榜名次。
5. "裁判"本身也有偏见。 现在普遍用 LLM 给 Agent 打分（LLM-as-a-judge），但《AI Engineering》系统揭示了裁判模型自身的偏差：自我偏好（偏向自己生成的答案）、首位偏差（偏向排在前面的选项）、冗长偏差（偏向更长的回答）。还有一条警告——比较式评估里"偏好 ≠ 正确"：人类投票选出的"更喜欢"，不等于"更正确"，如果投票者不是内行，甚至会把 Agent 训练成"讨好型"而非"正确型"。

这五条困境，正是后面所有评测方法要去解决的问题。可以把它们当成贯穿全文的"问题清单"。

💬 【面试卡片】 Q：Agent 行业的测试面临着哪些困难？

A： Agent 测试主要面临五大困难。第一，非确定性导致传统的"通过/失败"判定失效，同一输入多次运行结果不同，无法用"等于期望值"来判对错。第二，不能只看最终结果，还要看它"会怎么失败"——评估 Agent 本质上是识别它的失败模式、并量化每种失败发生的频率，因为一个 Agent 可能答对了，但中间用错了工具、绕了远路。第三，失败面更多也更新，Agent 比单纯的大模型多了规划、工具调用、多轮交互、多智能体协作等环节，每一个都是新的失败来源，任务越复杂失败点越多。第四，公开 benchmark 会被数据污染，测试题可能已经混进了训练数据导致分数虚高，所以选型时不能只看排行榜名次。第五，用来打分的"裁判"本身也有偏见，LLM-as-a-judge 存在自我偏好、首位偏差、冗长偏差，而且比较式评

3.2 Agent评估全景图

在深入每一种具体的评测方法之前，我们先建立一张“评测全景地图”，让你直观地看清：一个 Agent 从立项、开发到上线运行，评测到底分布在哪些环节？

本章是全篇报告的“指引篇”──它先明确解答“哪里要测”，第 3.3 章再对仗讲清楚“怎么测”。

3.2.1 一条主线

为什么评测会散布在开发的每一个角落？《AI Engineering》在第 1章极富洞见地指出，评测之所以贯穿始终，是因为要达成以下 四个核心目的：

① 挑选模型 ───→ ② 标记进展 ────→ ③ 决定上线 ───→ ④ 生产监控
 (选型期)         (开发期)          (发布期)         (运行期)

这些目的恰好落在开发时间线的不同位置上，把它们半闭环地串联起来，就是一条完整的评测生命周期。

这本书还有一个更根本的主张，被称为：

💡 核心观点：评估驱动开发（Evaluation-Driven Development） 在你动手搭建一个 Agent 之前，必须先定义“怎么才算成功”。类比于传统软件的测试驱动开发（TDD），先定义评估标准，再动手开发；待各维度测法清晰后，再把它们组装成可自动运行的评估 Pipeline。

因此，评测决不是开发末尾临时拥抱的防黑天鹅工序，而是一路延续到下线的主航道。其余三份资料也各自深度呼应了这条“评估主线”：

• 《Agentic Design Patterns》：强调评估要“贯穿到线上生产监控，并最终沉淀为可问责的工程治理”；
• 《AI Agents in Action》：直接把“评估”做成了与推理、记忆、规划并列的 Agent 四大核心组件之一；
• 美团龙猫：示范了如何将这套系统性评估思想凝结成一个真实场景下的生活服务评测基准（VitaBench）。

3.2.2 上线前验证 → 上线后监控

沿着真实交付生命周期，评测不应该简单分成"开发期测质量、上线后测稳定和安全"。更准确的分法是两层：

• 上线前验证：用离线评测集、仿真环境、压测、红队用例和发布闸门判断"能不能上线"；
• 上线后监控：用真实流量、日志、trace、metrics、用户反馈判断"上线以后有没有退化、漂移、成本失控或被攻击"。

成本、效率、延迟、安全、合规不是生产期才出现的指标，而是横向贯穿两层：上线前它们是准入门槛，上线后它们是持续监控项。

下面按这条主线，逐一穿透每个阶段测什么、对应第 3.3 章哪一节：

图 033 · 已恢复原图内容 · 点击放大

🛠️ 贯穿全程的「通用武器库」（对应 §3.3.1）

在探讨具体阶段前，必须先掌握三件"通用武器"（LLM-as-a-judge、比较式评估、基础度量）。它们没有固定归属，而是在模型选型、组件调试、发布闸门和生产监控里被反复调用。

✅ 上线前验证：回答"能不能上线"（对应 §3.3.2 \~ §3.3.6）

上线前不是只测"答案对不对"，而是要把模型、组件、整机、资源消耗和安全红线一起放进发布闸门。

• 选型期：挑对地基模型（对应 §3.3.2）
  公开榜单只作粗筛；用 License、限价、延迟、隐私等硬约束缩小候选池；最后用业务私有数据集终筛。这里已经要看成本和延迟，不能等上线后才发现用不起、太慢。
• 开发期前置标准：先定义"怎么算好"（对应 §3.3.3）
  按《AI Engineering》的四类标准圈定方向：领域能力、生成能力、指令遵循、成本与延迟；同时补上 Agent 项目必须有的安全/合规红线。
• 组件评测：逐个测零件（对应 §3.3.4）
  Prompt、RAG、工具调用、规划推理分别隔离评估。Prompt 安全、RAG 忠实度、工具乱调、规划绕路，都属于上线前必须暴露的问题。
• 系统评测：测整机能不能稳定完成任务（对应 §3.3.5）
  用端到端成功率、轨迹评测、多轮用户模拟、多 Agent 协作评测，检查系统整体可靠性。效率也在这里进入评分：步数过多、绕远路、超时，不能算真正可用。
• 评测集 + Pipeline + 发布闸门（对应 §3.3.6）
  把前面各维度的测法组装成可自动回归的评估流水线，并设上线阈值：质量分、Pass^k、P95 延迟、token/成本预算、最大步数、安全红队通过率、误拒率等。

📡 上线后监控：回答"真实流量下有没有变坏"（对应 §3.3.7）

上线不是开始测试成本和安全，而是把上线前已经定义好的指标迁移到真实流量里持续观测。

🎯 警言：监控的目标和评估的目标，本质上是同一个。 区别在于：上线前主要用准备好的数据、仿真和压测；上线后用真实用户流量、日志、trace、metrics 和反馈。

• A/B 测试与灰度发布：小流量分发，用留存率、转化、满意度、投诉率等线上业务指标作终审，并设置回滚线；
• 监控与可观测性：用 logs、traces、metrics 记录每次运行，并在这套观测底座上持续监控质量、漂移、异常、成本、延迟、安全和合规。

把两层主线连起来读，就是一个 Agent 评测的完整故事：

💡 全景流串联： 上线前先把"能不能上线"测透：选模型 → 定成功标准 → 测组件 → 测整机 → 组装评测集和 Pipeline → 用质量、成本、延迟、效率、安全、合规做发布闸门；
上线后再把同一组指标搬到真实流量里持续监控：A/B 灰度 → logs/traces/metrics → 漂移和异常检测 → 成本/延迟/安全告警 → 回灌评测集重新回归。

💬 【面试卡片】
Q：你认为在 Agent 系统中，应该测试/评估哪些东西？

💡 答题思路：
先以“Agent 系统与传统软件的根本不同（如概率性、开放式输出、无唯一标准答案）”作为宏观背景切入，说明为什么无法靠单一测试满足要求。接着，不要把"成本/延迟/安全"误归成上线后才测，而要按 上线前验证 → 上线后监控 展开：上线前它们是发布闸门，上线后它们是持续监控项。重点把开发期的次序讲清——真正前置的只有一份轻量的"成功标准清单"，而评测集和评估 Pipeline 要等组件、集成各维度怎么测定完，才一起组装出来（因为评测集的标注依赖这些指标）。

👨‍💻 标准回答：
在 Agent 系统中，由于大模型天然是概率性的、且其输入输出是开放性的，我们没有办法像传统软件那样依靠唯一的标准答案进行 assert 断言。因此，Agent 系统不能采用单纯的“黑盒通过性测试”，而是需要将评估与测试融入到整个开发的生命周期中。我会按 上线前验证 和 上线后监控 两层来组织：

1. 【选型期·模型自身评测】：挑选合适的地基大模型。我们会使用硬性约束（如成本、延迟、隐私等）进行初筛，然后再使用业务私有数据集对模型的推理和专项能力进行终审测试，防止公开榜单的“数据污染”虚高。
2. 【开发期·组件级评测（零件测试）】：对构成 Agent 的核心零件进行独立单测，核心是识别各组件特有的失败模式。这里主要包含四大零件的测试：Prompt（测试鲁棒性）、RAG检索（测试召回与回答忠实度）、工具调用（测试调错率与填参率）和规划推理（测试反思与多步规划）。
3. 【开发期·集成级评测（整机测试）】：把零件拼装起来，对 Agent 作为整机端到端表现开展高压集成测试。主要包括：任务最终端到端成功率（通过高压 Passk^k 指标测试稳定性）、关键工具行动路径对齐的轨迹评测（Trajectory）、引入用户模拟器的多轮对抗鲁棒性测试、以及多智能体协作时的分工损耗及协同效率评估。
4. 【上线前·组装评测集 + 评估 Pipeline + 发布闸门】：当上面组件、集成各维度"怎么测、用什么指标"定完，才把评测集与评估 Pipeline 一起组装出来——先据这些指标标注评测数据集（单测 test file + 全场景回归 evalset），再选打分法、绑定业务北极星指标、设定可用阈值。发布闸门不只看质量，还要看 P95 延迟、token/成本预算、最大步数、安全红队、提示注入、误拒率等。之所以放在最后，是因为评测集每条样本的期望输出/评分标准，正是用前面各维度的指标标注的——指标先行，数据才有依据。
5. 【上线后·真实流量监控】：

• 上线时，采用 A/B 测试 / 灰度发布分流，用线上真实业务指标进行版本裁决，并设置回滚线。
• 上线后，建立以 Logs、Traces、Metrics 为核心的 可观测性系统，持续监控质量漂移、异常行为、TTFT/TPOT、token 成本、工具循环、越狱/提示注入攻击、guardrail 触发率、误拒率和合规审计记录。

总结来说，Agent 的测试并不是单一指标能解决的，它是由“上线前验证发布闸门”和“上线后真实流量监控”共同构成的全生命周期闭环评估网络。成本、效率、延迟、安全、合规都不是上线后才测，而是上线前先验收，上线后持续盯。

越往后走，评测的场景便越具体，直接接触生产中极易在 Edge Cases 上坍塌的“深水区”。接下来的章节，就把这条主线上的每个环节逐一摊开，讲清每一处"怎么测、用什么工具"。

3.3 评测细节

本章是全篇主体。我们沿着第 2 章那张生命周期主线，从"通用武器库"开始，再依次走过上线前验证（选型 → 前置定成功标准 → 组件 → 集成 → 组装评测集与 Pipeline → 发布闸门）和上线后监控（灰度、可观测性、漂移、成本与安全告警）。每一个小节都用同一个模板讲：

【是什么】 这一节评的对象是什么 → 【为什么测】 不测会怎么翻车 → 【怎么测】 具体指标、工具、可照做的步骤。

📌 这里的怎么测，注意也不是标准的答案。而是我基于这4个资料来总结的。怎么测这一步有的地方写的是具体的思路，有的地方是一些可以参考的做法。具体真正工程实践上，没有标准答案，而是要根据我们今天讲解的思路，结合自己的项目灵活扩展。

3.3.1 通用武器库

在进入各个生命周期阶段之前，先认识三件"通用武器"。它们不属于某一个阶段，而是在选型、组件、集成、生产里被反复使用——先讲清楚，后面各节直接引用。

3.3.1.1 LLM-as-a-judge

【是什么】 用一个（通常更强的）大模型，按照预先写好的评分标准（rubric），去给另一个 Agent 的输出打分或排序。它是目前最主流的自动评估手段，四份资料无一例外都在用。

它有三种典型用法：

• 单点打分：给一个输出打一个绝对分（如"有用性 1–5 分"）；
• 对参考打分：把输出和"标准答案"比，判断是否一致；
• 两两比较：给出 A、B 两个输出，让裁判选哪个更好。

【为什么测】 Agent 的输出大多是开放式自然语言，没有唯一标准答案，用精确匹配根本没法判分；纯人工评估又太慢太贵、无法规模化。LLM-as-a-judge 填补了中间地带——它能像人一样理解语义，又能像程序一样批量自动跑。《AI Engineering》给了一个有说服力的数据：GPT-4 作为裁判与人类的一致性可达 85%，甚至高于人类评审之间的一致性（81%）。

【怎么测】

定性：这是一个方法、分 3 步走（写标准 → 固定裁判 → 批量跑），三步是先后顺序，不能跳。

1. 【步骤】写清楚 rubric：定义评估维度和每个分档的含义。实战书的做法是借用教育学的"评分量规"概念，比如评一个推荐器，从 subject / format / genre 三个维度各打 1–5 分，并写明每一分代表什么。
2. 【步骤】固定裁判模型和提示词：设计模式书里用 Gemini（gemini-1.5-flash-latest，temperature=0.2）搭了一个 LLMJudgeForLegalSurvey，并用 response_mime_type="application/json" 强制输出 JSON 分数（含 overall_score、rationale、detailed_feedback、concerns、recommended_action 五个字段），方便后续解析聚合。
3. 【步骤】批量跑 + 聚合：把多组输入喂进去，解析每条打分，再求平均/分布。

📋 一个真实的 judge 提示词长什么样（直接照搬一个例子）

下面是实战书第 9 章"推荐器"案例里真实的裁判提示词（evaluate_recommendation.jinja2，Jinja2 模板，{{ }} 里是运行时会被填入的变量）。它麻雀虽小五脏俱全，正好凑齐一个标准 judge prompt 的四要素——角色设定 + 评分维度 + 1–5 分量规 + 指定输出格式：

system:
You are a discerning recommender of {{subject}} {{format}} of the {{genre}}.
Your purpose is to evaluate the quality of given recommendations.
Make sure that the recommendation aligns well with each of the criteria:
Format - make sure the format aligns with {{format}}
Subject - be sure the subject is the same as {{subject}}
Genre - make sure the genre is similar to {{genre}}

Please follow any special instructions and align your scores accordingly given here. {{custom}}

Rate each criteria, subject, format and genre on a scale from 1 to 5 using the following guide:
1  Poor alignment: this is the opposite of what is expected given the criteria.
2  Bad alignment: not a good fit for the given criteria.
3  Mediocre alignment: it may or may not fit well with the given criteria
4  Good alignment: it may not align 100% with the criteria but is a good fit; otherwise
5  Excellent alignment: this is a good recommendation for the given criteria

You will be shown a number of recommendations.
Respond with only the item title and a rating from 1-5 (5 being the best) for
each criterias alignment (Subject, Format and Genre).
Below is an example of the requested output:
Title: Time Bandits
Subject: 4
Format: 5
Genre: 4

user:
{{recommendation}}

（{{subject}}/{{format}}/{{genre}} 是评测维度，{{custom}} 是留给"特殊评分说明"的插槽，{{recommendation}} 填入待评的推荐内容。）

从这个例子能学到三件事：

• 维度可参数化：把评测维度写成 {{ }} 变量，换个场景填不同值就能复用同一套裁判，不必每次重写；
• 量规要逐档下定义：不是光说"1–5 分"，而是把"1 分长什么样、5 分长什么样"逐档写清——这正是 AI Engineering 强调的 "create scoring rubrics with examples"；
• 要给输出格式做示范：提示词末尾用 Title/Subject/Format/Genre 明确示范了期望的输出长相，裁判才会稳定吐出可解析的结果，方便后续批量聚合。

💡 再补一个佐证"裁判没有统一标准"的发现：AI Engineering 指出，同样叫"忠实度（faithfulness）"这一个指标，三个主流评估工具的 judge 提示词标度各不相同——MLflow 用 1–5 分、Ragas 用 0/1、LlamaIndex 让模型直接答 YES/NO。这意味着 LLM-judge 的提示词至今没有行业标准，换一个工具或提示词，分数就不可比。

⚠️ 必须知道的三大偏见（面试高频） —— 《AI Engineering》系统揭示了裁判模型自身的偏差，用它的时候要警惕：

• 自我偏好（self-bias）：裁判偏向自己生成的答案；
• 首位偏差（first-position bias）：两两比较时偏向排在前面的那个；
• 冗长偏差（verbosity bias）：偏向更长的回答，哪怕没更好。