高概率题库 · RAG 系统方向（22题）

出现频率 60% 以上。每题均为六段式结构：题目 / 押题依据 / 标准答案 / 前沿加分 / 常见踩坑 / 回答策略。

← 返回高概率题库总览

一、RAG 系统方向（22题）

核心原理

Q1：请解释 RAG 的工作原理。与直接 Fine-tuning 相比，RAG 主要解决了什么问题？

难度：⭐⭐ | 公司：字节、阿里、腾讯（高频）

查看完整解析

① 押题依据

RAG 是企业级 AI 产品的核心架构，几乎所有知识库、客服、搜索类产品都在用。面试官考察你是否真正理解技术实现，还是只会背概念。

② 标准答案

RAG（检索增强生成）的核心思路是：在大模型生成回答前，先从外部知识库检索相关文档，将检索内容拼接进 Prompt，让模型基于这些上下文生成答案。

与 Fine-tuning 的核心差异：

维度	RAG	Fine-tuning
知识更新	实时更新知识库即可	需要重新训练模型
成本	低（只需维护向量库）	高（GPU 训练成本）
适用场景	知识频繁变化、需要引用来源	风格/格式固定、领域专用
可解释性	可追溯来源文档	黑盒，无法解释

RAG 主要解决的问题：

知识时效性：模型训练后的新知识无法获取，RAG 通过外部检索解决
幻觉问题：基于检索到的真实文档生成，减少编造
可追溯性：可以显示答案来源，增强可信度

③ 前沿加分

2025 年后 RAG 演进方向：

Agentic RAG：模型自主决定是否检索、检索几轮，比 Naive RAG 更灵活
GraphRAG：用知识图谱替代纯向量检索，处理多跳推理（如"A 的上司的上司是谁"）
混合方案：RAG + Fine-tuning 结合，用 Fine-tuning 固化领域知识，用 RAG 补充时效信息

④ 常见踩坑

❌ 只说"检索 + 生成"，忽略 Embedding、Chunk 策略、向量数据库等关键环节
❌ 把 RAG 和 Fine-tuning 说成"二选一"，实际很多场景是组合使用
❌ 说不清楚 RAG 的局限性（如检索不到相关文档时会失败）

⑤ 回答策略

开场句：「RAG 本质是给大模型加外挂知识库，我从原理和选型两个角度说。」

时间分配：原理（1分钟）→ 对比 Fine-tuning（1分钟）→ 前沿补充（30秒）

⑥ 追问预判

「什么场景用 RAG，什么场景用 Fine-tuning？」→ 知识更新频率是核心判断标准

Q2：一个完整的 RAG 流水线包含哪些关键步骤？从数据准备到最终生成。

难度：⭐⭐

查看完整解析

① 押题依据

考察你是否真正做过 RAG 项目，还是只停留在概念层面。完整流程包含很多工程细节。

② 标准答案

完整 RAG 流水线分为离线准备和在线服务两个阶段：

离线准备阶段（构建知识库）：

数据收集与清洗：收集文档（PDF/Word/网页），去除无效内容（页眉页脚、广告）
文档切块（Chunking）：将长文档切分为 Chunk（通常 200-500 token），设置重叠（overlap 10-20%）避免语义断裂
向量化（Embedding）：用 Embedding 模型（如 text-embedding-3）将每个 Chunk 转为向量
索引构建：将向量存入向量数据库（Milvus/Qdrant/Pinecone），建立索引加速检索

在线服务阶段（用户提问）：

查询向量化：将用户问题转为向量
相似度检索：在向量库中计算相似度，召回 Top-K 相关 Chunk（通常 K=3-5）
上下文拼接：将召回的 Chunk 拼入 Prompt 模板
LLM 生成：调用大模型生成最终答案
后处理：格式化输出，添加来源引用

③ 前沿加分

实际生产中还会加入：

Reranker：在召回后用更精准的模型重新排序
混合检索：向量检索 + BM25 关键词检索结合
查询改写：用 LLM 先改写用户问题，提升召回率

④ 常见踩坑

❌ 忽略数据清洗，导致检索到大量无效内容
❌ Chunk 切太大（超过 1000 token），导致上下文噪声多
❌ 不做 overlap，导致关键信息被切断

⑤ 回答策略

开场句：「RAG 流程分离线构建和在线服务两部分，我按顺序说。」

时间分配：离线（1分钟）→ 在线（1分钟）→ 工程优化（30秒）

⑥ 追问预判

「Chunk 大小怎么定？」→ 根据文档类型和模型 Context Window 权衡

Q3：文本切块（Chunking）策略如何选择？切块大小和重叠长度背后有什么权衡？

难度：⭐⭐

查看完整解析

① 押题依据

Chunking 是 RAG 系统最容易被忽视但影响最大的环节，直接决定检索质量。

② 标准答案

Chunk 大小的权衡：

Chunk 大小	优势	劣势	适用场景
小（100-200 token）	检索精准，噪声少	可能丢失上下文	FAQ、短问答
中（300-500 token）	平衡精准和完整性	通用	大部分场景
大（800-1000 token）	保留完整语义	噪声多，检索不精准	长文档摘要

Overlap（重叠）的作用：

设置 10-20% 的重叠，避免关键信息被切断。例如：

Chunk 1：「...公司成立于 2020 年」
Chunk 2（无 overlap）：「主要业务是...」→ 丢失主语
Chunk 2（有 overlap）：「公司成立于 2020 年，主要业务是...」→ 语义完整

选择策略：

文档类型：结构化文档（合同、报告）按章节切，非结构化（对话记录）按语义切
问题类型：精确查找用小 Chunk，理解类问题用大 Chunk
模型 Context Window：召回 5 个 Chunk 后总长度不能超过模型限制

③ 前沿加分

高级 Chunking 策略：

语义切块：用 LLM 识别段落边界，而非固定 token 数
层级切块：同时存储大 Chunk（摘要）和小 Chunk（细节），先召回大的再定位小的
动态 Chunk：根据查询类型动态调整召回的 Chunk 大小

④ 常见踩坑

❌ 用固定字符数切块，忽略句子边界，导致语义断裂
❌ Overlap 设置为 0，关键信息被切断
❌ 所有文档用同一套 Chunk 策略，忽略文档类型差异

⑤ 回答策略

开场句：「Chunking 是 RAG 的基础，核心是平衡精准和完整性。」

时间分配：大小权衡（1分钟）→ Overlap 作用（30秒）→ 选择策略（1分钟）

⑥ 追问预判

「你们项目用多大的 Chunk？」→ 说出具体数字和选择理由

Q4：如何选择合适的 Embedding 模型？评估 Embedding 好坏的指标有哪些？

难度：⭐⭐

查看完整解析

① 押题依据

