大模型应用开发工程师模拟面试笔记

Q1：请先用 1-2 分钟简单介绍一下你自己。

候选人回答：
Hi, I'm Fang Qidong. I hold a master's degree in Software Engineering from Henan University, and I've been working in backend development for six years, with the last three focused on LLM applications.

📖 参考回答（中文）：

面试官好，我叫方启东，硕士毕业于河南大学软件工程专业，6 年后端研发经验，近 3 年专注 LLM 应用开发。

过去在清华同方期间，我主要做了三件事：一是基于 LangChain + Milvus 搭建了供热行业 RAG 知识库问答系统；二是用 LangGraph 设计并落地了 AI Agent，覆盖故障诊断、数据查询等场景；三是对 Qwen 系列模型做过 LoRA 微调，并用 vLLM 部署上线。此外还主导开发了一套低代码 AI Agent 平台。

一句话总结：有后端工程的底子，也有 RAG、Agent、微调的全链路实战经验。

点评：
英文表达流畅，结构清晰。如果能补充中文版本给国内面试官会更稳妥。另外可以加一句"想要什么"——展示明确的职业动机。

---

Q2：假设你现在要搭建一个供热行业的 RAG 问答系统，第一步你会做什么？

候选人回答：
了解相关技术现状，再选型。最后开始文档数据处理 — 解析 — 分块。

📖 参考回答：

第一步不是写代码，而是做两件事：

第一，明确业务边界。 跟业务方对齐：知识库覆盖哪些文档？用户问什么问题（故障咨询/政策查询/数据查询）？期望的回答质量指标是什么（准确率目标、响应时间要求）？

第二，技术选型验证。 带着业务需求去选型：Embedding 模型选哪个（bge / m3e 还是调用 API）、向量库选哪个（Milvus / pgvector / ES）、LLM 选哪个（Qwen / DeepSeek）、部署方式（自建还是 API）。选型依据不是"哪个热门"，而是"哪个匹配我们的场景和数据量"。

这两步确定后才开始搭流水线：文档解析 → 分块 → Embedding → 入库。

追问意图：
考察候选人是否一上来就写代码。有经验的工程师会先做需求对齐和技术验证，而不是直接开干。

---

Q3：选 Embedding 模型时，你会在哪些模型之间做对比？最终选型的决定因素是什么？

候选人回答：
主要看维度、领域能力、多语言支持、成本以及能接受的长度。

📖 参考回答：

我会拉 3-4 个候选模型来做对比实验，比如 bge-large-zh-v1.5、m3e-large、text-embedding-3-small。

选型决策因素按优先级排序：

1. 领域召回率（Recall@5） — 用我们供热领域 200 条测试 Query 实测对比，哪个模型在专业术语上的召回率高就选哪个。这是核心指标。
2. 部署方式与延迟 — 能否自建？自建延时 5ms 级别，API 调用 200ms+，直接影响系统 P99 延迟。
3. 成本 — 自建一次性投入，API 按量付费。日调用量超过一定阈值后自建更划算。
4. 维度 — 768 维是黄金平衡点，不是越高越好。维度太高有"维度灾难"问题。

最终我们在项目中选了 bge-large-zh-v1.5，因为它在中文领域术语上的 Recall@5 比第二名高 3-5 个百分点，且可以用 TEI 自建服务，延时可控、数据不出网。

追问意图：
考察候选人是否有实际对比选型经验，还是只停留在看文档列维度的层面。"用数据做决策"和"列参数清单"是两回事。

---

Q4：Embedding 质量和检索效果、Recall 之间是什么关系？

注：此题是候选人反问面试官，但面试经典问题，故收录。

📖 参考回答：

核心一句话：Embedding 模型决定了 RAG 检索的天花板。

