前面几篇文章里我们已经讨论了 RAG 的基础链路、文档切分、Embedding 模型和向量数据库。到这里一个最小 RAG 系统已经可以跑起来了文档切分 ↓ Embedding 向量化 ↓ 写入向量数据库 ↓ 用户提问 ↓ 向量检索 ↓ 大模型生成答案这个流程看起来很完整。但很多系统真正进入使用后会遇到一个非常典型的问题文档明明在知识库里系统就是检索不到或者检索到的内容看起来相关但不能回答问题。这时候很多人第一反应是换 Embedding 模型、换向量数据库、调大 TopK。这些方法可能有帮助但不一定能解决根因。因为真实 RAG 检索质量的问题往往不是单一向量检索能完全覆盖的。尤其在企业文档、技术文档、产品文档、接口文档里很多问题并不是纯语义相似问题而是精确匹配、关键词命中、术语对齐、编号定位和业务过滤共同作用的问题。这篇文章就讨论一个核心问题RAG 检索质量应该怎么提升为什么很多系统需要从单一向量检索走向关键词检索和 Hybrid Search。为什么只靠向量检索不够向量检索很适合处理语义相似。比如用户问题还没转正能不能休年假 文档片段试用期员工年休假按入职时间折算。这里“还没转正”和“试用期”并不是完全一样的词但语义上接近。Embedding 模型如果效果不错就有机会把它们匹配到一起。再比如用户问题线上数据库多久备份一次 文档片段生产环境数据库每日凌晨执行全量备份。“线上数据库”和“生产环境数据库”也是近义表达。这类问题是向量检索擅长的。但真实知识库里还有很多问题并不适合只靠向量检索。比如ERR_1024 表示什么 POST /orders 的 quantity 参数怎么填 v2.3.1 是否支持批量导入 P-7003 这个产品型号的功耗是多少这些问题里错误码、接口路径、参数名、版本号、产品型号是关键。它们不是普通语义表达而是精确符号。如果只靠向量检索系统可能召回语义相似但编号错误的内容。比如用户问ERR_1024系统召回ERR_1025。从文本相似度上看它们很接近从业务上看它们完全不同。这就是单一向量检索的局限。向量检索擅长“相似”但很多业务问题需要“准确”。向量检索容易漏掉什么在实际项目里只靠向量检索容易漏掉几类内容。第一类是编号和代码。比如错误码、订单号、工单号、版本号、产品型号、接口路径。这些内容通常需要精确命中。第二类是短关键词。比如某个字段名、配置项、模块名、表名、函数名。短词在向量空间里信息量有限很容易被更长、更语义化的内容淹没。第三类是专有名词。比如内部系统名、项目代号、部门简称、产品缩写。通用 Embedding 模型不一定理解这些词。第四类是表格字段。比如用户问“最大并发数是多少”答案可能藏在参数表里。表格被切分和转换后如果字段名没有很好保留向量检索可能不稳定。第五类是相似业务流程。合同审批、采购审批、报销审批、立项审批都很像。向量检索可能把它们混在一起。第六类是版本和时间敏感内容。旧制度、新制度、旧接口、新接口在语义上可能很相似但真实答案应该来自最新版本。这些问题说明一个事实RAG 的检索不只是语义相似度问题。它还包括关键词命中、结构化过滤、版本选择、权限控制和业务边界判断。关键词检索解决什么问题关键词检索最典型的代表是 BM25。它和向量检索的思路不同。向量检索关注语义相似关键词检索关注词项匹配。比如用户问ERR_1024 是什么意思关键词检索会非常重视ERR_1024这个词是否出现在文档里。而向量检索可能认为ERR_1025、ERR_1042、错误码说明都很相似。在这种场景下关键词检索往往更可靠。关键词检索特别适合错误码。接口路径。参数名。配置项。产品型号。版本号。文件名。表名。精确术语。比如POST /orders tenant_id max_connections v2.3.1 P-7003这些内容不一定需要语义理解而是需要精确定位。所以在 RAG 系统里关键词检索不是过时技术。它仍然非常重要。尤其是技术文档和企业文档很多问题如果没有关键词检索召回质量会很不稳定。向量检索和关键词检索各自擅长什么可以简单对比一下。向量检索擅长同义表达。口语化问题。概念相似。长文本语义匹配。用户不知道准确关键词时的模糊查询。关键词检索擅长精确词命中。编号、代码、参数名。短文本查询。专有名词。字段、路径、版本号。举个例子。用户问还没转正能不能休年假文档里写试用期员工年休假按入职时间折算。这时向量检索更有优势。再看另一个问题ERR_1024 是什么意思文档里写ERR_1024用户认证失败请重新登录。这时关键词检索更有优势。所以不要把向量检索和关键词检索看成二选一。它们解决的是不同问题。真实系统里很多时候需要两者配合。Hybrid Search 是什么Hybrid Search 通常指混合检索。最常见的形式是向量检索 关键词检索也就是同一个用户问题同时走两条召回链路用户问题 ├─ 向量检索召回语义相似内容 └─ 关键词检索召回关键词命中内容 ↓ 合并结果 ↓ 去重和排序 ↓ 交给后续 Rerank 或生成模型Hybrid Search 的目标不是炫技而是把不同检索方式的优势组合起来。向量检索负责找“意思接近”的内容。关键词检索负责找“词命中准确”的内容。两者结合后系统对真实问题的覆盖面通常会更好。比如用户问v2.3.1 版本支持批量导入吗关键词检索可以确保v2.3.1被命中。向量检索可以找到“批量导入”“批量上传”“批处理导入”等语义相关内容。如果只靠其中一种都可能不够稳定。这就是 Hybrid Search 的价值。Hybrid Search 不是简单把结果拼起来很多人理解 Hybrid Search 时会以为它就是向量检索 TopK 关键词检索 TopK然后直接把结果全部塞给模型。这样做很容易出问题。因为多路召回之后会出现几个新问题。第一结果重复。同一个 Chunk 可能同时被向量检索和关键词检索召回。第二分数不可直接比较。向量相似度和 BM25 分数不是一个尺度不能简单放在一起排序。第三召回内容质量不一。关键词命中的内容可能只是出现了某个词但并不能回答问题。向量召回的内容可能语义相关但缺少精确条件。第四TopK 变多后上下文容易超长。如果两个检索器各召回 10 条合并后可能有 20 条候选内容不能全部无脑塞进 Prompt。所以 Hybrid Search 的关键不只是“多路召回”还包括合并。去重。分数归一化。初步过滤。重排序。上下文压缩。这些步骤决定了 Hybrid Search 是否真正有效。多路召回结果怎么合并一个简单的合并策略是取并集。比如向量检索返回 A、B、C、D、E 关键词检索返回 C、E、F、G、H 合并结果为 A、B、C、D、E、F、G、H然后按某种规则重新排序。这比只用一种检索方式覆盖更广。但真实系统里需要更细致地处理。可以考虑几个因素第一同一个 Chunk 被多路召回说明它可能更重要。如果一个片段同时被向量检索和关键词检索命中可以提高它的优先级。第二关键词命中精确标识符时应该提高权重。比如命中ERR_1024、POST /orders、tenant_id比命中普通词更重要。第三向量检索分数高但关键词不命中不一定要降权。因为用户问题可能是口语化表达关键词不一致很正常。第四重复内容要去掉。同一文档、同一段落、相邻高度重叠 Chunk都需要处理否则会浪费上下文。第五要考虑 metadata。版本、权限、租户、文档状态等过滤条件最好在检索阶段就参与而不是等生成阶段再处理。合并策略不是越复杂越好。早期可以先用简单规则然后通过真实问题集逐步调整。Rerank 在 Hybrid Search 后更重要多路召回之后候选内容会变多。这时 Rerank 的作用会更明显。Retriever 负责把可能相关的内容召回来。Rerank 负责在候选内容中进一步判断哪些更值得交给模型。比如 Hybrid Search 召回了 20 个 Chunk最终可能只选 5 个进入 Prompt。这时 Rerank 可以帮助过滤掉只命中关键词但不回答问题的片段。语义相似但业务对象错误的片段。旧版本文档。重复内容。只包含背景但没有答案依据的片段。所以 Hybrid Search 和 Rerank 经常一起使用。可以理解为Hybrid Search 提升召回覆盖面 Rerank 提升最终上下文精度不过 Rerank 本身也有成本。如果候选太多Rerank 调用会变慢、变贵。所以前面的召回数量、过滤策略、去重策略仍然很重要。哪些场景必须重视精确匹配不是所有场景都必须上复杂 Hybrid Search。但下面这些场景一定要重视精确匹配。第一接口文档。接口路径、参数名、返回字段、错误码都需要准确命中。第二运维文档。配置项、命令、服务名、端口号、版本号都很关键。第三产品文档。产品型号、规格参数、功能版本、兼容性说明不能混淆。第四制度文档。不同制度、不同流程、不同部门规则可能很相似需要业务边界过滤。第五合同和合规文档。条款编号、责任主体、时间范围、适用条件都需要准确。第六知识库里存在大量缩写和内部代号。通用 Embedding 模型不一定知道这些词是什么意思。这些场景如果只靠向量检索很容易出现“看起来相似但实际错误”的召回结果。检索质量不要只靠调 TopK很多系统召回效果不好时会直接调大 TopK。比如从 Top5 改成 Top10从 Top10 改成 Top20。调大 TopK 有时有帮助。因为正确片段可能原本排在第 8 位Top5 看不到Top10 就能看到。但调大 TopK 不是根本方案。它也会带来问题更多无关内容进入候选集。Prompt 变长成本增加。模型更容易被干扰。Rerank 成本增加。引用来源更难判断。如果正确内容经常排得很靠后说明召回策略本身需要优化。可能是Query 没有改写。文档切分不合理。Embedding 模型不适合。关键词检索缺失。metadata filter 缺失。相似内容太多需要 Rerank。所以 TopK 是一个参数但不是万能开关。真正要提升检索质量需要回到召回链路设计。Query 处理也会影响检索质量检索质量不只取决于数据库和模型也取决于用户问题怎么进入系统。用户问题经常是口语化、模糊的。比如这个接口怎么传数量如果没有上下文系统不知道“这个接口”指哪个接口。再比如线上库那个备份规则是什么这里“线上库”可能对应“生产环境数据库”“备份规则”可能对应“备份策略”。Query 处理可以做几件事识别关键词。提取精确实体。补充同义词。结合上下文改写问题。拆分复杂问题。为不同检索器生成不同 Query。比如同一个用户问题可以生成两种检索输入向量检索 Query生产环境数据库备份策略是什么 关键词检索 Query生产环境 数据库 备份 策略对于错误码问题可以保留精确编号ERR_1024 认证失败这样 Hybrid Search 会更稳定。所以检索质量提升不只是后端数据库的事也包括 Query 层的处理。检索质量应该怎么评估不要只凭感觉判断检索质量。“看起来还行”很容易误导人。应该用真实问题集评估。可以准备一批问题每个问题标注期望召回的文档或 Chunk。比如问题试用期员工能不能申请年假 期望召回员工手册 请假制度 年假规则问题ERR_1024 是什么意思 期望召回错误码说明 ERR_1024问题v2.3.1 支持批量导入吗 期望召回版本发布说明 v2.3.1评估指标可以包括Top1 是否命中。Top3 是否命中。Top5 是否命中。是否召回了错误相似内容。是否漏掉必要上下文。最终答案是否准确。还可以按问题类型拆分评估语义类问题。编号类问题。接口类问题。表格类问题。制度流程类问题。版本类问题。这样才能知道系统到底在哪类问题上弱。如果语义类问题好但编号类问题差就应该补关键词检索。如果关键词命中好但答案仍然混乱可能需要 Rerank 或 Prompt 约束。如果同类流程混淆可能需要 metadata filter。评估要帮助你定位问题而不是只给一个模糊分数。一个实用的检索质量排查清单当用户反馈“搜不到”或“答错了”时可以按下面顺序排查。第一文档里是否真的有答案如果知识库本身没有内容检索再强也没用。第二文档是否解析成功PDF、表格、代码块、标题层级是否丢失。第三Chunk 是否合理答案依据是否被切散是否缺少标题和上下文。第四Embedding 是否能召回用用户原问题测试看正确 Chunk 是否进入 TopK。第五关键词检索是否能命中编号、参数、路径、版本号是否可以精确查到。第六是否需要 Hybrid Search如果问题类型混合单一路检索可能不够。第七metadata filter 是否正确权限、租户、版本、文档状态是否过滤正确。第八是否需要 Rerank候选内容太多或相似内容太多时重排序很重要。第九最终 Prompt 是否合理检索正确不代表生成正确模型仍然需要约束。第十是否记录了完整链路如果没有 query、召回结果、分数、过滤条件和最终上下文就很难排查。这份清单能帮助你把“答错了”拆成具体工程问题。总结RAG 检索质量提升不是简单换一个向量数据库也不是只把 TopK 调大。向量检索擅长语义相似但不擅长所有精确匹配问题。关键词检索在错误码、接口路径、参数名、产品型号、版本号等场景里仍然非常重要。Hybrid Search 的价值在于把向量检索和关键词检索结合起来同时提升语义召回和精确命中能力。但 Hybrid Search 不是简单拼接结果。多路召回之后还需要合并、去重、过滤、排序和 Rerank。真正可用的检索链路应该结合文档切分、Embedding、关键词检索、metadata filter、Rerank 和 Query 处理一起设计。最终检索质量要靠真实问题集评估而不是靠感觉判断。如果能把召回链路设计清楚RAG 系统会从“偶尔答对”逐渐变成“稳定找到依据”。下一篇文章可以继续讨论 Rerank。因为当召回结果越来越多时真正决定模型看到什么的往往就是重排序这一步。
RAG 检索质量怎么提升？从关键词到 Hybrid Search
发布时间：2026/7/15 1:38:31
前面几篇文章里我们已经讨论了 RAG 的基础链路、文档切分、Embedding 模型和向量数据库。到这里一个最小 RAG 系统已经可以跑起来了文档切分 ↓ Embedding 向量化 ↓ 写入向量数据库 ↓ 用户提问 ↓ 向量检索 ↓ 大模型生成答案这个流程看起来很完整。但很多系统真正进入使用后会遇到一个非常典型的问题文档明明在知识库里系统就是检索不到或者检索到的内容看起来相关但不能回答问题。这时候很多人第一反应是换 Embedding 模型、换向量数据库、调大 TopK。这些方法可能有帮助但不一定能解决根因。因为真实 RAG 检索质量的问题往往不是单一向量检索能完全覆盖的。尤其在企业文档、技术文档、产品文档、接口文档里很多问题并不是纯语义相似问题而是精确匹配、关键词命中、术语对齐、编号定位和业务过滤共同作用的问题。这篇文章就讨论一个核心问题RAG 检索质量应该怎么提升为什么很多系统需要从单一向量检索走向关键词检索和 Hybrid Search。为什么只靠向量检索不够向量检索很适合处理语义相似。比如用户问题还没转正能不能休年假 文档片段试用期员工年休假按入职时间折算。这里“还没转正”和“试用期”并不是完全一样的词但语义上接近。Embedding 模型如果效果不错就有机会把它们匹配到一起。再比如用户问题线上数据库多久备份一次 文档片段生产环境数据库每日凌晨执行全量备份。“线上数据库”和“生产环境数据库”也是近义表达。这类问题是向量检索擅长的。但真实知识库里还有很多问题并不适合只靠向量检索。比如ERR_1024 表示什么 POST /orders 的 quantity 参数怎么填 v2.3.1 是否支持批量导入 P-7003 这个产品型号的功耗是多少这些问题里错误码、接口路径、参数名、版本号、产品型号是关键。它们不是普通语义表达而是精确符号。如果只靠向量检索系统可能召回语义相似但编号错误的内容。比如用户问ERR_1024系统召回ERR_1025。从文本相似度上看它们很接近从业务上看它们完全不同。这就是单一向量检索的局限。向量检索擅长“相似”但很多业务问题需要“准确”。向量检索容易漏掉什么在实际项目里只靠向量检索容易漏掉几类内容。第一类是编号和代码。比如错误码、订单号、工单号、版本号、产品型号、接口路径。这些内容通常需要精确命中。第二类是短关键词。比如某个字段名、配置项、模块名、表名、函数名。短词在向量空间里信息量有限很容易被更长、更语义化的内容淹没。第三类是专有名词。比如内部系统名、项目代号、部门简称、产品缩写。通用 Embedding 模型不一定理解这些词。第四类是表格字段。比如用户问“最大并发数是多少”答案可能藏在参数表里。表格被切分和转换后如果字段名没有很好保留向量检索可能不稳定。第五类是相似业务流程。合同审批、采购审批、报销审批、立项审批都很像。向量检索可能把它们混在一起。第六类是版本和时间敏感内容。旧制度、新制度、旧接口、新接口在语义上可能很相似但真实答案应该来自最新版本。这些问题说明一个事实RAG 的检索不只是语义相似度问题。它还包括关键词命中、结构化过滤、版本选择、权限控制和业务边界判断。关键词检索解决什么问题关键词检索最典型的代表是 BM25。它和向量检索的思路不同。向量检索关注语义相似关键词检索关注词项匹配。比如用户问ERR_1024 是什么意思关键词检索会非常重视ERR_1024这个词是否出现在文档里。而向量检索可能认为ERR_1025、ERR_1042、错误码说明都很相似。在这种场景下关键词检索往往更可靠。关键词检索特别适合错误码。接口路径。参数名。配置项。产品型号。版本号。文件名。表名。精确术语。比如POST /orders tenant_id max_connections v2.3.1 P-7003这些内容不一定需要语义理解而是需要精确定位。所以在 RAG 系统里关键词检索不是过时技术。它仍然非常重要。尤其是技术文档和企业文档很多问题如果没有关键词检索召回质量会很不稳定。向量检索和关键词检索各自擅长什么可以简单对比一下。向量检索擅长同义表达。口语化问题。概念相似。长文本语义匹配。用户不知道准确关键词时的模糊查询。关键词检索擅长精确词命中。编号、代码、参数名。短文本查询。专有名词。字段、路径、版本号。举个例子。用户问还没转正能不能休年假文档里写试用期员工年休假按入职时间折算。这时向量检索更有优势。再看另一个问题ERR_1024 是什么意思文档里写ERR_1024用户认证失败请重新登录。这时关键词检索更有优势。所以不要把向量检索和关键词检索看成二选一。它们解决的是不同问题。真实系统里很多时候需要两者配合。Hybrid Search 是什么Hybrid Search 通常指混合检索。最常见的形式是向量检索 关键词检索也就是同一个用户问题同时走两条召回链路用户问题 ├─ 向量检索召回语义相似内容 └─ 关键词检索召回关键词命中内容 ↓ 合并结果 ↓ 去重和排序 ↓ 交给后续 Rerank 或生成模型Hybrid Search 的目标不是炫技而是把不同检索方式的优势组合起来。向量检索负责找“意思接近”的内容。关键词检索负责找“词命中准确”的内容。两者结合后系统对真实问题的覆盖面通常会更好。比如用户问v2.3.1 版本支持批量导入吗关键词检索可以确保v2.3.1被命中。向量检索可以找到“批量导入”“批量上传”“批处理导入”等语义相关内容。如果只靠其中一种都可能不够稳定。这就是 Hybrid Search 的价值。Hybrid Search 不是简单把结果拼起来很多人理解 Hybrid Search 时会以为它就是向量检索 TopK 关键词检索 TopK然后直接把结果全部塞给模型。这样做很容易出问题。因为多路召回之后会出现几个新问题。第一结果重复。同一个 Chunk 可能同时被向量检索和关键词检索召回。第二分数不可直接比较。向量相似度和 BM25 分数不是一个尺度不能简单放在一起排序。第三召回内容质量不一。关键词命中的内容可能只是出现了某个词但并不能回答问题。向量召回的内容可能语义相关但缺少精确条件。第四TopK 变多后上下文容易超长。如果两个检索器各召回 10 条合并后可能有 20 条候选内容不能全部无脑塞进 Prompt。所以 Hybrid Search 的关键不只是“多路召回”还包括合并。去重。分数归一化。初步过滤。重排序。上下文压缩。这些步骤决定了 Hybrid Search 是否真正有效。多路召回结果怎么合并一个简单的合并策略是取并集。比如向量检索返回 A、B、C、D、E 关键词检索返回 C、E、F、G、H 合并结果为 A、B、C、D、E、F、G、H然后按某种规则重新排序。这比只用一种检索方式覆盖更广。但真实系统里需要更细致地处理。可以考虑几个因素第一同一个 Chunk 被多路召回说明它可能更重要。如果一个片段同时被向量检索和关键词检索命中可以提高它的优先级。第二关键词命中精确标识符时应该提高权重。比如命中ERR_1024、POST /orders、tenant_id比命中普通词更重要。第三向量检索分数高但关键词不命中不一定要降权。因为用户问题可能是口语化表达关键词不一致很正常。第四重复内容要去掉。同一文档、同一段落、相邻高度重叠 Chunk都需要处理否则会浪费上下文。第五要考虑 metadata。版本、权限、租户、文档状态等过滤条件最好在检索阶段就参与而不是等生成阶段再处理。合并策略不是越复杂越好。早期可以先用简单规则然后通过真实问题集逐步调整。Rerank 在 Hybrid Search 后更重要多路召回之后候选内容会变多。这时 Rerank 的作用会更明显。Retriever 负责把可能相关的内容召回来。Rerank 负责在候选内容中进一步判断哪些更值得交给模型。比如 Hybrid Search 召回了 20 个 Chunk最终可能只选 5 个进入 Prompt。这时 Rerank 可以帮助过滤掉只命中关键词但不回答问题的片段。语义相似但业务对象错误的片段。旧版本文档。重复内容。只包含背景但没有答案依据的片段。所以 Hybrid Search 和 Rerank 经常一起使用。可以理解为Hybrid Search 提升召回覆盖面 Rerank 提升最终上下文精度不过 Rerank 本身也有成本。如果候选太多Rerank 调用会变慢、变贵。所以前面的召回数量、过滤策略、去重策略仍然很重要。哪些场景必须重视精确匹配不是所有场景都必须上复杂 Hybrid Search。但下面这些场景一定要重视精确匹配。第一接口文档。接口路径、参数名、返回字段、错误码都需要准确命中。第二运维文档。配置项、命令、服务名、端口号、版本号都很关键。第三产品文档。产品型号、规格参数、功能版本、兼容性说明不能混淆。第四制度文档。不同制度、不同流程、不同部门规则可能很相似需要业务边界过滤。第五合同和合规文档。条款编号、责任主体、时间范围、适用条件都需要准确。第六知识库里存在大量缩写和内部代号。通用 Embedding 模型不一定知道这些词是什么意思。这些场景如果只靠向量检索很容易出现“看起来相似但实际错误”的召回结果。检索质量不要只靠调 TopK很多系统召回效果不好时会直接调大 TopK。比如从 Top5 改成 Top10从 Top10 改成 Top20。调大 TopK 有时有帮助。因为正确片段可能原本排在第 8 位Top5 看不到Top10 就能看到。但调大 TopK 不是根本方案。它也会带来问题更多无关内容进入候选集。Prompt 变长成本增加。模型更容易被干扰。Rerank 成本增加。引用来源更难判断。如果正确内容经常排得很靠后说明召回策略本身需要优化。可能是Query 没有改写。文档切分不合理。Embedding 模型不适合。关键词检索缺失。metadata filter 缺失。相似内容太多需要 Rerank。所以 TopK 是一个参数但不是万能开关。真正要提升检索质量需要回到召回链路设计。Query 处理也会影响检索质量检索质量不只取决于数据库和模型也取决于用户问题怎么进入系统。用户问题经常是口语化、模糊的。比如这个接口怎么传数量如果没有上下文系统不知道“这个接口”指哪个接口。再比如线上库那个备份规则是什么这里“线上库”可能对应“生产环境数据库”“备份规则”可能对应“备份策略”。Query 处理可以做几件事识别关键词。提取精确实体。补充同义词。结合上下文改写问题。拆分复杂问题。为不同检索器生成不同 Query。比如同一个用户问题可以生成两种检索输入向量检索 Query生产环境数据库备份策略是什么 关键词检索 Query生产环境 数据库 备份 策略对于错误码问题可以保留精确编号ERR_1024 认证失败这样 Hybrid Search 会更稳定。所以检索质量提升不只是后端数据库的事也包括 Query 层的处理。检索质量应该怎么评估不要只凭感觉判断检索质量。“看起来还行”很容易误导人。应该用真实问题集评估。可以准备一批问题每个问题标注期望召回的文档或 Chunk。比如问题试用期员工能不能申请年假 期望召回员工手册 请假制度 年假规则问题ERR_1024 是什么意思 期望召回错误码说明 ERR_1024问题v2.3.1 支持批量导入吗 期望召回版本发布说明 v2.3.1评估指标可以包括Top1 是否命中。Top3 是否命中。Top5 是否命中。是否召回了错误相似内容。是否漏掉必要上下文。最终答案是否准确。还可以按问题类型拆分评估语义类问题。编号类问题。接口类问题。表格类问题。制度流程类问题。版本类问题。这样才能知道系统到底在哪类问题上弱。如果语义类问题好但编号类问题差就应该补关键词检索。如果关键词命中好但答案仍然混乱可能需要 Rerank 或 Prompt 约束。如果同类流程混淆可能需要 metadata filter。评估要帮助你定位问题而不是只给一个模糊分数。一个实用的检索质量排查清单当用户反馈“搜不到”或“答错了”时可以按下面顺序排查。第一文档里是否真的有答案如果知识库本身没有内容检索再强也没用。第二文档是否解析成功PDF、表格、代码块、标题层级是否丢失。第三Chunk 是否合理答案依据是否被切散是否缺少标题和上下文。第四Embedding 是否能召回用用户原问题测试看正确 Chunk 是否进入 TopK。第五关键词检索是否能命中编号、参数、路径、版本号是否可以精确查到。第六是否需要 Hybrid Search如果问题类型混合单一路检索可能不够。第七metadata filter 是否正确权限、租户、版本、文档状态是否过滤正确。第八是否需要 Rerank候选内容太多或相似内容太多时重排序很重要。第九最终 Prompt 是否合理检索正确不代表生成正确模型仍然需要约束。第十是否记录了完整链路如果没有 query、召回结果、分数、过滤条件和最终上下文就很难排查。这份清单能帮助你把“答错了”拆成具体工程问题。总结RAG 检索质量提升不是简单换一个向量数据库也不是只把 TopK 调大。向量检索擅长语义相似但不擅长所有精确匹配问题。关键词检索在错误码、接口路径、参数名、产品型号、版本号等场景里仍然非常重要。Hybrid Search 的价值在于把向量检索和关键词检索结合起来同时提升语义召回和精确命中能力。但 Hybrid Search 不是简单拼接结果。多路召回之后还需要合并、去重、过滤、排序和 Rerank。真正可用的检索链路应该结合文档切分、Embedding、关键词检索、metadata filter、Rerank 和 Query 处理一起设计。最终检索质量要靠真实问题集评估而不是靠感觉判断。如果能把召回链路设计清楚RAG 系统会从“偶尔答对”逐渐变成“稳定找到依据”。下一篇文章可以继续讨论 Rerank。因为当召回结果越来越多时真正决定模型看到什么的往往就是重排序这一步。
