首页 > 其他分享 >来自学术界的知识库 RAG 调优方案实践(一)

来自学术界的知识库 RAG 调优方案实践(一)

时间:2024-05-28 18:58:04浏览次数:18  
标签:检索 RAG self 知识库 调优 HyDE 原始 模型

背景介绍

在之前的文章详细梳理过工业界的 RAG 方案 QAnythingRagFlow,这次主要整理下来自学术界的一系列 RAG 优化方案。

主要关注优化方案对应的设计思想以及相关的实现,希望可以对大家的 RAG 服务效果提升有所帮助。

基础介绍

在综述论文 Retrieval-Augmented Generation for Large Language Models: A Survey 介绍了三种不同的 RAG 架构:

请添加图片描述

  1. Native RAG: 原始 RAG 架构,对应最原始的 RAG 流程,和之前 搭建离线私有大模型知识库 介绍的流程基本一致;
  2. Advanced RAG:高级 RAG 架构,在原始 RAG 上增加了一些优化手段,之前实践过的 RAG Rerank 优化手段就属于高级 RAG 中的 Post-Retrieval (检索后的优化);
  3. Modular RAG:模块化 RAG 架构,通过模块化的架构设计,可以提供灵活的功能组合,方便实现功能强大的 RAG 服务。

本篇文章主要实践的还是高级 RAG 架构中的优化手段,涉及的时是之前较少涉及的 Pre-Retrieval(检索前的优化),目前有大量相关论文的研究,目前主要选择其中几种有代表性的方案进行实践,所有的实现都是基于 langchain 完成的。

优化方案

HyDE

HyDE 的优化手段来自于论文 Precise Zero-Shot Dense Retrieval without Relevance Labels,主要流程如下所示:
请添加图片描述

用户原始的问题与需要检索文档的向量相似度上不接近,因此向量检索效果不佳。因此 HyDE 的设计思想如下:

  1. 根据原始问题使用大模型生成假设文档,可以理解为使用大模型先给出答案,此答案中可能存在幻觉;
  2. 基于生成的假设文档进行向量检索;

为什么假设文档检索的效果会好于通过问题检索呢?我直观理解下来就是与大模型的答案语义上接近的更有可能是所需的答案,而且大模型是通过大量原始文档学习出来,因此生成的假设文档与原始文档上更接近,因此更易于检索。

实现方案

HyDE 的实现在 langchain 已经支持了,可以通过 from langchain.chains import hyde 进行使用,提供的是一个向量化查询的转换支持,可以看到其中最核心的方法如下所示:

def embed_query(self, text: str) -> List[float]:
    """Generate a hypothetical document and embedded it."""
    # 通过大模型生成文本对应的响应

    var_name = self.llm_chain.input_keys[0]
    result = self.llm_chain.generate([{var_name: text}])
    documents = [generation.text for generation in result.generations[0]]
    # 文档向量化

    embeddings = self.embed_documents(documents)
    return self.combine_embeddings(embeddings)

熟悉 langchain 的研发同学应该都了解这个方法的用途,主要是用于将原始文本向量化,方便进行后续的向量检索。

常规的文本向量化是直接调用下面的 self.embed_documents() 将原始查询 text 向量化。但是在 HyDE 中会增加一个大模型生成回答的流程 self.llm_chain.generate([{var_name: text}]),接下来将大模型的回答向量化,并使用此向量进行检索。

接下来可以看看 HyDE 中使用 prompt,这部分可以在 from langchain.chains.hyde import prompts 中看到,看起来是根据不同场景设计了不同的 prompt。我们以 web_search 为例,对应的应该是文本搜索的场景,prompt 如下所示:

from langchain_core.prompts.prompt import PromptTemplate

web_search_template = """Please write a passage to answer the question
Question: {QUESTION}
Passage:"""
web_search = PromptTemplate(template=web_search_template, input_variables=["QUESTION"])

可以看到 prompt 也相对简单容易理解。

实践效果

