RAG 工程 · 高频面试题

答：为什么改：用户 query 常是口语、带指代、缺上下文（"那这个呢""它支持吗"），直接检索命中率低。

怎么做：① 多轮场景先做指代消解与上下文补全，把 query 补成自洽问句；② 同义与术语扩展，把口语映射到知识库的标准说法，生成 2-3 个变体并行检索后融合；③ HyDE：先让模型写一段假设答案，用它的向量去检索，适合短 query 与术语缺失，缺点是可能把方向带偏，需与原 query 双路并行；④ 复杂问题拆成子问题分别检索，再合并结果。

什么时候有效：query 短、口语化、指代多、与文档用词不一致时收益明显；query 本就是用户原话或已很具体时收益很小，只增加延迟。

易错：改写后丢掉关键限定（时间、版本、否定），检索方向跑偏；用改写结果替换原 query 而不是多路并行，等于把原来能命中的也丢了。

答：先分层定位，别直接换模型。① 造 10-20 条"问题 + 应命中文档"探针集，只跑检索，看目标片段是否进 top-k。② 压根没入库：查解析失败、切片截断、编码与去重误删。③ 入库但排不进：多为 query 与文档表述差异（口语 vs 术语）→ 加 query 改写 / HyDE、BM25 混合召回、同义词词典。④ 进了但排太后：加 Rerank、调 top-k 与切片粒度。⑤ 仍差再看 Embedding 是否领域不适配（换多语种模型或做对比学习微调），以及元数据过滤是否误伤。

易错：把"召回差"当"模型差"，实际多为解析不全或切片切断了关键条件；只测端到端，无法区分是召回还是生成的问题。

追问：① 探针集怎么造才不偏？② 召回和生成都差时先修哪个？③ 过滤条件写错会表现成什么现象？

答：常见四类：① 定长 + overlap，最快但易切断语义；② 按结构切（段落 / 标题 / 表格行），保语义完整；③ 递归分隔符，先按段落再按句号，到上限才强切；④ 语义或父子块，子块检索、父块喂模型，兼顾精度与上下文。

chunk size 怎么定：以"一个可独立回答的知识点"为单位，中文 300-500 字、英文 200-400 token 起步，overlap 取 10-20%。用评测集做网格搜索，固定 top-k 下看命中率与答案正确率，别凭感觉。结构化文档（合同、手册）优先按标题层级切。

易错：固定字数切会把"条件 + 结论"切到两块，命中条件却答不出结论；overlap 过大会重复召回、挤占上下文预算。

答：解决的问题：小块检索准（向量不被无关内容稀释），但小块缺上下文，模型拿到半句就编。父子块把"检索单位"和"投喂单位"拆开。

实现：① 入库时同时写子块向量与父块正文，子块元数据挂 parent_id；② 命中子块后按 parent_id 取回父块，或取相邻窗口 ±N 句，再送模型；③ 层级可多层（句 → 段 → 节），按问题类型选粒度；④ 同一父块命中多个子块时去重合并，只留一份父块并提升其排序；⑤ 父块过长时截断或摘要，避免挤占上下文。

易错：子块与父块都建向量，索引膨胀且父块互相重复；父块过大后多个问题共用同一段上下文，精度回落；更新只重算子块，父块仍是旧版内容。

答：作用：向量检索与 BM25 都是"分别编码再比相似度"，为速度牺牲精度，只能粗筛；Rerank 用 cross-encoder 把 query 与片段拼在一起打分，精度高但慢，所以只对 top-20~50 精排到 5-8 条。

必须加：① 语料同质化高（制度、条款、代码注释），向量分不开；② top-k 要压得很小以控延迟与成本；③ 准确性要求高（客服、合规、医疗）；④ 混合检索两路分数量纲不同，需要统一重排。

可以不加：语料少、问题简单的演示链路。

易错：Rerank 只能重排已召回候选，没进 top-50 的救不回来；把它当提升召回的手段是错位，应先保召回再精排。

