12个RAG痛点和建议的解决方案

已于 2024-05-02 00:07:37 修改
阅读量2.6k 收藏 28
点赞数 26
文章标签： 人工智能 自然语言处理
于 2024-02-08 17:24:51 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/lichunericli/article/details/136078239
版权

解决检索增强生成的核心挑战

原文地址：archive.is/bNbZo

受Barnett等人的论文《设计检索增强生成系统时的七个故障点》的启发，让我们在本文中探讨论文中提到的七个失效点以及开发RAG管道时的五个额外常见痛点。更重要的是，我们将深入研究这些RAG痛点的解决方案，以便在日常RAG开发中更好地解决这些痛点。

我用“痛点”而不是“失败点”，主要是因为这些点都有相应的解决方案。让我们试着在它们成为RAG管道中的故障之前进行修复。

首先，让我们研究一下上述论文中提到的七个痛点；请参阅下图。然后，我们将添加另外五个痛点及其建议的解决方案。

痛点1：内容缺失

当实际答案不在知识库中时，RAG系统提供了一个看似合理但不正确的答案，而不是说它不知道。用户收到误导性信息，导致沮丧。

我们提出了两种解决方案：清理数据，更好的提示

  • 清理数据

垃圾进，垃圾出。如果你的源数据质量很差，比如包含冲突信息，无论你构建的RAG管道有多好，它都无法从你提供的垃圾中输出黄金。这个拟议的解决方案不仅适用于这个痛点，也适用于本文中列出的所有痛点。干净的数据是任何运行良好的RAG管道的先决条件。

  • 更好的提示

在由于知识库中缺乏信息而导致系统可能提供看似合理但不正确的答案的情况下，更好的提示会有很大帮助。通过用“如果你不确定答案，告诉我你不知道”等提示来指导系统，你鼓励模型承认其局限性，并更透明地传达不确定性。无法保证100%的准确性，但制作提示是清理数据后所能做的最大努力之一。

痛点2：错过排名靠前的文档

重要文档可能不会出现在系统检索组件返回的顶部结果中。忽略了正确的答案，导致系统无法提供准确的响应。该报暗示，“问题的答案在文档中，但排名不够高，无法返回给用户”。

我想到了两个建议的解决方案：chunk_size和similarity_top_k的超参数调整

chunk_size和similarity_top_k都是用于管理RAG模型中数据检索过程的效率和有效性的参数。调整这些参数可能会影响计算效率和检索信息质量之间的权衡。我们在上一篇文章《使用LlamaIndex自动进行超参数调整》中探讨了chunk_size和similarity_top_k的超参数调整细节。请参阅下面的示例代码片段。

param_tuner = ParamTuner(
    param_fn=objective_function_semantic_similarity,
    param_dict=param_dict,
    fixed_param_dict=fixed_param_dict,
    show_progress=True,
)

results = param_tuner.tune()

函数objective_function_semantic_eximality定义如下，param_dict包含参数chunk_size和top_k及其相应的建议值：

# contains the parameters that need to be tuned
param_dict = {"chunk_size": [256, 512, 1024], "top_k": [1, 2, 5]}

# contains parameters remaining fixed across all runs of the tuning process
fixed_param_dict = {
    "docs": documents,
    "eval_qs": eval_qs,
    "ref_response_strs": ref_response_strs,
}

