原文链接：https://www.yuque.com/zander-xsg7o/bftg9l/wvt7ck2408cdnqo9?singleDoc#
本文我觉得很好的点是教如何写一个真正有效的、能够写在简历上的项目。
正文
最近很多小伙伴私信我推荐项目，由于一直在赶论文没抽出时间，先跟大家说一声抱歉！
ok，废话不多说，进入正题！项目到底怎么做，才能扛住面试追问？
如果不想面试被这样说，请跟着教程一步一步做！ "这你跟教程做的吧？" "指标提升了多少？""大概……有一点？" "线上遇到什么问题？""……没上过线"
三个项目，有项目背景，容易拿数据，最最最最重要的是不吃算力！(默认有3090及以上哈)
项目一：电商客服问答——大模型训练方向
面试讲项目，开口第一句别上来就说"我用LoRA做了个SFT"。先说业务！
场景很简单：电商公司客服每天5000+咨询，退换货、物流、商品参数、售后投诉什么都有。 现在的规则引擎只能兜住40%，剩下全靠人力。so你的活就是——让大模型扛住高频标准问题，把自动解决率从40%干到75%以上。
为什么选客服场景，不选医疗也不选法律？很简单：
第一，数据好搞。电商客服对话数据集网上一搜一大把，自己模拟构造也容易。医疗数据你上哪弄？
第二，指标好定。自动解决率、准确率、满意度，都是硬指标，面试讲起来有说服力，就不虚了！
第三，SFT + DPO 天然适配这个场景。SFT 教模型怎么回答，DPO 教模型哪种回答让用户更爽。客服场景天生就有"好回答"和"差回答"的区分。
第四，也是比较实际的——字节、阿里、京东、拼多多都有类似业务，以后面这些公司能用上。
数据不用去实习也能搞到
很多人第一反应是"我没实习过哪来的数据"。别慌。
- GitHub 搜
e-commerce customer service dataset，中文电商客服多轮对话数据集好几个 - 淘宝京东商品页的"问大家"板块，手动整理个两三百条就够用
- 还有个省事的办法：写几个客服场景模板，用 GPT-4 批量扩写指令对，成本低可控性强
- 偏好数据更简单：SFT 训完让模型自己生成 2-3 条回答，你标哪条更好就行
面试的时候别说数据是"网上下载的"。你可以说： "训练数据两部分，一部分来自电商平台公开 FAQ 加历史对话清洗， 另一部分是基于业务 SOP 用模板扩写的。原始 12000 条，去重、去短回复、去矛盾答案之后剩 5800 条做 SFT。"
如果一开始直接说数据是"从网上收集的"，面试官马上追问"怎么保证质量"，答不上来就很被动。 这个项目是算法岗的基本盘。你一个训练项目都没有，大部分面试走不过第二轮，这不是吓你。
别从零写，先读这几个仓库
我自己做的时候踩过一个坑：一上来就自己从头写训练脚本，config 写错、数据格式对不上，折腾了三天才跑通。后来发现正确姿势是先读别人的代码。
最值得读的三个：
LLaMA-Factory（68k star）https://github.com/hiyouga/LLaMA-Factory SFT+DPO 全流程做得最完整的项目。数据格式模板、LoRA 配置、各种对齐算法实现全有。 我当时在里面学到最有价值的东西是它的数据格式规范，省了很多踩坑时间。
TRL（12k star）https://github.com/huggingface/trl HuggingFace 官方训练库。SFTTrainer、DPOTrainer 写得很规范。 面试被问原理时说"我读过 TRL 源码"，比说"我看了篇博客"强太多。
Qwen3（27k star）https://github.com/QwenLM/Qwen3 选什么模型、怎么调、怎么部署，看官方文档最靠谱。
我的做法是：花 2 天读 LLaMA-Factory 的数据模板和训练配置 → 然后用 TRL 自己写训练脚本。面试你就可以说"工程结构参考了 LLaMA-Factory，但训练代码是自己基于 TRL 写的"——这个说法面试官接受度很高，我实测过。
推荐技术选型
| 组件 | 推荐 | 备选 |
|---|---|---|
| 基座模型 | Qwen3-8B | DeepSeek-R1-Distill-Qwen-7B、Qwen2.5-7B |
| 微调框架 | HuggingFace TRL | OpenRLHF（进阶） |
| 高效微调 | HuggingFace PEFT（LoRA/QLoRA） | — |
| 训练基建 | PyTorch + DeepSpeed ZeRO-2 | Transformers Trainer |
| 显卡要求 | 单卡 3090/4090 可跑 QLoRA | 双卡可跑全参 LoRA |
分步执行（建议 3-4 周）
第1周：SFT 跑通
-
数据准备（电商客服场景）
- 收集电商 FAQ + 客服对话数据，按场景分类：退换货、物流、商品参数、投诉
- 转化为指令格式：
{"instruction": "用户问：这个能退吗？已经拆封了", "input": "商品类别：食品", "output": "很抱歉，食品类商品拆封后不支持无理由退货..."} - 原始数据 ~12000 条 → 清洗后保留 5800 条（去重、去短于20字的回复、去答案矛盾的样本）
- 别忘了记录清洗规则和前后数量变化——面试一定会问"你的数据怎么来的、怎么清洗的"，说不出数字就很减分
-
跑 SFT
- 用 TRL 的
SFTTrainer，配置 LoRA（rank=16, target_modules=["q_proj","v_proj"]） - 训练 2-3 epoch，记录 loss 曲线
- 输出：训练配置文件 + loss 截图 + 推理样例
- 参考 LLaMA-Factory 的
examples/目录下客服/对话场景配置
- 用 TRL 的
-
本周交付验收
- 能回答"SFT 的 loss 和预训练 loss 有什么区别？代码层面怎么实现？"
- 能展示训练前后同一批客服 query 的输出对比（比如退货政策问答的准确性变化）
第2周：LoRA 消融实验——这步决定你是"会跑"还是"做过实验"
这一步是把项目从"跑通了"变成"做过实验了"的分水岭。我被问过好几次"rank 怎么选的"，第一次没答好，后来补做了消融实验才过关。
至少跑 3 组对比：
| 实验 | 变量 | 要记录的指标 |
|---|---|---|
| rank 消融 | rank=4 / 16 / 64 | loss、任务准确率、显存占用 |
| target_modules | q_proj+v_proj vs 全部线性层 | 效果差异、训练耗时 |
| QLoRA vs LoRA | 4bit 量化 vs FP16 | 精度损失、显存节省比例 |
面试的时候你怎么讲这个实验？直接这么说：
"我对 LoRA 的 rank 做了消融，发现 rank=16 在我的任务上是效果和效率的最优平衡点。rank=64 效果提升不到 1%，但显存多了 40%，不划算。"
就这一句话，面试官就能判断你是真做过实验的。这个经验对我真的很管用。
第3周：DPO 偏好对齐
-
构建偏好数据（客服场景天然适合做偏好标注）
- 用 SFT 后的模型对同一批客服 query 生成 2-3 条回答
- 标注标准：回答是否准确、是否有安抚情绪、是否给出可执行方案
- 比如同一个退货问题，chosen 是"给出明确退货步骤+预计时间"，rejected 是"只说了可以退但没说怎么操作"
- 数量：1000-3000 对足够
- 偏好数据的质量比数量重要很多，这个经验我吃过亏。一开始图省事堆了一堆噪声数据进去，结果效果反而还不如 SFT-only
-
跑 DPO
- 用 TRL 的
DPOTrainer - 关注 β 参数（默认 0.1），试 0.05 / 0.1 / 0.3
- 用 TRL 的
-
对比实验
| 对比维度 | 要记录的 |
|---|---|
| SFT-only vs SFT+DPO | 同一评测集上的准确率/偏好胜率 |
| β 不同取值 | 偏好对齐程度 vs 多样性损失 |
| 偏好数据质量 | 噪声数据占比 10%/30% 时的效果衰减 |
第4周：失败案例分析 + 项目文档
这步最容易被忽略，但我个人觉得面试加分最多。因为面试官真正想看的不是"你做成了什么"，而是"你遇到问题时怎么想的"。
客服场景典型翻车：
- 复读机："您好您好您好我们的退货政策是……" —— 后来发现是训练数据里有大量重复句式，清掉之后好了
- 突然变冷：应该礼貌安抚的退货场景，模型回复跟机器人一样冰冷。查了半天，是 DPO 偏好数据里混了两种风格
- 答非所问：用户问物流到哪了，模型回答退货政策。这个比较头疼，根因是指令分类能力不够，后来加了场景分类 prompt 缓解了一些
- 事实错误：给了错误的退货天数。最坑的一个 bug，排查下来是 SFT 数据中有两条互相矛盾的样本
每个翻车都写清楚：出了什么问题 → 为什么 → 试了什么 → 解没解决。面试讲这些比讲指标有用得多。
简历怎么写
面向电商客服智能问答场景，针对退换货、物流、商品咨询等高频问题，基于 Qwen3-8B 完成指令微调与偏好对齐全流程。清洗并构建 5800 条客服指令数据集完成 LoRA SFT，对 rank、target_modules、量化方案进行消融实验；基于客服满意度维度标注 2000 组偏好数据完成 DPO 对齐。最终回答准确率从 58% 提升至 82%，用户偏好胜率达 67%，自动解决率由 40% 提升至 72%，并沉淀 badcase 分析与迭代策略。
面试会怎么追问你
这些我被问过，提前准备好：
- "LoRA 的 rank 你怎么选的？" —— 讲消融实验结论就行
- "偏好数据怎么构建的？质量差会怎样？" —— 讲噪声实验
- "DPO 和 PPO 你为什么选 DPO？" —— 不需要额外 Reward Model、训练更稳定、数据量要求更低。PPO 我也了解，但在我这个数据规模和资源下不现实
- "loss 不降你怎么排查？" —— 学习率太大、数据有问题、梯度裁剪没开、混合精度配置不对，挨个排查
- "出现复读机怎么办？" —— 就讲你的翻车案例
- "β 调大调小分别会怎样？" —— 调大更保守不敢偏离参考模型，调小偏好更强但容易过拟合
用到的开源仓库
- LLaMA-Factory：https://github.com/hiyouga/LLaMA-Factory （⭐68k，SFT+DPO 全流程参考实现，含数据模板和训练配置）
- TRL：https://github.com/huggingface/trl （SFT/DPO 训练，自己写脚本的规范参考）
- PEFT：https://github.com/huggingface/peft （LoRA/QLoRA）
- Transformers：https://github.com/huggingface/transformers （模型加载/推理）
- Qwen3：https://github.com/QwenLM/Qwen3 （基座模型官方文档+微调最佳实践）
- nanoGPT：https://github.com/karpathy/nanoGPT （理解训练闭环，建议做之前先花 2 天读源码）
项目二：金融研报问答——RAG 系统，面试问得最多的方向
为什么做 RAG，而且选金融场景
RAG 是目前面试被问到概率最高的模块，没有之一。字节阿里腾讯美团，几乎每场必问。但这个方向有个尴尬的问题：90% 的人做出来都是一个 demo，随便切个 txt 文件、用 LangChain 套一下就完了。面试官追两句就知道深浅。
所以关键不在于"要不要做 RAG"，而在于场景选什么。
我选的是金融研报。原因很简陋——PDF 比 txt 难处理太多了(手动狗头)。研报里全是多栏排版、表格、图表、脚注，不做版面分析直接 split，表格数据全是乱的。面试你只要说"我处理过 PDF 多栏排版和表格切块"，就比纯文本选手听起来厉害很多。 另外金融问答有个天然优势：答案是确定的。"比亚迪 Q3 毛利率多少"，研报里白纸黑字写着，评测非常好做。不像开放域问答那样评测全是主观。 再加上字节、蚂蚁、百度、阿里都有金融 AI 团队，面试官对这个场景很熟，不用花时间解释背景(应该吧)。
具体的任务就是：给分析师做一套研报问答工具，自然语言提问，系统自动从几百份 PDF 里找到相关段落，生成回答，标注来源文档和页码。
数据去哪找
研报数据其实蛮好搞得。东方财富 Choice 上市公司年报季报 PDF 免费下载， 选 3-5 个行业各拿 10 份就够了。发改委、人民银行的政策文件也是公开的。 如果懒得一个个找，卷心菜研究、墨宝研报都有免费的行业报告可以批量下。 评测数据集可以用 FinanceIQ 或 FinQA，GitHub 和 HuggingFace 都能搜到。
总量控制在 200-300 份 PDF 就行，太少不够多样性，太多你处理不过来。
面试时别说"下载了一批 PDF"。换个说法：
"语料库 300+ 份金融研报和政策文件，覆盖新能源、半导体、消费三个行业。文档以 PDF 为主，包含多栏排版、表格、图表，部分超过 80 页。评测集自建了 120 条，分事实型、对比型、汇总型三类。" 按这么说完面试官一般不会再追问数据来源。
代码别从零写，先读这三个
项目一的时候我说过，从零写是浪费时间。RAG 这块更是——光 PDF 解析就能折腾你一周。
RAGFlow（75k star）https://github.com/infiniflow/ragflow 这个我觉得是 RAG 方向最值得读的项目。它的 DeepDoc 模块做了深度 PDF 解析，表格识别、多栏处理、图表提取都有。混合召回链路和评测指标体系也做得很完整。我花了差不多三天把它的切块策略和检索融合那部分代码读了一遍，收获很大。
Langchain-Chatchat（37k star）https://github.com/chatchat-space/Langchain-Chatchat 中文 RAG 的老牌项目了。中文分词切块、FAISS/Milvus 多向量库适配、BM25+KNN 混合检索这些实现写得比较清晰，适合学习。
QAnything（14k star）https://github.com/netease-youdao/QAnything 网易有道做的。它的 2-stage retrieval（先 Embedding 粗筛再 Rerank 精排）和父子文档召回策略比较有意思，rerank 阈值怎么设计的也值得看。
我的做法跟项目一类似：先花两三天读 RAGFlow 的 DeepDoc 和检索融合代码，理解思路，然后自己用 FAISS + FlagEmbedding 写一套。面试时说"我参考了 RAGFlow 的文档解析思路，但检索和评测链路是自己实现的"，这个说法比较安全。
技术选型一览
| 组件 | 推荐 | 备选 |
|---|---|---|
| 向量检索 | FAISS | Milvus（数据量大时） |
| Embedding | bge-large-zh-v1.5（FlagEmbedding） | text2vec、m3e |
| 重排 | bge-reranker-v2-m3（FlagEmbedding） | cross-encoder/ms-marco |
| BM25 | rank_bm25（Python库） | Elasticsearch |
| 生成模型 | Qwen3-8B / Qwen2.5-7B | DeepSeek-R1-Distill-7B |
| 评测 | RAGAS / 自建离线评测集 | — |
| PDF解析 | PyMuPDF + pdfplumber（表格） | marker / RAGFlow DeepDoc |
| 快速原型 | LlamaIndex（仅用于搭 baseline） | LangChain |
| 数据领域 | 金融研报 + 政策文件 PDF | — |
具体怎么做，分四周
第1周：数据处理 + 基线搭建
-
数据准备（金融研报场景）
- 从东方财富/卷心菜等平台下载 200-300 份 PDF 研报（选 3-5 个行业就差不多了，比如新能源+半导体+消费）
- PDF 解析是第一个难点：用 PyMuPDF 提取文本，用 pdfplumber 解析表格，处理多栏/页眉页脚
- 这个点面试很容易出彩：你能讲清楚"纯文本 split 在 PDF 上为什么不行，表格会被拆散、多栏内容会串行"，打败百分之99的对手(狗头保命)
- 参考 RAGFlow 的 DeepDoc 模块，学习它的版面分析思路
-
切块实验（这步感觉很多人都不做，但面试基本上必问）
- 至少对比 3 组 chunk_size：256 / 512 / 1024
- overlap：50 / 100 / 200
- 记录每组切块数量、平均长度、以及后续召回的 Recall@5 变化
- 金融文档特殊点：表格行不能被切断，因此需要“表格保护”切块策略，这是一个很好的面试话题
- 输出：一张切块策略对比表
-
向量索引构建
- 用 FlagEmbedding 的 bge-large-zh-v1.5 做 embedding
- 用 FAISS 构建索引（先用 Flat，后面对比 IVF/HNSW）
- 输出：索引构建脚本 + 向量维度和文档数记录
第2周：多路召回 + 召回评测
-
实现 3 路召回
- 路线 A：纯向量召回（FAISS）
- 路线 B：纯 BM25 召回
- 路线 C：混合召回（向量 + BM25 分数加权融合）
-
构建评测集（金融场景的核心优势：答案确定性强）
- 自己写 80-120 条
(query, ground_truth_doc_id, answer)三元组 - query 分三类：事实型（"比亚迪 Q3 营收多少"）、对比型（"宁德时代 vs 比亚迪毛利率哪个高"）、汇总型（"新能源行业 2025 年主要政策变化"）
- 这个分类别小看，面试时你说"我的评测集覆盖三类问题，其中对比型和汇总型是纯向量召回的弱点"——这就自然引出了你为什么要做混合召回
- 自己写 80-120 条
-
跑评测
| 召回方案 | Recall@3 | Recall@5 | Recall@10 | 备注 |
|---|---|---|---|---|
| 纯向量 | ? | ? | ? | baseline |
| 纯 BM25 | ? | ? | ? | 关键词场景更强 |
| 混合召回 | ? | ? | ? | 通常最优 |
- FAISS 索引对比（面试区分度很高）
| 索引类型 | Recall@10 | 查询延迟(ms) | 构建时间(s) | 内存占用(MB) |
|---|---|---|---|---|
| Flat | ? | ? | ? | ? |
| IVF | ? | ? | ? | ? |
| HNSW | ? | ? | ? | ? |
第3周：重排 + 生成 + 故障处理
-
接入 Reranker
- 用 FlagEmbedding 的 bge-reranker-v2-m3
- 对比：向量召回 Top20 → Rerank 取 Top5 vs 直接 Top5
- 记录 Recall 和准确率变化
-
生成约束
- 实现引用溯源：回答中标注证据来源段落
- 实现拒答机制：召回分数全低于阈值时返回"我不确定"而不是硬编
- 这个问题面试百分百会问：
你怎么缓解幻觉？你就说"证据绑定+低置信度拒答+生成后引用校验"
-
故障处理——这块面试问得很频繁，没有案例会很被动
| 故障 | 你的 badcase（金融场景具体例子） | 根因 | 怎么修的 |
|---|---|---|---|
| 空召回 | “宁德时代 2025 年装机量”，但文档里写的是"装车量" | 表述差异导致 embedding 语义鸿沟 | 加 query 改写（同义词扩展） |
| 答非所问 | 问“比亚迪毛利率”召回了营收段落而不是利润表 | chunk 太大，整页财报被切成一个块 | 缩小 chunk + 表格单独切块 + 重排 |
| 幻觉 | 模型编造了一个不存在的数字 | 生成时未绑定证据 | 加引用约束 + 后校验 |
| 延迟高 | 响应超过 3 秒 | 重排模型太重 + PDF 过长导致切块多 | 先粗筛再精排 / 缓存热查询 |
第4周：评测闭环 + Demo + 文档
-
搭一个可演示的 Demo（Gradio / Streamlit 都行）
- 输入 query → 显示召回文档 → 显示最终回答 + 引用来源
- 面试官可能会让你现场演示，有Demo加分极大
-
整理项目文档
- 系统架构图（切块→索引→召回→重排→生成→评测）
- 每个模块的选型理由
- 实验表（切块/召回/重排所有对比）
- badcase 池（至少 10 个典型案例）
简历可以这么写
面向金融研报智能问答场景，针对 PDF 多栏排版、表格密集等复杂文档特点，设计并实现 RAG 系统。构建 BM25+Dense 混合召回链路，引入 Cross-Encoder 重排提升检索相关性；设计"表格保护"切块策略解决财务表格切断问题，并基于自建 120 条三类型评测集和 badcase 池迭代优化。最终混合召回 Recall@5 达 87%，较纯向量方案提升 15 pp，答非所问比例下降 22%。
面试高频追问
RAG 项目被追问的概率比训练项目还高，这几个你一定会遇到：
- chunk size 怎么选的 —— 讲你的 256/512/1024 三组对比，最好记住具体 Recall 数字
- 为什么不只用向量检索 —— 举例子：用户搜"宁德时代装机量"，文档里写的是"装车量"，纯向量可能召不回来，BM25 反而能匹配到。所以混合召回效果最稳
- Reranker 到底有多大提升 —— 直接报数。如果不做实验你根本说不出这个数字，所以实验必须跑
- 空召回你怎么处理 —— query 改写 + 同义词扩展 + 降级拒答
- 幻觉怎么缓解 —— 证据绑定 + 低置信度拒答 + 生成后引用校验
- QPS 多少，瓶颈在哪 —— 重排模型和生成模型是延迟大头
讲真，RAG 的追问深度比训练项目大。但好在每个追问都能用实验数据回答，所以实验做扎实了反而最好讲。
相关开源仓库汇总
- RAGFlow：https://github.com/infiniflow/ragflow （★75k，生产级 RAG 全链路参考，重点读 DeepDoc PDF 解析 + 检索融合 + 评测体系）
- FAISS：https://github.com/facebookresearch/faiss （向量检索）
- FlagEmbedding：https://github.com/FlagOpen/FlagEmbedding （Embedding + Reranker）
- Langchain-Chatchat：https://github.com/chatchat-space/Langchain-Chatchat （★37k，中文 RAG 经典参考，学切块/向量库适配/混合检索）
- QAnything：https://github.com/netease-youdao/QAnything （★14k，学 2-stage retrieval + rerank 阈值设计）
- LlamaIndex：https://github.com/run-llama/llama_index （快速搭 baseline）
- Milvus：https://github.com/milvus-io/milvus （生产级向量库，数据量大时推荐）
- GraphRAG：https://github.com/microsoft/graphrag （进阶：复杂多跳问答场景）
项目三：把前两个项目部署上线——推理优化，大部分人最虚的环节
为什么一定要有部署项目
到这里你有了项目一训好的客服模型，有了项目二的研报 RAG 系统。但如果只能在 Notebook 里跑，面试官会觉得你只是个"调参选手"。
实话说，做训练和 RAG 的人很多，但一问到部署——"你的服务 QPS 多少？""P95 延迟多少？""OOM 了你怎么处理？"——十个人里八个答不上来(我之前也答不上来，嘻嘻)
这个项目就是把前面两个串起来，做成一个真正能扛并发的在线服务。场景还是接着客服来：日均 5000+ 请求，双11 高峰翻 3 倍，要求单次响应 P95 < 2 秒，32 并发不能崩，GPU 扛不住了要有降级方案，热门问题（"双11能叠加优惠券吗"这种）直接走缓存不过模型。
做完这个项目，你的简历就不只是"会训练"、"会做 RAG"，而是"能跑通训练→检索→部署全链路"。恭喜你可以得道成仙了。
推理框架怎么选
这个方向的开源生态特别成熟，不用自己造轮子。
vLLM（73k star）https://github.com/vllm-project/vllm —— 推理服务的事实标准了。PagedAttention、continuous batching、自带 OpenAI 兼容 API，这仨东西面试全是高频考点。先把 vLLM 跑通，后面做量化对比、压测全基于它来。
LMDeploy（7.7k star）https://github.com/InternLM/lmdeploy —— 量化+部署一体化。我主要拿它来做 AWQ 量化，然后跟 vLLM 跑 benchmark 对比。面试时候有对比数据说话会更有底气。
SGLang（20k star）https://github.com/sgl-project/sglang —— 进阶用的。如果你精力够，可以拿 SGLang 和 vLLM 做个 A/B 对比，面试提一嘴"我也对比了 SGLang"会加分。精力不够就先不管它。
整体路线就是：vLLM 跑通服务 → LMDeploy 做量化实验 → FastAPI 套一层做工程化。目标是产出一份量化对比表 + 一份压测报告 + 一份故障处理文档。
能讲清这个项目的人真的不多，面试里属于"别人没有你有"的加分项。
技术栈选型
| 组件 | 推荐 | 备选 |
|---|---|---|
| 推理引擎 | vLLM | SGLang（进阶对比） |
| 量化 | AWQ (autoawq) | GPTQ (auto-gptq)、LMDeploy |
| 服务框架 | FastAPI + vLLM OpenAI-compatible server | — |
| 缓存 | Redis（缓存热门客服问题） | — |
| 压测 | locust / 自写并发脚本 | — |
| 监控 | Prometheus + Grafana（了解即可） | 日志+手动指标 |
| 模型 | 项目一微调后的 Qwen3-8B 客服模型 | Qwen3-14B（量化后） |
分四周执行
第1周：推理基础 + 量化实验
-
先用 vLLM 把项目一微调好的客服模型跑起来
python -m vllm.entrypoints.openai.api_server --model ./qwen3-8b-ecom-sft-dpo- 验证基础推理正确性：用项目一的客服测试集验证输出一致性
-
量化对比实验——面试几乎必问，没数据很难讲
| 方案 | 模型体积 | 显存占用 | 推理速度(tokens/s) | 效果损失（评测集准确率） |
|---|---|---|---|---|
| FP16 原始 | ? | ? | ? | baseline |
| AWQ INT4 | ? | ? | ? | ? |
| GPTQ INT4 | ? | ? | ? | ? |
| INT8 | ? | ? | ? | ? |
- 输出：一张完整的量化对比表 + 结论（"AWQ 在我的场景下精度损失 <1%，推理速度提升 2.1x"）
第2周：服务化 + 并发压测
-
搭 API 服务（串联项目一+项目二）
- vLLM 自带 OpenAI-compatible server
- 前面套一层 FastAPI 做限流、超时、降级
- 加 Redis 做热问题缓存：“双11能叠加优惠券吗”这类高频 query 命中缓存直接返回，不走推理
- 请求链路：用户请求 → Redis 查缓存 → 未命中则走 RAG 检索（项目二）→ 客服模型推理（项目一）→ 返回结果 + 写入缓存
-
压测（这步的数据面试直接拿来讲）
| 并发数 | QPS | P50延迟(ms) | P95延迟(ms) | P99延迟(ms) | 显存峰值 |
|---|---|---|---|---|---|
| 1 | ? | ? | ? | ? | ? |
| 4 | ? | ? | ? | ? | ? |
| 8 | ? | ? | ? | ? | ? |
| 16 | ? | ? | ? | ? | ? |
| 32 | ? | ? | ? | ? | ? |
- KV Cache 分析
- 记录不同 max_seq_len 下显存变化
- 面试能讲"KV Cache 的显存公式：2 × num_layers × hidden_dim × seq_len × batch × precision_bytes"
第3周：工程化完善
-
限流与降级
- 令牌桶限流：超过 QPS 阈值返回 429
- 超时机制：推理超过 N 秒自动中断返回兜底回答
- 降级策略：GPU OOM 时自动切到更小的量化模型
-
日志与监控
- 每次请求记录：input_tokens、output_tokens、latency、status
- 统计：每小时 QPS、平均延迟、错误率
- 不需要搭完整 Prometheus，但要能讲清楚你会关注哪些指标
-
故障演练——你不练就面试时现场编，大概率翻车
| 故障 | 现象 | 排查步骤 | 修复方案 |
|---|---|---|---|
| OOM | 进程被 killed | nvidia-smi 查显存、检查 batch/seq_len | 减 max_seq_len / 开量化 / 降并发 |
| 延迟飙升 | P95 从 500ms 涨到 3s | 查并发数、查 KV Cache 占用 | 开 continuous batching / 加缓存 |
| 请求抖动 | 部分请求超时 | 查 GC、查显存碎片 | 预热 + 固定 batch |
| 输出截断 | 回答不完整 | 查 max_new_tokens 设置 | 调大上限 + 流式输出 |
第4周：串联整合 + 文档
-
把项目一的客服模型 → 项目二的研报 RAG → 项目三的推理服务串成完整链路
- 客服场景：用户提问 → API 网关 → 意图识别（是客服问题还是研报问题）→ 走对应链路 → 返回结果
- 研报场景：用户提问 → RAG 检索 → 模型生成 + 引用源 → 返回
- 有缓存层、有限流、有监控
-
画一张系统架构图（面试时可以直接在白板上复现）
-
整理项目文档
- 量化对比表
- 压测报告
- 故障演练记录
- 性能优化顺序：缓存 > 量化 > Batching > 硬件升级
简历参考写法
基于 vLLM 搭建电商客服 + 研报问答在线推理服务，完成 AWQ/GPTQ 量化对比实验，在 Qwen3-8B 客服模型上实现 INT4 量化后推理速度提升 2.1x，精度损失 <1%。设计 FastAPI+Redis 服务架构，支持并发限流、超时降级和热问题缓存（缓存命中率 35%）。在 32 并发下 QPS 达 xx，P95 延迟 xx ms，并完成 OOM、延迟抖动等典型故障演练，串联训练-检索-部署全链路。
部署方向面试会问什么
部署项目的追问跟训练和 RAG 画风不太一样，更偏工程和系统。
最常被问的就这几个：
- "continuous batching 是怎么回事？" —— 不等一批凑满就动态合并请求，提升 GPU 利用率。vLLM 的核心机制之一
- "KV Cache 显存怎么估？" —— 公式：2 × num_layers × hidden_dim × seq_len × batch × precision_bytes。最好带上你的实测数据
- "量化掉了多少精度？" —— 直接报你的实验数字，这就是为什么量化实验必须做
- "P95 延迟多少？瓶颈在哪？" —— 报压测数据。瓶颈通常在 decode 阶段，因为它是访存密集型的
- "OOM 了怎么办？" —— 讲你的故障演练经历
- "如果要把延迟砍一半，你从哪入手？" —— 缓存热 query > 量化 > speculative decoding > batch 策略优化
- "Prefill 和 Decode 有什么区别？" —— Prefill 计算密集（并行处理整个 prompt），Decode 访存密集（逐 token 自回归生成）
这些问题有一半以上不做实验根本答不清楚。所以压测和量化对比那两周的时间一定不能省。
开源仓库
- vLLM：https://github.com/vllm-project/vllm （★73k，推理引擎事实标准，重点读 PagedAttention + continuous batching）
- LMDeploy：https://github.com/InternLM/lmdeploy （★7.7k，量化+部署一体化，拿来和 vLLM 做 benchmark）
- SGLang：https://github.com/sgl-project/sglang （进阶对比）
- AutoAWQ：https://github.com/casper-hansen/AutoAWQ （AWQ 量化）
- AutoGPTQ：https://github.com/AutoGPTQ/AutoGPTQ （GPTQ 量化）
三个项目的执行节奏总览
| 周 | 项目一：训练与对齐 | 项目二：RAG 系统 | 项目三：推理部署 |
|---|---|---|---|
| W1 | 客服数据清洗 + SFT 跑通 | — | — |
| W2 | LoRA 消融实验 | — | — |
| W3 | 客服偏好数据 + DPO | — | — |
| W4 | 客服 badcase + 文档 | — | — |
| W5 | — | 研报 PDF 解析 + 切块 + baseline | — |
| W6 | — | 金融 QA 评测集 + 多路召回实验 | — |
| W7 | — | 重排 + 故障处理 | — |
| W8 | — | Demo + 评测文档 | — |
| W9 | — | — | 客服模型量化实验 |
| W10 | — | — | 服务化 + 压测 |
| W11 | — | — | 工程化 + 故障演练 |
| W12 | — | — | 客服+研报三项目串联 + 总文档 |
12 周 = 3 个月，和我之前发的6个月规划里的第 2-4 个月刚好对上。前面1个月补基础，后面2个月刷题+面试，中间3个月就做这三个项目。
做完之后怎么判断能不能写进简历
说个我自己的标准，每个项目做完用这几条对一下：
✅ 有没有至少 3 组对比实验——不是"跑通了"，是"试过几种方案知道哪个好" ✅ 有没有能说出口的数字——"效果不错"是废话，"准确率从 58% 到 82%"才是有效信息 ✅ 有没有翻车记录——面试官其实最想听你遇到问题怎么解决的 ✅ 能不能讲满 5 分钟不卡壳——背景→问题→方案→实验→结果→复盘，这个链条要通 ✅ 面试官追问三层还能不能接住
五条里不到三条的项目，说实话别往简历上放。写上去被问到反而减分。
我踩过的坑，你们别再踩了
- 只跑通不做实验 —— 面试官问"你做了什么优化"，你张嘴说不出东西，氛围直接冷下来
- 用公开 demo 数据还不改 —— 面试官一眼就看出来了，问"数据哪来的"你就尬住
- 三个项目互不相干 —— 做了训练、做了 RAG、做了部署，但串不起来，整体感全无
- 只有代码没有文档 —— 你能跑不代表面试官能看到你的思考过程，文档是你的证据
- 贪多嚼不烂 —— 做5个浅的不如3个深的。面试不看数量看深度
- 不准备追问 —— 项目做了，但讲的时候结结巴巴，和没做区别不大
最后说一句掏心窝的： 这三个项目不是三个独立作业。从头到尾就是一条线——电商客服你微调了模型，金融研报你做了知识检索，最后部署的时候把两个都串上线。面试官要看的就是你能不能从一个具体需求出发，把训练、检索、上线这条路走通。 三个做扎实了，简历上写的就不再是"熟悉大模型相关技术"这种空话，而是你真做过的东西。