Embedding 质量直接决定检索准确率，是 RAG 系统的核心。PM 需要知道如何评估和选型。

② 标准答案

选择 Embedding 模型的考量维度：

维度	说明	示例
语言支持	中文/英文/多语言	text-embedding-3（多语言）、bge-large-zh（中文）
向量维度	维度越高越精准，但存储和计算成本越高	512/768/1024/1536 维
领域适配	通用 vs 领域专用	法律、医疗领域需要专用模型
成本	API 调用费用 vs 自部署成本	OpenAI API vs 开源模型

评估 Embedding 好坏的指标：

检索准确率（Recall@K）：Top-K 结果中相关文档占比
MRR（Mean Reciprocal Rank）：第一个相关结果的平均排名
NDCG（归一化折损累积增益）：考虑排序质量的综合指标
语义相似度测试：用标注数据集测试相似文本的向量距离

实际选型建议：

通用场景：OpenAI text-embedding-3-large（1536 维，多语言）
中文优化：bge-large-zh-v1.5（1024 维，开源）
成本敏感：bge-small-zh（512 维，性能略降但成本低）

③ 前沿加分

2025 年 Embedding 技术趋势：

多模态 Embedding：文本 + 图片统一向量空间（CLIP 系列）
指令式 Embedding：根据任务类型（检索/分类/聚类）调整向量表示
动态维度：根据查询复杂度动态调整向量维度

④ 常见踩坑

❌ 用英文 Embedding 模型处理中文，效果大幅下降
❌ 只看模型参数大小，忽略实际检索效果测试
❌ 不做 Benchmark 对比就直接上线

⑤ 回答策略

开场句：「Embedding 选型要看语言、领域、成本三个维度，我从评估指标说起。」

时间分配：评估指标（1分钟）→ 选型建议（1分钟）→ 前沿补充（30秒）

⑥ 追问预判

「你们用的什么 Embedding 模型？」→ 说出模型名称和选择理由

检索优化

Q5：除了基础向量检索，还有哪些可以提升 RAG 检索质量的技术？

难度：⭐⭐⭐ | 公司：字节、阿里（高频）
PM 重点：混合检索（稠密+稀疏）、Reranker、HyDE

查看完整解析

① 押题依据

基础向量检索在实际场景中召回率往往不足，面试官考察你是否了解工程优化手段。

② 标准答案

核心优化技术：

混合检索（Hybrid Search）
- 向量检索（语义相似）+ BM25（关键词匹配）结合
- 适用场景：用户问题包含专有名词、产品型号等精确匹配需求
- 融合策略：RRF（Reciprocal Rank Fusion）或加权平均
Reranker（重排序）
- 召回 Top-20 后，用更精准的模型（如 Cross-Encoder）重新排序，输出 Top-5
- 优势：Cross-Encoder 比 Embedding 更准确，但计算慢，只用于精排
- 常用模型：bge-reranker-large
HyDE（假设性文档嵌入）
- 先让 LLM 根据问题生成假设答案，再用假设答案做检索
- 原理：假设答案比问题更接近知识库文档的语言风格
- 适用场景：用户问题表达模糊时
查询改写（Query Rewriting）
- 用 LLM 将用户问题改写为多个子问题，分别检索后合并
- 适用场景：复杂问题需要多角度信息

③ 前沿加分

Self-RAG：模型自主判断是否需要检索，避免无效检索
CRAG（Corrective RAG）：检索后评估结果质量，质量低时触发网络搜索补充
多路召回：同时用多个 Embedding 模型检索，取并集

④ 常见踩坑

❌ 盲目堆砌技术，不做 AB 测试验证效果
❌ Reranker 用在所有查询上，导致延迟过高
❌ 混合检索的权重固定，不根据查询类型动态调整

⑤ 回答策略

开场句：「基础向量检索召回率有限，我说几个常用的优化手段。」

时间分配：混合检索（1分钟）→ Reranker（1分钟）→ 其他技术（1分钟）

⑥ 追问预判

「Reranker 会增加多少延迟？」→ 通常增加 100-300ms，需要权衡

Q6：什么是"Lost in the Middle"问题？如何缓解？

难度：⭐⭐⭐
PM 重点：长文本中间内容被忽视，影响最终生成质量

查看完整解析

① 押题依据

这是 RAG 系统的经典问题，考察你对 LLM 注意力机制的理解。

② 标准答案

问题定义：

当 Prompt 中包含多个检索到的 Chunk 时，LLM 对开头和结尾的内容注意力更高，中间部分容易被忽略。这导致即使检索到了相关文档，但因为排在中间位置而没被利用。

原因：

LLM 的注意力机制对位置敏感
长上下文中，模型倾向于关注首尾信息

缓解方法：

调整 Chunk 顺序
- 将最相关的 Chunk 放在开头或结尾
- 根据相似度分数排序，Top-1 放开头，Top-2 放结尾
减少召回数量
- 不要盲目召回 Top-10，精选 Top-3 即可
- 用 Reranker 提升 Top-K 的质量
分段生成
- 将多个 Chunk 分批输入，每批生成部分答案，最后合并
- 适用于需要综合多个文档的场景
Prompt 设计
- 明确指示：「请仔细阅读以下所有文档，包括中间部分」
- 在每个 Chunk 前加编号和重要性标注

③ 前沿加分

注意力增强：用特殊 token 标记重要 Chunk，引导模型注意力
多轮检索：先用 Top-1 生成初步答案，再根据答案检索补充信息

④ 常见踩坑

❌ 召回 10+ 个 Chunk 直接拼接，导致中间信息丢失
❌ 只按相似度排序，不考虑位置影响
❌ 不监控实际使用了哪些 Chunk

⑤ 回答策略

开场句：「Lost in the Middle 是 LLM 注意力机制的特性，核心是优化 Chunk 排序。」

时间分配：问题解释（1分钟）→ 缓解方法（1.5分钟）

⑥ 追问预判

「你们怎么验证这个问题？」→ 用 attention 可视化或对比实验

Q7：什么场景下选择知识图谱（GraphRAG）而不是传统向量检索？

难度：⭐⭐⭐
PM 重点：多跳推理、实体关系密集的场景适合 GraphRAG

查看完整解析

① 押题依据

GraphRAG 是 2024-2025 年的热点技术，考察你对不同 RAG 范式的理解。

② 标准答案

传统向量 RAG vs GraphRAG：

维度	向量 RAG	GraphRAG
检索方式	语义相似度	实体关系路径
适用问题	单跳查询（"什么是 X"）	多跳推理（"A 的上司的上司"）
知识表示	文本 Chunk	实体 + 关系图谱
构建成本	低	高（需要实体抽取和关系标注）

GraphRAG 适用场景：

