Agent 岗位面试的第一轮，考官往往不急着问高大上的系统设计，而是先探你的“地基”——大模型的能力边界、RAG 的取舍、记忆的分层。

这三个概念看似基础，却是最容易暴露“背过 vs 用过”的地方。很多候选人能把名词解释背得滚瓜烂熟，但一旦被追问“为什么这么选”“踩过什么坑”，就立刻露怯。第一轮面试的本质，其实是在考察：你是否具备在工程约束下做技术决策的能力，而不是单纯的知识搬运能力。

下面我们逐一拆解这三个高频“地基题”。

---

一、LLM：先讲清“大”到底大在哪

高频问法：​ “大模型和小模型的本质区别是什么？”

很多人只会答“参数多”。这只是表象。面试官想听的是背后的逻辑链，以及你对“规模效应”的理解。

建议从三个维度展开：

1. 规模带来涌现（Scaling Laws）

这是大模型最核心的特征。

• 参数量从百万级跨越到十亿、千亿乃至万亿级；

• 训练数据从 GB 级跨越到 TB、甚至 PB 级；

• 在算力和数据的双重支撑下，量变引发了质变——这就是所谓的“涌现能力”（Emergent Abilities）。

这种能力是小模型不具备的，典型表现包括：

• 复杂推理：链式思维（CoT）、多步逻辑推理；

• Few-shot / Zero-shot 学习：不需要大量标注数据，仅凭少量示例甚至无需示例就能完成新任务；

• 泛化能力：同一套模型，可以覆盖文本、代码、数学推理等多种场景。

2. 能力维度的差异

维度	大模型	小模型
核心优势	通用性强、泛化好	专精单一任务、稳定性高
适用场景	开放域问答、复杂推理、多模态理解	文本分类、NER、情感分析、规则明确任务
上下文长度	可达上百 K tokens，适合长文档	通常只有几百～几千 tokens
模态支持	文本、代码、图像、音频等多模态	多为单模态

一句话总结：大模型胜在“通”和“长”，小模型胜在“专”和“快”。

3. 成本与部署的取舍

这是工程落地时必须直面的现实问题：

• 大模型：训练成本动辄数百万到数千万美元，推理需要 GPU 集群，延迟高、成本高；

• 小模型：可以在 CPU、手机、树莓派等边缘设备上实时运行，支持本地化部署，隐私可控。

✅ 加分回答

能主动说出这句话的人，通常会让面试官眼前一亮：

“不是所有场景都该上大模型。”

比如：

• 实时控制系统（毫秒级响应）；

• 高度隐私敏感场景（医疗、金融终端）；

• 成本极度敏感的大规模请求（每天亿级调用）。

在这些场景下，小模型 + 规则系统反而是更专业、更经济的选择。

这体现的不再是“会不会用大模型”，而是技术选型的判断力——不盲从技术热点，而是让技术服务于业务目标。

---

二、RAG：别只背“切片—向量—召回”

高频问法：​ “为什么要用 RAG？它解决了 LLM 的什么问题？”

先给一个“一句话版本”的答案

标准答案是两点：

1. 知识冻结问题：LLM 的知识停留在预训练截止时间，无法获取最新信息；

2. 幻觉问题：模型在缺乏确定知识时会“一本正经地胡说八道”。

RAG（Retrieval-Augmented Generation）的核心思路是：

在生成之前，先从外部知识库检索相关信息，和用户问题一起拼成 Prompt，再交给 LLM 生成。

一句话概括：先检索，后生成，让模型“开卷答题”。

再讲完整链路（三个核心阶段）

面试官希望听到你对全流程的掌控力，而不仅仅是一个概念：

1. 数据准备与索引（Indexing）

• 收集并清洗知识库文档；

• 文档切分（Chunking）：将长文档拆成合适大小的片段；

• 向量化（Embedding）：用嵌入模型将每个 Chunk 转成向量；

• 存入向量数据库：如 FAISS、Milvus、Pinecone、Weaviate 等。

2. 检索（Retrieval）

• 用户 Query 用同一个嵌入模型向量化；

• 在向量数据库中做相似度搜索（通常是余弦相似度）；

• 取 Top-K 最相关的片段。

3. 生成（Generation）

• 将检索到的片段 + 用户问题拼成 Prompt；

• 调用 LLM 生成答案；

• 可选：在答案中附上来源引用，增强可解释性和可信度。

