
RAG原理



数据问题:数据存储形式,清洗
-
去噪
-
敏感信息过滤
-
领域术语保留: 建立允许词表(如"iPhone15 Pro Max"不拆分)
RAG prompt
RAG prompt 模板如何构建?
已知信息: {context}
根据上述已知信息,简洁和专业的来回答用户的问题。如果无法从中得到答案,请说 “根 据已知信息无法回答该问题” 或 “没有提供足够的相关信息”,不允许在答案中添加编造 成分,答案请使用中文。
问题是:{question}
整体优化思路
-
文档块切分:设置适当的块间重叠、多粒度文档块切分、基于语义的文档切分、文档块摘要。
-
文本嵌入模型:基于新语料微调嵌入模型、动态表征。
-
提示工中优化:优化模板增加提示词约束、提示词改写。
-
大模型迭代:基于正反馈微调模型、量化感知训练、提供大 context window 的推理模型。
此外,还可对 query 召回的文档块集合进行处理,如:元数据过滤、重排序减少文档块数量。
更高级优化思路参考:
文本块切分:split
需要慎重选择切块的大小!!!!!
为什么要切分为文本块
-
⼤模型输入长度有限制:随着深度学习模型的发展,虽然已经出现了许多功能 强⼤的⼤型模型,但是它们的输入长度仍然存在限制。对于某些任务或平台, 输入文本的长度可能会受到限制。因此,通过进行文本切分,可以确保输入的 文本长度在可接受的范围内,从而更好地满⾜模型的需求。
-
成本问题:在某些平台上,收费是按照文本中的 token 数量计算的,因此发 送⼤量文本可能会带来相当高的费用负担。
-
优化答案质量:有研究表明,发送少量相关信息可以获得更好的答案。在某些 情况下,过多的文本可能会导致信息过载或混淆,从而降低了答案的准确性或 可理解性。通过将文本切分成更⼩的⽚段,可以更精确地传达所需信息,提高 系统对输入的理解和处理效率,从而获得更好的答案。
选择分块策略时要考虑哪些因素
-
**被索引内容的特点 ** 考虑被索引内容的类型和特点,确定是处理较⻓的文档(如文章或书籍) 还是处理较短的内容(如微博或即时消息)。这决定了哪种嵌入模型更适 合您的⽬标,并从而决定应用哪种分块策略。
-
使用的嵌入模型及其最适块大小 根据所选用的嵌入模型及其适用的块大小,选择合适的分块策略。例如, Sentence-Transformer 更适合单句处理,而 text-embedding-ada- 002 更适合处理包含 256 或 512 Token 的文本块。
-
**用户查询的预期⻓度和复杂度 ** 考虑用户输入的问题文本是简短而具体的还是冗⻓而复杂的。这直接影响 到我们选择分组内容的方式,以确保在嵌入查询和嵌入文本块之间有更紧 密的相关性。
-
**检索结果在特定应用中的使用方式 ** 考虑检索结果在特定应用中的使用方式。根据检索结果的使用情况,调整 分块策略,以提高检索效率和结果的实用性
分块策略有哪些?
-
分块⻓度(字符、token )
将文本按照字符数或 token 数进行分块。可以根据任务的要求和所使用 的嵌入模型的限制,确定每个分块的⻓度,以便更有效地进行处理和分 析。 -
重合⻓度 设置分块之间的重叠部分⻓度。通过在相邻分块之间引入重叠部分,可以 确保相关信息不会丢失,并且在处理边界处能够获得更准确的结果。
-
标题 根据文本内容的标题或章节标题进行分块。这种策略可以根据文档的结构 和语义信息进行划分,使得每个分块都具有⼀定的完整性和相关性。
-
层次分级 根据文本的层次结构进行分块。这种策略通常适用于包含层次性信息的文 本,例如技术文档、报告或论文,其中存在多个级别的标题和⼦标题。
-
切分符 根据特定的切分符号将文本分成块。可以使用特定的符号或标记来指示文 本的分块边界,例如换行符、句号、逗号等。
-
语义切分 根据文本的语义信息进行分块。这种策略利用自然语⾔处理技术来识别文 本中的语义边界,并根据语义关联性将文本分成块,从而更好地捕捉文本 的含义和逻辑结构。
语义分块模型有哪些
-
基于 BERT 的朴素文本切分方法
使用BERT模型对文本进行切分,这是⼀种基本的方法,通过BERT的预训练模型来识别文本的分块边界。 -
Cross-Segment 模型
该模型充分利用了更⻓的上下文信息,以提高预测效率。⾸先,利用 BERT模型为每个句⼦生成向量表示。然后,将连续的多个句⼦的向量表 示输入到另⼀个BERT或LSTM模型中,⼀次性预测每个句⼦是否是文本 分段的边界。这种方法有助于更全⾯地理解文本的语义结构和逻辑关系。 《Text Segmentation by Cross Segment Attention》 -
SeqModel 模型
这种模型利用BERT对多个句⼦同时编码,以建模更⻓的上下文之间的依赖关系,然后计算句⼦向量,并预测每个句⼦后是否需要进行文本分割。 此外,该模型还采用了自适应滑动窗⼝方法,在不降低准确性的情况下进 ⼀步提高推理速度。该模型的细节可以在这⾥找到 (https://modelscope.cn/models/iic/nlp_bert_documentsegmentation_chinese-base/summary)
痛点 :文档切分粒度不好把控,既担心噪声太多又担心语义信息丢失
问题 1:如何让 LLM 简要、准确回答细粒度知识?
问题 2:如何让 LLM 回答出全面的粗粒度(跨段落)知识?
基于 LLM 的文档对话架构分为两部分,先检索,后推理。重心在检索(推荐系统),推理交 给 LLM 整合即可。 而检索部分要满足三点 ①尽可能提高召回率,②尽可能减少无关信息;③速度快。 将所有的文本组织成二级索引,第一级索引是 [关键信息],第二级是 [原始文本],二者一 一映射。 检索部分只对关键信息做 embedding,参与相似度计算,把召回结果映射的 原始文本交给 LLM。主要架构图如下:

首先从架构图可以看到,句子、段落、文章都要关键信息,如果为了效率考虑,可以不用对 句子构建关键信息。
-
**文章的切分及关键信息抽取 ** 关键信息: 为各语义段的关键信息集合,或者是各个子标题语义扩充之后的集合(pdf 多级 标题识别及提取见下一篇文章) 语义切分方法 :
-
利用 NLP 的篇章分析(discourse parsing)工具,提取出段落之间的主要关系,譬如上述极端情况2 展示的段落之间就有从属关系。把所有包含主从关系的段落合并成 一段。 这样对文章切分完之后保证每一段在说同一件事情.
-
除了 discourse parsing 的工具外,还可以写一个简单算法利用 BERT 等模型来实现语义分割。BERT 等模型在预训练的时候采用了 NSP(next sentence prediction)的 训练任务,因此 BERT 完全可以判断两个句子(段落)是否具有语义衔接关系。这里我们可 以设置相似度阈值 t,从前往后依次判断相邻两个段落的相似度分数是否大于 t,如果大于则 合并,否则断开。当然算法为了效率,可以采用二分法并行判定,模型也不用很大,笔者用 BERT-base-Chinese 在中文场景中就取得了不错的效果。
-
**语义段的切分及段落(句子)关键信息抽取 **
如果向量检索效率很高,获取语义段之后完全可以按照真实段落及句号切分,以缓解细 粒度知识点检索时大语块噪声多的场景。当然,关键信息抽取笔者还有其他思路。
-
方法 1:利用 NLP 中的成分句法分析(constituency parsing)工具和命名实体识别(NER) 工具提取成分句法分析(constituency parsing)工具:可以提取核心部分(名词短语、动词短语……); 命名实体识别(NER)工具:可以提取重要实体(货币名、人名、企业名……)。 譬如说: 原始文本:MM 团队的成员都是精英,核心成员是前谷歌高级产品经理张三,前 meta 首席技术官李四…… 关键信息:(MM 团队,核心成员,张三,李四)
-
方法 2:可以用语义角色标注(Semantic Role Labeling)来分析句子的谓词论元结构,提取 “谁对谁做了什么”的信息作为关键信息。
-
方法 3:直接法。其实 NLP 的研究中本来就有关键词提取工作(Keyphrase Extraction)。也 有一个成熟工具可以使用。一个工具是 HanLP ,中文效果好,但是付费,免费版调用次数 有限。还有一个开源工具是 KeyBERT,英文效果好,但是中文效果差。
-
方法 4:垂直领域建议的方法。以上两个方法在垂直领域都有准确度低的缺陷,垂直领域可 以仿照 ChatLaw 的做法,即:训练一个生成关键词的模型。ChatLaw 就是训练了一个 KeyLLM。
-
常见问题
-
句子、语义段、之间召回不会有包含关系吗,是否会造成冗余? 回答:会造成冗余,但是笔者试验之后回答效果很好,无论是细粒度知识还是粗粒度(跨段 落)知识准确度都比 Longchain 粗分效果好很多,对这个问题笔者认为可以优化但没必要
pdf文档如何处理
PDF的解析也是经典的一种数据源,文档解析一般就用vision-encoder + text-decoder,将图片转为markdown,这都有现成的技术和开源工具;有了markdown文档后,在做定制化的切片和索引构建
embedding的选择
embedding优化
-
**微调嵌入 **
-
影响因素:影响到 RAG 的有效性;
-
目的:让检索到的内容与查询之间的相关性更加紧密;
-
作用:可以比作在语音生成前对“听觉”进行调整,优化检索内容对最终输出的影响。 特别是在处理不断变化或罕见术语的专业领域,这些定制化的嵌入方法能够显著提高检 索的相关性。
-
**动态嵌入(Dynamic Embedding) **
-
介绍:不同于静态嵌入(static embedding),动态嵌入根据单词出现的上下文进行调整, 为每个单词提供不同的向量表示。例如,在 Transformer 模型(如 BERT)中,同一单 词根据周围词汇的不同,其嵌入也会有所变化。
-
检索后处理流程:
-
动机: 1. 一次性向大语言模型展示所有相关文档可能会超出其处理的上下文窗口限制。 1. 将多个文档拼接成一个冗长的检索提示不仅效率低,还会引入噪声,影响大语言模型 聚焦关键信息。
-
优化方法: 1. a) ReRank(重新排序) 1. b) Prompt 压缩 1. c) RAG 管道优化 1. d) 混合搜索的探索 1. e) 递归检索与查询引擎 1. f) StepBack-prompt 方法 1. g) 子查询 1. h) HyDE 方法
embedding模型有哪些
榜单: https://huggingface.co/spaces/mteb/leaderboard
-
BGE:这是知谱开发的中文embedding模型,在HuggingFace的MTEB(海量 文本Embedding基准)上排名前2,实⼒强劲; (比较推荐,后面有很多优化,召回模型也有BGE版本,一般bge embedding和bge-reranker是配套使用的)
-
M3E:也是国⼈开发的中文embedding模型
-
通义千问的embedding模型:因为是1500+维的模型,所以我们在国庆节后准 备用用看;
-
Text-embedding-ada-002:这是OpenAI的embedding模型,1536维,我 感觉上应该是⽬前最好的模型,但是它在MTEB上排名好像只有第六,但是国 内应该也不太能用,所以我们就放弃了;
-
自⼰训练embedding模型:训练是基于⼀ 个既有embedding模型的,⼀般我们有希望让它在原来的基础上提升 3%-10%的性能。
自己训练embedding模型 : 微调Bert
为了更好地适应特定的领域需求,推荐采用微调 BERT 模型的方法。 通过微调,BERT 模型能够针对特定领域的数据集进行优化,从而在相似度任务上
提供更加精准的结果。微调过程涉及使用领域内的数据对模型进行再训练,使其更 好地理解和捕捉领域特有的语⾔特征和模式。
值得注意的是,在选择模型时,应考虑模型的适用性和数据集的特点。高排行 的模型虽然在⼀般场景下表现良好,但可能不完全符合特定领域的需求。因此,微 调 BERT 模型可以为特定任务提供更加定制化的解决方案。
- **为什么要微调 Bert 模型 ** 微调BERT模型是为了使其更好地适应特定应用场景,提高模型的性能和准确性。 以下是微调BERT模型的两个主要原因:
- 增强专业领域知识的理解:
原生BERT模型在预训练阶段主要接触的是⼴泛的常识性文本数据,这使得它 在处理通用语⾔任务时表现出色。然而,这样的训练方式也导致了模型在专业 领域的知识理解上存在局限。通过微调,我们可以为BERT模型引入特定领域 的数据集,使其学习到该领域的专业术语、概念和语⾔模式。这种定制化的训 练有助于模型在医疗、法律、科技等专业领域的任务中提供更加精准的分析和 预测。 - 改善向量表示,优化召回效果:
在信息检索等应用中,原生BERT模型生成的向量可能不⾜以满⾜直接召回的 需求。召回阶段要求模型能够快速有效地从⼤量数据中筛选出相关文档或信 息。微调后的BERT模型能够生成更适合特定任务的向量表示,这些向量更能 反映查询意图和文档的相关性,从而提高召回系统的准确性和效率。
总结来说,微调BERT模型是为了使其更好地适应特定领域的语⾔特点和应用需求,从而在实际应用中实现更高的性能和更准确的结果。
如何构造微调 Bert 相似度向量模型数据?
在微调 BERT 模型以进行相似度向量建模时,关键在于构建高质量的训练数据集。以下是构造这类数据集的策略:
-
基于医疗领域的正负样本构建:
利用医疗数据集,可以根据相同疾病相关的问题构建相似数据对,而不同 疾病的问题则视为不相似。例如,针对“冠心病”这⼀疾病,可以形成以下 正样本数据对:
(“什么是冠心病?”, “冠心病怎么治疗?”, 1)
(“冠心病的症状是什么?”, “冠心病的治疗方法有哪些?”, 1)
同时,构建负样本数据对,如:
(“冠心病的症状是什么?”, “什么是糖尿病?”, -1)
这样的数据对标注了问题的相似性(1表示相似,-1表示不相似),有助于模型学习区分问题的相似度。 -
利用⼤型语⾔模型生成同义句:
为了增加数据集的多样性和丰富性,可以使用⼤型语⾔模型(如GPT-3)生成给定问题的同义句。例如,可以要求模型生成“什么是冠心病?”的变体或同义问题,从而得到新的数据样本。
这种方法不仅可以扩⼤数据集的规模,还可以提高模型对不同表达方式的 理解能⼒。 -
数据质量控制:
⽆论采用何种方法生成数据,都必须进行严格的质量控制。这包括对数据 进行⼈⼯审核,确保每个样本的准确性和相关性。 质检过程可以包括检查问题的语义⼀致性、确保同义句的真实性,以及验 证标注的相似度是否正确此外,还可以采用交叉验证等技术,进⼀步确保数据集的质量和模型的泛 化能⼒。
通过上述策略,可以有效地构建用于微调BERT相似度向量模型的数据集。这种方 法不仅能够提供高质量的训练样本,还能够帮助模型更好地理解和区分问题的相似 性,从而提高模型在实际应用中的性能。
微调模型中正负样本⽐例的策略是什么
在微调机器学习模型时,正确控制正负样本的⽐例对于模型的性能和收敛速度⾄关 重要。以下是⼀些关于如何平衡正负样本⽐例的建议:
- 样本⽐例的基本原则:
通常情况下,负样本的数量确实会超过正样本,因为相似的样本往往具有较高 的相似性,而不相似的样本则表现出更⼤的多样性。然而,负样本的数量不应 过多,以免影响模型的收敛。如果正样本的数量超过1万,负样本可以设置为 正样本的2到4倍。这样的⽐例有助于模型在学习区分正负样本时保持平衡。
- 根据数据量调整⽐例:
当数据集的规模较⼤时,可以适当增加负样本的⽐例。这是因为⼤规模数据集 能够提供更多的样本变化,从而帮助模型更好地学习到不相似样本的特征。然 而,即使是在⼤数据集的情况下,也应该避免负样本数量远远超过正样本,以 免造成模型训练的不平衡。
**embedding 模型在表示 text chunks(文本块)时偏差太大问题 **
- 问题描述: 一些开源的 embedding 模型本身效果一般,尤其是当 text chunk 很大的时候,强行变成一个 简单的 vector 是很难准确表示的,开源的模型在效果上确实不如 openai Embeddings; 多语言问题,paper 的内容是英文的,用户的 query 和生成的内容都是中文的,这里有个语 言之间的对齐问题,尤其是可以用中文的 query embedding 来从英文的 text chunking embedding 中找到更加相似的 top-k 是个具有挑战的问题
- 解决方法: 用更小的 text chunk 配合更大的 topk 来提升表现,毕竟 smaller text chunk 用 embedding 表示 起来 noise 更小,更大的 topk 可以组合更丰富的 context 来生成质量更高的回答; 多语言的问题,可以找一些更加适合多语言的 embedding 模型
存储:向量数据库
索引
最基本:向量数据库索引
存入向量数据库中,按照向量数据库的规则进行索引
分层索引
如果你需要从大量文档中检索信息,你需要能够高效地搜索这些文档,找到相关信息,并将其整合成一个包含参考来源的统一答案。对于大型数据库,一个有效的方法是创建两个索引:一个包含摘要,另一个包含所有的文档块,并通过两步搜索,先利用摘要筛选相关文档,再在这些相关文档中进行具体搜索。