环节	作用	上限决定者
Embedding	将文本编码为语义向量，决定"哪些内容在语义上是相近的"	✅ Embedding 模型质量
向量检索（HNSW/IVF）	在向量空间中快速找到最近邻	❌ 只决定速度和精度，不能找回 Embedding 漏掉的内容
Re-ranker	对召回结果精排	❌ 只能排序，不能创造新的召回
LLM 生成	基于召回结果生成回答	❌ 只能基于已有信息回答

具体影响：

• 好的 Embedding 能理解"供温 = 供水温度"，差的 Embedding 当成两回事 — 直接影响 Recall
• 768 维是当前中文场景的黄金平衡点（信息量够、检索快）
• Embedding 质量差导致的漏召回，后续重排序和 LLM 生成环节无法补救

---

Q5：你怎么确定 Chunk Size？有没有通用的方法找到最优值？

候选人回答：
不存在全局通用固定值，只能结合"文档类型 + 嵌入模型 + 向量库 + 业务场景"量化寻优。

📖 参考回答：

没有万能值，我的方法是控制变量实验：

1. 固定 Embedding 模型（bge-large-zh）和检索方式（余弦 + HNSW）
2. 设置多组 Chunk Size：[256, 512, 768, 1024]
3. 每组配合不同的 Overlap：[0, 64, 128]
4. 在 200 条标注 Query 上跑 Recall@5

实验结果：

• Chunk 256：Recall 87% — 信息碎片化，语义不完整
• Chunk 512 + Overlap 128：Recall 92% — 最优
• Chunk 768：Recall 90% — 噪声增多，定位不准
• Chunk 1024：Recall 86% — 每个块包含多个主题，精度下降

结论：用数据说话，而不是拍脑袋。

追问意图：
考察候选人有没有真正动手调过参数，还是停留在理论上。"量化寻优"四个字谁都会说，能说出来具体做了几组实验、结果怎么样的才是真做过。

---

Q6：你怎么保证 LLM 正确使用了检索到的信息？如果 LLM 忽略上下文自己凭记忆回答，怎么处理？

候选人回答：
提示词强约束 + 输出强引用，两个方向。

📖 参考回答：

两层的解决方案：

第一层：Prompt 层强约束。

你必须严格基于以下资料回答问题。
如果资料中有相关信息，用【资料 X】标出来源。
如果资料中没有相关信息，直接说"知识库中暂未收录"，不要自行推断。

并配上 few-shot 示例：分别展示"有资料时怎么答"和"没资料时怎么说"。

第二层：输出层强制校验。
正则提取回答中的引用标记，跟实际检索结果 ID 列表做交叉校验：

• 引用标记指向不存在的资料 → 不合格，重新生成
• 关键事实信息没有引用来源 → 不合格，重新生成
• 重试上限 3 次，仍不合格就降级返回检索原文

效果：LLM 忽略检索内容的比例从 ~15% 降到 3% 以下。

追问意图：
考察候选人是否有系统性的幻觉防控手段，还是只停留在"写个 Prompt 告诉他别瞎编"的层面。输出层主动校验是关键分水岭。

---

Q7：你的故障诊断 Agent 怎么判断该查哪个数据、调哪个工具？用户说"暖气不热"，Agent 应该先问还是先查？

候选人回答：
通过意图识别路由到对应业务域，再决策工具调用。先问用户基础信息，再去查询数据。

📖 参考回答：

具体分三步：

第一步：意图分类。 用 LLM + few-shot 将用户 Query 分类到业务域：故障诊断 / 政策咨询 / 数据查询。"暖气不热"走故障诊断域。

第二步：信息完整性检查。 故障诊断域需要三个字段：地址、户号、故障现象。用户一次说全了就直接查；缺信息就反问："请问您的地址和户号是？"

第三步：分步工具调用（DAG 编排）。 信息收齐后，按编排依次调用：

查换热站实时数据 → 查历史工单 → 查知识库 → 综合分析输出

每个工具结果写进 State，下一个节点直接引用。

关键设计：Agent 不问完所有信息再查，而是问一个、查一个、推进一步——对用户更友好，上下文窗口也更可控。