答：选型四问：语言与领域是否匹配、最大输入长度是否覆盖切片、是否支持稀疏或多向量、能否本地部署。中文检索常用 bge-m3 / gte 系，多语种看 multilingual-e5；闭源 API 省运维，但按 token 计费且有数据合规问题。

维度与成本：维度越高表达力越强，存储与检索开销也线性涨——1024 维比 512 维约多一倍内存与算力；可用 Matryoshka 截断或 PQ/SQ 量化压缩。真正的成本大头是全量重建：换模型就得整库重算 embedding 并重建索引，所以要一次选稳。

怎么验：在自己的 50-100 条探针集上比 Recall@10 与端到端正确率，别只看公开榜单排名。

易错：只看榜单不看领域适配；换了模型却没重算历史库，两代向量混在同一索引，相似度不可比。

答：三条不变量：块能唯一映射到源文档版本、删除能传播、重建能重放。① 主键用 doc_id + 版本号 + 块序号，同一文档更新时按前缀删旧块再写新块，不要只 upsert。② 切读路径的顺序：先写新版本、再切开关、最后删旧版，避免出现空窗。③ 删除在向量库里多为标记删除，配墓碑表加定期 compaction，防止幽灵块被召回。④ 定时对账：源文档内容哈希与索引里存的哈希比对，差异走补偿任务，只比条数会漏掉改过内容的块。⑤ 向量库与元数据库双写用同一批次 ID，失败可重放，别硬上分布式事务。

易错：只写不删导致同一文档多版并存；对账只比条数不比哈希；重建时直接覆盖线上索引，出错没有退路。

答：目标：用户能点回原文，而不只是看到编号。① 每个块带 doc_id、页码 / 章节与原文锚点（起始偏移或单元格坐标）；② 生成时要求逐句输出引用编号，答案句与片段做 span 对齐，前端点击高亮原文；③ 引用粒度到句不到文档，否则等于没给依据；④ 后置校验：答案句与所引片段做蕴含判断，不支撑就标"未核实"。

引用错怎么排查：a) 编号错位——片段重排后编号没跟着更新，查拼上下文时的映射表；b) 引了不相关片段——Rerank 排序与实际使用顺序不一致；c) 片段本身解析错（表格错列、双栏串行），回看原始文件；d) 模型凭记忆作答却硬挂引用，用无引用即拒答加后置校验卡住。

易错：引用只到文档级，用户无法验证；把"有引用"当"引用正确"，不做蕴含校验。

答：判断标准是"要不要算"。① 需要聚合、排序、比较、按条件筛选（"上季度超过 30 万的订单有几笔"）→ Text-to-SQL，交给数据库精确计算；② 需要解释口径、条款、原因（"这条规则为什么这么定"）→ RAG 检索文本；③ 表小且问题以查值为主 → 表格转文本块走 RAG，工程最省；④ 混合：SQL 取数、RAG 取口径，答案里同时给数字与出处。

Text-to-SQL 的坑：表结构要给模型看（列名、类型、样例值、注释），否则字段猜错；必须做 SQL 语法校验、只读账号与行数上限；多表 JOIN 与同义词映射（"营收"对应哪个字段）要维护字典；结果回填自然语言并附查询语句供核对。

易错：用 RAG 硬答数值问题，检索到的是示例表而非真实数据；不给样例值，模型把枚举字段猜错。

答：为什么要路由：多库时全库检索会互相污染，延迟与成本也翻倍。① 分索引：按租户、业务域、文档类型拆，query 先判定目标索引再检索。② 实现：规则优先（关键词、来源入口、用户所在页面）覆盖大部分明确场景；剩余用轻量分类器或小模型做多标签意图分类，允许并行打到 2-3 个库；也可用库描述向量与 query 比相似度选库。③ 兜底：置信度低就走全库并按库加权融合，而不是硬选一个。④ 可观测：记录 query、命中库与是否正确，用 bad case 补规则。

易错：用 LLM 串行逐库判断，延迟叠加且不稳定；路由错了没有全库兜底，表现为"这个库的问题永远答不上"。

