说明
底本为 Language Models Interview Handbook（© 2026 Lamhot Siagian, AI Engineering Insider）；个人学习整理，转载请注明出处，勿用于商业再发行。
第 16 章 架构、扩展与实务部署
本章概述
团队进入生产阶段后，讨论不再只围绕提示与基座模型。必须决定稀疏专家路由是否值得运维复杂度，结构化知识是否应由检索之外的方式补充，如何负责任地调超参，以及如何在真实负载下管理偏见、隐私、可解释性与成本。这些话题区分扎实原型与可长期演进的系统。
本章汇集资深面试里常见、且迫使候选人把模型架构连到产品治理的概念：混合专家（MoE）带来的稀疏扩展、结构化知识增强、跨模型生态的实务比较，以及部署前沿系统的运维现实。
Interview Anchor 面试锚点
| 维度 | 内容 |
|---|---|
| 面试官真正想测的 | 能否把前沿模型选择与生产中的治理、隐私、偏见、评估与运维约束连起来。 |
| 高质量回答套路 | 比较架构选项 → 说明其运维价值 → 再解释它带来哪些新的评估与治理负担。 |
| 常见低分答法 | 把部署讨论做成只谈算力；成熟回答会包含访问控制、可审计性、隐私与人工升级路径。 |
INTERVIEW CHEATSHEET 面试速记条
| 项 | 要点 |
|---|---|
| 要表达的亮点 | 生产成功依赖全栈：架构、质控、安全、隐私与运维治理。 |
| 最佳举例 | 模型基准很好看，仍可能因权限、新鲜度或升级规则设计差而在生产失败。 |
| 可追问方向 | 提到 MoE 路由、知识图谱、超参、偏见评估与隐私控制。 |
| 资深补充 | 区分研究新颖性与可部署性。 |
| 切忌这样说 | 假设最大或最新架构自动等于最佳生产选择。 |
下面的部署—治理矩阵旨在把生产就绪说清楚：把架构决策与策略、监控、事故响应与组织归属绑在一起。
表 16.1（A deployment governance matrix for real-world LLM systems）
| 领域 | 示例控制 | 为何重要 |
|---|---|---|
| 隐私 | 脱敏、访问控制、数据最小化 | 当提示或检索上下文含敏感数据时，限制泄露风险 |
| 质量 | 回归集与场景测试 | 在用户大量吸收失败之前发现漂移 |
| 安全 | 审核、拒绝路径、人工升级 | 降低来自不应支持或不安全行为的伤害 |
| 运维 | 日志、追踪、回滚、版本管理 | 让故障可诊断，而不是一团迷雾 |
What Strong Candidates Sound Like
书里有一句可背的口述（译文）：「最难的部署问题往往是跨层问题——检索、权限、评估与模型行为会一起失效，而不是一次只坏一层。」
问答（沿用书中编号 Q142–Q151）
Q142. 什么是混合专家（MoE）模型，为何有吸引力？
答。 混合专家（MoE）包含多个专家子网络与路由机制，对每个词元或样本只激活其中一部分。这形成稀疏架构：总参数量可以很大，但每步实际用到的算力远小于「所有参数每步都激活」的稠密情况。
面试官喜欢这个话题，因为它抓住一种核心扩展思路：在不付满额稠密算力的前提下增大容量。Switch Transformers 在大规模训练里让这种权衡尤其有影响（Fedus et al., 2022）。
Q143. MoE 系统会引入哪些新的失效模式？
答。 稀疏路由带来自有风险：有的专家可能过载，有的闲置；若路由器塌缩到少数专家，训练可能不稳定；调试也更难，因为质量回退可能反映路由行为，而不只是基座模型质量。
强答应说：MoE 用条件容量换稠密简单性——可以非常高效，但需要仔细的负载均衡、路由诊断与服务感知的基础设施。
Q144. 知识图谱如何补充语言模型？
答。 知识图谱以结构化形式表示实体及其关系。它们可通过提供显式事实约束、更干净的实体链接，以及有时难以仅从非结构化文本恢复的多跳关系推理，来补充 LLM。
实务上，当产品依赖稳定实体与关系（商品、人员、法规、科学概念或企业资产等），且可追溯性与流畅度同样重要时，知识图谱帮助最大。
Q145. 何时知识图谱比纯向量检索更有用？
答。 向量检索擅长文本上的语义相似，但当任务依赖显式图结构时可能吃力：父子层级、所有权链、类型化关系或多跳约束。当答案不仅取决于找到相关段落，还取决于实体间结构化链接的导航时，知识图谱更有用。
最强的面试回答是比较式而非意识形态化：许多强系统两者都用——向量检索做广域证据发现，图推理做实体锚定的逻辑。
Q146. 什么是自适应 softmax，何时有用？
答。 自适应 softmax通过对罕见词比常见词花更少算力，来加速超大词表训练。它把词表组织成簇，使模型能廉价地评估常见词元，同时仍支持很大的整体词表。
这在大词表设定下最重要——此时输出层会成为计算瓶颈。面试准备里它不如注意力或 LoRA 显眼，但却是系统效率与模型数学深度交织的好例子。
Q147. Claude 式与 GPT 式生态对开发者常见差异是什么？
答。 最稳妥的面试回答是：两者都提供前沿语言模型，但常在打包方式、产品默认、工具接口、上下文窗口选项与周边平台人体工学上不同。实务里开发者更少按品牌身份比较，更多按任务契合度：推理质量、工具使用、延迟、上下文处理、定价、安全控制与部署约束。
好的回答保持随版本更新的意识，避免把假设写死。正确比较通常是经验性的：在你的工作负载、提示与延迟预算上实测候选模型，而不是依赖品牌层面的传闻。
Q148. 为何超参数不止学习率重要？
答。 超参数控制的远不止是优化速度。批量大小影响梯度噪声与硬件效率；权重衰减影响泛化；序列长度改变内存压力；解码参数改变输出质量；在真实 LLM 系统里，检索设置、重排序深度与切块大小也是运维型超参。
面试里要体现广义思维：超参数是工程师设定而非模型学到的任何旋钮。好团队把它们当作系统设计的一部分，而不是训练结束时的事后补丁。
Q149. 如何应对有偏见或系统性错误的输出？
答。 先把失败具体化：哪些群体、主题或场景出现系统性问题。再在合适层级改进栈：更好的数据策展、更强的评估集、检索约束、校准过的拒绝、生成后校验，或针对性微调。一张万能膏药很少解决所有偏见或准确率问题。
强答应包含度量：团队需要分组评估、有代表性的边界案例，以及清晰的升级政策；否则「修复偏见」只是口号，而不是工程流程。
Q150. 为何可解释性与隐私在 LLM 部署里很难？
答。 可解释性难在大神经网络并不暴露人类可读规则来解释回答为何出现。隐私难在模型可能被要求处理敏感数据、检索机密文档，或调用在受保护系统上操作的工具。两者结合形成棘手的治理挑战：需要可见性与可审计性，又不能不必要地暴露更多数据。
面试里要把隐私连到架构：访问控制、数据最小化、日志政策、保留与脱敏策略既是产品决策，也是模型决策。
Q151. 团队最常低估哪些部署瓶颈？
答。 团队常低估评估维护、提示与模型版本漂移、访问控制复杂度、长尾延迟，以及排查横跨检索、工具与模型行为的失败所需的人力成本。算力成本重要，但运维模糊性往往更痛。
最强的面试回答是诚实且系统级的：生产 LLM 难在质量依赖全链路；笔记本里看起来很棒的模型，一旦真实文档、真实权限与真实用户进入闭环，仍可能失败。