Appearance
课 1 · 项目包装与面试
本课目标
掌握简历中 AI 项目的写法、面试中的架构讲解技巧，覆盖高频面试题的回答框架。课后你会有一份可用的简历描述和面试准备清单。
整个课程做下来，你手上有一个完整的 AI 应用项目：知识库 Agent，覆盖 RAG、Tool Call、Multi-Agent、质量控制。
这一课解决最实际的问题：怎么把这个项目写进简历、在面试中讲清楚。
这里默认以 basic/project 作为最终交付物来包装，模块 1-8 用来解释项目为什么会一步步演进成今天的样子。
项目文档怎么写
项目文档是给面试官看的，也是给自己理清思路的工具。
README 结构
markdown
# 智能知识库 Agent
## 项目简介
基于 RAG + Agent 架构的企业知识库问答系统。支持文档导入、
语义检索、多工具调用、多 Agent 协作。
## 技术架构
- LLM：Qwen3.6-Plus（阿里云百炼 OpenAI-compatible）
- Embedding：text-embedding-v4（阿里云百炼）
- 向量存储：SQLite + sqlite-vec（final） / Postgres + pgvector（课程工程实践）
- 框架：Vercel AI SDK + TypeScript
## 核心功能
1. 文档导入与智能分块
2. 混合检索（BM25 + 向量 + RRF 融合，可按需加 Rerank）
3. Agent 工具调用（知识库搜索、文件操作、任务管理）
4. 多 Agent 协作（研究 → 撰写 → 审校）
5. 质量控制（输出校验、重试、Fallback）
## 关键指标
- 检索 Faithfulness：0.85+
- 平均响应时间：< 3s
- 日均 Token 成本：< $5关键原则：有数据、有架构、有取舍。 面试官看的不是功能列表，是你的技术判断力。
简历怎么写
STAR 法则
简历项目描述用 STAR（Situation-Task-Action-Result）：
智能知识库 Agent | TypeScript + Vercel AI SDK
────────────────────────────────────────────────
基于 RAG + Agent 架构的企业知识库问答系统。
- 设计混合检索方案（BM25 + 向量 + RRF 融合），
并用小评测集和 Bad Case 验证优化效果
- 搭建 Multi-Agent 协作流程（研究-撰写-审校），
内容生成准确率 85%+
- Token 成本控制：语义缓存命中率 65%，日成本降低 60%技术关键词
确保简历中包含这些关键词（ATS 系统和面试官都会扫描）：
| 方向 | 关键词 |
|---|---|
| 模型 | LLM、Qwen、GPT、Embedding |
| 框架 | Vercel AI SDK、LangChain、LlamaIndex |
| 检索 | RAG、向量检索、BM25、混合检索、Rerank、pgvector、sqlite-vec |
| Agent | Tool Call、ReAct、Multi-Agent |
| 质量 | 幻觉控制、离线评测、Bad Case、RAGAS、A/B 测试 |
| 工程 | Token 优化、语义缓存、Tracing、监控 |
避坑
- ❌ "使用了 ChatGPT API" — 太笼统，没有技术深度
- ✅ "基于 Vercel AI SDK 的 generateText + tool 实现 ReAct Agent" — 具体到 API 级别
- ❌ "优化了系统性能" — 没有数据
- ✅ "语义缓存命中率 65%，日均 Token 成本降低 60%" — 有量化结果
面试中怎么讲项目
3 分钟讲清楚架构
面试官问"介绍一下你的项目"，按这个结构：
第一段：一句话说清楚做了什么（30 秒）
我做了一个企业知识库问答系统，用户可以导入文档，通过自然语言提问获取准确答案。核心架构是 RAG + Agent，用 TypeScript 和 Vercel AI SDK 实现。
第二段：技术架构（1 分钟）
技术架构分三层：
- 检索层：文档经过分块、Embedding 后进入向量存储。课程工程实践里我用过 pgvector，最终交付里为了做本地优先工具改成了 SQLite + sqlite-vec。查询时用 BM25 和向量检索做混合检索，RRF 融合后再排序；如果遇到难样例，再用 Rerank 做进阶增强。
- Agent 层：基于 ReAct 模式，Agent 可以调用知识库搜索、文件操作、任务管理等工具。
- 质量层：输出用 Zod Schema 校验，重试 + Fallback，Token 成本控制有语义缓存。
第三段：技术决策和结果（1 分钟）
选混合检索是因为纯向量检索对术语匹配不够精确，加 BM25 后检索稳定性提升明显。我会用小评测集和 Bad Case 做验收，再决定是否需要加 Rerank。最终检索 Faithfulness 达到 0.85+，日均成本控制在 $5 以内。
讲项目的原则
- 先全貌后细节 — 先说整体架构，面试官追问时再展开
- 讲决策不讲流水账 — "为什么选 X 而不是 Y"比"我做了 A 然后做了 B"有价值
- 有数据 — 每个技术决策最好配一个量化结果
- 承认边界 — "如果数据量更大，我会考虑..."比假装完美更加分
高频面试题与回答框架
以下覆盖 300+ 道真实面经中的高频题。不给标准答案——用自己项目的经验回答，比背答案有效 10 倍。
LLM 基础
Q：Attention 机制中为什么要除以 √dk？
防止在 dk 较大时，点积结果过大导致 Softmax 进入饱和区（梯度接近 0）。除以 √dk 做缩放，让注意力分数保持在合理范围。
Q：KV Cache 的作用？
自回归生成时，每生成一个 Token 都需要和前面所有 Token 做 Attention。KV Cache 把已计算的 Key/Value 缓存起来，新 Token 只需要计算自己的 Q，和缓存的 K/V 做 Attention。把 O(n²) 降到 O(n)。代价是显存占用。
Q：Decoder-only 为什么是主流架构？
三个原因：1. 自回归生成天然适合对话场景。2. 训练数据利用效率高（每个位置都可以预测下一个 Token）。3. 大模型 scaling law 在 Decoder-only 上表现最好。GPT、Claude、LLaMA 都是 Decoder-only。
RAG
Q：描述一下 RAG 的完整流水线。
六步：文档解析（PDF/Markdown/HTML → 纯文本）→ 分块（递归分块，512 token，重叠 50）→ Embedding（用 text-embedding-v4 生成向量）→ 存储（课程工程实践里可用 pgvector，最终交付里可用 sqlite-vec）→ 检索（查询 Embedding → Top-K 相似文档）→ 生成（检索结果作为上下文，LLM 生成回答）。
关键点：分块粒度影响检索精度，太大太小都不好。实际项目中先用混合检索（BM25 + 向量）打稳主线，再按 bad case 决定要不要加 Rerank。
Q：BM25 和向量检索各自的优缺点？
BM25 基于词频统计，擅长精确关键词匹配，对术语、代码片段效果好，但不理解语义。向量检索基于语义相似度，能匹配同义词和语义相近的表述，但对精确术语匹配可能不如 BM25。最佳实践：两者结合，用 RRF 融合排序。
Q：Rerank 和 Embedding 检索有什么区别？
Embedding 检索是 Bi-Encoder：query 和 document 分别编码，然后比较向量相似度，速度快但精度有限。Rerank 是 Cross-Encoder：把 query 和 document 拼在一起过一个模型，精度高但速度慢。所以实践中先用 Embedding 粗筛 Top-50，再用 Rerank 精排 Top-5。
Agent
Q：ReAct 模式是什么？
ReAct = Reasoning + Acting。Agent 每一步先推理（Thought：我需要做什么），再执行（Action：调用工具），最后观察（Observation：工具返回结果），循环直到任务完成。和直接调工具相比，ReAct 的"推理"步骤让模型可以做多步规划。
Q：Tool Call 的执行者是谁？
应用层代码，不是模型。模型只是生成一个 JSON 指令（工具名 + 参数），应用层解析后执行对应的函数，把结果回传给模型。模型不直接接触网络、文件系统或数据库。
Q：Agent 的记忆管理怎么做？
分短期和长期。短期记忆：对话历史，用滑动窗口 + Token 预算控制，超过阈值时压缩历史（让 LLM 生成摘要）。长期记忆：用向量数据库存储从对话中提取的重要信息，按语义相似度检索相关记忆注入上下文。
微调概念
Q：LoRA 是什么？为什么用它而不是全量微调？
LoRA（Low-Rank Adaptation）：冻结原模型权重，在注意力层旁边插入低秩矩阵（rank 通常 8-64），只训练这些新参数。参数量从几十亿降到几百万，显存需求大幅降低。适合没有大量 GPU 资源的场景。
Q：SFT、RLHF、DPO、GRPO 分别解决什么问题？
- SFT（Supervised Fine-Tuning）：让模型学会特定任务格式和知识
- RLHF（Reinforcement Learning from Human Feedback）：让模型输出更符合人类偏好，用奖励模型 + PPO
- DPO（Direct Preference Optimization）：简化版 RLHF，不需要单独训练奖励模型，直接从偏好数据学习
- GRPO（Group Relative Policy Optimization）：DeepSeek 提出，用组内相对排序替代绝对奖励，训练更稳定
工程化
Q：怎么减少幻觉？
多管齐下：1. RAG 提供参考资料 + Prompt 限制"只从参考资料回答"。2. 低 temperature。3. 要求模型标注不确定信息。4. 输出后二次验证。5. 结构化输出（Zod Schema 约束）。没有银弹，实际项目中组合使用效果最好。
Q：Token 成本怎么控制？
四个方向：1. 选对模型（简单任务用小模型）。2. 控制输入长度（上下文压缩、裁剪历史）。3. 限制输出长度（maxTokens）。4. 语义缓存（相似问题命中缓存直接返回）。我们项目中语义缓存命中率 65%，日成本降低了 60%。
Q：显存怎么估算？
粗算公式：模型参数量 × 每参数字节数。FP16 下，7B 模型 ≈ 7 × 2 = 14GB。BF16 同理。INT8 量化后减半（7GB）。INT4 量化再减半（3.5GB）。还要加上 KV Cache 的显存（和序列长度×批量大小成正比）。推理场景可以量化到 INT8/INT4，训练必须用 FP16/BF16。
面试准备 Checklist
□ 项目描述准备好（3 分钟版 + 1 分钟版）
□ 每个技术决策能说清"为什么选它"
□ 关键数据记住（准确率、成本、延迟）
□ 已知问题和优化方向想清楚
□ 高频题过一遍，用自己项目举例
□ Demo 可以随时运行展示本课产物
- ✅ 项目 README 和简历描述
- ✅ 3 分钟架构讲解模板
- ✅ 高频面试题回答框架
- ✅ 面试准备 Checklist
面试追问
Q：你的项目和直接调 ChatGPT API 有什么区别？
三个层面：1. 检索增强——RAG 让回答基于真实数据，不依赖模型训练知识。2. 工具能力——Agent 可以执行文件操作、数据库查询等实际任务。3. 工程保障——重试、Fallback、监控、成本控制，是生产级的系统。直接调 API 只是一个聊天框，我的系统是一个可上线的产品。
Q：如果让你重新做这个项目，会怎么改？
如果数据量更大，会从本地优先的 SQLite 或课程里常见的 pgvector，升级到专门的向量数据库（Pinecone/Milvus）。如果对实时性要求高，会用流式输出 + 增量检索。如果要支持多用户，需要加权限隔离和多租户支持。另外会花更多时间在评测体系上，建标注数据集和自动化回归测试。