> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# AI工程师面试必备的10个问题
- URL: https://www.hubwiz.com/blog/top10-interview-questions-for-ai-engineers/
- Published: 2026-04-29T11:20:49.000Z
- Updated: 2026-04-29T11:20:49.000Z
- Description: 我第一次 AI 工程师面试失败了。这是我为了不再失败而构建的完整攻略。
- Author: admin
- Tags: JOB MARKET, #Import 2026-10-14 14:41

那封邮件在一个周二的晚上 11:43 到达。

> "感谢您抽出时间参加我们的面试。经过慎重考虑，我们决定继续推进其他候选人的流程…"

我盯着笔记本电脑屏幕看了很久。蓝色的光芒仿佛在指责我。

那是一场为期 90 分钟的技术面试，面向一家我花了三年时间想去工作的公司的高级 AI 工程师职位。我曾经交付过 LLM 功能，写过 RAG 管道，在生产环境中使用过向量数据库、嵌入和提示工程。从简历上看，我是合格的。

但在"告诉我你如何处理 LLM 中的幻觉？"和"设计一个每天处理 10,000 份文档的系统"这两个问题之间，我崩溃了。

不是因为我不知道这些概念。我大部分都知道，但可以说是比较松散的。就像大多数读过几篇博客文章、交付过几个演示的工程师那样"知道"一些东西。

但是，知道关于某件事的信息，与能够在压力下实时构建一个生产级解决方案——而一个以此为生的面试官正在看着你——是完全不同的两种能力。

那天晚上，我开始构建一些东西。一份我认为是个人攻略的文档。对我曾经答错的每一个难题的残酷而全面的回答。

接下来就是那份攻略。它很长。这是刻意的。每个部分都告诉你面试官真正在寻找什么，完整的技术答案，以及将拿到 offer 的候选人与收到礼貌拒绝邮件的候选人区分开来的那一个关键点。

## 开始之前：这篇文章是什么，不是什么

这不是一份速查表。

如果你把下面的每个部分当作要逐字背诵的要点来读，你会以和我完全相同的方式在面试中失败。问这些问题的面试官已经听过数百个排练过的答案。他们知道排练过的答案听起来是什么样子——大概自信 90 秒钟，然后在一个追问深入一层时就崩塌了。

这篇文章是：一个*理解*定义生产环境中 AI 工程的十个难题的框架。如果你理解了这些问题——我说的真正理解，就像你理解为什么数据库索引有效、为什么无状态服务更容易扩展那样——那么你就可以回答这些问题的任何变体，处理面试官的任何追问，并根据面试官带来的具体情境调整或重新表述你的答案。

我将每个部分以相同的方式结构化：

- **问题**以及为什么面试官会问（他们真正在测试什么）
- **完整的技术答案**，基于真实的生产经验构建
- **面试杀手锏 →** 将拿到 offer 的候选人与被拒的候选人区分开来的那一个关键点

### 现状：2025 年成为"AI 工程师"意味着什么

在我们深入十个问题之前，让我们先认同一个令人不安的事实：

"AI 工程师"这个头衔已经被稀释到几乎毫无意义的地步。

有些 AI 工程师几乎无法解释 Transformer 和循环网络的区别。有些 AI 工程师没有交付过任何生产系统。有些 AI 工程师的全部技能就是："写一个提示，调用 OpenAI API，然后祈祷一切顺利。"

而另一些 AI 工程师能够系统性地思考，能够同时推理成本、可靠性、延迟、安全性和质量。他们在凌晨 2 点调试过生产故障，因为他们的嵌入模型在提供商更新后开始表现不同。他们可以在餐巾纸上算出成本，设计一个每天处理 10,000 份文档的摘要管道。

面试官正在试图找到第二种人。这十个问题就是他们的工具。

让我们逐一来看——不是作为要记忆的要点，而是作为需要深入理解的问题，我建议你在回答时重新表述或加入自己的思考。

## 问题 01 · 嵌入与向量搜索

**"你之前使用过嵌入吗？你是如何选择合适的模型的，你遇到了哪些扩展问题？"**

嵌入是现代 AI 系统如 RAG、语义搜索、推荐系统、异常检测的骨干。如果你正在构建任何需要理解*含义*（而不仅仅是匹配关键词）的东西，你就需要嵌入。

记住以下步骤：

