跳到主要内容

Agent / AI 面经

核心考点​

1. LLM 基础​

  • Transformer 架构：Encoder-Decoder，注意力机制（Attention）是核心
  • Self-Attention：Q、K、V 矩阵，计算 token 间相关性
  • 位置编码：解决序列顺序问题（绝对/相对/RoPE）
  • Temperature & Top-p：控制输出随机性；Temperature 越低越确定
  • 上下文窗口：模型一次能处理的最大 token 数

2. Prompt 工程​

  • Zero-shot：直接提问，无示例
  • Few-shot：提供少量示例引导输出格式
  • Chain-of-Thought (CoT)：让模型逐步推理，提升复杂任务准确性
  • System Prompt：设定角色和行为约束
  • Prompt 注入攻击：用户输入覆盖系统指令，需做输入过滤

3. RAG（检索增强生成）​

用户问题 → 向量化 → 向量数据库检索 → 相关文档 → 拼入 Prompt → LLM 生成答案
  • 向量数据库：Pinecone、Qdrant、Chroma、Milvus
  • Embedding 模型：将文本转为高维向量（如 text-embedding-3-small）
  • Chunk 策略：固定大小 / 语义分割；重叠窗口避免信息截断
  • Re-ranking：检索后用精排模型提升相关性

4. Agent 设计模式​

  • ReAct：Reasoning + Acting，思考→动作→观察循环
  • Plan-and-Execute：先规划子任务，再逐步执行
  • Multi-Agent：多个 Agent 协作，各司其职（Orchestrator + Worker）
  • Tool Use / Function Calling：LLM 决定调用哪个工具及参数

5. MCP（Model Context Protocol）​

  • Anthropic 提出的开放协议，统一 AI 与外部工具/数据源的接口
  • 架构：MCP Client（LLM 应用）↔ MCP Server（工具提供方）
  • 传输方式：stdio（本地）、HTTP+SSE（远程）
  • 核心能力：Tools（工具调用）、Resources（数据读取）、Prompts（提示模板）
  • 意义：避免每个应用重复实现工具集成，生态统一

6. 微调 vs RAG vs Prompt​

方法优点缺点适合场景
Prompt Engineering零成本，快速迭代受上下文长度限制通用任务
RAG知识可实时更新检索质量影响结果知识库问答
Fine-tuning深度定制风格/能力成本高，数据要求高垂直领域专业化

7. 高频面试题​

  • Hallucination（幻觉）怎么缓解：RAG 提供事实依据、CoT 推理、输出校验
  • 如何评估 LLM 效果：BLEU/ROUGE（文本相似度）、人工评估、自动化 LLM-as-Judge
  • Token 数怎么优化：压缩 Prompt、摘要历史对话、动态检索
  • 流式输出原理：SSE（Server-Sent Events）逐 token 推送
  • LangChain vs 原生调用：LangChain 封装链路和工具，快速原型；生产环境可考虑轻量替代（LlamaIndex、自研）

RAG 系统设计与优化​

RAG 深入解析​

1. RAG 完整架构​

【离线阶段 - 知识库构建】
原始文档 → 预处理（清洗/去重）→ 分块（Chunking）
    → Embedding 模型向量化 → 存入向量数据库

【在线阶段 - 检索生成】
用户问题 → Query 改写/增强 → 向量化
    → 向量检索（Top-K）→ 可选：Re-ranking
    → 拼接 Prompt → LLM 生成 → 后处理 → 输出

2. Chunking 策略​

策略特点适用场景
固定大小简单，可能截断语义通用场景
递归字符分割按段落/句子/词分割结构化文本
语义分割按语义边界分块质量要求高
文档结构感知利用 Markdown/HTML 标题有结构的文档
Small-to-Big存小块，检索后返回大块平衡精度和上下文

关键参数

  • chunk_size：通常 512-1024 tokens
  • chunk_overlap：通常 50-200 tokens，避免边界信息丢失

3. 检索优化​

混合检索

稠密检索（向量相似度）
    +
稀疏检索（BM25 关键词）
    → RRF（倒数排名融合）合并结果

