AI应用开发工程师面试题汇总（一）：基础概念与核心原理30问-171主机测评

AI应用开发工程师面试题汇总（一）：基础概念与核心原理30问

文章目录

AI应用开发工程师面试题汇总（一）：基础概念与核心原理30问
- 前言
- 一、大模型核心原理必问10题
- - 1. 什么是Token？大模型是如何将文本转换为Token的？
  - 2. Temperature参数的作用是什么？如何选择合适的Temperature值？
  - 3. 什么是上下文窗口？超出上下文窗口会发生什么？
  - 4. 什么是"Lost in the Middle"问题？如何缓解？
  - 5. 大模型为什么会产生幻觉？有哪些类型？
  - 6. 缓解大模型幻觉的常见手段有哪些？
  - 7. Few-Shot、Zero-Shot和Chain-of-Thought（CoT）有什么区别？各自的适用场景是什么？
  - 8. 如何让大模型输出结构化数据（如JSON）？有哪些常见问题和解决方案？
  - 9. 流式响应（Streaming）的原理是什么？在工程实现中需要注意什么？
  - 10. Embedding是什么？在AI应用开发中有哪些用途？
- 二、向量与检索基础8题
- - 11. 余弦相似度、点积和欧氏距离有什么区别？在向量检索中如何选择？
  - 12. HNSW和IVF是两种常见的向量索引算法，请比较它们的原理和适用场景
  - 13. Embedding维度的选择有哪些考量因素？
  - 14. 向量数据库和传统关系型数据库有什么区别？各自的适用场景是什么？
  - 15. 语义检索和关键词检索有什么区别？为什么需要混合检索？
  - 16. 在RAG系统中，Top-K的K值如何选择？太大或太小有什么问题？
  - 17. 请描述RAG（检索增强生成）的基本流程和核心组件
  - 18. 文档分块（Chunking）有哪些策略？如何选择合适的分块方式？
- 三、工具调用与Agent基础6题
- - 19. Function Calling的原理是什么？如何在应用中实现工具调用？
  - 20. 什么是ReAct模式？它与Function Calling有什么区别？
  - 21. 当Agent有多个可用工具时，如何优化工具选择的准确性？
  - 22. 工具调用失败时应该如何处理？设计一个完善的错误处理机制
  - 23. Agent的记忆机制有哪些？如何设计Agent的长期和短期记忆？
  - 24. 多轮对话管理有哪些核心挑战？如何设计一个高效的多轮对话系统？
- 四、工程实践必问6题
- - 25. 如何管理Prompt模板？有哪些最佳实践？
  - 26. 大模型输出校验与重试机制如何设计？
  - 27. 大模型应用的成本优化有哪些策略？
  - 28. 如何对大模型应用进行A/B测试？有哪些注意事项？
  - 29. 大模型应用的灰度发布策略是怎样的？
  - 30. 大模型应用上线前需要检查哪些事项？请列出一份完整的检查清单
- 总结

前言

AI应用开发已经成为技术行业最热门的方向之一，越来越多的团队开始将大模型能力集成到实际产品中。然而，AI应用开发不同于传统的Web开发或后端开发，它涉及到自然语言处理、向量检索、提示工程、Agent编排等多个交叉领域的知识。对于准备面试AI应用开发工程师岗位的同学来说，掌握核心原理和工程实践方法是基本要求。

本文整理了30道高频面试题，覆盖大模型核心原理、向量与检索基础、工具调用与Agent基础、工程实践四个方向。每道题都给出了参考答案，包含原理讲解、实践要点和面试加分点，帮助你系统性地准备面试。无论你是刚转型的开发者还是有经验的AI工程师，都可以用来查漏补缺。

一、大模型核心原理必问10题

1. 什么是Token？大模型是如何将文本转换为Token的？

参考答案：

Token是大模型处理文本的基本单位，介于"字符"和"单词"之间。大模型不能直接理解原始文本，需要先将文本切分为Token序列，再将每个Token映射为一个高维向量（Embedding），然后输入到模型中进行计算。

Token的切分方式主要有三种：字符级（按字符切分）、词级（按完整单词切分）和子词级（Subword，如BPE、WordPiece、SentencePiece）。现代大模型普遍采用子词级切分，兼顾了词表大小和语义完整性。BPE（Byte Pair Encoding）是最常见的子词切分算法，它从字符开始，通过统计频率逐步合并高频字节对，直到达到预设词表大小。

实践要点：

不同语言的Token效率不同：英文通常1个单词≈1-2个Token，中文通常1个汉字≈1-2个Token
Token数量直接影响调用成本和推理速度
上下文窗口的限制是按Token计算的，而非字符数
编写Prompt时应注意Token预算，避免不必要的冗余文本

面试加分点：能说出BPE算法的基本流程，理解Tokenization对多语言场景的影响，知道特殊Token（如开始符、结束符、分隔符）的作用。

2. Temperature参数的作用是什么？如何选择合适的Temperature值？

参考答案：

Temperature是控制大模型输出随机性的核心参数，作用于模型输出Logits之后的Softmax层。数学上，Softmax的公式变为：p_i = exp(logit_i / T) / Σ(exp(logit_j / T))。当T=1时为标准Softmax；T越小，概率分布越尖锐，模型倾向于选择概率最高的Token；T越大，概率分布越平坦，输出越随机多样。

实践选择指南：

Temperature=0（贪心解码）：适用于代码生成、数据抽取、结构化输出、事实性问答等需要确定性和准确性的场景。每次输出结果基本一致（受浮点精度影响可能有极小差异）
Temperature=0.3-0.5：适用于知识问答、摘要生成、文档分析等需要一定准确性但允许少量表述变化的场景
Temperature=0.7-1.0：适用于创意写作、对话聊天、广告文案等需要多样性和创造性的场景
Temperature>1.0：一般不推荐，输出可能变得不连贯

面试加分点：理解Temperature与Top-P、Top-K的关系和区别；知道Temperature=0时模型并非完全确定（因为batch推理时浮点运算的非确定性）；能结合具体业务场景说明为什么选择某个Temperature值；知道除了Temperature外，还有repetition_penalty、frequency_penalty等采样参数。

3. 什么是上下文窗口？超出上下文窗口会发生什么？

参考答案：

上下文窗口（Context Window）是大模型单次推理能处理的最大Token数量，包括输入（Prompt + 用户消息 + 历史对话）和输出的总和。上下文窗口由模型架构决定，主要受限于注意力机制的计算复杂度——标准自注意力的计算量与序列长度呈平方关系。

超出上下文窗口的常见后果：

直接截断：部分模型会自动截断超出的部分，通常是截断最早的消息，导致丢失早期上下文
报错拒绝：部分API会直接返回错误，要求用户减少输入
性能退化：即使模型支持超长上下文，在超长输入下也可能出现"Lost in the Middle"问题，对中间位置的信息处理能力下降

