RAG全链路面试速查
本文对应 RAG详细解析 模块全部文档的面试考点提炼。RAG是面试中最容易被深挖的方向，准备好"你遇到过什么坑"的回答。
整体架构
Q1：RAG的核心流程？为什么需要它？
核心流程：索引（离线：文档→解析→分片→向量化→入库）+ 检索（在线：用户问题→问题处理→向量检索→筛选）+ 生成（检索结果+问题→Prompt→模型回答）。
为什么需要：解决两个痛点——模型知识有截止日期（不知道最新信息）、模型凭空编造（幻觉）。RAG给模型一个"开卷考试"的机会，基于真实材料回答。
Q2：RAG和微调怎么选？能不能一起用？
数据更新频繁、需要精确引用选RAG。追求特定风格/领域深度能力选微调。两者可以组合——微调学说话方式，RAG提供准确信息。
典型场景：企业知识库（RAG）、客服话术（微调）、法律分析（RAG+微调）、最新政策解读（必须RAG）。
文档处理
Q3：分片策略怎么选？分片大小怎么定？
常见策略：固定大小切分（简单但可能截断语义）→ 按段落/标题切分（需要文档格式规范）→ 语义切分（效果好但开销大）→ 递归切分（先大结构后小结构，LangChain常用方案）。
大小参考：256-1024 Token区间，加50-100 Token重叠防边界丢失。太细信息不完整，太粗话题混杂精度下降。
建议：先按自然结构分，设上限800 Token，超过的再往下拆，用ChunkViz可视化验证。
Q4：PDF解析为什么是第一个大坑？
PDF面向展示不面向数据：文本顺序可能乱（多栏布局）、表格丢结构（就是文字+线条）、扫描件没文字（需OCR）、公式图表无法常规提取。
实际方案：文本类用Apache Tika + 后处理修段落；表格密集型用专门工具（Camelot）；扫描件走OCR（PaddleOCR）；混合型多路处理后合并。
📖 搞懂Tika才能做好RAG文档解析 | 文档预处理读取清洗与标准化
向量化与检索
Q5：Embedding是怎么把文字"变成"向量的？选模型看什么指标？
Embedding模型把文本映射到高维空间，语义相近的文本距离近。常用余弦相似度衡量。
选模型看：维度（表达能力vs成本）、语言支持（中文选BGE/M3E）、上下文长度（超过就截断）、生成速度（数据量大时是瓶颈）。
误区：通用大模型的Embedding不一定比专用小模型好。Embedding质量主要取决于训练方式（对比学习、难负例挖掘）。
Q6：HNSW为什么快？跟暴力搜索和IVF比各自什么场景用？
HNSW建多层图结构：顶层粗定位逐层细化，O(log n)复杂度。类比快递——省际干线（顶层）→ 市内主干道 → 小区内部。
关键参数：M（每个节点连接数，越大越精准也越慢）、efSearch（查询候选数，精度-延迟权衡）。
选型：数据量小于10万 → 暴力搜索就够快；10万-千万 → HNSW（精度高但内存大）；亿级 → IVF（内存友好）。
Q7：混合检索为什么比纯向量检索效果好？怎么融合结果？
向量检索擅长语义匹配但对精确关键词不敏感（编号、名称容易搜错）。BM25关键词检索擅长精确匹配但不懂同义词。两者互补。
融合方法：RRF（Reciprocal Rank Fusion），公式 score = Σ 1/(k + rank_i)。不看分数绝对值只看排名，天然解决两种检索分数不可比的问题。
Q8：重排序为什么不能替代初检？两阶段架构的逻辑？
初检用双塔模型（query和doc独立编码），速度快（毫秒级搜百万条）但精度有限。
Rerank用交叉编码器（query和doc拼一起过模型），精度高但每对都要算，对百万条要几分钟。
所以两阶段：粗排（向量/BM25取Top-50~100）→ 精排（Reranker对这几十条逐一打分取Top-5）。实测加Rerank后Hit@5能从0.72提升到0.85。
Q9：Query Rewrite解决什么问题？HyDE是什么思路？
用户提问经常含糊（指代词、口语化、省略上下文），直接检索命中率低。重写后才能高质量检索。
手段：指代消解（"它"→具体名词）、上下文补全（"还有别的吗"→补全在讨论什么）、子问题拆分（复合问题分开检索）。
HyDE：让LLM先生成一个"假的理想答案"，用这个假答案去做向量检索——因为假答案的语义跟真实文档更接近（都是回答形式），比用问题本身检索效果好。
📖 为什么要问题重写
Q10：查询路由是做什么的？为什么是"必不可少"的？
用户的问题不一定都适合走RAG。路由器先分类：知识检索类（走RAG）、工具调用类（走Agent）、闲聊类（直接回答）、需要澄清的（反问用户）。
如果不做路由，闲聊"今天天气真好啊"也去检索知识库，白白浪费延迟和计算。工具类问题走RAG只能检索到操作说明而不能真的执行操作。
实现方式：用LLM做意图分类（给几个分类示例），或者训练一个小的分类模型做路由。
进阶话题
Q11：GraphRAG跟传统RAG比，什么场景值得用？
需要多跳推理时（A→B→C的关系链），传统RAG检索单个chunk找不到完整答案。GraphRAG先建知识图谱（抽取实体和关系），检索时在图上遍历找关系链，再把对应文本chunk喂给模型。
适合：组织架构问答、跨文档因果推理、实体关系密集的场景。
没必要用：单文档内能答完的简单问答、知识点相互独立的FAQ。
Q12：向量数据库怎么选型？
PGVector（已有PostgreSQL就直接用，500万以内够用）、Milvus（分布式亿级数据）、Qdrant（Rust实现单机性能强）、Chroma（Python优先开发用）。
选型问清：数据量多大、现有技术栈是什么、需不需要元数据过滤、团队技术背景。
常见面试话术："我们选PGVector因为项目已经用PG，数据量十几万条不需要专门的向量库，加个插件就行，检索延迟20ms以内。"
生产落地
Q13：RAG系统怎么做效果评估？
检索侧：Hit@K（Top-K中是否有正确chunk）、MRR（正确chunk排名的倒数平均值）。
生成侧：Faithfulness（回答是否忠于检索材料）、Answer Relevancy（是否真正解答了问题）。
实操：构建Golden Set（100-200标准问答对），每次调参后跑一遍对比。RAGAs框架可以自动化评估。
Q14：RAG的幻觉跟大模型本身的幻觉有什么不同？怎么分别治理？
RAG场景幻觉分两侧：
检索侧：知识库没有答案但模型硬答。治理：设相关性阈值 + Prompt约束"没有就说不知道" + 前置判断检索结果是否包含答案。
生成侧：检索到了但模型脑补了材料里没有的内容。治理：要求引用来源 + 结构化输出（answer和source_chunks字段）+ 事后验证（另一个模型校验一致性）。
Q15：知识库更新策略？增量还是全量？
大部分场景用增量更新（文档粒度增删改）。策略：内容Hash变更检测 → 文档修改就删旧chunk全量重切重Embedding → 新chunk入库前做语义去重。
全量重建的场景：换Embedding模型（新旧向量不在同一空间）、改分片策略、修复严重预处理Bug。
Q16：你在RAG项目中遇到的最大的坑？（开放题准备）
常见坑可以选一个跟自己项目贴近的说：
- 检索召回多但答案质量低：chunk信息密度低/上下文不完整 → 加Reranker+相关性阈值
- 多轮对话检索退化：后续问题省略化 → 每轮做Query Rewrite补全上下文
- 文档格式五花八门：统一预处理流水线按格式路由不同解析器
- 加了新文档旧问题答错了：新旧chunk语义重叠互相"抢位置" → 增量时做去重检测