RAG 检索答非所问：四层定位法

RAG 答非所问，最有效的排查顺序是把问题拆成四层：问题是否被正确理解，文档是否被正确解析和切分，检索是否召回了正确片段，模型是否基于这些片段生成了受约束的回答。先看最终答案再调向量参数，往往会把解析错误、过滤错误和生成幻觉混在一起。每一层都要保留可检查的中间结果，才能判断是“没有找到”还是“找到了但没有使用”。

第一层：问题与意图

先冻结用户原问题，不要一上来改写。把问题拆成主题、对象、时间、条件和期望输出。例如“报销差旅住宿超标怎么办”至少包含费用类型、制度动作和可能的地域或职级条件。如果索引内容使用的是“住宿费标准及审批流程”，而查询只保留“超标怎么办”，检索可能偏向处罚或审批片段。

排查时建立三份查询：原问题、去掉口语后的规范问题、包含关键实体和条件的扩展问题。逐份检索并记录结果差异。如果规范问题能召回正确文档，说明查询理解或词汇映射有问题；如果三份查询都找不到，继续检查文档和索引，不要把问题归因于提示词。

条件信息必须有明确的过滤策略。时间、部门、产品版本、权限范围等条件，既可以作为查询文本，也可以作为结构化 metadata filter；两者不能互相替代。只写进自然语言的“2025 年制度”，未必能阻止检索返回 2023 年的同名文档；只做 metadata filter，又可能因为文档没有正确写入该字段而返回空集。

第二层：文档解析与切分

向量检索无法补救源文档本身没有被正确解析的情况。扫描 PDF 里的文字可能仍是图片，复杂表格可能被打乱，页眉页脚可能与正文混在一起，标题层级也可能在转换时丢失。先随机抽取几份知识文档，检查原文、解析文本和最终 chunk 是否保持语义顺序，尤其要看否定词、单位、编号和条件句有没有断裂。

切分的目标不是让每个 chunk 长度相同，而是让一个片段包含可独立理解的事实。制度条款通常应把标题、适用范围、例外条件和操作步骤放在同一上下文；API 说明则应尽量保留字段名、类型和约束。过小会把“适用对象”与“金额上限”分开，过大则会把多个版本或多个主题混在一起，降低排序和生成的精确性。

每个 chunk 都应保留来源文档、章节、版本、生效日期、权限范围和稳定定位信息。重复的页眉、目录、免责声明会稀释有效文本；重复文档会让召回结果看似相关，却占满 top-k。可以先做去重和结构清洗，再评估切分长度，不要把所有问题都交给 embedding 模型。

以“密码重置”知识库为例，一个高质量片段应同时说明适用的账号类型、重置步骤、身份验证条件和失败后的人工渠道。如果切分后只剩“点击重置密码”，模型会给出看似正确却无法执行的答案；这不是排序参数的问题，而是上下文单元设计失败。

第三层：召回、过滤与排序

在 OpenAI Retrieval API 的具体实现中，Vector Store 是 Retrieval API 和 file search 使用的语义检索容器；向 Vector Store 添加文件时，该实现会自动执行切分、生成嵌入并建立索引，关联的 vector_store.file 还可以携带 attributes 供过滤。这里描述的是 OpenAI Vector Store/Retrieval 的处理链，不是所有向量库或所有 RAG 框架的默认行为；其他系统可能要求调用方自行切分、嵌入、建索引或管理 metadata。即使在这套实现中，自动化也不代表每个文件都被正确解析，过滤字段也不会自动变得完整。排查时应检查文件状态、实际切分结果、attributes，以及查询时使用的过滤条件。

把“召回为空”“召回不相关”“正确片段排位太后”区分开。召回为空通常与文件未完成索引、过滤条件冲突或查询过窄有关；召回不相关可能是解析、切分、重复和语义表述问题；正确片段排位太后则需要比较语义相似度、关键词重合和结果排序策略。不要只看 top-1，先保存 top-k 的文档标识、chunk 内容、得分、过滤条件和索引版本。

如果技术名词、编号和错误码很重要，纯语义检索可能不够。OpenAI Retrieval 文档提供混合检索的权重调节，让语义嵌入匹配和稀疏关键词匹配共同参与排序。关键词权重提高，适合版本号、接口名和错误码；语义权重提高，适合用户换一种说法描述概念。权重不是固定答案，应使用带标准答案的查询集对比，而不是凭几条对话感觉调整。