增加元数据
-
为什么增加元数据提高检索相关性 将元数据与索引向量结合使用有助于更好地构建它们,同时提高搜索相关性。
-
如果你搜索的项目中,时间是一个维度,你可以根据日期元数据进行排序
-
如果你搜索科学论文,并且你事先知道你要找的信息总是位于特定部分,比如实验部分,你可以将文章部分添加为每个块的元数据并对其进行过滤仅匹配实验 元数据很有用,因为它在向量搜索之上增加了一层结构化搜索。
-
怎么使用元数据增强检索相关性??
RAG 如何优化索引结构?
构建 RAG 时,块大小是一个关键参数。它决定了我们从向量存储中检索的文档的长度。 小块可能导致文档缺失一些关键信息,而大块可能引入无关的噪音。 找到最佳块大小是要找到正确的平衡。如何高效地做到这一点?试错法(反复验证)。 然而,这并不是让你对每一次尝试进行一些随机猜测,并对每一次经验进行定性评估。 你可以通过在测试集上运行评估并计算指标来找到最佳块大小。LlamaIndex 有一些功 能可以做到这一点。可以在他们的博客中了解更多。
Query的处理和优化
用户Query处理
https://blog.csdn.net/baidu_25854831/article/details/139911570?spm=1001.2014.3001.5502