Query 增强

  • HyDE（假设文档嵌入）：让 LLM 先生成假设答案，用假设答案检索
  • Multi-Query：生成多个角度的查询并集检索
  • Step-Back Prompting：将具体问题泛化为更高层次的问题

Re-ranking

  • Cross-Encoder 模型（如 BGE-Reranker）对 query+doc 联合编码评分
  • 比双塔 Embedding 更准确，但速度慢（仅用于 Top-K 精排）

4. 向量数据库选型​

数据库特点适用场景
Pinecone全托管，简单快速原型
Qdrant开源，Rust 实现，高性能自托管生产
Weaviate内置混合检索需混合搜索
Chroma轻量，本地优先开发调试
Milvus大规模，功能全企业级
pgvectorPostgreSQL 扩展已有 PG 的项目

5. 评估体系​

RAGAS 评估框架：
- Faithfulness（忠实性）：答案是否基于检索到的上下文
- Answer Relevancy（相关性）：答案是否回答了问题
- Context Recall（上下文召回）：检索的文档是否包含答案所需信息
- Context Precision（上下文精确）：检索的文档是否都有用

6. 常见问题与优化​

问题原因解决方案
检索不到相关内容Chunk 太大/太小，Embedding 弱调整分块，换更好的 Embedding 模型
检索到但答错LLM 忽略上下文优化 Prompt，强调「只根据以下内容回答」
多跳推理失败信息分散在多个文档Graph RAG，建立实体关系图
长文档理解差超出上下文窗口层次化索引（先摘要，再详细）

7. 高频面试题​

  • RAG 和 Fine-tuning 如何选择？ 知识需要实时更新用 RAG；需要改变模型风格/能力用 Fine-tuning；两者可结合
  • 如何提升 RAG 的准确率？ 改善 Chunking 策略、升级 Embedding 模型、加 Re-ranking、优化 Prompt
  • 向量相似度搜索原理？ 计算 Query 向量与文档向量的余弦相似度或内积，用 HNSW/IVF 近似最近邻加速
  • Graph RAG 是什么？ 将文档解析为知识图谱，结合图遍历和向量检索，适合复杂推理

AI Agent 工程化实践​

Agent 工程化全景​

1. Function Calling 深入​

tools = [{
    "type": "function",
    "function": {
        "name": "search_web",
        "description": "搜索互联网获取实时信息",
        "parameters": {
            "type": "object",
            "properties": {
                "query": {"type": "string", "description": "搜索关键词"}
            },
            "required": ["query"]
        }
    }
}]

response = client.chat.completions.create(
    model="gpt-4o",
    messages=messages,
    tools=tools,
    tool_choice="auto"  # auto / none / required
)

# 若模型决定调用工具
if response.choices[0].message.tool_calls:
    tool_call = response.choices[0].message.tool_calls[0]
    result = execute_tool(tool_call.function.name, tool_call.function.arguments)
    # 将结果追加到 messages 继续对话

2. ReAct 模式实现​

System Prompt 示例：
你是一个能调用工具的 AI 助手。每次思考请遵循以下格式：

Thought: 分析当前状况，决定下一步
Action: 调用工具名称
Action Input: 工具参数
Observation: （工具返回结果）
... (循环直到有答案)
Final Answer: 最终答案

终止条件

  • 得到足够信息生成最终答案
  • 达到最大迭代次数（防止死循环）
  • 工具调用失败超过阈值

3. 多 Agent 系统设计​

层级架构

Orchestrator Agent（任务分解和协调）
    ├── Research Agent（信息检索）
    ├── Code Agent（代码生成执行）
    ├── Writer Agent（内容生成）
    └── Critic Agent（质量评估）

通信方式

  • 共享消息队列
  • Blackboard 模式（共享状态空间）
  • 直接函数调用（同步）
  • 事件驱动（异步）

代表框架

框架特点
LangGraph图结构工作流，状态机，支持循环
AutoGen对话式多 Agent，微软出品
CrewAI角色化 Agent 团队，简单易用
OpenAI Swarm轻量级 handoff 模式