一个最小评估集可以包含三类问题：答案所在 chunk 明确且唯一的问题、需要多个 chunk 合并的问题、知识库中没有答案的问题。记录每个问题的正确片段是否出现在 top-k、正确片段排名、过滤是否符合预期，以及无答案时系统能否拒答。这样可以分别观察召回覆盖、排序质量和越权回答。

第四层：上下文使用与回答生成

如果正确片段已经进入上下文，答案仍然错误，就要检查生成阶段。常见原因是 top-k 过大，把多个版本、相反规则或无关章节一起交给模型；上下文超过限制后，关键片段可能被截断；提示词没有要求区分事实、条件和未知信息；模型把用户的暗示当成了知识库事实。

先做一个最小实验：只把人工确认的一个正确 chunk 放入提示词，要求模型只依据该片段回答，并在信息不足时明确说无法确定。如果此时答案正确，问题在检索结果组合、排序、截断或提示词；如果仍然错误，检查片段文本是否完整、问题是否有歧义，以及生成模型是否遵守约束。

回答模板应要求模型保留适用条件、时间版本和例外情况。需要引用时，引用应来自实际进入上下文的文档定位，而不是模型自行拼出的链接。对于知识库没有覆盖的问题，允许拒答比生成一个语气确定的猜测更安全。尤其是制度、合同和运维命令，答案中缺少一个条件就可能把正确规则变成错误操作。

一个完整的四层定位例子

用户问“华东区域的采购审批额度是多少”，系统返回了华南区域的额度。第一层先检查“华东”是否被查询改写保留；第二层检查区域字段是否在文档正文和 metadata 中存在；第三层检查过滤条件是否真的传到了检索请求，以及华东片段是否在 top-k；第四层检查提示词是否要求按区域作答，是否把华东和华南片段一起塞进上下文。

若华东片段没有召回，修复索引字段或过滤；若召回但排名靠后，比较区域词、版本和额度字段的混合排序；若片段正确但答案仍选华南，减少冲突上下文并增加条件约束。四种修复对应不同层，不能用同一个“调大 top-k”覆盖所有问题。top-k 变大有时能找回正确片段，也会增加冲突信息和上下文成本。

常见失败模式

第一，在 OpenAI Vector Store/Retrieval 中把文档上传成功当成内容可检索，忽略其异步索引状态。第二，metadata 的字段类型、大小写或日期格式不一致，过滤后结果为空。第三，切分把标题和条件拆开，片段单独看都像正确答案。第四，只优化向量相似度，不处理错误码、版本号等精确词。第五，top-k 太小导致多段证据缺失，太大又引入相互冲突的版本。第六，生成提示词只要求“回答问题”，没有要求基于证据、保留条件和在无证据时拒答。

在 OpenAI Vector Store/Retrieval 的具体实现中，Vector Store 对象有 in_progress、completed 和 expired 等状态；这些是该 API 的对象生命周期状态，不是所有向量库或所有 RAG 系统的通用状态。创建或关联文件的操作可能是异步的，应等待完成或主动检查状态；配置过期策略后，超过期限的 OpenAI Vector Store 可能进入 expired。排障时要把该实现的索引状态、vector_store.file 状态和过期策略纳入检查，而不是只观察模型输出。对 OpenAI Vector Store 删除文件后，内容还可能在短时间内出现在搜索结果中，这是其文档说明的最终一致性行为，不能据此推断其他向量库也有相同表现。

建议的修复顺序

先建立十到几十条带“正确文档和正确片段”的固定查询集，保存原问题、过滤条件、top-k 结果和最终回答。然后按查询、文档、召回、生成四层逐层替换为可观测中间结果。每次只改一层：先修解析和 metadata，再调切分与去重，再比较混合检索权重，最后优化上下文组合和拒答策略。

上线后继续采集无答案、低置信度、用户纠正和重复追问。把这些反馈标注为查询错误、知识缺失、召回错误或生成错误，避免把所有反馈都归为“模型不聪明”。当每一层都有可复现证据，RAG 的优化才会从试参数变成可验证的工程迭代。