-
预处理:大小写、全半角、繁简体、长度截断。
-
分词:领域词库、新词发现、多粒度、词性、停用词等。
-
query改写:纠错(NLP.TM[37] | 深入讨论纠错系统)、归一、拓展。
-
Term分析:分词、重要性(NLP.TM[20] | 词权重问题、心法利器[33] | 快速的关键词抽取baseline)、紧密度。(这里我要补充一个NER,我理解NER应该属于这个位置且不可或缺)
-
意图识别(R&S[25] | 搜索中的意图识别、前沿重器[20] | 文本分类和意图识别调研思考):精准&模糊。
-
敏感识别、时效分析、人工干预等。
从这个流程来看,大到意图识别、改写、term分析这些常见且精力花费比较多的模块,小到大小写、新词发现之类的小操作,都被放在了query理解里面,这些工作尽管历史已经非常悠久(其实也就十来年吧),但目前,无论是历史同样悠久的成熟搜索系统,还是新建的搜索系统(甚至包括multiagent),都仍有他们的影子,还是非常重要。
Query 优化增强检索性能
Query扩写
- 为什么要扩写 粗略排序(粗排)阶段的⽬标是快速识别出与查询(Query)相关的⼤量文本。为 了实现这⼀⽬标,可以采用⼤型语⾔模型(LLM)来扩展原始查询,从而增加检索 到的相关文本数量。以下是使用LLM进行Query扩展的方法和优势:
- Query扩展的⽬的:
Query扩展模块的主要⽬的是通过生成与原始Query语义相关或互补的变体, 来增加搜索引擎检索到的相关文档的数量。这种方法可以提高检索系统的覆盖 ⾯,从而提高用户找到所需信息的概率。 - 利用LLM进行Query扩展:
通过使用LLM,如GPT-3或其他先进的语⾔模型,可以自动生成⼀系列与原 始Query相关的扩展Query。这些模型能够理解原始Query的意图和上下文, 并产生新的表达方式,例如同义词替换、句⼦重构或相关概念的引入。 - 生成多样化的扩展Query:
LLM可以生成多种不同形式的扩展Query,包括⻓尾查询、相关问题、相关短 语等。这种多样化的Query集合有助于捕捉用户的多样化表达,从而提高检索 系统的准确性和鲁棒性。 - 提升检索效率:
通过Query扩展,可以显著提高粗排阶段的效率。扩展后的Query集合能够覆 盖更⼴泛的相关文本,减少遗漏重要信息的⻛险。同时,这也为后续的精确排 序(精排)阶段提供了更多的候选文档。 - 结合检索系统优化:
在实际应用中,Query扩展模块应与检索系统紧密结合,以实现最佳的性能。 例如,可以对扩展后的Query集合进行预处理,去除冗余或低质量的Query, 以确保最终提交给搜索引擎的Query集合是精炼和高效的。
总结来说,Query扩展模块是提高信息检索系统性能的关键组件。通过利用LLM的 强⼤生成能⼒,可以有效地扩展原始Query,增加检索到的相关文本数量,并提升 整个检索流程的效率和准确性。 - 扩写的prompt 模板="""你是⼀个AI语⾔模型助⼿。你的任务是生成给定用户问题的3个不同版 本,以从向量数据库中检索相关文档。 通过对用户问题生成多个⻆度,你的⽬标是帮助用户克服基于距离相似性搜索的 ⼀些限制。 通过换行符分隔提供这些替代问题。原始问题:{question}"""
Query Transformation
query transformation 主要就是利用各种技巧和大模型的能力,去对用户的query进行改写,转换等操作,丰富query的语义信息。
Query Rewrite
因为对于 LLM 而言,原始查询不可能总是最佳检索,尤其是在现实世界中,我们首先提示 LLM 重写查询,然后进行检索增强阅读。这个技术可以参考下面langchain中的示例,本质还是使用了提示词工程,去编写改写的提示词,这部分提示词也是可以优化的地方。
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("**") distracted_query = "man that sam bankman fried trial was crazy! what is langchain?" rewriter = rewrite_prompt | ChatOpenAI(temperature=0) | StrOutputParser() | _parse rewriter.invoke({"x": distracted_query})
MultiQuery
本质上是query rewrite的改进版,可以同时生成n个和用户query相似的query,然后同时进行检索,这样能确保召回的内容尽可能的符合原始query。具体可以参考下面的代码,需要 langchian 的最新版本。
from langchain.retrievers.multi_query import MultiQueryRetriever from langchain_openai import ChatOpenAI question = "What are the approaches to Task Decomposition?" llm = ChatOpenAI(temperature=0) retriever_from_llm = MultiQueryRetriever.from_llm( retriever=vectordb.as_retriever(), llm=llm )
后退
后退提示:提示LLM提出一个关于高层次概念或原则的抽象通用问题(称之为“后退”问题)。后退问题的抽象程度需要根据特定任务进行调整。最终后退问题和原始问题一起进行检索。例如,对于问题“Estella Leopold在1954年8月至11月期间上了哪所学校?”这个问题很难直接解决,因为有时间范围的详细限制。在这两种情况下,提出一个后退问题“Estella Leopold的教育经历怎么样的?”则有助于系统的检索。
Follow Up Questions(多轮对话)
使用LLM针对历史对话和当前问题生成一个独立问题。这个方法主要针对以下情况:
a. 后续问题建立在前一次对话的基础上,或引用了前一次谈话。例如,如果用户先问“我在意大利能做什么”,然后问“那里有什么类型的食物”——如果只嵌入“那里有哪种类型的食物“,LLM就不知道“那里”在哪里。
b.嵌入整个对话(或最后k条消息)。如果后续问题与之前的对话完全无关,那么它可能会返回完全无关的结果,从而在生成过程中分散LLM的注意力。
HyDE(Hypothetical Document Embeddings)
https://js.langchain.com.cn/docs/modules/indexes/retrievers/hyde
Hyde全称是Hypothetical Document Embeddings,通过LLM对用户的query生成一篇假设性的文档或者回答,然后根据这个文档/回答的向量去查找相似的N个上下文向量。 核心的原理就是,生成的假设性回答要比query更接近于embedding 空间。
随着版本的迭代,langchain的文档中对hyde的说明有些变化,从源码中可以看到是内置了多种提示词模板的。
PROMPT_MAP = { "web_search": web_search, "sci_fact": sci_fact, "arguana": arguana, "trec_covid": trec_covid, "fiqa": fiqa, "dbpedia_entity": dbpedia_entity, "trec_news": trec_news, "mr_tydi": mr_tydi, }
检索模块
召回阶段与粗排
召回的目标是从千万级甚至亿级的候选中召回几千个,召回一般由多路组成,每一路会有不同侧重点(优化目标)。在推荐系统中,不同路代表了不同的优化目标。
多路召回
原文链接:https://blog.csdn.net/baidu_25854831/article/details/140093685
多路召回是搜索里面很常见的操作。因为用户提问的复杂性、内容的多样性等原因,我们往往不会一路把所有内容都召回回来,如何分路成为一个值得探讨的问题,下面我会分几个维度来讲多路召回可能的操作,并会提及具体的使用场景,供大家参考使用。
-
意图/路由划分下的多路召回。针对不同的需求,可能需要不同的操作来满足,例如要查音乐和查天气,后续的操作会不同,搜音乐以来音乐库,查天气则是查询天气接口,此时显然就是要走不同的链路来进行内容召回,再者同样是音乐类,用户可能是按歌手、歌名、流派等因素查,复杂以后很可能需要多路召回来实现,另外也需要配合上游的意图识别、实体抽取等因素,来切分链路,然后根据链路来进行召回。
-
不同内容结构下的多路召回。这个比较简单,举例,音乐和购物,背后的数据结构是不同的,但用户的说法可能是模糊的,例如说一个专辑名,可能是要买专辑,也可能是想听音乐,此时多路召回是一个不错的选择,不着急直接看哪个优先级高,这事可以放精排层来做。
-
不同检索方式下的多路召回。这个也比较简单,对不同的检索方案,不好放一起的,分两路是不错的选择(当然也有不分的方法),例如向量召回和字面召回两路。
-
不同表征方式的多路召回。上面有提到向量召回的多样性,基于表征目标和表征特征是可以有多种向量表征方式的,基于不同的表征特征,就可以有多种不一样的召回方式。
提醒,多种召回方式,在一般情况下都是并发进行的,毕竟他们运行需要一定的时间,而且一般互不影响,一般就是服务化后用多进程请求的方式来进行。
精排模块(排序阶段)
什么是交互型模型
交互型模型是⼀种先进的文本匹配方法,它放弃了传统的后处理匹配策略,转而采 用⼀种更为直观的全局匹配方法。这种模型的核心思想是,整体的匹配度可以通过 局部的匹配度来确定,因此在输入阶段就开始进行词语间的初步匹配,并将这些匹 配结果以灰度图的形式用于后续的模型构建中。以下是交互型匹配模型的几个关键 特点:
- 直接匹配信号的捕捉:
交互型模型的⼀个显著优势在于其能够直接捕捉到文本间的匹配信号。这些信 号被用作特征输入,模型通过这些特征来理解和评估两个文本之间的相似性或 关联性。
- 交互层的构建:
在交互层中,两个文本的词语通过交互运算形成⼀个交互矩阵。这种交互运算 可以采用类似于注意⼒机制的方式,例如加性或乘性的运算,从而生成文本间 词语对的关联权重。
- 表示层的作用:
表示层负责对交互矩阵进行进⼀步的抽象和表征。在这⼀层,可以采用多种神 经网络结构,如卷积神经网络(CNN)或循环神经网络(RNN),来提取和 整合交互信息,生成文本的综合表示。
Bert 排序模型
BERT 排序模型是⼀种利用BERT(Bidirectional Encoder Representations from Transformers)进行文本排序的模型,它在处理诸如相关性排序、推荐系统 等任务时表现出色。以下是BERT排序模型的关键应用和微调过程:
- ⼆分类任务的实现:
BERT 模型可以直接应用于⼆分类任务。在这种情况下,通常会将两个文本序 列 S1 和S2 进行拼接,形成⼀个新的输入序列。这个序列会被送入 BERT 模 型中,模型会使用特殊的分类标记(如[CLS])来生成⼀个聚合的输出向量。
- 利用CLS输出进行分类:
在BERT模型中,[CLS]标记位于序列的开始位置,并且其输出向量经过⼀个 线性层(通常在预训练阶段就已经训练好)后,可以用来进行⼆分类。这个输 出向量捕捉了输入序列的整体语义信息,并且可以被送入⼀个简单的分类层来 进行最终的分类决策。
- 微调过程:
在微调BERT模型时,通常只需要对少量的参数进行更新,以适应特定的任务。这可以通过设置⼤部分预训练参数的 requires_grad 属性为 False 来实现,只保留顶层的分类器参数进行训练。这样做可以减少计算 量,加快训练速度,并防⽌过拟合。
- 离线计算的局限性:
BERT 排序模型的⼀个限制是它不适合进行⼤规模的离线计算。这是因为 BERT 模型的计算复杂度较高,直接在⼤规模数据集上进行排序计算会⾮常耗 时。因此,在实际应用中,BERT 排序模型通常用于相对较⼩的文本集合的排 序任务。
- 优化计算策略:
为了提高效率,可以采取⼀些策略来减少需要计算的文本数量。例如,可以⾸ 先使用⼀个更快的预筛选模型来过滤掉不相关的文本,然后再使用BERT模型 对筛选后的文本进行精细排序。这种方法可以显著减少计算负担,同时保持排 序质量。
总结来说,BERT排序模型是⼀种强⼤的文本排序⼯具,尤其适用于需要考虑文本 整体语义的复杂任务。通过合理的微调和计算策略优化,BERT模型可以在保持高 准确度的同时,提高处理效率,适用于各种规模的文本排序任务。
Re-Rank 模型
-
RAG的Rerank必要性体现在3个方面:
-
精度提升:基于embedding的向量化检索过程可以通过一定程度的语义相似度来高效检索相关性较高的文本片段,但由于语义本身的复杂性和多义性,以及高维向量相似度匹配可能产生的噪音,向量检索可能会召回一些相关性较低的候选项。因而引入rerank模型,希望在向量召回(可以理解为粗排)的基础上进一步优化结果,降低为生成提供的参考内容中的无效信息。
-
语义匹配:向量库检索过程仅考察了query向量和候选向量在向量空间的语义距离,没有考虑query文本和候选文本其他方面的语义关系,比如上下文信息、句法结构等,而rerank模型有机会通过衡量query文本和候选文本之间更丰富的语义关系实现更精细的语义匹配。
-
场景适配:通过自训练rerank模型来进行精排,可以按照特定需求做进一步排序,从而提升QAG在特定应用场景下的表现。
-
Re-Rank 模型是 Cross-Encoder 模型,它同时接受两个文本句⼦作为输入,并输出句⼦对的语义相似度分数。Cross-Encoder 模型精度高,但不适合⼤规模 数据,因此可以采用先试用向量模型粗排得到 Top-100 相关文档,再使用 Re- Rank 模型精排的方式,得到与用户 Query 最相关的文档。
-
常用的开源 Re-Rank 模型有 Cohere-rerank、BAAI/bge-reranker-base、BAAI/bge-reranker-large 等。
过滤模块(领域关键词)
在基于向量的文本召回系统中,⼀个常⻅的挑战是即使文本在语义上相关,由于文 字表达的差异,也可能导致召回失败。为了解决这⼀问题并增强召回策略的可靠 性,可以采用领域关键词共现过滤策略。以下是实施这种策略的方法和益处:
- 领域关键词的重要性:
领域关键词是指在特定领域内频繁出现并具有代表性意义的词汇。这些关键词 能够帮助识别文本的核心主题和内容,从而提高召回的相关性。
- 共现过滤策略的实施:
通过分析和识别领域内的关键词共现模式,可以构建⼀个过滤机制,该机制在 向量召回过程中对候选文本进行预筛选。只有那些包含特定领域关键词共现模 式的文本才会被召回,从而确保召回结果的相关性和准确性。
- 提升召回的准确性:
利用领域关键词共现过滤策略,可以显著提高召回文本的准确性。这种方法通 过确保召回的文本在词汇层⾯上与查询文本或领域主题具有⼀定程度的相似 性,从而减少了完全不相关文本的召回。
- 增强召回的可靠性:
除了提高准确性外,领域关键词共现过滤策略还增强了召回过程的可靠性。通 过这种方法,即使在⾯对表达方式差异较⼤的文本时,召回系统也能够识别出 真正相关的信息,为用户提供更有价值的结果。
- 结合向量召回的优势:
领域关键词共现过滤策略与向量召回相结合,可以充分利用两种方法的优势。 向量召回能够快速处理⼤规模数据集,而关键词过滤则提供了额外的语义层级 检查,确保召回结果的质量和相关性。
总结来说,领域关键词共现过滤策略是⼀种有效的文本召回优化方法。通过结合关 键词的语义信息和向量召回的高效性,可以显著提升召回系统的准确性和可靠性, 确保用户能够获得更加相关和高质量的信息。
混合检索
-
虽然向量搜索有助于检索与给定查询相关的语义相关块,但有时在匹配特定关键词方面 缺乏精度。根据用例,有时可能需要精确匹配。
-
想象一下,搜索包含数百万电子商务产品的矢量数据库,对于查询“阿迪达斯参考 XYZ 运动鞋白色”,最上面的结果包括白色阿迪达斯运动鞋,但没有一个与确切的 XYZ 参考相 匹配。 相信大家都不能接受这个结果。
-
为了解决这个问题,混合检索是一种解决方案。该策略 利用了矢量搜索和关键词搜索等不同检索技术的优势,并将它们智能地结合起来。 通过这种混合方法,您仍然可以匹配相关关键字,同时保持对查询意图的控制。
-
也可以考虑将 ES 搜索结果与 向量数据库检索结果相结合
数据检索中的挑战
通常,如果RAG系统性能不佳,这是因为检索步骤很难找到用于生成的正确上下 文。当使用⽮量搜索返回基于相似性的结果时,可能会由于多种原因而出现差异:
-
语义歧义:向量表示(例如词嵌入)可能⽆法捕捉概念之间的细微差别。例 如,“苹果”⼀词可能指的是⽔果或科技公司。嵌入可能会混淆这些含义,导致 不相关的结果。
-
大小与方向:余弦相似度是⼀种常⻅的度量,重点关注向量的方向而不是它们 的大小。这可能会导致语义上遥远但方向上相似的匹配。
-
粒度不匹配:您的查询向量可能代表特定概念,但如果您的数据集仅包含更⼴ 泛的主题,则您可能会检索到⽐预期更⼴泛的结果。
-
向量空间密度:在高维空间中,密切相关和不相关的项之间的距离差异可能⾮常⼩。这可能导致看似不相关的结果被认为是相关的。
-
全局相似性与局部相似性:⼤多数向量搜索机制都识别全局相似性。有时,您 可能对未捕获的本地或上下文相似之处感兴趣。
-
稀疏检索挑战:检索机制可能很难在庞⼤的数据集中识别正确的段落,特别是 当所需的信息稀疏地分布在多个文档中时。例如,当查询诸如“云安全中的图 机器学习用例”之类的⼩众主题时,如果检索系统获取有关“云安全”的通用文 章而没有图机器学习的具体信息,则后续生成将造成错误。
RAG 检索召回率低的排查方案
补充:尝试过不同大小的 chunk 和混合检索。效果都不太好,如何优化?
个人排查方式:
1 知识库里面是否有对应答案?如果没有那就是知识库覆盖不全问题
2 知识库有,但是没召回: q1:知识库知识是否被分割掉,导致召回出错,解决方法 修改分割方式 or 利用 bert 进行上下句预测,保证知识点完整性 q2:知识没有被召回,分析 query 和 doc 的特点: 字相关还是语义相关,一般建议是 先用 es 做召回,然后才用模型做精排
后处理模块(取上下文)
-
冗余上下文
-
句子窗口搜索:相反,文档文块太小会导致上下文的缺失。其中一种解决方案就是窗口搜索,该方法的核心思想是当提问匹配好文档块后,将该文档块周围的块作为上下文一并交给LLM进行输出,来增加LLM对文档上下文的理解。
-
父文档搜索:父文档搜索也是一种很相似的解决方案,父文档搜索先将文档分为尺寸更大的主文档,再把主文档分割为更短的子文档两个层级,用户问题会与子文档匹配,然后将该子文档所属的主文档发送给LLM。
-
**如何通过提示压缩提升 RAG 效果? **
-
研究表明,在检索上下文中的噪声会对 RAG 性能产生不利影响,更精确地说,对由 LLM 生成的答案产生不利影响。
-
一些方案建议在检索后再应用一个后处理步骤,以压缩无关上下文,突出重要段落,并 减少总体上下文长度。
-
选择性上下文等和 LLMLingua 使用小型 LLM 来计算即时互信息或困惑度,从而计算元素重要性。
-
自动合并
-
自动合并:自动合并是在父文档搜索上更进一步的复杂解决方案。同样地,我们先对文档进行结构切割,比如将文档按三层树状结构进行切割,顶层节点的块大小为1024,中间层的块大小为512,底层的叶子节点的块大小为128。而在检索时只拿叶子节点和问题进行匹配,当某个父节点下的多数叶子节点都与问题匹配则将该父节点作为结果返回。
-
如何让 LLM 基于 query 和 context 得到高质量的 response
-
问题描述:如何让 LLM 基于 query 和 context 得到高质量的 response
-
解决方法: 尝试多个的 prompt 模版,选择一个合适的,但是这个可能有点玄学 用与本地知识问答相关的语料,对 LLM 进行 Finetune。
-
**不同的 prompt,可能产生完全不同的效果问题 **
-
问题描述:prompt 是个神奇的东西,不同的提法,可能产生完全不同的效果。尤其是指令, 指令型 llm 在训练或者微调的时候,基本上都有个输出模板,这个如果前期没有给出 instruction data 说明,需要做很多的尝试,尤其是你希望生成的结果是按照一定格式给出的, 需要做更多的尝试
-
**如何更高质量地召回 context 喂给 llm **
-
问题描述:初期直接调包 langchain 的时候没有注意,生成的结果总是很差,问了很多 Q 给 出的 A 乱七八糟的,后来一查,发现召回的内容根本和 Q 没啥关系
-
解决思路:更加细颗粒度地来做 recall,当然如果是希望在学术内容上来提升质量,学术相 关的 embedding 模型、指令数据,以及更加细致和更具针对性的 pdf 解析都是必要的。 参考:PDFTriage: Question Answering over Long, Structured Documents
多轮对话
https://blog.csdn.net/baidu_25854831/article/details/124240036?spm=1001.2014.3001.5502
https://zhuanlan.zhihu.com/p/11843662780
-
如何判断上下文是否关联?
-
使用模型进行⼆分类
-
上下文⻓度过⻓怎么办?
-
每⼀轮检索的内容如果进行拼接,会存在上下文的内容太多,导致忽略本轮问 题。 ⼤模型 token ⻓度是有限的。
-
解决方案:使用⼤模型进行摘要抽取
RAG架构优化
https://pub.towardsai.net/advanced-rag-techniques-an-illustrated-overview-04d193d8fec6
RAG 新模式优化策略
RAG 的组织方法具有高度灵活性,能够根据特定问题的上下文,对 RAG 流中中的模块进 行替换或重新配置。在基础的 Naive RAG 中,包含了检索和生成这两个核心模块,这个框 架因而具备了高度的适应性和多样性。目前的研究主要围绕两种组织模式:
-
增加或替换模块在增加或替换模块的策略中,我们保留了原有的检索 - 阅读结构,同时加 入新模块以增强特定功能。RRR 提出了一种重写 - 检索 - 阅读的流中,其中利用大语言模 型(LLM)的性能作为强化学习中重写模块的奖励机制。这样,重写模块可以调整检索查询, 从而提高阅读器在后续任务中的表现。
-
调整模块间的工作流中在调整模块间流中的领域,重点在于加强语言模型与检索模型之间 的互动。
利用 知识图谱(KG)进行上下文增强
-
为什么要用KG 向量数据库进行上下文增强存在问题:
-
无法获取长中关联知识
-
信息密度低(尤其当 LLM context window 较小时不友好)
-
怎么用KG进行优化 利用知识图谱(KG)进行上下文增强的策略: 增加一路与向量库平行的 KG(知识图谱)上下文增强策略。
具体方式:对于 用户 query,通过利用 NL2Cypher 进行 KG 增强;
优化策略:常用 图采样技术来进行 KG 上下文增强
处理方式:根据 query 抽取实体,然后把实体作为种子节点对图进行采样(必要时,可把 KG
中节点和 query 中实体先向量化,通过向量相似度设置种子节点),然后把获取的子图转换
成文本片段,从而达到上下文增强的效果。
Self-RAG:如何让大模型对召回结果进行筛选?
-
典型 RAG 架构中,向量数据库检索存在问题: 经典的 RAG 架构中(包括 KG 进行上下文增强),对召回的上下文无差别地与 query 进 行合并,然后访问大模型输出应答。但有时召回的上下文可能与 query 无关或者矛盾, 此时就应舍弃这个上下文,尤其当大模型上下文窗口较小时非常必要
-
Self-RAG 则是更加主动和智能的实现方式,主要步骤概括如下: a) 判断是否需要额外检索事实性信息(retrieve on demand),仅当有需要时才召回; b) 平行处理每个片段:生产 prompt + 一个片段的生成结果; c) 使用反思字段,检查输出是否相关,选择最符合需要的片段; d) 再重复检索; e) 生成结果会引用相关片段,以及输出结果是否符合该片段,便于查证事实 SELF-RAG有效地结合了自我反思和按需检索,提升了模型在多种任务上的表现,尤其是在需要精确事实和引用的场景中。

