项目实战与求职准备 Capstone & Career Preparation

阶段总览

1. 作品集：三类项目，覆盖三种能力

1.1 推荐的项目组合

作品集的组合逻辑是能力覆盖，而不是数量。面试官看的是「训练、工程、应用，你哪一块是短板」。三类各做一个，比同类做三个更有说服力。

一个常被忽略的现实：2026 年企业筛选简历时，「能一键复现的仓库」通过率显著高于「只有描述的项目」；许多团队把「GitLab 上有一定星数、或有可运行 demo」直接作为替代论文的证明。所以三类项目不必都做到完美，但每类至少要有一个陌生人能 10 分钟跑起来的交付物。

python# 作品集「可验证性」自检脚本：把 README 的硬指标当门禁
import re, pathlib
REQUIRED = ["快速开始", "评测", "样本量", "取舍", "限制"]
def audit(readme_path):
    text = pathlib.Path(readme_path).read_text(encoding="utf-8")
    missing = [k for k in REQUIRED if k not in text]
    has_numbers = bool(re.search(r"\d+%|\d+\s*(ms|s|tokens/s|次)", text))
    return {"missing_sections": missing, "has_quantified_results": has_numbers,
            "pass": (not missing) and has_numbers}
print(audit("README.md"))
# 预期（合格）：{'missing_sections': [], 'has_quantified_results': True, 'pass': True}
# 判据：缺「评测」或没有量化数字 -> 直接不通过；这是 90% 个人项目的通病。

1.2 作品集的五条纪律

bash# 可复现性的最低标准：一条命令 + 锁定的依赖
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.lock          # 不是 requirements.txt，要锁版本
docker compose up -d                       # 向量库 / 缓存 / 服务
python scripts/demo.py --q "犹豫期可以退保吗" --offline   # 无需 API key 也能跑
# 自检三问：① 新容器里能跑通吗？② 没网能跑吗（离线 demo）？③ 跑完全程多久？
# 经验：给出「约 3 分钟、需 8GB 显存、有无需 GPU 的降级路径」比炫技更得分。

1.3 让仓库「可被验证」：README 的六段结构

招聘方打开一个仓库，平均只停留 90 秒：先扫 README，觉得靠谱才点开代码。所以 README 不是附属文档，而是项目的门面与唯一的「自我推销」位置。下面这个六段结构经过反复验证，能覆盖评审者的全部核心疑问。

text# 项目名 —— 一句话说明它解决什么问题（带上最关键的数字）

## 1. 它是什么 / 为什么做
   业务场景、输入输出形态、为什么值得做。2–4 句，不看代码也要能懂。
   反例：本项目使用了 RAG、Agent、vLLM 等先进技术。（没说解决什么问题）

## 2. 快速开始（目标是陌生人 10 分钟内跑通）
   git clone <repo> && cd <repo>
   cp .env.example .env          # 只有这一步需要填 key
   docker compose up -d          # 起向量库 / 缓存 / 服务
   python scripts/demo.py --q "犹豫期可以退保吗"
   - 优先提供一个无需外部 API 的离线 demo 路径，把验证门槛降到最低
   - 写清「需要什么硬件 / 显存 / 大约多久」，避免对方跑到一半失败

## 3. 架构与数据流
   [架构图]  客户端 -> 网关(鉴权限流) -> 检索(混合召回) -> 重排 -> 生成 -> 评测埋点
   每个框一句话说明职责与关键选型

## 4. 评测结果（最重要的一节，也是最多人缺失的一节）
   | 指标              | 基线   | 本项目 | 样本量 | 说明                    |
   | 检索 Top-5 命中率 | 62%    | 89%    | 380    | 混合检索 + 交叉编码器重排 |
   | 答案忠实性        | 71%    | 93%    | 160    | LLM-as-Judge，与人工校准  |
   | P95 端到端延迟    | 4.8s   | 2.1s   | 500 次 | 前缀缓存 + 重排批处理     |

## 5. 关键技术决策（3 条，每条一句话说清取舍与代价）
   - 用混合检索而非纯向量：稀疏召回补上专有名词与条款号，代价是多一个索引
   - 用 INT8 而非 INT4：精度只掉 0.4 分而速度提升 1.6 倍，INT4 掉 3 分不可接受
   - 不用 Agent 做主体：任务边界清晰，流水线更可控、延迟更低、可测

## 6. 已知限制与后续计划
   - 表格类条款（费率表）解析会丢结构，目前靠人工校对，计划引入版面模型
   - 单轮问答稳定，多轮追问超过 5 轮后上下文压缩会丢细节

• 第 4 节是分水岭：90% 的个人项目只有第 1、2 节，没有评测结果。只要补上「基线 / 本项目 / 样本量」三列，你的项目立刻从「练习」升格为「工程交付」。
• Quick Start 要实测：找一台干净的机器（或新建一个容器）真的跑一遍。最常见的翻车是「只有作者的本机能跑」。
• 架构图不必精美：一个 ASCII 数据流或一张手绘截图都行，关键是让读者 10 秒建立心智模型。
• 限制写得越诚实越加分：敢于承认局限，说明你理解系统的边界；含糊其辞反而会被追问到崩。
• 提交历史也是作品：把「训练中途调参的 20 个脏 commit」压成有意义的几条，评审者会看。

text## 评测方法（让数字可信的四要素）
   - 数据集：自建 380 条（来源、构造方式、是否含难例）
   - 指标定义：Top-5 命中率 = 前 5 段含正确条款的比例
                 忠实性 = LLM-as-Judge 与人工校准（kappa=0.81）
   - 对照基线：纯向量检索 / BM25 / 混合检索
   - 显著性：n=380 时 3% 内的差异视为不显著，只报告 >5% 的改进