def objective_function_semantic_similarity(params_dict):
    chunk_size = params_dict["chunk_size"]
    docs = params_dict["docs"]
    top_k = params_dict["top_k"]
    eval_qs = params_dict["eval_qs"]
    ref_response_strs = params_dict["ref_response_strs"]

    # build index
    index = _build_index(chunk_size, docs)

    # query engine
    query_engine = index.as_query_engine(similarity_top_k=top_k)

    # get predicted responses
    pred_response_objs = get_responses(
        eval_qs, query_engine, show_progress=True
    )

    # run evaluator
    eval_batch_runner = _get_eval_batch_runner_semantic_similarity()
    eval_results = eval_batch_runner.evaluate_responses(
        eval_qs, responses=pred_response_objs, reference=ref_response
最低0.47元/天 解锁文章
lichunericli
关注
『大模型笔记』RAG 系统开发中的12大痛点及解决方案
AI新视界
02-29 357
本文受到 Barnett 等人论文 《工程化检索增强生成系统时的七大挑战》 的启发，旨在探讨论文中的七个挑战及开发 RAG 系统时遇到的五个常见难题。更关键的是，我们将深入讨论这些难题的解决策略，帮助我们在日常开发中有效应对。
RAG 案框架（Qanything、RAGFlow、FastGPT、智谱RAG）对比
stephen147的博客
07-03 1万+
亮点在文档解析、切片、query改写及recall模型的微调。没有最好，在自己业务的数据上，能落地就是最好的～。1、Qanything rerank模块设计的最好。4、智谱RAG，在领域数据上微调训练最好。3、FastGPT 模块动态配置多。下面分别按照模块比较各框架的却别。2、RAGFlow 文档处理最好。亮点在：数据处理+index。亮点在：rerank。
一文详谈RAG优化方案与实践
weixin_45583158的博客
06-19 1402
导读RAG通过检索现有的大量知识，结合强大的生成模型，为复杂的问答、文本摘要和生成任务带来了全新的解决方案。本文详细的介绍了RAG遇到的挑战、通用范式、工程实践、优化实现策略等。一、RAG的背景介绍随着ChatGPT的兴起，大语言模型再次走进人们的视野，其在NLP领域表现出的语言识别、理解以及推理能力令人惊叹。越来越多的行业开始探索大语言模型的应用，比如政务、医疗、交通、导购等行业。通义系列、GP...
用通俗易懂的方式讲解：12 个大模型 RAG 痛点及解决方案
2301_78285120的博客
02-04 2415
我们探讨了开发RAG管道中的12个痛点（来自论文的7个和额外的5个），并为所有这些问题提供了相应的解决方案。
检索增强生成（RAG）有什么好的优化方案？
XiaoLiuLB的博客
10-02 1249
RAG（检索增强生成）是一种结合了信息检索和内容生成的技术，常用于提升人工智能回答问题的准确性和相关性。本文将RAG的优化分为两个主要方向进行介绍：基础功能优化和架构优化。
一文详谈RAG优化方案与实践，大模型必备干货！
2401_85373691的博客
01-24 656
随着ChatGPT的兴起，大语言模型再次走进人们的视野，其在NLP领域表现出的语言识别、理解以及推理能力令人惊叹。越来越多的行业开始探索大语言模型的应用，比如政务、医疗、交通、导购等行业。通义系列、GPT系列、LLama系列等模型，在语言交互场景下表现十分抢眼。以Gemini为代表这类大模型甚至发展出了视觉和听觉，朝着智能体的方向演化。他们在多个指标上展现的能力甚至已经超过了人类。
23-大模型（LLMs）RAG —— 关键痛点及对应解决方案.pdf
12-31
本文将针对这些问题及其解决方案进行详细探讨，以便在日常RAG开发过程中能够更好地应对相应的挑战。 首先，内容缺失问题是RAG系统面临的一个重大问题。当实际答案不存在于知识库中时，RAG系统倾向于提供一个看似...
RAG 开发四大痛点及解决方案
Meimei9411的博客
07-31 916
收录了52个优秀的大模型落地应用案例，这些案例覆盖了金融、医疗、教育、交通、制造等众多领域，无论是对于大模型技术的研究者，还是对于希望了解大模型技术在实际业务中如何应用的业内人士，都具有很高的参考价值。在最初的 RAG 方法中，比较类型的问题表现尤为不佳。观看零基础学习书籍和视频，看书籍和视频学习是最快捷也是最有效果的方式，跟着视频中老师的思路，从基础到深入，还是很容易入门的。光学理论是没用的，要学会跟着一起做，要动手实操，才能将自己的所学运用到实际当中去，这时候可以搞点实战案例来学习。
14-48 剑和诗人22 - RAG 的主要痛点和解决方案
ms44的专栏
07-08 1329
​​​​​检索增强生成 (RAG) 模型已成为一种有前途的方法，它利用存储在文档中的外部知识来提高生成文本的准确性和相关性。通过检索和调节相关的上下文文档，与传统语言模型相比，RAG 模型可以产生更真实、更深入和更具体的响应。然而，与任何新技术一样，RAG 模型也面临着一系列挑战，需要解决这些挑战才能充分发挥其潜力。在这篇博文中，我将深入探讨 RAG 模型的主要痛点，并探索这些问题的潜在解决方案。具体来说，重点关注检索、条件、忠诚度和安全性等领域出现的核心困难。
大模型RAG优化方案与实践（非常详细）从入门到精通，看这一篇就够了
玩赚AI大模型的博客
07-17 4147
RAG通过检索现有的大量知识，结合强大的生成模型，为复杂的问答、文本摘要和生成任务带来了全新的解决方案。本文详细的介绍了RAG遇到的挑战、通用范式、工程实践、优化实现策略等。一、RAG的背景介绍随着ChatGPT的兴起，大语言模型再次走进人们的视野，其在NLP领域表现出的语言识别、理解以及推理能力令人惊叹。越来越多的行业开始探索大语言模型的应用，比如政务、医疗、交通、导购等行业。通义系列、GPT系列、LLama系列等模型，在语言交互场景下表现十分抢眼。
一文详谈20多种RAG优化方法
m0_59164304的博客
07-08 2583
以上这些方法就是针对基础RAG在各个环节的优化方法，在实际开发过程中并不是所有方法都是有效的，不同问题有不同的解决方案，针对应用场景选择合适的优化方法组合才能最大限度发挥RAG的作用。
高级检索增强生成技术(RAG)全面指南：原理、分块、编码、索引、微调、Agent、展望
人工智能讲师分享前沿技术
04-27 6913
如果我们使用多个源来生成答案，要么是由于初始查询的复杂性（我们必须执行多个子查询，然后将检索到的上下文合并到一个答案中），要么是因为我们在各种文档中找到了单个查询的相关上下文，问题是我们是否能够准确地回溯我们的来源。显然，尽管OpenAI是LLM提供商的市场领导者，但仍有许多替代方案，例如Anthropic的Claude、最近流行的较小但功能强大的模型，例如Mixtral形式的Mistral、Microsoft的Phi-2以及许多开源选项，例如Llama2、OpenLLaMA、Falcon。
12个RAG痛点和建议解决方案
myboyliu2007的专栏
02-04 2210
Neutrino 目前支持。此外，您可以微调自定义的重新排序器，以获得更好的检索性能，详细的实现已在《通过与LlamaIndex微调Cohere Reranker来改善检索性能》中记录。准确解释用户查询以检索相关的结构化数据可能会很困难，特别是对于复杂或含糊不清的查询、不灵活的文本到SQL转换以及当前LLMs在有效处理这些任务方面的限制。在使用 LLMs 时，您可能会想知道，如果您的模型遇到问题，比如与OpenAI的模型发生速率限制错误，您需要一个备用模型作为主要模型发生故障的替代方案。
6个RAG进阶优化方案,对应14篇论文案例解析
python1222_的博客
10-24 2158
本文对近几月我了解到的RAG优化策略进行总结, 每个优化策略都有相应的研究论文作为支撑。在01先总结优化方向, 02细化说明相应论文在介绍RAG优化策略之前, 先说说知识库数据处理:增强数据粒度：旨在提升文本标准化、一致性、事实准确性和丰富的上下文，以提高 RAG 系统的性能。比如删除不相关的信息、消除实体和数据中的歧义、更新过时文档等。添加元数据：将引用的元数据（如日期和用途）集成到块中以进行过滤，并合并元数据以提高检索效率。
大模型RAG：文档分块方案与RAG全流程
qingkahui24689的博客
10-08 2288
我们知道，大模型在预训练阶段获取的知识是有限的，一般需要数据增强模块引入外部知识库，通过知识检索的方式搜索于用户提问相关的知识，这也是RAG相关应用架构出现的原因。但这又引申出另一个问题，外部知识文档往往比较长，可能是包含几十页甚至数百页的内容，如果直接使用会存在以下问题：大模型在预训练过程都有上下文长度限制，如果超过长度限制大模型会将超出部分丢弃，从而影响回答的性能表现。
这是我见过的大模型 RAG 优化方案与实践最全总结了
2401_84033492的博客
06-29 4206
随着ChatGPT的兴起，大语言模型再次走进人们的视野，其在NLP领域表现出的语言识别、理解以及推理能力令人惊叹。越来越多的行业开始探索大语言模型的应用，比如政务、医疗、交通、导购等行业。通义系列、GPT系列、LLama系列等模型，在语言交互场景下表现十分抢眼。以Gemini为代表这类大模型甚至发展出了视觉和听觉，朝着智能体的方向演化。他们在多个指标上展现的能力甚至已经超过了人类。
不用苦苦寻觅！这是大模型检索增强生成（RAG）最全综述！
热门推荐
机器学习社区
02-03 1万+
是什么：RAG 是一种通过检索外部知识库来获得额外语料，并使用 ICL（In-Context-Learning，上下文学习）来改进 LLM 生成效果的范式。为什么：LLM 受训练语料的限制，无法感知最新的内容，比如 LLM 训练后的新闻；此外，LLM 也容易产生幻觉，生成不正确的内容。如何做：当用户发起一个生成请求时，首先基于用户的 prompt 来检索相关信息，然后这些信息会被组合到 prompt 中，为生成过程提供额外的上下文，最后将组合后的 prompt 输入 LLM 生成结果。
RAG的12种调优策略
python1234_的博客
06-11 2875
随着越来越多的开发人员在创建RAG流程的原型方面积累经验，讨论如何使RAG流程达到投入生产所需的性能变得更为重要。本文主要阐述了以下调优点：
微软：RAG并不是你唯一的解决方案！
m0_59164304的博客
09-25 1239
微软亚洲研究院（MSRA）提出了一种。
端侧RAG
最新发布
04-24
<think>好的，我现在需要回答用户关于端侧RAG的实现方案和技术原理的问题。首先，我需要回顾一下用户提供的引用内容，确保答案准确并符合要求。用户提到了三种RAG类型：Naive RAG、Advanced RAG和Modular RAG，还提到了12个RAG痛点及解决方案。不过用户现在的问题是询问端侧RAG，也就是在终端设备上运行的RAG技术，这可能涉及到资源受限的环境，比如手机、IoT设备等。 首先，我需要明确端侧RAG的定义和特点。端侧通常指终端设备，与云端相对，因此端侧RAG需要在本地设备上完成检索和生成，无需依赖云服务器。这可能带来隐私保护、低延迟、离线可用等优势，但也面临计算资源、存储空间和能耗的限制。 接下来，我需要思考端侧RAG的技术原理。根据引用中的RAG基本步骤，包括索引、检索和生成。但在端侧，这些步骤需要适应本地环境。可能的实现方式包括轻量化的模型、优化的索引结构、本地数据库的使用等。例如，使用小型语言模型（如TinyLLM）或对模型进行剪枝、量化，以减少计算量和内存占用。索引方面，可能需要更高效的向量检索方法，比如使用本地向量数据库，如SQLite结合FAISS的轻量级版本。 然后，关于实现方案，可能需要分步骤说明。首先是数据处理和索引构建，考虑到端侧存储有限，数据需要高度压缩和分块。然后是检索过程的优化，比如使用近似最近邻算法（ANN）来提高检索速度，减少计算资源消耗。生成阶段则需要部署轻量级生成模型，或者采用模型蒸馏技术，将大模型的知识迁移到小模型中。此外，可能需要提到如何与设备硬件结合，比如利用移动设备的GPU或NPU加速推理。 同时，需要参考用户提供的引用内容。例如，Advanced RAG中的优化步骤，如数据清洗、元数据添加，可能在端侧同样适用，但需要更高效的实现。Modular RAG中的模块化设计可以让端侧RAG根据需要选择功能模块，减少不必要的计算。此外，解决RAG痛点的方案，如处理上下文长度限制或检索效率问题，在端侧可能需要特别的处理，比如上下文压缩或更高效的重排序机制。 还需要考虑用户可能的深层需求，比如隐私保护的具体实现方法，如何在本地处理数据而不上传到云端，以及如何在资源受限的环境下保持性能。此外，可能需要比较端侧RAG与云端RAG的优缺点，帮助用户理解适用场景。 最后，生成相关问题时要围绕端侧RAG的挑战、优化方法、应用场景、与云端的差异等方面提问，确保问题有针对性，能够引导用户进一步探索。 总结一下，回答结构应包括技术原理和实现方案两部分，结合引用中的RAG类型和优化方法，同时突出端侧的特点和解决方案。需要确保使用正确的中文和LaTeX格式，按照用户的要求添加引用标识，并生成相关问题。</think>### 端侧 RAG 技术原理与实现方案 #### **技术原理** 端侧 RAG（Retrieval-Augmented Generation）是将检索增强生成技术部署在终端设备（如手机、IoT设备）上的方案，其核心目标是**在本地完成知识检索与生成任务**，无需依赖云端服务器，从而实现**低延迟、隐私保护**和**离线可用性**[^1]。其技术原理分为以下关键环节： 1. **轻量化模型架构** 端侧需使用轻量级语言模型（如 TinyLLM、MobileBERT）和向量编码模型，通过**模型剪枝**、**量化**（如 8-bit/4-bit 压缩）和**知识蒸馏**降低计算量与存储需求。例如，生成模型参数量可压缩至百兆级别，同时保持语义理解能力[^2]。 2. **本地化索引与检索** - **索引构建**：将知识库分割为短文本块（Chunk），并转换为轻量级向量索引（如使用量化版 FAISS 或 SQLite 嵌入式数据库）。 - **检索优化**：采用**近似最近邻搜索（ANN）**算法（如 HNSW）加速检索，并通过元数据过滤（如标签、时间戳）缩小搜索范围。 3. **资源约束下的生成** 在生成阶段，通过**动态上下文窗口**控制输入长度，结合**注意力机制剪枝**减少内存占用。例如，仅保留与检索结果相关性最高的上下文片段。 #### **实现方案** 1. **端到端流程设计** ```plaintext 用户输入 → 本地向量编码 → 检索本地索引 → 上下文筛选 → 生成回答 ``` 2. **关键技术组件** - **轻量级向量数据库**：使用 SQLite + FAISS-Lite 实现嵌入式存储与检索，索引文件大小控制在 100MB 以内。 - **混合检索策略**：结合关键词匹配（BM25）与语义检索（向量相似度），提升召回率。 - **上下文压缩**：利用小型语言模型（如 DistilBERT）对检索结果摘要，减少生成阶段的输入长度。 3. **性能优化示例** 在 Android 设备上部署端侧 RAG 时，可通过以下公式估算资源消耗： $$ \text{内存占用} = \text{模型参数} \times \text{量化位数} + \text{索引大小} $$ 假设使用 4-bit 量化的 200MB 模型和 50MB 索引，总内存需求可控制在 250MB 以内。 #### **挑战与解决建议** | 挑战 | 解决方案 | |---------------------|------------------------------| | 设备算力有限 | 使用 NPU/GPU 加速推理 | | 存储空间不足 | 动态加载分片索引 | | 长文本处理效率低 | 滑动窗口分块检索 | ---
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值