追问：① 库描述怎么维护才不会和内容漂移？② 路由准确率怎么离线评？

答：拒答要分档，不是一句"不知道"。① 硬拒：最高分低于阈值、或没有任何片段能支撑答案 → 明说知识库无相关内容，给相近问题或转人工入口；② 软拒：有片段但证据不全（只覆盖部分条件）→ 输出已知部分并标注"未覆盖 X"，请用户补充；③ 澄清：缺关键槽位（版本、地区、时间）→ 反问而不是猜。

阈值怎么定：在评测集上扫一遍，取"无答案集"与"有答案集"的分数分布，选使误拒与误答之和最小的点；相对阈值（同 query 内 top1 与均值之差）比绝对阈值稳；不同库、不同 Rerank 模型要分别标定；上线后按周用 bad case 复核。

易错：随手拍一个 0.7 当阈值；只看相似度不看证据是否足够；拒答率不纳入监控，阈值调松后错误率悄悄上升。

答：版本是复合的：切片策略、embedding 模型、索引、Rerank、prompt 都可能单独变，所以要把"检索配置 + 生成配置"打包成一个版本号。

① 灰度：按租户或用户哈希分流 1% → 5% → 20% → 全量；先跑影子模式（新链路只记录不返回），对比新旧召回差异率。② 双索引并存：新版本写影子索引，读路径按开关切换，回滚只切开关、不重建。③ 门禁：每档看检索命中率、拒答率、采纳率、P95 延迟，任一越线自动回滚。④ 回滚要分钟级：配置集中管理，版本号写进缓存 key，回滚后旧缓存仍可用。⑤ 不可逆操作（换 embedding 模型）先保留旧向量，确认稳定后再删。

易错：只灰度 prompt 不灰度索引，两版混用导致指标不可比；回滚时忘了清或没隔离缓存，用户仍看到新版本的答案。

答：图谱补的是多跳关系与结构化约束，向量补的是语义相似。① 抽取：用 LLM 从文档抽实体-关系-属性，落三元组并保留来源片段。② 检索：query 先做实体链接，从实体出发 1-2 跳扩展，把子图转成"实体 A —关系→ 实体 B"的文本作为上下文；也可只把图谱用于过滤或扩召回，先定位实体再限定向量检索范围。③ 融合：子图文本与向量片段一起给模型，答案标注来源。

适合：强关系领域（供应链、金融风控、设备拓扑、法规条款）。不适合：纯语义问答、实体稀疏的语料。

易错：抽取阶段幻觉造边，图谱错则全链路错，必须保留原文出处可回溯；跳数放大导致上下文爆炸，通常限 2 跳内并限制邻居数。

答：目标是在 token 预算内保住"能回答问题的证据"。① 抽取式：按 query 相关性给句子打分，只留高分句，便宜且可引用。② 摘要式：用小模型把每块压成要点，有损，适合长文。③ 去冗余：块间相似度去重，MMR 兼顾相关与多样。④ 结构压缩：表格转键值、代码只留签名。⑤ 位置优化：按相关性重排，最相关放首尾。⑥ 递归：先粗压再精读，多轮检索而非一次塞满。

顺序：先 Rerank 砍数量，再压缩砍长度；反过来容易把证据压没。

易错：压掉了否定与限定条件（"除…之外""不适用于"），答案方向反转；压缩模型自己加料，引入原文没有的信息。

答：① Embedding：离线批量、只有变更文档重算、缓存重复块；用较小维度加标量量化存储。② 存储：向量走 PQ/SQ 量化，冷数据下沉对象存储，元数据与向量分离，热库只留活跃租户。③ 检索：先元数据或关键词粗筛再向量检索，控制 top-k，必要时用 IVF 降算力。④ 生成是大头：Rerank + 压缩砍上下文、按难度路由（简单问题走小模型或 FAQ 直接返回）、结果与语义缓存、合并请求、限制输出长度。⑤ 运营：按租户统计命中率，清理从未命中的块，别为无效索引付费。

