How does RAG work?**

P0 · rag

🏷 标签：rag, retrieval, vector-database, llm

1️⃣ 考察意图

面试官想验证你对RAG（检索增强生成）的整条链路理解深度，而非背诵流程。这是典型的“系统设计+工程取舍”题，刁钻点在于：多数人只讲“检索-拼接-生成”三步，但面试官真正想看的是你是否理解索引阶段的chunk策略如何影响检索质量、检索阶段召回率与精度的平衡、以及生成阶段如何避免幻觉。答好了能展示你从demo到生产落地的工程思维，包括对向量数据库、嵌入模型、重排序等组件的选型判断。

2️⃣ 标准答

RAG的核心是用外部知识库弥补LLM的知识截止和幻觉问题，分为索引、检索、生成三阶段，但每个阶段都有工程细节。

索引阶段：从原始文档到可检索向量

Chunking策略：固定大小（如256 tokens） vs 语义分块（如基于段落边界）。固定大小简单但可能切断上下文，语义分块用递归分割（如LangChain的RecursiveCharacterTextSplitter）保留语义完整性。工程取舍：小chunk（128 tokens）提升检索精度但增加向量库条目数，大chunk（512 tokens）召回更全但可能混入噪声。实际落地常用重叠分块（overlap=10-20 tokens）来缓解边界截断问题。
嵌入模型选型：通用场景用text-embedding-ada-002（1536维，性价比高），领域敏感场景用BGE或E5（支持多语言、可微调）。坑：直接用开源模型（如all-MiniLM-L6-v2）在垂直领域（如医疗、法律）召回率可能暴跌30%+，需用领域数据微调或换用领域专用模型（如BioBERT）。
向量数据库：FAISS（内存型，适合小规模）vs Milvus/Pinecone（分布式，支持百万级）。实际落地的坑：FAISS的IVF索引（倒排文件）在数据量>100万时，搜索延迟可能从毫秒级升到秒级，需切换为HNSW（分层可导航小世界图）来保证<100ms响应。

检索阶段：查询到相关文档

查询嵌入：用户query直接嵌入，但短查询（如“RAG原理”）语义稀疏，可用HyDE（假设文档嵌入）：先让LLM生成一个假设答案，再嵌入该答案去检索，提升召回率约10-15%（论文实验数据）。工程取舍：HyDE增加一次LLM调用，延迟多1-2秒，适合离线或对实时性要求不高的场景。
相似度搜索：余弦相似度 vs 点积。坑：如果嵌入模型未归一化，余弦相似度结果可能不稳定，建议在索引阶段对向量做L2归一化，确保搜索一致性。
Top-K选择：K值过大（如20）引入噪声，过小（如3）可能漏掉关键信息。经验值：通用场景K=5-10，结合后续重排序（Reranker）可适当放大到K=20，让Reranker二次过滤。

生成阶段：融合检索结果与LLM

Prompt拼接：典型模板是“基于以下上下文：{chunks}，回答：{query}”。坑：chunks顺序影响LLM注意力，建议按相关性降序排列，且用分隔符（如“---”）明确区分不同文档，避免LLM混淆来源。
幻觉控制：检索结果可能不包含答案，LLM仍会编造。解法：在prompt中加指令“如果上下文无答案，直接说不知道”，或使用自洽性检查（让LLM生成答案后，再检索答案中的关键实体，验证是否在原始chunks中）。
Reranker集成：在检索后、生成前加一个交叉编码器（如Cohere rerank-v3或BGE-reranker），对Top-K结果重新排序。效果：Reranker能提升Top-1准确率约15-20%（工业界报告），但计算成本高（每对query-doc需一次模型推理），适合对质量要求高的场景（如客服问答）。

总结：RAG不是简单三步，而是索引策略、检索精度、生成质量的三角平衡，每个环节都有trade-off，需要根据业务场景（实时性、数据规模、领域特性）做针对性调优。

3️⃣ 答题模板（30 秒电梯版）

