我要投稿

理解开源RAG项目QAnything中的Query Understand环节

发布日期：2024-04-26 11:59:35 浏览次数： 6741

作者：少军的AI空间

微信搜一搜，关注“少军的AI空间”

开源的LLM+RAG项目，之前看的是Langchain-Chatchat项目为主。不久前网易有道也开源了其QAnything，尝试跑了下，效果挺不错。

QAnything官网和网上已有许多架构解读，包括网易BCEmbedding模型、二阶段的Rerank重排等，不再赘述。

有一个比较特别的点，架构图里的Query会先送到一个LLM大模型里做Query Understanding，很少人关注到这点，但这却肯定是未来RAG架构中的常规设计。

Query Understanding可以理解成意图识别。用户的Query问法千奇百怪不可预知，用基于规则的方案缺乏泛化，也无法穷举做判断，所以只能基于In-context learning或FT的LLM来做Query Understand，泛化性更强。

Query understand 主要是解决多轮对话和意图识别的一个环节：

1、RAG里面的多轮对话和chat的多轮对话不太一样，RAG需要用query去检索。举个例子：

query1: 上海这座城市怎么样？

answer1: 上海………blablabla....

query2: 和北京比呢？

如果拿query2去检索，那拿到的片段全是北京的信息，没有上海的信息，回答会文不对题。

所以才有这样的解决办法，即通过LLM大模型把历史对话和当前问题改写成一个独立问题，比如这里会改写成：

condense query：上海和北京相比怎么样？

然后再拿这个condense query去做检索。因为LLM大模型有幻觉，这个condense query会被改错，所以最终回答的时候还得用history+原问题+检索片段来输出答案。而condense query只作用在检索这个过程。

2、意图分类：有些问题不适合RAG来回答，LLM大模型自己就能回答，或者有些问题需要接入数据库检索匹配，这里就可以做一个意图分类，把query分流处理。

这个环节决定了后续RAG增强后给后面LLM的最终提示词，也决定了最终答案的准确率。因此先用LLM做下Query Understand自然是很有必要的。

最后，架构图中前后出现了两个LLM大模型。它们是什么关系？这两个大模型可以是同一个大模型，也可以是不一样的大模型，这个主要看业务场景而定。在一个庞大复杂的问答场景里，用于Query Understanding的大模型，通常是通用基础大模型，比如通义千问、GPT4.0；用于最后输出Answer答案的LLM，则通常是经过微调后的行业领域专属大模型。