4. 记忆系统设计​

短期记忆（In-context）
→ 当前对话历史，直接放入 context window
→ 超长时摘要压缩

长期记忆（外部存储）
→ 向量存储（语义检索历史对话）
→ 结构化存储（用户偏好、任务状态）
→ 知识图谱（实体关系）

工作记忆（执行状态）
→ 当前任务的中间结果
→ 工具调用历史

5. 可靠性与安全​

幂等性

  • 工具调用可能因网络重试多次执行
  • 设计工具时保证幂等（查询类天然幂等，写入类需去重）

沙箱执行

  • 代码执行 Agent 必须在隔离环境（Docker/E2B）
  • 限制文件系统访问、网络访问、执行时间

Prompt 注入防御

  • 严格区分系统指令和用户输入
  • 对工具输出做内容过滤
  • 敏感操作需要用户二次确认

可观测性

  • 记录每次 LLM 调用（输入/输出/token 数/延迟）
  • 工具调用日志（工具名/参数/结果/耗时）
  • 使用 LangSmith / Langfuse / Phoenix 做 tracing

6. 成本与延迟优化​

  • 缓存：相同输入的 LLM 调用结果缓存（Prompt Cache）
  • 模型路由：简单任务用小模型（GPT-4o-mini），复杂任务用大模型
  • 流式输出：SSE 降低首字节时间，提升用户体验
  • 并行工具调用：无依赖的工具并发执行
  • Context 压缩：历史对话摘要，减少 token 消耗

7. 高频面试题​

  • Agent 如何处理工具调用失败？ 重试（指数退避）+ fallback 工具 + 告知 LLM 错误信息让其调整策略
  • 如何防止 Agent 无限循环？ 最大迭代次数 + 检测重复 action + 超时熔断
  • 多 Agent 如何保证任务不重复？ 任务队列 + 状态锁 + 幂等性设计
  • 如何评估 Agent 质量？ 任务完成率、工具调用准确率、token 效率、延迟 P99

大模型微调与部署面经​

大模型工程化​

1. 微调方法对比​

方法参数量显存需求效果适用场景
Full Fine-tuning全量极高（需多卡）最好资源充足
LoRA极少（0.1-1%）低较好最常用
QLoRA极少极低（量化基座）接近 LoRA消费级 GPU
Prefix Tuning少低一般特定任务
Prompt Tuning极少极低较差资源极少

LoRA 原理

原始权重 W（冻结）
低秩矩阵 ΔW = B × A（可训练，rank << d）
实际前向：h = Wx + BAx
  • rank 通常取 4-64，越大效果越好但参数越多
  • 推理时可将 BA 合并回 W，无额外推理开销

2. 训练数据准备​

数据格式（Instruction Tuning）

{
  "instruction": "将以下英文翻译成中文",
  "input": "Hello, world!",
  "output": "你好，世界！"
}

数据质量胜过数量

  • 1000 条高质量 > 10000 条低质量
  • 去重（MinHash）、过滤（困惑度/规则）、多样性保证
  • Alpaca / ShareGPT / LIMA 格式是常见开源数据集格式

RLHF 流程

1. SFT（监督微调）：在高质量数据上微调
2. Reward Model 训练：让人类对输出排序，训练奖励模型
3. PPO 强化学习：用奖励模型优化策略，对齐人类偏好

DPO（Direct Preference Optimization）：绕过 RM 直接从偏好数据优化，更简单稳定

3. 模型量化​

量化方式精度损失速度提升内存节省
FP16 / BF16极小2x2x
INT8（LLM.int8）小1.5-2x4x
INT4（GPTQ/AWQ）中2-4x8x
GGUF（llama.cpp）可选CPU 可用8-16x
  • GPTQ：后训练量化，逐层校准，精度好
  • AWQ：激活感知量化，保留重要权重精度
  • GGUF：llama.cpp 格式，支持 CPU 推理和混合量化

4. 推理优化​

KV Cache

  • 缓存已计算的 Key/Value，避免重复计算历史 token
  • 内存瓶颈：长上下文时 KV Cache 可达数十 GB
  • 优化：PagedAttention（vLLM）、滑动窗口、GQA（分组查询注意力）