追问意图：
考察候选人对 Agent 工作流的理解深度。简单的"先问再查"谁都会说，真正的设计在于问什么、查什么、判断信息是否完整、每一步的结果如何传递给下一步。

---

Q8：5000 条供热故障工单数据，用 LoRA 微调 Qwen-7B 来做工单分类，训练数据怎么做？注意什么？

候选人回答：
训练数据处理打标分类，对基模型最后一层改成分类层，而不是对话文本输出。

📖 参考回答：

工单分类是 Sequence Classification 任务，跟 Chat 微调不一样：

1. 数据打标。 按业务类别人工标注（设备故障 / 用户操作不当 / 外部原因 / 其他）。

2. 数据格式化。 每条数据为 {"text": "工单内容", "label": 0}，不是 Alpaca 指令格式。

3. 模型改造。 加载 Qwen-7B 时设 num_labels=4，框架自动将 LM Head 替换为 Linear 分类头。这个分类头随机初始化，需要全量训练。

4. LoRA + 分类头双学习率。 LoRA 加在 Attention 层（q_proj, v_proj），分类头不做 LoRA。LoRA 用 lr=1e-4，分类头用 lr=5e-4（从头学，需要更快收敛）。

5. 评估。 看 Accuracy / F1 / Confusion Matrix，重点分析易混淆类别。

关键注意：不要用对话格式训分类任务。分类头随机初始化，需要足够多的 epoch 才能收敛。

追问意图：
考察候选人是否理解不同任务需要不同的微调策略。"最后一层改成分类层"说起来简单，但 LoRA + 改分类头如何配合、数据格式怎么设计、学习率怎么设，才是区分有没有真正做过的分水岭。

---

Q9：从你目前的技术栈来看，未来 1-2 年你最应该补什么能力？

候选人回答：
提升架构设计能力。

📖 参考回答：

具体来说三个方向：

第一，大规模系统设计。 能做好一个 RAG 系统，但百万 QPS、多机房容灾、跨国部署的 AI 系统还没做过。计划通过读 DDIA、拆解开源系统架构（Milvus 查询引擎 / vLLM 调度层）、主动承担跨模块方案设计来补。

第二，从"功能设计"到"成本设计"。 现在更多考虑能不能跑通，下一步要在方案阶段估算 GPU 成本、Token 消耗、带宽开销，在架构层面做取舍。

第三，技术决策书面化。 把复杂方案画成清晰的架构图、写成可执行的 Design Doc，让团队其他人能接着干。现在输出还不够系统。

一句话：从能做好一个模块，到能设计一整套系统，再到能让团队跟着你把系统建出来。

追问意图：
考察候选人是否有清晰的成长规划。"架构设计"谁都会说，能展开说到具体怎么补、补什么、优先级的，才是认真思考过的。

---

面试总结

整体评价

维度	等级	评语
RAG 知识	⭐⭐⭐⭐	有实操细节，分块策略、Embedding 选型、评估方法都有真实经验
Agent 架构	⭐⭐⭐⭐	框架理解到位，多轮对话和工具调用设计有深度
模型微调	⭐⭐⭐	对话微调熟悉，分类微调需要补充常见做法
架构视野	⭐⭐⭐	有意识但缺少系统性的大规模系统设计经验
表达风格	⭐⭐⭐	回答偏短，容易被追问拉出细节，建议主动用"三层结构"展开

核心改进建议

1. 回答结构：不要只给结论，用"是什么 → 怎么做的 → 数据验证"三层展开。面试官想听的是过程，不是大纲。
2. 用数据说话：你的项目经验是真的，那就把数据拿出来（Recall 92%、准确率 88%、延迟 3s）。有数据支撑的回答和没数据的回答，可信度差一个等级。
3. 主动展示边界感：知道什么该做、什么不该做。比如微调 vs RAG 的选型逻辑、Agent 工具调用的权限控制，这些"边界判断"是高级工程师的标志。