检索质量优化：Chunk、Metadata、Hybrid Search 与 Rerank
RAG 的第一道质量门槛是检索。如果候选证据错了，后面的 prompt 再精致，也只是让模型更有条理地犯错。
但“检索质量差”不是一个单一问题。它可能是 chunk 切分不适合问答，可能是 metadata 缺失导致适用条件混乱，可能是纯向量漏掉错误码，也可能是召回结果够多但排序不稳定。
这篇文章围绕四个最常见的优化点展开：chunk、metadata、hybrid search 和 rerank。重点不是列技术名词，而是判断它们分别解决什么问题、带来什么成本、什么时候值得做。
提出问题：检索为什么找不到正确证据
假设一个云服务控制台接入 RAG 助手，帮助企业客户排查部署和账单问题。
用户包括一线客服、解决方案工程师和客户管理员。问题来自在线聊天、工单和控制台侧边栏，常见输入包括：
- “为什么我这个 VPC 不能绑定公网网关？”
- “API 返回
InvalidSignature怎么处理？” - “私有化 2.8 版本支持这个审计配置吗？”
- “上个月账单里对象存储流量费为什么突然升高？”
知识来源包括产品文档、FAQ、发布说明、错误码手册、历史工单、内部 SOP 和计费规则。期望输出是排查步骤、适用条件、引用来源和下一步动作。
这里的失败样本很典型：
- 用户问错误码，纯向量检索找到了语义相近的认证文档，却没有命中错误码手册。
- 用户问私有化版本，检索到了公有云最新文档，答案不适用。
- 文档里一个表格跨多行说明套餐限制，chunk 切分后丢了表头。
- top-10 里有正确片段，但排在第 8 位，没有进入最终上下文。
分析问题：召回、条件和排序要分开看
检索质量优化主要处理检索和排序问题，但也牵涉抽取、分类和判断。
模型可以帮助理解用户语言，但检索系统必须保留可解释、可回放的中间结果。否则线上出错时，团队只会看到一个错误答案，却不知道是召回、过滤、排序还是上下文组装出了问题。
收益/成本判断
检索优化的收益包括：
- 提高答案覆盖率，减少“知识库有但找不到”。
- 降低相似但不适用内容进入上下文的概率。
- 减少模型根据错误证据生成错误答案。
- 让不同问题类型使用不同检索策略。
- 为后续 RAG Eval 提供可定位的质量指标。
成本包括：
- 文档解析和 chunk 规则维护。
- metadata schema、标注和同步成本。
- 多路检索、rerank 带来的延迟和费用。
- 检索参数、阈值、融合权重的评估和回归测试。
- 索引重建、版本迁移和灰度发布成本。
什么时候简单关键词足够？
如果问题包含明确实体、错误码、订单号、API 名、文档标题，且用户愿意点开原文自己判断，关键词搜索通常足够。它可解释、便宜、容易排查，尤其适合专业用户。
什么时候简单向量足够？
如果知识库规模不大、文档条件差异少、问题主要是概念解释和流程问答，单路向量检索可以起步。比如内部 HR 政策问答、培训资料问答、低风险操作指南。
什么时候需要工程优化？
一旦出现精确词和自然语言混合、版本/套餐/权限决定答案、相似文档很多、top-k 波动明显、答案需要对外使用，就应该升级到 chunk、metadata、hybrid 和 rerank 的组合优化。
列举方案：从文档处理到 Rerank
检索优化要先让文档变成可检索、可引用、可过滤的证据单元，再选择关键词、向量、hybrid search 或 rerank。下面四类方案分别对应不同失败根因。
Chunk：让片段成为可回答单元
Chunk 的目标不是把文档平均切小，而是让每个片段既能被检索命中，又足够支撑一个回答。
切得太小，片段可能只有一句话，缺少标题、条件和上下文。模型看到“支持该配置”却不知道“该配置”是什么。
切得太大，向量会混合多个主题，召回时看起来相关，实际包含大量噪声。上下文预算也会被浪费。
更稳妥的做法是按文档结构切分：
- 标题层级：保留一级、二级、三级标题作为片段前缀。
- FAQ：问题和答案不要切开。
- 操作步骤：一组连续步骤尽量保留在同一片段。
- 表格：保留表头、行名和单位，必要时转成可读文本。
- 代码和错误码：保留代码块、错误码、参数名和解释。
- 版本说明：版本号、发布日期、适用范围不能和正文分离。
收益：提高召回可用性，减少“找到了但片段没法回答”。
成本：需要文档解析、特殊格式处理、索引重建和样本验证。对 PDF、表格、截图和代码文档尤其要投入额外处理。
Metadata：让业务条件进入检索
很多 RAG 错误不是主题错，而是条件错。
用户问的是“私有化 2.8”，检索到“公有云 3.1”；用户问的是“企业版套餐”，检索到“旗舰版”；用户是普通客服，却检索到了内部定价策略。
这些问题不能只靠向量相似度解决。需要把业务条件变成 metadata。
常见 metadata 包括：
metadata 的收益是让检索更符合业务语境，降低“找错”。
成本是 schema 设计和数据治理。metadata 如果缺失、错误或不一致，会制造新的误判。最好先选择真正影响答案的 3 到 5 个字段，而不是一次性设计几十个字段。
Hybrid Search：让精确匹配和语义召回互补
关键词和向量各有盲区。
关键词擅长错误码、接口名、产品名、政策编号、专有名词。它的问题是同义表达和自然语言召回弱。
向量擅长语义相似和表达变化。它的问题是精确 token 可能被稀释，业务条件可能被忽略，相似主题容易混淆。
Hybrid search 把两者组合起来，常见做法是：
- 同时跑 BM25/关键词和向量检索。
- 对结果去重。
- 按分数归一化或 rank fusion 融合。
- 再用 metadata 过滤和 rerank。
收益：减少单一路径漏召回，尤其适合“错误码 + 自然语言描述”的问题。
成本：参数更多、评估更复杂、延迟更高。需要明确融合策略，否则只是把两路噪声混在一起。
Rerank：在候选里选真正可回答的证据
召回阶段通常追求“别漏掉”，rerank 阶段追求“排对顺序”。
当 top-50 里有正确答案，但 top-5 经常不稳定时，rerank 很有价值。它可以用 cross-encoder、轻量模型、大模型评分或规则特征，把候选和查询放在一起判断相关性。
rerank 特别适合：
- 相似文档很多。
- 文档标题相似但适用条件不同。
- 查询较长，包含多个约束。
- 需要把历史工单和正式文档区分权威性。
- 向量 top-k 里正确片段排名靠后。
收益：提高进入上下文的证据质量，减少“找到了没用上”。
成本：额外模型调用、延迟和费用；还需要处理超时、分数阈值和候选数量。rerank 不能弥补召回阶段完全没找到正确资料的问题。
方案阶梯
检索优化可以按下面顺序推进：
- 建立基线：记录用户 query、召回结果、答案和反馈。
- 优化 chunk：让片段可检索、可阅读、可引用。
- 补关键 metadata：先补影响答案的字段。
- 引入 hybrid：解决精确词和语义表达混合的问题。
- 引入 rerank：解决候选多但排序不稳的问题。
- 加阈值和拒答：资料不足时不强答。
- 用 Eval 回归：每次改索引、参数、模型都跑评估集。
不要跳过基线。没有基线时，团队很容易把一次主观体验变好误认为整体质量提升。
决策判断：什么时候升级检索链路
反模式
第一种反模式：用固定长度切所有文档。
固定 500 字或 1000 token 可以作为起点，但不能处理 FAQ、表格、代码、版本说明和多级标题。切分规则应该服务可回答性。
第二种反模式：metadata 越多越好。
字段多但不准，会让过滤结果更差。先找出真正影响答案的条件，再逐步扩展。
第三种反模式：hybrid 只是两路结果拼接。
没有去重、融合、权重和评估，hybrid 可能只是把关键词噪声和向量噪声一起带进上下文。
第四种反模式：用 rerank 掩盖召回不足。
rerank 只能重排候选，不能凭空找回没有召回的文档。如果正确片段不在候选集里，问题在 query、chunk、索引或召回策略。
第五种反模式：只用线上感觉调参数。
检索参数对不同问题类型影响不同。一个参数让 FAQ 变好，可能让错误码变差。必须用分类型评估集回归。
结论收束：检索上线前工程清单
- 场景边界：核心问题类型是否分成错误码、概念解释、操作步骤、政策规则和历史案例。
- 文档解析：标题、表格、代码、图片文字、FAQ、版本说明是否正确抽取。
- Chunk 设计：片段是否包含足够标题、条件、来源和可回答内容。
- Metadata：字段是否少而准，是否能从问题中抽取或由系统上下文提供。
- 权限过滤：metadata 过滤是否在检索和上下文组装前完成。
- 检索组合：关键词、向量、hybrid 和 rerank 是否按问题类型路由。
- 阈值策略：低相关性、候选冲突、资料不足时是否追问或拒答。
- 可观测性：是否记录每路召回、融合分数、rerank 分数和进入上下文的片段。
- 评估集：是否覆盖找不到、找错、条件不适用、排名靠后和精确词问题。
- 成本延迟：rerank 候选数量、超时、缓存和降级路径是否明确。
小结
检索质量优化的关键是先定位失败类型。
chunk 解决片段不可用，metadata 解决业务条件不适用，hybrid search 解决精确匹配和语义召回的互补，rerank 解决候选排序不稳。它们不是越多越好，而是分别对应不同瓶颈。
知识库小、问题清晰、失败代价低时，关键词或简单向量就够。知识库大、条件复杂、答案要被业务使用时，检索必须进入工程化优化和评估闭环。