多跳推理问题
- 例：「张三的直属领导的部门预算是多少？」
- 需要：张三 → 领导 → 部门 → 预算，三跳关系
实体关系密集
- 企业组织架构、供应链网络、知识图谱
- 实体间关系比文本描述更重要
需要结构化推理
- 法律条款引用关系、学术论文引用网络
- 需要沿着关系链推理

不适合 GraphRAG 的场景：

非结构化文本（新闻、博客）
实体关系不明确的内容
快速迭代的知识库（图谱维护成本高）

③ 前沿加分

微软 GraphRAG 方案：

先用 LLM 从文档中抽取实体和关系，构建图谱
查询时沿图谱路径检索，再用 LLM 生成答案
适合大规模文档集的全局理解

④ 常见踩坑

❌ 盲目追求 GraphRAG，忽略构建和维护成本
❌ 把所有文档都转成图谱，实际大部分场景向量检索足够
❌ 图谱质量差（实体抽取错误），反而不如向量检索

⑤ 回答策略

开场句：「GraphRAG 适合多跳推理场景，我对比一下两种方案的适用性。」

时间分配：对比（1分钟）→ 适用场景（1分钟）→ 选型建议（30秒）

⑥ 追问预判

「你们项目用了 GraphRAG 吗？」→ 说出是否用、为什么用/不用

评估与工程实践

Q8：如何全面评估一个 RAG 系统？从检索和生成两个阶段分别提指标。

难度：⭐⭐⭐

查看完整解析

① 押题依据

评估体系是 AI PM 的核心能力，区别于工程师的关键考点。

② 标准答案

分阶段评估指标：

检索阶段（Retrieval）：

指标	定义	目标值
Recall@K	Top-K 中包含相关文档的比例	>90%
MRR	第一个相关文档的平均排名倒数	>0.8
Precision@K	Top-K 中相关文档占比	>60%

生成阶段（Generation）：

指标	定义	评估方法
Faithfulness	答案是否基于检索内容	LLM-as-Judge 或人工标注
Answer Relevance	答案是否回答了问题	语义相似度
Context Relevance	检索内容是否相关	人工抽查

用户体验层：

指标	定义	目标值
满意度	👍/👎 比例	>80%
追问率	用户继续追问的比例	<30%
纠错率	用户指出错误的比例	<5%

系统健壮性：

幻觉率：无相关文档时编造答案的比例
拒答率：正确拒绝回答的比例
延迟：P95 响应时间 <3s

③ 前沿加分

自动化评估框架：

RAGAS：开源 RAG 评估框架，支持 Faithfulness/Relevance 自动评估
LLM-as-Judge：用 GPT-4 评估答案质量，相关性达到人类标注 85% 一致性

④ 常见踩坑

❌ 只看生成质量，忽略检索阶段问题
❌ 只用自动化指标，不做人工抽查
❌ 评估数据集太小（<100 条），不具代表性

⑤ 回答策略

开场句：「RAG 评估要分检索和生成两阶段，再加用户体验层。」

时间分配：检索指标（1分钟）→ 生成指标（1分钟）→ 用户体验（30秒）

⑥ 追问预判

「怎么评估 Faithfulness？」→ 用 LLM 判断答案是否引用了检索内容

Q9：RAG 系统在实际部署中可能面临哪些挑战？

难度：⭐⭐⭐ | 公司：字节、阿里（高频）

查看完整解析

① 押题依据

考察你是否有实际落地经验，还是只停留在 Demo 阶段。

② 标准答案

核心挑战分类：

1. 数据质量问题

知识库内容过时、重复、矛盾
文档格式不统一（PDF/Word/扫描件）
缺少数据治理流程

2. 检索质量问题

召回率低：相关文档没被检索到
精准率低：检索到大量无关内容
语义理解偏差：用户问法和文档表述不一致

3. 生成质量问题

幻觉：检索不到时编造答案
答非所问：理解用户意图失败
引用错误：答案和来源不匹配

4. 工程性能问题

延迟高：向量检索 + LLM 生成总耗时 >5s
成本高：大量 API 调用费用
并发支持：高峰期响应慢

5. 用户体验问题

用户不知道 AI 能力边界，期望过高
错误时没有降级方案
缺少反馈闭环

应对策略：

挑战	解决方案
数据质量	建立文档审核流程，定期更新，去重
检索质量	混合检索 + Reranker + 查询改写
生成质量	置信度判断 + 拒答机制 + 来源引用
性能	向量库索引优化 + 缓存 + 异步生成
体验	明确能力边界 + 人工兜底 + 反馈收集

③ 前沿加分

在线学习：用用户反馈持续优化检索和生成
A/B 测试：不同 Chunk 策略、Prompt 模板并行测试
可观测性：记录每次检索和生成的中间结果，便于调试

④ 常见踩坑

❌ 只关注技术指标，忽略用户实际满意度
❌ 上线后没有监控和迭代机制
❌ 把 RAG 当成"一次性项目"，不做持续优化

⑤ 回答策略

开场句：「RAG 落地挑战主要在数据、检索、生成、工程、体验五个层面。」

时间分配：挑战分类（1.5分钟）→ 应对策略（1.5分钟）

⑥ 追问预判

「你们遇到的最大挑战是什么？」→ 结合实际项目说

Q10：了解 RAGFlow 等开源 RAG 框架吗？如何选择合适的框架？

难度：⭐⭐

查看完整解析

① 押题依据

考察你对 RAG 生态的了解，以及技术选型能力。

② 标准答案

主流开源 RAG 框架对比：

框架	特点	适用场景
LangChain	生态最完善，组件丰富	快速原型开发
LlamaIndex	专注数据连接和索引	企业知识库
RAGFlow	国产，可视化强	低代码搭建
Dify	国产，开箱即用	非技术团队
Haystack	模块化，灵活	定制化需求

选择框架的考量：

团队技术栈
- Python 生态：LangChain/LlamaIndex
- 低代码需求：Dify/RAGFlow
项目阶段
- 原型验证：Dify（快速搭建）
- 生产部署：LlamaIndex（性能优化）
- 深度定制：自研（完全可控）
功能需求
- 多数据源接入：LlamaIndex
- Agent 能力：LangChain
- 可视化管理：RAGFlow

自研 vs 开源框架：

维度	开源框架	自研
开发速度	快	慢
灵活性	中	高
维护成本	依赖社区	自己维护
适用	通用场景	特殊需求

③ 前沿加分

Vercel AI SDK：前端友好的 RAG 框架，支持流式输出
Semantic Kernel：微软出品，支持多模型编排
AutoGen：微软多 Agent 框架，支持 RAG + Agent 结合

④ 常见踩坑