## 复现实验（能一键重跑评测）
   make eval            # 自动跑评测集并生成本节表格
   -> 输出 reports/eval.json + 本 README 第 4 节的表格
# 关键：把「评测方法」独立成一节，评审者才能判断数字是否可信；
#       能一键重跑评测的项目，可信度高于只有一张静态表格的项目。

text# 「陌生人 10 分钟跑通」的最小命令集（写进 README 的 Quick Start）
git clone <repo> && cd <repo>
python -m venv .venv && . .venv/bin/activate
pip install -r requirements.lock                  # 锁定版本，不用 requirements.txt

python scripts/demo.py --q "犹豫期可以退保吗" --offline      # 离线可跑，无需 key
python scripts/eval.py --suite data/eval_380.jsonl           # 复现 README 第 4 节数字
python scripts/bench.py --rps 40 --duration 120 --warmup 30  # 压测 p50/p95/p99

# 一个「可被验证」仓库的目录结构（评审者扫一眼就知道你是否专业）
repo/
  README.md              # 六段结构，第 4 节是评测结果
  requirements.lock      # 锁定版本，保证可复现
  Makefile               # setup / demo / eval / bench 一键入口
  data/eval_380.jsonl    # 评测集（含来源与构造说明）
  scripts/               # demo.py / eval.py / bench.py
  reports/eval.json      # 评测原始输出（每个数字可追溯）
  docs/decisions.md      # 关键技术决策记录（ADR 风格）

# 判据：评审者跑完上面 3 条命令，就能看到 demo 结果、评测表格、压测数据；
#       「make eval 能复现 README 里每一个数字」是可信度的硬标准。
# 经验：在 README 写清硬件需求与预计耗时（如「约 3 分钟 / 8GB 显存 / 有 CPU 降级路径」），
#       能显著降低对方中途放弃的概率。

1.4 三个项目的技术深度阶梯

每个项目都要准备好被追问三层。下面列出各项目「必须能脱口而出」的问题——答不上来，说明这个项目只是「跑通」而非「掌握」。

python# 项目深挖自测：给每个项目的三层追问打分（0=答不出，1=含糊，2=清楚）
# 用法：对每个项目逐题自评，任何一层平均低于阈值就先补 README 再投
PROJECTS = {
  'A_RAG_Agent': {
    'L1_事实': ['语料 2.4 万字', '评测集 380 条', 'Top-5 命中率 62%->89%'],
    'L2_取舍': ['混合检索 vs 纯向量', '交叉编码器重排的延迟代价', 'RRF 的 k 取 60 的原因'],
    'L3_边界': ['长表格 chunk 碎裂', '幻觉导致引用错', '成本随并发上升的拐点'],
  },
  'B_SFT_DPO': {
    'L1_事实': ['SFT 1.2 万条', 'LoRA r=16 alpha=32', '偏好对 8k'],
    'L2_取舍': ['LoRA 层覆盖范围', 'DPO beta=0.1 的依据', '不用 PPO 的原因'],
    'L3_边界': ['reward hacking 迹象', '灾难性遗忘的验证', '数据分布漂移'],
  },
  'C_LLM_Serving': {
    'L1_事实': ['P95 延迟 2.1s', '吞吐 1800 tok/s', 'INT8 量化'],
    'L2_取舍': ['连续批 vs 静态批', '开环 vs 闭环压测', 'KV Cache 占用推导'],
    'L3_边界': ['拐点后延迟陡增', 'QPS x10 先崩在哪', '每百万 token 成本推导'],
  },
}

def score(answers):                     # answers: 每题 0/1/2
    n = len(answers)
    return round(sum(answers) / (2 * n), 2)

for name, layers in PROJECTS.items():
    flat = [a for v in layers.values() for a in v]
    print(f'{name}: 题量={len(flat)}  满分={2 * len(flat)}')

# 判据：把每题填 0/1/2 后
#   L1 平均 < 1.5 -> 数字没记住，必被怀疑没做过
#   L2 平均 < 1.5 -> 只是跑通、没有判断，最多到一面
#   L3 平均 < 1.0 -> 及格线以下，项目会被判定为「玩具项目」
# 目标：三个项目每层平均 >= 1.5，且至少一个项目 L3 >= 1.5（offer 级项目）

1.5 动手练习与自测

1. 可复现性门禁：在仓库里加 make setup && make demo，让一位没接触过项目的同伴在 10 分钟内跑出结果。判据：命令一次跑通、无需你口头解释；失败则回到 README 补依赖与数据获取步骤。
2. 数字可追溯：为 README 里每一个百分比标注「来自哪份评测报告、样本量多少」。判据：任挑一个数字，你能在 30 秒内定位到生成它的脚本与原始输出。
3. 三层追问自测：用上面的打分脚本对三个项目各评一次。判据：三个项目 L1 平均 ≥ 1.5；至少一个项目 L3 平均 ≥ 1.5。
4. 对照基线：你的项目是否有一个「最简单的基线」（纯向量检索 / 未微调原模型 / 单卡无批处理）？判据：README 有一行明确写出「基线 = X，本方法 = Y，改进 = Z 个百分点」。
5. 成本与规模：写下项目在「数据或流量 ×10」时最先崩的一环及缓解方案。判据：能说出具体瓶颈（显存 / 检索延迟 / 数据清洗耗时）而不是「加机器」。
6. 作品集主页：把三个项目汇总成一页，含架构图、关键技术、量化结果与三个最重要的技术决策。判据：非同行也能在 2 分钟内明白你做了什么、做得多好。

2. 简历与项目描述

2.1 一条合格的项目描述

