Agent面试-RAG篇

Q1: 请解释 RAG 的工作原理。与直接对 LLM 进行微调相比，RAG 主要解决了什么问题？​

​

RAG的核心是"检索+生成"两阶段：先从外部知识库中检索与用户问题相关的文档片段，再将这些片段作为上下文拼入prompt，让 LLM 基于检索到的信息生成回答。相比微调，RAG 的优势在于： ​

知识可实时更新，不需要重新训练模型；​

可追溯来源，减少幻觉且便于审计；​

成本低，不需要 GPU 资源做训练；​

领域迁移方便，换一套知识库即可适配新场景。​

微调的优势则在于风格适配和深层知识内化，实际中常将两者结合：微调让模型学会"如何利用检索结果"，RAG 提供最新知识。​

​

Q2: 一个完整的 RAG 流水线包含哪些关键步骤？​

​

完整流程分为离线索引和在线查询两部分。​

离线索引：①数据采集（PDF/网页/数据库等多源数据）→②文档解析（表格、图片用专门工具如 LlamaParse 处理）→③文本切块（按语义/固定长度切分，设置重叠）→④向量化（用 Embedding 模型如 BGE/M3E 生成向量）→⑤存入向量数据库（Milvus/Chroma/Weaviate）。​

在线查询：①Query 改写（扩展、纠错、多语言统一）→②检索（向量检索 + BM25 混合）→③重排序（用 Cross-Encoder 如 BGE-Reranker 精排）→④Prompt 组装（将 top-k 文档拼入 system prompt）→⑤LLM 生成→⑥后处理（格式化、来源引用标注）。​

​

Q3: 文本切块策略至关重要。你会如何选择合适的切块大小和重叠长度？​

​

切块大小的权衡： 小块（128-256 tokens）检索精度高但可能丢失上下文，大块（512-1024 tokens）上下文完整但引入噪声。经验值通常 256-512 tokens，重叠 10-20%。​

实际选择取决于：​

文档类型——法律合同用大块保完整条款，FAQ 用小块精准匹配；​

Embedding 模型的最大长度限制；​

LLM 的上下文窗口大小（决定能放多少块）。​

高级策略包括：递归切块（按标题→段落→句子层级切分）、语义切块（用 Embedding 相似度判断分割点）、父子块索引（小块检索，返回时拼上父块提供上下文）。建议用 RAGAS 等工具做 A/B 测试，用检索召回率和最终回答质量来选最优参数。​

​

Q4: 如何选择一个合适的嵌入模型？评估一个 Embedding 模型的好坏有哪些指标？​

​

选型考虑：​

语言支持（中文场景优先 BGE、M3E、GTE，英文可用 OpenAI text-embedding-3）；​

维度和性能（高维精度好但存储和检索成本高）；​

最大输入长度（影响切块策略）；​

推理速度和部署成本。​

评估指标：在 MTEB（Massive Text Embedding Benchmark）排行榜上对比，核心指标包括——Recall@K（检索召回率）、MRR（平均倒数排名）、NDCG（归一化折损累积增益）。实际中要用自己的领域数据构造测试集评估，因为通用排行榜上的冠军在你的垂直领域未必最优。还要考虑对称 vs 非对称检索——query 短、document 长时需要非对称模型（如 E5 系列）效果更好。​

​

Q5: 除了基础的向量检索，你还知道哪些可以提升 RAG 检索质量的技术？​

​

混合检索：向量检索（语义匹配）+ BM25（关键词匹配）互补，用 RRF（Reciprocal Rank Fusion）融合排序。​

Query 改写：HyDE（让 LLM 先生成假设性答案再用答案去检索）、Query Expansion（扩展同义词）、Multi-Query（将一个问题拆成多个子问题分别检索再合并）。​

重排序：检索后用 Cross-Encoder（如 BGE-Reranker、Cohere Rerank）对候选文档精排，大幅提升精度。​

知识图谱增强：对实体关系密集的场景（如医疗、金融），用图检索补充结构化知识。​

上下文压缩：对检索到的长文档做摘要或提取关键句，减少噪声。​

递归检索：先粗检索大范围文档，再在文档内精检索具体段落。​

​

Q6: 请解释"Lost in the Middle"问题。​

​

"Lost in the Middle" 是 Stanford 2023 年的研究发现：当多个检索文档放入 LLM 的上下文时，模型倾向于关注开头和结尾的文档，而忽略中间部分的信息。即使正确答案在中间位置，回答准确率也会显著下降。​

缓解方法：​

将最相关的文档放在开头或结尾（按相关性交替排列而非顺序排列）；​

​

Q7: 在什么场景下，你会选择使用图数据库或知识图谱来增强或替代传统的向量数据库检索？​

​

适合知识图谱的场景：①需要多跳推理（如"张三的老板的母校是哪？"需要跨两个关系跳转）；②实体关系密集的领域（医学：药物-疾病-症状、金融：公司-人物-持股）；③需要精确的结构化查询（"列出所有市值超过100亿且在北京的公司"）；④数据有明确的图结构（组织架构、社交网络）。​