处理超长上下文的工程方案：

对话历史压缩：将早期对话用摘要替代，保留近期原始对话
滑动窗口：只保留最近N轮对话作为上下文
分块处理：将长文档分块，配合RAG检索相关片段
上下文路由：根据用户问题，动态选择最相关的上下文片段

面试加分点：理解注意力机制的计算复杂度问题（O(n²)）；知道稀疏注意力、滑动窗口注意力等优化方案；了解上下文窗口与最大输出Token的关系（两者共享总额度）；能说出实际项目中管理上下文窗口的具体策略。

4. 什么是"Lost in the Middle"问题？如何缓解？

参考答案：

"Lost in the Middle"是指大模型在处理长文本时，对位于输入中间位置的信息表现出明显的"遗忘"或"忽略"现象。模型对开头和结尾的信息处理效果较好，但对中间部分的信息提取准确率显著下降。这一现象在多项研究中被实证发现，是大模型长上下文处理的核心痛点之一。

产生原因：

注意力机制的位置偏差：模型在训练时接触的文本通常是有限长度的，对长文本中间位置的注意力分配不足
相对位置编码的衰减：随着距离增加，注意力权重可能衰减
信息淹没：大量上下文中间的信息被周围内容稀释

缓解策略：

重排序（Reordering）：将最相关的信息放在Prompt的开头和结尾，次要信息放中间。在RAG场景中，将检索到的文档按相关性重排后再拼接
分块提问：将长文档分成多个小块，分别提问后汇总答案
地图-减少（Map-Reduce）：先对每个文档块独立处理（Map），再汇总结果（Reduce）
迭代检索：不要一次性塞入所有信息，根据问题动态检索最相关的片段
压缩上下文：用摘要替代原始长文本，减少中间噪音

面试加分点：能解释U型注意力分布的现象；知道重排序是RAG系统中的标准优化手段；理解为什么"塞更多上下文"不等于"更好的回答"；能结合实际项目说明如何在RAG pipeline中实现重排序。

5. 大模型为什么会产生幻觉？有哪些类型？

参考答案：

幻觉（Hallucination）是指大模型生成看似合理但实际上不正确、虚构或与事实不符的内容。这是大模型固有的挑战，根源于模型的生成机制——模型本质上是在做概率性的下一个Token预测，而非从知识库中检索事实。

幻觉的主要类型：

事实性幻觉（Factuality Hallucination）：生成与客观事实不符的内容，如编造不存在的人物、事件、数据
忠实性幻觉（Faithfulness Hallucination）：在摘要、翻译等任务中，生成内容与源材料不一致，如添加原文没有的信息
逻辑幻觉：推理过程中出现逻辑跳跃或错误，中间步骤与结论不匹配
指令幻觉：模型偏离用户指令，做了用户没有要求的事情

产生原因：

训练数据中的噪音、错误信息和过时信息
模型的概率生成本质：追求流畅性而非准确性
知识截止：训练完成后发生的事件模型不知道
长尾知识不足：对低频知识表示不充分
上下文冲突：当Prompt中的信息与模型参数知识冲突时

面试加分点：能区分"闭卷"场景和"开卷"（RAG）场景下幻觉的不同特点；理解温度参数对幻觉的影响；知道模型对自身不确定性的校准问题（模型往往对错误答案也表现出高置信度）；了解幻觉检测的自动化方法。

6. 缓解大模型幻觉的常见手段有哪些？

参考答案：

缓解幻觉需要从多个层面综合施策，没有单一方法能完全消除幻觉。

Prompt层面：

RAG（检索增强生成）：为模型提供外部知识，让模型基于检索到的文档生成答案，而非依赖参数知识
CoT（思维链）：引导模型展示推理过程，中间步骤的约束可以减少逻辑幻觉
指令约束：明确告诉模型"如果不确定请回答不知道"、“仅基于提供的上下文回答”
Few-Shot示范：给出包含"不知道"回答的示例，鼓励模型在不确定时承认

解码层面：

降低Temperature：减少随机性，降低生成虚构内容的概率
Top-P/Top-K约束：限制候选Token范围，避免低概率Token被选中
约束解码：使用结构化输出约束模型在合法范围内生成

后处理层面：

事实校验：用另一个模型或规则校验生成内容的事实准确性
引用追溯：要求模型标注信息来源，便于人工或自动验证
多路生成+投票：多次生成并取一致性最高的结果

系统层面：

知识库更新：定期更新RAG知识库，确保信息时效性
领域微调：在专业领域数据上微调，减少长尾知识幻觉
人工审核：对关键场景的输出进行人工审核

面试加分点：能说出RAG虽然能缓解幻觉但不能完全消除（模型可能忽略检索内容或曲解文档）；理解不同业务场景对幻觉的容忍度不同（创意写作vs医疗诊断）；知道如何设计评估指标量化幻觉率。

7. Few-Shot、Zero-Shot和Chain-of-Thought（CoT）有什么区别？各自的适用场景是什么？

参考答案：

这三种是Prompt工程中最基本的引导策略：

Zero-Shot（零样本）：直接给模型任务描述，不提供任何示例。例如：“请判断以下评论是正面还是负面：{文本}”。适用于简单任务或模型已有足够先验知识的场景。优点是Token消耗少，缺点是输出格式不可控、复杂任务效果差。

Few-Shot（少样本）：在Prompt中提供少量（通常2-5个）输入-输出示例，让模型通过模式匹配理解任务格式和逻辑。例如给出几个情感分析的示例后再要求模型分析新文本。优点是输出格式可控、任务理解更准确，缺点是消耗更多Token、示例选择影响效果。

Chain-of-Thought（思维链）：引导模型展示中间推理步骤，而非直接给出最终答案。可以与Zero-Shot或Few-Shot结合使用。Zero-Shot CoT只需在Prompt中加一句"请一步一步思考"，Few-Shot CoT则在示例中展示推理过程。适用于数学计算、逻辑推理、多步决策等需要中间推理的任务。

适用场景对比：

简单分类、格式转换 → Zero-Shot
需要特定输出格式、任务有特殊约定 → Few-Shot
数学推理、逻辑分析、复杂判断 → CoT
高准确性要求的复杂任务 → Few-Shot + CoT

面试加分点：知道Few-Shot示例的顺序和选择会影响效果；理解CoT的原理是让模型分配更多计算到推理过程；知道Self-Consistency（多次采样CoT取多数投票）可以进一步提升效果；了解CoT在不同规模模型上的效果差异（小模型可能无法从CoT中获益）。

8. 如何让大模型输出结构化数据（如JSON）？有哪些常见问题和解决方案？

参考答案：

让大模型可靠地输出结构化数据是AI应用开发的核心工程挑战之一。

常见方法：

Prompt约束：在Prompt中明确要求输出JSON格式，并给出Schema说明和示例。简单场景下有效，但模型可能不严格遵守。