推理框架

框架特点
vLLMPagedAttention，高吞吐，连续批处理
TGI（HuggingFace）生产就绪，流式输出
Ollama本地部署，易用
llama.cppCPU 推理，量化支持好
TensorRT-LLMNVIDIA 优化，极致性能

5. 部署架构​

用户请求
    ↓
API Gateway（认证/限流）
    ↓
Load Balancer
    ↓
推理服务集群（vLLM / TGI）
    ↓
GPU 实例（A100 / H100 / L40S）

+ Prompt Cache 层（Redis）
+ 模型版本管理（MLflow）
+ 监控（Prometheus + Grafana）

6. 高频面试题​

  • LoRA 的 rank 怎么选？ 从小到大实验，数据少 rank 小（4-8），数据多任务复杂 rank 大（32-64）
  • 微调后模型为什么会遗忘原有能力？ 灾难性遗忘，解决：混合原始数据、降低学习率、使用 LoRA
  • 如何估算微调所需显存？ 模型参数 × 精度（FP16=2字节）× 3（模型+梯度+优化器状态）+ 激活值
  • vLLM 为什么快？ PagedAttention 消除 KV Cache 碎片化 + 连续批处理（Continuous Batching）提高 GPU 利用率
  • 如何做模型 A/B 测试？ 流量分配 + 统一评估指标 + 足够样本量保证统计显著性

LLM 底层原理深入​

Transformer 与大模型核心原理​

1. Attention 机制​

Self-Attention 计算流程

输入嵌入 X (seq_len x d_model)
    |
 Q = X * W_Q,  K = X * W_K,  V = X * W_V
    |
 Attention(Q,K,V) = softmax(Q * K^T / sqrt(d_k)) * V
缩放因子 sqrt(d_k)：防止点积过大导致 softmax 梯度消失
    |
 Multi-Head: 并行多个 attention 头，关注不同子空间

Multi-Head Attention

MultiHead(Q,K,V) = Concat(head_1,...,head_h) * W_O
其中 head_i = Attention(Q*W_Q_i, K*W_K_i, V*W_V_i)

典型配置：GPT-3 96 个头，每个头 d_k = d_model/h = 128

KV Cache 优化

自回归生成时，每个新 token 都需计算所有历史 token 的 K/V
-> 缓存所有历史 K/V，新 token 只需计算自己的 K/V
-> 生成速度从 O(n^2) 降为 O(n)

2. 位置编码​

绝对位置编码（Sinusoidal）

PE(pos, 2i) = sin(pos / 10000^(2i/d_model))
PE(pos, 2i+1) = cos(pos / 10000^(2i/d_model))

优点：无参数，可注意到超过训练长度的位置
缺点：强行建模窗口长度限制

RoPE（旋转位置编码）

将位置信息编码到 Q、K 的旋转操作中
内积 q^T * k 天然地只依赖两个 token 的相对位置
限度外推能力更强，被 LLaMA、Qwen 等模型广泛采用

3. 主流架构对比​

GPT 系列（Decoder-Only）

仅使用 Transformer Decoder
因果式注意力（Causal Attention）：每个 token 只能关注左边
适合文本生成任务

BERT 系列（Encoder-Only）

双向注意力：每个 token 可关注所有其他 token
适合理解任务：分类、NER、问答匹配

T5 系列（Encoder-Decoder）

Encoder 理解输入，Decoder 自回归生成输出
适合 Seq2Seq：翻译、摘要、问答

4. 模型训练​

预训练目标

Causal LM（GPT）：预测下一个 token
  loss = CrossEntropy(predict[i], actual[i+1])

Masked LM（BERT）：预测被遮罩的 token
  随机遮罩 15% token，预测原始 token

常用优化器

Adam：自适应学习率，LLM 训练最常用
AdamW：Adam + 权重衰减，防止过拟合

Cosine LR Schedule：
- 预热期（warmup）：学习率从 0 增到最大値
- 䆮减期：cos 曲线减小到最小学习率

