延边万能胶 AI工程师面试备的10个问题

那封邮件在个周二的晚上 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、语义搜索、荐系统、异常检测的骨干。如果你正在构建任何需要理解含义（而不仅仅是匹配关键词）的东西，你就需要嵌入。

记住以下步骤：

为什么他们问这个问题： 嵌入是从搜索到荐再到 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 管道时你遇到过什么挑战？"

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

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

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

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

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

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

问题 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 天。我要退款。"

奥力斯    pvc管道管件胶批发    联系人：王经理    手机：15226765735（微信同号）    地址：河北省任丘市北辛庄乡南代河工业区

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

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

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

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

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

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

2 层：思维链/逐步理

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

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

3 层：输出验证与护栏

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

针对源文档的事实核查：答案的声明是否出现在检索到的上下文中？

标记"不受支持"声明的 NLI 分类器（微调用于检测蕴含 vs. 矛盾的模型）

门用于验证的二次模型调用

4 层：约束解码

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

5 层：置信度校准

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

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

将此作为你的心智模型：

图 3：幻觉御管道

问题 04 · 评估策略

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

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

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

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

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

任务特定指标

将指标与任务匹配：延边万能胶

分类：准确率、F1、精确率/召回率

摘要：ROUGE、BERT-Score

翻译：BLEU、COMET

生成：困惑度、连贯分数

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

LLM-as-Judge

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

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

人工评估

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

对抗测试

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

回归测试

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

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

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

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

或者

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

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

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

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

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

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

回答之前记住这些步骤：

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

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

以下是完整的诊断框架：

数据漂移

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

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

训练-测试泄漏

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

评估不匹配

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

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

提示敏感

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

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

延迟与时问题

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

上下文窗口溢出

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

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

问题 06 · 微调 vs 提示

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

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

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

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

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

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

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

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

什么时候应该微调：

你需要致的输出格式或风格，而提示法可靠地强制执行。如果你需要每个响应都是特定的 JSON schema、特定的写作风格或特定的人设——而提示给你 85 的致但你需要 99——微调将行为烘焙到权重中。

你有个狭窄的、定义明确的任务，并有大量标注示例（数百到数千个质量的输入/输出对）。分类、提取、转换——有明确正确答案的狭窄任务能从微调中受益。

你需要减少延迟，万能胶生产厂家通过移除长系统提示。微调后的模型可以将其行为编码到权重中，因此你不需要在每次调用时发送 2,000 token 的系统提示。

你想将大模型的行为蒸馏到小、便宜的模型中。 训练个小模型在你的特定任务上模仿大模型的输出。

什么时候不应该微调：

你只有不到几百个质量示例* 你的任务频繁变化，重新训练昂贵且缓慢

你需要广泛的通用知识，在狭窄数据上微调会致灾难地遗忘其他切

基础模型在正确的提示下已经表现良好

混法

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

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

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

问题 07 · 成本降低策略

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

或者

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

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

图 5 说明：

流程从语义缓存检查开始，因此如果几乎相同的问题之前已经回答过，系统可以几乎成本地立即返回响应。

如果查询是新的，它会按复杂度进行分类。简单的问题路由到个小型、廉价的模型，而较难的理任务只在要时才路由到较大的模型。

非紧急工作负载会被批处理，让你可以起处理许多请求，并利用批量 API 折扣将成本削减近半。

在输出端，提示压缩和输出长度控制有助于消除不要的 token，减少你为生成支付的费用而不影响质量。

后，个微调决策门评估任务是否足够狭窄和重复，以证明训练个小型自定义模型是理的。如果是的话，你可以移除系统提示，并为大批量用例解锁巨大的长期节省。

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

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

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

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

问题 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，而不仅仅是生成文本。这个问题测试你是否能够设计它们。

问题 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 份文档的系统，是不同量的问题。

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

问题 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 · 护栏

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

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

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

和往常样，以下步骤：

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

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

输入护栏

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

提示注入检测（隐藏在用户输入或检索文档中的恶意指令）

PII 检测（在数据进入上下文之前过滤或假名化敏感数据）

主题过滤（在 API 网关层阻止偏离主题或违反策略的请求）

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

输出护栏

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

响应中的 PII 泄漏

有害或违反策略的内容

偏离主题的响应

事实不致的输出（对于 RAG 系统）

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

红队演练

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

越狱（尝试绕过安全指令）

间接提示注入（隐藏在检索文档中的恶意内容，劫持 Agent 行为）

数据提取攻击（尝试让模型揭示训练数据或系统提示内容）

社会工程模式

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

监控与可观测

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

拒率——是否过（过度拦截）或过低（拦截不足）？

被标记内容率

用户报告的问题

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

人工参与循环

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

面试手锏： 引用真实框架。"我遵循 OWASP 的 LLM 0 进行威胁建模，遵循 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 点调试过东西、仔细思考过成本、安全和可靠、并在压力下构建了足够的心智模型来实时理的人。

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

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

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

1.本网站以及本平台支持关于《新广告法》实施的“极限词“用语属“违词”的规定，并在网站的各个栏目、产品主图、详情页等描述中规避“违禁词”。
2.本店欢迎所有用户指出有“违禁词”“广告法”出现的地方，并积极配合修改。
3.凡用户访问本网页，均表示默认详情页的描述，不支持任何以极限化“违禁词”“广告法”为借口理由投诉违反《新广告法》延边万能胶 ，以此来变相勒索商家索要赔偿的违法恶意行为。