实践方案：GraphRAG（微软开源）先对文档做实体抽取和关系建图，查询时用图遍历+向量检索混合。也可以用 Neo4j 存知识图谱，Cypher 查询结构化关系，向量库查语义相关性，两路结果融合。知识图谱的劣势是构建成本高、实体抽取质量依赖模型能力、难以覆盖非结构化长文本。​

​

Q8: 如何全面地评估一个 RAG 系统的性能？​

​

分两阶段评估。​

​

Q9: 你是否了解一些更复杂的 RAG 范式，比如自适应检索？​

​

Adaptive RAG：根据查询复杂度动态决定是否需要检索。简单问题（如"法国首都是哪"）LLM 直接回答，复杂问题才触发检索。可用分类器或 LLM 自身判断。​

Iterative RAG（迭代式）：ITER-RETGEN 等方法在生成过程中发现信息不足时再次检索，多轮迭代直到信息充分。​

Self-RAG：模型自己判断是否需要检索、检索到的文档是否有用、生成的回答是否被检索内容支持，通过特殊 token 实现自省。​

Corrective RAG (CRAG)：对检索结果做可信度评估，不可信时回退到 web 搜索或直接拒答。​

​

Q10: RAG 系统在实际部署中可能面临哪些挑战？​

​

数据层：文档格式多样（PDF 表格、扫描件、图片）解析困难；数据更新频率高时增量索引成本大；多语言混合场景下 Embedding 效果差。​

检索层：长尾 query 召回率低；同义词/近义词匹配不准；检索延迟在高并发下增长。​

生成层：幻觉（检索到了但没用或编造了不在文档中的信息）；上下文窗口不够放所有相关文档；生成结果不可控（格式/长度）。​

工程层：向量数据库选型和运维成本；Embedding 模型更新后需要全量重建索引；缓存策略设计；监控和评估体系搭建。​

安全层：知识库中的敏感信息可能被检索出来返回给无权限用户，需要做文档级别的权限控制。​

​

Q11: 了解搜索系统吗？和 RAG 有什么区别？​

​

传统搜索系统返回的是文档列表（链接），由用户自己阅读和理解；RAG 返回的是生成式答案，直接回答用户问题。搜索系统的核心是 "召回 + 排序"（BM25/Learning to Rank），RAG 在此基础上增加了 "生成" 环节。​

相似点：都涉及 query 理解、文档检索、相关性排序。​

​

Q12: 知道或者使用过哪些开源 RAG 框架？如何选择？​

​

RAGFlow：端到端 RAG 平台，内置文档解析（深度 PDF / 表格处理）、切块、检索、生成全流程，适合快速搭建完整系统。​

LlamaIndex：以数据索引为核心，适合复杂的数据连接和查询场景（SQL + 向量混合查询）。​

LangChain：通用 LLM 应用框架，RAG 是其中一个模块，适合需要灵活组合各组件的场景。​

Haystack：Deepset 出品，生产级 RAG 框架，组件化设计，适合企业部署。​

​

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

​

在新闻、论坛、工单等场景中，新文档通常比旧文档更有价值。​

​

Q14: 对知识库文件进行动态增量更新，怎么避免新旧文档分布不一致导致的检索偏差？​

​

分布不一致的原因通常是：新旧文档用了不同版本的 Embedding 模型，或者文档风格 / 长度差异大。​

解决方案：​

统一 Embedding 版本：更换模型后全量重建索引，不要混用新旧模型的向量；​

增量索引设计：新文档写入临时索引，定期（如每周）与主索引合并，合并时统一重新编码；​

文档版本管理：同一主题的旧文档在新版本入库后标记为过期，检索时过滤或降权；​

分布对齐：监控新旧文档的向量分布（用 t-SNE 可视化），如果偏差过大及时触发全量重建；​

Query-Time 归一化：对检索分数做归一化处理，消除不同时期文档的分数尺度差异。​

​

Q15: RAG 如果有噪声怎么办？​

​

噪声包括：检索到不相关的文档、文档中包含错误信息、文档质量参差不齐。​

应对策略：​

入库环节：数据清洗（去重、过滤低质量文档）、质量评分（用模型给文档打分，低于阈值不入库）；​

检索环节：提高检索阈值（相似度低于 0.7 的不返回）、用 Reranker 精排过滤掉低相关性结果、限制返回数量（top-3 比 top-10 噪声少）；​

生成环节：在 prompt 中明确指示 "如果提供的信息不足以回答，请说不知道"、要求模型引用来源便于验证；​

后处理：用事实核查模型（如 FActScore）检测幻觉，对置信度低的回答加提示标注。​

​

Q16: 讲一下 BM25 算法原理​

​

BM25 是经典的稀疏检索算法，基于词频（TF）和逆文档频率（IDF）。核心公式：score(Q,D) = Σ IDF(qi) * (f(qi,D) * (k1+1)) / (f(qi,D) + k1 * (1 - b + b * |D|/avgdl))其中：​

