Skip to content

RAG 高频面试题

如何评估 RAG 系统的效果?检索和生成分别看哪些指标?

这道题常用来区分“会背 RAG 名词”和“能把 如何评估 RAG 系统的效果?检索和生成分别看哪些指标 落到工程链路里”的候选人。

适合阶段:RAG 项目面 / Agent 工程面核心能力:概念边界 · 工程取舍 · 生产落地

面试官角度分析,想考什么

  • 真实问法:如何评估 RAG 系统的效果?检索和生成分别看哪些指标?
    是否能分层评估,而不是只让人主观看答案;是否理解 retrieval、context、generation、system 各自指标。
  • 能不能讲清边界
    面试官想确认你是否知道这个能力解决什么问题、不解决什么问题,以及它和相邻方案的差异。
  • 有没有工程调优意识
    合格答案要能落到文档、索引、检索、重排、Prompt、评估、成本和权限等实际环节。
  • 能不能处理失败情况
    生产 RAG 不只追求答对,还要能发现召回差、证据不足、引用错误、旧版本命中和越权风险。

可直接抄走的 30 秒参考答案

text
RAG 评估要拆层看。检索层看 `recall@k`、`precision@k`、`MRR`、`NDCG`,判断正确证据有没有捞到、排得靠不靠前;生成层看 faithfulness、answer correctness、relevance、引用准确率和拒答准确率;系统层还要看 P95 延迟、成本、索引新鲜度、权限误召回和用户反馈。

面试回答详解,知其所以然

这道题不要只背术语。更稳的回答方式是:先说明它在 RAG 链路中的职责,再讲实现机制,最后补上参数取舍、评估方式和生产风险。

1. 先给出核心定义

RAG 评估要拆层看。检索层看 recall@kprecision@kMRRNDCG,判断正确证据有没有捞到、排得靠不靠前;生成层看 faithfulness、answer correctness、relevance、引用准确率和拒答准确率;系统层还要看 P95 延迟、成本、索引新鲜度、权限误召回和用户反馈。

text
用户问题 -> 检索策略 -> 证据上下文 -> 模型生成 -> 引用与评估

2. 放到完整 RAG 链路里理解

  • 先构建 gold set:真实 query、标准答案、应命中文档、不可回答样例、权限样例和高风险样例。
  • 检索指标关注证据:正确 chunk 是否在 top-K,位置是否靠前,上下文是否包含足够答案依据。
  • 生成指标关注回答:是否忠于上下文、是否答全、是否引用正确、是否在无依据时拒答。
  • 线上指标关注体验和治理:延迟、token 成本、缓存命中、用户点赞/点踩、人工转接率、旧文档命中率。
  • LLM-as-judge 可以提升评估效率,但要有 rubric、抽样人工校准和版本固定。

3. 讲清工程取舍

  • 准确率和召回率:不能只追求 top-1 看起来相关,要确认正确证据是否稳定进入候选集。
  • 成本和延迟:更大的 top_k、更复杂的重排、更长的上下文会提升机会,也会增加 token、算力和 P95 延迟。
  • 可维护性:文档版本、索引版本、embedding 模型版本和 prompt 版本都要可追踪,否则线上问题很难复现。
  • 安全边界:权限过滤、租户隔离、来源可信度和无答案拒答要放在检索链路里,而不是只靠前端隐藏。

4. 面试里可以主动补充的生产细节

  • 建一套覆盖高频、长尾、无答案、权限、旧版本和冲突证据的评估集。
  • 记录每次请求的 query、rewrite、召回候选、分数、rerank 结果、最终上下文、答案和引用。
  • 对低置信检索结果触发扩大召回、改写查询、澄清问题、拒答或转人工。
  • 每次改 chunking、embedding、向量索引、reranker 或 prompt,都要做 case-level diff 和回归验证。

面试官追问3个问题

追问一:如果线上效果不好,你先排查哪里?

  • 考察点:是否具备分层定位能力。
  • 回答方向:先看 trace,确认正确证据有没有进入召回候选;如果候选里没有,查解析、切分、embedding、索引和 query rewrite;如果候选里有但没进上下文,查 rerank、过滤和 top-K;如果上下文里有但答错,查 prompt、模型和引用校验。

追问二:这个能力的参数怎么调?

  • 考察点:是否知道参数不能凭感觉。
  • 回答方向:用固定评估集比较 recall@k、MRR、上下文精度、faithfulness、最终准确率、P95 延迟和 token 成本,按业务风险选择阈值和默认值。

追问三:生产上最容易忽略什么?

  • 考察点:是否有真实落地意识。
  • 回答方向:容易忽略版本、权限、引用和无答案场景。RAG 系统必须记录索引版本、文档版本、metadata、引用来源和低置信兜底策略,否则很难做到可信和可回滚。

扩展知识

一个通用排障框架

text
文档是否解析对 -> chunk 是否切得合适 -> embedding 是否匹配 query -> 索引和过滤是否正确 -> rerank 是否把证据排前 -> prompt 是否约束模型 -> 答案是否忠于引用

常见错误回答

  • 只说“把资料放进向量数据库”,没有解释检索、重排、Prompt 和评估。
  • 把相似度分数当成可信度,没有说明证据校验和引用对齐。
  • 忽略权限、版本和删除传播,导致旧文档或越权内容进入上下文。
  • 用单个 demo case 证明效果,没有离线评估集和线上 trace。

基于 MIT 协议开源