Function Calling / Tool Calling：模型厂商提供的原生结构化输出能力。定义函数的参数Schema，模型输出符合Schema的参数。可靠性高于纯Prompt约束。

JSON Mode：部分模型提供专门的JSON输出模式，保证输出是合法的JSON语法。但不保证内容符合业务Schema。

约束解码（Constrained Decoding）：在推理层面对Token生成施加语法约束，如使用JSON Schema约束、正则约束等。可以从根本上保证输出格式合法，常见实现有Outlines、Guidance、LMQL等。

Pydantic + 校验：定义Pydantic模型，对模型输出进行解析和校验，校验失败时重试或修复。

常见问题与解决方案：

JSON语法错误（多余逗号、引号不匹配）→ 使用约束解码或JSON Mode
字段缺失或多余 → 在Schema中明确标注required字段，用Pydantic校验
类型不匹配（字符串vs数字）→ Schema中明确类型，约束解码保证
嵌套结构不正确 → 提供详细的嵌套Schema和Few-Shot示例
输出多余文本（如"以下是结果：“）→ Prompt中明确"只输出JSON，不要其他文本”，或用约束解码
枚举值不合法 → Schema中用enum约束

面试加分点：知道约束解码的原理（在每一步Token生成时，根据当前已生成内容计算合法的Token集合，屏蔽非法Token）；理解Function Calling和JSON Mode的区别；能说出在生产环境中为什么不能只依赖Prompt约束；了解输出校验失败后的重试策略设计。

9. 流式响应（Streaming）的原理是什么？在工程实现中需要注意什么？

参考答案：

流式响应是指大模型在生成过程中逐步返回Token，而非等待全部生成完毕后一次性返回。底层原理是模型自回归生成的特性——每次生成一个Token，因此可以"边生成边返回"。实现上通常采用SSE（Server-Sent Events）或WebSocket协议，服务端将生成的Token增量推送给客户端。

流式响应的优势：

用户体验：首Token延迟低，用户无需等待完整响应，感知更流畅
可中断性：用户可以在生成过程中停止，节省Token成本
实时反馈：在长文本生成场景中，用户可以实时看到进度

工程实现注意事项：

错误处理：流式传输中途可能发生网络中断或模型错误。需要设计断线重连和部分结果保存机制。

结构化输出困难：流式返回的是Token片段，JSON等结构化数据在未完成时无法解析。需要设计增量解析器或缓冲机制，在流结束后再解析完整结构。

超时管理：流式连接的持续时间较长，需要合理设置超时时间，避免Proxy或网关提前断开。

背压控制：客户端消费速度可能慢于服务端生成速度，需要实现背压机制防止内存溢出。

多路复用：同时处理多个流式请求时，注意连接池管理和资源隔离。

Token计数：流式模式下需要自己累计Token数量用于成本控制，部分API在流式响应的最后一条消息中返回总Token数。

前端渲染：Markdown渲染、代码高亮等需要在流式过程中增量更新，注意避免频繁重渲染导致性能问题。

面试加分点：理解SSE和WebSocket在流式场景下的优劣；知道如何实现流式响应的中间结果处理（如检测到完整句子时触发TTS）；能说明在Function Calling场景下流式响应的特殊处理（先返回函数调用意图，再执行函数）。

10. Embedding是什么？在AI应用开发中有哪些用途？

参考答案：

Embedding（嵌入）是将离散的文本（或图像、音频等）映射为连续的高维稠密向量表示。语义相近的文本在向量空间中距离较近，语义差异大的文本距离较远。Embedding模型通常基于Transformer架构，取最后一层的隐藏状态（如[CLS] Token或平均池化）作为整个输入的向量表示。

核心特性：

语义相似度：向量间的距离（如余弦相似度）反映语义相似度。"猫"和"小猫"的Embedding距离近，"猫"和"汽车"距离远
维度固定：无论输入文本长短，输出的向量维度固定（如768维、1024维、1536维等）
可计算性：向量支持数学运算，如计算相似度、向量加减（经典的"国王-男人+女人=女王"）

在AI应用中的主要用途：

RAG检索：将文档和用户查询分别Embedding后，通过向量相似度检索最相关的文档片段

语义搜索：超越关键词匹配，基于语义理解进行搜索

文本分类：用Embedding作为特征进行下游分类任务

聚类分析：对大量文本进行Embedding后聚类，发现主题和模式

去重与相似度检测：判断两段文本是否语义重复

推荐系统：基于内容语义相似度进行推荐

多模态对齐：文本和图像的Embedding在同一空间中，支持跨模态检索

面试加分点：理解Embedding维度与信息容量的关系；知道不同Embedding模型的维度选择依据；理解为什么Embedding后的向量需要归一化；了解稠密向量与稀疏向量（如BM25）的区别和互补性；知道对比学习（Contrastive Learning）是训练Embedding模型的核心方法。

二、向量与检索基础8题

11. 余弦相似度、点积和欧氏距离有什么区别？在向量检索中如何选择？

参考答案：

这三种是向量相似度计算的最常见方法：

余弦相似度（Cosine Similarity）：计算两个向量夹角的余弦值，公式为 cos(A,B) = A·B / (|A||B|)。取值范围[-1,1]，值越大表示越相似。只关注方向，忽略向量长度。在文本Embedding场景中，向量长度受文本长度影响，而语义相似度应与文本长度无关，因此余弦相似度是最常用的选择。

点积（Dot Product）：A·B = Σ(a_i * b_i)。当向量归一化后（长度为1），点积等于余弦相似度。点积计算更快（无需计算模长），但未归一化时结果受向量长度影响。如果Embedding模型训练时使用了归一化约束，使用点积即可。

欧氏距离（Euclidean Distance）：d(A,B) = √Σ(a_i – b_i)²。衡量向量在空间中的绝对距离，同时考虑方向和长度。取值范围[0, +∞)，值越小越相似。在图像Embedding、聚类等场景中常用。

选择建议：

文本语义检索 → 余弦相似度（最通用）或归一化后的点积（最快）
需要考虑向量长度信息的场景 → 欧氏距离
追求计算效率 → 归一化向量+点积（省去除法运算）

面试加分点：知道大部分向量数据库支持这三种度量方式，但底层索引结构可能对某种度量优化更好；理解归一化后点积与余弦相似度等价；知道负余弦相似度的含义（语义相反）；了解内积在MaxSim等late interaction模型中的应用。

12. HNSW和IVF是两种常见的向量索引算法，请比较它们的原理和适用场景

参考答案：

HNSW（Hierarchical Navigable Small World）：

基于图的索引算法，构建多层近邻图。上层稀疏用于快速跳转，下层稠密用于精确搜索
查询时从顶层开始贪心搜索，逐层下降，在底层找到最近邻
优点：查询速度快，召回率高，不需要训练
缺点：内存占用大（需要存储图结构），构建索引慢，不适合频繁删除
适用场景：数据量中等（百万级）、对查询延迟敏感、内存充足的场景

