RAG面试怎么答?沿着一份文档,把整个流程讲清楚

“先检索，再生成。”

这句话可以概括 RAG，却很难支撑一次完整的技术面试。

如果继续追问：

文档怎么处理？为什么这样切分？检索结果怎么筛选？效果如何评估？

答案就需要落到具体流程。

我们用一个假设场景来展开：给企业内部的产品文档，搭建一个问答助手。

一、文档拿到手，先检查解析质量

一份 PDF 看起来排版正常，提取出来的文本却可能存在标题丢失、表格错位、阅读顺序混乱等问题。

因此，入库之前，应抽样核对解析结果。

同时，保留文档来源、所属章节、版本和更新时间等元数据。

这些信息有助于后续定位出处、过滤旧版本和解释答案。

如果原始内容已经损坏，后面更换检索模型，也很难补回缺失的信息。

二、切分文档，要保留完整语义

检索系统需要从大量材料中找出与问题相关的部分。

切分，就是决定以什么内容单元参与检索。

块太短，可能只留下结论，丢掉适用条件；块太长，可能把多个主题混在一起。

例如：

“该方案支持免费升级。”

如果对应的产品型号、购买时间和限制条件被切到其他地方，单独召回这句话，就容易产生误解。

因此，切分策略应该结合文档结构验证。

章节标题、列表和表格，都值得单独检查。

对于脱离原文后难以理解的片段，也可以补充必要上下文。

Anthropic 的 Contextual Retrieval，就探索了在切块中加入说明性上下文的做法。

三、检索方式，要结合查询类型选择

向量检索是不是一定优于关键词检索？

需要看用户在问什么。

用户用口语描述需求时，语义检索可能更容易找到表达不同、含义相关的内容。

而产品型号、错误代码、专有名词等信息，通常需要精确匹配。

一个值得验证的方案是：

同时保留关键词检索和向量检索，再对候选结果进行融合。

面试时，可以进一步解释：

你的查询有哪些类型？

单一路径漏掉了什么？

怎样通过测试判断融合是否有效？

这些细节，比只说“使用混合检索”更有说服力。

四、召回之后，为什么还需要筛选？

初步召回解决的是：

从大量材料中，较快地找出一批候选内容。

重排进一步判断：

这些候选里，哪些更值得放进最终上下文。

可以把它理解为：先扩大候选范围，再进行更细的筛选。

不过，重排也会增加耗时。

因此，需要同时观察答案质量、延迟和成本，判断这一步是否值得保留。

五、生成回答时，要明确证据规则

材料放进提示词，并不代表任务已经完成。

还需要明确回答规则，例如：

优先依据提供的资料回答。

涉及条件时保留条件。

没有足够证据时说明缺失信息。

引用具体来源。

这些规则有助于约束输出，但不能替代质量检查。

尤其要区分两件事：

答案有没有引用？

引用内容是否真正支持答案？

出现了链接，并不代表结论已经得到证明。

六、评估效果，要把检索与回答分开看

检索阶段可以检查：

需要的资料有没有被找出来？是否排在足够靠前的位置？

回答阶段可以检查：

结论是否正确？是否完整回应问题？是否忠实于提供的证据？

此外，还要补上工程指标，例如响应时间、调用成本和失败率。

测试题也应覆盖不同情况：

资料中明确存在答案。

需要跨文档归纳。

用户提供的条件不完整。

知识库没有覆盖答案。

如果只测试“文档里恰好有一句原话”的问题，很容易高估系统能力。

面试时，可以这样组织项目介绍

“我们要解决的是某类用户在某个场景下的信息查询问题。

文档经过解析、清洗和切分后入库。查询时进行召回、筛选和上下文组织，再由模型生成带来源的回答。

最后通过固定测试集，分别检查检索效果、回答质量和服务成本。”

这段结构只是起点。

接下来，要填入你实际做过的技术选择、失败案例和实验结果。

为什么这样切分？为什么保留重排？哪类问题仍然答不好？

当这些问题都能继续展开，一个 RAG 项目才算讲得具体。

参考资料

Anthropic｜Contextual Retrieval

AI大模型学习路线

因篇幅有限，本文仅展示部分编程与 AI 学习资料；点击文章底部名片，或关注后回复“111”，即可获取完整资料。