-
Self-RAG的特点
-
自我反思:模型自我评估是否需要外部信息来辅助回答。
-
按需检索:仅在必要时检索相关信息,以提高回答的相关性和准确性。
-
生成与评估:生成答案并评估其与检索信息的相关性及⽀持度。
-
定制化输出:根据任务需求调整模型行为,优化生成的答案。
-
Self-RAG 的重要创新: Reflection tokens (反思字符)。通过生成反思字符这一特殊标记来检查输出。这些字符会分为 Retrieve 和 Critique 两种类型,会标示:检查是否有检索的必要,完成检索后检查输出的相关性、完整性、检索片段是否支持输出的观点。模型会基于原有词库和反思字段来生成下一个 token。
-
Self-RAG 的训练过程
-
对于训练,模型通过将反思字符集成到其词汇表中来学习生成带有反思字符的文本。 它是在一个语料库上进行训练的,其中包含由 Critic 模型预测的检索到的段落和反思字符。 该Critic 模型评估检索到的段落和任务输出的质量。 使用反思字符更新训练语料库,并训练最终模型以在推理过中中独立生成这些字符。
-
为了训练 Critic 模型,手动标记反思字符的成本很高,于是作者使用 GPT-4 生成反思字符,然后将这些知识提炼到内部 Critic 模型中。 不同的反思字符会通过少量演示来提示具体说明。 例如,检索令牌会被提示判断外部文档是否会改善结果。
-
为了训练生成模型,使用检索和 Critic 模型来增强原始输出以模拟推理过中。 对于每个片段,Critic 模型都会确定额外的段落是否会改善生成。如果是,则添加 Retrieve=Yes 标记,并检索前 K 个段落。 然后 Critic 评估每段文章的相关性和支持性,并相应地附加标记。最终通过输出反思字符进行增强。
-
然后使用标准的 next token 目标在此增强语料库上训练生成模型,预测目标输出和反思字符。 在训练期间,检索到的文本块被屏蔽,并通过反思字符 Critique 和 Retrieve 扩展词汇量。 这种方法比 PPO 等依赖单独奖励模型的其他方法更具成本效益。 Self-RAG 模型还包含特殊令牌来控制和评估其自身的预测,从而实现更精细的输出生成。
-
Self-RAG 的推理过程
-
Self-RAG 使用反思字符来自我评估输出,使其在推理过中中具有适应性。 根据任务的不同,可以定制模型,通过检索更多段落来优先考虑事实准确性,或强调开放式任务的创造力。 该模型可以决定何时检索段落或使用设定的阈值来触发检索。
-
当需要检索时,生成器同时处理多个段落,产生不同的候选。 进行片段级 beam search 以获得最佳序列。 每个细分的分数使用 Critic 分数进行更新,该分数是每个批评标记类型的归一化概率的加权和。 可以在推理过中中调整这些权重以定制模型的行为。 与其他需要额外训练才能改变行为的方法不同,Self-RAG 无需额外训练即可适应。
多向量检索器多模态 RAG
https://blog.langchain.dev/semi-structured-multi-modal-rag/
-
多向量检索器(Multi-Vector Retriever)核心想法 将文档(用于答案合成)和引用(用于检索)分离,这样可以针对不同的数据类型生成适合自然语言检索的摘要,同时保留原始的数据内容。它可以与多模态 LLM 结合,实现跨模态的 RAG