IVF（Inverted File Index）：

基于聚类的索引算法，先用K-Means将向量空间划分为多个聚类（倒排桶），查询时只搜索最近的几个桶
常与PQ（Product Quantization）组合为IVF-PQ，进一步压缩存储
优点：内存占用小（配合PQ压缩），构建速度快，支持动态增删
缺点：需要训练聚类中心，召回率受桶数和探测数影响，查询速度不如HNSW
适用场景：数据量大（亿级）、内存有限、对召回率要求可接受的场景

关键参数对比：

HNSW的ef_construction（构建时邻居数）和ef_search（查询时搜索范围）影响构建质量和查询速度
IVF的nlist（聚类桶数）和nprobe（查询时探测桶数）影响召回率和查询速度

面试加分点：知道HNSW的"可导航小世界图"理论基础；理解IVF中PQ压缩的原理（将高维向量拆分为子向量分别量化）；知道还有ANNOY、ScaNN等其他索引算法；能根据数据规模、延迟要求、内存预算给出索引选型建议；了解DiskANN等磁盘索引方案。

13. Embedding维度的选择有哪些考量因素？

参考答案：

Embedding维度是指向量表示的维度大小，常见的有768、1024、1536、3072等。维度的选择需要在信息容量和计算效率之间权衡。

维度对性能的影响：

信息容量：维度越高，能编码的语义信息越多，理论上表达能力更强
计算成本：向量相似度计算的时间与维度成正比，高维度降低检索速度
存储成本：每个向量的存储空间与维度成正比，百万级向量在1536维下约占6GB
维度灾难：当维度过高而数据量不足时，向量间的区分度反而下降，影响检索质量

选择考量因素：

任务复杂度：简单分类任务可能768维足够，细粒度语义区分可能需要更高维度

数据规模：数据量小时高维度容易过拟合，数据量大时高维度能更好地编码信息

延迟要求：实时检索场景倾向低维度以降低计算延迟

存储预算：大规模向量库需要考虑存储成本，可通过降维（如PCA）或量化（如PQ）压缩

Embedding模型限制：维度由Embedding模型决定，选择模型时需同时考虑维度和效果

实践建议：

优先选择经过充分验证的Embedding模型，其默认维度通常是效果和效率的平衡点
如果需要降低维度，可以用PCA或Matryoshka Representation Learning（MRL）技术
在实际项目中，建议用评测集对比不同维度下的检索准确率和延迟，做数据驱动决策

面试加分点：知道Matryoshka Representation Learning可以在同一模型中输出不同维度的Embedding，且低维表示仍保持较好效果；理解PQ量化本质上也是一种降维方式；能说出"维度越高效果越好"不是绝对的。

14. 向量数据库和传统关系型数据库有什么区别？各自的适用场景是什么？

参考答案：

核心区别：

维度向量数据库传统关系型数据库

数据类型	高维稠密向量	结构化行列数据
查询方式	近邻搜索（相似度）	精确匹配、范围查询、聚合
查询结果	Top-K相似结果（近似）	精确结果
索引结构	HNSW、IVF等近似索引	B-Tree、Hash等精确索引
一致性	最终一致性为主	强一致性（ACID）
典型操作	向量插入、相似度检索	增删改查、JOIN、事务

适用场景：

向量数据库：语义搜索、推荐系统、图片搜索、去重、RAG知识检索
关系型数据库：用户管理、订单处理、财务系统、事务性业务

实际项目中的配合使用：在RAG系统中，通常需要两者配合：

用向量数据库存储文档的Embedding向量，支持语义检索
用关系型数据库存储文档的元数据（标题、来源、时间、权限等）
查询时先通过向量数据库检索相关文档，再通过文档ID从关系型数据库获取元数据

选型注意事项：

部分数据库（如PostgreSQL + pgvector）同时支持向量和关系型查询，适合中小规模场景
专业向量数据库在大规模数据和高性能检索方面更有优势
需要考虑向量数据库的过滤能力（先过滤元数据再向量检索，或先向量检索再过滤）

面试加分点：理解ANN（近似最近邻）与KNN（精确最近邻）的区别，知道为什么大规模场景下必须用ANN；能说出向量数据库的过滤检索中"pre-filter"和"post-filter"的区别和权衡；了解混合检索中向量检索与全文检索的结合方式。

15. 语义检索和关键词检索有什么区别？为什么需要混合检索？

参考答案：

语义检索：基于Embedding向量的相似度进行检索。将查询和文档都映射为向量，计算相似度后返回最近邻结果。

优点：理解语义意图，能匹配同义词、不同表述方式；跨语言检索能力强
缺点：对专有名词、缩写、ID等精确匹配场景效果差；可能忽略关键词的精确匹配信号；Embedding模型的领域偏移可能导致效果下降

关键词检索：基于词项匹配的检索方式，如BM25、TF-IDF等。通过词频-逆文档频率等统计信号排序。

优点：精确匹配关键词，对专有名词、代码、ID等效果好；可解释性强；不需要额外模型
缺点：不理解语义，“汽车"搜不到"轿车”；对同义词和不同表述无能为力；语言敏感性高

为什么需要混合检索：两种方法各有盲区，实际查询往往同时需要语义理解和精确匹配。例如：

“Python中如何读取CSV文件” → 语义检索理解意图，关键词检索确保"CSV"精确匹配
“ERROR_CODE_4012的解决方案” → 关键词检索精确匹配错误码，语义检索补充相关上下文

混合检索的实现方式：

并行检索+融合：分别用语义和关键词检索，然后融合结果。常见融合方法：

Reciprocal Rank Fusion（RRF）：基于排名倒数融合，简单有效
加权分数融合：对两种检索的分数归一化后加权求和

级联检索：先用一种方法初筛，再用另一种方法精排

统一索引：部分系统支持同时构建向量和全文索引，在查询时联合使用

面试加分点：知道BM25的公式和核心思想；理解RRF相比加权融合的优势（不需要分数归一化，对不同分布的分数更鲁棒）；能说出在什么场景下语义检索优于关键词检索，反之亦然；知道如何评估检索效果（Recall@K、MRR、NDCG等指标）。

16. 在RAG系统中，Top-K的K值如何选择？太大或太小有什么问题？

参考答案：

Top-K是指向量检索时返回的最相似文档数量，是RAG系统中最基础但也最关键的参数之一。

K值过小的问题：

召回率不足：可能遗漏相关文档，导致模型无法获取足够信息
鲁棒性差：如果检索排序有波动，少量文档可能全部不相关
多角度信息缺失：对于复杂问题，可能需要多个文档提供不同维度的信息

K值过大的问题：

上下文膨胀：大量文档拼接后超出上下文窗口或增加推理成本
信息淹没：无关文档稀释有效信息，增加"Lost in the Middle"风险
幻觉风险增加：模型可能被无关信息误导
延迟增加：更多的输入Token意味着更长的推理时间

