本附录整理了 RAG 相关岗位（如大模型应用开发、AI 工程师、知识库架构师）面试中常见的问题及解答要点。内容偏重实战理解，而非纯理论背诵。
C.1 基础概念与理解
Q1：用自己的话解释什么是 RAG？它解决什么问题？
参考答案：
RAG 全称检索增强生成，是一种将外部知识库检索与语言模型生成相结合的技术框架。它让模型在回答问题时，先从一个事先建好的知识库（如文档集合）中检索出相关内容，再把这些内容作为参考，生成最终答案。
它主要解决大模型三个痛点：
- 知识过时：训练数据有截止时间，无法知晓最新信息；
- 幻觉：对不知道的事会编造细节；
- 不可溯源：说不出答案的依据是什么。
通过外挂知识库，RAG 让模型可以“开卷考试”，回答更准确、更新、更可信。
Q2：RAG 和模型微调有什么区别？各自适合什么场景？
参考答案：
- RAG：不改模型参数，把知识放在外部数据库里，通过检索动态提供给模型。适合需要频繁更新知识、必须溯源、知识量大的场景（如企业文档问答、政策查询）。
- 微调：用领域数据重新训练模型，把知识固化到参数里。适合需要模型掌握特定风格、推理模式、术语习惯的场景（如医疗诊断辅助、代码生成特定框架），但知识更新需重新训练，成本高。
简单说：RAG 管“是什么”（事实），微调管“怎么说”（风格/推理）。实际项目中可以结合使用。
Q3：RAG 的核心组件有哪些？
参考答案：
- 索引模块：负责将原始文档切分、向量化，存入向量数据库。
- 检索模块：接收用户查询，进行向量搜索，从知识库中召回相关片段。
- 生成模块：将检索结果与用户问题一起构建提示词（prompt），交给大模型生成回答。
- 知识库与运维：文档管理、更新、版本控制等外围支持。
C.2 索引与切分策略
Q4：文档切分（chunking）时需要注意什么？切分大小如何选择？
参考答案：
切分对最终效果影响很大，核心要平衡两个目标：
- 片段不能太大，否则检索精度下降，且容易超出 LLM 上下文窗口；
- 片段也不能太小，否则会丢失必要上下文，导致模型理解困难。
常见做法：
- 通用场景：
256–512 token比较合适； - 高密度文档（如法律条款）：可稍短，200–400 token；
- 叙述性文档：512–1024 token；
- 一定要重叠切分（overlap 10–20%），避免重要信息在片段边界被截断。
此外，保留文档元数据（标题、章节、页码）对溯源十分关键。
Q5：如何处理文档中含有表格、图表等内容？
参考答案：
- 表格：最好提取为结构化文本（如 Markdown 表格），或使用专门的表格理解模型（如 Table Transformer）生成描述性摘要，再入库。
- 图表/图片：可用多模态嵌入模型（如 CLIP）直接对图片向量化，或先用 OCR/图文识别提取文字后入库。
- 混合文档：采用分段时标记类型，在检索时根据内容类型选择不同策略。
Q6：什么是父子文档（Parent-Child Document）切分策略？为什么有用？
参考答案：
这是一种兼顾检索精度和上下文完整性的切分方式：
- 子片段：切成较小的 chunk（如 200 token），用于向量检索，这样能更精准匹配查询；
- 父片段：保留更大块的原始上下文（如整个小节），在检索命中子片段后，把父片段整体提供给 LLM 作为参考。
优点：小片段检索更准，大片段保留完整语境，模型就不容易“断章取义”。
C.3 检索与召回
Q7：向量检索的相似度算法有哪些？各有什么特点？
参考答案：
- 余弦相似度：最常用，衡量向量夹角，对文本长度不敏感，适合文本语义比较。
- 欧氏距离：适合向量空间位置相近的情况，对长度敏感，较少直接用。
- 点积：计算速度快，适合归一化向量。
一般向量数据库（如 Milvus、Pinecone）默认支持余弦相似度。选型时注意与嵌入模型的适配。
Q8：如果检索结果不相关或不够，怎么办？可以怎么优化？
参考答案：
- 调整嵌入模型：选择与领域匹配更强的模型，或进行领域微调。
- 改进切分：优化 chunk 大小和重叠，确保关键信息完整。
- 混合检索：加入关键词搜索（BM25）作为补充，组合向量与关键词结果。
- 重排序：引入 reranker（如 Cohere Rerank 或交叉编码器）对初步召回结果重新排序。
- 查询重写：用一个轻量 LLM 将用户问题改写得更适合检索（如补充简称、同义词），然后再检索。
Q9：什么是 RAG 中的“多跳检索”（Multi-hop Retrieval）？
参考答案：
有些问题无法通过单次检索直接回答，需要进行多轮推理。例如“去年 CEO 批准的上一季度研发预算是多少？”需要先找到“CEO 批准”的记录，再追踪到具体预算数字。
多跳检索通常通过迭代方式实现：第一轮检索获取部分信息，第二轮的查询会与第一轮结果拼接后再去检索，直到收集齐所有必要信息，再一起生成答案。
C.4 生成与质量控制
Q10：RAG 提示词（prompt）一般怎么设计？
参考答案：
典型模板包含以下要素：
- 角色设定：如“你是一个基于公司内部知识库回答问题的助手……”
- 知识上下文：将检索到的文档片段填入，通常用分隔符标记，如
【参考资料】……【/参考资料】。 - 回答要求：明确指令，如“请只根据以上资料回答，无法回答时说‘未找到相关信息’”。
- 引用格式：要求回答中注明出处，例如“（来源：《员工手册》第3条）”。
- 对话历史（可选）：在多轮问答中，需传入历史问答对，使回答连贯。
示例：
你是一个专业的政策问答助手。请仅根据以下参考资料回答用户问题。如果资料中没有答案，请明确说明。
【参考资料】
{检索到的文档片段}
【问题】
{用户问题}
【回答要求】
回答准确，并在每个关键信息后标注出处。Q11：如何评估 RAG 系统的回答质量？有哪些常用指标？
参考答案：
评估至少从两个维度：
- 检索质量：使用 Mean Reciprocal Rank (MRR)、NDCG@k 衡量检索结果排序质量；或人工标注相关度。
- 生成质量：
- 忠实度（Faithfulness）：回答是否严格基于检索到的文档，是否出现幻觉。可以用 RAGAS 框架自动评估，或人工比对。
- 答案相关性（Answer Relevance）：回答是否切题。
- 上下文相关性（Context Relevance）：检索到的内容是否冗余无关。
实际落地时，建议建立一套业务维度的评测集，定期用人工抽检或自动指标监测系统表现。
Q12：遇到 RAG 生成的答案仍然出现幻觉，怎么排查？
参考答案：
逐级排查：
- 检索是否漏召：查看实际检索到的片段，是否包含了能回答问题的信息。如果未召到，问题在索引/检索环节。
- 模型是否遵循指令：即使召回了正确信息，模型也可能“不听话”。检查 prompt 是否足够强调“只使用参考资料”，或尝试更强的指令。
- 上下文长度超限：当检索结果太多，超出模型上下文窗口时，部分资料会被截断。需控制 top‑k 数量或压缩上下文。
- 资料本身冲突或过时：知识库中有矛盾内容，模型可能选了错误的一条。需检查入库文档质量。
C.5 工程化与落地
Q13：知识库更新时，如何保证已有索引的一致性？
参考答案：
- 维护文档与 chunk 的映射关系（如用数据库存储文档 ID 与 chunk 列表）；
- 更新文档时，先标记并删除旧的 chunk 及对应向量，再重新切分、向量化、插入；
- 使用向量数据库的事务或分批更新能力，避免查询到正在更新的状态；
- 对大数量更新，采用异步流水线，并在更新完成后做一次全量校验。
Q14：RAG 系统如何控制成本和延时？
参考答案：
- 嵌入模型：能用轻量模型（如 BGE-small）就不用大模型，embedding 计算可批量并行。
- 向量数据库：选择合适的索引类型（如 IVF、HNSW），根据数据量调参，平衡精度与速度。
- 检索：合理设定 top‑k 值（通常 3–10），避免传入过多上下文加重 LLM 负担。
- 生成：必要时使用更小、更快的推理模型，或套用缓存机制：对相同问题直接返回缓存结果。
- 异步与流水线：检索和生成可部分异步，降低用户感知延迟。
Q15：如果要为一个全新领域搭建 RAG 系统，你会怎么起步？
参考答案：
- 明确业务需求和用户问题类型，定义“好答案”的标准。
- 收集并清理领域文档，确保内容完整、准确。
- 设计索引策略：切分方式、元数据、嵌入模型选择。
- 搭建检索与生成原型，使用少量样例快速验证效果。
- 建立评测：固化一批典型问题作为回归测试集。
- 根据评测结果持续优化：调整切分、检索、提示词，必要时微调嵌入或引入 reranker。
- 设计知识更新与运维流程，确保长期可用。
以上流程不需要一步到位，可小范围试点再滚动扩展。
通过这些问题和考点的梳理，读者可以快速建立对 RAG 系统从原理到落地的整体认知，也便于在面试或方案评审中有条理地展现自己的技术思考。