两个简单技巧让RAG检索准确率从50%提升至95%

在聊完了 RAG 的 chunking、embedding、评估指标和流程之后，终于可以落地看看实际应用了。说实话，RAG 系统做得好不好，检索阶段往往就是那个决定生死的环节。整个工作流分为数据摄取和数据查询两步，而检索正是中间最关键的桥梁。今天分享的这个实战案例，团队只用了两个技巧，就把 RAG 的检索准确率从 50% 直接拉到了 95%。

1. 什么是 RAG 检索准确率？为什么它那么重要？

检索准确率，说白了就是看系统能把用户问题相关的所有文档找出来多少。这个指标在 RAG 里尤其关键，因为如果检索阶段连“原料”都凑不齐，后端的生成模型再厉害也巧妇难为无米之炊。检索准确率高，生成内容的相关性才有了保障。

计算公式如下：

举个例子：

• 用户想查“Helsinki 的瑞典式按摩”
• 数据库里实际有 10 条相关文档
• 检索系统翻出来 9 条对的，顺便夹带 1 条错的
• 那么准确率就是 9 / 10

2. 案例背景

这个案例的目标很明确：为客服团队搭建一个内部聊天机器人，让客服能快速查到所需信息。项目初始阶段包括从多个系统抓取数据、做预处理和分块、嵌入向量，最终在 Azure AI Search 里建索引，再把聊天机器人连上去。

数据主要涉及两类实体：服务场所（比如水疗中心、健身房）和服务专家（比如按摩师、私教）。处理方式是合并文本字段（描述、城市、地区）成一个内容字段，然后为向量搜索生成嵌入向量。

最初的搜索策略很简单：要么用向量搜索，要么用全文 BM25 搜索，直接在内容字段里捞。结果呢？系统只在 50%~60% 的情况下能准确命中目标文档。

向量搜索不好使，是因为它擅长模糊匹配和语义相似性，而我们这个场景需要的是精确匹配。BM25 也好不到哪去，它完全依赖关键词频率，结果是哪个文档里关键词出现的次数多，哪个排前面，根本不管是不是真的相关。更麻烦的是，碰上芬兰语这种曲折变化丰富的语言，词形稍微一变，BM25 就彻底失灵。

3. 初始方案的问题

当时系统走的是向量搜索加 BM25 混合路线，问题也很明显：

1. 向量搜索：看重语义相似，但在具体的服务名称或位置匹配上，根本做不到精准。
2. BM25 搜索：靠关键词频率说话，常常把高频但低相关的内容推上来。遇上芬兰语这样词形多变的语言，效果更差。

检索结果相关性不足，用户体验自然大打折扣。

4. 把准确率拉到 95% 的两个关键技巧

团队最后只靠两个改动就翻盘了，而且思路非常简洁：

技巧一：用 LLM 改写用户查询

• 解决方法：在查询阶段，让大模型把用户输入转成结构化查询。比如用户说“赫尔辛基 瑞典式按摩”，模型改写成：服务字段=“瑞典式按摩”，城市字段=“赫尔辛基”。
• 效果：精准改写直接提升了检索命中率，也彻底绕开了 BM25 靠词频打分的局限。
• 代价：实时改写会带来额外的性能开销，高并发时可能拉长响应时间。而且改写逻辑需要不断调整，维护成本不低。

技巧二：用 LLM 改进索引结构

• 解决方法：在索引阶段，直接让大模型从自由文本中提炼出结构化的服务列表，作为专门的索引字段。举个例子，原文描述“This spa offers Swedish massage and aromatherapy”，模型自动抽取出“Swedish massage”和“aromatherapy”。
• 处理噪声：预处理时专门清洗拼写错误、语言变体等问题，让模型抽取更稳定。
• 效果：索引信息更精确，向量搜索那种模糊匹配导致的错配问题也得到了解决。
• 代价：构建索引需要大量的计算资源，尤其数据规模一大，成本上升明显。而且动态服务信息要持续更新，维护压力不小。

5. 总结

这个案例带来的启示其实很朴素：

1. 检索才是 RAG 的真正命门：生成效果要想好，检索先得过硬。
2. 简单的方法往往最有效：用 LLM 改查询、改索引，两个动作都不复杂，却直接翻盘。
3. 成本要算，但收益更值得看：虽然增加了计算和维护成本，但用户体验的飞跃证明了一切都值。

高质量的检索不仅能给生成阶段打牢地基，也提醒我们：技术优化千万别为了追复杂而复杂，回应用户的真实需求才是真正的方向。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：两个简单技巧让RAG检索准确率从50%提升至95%要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题