最近在思考如何更好的使用 LLMs，一个核心是 LLMs 如何理解用户的需求。不断的琢磨，也看到了不少同样的思考。今天分享出来，大多来自 langchain 的博客翻译，但这些内容也不够，想来不会比搜索引擎的 Query Expansion 简单。

正文

朴素的RAG通常将文档分成块，嵌入它们，并检索与用户问题具有高语义相似性的块。但是，这会带来一些问题：（1）文档块可能包含降低检索效果的无关内容，（2）用户问题可能表达不清，难以进行检索，以及（3）可能需要从用户问题中生成结构化查询（例如，用于向具有元数据过滤或SQL数据库的向量存储查询）。

LangChain有许多先进的检索方法来帮助解决这些挑战。(1)Multi representation indexing：创建一个适合检索的文档表示（如摘要），请阅读上周的博客文章了解有关多向量检索器的内容。(2)Query transformation：在本文中，我们将回顾一些转换人类问题的方法，以改善检索。(3)Query construction：将人类问题转换为特定的查询语法或语言，这将在未来的文章中介绍。

如果你想到一个朴素的RAG流程，一般的流程是将用户的问题直接传递给一个嵌入模型。然后将该嵌入与存储在向量库中的文档进行比较，并返回相似度最高的前 k 个文档。

查询转换处理的是将用户的问题在传递给嵌入模型之前进行的转换。

虽然这不是一个新现象（查询扩展Query Expansion在搜索中已经使用了多年），但新的是能够使用LLMs来实现它。

Rewrite-Retrieve-Read 

本文使用LLM来重写用户查询，而不是直接使用原始用户查询进行检索。

由于原始查询对于LLM来说并不总是最优的，尤其是在现实世界中…我们首先提示LLM重写查询，然后进行检索增强阅读。

所使用的Prompt相对简单（在这里的Hub上）：

链接：

1.https://arxiv.org/pdf/2305.14283.pdf

2.https://github.com/langchain-ai/langchain/blob/master/cookbook/rewrite.ipynb

Step back prompting

本文使用LLM生成一个“退后一步”的问题。这可以与或不使用检索一起使用。使用检索时，将使用“退后一步”问题和原始问题进行检索，然后使用两个结果来确定语言模型的响应。

这是使用的Prompt：

链接：

1.https://arxiv.org/pdf/2310.06117.pdf

2.https://github.com/langchain-ai/langchain/blob/master/cookbook/stepback-qa.ipynb

Follow Up Questions

在对话链中处理后续问题时，最基本和核心的地方查询转换的应用是非常重要的。在处理后续问题时，基本上有三种选择：

1. 只需嵌入后续问题。这意味着如果后续问题建立在或参考了之前的对话，它将失去那个问题。例如，如果我先问“在意大利我可以做什么”，然后问“那里有什么类型的食物” – 如果我只嵌入“那里有什么类型的食物”，我将无法知道“那里”指的是哪里。

2. 将整个对话（或最后的 k 条消息）嵌入。这样做的问题在于，如果后续的问题与之前的对话完全无关，那么它可能会返回完全无关的结果，这在生成过程中可能会造成干扰。

3. 使用LLM进行查询转换！

在这最后一个选项中，你将迄今为止的整个对话（包括后续问题）传递给LLM，并要求它生成一个搜索词。这就是我们在WebLangChain中所做的，也是大多数基于聊天的检索应用程序可能会做的事情。

那么问题就变成了：我应该使用什么Prompt来将整个对话转化为搜索查询？这就是需要进行大量Prompt工程的地方。以下是我们用于WebLangChain的提示（它将“查询生成”部分描述为构建一个独立的问题）。在这里的Hub上查看。

Multi Query Retrieval

在这个策略中，LLM被用来生成多个搜索查询。然后，这些搜索查询可以并行执行，并将检索到的结果一起传递。当一个问题可能依赖于多个子问题时，这真的非常有用。

例如，请考虑以下问题：最近一次赢得冠军的是红袜队还是爱国者队？

这实际上需要两个子问题：

1. “红袜队最后一次赢得冠军是什么时候？”

2. “爱国者队最后一次赢得冠军是什么时候？”

链接：

https://python.langchain.com/docs/modules/data_connection/retrievers/MultiQueryRetriever

RAG-Fusion

一篇近期的文章基于多查询检索的概念进行拓展。然而，他们并未将所有文档一并处理，而是使用互惠排名融合来重新排序文档。

链接：

1.https://towardsdatascience.com/forget-rag-the-future-is-rag-fusion-1147298d8ad1

2.https://github.com/langchain-ai/langchain/blob/master/cookbook/rag_fusion.ipynb

结论

如你所见，有许多不同的方式来进行查询转换。再次强调，这并不是一个新话题 – 但新的是使用LLMs来做这个。方法之间的差异归结于使用的提示。编写Prompt非常容易 – 几乎和想出它们一样容易。这就引出了一个问题 – 你将会想出什么样的查询转换呢？让我们知道吧！

欢迎一起探讨。