公式：做了什么 + 用了什么关键技术 + 量化结果 + 技术取舍 / 难点。避免「负责 AI 相关开发」这种无法验证、也无法引出追问的表述。

text# 差的写法
负责公司知识库问答系统的开发，使用了大模型与 RAG 技术，效果良好。

# 好的写法
- 从零搭建保险条款问答系统（RAG + Agent，2.4 万字语料 / 380 个条款文档）：
  采用「向量检索 + BM25 混合召回 + 交叉编码器重排」，将 Top-5 命中率从 62% 提升至 89%；
  答案忠实性（自建 160 条评测集，LLM-as-Judge 与人工校准）从 71% 提升至 93%，
  引用正确率 96%。加入 3 类高风险工具的审批门禁与全链路 tracing，
  线上人工介入率从 18% 降至 4%。

# 好的写法的四个特征：
#  1) 有具体规模（多少文档 / 多少评测用例）—— 说明你真的做过
#  2) 有前后对比数字（62% -> 89%）—— 说明你的改动真的有效
#  3) 有指标定义（命中率、忠实性、引用正确率）—— 说明你懂评估
#  4) 有工程细节（审批门禁、tracing）—— 说明你不只是会调 API

• 技术栈要精不要多：只写你能被追问三层的东西。写了「精通 vLLM」就要能回答 PagedAttention 与连续批处理；写了「熟悉分布式训练」就要能解释 ZeRO 三个阶段各切什么。
• 量化结果的锚点优先级：线上真实数据 > 自建评测集数据 > 公开基线上的复现数据 > 绝对指标 + 样本量。实在没有数据时，宁可不写数字，也不要编。
• 开源链接放在最显眼位置：招聘方会点开看。代码风格、README 质量、commit 历史都在被评估范围内。
• 一页为宜：精选 3 个项目讲透，好过 8 个都讲不透。简历的作用是获得面试，不是完整记录你的经历。

text# 简历条目自检：每条项目描述都要能通过下面 5 个断言
# 断言 1 有规模：句子含具体数字（文档数 / 样本量 / 请求量 / 参数规模）
# 断言 2 有基线：明确「从 X 提升到 Y」，而不是只写「效果良好」
# 断言 3 有指标定义：命中率 / 忠实性 / P95 延迟 / 每百万 token 成本 …
# 断言 4 有取舍：写出关键技术选择的代价（延迟、成本、复杂度）
# 断言 5 有钩子：留下 1-2 个你想被追问的关键词（前缀缓存 / 重排 / GQA）

# 反例 -> 正例
负责公司知识库问答系统的开发，使用了大模型与 RAG 技术，效果良好。
- 从零搭建保险条款问答（RAG + Agent，380 个条款文档，自建 160 条评测集）：
  混合检索（向量 + BM25）加交叉编码器重排，Top-5 命中率 62% -> 89%；
  懒加载加前缀缓存把 p95 从 3.4s 降到 2.1s；每千次请求成本 $1.9。

# 一句话公式
做了什么 + 用了什么关键技术 + 量化结果（基线 -> 提升）+ 技术取舍 / 难点

2.2 简历的六个模块与排序策略

• 排序按「岗位相关性」而非时间倒序：投 Agent 岗位，就把 Agent / RAG 项目放最前；投训练岗位，就把后训练实验放最前。一份简历可以有多个版本，这是合理且必要的。
• 关键词对齐 JD：把目标岗位 JD 里的技术名词列出来，检查你的简历覆盖了哪些、缺哪些。缺失的要么补上真实经验，要么不提（不要硬凑）。
• 「精通」只留给能讲 20 分钟的点：其余用「熟悉 / 了解 / 有实践经验」。面试官的口径通常是：写精通 = 我会往深了问。
• 每一条都要能引出你想被问的问题：简历是你控制面试方向的唯一工具。你想被问 RAG，就在 RAG 条目里留下「混合检索」「重排」「忠实度评测」这些钩子。
• 非科班不解释：你有 10 年工程经验 + 三个 AI 项目，这本身就是最强的说明。把篇幅留给项目。

python# 简历关键词覆盖度自检：把目标 JD 与简历都转成小写文本后比对
JD_KEYWORDS = ['rag', 'agent', 'mcp', 'evaluation', 'vllm', 'sglang',
               'quantization', 'lora', 'grpo', 'distributed', 'kubernetes',
               'tensorrt', 'kv cache', 'sft', 'dpo']

RESUME = '''负责知识库问答系统；使用 rag 与 agent；
用 vllm 部署并做 quantization；用 lora 做 sft。'''

def coverage(jd, resume):
    r = resume.lower()
    hit = [k for k in jd if k in r]
    miss = [k for k in jd if k not in r]
    return hit, miss

hit, miss = coverage(JD_KEYWORDS, RESUME)
print(f'覆盖 {len(hit)}/{len(JD_KEYWORDS)}: {hit}')
print(f'缺失: {miss}')
# 示例输出：覆盖 6/15: ['rag','agent','vllm','quantization','lora','sft']
#           缺失: ['mcp','evaluation','sglang','grpo','distributed','kubernetes','tensorrt','kv cache','dpo']

# 判据：目标岗位 JD 的核心关键词应覆盖 >= 60%（机器筛常按此打分）；
# 但缺失的关键词不要硬凑——要么补真实经验，要么在简历里不提。

2.3 动手练习与自测

