首页 > Agent面试-RAG篇
头像
debug 到凌晨 3
编辑于 昨天 19:28 浙江
+ 关注

Agent面试-RAG篇

也大大小小面了很多内部正在搞AI的公司,给大家分享一下我的面试题库!

第一章:RAG 系统

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

RAG(Retrieval-Augmented Generation)的核心是"检索+生成"两阶段:先从外部知识库中检索与用户问题相关的文档片段,再将这些片段作为上下文拼入 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 的上下文时,模型倾向于关注开头和结尾的文档,而忽略中间部分的信息。即使正确答案在中间位置,回答准确率也会显著下降。

缓解方法:①将最相关的文档放在开头或结尾(按相关性交替排列而非顺序排列);②减少输入文档数量,只保留 top-3 而非 top-10;③使用 Map-Reduce 策略(先让 LLM 对每个文档单独提取信息,再合并);④使用长上下文优化过的模型(如 Claude、GPT-4 Turbo 在长文本上注意力分布更均匀);⑤对检索结果做上下文压缩,缩短每个文档的长度。

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

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

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

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

分两阶段评估。

检索阶段:Recall@K(top-K 中包含正确文档的比例)、Precision@K(top-K 中正确文档的占比)、MRR(正确文档首次出现的排名倒数)、NDCG(考虑排名位置的加权指标)。

生成阶段:Faithfulness(回答是否忠实于检索到的文档,不编造)、Answer Relevancy(回答是否切题)、Context Relevancy(检索文档是否与问题相关)。

端到端指标:任务完成率、人工评分。

工具:RAGAS 框架可以自动化评估 Faithfulness/Relevancy/Context Precision 等,LangSmith 可做链路追踪和质量监控。建议构建 golden test set(100-200 条带标注的 QA 对),每次迭代后回归测试。

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

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

Iterative RAG(迭代式):ITER-RETGEN 等方法在生成过程中发现信息不足时再次检索,多轮迭代直到信息充分。

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

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

Agentic RAG:将 RAG 作为 Agent 的一个工具,Agent 自主决定何时检索、检索什么、检索几次,结合规划和反思能力。实际中 Agentic RAG 是当前的主流趋势。

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

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

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

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

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

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

全部评论

(12) 回帖
加载中...
话题 回帖

近期热帖

热门推荐