【2025版】如何提高RAG 检索准确率，从零基础到精通，精通收藏这篇就够了！

leah126

已于 2025-03-05 11:53:44 修改

阅读量882

点赞数 4

CC 4.0 BY-SA版权

分类专栏：大模型人工智能程序员文章标签：人工智能程序员大模型网络 AI大模型 RAG

于 2025-03-04 10:48:21 首次发布

本文链接：https://blog.youkuaiyun.com/leah126/article/details/146008754

程序员同时被 3 个专栏收录

1469 篇文章

订阅专栏

大模型

408 篇文章

订阅专栏

人工智能

331 篇文章

订阅专栏

在讨论了 RAG 的 chunking、embedding、评估指标、评估流程等技术后，我们进一步探讨 RAG 系统的实际应用。在实际项目中，RAG（Retrieval-Augmented Generation）系统的检索阶段往往是影响生成效果的核心环节。RAG 系统的工作流程包括数据摄取（Data Ingestion）和数据查询（Data Querying），其中检索是至关重要的一步。本文介绍了在一个案例中，团队如何通过2个关键技巧把 RAG 检索准确率从 50% 提高到 95 %

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

RAG 检索准确率（Recall）是衡量检索系统能否找到与用户查询相关的所有文档的指标。它在 RAG 系统中尤为重要，因为如果检索阶段无法提供足够的上下文，即使生成模型再强大，也难以输出高质量结果。高检索准确率是确保生成内容相关性的基础。

检索准确率（Recall）公式如下：

示例：

用户查询 “Swedish massage in Helsinki”。
数据库中有 10 条相关文档，检索系统返回 9 条相关文档和 1 条不相关文档。
检索准确率计算：

2. 案例背景

在这个案例中，我们通过两个关键改进，使系统的检索准确率从 50-60% 提升至 95% 以上。此项目的背景是为客户服务团队构建一个内部聊天机器人，以帮助客服人员更快地访问信息。

项目初始阶段包括：

从各种系统中获取数据。
预处理、chunking 和 embedding 数据。
在 Azure AI Search 中构建搜索索引。
将聊天机器人连接到搜索索引。

数据包括有关地点（如水疗中心和健身房）和专家（如按摩治疗师和私人教练）的信息。数据通过将文本字段（描述、城市、地区）合并为一个内容字段，并为向量搜索创建 embeddings 来准备。

最初的搜索查询要么作为向量搜索，要么作为全文 BM25 搜索对内容字段运行。然而，系统仅在 50-60% 的时间内检索到正确的文档。

向量搜索不适合这个应用，因为它优先考虑模糊匹配和语义相似性，而我们的应用需要精确匹配。BM25 搜索也不够，因为它基于术语频率，导致包含更多匹配查询术语的文档优先显示，而不是匹配相关术语的文档。BM25 还存在芬兰语词形变化的问题，稍微的词形变化会阻止文档检索。

3. 初始方案的问题

系统采用了向量搜索 和BM25 全文搜索 的组合，然而：

向量搜索：基于语义相似性，但无法精确匹配具体的服务或位置。
BM25 搜索：依赖关键字频率，但会优先返回包含高频关键词但相关性低的文档。对于芬兰语等具有词形变化的语言，BM25 的效果进一步降低。

这些问题导致检索结果相关性不足，严重影响了用户体验。

4. 检索准确率从 50-60% 提升至 95% 的两个技巧

通过以下两项关键改进，系统的检索准确率得以显著提升：

1.利用 LLM 改写用户查询

解决方案：在查询阶段，借助 LLM 将用户输入改写为结构化查询。例如，将 “Swedish massage in Helsinki” 改写为服务字段包含 “Swedish massage” 且城市字段为 “Helsinki” 的查询。
实际效果：精准的查询改写显著提高了检索相关性，减少了 BM25 依赖于关键词频率的问题。
成本与问题：
性能开销：查询改写需要实时处理，在高并发场景中可能增加响应时间。
维护复杂度：需持续优化查询改写逻辑，以适应不断变化的用户需求。

2.利用 LLM 改进索引

解决方案：在索引阶段，使用大语言模型（LLM）从自由文本中提取服务信息，生成结构化服务列表作为索引字段。例如，从描述 “This spa offers Swedish massage and aromatherapy” 中提取 “Swedish massage” 和 “aromatherapy”。
处理非标准化输入：预处理步骤清洗拼写错误、语言变体等噪声，提升模型一致性。
实际效果：索引信息更加精确，解决了向量搜索中模糊匹配导致的相关性不足问题。
成本与问题：
计算成本：索引构建需要显著的计算资源，特别是在大规模数据场景中。
维护复杂度：动态服务信息需要持续更新，确保索引的准确性和实用性。