K值选择策略：

基于评测：在标注好的评测集上测试不同K值的检索召回率和最终回答准确率，选择拐点

动态调整：根据查询复杂度动态调整K值——简单事实查询用小K（3-5），复杂推理用大K（10-20）

两阶段检索：第一阶段用较大的K（如20-50）保证召回率，第二阶段用重排序模型精排到小K（3-5）

考虑文档长度：文档块较短时K可以适当增大，文档块较长时K应减小

实践参考：

简单FAQ场景：K=3-5
知识库问答：K=5-10
复杂多跳推理：K=10-20（配合重排序）
代码搜索：K=1-3（代码块通常较长）

面试加分点：知道两阶段检索（召回+重排序）是工业RAG的标配；理解重排序模型（Cross-Encoder）与检索模型（Bi-Encoder）的区别；能说出文档分块策略与K值的关联；知道如何设计实验确定最优K值。

17. 请描述RAG（检索增强生成）的基本流程和核心组件

参考答案：

RAG是将外部知识检索与大模型生成结合的架构，让模型基于检索到的上下文生成回答，从而减少幻觉、提供最新信息、支持领域知识。

基本流程分为三个阶段：

一、数据准备阶段（离线）：

文档加载：从各种来源（PDF、网页、数据库、API）加载原始文档

文档分块（Chunking）：将长文档切分为语义连贯的小块。常用策略包括固定长度切分、按段落/标题切分、重叠切分等

Embedding生成：对每个文档块生成向量表示

向量入库：将向量和元数据存入向量数据库

二、检索阶段（在线）：

查询处理：用户输入可能需要改写、扩展或分解为子查询

查询Embedding：将用户查询转换为向量

向量检索：在向量数据库中检索Top-K最相似的文档块

（可选）重排序：用Cross-Encoder对检索结果精排，提升相关性

（可选）混合检索：结合关键词检索提升精确匹配能力

三、生成阶段（在线）：

上下文组装：将检索到的文档块组装到Prompt中，包含指令、上下文、用户问题

大模型生成：调用大模型基于上下文生成回答

后处理：引用标注、事实校验、格式化输出等

核心组件：

文档处理器（加载、分块、清洗）
Embedding模型
向量数据库
检索器（向量检索+关键词检索+重排序）
Prompt模板管理
大模型
后处理器（引用追溯、内容校验）

面试加分点：能说出RAG的常见优化方向（查询改写、文档分块优化、重排序、上下文压缩等）；理解"朴素RAG"与"Advanced RAG"的区别；知道RAG系统的评估维度（检索质量评估和生成质量评估）；了解多模态RAG的可能性。

18. 文档分块（Chunking）有哪些策略？如何选择合适的分块方式？

参考答案：

文档分块是RAG系统中最影响检索质量的环节之一。分块策略决定了检索粒度和上下文完整性。

常见分块策略：

固定长度分块：按固定Token数（如500）切分，通常加上重叠区域（如50 Token）。实现简单，但可能切断语义。

按结构分块：根据文档的自然结构切分——按段落、按标题层级、按Markdown的##标题等。保持语义完整性，适合结构化文档。

递归分块：优先按大结构（如章节）切分，如果块太大再递归按小结构（段落、句子）切分，直到满足大小约束。兼顾结构和大小控制。

语义分块（Semantic Chunking）：用Embedding模型计算相邻句子的语义相似度，在语义突变处切分。理论上最优，但计算成本高。

滑动窗口分块：以固定步长滑动窗口，每个窗口是一个块。适合需要均匀覆盖的场景，但冗余高。

父子分块（Parent-Child）：将文档切成小块用于检索（精确匹配），但返回时使用包含小块的大块（上下文完整）。兼顾检索精度和上下文完整性。

选择考量：

文档类型：技术文档适合按标题分块；法律合同适合按条款分块；对话记录适合按轮次分块
块大小：一般建议200-1000 Token，太小丢失上下文，太大稀释信息
重叠：20-50 Token的重叠可以避免边界信息丢失
元数据：每个块应保留来源、页码、标题路径等元数据，便于追溯和过滤

面试加分点：知道分块大小对检索质量的影响曲线（太小召回高但上下文不足，太大上下文足但召回低）；理解父子分块是解决"检索精度vs上下文完整性"矛盾的有效方案；能说出在不同文档类型下的分块策略选择；了解分块后对每个块生成摘要（摘要检索）的优化方式。

三、工具调用与Agent基础6题

19. Function Calling的原理是什么？如何在应用中实现工具调用？

参考答案：

Function Calling是大模型根据用户意图自动选择并调用外部工具的能力。模型本身不执行函数，而是输出函数调用的意图（函数名+参数），由应用层执行实际函数后将结果返回给模型。

工作流程：

定义工具：应用层定义可用工具的名称、描述和参数Schema（JSON Schema格式）

Prompt注入：将工具定义注入到系统Prompt中，模型"知道"有哪些工具可用

意图识别：用户提问后，模型判断是否需要调用工具，以及调用哪个工具

参数生成：模型生成符合Schema的函数调用参数（通常是JSON格式）

应用层执行：应用解析模型输出的函数调用，执行实际函数

结果回传：将函数执行结果作为新消息追加到对话中

模型总结：模型基于函数返回结果生成最终回答

工程实现要点：

工具描述要精确：模型依赖工具描述判断何时使用，描述应包含功能、适用场景、参数含义
参数Schema要严格：用JSON Schema明确定义参数类型、是否必填、枚举值等
错误处理：函数执行可能失败，需要将错误信息合理地回传给模型，让其决定重试或换方案
多工具调用：部分模型支持一次生成多个函数调用，支持并行执行
工具选择冲突：当多个工具都可能适用时，模型可能选错。需要在工具描述中明确边界

面试加分点：理解Function Calling与ReAct的关系和区别；知道模型在训练时需要包含工具调用的训练数据才能支持Function Calling；能说出在流式响应中处理Function Calling的特殊逻辑；了解工具调用的安全控制（权限校验、参数校验、执行超时）。

20. 什么是ReAct模式？它与Function Calling有什么区别？

参考答案：

ReAct（Reasoning and Acting）是一种让大模型交替进行推理和行动的Agent模式。核心思想是让模型在解决复杂问题时，先"思考"（Thought）下一步该做什么，然后"行动"（Action）调用工具，观察"结果"（Observation），再继续思考，形成Thought-Action-Observation的循环，直到得出最终答案。

ReAct的工作循环：

Thought：模型分析当前状态，推理下一步应该做什么
Action：模型决定调用哪个工具，生成调用参数
Observation：应用层执行工具，将结果返回给模型
重复上述循环，直到模型认为可以给出最终答案

ReAct与Function Calling的区别：

维度ReActFunction Calling

