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。