❌ 盲目选择"最流行"的框架，不考虑团队能力
❌ 框架版本更新快，生产环境锁定版本不及时
❌ 过度依赖框架，不理解底层原理

⑤ 回答策略

开场句：「RAG 框架选型要看团队、阶段、需求三个维度。」

时间分配：框架对比（1分钟）→ 选型建议（1分钟）→ 自研 vs 开源（30秒）

⑥ 追问预判

「你们用的什么框架？」→ 说出框架名称和选择理由

Q11：搜索系统和 RAG 有什么区别？

难度：⭐⭐

查看完整解析

① 押题依据

很多人把 RAG 理解成"搜索 + 生成"，但两者有本质区别。

② 标准答案

核心区别：

维度	搜索系统	RAG 系统
输出	文档列表（链接/摘要）	自然语言答案
用户行为	用户自己阅读文档	AI 综合多个文档生成答案
检索目标	找到相关文档即可	找到能回答问题的片段
排序依据	相关性 + 权威性 + 时效性	能否支撑答案生成
可解释性	显示匹配关键词	显示引用来源

具体差异：

搜索系统：
- 用户输入：「RAG 是什么」
- 输出：10 篇相关文章链接
- 用户需要：自己点开阅读、筛选、总结
RAG 系统：
- 用户输入：「RAG 是什么」
- 输出：「RAG（检索增强生成）是一种...」+ 来源引用
- 用户需要：直接获得答案

技术层面差异：

技术环节	搜索	RAG
索引粒度	文档级	Chunk 级
排序算法	BM25/PageRank	向量相似度 + Reranker
后处理	摘要提取	LLM 生成

什么时候用搜索，什么时候用 RAG：

用搜索：用户需要多个信息源、需要自己判断、探索性查询
用 RAG：用户需要明确答案、信任 AI 判断、效率优先

③ 前沿加分

混合方案：

先用 RAG 生成答案
同时展示相关文档链接（类似 Perplexity）
用户可以验证答案来源

④ 常见踩坑

❌ 把 RAG 当成"搜索的升级版"，忽略生成质量
❌ 用搜索的评估指标（点击率）评估 RAG
❌ 不考虑用户对"AI 生成答案"的信任度

⑤ 回答策略

开场句：「搜索返回文档列表，RAG 返回生成答案，核心区别在输出形式。」

时间分配：核心区别（1分钟）→ 技术差异（1分钟）→ 选型建议（30秒）

⑥ 追问预判

「能否结合两者优势？」→ 可以，RAG 生成答案 + 展示来源文档

大厂真题（高频）

Q12：构建向量检索库时如何处理时间衰减对召回的影响？

难度：⭐⭐⭐ | 公司：字节（真题）

查看完整解析

① 押题依据

字节真题，考察对时效性场景的工程理解。新闻、舆情、客服等场景中，旧文档的相关性会随时间下降，纯向量检索无法感知时间维度。

② 标准答案

时间衰减问题的核心是：向量相似度不包含时间信息，导致旧文档可能因语义相似而排在前面。

三种解决方案：

混合排序（最常用）

python

final_score = α × vector_similarity + β × time_decay_score
# time_decay_score = exp(-λ × days_since_publish)

优点：简单可控，α/β 可根据业务调整
缺点：需要人工调参

时间分桶 + 分层检索
- 先按时间分桶（近7天/近30天/历史）
- 优先在新桶中检索，不足时再查旧桶
- 适合明确需要最新信息的场景（如"今天的新闻"）
Embedding 时融入时间特征
- 在文档 Embedding 时拼接时间戳向量
- 让模型学习时间和语义的联合表示
- 缺点：需要重新训练 Embedding 模型

实际项目选择：

新闻/舆情：混合排序，β 权重设高（0.4-0.6）
客服知识库：时间分桶，优先返回最新版本文档
通用问答：纯向量检索即可，时间不敏感

③ 前沿加分点

动态权重调整：根据 Query 类型自动调整 α/β（如"最新"关键词出现时提高 β）
用户反馈闭环：收集点击数据，发现旧文档被跳过时自动降权
LLM 辅助判断：检索后让 LLM 判断"这个问题是否需要最新信息"，动态决定是否重排序

④ 常见踩坑

❌ 直接用发布时间排序，忽略语义相关性（变成时间线而非检索）
❌ 时间衰减系数 λ 设置过大，导致稍旧的高质量文档被完全过滤
❌ 没有考虑"常青内容"（如基础概念文档），这类内容不应衰减

⑤ 回答策略

开场句：「时间衰减的核心是向量检索不感知时间，我说三种工程方案。」

结构：混合排序（公式）→ 时间分桶 → Embedding 融合 → 实际项目怎么选

⑥ 追问预判

「α 和 β 怎么定？」→ A/B 测试，或根据业务规则（如新闻类 β=0.5，百科类 β=0.1）
「如何判断哪些文档需要时间衰减？」→ 文档元数据标记（is_time_sensitive 字段）

Q13：知识库动态增量更新时，如何避免新旧文档分布不一致导致的检索偏差？

难度：⭐⭐⭐ | 公司：美团（真题）

查看完整解析

① 押题依据

美团真题，考察对向量检索系统工程问题的理解。增量更新时，新文档的 Embedding 分布可能与旧文档不一致（模型版本、数据分布变化），导致检索偏差。

② 标准答案

问题根源：

旧文档用 Embedding 模型 v1，新文档用 v2 → 向量空间不对齐
新文档数据分布变化（如新增业务线）→ 语义空间漂移
结果：新旧文档相似度不可比，检索结果偏向某一侧

三种解决方案：

全量重建（最彻底）
- 每次模型更新时，重新 Embed 所有历史文档
- 优点：保证一致性
- 缺点：成本高，百万级文档重建耗时长

版本隔离 + 双路召回

旧索引（v1 Embedding）→ 召回 Top-K1
新索引（v2 Embedding）→ 召回 Top-K2
合并后重排序（用统一的 Rerank 模型）

优点：避免重建，新旧文档独立检索
缺点：需要维护多个索引

增量对齐（工程折中）
- 定期抽样旧文档，用新模型重新 Embed
- 计算新旧向量的偏移矩阵，对旧向量做线性变换对齐
- 适合模型微调场景（v1 → v1.1，变化不大）

实际项目选择：

文档量 < 10万：全量重建，成本可控
文档量 > 100万：双路召回 + Rerank
模型微调场景：增量对齐

③ 前沿加分点

在线对齐：实时检测新旧文档召回比例，动态调整双路召回的 Top-K 比例
A/B 测试验证：上线前对比新旧索引的召回效果，量化偏差影响
Embedding 版本管理：在向量数据库中记录每个文档的 Embedding 版本号，支持灰度切换

④ 常见踩坑