![None](https://www.hubwiz.com/blog/content/images/2026/04/1-FMVJgnjz-wYzt_bMGi0O2Q.png)

**为什么他们问这个问题：** 嵌入是从搜索到推荐再到 RAG 的现代 AI 系统的基础。对嵌入的深入理解表明你有扎实的基础。

**它们是什么：**

嵌入是数据的稠密向量表示——文本、图像、音频——其中语义上相似的项目在向量空间中彼此接近。模型不只是编码 token；它编码*含义*。"King" 比 "Bicycle" 更接近 "Queen"，不是因为它拼写的相似性，而是因为语义关系。

**它们如何工作：**

神经网络将输入文本映射到一个固定大小的向量——通常是 `text-embedding-3-small` 的 1,536 维，大变体的 3,072 维。然后你使用余弦相似度或点积来衡量两个向量之间的语义相似度。

**生产用例：**

- **语义搜索**：按含义而非关键词匹配查找文档。搜索"cardiac arrest"可以返回关于"heart attack"的结果，无需任何关键词重叠。
- **RAG 检索**：每个 RAG 系统中的核心检索机制。
- **重复检测**：将几乎相同的内容聚类，即使措辞不同。
- **推荐引擎**：推荐相似的产品、文章或内容。
- **聚类和主题建模**：按主题分组文档，无需预定义标签。
- **异常检测**：识别在语义上远离预期分布的异常查询或文档。

**选择模型：**

考虑因素：维度（越高 = 表达能力越强，但速度越慢、价格越高）、领域适配（通用模型 vs. 在法律、医学或技术文本上微调的领域专用模型）、多语言支持和成本。始终在*你自己的*数据上进行基准测试——MTEB 排行榜排名不能告诉你一个模型在你特定领域的表现。

**扩展考量：**

在几十万个向量规模下，精确搜索没问题。超过这个规模，精确最近邻搜索就太慢了。你需要近似最近邻（ANN）算法——HNSW（层次可导航小世界）或 IVF（倒排文件索引）。根据你的召回率/延迟权衡选择正确的索引类型。Pinecone、Weaviate、Qdrant 和 pgvector 都提供可配置的索引。

**面试杀手锏：** 如果是白板面试，画出管道流程：Query → Embed → ANN Search → Top-K → Re-rank → Generate。管道的可视化沟通是一个真正的差异化优势。

## 问题 02 — RAG

**"你设计过 RAG 吗？能带我们走一遍 RAG 的完整流程吗？在构建 RAG 管道时你遇到过什么挑战？"**

![None](https://www.hubwiz.com/blog/content/images/2026/04/1-a3vm-G24Zn5CW88lc7Tz8Q.png)

图 1\. 完整的 RAG 管道——离线索引构建（底部）和在线查询处理（顶部），从文档摄入到评估

我还制作了下面的图表来澄清概念：

![None](https://www.hubwiz.com/blog/content/images/2026/04/1-pT0yT_A3t5f3wYUv8dTALA-1.png)

图 2：与图 1 相同，只是更清晰

RAG 是现代应用 AI 的架构模式。如果你声称自己是 AI 工程师，却无法端到端地设计一个生产级 RAG 系统，你就有严重的信誉问题。

**为什么他们问这个问题：** RAG 是生产环境中最常见的 LLM 架构模式。如果你不能端到端地设计一个，你在任何应用 AI 角色中都会遇到困难。

我构建的第一个 RAG 系统有六个组件。我们现在运行的生产版本有十五个。以下是从简单到生产级的完整路径：

![None](https://www.hubwiz.com/blog/content/images/2026/04/1-JOJBGx1p6XF7mDI2GU2rRA.png)

问题 2 的回答框架——生产 RAG 管道的五个阶段，突出显示了大多数候选人跳过的步骤

**阶段 1：文档摄入**

解析源文档，如 PDF、HTML、数据库、Markdown。清理文本：去除页眉/页脚，规范化空格，移除伪影。然后分块：拆分为语义上连贯的片段。

分块大小非常重要。太小：你丢失上下文。太大：你稀释相关性。经验验证的最佳范围通常是 200-500 个 token，带重叠（这样不会在分块边界处截断信息）。

**阶段 2：嵌入与索引**

使用 `text-embedding-3-small`（OpenAI）或开源替代方案等模型嵌入每个分块。将嵌入存储在带有元数据的向量数据库中——文档 ID、来源、日期、章节标题——以便在查询时进行过滤。

模型选择很重要：考虑维度（越高 = 表达能力越强但速度越慢）、领域适配（通用 vs. 领域专用）、多语言支持和成本。在*你自己的*数据上进行基准测试，而不是 MTEB 排行榜分数。

**阶段 3：检索**

在查询时，嵌入用户的问题并执行相似度搜索——余弦或点积。检索 top-k 分块。

这就是大多数简单实现停止的地方。生产系统增加：**混合搜索**（将向量相似度与 BM25 关键词匹配结合）。这可以捕获精确术语（产品名称、型号、专有名词）比语义相似度更重要的情况。

**阶段 4：重排序** ← *大多数候选人跳过的步骤*

原始检索是不够的。使用交叉编码器重排序器（Cohere Rerank、BGE reranker）对 top-k 分块针对问题的实际相关性重新打分。交叉编码器同时关注查询和文档，这大大提高了精确度。

这是将基础 RAG 与生产质量 RAG 区分开来的唯一最重要的步骤。

**阶段 5：生成**

将重排序后的上下文 + 用户查询输入 LLM，配上精心设计的系统提示：*仅从提供的上下文中回答，引用来源，如果答案不存在，明确说明。* 在输出中包含来源归属。

**阶段 6：评估循环**

衡量检索召回率（正确的分块是否被检索到？）、答案忠实度（答案是否与来源匹配？）和答案相关性。使用 RAGAS 等框架或自定义评估套件。

**需要了解的常见 RAG 失败模式**

在正常路径之外，生产 RAG 系统会以可预测的方式失败，面试官有时会探究这些问题：

*检索失败*：正确的分块存在于数据库中但没有被检索到——因为查询嵌入和文档嵌入即使在语义上相关，也没有在向量空间中靠近。这就是为什么混合搜索（向量 + BM25）很重要，以及为什么重排序不是可选的。

*上下文污染*：在长对话中，上下文窗口被来自较早轮次的、不再相关的检索分块填满，挤掉了当前问题的正确分块。上下文管理——修剪过时的检索内容——是一个真正的生产关注点。

*分块边界失败*：一个句子从一个分块开始，在另一个分块结束。没有重叠策略，模型看到的是不完整的想法。分块边界处的重叠（50-100 个 token 重叠）是标准的缓解措施。

*元数据过滤 bug*：如果你的向量存储按元数据（日期、类别、用户 ID）过滤，而该元数据是错误的或填充不一致，你会默默地检索到不相关的结果，没有明显的错误信号。

**面试杀手锏：** 重排序步骤是你的差异化优势。大多数候选人会跳过它。将它作为一个独立阶段提及，立即表明你具有生产经验。

## 问题 03 — LLM 幻觉

**"你在实际系统中处理过幻觉吗？你采取了哪些防御层？"**

这几乎总是第一个问题。也是大多数工程师犯第一个错误的地方：他们把它当作一个关于模型的问题。

不是的。

这是一个关于*架构*的问题。

**为什么他们问这个问题：** 幻觉是公司不信任生产 AI 系统的首要原因。如果你正在构建任何面向客户的东西，你需要知道如何阻止模型自信地编造信息。面试官想看到你是否理解这是一个工程问题，而不是模型问题。

我交付第一个面向客户的 LLM 功能的那年夏天，我们收到了一个工单：*"你们的 AI 告诉我订单退货窗口是 60 天。实际上是 30 天。我要退款。"*

模型的错误不是以一种愚蠢的方式出现的。它以一种自信、流畅、完全可信的方式出错。这就是幻觉真正危险的地方。模型以非常自信的方式给出答案，甚至不给你怀疑的机会。

以下是你如何构建一个防御它的系统：

![None](https://www.hubwiz.com/blog/content/images/2026/04/1-HJowjJIbXeG3gcWOx2cMKA.png)

**第 1 层：检索增强生成（RAG）**

AI 领域最基础的防御——不是让模型从其参数记忆（训练时烘焙进去的权重）中回答，而是强制它从你控制的一组特定文档中回答。

模型从你的向量存储（Pinecone、Weaviate、pgvector、Qdrant）中检索相关的分块，你的系统提示指示它：*仅从提供的上下文中回答。如果答案不在这里，就说"我不知道"。*

这并不能完全消除幻觉——模型仍然可能误读上下文、错误归因引用或混淆分块——但它大大减少了编造。

**第 2 层：思维链/逐步推理**

当你强制模型在得出结论之前展示其推理过程时，你就从结构上降低了产生自信但毫无根据答案的概率。一个逐步推理的模型不太可能直接跳到一个听起来合理的谎言。

你可以通过提示（"在回答之前一步一步地思考"）或通过要求模型在填充 `answer` 字段之前先填充 `reasoning` 字段的结构化输出 schema 来强制执行这一点。

**第 3 层：输出验证与防护栏**

生成后的检查。你可以使用：

- 针对源文档的事实核查：答案的声明是否出现在检索到的上下文中？
- 标记"不受支持"声明的 NLI 分类器（微调用于检测蕴含 vs. 矛盾的模型）
- 专门用于验证的二次模型调用

**第 4 层：约束解码**

如果你的答案空间是有界的——仅是/否、五个类别之一、一个结构化的 JSON 对象——不要让模型自由生成。始终使用函数调用或结构化输出 schema。你给模型的自由度越少，它出错的方式就越少——请谨慎。

**第 5 层：置信度校准**

使用对数概率或自一致性采样。生成多个输出，寻找共识。如果模型的输出高度不一致，那就是模型不确定的信号。构建一个"弃权"路径：*"我没有足够的信息来可靠地回答这个问题。"*

**面试杀手锏：** 提到你将 RAG *和* 输出验证结合为分层防御。最成熟的候选人会说：*"没有单一技术是足够的。生产系统需要像安全一样的纵深防御。"*

将此作为你的心智模型：

![None](https://www.hubwiz.com/blog/content/images/2026/04/1-ajDtgLDiNyoHojMD7TGfhQ.png)

![None](https://www.hubwiz.com/blog/content/images/2026/04/1-OTBPxsGMkSUDgvvtB3Dw_Q.png)

图 3：幻觉防御管道

## 问题 04 · 评估策略

**"你是如何衡量你的 LLM 功能在生产中是否真正运行良好的？"**

如果你不能衡量质量，你就不能改进它。这个问题是关于你是否围绕 AI 构建了严格的系统，还是只是在希望事情正常运行。

**为什么他们问这个问题：** 公司需要能够在交付前建立严格评估的工程师。"看起来不错"不是一个质量标准。

在解释之前，先记住这些要点。

![None](https://www.hubwiz.com/blog/content/images/2026/04/1-lYT7bhQhilMTX9kza5M_xg.png)

问题 4 的回答框架——五种评估方法，从自动化指标到人工审查，底部是面试就绪的一句话

**任务特定指标**

将指标与任务匹配：

- **分类**：准确率、F1、精确率/召回率
- **摘要**：ROUGE、BERT-Score
- **翻译**：BLEU、COMET
- **生成**：困惑度、连贯性分数

但要始终问：这个指标与用户真正关心的东西相关吗？在用户觉得无用的摘要上获得高 ROUGE 分数是毫无意义的。

**LLM-as-Judge**

使用更强的模型来评估较弱模型的输出，标准包括有用性、准确性、安全性和风格遵从性。这比人工评估更适合快速迭代循环。

关键是结构化的评分标准。模糊的提示如"给这个答案打 10 分"会产生不一致、有偏见的判断。相反：提供具体标准、好/坏输出的示例和思维链指令。这大大减少了评判者的方差。

**人工评估**

仍然是主观质量的黄金标准。与真实用户进行 A/B 测试。大规模的点赞/点踩。任务耗时指标。任务完成率。100 个真实用户的信号比任何自动化指标告诉你的都多。

**对抗测试**

有目的地红队你的模型。测试越狱、边缘情况、域外查询、对抗性提示。评估的不仅是模型是否回答得好，还有当它不知道答案时失败得有多优雅。

**回归测试**

这是将生产系统与演示区分开来的纪律：维护一套已知良好的输入/输出对测试集。每次更改提示、模型或管道时——在交付前重新运行测试套件。在回归影响到用户之前就捕获它们。

**面试杀手锏：** *"我使用 LLM-as-Judge 进行快速迭代循环，使用人工评估进行最终确认。这让我既拥有自动化评估的速度，又拥有人工判断的准确性。"*

## 问题 05 · 部署策略/生产调试

**"请介绍一个完整的模型部署策略？"**

**或者**

**"你的模型在生产环境中的表现是否曾与测试环境中不同？你是如何调试的？"**

> 追问 → 如果模型部署到生产后出了问题，你是如何规划的？

这个问题是一个陷阱，但以最好的方式来说。

每个只在 notebook 中运行过 LLM 实验的工程师都会错误地回答这个问题。他们会说类似"模型可能需要重新训练"然后就停在那里。

真正交付过生产系统的工程师会立即开始列出真正的罪魁祸首。

**为什么他们问这个问题：** 这表明你是否真正交付过。大多数初级工程师只在 notebook 中运行过模型。这个问题暴露了"我构建了一个演示"和"我运行生产系统"之间的差距。

*回答之前记住这些步骤：*

![None](https://www.hubwiz.com/blog/content/images/2026/04/1-LcXbok4hpdpkZkGVwzyDBw.png)

问题 5 的回答框架——你的模型在生产中是否曾与测试中表现不同？你是如何调试的？

我的模型第一次通过所有评估指标后立即在生产中退化的那次，我以为我有的是模型问题。其实不是。我同时有数据问题、提示问题、延迟问题和监控问题。

以下是完整的诊断框架：

**数据漂移**

生产数据永远不会与你的测试集完全相同。真实用户更加混乱。他们用俚语、错别字、不完整的句子输入。他们会问训练数据从未覆盖的边缘情况。他们以触发完全不同模型行为的方式表达事物。

解决方案：持续监控输入分布。设置漂移检测警报。跟踪你的测试分布和生产分布之间的统计距离。

**训练-测试泄漏**

如果你的测试性能异常好——好到令人怀疑——你可能意外地将训练数据泄漏到了评估集中。重新审查你的数据管道是否存在时间泄漏或重叠。这种情况令人尴尬地普遍，而且几乎没有人承认。

**评估不匹配**

你的离线指标（F1、BLEU、困惑度）可能与用户真正关心的东西不相关。一个在你的评估套件上得分 0.94 的模型可能用起来感觉很糟糕。

构建使用真实用户查询、真实用户反馈、与真实用户的 A/B 测试的评估套件。跟踪点赞/点踩、任务耗时、任务完成率。这些才是真正重要的指标。

**提示敏感性**

用户表达方式的微小变化可能产生截然不同的输出。你的测试提示可能是精心构造的。真实用户不是。生产提示被真实用户输入修改的方式可能完全改变模型的响应。

解决方案：对抗性提示测试。有目的地尝试破坏你的提示。看看它们在交付前有多脆弱。

**延迟与超时问题**

在测试条件下表现良好的模型可能在并发负载下触及速率限制、超时或降级。在现实流量模式——包括突发流量——下分析你的推理管道。

**上下文窗口溢出**

在生产中，对话随时间变长。如果你在没有管理策略的情况下填充上下文（聊天历史、检索文档、工具输出），当上下文窗口限制被达到时，你会默默地丢失信息。这导致响应质量下降，而且由于没有明确的错误，非常难以诊断。

**面试杀手锏：** 从监控框架开始：*"我会设置三层监控——输入分布跟踪、输出质量评分和用户反馈循环——然后系统性地缩小故障模式的范围。"*

## 问题 06 · 微调 vs 提示

**"你之前微调过模型吗？你是如何决定微调而不是提示的？"**

这是一个务实的权衡问题。错误的答案是："我会微调以获得更好的性能。"正确的答案是细致的、有成本意识的、基于真实决策的。

**为什么他们问这个问题：** 这测试你做出务实权衡决策的能力，可以说是应用 AI 工程中最重要的技能。

以下是我在多年做这个决策过程中建立的诚实决策框架：

**从提示工程开始。始终如此。**

和往常一样，解释时记住这些步骤：

![None](https://www.hubwiz.com/blog/content/images/2026/04/1-Njik0QY5GehL141pwvnEzA.png)

问题 6 的回答框架：你是如何做提示和微调的？

它更快。更便宜。可逆。少样本示例、思维链、结构化输出 schema、系统提示——这些工具以微调成本和时间的一小部分覆盖了 80% 的任务。如果你可以通过精心设计的提示获得所需的行为，那就是正确的答案。

**什么时候应该微调：**

- **你需要一致的输出格式或风格**，而提示无法可靠地强制执行。如果你需要每个响应都是特定的 JSON schema、特定的写作风格或特定的人设——而提示给你 85% 的一致性但你需要 99%——微调将行为烘焙到权重中。
- **你有一个狭窄的、定义明确的任务**，并有大量标注示例（数百到数千个高质量的输入/输出对）。分类、提取、转换——有明确正确答案的狭窄任务最能从微调中受益。
- **你需要减少延迟**，通过移除长系统提示。微调后的模型可以将其行为编码到权重中，因此你不需要在每次调用时发送 2,000 token 的系统提示。
- **你想将大模型的行为蒸馏到更小、更便宜的模型中。** 训练一个小模型在你的特定任务上模仿大模型的输出。

**什么时候不应该微调：**

- 你只有不到几百个高质量示例\* 你的任务频繁变化，重新训练昂贵且缓慢
- 你需要广泛的通用知识，在狭窄数据上微调会导致灾难性地遗忘其他一切
- 基础模型在正确的提示下已经表现良好

**混合方法**

最成熟的模式：在领域上微调基础模型（赋予其领域适配的语言和格式），然后在上面叠加 RAG 进行事实依据。你同时获得两者：来自微调的风格一致性，来自检索的事实准确性。

**面试杀手锏：** 展示成本-时间思维：*"在投入两周时间构建微调管道之前，我会先花一天时间做提示工程。迭代速度的差异是巨大的。"*

![None](https://www.hubwiz.com/blog/content/images/2026/04/1-C94h0obgJNZH2qPmc5WvdA.png)

![None](https://www.hubwiz.com/blog/content/images/2026/04/1-_PisFbGH4KoJ2Yd3kAxi7w.png)

图 4：提示工程 vs 微调决策

## 问题 07 · 成本降低策略

**"你如何评估成本，请介绍你的成本降低策略？"**

**或者**

**"你在生产中曾经需要削减 LLM API 成本吗？你实际上做了什么？"**

![None](https://www.hubwiz.com/blog/content/images/2026/04/1-V2O0clrGlBu23oJbzB_XYQ.png)

图 5：成本优化决策树——通过复杂度分类、模型选择、缓存、批处理和微调决策路由传入请求，以最小化 API 支出而不牺牲输出质量

图 5 说明：

- 流程从语义缓存检查开始，因此如果几乎相同的问题之前已经回答过，系统可以几乎零成本地立即返回响应。
- 如果查询是新的，它会按复杂度进行分类。简单的问题路由到一个小型、廉价的模型，而较难的推理任务只在必要时才路由到较大的模型。
- 非紧急工作负载会被批处理，让你可以一起处理许多请求，并利用批量 API 折扣将成本削减近一半。
- 在输出端，提示压缩和输出长度控制有助于消除不必要的 token，减少你为生成支付的费用而不影响质量。
- 最后，一个微调决策门评估任务是否足够狭窄和重复，以证明训练一个小型自定义模型是合理的。如果是的话，你可以完全移除系统提示，并为大批量用例解锁巨大的长期节省。

当这个问题出现时，你可能已经谈论了十分钟。好的面试官会在这里仔细观察，因为成本思维就是成熟度思维。

初级工程师会去使用最大的可用模型。高级工程师理解每个 token 都要花钱，而钱是一个真正的工程约束，不是 CFO 的问题。

**为什么他们问这个问题：** AI 很昂贵。公司不只是想要会构建的工程师，他们还想要*不会*在三个月内烧光计算预算的工程师。最小化预算——你需要学习并聚焦你回答的整个理念，让他们觉得应该雇佣你，而不是那个对理论和 Python 编程有良好理解的人。

在回答成本相关问题之前记住这些步骤：

![None](https://www.hubwiz.com/blog/content/images/2026/04/1-fkQdnVCe7sN_PTPZVXAZiA.png)

问题 7 成本降低策略的回答框架

你可以这样开始解释预算相关的内容——在我们那次幻觉事件六个月后，我们遇到了另一种问题：我们的月度 API 账单悄悄从 4,000 美元增长到 31,000 美元，没有人注意到。并尝试串联上下文，比如那时候我学到成本优化不是一个事后考虑的事情。它是你在开始时做出的架构决策。

以下是完整的工具包：

**模型选择与路由**

这是杠杆率最高的举措。原则：使用能够可靠处理任务的最小模型。

构建一个路由器，按复杂度对传入请求进行分类。简单查询如"你们的营业时间是什么？"路由到快速、廉价的模型（Haiku 级别或微调的小模型）。复杂的多步推理任务路由到大模型。别忘了解释——在我们的系统中，仅此一项就将成本降低了 60%，而用户满意度几乎不变。

**提示优化**

更短的提示 = 更少的输入 token = 更低的成本。无情地审查你的系统提示。移除冗余示例。精简指令。压缩少样本示例。你在规模上削减的每个 token 都是钱。

此外：使用提示缓存。大多数提供商现在对静态提示前缀提供缓存。如果你的系统提示是 2,000 个 token，而每次用户查询都重新发送它，那就是每次调用 2,000 个 token 的浪费。

**语义缓存**

不是为每个请求发起新的 API 调用，而是存储之前的响应，以嵌入相似度为键。当新查询到来时，检查是否已经回答过语义上近乎相同的问题。如果是，返回缓存的响应。

这在查询重复率高的领域尤其强大：客户支持、内部 FAQ、产品文档。

**批处理与异步处理**

不是所有事情都需要实时。将非紧急请求批处理，通过批量端点提交——大多数提供商以 50% 的折扣提供这些端点。摘要作业、分析、分类管道、隔夜处理——所有这些都可以批处理。

**为效率微调**

微调后的小模型通常可以在特定狭窄任务上以推理成本的一小部分胜过通用大模型。前期训练成本在规模上很快就能回本。微调还允许你去除长系统提示，因为模型的行为已经烘焙到权重中。

**输出长度控制**

适当设置 `max_tokens` 并使用结构化输出 schema 来获取你需要的精确内容。不要让模型在答案只需 200 个 token 时生成 2,000 个 token 的解释。

**面试杀手锏：** 量化。*"在我们的系统中，模型路由将 API 成本降低了 70%，同时保持了 95% 的输出质量。"* 面试官记住数字，因为数字表明你真正交付过这些东西。

## 问题 08 · Agent 与工具使用

**"你构建过使用外部工具的 Agent 吗？带我了解一下你是如何构建的，以及什么最先出问题了。"**

Agentic AI 是该领域的发展方向。设计不仅仅生成文本而是采取行动——调用 API、运行代码、查询数据库、发送电子邮件——的 Agent 的能力是目前商业价值最高的 AI 工程技能。

**为什么他们问这个问题：** Agentic AI 是应用 AI 中最大的趋势。公司正在构建可以采取真实行动的 Agent，而不仅仅是生成文本。这个问题测试你是否能够设计它们。

![None](https://www.hubwiz.com/blog/content/images/2026/04/1-gLcTshhVLcS3rFgwtoO6kA.png)

问题 8 的回答框架——Agent 与工具使用

**核心架构：观察 → 思考 → 行动**

Agent 是一个循环中的 LLM：

- **观察**：读取当前状态——输入、工具结果、记忆
- **思考**：推理下一步该做什么——调用哪个工具，用什么参数，还是直接响应
- **行动**：调用工具或生成最终响应

这个循环持续进行，直到 Agent 达到终止状态或最大迭代限制。

**工具定义**

工具使用清晰的名称、描述和参数的 JSON schema 来定义。工具描述的质量直接决定了模型使用它们的可靠性。把工具 schema 当作 API 文档来对待——它们需要精确、完整且无歧义。

**编排模式**

不同的任务需要不同的模式：

- **ReAct**（Reason + Act）：模型在每个动作之前逐步推理。适合探索性的多步任务。\* **先规划后执行**：模型先生成完整计划，然后执行每一步。更适合结构清晰的复杂任务。\* **Map-Reduce**：跨多个 Agent 实例并行化子任务。适合大规模处理。

**错误处理**

工具会失败。API 会超时。速率限制会触发。生产 Agent 需要：带有指数退避的重试逻辑、回退策略、优雅降级、最大迭代限制（防止无限循环）以及每一步的全面日志记录用于调试。

**安全与防护栏**

拥有真实世界工具访问权限的 Agent 是危险的。实施：权限系统（Agent 只能调用预先批准的工具，只能读取特定数据）、高风险操作的人工审批循环（发送电子邮件、进行购买、修改数据库）、沙箱执行环境以及任何工具调用执行前的输出验证。

**状态管理**

Agent 需要跟踪跨轮次的状态：调用了哪些工具，返回了什么结果，尝试了什么且失败了。这种状态管理在架构中经常被低估。两种方法：上下文内状态（将所有内容附加到上下文窗口——简单但昂贵）和外部状态（数据库中的结构化对象，由 Agent 引用——更复杂但可扩展且可检查）。

LangGraph 的显式状态图方法在这里非常出色：Agent 的状态是一个类型化的 Python 对象，流经图结构，使其可调试、可恢复且易于测试。

**一个真实的模式：研究 Agent**

为了具体化：想象一个回答关于公司内部数据问题的 Agent。循环如下：

- 用户提出问题- Agent 调用 `search_knowledge_base` 工具 → 获得 5 个结果
- Agent 推理："我需要更具体的数据" → 使用 SQL 查询调用 `query_database`\- Agent 推理："我有足够的上下文了" → 生成最终答案
- 输出防护栏检查答案中的 PII → 移除员工姓名- 响应返回给用户

力量和危险都在第 3 步。Agent 正在动态生成并执行 SQL。你需要沙箱执行、只读数据库权限、查询验证和结果大小限制，以防止 Agent 做出灾难性的事情。

**面试杀手锏：** 提及你使用过的具体框架——LangGraph、CrewAI 或自定义编排——并解释你*为什么*选择它。*"我选择 LangGraph 是因为显式状态图让我更好地控制执行流程，并且比基于隐式链的框架更容易调试。"* 这表明你具有真实世界的决策能力，而不仅仅是理论知识。

## 问题 09 · 大规模系统设计

**"你构建过或参与过大规模文档处理管道吗？在那个规模下你是如何考虑成本和可靠性的？"**

这个问题揭示了你是在用系统性思维思考还是只用 notebook 思考。

这不是关于模型的。这是关于围绕模型的基础设施、成本和可靠性。任何人都可以写一个调用 LLM 并总结文档的 Python 脚本。构建一个以合理成本、带质量保证地每天可靠处理 10,000 份文档的系统，是完全不同量级的问题。

**为什么他们问这个问题：** 系统设计问题测试你大规模思考的能力。这不是关于模型，而是关于它周围的一切。

![None](https://www.hubwiz.com/blog/content/images/2026/04/1-2qJWS-W2Dcoe8YrBM-DX3A.png)

问题 9 的回答框架——大规模系统设计

让我展示如何用信封背面的计算来组织你的答案——因为面试官会记住做计算的候选人。

**先做计算**

每天 10,000 份文档 × 每份 2,000 个 token = 每天 2000 万个 token

按批量 API 定价：大约每 100 万 token $0.30-$1.00 = 每天 $6-$20 的输入成本，加上输出。

这就是你设计的预算约束。

**架构**

```
Message Queue (SQS/Kafka)
→ Worker Pool
→ LLM API
→ Result Store (S3/DB)

```

文档进入队列。Worker 拉取文档，调用 LLM 进行摘要，存储结果。将摄入与处理解耦，这样两者都不会阻塞对方。

**分块策略**

超过上下文窗口限制的文档需要分层方法：将文档拆分为分块，摘要每个分块，然后摘要这些摘要。对于非常长的文档，这种 map-reduce 模式是唯一可行的方法。

**成本工程**

- 使用批量 API——比实时端点便宜 50%\* 将简单文档（短、结构化）路由到更小、更便宜的模型；将复杂文档路由到大模型
- 缓存重复或近乎重复的文档的摘要（在文档处理管道中比你想象的更常见）

**可靠性**

- 死信队列用于失败的任务——在不丢失文档的情况下捕获失败
- 带指数退避的重试\* 幂等处理——重新运行不会创建重复摘要
- 基于队列深度的 Worker 自动扩展

**质量保证**

每天抽取 1-2% 的输出进行人工审查。随时间跟踪摘要长度、抽取密度和事实一致性。对偏离质量基线发出警报。

**面试杀手锏：** 从计算开始。每次都是如此。*"10K 文档 × 2K token = 每天 2000 万 token = 大约 $X/天。这就是我设计时需要考虑的约束。"* 这立即表明你具有工程成熟度。

## 问题 10 · 防护栏

**"你实际交付过哪些安全或防护栏措施？有没有你的系统以你意想不到的方式行为的情况？"**

这是面试中的最后一个问题。也是最能够预测你是否会被信任来交付重要系统的那个问题。

**为什么他们问这个问题：** 安全不再是可选的。监管机构、法律团队和用户都在意。公司需要负责任地构建的工程师——不仅仅是有效地构建。

和往常一样，以下步骤：

![None](https://www.hubwiz.com/blog/content/images/2026/04/1-9bfraG4jEoBG9L8TzbIA-w.png)

问题 10 的回答框架——防护栏

安全是一个纵深防御问题，完全像安全一样。没有单一机制是足够的。你需要重叠的层次。

**输入防护栏**

在有害和对抗性输入到达模型之前进行过滤或标记。使用分类器进行：

- 提示注入检测（隐藏在用户输入或检索文档中的恶意指令）
- PII 检测（在数据进入上下文之前过滤或假名化敏感数据）
- 主题过滤（在 API 网关层阻止偏离主题或违反策略的请求）

在边缘阻止或清理危险输入，不要让它们到达模型。

**输出防护栏**

在模型输出到达用户之前进行验证。检查：

- 响应中的 PII 泄漏
- 有害或违反策略的内容
- 偏离主题的响应
- 事实不一致的输出（对于 RAG 系统）

使用二级分类器或规则引擎作为安全网。

**红队演练**

系统地尝试破坏你自己的系统。测试：

- 越狱（尝试绕过安全指令）
- 间接提示注入（隐藏在检索文档中的恶意内容，劫持 Agent 行为）
- 数据提取攻击（尝试让模型揭示训练数据或系统提示内容）
- 社会工程模式

这不是一次性练习。按计划进行红队演练——在主要发布之前、模型更新之后、提示更改之后。

**监控与可观测性**

记录所有输入和输出（带 PII 脱敏）。跟踪：

- 拒绝率——是否过高（过度拦截）或过低（拦截不足）？
- 被标记内容率
- 用户报告的问题

为可能表明主动对抗使用或系统漂移的异常模式设置警报。

**人工参与循环**

对于高风险领域——医疗、法律、金融、合规——将不确定或敏感的输出在交付前路由到人工审查员。设计升级路径，使系统优雅地失败而不是危险地失败。一个说"我需要人工来验证这个"的系统比一个自信地说错话的系统要好。

**面试杀手锏：** 引用真实框架。*"我遵循 OWASP 的 LLM Top 10 进行威胁建模，遵循 NIST 的 AI RMF 进行风险管理。"* 这表明你系统性地思考安全，而不是被动应对。

## 如何实际使用本指南

以下是我建议的练习方案：

**第 1 周：概念内化**

阅读每个部分一次。然后，不看文章，尝试向一个假想的、技术上有能力但不是 AI 专家的同事解释每个概念。当你无法清楚地解释某件事的那一刻，那就是一个知识缺口——而缺口正是面试官生存的地方。

**第 2 周：构建一个小系统**

选择十个主题中的任何一个，构建一个可运行的原型。你不需要一个生产系统。但实际实现 RAG 检索，或构建一个简单的 Agent 循环，或设置一个 LLM-as-Judge 评估管道——即使在玩具规模上——也能以阅读永远无法做到的方式巩固知识。真实系统揭示真实问题。

**第 3 周：对抗练习**

找一个朋友或同事让他们扮演面试官。让他们严厉地追问："如果重排序器引入了延迟怎么办？""你如何处理一个 100K token 的文档？""以 10 倍规模运行的成本是多少？""如果你的队列堵塞了，失败模式是什么？"在对抗性质疑中存活的答案就是你面试中真正会给出的答案。

**前一天**

回顾"面试杀手锏"要点。不是为了背诵，而是为了提醒自己区分性信号。一个有生产经验的工程师听起来是什么样的，与一个只是在学习的人有什么区别？

## 他们没列出但应该有的问题

快速说明：本指南中的十个问题是最常见的，但对话不会在十个问题结束。以下是越来越多地出现在高级 AI 工程师面试中的五个问题，以及深入探索的方向：

**"你如何处理 Agent 中的长期记忆？"** → 了解情景记忆架构、压缩记忆方法，以及上下文内历史、外部记忆存储和检索增强记忆之间的权衡。

我建议阅读这篇文章以获得更好的批判性解决方案方法 →

**"你如何防止生产 Agent 中的提示注入？"** → 输入清理、提示分区、权限分离（不要信任具有系统级指令的用户输入）和分层验证。

**"解释多 Agent 系统的架构。"** → 编排者-子 Agent 模式、消息传递、共享状态管理、冲突解决以及集中式与分布式协调的权衡。

**"你如何在生产中进行提示版本控制？"** → 提示注册表、A/B 测试基础设施、回滚机制以及将提示变更集成到 CI/CD 管道中。

**"微调、RLHF 和 DPO 之间有什么区别？"** → 微调塑造格式/风格，RLHF（基于人类反馈的强化学习）使用奖励模型塑造行为对齐，DPO（直接偏好优化）在没有显式奖励模型的情况下实现类似的对齐目标——通常更简单，并且越来越受欢迎。

再读一遍那十个问题，注意其中的模式。

它们中的每一个都是一个*系统思维*问题，披着 AI 问题的外衣。

- 幻觉 → 架构性纵深防御
- 成本 → 路由、缓存、批处理、模型选择
- 生产故障 → 监控、漂移检测、评估不匹配
- RAG 设计 → 文档处理 + 检索 + 重排序 + 评估
- 微调 → 迭代速度、成本、任务特异性
- 评估 → 指标、回归测试、人类反馈循环
- 嵌入 → 向量索引、ANN 算法、扩展
- Agent → 观察/思考/行动循环、错误处理、安全
- 文档摘要 → 队列、Worker、成本计算、质量采样
- 安全 → 输入/输出防护栏、红队演练、监控、人工监督

被录用的 AI 工程师是那个能够同时兼顾所有这些关注点的人。是那个能够像后端工程师谈论数据库一样谈论语言模型的人——将其作为更大系统中的一个组件，具有已知的故障模式、性能特征、成本概况和可靠性要求。

## 最后一件事

收到那封拒绝邮件的晚上，我很沮丧。但回头看，我很感激。

那次面试教会了我我真正不知道的东西。不是表面的东西——我知道词汇。而是深度。生产经验。系统思维。

获得高级 AI 角色的工程师不是那些读过最多论文或构建过最多演示的人。他们是那些交付过东西、在凌晨 3 点调试过东西、仔细思考过成本、安全和可靠性、并在压力下构建了足够深的心智模型来实时推理的人。

这十个问题就是通往那种深度的地图。

研究它们——不是作为要记忆的答案，而是作为要内化的问题。构建小型系统来测试你的理解。找到你以为你知道的和你能够清楚地向另一个工程师解释的之间的差距。

那个差距——弥合它——就是工作。

---

原文链接: [The 10 Questions That Decide Whether You're an AI Engineer or Just an AI User](https://pub.towardsai.net/the-10-questions-that-decide-whether-youre-an-ai-engineer-or-just-an-ai-user-fdaadf2de912?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处