⚠️ 面试官的追问陷阱（区分“背过”和“用过”）

讲完基础链路，面试官一定会往深里挖，常见的“坑”包括：

• 分块粒度怎么定？

  • 太大：噪声多、冗余高，可能超过上下文窗口；

  • 太小：语义不完整，模型难以理解上下文。

  • 实际项目中往往需要结合文档结构（段落、章节、标题）做语义感知切分，而不是简单按字符数硬切。

• Query 太模糊怎么办？

  • 是否需要 Query Rewrite / Query Expansion？

  • 是否引入 HyDE（Hypothetical Document Embeddings）等策略，让模型先“假设”一个答案再检索？

• 召回一堆碎片如何优化？

  • 是否需要 Rerank（重排序）？

  • 是否引入 Cross-Encoder 做精细化排序，而不仅是向量相似度？

• 检索内容与模型内部知识冲突时信谁？

  • 这是一个典型的“可信度优先级”问题；

  • 工业界常见做法是：显式声明来源，或在 Prompt 中强调“优先参考检索内容，如有冲突以检索内容为准”。

能把这些“链路上的坑”讲清楚，说明你不是只在 Demo 里跑过 RAG，而是真正在项目中踩过坑、做过权衡。

---

三、Memory：记忆不是一个开关，而是一套分层架构

高频问法：​ “对话到第 100 轮，怎么让 Agent 还记得第 1 轮的关键约束？”

很多候选人的第一反应是：“把历史都塞进上下文窗口。”

这在第 5 轮、第 10 轮或许可行，但在第 100 轮，就会撞上上下文长度、成本和性能的三重墙。

先讲清记忆的三个核心作用

1. 上下文保持：解决指代消解（“它”指什么）、记住用户偏好（语气、格式、禁忌）；

2. 状态持久化：跨会话保存任务进度、中间结果、已完成的子目标；

3. 经验积累：从过往成功 / 失败的交互中提炼模式，用于后续决策优化。

再讲分层架构（短期 / 长期 / 混合）

记忆系统的关键，在于分层设计：

1. 短期记忆（Short-term Memory）

• 载体：当前对话上下文窗口、Transformer 的 KV Cache；

• 特点：

  • 极低延迟，随取随用；

  • 会话结束后即消失；

  • 受限于上下文窗口大小（即使 128K，也有成本与性能瓶颈）。

2. 长期记忆（Long-term Memory）

• 载体：

  • 向量数据库：存储历史对话、用户画像、经验片段；

  • 知识图谱：存储结构化关系和实体信息；

  • 模型权重：将高频、稳定知识通过微调“固化”进模型。

• 特点：

  • 可跨会话持久调用；

  • 检索会引入一定延迟；

  • 需要设计写入、更新、淘汰机制。

3. 混合架构（Hybrid Architecture）

工业级 Agent 通常采用多层混合：

• 热数据：放内存（如 Redis），用于高频访问的用户偏好、当前任务状态；

• 温数据：存向量数据库，用于语义检索历史对话和相关经验；

• 冷数据：落磁盘或对象存储，用于归档和不常访问的历史记录；

• 关键数据双写：

  • 一份存向量库，方便语义检索；

  • 一份落关系型数据库，保证事务一致性和可追溯性。

✅ 加分回答：记忆压缩与动态遗忘

能提到这两个概念，会让面试官觉得你对“成本 vs 信息完整度”有深刻认知：

• 记忆压缩：把长对话压缩成摘要、关键点或向量表示，只保留“高信息密度”的内容；

• 动态遗忘：为记忆项打分（基于时间衰减、重要性、使用频率），自动强化高价值记忆、淘汰低价值记忆——类似人脑的遗忘机制。

这背后反映的是：记忆不是越多越好，而是越“有用”越好。

---

▎小结：三个概念，考的是同一件事

大模型、RAG、Memory，这三个“地基问题”，表面看是三个知识点，本质上考的是同一件事：

在有限的资源（上下文长度、算力、成本、延迟）下，如何让系统既准确又经济。

• 懂 Scaling Laws，是为了知道什么时候不该用大模型；

• 懂 RAG 的细节取舍，是为了知道什么时候该相信外部知识，什么时候该怀疑检索结果；

• 懂 Memory 的分层与压缩，是为了知道哪些信息值得记住，哪些可以果断遗忘。

谁能在面试中把“取舍”讲透，而不是只讲“有什么”，谁就赢在了第一关。