推理过程	显式展示思考过程（Thought）	不一定展示推理过程
适用范围	通用Prompt模式，任何模型可用	需要模型原生支持
多步推理	天然支持多轮思考-行动循环	通常单次调用，需应用层编排多步
可控性	通过Prompt引导，可控性较低	通过Schema约束，可控性较高
可解释性	Thought过程提供可解释性	输出较简洁，可解释性低

实践建议：

简单工具调用场景优先用Function Calling，更可靠
复杂多步推理场景考虑ReAct或ReAct+Function Calling结合
可以在Function Calling基础上加入Thought步骤，兼顾可靠性和可解释性

面试加分点：知道ReAct论文的核心贡献是将推理和行动交替进行；理解ReAct与Plan-and-Execute（先规划再执行）的区别；能说出ReAct在工具选择错误时的自我纠偏能力；了解ReAct模式的Token消耗较高（因为要输出Thought）。

21. 当Agent有多个可用工具时，如何优化工具选择的准确性？

参考答案：

多工具场景下的工具选择是Agent开发的核心挑战。模型需要在众多工具中正确选择最合适的工具，避免选错、漏选或重复调用。

优化策略：

工具描述精细化：

每个工具的描述应包含：功能说明、适用场景、不适用场景、参数含义和约束
用示例说明何时用这个工具、何时不用
避免工具描述之间的模糊重叠

工具分组与分层：

按领域或功能分组，减少单次决策的候选数量
两级路由：先用路由工具选择类别，再在类别内选择具体工具
限制同时暴露的工具数量（一般建议不超过10-15个）

工具命名规范：

工具名应语义清晰、自解释
使用一致的命名约定（如search_xxx、create_xxx、delete_xxx）
避免模糊名称如get_data、process

Few-Shot引导：

在系统Prompt中给出典型的工具选择示例
展示相似但不同的查询应该选择不同工具的案例

工具选择校验：

在应用层对模型选择的工具做合理性校验
如果选择了明显不合适的工具，可以提示模型重新选择

动态工具加载：

根据用户意图动态加载相关工具子集
先用一个轻量级分类器判断意图，再加载对应工具集

面试加分点：知道工具数量过多会导致模型困惑（类似选择题选项过多效应）；理解工具描述的措辞对模型选择行为有显著影响；能说出如何通过A/B测试优化工具描述；了解工具选择的评估方法（工具选择准确率、误调用率等）。

22. 工具调用失败时应该如何处理？设计一个完善的错误处理机制

参考答案：

工具调用失败是Agent系统中的常见情况，完善的错误处理机制直接影响系统的健壮性和用户体验。

常见错误类型：

参数错误：模型生成的参数不合法（类型错误、缺失必填项、值超出范围）
执行错误：工具执行过程中的错误（网络超时、权限不足、资源不存在）
结果异常：工具执行成功但返回异常结果（空结果、格式不符、数据异常）
超时：工具执行时间过长

错误处理策略：

参数校验前置：在调用工具前，用JSON Schema校验模型生成的参数，不合法时直接反馈模型重新生成，而非执行失败后报错。

错误信息回传：将错误信息以结构化方式回传给模型，包含：

错误类型和描述
错误原因分析
建议的修正方向模型可以基于这些信息调整参数重试。

重试机制：

对临时性错误（网络超时、服务繁忙）设置自动重试，配合指数退避
对参数错误，将错误反馈给模型让其修正参数后重试
设置最大重试次数（通常2-3次），避免无限循环

降级策略：

工具不可用时，尝试用替代工具
无替代工具时，告知用户限制并给出基于模型自身知识的回答（标注不确定性）
对非关键工具，跳过并继续执行后续步骤

熔断机制：当某个工具连续失败超过阈值时，暂时禁用该工具，避免反复失败浪费资源。

日志与监控：记录所有工具调用的成功/失败情况、错误类型、重试次数等，用于后续分析和优化。

面试加分点：能说出错误信息回传给模型时的Prompt设计技巧（如何描述错误让模型有效修正）；理解不同错误类型需要不同的处理策略；知道如何平衡重试次数和用户体验；了解工具调用失败时的用户沟通策略（何时告知用户、如何表述）。

23. Agent的记忆机制有哪些？如何设计Agent的长期和短期记忆？

参考答案：

记忆机制是Agent实现持续交互和个性化服务的基础。类似人类的记忆系统，Agent的记忆也分为短期记忆和长期记忆。

短期记忆（工作记忆）：

对话上下文：当前会话内的消息历史，是最基本的短期记忆
实现方式：直接将历史消息作为上下文放入Prompt中
限制：受上下文窗口大小限制，无法保留过多历史
管理策略：
- 滑动窗口：保留最近N轮对话
- 摘要压缩：将早期对话压缩为摘要
- 选择性保留：只保留关键信息（用户偏好、关键决策、待办事项）

长期记忆：

跨会话记忆：在多个会话之间持久化的记忆
实现方式：
- 向量数据库存储：将记忆内容Embedding后存入向量库，需要时检索
- 键值存储：按类别存储结构化信息（用户偏好、事实记录等）
- 知识图谱：存储实体和关系，支持复杂查询
- 文件系统：将记忆写入文件，按需读取

记忆管理策略：

记忆写入：

显式触发：用户说"记住这个"时主动存储
隐式提取：从对话中自动识别值得记忆的信息（偏好、事实、决策）
重要性评估：对记忆内容打分，只存储重要信息

记忆检索：

语义检索：根据当前对话内容检索相关记忆
时间衰减：近期记忆权重更高
频率加权：经常被引用的记忆权重更高

记忆更新与遗忘：

过时信息更新或删除
冲突信息合并或覆盖
低重要性记忆定期清理

面试加分点：能说出不同记忆方案的优劣（向量检索vs结构化查询）；理解记忆系统的核心挑战是"什么该记"和"什么该回忆"；知道如何评估记忆系统的效果；了解记忆系统中的隐私保护问题。

24. 多轮对话管理有哪些核心挑战？如何设计一个高效的多轮对话系统？

参考答案：

多轮对话管理是AI应用开发的核心能力，涉及上下文维护、状态管理、意图理解等多个方面。

核心挑战：

上下文长度限制：随着对话轮数增加，上下文可能超出窗口限制

指代消解：用户说"它的价格呢"，需要理解"它"指代什么

话题切换：用户可能在对话中切换话题，需要识别和管理话题边界

意图变化：同一对话中用户意图可能演变（从查询转为操作）

状态管理：跨轮次的状态维护（如已收集的信息、待确认的事项）

上下文污染：早期对话中的错误信息可能影响后续回答

设计策略：

上下文管理：

滑动窗口 + 摘要：近期对话保留原文，早期对话压缩为摘要
结构化上下文：将对话中的关键信息提取为结构化状态，而非保留全部原文
上下文裁剪：根据当前问题相关性，动态选择历史消息