混合精度训练（Mixed Precision）

forward + backward：FP16（快，内存少）
权重更新：FP32（防止上溢）
损失缩放：防止 FP16 下溢（梯度过小表示为 0）

5. 模型评估​

自动化指标

Perplexity（困惑度）：衡量模型对测试集的预测能力
  PPL = exp(mean(-log P(token_i)))
  PPL 越低越好

BLEU：机器翻译评估，n-gram 重合度
ROUGE：摘要评估，召回率为主

LLM 专属评测

MMLU：世界知识理解，57 个学科选择题
HumanEval：代码生成能力（编写 Python 函数）
GSM8K：小学数学题推理
MTBench：多轮对话质量，GPT-4 作裁判

6. 高效 Attention 变体​

Flash Attention

  • 将 Attention 计算分块，减少 HBM（显存）访问次数
  • IO 复杂度：O(n^2/B) vs 标准 O(n^2)，实际可加速 2-4x
  • 然而输出与标准 Attention 完全相同（数学等价）

GQA（分组查询注意力）

MHA: 每个 Q 头都有独立的 K/V 头
 MQA: 所有 Q 头共享 1 个 K/V 头（KV Cache 最小）
GQA: G 组 Q 头共享 1 个 K/V 头（平衡）

 LLaMA 3 / Mistral 采用 GQA，大幅减小 KV Cache 占用

7. 资深面试题​

  • 为什么缩放系数 sqrt(d_k) 很重要？
    • 向量维度 d_k 增大时，点积的方差增大，导致 softmax 梯度极小
    • 除以 sqrt(d_k) 能把方差拉回到合理范围
  • 为什么 GPT 不用 Encoder？
    • 文本生成天然地是自回归的，只需 Decoder
    • 去掉 Encoder-Decoder 交叉注意力，模型更简单、规模更容易扯展
  • 长文本处理的振戰是什么？
    • 标准 Attention 是 O(n^2) 空间和时间复杂度
    • 解决：Flash Attention（效率）、Sliding Window（法拉）、RoPE 线性外推
  • 当 context 超过训练长度时模型表现如何？
    • Sinusoidal 位置编码：超长位置没被训练过，推理性能显著下降
    • RoPE：基于相对位置，外推能力更强，才有 YaRN、LongRoPE 等扩展方法

Prompt Engineering 进阶技巧​

资深 Prompt 工程全指南​

1. 高质量 Prompt 的完整结构​

角色设定（Role）：你是谁，有什么能力和经验
任务说明（Task）：需要做什么，目标是什么
背景信息（Context）：相关上下文和限制
输入数据（Input）：具体的内容
输出格式（Format）：JSON / Markdown / 列表 / 表格
约束条件（Constraints）：哪些要做，哪些不要做
示例（Examples）：few-shot 样例

高质量 System Prompt 示例

你是一个资深的 React 代码审查尓，有超过 10 年的上线项目经验。

你的职责：
- 密切关注代码质量、性能和安全性
- 只评论最重要的 2-3 个问题，每个问题用 100 字内阐明
- 对每个问题提供具体的修改建议和代码示例
- 评论用 Markdown 格式输出

严重问题：内存泄漏、XSS、并发风险
中等问题：不必要重渲染、过度设计、缺少错误处理
轻微问题：风格不一致、重复代码

2. Chain-of-Thought 及其变体​

Zero-Shot CoT

Q: 23 个員工每人工资 8500 元，每月总工资是多少？让我们一步一步思考。

Few-Shot CoT（提供推理示例）

示例：
Q: 5 个苹果，吃了3个，还剩几个？
A: 初始有 5 个苹果。吃掉了3个，5 - 3 = 2。所以还剩 2 个。

现在解决：
Q: 23 个員工每人工资 8500 元，每月总工资是多少？
A: 总工资 = 23 x 8500 = ...

Tree-of-Thoughts（多路探索）

请展开 3 个不同的解决思路，然后对每个思路进行优劣分析，最后选择最佳方案并详细展开。

考虑维度：可行性、实施成本、预期效果。

3. 达到编垆的输出控制​