“这个问题我从索引、检索、生成三个层面回答。索引阶段，关键是chunk策略和嵌入模型选型，比如用重叠分块避免边界截断，用领域微调模型提升召回。检索阶段，用HyDE改进短查询表示，结合HNSW索引保证搜索速度。生成阶段，通过Reranker二次过滤和自洽性检查控制幻觉。总结一句：RAG是检索与生成的系统工程，每个环节的取舍决定了最终效果。”

4️⃣ 高频追问 & 应对

追问 1：如果检索结果全是噪声，RAG怎么处理？

这是常见坑。解法分三层：1）检索前：用查询改写（如Query2Doc）或查询扩展（如添加同义词）提升召回质量；2）检索后：用Reranker过滤低分结果，或设置相关性阈值（如余弦相似度<0.5的直接丢弃）；3）生成时：在prompt中加“如果上下文无关，回答‘无法从知识库中找到答案’”，并做自洽性检查——让LLM生成答案后，再检索答案中的实体，验证是否在原始chunks中。如果噪声比例高（>50%），建议回退到纯LLM生成，避免RAG反而降低质量。

追问 2：RAG和微调（Fine-tuning）怎么选？能结合吗？

两者互补。RAG适合知识频繁更新（如新闻、产品文档）或需要引用来源的场景；微调适合固定知识（如公司内部规范）或提升模型风格/能力（如代码生成）。结合方式：先用RAG检索外部知识，再在prompt中注入，同时用微调后的LLM（如对领域术语有更好理解）来生成答案。工业界常见做法是“RAG+LoRA微调”：LoRA微调LLM的指令遵循能力，RAG提供最新知识，两者不冲突。

追问 3：如何评估RAG系统的好坏？

分三个维度：1）检索质量：用Recall@k（召回率）和MRR（平均倒数排名），对比不同chunk大小和嵌入模型；2）生成质量：用F1（答案与标准答案的token重叠）或BLEU/Rouge（适合摘要类任务），但更推荐人工评估（如5分制相关性、忠实度）；3）端到端指标：用“答案是否在检索结果中”作为忠实度代理指标。工业界常用RAGAS框架（开源），它提供忠实度、答案相关性、上下文精度等自动化评估指标。

5️⃣ 避坑 · 常见错误答法

❌ 只讲“把文档转成向量，搜一下，拼给LLM”，不提chunk策略、嵌入模型选型、Reranker等细节 → ✅ 必须展示对索引、检索、生成各环节的工程取舍，比如“chunk大小影响召回和延迟，我用重叠分块平衡”。
❌ 说“向量数据库用FAISS就行，简单高效”，忽略数据规模对索引类型的影响 → ✅ 要区分场景：小数据用FAISS+IVF，大数据用Milvus+HNSW，并说明HNSW在百万级数据下延迟<100ms。
❌ 认为RAG能解决所有幻觉问题，不提自洽性检查或回退策略 → ✅ 必须承认RAG的局限性，并给出具体解法，如“加阈值过滤低分结果”或“用自洽性检查验证答案来源”。

6️⃣ 简历呼应

如果你有RAG项目：从“我在XX项目中用RAG做客服问答，发现chunk大小从256调到512后召回率提升8%，但延迟增加20%，最终用重叠分块平衡”切入，展示实战调优经验。
如果你只做过传统NLP：用“传统信息检索（如BM25）与RAG的向量检索对比”类比，强调“BM25依赖词频，RAG用语义嵌入，但两者可结合（混合检索）”，体现迁移能力。
如果你是校招无项目：聚焦“我复现了RAGAS评估框架，在WikiQA数据集上对比了不同嵌入模型（BGE vs ada-002）的Recall@5差异”，展示论文复现和实验设计能力。
《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》（Lewis et al., 2020）——RAG原始论文
《Precise Zero-Shot Dense Retrieval without Relevance Labels》（HyDE论文，Gao et al., 2022）
《RAGAS: Automated Evaluation of Retrieval Augmented Generation》（Shahul et al., 2023）
LangChain官方文档：RecursiveCharacterTextSplitter与RAG最佳实践
Milvus向量数据库官方博客：HNSW vs IVF索引性能对比

—— 本场面试完 ——