1. 学完不敢面试，问题到底出在哪
先说个我看了很多次的场景：一个同学把AI大模型的基础课、进阶课都刷完了，Transformer原理能默写，LoRA、QLoRA、RAG这些词张口就来，OpenAI的API、开源的模型权重也都跑通过。结果到了写简历的时候，盯着屏幕一上午，憋不出一行项目经历。面试约了两家，聊不到二十分钟就冷场，最后只能尴尬收场。
这不是个例。我接触过不少想转行AI大模型的大学生、应届生，普遍都有同一个困惑：学了很多，但不知道拿什么去面试。
为什么会这样？说白了，大部分人的学习路径是“输入型”的——看视频、读文档、跑通Demo。这些动作能让你获得知识，但不能让你获得“谈资”。面试官不会因为你跑通过一个开源项目就给你发Offer，他要看到的是：你遇到一个实际问题，自己定义方案、动手解决、评估效果、分析失败原因，这条完整链路你走通了没有。重点不是技术本身，而是你怎么用技术。
这篇文章不打算再讲一遍Transformer或者Attention，也不准备给你列一堆学习路线图。我要聊的是更现实、更卡脖子的事：**怎么在有限的时间里，做出一个能放进简历、能支撑面试官连续追问30分钟的实战项目。**我会把项目选题、完整流程、面试话术、高频追问、避坑经验一次讲透。适合正在转行或者准备秋招、春招的同学，也适合那些“学完了但手里没牌”的焦虑型学习者。
2. 面试项目怎么选：方向比努力重要
很多同学的项目焦虑，其实不是缺时间，而是缺“够得着”的目标。一上来就想做一个通用大模型、做一套完整Agent平台、搞一个全网爆款应用，这既不现实，也没必要。面试项目的好坏标准只有一个：**面试官问你的每一个问题，你都能接得住。**接住的底气来自两件事——你真实地做过，并且你清楚地知道每步为什么这么做。
2.1 方向一：RAG知识库问答系统，性价比之王
RAG（检索增强生成）是目前最适合转行者的面试项目，没有之一。原因很简单：它把“大模型应用开发”的所有核心环节都串起来了——文本处理、向量化、检索排序、Prompt设计、模型调用、效果评估。而且它对算力要求极低，不需要你微调任何模型，跑在消费级显卡甚至纯CPU上都能完成。
我见过一个很典型的例子：某同学用某个开源embedding模型加一个大模型API，做了个校园图书馆问答系统。数据就几百本公开的图书简介和馆藏信息，系统能回答“某本书在哪个馆、怎么借、有没有电子版”这类问题。项目不大，但他把每个环节都讲得很透：为什么用这个embedding模型而不是那个？检索召回TopK取多少是试出来的？为什么某些问题答得不准？他用这个项目拿了两个Offer。
RAG项目最好的地方在于，它是一个“可以无限追问”的项目。面试官问你数据从哪来、检索为什么不准、上下文窗口怎么处理、并发怎么做，每一层都能往下挖，而每一层你都可以通过实际操作给出答案。这才是面试项目最该有的样子。
2.2 方向二：垂直场景的指令微调，展现动手深度
如果你有一定的GPU资源——比如能借到一张消费级显卡、或者用几小时的云端算力——指令微调也是很好的选择。它比RAG更有技术深度，能体现你对模型训练的理解。
但这里要泼一盆冷水：微调项目翻车率极高。很多同学跑完一次微调，发现模型变傻了、回答语无伦次，然后就慌了。根本原因通常不是代码问题，而是数据问题——训练数据量太小、格式混乱、质量参差。所以选这个方向，你的重点应该放在“数据从哪来、怎么清洗、怎么构建指令集”上，而不是“训练脚本怎么跑通”。
举个例子：某同学做了一个面向法律咨询场景的微调项目，用几百条公开的租赁合同纠纷问答数据，对某个开源7B模型做LoRA微调。他选这个场景是因为数据相对规范，而且他能找到明确的评估维度——回答里是否包含“合同条款依据”。训练本身只用了几个小时，但他把大部分精力花在了数据清洗和评估设计上。面试的时候，面试官问他“你做了哪些降低模型幻觉的手段”，他能拿出实际案例和数据对比来回答。
2.3 方向三：Agent工具调用工作流，展示工程整合能力
第三个方向是做Agent，让模型学会使用外部工具——比如根据用户指令查询天气、计算表达式、查询数据库。这类项目面试时很加分，因为它体现的是工程能力：你不仅要调模型，还要写工具定义、设计调用策略、处理模型返回的异常结果。
不过Agent项目的坑是容易做成“玩具”。你让模型调了个计算器、查了个日期，这说服力不够。要做好，核心是让Agent解决一个真实场景的问题。比如做一个“简历信息提取助手”——用户发一段口述经历，模型自动调用一个结构化输出工具，提取出教育背景、项目经历、技能清单，再调用一个校验工具检查时间线是否合理。这个项目不大，但它同时涉及大模型、工具调用、结构化数据、异常处理，面试时可讲的内容非常密集。
2.4 选题对照：选项目前先问自己三个问题
想清楚方向之后，收起马上动手的冲动，先回答三个问题。
第一个问题：这个项目解决谁的问题？“图书馆问答”解决学生查书难，“简历提取助手”解决求职者整理资料烦，“租赁纠纷问答”解决普通人看不懂合同条款。有明确用户，项目才有灵魂。
第二个问题：**这个项目的数据你从哪里来？**数据是最容易卡住转行者的地方。公开数据集、开源语料、自己生成的模拟数据都可以，但你必须清楚地知道数据的规模、质量、局限性。数据是项目的命脉，说不清数据来源的项目，面试官三两句话就能问穿。
第三个问题：**效果怎么衡量？**不要说什么“感觉回答挺准的”。用准确率、召回率、拒答率、端到端耗时这些指标说话。哪怕你只有100条测试样本，能给出准确率从58%提升到74%的对比记录，也比一万句“我感觉效果不错”更有说服力。
选项目有三个“不选”：不选烂大街的“智能客服”（面试官已经听过八百遍）；不选完全依赖别人搭好的平台的“低代码Demo”（技术含量说不出来）；不选超出自己能力范围的大工程（做不完等于没做）。
3. 把一个项目做成“能讲的闭环”
选好方向只是万里长征第一步。真正拉开差距的，是你能不能把一个想法做成一条完整的链路，并且每一步都知道自己在干什么、为什么这么干。下面我用最热门的RAG方向，从头到尾拆一遍，看完你就能直接照着做。
3.1 完整项目长什么样：RAG问答系统的全流程拆解
RAG的核心逻辑一句话：**先搜到相关资料，再让大模型基于资料作答。**听起来简单，但工程细节非常多。我用一个校园信息问答系统来拆解。
先说数据。假设你有几千条学校相关的公开信息文本。第一步是文本清洗：去掉无关页眉页脚、统一编码格式、去除重复段落。这里很多人会犯错——直接拿原始文档切块，结果同一句话出现七八个版本，检索时全被召回，浪费上下文窗口还干扰回答质量。
清洗完之后是切片（Chunk）。切片是RAG里最容易被低估的环节。切太短，语义不完整；切太长，向量化效果变差，还容易塞爆上下文窗口。我自己的经验是：先用300到500字左右的块大小做基线，然后拿几十个真实问题测一遍检索效果，再微调。不同数据源的理想块大小差异很大——条款类文本可以长一些，问答类短一些。不要迷信网上说的“256最好”，那是别人的数据，不是你的。
然后是向量化。选一个开源的embedding模型，把切片转成向量，存入向量数据库。这一步有两个关键参数：一个是embedding模型的维度，决定存储和检索开销；另一个是检索TopK——召回多少条相关片段送给大模型。TopK太小，可能漏掉关键信息；TopK太大，无关片段会干扰模型判断。建议从5开始，根据测试效果上下调整。
最后是生成。把用户问题连同召回的片段拼成Prompt，调用大模型API生成回答。Prompt模板里最好明确告诉模型“只能基于以下资料回答，不要编造”，这能在一定程度上减少幻觉。同时还可以加一个兜底逻辑：如果召回的片段相关性普遍太低，直接返回“抱歉，资料库中没有找到相关信息”，不要硬答。
3.2 关键环节：向量化与检索的参数逻辑
RAG项目里被问最多的就是“参数你怎么定的”。这里我把调试过程展开讲。
先看embedding选型。市面上开源embedding模型各有侧重，有的对中文支持好，有的在长文本上表现稳。选择标准不是“哪个最新”，而是“在你的数据上谁更准”。具体做法：准备100条带标准答案的测试问题，分别用两个候选模型走一遍检索流程，对比“正确答案是否出现在召回内容中”的比例。选那个比例高的，哪怕它发布时间老一点。这个对比测试的结果，写进简历和面试里都是加分项。
再看TopK和相似度阈值。TopK决定了模型能看到多少参考资料，相似度阈值决定了“什么情况下宁可不说也不乱说”。这两个参数是联动的。我见过一个典型翻车现场：某同学把TopK设成10，检索出来的片段有一半跟问题无关，大模型被迫在无关内容里“编”答案。后来加了一道阈值过滤——相似度低于0.45的片段不送给模型，问题立刻改善。他后来跟我说，之前以为检索是模型的事，没想到是策略的事。这个认知转变，其实是RAG项目最大的成长点。
再看切片策略。相比固定字数切片，“按语义边界切片”效果通常更好——在段落、标题或列表项处断开，保留完整语义块。一些成熟的文档解析库可以按版面结构切分，优先保留标题层级。一个来自用户FAQ的数据源，按“问答对”切分往往比按字数切分效果翻倍，因为每一条FAQ本身就是完整语义单元。
3.3 指令微调项目的核心步骤与参数细节
如果你的项目走指令微调路线，流程稍有不同。这里只讲LoRA，因为它是最适合个人/学生做微调的方式——训练参数量少、显存占用低、几小时就能出结果——同时效果通常不输全参微调太多。
先看数据。指令微调数据长什么样？一个典型样本长这样：
{"instruction": "根据合同条款回答：租户提前退租，押金能否退还？", "input": "租赁合同第二十一条：如租户在合同期内提前退租，已支付的押金不予退还。", "output": "不能退还。依据租赁合同第二十一条，租户在合同期内提前退租，已支付的押金不予退还。"}这里有个关键点：**人工写高质量数据，哪怕只有几百条，效果也远好于从网上爬一堆低质量数据。**大模型微调本质是“教模型你的偏好”，数据垃圾，模型就学垃圾。如果你的数据是从某些平台搬来的，至少要保证格式统一、答案正确、无重复。很多微调失败，问题就出在数据上，而不是训练参数上。
然后看训练配置。以某个7B模型为例，LoRA的典型配置是：rank设为8，alpha设为16，只对注意力层的q_proj和v_proj注入LoRA。为什么只注入这两个？因为大量实验表明，注意力层的权重对指令遵循能力影响最大，先在这里做局部更新性价比最高。rank=8的意思是在原有的权重矩阵旁边加一个低秩的旁路矩阵，参数量很小。整套配置训练下来，可训练参数量只有千万量级，仅占模型总参数的很小比例。这解释了为什么一张24GB显存的消费级显卡就能训练——因为大部分原模型权重是冻结的。
训练轮次（epoch）建议从2到3开始，不要贪多。微调比预训练更容易过拟合——训练集上表现越来越好，测试集上反而变差。一个经验指标：训练完用一条“没见过的、但你有标准答案”的测试样本先问一遍，如果模型开始重复训练集里的句子，说明过拟合了，赶紧降epoch或者加数据。
还有一个容易忽略的配置：学习率和调度策略。LoRA微调建议用小学习率，通常1e-4到2e-5这个区间，配合warmup加cosine衰减。这部分面试官很喜欢追问，因为很多人只会填默认参数，说不出为什么。
3.4 怎么界定“效果还可以”：你的项目需要可量化的评估
做完了项目，最大的问题来了：怎么让别人知道你做的东西是有用的？答案是：**建立一套评估清单。**没有评估，项目就是一个“跑通了的脚本”；有评估，才是“一个让人信服的系统”。
RAG项目至少要测几个指标：检索准确率（正确答案是否在召回结果中）、端到端回答准确率（大模型最终回答是否正确）、拒答率（不知道时是否不乱说）、平均时延（用户等多久）。前面说的100条测试问题，这时候就派上用场了。跑一遍，把数字记下来。如果你是优化过参数的，还可以把“优化前vs优化后”的对比数据一起记录下来。
微调项目评估更讲究：要区分“通用能力保持”和“垂直能力提升”。很多转行者只看垂直数据集上的表现，忽略了模型原本的通用能力是否被破坏。为了留住通用能力，我的建议是额外准备一份通用评测集，比如常识问答、数学题、逻辑推理，微调前后对比跑一遍。如果垂直能力上升但通用能力大幅下降，说明学习率太大、数据过拟合或者训练轮次太多。
评估环节最大的坑是用训练数据测效果。模型当然记得训练数据里的答案，测出来的准率好看极了。一定要用训练时没见过的样本做测试。这句话听起来像常识，但做起来很多同学依然会犯，尤其当数据总量不大、舍不得留测试集的时候。我建议哪怕数据再少，至少也要留出10%到20%作为测试集。少这100条数据，可能就是面试时你能不能扛住追问的分水岭。
4. 项目怎么“讲”面试官才买账
很多同学有个错误理解：面试是“我被考”。实际上面试是双向信息匹配——面试官想知道你会什么、你怎么思考问题、你能不能搞掂实际工作。你的项目，就是证明这三件事的证据。怎么把这个证据讲好，非常讲究。
4.1 用STAR框架把项目讲成一个有逻辑的故事
STAR模型不是简历专用的，面试讲项目同样好用。
S（Situation）——背景是什么？不要上来就说“我做了个RAG系统”。先交代场景：“校园信息化建设过程中，大量信息分散在多个网页和文档里，学生找答案困难。”一句话，让面试官知道你做这个项目的意义。
T（Task）——你的任务是什么？承接背景，明确目标：“搭建一个问答系统，让学生用自然语言提问，系统自动从资料库检索并生成准确回答。”
A（Action）——你具体做了什么？这是主体，按“数据清洗→切片→向量化→检索→生成→评估”的顺序讲，每个环节带出关键决策和参数依据。不要流水账，要突出“我遇到了什么问题，我是怎么解决它的”。
R（Result）——结果怎么样？给出数据：“100条测试问题的端到端准确率从62%提升到78%，拒答率从20%降到8%。”数字就是说服力。
STAR框架最核心的价值是：它逼着你先想清楚“为什么做、怎么做、结果如何”。如果你连这三件事都说不出个数，那就回头补功课，而不是急着去面试。
4.2 高频追问清单：这些问题你扛得住吗
一个真实做过项目的面试者，和只跑过Demo的面试者，在追问环节会瞬间拉开差距。下面这些是RAG和微调项目被问得最多的问题，你可以先自己答一遍，答不出来就是项目还没有做透：
- “你的向量化模型是怎么选的？跟另一款比过吗？差距量化过吗？”
- “检索召回TopK为什么设成5？设成3会怎样？设成10会出现什么问题？”
- “你的切片策略是怎么定的？按固定长度切和按语义切各有什么优劣？”
- “用户问的问题在你的语料里完全没有答案，你的系统会怎么处理？”
- “你的测试集是怎么构建的？会不会存在测试集和训练集重复的问题？如何保证测试集不泄漏到训练数据里？如果发现重叠你怎么处理？”
- “你说回答准确率有78%，另22%的错误是怎么分布的？全是知识缺失吗？还是模型本身逻辑错误？还是检索不到但模型硬答？”
这几个问题里，最后两个是真正的能力分水岭。能用数据描述失败模式的候选人，几乎是拿到Offer的候选人了；只会说“效果总体还可以”的，面试官基本确定他只是在跑通教程。
关于“测试集怎么保证不泄露”这个问题，我再补充两句。很多同学数据总量不多，把所有样本扔进去训练，最后用同一批数据测效果，这在面试里是硬伤。实际做法：先按比例切出测试集，一条不碰，放进一个单独的文件夹里，训练脚本里显式地用路径排除它。面试时你可以直接说“我在代码里强制过滤了与测试集重合的样本”，这句话的杀伤力远大于任何自我表扬。
4.3 简历上项目怎么写：三句话抓住关键信息
简历里的项目描述，很多人会写成两大段流水账，看三秒就失去耐心。好的项目描写应该像电梯演讲——三十秒内让面试官抓到关键信息。
可以按这个模板来写：**项目一句话背景+我负责的范围+核心技术手段+一份量化结果。**比如下面这样：
“校园知识库问答系统：基于开源embedding模型与国产大模型API构建RAG问答链路。负责数据处理、切片策略调优、检索评估与Prompt设计。通过语义边界切片和相似度阈值过滤，将100条测试问题的端到端回答准确率从62%提升至78%，拒答率从20%降至8%。”
一段话，信息密度拉满。你负责什么、怎么做的、做到什么程度，全清楚了。面试官看到这样的描述，后续追问会自然地围绕“切片策略怎么调的、阈值怎么定的、测试集怎么建的”，而这些你都在实际项目中做过。
简历有个返工率极高的雷区：**写了超过自己能力的项目。**比如写“基于XX模型微调的企业级客服系统”——被问道“你的训练数据量多少？多轮对话怎么做的？线上部署容错怎么设计？”直接懵掉。建议回去立刻把描述改小改实，把“企业级”“平台级”“大规模”这类词全部删掉，换成“Demo级但完整闭环”“千条级数据”“单机部署”，至少面试不会被一句话问穿。
5. 常见问题与避坑速查
最后把转行者最常见的卡点和翻车场面集中盘点一下。这些全是我在实际接触中反复见到的，拿出来给大家排雷。
5.1 没有GPU、没有数据、没有时间怎么办
先说GPU。RAG项目对算力几乎没要求：embedding模型在CPU上也能跑，向量检索本身不消耗GPU，大模型调用API就行。这项技术栈完全可以在家用电脑上学完。微调项目则需要一点算力，但LoRA把门槛降得足够低了。市面上有不少按小时租GPU的平台，几百块预算就够跑完一次小规模微调。你要算的不是钱，是时间。一次微调从数据准备到评估，三四天起步，别指望一个晚上全部搞定。
数据来源的思路要打开。你不需要“全网独家数据”，你只需要“你自己动手处理过的数据”。公开的开放语料、政府公开信息、网上公开的用户常见问答、你自己根据领域知识整理出的模拟数据，都可以。面试官在乎的不是数据的稀缺性，而是你如何处理它、如何发现它的缺陷、如何设计实验来验证效果。
时间分配是另一个大坑。建议把60%的时间花在数据和评估上，20%花在模型调用和调试上，20%花在写简历和演练面试上。很多人时间分配完全反过来——数据的活枯燥、评估繁琐，全都糊弄过去，只享受跑通模型那一刻的爽感。结果项目做完才发现自己没东西可讲，只能回来补数据工作。还不如一开始就把它当主线任务。
5.2 面试现场最容易被拆穿的地方
我列过一个高频翻车清单，几乎每条都有同学中过招：
- 用训练集当测试集夸准确率高——被多问几句“具体怎么测的”就露馅。
- 不知道自己用的模型参数量、上下文长度、许可证类型——做项目的基本盘，一问就现形。
- 说不出失败经历——面试官问“你遇到过最大的坑是什么”，回答“没什么坑，挺顺利的”，直接扣分。真实项目中一定有坑，没有坑说明你做得太浅或者不诚实。学会讲一个“数据清洗踩过的坑”“向量化选型踩过的坑”并且说清楚怎么爬出来的，这反而是最加分的部分。
5.3 做不到全流程怎么办：分阶段策略
有同学问：“我时间不够，做不到完整闭环，怎么办？”我的建议是：做一环，做透一环，然后把这一环讲到极致。
比如你实在没时间做微调，那就把公开模型下载下来做一次推理实验：不同Prompt模板对回答格式稳定性的影响。做一个系统的对比测试，整理成表格，这本身就是一个可以放进简历的项目——前提是把实验设计写清楚、样本数量给足、结论说得明确。
如果你的四六级/期末考挤占了大部分时间，连微调都没时间跑，那就做一个纯Prompt工程的项目——用API设计一套稳定可复用的Prompt模板，针对一个细分场景持续迭代，配合测评记录。这虽然不如微调项目技术深度大，但比没有项目强很多。面试官更在意的是你有没有“通过设计实验来获得结构化认知”的能力，而不是你用了多难的技术。
我在实际接触转行者时有个很深的体会：**面试官不是要找一个什么都会的人，而是要确认一个“给他一个任务，他能自己想办法走通”的人。**你不需要做得多宏大，但你需要让他通过你做的那个小项目，感受到你把一件事想明白、做扎实的能力。
最后再分享一个心态层面的建议：转行AI大模型不是在“补课”，而是在“展示作品”。你的目标不是学完所有AI知识再去面试，那样永远学不完。目标是在三到四周内，做出一个能讲30分钟的小而完整的项目，然后带着它去面试。面试官问得越深，说明他越感兴趣；你答得越实，Offer离你越近。第一次做项目一定会笨拙，没关系，把衡量标准从“我多会写代码”换成“我多会解决具体问题”，面试这事，你心里就有底了。
