在聊完了 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 混合路线，问题也很明显：
- 向量搜索：看重语义相似，但在具体的服务名称或位置匹配上，根本做不到精准。
- BM25 搜索：靠关键词频率说话，常常把高频但低相关的内容推上来。遇上芬兰语这样词形多变的语言，效果更差。
检索结果相关性不足，用户体验自然大打折扣。
4. 把准确率拉到 95% 的两个关键技巧
团队最后只靠两个改动就翻盘了，而且思路非常简洁：
技巧一：用 LLM 改写用户查询
- 解决方法：在查询阶段，让大模型把用户输入转成结构化查询。比如用户说“赫尔辛基 瑞典式按摩”，模型改写成：服务字段=“瑞典式按摩”，城市字段=“赫尔辛基”。
- 效果：精准改写直接提升了检索命中率，也彻底绕开了 BM25 靠词频打分的局限。
- 代价：实时改写会带来额外的性能开销，高并发时可能拉长响应时间。而且改写逻辑需要不断调整，维护成本不低。
技巧二：用 LLM 改进索引结构
- 解决方法：在索引阶段，直接让大模型从自由文本中提炼出结构化的服务列表，作为专门的索引字段。举个例子，原文描述“This spa offers Swedish massage and aromatherapy”，模型自动抽取出“Swedish massage”和“aromatherapy”。
- 处理噪声：预处理时专门清洗拼写错误、语言变体等问题，让模型抽取更稳定。
- 效果：索引信息更精确，向量搜索那种模糊匹配导致的错配问题也得到了解决。
- 代价：构建索引需要大量的计算资源，尤其数据规模一大，成本上升明显。而且动态服务信息要持续更新，维护压力不小。
5. 总结
这个案例带来的启示其实很朴素：
- 检索才是 RAG 的真正命门：生成效果要想好，检索先得过硬。
- 简单的方法往往最有效：用 LLM 改查询、改索引，两个动作都不复杂，却直接翻盘。
- 成本要算，但收益更值得看：虽然增加了计算和维护成本，但用户体验的飞跃证明了一切都值。
高质量的检索不仅能给生成阶段打牢地基，也提醒我们：技术优化千万别为了追复杂而复杂，回应用户的真实需求才是真正的方向。