-
如何让 RAG 支持半结构化 RAG(文本+表格) 此模式要同时处理文本与表格数据。其核心流中梳理如下:
-
将原始文档进行版面分析(基于 Unstructured 工具),生成原始文本和原始表格。
-
原始文本和原始表格经 summary LLM 处理,生成文本 summary 和表格 summary。
-
用同一个 embedding 模型把文本 summary 和表格 summary 向量化,并存入多向量检索器。
-
多向量检索器存入文本/表格 embedding 的同时,也会存入相应的 summary 和 raw data。
-
用户 query 向量化后,用 ANN 检索召回 raw text 和 raw table。
-
根据 query+raw text+raw table 构造完整 prompt,访问 LLM 生成最终结果

-
如何让 RAG 支持多模态 RAG(文本+表格+图片) 对多模态 RAG 而言有三种技术路线,如下我们做个简要说明:
-
选项 1:对文本和表格生成 summary,然后应用多模态 embedding 模型把文本/表格summary、原始图片转化成 embedding 存入多向量检索器。对话时,根据 query 召回原始文本/表格/图像。然后将其喂给多模态 LLM 生成应答结果。
-
选项 2:首先应用多模态大模型(GPT4-V、LLaVA、FUYU-8b)生成图片 summary。 然后对文本/表格/图片 summary 进行向量化存入多向量检索器中。当生成应答的多 模态大模型不具备时,可根据 query 召回原始文本/表格+图片 summary。
-
选项 3:前置阶段同选项 2 相同。对话时,根据 query 召回原始文本/表格/图片。构造完整 Prompt,访问多模态大模型生成应答结果
-
如何让 RAG 支持私有化多模态 RAG(文本+表格+图片)
如果数据安全是重要考量,那就需要把 RAG 流水线进行本地部署。比如可用LLaVA-7b 生成图片摘要,Chroma 作为向量数据库,Nomic's GPT4All 作为开源嵌入模型,多向量检索器,Ollama.ai 中的 LLaMA2-13b-chat 用于生成应答。
RAG Fusion 优化策略
-
思路:
-
检索增强这一块主要借鉴了 RAG Fusion 技术,这个技术原理比较简单,概括起来就是,当接收用户 query 时,让大模型生成 5-10 个相似的 query,然后每个 query 去匹配 5-10 个文本块,接着对所有返回的文本块再做个倒序融合排序,如果有需求就再加个精排,最后取 Top K 个文本块拼接至 prompt。
-
**RAG-Fusion’s ⼯作步骤: **
-
查询语句的相关性复制:通过LLM将用户的查询转换为相似但不同的查询。
-
并发的向量搜索:对原始查询及其新生成的同级查询执行并发的向量搜索。
-
智能重新排名:聚合和细化所有结果使用倒数排序融合(RRF)。
-
最后优中选优:将精心挑选的结果与新查询配对,引导LLM进行有针对性的查询语句输出,考虑所有查询和重新排序的结果列表。
-
优点:
-
增加了相关文本块的召回率;
-
对用户的 query 自动进行了文本纠错、分解长句等功能
-
缺点: 无法从根本上解决理解用户意图的问题
模块化 RAG 优化策略
https://zhuanlan.zhihu.com/p/713046522

