|
开源的LLM+RAG项目，之前看的是Langchain-Chatchat项目为主。不久前网易有道也开源了其QAnything，尝试跑了下，效果挺不错。 
QAnything官网和网上已有许多架构解读，包括网易BCEmbedding模型、二阶段的Rerank重排等，不再赘述。
有一个比较特别的点，架构图里的Query会先送到一个LLM大模型里做Query Understanding，很少人关注到这点，但这却肯定是未来RAG架构中的常规设计。
Query Understanding可以理解成意图识别。用户的Query问法千奇百怪不可预知，用基于规则的方案缺乏泛化，也无法穷举做判断，所以只能基于In-contextlearning或FT的LLM来做Query Understand，泛化性更强。
Query understand主要是解决多轮对话和意图识别的一个环节：
1、RAG里面的多轮对话和chat的多轮对话不太一样，RAG需要用query去检索。举个例子： query1: 上海这座城市怎么样？ answer1: 上海………blablabla.... query2: 和北京比呢？
如果拿query2去检索，那拿到的片段全是北京的信息，没有上海的信息，回答会文不对题。
所以才有这样的解决办法，即通过LLM大模型把历史对话和当前问题改写成一个独立问题，比如这里会改写成：
condensequery：上海和北京相比怎么样？
然后再拿这个condensequery去做检索。因为LLM大模型有幻觉，这个condensequery会被改错，所以最终回答的时候还得用history+原问题+检索片段来输出答案。而condensequery只作用在检索这个过程。
2、意图分类：有些问题不适合RAG来回答，LLM大模型自己就能回答，或者有些问题需要接入数据库检索匹配，这里就可以做一个意图分类，把query分流处理。
这个环节决定了后续RAG增强后给后面LLM的最终提示词，也决定了最终答案的准确率。因此先用LLM做下Query Understand自然是很有必要的。 最后，架构图中前后出现了两个LLM大模型。它们是什么关系？这两个大模型可以是同一个大模型，也可以是不一样的大模型，这个主要看业务场景而定。在一个庞大复杂的问答场景里，用于Query Understanding的大模型，通常是通用基础大模型，比如通义千问、GPT4.0；用于最后输出Answer答案的LLM，则通常是经过微调后的行业领域专属大模型。
| 