理想很丰满,实践下来发现 HyDE 实际效果不佳,实际测试中大模型给出的响应与原始知识库中的文档表达形式并不接近,导致最终测试时原始 query 可以检索到部分相关文档,使用大模型给出的回答进行检索则完全检索不到任何内容。

目前来看,HyDE 在大模型可以给出与文档类似的表达形式的内容时可能会有一些效果。预期对大模型的选型和使用场景上都有明显要求,使用不当可能会导致效果更差。

Rewrite-Retrieve-Read

Rewrite-Retrieve-Read 的想法来自于 Query Rewriting for Retrieval-Augmented Large Language Models
,对应的流程如下所示:
请添加图片描述
此方法的主要思想是用户的原始问题检索效果不佳,通过大模型进行重写提升问题对应的检索能力。

有实际上线 RAG 服务的应该有类似的遭遇,用户的问题都是千奇百怪的,确实存在原始问题检索效果不佳的情况,Rewrite-Retrieve-Read 就是基于大模型提供的能力进行了重写。

实现方案

Rewrite-Retrieve-Read 的实现方案相对简单,使用大模型直接重写问题,对应的实现可以参考 langchain template

核心的功能如下所示:

template = """Provide a better search query for \
web search engine to answer the given question, end \
the queries with ’**’. Question: \
{x} Answer:"""
rewrite_prompt = ChatPromptTemplate.from_template(template)

def _parse(text):
    return text.strip("**")

rewriter = rewrite_prompt | ChatOpenAI(temperature=0) | StrOutputParser() | _parse

可以看到 langchain 中设计了一个特殊的 prompt 进行了原始问题的转换,思路相对简单。

实践效果

最终实际测试下来,效果不是特别问题,部分问题转换后的效果更好,部分效果更差,从目前来看,与大模型本身的能力存在较大关系。

Query2Doc

Query2Doc 的想法来自于 Query2doc: Query Expansion with Large Language Models,是在 HyDE 的想法上进行了一些提升。

原始的 HyDE 是使用大模型生成的答案(Hypothetical Document)进行检索,而 Query2Doc 则会将生成的答案与原始问题进行拼接,之后使用拼接得到的内容进行检索。

针对不同的检索方案拼接方案有所差异,其中稀疏检索的中的拼接方案如下所示:

请添加图片描述
其中的 q 为原始问题,d 为生成的回答,可以看到 q 会被重复 n 次,并与 d 拼接起来。

而密集检索的拼接方案如下所示:

请添加图片描述
可以看到是直接将原始问题 q 与大模型生成的回答 d 进行了拼接,中间使用分隔符 [SEP] 进行了分隔。

实现方案

可以参考 HyDE 进行简单调整即可实现 Query2Doc,简单的示例如下所示:

def embed_query(self, text: str) -> List[float]:
    """Generate a hypothetical document and embedded it."""
    # 通过大模型生成文本对应的响应

    var_name = self.llm_chain.input_keys[0]
    result = self.llm_chain.generate([{var_name: text}])
    documents = [generation.text for generation in result.generations[0]]
    # 拼接原始查询与生成的响应,使用空格作为分隔符 SEP

    documents = [f"{text} {doc}" for doc in documents]
    # 文档向量化

    embeddings = self.embed_documents(documents)
    return self.combine_embeddings(embeddings)

实践效果

实际测试下来,相对原始的 HyDE 方案效果更好,但是实际效果改善不明显。

总结

本次测试了目前比较常规的几种 Pre-Retrieval 优化手段,从目前来看,优化思想都相对容易理解,都是在尝试利用大模型提供的能力优化了原始 query 难以检索的问题。

但是实际测试下来,改善效果相对有限,不如之前测试过的 Rerank 机制那么立竿见影。后续会进一步调研其他可能的优化方案,欢迎关注。

标签:检索,RAG,self,知识库,调优,HyDE,原始,模型
From: https://blog.csdn.net/hustyichi/article/details/139273532