JSON 输出控制

以 JSON 格式输出结果，不要添加任何其他文字：

{
  "intent": "用户意图",
  "entities": ["实体列表"],
  "sentiment": "positive|negative|neutral",
  "confidence": 0.95
}

结构化输出模板

请按如下格式回复，远局一行也不要输出：

## 分析结果
**核心问题：**[1-2句]
**影响范围：**[1-2句]

## 解决方案
1. [100字内]
2. [100字内]

## 推荐方案
[50字内，说明选择理由]

4. 上下文管理技巧​

对话历史压缩

[历史对话摘要：
- 用户希望完成一个 React 在线商城设计
- 已确定技术栈：React + TypeScript + TailwindCSS
- 已设计完成首页和商品详情页
- 待完成：购物车和结账页面]
请继续帮助设计购物车页面。

分片加载分析

文档总共 50 页，每次只分析第 X-Y 页的内容。
当上一笔分析结束后，输入「继续」就会分析下一笔。

5. 提升模型输出质量的技巧​

角色扮演法

模拟一位拥有 20 年 Kubernetes 运维经验的亓家。
以专家的身份回答：直接指出最常见的坑和额外注意事项。

对比法

以对比表格的形式比较 React 18 和 React 17 的差异。
包含：功能点、性能影响、迁移难度、适用场景。

递进式详细

先用 2 句概述核心关键点。
然后递进展开：
- 实现原理
- 代码示例
- 常见坏呓
- 最佳实践

6. 语境干预技巧​

限制模型行为

严格要求：
1. 只使用我提供的代码库和文档中的 API，不要化鱼其他 API
2. 如果不确定就说「我不确定」，而不是编造答案
3. 代码示例必须是可运行的完整代码，不要使用占位符

强制指定格式

回答这个问题时务必遵循下列规则，否则回答无效：
- 第一行必须是 TLDR：用一句话概括
- 第二段展开详细解释
- 最后一行是行动建议

7. 测试与优化 Prompt 的方法​

系统性评估

构建测试集：
1. 正常案例：10 个标准输入
2. 边界案例：5 个极端情况
3. 对抗性输入：3 个尝试误导的输入

评指标：输出准确性、格式合规性、违禁率

A/B 测试

对比两种 Prompt：
- 版本 A：直接说任务
- 版本 B：加上角色设定和示例
各运行 20 次，对比平均输出质量

8. 高级技巧​

综合运用

步骤 1（角色设定）：你是一个 SQL 优化专家
步骤 2（任务分解）：分析这个查询的性能问题
  - 先识别常见问题（全表扫描、缺少索引等）
  - 再给出修改建议
  - 最后提供优化后的 SQL
步骤 3（示例）：提供一个类似的优化案例

自我评估准则

输出之前，对照以下标准自我检查：
1. 是否直接回答了用户的问题？
2. 是否提供了具体的代码示例？
3. 是否提到了可能的常见坏呓？
4. 格式是否符合要求？
如果以上任一项不满足，重新生成。

9. 高频资深面试题​

  • Prompt 注入攻击如何防御？
    • 将系统指令和用户输入明确分隔
    • 输入内容进行转义和过滤
    • 配置输出可解释性，异常输出可监测
    • 敏感操作需二次确认机制
  • Few-shot 和 Fine-tuning 怎么选择？
    • 数据量少且任务模式短期内频繁变化 -> Few-shot
    • 需要专业风格、领域抓词、特定输出格式 -> Fine-tuning
    • 两者并不互斥，微调后的模型用 few-shot 进一步提升
  • 如何评估 Prompt 的质量？
    • 准确性：输出是否正确回答了问题
    • 一致性：相同输入输出是否稳定
    • 完整性：输出是否覆盖了关键信息
    • 格式合规性：输出是否符合指定格式
  • 为什么 Temperature 高时输出更润着但可能不准确？
    • Temperature 控制 softmax 后的概率分布晌散程度
    • 高 Temperature：概率分布更平坦，小概率的 token 也有机会被选
    • 低 Temperature：分布更集中，和确定性如 0 时总是选最高概率 token