1. 改写一条描述：挑你现有一句最弱的项目描述，按「做了什么 + 关键技术 + 量化结果 + 取舍」重写。判据：新版至少含 2 个数字、1 个基线、1 个取舍，且不超过 3 行。
2. 关键词对齐：把目标岗位 JD 复制出来，用上面的脚本算出覆盖率。判据：核心关键词覆盖 ≥ 60%；未覆盖的要能区分「该补经验」还是「本就不相关」。
3. 一页裁剪：把简历裁到一页，删掉所有不能被追问的内容。判据：删完后仍保留 3 个项目、每项目 ≥ 2 个量化结果，且有开源链接。
4. 方向微调：为「应用 / Agent」与「推理 / 基础设施」两个方向各做一版，调整项目排序与突出侧面。判据：两版第一屏内容明显不同，且各自与该方向 JD 关键词最匹配。
5. 「精通」审查：把简历里所有「精通 / 熟悉」列出来，逐个自问「我能不能讲 20 分钟」。判据：讲不到 20 分钟的一律降级为「有实践经验 / 了解」。

3. 面试体系与答题结构

3.1 四类环节与准备重点

bash# 用纯文本维护一份面试准备看板（放进仓库 docs/interview.md）
# 每轮面试前打开，面完 24 小时内更新

## 待办
- [ ] 手写清单 6 项独立写出（注意力 / LoRA / KV 估算 / GRPO 优势 / DPO / softmax）
- [ ] 原理题四栏表填满 30 个知识点
- [ ] 系统设计 5 题，每题写到第 4 步容量估算
- [ ] 项目 A/B/C 各做一次三层追问自测

## 进行中
- [ ] 项目 C：补齐「开环压测」与「容量拐点」两节 README

## 已完成
- [x] 简历两版（应用方向 / 基础设施方向）
- [x] 作品集主页上线

# 统计已完成条数
grep -c '\[x\]' docs/interview.md
# 经验节奏：练手 3-5 家 -> 复盘修正表达 -> 重点公司 8-12 家 -> offer 比较

3.2 系统设计题答题框架（六步）

第 4 步最容易被答成一句空话（「加机器就行」）。下面给出一个可以当场口算的估算模板——面试时只要能把这张表写出来，这一轮基本就稳了。

python# 题目：设计一个日请求 100 万次的大模型问答服务，估算资源与成本
import math

REQ_PER_DAY = 1_000_000
RPS_AVG     = REQ_PER_DAY / 86_400          # ≈ 11.6 请求/秒（平均）
PEAK_FACTOR = 4                              # 峰值系数，业务通常取 3–5
RPS_PEAK    = RPS_AVG * PEAK_FACTOR          # ≈ 46.4 请求/秒（峰值）

IN_TOK, OUT_TOK = 800, 300                    # 输入 / 输出 token 长度（来自线上分布）

# 单卡吞吐必须来自压测，不能拍脑袋。经验量级：
# 7B 模型 / FP16 / A100-80G / 连续批处理 + GQA + 前缀缓存
#   满足 p95 < 3s 时，约 1500–2500 output token/s（强依赖输入长度与并发）
SINGLE_GPU_OUT_TOK_S = 2000