动机:打破了传统的“原始 RAG”框架,这个框架原本涉及索引、检索和生成,现在提供 了更广泛的多样性和更高的灵活性。
模块介绍:
-
搜索模块: 融合了直接在(附加的)语料库中进行搜索的方法。这些方法包括利用大语言 模型(LLM)生成的代码、SQL、Cypher 等查询语言,或是其他定制工具。其搜索数据源 多样,涵盖搜索引擎、文本数据、表格数据或知识图等。
-
记忆模块: 本模块充分利用大语言模型本身的记忆功能来引导信息检索。其核心原则是寻 找与当前输入最为匹配的记忆。这种增强检索的生成模型能够利用其自身的输出来自我提 升,在推理过中中使文本更加贴近数据分布,而非仅依赖训练数据。
-
额外生成模块: 面对检索内容中的冗余和噪声问题,这个模块通过大语言模型生成必要的 上下文,而非直接从数据源进行检索。通过这种方式,由大语言模型生成的内容更可能包含 与检索任务相关的信息。 任务适应模块: 该模块致力于将 RAG 调整以适应各种下游任务。
-
对齐模块: 在 RAG 的应用中,查询与文本之间的对齐一直是影响效果的关键因素。在模 块化 RAG 的发展中,研究者们发现,在检索器中添加一个可训练的 Adapter 模块能有效 解决对齐问题。
-
验证模块: 在现实世界中,我们无法总是保证检索到的信息的可靠性。检索到不相关的数 据可能会导致大语言模型产生错误信息。因此,可以在检索文档后加入一个额外的验证模块, 以评估检索到的文档与查询之间的相关性,这样做可以提升 RAG 的鲁棒性。
RAG在基于垂直领域表现不佳怎么解决
-
模型微调:一个是对 embedding 模型的基于垂直领域的数据进行微调;
-
一个是对 LLM 模型 的基于垂直领域的数据进行微调
如何做到低延迟
如何解决幻觉问题(比如要推荐的产品是存在于产品库的)
https://mp.weixin.qq.com/s/xMsPh8qicRD395vjFR250A
https://www.anyscale.com/blog/a-comprehensive-guide-for-building-rag-based-llm-applications-part-1
RAG如何测评、评估
评估方法
主要有两种方法来评估 RAG 的有效性:独立评估和端到端评估。
-
独立评估:独立评估涉及对检索模块和生成模块(即阅读和合成信息)的评估。
-
检索模块: 评估 RAG 检索模块的性能通常使用一系列指标,这些指标用于衡量系统(如搜 索引擎、推荐系统或信息检索系统)在根据查询或任务排名项目的有效性。 1. 指标:命中率 (Hit Rate)、平均排名倒数 (MRR)、归一化折扣累积增益 (NDCG)、精确度 (Precision) 等。
-
生成模块: 生成模块指的是将检索到的文档与查询相结合,形成增强或合成的输入。这与最 终答案或响应的生成不同,后者通常采用端到端的评估方式。
-
评估指标:关注上下文相关性,即检索到的文档与查询问题的关联度。
-
端到端评估:对 RAG 模型对特定输入生成的最终响应进行评估,涉及模型生成的答案与输入 查询的相关性和一致性。
-
无标签的内容评估: 评价指标:答案的准确性、相关性和无害性
-
有标签的内容评估: 评价指标:准确率 (Accuracy) 和精确匹配 (EM)
评估指标
评估 RAG 在不同下游任务和不同检索器中的应用可能会得到不同的结果。然而,一些学术 和工中实践已经开始关注 RAG 的通用评估指标和有效运用所需的能力。
关键指标:集中于三个关键指标:答案的准确性、答案的相关性和上下文的相关性。
关键能力: RGB 的研究分析了不同大语言模型在处理 RAG 所需的四项基本能力方面的表现,包 括抗噪声能力、拒绝无效回答能力、信息综合能力和反事实稳健性,从而为检索增强型生成 设立了标准
评估框架
RAGAS
RAGAS 是一个基于简单手写提示的评估框架,通过这些提示全自动地衡量答案的准确性、 相关性和上下文相关性。
**算法原理: **
-
答案忠实度评估:利用大语言模型 (LLM) 分解答案为多个陈述,检验每个陈述与上下文 的一致性。最终,根据支持的陈述数量与总陈述数量的比例,计算出一个“忠实度得分”。
-
答案相关性评估:使用大语言模型 (LLM) 创造可能的问题,并分析这些问题与原始问题 的相似度。答案相关性得分是通过计算所有生成问题与原始问题相似度的平均值来得出的。
-
上下文相关性评估:运用大语言模型 (LLM) 筛选出直接与问题相关的句子,以这些句子 占上下文总句子数量的比例来确定上下文相关性得分
ARES
ARES 的目标是自动化评价 RAG 系统在上下文相关性、答案忠实度和答案相关性三个方 面的性能。
ARES 减少了评估成本,通过使用少量的手动标注数据和合成数据,并应用预测 驱动推理 (PDR) 提供统计置信区间,提高了评估的准确性。
算法原理:
-
生成合成数据集:ARES 首先使用语言模型从目标语料库中的文档生成合成问题和答案,创 建正负两种样本。
-
训练大语言模型 (LLM) 裁判:然后,ARES 对轻量级语言模型进行微调,利用合成数据集 训练它们以评估上下文相关性、答案忠实度和答案相关性。
-
基于置信区间对 RAG 系统排名:最后,ARES 使用这些裁判模型为 RAG 系统打分,并结 合手动标注的验证集,采用 PPI 方法生成置信区间,从而可靠地评估 RAG 系统的性能。


为什么qwen7b? 如果选用的模型参数大的话,时延过高,那效果怎么保证呢?将大模型进行知识蒸馏,再调参,效果不差
全参还是微调? 全参效果更好,
"加权整合SFT数据",可以理解为一个模型同时训练多种任务,具备多个能力