•

f(qi,D) 是词 qi 在文档 D 中的词频；​

•

|D| 是文档长度；​

•

avgdl 是平均文档长度；​

​

Q17: 是否做过意图识别？如果要做意图识别，可以怎么实现？​

​

意图识别的目标是判断用户查询属于哪种类型（闲聊 / 知识问答 / 任务执行 / 投诉等），以便路由到不同处理流程。​

实现方案：​

LLM 直接分类：在 prompt 中列出意图类别和描述，让 LLM 判断，简单高效但延迟高、成本大；​

轻量分类模型：用 BERT/RoBERTa 微调一个多分类器，延迟低（<10ms），适合高并发；​

Few-shot + 向量检索：预定义每种意图的典型 query，用向量相似度匹配最接近的意图；​

规则 + 模型混合：关键词规则处理明确意图（如包含 "投诉" 直接路由），模糊意图交给模型。​

​

Q18: 介绍检索做的优化，具体追问子问题分解怎么做？​

​

检索优化的典型手段：混合检索、Query 改写、Reranker 精排（前面已详述）。​

子问题分解（Query Decomposition）具体做法：用 LLM 将复杂问题拆分为多个简单子问题，分别检索后合并结果。例如 "对比 Tesla 和 BYD 2024 年的销量和利润" 拆为：​

•

"Tesla 2024 销量"​

•

"Tesla 2024 利润"​

•

"BYD 2024 销量"​

•

"BYD 2024 利润" 四个子查询。​

实现方式：① Few-shot prompt 让 LLM 输出子问题列表；② 对每个子问题独立检索 top-K；③ 合并去重后送入 LLM 生成最终答案。​

LangChain 的 MultiQueryRetriever 和 LlamaIndex 的 SubQuestionQueryEngine 都封装了这个能力。注意控制子问题数量（一般不超过 5 个），否则检索成本线性增长。​

​

Q19: 在 RAG 里的 "召回 - 过滤 - 生成" 三段式 pipeline 能细讲一下吗？​

​

•

召回阶段：目标是高召回率，宁多勿少。用混合检索（向量 + BM25）从知识库中捞出 top-50~100 候选文档。这一步追求速度，用 ANN（近似最近邻）索引如 HNSW/IVF 加速。​

​

Q20: 介绍一下 Function Calling 和 MCP​

​

Function Calling 是 OpenAI 首创的机制：在 API 调用时定义可用函数的 schema（名称、参数、描述），LLM 根据用户请求判断是否需要调用函数，并输出结构化的函数名和参数 JSON。开发者执行函数后将结果返回给 LLM 继续生成。核心是让 LLM 学会 "何时调用" 和 "如何填参数"。​

MCP（Model Context Protocol）是 Anthropic 提出的开放协议，标准化了 LLM 与外部工具 / 数据源的连接方式。类似 USB-C 接口标准 —— 任何工具只要实现 MCP Server 接口，任何 LLM 客户端只要支持 MCP Client，就能即插即用。MCP 比 Function Calling 更通用：不局限于单个 API 提供商，支持资源（Resources）、工具（Tools）、提示模板（Prompts）三类能力的标准化暴露。​

​

Q21: 在高并发查询 Agent 系统中，你会如何优化召回和生成阶段的延迟？​

​

召回优化：​

向量数据库选用支持 GPU 加速的方案（如 Milvus GPU 版），或用 HNSW 索引提升 CPU 检索速度；​

引入缓存层 —— 对热门 query 用 Redis 缓存检索结果（精确匹配）或语义缓存（Embedding 相似度 > 0.95 复用结果）；​

预计算 —— 高频文档的 Embedding 预加载到内存；​

异步并行 ——BM25 和向量检索并行执行。​

生成优化：​

用 vLLM/TGI 做推理服务，利用 Continuous Batching 和 PagedAttention 提升吞吐；​

KV Cache 优化减少重复计算；​

流式输出（SSE）降低首 token 延迟；​

小模型分流 —— 简单问题用 7B 模型，复杂问题才用大模型；​

prompt 压缩 —— 用 LLMLingua 等工具压缩上下文长度。​

​

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

​

•

搜索前：Query 改写，将用户问题转化为更适合搜索引擎的关键词组合（去除口语化表述、提取核心关键词）。​

•

搜索后过滤：① 相关性重排 —— 用 Cross-Encoder 对搜索结果与原始 query 打分，过滤低于阈值的；② 来源可信度过滤 —— 维护可信域名白名单，降权或过滤低质量来源；③ 内容去重 —— 多个结果说同一件事只保留最优质的；④ 摘要提取 —— 不把整个网页塞入 prompt，而是提取与 query 最相关的段落。​

•

生成时：在 prompt 中指示 LLM"仅基于搜索结果中与问题直接相关的信息回答"、"忽略不相关的搜索结果"。还可以让 LLM 先判断搜索结果是否足以回答，不足时再发起补充搜索或直接告知用户。​

​