学术界的秘密武器：RAG 知识库调优方案深度解析（第一部分）非常详细收藏我这一篇就够了

背景介绍

在之前的文章详细梳理过工业界的 RAG 方案 [QAnything] 和 [RagFlow]，这次主要整理下来自学术界的一系列 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] 机制那么立竿见影。后续会进一步调研其他可能的优化方案，欢迎关注。

如何学习AI大模型？

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

第一阶段： 从大模型系统设计入手，讲解大模型的主要方法；

第二阶段： 在通过大模型提示词工程从Prompts角度入手更好发挥模型的作用；

第三阶段： 大模型平台应用开发借助阿里云PAI平台构建电商领域虚拟试衣系统；

第四阶段： 大模型知识库应用开发以LangChain框架为例，构建物流行业咨询智能问答系统；

第五阶段： 大模型微调开发借助以大健康、新零售、新媒体领域构建适合当前领域大模型；

第六阶段： 以SD多模态大模型为主，搭建了文生图小程序案例；

第七阶段： 以大模型平台应用与开发为主，通过星火大模型，文心大模型等成熟大模型构建大模型行业应用。

👉学会后的收获：👈
• 基于大模型全栈工程实现（前端、后端、产品经理、设计、数据分析等），通过这门课可获得不同能力；

• 能够利用大模型解决相关实际项目需求： 大数据时代，越来越多的企业和机构需要处理海量数据，利用大模型技术可以更好地处理这些数据，提高数据分析和决策的准确性。因此，掌握大模型应用开发技能，可以让程序员更好地应对实际项目需求；

• 基于大模型和企业数据AI应用开发，实现大模型理论、掌握GPU算力、硬件、LangChain开发框架和项目实战技能， 学会Fine-tuning垂直训练大模型（数据准备、数据蒸馏、大模型部署）一站式掌握；

• 能够完成时下热门大模型垂直领域模型训练能力，提高程序员的编码能力： 大模型应用开发需要掌握机器学习算法、深度学习框架等技术，这些技术的掌握可以提高程序员的编码能力和分析能力，让程序员更加熟练地编写高质量的代码。

1.AI大模型学习路线图
2.100套AI大模型商业化落地方案
3.100集大模型视频教程
4.200本大模型PDF书籍
5.LLM面试题合集
6.AI产品经理资源合集

👉获取方式：
😝有需要的小伙伴，可以保存图片到wx扫描二v码免费领取【保证100%免费】🆓