易错：只盯向量库账单，实际 token 成本占大头；为省钱把 top-k 砍到 3，准确率崩了导致重试与人工成本更高。

追问：① 怎么定位成本花在哪个环节？② 降级到什么程度会伤体验？

答：链路：解析出图 / 表 / 页 → 用视觉模型或 OCR 生成描述与结构化内容 → 与文本块同库（统一向量空间）或分库 → 检索按模态路由 → 生成时把原图加描述一起交给多模态模型。

做法：页面截图与文本双通道，截图保版式、文本保可检索；图表必须生成"标题 + 结论"描述，否则搜不到图里的数值；统一 embedding 或做跨模态对齐；引用要回指原图页码与区域。

坑：视觉模型读表易错位、数字幻觉；整页截图分块会切断图表；跨模态相似度普遍偏低，需靠文本描述兜底；原图存储与带宽成本高。

易错：只索引图像描述不索引原图，答案无法引用；把 PDF 整页截图当一块，检索精度骤降。

答：本质是"生成未被约束 + 校验缺失"。① 看引用：答案句能否映射到片段，无引用或对不上 → prompt 没强制逐句挂来源，改成"先摘原文再答"并要求引用编号。② 看检索：召回片段本就不含答案 → 是检索问题，别在生成上调。③ 看片段质量：块被切断、表格错位，模型只能靠常识补全。④ 看温度与长度：高温加要求长篇会放大编造。⑤ 加后置校验：答案与片段做蕴含判断，不通过则降级为"仅列原文"。⑥ 明确拒答路径，允许说不知道。

易错：只把 prompt 改成"不要编造"，模型照样编；把"有引用"当"有依据"，引用也可能挂错片段。

追问：① 蕴含校验用什么模型、阈值怎么定？② 拒答率高了怎么权衡？

答：先拆再压。P95 2s 的粗账：网关与鉴权 50ms、query 改写 100-200ms、向量检索 50-100ms、BM25 并行 50ms、融合去重 20ms、Rerank 200-400ms、prompt 组装 20ms、首 token 400-800ms、流式吐完 1-1.5s。

手段：能并行的并行（向量与关键词、多路检索）；Rerank 只排 top-20 且用小模型或 ONNX 加速；先流式吐字再补引用；语义缓存命中直接返回（<100ms）；长文档预切预索引，避免在线解析；超时降级为先返回检索摘要。

注意：先和需求方对齐"2s 指首字还是整体"，整体 2s 在生成侧几乎不可能，除非严格限制输出长度。

易错：拿 P50 当 P95 报；只优化检索（占比最小），真正的大头是生成与 Rerank。

答：四层：① 结果缓存：query 归一化后按 key 缓存完整答案，key 必须带租户、权限与知识库版本。② 语义缓存：把 query 向量化，在缓存库做相似检索，相似度超阈值（如 0.9+）直接复用答案；要防"看似相同实则不同"（数字、否定、时间条件）。③ 检索缓存：query → 召回块 ID 列表，文档更新时按 doc_id 失效。④ 前缀 / KV 缓存：固定系统 prompt 与公共前缀复用，省首 token 延迟。

失效：版本号进 key；语义缓存对文档 ID 建反向索引，文档一变批量清；TTL 兜底。

易错：阈值调太低会把"退款多久到账"与"换货多久到账"当同一问题；缓存不做权限隔离，会跨租户泄漏答案。

答：结构：角色与边界 → 任务 → 证据（编号片段，带来源与页码）→ 输出格式 → 约束（只依据证据、不足则拒答、逐句标注引用编号）。

要点：① 证据放前面、问题放后面，减少中间位置衰减；② 片段编号并去重，按相关性排序；③ 约束写成可检查的规则（"每个结论后跟 [1]"），不写"尽量准确"；④ 输出用固定 schema，便于解析与校验；⑤ few-shot 给 1-2 个"证据不足 → 拒答"的示例，比只给正面例子管用；⑥ 系统 prompt 保持稳定以命中前缀缓存。

