RAG 专项训练 · Session 03
Q11
如果一个问题答案明明就在文档里,但系统就是召回不到,你会怎么系统性排查?请按步骤讲,不要只列关键词。
Q12
你怎么理解 metadata 在 RAG 里的作用?如果没有 metadata,会出什么问题?
Q13
很多企业文档里有表格。你觉得表格内容应该怎么入库?直接当普通文本切分会有什么风险?
Q14
如果你做的 RAG 系统经常“答得像对,但其实是错的”,你会怎么降低这种“看起来很合理的错误答案”?
Q15
请你设计一个“企业设备运维知识库”的 RAG 方案。
要求你至少讲到:
数据来源
切分策略
检索策略
是否要接工具
最后怎么给用户返回答案
你继续按 Q11-Q15 回答,我继续严格打。
22:01
11. 首先检查用户的query是否不准确噪声太大,其次检查检索模式是否为单一的语义检索或者关键词检索,导致答案没有检索到,继续就是检查是否答案被分片进行分割导致无法召回
12. metadata包含了原始文档信息,名称,时间等,可以对召回的片段进行文档来源的标注,同时加速检索效率
13. 表格应该要使用对应的解析器进行解析,比如解析为json方便后续进行检索召回,如果直接进行切分会导致语义不完整,召回后噪声大
14. 看起来很合理的错误答案可能是没有进行正确的召回,或者召回的内容没有进行rerank过滤,导致模型出现幻觉
15. 企业设备运维知识库需要设备档案信息,设备维护信息等文档,切分策略使用语义进行chunk切分,检索使用embedding进行向量然后rerank重拍,top-k过滤,不需要接入工具,将设备基础信息,设备维护信息,设备运行情况进行召回后给到LL M进行回答
22:18
这一轮是 58/100。不是因为你完全不会,而是因为你开始碰到真正区分“懂概念”和“能面试过关”的题了。你现在最大的问题是:
答案还是太短
经常只答到一半
没把“工程判断”和“场景边界”讲透
有些题你本来可以答得很好,但自己把答案收得太窄了
我按严格面试官方式给你拆。
Q11 评分:11/20
你提到了 query、检索模式、分片问题,方向没错,但这题要求是“系统性排查”,你现在还是在列点,没有步骤感。
真正高分回答要从 query -> 索引 -> 切分 -> 召回策略 -> 过滤条件 -> 数据质量 一层层排。
更优答案:
如果答案明明在文档里却召回不到,我会分五步排查。第一先验证数据是否真的入库了,包括文档解析是否成功、chunk 是否生成、向量是否写入成功;第二检查 query 本身,是否有歧义、缩写、别名、口语表达,需要不要做 query rewrite;第三检查 chunk 设计,是否切得过碎、关键信息被切断,或者 chunk 太大导致语义被稀释;第四检查召回策略,比如是不是只用了向量检索、top-k 太小、没有混合检索、metadata 过滤过严;第五做人工对比实验,用已知答案问题去查 top-k 结果,看问题到底出在召回前还是召回后。
你现在缺的不是点,而是这句:
先确认“数据有没有进去”,再确认“进去的数据能不能被正确召回”。
Q12 评分:12/20
你说了 metadata 是文档名称、时间、来源标注,这对,但还是太浅。
metadata 在 RAG 里不是“附属信息”,而是检索治理的关键部件。
更优答案:
metadata 在 RAG 里至少有四个作用。第一是过滤,比如按部门、时间、文档类型、设备编号、知识库范围做筛选;第二是引用,让最终答案能返回来源文档、页码、标题;第三是权限控制,不同用户只能查自己有权限看的资料;第四是召回治理,比如限定搜索最近版本、指定业务域,减少跨库污染。如果没有 metadata,系统会更容易召回到错误范围的内容,也很难做引用追溯和权限隔离。
你原答案里“加速检索效率”这句不算核心,面试里别放太前面。
更重要的是:
过滤
引用
权限
知识域隔离
Q13 评分:13/20
这题你答得方向是对的,而且比前几题更接近工程回答。
你说了“解析成 JSON 更方便检索”“直接切分会语义不完整”,这是有效信息。
但还差两个很重要的补充:表格适不适合做 RAG,以及 行列关系丢失的风险。
更优答案:
表格不能简单当普通文本切分,因为表格的语义依赖行列关系。比如设备编号、参数、单位、阈值、时间列,这些字段一旦被切开,模型看到的只是碎片文字,很容易误读。更合理的做法是先把表格解析成结构化表示,比如 JSON、键值对,或按“表头 + 行记录”展开成可检索文本;如果表格本身是强结构化查询场景,比如统计报表、设备台账、实时数据,很多时候更适合落表后走 SQL 或工具查询,而不是纯 RAG。
高分关键句你要记住:
表格的核心不是文字,而是结构关系。
Q14 评分:10/20
这题你答得明显不够。你只说了“召回错”和“没 rerank”,但面试官问的是:怎么降低这种看起来合理但其实错误的答案。
也就是说,他要听的是“治理手段”,不是只听“成因”。
更优答案:
要降低这种“像对但其实错”的答案,我会从四个层面做治理。第一提升检索质量,包括混合检索、rerank、chunk 优化和 metadata 过滤,保证模型看到的证据更准;第二在 prompt 上约束模型,要求必须基于给定证据回答,没有证据就明确说不知道;第三强制返回引用来源,让答案可追溯;第四做置信度和兜底机制,比如低相关召回时不直接生成结论,而是返回候选资料或建议用户补充问题。对于高风险场景,还可以加规则校验或人工审核。
这是非常重要的一题,你以后一定要会说这几个词:
基于证据回答
无证据不编造
引用返回
低置信度兜底
Q15 评分:12/20
你答了数据来源、切分、检索、返回,但这题最严重的问题是:你把它设计成了“纯文档问答”,没有结合“设备运维”的真实业务属性。
企业设备运维知识库很多时候 必须接工具,因为光靠文档不够。
更优答案:
企业设备运维知识库的数据来源至少包括设备说明书、SOP、维修手册、历史故障记录、告警处理记录、巡检记录、点位说明和设备台账。切分上我会优先按标题层级、故障章节、处理步骤切分,而不是单纯固定 token 切,因为运维知识很依赖步骤完整性。检索上建议做混合检索,设备编号、故障码、告警名适合关键词召回,故障现象和处理经验适合向量召回,再用 rerank 精排。这个场景我会接工具,因为很多问题会涉及实时状态,比如当前告警、最近运行参数、维修工单状态,这些不能只靠知识库。最终返回给用户时,答案里要区分“知识库结论”和“实时数据结论”,并附上来源文档、页码或工单编号。
你原回答里最大的问题是这句:不需要接入工具。
这在设备运维场景下通常是错误的,除非面试官明确说它只是“静态文档助手”。
你这一轮暴露出的核心短板
你会说模块,但不太会说 系统治理手段。
你还没形成“先判断场景,再决定方案”的习惯。
一碰到真实企业场景题,你容易把它答成普通知识库问答。
你缺少“高风险答案怎么兜底”的意识。
这四点是中高级面试非常看重的。
你现在必须背下来的几句
先判断这是静态知识问题,还是实时数据问题。
RAG 适合从非结构化知识里找答案,不适合替代数据库和业务系统。
表格的核心是结构关系,不是单纯文本。
降低幻觉不能只靠模型,要靠检索质量、提示约束、引用返回和低置信度兜底共同治理。
给你一版 Q11-Q15 速记版
Q11
我会先确认文档有没有成功解析、切分、入库,再检查 query 是否有歧义或别名问题,然后看 chunk 是否切坏、top-k 是否过小、是否缺少混合检索或 metadata 过滤过严。最后用已知答案问题回放 top-k,定位是“没召回到”还是“召回到了但排不到前面”。
Q12
metadata 不只是来源信息,它决定了过滤、引用、权限和知识域隔离。没有 metadata,系统容易跨库误召回,也很难做可追溯和权限控制。
Q13
表格不能直接按普通文本切分,因为它依赖行列关系。更合理的是解析成结构化 JSON、键值对或按行展开;如果是强结构化数据,很多时候更适合走 SQL 或工具查询。
Q14
降低“像对但错”的答案,核心是四件事:提高检索质量、要求模型严格基于证据回答、强制返回引用、低置信度时兜底不乱答。高风险场景还要加规则校验或人工审核。
Q15
设备运维知识库要接设备手册、SOP、故障案例、工单记录、巡检记录和设备台账。检索建议混合检索加 rerank,设备编号和故障码走关键词,故障现象走向量。很多问题还要结合实时告警和运行数据,所以通常要接工具,不应只做纯 RAG。
Tags
Share