状态管理：

对话状态跟踪（DST）：维护一个结构化的对话状态对象，记录已收集的槽位、用户意图、待确认项
状态机模式：定义对话流程的状态机，根据状态决定下一步行为
意图路由：根据用户当前意图动态切换处理逻辑

对话策略：

澄清机制：当用户意图不明确时，主动提问澄清
确认机制：关键操作前要求用户确认
主动引导：在完成任务后主动提供相关建议

工程实现要点：

每轮对话后更新对话状态，而非依赖模型从历史中推断
将对话状态序列化存储，支持断点续传
设计对话中断和恢复机制（用户中途离开再回来）
监控对话质量指标（完成率、轮次数、用户满意度）

面试加分点：能说出对话状态跟踪的经典方法；理解纯Prompt方案与结构化状态管理方案的优劣；知道如何在多轮对话中处理工具调用状态；了解多模态对话（语音+文本+图像）的额外挑战。

四、工程实践必问6题

25. 如何管理Prompt模板？有哪些最佳实践？

参考答案：

Prompt模板管理是AI应用工程化的基础，直接影响代码可维护性和Prompt质量。

常见管理方式：

代码硬编码：将Prompt直接写在代码字符串中。简单场景可用，但不利于维护和迭代。

模板文件：将Prompt存为独立文件（如.txt、.jinja2、.yaml），代码中按需加载。支持模板语法（变量插值、条件判断、循环等）。

模板管理系统：构建或使用专门的Prompt管理平台，支持版本控制、A/B测试、效果监控、在线编辑等。

配置化：将Prompt作为配置项存入数据库或配置中心，支持动态更新而无需发版。

最佳实践：

模板设计：

使用模板引擎（如Jinja2）实现变量插值和逻辑控制
将系统Prompt和用户Prompt分离管理
Prompt中明确标注变量位置，使用统一的占位符语法（如{{variable}}）
模板中包含输出格式说明和Few-Shot示例的区域

版本管理：

对Prompt进行版本控制，每次修改记录变更原因和效果
支持回滚到历史版本
不同环境（开发、测试、生产）使用不同版本

质量保证：

为每个Prompt编写测试用例，验证输出格式和内容
建立Prompt评测集，定期回归测试
监控线上Prompt的输出质量指标

模块化：

将常用Prompt片段（如输出格式说明、约束条件）抽为可复用的子模板
按功能模块组织Prompt（如摘要模板、分类模板、抽取模板）
支持模板继承和组合

面试加分点：知道Prompt即代码的理念；理解Prompt版本管理的重要性（Prompt微小修改可能导致行为剧变）；能说出如何设计Prompt的A/B测试；了解Prompt缓存对成本优化的作用；知道如何处理多语言场景下的Prompt管理。

26. 大模型输出校验与重试机制如何设计？

参考答案：

大模型的输出具有不确定性，生产环境中必须设计完善的校验与重试机制来保证可靠性。

输出校验层次：

格式校验：

JSON合法性检查：解析JSON是否成功
Schema校验：用JSON Schema或Pydantic校验字段完整性、类型正确性
枚举值校验：检查是否在允许的取值范围内

内容校验：

空值检查：关键字段不能为空
长度检查：输出是否在合理长度范围内
敏感词检查：是否包含违规内容
事实性校验：对关键事实进行交叉验证

业务校验：

业务规则校验：输出是否满足业务约束（如金额不能为负、日期不能在未来）
一致性校验：多字段之间的逻辑一致性
引用校验：如果输出包含引用，验证引用是否真实存在

重试策略设计：

重试条件：

格式错误：可以重试，在Prompt中补充错误提示
内容不达标：可以重试，调整Prompt或增加约束
业务校验失败：可以重试，但需要分析原因

重试方式：

简单重试：直接重新调用，适用于偶发错误
反馈重试：将错误信息加入Prompt，让模型修正。例如：“上一次输出缺少required字段’price’，请重新输出完整的JSON”
参数调整重试：降低Temperature、增加Few-Shot示例后重试
换方案重试：多次重试失败后，换用更简单的Prompt或换用结构化输出方式

重试控制：

最大重试次数：通常2-3次
重试间隔：指数退避，避免突发流量
熔断：连续失败时暂时降级
兜底方案：重试耗尽后返回默认值或转人工

工程实现建议：

用装饰器或中间件统一处理校验和重试逻辑，业务代码无需关心
记录每次重试的原因和结果，用于分析优化
对重试场景做监控告警，重试率过高说明Prompt或参数需要优化

面试加分点：能说出"反馈重试"比"简单重试"效果好的原因（模型知道哪里错了才能修正）；理解重试机制对成本的影响（重试增加Token消耗）；知道如何平衡可靠性和延迟；了解约束解码可以从根本上消除格式校验失败的问题。

27. 大模型应用的成本优化有哪些策略？

参考答案：

大模型应用的成本主要由Token消耗量决定，优化成本是工程实践中的重要课题。

Prompt层面优化：

Prompt精简：去除冗余描述，精简指令，减少不必要的示例。用简洁的Prompt达到同样效果。

Few-Shot优化：减少示例数量，或使用更短的示例。在效果允许的前提下，2个示例通常比5个更经济。

系统Prompt缓存：部分API支持Prompt缓存，将固定的系统Prompt缓存后，后续请求只需发送变化部分，大幅降低成本。

上下文裁剪：只保留与当前问题最相关的上下文，去除冗余信息。用摘要替代原始长文本。

模型选择优化：

分级使用：根据任务复杂度选择不同级别的模型。简单分类用小模型，复杂推理用大模型。

路由策略：先用轻量级模型判断查询复杂度，再路由到合适的模型。

微调小模型：对特定任务微调小模型，可能达到接近大模型的效果，但推理成本大幅降低。

架构层面优化：

缓存结果：对相同或相似的查询缓存结果。可以用语义相似度判断是否命中缓存。

批量处理：将多个请求合并为批量请求，部分API提供批量折扣。

异步处理：非实时场景使用异步处理，利用低峰时段资源。

RAG优化：减少不必要的文档检索和上下文传递，通过精准检索减少Token消耗。

运行时优化：

Max Tokens限制：设置合理的最大输出Token数，避免模型生成冗长内容。

提前终止：检测到模型已经输出完整答案时提前终止生成。

流式中断：用户主动中断时立即停止生成，节省Token。

监控与分析：

建立Token消耗监控面板，按功能模块、用户、时间维度分析
定期审计Prompt效率，淘汰低效Prompt
设置成本预算和告警

面试加分点：能说出Prompt缓存的技术原理和适用条件；理解微调小模型与使用大模型+RAG的成本对比；知道如何评估不同优化策略对质量的影响；了解模型量化和蒸馏在降低部署成本中的作用。

28. 如何对大模型应用进行A/B测试？有哪些注意事项？

参考答案：