RPS_PER_GPU = SINGLE_GPU_OUT_TOK_S / OUT_TOK        # ≈ 6.7 请求/秒/卡
GPUS        = math.ceil(RPS_PEAK / RPS_PER_GPU)      # ≈ 7 张
GPUS_HA     = GPUS + max(1, GPUS // 5)               # N+1 冗余 ≈ 9 张

GPU_USD_HOUR = 2.5                                    # 云上 A100 量级单价
MONTH_COST   = GPUS_HA * GPU_USD_HOUR * 24 * 30       # ≈ 16,200 美元/月

MONTHLY_OUT_TOK = REQ_PER_DAY * 30 * OUT_TOK          # 输出 token 总量
PER_M_TOK = MONTH_COST / (MONTHLY_OUT_TOK / 1_000_000)  # ≈ 1.8 美元/百万 output token

# 面试时还要主动补三句：
#  1) 这些数字里哪个最不确定 —— 单卡吞吐（依赖压测），所以要说明测量条件
#  2) 能怎么把成本压下来 —— 前缀缓存（命中率高可省 30%+ prefill）、
#     语义缓存（重复问题占比通常 10–30%）、模型路由（简单问题走小模型）
#  3) 什么时候该用商业 API —— 峰值稀疏或总量不大时，API 的弹性优于自建固定成本

经典练习题：① 设计企业内部知识库问答（10 万文档 / 5000 员工 / 私有化部署）；② 设计能跑长任务的 Agent 平台（工具注册、审批、可观测、断点恢复）；③ 设计日请求 100 万次的推理服务（含成本优化与降级）；④ 设计多模态文档处理流水线（含复杂版面）；⑤ 设计客服 Agent 的评测与回归体系。每题都按六步写一遍，并强制写上第 4 步的数字。

text# 系统设计六步答题模板（把每步写成一句话，面试时照这个节奏走）
1. 澄清：用户量 __ / 请求量 __ / 输入输出长度 __ / 延迟 SLA __ / 成本上限 __ / 私有化 __
2. 架构：客户端 -> 网关(鉴权/限流) -> 编排 -> 检索/工具 -> 模型(路由) -> 缓存 -> 观测
3. 选型：检索=? 模型(大/小/路由)=? 部署(API/自托管)=? 缓存(前缀/语义)=?
        每项补一句「为什么是它、代价是什么」
4. 估算：显存=? 卡数=? 每千次请求成本=? p95=?
5. 质量与安全：评测集 / tracing / 限流降级 / 注入防御 / 审批 / 合规留痕
6. 演进：流量 x10 / 延迟要求 x2 / 多模态 时，架构怎么改

# 示例（企业内部知识库问答 5000 员工 / 10 万文档 / 私有化）
估算（粗算，口算级）：
  10 万文档 x 平均 6 chunk = 60 万 chunk；
  向量索引 60 万 x 1024 维 x 4B ≈ 2.4 GB（HNSW 常驻内存，单机可放）；
  Qwen3-14B INT4：权重约 8-9 GB，KV Cache 单请求 4k 上下文约 0.4 GB；
  A100-80G 单卡 2 并发稳妥，4 并发建议 TP=2；日均约 8000 次问答，单卡足够。
  延迟预算：检索 80ms + 重排 120ms + 生成 1.8s ≈ 2.0s，满足 p95 < 3s。

3.3 手写实现清单（必须能当场写出来）

python# 面试高频手写清单 —— 每一项都应能在 10 分钟内写出核心逻辑

# 1) Scaled Dot-Product Attention（含因果掩码）
def attention(Q, K, V, mask=None):
    d_k = Q.shape[-1]
    scores = Q @ K.transpose(-2, -1) / d_k ** 0.5
    if mask is not None:
        scores = scores.masked_fill(mask == 0, float("-inf"))
    w = scores.softmax(dim=-1)
    return w @ V, w

# 2) 手写 LoRA 层（并说明参数量）
class LoRA(nn.Module):
    def __init__(self, in_f, out_f, r=8, alpha=16):
        super().__init__()
        self.A = nn.Parameter(torch.randn(r, in_f) * 0.01)
        self.B = nn.Parameter(torch.zeros(out_f, r))     # B 初始化为 0 -> 初始等价于原模型
        self.scale = alpha / r                            # 缩放，使 r 变化时效果稳定
    def forward(self, x):
        return x + (x @ self.A.T @ self.B.T) * self.scale

# 3) KV Cache 显存估算（容量规划必考）
def kv_bytes(layers, seq, kv_heads, d_head, batch=1, bytes_per=2):
    return batch * layers * seq * kv_heads * d_head * 2 * bytes_per

# 4) GRPO 组相对优势
def group_adv(rewards, eps=1e-4):
    r = torch.tensor(rewards, dtype=torch.float)
    return (r - r.mean()) / (r.std() + eps)

# 5) DPO 损失
def dpo_loss(p_chosen, p_rejected, r_chosen, r_rejected, beta=0.1):
    c = beta * (p_chosen - r_chosen)
    rj = beta * (p_rejected - r_rejected)
    return -torch.nn.functional.logsigmoid(c - rj).mean()

# 6) softmax（含数值稳定处理）—— 别在这里翻车
def softmax(x, axis=-1):
    x = x - x.max(axis=axis, keepdims=True)
    e = torch.exp(x)
    return e / e.sum(axis=axis, keepdims=True)

# 加分动作：写完后主动补充说明
#   · 这段的复杂度是多少
#   · 数值上有什么风险、怎么解决
#   · 生产环境会怎么优化（F.scaled_dot_product_attention / 融合内核）

python# 高频手写续：采样与结果融合（都要能现场写出并解释）
import torch

def top_k_top_p_filter(logits, top_k=0, top_p=0.9, temperature=1.0):
    logits = logits / max(temperature, 1e-6)
    if top_k > 0:                                   # 只保留概率最高的 k 个
        kth = torch.topk(logits, top_k).values[..., -1, None]
        logits = torch.where(logits < kth, float('-inf'), logits)
    if top_p < 1.0:                                 # 核采样：按累积概率截断
        s, idx = torch.sort(logits, descending=True, dim=-1)
        cum = torch.cumsum(torch.softmax(s, dim=-1), dim=-1)
        cut = cum > top_p
        cut[..., 1:] = cut[..., :-1].clone()         # 移位：保留跨越阈值的那个
        cut[..., 0] = False
        s = s.masked_fill(cut, float('-inf'))
        logits = torch.empty_like(logits).scatter_(-1, idx, s)
    return torch.softmax(logits, dim=-1)

def rrf(rank_lists, k=60):                           # 混合检索的融合公式
    scores = {}
    for ranks in rank_lists:
        for pos, doc in enumerate(ranks, start=1):
            scores[doc] = scores.get(doc, 0) + 1.0 / (k + pos)
    return sorted(scores, key=scores.get, reverse=True)

# 预期：rrf([[1,2,3],[3,1,4]]) -> [1, 3, 2, 4]
#   doc1 两表都靠前：1/61 + 1/62 ≈ 0.0325（最高）；doc3 次之 ≈ 0.0323
# 预期：top_p=0.9 通常保留 5-20 个候选；温度常用区间 0.7-1.0

3.4 高频原理题速查表

原理题的答题要求不是「说对名词」，而是说出因果链。下表列出最常被问的问题，以及回答里「必须触及的点」——缺了这些点，面试官会认为你只是背过。

• 答题四段法：先「是什么」（一句话定义）→ 再「为什么」（动机与因果）→ 再「怎么用」（工程细节与超参）→ 最后「什么时候不要用」（边界条件）。第四段是分水岭。
• 主动给数字：说 GQA 省显存时给出「KV Cache 降为 1/g」；说 warmup 时给出「1–3% 总步数」；说量化收益时给出「INT8 约 1.5–2 倍、INT4 约 2–3 倍」。有数字才显得是做过而不是读过。
• 不要背结论：面试官最常见的追问是「那如果没有这个条件会怎样」——只有理解因果链才能答上来。
• 承认不知道：遇到真不会的，说「这块我没有实践过，我的理解是…可能不对」。编造的答案比不知道的答案伤害大得多。

python# 把原理题按「四栏」结构化：填不满的栏目就是你的短板
KNOWLEDGE = {
  'continuous_batching': {
    'what':  '按 token 迭代调度，序列一结束就补新请求进批',
    'why':   '静态批要等最长序列结束，短序列算力被浪费',
    'how':   'vLLM/SGLang 默认开启；调 max_num_seqs 平衡吞吐与延迟',
    'num':   '相比静态批吞吐常提升 2-4 倍；max_num_seqs 常取 256',
    'limit': '超长序列会拖慢整批；需配合 chunked prefill 与抢占',
  },
  'paged_attention': {
    'what':  '把 KV Cache 切成固定大小 block，用 block table 间接寻址',
    'why':   '连续分配按最大长度预留，实测内部碎片常达 60-80%',
    'how':   'block_size（如 16）需与内核对齐；支持前缀共享',
    'num':   '显存浪费接近 0；前缀缓存命中时可省 30%+ prefill',
    'limit': 'block 太小调度开销大、太大碎片多；需实测取平衡',
  },
}

def audit(kb):
    for name, cols in kb.items():
        empty = [c for c, v in cols.items() if not v]
        print(f'{name}: {"OK" if not empty else "缺 " + ",".join(empty)}')

audit(KNOWLEDGE)
# 判据：每题的 what/why/how/num/limit 都不能为空；
#   「num」栏空 = 没有量化认识；「limit」栏空 = 没理解边界条件。
# 目标：把 30-50 个高频知识点全部填满——这就是面试前最后要看的东西。

3.5 项目深挖的三层追问模型

项目深挖环节的提问逻辑是固定的三层结构。提前按这三层为每个项目准备好答案，这一轮就很难失分。

text# 三层追问应答自检：把每个项目的答案写成三行，缺行的就是漏洞
项目 A（RAG + Agent）
  L1 事实：380 条款文档 / 160 条评测集 / Top-5 62%->89% / 引用正确率 96%
  L2 取舍：混合检索 vs 纯向量（召回 +12%，代价是索引复杂度上升）；
           重排 +9%，代价 p95 +120ms；RRF 的 k=60 是经验默认
  L3 失败：长表格被切碎导致召回漏 -> 改按版面切；
           成本随并发非线性上升 -> 前缀缓存 + 语义缓存，降本约 35%

# 自检断言（每条为真才继续）
#   L1 行至少 3 个数字？            -> 否则被怀疑没做过
#   L2 行每个选择都带「代价是…」？  -> 否则被判定只会用、不会判断
#   L3 行有具体失败 + 修复闭环？    -> 这是资深与新手的真正分界
# 提醒：L3 一定要讲真实失败；编一个「完美项目」比讲一次失败更减分。

3.6 动手练习与自测

1. 限时手写：10 分钟内默写 Scaled Dot-Product Attention（含 mask 与数值稳定）+ KV Cache 显存函数。判据：一次写对，且能解释 √d_k、mask 用 −∞ 的原因。
2. 原理题四段：随机抽 10 个知识点，按「是什么 / 为什么 / 怎么用 / 何时不用」口述。判据：每题都能给至少 1 个数字，且第四段（边界）不空白。
3. 系统设计限时：45 分钟内完成「日请求 100 万次问答服务」六步，必须写出显存 / 卡数 / 每百万 token 成本。判据：第 4 步有可复算数字，且明确标出最不确定的假设。
4. 三层追问录音：让同伴对项目 C 连续追问 10 分钟并录音。判据：无「要回去翻代码」的回答；至少主动说出 1 个失败与 1 个权衡。
5. 采样 / 融合实现：现场写出 top-k / top-p 与 RRF。判据：能说清 top_p 的累积概率截断逻辑，且 RRF 例子输出为 [1,3,2,4]。
6. 复盘归因：每次模拟面试后写下「哪一问答得含糊」，并给出 48 小时内的补救动作。判据：含糊点在下一次模拟中不再出现。

4. 求职策略与持续学习

4.1 岗位地图与投递策略

• 投递节奏：先投 3–5 家「练手目标」（不是最想去的）收集反馈、修正表达，再投重点公司。面试表达是练出来的，别用最想去的公司当练习场。
• 内推优先：开源社区、技术群、前同事是最高效的渠道。开源项目做得好的话，维护者本身就是内推人。
• 匹配度优先于排名：一个有对应项目经验的候选人，比背景更强但方向不匹配的候选人更容易通过。所以简历要按岗位方向做微调（同一份项目，突出不同侧面）。
• 谈薪要点：① 准备市场区间（多份 offer 是最好的筹码）；② 明确自己的不可替代点（如「能独立交付带评测体系的 Agent 系统」）；③ 不只看月薪，看总包、职级、成长空间与团队方向；④ 第一次报价不要先出底牌，先问对方预算区间。

text# 投递看板（docs/jobs.md，也可用飞书多维表格维护）
公司 | 岗位 | 渠道 | 投递日 | 阶段 | 下一步
-----|------|------|--------|------|------
A    | 大模型应用 | 内推 | 03-01 | 一面 | 约二面时间
B    | 推理基础设施 | 官网 | 03-03 | 笔试 | 刷 2 题
C    | 后训练算法 | 内推 | 03-05 | 待回复 | 一周后跟进
...

# 漏斗经验（AI 岗位，2026）
投递 15-25 家 -> 面试 8-12 家 -> 终面 4-6 家 -> offer 2-3 个
即 投递->面试 约 15-25%；面试->offer 约 20-30%
# 策略：先用 3-5 家练手目标修正表达，再投重点公司；练手目标不要用最想去的公司

4.2 12 周求职冲刺时间线

假设前面阶段已完成、三个项目已具备雏形，那么从「决定求职」到「拿 offer」的 12 周可以这样安排。这个节奏的核心是先修作品，再修表达，最后集中投递——顺序颠倒会浪费大量机会。

text# 12 周冲刺清单（勾选式；每周只聚焦 1 个主产出）
W1-3  [ ] 项目 A/B/C README 补齐评测节，达到「陌生人 10 分钟跑通」
      [ ] 统一代码风格；加 make setup / make demo / make eval
W4    [ ] 简历长版 -> 一页版；按 2-3 个方向各做一版
W5    [ ] 原理题四栏表填满 30 个知识点；6 个手写实现全部默写一遍
W6    [ ] 系统设计 5 题（每题写到第 4 步容量估算）
W7    [ ] 作品集主页上线；投 3-5 家练手目标
W8-9  [ ] 每场面试 24h 内复盘，记录「答得含糊」的问题并修补
W10-11[ ] 投重点公司（内推优先）；做 3 轮模拟面试
W12   [ ] offer 比较与谈薪；对失败场次做归因

# 判据：每周结束时能回答「本周的可交付物是什么」；答不出说明这周在空转。
# 反模式：先疯狂投递再回头修作品 —— 顺序颠倒会浪费前 20% 的宝贵机会。

4.3 职业路径与三年成长路线

• 第一年（0–12 个月）：把一件事做完整。 目标不是学得多，而是独立交付一个从数据到上线、带评测的系统。这一年的关键产出是「可被验证的系统能力」。
• 第二年（12–24 个月）：形成标签。 在一个具体方向上形成可辨识的优势——比如「混合检索调优」「后训练数据构造」「推理服务压成本」。有标签才有人记得你。
• 第三年（24–36 个月）：从做项目到做决策。 开始为技术选型负责、带人、定义指标与标准。这一阶段的瓶颈通常不是技术，而是沟通与判断。
• 工程背景的人是应用 / 平台方向的天然优等生：你们的瓶颈在模型侧（阶段 5–9），而不在工程侧。把模型侧补到「能读论文、能设计实验」，竞争力会非常突出。不要试图在数学上与科班拼深度，要在系统上与他们拉开差距。
• 关于「要不要读研/读博」：如果目标是应用与平台，项目经验的边际收益远高于学位；如果目标是研究型岗位，学位几乎是必需的。先明确目标，再决定是否回炉。

text# 路径选择打分（自评 1-5 分，加权后看哪一列最高）
维度(权重)            应用  算法  平台
喜欢的交付物(3)         ?     ?     ?
数学基础自信(2)         ?     ?     ?
性能 / 系统兴趣(3)      ?     ?     ?
实验耐心(2)             ?     ?     ?
可获得的资源(2)         ?     ?     ?   # 有无 GPU / 数据 / 导师
# 打分规则：每列 = Σ(自评分 x 权重)；最高列即优先方向。
# 但三条路不是互斥的——应用型也能往平台靠，
# 关键是在第一年先「把一件事做完整」，再谈方向标签。

4.4 持续学习机制：让能力不贬值

python# 季度能力自评：把 17 个阶段按「能否独立交付」打分，而不是「是否学过」
# 分值：0=没学过 1=看过 2=跑通过 3=能改写 4=能设计与排错
SELF = {
  '05_数学与优化': 2, '06_Transformer': 3, '07_训练工程': 2,
  '08_后训练_SFT': 3, '09_RL后训练': 2, '13_RAG': 4,
  '14_Agent': 4, '15_Evals': 3, '16_推理优化': 2, '17_求职': 3,
  # ... 其余阶段自行补全
}

def summary(self_score):
    weak  = [k for k, v in self_score.items() if v <= 1]
    solid = [k for k, v in self_score.items() if v >= 3]
    avg   = sum(self_score.values()) / len(self_score)
    return weak, solid, round(avg, 2)

weak, solid, avg = summary(SELF)
print('平均分', avg)                 # 期望随季度单调上升
print('短板(<=1)', weak)              # 下季度学习清单就来自这里
print('已扎实(>=3)', solid)           # 可以作为简历上的标签

# 判据：季度平均分应比上季 +0.3 以上；
#   「>=3 的项」至少覆盖一个岗位方向所需的关键阶段（如应用方向需 13-15 均 >=3）。
# 反模式：把所有阶段都自评 3+，等于没评——自评要写下来才会诚实。

4.5 动手练习与自测

1. 建立投递看板：按上面的表格建一个 jobs 看板，填满 10 家目标公司。判据：每家有明确渠道（内推优先）、投递日与「下一步动作」。
2. 制定 12 周计划：把 12 周清单复制成你自己的版本，标出每周唯一的主交付物。判据：每周都能回答「本周交付什么」；前三周先修作品再投递。
3. 路径打分：用打分表给自己三个方向各算一次加权分。判据：得出一个优先方向，并写出「第一年要把哪一件事做完整」。
4. 季度自评：用脚本给 17 个阶段打分。判据：得出「短板清单」与「可作为简历标签的 3 个已扎实项」，并据此安排下季度学习。
5. 漏斗校准：记录你实际投递的前 10 家的转化率，与 15–25% 的经验值对比。判据：若面试率明显偏低，优先修简历与作品集而非扩大投递量。
6. 谈薪准备：写下你的市场区间、不可替代点与期望职级。判据：能给出「总包区间 + 支撑该区间的项目证据」，且不先出底牌。

项目里程碑

阶段练习项目

常见误区

• 等学完所有内容再开始做项目，结果一直没有可展示的作品。
• 项目只有代码没有 README，或者无法一键跑起来，招聘方 90 秒后直接关掉。
• README 里没有评测结果这一节——这是 90% 个人项目的通病，也是最致命的缺失。
• 简历写「负责 XX 系统开发」但没有量化结果，既无法验证也无法引出追问。
• 技术栈写一大堆，每个都经不起追问三层，反而暴露了不扎实。
• 只准备八股不练手写实现，现场写注意力或 DPO 损失时卡壳。
• 手写代码时不做数值稳定处理（softmax 不减最大值、mask 用 0），直接暴露工程习惯问题。
• 系统设计题上来就给方案，既不澄清需求也不做容量与成本估算。
• 只投「最想去的公司」，没有练手机会，表达未经修正就消耗了宝贵机会。
• 面试后不复盘，同一个问题在第二家公司还是答不好。
• 简历上写了「精通」，被问两个细节就答不出来，信任瞬间崩塌。
• 把「刷完课程」当成目标，而不是「交付能运行的系统和可验证的结果」。

面试高频问题速答

介绍一个你最有挑战的项目，重点说技术难点与你的决策。

推荐结构（STAR + 技术取舍）：① 背景与约束——业务目标、数据规模、延迟与成本约束；② 方案与备选——提出 2–3 个方案并说明为什么选这个（如为什么用混合检索而不是纯向量、为什么不上 Agent 而是流水线）；③ 关键难点——具体到技术细节（召回率不足、重排延迟过高、长上下文成本失控），以及你怎么定位与解决；④ 结果与验证——量化指标、评测集规模、对比基线；⑤ 限制与后续——已知失效场景与下一步计划。第五点最容易加分，因为它证明你在持续思考而不是结项就忘。

如果让你设计一个日请求 100 万次的推理服务，你会怎么估算资源？

步骤：① 明确输入输出长度分布与延迟 SLA；② 选模型与量化方案，估算单次请求的显存与算力需求；③ 通过压测得到「满足 p95 延迟前提下的单卡 QPS」——注意不是峰值吞吐，而是满足 SLA 的 QPS；④ 用日请求量除以 86400 得平均 QPS（约 11.6），再乘峰值系数 3–5 得峰值 QPS（约 35–58）；⑤ 除以单卡 QPS 得卡数，加 N+1 冗余；⑥ 计算月度成本并与商业 API 对比。同时主动说明优化手段能把成本降低多少：前缀缓存（命中率高时省 30%+ prefill）、语义缓存（重复率通常 10–30%）、模型路由（简单问题走小模型）、量化（INT8 约 1.5–2 倍加速）。

你没有训练大模型的资源，怎么证明你有训练能力？

三条路径：① 在 7B–8B 级模型上用 QLoRA + 梯度检查点 + 梯度累积完成 SFT（单卡或少量卡可行），再做 DPO 或小规模 GRPO；② 在 1B 以下模型上从零训练一个 MiniGPT，展示对训练全流程、损失曲线与初始化问题的理解；③ 用公开数据集做数据管线与质量分析（清洗、去重、配比、污染检测），这是训练能力中最被低估但最重要的一环。关键在于呈现「对照实验 + 失败分析」，而不是指标有多高。面试官想看的是你能否设计实验并对结果做出正确解释。

你的项目里最失败的一次尝试是什么？

这类题在考察反思深度，不是在找弱点。合格答法要包含四段：① 具体做了什么（可验证的细节）；② 期望是什么、实际发生了什么（承认偏差，敢给数字）；③ 你怎么定位原因（诊断过程比结论更重要）；④ 学到什么并如何改变了后续做法。例如：「我一度用纯向量检索，Top-5 命中率只有 62%，起初怀疑是嵌入模型不行，换了两三个模型都没改善；后来把失败样本捞出来逐个看，发现失败集中在含条款编号与专有名词的查询上——稀疏检索恰好擅长这个，于是改成混合检索 + RRF，命中率直接到 89%。这让我形成了习惯：先看失败样本，再动方案。」

你怎么跟进 2026 年快速变化的 AI 技术？

机制化而不是靠感觉：① 每周固定时间看 arXiv 摘要与实验室技术报告，只精读与方向相关的 1–2 篇；② 每月做一次最小复现（一个小技术点），复现一次胜过读十篇；③ 每两周写一篇技术笔记，写作会暴露理解漏洞；④ 持续参与一个开源项目（issue / PR / 讨论），这是最好的学习与求职渠道；⑤ 每月看一次目标岗位 JD 的变化，用市场需求反推学习优先级；⑥ 每季度用结构化清单自评，找真实短板。重点是「固定时间 + 固定产出」，而不是「有空就看」。

你为什么想做这个方向？如果模型能力再大幅提升，你担心自己的工作被替代吗？

答题要点是展示对岗位本质的理解，而不是表达热情。可以这样组织：① 说明你关注的是把能力变成可靠系统这件事，而不是某个具体模型的调参技巧——模型越强，把能力工程化、评测化、可控化的需求反而越大；② 举一个你实际遇到的例子，说明「模型本身没问题但系统失败」的场景（检索召回不足、上下文冲突、工具调用错误），这类问题是模型能力提升无法自动解决的；③ 承认会被替代的部分：纯提示词调优、机械的 API 拼接确实在贬值，所以我把精力放在评测体系、系统设计与成本控制这些更靠工程判断的地方。这个回答的关键是诚实地区分「会贬值的能力」与「会升值的能力」。

你手上如果有多个 offer，你会怎么选？

给出结构化的比较维度，而不是只说「看成长」：① 方向匹配度——是否在做你想深入的领域（做三年非目标方向的机会成本极高）；② 团队与直属 leader——面试时可以反向面试：团队规模、技术决策谁拍板、最近半年做了什么；③ 工程成熟度——有没有评测体系、有没有真实流量、还是长期做 demo；④ 成长曲线——你能接触到的是「一个模块」还是「一条链路」；⑤ 回报结构——总包构成、股权与兑现条件、职级与晋升通道。把这些写成一张表再比较，会比凭感觉靠谱得多。

学习资源