相关文章

  • 请描述一下 cookies sessionStorage和localstorage区别
    Cookies、sessionStorage和localStorage都是Web浏览器提供的客户端存储机制,但它们之间有一些重要的区别:存储容量:Cookies最大容量约为4KB。sessionStorage和localStorage的容量都约为5MB。有效期:Cookies有明确的过期时间,可以设置为在浏览......
  • Fine-tuning in LLaVA:多模态的指令调优
    1Prerequisites1.1TrainingMethods训练方法通常分为三种:提示工程、微调和预训练。1.1.1PromptEngineering不需要重新训练模型,节省成本。1.1.2Fine-tuning微调和预训练的代码基本相同,但是计算量相对小很多。1.1.3Pre-training大规模数据集上训练,得到的是一个未加调......
  • JVM调优维护常用工具之Jconsole 监控管理
    Jconsole(JavaMonitoringandManagementConsole)是JDK中自带的java监控和管理控制台,用于对JVM中内存、线程和类等的监控,是一个基于JMX(javamanagementextensions)的GUI性能监测工具。jconsole使用jvm的扩展机制(接口、抽象类、反射、DubboSPI机制之一JDK中的SPI等)获取......
  • 【wiki知识库】02.wiki知识库SpringBoot后端的准备
      ......
  • Activity与Fragment之间通信(二)——接口回调
    一。引言上篇文章讲述了Activity和Fragment怎么样通过Bundle传递消息,这篇介绍如何通过接口回调实现通信。首先,Bundle并不适用于任何通信情况,我们来看看Bundle通信的缺点:(1)数据类型的限制:Bundle只能传递一些基本数据类型,如int,String等,无法直接传递自定义对象。(2)繁琐的代码:在......
  • RAG-GPT实践过程中遇到的挑战
    引言大型语言模型(LLM)的新进展,包括ChatGPT,为AI应用提供了新的能力,使其能够构建新的人机交互解决方案、完成复杂任务、总结文档、回答文献中的问题并生成新内容。然而,LLM在获取最新知识或企业内部知识库中的领域特定知识时仍存在局限性。解决此问题的两个选项是:微调LLM(继......
  • # 使用RAG-GPT集成智谱AI、DeepSeek快速搭建OpenAI Cookbook智能客服
    引言前面介绍了使用RAG-GPT和OpenAI快速搭建LangChain官网智能客服,目前国内也有一些比较不错的云端大模型API服务。本文将介绍通过RAG-GPT集成智谱AI和DeepSeek,快速搭建OpenAICookbook智能客服。RAG技术原理介绍在介绍RAG-GPT项目之前,我们首先要理解RAG的基本原理,RAG在问答系......
  • 使用 Spring Cloud Alibaba AI 构建 RAG 应用
    作者:姬世文背景介绍RAG(RetrievalAugmentedGeneration)检索增强生成(RAG)是一种用于将数据与人工智能模型集成的技术。在RAG工作流程中,第一步将文档数据加载到矢量数据库(例如Redis)中。当收到用户查询时,矢量数据库会检索一组与该查询相似的文档。然后,这些文档数据充当用户问题......
  • Keras深度学习框架第二十八讲:可视化超参数调优过程
    1、绪论可视化超参数调优过程(Visualizethehyperparametertuningprocess)指的是在机器学习或深度学习的模型训练中,通过图形化或可视化的方式展示和调整模型的超参数(hyperparameters)。这个过程有助于用户直观地理解超参数如何影响模型的性能,从而找到最优的超参数设置。可......
  • Nodejs 在实战中的校验用户信息(JWT、localStorage、Cookie)
    本文分别站在了客户端(reactjs)与服务端(nodejs)的角度,总结了整个用户校验过程各自的操作。一概念明晰1.1localStorage和Cookie都是存储数据的方式localStorage:储存在客户端(浏览器)本地Cookie:存储在服务端,安全性更高。(是一个HTTP请求标头,由服务器通过 Set-Cookie 设置,......