在LLM+RAG应用中，有几个常见的问题：1）检索到太多与query不相关的文档/段落，带来噪声信息，干扰LLM生成；2）检索太多无关信息，导入输入的promt长度太长，影响生成效率；3）不是每个query都需要检索信息回答，而每次都去检索、召回，造成计算资源浪费。针对上述问题，本次分享一篇<FIT-RAG: Black-Box RAG with Factual Information and Token Reduction>paper，看看它是如何来解决这些回答的。
2、方法
上图为论文提出的FIT-RAG整体框架，主要包括5个部分：
1）a Similarity-based Retriever：基于相似度的检索器，负责从语料库中检索出与query相关文档；
2）a Bi-label Document Scorer：文档事实信息判断器，负责对检索到的候选文档进行0,1判断打分，包含两个维度：has_answer进行事实信息判断，llm_prefer进行模型偏好判断；
3）a Bi-faceted Self-Knowledge Recognizer：判断query是否需要检索信息；
4）a Sub-document-level Token Reducer：文档组合器，负责选择top-k文档并进行压缩与组合；
5）a Prompt Construction：负责构建prompt；
下面对上述5个环节进行展开说下。
1）a Similarity-based Retriever：对给定一个query，其负责从已有的corpus中检索出相关文档，具体可以基于向量相似度或者传统的BM25等方法，paper中是检索100篇相关文档。
2）a Bi-label Document Scorer：训练一个分类器，paper是基于T5框架，在decoder部分用一个二分类head来代替，然后采用lora方式微调来训练。分类器要做两个维度的判断，第一个是has_answer：代表召回的文档是否包含真实答案；第二个是llm_prefer：代表召回的文档是否有利于query回答。关于训练数据集的构建，对于一篇召回的文档x来说，如果x包含query对应的真实答案，has_answer就标1，否则标1；将x与query输入一个LLM，若生成的结果是正确的，LLM_Prefer就标，否则标0；
paper在构建这个训练集时发现，标签集合为 {1, 1} or {0, 0}数量要远远大于{0, 1} or {1, 0} 类型，数据存在不平衡，为此文中有提出不平衡的训练方法，这里我就不详细讲，个人觉得这个不平衡问题，更多应该在构建数据层面来解决，因为不同任务类型，会影响标签分布。如果query的答案是很简单的几个词类型，那么标签{1,1}与{0,0}的概率肯定很大，而如果query的答案是一段话，那么{0, 1} 与 {1, 0}类型就会多。
3）a Bi-faceted Self-Knowledge Recognizer：是训练一个模型来判断query是否需要检索。具体判断思路如下：
从两个维度判断：1）如果检索出的文档包含答案比例（由a Bi-label Document Scorer模块预测的has_answer累计得到，比例越高，说明query能更多依据之前的信息来回答，就不需要检索）；2）判断q与历史query库的相似度，利用knn方式来预其类型（需要事先构建query类型库，根据LLM能否直接回答出答案来标“需要检索”“不需要检索”来预测q属于的类型），最终判断依据是这两个维度都达到预定的值，就认为不需要检索，反之需要。
4）a Sub-document-level Token Reducer：该环节包括，利用第二步的结果对召回的文档进行下重排，然后选择topk文档，接着对topk文档进行更小粒度切分与组合，组合后再用一个分类模型来判断，组合的片段是否有利于query的回答来进行取舍。流程如下：
5）完成以上过程后，就是构建最终的prompt，根据第三步的判断，分别构建出不需要检索的prompt和需要检索的prompt。
3、实验
结果显示FIT-RAG框架3个数据集上Acc指标都得到显著提升，输入的token也更少。下面是各个模型的消融对比结果。
结语：分享一个FIT-RAG，其主要围绕过滤检索信息+提高检索信息+query是否需要检索判断这三个方面来优化，每个环节都构建一个小模型来实现。整体感觉FIT-RAG提出的pipline比较多，有点复杂了LLM+RAG流程，这也给响应效率带来问题（这个文中没有提及），个人觉得流程思路可以借鉴，能否让这三个流程用一个小的模型或者2b的LLM来实现，而不是单独训练。
