86 lines
8.1 KiB
Markdown
86 lines
8.1 KiB
Markdown
---
|
||
id: ai.rag.interview
|
||
title: RAG 面试题
|
||
type: interview
|
||
domain: ai
|
||
stack: [rag]
|
||
tags: [RAG, 检索, 评测, 面试]
|
||
level: intermediate
|
||
related: [ai.rag.pipeline-chunking, ai.rag.hybrid-rerank, ai.rag.generation-eval]
|
||
week: [5, 6, 16]
|
||
---
|
||
|
||
# RAG 面试题
|
||
|
||
## 基础
|
||
|
||
### 【基础】什么是 RAG？和微调有什么区别？
|
||
|
||
**参考答案**：RAG 先从外部知识库检索相关资料，再把资料和问题一起交给大模型生成答案。和微调相比：知识更新只需要更新索引，成本低；答案可以附引用、可追溯；能做权限控制。微调改变的是模型的行为和风格（格式、领域语气、特定任务能力），不适合频繁变化的事实性知识。很多场景两者结合，但先做 RAG。
|
||
|
||
**追问**：什么情况下需要 RAG 和微调结合？→ 既要最新的企业知识，又要固定的输出格式或领域表达时：RAG 提供知识，微调（或更常见的：提示词 + 少量示例）约束格式。先用 RAG 和提示词解决，确实不够再考虑微调。
|
||
|
||
### 【基础】RAG 的完整流程是怎样的？
|
||
|
||
**参考答案**：离线：加载文档 → 解析清洗 → 切分 → 嵌入 → 写入向量库（带元数据），关键词检索还要写入倒排索引。在线：问题（必要时改写）→ 检索（向量 / 关键词 / 混合）→ 权限和元数据过滤 → 重排 → 拼接提示词 → 大模型生成 → 返回答案和引用；全程记录日志用于评测和分析。
|
||
|
||
**追问**：文档解析这一步常见的问题有哪些？→ PDF 表格被拆散、多栏排版顺序错乱、扫描件需要 OCR、页眉页脚和水印混入正文。表格转成 Markdown 表格整体入库，解析结果要抽样人工检查。
|
||
|
||
### 【基础】chunk 大小怎么定？切分有哪些策略？
|
||
|
||
**参考答案**：没有固定答案，要用评测集对比。太小上下文不完整，太大主题混杂、浪费 token。策略：固定长度加重叠、按文档结构（标题 / 段落）切分、按句子 / 语义切分、父子块（小块检索、返回大块）。结构化文档优先按结构切，并把标题路径加到块内容里。
|
||
|
||
**追问**：父子块（小块检索、返回大块）解决什么问题？→ 小块语义集中、检索准，但上下文不完整；命中小块后把它所在的大块（父块）交给模型，兼顾检索精度和上下文完整。
|
||
|
||
### 【基础】为什么要混合检索？
|
||
|
||
**参考答案**：向量检索擅长语义相似，但对错误码、型号、人名等精确词效果差；BM25 擅长精确匹配，但不理解同义表达。两者互补，用 RRF 等方法融合后效果通常更稳定。中文关键词检索要先分词。
|
||
|
||
**追问**：中文 BM25 要注意什么？Elasticsearch 怎么做混合检索？→ 中文要先分词（jieba、ES 的 IK 等分词插件），否则按单字匹配效果差；ES 可以同时做 BM25 和 kNN 向量检索，再用 RRF 等方式融合，具体语法随版本变化，以官方文档为准。
|
||
|
||
## 进阶
|
||
|
||
### 【进阶】怎么减少 RAG 的幻觉？
|
||
|
||
**参考答案**：检索层面：提高召回质量（切分、混合检索、重排），召回不到时拒答；提示词层面：要求只依据资料回答、资料中没有就说没有、每个结论标注引用编号；生成后：校验引用编号是否存在、关键数字是否出现在被引用的资料中；评测：用忠实度指标和人工抽查持续监控。
|
||
|
||
**追问**：模型给出的引用编号是对的，内容却不在资料里，怎么发现？→ 生成后做校验：引用编号必须存在；抽取答案中的关键数字 / 实体，检查是否出现在被引用的资料里；不通过时降级为“只返回相关资料”或提示人工核对，并记录为 Bad Case。
|
||
|
||
### 【进阶】怎么评测一个 RAG 系统？
|
||
|
||
**参考答案**：分层评测。检索层：人工标注问题和应命中的文档，计算 Recall@k、MRR；生成层：忠实度（答案是否有资料支撑）、答案正确性和相关性，用人工标注 + LLM 评分并互相校准；端到端：拒答率、无权限问题的处理；线上：用户反馈、转人工率、差评样本分析。评测集要覆盖精确词、多轮、无答案、无权限等类型，改动前后都跑。
|
||
|
||
**追问**：评测集从哪里来？→ 初期人工根据文档编写（每类问题若干条），上线后从真实日志和差评中补充；可以用大模型辅助生成候选问题，但必须人工审核；评测集要版本化管理。
|
||
|
||
### 【进阶】重排（rerank）是什么？为什么不直接用重排模型检索全部文档？
|
||
|
||
**参考答案**：重排模型（通常是交叉编码器）把问题和候选文本拼在一起计算相关度，比向量的双塔模型更准，但每一对都要单独计算，速度慢、成本高。所以先用向量 / BM25 快速召回几十个候选，再用重排模型精排取前几个。
|
||
|
||
**追问**：重排之后取几条给模型？→ 用评测集测试：太少可能漏掉答案，太多增加成本和干扰，常见 3~8 条；同时设置重排分数阈值，低于阈值的不放进提示词。
|
||
|
||
### 【进阶】什么是 Agentic RAG？和普通 RAG 有什么区别？
|
||
|
||
**参考答案**：普通 RAG 是固定流程：检索一次、生成一次。Agentic RAG 让模型作为 Agent 决定是否检索、检索什么、检索结果不够时改写问题再检索、从多个知识源（文档、数据库、搜索）中选择，并在生成后自我检查。适合复杂多跳问题，代价是延迟和成本更高、流程更难控制，需要设置最大步数和评测。详见 [Agent 设计专题](../agent-design/index.md)。
|
||
|
||
**追问**：Agentic RAG 怎么防止无限检索？→ 设置最大步数 / 最大检索次数和总超时；每一步记录状态，达到上限后基于已有资料回答或拒答；用评测集对比它和普通 RAG 的效果、延迟和成本，确认值得。
|
||
|
||
## 场景题
|
||
|
||
### 【场景题】知识库里有不同部门的保密文档，怎么保证员工只能问到有权限的内容？
|
||
|
||
**参考答案**：每个块在入库时带权限元数据（可见部门 / 角色）；问答时先鉴权得到用户的部门和角色，在检索阶段作为过滤条件（先过滤再取 top-k），无权限内容不进入提示词；缓存要区分权限；日志脱敏；评测集包含越权问题做回归。不能只靠提示词约束模型。详见[带权限的知识库场景](scenarios/permission-aware-kb.md)。
|
||
|
||
**追问**：用户的部门变了，之前的缓存答案怎么办？→ 缓存 key 包含权限维度（部门 / 角色的哈希），或者敏感知识库不缓存答案；权限变更事件触发相关缓存失效。
|
||
|
||
### 【场景题】用户反馈“答案不对”，你怎么排查？
|
||
|
||
**参考答案**：用请求 ID 找到这次的完整链路记录：改写后的问题、检索到的块和分数、重排结果、最终提示词、模型输出。判断问题在哪一层：正确资料没被召回（切分、嵌入、检索参数问题）→ 召回了但排序靠后（重排）→ 资料在提示词里但模型答错（提示词、模型能力）→ 资料本身过期或错误（数据问题）。把它加入评测集（Bad Case），修复后回归。
|
||
|
||
**追问**：怎么把这类问题变成可持续改进的流程？→ 建立 Bad Case 记录：每个问题标注失败环节（解析 / 切分 / 检索 / 排序 / 生成 / 数据），定期汇总找出占比最高的环节优先优化，修复后加入评测集防止回归。
|
||
|
||
### 【场景题】文档每天都在更新，怎么保持索引最新？
|
||
|
||
**参考答案**：监听文档源的变更（事件、定时比较更新时间或内容哈希），只处理变化的文档；每个块带 `doc_id` 和版本号，更新时先删除该文档的旧块再写入新块（或写入新版本后原子切换）；删除的文档同步删除；入库是异步任务，失败重试、幂等；监控入库延迟和失败数。跨栈的数据同步场景见 [scenarios/](../../../scenarios/index.md)。
|
||
|
||
**追问**：嵌入成本很高，大量文档频繁小改动怎么办？→ 按块计算内容哈希，只有内容变化的块才重新嵌入；元数据（如权限）变化只更新元数据，不重新嵌入。
|