❌ 直接用新模型增量更新，不做任何对齐处理（最常见错误）
❌ 双路召回时，新旧索引的 Top-K 比例固定（应根据文档量动态调整）
❌ 没有监控新旧文档的召回分布，问题发现滞后

⑤ 回答策略

开场句：「增量更新的核心问题是向量空间不对齐，我说三种工程方案。」

结构：问题根源（模型版本/数据分布）→ 三种方案（全量/双路/对齐）→ 实际项目怎么选

⑥ 追问预判

「双路召回的 Top-K 比例怎么定？」→ 根据新旧文档数量比例，如新文档占 20%，则 K2 = 0.2 × K
「如何监控检索偏差？」→ 统计新旧文档的召回率、平均排名，设置告警阈值

Q14：RAG 如果有噪声怎么办？

难度：⭐⭐ | 公司：字节、阿里

查看完整解析

① 押题依据

高频题，考察对 RAG 系统鲁棒性的理解。噪声来源多样（检索错误、文档质量差、OCR 错误等），直接影响生成质量。

② 标准答案

噪声来源分类：

检索噪声：召回的文档与 Query 不相关
内容噪声：文档本身质量差（错别字、格式混乱、OCR 错误）
冲突噪声：多个文档内容矛盾

分层解决方案：

阶段1：检索后过滤（Rerank）

python

# 用 Rerank 模型重新打分，过滤低相关文档
rerank_scores = rerank_model(query, retrieved_docs)
filtered_docs = [doc for doc, score in zip(docs, scores) if score > threshold]

常用模型：bge-reranker、cohere-rerank
阈值设置：根据业务容忍度，通常 0.5-0.7

阶段2：生成时降噪

Prompt 工程：明确告知模型"如果文档不相关，直接说不知道"
Self-Consistency：多次生成，选择一致性最高的答案
引用验证：要求模型标注答案来源，人工/自动检查引用是否合理

阶段3：内容质量预处理

文档入库前：去除格式符号、修正 OCR 错误、过滤低质量文档
质量评分：用 LLM 对文档打分（可读性、完整性），低分文档降权或不入库

阶段4：冲突处理

检测冲突：用 LLM 判断多个文档是否矛盾
解决策略：
- 优先信任权威来源（如官方文档 > 论坛帖子）
- 时间优先（新文档 > 旧文档）
- 明确告知用户"存在不同说法"

③ 前沿加分点

Self-RAG：模型自主判断检索结果质量，决定是否使用
CRAG（Corrective RAG）：检索后评估质量，质量低时触发网络搜索补充
噪声注入训练：在 Fine-tuning 时故意加入噪声文档，提升模型鲁棒性

④ 常见踩坑

❌ 只依赖 Rerank，不做生成阶段的降噪（Rerank 也会误判）
❌ 阈值设置过高，导致召回率过低（宁可有噪声，也不能漏掉相关文档）
❌ 没有监控噪声率，问题发现滞后

⑤ 回答策略

开场句：「RAG 噪声分检索噪声和内容噪声，我分四个阶段说解决方案。」

结构：噪声来源 → 检索后过滤 → 生成时降噪 → 内容预处理 → 冲突处理

⑥ 追问预判

「Rerank 阈值怎么定？」→ A/B 测试，平衡准确率和召回率
「如何评估噪声率？」→ 人工标注 Bad Case，统计噪声文档占比

Q15：讲一下 BM25 算法原理。

难度：⭐⭐ | 公司：字节、阿里（高频）

查看完整解析

① 押题依据

字节、阿里高频题，考察对传统检索算法的理解。BM25 是混合检索中的关键词匹配部分，与向量检索互补。

② 标准答案

BM25 核心思想：

BM25（Best Matching 25）是基于 TF-IDF 改进的关键词匹配算法，用于计算查询和文档的相关性分数。

公式（简化版）：

Score(Q, D) = Σ IDF(qi) × (f(qi, D) × (k1 + 1)) / (f(qi, D) + k1 × (1 - b + b × |D| / avgdl))

三个核心要素：

TF（词频）：词在文档中出现次数
- 但有上限：出现 10 次和 100 次的权重差异不大（饱和效应）
- 参数 k1 控制饱和速度（通常 1.2-2.0）
IDF（逆文档频率）：词的稀有程度
- 常见词（如"的"）权重低，稀有词（如"RAG"）权重高
- 公式：log((N - df + 0.5) / (df + 0.5))
文档长度归一化：
- 长文档天然包含更多词，需要归一化
- 参数 b 控制归一化程度（通常 0.75）

与 TF-IDF 的区别：

维度	TF-IDF	BM25
TF 增长	线性增长	饱和增长（有上限）
文档长度	不考虑	归一化处理
效果	基础	更准确

实际应用：

混合检索：BM25（关键词）+ 向量检索（语义）
适用场景：专有名词、产品型号、精确匹配需求

③ 前沿加分点

BM25+：改进版，处理长文档效果更好
学习排序（LTR）：用机器学习模型学习 BM25 参数，而非固定值
神经 BM25：用神经网络学习词权重，替代传统 IDF

④ 常见踩坑

❌ 把 BM25 当成"过时技术"，实际在混合检索中仍然重要
❌ 参数 k1/b 用默认值，不根据数据集调优
❌ 不做分词预处理，导致中文检索效果差

⑤ 回答策略

开场句：「BM25 是改进版 TF-IDF，核心是词频饱和和文档长度归一化。」

结构：核心思想 → 三要素（TF/IDF/长度）→ 与 TF-IDF 对比 → 实际应用

⑥ 追问预判

「BM25 和向量检索哪个更好？」→ 互补，BM25 擅长精确匹配，向量检索擅长语义理解
「k1 和 b 怎么调？」→ k1 控制词频饱和（1.2-2.0），b 控制长度归一化（0.75 常用）

Q16：意图识别是否做过？如何实现？

难度：⭐⭐ | 公司：字节、阿里

查看完整解析

① 押题依据

高频题，考察对用户意图理解的工程实现。意图识别是 RAG/Agent 系统的前置环节，决定后续流程。

② 标准答案

意图识别的作用：

在 RAG/Agent 系统中，用户输入可能有多种意图：

知识查询（"RAG 是什么"）
任务执行（"帮我订机票"）
闲聊（"你好"）
多轮对话（"那它和 Fine-tuning 有什么区别"）

意图识别决定：是否检索、调用哪个工具、如何生成回答。

三种实现方式：

1. 规则匹配（最简单）

python

if "是什么" in query or "介绍" in query:
    intent = "knowledge_query"
elif "帮我" in query or "订" in query:
    intent = "task_execution"

优点：快速、可控
缺点：覆盖不全，维护成本高

2. 分类模型（传统方案）

