RAG 专项训练 · Session 02
Q6
如果检索出来的内容很多，但最终答案还是不准，你会优先排查哪些环节？按顺序讲。
Q7
embedding 模型 和 rerank 模型 分别负责什么？为什么很多系统两个都要有？
Q8
如果一个企业知识库里既有 PDF，也有扫描件图片，还有 Excel 表格，你会怎么处理文档解析问题？
Q9
什么情况下你会认为这个问题“不适合做 RAG”，而应该改成数据库查询、规则引擎或者工作流系统？
Q10
如果领导问你：“这个 RAG 系统到底好不好，怎么评估？”你会怎么设计评估指标？
你按 Q6-Q10 回答，我继续严格打。
21:45
1. 我会优先检查召回内容，看召回的内容是否overlap重叠内容过多，然后再检查dunck分片是否太小导致语义缺失，再检查是否进行rerank寻找语义相关性最高的，其次是检查top-k是否返回数据过多，还要检查不同业务的知识库是否进行隔离
2. embedding 模型 是将chunk或者用户的query进行向量化处理，rerank是对召回的内容进行重新排序，筛选语义相关性高的，有的系统二者都有是可以增强检索的相关性
3. 使用不同的库，如python-docx 或者 pands，pdf等python库将文档统一处理成有相同的metadata的md文件，方便后续进行分割和检索
4. 对于需要检索实时数据的情况或者更新速度较快的内容不适合rag，适合查询数据库或者工作流才能保证数据的有效性
5. 对弈rag系统的评估主要看，召回成功率，语义相关性，召回生成事件，以及用户使用主观评价等方面
22:01
这一轮比上一轮稍好一点，说明你开始往“排查思路”上靠了，但整体还是偏 提纲式回答，缺少面试官最看重的两样东西：
判断顺序
工程指标
这一组我给你 64/100。能聊，但还撑不起“我真的做过并能落地”的感觉。
逐题点评
Q6 评分：14/20
你这题比上一轮好，至少开始按排查顺序回答了，也提到了 overlap、chunk、rerank、top-k、知识库隔离，这些点都对。
但问题是顺序还不够完整，而且少了两个关键检查项：query 问题 和 生成问题。很多人一上来只盯召回，其实用户问题改写失败、权限过滤错、prompt 注入方式不对，也会导致答案不准。
更完整的回答应该是：
如果检索很多但答案不准，我会按链路排查。第一步先看 query 本身有没有问题，比如用户问题是否过短、歧义大，是否需要 query rewrite；第二步看召回结果是否真的包含答案，也就是检查 chunk 质量、top-k、混合检索策略、知识库隔离和 metadata 过滤；第三步看 rerank 是否把真正有用的片段排到了前面；第四步看 prompt 拼接是不是把噪声片段带太多，导致模型被干扰；最后再看生成模型是否理解错误，或者回答时没有被约束在引用内容内。
面试官会喜欢你多补一句：
我会先判断问题是在“没召回到”，还是“召回到了但没答对”，这是两个完全不同的排查方向。
Q7 评分：13/20
你把两个模型的职责说对了，但还是太平。面试官会继续追问：为什么 embedding 不能直接替代 rerank？
更优回答：
embedding 模型的职责是把文档 chunk 和用户 query 编码成向量，用于高效率的大规模初筛召回；它更适合从大库里快速找一批可能相关的候选。rerank 模型是在初筛结果上做精排，它通常直接看 query 和候选文本对，判断哪个更相关，所以精度通常高于单纯向量相似度。很多系统两个都要，是因为 embedding 解决“从海量数据里先捞出来”，rerank 解决“从候选里排准顺序”，一个偏效率，一个偏精度。
你要补一个很关键的取舍：
如果只用 rerank，成本太高，不能直接对全库逐条排序；如果只用 embedding，效率高但精度不够。
Q8 评分：12/20
你的思路是对的：先解析，再统一格式，再抽 metadata。
但你的回答还像“我会用几个 Python 库”，不够像系统设计。真正好的回答不是列库，而是讲 文档类型差异 -> 解析策略 -> 统一中间表示 -> 质量兜底。
更优答案：
企业知识库里不同文档类型要分开处理。对于 Word、Excel、PDF 这类结构化或半结构化文档，我会分别用对应解析器提取正文、标题、表格和页码；对于扫描件图片或扫描版 PDF，需要增加 OCR 流程，把图片文字识别出来。解析后我不会直接入库，而是统一转成中间表示，比如带标题层级、段落、表格、页码、来源路径、时间、权限信息的结构化 JSON 或 Markdown，再做清洗和切分。这样后续 chunk、检索、引用返回和权限控制会更稳定。
你漏掉的关键点有：
OCR
表格处理
页码 / 标题 / 来源路径
失败兜底和人工抽检
如果面试官追问：
Excel 怎么做 RAG？
你可以答：不是所有 Excel 都适合直接进 RAG，结构强、字段明确的更适合抽成表结构走 SQL 或检索前先做结构化转换。
Q9 评分：12/20
你的方向对，提到了 实时数据 和 更新快 不适合纯 RAG。
但这题你答得还是不够全。真正高分答案要体现：RAG 适合非结构化知识，不适合强结构化、强事务、强精确计算场景。
更优答案：
我会从三个角度判断这个问题适不适合做 RAG。第一，如果问题答案主要存在于非结构化文档里，比如制度、手册、FAQ、历史案例，那适合 RAG；第二，如果问题需要精确实时数据，比如订单状态、库存、今天能耗、当日报警，那更适合数据库查询或 API 调用；第三，如果问题需要固定规则判断、审批流、状态流转、多系统动作执行，那更适合规则引擎或工作流系统。RAG 更适合“找资料并辅助理解”，不适合替代强确定性的查询和执行系统。
这是你以后一定要背的一句：
RAG 解决的是“从非结构化知识中找答案”，不是“替代数据库和业务系统”。
Q10 评分：13/20
你说了几个方向：召回成功率、语义相关性、生成效果、用户评价，基本对。
但这题最容易拉开差距，因为面试官想听的是 可量化指标体系，而不是泛泛而谈。
更优答案：
RAG 评估我会分成离线评估和在线评估两层。离线评估重点看检索效果和回答效果，比如 recall@k、MRR、nDCG、命中率、是否召回正确证据、答案正确率、引用正确率；在线评估看用户维度，比如问题解决率、追问率、人工转接率、平均响应时延、用户满意度。再往工程侧补，还要看 token 成本、检索耗时、失败率、空召回率。这样才能同时评估“答得准不准、快不快、值不值”。
你这里少了最重要的三个词：
Recall@K
引用正确率
人工转接率 / 问题解决率
你这一轮的共性问题
你会说“做法”，但不太会说“为什么这样做”。
你知道模块名，但缺少 指标化表达。
你经常停在“有这个环节”，但没说“这个环节解决什么问题”。
你的答案还不够像真实项目 owner，更像看过资料的人。
你现在最需要强化的能力
以后答 RAG 题，尽量把回答说成这个结构：
先定性
这个问题属于检索问题、生成问题，还是数据源问题。
再拆链路
离线建库、在线检索、重排、生成，各环节分别可能出什么错。
再给指标
不要只说“好不好”，要说 Recall@K、命中率、时延、转人工率。
最后说边界
什么适合 RAG，什么必须走 API / SQL / 工作流。
给你一组速记版示范
Q6 速记版
我会先判断是没召回到，还是召回到了但没答对。先查 query 规范化和检索结果，再查 chunk、top-k、metadata 过滤和 rerank，最后查 prompt 拼接和生成模型理解。很多时候不是模型差，而是检索噪声太大。
Q7 速记版
embedding 负责把 query 和 chunk 编码成向量，用于海量数据里的高效初筛召回；rerank 负责对候选结果做精排，提升最终相关性。前者偏效率，后者偏精度，所以很多系统两个都要。
Q8 速记版
不同文档要分开解析：Word、PDF、Excel 走不同解析器，扫描件要加 OCR。解析后统一转成结构化中间格式，保留标题、页码、表格、来源路径和权限 metadata，再做切分和入库。
Q9 速记版
RAG 适合非结构化知识问答，不适合实时数据查询、强精确计算和强流程执行。像今天能耗、库存数量、审批状态，更适合 API、SQL 或工作流系统。
Q10 速记版
评估要分离线和在线。离线看 recall@k、命中率、引用正确率、答案正确率；在线看问题解决率、追问率、转人工率、响应时延和 token 成本。
下面开始第三轮，我给你上更像真实面试的 RAG 进阶追问。这一组答好了，你的面试表达会明显上一个台阶。
Tags
Share