A/B测试是验证大模型应用改动效果的科学方法，但与传统Web应用的A/B测试有显著差异。

测试设计：

确定指标：

业务指标：用户满意度、任务完成率、转化率、留存率
质量指标：回答准确率、幻觉率、相关性、完整性
效率指标：响应延迟、Token消耗、成本
用户指标：点赞/踩比例、反馈评分、复访率

确定变量：

Prompt版本（措辞、结构、Few-Shot示例）
Temperature等采样参数
模型选择（不同级别模型）
RAG配置（分块策略、Top-K、重排序）
工具定义和选择策略

流量分配：

随机分流：用户随机分配到A组或B组
确保同一用户始终在同一组，避免体验不一致
样本量计算：根据预期效果大小和统计显著性要求计算

注意事项：

输出的非确定性：大模型的输出具有随机性，同一用户同一问题可能得到不同回答。需要更多样本量来消除噪音。

评估困难：大模型输出是自然语言，难以自动化评估。常用方法：

人工评估：标注员对输出质量打分
模型评估：用另一个模型做评判（LLM-as-a-Judge）
规则评估：对结构化输出做规则校验
用户反馈：收集用户隐式和显式反馈

延迟差异：不同Prompt或模型的延迟可能不同，用户可能感知到差异，影响测试公平性。

多变量测试：同时测试多个变量时，需要多变量测试（MVT）或正交实验设计。

长期效应：短期A/B测试可能无法捕捉长期效应（如用户学习效应、内容质量长期变化）。

伦理考虑：确保B组用户不会得到明显更差的服务，设置质量底线。

面试加分点：知道LLM-as-a-Judge的方法和局限性；理解大模型A/B测试的样本量计算与传统Web测试的不同；能说出如何处理评估中的主观性问题；知道如何在A/B测试中同时评估多个维度（质量vs成本vs延迟）。

29. 大模型应用的灰度发布策略是怎样的？

参考答案：

灰度发布是大模型应用从开发到全量上线的关键环节，目的是在可控范围内验证新版本的效果和稳定性。

灰度发布流程：

一、发布前准备：

离线评测：在评测集上验证新版本的关键指标（准确率、格式合规率、延迟等）

回归测试：确保新版本不引入已知问题的回归

影子测试（Shadow Testing）：新版本与旧版本并行处理真实流量，但只返回旧版本结果，对比差异

安全检查：内容安全、敏感词、越狱防护等检查

二、灰度策略：

按流量比例：从1%开始逐步放量（1% → 5% → 10% → 50% → 100%）

按用户分群：

内部用户先行 → 小范围真实用户 → 逐步扩大
按用户标签分群（新用户vs老用户、免费vs付费）

按功能模块：先灰度非核心功能，再灰度核心功能

按场景：先灰度低风险场景（如FAQ），再灰度高风险场景（如交易决策）

三、监控与决策：

实时监控指标：

质量指标：输出准确率、格式合规率、用户反馈
稳定性指标：错误率、超时率、重试率
性能指标：延迟分布、吞吐量
成本指标：Token消耗、API费用

告警机制：

设置关键指标的阈值告警
设置自动回滚触发条件（如错误率超过5%自动回滚）
人工值守关键灰度阶段

决策点：

指标达标 → 继续放量
指标异常 → 暂停灰度，分析原因
指标严重恶化 → 立即回滚

四、回滚机制：

版本切换：保留旧版本，可以一键切换
流量切换：通过配置中心调整流量分配
数据兼容：确保新旧版本的数据格式兼容，回滚不影响已有数据

面试加分点：知道影子测试与传统A/B测试的区别；理解大模型应用的灰度发布比传统应用更复杂（输出不确定性、评估困难）；能说出如何设计自动回滚策略；了解canary release和blue-green deployment在大模型场景下的适用性。

30. 大模型应用上线前需要检查哪些事项？请列出一份完整的检查清单

参考答案：

大模型应用上线前的检查清单是保障系统稳定性和安全性的最后一道防线。

一、功能与质量检查：

核心功能测试通过：所有主要用户路径已测试
输出格式校验：结构化输出符合Schema要求，格式错误率低于阈值
输出质量评估：在评测集上的准确率、相关性、完整性达标
边界case测试：空输入、超长输入、特殊字符、多语言输入
多轮对话测试：上下文保持、指代消解、话题切换
工具调用测试：所有工具的正确调用、参数校验、错误处理
Prompt版本确认：使用正确的Prompt版本，无遗留的调试Prompt

二、安全与合规检查：

越狱防护：已测试常见越狱攻击（角色扮演、指令注入、编码绕过等）
内容安全：敏感词过滤、违规内容检测已启用
数据脱敏：用户输入和模型输出中的敏感信息已脱敏
权限控制：工具调用的权限校验已配置
审计日志：所有请求和响应已记录，支持追溯
合规要求：满足GDPR、个人信息保护法等法规要求
隐私政策：用户已知晓并同意数据处理方式

三、性能与稳定性检查：

延迟测试：P50/P95/P99延迟在可接受范围内
吞吐量测试：支持预期的并发量
限流配置：API调用频率限制已配置
超时设置：请求超时、流式超时已合理配置
降级方案：模型不可用时的降级策略已实现
重试策略：重试次数、间隔、熔断阈值已配置
成本预算：Token消耗预算已设置，超额告警已配置

四、监控与运维检查：

监控面板：质量指标、性能指标、成本指标监控已就位
告警规则：关键指标告警阈值已配置
日志系统：请求日志、错误日志、审计日志已配置
灰度策略：灰度发布计划已制定
回滚方案：回滚流程已验证
值班安排：上线后的on-call安排已确认
应急预案：已知问题的应急处理流程已文档化

五、用户体验检查：

流式响应：流式输出体验正常
错误提示：用户可见的错误信息友好且不泄露技术细节
加载状态：等待时有适当的加载提示
中断处理：用户中断请求后行为正常
移动端适配：移动端体验正常

面试加分点：能根据业务场景定制检查清单（如医疗场景需要额外的合规检查）；理解大模型应用上线检查与传统应用的不同之处（输出不确定性、安全边界不同）；知道如何建立自动化的上线前检查流水线；了解上线后的持续监控和迭代优化策略。

总结

本文覆盖了AI应用开发工程师面试中最高频的30道题目，从大模型核心原理到向量检索、从工具调用到工程实践，每道题都包含了原理讲解、实践要点和面试加分点。准备面试时建议重点关注：

理解原理而非记忆答案：面试官更看重你对原理的理解深度，而非标准答案的背诵

结合项目经验：能用自己的项目经验佐证理解，比纯理论回答更有说服力

关注工程实践：原理知识是基础，但工程实践能力是区分水平的关键

保持学习：AI领域发展迅速，面试题也在不断更新，持续学习是根本

后续文章将继续覆盖Prompt工程进阶、RAG系统优化、Agent架构设计等深入主题，敬请关注。