训练文本分类模型（BERT/RoBERTa）
输入：用户 Query
输出：意图类别（knowledge/task/chitchat）
需要标注数据（通常 1000+ 条）

3. LLM 判断（当前主流）

python

prompt = f"""
判断用户意图，返回 JSON：
用户输入：{query}
意图类别：knowledge_query / task_execution / chitchat / clarification
"""
intent = llm.generate(prompt)

优点：零样本/少样本即可，灵活
缺点：延迟高（增加一次 LLM 调用）

实际项目选择：

意图类别少（<5 种）：规则匹配
意图复杂、有标注数据：分类模型
快速迭代、意图多变：LLM 判断

③ 前沿加分点

多意图识别：一句话包含多个意图（"介绍 RAG 并帮我生成示例代码"）
意图澄清：识别到模糊意图时，主动追问用户
上下文意图：结合对话历史判断意图（"那它呢"需要回溯上文）

④ 常见踩坑

❌ 所有 Query 都走检索，不做意图过滤（闲聊也检索，浪费资源）
❌ 意图分类过细，导致边界模糊、准确率低
❌ 不做意图置信度判断，低置信度时应该追问而非直接执行

⑤ 回答策略

开场句：「意图识别决定 RAG 是否检索，我说三种实现方式。」

结构：意图识别作用 → 三种方式（规则/模型/LLM）→ 实际项目怎么选

⑥ 追问预判

「意图识别错了怎么办？」→ 设置置信度阈值，低置信度时追问用户
「如何处理多意图？」→ 拆解为多个子任务，分别执行

Q17：检索做了哪些优化？追问：子问题分解怎么做？

难度：⭐⭐⭐ | 公司：字节（真题）

查看完整解析

① 押题依据

字节真题，考察对检索优化的系统性理解。子问题分解是复杂查询的关键技术。

② 标准答案

检索优化的五个层次：

1. 查询改写（Query Rewriting）

用 LLM 将用户问题改写为更适合检索的形式
例：「RAG 咋样」→ 「RAG 的优缺点是什么」
技术：Few-shot Prompt 或 Fine-tuning

2. 查询扩展（Query Expansion）

添加同义词、相关词
例：「大模型」→ 「大模型 OR LLM OR 大语言模型」
技术：词典匹配或 LLM 生成

3. 混合检索（Hybrid Search）

向量检索（语义）+ BM25（关键词）
融合策略：RRF（Reciprocal Rank Fusion）
适用：专有名词、产品型号查询

4. 多路召回

同时用多个 Embedding 模型检索，取并集
例：通用模型 + 领域模型
提升召回率，但增加计算成本

5. Reranker 精排

召回 Top-20，用 Cross-Encoder 重排序，输出 Top-5
模型：bge-reranker-large
权衡：准确率 ↑，延迟 ↑

子问题分解（重点）：

适用场景：

复杂问题：「对比 RAG 和 Fine-tuning 的成本、效果、适用场景」
多跳推理：「张三的领导的部门预算是多少」

实现方式：

方式1：LLM 分解

python

prompt = f"""
将复杂问题拆解为子问题：
原问题：{query}
子问题列表（JSON 格式）：
"""
sub_queries = llm.generate(prompt)
# 输出：["RAG 的成本", "Fine-tuning 的成本", "RAG 的效果", ...]

方式2：模板分解

预定义分解模板（如"对比类"→ 拆成"A 的特点"+"B 的特点"）
适合固定场景

分解后的处理：

并行检索：每个子问题独立检索
结果合并：将所有检索结果拼接
统一生成：LLM 基于合并结果生成最终答案

③ 前沿加分点

自适应分解：LLM 判断是否需要分解，简单问题直接检索
分解 + 验证：生成子问题后，让 LLM 验证是否完整覆盖原问题
迭代分解：根据第一轮检索结果，动态生成新的子问题

④ 常见踩坑

❌ 所有问题都分解，简单问题反而效果变差
❌ 子问题过多（>5 个），导致检索成本高、噪声多
❌ 子问题之间有依赖关系，但并行检索（应该串行）

⑤ 回答策略

开场句：「检索优化分五个层次，子问题分解是处理复杂查询的关键。」

结构：五个优化层次（改写/扩展/混合/多路/Rerank）→ 子问题分解（场景/实现/处理）

⑥ 追问预判

「子问题分解会增加多少延迟？」→ 增加 1 次 LLM 调用（~1s）+ N 次并行检索
「如何判断是否需要分解？」→ 用 LLM 判断问题复杂度，或根据问题长度/关键词

Q18："召回-过滤-生成"三段式 Pipeline 能细讲一下吗？

难度：⭐⭐⭐ | 公司：字节（真题）

查看完整解析

① 押题依据

字节真题，考察对 RAG 工程架构的理解。三段式是生产环境的标准做法，平衡召回率、精准率和延迟。

② 标准答案

三段式 Pipeline 架构：

用户 Query
    ↓
【召回阶段】Recall：快速粗排，召回候选集（Top-100）
    ↓
【过滤阶段】Rerank：精准重排，过滤噪声（Top-10）
    ↓
【生成阶段】Generate：LLM 基于精选文档生成答案

各阶段详解：

阶段1：召回（Recall）

目标：高召回率，不漏掉相关文档
技术：
- 向量检索（ANN 算法，如 HNSW）
- BM25 关键词检索
- 混合检索（两者融合）
召回数量：Top-50 ~ Top-100
延迟：<100ms
权衡：速度优先，允许一定噪声

阶段2：过滤/重排序（Rerank）

目标：提升精准率，过滤噪声
技术：
- Cross-Encoder 模型（如 bge-reranker-large）
- 输入：Query + 每个文档，输出相关性分数
- 比向量检索更准确，但计算慢
输出数量：Top-5 ~ Top-10
延迟：100-300ms
权衡：准确率优先，计算成本高

阶段3：生成（Generate）

目标：基于精选文档生成答案
技术：
- 将 Top-5 文档拼接进 Prompt
- LLM 生成答案 + 来源引用
延迟：1-3s（取决于模型和输出长度）

为什么要三段式？

方案	问题
只用向量检索	精准率低，噪声多
只用 Rerank	计算成本高，无法处理大规模文档
三段式	平衡召回率、精准率、延迟

实际工程优化：

召回阶段：用 GPU 加速向量检索
过滤阶段：批量 Rerank，减少 API 调用
生成阶段：流式输出，降低用户感知延迟

③ 前沿加分点

四段式：召回 → 粗排 → 精排 → 生成（大规模场景，如电商搜索）
动态 Top-K：根据 Query 复杂度动态调整召回数量
缓存优化：高频 Query 缓存召回结果，跳过召回阶段

④ 常见踩坑