易错：把 20 个片段全塞进去又不编号，模型无法引用也分不清主次；负面指令堆太多会挤压有效信息，反而降低遵循率。

答：常用：Recall@k（应命中文档是否在 top-k，RAG 最关键）、Precision@k、MRR（第一个相关结果排名的倒数）、nDCG（考虑分级相关性与位置）、Hit Rate。生成侧配套 context precision / context recall，衡量给进去的片段是否有用、是否够用。

怎么用：先保 Recall@k——漏了就无解，再压 k 控精度；按问题类型分桶看（单跳、多跳、精确编号），整体均值会掩盖长尾；线上用点击与采纳率做代理指标。

易错：只报一个平均值不看分桶；优先调 Precision 把召回压垮——RAG 里漏召回的代价远高于多召回。

答：① 来源：真实用户 query 日志优先，业务 FAQ 与专家出题补齐，三者混合。② 规模：50-200 条起步，高频占六成、长尾与边界占四成，按类型分桶（单跳、多跳、否定、时效、无答案）。③ 标注：每条给"问题 / 标准答案要点 / 应命中文档 ID 与页码 / 是否应拒答"，交叉标注并抽检一致率。④ 必须含无答案集，用来测拒答率，防止只会硬答。⑤ 维护：线上 bad case 定期回流，版本化并冻结，改动前后跑同一集。

易错：只用 LLM 合成问题，问法单一、与真实口语分布不符，高分不可信；只给参考答案不给应命中文档，就无法分别评检索与生成。

答：是什么：把检索从一次性步骤变成可被模型编排的动作——判断要不要检索、检索什么、是否多轮改写或多跳、是否调用其他工具（SQL、API、图谱），并用结果充分性判断决定继续还是作答。

典型形态：query 规划 → 并行子问题检索 → 反思"够不够" → 补检索或换工具 → 汇总生成带引用。

值得上：多跳与比较类问题、跨数据源（文档 + 数据库）、问题模糊需澄清、准确率优先且能容忍延迟。不值得：单跳事实问答、语料单一、延迟 2s 内——一次检索加 Rerank 就够，Agent 化只增加不确定性与成本。

易错：把 Agentic 当"更高级所以更好"，它牺牲延迟与可复现性；没有最大轮数与预算上限，会陷入反复检索的死循环。

答：原则：权限过滤必须发生在检索之前。① 每个块入库时写租户、部门、密级与可访问 ACL，作为标量元数据。② 查询时把当前身份编译成过滤表达式（tenant = X 且 ACL 含 role Y），随向量检索一起下发，让向量库做 pre-filter；取回后再过滤会让 top-k 被无关块占满，甚至越权。③ 权限变更要快生效：ACL 单独存、检索时联查，或按权限分组做分区索引。④ 缓存 key 带租户与权限版本，语义缓存同样隔离。⑤ 审计记录谁在何种权限下命中了哪些块。

易错：先检索后过滤，命中被无效块吃掉，答案变差且可能越权；把租户过滤写进 prompt 靠模型自觉，等于没有权限。

追问：① 过滤比很高时（如只看本部门）向量库召回怎么保？② 用户权限实时变更怎么不重建索引？

答：先看缺什么：缺知识（时效、私域事实、需引用）→ RAG；缺行为（语气、格式、固定流程、领域术语习惯）→ 微调；两者都缺就都做。

RAG 优势：知识可增量更新、可溯源、权限可控、成本低、不易灾难性遗忘。微调优势：把风格与格式内化，省 prompt token、降低对上下文的依赖、提升特定任务稳定性；代价是更新要重训、易过拟合、难引用。

顺序：先用 RAG + prompt 打到瓶颈，再用少量高质量样本做 SFT / LoRA 补格式与拒答行为；数据不足时优先调检索而不是微调。

易错：用微调"灌知识"，事实很快过时且无法引用；用 RAG 解"输出格式不听话"，prompt 与后处理才是对的层级。