Appearance
AI 应用开发面试题
覆盖六大知识模块的高频面试题，附回答框架和实战经验
学习目标
- 掌握 AI 应用开发岗位的核心面试考点
- 学会用结构化框架回答技术问题
- 理解面试官的考察意图，给出有深度的回答
使用建议： 每道题先自己思考 2 分钟，再看参考回答。重点不是背答案，而是理解背后的思路。面试中结合自己的项目经验回答效果最好。
第一部分：基础知识
Q1: Python 中的类型提示（Type Hints）在 AI 项目中有什么实际作用？
考察点： 工程化意识
类型提示不只是代码规范，在 AI 项目中有实际工程价值：
- Pydantic 数据校验：LLM 返回的结构化数据通过 Pydantic 模型自动校验，类型提示是基础
- IDE 补全和重构：AI 项目依赖大量 SDK，类型提示让 IDE 能准确补全
- 团队协作：Prompt 模板、API 响应结构等通过类型定义，减少沟通成本
- 运行时校验：FastAPI 自动根据类型提示做请求参数校验
Q2: async/await 在 AI 应用中为什么重要？
考察点： 并发模型理解
LLM API 调用是典型的 I/O 密集型操作（网络请求耗时 1-10 秒），异步编程可以：
- 并发调用多个模型：同时请求 GPT-4o 和 Claude 做对比，总耗时等于最慢的那个
- 流式响应处理：
async for逐 Token 处理流式输出 - 高吞吐服务：FastAPI + async 可以同时处理大量并发请求，不会因为等待 LLM 响应而阻塞
关键区别： 异步不是多线程。Python 的 asyncio 是单线程事件循环，适合 I/O 密集场景；CPU 密集任务（如 Embedding 计算）需要多进程。
Q3: Transformer 架构的核心创新是什么？
考察点： 基础理论
Self-Attention 机制——让模型在处理每个 Token 时能"看到"输入序列中的所有其他 Token，并根据相关性分配不同权重。
相比 RNN/LSTM 的优势：
- 并行计算：不需要按顺序处理，训练速度大幅提升
- 长距离依赖：任意两个 Token 之间只需一步注意力计算，不存在信息衰减
- 可扩展性：架构简单统一，容易通过增加参数量来提升能力
加分回答： 提到 Multi-Head Attention（多头注意力让模型从不同子空间捕获不同类型的关系）和 Positional Encoding（弥补 Attention 机制缺乏位置信息的问题）。
Q4: 什么是 Chain-of-Thought（CoT）？什么场景下用？
考察点： Prompt Engineering 实战
CoT 是让模型"分步思考"的提示技术，通过在 Prompt 中加入推理步骤示例，引导模型输出中间推理过程。
适用场景： 数学计算、逻辑推理、多步决策、代码调试 不适用场景： 简单事实问答、翻译、分类（反而会增加延迟和成本）
实战技巧：
- Zero-shot CoT：直接加"让我们一步步思考"
- Few-shot CoT：给出带推理步骤的示例
- 推理模型（o3、DeepSeek-R1）已内置 CoT，不需要手动引导
第二部分：核心技术栈
Q5: 你们项目是怎么选模型的？
考察点： 工程决策能力（高频题）
回答框架：
- 先说业务场景和核心需求（任务类型、质量要求、延迟要求）
- 再说评估了哪些候选模型，用什么指标对比
- 最后说选择结果和理由，以及成本和 fallback 方案
示例回答：
我们做的是企业知识库问答，核心需求是中文理解准确、延迟 <3s、月成本控制在 $500 以内。评估了 GPT-4o、Claude Sonnet、DeepSeek-V3 三个模型，用 200 条标注数据做了准确率和延迟测试。最终选了 GPT-4o mini 做主力（准确率 92%，满足需求），GPT-4o 做复杂问题的 fallback，月成本约 $200。
面试忌讳： 只说"我们用的 GPT-4o"。面试官想听的是选型过程和工程思考，不是模型名字。
Q6: 闭源模型和开源模型怎么选？
考察点： 技术选型权衡
| 选闭源 | 选开源 |
|---|---|
| 快速验证 MVP | 数据不能出内网 |
| 团队没有 GPU 运维能力 | 需要深度定制（微调） |
| 追求最强综合能力 | 长期成本敏感（大规模调用） |
| 不涉及敏感数据 | 有合规硬性要求 |
加分回答： 提到混合方案——开发测试用闭源 API 快速迭代，生产环境用开源模型降低成本和合规风险。
Q7: 推理模型和通用模型有什么区别？什么时候用？
考察点： 模型能力理解
推理模型（如 o3、DeepSeek-R1）在回答前会进行内部思考（Chain-of-Thought），擅长数学、编程、复杂逻辑分析。代价是更慢、更贵（Token 消耗 3-10 倍）。
- 用推理模型： 数学证明、复杂代码生成、多步逻辑推理、数据分析
- 用通用模型： 日常对话、内容生成、翻译、简单问答
关键点： 不要滥用推理模型。80% 的场景通用模型就够了，推理模型用在刀刃上。
Q8: 怎么控制 LLM API 成本？
考察点： 成本意识（企业非常看重）
按优先级：
- Prompt 工程 — 精简 prompt，减少不必要的 token
- 模型分级路由 — 简单任务用便宜模型，复杂任务用强模型
- 缓存 — Prompt Caching + 响应缓存
- Batch API — 非实时任务用批量接口，享受 50% 折扣
加分回答： 给出具体数字。比如"通过模型路由，我们把 80% 的简单问答路由到 mini 模型，月成本从 $2000 降到 $400"。
Q9: Function Calling 的工作原理是什么？和直接让 LLM 输出 JSON 有什么区别？
考察点： 核心机制理解
Function Calling 是模型原生支持的结构化输出能力：
- 开发者定义函数的 JSON Schema（名称、参数、描述）
- 模型根据用户意图决定是否调用函数，并生成符合 Schema 的参数
- 开发者执行函数，将结果返回给模型继续对话
vs 直接输出 JSON：
- Function Calling 有 Schema 约束，输出格式更可靠
- 模型经过专门训练，函数选择和参数生成准确率更高
- 支持并行调用多个函数
- 直接输出 JSON 容易格式错误，需要额外的解析和重试逻辑
Q10: 解释 RAG 的完整流程，以及每个环节的关键挑战
考察点： RAG 系统设计能力（核心高频题）
完整流程：
- 文档处理 → 加载、清洗、分块（Chunking）
- 向量化 → 用 Embedding 模型将文本块转为向量
- 索引存储 → 存入向量数据库（Pinecone/Milvus/pgvector 等）
- 检索 → 用户查询向量化后，从向量库中检索 Top-K 相关文档
- 生成 → 将检索到的文档作为上下文，连同用户问题一起发给 LLM 生成回答
各环节关键挑战：
| 环节 | 挑战 | 解决方案 |
|---|---|---|
| 分块 | 块太大信息冗余，太小丢失上下文 | 语义分块、重叠窗口、递归分块 |
| 检索 | 语义相似 ≠ 问题相关 | 混合检索（向量 + BM25）、Reranker 重排序 |
| 生成 | 幻觉——模型编造不在上下文中的信息 | 要求引用来源、设置低 temperature、添加 Guardrails |
Q11: 向量搜索中，余弦相似度和欧氏距离有什么区别？什么时候用哪个？
考察点： Embedding 基础
- 余弦相似度：衡量方向相似性，忽略向量长度。适合文本语义搜索（归一化后的 Embedding）
- 欧氏距离（L2）：衡量空间中的绝对距离。适合需要考虑"量级"的场景
实际选择： 大多数文本 Embedding 模型输出的向量已经归一化，此时余弦相似度和 L2 距离等价。默认用余弦相似度即可。
第三部分：框架与工具
Q12: LangChain 和 LlamaIndex 有什么区别？怎么选？
考察点： 框架选型
| 维度 | LangChain | LlamaIndex |
|---|---|---|
| 核心定位 | 通用 LLM 应用编排框架 | 数据索引和检索框架 |
| 擅长场景 | Agent、工作流、多步链式调用 | RAG、知识库、文档问答 |
| 灵活性 | 高，组件可自由组合 | 中，围绕索引和查询设计 |
| 学习曲线 | 较陡，抽象层多 | 较平，API 直观 |
选型建议：
- 做 RAG/知识库 → LlamaIndex 更直接
- 做 Agent/复杂工作流 → LangChain（特别是 LangGraph）
- 两者可以混用：LlamaIndex 做检索，LangChain 做编排
Q13: 什么是 AI Agent？和普通的 LLM 调用有什么区别？
考察点： Agent 概念理解
Agent = LLM + 工具调用 + 自主决策循环
普通 LLM 调用是"一问一答"，Agent 是"接到任务后自主规划、调用工具、观察结果、迭代执行直到完成"。
Agent 的核心组件：
- 规划（Planning）：将复杂任务分解为子步骤
- 工具（Tools）：搜索、代码执行、API 调用、数据库查询等
- 记忆（Memory）：短期（对话上下文）+ 长期（向量存储）
- 反思（Reflection）：检查中间结果，必要时调整策略
关键挑战： 控制循环次数（防止无限循环）、错误恢复、成本控制。
Q14: MCP 协议解决了什么问题？
考察点： 前沿技术了解
MCP（Model Context Protocol）是 Anthropic 提出的开放协议，标准化了 LLM 与外部工具/数据源的连接方式。
解决的问题： 之前每个 AI 应用都要为每个工具写定制集成代码（M×N 问题）。MCP 定义了统一的 Client-Server 协议，工具提供方只需实现一次 MCP Server，所有支持 MCP 的 AI 应用都能直接使用。
类比： USB 接口之于外设，MCP 之于 AI 工具集成。
第四部分：应用实践
Q15: 设计一个智能客服系统，你会怎么做？
考察点： 系统设计能力（高频题）
架构要点：
- 意图识别 → 分类用户问题（FAQ / 知识库查询 / 需要人工）
- 知识库检索 → RAG 从企业文档中检索相关信息
- 回答生成 → LLM 基于检索结果生成回答
- 多轮对话 → 维护对话历史，支持上下文追问
- 兜底机制 → 置信度低时转人工
关键设计决策：
- 模型选择：高频简单问题用 mini 模型，复杂问题路由到强模型
- 知识库更新：支持增量更新，不需要全量重建索引
- 评估指标：回答准确率、用户满意度、转人工率、平均响应时间
Q16: 流式输出（Streaming）在前端怎么实现？为什么重要？
考察点： 全栈能力
为什么重要： LLM 生成完整回答可能需要 3-10 秒，流式输出让用户在 200ms 内就能看到第一个字，感知延迟大幅降低。
实现方式：
- SSE（Server-Sent Events）：最常用，服务端推送，浏览器原生支持
- WebSocket：双向通信，适合需要中断生成的场景
- 前端渲染：逐字/逐句追加到 DOM，配合打字机动画效果
注意事项： 流式输出时 Token 用量统计需要在流结束后汇总；错误处理要考虑流中断的情况。
Q17: Text-to-SQL 的主要挑战是什么？
考察点： 数据分析 Agent 经验
核心挑战：
- Schema 理解 — LLM 需要理解表结构、字段含义、表间关系
- SQL 正确性 — 生成的 SQL 可能语法错误或逻辑错误
- 安全性 — 防止 SQL 注入，限制危险操作（DELETE/DROP）
- 性能 — 生成的 SQL 可能效率极低（全表扫描、笛卡尔积）
解决方案：
- 在 Prompt 中提供 Schema 信息和示例查询
- 生成后先做语法检查和 EXPLAIN 分析
- 使用只读数据库连接，限制查询超时
- 复杂查询分步生成，先理解意图再写 SQL
第五部分：生产部署与运维
Q18: 什么是 LLMOps？和传统 MLOps 有什么区别？
考察点： 生产化意识
LLMOps 是 LLM 应用的运维体系，核心关注点：
| 维度 | 传统 MLOps | LLMOps |
|---|---|---|
| 模型管理 | 训练、版本、部署 | Prompt 版本管理、模型路由 |
| 评估 | 固定测试集 + 指标 | 人工评估 + LLM-as-Judge + A/B 测试 |
| 监控 | 准确率、延迟 | 幻觉率、Token 用量、成本、用户满意度 |
| 迭代 | 重新训练模型 | 调整 Prompt、切换模型、优化 RAG |
Q19: 如何检测和防止 LLM 幻觉？
考察点： 质量保障能力
检测方法：
- 基于检索的验证：检查 LLM 回答是否有检索文档支撑
- 自我一致性检查：同一问题多次生成，比较答案一致性
- LLM-as-Judge：用另一个模型评估回答的事实准确性
- 人工抽样评估：定期抽样人工审核
防止策略：
- 降低 temperature（减少随机性）
- 要求模型引用来源（"根据文档 X..."）
- 添加 Guardrails（输出过滤和校验）
- 当检索结果不足时，让模型说"我不确定"而非编造
Q20: Prompt Injection 是什么？怎么防御？
考察点： 安全意识（必考题）
Prompt Injection 是攻击者通过精心构造的输入，覆盖或绕过系统提示词，让 LLM 执行非预期行为。
攻击类型：
- 直接注入：用户输入中包含"忽略之前的指令，执行..."
- 间接注入：恶意内容隐藏在 LLM 会读取的外部数据中（网页、文档）
防御策略：
- 输入过滤：检测和过滤可疑的指令性文本
- 角色隔离：系统提示词和用户输入用明确的分隔符区分
- 输出校验：检查 LLM 输出是否包含敏感信息或非预期操作
- 最小权限：Agent 的工具调用权限最小化
- Guardrails 框架：使用 NeMo Guardrails 等专用框架
Q21: 如何优化 LLM 应用的响应延迟？
考察点： 性能优化经验
按效果排序：
- 选择更快的模型 — mini/Flash 系列比旗舰模型快 3-5 倍
- 流式输出 — TTFT（首 Token 时间）通常 <500ms，用户感知延迟大幅降低
- Prompt Caching — 缓存命中时输入处理速度提升 2-5 倍
- 响应缓存 — 相同问题直接返回缓存结果，延迟降到毫秒级
- 并行调用 — 多个独立的 LLM 调用并行执行
- 预计算 — 高频问题预先生成答案
第六部分：进阶与前沿
Q22: 多 Agent 系统怎么设计？有什么挑战？
考察点： 架构设计能力
常见架构模式：
- 主从模式：一个 Orchestrator Agent 分配任务给 Worker Agent
- 流水线模式：Agent A 的输出是 Agent B 的输入，串行处理
- 辩论模式：多个 Agent 对同一问题给出不同观点，最终综合
核心挑战：
- 通信开销：Agent 间传递信息消耗大量 Token
- 错误传播：一个 Agent 的错误会影响下游所有 Agent
- 调试困难：多 Agent 交互的中间状态难以追踪
- 成本爆炸：N 个 Agent × M 轮交互 = 巨大的 Token 消耗
实战建议： 能用单 Agent 解决的问题不要用多 Agent。多 Agent 适合任务天然可分解且子任务需要不同专业能力的场景。
Q23: LoRA 微调的原理是什么？什么时候需要微调？
考察点： 模型定制能力
LoRA 原理： 冻结原始模型权重，在每层注入低秩分解矩阵（A × B），只训练这些小矩阵。参数量通常只有原模型的 0.1%-1%，大幅降低训练成本。
需要微调的场景：
- 特定领域的专业术语和风格（法律、医疗）
- 特定输出格式的严格遵循
- Prompt 工程无法达到的质量要求
- 需要降低推理成本（微调小模型替代大模型）
不需要微调的场景：
- Prompt 工程 + Few-shot 就能解决
- 需求经常变化（微调成本高，迭代慢）
- 训练数据不足（<1000 条高质量样本）
Q24: 你怎么看 AI Agent 的未来发展？
考察点： 技术视野
回答要点（言之有据，不空谈）：
- 工具生态标准化：MCP 等协议让 Agent 能即插即用地连接各种工具和数据源
- 推理能力提升：推理模型让 Agent 能处理更复杂的多步任务
- 多模态融合：Agent 不仅处理文本，还能理解图片、操作 GUI、生成代码并执行
- 可靠性挑战：当前 Agent 在长链路任务中的成功率仍然不高，错误累积是核心瓶颈
- 人机协作：短期内更现实的方向是 Human-in-the-Loop，而非完全自主
综合题
Q25: 从零搭建一个 RAG 知识库问答系统，说说你的技术方案
考察点： 综合系统设计能力（终面常见题）
回答框架：
1. 数据层
- 文档加载：支持 PDF/Word/Markdown/网页
- 分块策略：递归分块，chunk_size=512，overlap=50
- Embedding：选择适合中文的模型（如 BGE-M3）
2. 存储层
- 向量数据库：pgvector（已有 PostgreSQL）或 Milvus（大规模）
- 元数据存储：文档来源、更新时间、权限标签
3. 检索层
- 混合检索：向量检索 + BM25 关键词检索
- Reranker：用 Cross-Encoder 对 Top-20 结果重排序，取 Top-5
- Query 改写：对模糊查询做扩展和改写
4. 生成层
- 模型选择：GPT-4o mini（主力）+ GPT-4o（fallback）
- Prompt 设计：包含角色定义、检索上下文、回答要求、引用格式
- 流式输出：SSE 推送到前端
5. 运维层
- 评估：准确率、召回率、用户满意度
- 监控：Token 用量、延迟、幻觉率
- 迭代：根据 bad case 优化分块策略和 Prompt
面试技巧
回答原则
- 先说结论，再展开 — 面试官时间有限，先给答案再解释
- 结合项目经验 — "在我们的项目中..."比纯理论有说服力 10 倍
- 给具体数字 — "准确率从 85% 提升到 93%"比"效果提升了很多"好
- 承认不知道 — 不确定的问题说"这个我了解不深，但我的理解是..."，比胡编好
常见追问方向
面试官在你回答后通常会追问：
- "遇到过什么问题？怎么解决的？" → 准备 2-3 个踩坑故事
- "如果规模扩大 10 倍怎么办？" → 思考扩展性
- "有没有考虑过其他方案？为什么没选？" → 展示技术广度
- "成本是多少？怎么优化的？" → 展示成本意识