❌ 召回数量过少（Top-10），导致召回率低
❌ Rerank 用在所有 Query 上，导致延迟过高（应该只对复杂 Query 用）
❌ 生成阶段不做 Chunk 排序，直接拼接（Lost in the Middle 问题）

⑤ 回答策略

开场句：「三段式是 RAG 生产架构，核心是平衡召回率、精准率和延迟。」

结构：架构图 → 三阶段详解（召回/过滤/生成）→ 为什么三段式 → 工程优化

⑥ 追问预判

「召回和 Rerank 的 Top-K 怎么定？」→ 召回 50-100（保证召回率），Rerank 5-10（控制延迟）
「能否跳过 Rerank？」→ 可以，简单 Query 或延迟敏感场景

Q19：介绍 Function Calling 和 MCP。

难度：⭐⭐ | 公司：字节、阿里

查看完整解析

① 押题依据

高频题，考察对 LLM 工具调用机制的理解。Function Calling 是 Agent 的核心能力，MCP 是 2024 年的新标准。

② 标准答案

Function Calling（函数调用）：

核心思想： 让 LLM 能够调用外部工具/API，而不只是生成文本。

工作流程：

定义工具：描述函数名、参数、功能

json

{
  "name": "get_weather",
  "description": "获取指定城市的天气",
  "parameters": {
    "city": {"type": "string", "description": "城市名"}
  }
}

LLM 判断：根据用户输入，决定是否调用工具
- 用户：「北京天气怎么样」
- LLM 输出：{"function": "get_weather", "arguments": {"city": "北京"}}
执行工具：系统调用真实 API，获取结果
- 返回：{"temperature": 15, "condition": "晴"}
LLM 生成：基于工具返回结果，生成自然语言回答
- 输出：「北京今天 15 度，晴天」

支持 Function Calling 的模型：

OpenAI GPT-4/GPT-3.5（原生支持）
Claude 3.5（Tool Use）
国产模型：通义千问、文心一言（部分支持）

MCP（Model Context Protocol）：

背景： 2024 年 Anthropic 推出的开放标准，统一 LLM 与外部工具的交互协议。

核心特点：

标准化协议：
- 定义统一的工具描述格式
- 支持多种工具类型（API/数据库/文件系统）
- 类似"LLM 的 USB 接口"
与 Function Calling 的区别：

维度	Function Calling	MCP
范围	单次函数调用	持久化上下文连接
状态	无状态	有状态（可保持连接）
适用	简单工具调用	复杂系统集成

实际应用：
- 连接企业内部系统（CRM/ERP）
- 访问私有数据库
- 文件系统操作

③ 前沿加分点

多工具编排：LLM 自主决定调用顺序（先查天气，再推荐穿搭）
工具链（Tool Chain）：一个工具的输出作为另一个工具的输入
MCP Server：社区正在构建 MCP 工具生态（类似 Chrome 插件市场）

④ 常见踩坑

❌ 工具描述不清晰，导致 LLM 误判是否调用
❌ 不做参数校验，LLM 生成的参数可能不合法
❌ 工具调用失败时没有降级方案（应该告知用户或重试）

⑤ 回答策略

开场句：「Function Calling 让 LLM 能调用工具，MCP 是统一的工具协议标准。」

结构：Function Calling 原理（流程）→ MCP 介绍（背景/特点/对比）→ 实际应用

⑥ 追问预判

「如何保证 LLM 正确调用工具？」→ 清晰的工具描述 + Few-shot 示例 + 参数校验
「MCP 和 LangChain Tools 有什么区别？」→ MCP 是协议标准，LangChain 是实现框架

Q20：高并发 Agent 系统中，如何优化召回和生成阶段的延迟？

难度：⭐⭐⭐ | 公司：字节（真题）

查看完整解析

① 押题依据

字节真题，考察对 RAG/Agent 系统性能优化的理解。高并发场景下，延迟和成本是核心挑战。

② 标准答案

召回阶段优化（目标：<100ms）：

1. 向量检索优化

索引算法：HNSW（精准）vs IVF（快速），根据场景选择
量化压缩：向量从 float32 → int8，存储和计算成本降低 4 倍
GPU 加速：用 GPU 做向量相似度计算（适合大规模场景）

2. 缓存策略

热点 Query 缓存：高频问题缓存召回结果（如"什么是 RAG"）
TTL 设置：根据知识库更新频率设置缓存过期时间
缓存命中率监控：目标 >30%

3. 并行召回

向量检索 + BM25 并行执行，而非串行
用异步 I/O 减少等待时间

生成阶段优化（目标：<3s）：

1. 模型选择

分层模型：简单 Query 用小模型（GPT-3.5），复杂 Query 用大模型（GPT-4）
本地部署：高并发场景自部署开源模型（Llama/Qwen），降低 API 成本

2. 流式输出

用 SSE（Server-Sent Events）流式返回，降低用户感知延迟
首 token 延迟 <500ms 即可开始输出

3. Prompt 优化

压缩上下文：只传递关键 Chunk，不传递完整文档
减少输出长度：限制生成 token 数（如 max_tokens=500）

4. 批处理（Batching）

多个请求合并为一个 Batch 调用 LLM
适合 API 调用场景，降低成本

系统架构优化：

1. 异步处理

用户请求 → 立即返回 request_id
后台异步处理 → 完成后推送结果

2. 限流 + 降级

高峰期限流，超过阈值返回"系统繁忙"
降级方案：关闭 Rerank、减少召回数量

3. 负载均衡

多实例部署，用 Nginx/K8s 做负载均衡
向量数据库分片（Sharding）

③ 前沿加分点

预计算：离线预生成高频问题的答案，在线直接返回
模型蒸馏：用大模型生成数据，训练小模型，降低推理成本
边缘计算：将小模型部署到边缘节点，降低网络延迟

④ 常见踩坑

❌ 只优化单个环节，忽略整体链路（召回快但生成慢，总延迟仍高）
❌ 过度缓存，导致知识库更新后用户看到旧答案
❌ 不做监控，不知道瓶颈在哪个环节

⑤ 回答策略

开场句：「高并发优化分召回和生成两阶段，我从技术和架构两个层面说。」

结构：召回优化（索引/缓存/并行）→ 生成优化（模型/流式/Prompt）→ 架构优化（异步/降级/负载均衡）

⑥ 追问预判

「如何监控延迟？」→ 分段监控（召回/Rerank/生成），用 P95/P99 指标
「成本和延迟如何权衡？」→ 根据业务场景，ToC 优先延迟，ToB 可接受稍高延迟

Q21：让 Agent 调用搜索引擎，如何避免无关结果影响回答？

难度：⭐⭐ | 公司：字节（真题）

查看完整解析

① 押题依据

