RAG 上线后，最难排查的故障常有几个相似症状：回答语气很确定，引用片段却答非所问；同一个问题换一种说法，命中的文档随之变化；新旧制度一起进入上下文。团队往往先换 Embedding 模型，召回指标却没有明显变化。
H3C 对企业级 RAG 链路的梳理将流程分为知识索引构建、查询检索和生成增强。实际排查时，检索质量在前两步已经被大致决定：原始文档有没有清洗干净，切块是否保留语义，查询范围有没有被正确约束，候选片段是否经过二次排序。
Introl 在 2025 年 12 月更新的资料中提到，Harvey AI 已为 97% 的 Am Law 100 律师事务所提供服务。与此同时，生产环境还要处理嵌入漂移、多租户和亚 50 毫秒延迟等问题。检索调优因此不能只看准确率，还要同时考虑索引更新和响应时间。
先查切块，别让 Embedding 背锅
按 500 字或固定 Token 数切分，实施简单，却很容易破坏文档结构。财务报表的表头和数据行可能被分开，制度条款的正文和例外说明也可能落入两个片段。后续向量化再准确，也很难补回已经丢失的关系。
Introl 汇总的测试结果显示，语义分块相较固定大小分块，召回率最高可提升 9%。这里的“最高”需要留意，它是特定测试条件下的结果，不能直接当作所有知识库的收益承诺。
更稳妥的处理顺序是：
- 先识别标题、段落、列表、表格和代码块，尽量按原始结构切分。
- 在切分前清理页眉、页脚、页码、重复导航和 OCR 噪声。H3C 的流程同样把解析、清洗和脱敏放在嵌入之前。
- 对缺少明显结构的长文本，再根据句子边界和相邻句子的语义相似度寻找切点。
- 给片段补上文档 ID、版本、页码、章节和内容类型。表格与代码块尤其需要这些信息。也可以参考 PageIndex、重排序等方法的整理，为片段增加可导航的层级信息。
RecursiveCharacterTextSplitter 可以继续作为兜底工具，但不宜承担 PDF、表格和代码的第一层解析。现有 LightRAG 或 LangChain 链路也不必全部重做，先补结构解析和元数据，通常更容易定位收益来自哪里。
语义分块会增加索引计算。知识库更新频繁时，可以只重建发生变化的文档，避免每次全量计算。评估时使用同一组查询，比较不同切块方式下的 Recall@K，并人工抽查未命中的片段是否在切分时就已失去上下文。
搜索范围没圈对，混合检索也会跑偏
向量检索与 BM25 组合后，可以同时处理语义相近和关键词精确匹配的问题。但当知识库里同时存在旧版制度、新版制度，或者多个区域使用相同指标名称时，两路检索仍可能返回字面相关、业务上却不适用的内容。
例如用户提问：“上个月华东区的销售数据怎么样？”检索前应先识别相对时间、区域和文档类型。“上个月”需要根据提问时间转换成明确日期，区域名称也要与知识库中的标准字段对齐。租户、部门、文档版本和访问权限，同样适合进入过滤条件。
当字段识别结果足够可靠时，可将其作为硬过滤条件传入 Milvus、Pinecone 或 Weaviate，让向量搜索在更小的候选范围内进行。过滤字段还要统一格式，并确认已经进入数据库的可过滤索引。否则，脏数据会让硬过滤直接变成零结果。
置信度不足的字段不宜强行过滤。可以保留多个候选值，或退回范围更宽的检索，再交给重排序模型判断。这样能减少意图识别出错造成的漏召回。
火山引擎开发者社区的 RAG 方案对比把数据量低于 10 万条、并发低于 100 作为轻量场景的参考条件。这组数字适合用于架构选型，不能直接换算成元数据过滤的精度收益。过滤是否有效，仍要在自己的查询集上测试，并记录旧版本误命中、跨区域误命中和过滤后零结果等问题。
重排序的价值，取决于难负样本
向量检索负责尽量找全候选，Cross-Encoder 重排序模型再联合读取问题与片段，判断哪一段更能支撑答案。两者处理的是不同阶段。
Introl 引用的嵌入基准中，Voyage-3-large 相比 OpenAI 和 Cohere 的部分模型高出 9%—20%。基准成绩可以帮助选型，却不能代替业务查询测试。公司简称、内部术语和专业缩写，仍可能让通用模型排错顺序。
模型分工也要理清。BGE-M3 更适合放在召回侧；BGE-Reranker、Jina Reranker v2 或 Cohere Rerank API 可用于候选重排。需要领域适配时，再针对可微调的模型评估 LoRA 等方案。
训练数据里最有价值的通常是难负样本，例如：
- 关键词相同，但来自旧版本制度的片段；
- 实体相同，但时间或区域不符合问题的片段；
- 向量分数很高，实际无法为答案提供依据的片段。
点击日志只能作为线索，不能直接等同于相关性标签。更可靠的做法是结合人工判断、明确的未采纳反馈，以及现有检索器反复出现的误命中样本。
候选数量需要和延迟一起测试。先召回 Top-100，再重排并选出 Top-10，可以作为初始配置，但不应被当成固定答案。如果整条检索链路要求亚 50 毫秒响应，就要继续调整候选数量、模型大小、批处理方式和重复查询缓存。
用失败样本做验收
LinkAI 的 RAG 优化实践把导入、检索、生成和评估放在同一条链路中。对检索环节做改动时，最好准备一组来自真实业务的问题，并为每个问题标出能够支撑答案的片段。
可以重点记录四类指标：
Recall@K：正确片段有没有进入候选集；MRR或nDCG：正确片段是否排在足够靠前的位置；- 过滤后的零结果、旧版本误命中和跨范围误命中；
- 重排序延迟，以及最终送入大模型的上下文长度。
每轮测试只改一个主要变量，并记录切块配置、Embedding 版本、过滤规则和重排序模型版本。失败样本也要分开看：所需片段没有进入 Top-K，优先修切块与过滤；片段已经进入候选集却排得太后，再调整重排序。等这三个环节稳定后，更换嵌入模型的效果才容易解释。