字节真题，考察对 Agent 工具调用鲁棒性的理解。搜索引擎返回结果质量不可控，需要过滤和验证。

② 标准答案

问题根源： 搜索引擎（Google/Bing）返回的结果可能包含：

广告、SEO 垃圾内容
与 Query 弱相关的结果
过时信息

如果 Agent 直接使用这些结果，会生成低质量答案。

四层过滤方案：

层1：搜索前优化（Query 改写）

用 LLM 将用户问题改写为更精准的搜索词
例：「RAG 咋样」→ 「RAG 检索增强生成优缺点」
添加时间限制：「site:arxiv.org after:2024」

层2：搜索后过滤（结果筛选）

2.1 基于规则过滤

python

# 过滤广告、低质量网站
blacklist = ["广告", "SEO", "垃圾站"]
filtered = [r for r in results if not any(b in r.url for b in blacklist)]

2.2 相关性评分

用 Rerank 模型对搜索结果重新打分
过滤相关性分数 <0.5 的结果
只保留 Top-3 ~ Top-5

2.3 内容质量检查

检查结果长度（过短可能是导航页）
检查是否包含关键词
检查来源权威性（如 .edu/.gov 优先）

层3：生成时验证（Prompt 工程）

在 Prompt 中明确指示：

以下是搜索结果，可能包含无关内容：
{search_results}

要求：
1. 只使用与问题直接相关的信息
2. 如果所有结果都不相关，回答"未找到相关信息"
3. 标注信息来源

层4：生成后检查（答案验证）

4.1 引用验证

检查答案中的事实是否真的出现在搜索结果中
用 LLM 做 Faithfulness 检查

4.2 置信度判断

让 LLM 输出置信度分数（0-1）
低置信度时提示用户"答案可能不准确"

实际工程实践：

场景	策略
事实查询	优先使用权威来源（Wikipedia/官网）
时效性查询	添加时间过滤（after:2024）
专业领域	限定搜索范围（site:arxiv.org）

③ 前沿加分点

多源验证：同时搜索多个引擎，交叉验证结果
Self-RAG：Agent 自主判断搜索结果质量，决定是否使用
用户反馈闭环：收集用户对答案的评价，优化过滤策略

④ 常见踩坑

❌ 直接使用搜索引擎的 Top-1 结果，不做任何过滤
❌ 过滤规则过严，导致有用信息也被过滤
❌ 不标注信息来源，用户无法验证答案

⑤ 回答策略

开场句：「搜索结果质量不可控，我说四层过滤方案。」

结构：问题根源 → 四层过滤（搜索前/搜索后/生成时/生成后）→ 实际工程实践

⑥ 追问预判

「如何判断来源权威性？」→ 域名白名单（.edu/.gov/知名媒体）+ PageRank
「过滤后没有结果怎么办？」→ 放宽过滤条件，或明确告知用户"未找到相关信息"

Q22：传统 RAG 是"先检索后生成"，你了解自适应检索等更复杂的 RAG 范式吗？

难度：⭐⭐⭐⭐

查看完整解析

① 押题依据

前沿题，考察对 RAG 演进方向的理解。2024-2025 年 RAG 从 Naive RAG 演进到 Agentic RAG，面试官考察你是否跟进前沿。

② 标准答案

RAG 范式演进：

第一代：Naive RAG（朴素 RAG）

用户提问 → 检索 → 生成答案

特点：固定流程，一次检索
问题：
- 不需要检索的问题也检索（浪费资源）
- 检索不到时无法补救
- 无法处理多跳推理

第二代：Self-RAG（自适应 RAG）

核心思想：让 LLM 自主决定是否检索、何时检索。

工作流程：

判断是否需要检索
- LLM 评估：这个问题需要外部知识吗？
- 不需要：直接生成答案（如"1+1=?"）
- 需要：触发检索
评估检索结果质量
- LLM 判断：检索到的文档相关吗？
- 相关：使用
- 不相关：触发网络搜索或拒答
验证生成答案
- LLM 自我检查：答案是否基于检索内容？
- 是：输出答案
- 否：重新生成

优势：减少无效检索，提升准确率

第三代：CRAG（Corrective RAG）

核心思想：检索后纠错，质量低时补充检索。

工作流程：

检索 → 质量评估 → 
  - 高质量：直接生成
  - 中等质量：改写 Query 重新检索
  - 低质量：触发网络搜索

第四代：Agentic RAG（Agent 化 RAG）

核心思想：RAG 作为 Agent 的一个工具，Agent 自主编排检索策略。

能力：

多轮检索：根据第一轮结果，决定是否继续检索
检索策略选择：向量检索 vs 关键词检索 vs 网络搜索
多源融合：同时检索知识库、数据库、API

示例：

用户：「对比 RAG 和 Fine-tuning」
Agent 规划：
  1. 检索 RAG 相关文档
  2. 检索 Fine-tuning 相关文档
  3. 综合生成对比答案

第五代：GraphRAG（图谱 RAG）

核心思想：用知识图谱替代向量检索，处理多跳推理。

适用场景：

多跳推理：「张三的领导的部门预算」
实体关系密集：组织架构、供应链

各范式对比：

范式	检索次数	自主性	复杂度	适用场景
Naive RAG	1 次固定	无	低	简单问答
Self-RAG	0-N 次	中	中	通用场景
CRAG	1-N 次	中	中	质量敏感
Agentic RAG	N 次	高	高	复杂任务
GraphRAG	图谱遍历	中	高	多跳推理

③ 前沿加分点

混合范式：根据问题类型动态选择范式（简单问题用 Naive，复杂问题用 Agentic）
强化学习优化：用 RL 训练 Agent 的检索策略
多模态 RAG：检索文本 + 图片 + 表格，统一生成答案

④ 常见踩坑

❌ 盲目追求复杂范式，忽略实际需求（大部分场景 Naive RAG 足够）
❌ Self-RAG 判断不准确，导致该检索时不检索
❌ Agentic RAG 成本高（多次 LLM 调用），不做成本控制

⑤ 回答策略

开场句：「RAG 从 Naive 演进到 Agentic，核心是让模型自主决定检索策略。」

结构：五代范式（Naive/Self/CRAG/Agentic/Graph）→ 对比表 → 实际选型建议

⑥ 追问预判

「你们项目用的哪种范式？」→ 说出范式和选择理由
「Self-RAG 如何判断是否需要检索？」→ 用 LLM 做二分类，或训练专门的判断模型

高概率题库 · RAG 系统方向（22题） ​

一、RAG 系统方向（22题） ​

核心原理 ​

检索优化 ​

评估与工程实践 ​

大厂真题（高频） ​

高概率题库 · RAG 系统方向（22题）

一、RAG 系统方向（22题）

核心原理

检索优化

评估与工程实践

大厂真题（高频）